Comments on some alleged attacks against Chip-and-PIN cards

[My personal opinion]

[03 Oct 2021] Apparently, this kind of claims will never end. Here is another one 

5. Researchers find Apple Pay, Visa contactless hack

Well, it is a variant of #3 below by replacing a card with an iPhone. There is no need to analyse further on its effectiveness or exploitability.

[10 Aug 2019] Revision notes: When a new alleged attack against an EMV card, I will record it here, rather than write a new piece. 

4. On 29 July 2019, a claim was made "Visa card vulnerability can bypass contactless limits" with some seemingly convincing details such as "First, the device tells the card that verification is not necessary, even though the amount is greater than £30. The device then tells the terminal that verification has already been made by another means. This attack is possible because Visa does not require issuers and acquirers to have checks in place that block payments without presenting the minimum verification."

Well, the above is not specified in any EMV card. A very simple rule is: for any offline transaction, it is the SE (Secure Element), i.e. the card) to make the final decision, not the terminal, neither the CD (Consumer Device, i.e the phone).

Because no more details have been revealed on the alleged attack and what the disclosed is nothing to do with an EMV card, Visa wasn't impressed by this claim at all with no more action. 

My comment is "Visa is correct."


Note: for online transactions, none of alleged attacks in this blog is relevant.

[Below is the first write-up, if you would like to know what has happened. The Cambridge University attack claim is highly recommended to read. :)]

