Give me your credit card, the NFC way |
More than one month ago I gave a presentation about the NFC credit cards privacy at No cON Name (NcN), a well known Spanish security conference. It's not a new subject and, also, some researchers presented talks about it in other conferences during this year, but, until that moment, there were no proofs of concept with Spanish credit cards (at least public ones). You can take a look at the presentation here (Spanish).
As I have mentioned in some posts about this subject, NFC payments are a normal part of life in some Asiatic countries, like Japan. However, this technology has arrived this year to Spain and other European countries, supported by banks, mostly. The result is that a person could have an NFC credit card in his wallet without even knowing it. It wouldn't be a problem if data were correctly protected, but we can't assume anything in the security world and this is another proof of that.
My research was based on the source code published by Renaud Lifchitz at the past Hackit Ergo Sum, showing how easy was extracting private data from some French credit cards. This code was implemented to work with ISO/IEC 14443A cards and some specific issuers, so I had to modify some things to make it more global. I added support for ISO/IEC 14443B cards and some more issuers (VISA, VISA Electron, Mastercard). You can download the modified code from this link. I'm not a C programmer, not clean/good code, but it works ;)
I used an NFC reader with a PN532 chip (I commented some time ago how to setup your NFC lab) because it seems that it supports some important NFC software projects, like libnfc. Two NFC commands are enough to establish a communication with an NFC device (complete PN532 specification here):
-
InListPassiveTarget: Lists closer devices and initializes the communication.
-
InDataExchange: Exchanges data between the reader and the device.
Simplifying a bit, we can say that a contactless credit card (NFC) is just a smartcard with an NFC interface. So once the NFC communication is established we can send EMV commands to obtain the credit card data. In this case, I used the following commands:
-
Select: Opens a logic channel between the reader and the selected MF/EF. This is useful to select the application id (card issuer) from where we will read the information:
0xA0 0x00 0x000x000x03 0x10 0x10 (VISA)
0xA0 0x00 0x000x000x03 0x20 0x10 (VISA Electron)
0xA0 0x00 0x000x000x04 0x10 0x10 (Mastercard) -
Read record: Reads the selected record.
Using these commands and taking a look at the specifications (EMV Specification Book 3 and ISO7816-4) we can extract the credit card data, but, is it really worth it? To answer this question you can watch the following video:
The video shows only one card, but at NcN I used three different credit cards from three different Spanish banks (thanks Marc!). Also, a nice girl offered herself as a volunteer to test his credit card and it worked too (no logs recorded, I swear!). In summary, it's possible to extract at least the following information:
-
Cardholder name
-
Permanent Account Number (PAN)
-
Expiry date
-
Operation modes
-
Card certificate public key
-
Issuer certificate public key
-
...
Now the question is if it's possible to commit fraud with this data. These are some ideas about it:
-
Buying by telephone: Some orders can be performed by telephone and to pay with credit card just the information mentioned above is asked, no additional details like CVV/CV2/...
-
Online shoping: In an ideal case, when you buy something on Internet with a credit card, the CVV/CV2/... is asked to securely identify the cardholder. This number is not stored within the chip or the magnetic stripe, so it would be secure. However, there are a lot of web sites where you can purchase anything without entering that code. Just take a look, even some famous online stores do it.
-
Card cloning: Thanks to the EMV commands we can access to the magnetic stripes (Track1 and Track2). With this data would be possible to create a new card and pay in places where an identification is not needed like parkings, vending machines, road tolls, 24h petrol stations, etc. I have not tested it yet, but you can watch the Kristin Paget's video making a demostration at Shmoocon this year.
-
Underground market: Underground forums are good to trade with banking credentials and stolen credit card data, so someone could collect this data and sell it to the best buyer.
So think about this scenario: someone brings an NFC reader or a mobile phone with an NFC chip to a crowded place and starts to collect credit cards data. It's so crowded that it's not suspicious if someone is really close to another person. How about a big city's metro at rush hour?
I think this is a very good scenario to obtain a lot of credit cards information. So, how can we protect us from this threat?
-
Firs of all, try to avoid using contactless credit cards.
-
If there is no option, it's possible to disable or extract the NFC chip. It seems that 3 seconds in a microwave is enough time to disable the chip, but, beware, because if you don't control well that timing you can set the chip on fire! (don't try this at home).
-
The last option would be using a Faraday's cage to isolate the card and avoid that any device were able to communicate with it. There are some wallets in the market with this functionality. We tested one of them during the presentation thanks to another volunteer and it worked well (at least with the reader used).
As I have mentioned before, it's not a new vulnerability, but it's a big privacy fail known some time ago. This year has become more important due to the banks' initiatives to support this payment type in Europe, and, because of that, it has been a current subject in this year's security conferences. This is something to take into account and be checked before distributing new NFC cards to customers (even more important if customers don't know what a contactless card is), because it's a way to facilitate the fraud and a privacy loss. Also, these cards are probably not in compliance with PCI DSS, because his Requirement 4 says that it's a must to “Encrypt transmission of cardholder data across open, public networks”. In this section “Wireless technologies” are mentioned explicitly as an example of “public networks”.
So, please, take a look at your credit cards and who approaches them, because NFC credit cards are far from privacy, at least nowadays.
Some of my friends have also
Some of my friends have also NFC credit cards which are more better considering privacy...They've suggested me also to apply for it. I'm also thinking to apply for it sooner...
Hi! Do you have more
Hi!
Do you have more information about these cards?
Thanks!
Hi, I try your code to read
Hi, I try your code to read some smartcard - credit card but by function InListPassiveTarget() I´m not able read any UID etc. Mifare card readed OK. I can see UID but any smartcard nothing.I have PN532 module V3. Have You any idea where is problem? I want read credit card number by APDU but nothing readed. I try RC522 too and there I can read UID, but it is all, no APDU . Thanx
Hi, how You do it. I try
Hi,
how You do it. I try InListPassiveTarget() and the card 14443-4A dont respond to pn532. I try Your code and and on this function was return false. You set any spec. parameters to PN532?
Hi! Is the NFC device
Hi!
Is the NFC device detected? If it is, then maybe the card is not really a 14443A or 14443B card, are you sure about it? Could you send me an email with the script output? It is difficult to help you just with this information...
Thanks!
Nice Article. we try your
Nice Article. we try your code to read some smartcard - credit card but by function InListPassiveTarget() I´m not able read any UID etc. Mifare card readed OK. I can see UID but any smartcard nothing.I have PN532 module V3. Have You any idea where is problem? I want read credit card number by APDU but nothing readed. I try RC522 too and there I can read UID, but it is all, no APDU . Thanx
that was great tutorial
that was great tutorial