Yoni Heisler does an excellent job of demystifying Apple Pay. I wrote up a shorthand version of the post, made a bit of a hash of it, actually, but got some great feedback. This is an edited version of the original which, I hope is now correct. Thanks very much for the comments.
Here’s my [updated] take on how all this works.
In a nutshell, when you sign up for Apple Pay, your credit card info is encrypted and sent to the appropriate credit card network. The network verifies the card, then sends you back a token. The token is the key to the process. It is not generated mathematically, so there’s no way to reverse engineer it or decrypt it to get from the token back to the card number.
Imagine if you went into a restaurant and queued for a table. The attendant writes your name down, shuffles a deck of cards, and picks one at random. They write the card down next to your name and hand you the card. If you want to check on your table, you show the card to the attendant, they scan the list to find your card number, then tell you your place in line.
The Apple Pay token is sort of like that randomly generated playing card. It is unique and, though it is the same length as a card number and may share the last four digits, it is not derived from your card number. Once you have it, the token is stored in your device’s secure element. The secure element is part of the NFC system and has a level of hacking protection, becoming disabled after a predetermined number of invalid access attempts.
When you use Apple Pay, you must prove your identity to retrieve the token from the secure device. As far as I can tell, a PIN won’t cut it. You have to use Touch ID to verify a transaction. That’s key. If someone steals your phone, they won’t be able to use your credit card.
Once Apple Pay verifies your identity, NFC is used to send the token to the merchant, the merchant sends the token to merchant processor, on to the card processors (Visa, MC, Amex, etc.). They in turn match up the pseudo credit card token with your real credit card number and then send that off to your issuing bank for approval. The issuing bank looks you up in their list, processes the transaction with the credit card company and sends an OK back to the merchant.
If someone intercepts your token, they won’t be able to use it without cracking Touch ID. I suspect people will immediately get to work trying to do this. But even if they do, once the token is breached, Apple can send you a new one, invalidate the old one, and you don’t have to replace your credit card. Huge.
One more piece of the puzzle is the CVV and cryptogram that your Apple Pay device sends along with the token.
But there’s a whole lot more to Apple Pay than Touch ID and the simple handing off of tokens. Providing an additional layer of security, an Apple Pay-equipped iPhone at the time of each transaction also sends a dynamically generated CVV up the chain along with a cryptogram. The CVV is the three-digit string located on the back of your credit card and, in the case of Apple Pay, is a algorithmically-generated dynamic string that’s tied directly to the token. The cryptogram itself “uniquely identifies the device” that created the token and, according to the EMV Payment Spec, is likely comprised of encrypted data sourced from the token, the device itself, and transaction data. Note, though, that the precise components of the Apple Pay cryptogram aren’t publicly known.
The important thing to remember, though, is that the cryptogram is effectively a one-time use digital signature that verifies that the token in transit originated from the device being used. Additionally, the cryptogram includes pertinent transaction data such as the identity of the merchant and how much is being charged.
Thanks again to JEhrler for steering me right (or, at least, a little righter).
Unfortunately you got several things wrong.
First, it is not Apple that generates the token that is essentially a pseudo credit card, rather it is the card processors (Visa, MC, Amex and, soon, Discover) and/or the issuing banks (this is a little unclear).
Second, it is not really a random number token, it has to follow the accepted nomenclature of credit card numbers. That is why it is 16 digits long, etc. so that merchant terminals simply see another credit card number to pass along and therefore any NFC terminal works with Apple Pay. However, there is nothing (other than the last four numbers) that correlate to your actual real credit card number.
Third, when you actually pay with Apple Pay, the token (aka pseudo credit card number) is passed to the merchant’s machine. It in turn sends it on through its merchant processor (e.g. Stripe) on to the card processors (Visa, MC, Amex, etc.). They in turn match up the pseudo credit card token with your real credit card number and then send that off to your issuing bank for approval. Apple is not involved with this process at all!
So, to sum, Apple’s only real involvement is in the software/hardware on your phone for storing tokens, generating one time cryptograms and using Touch ID (or something else with the Apple Watch) to verify identity before sending out the tokens and cryptograms.
The entire rest of the process is carried out by the existing payment systems.
The only thing I don’t quite understand is why individual issuers (banks, credit unions, etc) have to agree to be part of Apple Pay if the card processors (VI, MC, etc) are the ones actually matching tokens with the real credit card numbers. I assume this has to do with decrypting the cryptograms to provide vendor, etc. info but not really sure.
“when you sign up for Apple Pay, you send your credit card info to Apple…” — Really? This is the exact type of misinformation PayPal and the others have been spreading. The article clearly states “When a user first signs up for Apple Pay, […] the card
information is immediately encrypted and securely sent to the
appropriate credit card network.” Sent to the credit card company network, not to Apple.
Also “pin number?” Is that like the pin number I use at the ATM machine? It’s PIN, as in Personal Identification Number.
It is funny that, after referencing and presumably reading the very clear description on TUAW, Mark gets quite a bit of it wrong in his recap.
On the plus side, he did successfully drive me to read the entire TUAW article. So good job on that.
Thanks very much for the corrections. Can you take another read through, see if this is closer?
Yup. Mea culpa. Hopefully, this update is better. Thanks for the feedback.
Much better. One more piece of the puzzle you didn’t summarize, but is very important is cryptographic link between the one time cryptogram and the token. Without both pieces, a token is worthless.
Here is the quote from Yoni:
The important thing to remember, though, is that the cryptogram is effectively a one-time use digital signature that verifies that the token in transit originated from the device being used. Additionally, the cryptogram includes pertinent transaction data such as the identity of the merchant and how much is being charged.
There are two important facts here to remember:
Tokens cannot be used without an accompanying cryptogram
The cryptogram ensures that a token can only be used from the device on which it was initially loaded
The only piece of the puzzle I don’t understand and I wish Yoni (or you) could discover (ha!) and explain is why the issuing banks (Chase, BofA, etc) need to explicitly sign up for Apple Pay.
Since the card processors (Visa, MC, etc) do the matching of the token with the real credit card, couldn’t they also deal with the cryptogram? Then they could just send a normal set of data to the issuing bank.
But there clearly is something that the issuing banks need to do in the process that requires systems and explicit buy in. What that would be is the one piece I haven’t seen fleshed out.
Maybe you or Yoni could explain that? Thanks.
A pin won’t cut it? But if you knew the pin, you could just reprogram Touch ID anyways, no?
Credit card information can’t be encrypted unless the private key is also going to the banks in the initial setup. unless it is totally different mechanism from the secure element.
the whole issue is that secure element suppose to have the private key
but it is the banks that need it because otherwise Apple would know it.
So some how private key needs to travel from secure element to bank
in order to have a secure transaction.
because public key is what is coming back from the bank.
I guess I could read the EMVco standard. but I am too lazy.
I believe it has more to do with the fact that V/MC is really just a big switch and they don’t know if a card is active for instance with a issuer or have the other information the bank has to verify an identity. Another issue is debit routing (at least State-side with Durbin), which apparently they figured out.
The piece I am still sort of unclear on is how the bank at the start verifies that the token request is authentic. What is stopping someone with a copy of a credit card from taking a picture of it and scanning in to request a new token? Does the cardholder get alerted when a new token is requested? Of course I guess at the end of the day the issuer can revoke a token from being accepted just as they can reject a cancelled card.
As to your first part, the processors currently transfer the info to the issuing banks and await an approval or denial from them. So not knowing if a card is valid is part of the current system. My hypothetical doesn’t change this at all.
As to your second part, this will indeed be an interesting question. I wonder if it could involve a phone call from the issuing bank to the phone number on record with a one time confirmation number?
It will be interesting to see how the system secures this part of the loop!
I’ve been unlucky enough to work on payment transaction systems in the past. Overall this makes a lot of sense. I’m curious about some stuff that will never be made public (which is a good thing).
When a payment processor gets a token how does it know which agency or bank it should be sent to? Simple example, is it Visa or MC? Usually these are handled by different processors.
When you use up the tokens in your secure vault (they are one time use) does the bank refresh you with new ones? Do they send some ridiculous number of tokens so it’s never a problem?
just read the MacWorld article:
http://www.macworld.com/article/2607181/why-apple-pay-could-be-the-mobile-payment-system-youll-actually-use.html
another good one:
http://bankinnovation.net/2014/09/heres-how-the-security-behind-apple-pay-will-really-work/
Here’s how I’ll think it’ll work. You’ll scan your card (validate it …whatever). Your bank or credit card provider will accept it (hopefully). After which you’ll be able to touch your finger/thumb against the TouchID at Apple Pay enabled NFC transaction point and pay for whatever it is your after.