Every a while, we would read headlines on the Internet of frightening stories on Chip-and-PIN card attacks, such as the following three:

    1. Chip and PIN is broken, 11 Feb 2010 (https://www.lightbluetouchpaper.org/2010/02/11/chip-and-pin-is-broken/)

    2. Cloning chip-and-PIN cards: Brazilian job, 09 Mar 2018 (https://www.kaspersky.com/blog/chip-n-pin-cloning/21502/)

and

    3. Secret Service Warns of Chip Card Scheme,  05 Apr 2018 (https://krebsonsecurity.com/2018/04/secret-service-warns-of-chip-card-scheme/)

By reading the headings alone, one would wonder whether the Chip-and-PIN scheme (a.k.a. EMV) has some security concerns because these headlines, more or less, implicitly lead readers to think to the direction that Chip-and-PIN might have security problems.

However, as a matter of fact, none of the above headlines is true.

The fallacy of #1 is well understood - it assumed that the card accepting terminal (i.e. the POS terminal in the film) asked a PIN but not to check if a PIN verification had been performed (a field of CVR that the terminal should read and check). It goes like that: the terminal asks for a PIN, after the PIN is entered, the terminal is not bothered  to check if the PIN verification has been performed by the card. There are detailed explanations in the comments followed in the link of #1.

The #2 recycles the Yes-card attack known about 20 years ago - a card always says "PIN OK" to any PIN entered (The sentence "You read that right: The cybercriminals’ app can say a PIN is valid, no matter what PIN was entered."). This is the whole point why DDA (Dynamic Data Authenticate) is designed in a Chip-and_PIN card to ensure that a card valid when used offline. The attack on #2 has nothing to do with the Chip-and-PIN scheme because a Yes-card won't work without a successful DDA.

The #3 is, in essence, about using a valid stolen Chip-and-PIN card. If  one valid card is stolen and the card loss has not been reported yet, a crook can spend the card with a limited amount that no PIN is required, especially in contactless case. This risk is well recognised and this is why a card is limited on contactless or offline spending. The #3 actually suggests that there is a way to steal a large amount of genuine cards, and the period of reporting loss could be very long - a new corporate card may not be used for a long time after activation.  This could happen to the scenarios as described in #3 but, again, it has nothing to do with Chip-and-PIN. The PIN even not involved. In addition, the use of a chemical lab to fabric fake cards is not impressive either, there are more cost effective ways to fool a user to activate a corporate card.

These articles worth having a look to know the crook's ideas, but we shouldn't be influenced by the simple claims on their headlines.

Card fraud - a case description

I read the story from the Internet. I’m not able to verify its authenticity but it reads genuine. I share this story here and I hope you can provide your insights. I’m puzzled with the Bank_C Debit card.

An American traveller had a holiday in Europe and her purse was stolen. I record the card related events here. I have my personal remarks with [BL: …]

02 Oct 2015

Italy, her purse was stolen, including the following:

1. AMEX Card
2. Bank_A Credit Card
3. Bank_A Debit Card
4. Bank_B Blank Cheques

She reported to AMEX and Bank_A for the card loss immediately.

[BL: I assume in 2015, US was using plastic cards only. No EMV cards yet. Update: I went US in 2016 and I found they "dip" a chip card and sign the receipts. A chip card did not verify cardholder's PIN offline.] 

07 Oct 2015

She got back to US and checked all her cards.

For AMEX, everything was fine. No fraudulent transaction. [BL: I think it is because AMEX is always online. This is why, in Europe, many small vendors do not take AMEX cards.]

Then she checked Bank_A. Ouch, two days of her reporting the stealing (04 Oct 2015), there had been 16 transactions on the Bank_A Debit Card, eight for small amount purchasing and the other eight for Euro-to-US dollar exchanging.

She called Bank_A and inquired why the stolen card after reporting to the bank was still in use. Bank_A had no idea and only confirmed that cardholder was not responsible for the fraudulent use.

[BL: I guess the small amount transactions were offline, so Bank_A was not able to know it. The vendor of the card being used might not have their black list updated yet.]

09 Oct 2015

After three days, she found her invalid Bank_A Debit Card was still in transaction. She drove to Bank_A in person to check. As usual, Bank_A still had no idea what was going on. She was advised to close the account and open another one.

11 Oct 2015

After another two days, she found that the Bank_A Debit Card was still in use. In addition, the stolen Bank_A Credit Card was being fraudulently used as well – three small amount transactions. She called Bank_A again, and, of course, Bank_A had no idea.

14 Oct 2015

The Bank_A cards fraudulent transactions eventually stopped. But, the story went on.

13 Nov 2016

She found her Bank_C [BL: another bank] Debit Card had been fraudulently used since 22 Oct 2015 - three to four small amount transactions a day. But, as she claimed, Bank_C Debit Card had never left US!

She had three screen-shots online. I upload them here for reference.

How credit card payment works

Working for the payment industry, I am often asked how credit card payment works. Although a credit card is involved with many aspects, such as card making, card security and purchase processing, understanding the five key players in the business would provide a clear idea of the credit card business.

1. The consumer: a credit card holder who’s responsible for any payments of his credit card.

2. The merchant: a shop or service provider who accepts the customer’s credit card payment. For every credit card transaction they accept, they must pay a fee called the “merchant discount”.

3. The issuer: a bank that issues credit cards to consumers.

4. The acquirer: a bank that serves the merchant. This includes crediting the merchant's account for the value charged to a credit card less all the fees.

5. The payment network: a credit card service provider that processes card payments and links the acquirer and the issuer involving this payment. Visa and MasterCard are the largest payment networks in the world. Other worldwide payment networks are American Express, Discover and JCB.

The issuer, acquirer, and payment network support the credit card payment at the background, unseen by consumers.

This “five-player” setup allows the acquirer and the issuer only to deal with the payment network instead of having direct contact with each other during a transaction of credit card payment. In this way, a card issued by a bank in UK can be used at a shop in US without requiring the banks (the acquirer and the issuer) to have a direct contact. The consumer deals with the merchant, the merchant with the acquirer, and the acquirer with the payment network. At this point, the merchant gets paid the price less the “merchant discount” and the consumer served. The payment network then continues the process to contact the issuer who will send the credit card bill to the consumer.

The “merchant discount” is shared between the acquirer, the issuer and the network. Typically in US, the average "merchant discount" is about 2.0%. Of this, 1.7% goes to the issuer (known as the “interchange fee”), 0.15 ~ 0.17% to the payment network (known as the “processing fee”), and the rest to the acquirer. It can be 2.5% or 3% in some European countries. In addition to the “merchant discount”, depending on the payment scheme, some other fees may apply, such as a fixed service charge. This explains why some shops are reluctant to accept credit card payments.

Many “Prime” or “Superprime” card issuers use the majority of their interchange revenue to fund their loyalty programs, such as “Amazon points”, “Nectar points” and “cash back”. It is usually worth 0.5% and hence the issuer’s profit from card purchasing is relatively small.

However, they recover the loss by charging high interest rates of card lending and other fees, such as the late payment fee and call charges. So, to take advantage of credit cards and save money, it’s better to pay the credit card bill in full on time.

RSA and me – 30 years after my first implementation

My first implementation of RSA was in 1988, 30 years ago. Time flies! I write a small essay here for the record.

In early 1985, less than one year after my graduation with a degree of Computer Science, I happened to get involved with a cryptography project to implement a block cipher for a satellite communication system.

At that time, the DES had been published for nearly 10 years but, by the hardware availability in China, it was impossible to write a piece of software, in 8086 assembly, to achieve a performance to encrypt a 32kbps voice channel. A block cipher with a large block size and a large key space was proposed and implemented. The cipher was assessed as a fit-for-purpose cipher for “battle fields”.

I and my very good friend, Tian Chang, implemented the cipher in an Intel 8086 Single Board Computer, SDK-86 as follows:

and built an interface board to connect this “cipher machine” to the communication channel. He did the board design and layout, and I developed the communication software between the SBC and an IBM PC XT.

We didn’t have any proper tools for the code development and had to use the printer interface of the IBM PC XT to communicate with the Intel 8086 SBC. So we could write and debug code on the IBM PC XT and then loaded the code to the Intel 8086 SBC. Worse, we didn’t have any EEPROM writer nor any spare EEPROM at the beginning. The communication software on the SBC had to be keyed in manually through its key pad (the bottom-right of the picture) in hexadecimals.

Later, we bought a piece of EEPROM and “burnt” the communication code in. It was a very primitive bootloader through IBM PC XT’s printer port. We no longer needed to manually type hexadecimals in. Tian Chang and I later published paper, titled 

    A simple communication method between a microcomputer and a single board computer” in “J. of Military Communication Technology, Jan 1, 1987

This paper was actually a by-product of the project, which was to solve the problem in Intel SDK-86 development. Neither design nor assessment was discussed about the block cipher in the paper.

Two challenges were posed to the deployment of the block cipher: the deterioration of channel quality and the key distribution.

One drawback of applying block ciphers to communication systems is error propagation when CBC mode is used. For a block cipher with long block size, a 10^–6 error rate will be amplified to 10^–4. To mitigate this issue, we designed and implemented a BCH error correction code. This experience definitely benefited my later career in mobile networks (US 8560920 B2/NC10090ES).

The challenge on key distribution wasn’t that easy. The key management for conventional cipher based systems was studied but with the hardware availability and manufacture capability in the 1980’s China, it wasn’t reasonable to expect any “cryptographic facility” to protect any master key. Public-key based systems had to be considered.

There was another commercial need - We were approached by the Ministry of Oil Industry, who were seeking a solution for securing their satellite communications. Hardly to believe, in 1980s ,China was an oil export country and their main buyer was Japan. In the price negotiation, they found their Japanese counterpart appeared having known their annual output and domestic consumption. The Japanese had their advantages in the negotiation. It was a very much closed China then and there were not many contacts to the outside world. Some of the officials were suspecting their satellite links were eavesdropped.

The main oil fields were scattered in the Gobi desert. Each oil field reported their daily output via satellite links by plain text. The need of an encryption system was well received but its key distribution was a headache – a courier needed to take nearly a week to get to an oil field by car, driving in desert. It was infeasible to work with a manual key distribution scheme. A full-automatic system, with minimum hardware security, was much needed.

A public key based key distribution system appeared prefect – a board with a public key of the Ministry burnt in EEPROM. There was no need to consider authenticity, as long as the message was encrypted on the satellite links.

There were three well-known public key cryptosystems available that time: The Merkle–Hellman knapsack cryptosystem, the RSA cryptosystem, and the McEliece cryptosystem. McEliece cryptosystem was ruled out because there was not enough memory in the Intel 8086 SBC. We weighed Knapsack scheme and RSA scheme, and decide to implement the Knapsack scheme.

We knew that the basic Knapsack scheme had been broken by Adi Shamir, but there had been many variants with some fixes. Comparing to RSA, a fast implementation of Knapsack scheme could be achieved while the RSA scheme was formidable due to its big-number modular exponentiation.

We made our own fix and coded the Knapsack scheme. The project was completed but the Knapsack scheme died out very soon. All attention turned to RSA implementation.

The experience in implementing Knapsack scheme was invaluable. I not only had a concrete example of public-key cryptosystem, but also I mastered big-number arithmetic.

Around 1987, ISO was considering to standardise RSA and a fast implementation would be needed.  I thought implementing RSA could be a good project for my MSc degree. A full RSA implementation, consisting encryption, generation of strong primes, and a full big-number library, should be good enough.

To make this project more interesting, or to find a potential customer, I went to a remote village, code named Unit 854 in County Pengxian, near Chengdu, the capital of Sichuan, in spring of 1988. From my school in Nanjing, it was a train journey over 40 hours. Upon arriving Chengdu, I took a long-distance bus to Pengxian and then caught a local bus to Unit 854. It was a long journey – tiring but interesting.

Unit 854 was located at the foot of Sichuan North-West plateau, about 800 metres above sea level. However, not far away, there are many beautiful mountains above 4,000 metres.

I arrived there in a day of April 1988 and was stunned by the countryside scenery – endless rape flowers blanketing the vast slopes of hills nearby, bright white clouds winding round the mountainside far away, and light blue smokes ascending slowly from villager’s kitchen chimneys here and there – it must be the lunch time.

Unit 854 was a research institute for secure telecommunication networks. Some of their cryptographic experts were educated in Westfield College, London University. It was very rare in the 1980s China.

I really enjoyed my stay in Unit 854 and implemented a 384-bit (100-digit) RSA with an impressive performance 2.7 seconds per encryption-decryption at a 6MHZ 80286 PC. A full big-number arithmetic library was written in 8086 assembly language. The RSA was implemented with CRT with “strong primes”.

My study in Unit 854 was fruitful. So was my climbing and traveling.

Not too far away from Unit 854, there a mountain called Jiufeng (literally, Nine Peaks) 3,800 metres high. I spent whole day on climbing it from its 800 metre foot to its top. I started in the morning and reached the top in later afternoon. After finishing canned food, I tried to cook some rice and the rice was only half-cooked – the water was boiling at 80 degrees Celsius!

In summer, I visited Jiuzhaigou National Park and Huanglong  National Park Huanglong National Park, and travelled Tibetan area in the Sichuan Northwest plateau, 4,500 metre high. It was a beautiful region, not much population.

By retrospection, if the academic environment were not that closed, I would have used Montgomery arithmetic to do the RSA. I heard this method from a friend, Jun Fang, who just finished his PhD from Paris (Telecom Paris Tech) and was visiting Unit 854. I managed to get a copy of Montgomery’s paper, studied it, and made some notes, but I didn’t have any chance to implement it.

I won a contract to make a C version, length variable RSA. The client was Unit 854 who was using Sun SPARCstations to build a secure network. That time I heard PKCS (Public Key Cryptography Standards) and hoped to get a copy of this standard. I was planning to make my RSA implementation to comply with PKCS.

Although China had started the “Open Door Policy” for several years, my connections to the outside world was still very limited. There was no email then, never mind the Internet in China.

I wrote a letter to Ron Rivest and asked if I could have a copy of PKCS. Surprisingly, I received a letter from Ron telling me that Dr Burton Kaliski would send me a copy soon Not long, a big envelope arrived to my office, sent by Burt.

I was very much moved by their helpfulness and warm-hearts. I had never met them and I had not been sure if they would help. I wondered it would be nice if I could say thank-you to them in person.

The work with Unit 854 completed in early 1994 and then I went to University of Bradford, England as an academic visitor, sponsored the British Council. I didn’t have chance to work on PKCS. Later, I won the ORS award and started my PhD study.

Although my research was in the security of high-speed networks, but almost the same time, I was offered a job by Motorola as a Senior Cryptographer, developing crypto engines for their smartcard products – they were developing an RSA engine with Montgomery arithmetic!

To complete my PhD degree, I needed to publish some papers. One of my papers was accepted by the PKC 1997 and I was very happy to know that both Ron and Burt would attend the conference.

The PKC 1997 was held in Four Seasons Hotel Toronto. With great pleasure, I met both of them and thanked them in person for their help. The chat with Ron was short. I recall he wore jeans and a pair of trainers, easy-going and agreeable. The chat with Burton was a bit longer. We talked about work, life and family. It was a very nice trip.

My smartcard experience was short. After two years of my joining Motorola Smartcard Division, they sold the business to ATMEL. Later the same business was sold to INSIDE SECURE.

I stayed Motorola, joined their NCSG (Network and Communications Systems Group) and continued my work on high-speed networks and cryptography, including ECC, AES, Kasumi, parallel RSA, SNOW and so on.