Skip to main content

Apple Pay and security: What you need to know

Yesterday Apple announced Apple Pay, a payment mechanism that will be available on the iPhone 6, iPhone 6 Plus, and Apple Watch. While the convenience of such a feature is tempting, how do we know if we can trust it? To answer this, let's take a look at what we know about Apple Pay's security so far.

NFC

The iPhone 6, iPhone 6 Plus, and Apple Watch will all include NFC chips. NFC — which stands for near-field communication — is a set of standards that mobile devices can use to communicate with each other via radio communications. It's somewhat similar to Bluetooth LE but, among other differences, only works over very short distances (generally 10 cm or less), making it ideal for things like mobile payments. NFC isn't anything new — credit cards and Android phones have been using it with limited success for several years now — but this is the first time Apple has included it in one of their devices.

NFC is not inherently secure. The standards that define NFC do not lay out any specification for how NFC transmissions should be secured. Often times they are not. It's not currently clear what, if any, security implementation Apple will be using to encrypt NFC transmissions between devices, but we'll see shortly why this shouldn't really matter.

With NFC credit cards, simply holding the card up to an NFC card reader is enough to initiate a payment. The downside to this approach is the cards are always in a readable state. There's no difference between you legitimately holding your card up to a card reader, and a criminal holding an NFC reader up to your butt to read the cards in your wallet. Enter the iPhone's first advantage: Touch ID. You begin an NFC payment by holding your iPhone up to an NFC card reader, but that only initiates the payment. iOS will then prompt you to confirm the payment using Touch ID. If you don't confirm the payment with Touch ID, then it will not go through. Additionally, once a payment has occurred, you receive a notification on your iPhone that the payment has taken place.

The Apple Watch will not have Touch ID, so how does it fit in to Apple Pay? Before you can make a payment with an Apple Watch, you'll have to unlock it with a passcode. Once unlocked, the Watch will only be able to make payment while it is in contact with your wrist. If the sensors on the back of the watch detect that it is no longer in contact with your skin, a passcode will need to be entered on the Watch again before it can make any more purchases. Finally, any time you go to make a payment, you'll be required to press the button on the side of the Apple Watch twice to confirm your payment. Once again, this helps protect against payment information being read just by an attacker getting in close proximity to you.

Paying within apps

In addition to making payments at NFC-equipped point-of-sale systems, Apple Pay will also bring the ability to pay for physical goods within apps. Until now, developers have been allowed to sell in-app purchases for premium in-app content, virtual goods, and subscriptions. Developers could not, however, charge users to purchase physical goods, or goods and services outside of the app. This led to frustrating experiences for users where you'd have to manually enter all of your credit card information into an app when wanting to make a purchase. With Apple Pay, buying physical goods can now be as easy as in-app purchase. In addition to Target, whose app Apple used to demonstrate Apple Pay during their presentation, Apple has also announced that other big names such as Groupon, Panera Bread, MLB.com, Starbucks, and Uber will also support Apple Pay in their apps.

The current ecosystem requires you to enter your full credit card information into an app which means you're trusting both the app and a server to both transmit and store your credit card information securely. With Apple Pay, neither the app nor the merchant ever see your credit card information. To understand how this can be, first we need to step back and discuss how iOS will hold your information.

Passbook and the Secure Element

To set up Apple Pay, Passbook will use your iPhone's camera to capture your card information (Note that Apple carefully chose the word capture. They did not say that you take a photo of your card). Apple will then take this data, go to your bank, and verify that the card belongs to you. Most systems will authorize a payment on your account for a very small amount, then require you to correctly enter the value of that amount — proving you have access to that account — but Apple hasn't yet revealed the details of their process. Once your card has been authorized, instead of storing your credit card number, iOS will use a unique Device Account number that is encrypted and stored in the iPhone's Secure Element. The details on the Secure Element are limited, but we know that it will be a dedicated chip on the iPhone tasked with storing this information.

When you go to make an actual payment, what's transmitted is a combination of a one-time payment number along with a transaction-specific dynamic security code. This seems to be Apple's implementation of tokenization) for credit card payments. With tokenization, rather than sending your actual credit card number, a token representing your card's original data is sent to the payment processor. The payment processor can then de-tokenize your information to map it back to your original card number. In short, your credit card number is never transmitted to merchants with Apple Pay. This one-time token can only be used once, drastically limiting the impact to a user if it is somehow intercepted.

And should your iPhone ever get stolen, payments can be suspended via Find My iPhone. One long-standing caveat to this is that Find My iPhone requires an Internet connection to work. The normal means to elude Find My iPhone are still available — notably enabling airplane mode — but this would also disable NFC. Even if a thief manages to disable all network connections while keeping NFC enabled, Apple Pay will still require Touch ID to make payments, making the process more involved for criminals than just holding your phone up at a POS.

Your private transactions stay private

