See previous posts in this series:
Pay Technology: The Secure Enclave Processor
Pay - Tokenization for Security
This time we are looking at a patent application, not a patent. Depending on what happens at the United States Patent and Trademark Office, this may or may not eventually mature into an issued patent. Because it's only an application, the claims at the end of the patent may end up looking very different by the time the patent issues. For that reason we'll deemphasize the analysis of whether or not competitors will be able to easily compete with this technology.
The title of this patent amplification provides good insight into Apple's focus: "Method to Send Payment Data Through Various air Interfaces Without Compromising User Data."
Pay Technology: The Secure Enclave Processor. The portable device also includes an application processor (here labeled with number 104) that executes applications. In other words, a CPU, like the A8 ARM cores. This particular device also contains three "air interfaces," namely WiFi, Bluetooth, and NFC, as indicated by numbers 110, 112, and 114 respectively. The NFC interface, in particular, is shown in green.
The portable device can make purchases by using the NFC interface to establish a secure link to the point of sale device (shown in yellow, and usually abbreviated as "POS.")
The patent specification suggests that the other air interfaces may be used as well, for the exchange of additional information like special offers, coupons, and the like. These other interfaces are advantageous over NFC because they allow faster data transmission and you don't have to hold the device so close (3-6 cm) to the POS while the transfer is progressing. The patent envisions using NFC for an initial "bump" to establish the initial connection and set up a second link, then using other protocols for maintaining the second link over time.
FIG. 2 provides more detail of the transaction handshaking.
In FIG. 2, the WiFi or Bluetooth interfaces (110 or 112) are used after a secure link is established using NFC (114). The patent suggests that, for example, the WiFi interface may be used to transmit the purchase information while the slower, NFC interface can be used for things like coupon offers, receipts, and so on.
The Secure Element (108) passes encrypted credit card data (206) to the application processor (104). The boxes on the bottom, 106 and 206, show the difference between plaintext credit card data (106) and encrypted credit card data (206). Note that the information that would actually be a problem if intercepted is all in box 106, and this information is not stored in the secure element.
As explained by the application text, the confidentiality of data sent to the application processor may be compromised by a rogue app. The credit card data 106 is encrypted by the secure element, which produces the encrypted version (206) as a result.
Looking more closely at the encrypted credit card data, it is composed of several parts. The "alias" (shown in green) is an identifier associated with the credit card data, but it cannot be used to make a payment without valid crypto data that corresponds to the alias. Thus the alias need not be a secret. Payments made with the alias are not accepted unless the crypto data (shown in yellow) is also supplied. The alias may be thought of as a "token" of the sort discussed here: Pay - Tokenization for Security.
There are several possible ways of generating the crypto data (shown in yellow). The general idea is it is a cryptographic hash of the alias and some other values (for example cryptographic salt, a merchant identifier, a counter, or any other important information). If someone offers payment by sending an alias and crypto data, the bank needs to decrypt the crypt data and compare the information in it to the alias to see if they match. (Alternately, the bank may instead encrypt the alias and the other data and compare the resulting crypto data to the data it receives from the purchaser via the POS). The "shared secret" (orange) refers to a cryptographic key that is known both by the device and by the back end (i.e. bank) but by no one else. This shared secret can be established at the time the credit card is "loaded" onto the device using the techniques described here: Pay - Tokenization for Security.
If the information matches, then the purchase is approved.
ConclusionThe bulk of the claims, and much of the explanation in the application, refer to the idea of using NFC to establish another type of link, and then using the other type of link to perform the transfer of payment information. This could mean using NFC to exchange information sufficient to establish a WiFi or bluetooth connection to the POS terminal, or to establish a connection over some other network back to the bank.
As such, it's unlikely Pay will rely on such a technique. The available infrastructure will generally involve just NFC, not NFC + something else. Of course, Apple may choose to use a system like the one described in the patent application in its own stores, and other retailers may do something like this as well, but the focus of this invention seems to involve things that are not critical to the operation of Pay.
Nonetheless, as described above, the details of the transaction, ignoring the air interfaces, is probably pretty close to how Pay works, so this patent application provides some useful information.
Post a Comment