Security of EMV transactions

To implement the CAP method, the client must have a microprocessor card with an EMV application, as well as a special card reader capable of initiating the generation of an OTP password and displaying its value consisting of 8 digits on the reader’s display (sometimes the reader and the card are combined in one physical device). Such a reader can cost several euros (10-15 euros, depending on the manufacturer and the volume of the purchased batch of devices). In addition to the additional costs of providing cardholders with readers, another disadvantage of this approach is the fact that the client needs to come to the bank for a card reader, and, in addition, to carry out the operation, the reader must be at hand, which is not always convenient, since the size of the device significantly exceeds the size of a bank card, and such a reader does not fit in a wallet.

Against this background, the cell phone, being the most popular mobile device used by the population of the planet (according to the results of 2005, more than 2 billion cell phones were used worldwide, and by 2010 about 3 billion consumers will have this device), has long attracted the attention of researchers as a potential universal authentication tool. Moreover, the capabilities of mobile phones, both in terms of their computing abilities, supported communications, and in terms of functionality, are constantly growing.

However, today there are difficulties in using a mobile phone as an authentication tool. They are as follows. It is known that a truly secure place to store confidential information on a phone is a SIM card (some phone models have a separate microprocessor that performs the function of a security element-security element; but there are few such models on the market). However, you can download information to the SIM card only with the permission of the mobile operator controlling it. At the same time, even if the latter authorizes the download and use of confidential client information on the SIM card, the only possible way to implement this in practice is to preload data to the SIM card during its personalization by the operator or his authorized personalization center. Remote personalization of the SIM card using over-the-air technology (OTA-GSM 03.48), designed to download data and applications to the SIM card and supported by all Java cards personalized with OTA profile support, is not actually used in practice, since in this case the bank must share its confidential information with the cellular operator. The fact is that the procedure for downloading data using OTA technology today is under the full control of the mobile operator.
The same applies to the technology based on the use of the Security and trusted services API protocol (SATSA, JSR177), which allows the midlet to use procedures and data uploaded to a SIM card that supports Java Card (most of these SIM cards today). In addition to the fact that the JSR177 specification is optional for the MIDP 2.0 profile of the J2ME platform, and therefore is practically not supported by cell phones, authorization of midlet access to card applications using SATSA is still required from the cellular operator.

At the same time, MasterCard released the MasterCard mobile authentication (MMA) specification, which is based on the CAP scheme implemented by a midlet loaded on a Java-compatible phone. Recall that at the input of the CAP algorithm, the current operation number (ATC), the card application profile (AIP) are set, at the output — an 8-digit digital one-time password, which is a function of the AAC cryptogram (authentication application cryptogram). A cryptogram is formed using an algorithm defined in the EMV standard for calculating an applied cryptogram. This algorithm uses a double-length key (112 bits) customer master key, which is the only secret transmitted to a mobile phone.

To ensure the confidentiality of the secret data of the midlet (customer master key), when downloading it to the phone, the PBE (password-based encryption) algorithm is used, implemented as part of the standard Bouncy Castle APIs for J2ME package, which, in turn, implements a standard interface to cryptographic functions defined by MIDP (mobile information device profile). In general terms, the MIDP profile is an open programming interface to J2ME libraries on cell phones and other devices. When forming a key in the PBE algorithm (the 3DES algorithm is used for data encryption), the client’s mobile PIN code is used as a password, and the phone number (MSISDN) is used as a Salt value.

The mobile PIN code is invented by the client and used by him every time when initializing the midlet on his phone. The value of the mobile PIN code entered by the customer is necessary to decrypt the customer master key, which is stored in the phone in encrypted form. Therefore, if you enter an incorrect PIN value, an incorrect value of the customer master key will be obtained as a result of decryption, which means an incorrect value of the AAC cryptogram and a one-time password will be calculated. The last fact will be recorded on the client authentication server.

Thus, the reliability of the described scheme is mainly determined by the secrecy of the client’s mobile PIN code. If the phone falls into the hands of a fraudster who does not know the value of the PIN code, then after three unsuccessful authentication attempts (an incorrect value of the calculated cryptogram), the client will be blocked on the authentication server, and further use of the midlet will become impossible.
Analysis of the authentication scheme using the midlet shows that since all cryptographic calculations in this case are performed by the phone processor, theoretically, by downloading a spy program to the phone that monitors the state of the phone’s memory and transmits information from RAM to the outside, you can compromise the value of the customer master key, and hence the scheme as a whole. To date, the list of viruses for cell phones consists of 30-40 programs, while a similar list for personal computers is several hundred thousand programs. At the same time, we are not very afraid to enter passwords on the keyboard of our computer for Internet banking or for our authentication when performing EC operations.

