Apple Pay vs Google Wallet : The Secure Element

Note: You can read all articles in this series by visiting the Table of Contents

Both Google Wallet and ApplePay are trying to solve the same set of problems – mobile payments at the physical POS and inside apps. They have many characteristics that are very similar, but they also differ in significant ways when it comes to implementation and user experience. In this series of blog posts, we will analyze a few similarities and differences one by one. We will start by talking about the Secure Element today.

A Secure Element (SE) securely stores card/cardholder data and does cryptographic processing. During a payment transaction it emulates a contactless card using industry standard protocols to help authorize a transaction. The Secure Element could either be embedded in the phone or embedded in your network operator’s SIM card. We will generically refer to them as device-based Secure Element. More recently, with the introduction of HCE technology by Google, the definition of Secure Element has been expanded to include a secure cloud as well. We will refer to them as cloud-based Secure Element.

In the beginning, Google Wallet v1.0 started its journey by using the device-based Secure Element for card emulation. This approach didn’t work out well for Google as most of the major network operators (Verizon, AT&T and T-Mobile) decided to support their own brand of wallet called Softcard (previously Isis) and blocked access to the Secure Element for any other wallet providers. Google had no choice but to move on.

se-hce-dual-ce

Today, Google wallet v3.0 does not use a device-based Secure Element. It uses a technology called Host-based card emulation (HCE) instead, where card-emulation and the Secure Element are separated into different areas. For example, in HCE mode, when an NFC enabled Android phone is tapped against a contactless terminal, the NFC controller inside the phone redirects communication from the terminal to the host operating system. Google wallet picks up the request from the host operating system and responds to the communication with a virtual card number and uses industry standard contactless protocols to complete the transaction. This is the card-emulation part. The transaction proceeds and reaches the Google cloud servers where the virtual card number is replaced with real card data and authorized with the real Issuer. Since the real card data is securely stored in Google’s cloud servers, the cloud represents the Secure Element part. In general, this approach is considered less secure compared to the embedded SE approach. But there are some areas (like Lost & Stolen use-case) where it is more secure. We will discuss that in a different post.

NOTE: This doesn’t mean that Android operating system does not support device-based Secure element anymore. In fact it supports both device-based Secure Element and HCE using a routing table at the NFC controller level.

ApplePay, in contrast, works using traditional device-based Secure Element. It does not use HCE technology. Consequently, Apple does not store the real card or token data in their cloud servers at all. The on-device Secure Element essentially performs card-emulation in addition to secure storage. It sends payment data to the contactless terminal when you Tap & Pay. I have attempted to demystify how ApplePay works in one of my previous posts. In many ways it is similar to how Google Wallet v1.0 used to work (with some important differences).

se-ce-iphone

First, ApplePay does not store the real card data inside the SE. This is in direct contrast to Google Wallet 1.0 and Softcard. Instead, they store a token that conforms to EMVCo tokenization specification. It is this token (along with a cryptogram) that gets sent to the contactless terminal. During the authorization flow, the card network identifies the token, de-tokenizes them into real PAN with the help of a Token Service Provider (TSP) and sends the real PAN over to Issuer for authorization.

Second, Apple owns and controls the Secure Element embedded inside the device thereby avoiding unnecessary challenges from the MNOs.

Finally, Apple significantly simplified the provisioning model. If they had to provision the real card details, they would have to depend on a complex and convoluted process. Fortunately, they provision a token instead and took the opportunity to simplify the process to a bare minimum.

In the next post, we will discuss how these two services differ when the device is lost or stolen.

Related Reading:

 
 
Apple Pay – An attempt to demystify
 
 
jCarouselLite version 1.1 released !

Ganeshji Marwaha