While your most recent purchases will show up in Passbook, Apple has said that your payments are private, and they do not store details of your transactions. Additionally they point out that with Apple Pay, you no longer have to disclose your personal information to cashiers. Using a normal card, you give a cashier your credit card number, name, and security code. With Apple Pay, they don't see any of that, further reducing opportunities for your card information to be compromised.

Apple Pay and iCloud security

I've seen a number of people and publications comment on how could we possibly trust Apple with credit cards after the celebrity photo theft last week. We know now that the iCloud accounts in question were compromised by successfully answering security questions on the accounts; not by any misconfiguration or weakness in Apple's servers. iCloud Photos are also fundamentally different in that they're transmitted to remote servers for storage, from where they were retrieved. Apple Pay handles credit card information completely differently. It's good to be skeptical and ask questions, but what we don't need are more straw man arguments.

The comparison

Ultimately the question is, how does Apple Pay security compare to credit cards? By all accounts, it seems to win.

  • Apple authorizes that your cards belong to you
  • Touch ID is required for payments on iPhone
  • Passcode and confirmation button-presses required for payments on Apple Watch
  • No credit card numbers are stored on your devices
  • Credit card tokens are stored encrypted in the Secure Element
  • Payments can be suspended via Find My iPhone if your device is lost

The question should not be "Is Apple Pay 100% secure?", because no payment system is. The question should be "Is Apple Pay more secure than what I'm currently using?", and in many cases I think the answer is yes. Using the cliché analogy of home security: alarm systems don't protect you from burglars 100%, but they do offer additionally security over what a simple deadbolt would. It would be hard to argue that Apple Pay would be as insecure, let alone more insecure, than carrying around a wallet full of credit cards. Magstripes can be skimmed. Numbers can be written down. Cards can get dropped or left behind. Wallets can be lost. If you lose an iPhone with Apple Pay, you don't lose your actual credit card numbers, and it's protected by a passcode and Touch ID.

There are certainly some unanswered questions. How does Apple communicate with your bank when adding new cards? How exactly does the tokenization work and how well does it protect your original card information? How does the Secure Element work and how does it prevent tampering? Hopefully we see Apple release more details about each of these pieces in the coming months, but I don't see having any of these unanswered right now as a deal breaker.

How widely accepted Apple Pay will be or how well it will work are different questions entirely, and this post is not intended to answer them. I imagine that for the foreseeable future, Apple Pay will be a complement to carrying cards in our wallet, not a replacement. But personally, I can't wait to try it out on an iPhone 6 later this month.

