Historically, the oldest payment method is based on the card number. In the past, credit cards had only their numbers, and that’s all. The number was embossed on the card. The card was ‘rolled’ using a special device to make a payment, and its number was entered into an ancient database (i.e. printed on a piece of paper). There’s a video from the Payment Village depicting that process.
These slips were sent to the acquiring bank at the end of the working day or week. Then the bank was sending requests to deduct these sums from the cardholders via the issuing banks. It was so long ago that very few people knew where the three-digit payment verification code printed on the back of the card (CVV2/CVC2) came from. Reportedly, this code was used as a checksum to make sure that the cardholder doesn’t make a mistake and correctly enters all the information while making a payment. This seems to be true, taking how short this code is.
Today, the physical card may be not involved in payments at all. This mechanism is called “card not present”; it’s most commonly used in online payments. If the card number is entered when making a payment at a terminal (which is typical for hotels, payments over the phone, and most terminals in the United States), it’s called PAN Key Entry.
Many people still believe that the Cardholder field on the front of the card must be entered correctly and that it’s checked. This is not true: not a single bank verifies this field.
Magnetic stripe operations represent one of the simplest payment methods. In peoples’ minds, it’s associated with certain fraud types. Such tricks as skimming at ATMs and double charges at restaurants are possible due to some shortcomings of the magnetic stripe. First, it’s easy to copy: all you need is a special magnetic stripe reader/writer that is also sometimes called an encoder. A cloned magnetic stripe is sufficient to make payments in most supermarkets in the world. To verify the cardholder, the cashier must compare the signature on the check with the cardholder’s signature on the back of the card.
The above picture shows the information recorded on the card. Black bars represent ones, while white bars represent zeros. A number of open-source solutions can be used to decode this data (e.g. magstripe).
As you can see, the card has not one but two magnetic stripes of different densities (Track1 and Track2). What data are recorded on a magnetic stripe?
- Card number, expiration date, cardholder’s name – i.e. all information that is physically imprinted on the front of the card;
- Service code – three digits that help the device (terminal or ATM) interact with the card to understand what functions does the card support and what doesn’t (i.e. is it possible to use this card at an ATM? is the card equipped with a chip? etc.).; and
- Card Security Code (CVV2, CVC2, CID – terminology depends on the payment system) – a code similar to the one printed on the back of the card. It’s calculated according to a cryptographic checksum algorithm (MDK MAC) using a 128-bit key based on the information recorded on the magnetic stripe. A computed CVV is used to protect the cardholder against certain attacks (e.g. when an attacker substitutes the service code and tries to convince the payment terminal that the card is not equipped with a chip). If such attacks take place, the issuing bank receives the magnetic stripe data, verifies it, and the checksum doesn’t match the transmitted value in the CVV field. Verification takes place in a secure environment at the issuing bank called HSM (Hardware Secure Module).
In the late 1990s, the magnetic stripe was replaced by smartcards popularized by the EMV consortium (Europay, MasterCard, and Visa). The idea promoted by EMV was simple: solve all the problems associated with the magnetic stripe using features of smartcards, symmetric cryptography, and the Public Key Infrastructure. Smartcard transactions have three levels of protection:
- Card authentication. The payment terminal verifies that the card is genuine and was indeed issued by a certain bank (i.e. wasn’t forged by malefactors);
- Cardholder verification. Checking that this card actually belongs to the buyer standing in front of the payment terminal; and
- Transaction authorization. The path from the card to the issuing bank is long. The bank must make sure that the transaction data haven’t been altered by malefactors (i.e. the amount remains the same, the transaction date is correct, and the transaction is unique and wasn’t made last month).
Let’s examine these protection mechanisms in more detail.
The authenticity of a card is checked using the RSA public-key cryptography. The current minimum key length requirement is 1024 bits. A limited number of certification centres issue keys for banks, and banks enrol the keypairs to the cards issued by them. The card’s private key is stored in the nonreadable area of the smartcard. Trusted root certificates are installed on the terminal in the course of its configuring. During the transaction, the card provides the public keys to the payment terminal along with the information encrypted with the private key in the digital signature mode. If the public key is trusted and could successfully decrypt the information transmitted by the card, then the terminal considers the card to be authentic. That would mean that the certification authority had issued the private key to the bank, and the bank issued the key to the card.
There are three card authentication schemes:
- SDA – static data authentication;
- DDA – dynamic data authentication; and
- CDA – combined dynamic data authentication.
The first method uses only one static field stored on the card: AIP (Application Interchange Profile) EMV field. It’s signed with a private key and verified by the terminal. But the EMV consortium quickly realized that for offline terminals popular at that time (i.e. terminals that don’t go online to verify the cryptogram), this was obviously not enough: anyone could clone the public key and the signed static string. Offline terminals could not check the online cryptogram immediately. Therefore they accepted transactions from the forged cards.
The next implemented scheme (DDA) relies on dynamic data received from the terminal. The terminal generates a UN (Unique Number) field signed by the card’s private key. The entropy of this field is 232, which is sufficient to protect against the first attack.
However, in 2009, researchers from the University of Cambridge published a paper describing the so-called PIN OK attack (PDF). A special device located between the card and the terminal performs a “Man-in-The-Middle” attack and substitutes one of the fields submitted by the card. This substitution cannot be detected using the SDA or DDA schemes. But the EMV consortium has developed a new protection mechanism, CDA, even before this publication. To protect against this attack, the terminal would check the integrity of most of the fields transmitted by the card that are involved in the phase called “risk management”.
Offline authentication was created primarily to protect offline payments at terminals that aren’t connected to the Internet all the time. That is why, on modern terminals connected to the Internet, a transaction won’t be rejected in 99% of cases even if the result of the DDA or CDA operation is not successful: the issuing bank authorizes it using a cryptogram (see below). However, some payment systems suggest that “If the offline CAM fails consistently for the same card when used at different merchant locations, then this may indicate fraudulent activity”.
There are two main cardholder verification techniques: PIN code and signature. In fact, their number is a little larger: the PIN code can be checked offline (directly on the card) and online. It can be encrypted (using a 3DES symmetric key) or transmitted in plain text.
There is also the NoCVM verification technique (i.e. when no verification is required). A good example of such transactions is those that don’t exceed a certain limit and don’t require you to enter the PIN code. Sometimes, they are called “Tap and Go”.
Another method is called, depending on the payment system, CDCVM or On-Device CVM; it enables verification on the cardholder’s mobile phone. As you are likely aware, it’s used in Google Pay, Apple Pay, Samsung Pay and so on.
Smartcards use payment cryptograms to authorize transactions. The card submits a list of fields to the terminal (their set depends on the cryptogram version and card settings). Usually, this includes the transaction amount, currency, date, and other terminal settings that are important for the risk management stage. Then the card adds to the above fields its internal fields: application transaction counter, the version of the cryptogram, etc.
The constructed string is encrypted using the 3DES secret key stored on the card in the digital signature mode and transmitted to the bank along with all signed information. The issuing bank uses a Hardware Security Module (HSM) that contains a copy of the card’s symmetric 3DES key.
HSM also creates a digital signature based on the data received from the payment terminal. If the calculated cryptogram is the same, the transaction is considered genuine. That means that no one has changed the transaction data from the card to the issuing bank during their transmission. At the same stage, if the online PIN verification is used, the card’s PIN code will be decrypted and verified.
Note that these three functions work efficiently only together. To ensure that verification works correctly, it must be controlled by authentication. If there is no authorization, the entire transaction becomes high-risk, and so on.
Contactless payments became popular in the mid-2010s. Banks and payment systems advertise them as a fast and convenient payment method. This is understandable: the more people pay with cards, the more banks and payment systems earn on commissions! As technology advances, security should be advanced as well, but this isn’t always the case. And contactless payments are a glaring example of this.
At the time when contactless payments were invented, chip-based cards were not very common in the US yet. Therefore, Visa and MasterCard made provisions for an intermediate step: new contactless cards could make payments at outdated terminals that don’t support modern cryptography. These were called Legacy modes (i.e. modes whose security degrees are significantly lower in comparison with EMV payments and modern forms of contactless payments).
In terms of protection, Legacy modes are more like magnetic stripe operations (even though they use near-field communication (NFC) technology). These modes were supposed to be used only in a few countries and to be completely abandoned after some time; however, you can encounter them almost everywhere nowadays, including Europe, where even the magnetic stripe nowadays is prohibited.
Another problem is how payment systems implement contactless payments. Instead of inventing something new, Visa and MasterCard decided to use EMV again, but each company did this in its own way (so, de jure they ceased to be parts of the EMV standard).
What follows from this:
- First, the protection mechanisms and their problems described back in the early 2000s still persist. In most cards, even the cryptographic keys used for EMV and NFC cryptograms are the same; and
- Second, the EMV consortium can no longer control how the payment process is implemented.
Visa was unhappy with the “too long” time required to complete a payment. Everything is fine if a chip is used because the card is inserted into the terminal. However, Visa decided that it’s not convenient for customers to hold the card near the terminal, waiting for all the EMV steps to go through. The stage causing the main delay was the offline card authentication.
Concurrently, MasterCard made a completely opposite decision: the company recognized that offline authentication is essential and made the CDA scheme mandatory for the cards supporting this method. According to the EMV specification, if the CDA interaction isn’t successful, the terminal can send a cryptogram for online authentication. But for contactless MasterCard payments, a failed CDA authentication always results in a payment cancellation. The difference in transaction duration is negligible, but it remains the deciding factor for Visa.
Now you know how electronic and contactless payments work. In the following articles, we will discuss vulnerabilities present in these schemes and analyze the most high-profile fraud cases.