Possible schemes for forging a magnetic stripe

In the right hand, we only have a card with a magnetic stripe, which is transferred to the information 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 stripe, and if it is equal to 2xx, it must require the transaction to be performed using the chip.
The terminal must not allow magnetic stripe operations if the service code value is 2xx and the terminal did not make a decision to switch to Fallback mode after trying to use the card chip to perform the operation. You must have a clear instruction for the cashier and a clear message on the terminal display that the transaction must be performed using the chip or be rejected.
In many implementations of the terminal application, despite the warnings, the seller still has the ability to circumvent the above rule and perform the 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.
Still, the Issuer is recommended to reject transactions in which the data element DE 061 (POS Data in terms of MasterCard) indicates that the terminal can perform an operation on the chip, but conducts it on the magnetic stripe and the POS Entry Mode (DE022) is not equal to 80X (case of Fallback), but is equal, for example, to 90X (magnetic stripe) or 05x (chip).
Let’s now consider “Case 1. Option 1. Magnetic terminal”. In the right hand we have the same card as in the previous case. In this case, the card may additionally contain a non-personalized chip for greater credibility. We are trying to use this card in a terminal that accepts only cards with a magnetic stripe.
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 same zone of the Chip Liability Shift accepted in the payment system;
the Issuer— in all other cases.
To protect against fraud, when a fake card does not have a chip, the display of magnetic terminals in the case of a card with a Service Code=2xx you should see a message about the need for the merchant’s cashier to check whether the chip is present on the card. If the chip is not present, the cashier must decline to accept the card.
Case 1. Option 2. data from the first and second tracks of the hybrid credit card is copied to the card with a magnetic stripe only, and the service code value is changed to 1xx. The card is used offline for performing unlimited operations (the operation size is less than the Terminal Floor Limit). Using the card in real time has little chance of success, because changing the service code violates the integrity of the record of the second track of the magnetic card, and checking the CVV/CVC value in the processing center of the Issuer will detect this fact.
In this case, there is every possibility 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, the entire responsibility for fraud lies with the card Issuer. This is by far the most serious gap in the concept of chip migration. Indeed, both the card and the terminal support the new technology, and yet card forgery is possible without any violations of the rules of card acceptance by the merchant. To avoid this type of fraud, payment systems are going to soon adopt a rule according to which all transactions on cards with a magnetic stripe in terminals that support online operation must be sent for authorization to the Issuer.
If the terminal accepts only cards with a magnetic stripe, then the following are responsible for fraud:
the servicing Bank, if this Bank and the Issuer of the fake card are located in the same zone of the responsibility shift accepted in the payment system;
the Issuer— in all other cases.
Case 2. Initializing a Fallback to a fake magnetic stripe. A blank hybrid card with a “curve” (for example, a burned or incorrectly personalized) chip is used. In this case, the billet will cost more (about 50 cents), but you can apply information copied from the magnetic track of a real hybrid card to the magnetic stripe and use it in both the magnetic and hybrid terminal.
If a fake card is used in a hybrid terminal, the entire responsibility for fraud lies with the card Issuer.
If the terminal accepts only cards with a magnetic stripe, then the following are responsible for fraud:
the servicing Bank, if this Bank and the Issuer of the fake card are located in the same zone of the responsibility shift accepted in the payment system;
the Issuer— in all other cases.
The only counter measure to combat this type of fraud is the organization of monitoring the number of Fallback transactions performed on each card of the Issuer in the Issuer’s processing center. If the number of Fallback operations for a certain card is higher than the threshold value, 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.
Fake chip As previously noted, fake (CLO the chip can only be copied based on the data read by the terminal on the card. Here are the ways to clone a hybrid card that were already mentioned above. In all cases, to achieve the result, the cloned card must only be used in offline transaction authorization mode. The following was established.
If the hybrid card is an SDA card, it is easily cloned to the SDA card.
If we are dealing with a DDA / CDA card that also directly supports the SDA method (the card contains a Signed Static Application Data object), then this card can be cloned to the SDA card:
by changing the card profile (Application Interchange Profile object) that does not have an SDA Tag List object, so that the card profile indicates that the card only supports the SDA method;
when using the card in terminals that only support the SDA card authentication method or in violation of the rules of payment systems in terminals that do not support any offline authentication method;
when using a card issued using a false system key in a terminal where the false system key was pre-loaded.
DDA-card “upgrade”, created on its basis the printed circuit Board using along with the chip a second chip emulator, the current scheme of attack two chips.
Once again, it is practically possible to fake a chip only by cloning it— transferring the chip data to another chip. Indeed, in order to change data on an already personalized chip, you can use two methods: try to do this using the Script Processing procedure or in the card personalization mode.
In the Script Processing procedure, the PUT DATA and UPDATE RECORD commands are used to change records and individual data objects. These commands are applied using MAC codes and
if necessary, data encryption. In addition, these commands are most often executed after authentication with the Issuer’s card.
Therefore, during the Script Processing procedure, fraud is only possible if the card/Issuer’s secret keys used to generate the cryptogram and ensure the integrity of data exchange (generating the Message Authentication Code) are compromised.
The keys used in the personalization stage and in the Script Processing procedure are different.
Counterfeit chip data in the card personalization mode is also possible only as a result of compromising the keys of the card/Issuer/card manufacturer. This follows from the description of the card lifecycle (see section 5.1). The chip manufacturer assigns each chip its serial number (Chip Serial Number) and enters the card provider’s secret key into the chip, which is output from the card provider’s key using the chip’s serial number as a diversification fashion.
Then the card supplier, after implementing the chip into the plastic of the card, performs the pre-personalization procedure for the card. At the beginning of the procedure, the card must authenticate the card provider using the card’s secret key, which was previously set up by the chip manufacturer and is known only to the card and its supplier. Only after successful authentication of the card provider can it be pre-personalized.
In the card security projection, the pre-personalization procedure consists of entering three keys on the card, which are output from the card provider’s secret key and the KEY DATA element, which includes the chip’s serial number. These keys are used for displaying session keys of the card used during the personalization stage to generate cryptograms, ensure the confidentiality and integrity of data transmitted from the personalization machine to the card.
This means that the personalization stage uses a separate set of keys that differs from similar keys used during the transaction.
It follows from the above that at the card personalization stage, fraud is only possible if the card/Issuer’s secret keys are compromised.

Stolen/lost/not received cards (Lost/Stolen / NRI)
The microprocessor card is also a powerful tool in the fight against such types of fraud as stolen/lost/uncollected cards. Using the Chip&PIN approach, adopted today in the UK, allows you to significantly reduce these types of fraud. The DDA/CDA + PIN Offline method is the most reliable of all known methods of protection against card fraud.
Here it is important to note that the implementation of the Chip&PIN approach should be implemented from two sides — both on the part of the Issuer and the servicing Bank. To encourage the servicing Bank to install terminals that support PIN Offline, payment systems introduce the Chip&PIN Liability Shift, as well as other rules that introduce an element of economic attractiveness for using such terminals.
CNP transaction fraud
With the migration to the chip (especially in the Chip&PIN version), there will be a decrease in fraud such as “Fake card”, ” Stolen/Lost/Non-received cards” and the movement towards scams of the CNP and ID Theft types. Unfortunately, the use of IPC does little to combat these types of fraud, except for providing convenient authentication of the cardholder in a transaction made using the 3D Secure Protocol by the Issuer’s Access Control Server (Chip Authentication Program/Token Based Authentication technology)

Fraud by an unfair trading company
Let’s focus on another type of fraud, which is possible on the part of an unscrupulous merchant. In simplified form, fraud looks like this.
When a microprocessor card holder applies to a merchant for a purchase, the merchant completes any terminal/card decision by rejecting the transaction. In this case, the cardholder either leaves the merchant with nothing, or pays for the product in cash.
Then the fraudulent merchant sends the data on the unsuccessful transaction to the servicing Bank as an operation successfully completed offline. The servicing Bank is presented with all the evidence that the transaction was completed successfully: a forged cryptogram Information Data value indicating that the operation was completed by generating a cryptogram of the vehicle card, a cryptogram value that does not depend on its type (vehicle, ARQC, AAC), and the ICC Dynamic Number value. All this data, with the exception of Cryptogram Information Data, could only be generated by a real microprocessor card.
The servicing Bank generates segments based on the received data, which it sends to the payment system, and reimburses the merchant for the “performed” operations in it.
After some time, some cardholders initiate chargebacks for fraudulent transactions made using their cards. However, it will be difficult for the Issuer to initiate them, since the servicing Bank has presented the TC cryptogram in the presentation or at the request of the Issuer (the message retrieval request).
In this case, the payment system will be able to understand the situation, which after a while will find out that a strange situation has arisen, when customers complain, clearing messages transmitted by the servicing Bank look convincing, which happens unusually often in one point of sale. To understand this situation, the payment system will take time. During this time, the fraudulent company will be able to escape.
Another way to combat such fraud is to use the CDA method for offline card authentication and the requirement for a merchant company, which is that the company provides the Signed Dynamic Application Data element to the servicing Bank, and not just a cryptogram. In this case, the servicing Bank extracts the correct cryptogram Information Data value from the Signed Dynamic Application Data element, and the fraud scheme described earlier does not work.

The fight against ATM fraud
Cases of fraud using ATMs. Adhering to the accepted numbering of types of fraud, we can say the following. Microprocessor cards will not solve only problems 1, 2 and 4, since the presence of a plastic card in the hands of a fraudster and the PIN code of its holder is a sufficient condition for successful cash withdrawals at an ATM.
In all other cases, the use of a microprocessor card will avoid fraud. When using a microprocessor card online, knowledge of the PIN code and all the card data available to the terminal is not sufficient for the successful execution of the operation by a fraudster. A necessary condition in this case is to know the card’s secret key, which is not available to the fraudster, and which is used to generate the cryptogram. The key is necessary for mutual authentication of the card and the Issuer, without which the transaction will be rejected (we do not consider the degenerate case when the Issuer does not support the processing of “chip” card data).
Key management
Key management issues are discussed in sections 10 and 11 of Book 2 of the EMV 4.1 standard. the Presence of a PKI infrastructure within the payment system is one of its most important elements, which allows for a high level of security of transactions performed using microprocessor cards.
The payment system certification authority (CA) is controlled by the payment system and is used for calculating the Issuer’s certificates. CA public keys are sent to the servicing banks (for verifying the Issuer’s key certificates, which is necessary when performing card authentication and PIN block encryption procedures during transaction processing), as well as to issuers for one-time verification of the Issuer’s public key certificate received from the CA.
To exchange keys between the Bank and the CA, you must install a secure channel that eliminates the possibility of forgery — providing the key and the Issuer’s key certificate from a false system certification authority. In other words, the procedure for transferring the public key to the Bank must ensure the authentication of the key source (the payment system certification authority) and the integrity of the transmitted key.
It is necessary to pay special attention to the issue of entering false asymmetric system keys into the terminal application. When entering false keys in a certain terminal, fraudsters can personalize cards with these system keys and use them in terminals with previously loaded false system keys.
Each public key of the system has an expiration date, after which it must be withdrawn from use. This procedure is called the revocation procedure. Key revocation can be planned (after the expiration of the system key) or accelerated (for example, due to key compromise). In the second case, the payment system simply notifies its participants about the change in the key validity period. Servicing banks are required to revoke the system keys in all their terminals within three months from the date of the key expiration.
All public keys in the system expire on December 31 of the year. If the key is revoked, the date may be different (not December 31), since the validity period is changing. However, the six-month period provided by the payment system for revoking the key from the terminals remains in this case.
The system certification authority must distribute the new public keys of the system by January 1 of next year. After that, the servicing banks must upload the new system keys to all their terminals within 6 months, i.e. by June 30 of the following year.
Payment systems allow using new system keys in terminals only from January 1, despite the fact that the keys can be brought to banks before January 1. At the same time, the payment system starts using the new system keys to create the Issuer’s public key certificates no earlier than June 30 of the same year.
Payment systems support the decision that the validity period of all certificates used for offline card authentication and PIN block encryption, if such a key is used, must be longer than the validity period of the card. This is necessary in order for the hybrid card to be able to perform a transaction on the chip during its entire lifecycle.
Special attention should be paid to secure key storage in the Issuer’s system. The following keys used in the IPC are stored in the Issuer’s system:
1MCAS-key for generating the master key of the ICAS card intended for output of the session key for generating application cryptograms;
IMKSMI-key for generating the master key of the MCS card, intended for output of the session key used to ensure the integrity of data transmitted in the command and authentication of the data source;
1MKJ-key for generating the master key of the a1kj card intended for output of the session key used to ensure the confidentiality of data transmitted in the team;
1MKSH-key for generating the master key of the MKWN card, intended for calculating the value of the ICC Dynamic Number;
IMKqAc-key for generating the master key of the MK0A card[D intended for calculating the value of the DAC (Data Authentication Code);
the Issuer’s key used for generating public key certificates for the card.
Compromising, for example, the Issuer’s key used when performing the card authentication procedure, leads to the possibility of creating a card that successfully authorizes transactions offline. The EMV V. 4. 1 standard does not pay attention to the distribution of CRL sheets (certificate revocation sheets) to servicing banks in case of compromising the Issuer’s keys. These issues should be reflected in the operating rules of specific payment systems.
We need to work out the Bank’s response to the case of keys being compromised. You should start working through this issue by defining the card settings. For example, to prevent compromise of any symmetric key of a card that supports dynamic authentication, it is useful to set the Offline Dynamic Authentication Failed bit in the Card Issuer Action Code— Offline and Card Issuer Action Code — Online objects to 1. This will prevent successful completion of operations using cards with compromised symmetric keys offline and control the issue of compromising the Issuer’s keys and its cards on the Issuer’s host. Indeed, if the fake card does not know the asymmetric key, it will fail its dynamic authentication procedure, and the terminal will send the authorization operation to the Issuer, who, if it knows about the fact of compromising its symmetric key, will reject such a transaction.
Of course, the Issuer can act more radically and reliably by setting the Offline Dynamic Authentication FaiLed bit in the Card Issuer Action Code— Decline object to 1, thereby declaring the failure of dynamic card authentication sufficient to reject the operation. However, in this case, the card’s availability in the payment system’s terminal network may be restricted. We have already mentioned the reasons for this restriction. They may include the absence of the system key on the terminal that was used to certify the Issuer’s key, errors in the terminal application (for example, the terminal did not present a random number to the card)