23 Comments
  • Since Apple Pay requires the iPhone to have an internet connection, what happens if your iPhone doesn't have a connection in the store?
  • You don't pay via Apple Pay and have to go back to a credit card/cash Apple made it easier to pay, but did not completely remove the need to carry a credit card/cash with you.
  • You raise a good point and I believe I was wrong about Apple Pay requiring an Internet connection. I revised the paragraph in the article. Thanks for pointing that out.
  • If you want to learn more details of how Apple may be working with credit card providers, developer programs such as Visa payWave can give one a better insight. https://developer.visa.com/paywavemobile
  • One thing that occurred to me was I'm sure that there are a lot of people who allow a friend or family member to unlock their phone using Touch ID. So what I want to know is if any finger authorized on Touch ID can make a payment, or will there be levels of access available?
  • Presumably any finger would work. Touch ID has never been marketed as being for multiple people or offering different tiers of access. Could be interesting to see a feature like that get added in the future.
  • This looks good and cannot wait to see its capabilities and retailer implementation. I wonder how it would deal with something like splitting a check with friends for dinner. Just the other day was part of a group of 7 that split a $1K dinner...I think it was pretty easy for the waiter to take all 7 cards and split the bill evenly. Even if using Apple Pay means I have to carry just one card for emergencies, that would be a win.
  • Splitting checks is a great idea, but I don't think it will require much of Apple Pay. A waiter could in theory just ring up the different amounts to charge each Apple Pay device, as they currently do with credit cards. Any apps that implement Apple Pay could also implement a "split check" feature. For example, Uber has the option to split your fair with other riders. That could continue to work as it already does, and each person could use Apple Pay to pay on their respective devices.
  • I think it's worth noting, in this scenario, that you probably wouldn't be able to use Apple Pay at all. Most restaurants (at least in the US) take your card from you and run it on a computer, often not even in sight of the table (I know, I know, but that's a different discussion). If Apple Pay requires you to use Touch ID to initiate the actual transaction, then you're not going to be able to use it to pay at a restaurant unless they have a reader that they can bring out to your table. That said, splitting the check should happen in the restaurant's system, and then each card is run as a separate transaction, so there should be no reason that Apple Pay *couldn't* do it, assuming the aforementioned accessibility to the scanner.
  • This will be something that will be possible within the year, not immediately. As we have to move to EMV cards by October 2015 (no PIN, but at least we are making a move in the right direction), the current process of doing transactions isn't going to work very well (it is usually not possible to finalize a bill after the fact on a chip card when the chip was used to authorize the transaction versus storing the card number). What we will likely see is the mobile readers that are pretty much used everywhere in Europe.
  • I like the idea of sending the check via text message to do the verification. Diners still write checks manually, so I'd hope they would install NFC readers.
  • Some of your unanswered questions are actually already answered, Nick. The process that Apple is using is very similar to Softcard. I can get into some very deep technical discussions about them if you would like, but to touch on a few very quickly. When you add a card to your device, your bank is going to issue you a token that is separate from your card information that is linked to your account. When I did this on my Capital One account with Softcard a while back (when Capital One was supported), they literally gave me 3 new card numbers that showed up under my account (one card for each of the 3 cards I added). This "card" was then tokenized and the token was stored on the secure element. In this particular case, the token was now two layers deep (it was a token to a card to a card). In doing this, my real card information was never stored or ever exposed. The Apple method will do the exact same thing, although I'm not sure if the end user will ever see the cards in their account like how it was done with Softcard (although they may). The secure element and all about it can be found at http://www.smartcardalliance.org/publications-nfc-frequently-asked-quest.... The unanswered question is whether the secure element being used by Apple is SIM based or built into the phone itself (there are a bunch of different ways to do it).
  • You are way more informed that the writers at imore.com. It seems to me that the writers are just regurgitating Apple's marketing without understanding how the underlying technology. The tech was built before Apple and Google. Google and Apple are just using standards. There is no new magic here.
  • Thanks. To be fair, though, the information is new to Apple users so much of the technology is new to the audience. It is understandable that most don't know about how it all works because the ecosystem didn't have it before (whereas on Android, it's been there a while).
  • Thanks for your contributions. I understand the high-level of the implementation, what I'm looking for is Apple to detail their specific implementation. Secure elements have been defined as an abstract, but the specifics of how they are implemented can vary by implementation. I'm hoping to hear the details on Apple's implementation. The devil's in the details.
  • The specific architecure implementation is the same with any secure element, which is a standard for NFC. The key differences between various secure elements found in mobile devices would not be beneficial to document and expose by Apple unless Apple is planning to allow third party storage on the element itself (for non transaction purposes). So much of the information really isn't all that beneficial to the consumer. The one part that would be beneficial to know, however, is whether it is SIM card based or embedded. I believe it to be embedded, which means that information stored on it would be completely unique to the device and wouldn't be lost on a change of carrier. This is not true for many carrier based implementations today in which if you change carriers, you have to be issued new tokens since the Sim card changed.
  • Any idea what the flow will be like for transactions that involve adding a tip or some kind of gratuity? Or if that's supported at all?
  • Interesting question. For apps, they can just built-in a tip line and add that to the total amount. For physical establishments, I'm not sure if they'll need to let you add the tip before making the charge, or if there's a way to add the tip afterwards. The notion of transaction specific tokens seems to preclude the latter.
  • For physical establishments, eventually it will all be done at the table. In Europe, were Chip and PIN cards are used very heavily, the merchant brings a wireless card reader to the table to allow for the transaction. You specify the tip amount on your check and when the waiter rings you up, they put the tip in at that moment. You then complete the transaction by inserting your card and inputting your PIN. The same is true for NFC payments. You specify your TIP amount and the waiter puts that in. Then, they hand you the machine in which you tap your card or phone against it, it reads, charges, and then prints the receipt. The current process that we do in the US, that is charge, add a tip, and then close the transaction (finalizing the bill) doesn't work with chip cards (PIN or no PIN) or NFC cards. Since all cards are going chip (albeit most will not have a PIN) in October 2015, the new (to the US) process will be how it has to go.
  • Another thing to consider is what happens when returning a merchandise purchased with Apple Pay. Since the actual credit card number was never transmitted to the merchant, how will it determine which credit card was used when the customer goes back for a return (and lets assume that he no longer has access or using Apple Pay)?
  • I assume this is something the banks handle. They have the mapping between your token and actual account information. Any returns would be handled by them, not by Apple.
  • Actually, not that complicated. What happens is that when you make a purchase using Apple Pay, the device will generate a one-time use card number on the merchant network that your original card is associated with. This one-time use card number is what gets charged, but is actually valid for much longer than the transaction takes place (no less than 90 days), even if you cancel Apple Pay, get new card numbers, etc. This is for several reasons, but primarily for the ability to charge-back as well as returns. The merchant would return the funds to the virtual card used and you would see the funds in your bank account (or credit card) as normal. In fact, one thing that you will always know is the last 4 digits of the virtual card number that gets generated. This will usually be printed on the receipt as well (as it is almost always needed to do returns).
  • I think it's cool that Apple has finally added NFC. What I would like to know is if NFC is only available for payments or can you also transfer files to other NFC capable devices as well, like on many other devices with NFC? They never really discussed this and I haven't seen it addressed anywhere else. Posted via the Android iMore App!