I have been writing a few posts about NFC payments, and I am lacking a basic background post showing where I come from, so here it is: my own little NFC Payments 101. It may not be fully objective, not even fully correct (I haven’t directly worked on this topic for a while). You are welcome to help through comments and criticisms, and I will do my best to correct/improve things as needed.
First, let’s state what this is not about:
- Mobile payment. NFC is one form of mobile payment, but not the only one. In particular, I will not address the kinds of payments that are solely mobile-based, rely on SMS, Internet, or whatever. Here, I will only be talking about contactless payment, using a secure element.
- Contactless cards. Contactless cards are fun, but here, I am using NFC in its restrictive meaning, which involves a mobile device.
Next, let’s move into a few definitions (in alphabetical order):
- Bank. The financial service provider who issues a payment application. Could be a bank like Citi or a credit card specialist like American Express.
- Device vendor. Whoever provides the device through which the payment will be performed.
- Embedded Secure Element (eSE). A Secure Element that is soldered into the mobile device during production. See Secure Element.
- Merchant. Since we are considering in-person, whoever accepts to be paid through a NFC payment, and has access to the proper infrastructure to do so.
- MicroSD. A specific kind of MicroSD, which includes a Secure Element and a NFC antenna. It may be used as a NFC adapter on mobile devices that don’t natively support NFC. See Secure Element.
- Mobile device. A mobile device that includes a NFC interface, a Secure Element, as well as a Mobile Wallet, on which an end-user can perform mobile payments.
- Mobile Network Operator (MNO). A company providing network access to the mobile device. If GSM is used, the mobile device contains a SIM, which is owned by the MNO.
- Mobile Wallet. A mobile application, running on the mobile device, that allows the end user to select the card to use for a particular transaction, to register a new card, or perform similar management operations.
- Payment Application. An application running on the Secure Element that can perform a payment, usually following the EMV specification.
- Payment Terminal. A device that is used by the merchant to process NFC payments (and possibly other kinds of payments).
- Secure Element (SE). Some secure MCU, including a Java Card platform, supporting the required GlobalPlatform specifications, with the proper security certifications (Common Criteria, EMVCo, for instance). The Secure Element is used to run the Payment Applications, and possibly other applications.
- SIM. A Secure Element that includes the credentials for authenticating a device into the GSM network, provided by the MNO. See Secure Element.
- Trusted Services Manager (TSM). An entity in charge of managing the assets on a Secure Element on behalf of the owner of these assets (which may be the owner of the Secure Element itself, or simply the owner of an application on the Secure Element).
Stakes and stakeholders
In NFC payments, the stakes are rather high, since the idea is to move currency from one account to another. A single device (and in particular its Secure Element) will hold data pertaining to several payment cards in a single location. Some of this data (considered less sensitive) will be stored on the mobile device (card name, associated picture, partial number, etc. The more sensitive data, and in particular the end user PIN and associated counters, and the cryptographic keys used to authenticate the card, are stored and processed solely on the SE.
Another stakeholder is the owner of the SE. This owner depends on the kind of SE. A SIM is usually the property of a MNO, and an eSE would be expected to be the property of the device vendor (possibly transferred to another actor, like Google), and a NFC MicroSD is the property of whoever provided it to the end-user (possibly a bank, possibly another actor). In all cases, this SE owner is the one who holds the keys to the SE, and has the power to allow banks and other application providers to put their content/credentials on their SE.
Something interesting with NFC payment is that this is a significant departure from traditional cards. When deploying contactless cards, a bank selects card suppliers, verifies their credentials, tests the cards thoroughly, and then deploys the cards. The bank controls the entire process, even if most of it is outsourced to various suppliers.
With NFC, things are very different. The “card” (SIM, eSE, MicroSD) is selected by somebody else. Even worse, there may be several cards for different devices or different MNOs. Banks need to trust all these people to have done the right thing, and all that trust is not easy for them. I am not sure what the model is for applications, but it may also be similar. Is the wallet owner going to put a single copy of the Visa application, associated to one data set for each Visa bank, or is the wallet owner going to install (almost) the same code several times, to better isolate the assets of different banks? If banks need to share the same code, that will require a lot of trust.
How do you get that trust? Through a security certification. And because there are many things to evaluate and many banks to convince, the evaluation requirements need to be quite high. This leads to potential cost issues for vendors, which can become especially high if every mobile device/SE needs to be certified for every NFC payment model. Factoring these costs is going to be important; standard certification frameworks, such as Common Criteria, are the current solution, but these frameworks may lack the flexibility required for such deployments. We’ll see.
Things get really funny if we keep adding stakeholders in the picture. Consider for instance that other people may want to add applications in the SE. For instance, your company may want to put a VPN there, or I could try to sell you a very good password storage app. These applications are not sensitive (from a banker’s point of view), but bankers want to ensure that they won’t interfere with their own applications (after all, I have designed logical attacks in the past). Java Card provides some solutions, with the firewall that isolates applications, and the bytecode verifier that checks that the application isn’t malware. But most likely, this is not sufficient, and an extra step will be required to convince everybody that the application is innocuous to other applications.
Before getting into an actual NFC payment, the credentials need to get to your mobile device. In some cases, the payment application may also need to get there. So, how does that work?
We can assume here that the wallet owner has control over the SE. This means that this entity is able to load new applications, instantiate them, delete them, and more. It may also authorize other entities to perform similar operations. For instance, on a SIM, the MNO will always be allowed to manage its SIM applications and whatever other applications are required for its telco operations.
Similarly, banks will be allowed to manage their own applications, or at least their own credentials. In GlobalPlatform jargon, this means that banks will have a Security Domain that represents them on the card, with the appropriate privileges. Each Security Domain has its own set of cryptographic keys, which allows it to perform secure operations independently of the other actors.
In a typical NFC deployment, the operation of Security Domains is delegated to specialized technical operators, Trusted Service Managers. There usually will be at least two types of TSMs:
- The bank TSM(s). Each bank has a TSM, in charge of managing its assets on the SE.
- The wallet owner’s TSM. This TSM manages the wallet-related applications (if any), and it is also in charge of creating Security Domains for the banks’ TSMs.
All exchanges between TSMs and between the TSMs and the SEs are standardized by GlobalPlatform, in various documents. This allows the ecosystem to work. Now, let’s imagine that a new bank wants to install a card in a user’s mobile wallet. Here are the operations that need to be performed:
- Loading the payment application. Actually, this is optional, as several banks may use the same application, for instance a standard Visa or MasterCard application. When required, this is done by transmitting a CAP file (binary format for Java Card) to the SE.
- Instantiating the payment application. For a given bank, a new instance needs to be created, in order to store all the specific information. This is a simple operation, which does not involve any sensitive information.
- Personalizing the payment application instance. Once the instance is created, this step consists in populating it with the proper data, including highly sensitive data such as cryptographic keys. This operation is always performed by establishing a secure communication channel between the Secure Element and some kind of secure factory, in which the cryptographic keys are stored/generated. The fact that the SE is actually outside of the factory when it is personalized doesn’t change this.
- Sending the non-sensitive information to the wallet. Once the payment application instance is ready on the card, more information needs to be provided to the wallet in order to be able to use it. This typically includes a logo, a name, and a reference to the payment application instance’s identifier on the card (AID). This information is stored in the mobile wallet, on the device.
This looks rather simple, but the devil is in the details. Since the information that circulates during this installation is highly sensitive, the security level of the secure channel is very important. Also, several actors need to collaborate in order to make all this happen, which makes it possible, at least in theory, to design all kinds of attacks, including social attacks on employees of the various TSMs involved. As of today, the ecosystem remains a bit small to attempt such things, but this may change in the future.
What is a NFC transaction?
There is no such thing as a standard NFC transaction, as there are many ways to perform a NFC payment. First, let’s consider a few typical requirements:
- The user must present a PIN for payments over 15 euros.
- The user must present a PIN before performing a payment.
- It must be possible to perform a small payment with the phone off.
- The user must see the amount of the transaction on the phone after the transaction.
- The user must be notified when a transaction is successful.
If all of this looks obvious, then think again. All these requirements are contradictory or close to impossible to achieve in most payment schemes. I haven’t been involved in this topic for a while, so my scenarios may be incomplete. However, the objective is here to show a few issues related in particular to usability vs. security. So, let’s look at a few examples, and analyze where things can go wrong.
Small transaction, no PIN required
This sounds simple. Here is what somebody may expect:
- Bob takes the phone out of his pocket
- Bob turns the screen on
- Bob taps the phone on the payment terminal
- The phone beeps/vibrates and displays the amount to confirm the transaction
Steps 1 to 2 are correct. Turning the phone’s screen on also activates the NFC interface (which is deactivated to save energy), including card emulation mode. At this point, a payment is possible.
Step 3 may not work with all wallets. If I understand what Google is saying about their wallet, you would then need to launch the wallet application and enter your wallet PIN to do so.
Step 4 is more difficult, at least in the U.S. . Card transactions in the U.S. actually emulate a magstripe, optionally replacing the static authentication by a dynamic one. In this transaction, the payment terminal simply reads data from the card, and does not communicate the amount to the card. In fact, the card doesn’t even know if the transaction was successful. The interface remains the same with a NFC payment: the payment application doesn’t know the amount, and it doesn’t know what happened after it sent its information. So, even if everything went fine from the phone’s point of view, the transaction may still be rejected by the payment terminal. Some user friendliness to work on.
Large transaction, PIN required (pre-authorization)
Here is another simple one:
- Lisa takes the phone out of her pocket
- Lisa turns on the phone and selects the mobile wallet
- Lisa selects the card to use
- Lisa enters this card’s PIN
- Lisa taps the phone on the payment terminal
- Lisa gets feedback through the payment terminal
This sequence is correct, but other options are possible. Since a PIN needs to be entered before to perform a transaction, step 2 is mandatory, as Lisa needs to turn on the phone explicitly, and select the mobile wallet (a shortcut key may be used, though). Note that this selection may require the presentation of a mobile wallet PIN, just to unlock the wallet.
Step 3, on the other hand, is optional. It should be possible to define a default card, to make a typical transaction shorter.
Step 4 is here critical, as a PIN is entered. The nice thing, from a usability point of view, is that the user can enter the PIN wile waiting at the merchant’s counter, making the actual transaction a simple tap. The bad thing, from a security point of view, is how it differs from a typical PIN entry:
- In standard transactions, PINs are entered on a PIN Entry Device (PED). The payment industry has defined specific guidelines for the security of these devices, PCI-PED. These guidelines are not easy, and mobile phones just don’t make it. It is hard to protect the PIN on a phone, as it is entered, as it is (temporarily) stored, and even after it is entered, with our screen smudges. TEE vendors will claim to be better, but they can hardly claim to be at PCI-PED level.
- The PIN is here entered before the transaction. In a “good” implementation, it will be presented to the card immediately, and erased from the mobile’s memory. However, the user most likely wants to approve a single $5 transaction at Starbucks in the next 2 minutes, and not a $2,000 transaction the next day. However, the SE doesn’t make the difference, because the SE doesn’t know about real-time. It is therefore the mobile device’s responsibility to clear the PIN status 1 or 2 minutes after it has been presented. And even then, during these few minutes, Lisa’s device is a prime candidate for an attacker, since any payment request has been preapproved.
Large transaction, PIN required (double tap)
This is a similar model, in which the PIN entry is managed differently:
- Paul takes the phone out of his pocket
- Paul turns the screen on
- Paul taps the phone on the payment terminal
- The phone beeps and asks for a PIN, because the amount is above 15 euros
- Paul enters his PIN
- Paul taps the phone again
- The phone displays a recap of the transaction
You may have guessed, at least from the subtle reference to euros, that this scenario is not very American. We are here using the version of the EMV protocol in which the card is involved in the risk management decisions, and therefore knows about the amount to be paid. The decision to ask for a PIN will most likely be taken by the terminal during step 3, but some information is still available when interacting with the user.
Also, note that, although I have here simplified step 2, there may still be a full wallet opening and card selection sequence before the actual payment; I have simply assumed here that there was a single or default card, which is common in Europe.
The interesting thing here is that there is no major difference in the PIN handling, and that both security remarks made above apply here. Because the second tap is an entirely new transaction, there is no real difference. The difference is more subtle and is related to liability issues, as the user presents the PIN while knowing the amount. That is discussed below.
Small transaction with dead battery
This last one is the “killer use case”. Cards don’t have batteries, so nobody worries about cards being out of juice. For phones, the problem is different, and issuers are afraid that users relying solely on their phones for payment may be stuck in a bad situation if they run out of battery. It would be nice for them to be able to at least make a small payment, for instance to buy the train ticket to go back home.
Actually, this can be addressed. First, contactless readers provide power to cards, so they can provide power to the SEs embedded in phones. Then, if this is not enough, it is quite likely that although the battery is not charged enough to power the entire phone, it has enough power for the NFC controller. So, basically, this can work (the MicroSD case is a bit more difficult, since their antenna is too small to get power from the reader, so they need to be fully powered from the mobile device). So, here is the (very simple) transaction:
- Ada takes the phone out of her pocket
- Ada taps the phone on the reader
- Ada gets feedback on the transaction from the payment terminal
So, what has happened? The mobile wallet has been transformed into a single contactless card. There is no way to select a card, there is no way to present a PIN, there is no way to prevent a transaction from being made. Yes, a NFC phone with a dead battery becomes a simple piece of plastic with a SE.
In principle, this is OK. The user simply needs to select the default card to be used in such a situation, and to select the option that allows transactions to be performed with the phone off. However, in the case of a dying battery, this choice needs to be done while the phone still works.
In terms of security, this is not bad. Claiming that it is not sufficient is equivalent to claiming that the security of all contactless cards is not sufficient.
PIN, PIN, or PIN?
We have seen that the use of PINs is an interesting part of NFC payments. However, this same name covers a number of different mechanisms, or at least different uses. Here, we will consider three distinct uses:
- Unlock your wallet. This particular PIN is a code that is used when first accessing the wallet, in order to “unlock” it. This PIN code is managed by the mobile wallet application (on the mobile device), although the PIN itself can be managed on the SE. More importantly, this PIN is provided before even choosing the payment card, which reduces its use as a “traditional” PIN.
- Authenticate the user. This use case happens when the end user can present the PIN before to actually perform a transaction, to unlock a particular card. The PIN is presented to the card, and it will authorize the next transaction for a limited time. Of course, the timing is enforced by the mobile device, since cards don’t have a real-time clock. Also, since this PIN is presented before the actual transaction, it cannot be considered as authenticating the transaction.
- Authorize the transaction. This use case is the traditional use of PIN, when it is entered on a PIN entry device, part of the payment terminal. In that case, the payment terminal first displays the amount to be paid, and then asks for the PIN. In that case, the PIN is more powerful, since it shows that the user has authenticated himself after looking at the transaction’s amount. In fact the PIN entry device security requirements are careful about protecting the PIN, and also about ensuring that the correct amount is displayed.
Of course, the difference between these three types of PIN are subtle. The user, who enters a sequence of digits, may not realize the differences. However, in terms of liability, things are different, as we are moving into more and more responsibility for the user. For instance, the first kind of PIN (opening the wallet) does not even imply that the user wants to make a payment; the user may just want to adjust a setting on a card, or register a new card. On the opposite, after entering the last kind of PIN (on a payment terminal), the bank knows that the amount has been presented to the user before he entered the PIN, so it is more difficult for the user to make a “I didn’t know” claim.
A few threats
First, let’s not forget our starting point: a contactless card. If you have a contactless payment card, a few bad things may happen. Your card may be stolen and used by somebody else. If there is no PIN to present, this will just work. Or somebody can get close to you and make a transaction directly from your pocket. They may not even need to be that close, provided that they have a powerful enough field (they will just fry your brain a little as a bonus, but they may look suspicious with their big antenna).
If things go well, dynamic card authentication should be used, which means that each transaction uses a random challenge that the card need to encrypt to prove that it has the appropriate encryption key. In that case, the good news is that you don’t have to fear about someone copying your card.
Now, if you move the payment application to a mobile device, the same threats remain: somebody may steal your mobile and use it to pay for something, or some guy may just come by and perform a transaction from your pocket.
Well, not necessarily. On an Android phone, by default, the NFC interface is only activated when the screen is on. This means that you need to turn your screen on to perform a transaction, and it also means that your phone is safe in your pocket (actually, safer than your contactless card).
And if you are using a Google Wallet, it comes with a lock. You need to know a PIN to open the wallet. Even if this mechanism can be attacked, it is still better than your traditional wallet, which usually doesn’t include a lock.
So, what’s new? Or more importantly, what’s worse? Well, the main thing is that your mobile device (and your SE) happen to be connected to Internet. This is not good, since this is a new origin for an attack. For instance, the famous relay attack can work very well there. This is not easy, of course, since it requires some mobile malware that has the privileges required to access the payment application. Still, it is possible on your phone, and not on your standard contactless card.
Naturally, everything that works on a contactless smart card also works on a Secure Element. So, expect power analysis and fault induction attacks to be around. However, unless something new happens, there is no big fear to have. And even if it does, the payment application on your mobile device is more likely to be upgraded as required than the one on your (not connected) contactless card.
Overall, I don’t see much differences so far in terms of threats. Of course, such statements are systematically proven wrong by attackers, so don’t forget to check regularly.
You may be more confused after reading it than before; if so, it may mean that you have been exposed to some of the complexity behind NFC payments.
All of this complexity is manageable, but not easily. Because some basic hypotheses from the previous models are broken, many stakeholders have problems adapting to the new situation. Some of these problems can be addressed by reasoning and adaptation, but it is likely that a few problems will require innovative solutions.
My personal opinion is that security certification is one of these issues that will require fresh thinking and new solutions. However, not everybody agrees with me, and the debate has already been going on for a number of years. So, there is more fun to come in this area.