Clone MasterCard in MagStripe mode
We proceed directly to the principle of cloning. This contactless card attack method was published by two researchers Michael Roland, Josef Langer from the University of Austria. It is based on a general principle called Skimming. This is such a scenario in which an attacker steals money from a bank card by reading (copying) information from this card. In the general case, it is important to keep the PIN code confidential and prevent it from leaking. But in the method of the Austrian guys we do not need to know this. Cloning of a payment card is successful for the kernel version of the EMV Contactless Kernel 2 application. The version of this protocol supports two operating modes for contactless cards: EMV protocol (MasterCard PayPass M / Chip) and MagStripe (MasterCard PayPass MagStripe) mode.
MagStripe is a magnetic stripe card support mode. This mode is implemented on MasterCard cards with a contactless interface. MagStripe mode is most likely needed for banks that find it difficult to translate the entire infrastructure to support chip contactless EMV transactions. By the way, Visa cards also have a similar mode of operation – PayWave MSD (Magnetic Stripe Data).
The transaction processing process for contactless cards has been reduced in comparison with chip cards and usually works in the following mode:
The terminal sends a SELECT PPSE (Proximity Payment System Environment) command. The card sends a list of supported applications.
The terminal sends a SELECT command. In response, he receives the necessary application details.
The terminal sends the GET_PROCESSING_OPTIONS command. The card answers what type of authentication it supports and whether verification of the cardholder exists there.
The terminal sends the READ_RECORDS command. The card in response sends Track1 and Track2 almost the same as that recorded on the magnetic strip of the card.
The terminal sends the COMPUTE_CRYPTOGRAPHIC_CHECKSUM command. Which means that the card should generate a CVC3 value based on the passed Unpredictable Number.
The card supports the special COMPUTE CRYPTOGRAPHIC CHECKSUM command, the argument of which is the data defined in the Unpredictable Number Data Object (UDOL). As a result, the card uses the 3DES algorithm and the secret key to calculate the dynamic value CVC3 (Card Verification Code). As an argument to the 3DES function, the concatenation of the UDOL data and the transaction counter (Application Transaction Counter, ATC) are used. Thus, the value of CVC3 always depends on the UN and ATC objects.
In other words, this command is needed so that the card generates a certain “signature” so that the issuer can verify the card. However, in this signature there is no signature of the transaction itself. The signature contains ATC values - 2 bytes, CVC3 (Track1) – 2 bytes, CVC3 (Track2) – 2 bytes, which are generated by the card based on a secret key that the issuing bank and transaction counter (ATC) also know. At the same time, to generate the signature, the POS terminal informs the UN (Unpredictable Number) card – 4 bytes, which is also used in the generation of the signature. Unpredictable Number prevents the generation of authentication codes on a real card for subsequent use in fraudulent transactions. For the attack, the UN strongly interferes with us, since it is not possible to enumerate 4 bytes without going beyond the limits of the transaction counter. However, there are some weaknesses in the specification of this.
Firstly, the specification restricts the UN to the encoding of numbers, namely the Binary Decimal Code (BCD), which essentially means that if we look at such an encoded number in HEX, we will only see numbers from 0 to 9, all other values are considered as if forbidden. Thus, the amount of UN decreases from 4,294,967,295 to 99,999,999.
Secondly, the number of significant UN digits is determined by the card. Thus, depending on the special parameters in the tracks, the number of digits in the UN can be from 10 to 10000, depending on the type of card, in practice, 1000 values are most often found.
Thus, the attack plan is as follows:
We read the card and find out the number of significant digits from UN, which the terminal will provide
We sort through all UNs, get all possible values of the COMPUTE_CRYPTOGRAHIC_CHECKSUM function, save them in the corresponding table with mapping UN -> Result
We bring it to the POS terminal, we find out the number that the POS terminal asks for.
We select the desired result from the table and substitute it in response to the terminal.
The transaction is leaving.
PROFIT. But the success of the approval of the transaction is not guaranteed, because the issuing bank may reject such a transaction.
It is also worth noting that the transaction counter (ATC) prevents the reuse of previously used authentication codes, which means that if we used this attack, we must copy the card again, since the transaction counter was already used to obtain information and was used in the signature, which means that if we had a transaction counter of 1000, and after we sent the transaction to the bank, the bank will no longer accept transactions with a counter below <1001. In addition, the transaction counter is limited to 2 bytes, which means that we can perform no more than 65 card cloning cycles, after which the card most likely will stop working.
In most cases, the data transferred from the card is static for all transactions. Of course, except COMPUTE_CRYPTOGRAPHIC_CHECKSUM. To generate dynamic CVC3 code, the map application must be read with the SELECT command, then GET_PROCESSING_OPTIONS, and only then COMPUTE_CRYPTOGRACHIC_CHECKSUM and this is a pretty important point. These three commands are required to generate CVC3. According to the experiment, using only these three commands, it took just one minute to search 1000 values on the Google Galaxy Nexus S.
To work with the terminal and the card, the Terminal Simulator program from MasterCard was used. It works great with various NFC readers and smart card readers. In addition, it is absolutely free. It allows you to test cards with various settings of the POS terminal and maintains a detailed log of all requests from the terminal and card responses. It can also be used to test the application on the phone, working in map mode.
To read the card, the NFC reader ACR122 was used.
Now let’s try to convert all this into code. The application will be written in the Kotlin language for Android. First, let’s try to describe the general structure of the team.