Summarizing the above, it can be stated that the large-scale implementation of the 3D Secure protocol has not yet occurred. By mid-2007, the 3D Secure protocol was supported by more than 115 thousand online stores, approximately 400 servicing banks and 3160 issuing banks. The leader in the implementation of 3D Secure is the United Kingdom, which accounts for more than 31 thousand online stores. Approximately 65% of all online stores supporting 3D Secure are located in Europe.

From the point of view of the issue, more than 20.5 million MasterCard and Maestro cardholders have registered to use the protocol only in the MasterCard payment system. Of course, this is a very small proportion (several percent) of cardholders in terms of the total number of cards of this payment system. It can be said that it is the slow implementation of the emission part of the protocol that is the main reason for increasing the security of EC operations.

At the same time, according to MasterCard in July 2007, approximately 22% of all EC operations in Europe were carried out in stores that support 3D Secure. At the same time, in about 6% of all operations, 3D Secure was supported both by trading enterprises and servicing banks, and by card issuers.

Many servicing banks (online stores) use additional checks in their systems when processing EC transactions. Such checks include:

* verification of the cardholder’s address (address verification system); provision of CVV2/CVC2 values to the issuer for verification;
* checking the number of transactions performed from a certain IP address (IP address frequency check);
* control of the number of transactions performed on the card during a certain period of time (card number frequency check);
* checking for the coincidence of the country of the delivery address of the goods with the country whose resident is the bank that issued the card (country match). The country of which the bank is a resident is determined by the value of the bank identification number (bank identification number, or BIN);
* checking the IP address (or grid of addresses) from which the transaction was initiated for its presence in the blacklist (block IP address);
* checking the location of the cardholder (by the IP address of his Internet provider) with the geography of goods delivery (geolocation);
* card screening by some LIce banks (block bank BINs);
* screening out transactions coming from anonymous proxy servers (block proxy);
* screening out transactions in which e-mail addresses from certain domains were specified, for example, domains that offer free e-mail services (block proxy);
* checking the card number for its presence in the blacklist (negative database);
* using open resources that store black lists of fraudulent card details (for example, CyberSource Negative Database and Scoring System, SharedGlobal Negative Database and Scoring System), as well as authenticating the cardholder by his phone number (MyVirtualCard).

The first two checks from the above list are recommended by payment systems. So VISA believes that using CVV2 verification reduces the likelihood of fraud by more than 60%. Today, payment systems are taking steps to oblige issuers to check the CVC2/CVV2 values obtained from authorization requests in their processing systems, and high-risk trading enterprises (for example, online casinos) insert the values of these cryptocurrencies into authorization requests.
Research by ClearCommerce (USA) regarding the evaluation of the effectiveness of using the AVS system shows that only 40% of transactions successfully pass this check, despite the fact that the share of fraudulent among them is less than a percent. On the other hand, when using AVS, 35% of fraudulent transactions successfully overcome this protection.
In addition to the checks listed above, online stores sometimes pay attention to the following facts that increase the likelihood of fraud:

* the customer is being served in the store for the first time;
* the size of the operation is higher than the usual value for the store;
* the order consists of a large number of identical items;
* transactions are carried out on cards with similar numbers;
• the delivery address of the order is the same for purchases made with different cards;
* multiple transactions on the same card within a short time interval;
* multiple transactions performed on different cards with the same billing address, but different delivery addresses of goods;
* a transaction that the customer wants to pay with more than one card.

The store (especially the MO (TO) store) may have other reasons for doubt — the cardholder’s indecision in providing personal data, the requirement for urgency of order fulfillment, a strange delivery address, the customer’s disinterest in the properties of the goods (for example, in color), etc.
Another previously mentioned aspect of the fraud problem for CNP transactions is the theft of card details from the servers of mainly online stores. Despite the prohibition of payment systems, servicing banks and trading enterprises store CVC2/CVV2 values, card magnetic stripe data, addresses used in AVS, encrypted PIN blocks in their systems. Online stores leave data available to them in their databases: the card number, its expiration date, sometimes CVV2/CVC2 and the address used in the AVS system. Studies carried out by Visa USA have shown that in the USA 37% of trading enterprises, despite the prohibitions of payment systems, continue to store card information in their systems.

As a result, when hacking the websites of online stores, the data of cards of various issuers is compromised. The most significant cases are the hacking of the TJX server and the CardSystems Solutions processor database, as a result of which 45.7 and 40.0 million cards were potentially compromised, respectively.