With the latest update of iOS, Apple has started following a rather ‘intrusive’ policy in getting their customers on board their Apple Pay platform. Apple hopes to bring its current $28B Apple Pay business to $40B by the end of fiscal year 2020. A recent study reveals that digital payments are expected to hit $726B by 2020. Although a majority of Americans still prefer carrying the good old stash of cash, with more and more options available for making the switch to digital payments easier, the adoption of cashless transactions is on a steady rise.
In 2008, Apple took the mobile industry by surprise with a patent application that talked about the use of a fingerprint sensor embedded into a mobile device which could be used for authentication purposes. It was speculated at that time that this would revolutionize the way with interact with and use our gadgets, and there would be no better time than now to validate this statement. Apple’s Touch ID fueled the foundation of Apple Pay. The first and foremost challenge to get people to use an ‘app’ for payments is to promise security. To implement it, Apple needed something literally out of the box. It wasn’t possible to achieve this level of security with a software-only solution, and hence Apple created the Secure Enclave.
Secure Enclave is a co-processor fabricated into Apple T1, S2, S3, A7 and later processors. It uses encrypted memory and includes a hardware random number generator. It is the heart of Apple’s security system which enables the secure use of Apple Pay. The security architecture in Secure Enclave is rock solid, mostly because it is hardware-based. It would require a huge amount of hardware-level penetration to even attempt to access the data encrypted and stored within the Secure Enclave.
Apple talks about its now well-known Apple Pay in a US patent application that dates back to 2008. The invention that Apple disclosed back then outlined a wireless peer to peer financial transaction method which used NFC for communication between two devices.
Apple Pay comes built into the core of iOS and enables users to make payments using their existing debit and credit cards via their phone. It uses NFC (Near Field Communication), the same technology used by all contactless payment providers, although Apple does boast a lot about their top-of-the-line security standards, which in theory, should attract more users. The main component of Apple Pay is the Secure Element. It is a certified chip running the Java Card platform and complies with financial industry requirements for electronic payments. During an NFC transaction, the data routed using a dedicated hardware bus between the NFC controller and the Secure Element. No data is transferred through the application processor, hence making the system secure. Even when the data must go through the application processor (for example, for in-app purchases, online shopping etc.) the data is encrypted by the Secure Element and then routed to the application processor for payment authorization at the point of sale.
Apple Pay in itself is not a payment provider. It only acts as a gateway between your bank/card issuer and the merchant with whom you wish to transact. Credit/Debit/Prepaid cards can be added to your Apple Pay in order to make seamless payments. The beauty of the ecosystem is that full card numbers are never stored. Not even on Apple servers or on the device. Instead, a Device Account Number is created, encrypted and stored in the Secure Element. This is a unique number for all your cards and payment methods and is never sent to the cloud. It always remains encrypted inside the Secure Element. Another US patent application by Apple hints at the above discussed method of using a Device Account Number (a non-native credential, as discussed in the patent) for authorizing a payment between a merchant and a host device.
Cards can be added to Apple Pay either manually, from iTunes account or from the card issuer’s app. For adding a card manually, the card number, expiration date and CVV are used. The CVV is verified at the Apple Pay servers.
Anytime a user wishes to make a payment, at either an NFC enabled Point of Sale, or in an online transaction, it must be authorized by the user, at his own device. This can be done by using either Face ID (facial recognition on iPhone X), Touch ID (fingerprint recognition on previous iPhones) or passcode verification, if the former are not available. On Apple Watch, a double tap on the side button enables payments after unlocking the device by entering a passcode. The authentication process occurs entirely at the Secure Enclave, so the NFC controller can be alerted about the authorization directly, without the involvement of the application processor.
For added security, along with the Device Account Number which is stored in the Secure Element, a transaction specific dynamic security code is also stored. This one time code is computed from a counter which is incremented for each new transaction, and a key provisioned in the payment applet during personalization and is known by the card issuer/bank. Hence, whenever a contactless payment is attempted, the Device Account Number and the transaction-specific dynamic security code are used when processing the payment. The card number or other card details are never transmitted.
For in-app purchases, an API is used to determine whether the device supports Apple Pay or not. Upon confirmation of availability, the app requests from iOS the Apple Pay Sheet, which requests information for the app, as well as other necessary information such as which card to use. The information is provided to the app once the payment attempt is authorized by the user using Face ID/Touch ID/Passcode. A similar process is followed when paying on the web. An Apple provided TLS certificate is used to prove the authenticity of the website, and the entire transaction takes place over HTTPS. Once the merchant is validated and Apple Pay support is confirmed at the user’s end, the process of authorization can take place the same way as it does in the case of in-app purchases.
Another very attractive feature that Apple Pay has to offer is the Apple Pay Cash. This allows a user to send/receive money to and from other Apple users. Green Dot Bank and Apple Payments Inc. together bring this feature to life. Money requests and transfers can even be initiated using iMessage or even Siri, Apple’s digital personal assistant. Your Apple Pay Cash is essentially your own digital wallet. It stores cash in itself, which can be directly used for making payments, or sending money to other users. When the user sends money with Apple Pay, adds money to an Apple Pay Cash account, or transfers money to a bank account, a call is made to the Apple Pay Servers to obtain a cryptographic nonce, which is similar to the value returned for Apple Pay within apps. The nonce, along with other transaction data, is passed to the Secure Element to generate a payment signature. When the payment signature comes out of the Secure Element, it’s passed to the Apple Pay Servers. The authentication, integrity, and correctness of the transaction is verified via the payment signature and the nonce by Apple Pay Servers. Money transfer is then initiated and the user is notified of transaction completion.
Huge data breaches containing credit card numbers of millions of users have been hitting the headlines multiple times every year for the past decade. While all this is going on, the approach used by Apple to not even store credit card details of users might just be THE solution for avoiding even more potential losses. Apple has avoided any security infiltration so far, which does give its users a sense of trust and allows them to freely use Apple’s services by providing their sensitive information. The big question is, can (or will) the financial industry move towards implementing the backbone approach of Apple Pay as the default process for consumer transactions – or will it remain proprietary to the Apple ecosystem?
References
Rahul is a seasoned IP Professional with 10 years of experience working closely with senior litigators on patent infringement and trade secret misappropriation. Rahul has a Bachelor's degree in Electrical Engineering from Indian Institute of Technology (IIT) Delhi and is a certified Project Management Professional (PMP). He has advised clients on more than 100 technology cases cumulatively resulting in over $1 billion in settlements and verdicts, including cases where he has testified at deposition or through expert reports.