Modification of DDA/CDA transactions

Here are the simplest examples of possible data modification. If the terminal in the GENERATE AC command has requested a cryptogram TC, and the card in the person of the bank chip decides to process the transaction online or reject it offline, then the emulator chip changes the unprotected cryptogram information data in such a way that the card responds to the terminal with a cryptogram TC. Thus, the transaction is approved despite the fact that by the issuer’s decision it must either be rejected or transferred to the issuer for authorization.

Another example. The emulator chip, having received the transaction size value from the terminal, changes it to a smaller value at which the card is ready to approve the transaction in offline authorization mode.
Such an emulator chip in the literature is called a wedge device. It must be said that 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 performs the function of an intermediary of information exchange between the card and the terminal.

The problem of ensuring the integrity of the information exchange of the card with the terminal is solved by using CDA cards. Such cards maintain the integrity of the most important information circulating between the card and the terminal during transaction processing. Therefore, it is impossible to modify the information exchange in a way that is invisible to the terminal.
In addition, CDA cards demonstrate higher performance (shorter transaction execution time) compared to DDA cards. This is due to the fact that the INERNAL AUTHENTICATE command is not used for offline authentication of the card, which reduces the exchange of terminal data with the card.

Ensuring the integrity of information exchange with the terminal and higher performance makes CDA cards attractive for contactless payments. In particular, the MasterCard PayPass standard considers only the CDA method as a method of dynamic authentication.

At the same time, CDA cards have a number of weaknesses. Firstly, the size of the CDA card key module may not exceed 205 bytes. To date, this restriction is not burdensome, since mostly smaller card keys are used. However, this limitation may become sensitive in the future. Payment systems already distribute their keys with a size of 248 bytes (the maximum key size in accordance with the EMV standard), allowing issuers and cards to use keys of comparable sizes.
Secondly, if the servicing bank (payment system) manages the loading of the system keys to the terminals carelessly, it may happen that the servicing bank did not load (or rather, did not load on time) some of the system keys on its terminals. In this case, all CDA cards of issuers whose keys are certified on a system key that is not present in the terminal 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 recover data from signed dynamic application data and will have to reject the transaction. This will happen even if the card, in response to the GENERATE AC command, sends an ARQC cryptogram to the terminal to process the transaction in real time. Without knowledge of the system key, it is impossible to recover 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, a transaction in the absence of a corresponding system key on the terminal could be performed online. The CDA method, in case of failure of card authentication, unlike other authentication methods, deprives it of the opportunity to apply for authorization to the issuer.

Summarizing the above, we list below the ways to clone a hybrid card for its use in offline transaction authorization mode:
1) If the hybrid card is an SDA card, then it is easily cloned into an SDA card;
2) if we are dealing with DDA/CDA-card-enabled method also directly SDA (on the card there is a data object with the signed static application data), then this card can be cloned to the SDA-card:
• changing profile card (object application interchange profile) that will be invisible for a terminal, in the absence of the object SDA tag list so that the profile card will point to support the SDA method;
• when using a cloned card in terminals that support, in violation of the rules of payment systems, only the SDA card authentication method or do not support any offline authentication method;
• when using a card issued using a false system key in a terminal to which the false system key was preloaded;
3) The DDA card can be “upgraded” by creating a printed circuit board based on it, which uses, along with the chip of the real card, a second chip simulator operating according to the two-chip attack scheme.
Once again, we note that chip forgery is practically possible only by cloning it — transferring data from a real chip to a chip used to produce a fraudulent card. Indeed, in order to change the data on an already personalized chip, you can use two ways: try to do it 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 execution of the script processing procedure, fraud is possible only if the secret keys of the card/issuer used to form a cryptogram and ensure the integrity of data exchange (formation of MAC codes) are compromised.
The keys used at the personalization stage and in the Script Processing procedure are different.
Forgery of chip data in the card personalization mode is also possible only as a result of compromising the card keys (issuer) of the card manufacturer.
The chip manufacturer assigns each chip its serial number (chip serial number) and enters the card supplier’s secret key into the chip, which is derived from the card supplier’s key using the chip’s serial number and key identifier as a diversification mode.

Further, the card supplier, after implementing the chip into the plastic of the card, performs the procedure of pre-personalization of the card. At the beginning of the procedure, the card must authenticate the card supplier using the card’s secret key previously established by the chip manufacturer, known only to the card and its supplier. Only after successful authentication of the card provider, he has the opportunity to perform its pre-personalization.
In the projection on the security of the card, the prepersonalization procedure consists in the fact that keys are entered on the card, which are derived from the secret key of the card issuer and the KEY DATA element, which includes the serial number of the chip and the key identifier of the issuer. These keys are designed to output the session keys of the card used at the stage of its personalization for mutual dynamic authentication of the card and the card personalization machine, as well as to ensure the confidentiality and integrity of data transmitted from the personalization machine to the card.

Thus, at the personalization stage, a separate set of keys is used, which differs from similar keys used when performing a transaction.
It follows from the above that at the stage of card personalization, fraud is possible only if the card’s (issuer’s) secret keys are compromised.

Recently, information about the scheme of virtual cloning of the card in real time appeared in print. The scheme is applicable to any cards (SDA, DDA, CDA), including those that support the verification of a secure PIN code. The idea is that the scammers have a terminal controlled by them, located, say, in a restaurant, as well as a card with an application running on a contact interface (ISO 7816) and a contactless radio interface (a victim interface, for example, in accordance with ISO 15 693, ISO 18 000). The purpose of the fraudulent card application is to support data exchange with the real POS terminal and the fraudster’s equipment in the data relay mode.

The scheme looks like this. A fraudster with a backpack on his shoulders comes, for example, to a jewelry store, chooses jewelry for 2000 euros and waits for a call from an accomplice in a restaurant. At this time, an unsuspecting restaurant visitor decides to pay with a card for lunch worth 20 euros. An accomplice of a fraudster with a backpack calls the latter and he goes to the cashier of a jewelry store to pay for jewelry with his fraudulent card.

Next, the fraudulent card is inserted into the reader of a real POS terminal, and the card begins to broadcast commands received from the real terminal via the radio interface to the fraudster’s equipment located in the backpack. The fraudster’s equipment, in turn, retransmits these commands to a POS terminal controlled by fraudsters, which delivers commands to the card of an unsuspecting restaurant customer. The responses of the restaurant customer’s card are transmitted to the real terminal of the jewelry store in reverse order..