I spend my days as the Director of Technology for Mobility practice and help my clients design enterprise and consumer mobile strategies. Mobile Payments, Digital Wallet and Tokenization technologies are my areas of specialization

  • Pingback: Apple Pay vs Google Wallet : The Secure Element | Patrick Bouillaud Blog()

  • Connor Poole

    You don’t offer pros and cons of using an embedded SE vs a UICC (sim card SE) vs HCE (cloud based). Any input here would be much appreciated; I have assembled below what basic pro’s and cons I can think of.

    embedded SE:

    Pros:
    – Not at the mercy of the cell providers sim card
    – Works without an internet connection
    – The tokenized LUK for the card information is never transmitted nor stored anywhere else
    Cons:
    – Every device has a different hardware configuration, the embedded SE approach is not very standardized. As such, a flaw in interfacing with the embedded SE (a hardware flaw) could introduce security concerns?
    – Fixed storage and fixed capabilities for the life of the device

    UICC:
    Pros:
    – Works without an internet connection
    – The tokenized LUK for the card information is never transmitted nor stored anywhere else
    – Sim is upgradable if new security standard is released
    Cons:
    – Cellular providers can block a phone from using the UICC as they distribute the sim card
    – Easier to remove a sim than to tap the traces for an embedded SE

    HCE:
    Pros:
    – Freedom from carriers
    – Cheaper, no additional hardware
    – tokenized LUK is never on device so if device is stolen there is 0 chance of it being recovered
    Cons:
    – Tokenized LUK is in the cloud and susceptible to server security and transmission security
    – The kernel handles the LUK transmission, a bad kernel could open security flaws
    – Requires internet connection to work???

  • Connor Poole

    The real question is why didnt google (and microsoft) simply use embedded SE when they first announced their payment systems in 2012? And why arent they doing it now, it just seems so much easier.

  • Thank you for the comment Connor Poole. I agree with your idea of providing the differences between different SEs. But, that post was specifically targetted towards explaining where the Secure Element is located when using Apple Pay and Google Wallet. It does make for another interesting blog post to address the differences between all types of SEs though. In fact, I am sure such a post will be an open ground for feedback as one person may not be able to collate all pros and cons. Your list is a very good starting point.

  • Google Wallet’s first version supported both embedded SE and SIM based SE. Regardless of whether the SE was embedded or SIM based, the carriers (Verizon, AT&T and T-Mobile) did not allow Google Wallet to work in their network because they were busy promoting their own brand of mobile wallet – ISIS (Softcard). They held the keys to the kingdom by holding onto the Issuer Domain Key for the Secure Element.

    This was possible for them because, unlike Apple, Google was not the phone hardware manufacturer. Moreover, the contract between the MNOs (Mobile Network Operators) and phone manufacturers allowed MNOs such control.

    In the case of Apple, Apple controls the key to the issuer security domain on the SE. They manufacture the hardware, MNOs do not have access to customize their software and most importantly, their contract with MNOs do not allow such control. That is the reason why the whole concept of embedded SE becomes so easy for Apple while it is such a pain for Google.

  • Connor Poole

    I’m confused when you say the MNOs held the Issuer Domain Keys for the Secure Element… I see this being true for a UICC implementation (the MNOs distribute the SIMs), but I don’t see why this would be true for an embedded solution. Am I missing something here? Or is the real reason behind all of this simply that the MNO would not allow phones to operate on their network if they had their own manufacturer included embedded SE?

    Also do you have any more references for the Issuer Domain Key? I’d like to read up on that… is it similar to CA certificates for the web?

  • Hi Connor, The MNOs hold control of the phone’e embedded Secure Element as well. That is how typical contracts between phone manufacturers and MNOs are structured. That is the reason why, although Google Nexus phones had embedded SEs were still unable to work with Google Wallet on the 3 major MNOs. Hope that clears your confusion.

    Regarding, Issuer Domain Keys, i would recommend reading whitepapers and articles from smartcardalliance.org

  • Connor Poole

    Ganeshji, Sorry for the delayed response. Do you have any sources for the MNO’s controlling the embedded Secure Element?

    Thanks for all your help understanding this

  • nickdanny

    good post..v nice.
    Mont
    blanc pens

    http://www.williampenn.net/brand/montblanc

  • Thank you my precious friend. You helping me understand the process. I am very grateful to you for your taking the time to demystify the prodigal with me.

  • You can use Samsung so security is perfect..
    promosyon canta

  • Bestcanta Promosyon

    thank you.