Forget contactless point-of-payment… that’s a solved problem. Apple’s use of tokenization is the interesting part
[USUAL DISCLAIMER: I have no inside info, these are personal views]
I’ve been using a beta version of ApplePay on my iPhone 4 for some time now…
My very old, but very effective, Barclaycard contactless PayTag, stuck to my iPhone 4
The interesting question is how Apple chose to embed the card details inside the phone
To understand why, we have to rewind to March, when something curious happened: a body called “EMVCo” released a technical specification document for something called “tokenization”.
It was curious because it seemed to solve a problem that was already being solved by other players in the card industry. Make no mistake, however: the problem is a big one. Here’s what I mean.
I’ve written extensively about how Payment Cards implement the “pull model”. When you want to pay for something, you hand over your card details to the merchant and then hope that those details don’t get into the wrong hands as they pass from merchant to their acquirer to the switch and finally to the bank that issued the card in the first place.
In particular, the big problem is what happens when companies with millions of cards on file get hacked. Think of major online retailers who save your card details for you. It’s very convenient for you but it only works because they’ve stored your card details on their servers. If they get hacked, then millions of people are at risk of theft and card issuers will have to reissue millions of new cards. It’s a huge pain.
When you allow a merchant to keep your card details on file, you have to trust all the actors in the blue oval not to mess up…
However, there’s a really cool thing you can do to make this system much safer. It’s called tokenization. Here’s the idea:
- When you enter your card details on a merchant’s website for the first time and tick the “save my details for next time” button, the merchant doesn’t store your card details right way.
- Instead, they send the details to their merchant acquirer – e.g. Elavon – and ask them to issue a token.
- The acquirer creates a random number that might look like a credit card number in some cases – the token – and returns it to the merchant.
- The acquirer records all this information in its own database (i.e. the real card details, the token they issued and which merchant they issued the token to, etc).
- The merchant stores only the token in their database, not the real card number.
Now, next time you try to buy something from that merchant, they send the token they’ve stored to the acquirer. The acquirer checks that the token is valid and that it came from the right merchant. And, if so, they convert it back to the real card number and process the transaction as normal.
The really important point here is that we no longer really care as much about the merchant’s security. If they get hacked, it’s not as much of a problem: the tokens are useless to anybody else. The acquirer will only accept them if they’re presented by the original merchant. If the hacker tries to use them somewhere else, they simply won’t work.
Excellent! A really simple system that dramatically reduces the risk of fraud and lowers risk and cost for merchants. You can think of it as if the “circle of trust” has been shrunk:
If merchants use tokenization services, the implications if they get hacked are far less serious. (TSP stands for “Token Service Provider”)
And this is nothing new. Acquirers have offered this service for ages for merchants who wanted to use it.
Great. Problem solved?
Not so quick….
Now think about Apple Pay and think about the challenges Apple faced in getting this to work.
Here’s how contactless payments are supposed to work when you pay for goods in store: the cashier rings up the price and activates the contactless pad so you can pay. You tap your contactless card and you’re done. This piece is completely normal: anybody with a contactless (“PayWave” or “PayPass”) card can do that today. It’s what I’ve done with the PayTag on my iPhone 4 for ages.
But how do you get a phone to pretend to be a contactless card? Well that’s a solved problem too. Android devices have done it in various ways for years, for example.
So what’s the problem? The answer is: security. Sure… you can put somebody’s card details into the “Secure Element” of a phone (or do something clever with Host Card Emulation) but if you’re putting the real card number in there then you face all the same risks a merchant faces… if somebody were to figure out how to hack into your system, you’ve got a big problem on your hands… And in Apple’s case, imagine if almost 1 billion payment cards were compromised!
So it would be much safer if you stored a token on the phone, rather than the card details themselves. That way, if the system is broken, you can just invalidate all the Apple tokens and you’re done.
But there’s a really subtle problem
How does a firm like Apple get the tokens? Remember: they want to emulate a contactless card so that the customer can use the phone to pay at a merchant. You don’t know which merchant acquirer any given merchant uses so an acquirer-specific token is useless!
So Apple can’t use the merchant acquirer services to get its tokens… imagine it put a First Data token on its phones. What happens if you try to pay for something at a merchant who uses Elavon? It isn’t going to work…
And this is where the EMVCo spec comes in. In short, the EMVCo spec proposes is that tokenization be standardized and it implies strongly that it should be the schemes (or maybe issuers) who perform the work, not the acquirers.
Effectively, they’re proposing the circle of trust be tightened even further:
I scratched my head at first… apart from perhaps being a power grab, why would anybody bother change this simple model?
The answer was on page 26, section 3.8 and the introduction of the idea of a “token requestor”. What the EMVCo spec highlighted – and what I missed at the time – was that it isn’t only merchants who might want to create tokens… other players might need to as well… players like telcos and Apple:
“Payment Token Requestors may be traditional participants within the payments industry or newly emerging participants. Potential Token Requestors include, but are not limited to Card-on-file Merchants, Acquirers, Acquirer Processors, and payment gateways on behalf of Merchants, Payment enablers, such as original equipment manufacturer (OEM) device manufacturers, Digital wallet providers, Card Issuers”
(EMVCo Tokenisation Spec, page 26-27, my emphasis)
Of course!
Imagine you were trying to build something like Apple Pay. This is exactly what you would need. You’re faced with consumers with cards from thousands of issuers and you want to create tokens that can be processed by merchants who use one of tens of acquirers.
You need a system that gives you a token that all acquirers can process and which the schemes can route to the right issuers… it makes sense that it be the schemes who provide such a services. Indeed, Visa Inc have written about their service here.
And so I think that’s what’s going on. Apple is acting as a “Token Requestor” in the EMVCo model. When you enter your card details or take a picture of your card with your iPhone 6, Apple will call the Token Service for the appropriate network – let’s assume Visa. Visa will check the details (maybe your postal code, CVV2, etc) and perhaps authorize with the issuer.
And Visa will then issue Apple with a token. This token will only work for contactless payments and it will be associated with Apple so it can be revoked in the event of a problem. But it will look just like an ordinary card number so acquirers will be able to process it without even realizing it’s a token.
And it’s this token that will be stored on the phone’s secure element and passed to merchants every time you use it. So, in many ways, Apple Pay could turn out to be astonishingly standard-compliant.
In summary, my take on the interesting aspects of the Apple Pay announcement are:
- It’s looks like a really nice use of the EMVCo “Token Requestor” concept
- It relies on schemes having Token Service Providers up and running so don’t expect it to roll out everywhere, for all schemes, any time soon.
- It’s surprisingly vanilla.
- It’s conceivable that Apple is taking zero cut from any of this. They’re certainly not in the transaction flow in any meaningful way
- But notice how much leverage it gives them over issuers. It would be easy to refuse to include an issuer’s cards on the platform unless the issuer pays up. That has the interesting property that deals could be done on a case-by-case basis and different issuers may have different deals.
This is, of course, just my analysis from public information. I have no inside knowledge and I could be completely wrong. In particular, I’m struggling to reconcile my analysis with some claims that Apple Pay will use a different token for every purchase. I don’t understand how that would work, unless we assume the phone is online at point of purchase? Anybody know for sure? Am I way off the mark?
Richard Gendal Brown 
Great post Richard!
Two points:
1. My understanding was that they wouldn’t use a different token for each transaction but generate a new security code (CVV?) to accompany it – not sure how this helps though. Also, all the negotiating Apple has done about having this recognised as “Card present” transaction process confuses me slightly – isn’t contactless always card present? Or does this mean its now the equivalent of PIN verified because of the fingerprint ID? Makes me think that somehow this is not really running as a card present transactions (hence the dynamic security code) but they have simply negotiated “card present” rates – would be keen to hear your view.
2. You write that its conceivable that Apple will receive zero cut as they are not in the transaction flow in any meaningful way. This was my thinking and tied with your last bullet on the leverage that Apple has and the reports of them negotiating discounted rates with issuers actually makes me think that have simulated a 5 party model where they take a slice of the interchange (in the form of a rebate from issuers) in exchange for using their infrastructure (and inclusion in the wallet). If so, its a massively audacious approach to solving the commercial model compared to previous attempts. It also makes me question whether it could ever work in Europe with interchange due to plummet….
Reblogged this on Preston Byrne and commented:
Richard Brown rocks it again.
@moshe – Hi Moshe – long time no speak 🙂
Thanks for the comments
1) I wonder if this is just confusion from commentators who don’t fully understand the subtleties of payment card fees? Alternatively, perhaps they’re referring to ApplePay’s usage for purchases in apps? i.e. the non-NFC case? Hard to tell
2) Agree. If they *are* taking a per-tx fee from issuers (calculated/reconciled how?) or even just some other mechanism, I agree it’s massively audacious.
Great post! From what I can tell the payment terminals themselves should not require any changes to be able to accept Apple Pay. If the token is effectively a virtual card, is there anything that prevents it from being used at contactless terminals internationally, provided the issuer has not chosen to disallow international transactions?
Hi Oliver. I agree… and I can think of no reason why it wouldn’t work abroad, provided the card was issued by one of the US issuing banks currently onboarded by Apple.
Richard – great post as usual.
You ask how one-off tokens could work if the phone is offline. One possible answer is that a small number of different one-off tokens (say 5) will be down loaded to the phone for use when the phone is off-line. Doesn’t solve the problem if the phone is not connected for some time but in most situations making more than 5 payments before being back on-line is not very likely.
@Keith – thanks 🙂 Great idea… yes… that could work. I also spoke to a colleague yesterday who speculated that the token remains the same but some other field is used to create a secure value that changes each time — it would need to be something that the phone could calculate offline but which the network could validate… (Reminds me of the RSA SecureID system where an offline device is able to reliably create random-looking numbers that the server is able to validate). Suspect it could be done quite easily by including some sort of secret seed at the time the token is provisioned to the device.
Pure speculation from me, but I wonder if the ‘different token’ per transaction concept could effectively be 2-factor authentication using something akin to a tokenized version of the CVV2.
If the scheme/issuer and the secure element both know this CVV2 token, then a payment could be authorised by the secure element effectively signing its request using a hash against this CVV2 token plus, say, the transaction timestamp (available without being online). The transaction could be verified by the scheme/issuer without the customer having to reveal the tokenised CVV itself, meaning that even if the transaction was intercepted, the CVV2 token would remain safe.
Richard: looks like you beat me to it!
@andy – genius! Thanks…. I may have replied to Keith first but you provided a plausible mechanism. Very clever. Seems very do-able, for sure.
Hi Richard,
You wrote:
“And Visa will then issue Apple with a token. This token will only work for contactless payments and it will be associated with Apple so it can be revoked in the event of a problem… And it’s this token that will be stored on the phone’s secure element and passed to merchants every time you use it. So, in many ways, Apple Pay could turn out to be astonishingly standard-compliant.”
If your Apple device receives a token that gets stored only in the device secure area, and never synced with your other iCloud-backed data, what happens when people migrate from one Apple device to the next (upgrades, replacements, etc)? Will they have to photograph/re-enter all their card data and receive new tokens?
Using a different token for each transaction that is generated off-line is not a problem, they could use “heuristic deterministic”
keys generated from a seed with high entropy. It’s a standard already implemented in Bitcoin.
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
You can recreate the credit card wallet on any device as long as you know the 12(or 18 or 24) word seed.
Hi Isaac. Good question. I assume you’ll need to re-enter details but I guess it’s conceivable that Apple could cache the token too – not sure.
Hi Paul,
Good point but I’m not sure it would work in this case. Here’s my thinking: the 16-digit card number address space feels too small to allow every consumer to have a non-overlapping (and potentially unbounded!) number of deterministic one-time-use values. So you’d have to put the “changes every time” value in a different field. As Andy points out, you could imagine CVV2 or something like that being overloaded. But now your problem is different: to avoid an adversary simply reusing a value they’d seen you use in the past, it would have to be tied to the transaction… so a signature over a representation of the transaction feels like the way to go.
Hi Richard,
Yes, you’re right about the address space being too small for card numbers.
I would have loved to be a fly on the wall while they were working all this out, knowing that most of the problems encountered have already being solved but being constrained by having to use the existing credit card infrastructure(and not the Bitcoin protocol or similar).
If Apple caches the tokens, it’s susceptible to iCloud backup attacks ala FappeningGate
@Paul – agree. Would have been amazing to have been on the inside as this was being worked out. Delivering something that has a good chance of achieving good consumer adoption on top of a massive legacy infrastructure is entirely non-trivial!
Seems we were on the right lines for the business model… http://www.macrumors.com/2014/09/12/more-apple-pay-details/
Apple will very likely be using existing NFC payment technology for the communication between the iPhone and the merchant terminal. Where supported, I suspect that this will be EMV.
For those wondering about the “dynamic” value:
There is an existing fallback method for NFC payments that allows using some of the magnetic stripe data fields to encode a per-transaction value which proves that the original card has been presented to the payment terminal. It is used only as a fallback where proper EMV payments are not possible. If you’re interested in the details, see the paper linked on the presentation page below.
The advantage is that, to the terminal and to the merchant’s payment systems, everything looks like a plain old magnetic stripe payment (only the physical card reader has to be replaced, the software and payment protocols stay the same); the disadvantage is that no transaction-specific data is actually included in the “signature”, and there are some attacks possible: https://www.usenix.org/conference/woot13/workshop-program/presentation/roland
It would be interesting to know whether Apple intends to support that fallback protocol with Apple Pay; if they don’t, this might force US merchants to finally adopt EMV payments.
I like your analysis and I appreciate the work you have done. Having experience in the financial industry and the tech world, I completely agree with what you are saying. I am wondering however, what do you think banks will do when Apple Pay starts to be the predominant form of mobile payment?
Taking your analysis one step further, if I have itunes, and Apple Pay, as a bank my role as a card issuer is limited because I don’t need a banking wallet or payment solution from a merchant standpoint.
@Lukas – very helpful. Thanks.
@Abdul – agree. You can already imagine Tim Cook’s keynote next year can’t you…. “You know… having to tap the pad is so CUMBERSOME!”… and then they use iBeacon or something to make the payment request appear on the screen just at the right time and you simply approve by pressing Touch ID… So now Apple controls the consumer side *AND* has an offering on the merchant side… so they can route the transaction… sure… they could route it to the payment card system but they don’t need to at that point…
That said then, what can banks do fend off this threat? What are your thoughts on what Android will do?
Just guesses here I presume.
Thank you Richard, a great explanation.
So, where are we now:
– storing a card at an iPhone triggers the TSP to issue a token which is associated to an iPhone-hardware ID. This could be any payment gateway.
– paying with ApplePay then wraps an encryption around TouchID, Token, and Transaction Details, and processes this package up to the issuer.
Yet how is this decrypted? Is Apple needed for this? If so, I had an idea, why they take 0.15% of each transaction and why they do not know details of the transaction in the same time.
My bottom-line is, Apple uses network-side tokenization in combination with a strong (probably Apple owned) encryption / decryption. So they do not know the details, but the network has to use Apple for decryption.
Does that make sense to you?
Hi,
I have few querie on ApplePay
1) How Apple passbook is part of Apple Pay ?
2) I beleive an iPhone user will be able to provision mulitple accounts (or credit cards) in ApplePay. In such secnario, while making payment on some POS, which card will be used for payment? Will the phone show options or user has to prioritize the accounts through some settings?
Thanks
mobiQ
@abdul – great question! My prediction is that the right path forward for the Android ecosystem is for mobile network operators to step up…. they have the consumer relationships, after all, in a way that the Android manufacturers don’t. i.e. apart from maybe Samsung, which Android manufacturers are seriously going to be able to offer something similar?
@Andreas – I think step 2 might be slightly different. Remember that everything is going over the regular payment card rails…. the merchant terminal just thinks it sees a contactless payment card. So I don’t see where any Apple-specific stuff can fit in general. So my theory is that they’re doing the following. A) I think they send the same token every time. B) But in addition, I think they must be provisioning a secret to the Secure Element when the card is first enrolled…. and this secret is used to create a transaction-specific code, which is placed in another field (CVV2? something like it?). Perhaps they just hash the timestamp and encrypt it using this secret? Maybe something more sophisticated. Doesn’t really matter… it just needs to be based on a secret that only the iPhone Secure Element knows, which is somehow unique to a transaction to prevent replay attacks and which the scheme/TSP/issuer can verify. And since the TSP/issuer was involved in token creation, they will know what the secret key or its public pair is C) I don’t think any TouchID information is sent over the rails… the TouchID piece, instead, could be what justifies Apple’s fee. This is because the issuers will know whether the transaction came from an iPhone or not (since they can see the token). So they’ll know the transaction was authenticated by TouchID. And so they’ll be confident that the transaction was initiated by the true owner of the card… and so the likelihood of fraud is lower than with a regular contactless card. Perhaps they’d be willing to pay 15bps for this assurance. (Consider the plastic contactless use case…. no PIN is required in general and the issuer can *not* be sure the card was used by its true owner… so the risk of fraud is much higher and transaction value limits much lower as a result)
@mobiQ
1) I think PassBook is used in two places…. A) it’s presumably the user interface a customer uses to enrol cards. B) it would be the place the consumer goes to see transaction history, etc. Note: my hypothesis is that transaction history is *pushed* by the issuer after the payment is made… i.e. the iPhone doesn’t know any of the details at the time it pays… it just authorises a transaction… it’s only when the issuer then pushes down a message that the iPhone knows the value and the name of the merchant, etc
2) I’ve seen a video somewhere where you have a default card… but can also press the TouchID button in advance of the purchase to pull up a UI that lets you select your preferred card for a particular transaction.
A nice analysis on the subject. Just a novice question. It is mentioned that we can take the snap of the Credit/Debit Card and then apple with the use the tokenization service provider (VISA) will to create a “Dynamic Account Number ” which is stored in the Secure element which is the token.
But let say if a rouge user goes and scans some one else Credit /Debit card, will the token be generated blindly or the Issuer also has some role to verify the card? How will issuer Verify that phone and Card are owned by same person?
Hi @Ali – don’t know how Apple will do it but there’s the concept of ID&V (Identification and Verification) in the EMVCo spec. As you imply, the Issuer needs to be REALLY sure the card is being enrolled by the true owner… since once the token is issued, there will be a general assumption that it is “good” from then on… so getting it right as this point is very important.
In general, I would expect issuers to use things like CVV2 and asking for postal code information and maybe also 3DS (i.e. Verified By Visa, etc)… basically whatever the issuer considers necessary to be sure the token is being issued to the card’s rightful owner.
Thanks for the quick reply. But yet another question, if 3DSecure is used chances are that an SMS is sent to the same mobile phone so the rouge user can put the OTP easily and verify himself?
@ali… ahh – perhaps 3DS is deployed differently in different countries? My experience (UK) is that 3DS requires you to know a password that you previously set up (via 3DS) with Visa… no SMS.
@gendal : Yes true. In UAE it works by sending an OTP
https://www.sc.com/ae/3dsecure/how_it_works.html
🙂
Hi Richard, fantastic post – among the best I’ve read on Apple Pay so far.
What are your thoughts on Apple Pay moving to UK? What changes would be required for it to work here? My understanding is that all we need is the Tokenization Service that the schemes are providing in US. All the other systems, on the merchant, issuer and acquirer side, do not need to change. Am I correct?
Also, I wonder if we could ‘jump the gun’ on Apple Pay in UK, especially since there is wide contactless adoption here. Could another party, (say Samsung perhaps?) launch something like Apple Pay, but using HCE and their own proprietary tokenization service? My guess is, they probably could, but it would work only for cards that they have issued themselves. If they want to provide an ‘open market’ service similar to Apple Pay where a customer could load any debit/credit card, it wouldn’t work because there isn’t a centralised Tokenization scheme. Would you agree?
If so, it sounds like we need Visa/MC to hurry up and bring their Tokenization service across the pond!
Hi Richard,
Great post and I hope I can add some more information based on my own research into Apple Pay after their announcement. First, I should point out that Apple Pay really makes things quite secure, by minimizing many of the leakage points along the Consumer–>Issuer–>Switch–>Acquirer–>Merchant chain. Yes, the use of a dynamically generated one-time use token is one such component, but the entire system includes the following security components for the first time in a NFC enabled contactless payment system:
1. h/w encrypted storage (Secure Element Chip on device)
2. biometric security (Apple’s Touch ID)
3. Cryptograms (provided by card issuing banks)
4. Dynamically generated one-time use tokens (provided by Visa/MC/Amex).
As you know for security, the problem is always securing the weakest link in the chain. Typically that has been the user who either loses his wallet or his card details to spyware. More recently, hackers have gone to the large nodes in the network, namely large retailers and payment processors like First Data to get most bang for their investment.
Based on what Mastercard shared:
http://bankinnovation.net/2014/09/heres-how-the-security-behind-apple-pay-will-really-work/
it seems that with this new system, Apple has seriously strengthened the user side of the equation by storing only cryptograms and tokens in the secure element chip and not the card numbers. Additionally, they’ve ensured that only valid card numbers (cryptograms) are used by involving issuing banks when the card is scanned into the Passbook application.
Also, Apple worked with 6 of the major payment processors: Authorize.net, Chase Paymentech, Cybersource, First data, Stripe, TSYS to ensure that their APIs integrated Apple pay within their platforms. This ensures that encrypted information provided at the time of purchase by the iPhone’s Secure element chip to the POS terminal, could be decrypted, passed on to Visa/MC/Amex for token validation and finally the issuing bank that would validate the cryptogram. By securing the entire transaction chain, Apple is helping the issuing banks cut down on their fraud expenses and liability, something that they may believe is worth the rumored 0.15% that Apple asked for. It also brings a newer, younger consumer to the credit card market which has generally preferred to use other types of payments (e.g: bitcoin).
What is more interesting if you read Apple’s guide to Apple Pay , you’ll realize that their vision is much broader and this system is not limited to in-store retail purchases. They’ve published pre-requisites for apps that wish to use Apple Pay for payments, something which should really worry PayPal.
“Hi @Ali – don’t know how Apple will do it but there’s the concept of ID&V (Identification and Verification) in the EMVCo spec. As you imply, the Issuer needs to be REALLY sure the card is being enrolled by the true owner… since once the token is issued, there will be a general assumption that it is “good” from then on… so getting it right as this point is very important.
In general, I would expect issuers to use things like CVV2 and asking for postal code information and maybe also 3DS (i.e. Verified By Visa, etc)… basically whatever the issuer considers necessary to be sure the token is being issued to the card’s rightful owner.”
It could be much simpler…when you take a photo of a card to add to Passbook, Apple can read the name on card and validate against the registered details in your Apple account…
@ltj21 – great questions. My take is that, at the very least, a scheme in the uk would need to offer a token service. However, I think the issuers may also need to do a small piece of work – I don’t know what that is but I suspect it might be 1) updating authorisation systems to allow >£20 transactions if authenticated with touchid. 2) maybe updating issuer/processor systems to integrate with passbook (maybe push notify of successful transactions? Speculation)
On the android side, I wonder if the MNOs have an opportunit… Most of them have already done work with NFC. So I agree with you. Why not modify to work more like apple pay and the relaunch?
Thanks Prakash. Very helpful. I’ve seen conflicting information on the tokens. My working assumption is that they are *not* single use and that the single-use/per-tx data is carried in some other field. But I don’t have the detail.
I agree the developer spec is interesting. It does seem to validate apple’s claims that they don’t capture much data. The app developer only really has to pass value and merchant ID through the apple pay iOS api.
D’oh! Good spot 🙂
Here’s my question. Apple has listed some processors that already support Apple Pay. What happens if a merchant uses Elavon, for example? Will it not work at all? Will it work for some cards?
Do the acquiring bank/processor, payment network (Visa/MC/AMEX), and issuing bank all need to support Apple Pay for my transaction to process correctly?
A customer using a Bank of America Visa card at a merchant using Chase Paymentech – this will work (right?). What if the merchant used Elavon? What if the customer used a local credit union Visa card?
Your article was great! Thanks!
@dinfos – from what I can tell, the acquirers are almost entirely irrelevant to this… the transaction is routed through them, of course, but they don’t need to do anything special…. it’s just a payment card transaction. That’s the nice thing about the EMVCo tokenisation spec… tokens look just like regular card numbers (PANs). So they can be routed and processed without any changes by those participants who don’t need to know anything about them. It’s only when the token reaches the scheme (or PERHAPS the issuer, depending on the model) that their lookup table tells them it’s a token and they route it to the TSP to get it converted back to a PAN and then things carry on as normal.
In-app payments will probably require some changes to the acquirers, though? They currently don’t need to forward a cryptogram to the issuer/token service provider; it seems like they have for Apple Pay (the onlinePaymentCryptogram described in Apple’s Payment Token Format Reference). However, this might be something that is already necessary for acquiring 3-D secure transactions.
@gendal: Do you have any idea whether Apple Pay in-store supports only EMV terminals, or whether the legacy Mag Stripe protocol (with a CVV3/dCVV) is supported?
@lukas – good point re cryptograms… not something I know anything about (i need to do some more reading!). as for in-store, I think it’s only contactless… i.e. not magstripe and not EMV chip/pin, chip/dip, etc…
@gendal: There are actually two contactless profiles: EMV and one (a bit confusingly) called “Mag Stripe” (at least by Mastercard).
The former is very similar to the contact-based variant; the main differences are that offline PIN verification is not possible and that the issuer can’t reply to the application on the card, both because the card only stays in the terminal field very briefly.
The latter is also similar to its namesake and has been designed in a way that necessitates only minimal changes to POS, merchant and acquirer systems: To them, it looks like a plain magnetic stripe transaction where only the static data of the stripe is transmitted with the transaction details.
However, the values are not completely static: The terminal challenges the card with a random number for every transaction; the card signs this challenge and an incrementing transaction counter using a secret key only known to the issuer and the card. It includes the result (CVV3) in place of the CVV value that is part of the legacy magnetic stripe data fields.
Since the issuer knows the key and the latest transaction number, they can verify that the original card was involved in the transaction. However, the values used are cryptographically speaking very short and the transaction details are not used as an input to the signature generation; this allows for some transaction pre-play attacks. It also can’t be used for offline transactions, since the terminal can’t autonomously verify the authenticity of the CVV3.
A card and a terminal might support only one or both of the contactless payment protocols; EMV is always preferred.
@lukas – EXCELLENT! Thanks so much for clarifying this point… as you can see, I’m not an expert on NFC and I didn’t know any of that detail… and it fills in a key gap in my knowledge around how they’re able both to use a static token AND include some dynamic / per-transaction element…. thanks for persisting 🙂
Interesting and insightful analysis! Many of the reports on Apple Pay have been by people without knowledge of EMV tech.
> “And Visa will then issue Apple with a token. This token will only work for contactless payments”
This point doesn’t seem right, though. Since iPhone users will be able to use Apple Pay to transact online (through certain payment gateways), and the original PAN is not stored on the device, presumably it will be a token that is used for the online transaction. It’s possible that there will be two tokens – one for contactless and another for online – but I haven’t come across anything yet that says authoritatively that there are two tokens stored in the Secure Element.
@andrewescott — good spot. Thanks. You’re right — my wording was confusing… I was trying to point out that the token wouldn’t work if somebody somehow extracted it and created a magstripe card out of it or entered it into a web form… i.e. it’s more secure than having the PAN on the phone. But you’re quite right, it’s also needed for the in-app path.
Very clear explanation with nice graphics too, never seen it that way before.
You wrote: “When you enter your card details on a merchant’s website for the first time and tick the “save my details for next time” button, the merchant doesn’t store your card details right way.” WHOA!
The merchant has to posses the credentials (even for a second) to send them to their processor. Remember RAM scrapers at Target? If at __any point__ the merchant has the confidential consumer credentials then those credentials are vulnerable to security weaknesses of the merchant.
Another weakness is any fourth party such as Elavon, a processor you mentioned by name. In March 2014 the California DMV was notified by MasterCard of what turned out to be a six month exposure opening a window to at least 12 million transactions made during 2012. Their processor? Elavon. For that matter why are the consumer credentials held in a phone at all? Proprietary hardware may stop some crooks, but impossible just means it hasn’t been done yet.
Why does there need to be __any__ fourth party in addition to the consumer, the merchant and the provider?
How does an NFC communicator, or chip-in-card, going to improve security in the growing venues of electronic (from computer) and mobile (from cell phone, but not physically present) commerce? Can physically present (brick & mortar) merchants afford to implement both? Target alone is facing a $100M bill for the EMV partial solution.
We don’t need more complex and expensive locks. We need a shift in thinking where the merchant never has even temporary custody of confidential consumer credentials and can provide security in physically present, electronically present, non-present commerce, all while operating within existing hardware and communications infrastructures and without proprietary restrictions. There is at least one system that may.
Simply put:
What Merchants don’t have, Crooks can’t steal.
Ajaypal Singh Banga, are you reading these?
Jonathan E. Jaffe
Re: CA-DMV See http://www.nc3.mobi/references/2014-unknown/#20140322 for details, references and links.
Re: Target compromise see http://nc3.mobi/references/20131218-target
NFC which has problems known for years. See http://nc3.mobi/references/nfc/
EMV is no panacea either. Problems were made pubic as far back as 2008 See http://nc3.mobi/references/emv/
@Jonathan – thanks for the comment.
I didn’t intend to imply tokenisation solved the problem of the payment card architecture… it’s merely a mitigation for some very serious risks. As you say, the only way to be sure the merchant (or its processor) won’t lose or misuse your secrets is never to share them with the merchant or its processor. I call this mode of payment a “push payment” – i.e. the funds are pushed to the merchant by the consumer, rather than the consumer giving the merchant the information they need to pull the money from their account.
New systems such as Barclays PingIt, VocaLink Zapp and, of course, Bitcoin work in this new way. From the URL in your post, I’m guessing that’s the way your platform works too?
The problem (at least for the systems I’ve studied) is that transitioning to push from pull requires huge disruption to the merchants… so there is a friction to overcome.
Richard
@Richard
NC3 is for provider-level adoption (ex: each bank that issues charge cards) so there is no fourth party that __ever__ has the, confidential consumer credentials. Neither does the merchant which is why one of our phrases is
What Merchants don’t have, Crooks can’t steal.
NC3 isn’t like anything else you listed and I have a list of several dozen that it isn’t like. NC3 is less expensive as it requires no special hardware (i.e. any smartphone) by the consumer and works in the existing transaction and communications infrastructure, so no new hardware for merchants. NC3 functions in all commerce venues with many features not even described elsewhere. My personal favorite is VoiceCommand. I invite you and your readers to read the PDF linked from the bottom of the home page. The 16 pages are designed to be printed as a booklet, so the print is large. Also makes for easy on-line reading.
Or, get the story direct.
Click to access NC3-Graphic_Story.pdf
If you drink coffee from a drive through see one operational efficiency at
Click to access NC3-Ex-DriveThru-OrderInAdv.pdf
As for Bitcoin, I like the idea, but I’m not keen on being subject to currency fluctuation such as $1100/BTC on 4/4/2013 to just under $400/BTC this morning and on a long downward trend. See http://www.coindesk.com/price/ and change the first date to 9/22/2012.
If you think NC3 has value see the menu for HowToGetIt and scream toward the people listed there.
Jonathan
@Richard
Does ‘switch’ represents Payment Networks(Master/Visa etc) in your diagrams?
@mobiq – yes… sorry for not being clear. I was referring to the function they perform in routing (i.e. switching) payments from merchants to issuers.
Great post! Lots of quaere I caught up. Thanks.
I wait update in addition.
Hi Richard,
This is a great post! Very informative.
You presented to us at Santander on BitCoin, I’ll pass this on to the wider group!
Expect a new follower on Twitter
Thanks again.
Reblogged this on mobiq and commented:
A great post on Apple Pay
There is one thing in Apple Pay that does not seems to me as “vanila use of EMV tokens”, and that is ability of ApplePay to do “card present” transactions – in other words, to simulate actual credit card at contactless payment device.
Normally tokens are used by merchants who wants to save credit card numbers in order to save time for customers when they shop again on their ONLINE sites (since stored card numbers do not help much for in-store purchases when customer have physical credit card). And for any online transaction it can not be proved that actual credit card is on other side – card chip can not be used to sign transaction as they do when actual card is used in store. Upside for those “card NOT present” transactions is that merchant does not need chip – only card number and CVV. Downside is that banks/Visa/mastercard charge more fee % for those “card NOT present” transactions due to increased risk.
But in this case ApplePay is able to do “card PRESENT” transactions, which imply it is able to SIGN every transaction with key issued by card issuer and normally stored in card secure chip (Authorization Request Cryptogram – ARQC). Technically that is not strange – I assume keys needed for signing this is what Apple says they get in addition to card number token. But what IS strange to me is WHO issued that key?
While card number tokens can be issued by Visa/MC without issuer bank knowledge (allowing card from ANY bank to be linked to ApplePay), keys to sign “card present” transactions are presumably issued by card issuer bank (and ARQC signed transactions are checked by same issuer bank).
So, if bank who issed card linked to ApplePay must be one to supply ApplePay with valid keys to sign “card present” transactions, does that mean ApplePay had to have agreement with any such issuer bank? Which would limit options about which cards user can link to ApplePay (ie only from those banks that Apple has agreement), but could explain things like Apple being able to update expiration dates and Apple being in loop for transaction fees.
Another question : what is security advantage of using card number tokens that are accepted at any payment device?
Advantage of merchant using tokens to store in its database is that token issuer (acquirer or switch) can prevent any transaction with that token outside of that merchant . In other words, if someone steal ‘tokenized’ card database from Target, only place to buy (using stolen card numbers) would be in Target.
But in ApplePay case, token is given to customer directly, and that same token is expected to be accepted at ANY merchant. So if someone steal that token, he can use it at other places just as he could real card number. Presumably Apple can have some measures to identify device (iPhone) , but is it also part of ‘standard’ EMV token process? And if such device identification is used, would it work too with regular card number?
In other words, it looks like token use by ApplePay offer less security benefits than token use by merchants.
The token/device account number is presumably flagged als “only for NFC use” at the token service provider (i.e. the credit card networks).
Since NFC transactions always include a dynamic value generated using a private key stored in the secure element, which can only be used for signing, but never exported, extracting tokens from iPhones is (hopefully) impossible.
Per-merchant tokens would be more secure, but they would be much harder to use: The secure element, in some cases, doesn’t even know at which merchant a given transaction is taking place; changing that would require (extensive) modifiations to existing merchant infrastructure, which would defeat the purpose of using existing protocols.
Hi @nenea, @lukas,
Excellent posts – thanks.
I think you’ve pretty much summarised it by yourselves so just a few quick points:
1) Apple has now published quite some detail about how it actually works – https://www.apple.com/privacy/docs/iOS_Security_Guide_Oct_2014.pdf (page 24 or so onwards)
2) I *think* the relevant key material needed to get EMV to work at POS (over NFC) is associated with the card network… so I expect it is provisioned down to the phone at time of enrollment… but I could well be wrong here.
3) Regardless, it does appear from the press that Apple is signing deals with issuers… i.e. there is a relationship between Apple and issuers on its platform so the mechanism would, in principle, exist for them to get hold of any key material they needed
4) Additional complexity/confusion comes from the fact that 1) the EMVCo tokenisation spec allows certain functions to be performed by either the scheme or the issuer, 2) many issuers either outsource their processing and/or are taking services from the schemes — so the lines are very blurred.
5) Thank you for raising this… I deliberately glossed over the whole EMV POS security side of things when I wrote this post as it wasn’t clear to me at the time how they were doing it… their recent document publication – above – plus twitter conversations with people who know more about this than me make me think the discussions in these comments are pretty close to the reality.
Apple gave NFC (near-field communication) a long-awaited stamp of approval when it announced Apple Pay, the company’s new, proprietary mobile wallet app. The app is now available on NFC-enabled iPhone 6 and 6 Plus, two iPad models, and the soon-to-arrive Apple Watch.
So did it turn out that this is what happens? As far as I understand, I’ve just used Apple pay for the first time. I had to give it all my credit card details and it gave them to the shop’s credit card machine. It didn’t seem that Apple had any more involvement in it than they would have if I’d used notepad to write down the card info and then I’d read it back. It’s great of course because it has the finger print security on the info and the nfc to save me reading it out and making errors in translation but the role of the credit card company etc remain the same and apple don’t actually become a financial services company.
@samjgarforth — yes… the role of the card companies, networks, acquirers, etc., remains unchanged pretty much. Apple Pay is doing more than just storing your card number but that’s certainly the right mental model to use when thinking about how it all fits together.
Hello @Richard,
This is so wonderful post. Actually i was also looking for how Apple Pay exactly works and suddenly i reach out your article which is amazing and greatly helped me a lot. Thanks for this helpful information.
Thanks again.