(In this posting, I use "NFC" as shorthand for the established (pre-Apple Pay) system used by extant credit-cards and banks for short-range (under 10cm) wireless payments, I believe this is ISO/IEC 14443).

NFC-for-payments

(I think that) I understand how NFC-for-payments works: In the case of NFC-ready cards (that have the Wi-Fi-like logo on them), a closed and secure chip contains a copy of your credit card information, an NFC payment terminal interrogates your card (using a principle similar to RFID), and the terminal gets your details and then issues the charge to the merchant's payment-processor and that's it.

So far, so straightforward: NFC is just yet another way of getting your account details out of your physical credit card, just like the magnetic-stripe or the EMV chip. Once the terminal has your card details (card number, expiry, etc) it makes no difference to the merchant how they got those details - they could have been submitted manually by physically keying-in the embossed numbers on the card.

However, I understand that "standard" NFC-for-payments, by default, is an analog of the magstripe, in that it just reads a straight copy of the card details: the NFC chip does not generate any one-time-use card number or even subvert the credit-card system with its own account/digital-wallet system. I also understand that NFC, by default, does not employ any over-the-air encryption or even a challenge-response system, meaning it's hypothetically possible to run a handheld reader by people's purses and coat-pockets to skim low-value amounts[1] from "dumb" NFC cards, or an attacker could hide an NFC sniffer beside an NFC terminal to capture NFC data mid-flight[2]. That's concerning. I wonder how the NFC system was authorized by Visa, Mastercard, AMEX et alii given how insecure it is.

Recently, but long before Apple Pay was announced, Android phones had NFC functionality that allowed users to clone their credit cards' details onto the NFC chip, and then use the NFC-enabled phone as a substitute card at NFC payment terminals. Assuming that the same security issues that affect NFC still apply, then I suppose it's no-wonder that Apple didn't include an NFC feature in the iPhone, at least initially.

Apple Pay

Apple Pay uses the same NFC protocol - which is why you can use Apple Pay with any NFC terminal. Apple wanted to make it more secure, but they couldn't encrypt the OTA signal because that would break compatibility with existing NFC terminals - so they added security by not sending the raw, original credit card details but instead Apple Pay in the iPhone itself generates and sends a one-time, single-use credit-card number, which is then transmitted via NFC. This is so that if the radio transmission were to be intercepted then the attacker would have no use for the details (because if the single-use card number was already charged they couldn't charge it again - and if they got their charge through first then the bona-fide merchant would see their charge declined and they could dispute it immediately).

Because Apple Pay then becomes its own system-atop-another-system (because Apple controls the single-use credit card numbers) this means they need to require customers' banks to agree to join their system on an individual basis (so the bank's systems can accommodate Apple's single-use credit-card numbers) - this explains the slow roll-out of Apple Pay, and it also explains why they can justify asking for a 0.15% cut of every transaction: because they are adding-value with the added security from their single-use system.

