{"id":1326,"date":"2015-01-03T17:07:06","date_gmt":"2015-01-03T17:07:06","guid":{"rendered":"http:\/\/www.gmarwaha.com\/blog\/?p=1326"},"modified":"2015-01-03T17:14:51","modified_gmt":"2015-01-03T17:14:51","slug":"apple-pay-an-attempt-to-demystify-take-2","status":"publish","type":"post","link":"https:\/\/www.gmarwaha.com\/blog\/2015\/01\/03\/apple-pay-an-attempt-to-demystify-take-2\/","title":{"rendered":"Apple Pay – An attempt to demystify – Take 2"},"content":{"rendered":"

Earlier, a couple of months ago, I attempted to demystify ApplePay<\/a> in this blog post<\/a>. Those were the\u00a0early days when most of us didn’t have access to enough\u00a0information on its inner workings. Even with such limited information,\u00a0many parts of the post<\/a> turned out to be correct, but some turned out to be wrong too.\u00a0Today, with access to more information, I am making a second attempt\u00a0at demystifying ApplePay. This post is primarily a rehash of the original with only the relevant parts changed. Let’s get on with the article now…<\/p>\n

When Apple announced ApplePay<\/a> as a service on September 9th, 2014 and subsequently in their press release<\/a>, they mentioned a few key terms like Secure Element<\/a>, Tokens, One time unique number, Device account number, dynamic security code and such. Take a look at the 4th paragraph in their press release<\/a> to see what I\u00a0mean. For the layman, this could mean that apple has used\u00a0some complex\u00a0security technology to make ApplePay secure; but for some people in the field of mobile payments and security, it was not very clear what Apple was trying to say. So, let\u2019s try and dissect that, shall we?<\/p>\n

For simplicity, we are only going to discuss about ApplePay in the context of a payment made at a physical POS<\/a>\u00a0and not the mCommerce version of the service. This is only an educated attempt to understand the underlying implementation while the reality could well, be different.<\/p>\n

Let\u2019s start with the Secure Element<\/a> (SE). ApplePay stores the payment credentials inside the SE<\/a>. It does not store them in the cloud and it does not store them within the host operating system. This means that none of the iOS apps will have access to the payment information stored within the SE<\/a>.<\/p>\n

What exactly is stored in the SE?<\/h4>\n

When, you as a customer add a credit card to your Passbook (Mobile Wallet<\/a>), the simplest thing for the wallet to do would be to store the real payment credentials like the Primary\u00a0Account Number (PAN) into the SE<\/a>. But that is a naive implementation and Apple does not do that. ApplePay instead stores something called a token and some associated data inside the Secure Element<\/a>.<\/p>\n

What is a token?<\/h4>\n

Token is like a fake credit card number that looks and feels like a credit card number for most intents and purposes, but it is not the real deal. During transaction authorization the token would be de-tokenized<\/code> into the real PAN<\/a>\u00a0before passing\u00a0on to the Issuer<\/a> for authorization. The entity that places a request to de-tokenize<\/code> differs depending on the tokenization standard used. In proprietary tokenization technologies, an Acquirer<\/a> would be responsible for tokenization<\/code> and de-tokenization<\/code>. But,\u00a0ApplePay uses the latest in tokenization standard<\/a> created by EMVCo<\/a>. In this case, the payment network<\/a> performs de-tokenization<\/code>.<\/p>\n

How is a token provisioned to the SE?<\/h4>\n

Now that we know that a Token is stored in the SE<\/a>, the next step is to find out how it gets provisioned there in the first place.\u00a0There are many ways in which this could have been implemented and we will not know for sure until Apple announces its implementation. But, here is an educated guess I would go with…<\/p>\n

When a customer adds a credit card to their wallet, the PAN<\/a>\u00a0details are submitted to ApplePay servers. ApplePay sends the information over to the appropriate payment network<\/a> (Visa, Master Card or AMEX) asking for a Token in return. In this scheme of things, the payment network is said to play the role of a Token Service Provider (TSP) while ApplePay plays the role of a Token Requestor (TR).<\/p>\n

The TSP<\/a>\u00a0in turn requests the appropriate card Issuer<\/a> to perform Identification & Verification (ID&V) and\/or out of band validation\u00a0(OOB) to verify if the card is valid, if it is in good standing and if the request is originating\u00a0from an authentic customer. After receiving a successful response from the Issuer<\/a>, the\u00a0TSP<\/a>\u00a0vaults the PAN<\/a>, generates and maps it to a token and returns the token and a token-key back to ApplePay’s server. This token-key will later be used to generate a dynamic cryptogram<\/code> at the SE<\/a>. ApplePay, acting as its own Trusted Service Manager (TSM) provisions the token, token-key and maybe other data into the Secure Element<\/a>. It is the Token that Apple calls as “Device Account Number” in its press release<\/a>.<\/p>\n

What happens when a\u00a0payment transaction is initiated?<\/h4>\n

When a customer taps or waves their iPhone in front of a point of sale terminal, a payment transaction is initiated. ApplePay uses EMVCo\u2019s Contactless<\/a> suite of specifications to communicate with the contactless reader terminal. When it is time for the Secure Element to send information to the terminal, it does a couple of\u00a0things. First, it identifies if the contactless terminal supports EMV Contactless or if it supports only Contactless MSD (for backwards compatibility).<\/p>\n

If it supports EMV<\/a>\u00a0Contactless, the SE<\/a>\u00a0generates a dynamic cryptogram<\/strong> using a combination of\u00a0the token, token-key, transaction amount, transaction counter etc. If the terminal supports only Contactless MSD, it generates a dynamic CVV<\/strong>\u00a0instead,\u00a0using similar data elements like\u00a0token-key and other transactional data. Finally, it passes the token, the dynamic cryptogram\u00a0(or\u00a0the dynamic CVV) and other payment and chip data elements to the terminal in compliance with\u00a0EMV Contactless specification.<\/p>\n

Let\u2019s stop for a moment here and review what just happened and compare that to Apple\u2019s press release<\/a>\u00a0as quoted below.<\/p>\n

“Each transaction is authorized with a one-time unique number<\/strong> using your Device Account Number<\/strong> and instead of using the security code from the back of your card, Apple Pay creates a dynamic security code<\/strong> to securely validate each transaction.\u201d- From the press release<\/p><\/blockquote>\n

From the quote above, the Device Account Number<\/code> represents the Token<\/code>, the One-time Unique Number<\/code> represents the dynamic cryptogram<\/code> and the Dynamic Security Code<\/code> represents the dynamic CVV<\/code>.<\/p>\n

What happens during a payment transaction?<\/h4>\n

The contactless terminal receives the token, dynamic cryptogram (or dynamic CVV) and other data elements according to the contactless EMV<\/a> specification (or contactless MSD for backwards compatibility) and\u00a0sends\u00a0them over to the Acquirer<\/a>. The Acquirer doesn’t know or care if the incoming PAN<\/a>\u00a0is a token\u00a0PAN<\/a>\u00a0or the real PAN<\/a>. They just identifiy the payment network based on the BIN<\/a>\u00a0and send it over the corresponding payment network.<\/p>\n

The payment network<\/a> identifies that it is a tokenized PAN<\/a>\u00a0and not a real PAN<\/a>\u00a0based on BIN<\/a>\u00a0tables. Consequently, they send a request out to the TSP<\/a>\u00a0to de-tokenize passing in the Token, the dynamic cryptogram (or dynamic CVV) and other transaction data elements. The TSP<\/a>\u00a0validates the cryptogram using the token-key that it shared earlier during the provisioning process. It also performs token channel validations and other configured domain control validations. If all the validations came out\u00a0positive, the TSP<\/a>\u00a0de-tokenizes and returns the real PAN<\/a>\u00a0back to the payment network. The payment network attaches the real PAN<\/a>\u00a0to the authorization request and sends it over to Issuer for authorization.<\/p>\n

The Issuer<\/a> authorizes the transaction depending on the customer’s account status. The authorization response\u00a0flows back from Issuer to the Payment network. The payment network removes the real PAN<\/a>\u00a0from the response and attaches token in its place before responding\u00a0back to the Acquirer<\/a> and back to the Merchant<\/a> where your receipt gets printed.<\/p>\n

In conclusion, we saw how ApplePay\u00a0does provisioning and how a payment transaction is processed.\u00a0For some of us this is good enough information to\u00a0understand the security strategy used by ApplePay. But some others may have more questions.\u00a0What happens when the\u00a0Card is lost?\u00a0What\u00a0happens when the phone is lost?\u00a0What happens when the merchant is compromised? How does ApplePay handle these challenges? These are all very good questions, but this post has\u00a0already become too big. So, I will address those follow-up questions in my next post. Stay tuned!<\/p>\n

Related Reading:<\/h4>\n