But how does Apple Pay work at the back-end, between the NFC terminal and the customer's own credit-card account? The merchant receives the single-use credit-card number and would presumably still process it the same way they handle a normal credit-card number: they pass it to their payment processor who then charges the network (Visa, MasterCard, or AMEX), who in-turn charges the customer's bank/credit-card provider... but how can any of those involved know what the customers' original credit account details are? Apple is the one generating these single-use codes. I understand that credit-card numbers include the identifier of the originating bank (which is why all of my cards from the same bank share their initial 8 digits) - so the Apple Pay system either generates a single-use code within the customer's bank number-space (i.e. with their bank's prefix) - or it must generate a single-use number with Apple's own prefix, in which case Apple would then receive the charge and then pass it on to the originating bank themselves.

Two possibilities for the back-end:

If Apple uses the customer's bank's prefix, then the bank gets the charge sent directly to themselves and Apple is not a payment intermediary - all Apple Pay does is generate a single-use number. Apple would have no way of knowing how much money was actually charged and so they could get cheated-out of the 0.15% cut they're asking for. This system would require some way of translating the single-use codes to actual account details - I guess Apple provides that to the banks via a back-end side-channel.

However, if Apple uses their own bank prefix, then it means that every transaction passes through Apple's system: they would have access to the details for every transaction and form a shopping-habits profile for all of their users. They would also be able to know exactly what amounts are being spent and claim their 0.15% cut and keep the single-use-card-details mapping a secret - they would then proxy (forward) the charge on to the customer's bank.

...neither of the above strike me as being particularly ideal solutions.

Everything is terrible

So I come to the conclusion that Apple Pay is a "patch" for NFC, NFC itself being an insecure add-on for an already outmoded system (that being the concept of reusable card details).

So I ask, when NFC was originally introduced, why didn't they introduce and mandate single-use payment details (managed by banks or the payment network directly, instead of a third-party)? And it would not have been a stretch to also use a challenge-response or (a reasonably future-proof) OTA encryption system - this would have completely obviated the need for Apple Pay.

Now, if it turns out that NFC already actually has OTA encryption and banks already support single-use details[3] (isn't that what EMV does anyway?) then what value does Apple Pay add?

Is this the result of the incumbent card networks (Visa, MasterCard, AMEX, etc) being so resistant to change that they'd rather add new features that inherit the underlying system's insecurity and/or technical incompetence which allowed an insecure system like NFC to be deployed into production, and without at-least pushing for OTA encryption as a patch after release? It's a mystery that given the sheer amount of money that card-networks claim (and where does it all go?) that we don't see them working on their own innovative or disruptive platforms... it's a no-brainer.

Footnotes

[1] I understand in many places, NFC charge amounts below a certain threshold, say $20 or £10, do not require a PIN for charge authorization authentication - ostensibly to speed-up the customer experience when making small purchases, such as a cup of coffee or a train-fare.

[2] And given the production-quality and attention-to-detail of present-day ATM card skimmers it's entirely possible that organized-criminals could devise even harder-to-find NFC skimmers given only the requirement for a passive receiving antenna and microcontroller + memory board.

[3] I remember reading about some banks a few years ago that generated single-use credit numbers for customers to use for online shopping, though this is a per-bank feature that is not inherently supported by the credit-card networks themselves.

ISO/IEC 14443 describes RFID cards, not NFC payment systems. That's the proximity solution that card issuers are using and has proven to not be secure enough/trustworthy enough and consumers have not adopted it.
– littleadvAug 10 '16 at 6:32

5

I'm voting to close this question as off-topic because the knowledge needed to accurately answer this question involves a detailed knowledge of network security and protocols. There are other sites in the StackExchange network that would be a better match.
– mhoran_psprepAug 10 '16 at 10:13

"skim low-value amounts[1] from "dumb" NFC cards" - no. There's no actual money on a card. You still need to use your merchant account to settle, and that means talking to the card schemes, who will come down on you like a ton of bricks when it becomes obvious what you're doing.
– AakashMAug 10 '16 at 14:31

3 Answers
3

I think that you're missing one significant point: NFC is not only used for payments. It's a general protocol ("Near-Field Communication") that is supposed to provide easy connectivity between adjacent devices.

As such, built-in encryption/security are counter-productive the same way as built-in encryption/security are counter-productive in IP: you're forcing something from a higher layer on a lower layer. Applications that use NFC but don't need this extra security will pay unnecessary penalty.

Here come providers like Apple Pay, Android Pay, Samsung Pay and others. They provide applications that use NFC for specific purpose. And they provide the security needed for that purpose.

Banks are welcome to introduce their own applications, but they lack the client base to make it wide enough spread for POS providers to include it. Visa/Mastercard have their own "near-field" solutions already that are embedded in cards themselves, and are not necessarily interested in competing with software giants like Apple or Google in their fields. Phone manufacturers also lack the wide enough client base (with the exception of Samsung, which is very popular and as the result is able to pull off its own payment system - I think they're partnered with Visa).

In my posting I refer exclusively to the existing single NFC standard used for payments only - not other applications of NFC (I believe this is ISO/IEC 14443 - though I can't find payment-specific information regarding this specification).
– DaiAug 10 '16 at 6:08

I disagree with your assessment that transport-layer (in this case, OTA) security is "forcing something from a higher layer on a lower layer" - on the contrary, transport-layer security is a perfect example of separation-of-concerns: NFC would be already inherently secure if the system mandated OTA encryption.
– DaiAug 10 '16 at 6:09

1

@Dai no, because that imposes extra burden that's not necessary. Do you always need all phone lines wire-tap proof? No. Are you willing to pay for them to be? No. SSL handshake adds latency to protocols, so why force it on those who don't need it? So TLS is a layer on top of IP, not part of the IP. Same here - transport is just a pipeline. If you want to make a more secure tunnel within the pipeline because you need it - you make it, others won't pay for it. That's how network layering architecture works. NFC is essentially is layer 2-3, whereas security tunnels are at layers 4-5
– littleadvAug 10 '16 at 6:29

@Dai in any case your question is entirely off-topic, so if you want to venture into a technical discussion on network security - I'll have to delete my answer and vote to close your question
– littleadvAug 10 '16 at 6:30

Banks aren't "welcome to introduce their own applications". Apple won't allow third-party apps to access the NFC hardware on the iPhone, so only Apple can make payment apps on their platform.
– Mike ScottAug 10 '16 at 14:56

If Apple uses the customer's bank's prefix, then the bank gets the charge sent directly to themselves and Apple is not a payment intermediary

Yes as part of adding a Card to Apple Pay, the details are sent over to issuing Bank along with device details and other info. Based on verification, the Bank sends a DAN[Device Account Number] and other codes.

After you show your phone at Point of Sale, DAN gets transmitted. This is similar as Card Number getting transmitted, there is additional info encoded. Visa then sends this back to Issuing Bank and based on DAN the actual card is charged.

Right now criminals have found the easy step ... as part of set-up Apple Pay sends info the Issuing Bank to Verify. If you are frequent user of iTunes and have used the same card for years, etc, its auto approved. Else they use alternative method, i.e. call the customer, etc. It is easy here to spawn. I get card details, no need to spend time in duplicating stuff [mag or chip]. Just try registering on Apply Pay, some one less experienced from Customer Service calls up and I am approved. Use this for few places and then just delete this card and add a new one. As Apply Pay doesn't store my card, they don't know new from old ...

NFC / Contactless Payment.

"standard" NFC-for-payments ... reads a straight copy of the card details ... does not generate any one-time-use card number ... does not employ any over-the-air encryption or even a challenge-response system [?]

However what process is used depends on the vendor equipment and the scheme (Visa, Mastercard, Amex, ...)

A "Magstripe mode", if supported, allows the card number and expiry date to be read.

There is a good description at Level2Kernel which covers "Magnetic Stripe Mode" and "EMV Mode" etc for each scheme (Mastercard, Visa etc do things differently).

MasterCard

Contactless MasterCard transactions can be performed in either EMV mode or Mag-Stripe mode. After Entry Point has initiated a transaction the MasterCard Kernel issues a Get Processing Options command. In the response from the card a data object called the Application Interchange Profile (AIP) determines whether the transaction will continue in either EMV Mode or Mag-Stripe Mode. The AIP also determines if “On-device cardholder verification” (CDCVM) is supported.

EMV Mode (M/Chip)

The commands exchanged with the card for EMV Mode closely resemble those used for an EMV contact transaction, with Read Record commands being used to retrieve all the card data, followed by a Generate Application Cryptogram (GENAC) request to obtain a unique, transaction-specific, cryptogram from the card. Once all of these exchanges have been completed, the card can be removed from the RF field. However, unlike for contact transactions, not all the transaction processing occurs before the card exchanges have been completed. This is to optimise the contactless transaction performance by reducing the amount of time the card is required to remain in the RF field.

Our technology uses the chip on your card to generate unique cryptograms (that’s techie speak for a type of puzzle that consists of a short piece of encrypted or encoded text) and digital signatures to protect your payments. Digital signatures are like handwritten signatures in some ways – but they are much more difficult to forge.

Fact: You have to be extremely close to someone for their gadget to be able to read your card - and even then all they would ever get is the card number and expiry date. That’s the same information you see by simply looking at the front of any card.There’s no way anyone can get the security code on the back of the card, your name and address, or bank account details. The vast majority of online retailers require additional details like these and others to make a purchase.

Clearly, Apple Pay must following the EMV contactless specifications of books C-2, C-3 and C-4 for MasterCard, Visa and American Express transactions respectively. More specifically, it must be following what I called above the “mobile phone profile” of the contactless specifications. It must be implementing the contactless mag-stripe mode, since magnetic stripe infrastructure is still prevalent in the US. It may or may not be implementing contactless EMV mode today, but will probably implement it in the future as the infrastructure for supporting payments with contact cards is phased in over the next year in the US.