Pay - Tokenization for Security

Apple's new payment system, Pay, incorporates numerous technologies to improve security.  As someone who's had to try and remember all of his credit-card autopay's and go through them one-by-one to update account information - twice in a year - due to theft of credit card information from various retailers, I appreciate this.  Contrary to a dumb article at the New York Times (no link to dumbness), part of the cost of security breaches is born by the consumer, in the time and energy spent dealing with the aftermath.

One of the techniques used in Pay is "one time tokens."

What's that?



Well, Apple's U.S. Patent No. 8,468,580 may be instructive.  This patent has been referenced by many a Mac blogger in talking about Pay, but apparently none of them read it.  The title of this patent is "Secure Communication Between Trusted Parties."  In cryptography, "security" refers to one or more of several concepts.  A "secure" communication is one that can't be modified without detection, and which can't be intercepted and understood by anyone other than the intended party.  "Trust" in cryptography refer to authentication of identity; a party is "trusted" if his or her identity is assured.


Reading through the summary of the invention is instructive.

The present disclosure relates to providing communication between trusted parties. For example, a trust relationship may exist when two parties have an existing and verifiable relationship, such as where a user's account or other information is stored on an electronic device based upon a prior approval granted by an institution associated with the account, e.g., an account issuer. 

The "electronic device," of course, is an iPhone or Watch.  The "user" is you.  The "user's account" is your credit card account.  The "institution" is the financial institution that issued your credit card.

In such an example, a third party with an existing relationship with both the account holder and the account issuer may facilitate establishment of the trust relationship. In particular, a third party may serve as an intermediary to establish the identity of each party during the process of storing the account information on the electronic device and acquiring the initial approval for such storage.

The "third party" is Apple.  It "acquires the initial approval" during the process where you add your credit card information to the device via the Passbook app.

Once the parties' identities are established, such as once the account holders' account information is stored on an electronic device, communications between the electronic device and account issuer may be streamlined in view of the existing relationship between the electronic device and the account issuer. In particular, communications made between the electronic device and the account issuer may be deemed trusted so that a user of the electronic device, such as the account holder, can identify the communications as coming from a trusted source, such as the account issuer.

This refers to the general idea of authentication.  Once the information is stored on the device, then the other parties to the credit card transaction can trust that the user of the device is who he or she says he or she is.  The patent explains this:

For example, a user having bank account information stored on an electronic device after approval by the associated bank may be able to ascertain that messages received on the electronic device that allege to be from the bank are actually from the bank. Likewise, messages initiated at the electronic device and sent to the bank (or other appropriate institution) may be trusted at the bank as having come from the owner of the electronic device. In some embodiments, the trust relationship may be leveraged to allow searching or other interactive communications between the trusted parties.

The patent specification then goes on to describe how the invention works.  Fig. 4 of the patent is instructive:

Note that each box has an associate number.  In walking through the explanation I'll refer to these.

Loading a Card

First we have the process of loading a credit card onto the iPhone.

Starting with block 60, the user (you) provides account information to be stored on the iPhone.  Among other methods, this can be done by using the iPhone's camera to take a photo of the credit card.

According to this figure, no account information is stored on the device until the phone transmits a request to do so to "a trusted third party."  This would be Apple.  Presumably the request is appropriately encrypted using a public key provided by Apple, as it seems like it would contain sensitive information.  Only Apple, using the private key known only to it, can decrypt the information.

In block 68 the request is received by the third party, which may authenticate the iPhone itself (one way that comes to mind would be if the iPhone digitally signed the request using its own private key) or the user (for example by Touch ID).

Once Apple decides that everything is kosher, it transmits an approval request (block 72) to the issuing entity (the institution that issued you the credit card - a bank, retailer, etc.)

After the issuer receives the request, it evaluates it (block 76) taking into account security concerns (for example, there may be restrictions on the account).  If the issuer approves, it transmits approval message 82 back to Apple (which receives it in block 84).

So far, in other words, we have this:

1. User seeks to load credit card into Passbook
2. Apple receives request to do so, and checks with the credit card issuer.
3. Credit card issuer approves the request, and lets Apple know.

Apple checks the message from the issuer to make sure it's authentic (checking that it's properly digitally signed, etc.)  Then Apple sends a signal (block 88) to the iPhone.  This tells the iPhone that it's okay to store the credit card information in Passbook (block 90).

And that's that.

Making a Payment

The process of loading the card onto the device wasn't that interesting, really.  But the result is that a secure "channel" is effected between the parties.  The following figure shows the process that would correspond to a payment made from the iPhone.

The "Message" (block 152) is the payment request.  This message would presumably contain information like the amount to be paid, the intended recipient of the payment, the date and time, the physical location, and some sort of information identifying the account (though this identification would not be the account number, but rather some unique number from which the account number can be derived by someone having the appropriate key). 

The message would include a "token" - information specific to the iPhone that can be used to authenticate the message as being from that particular iPhone (or from that particular user).  This "token" presumably was stored on the iPhone at the time the card was loaded.  

This authentication takes place in block 154.  It also involves checking that the account being accessed is in fact authorized for use with that particular iPhone - block 156 includes the information necessary to verify that the token is correct (it's a database, essentially).  Presumably this database also includes the information necessary to derive the actual account number from the token.

Assuming everything is right, the issuing entity can process the message (i.e. implement the payment) in block 158.  

So what's going on here?  First, the iPhone never has to hold onto the actual credit card information.  It needs only a "token" - a code that is worthless to anyone who steals it because it is tied to the device and cannot be used with any other iPhone or device.  Apple has also said it uses "one time" tokens. 

What's probably going on here is that the "token" that is stored on the iPhone when the card is "loaded" is a "seed."  Each time a payment message is sent, a new token is derived from the previous token, and is used only once.  So we have: original token → token 0 → token 1 → token 2.  Each token is derived from the previous one.  This is often done by essentially encrypting the prior token with the same key, over and over, to produce what looks like a series of random numbers.  The bank also knows the same key, and so it can calculate whether the token is the proper token.  Without the key, it's almost impossible to guess what token comes next in the sequence.

Moreover, old tokens can't be reused.  In other words, once I've paid for something using token 1, I can't do it again.  There are multiple ways to accomplish this - there could be a central database or authority that keeps track of where the device is in the sequence of tokens, for example.

If someone intercepts the message during transmission from the device, all they can do with it is use it to perform the exact transaction the user is trying to perform.  It's worthless for any other purpose, and the transaction can only be done once.

Implications

One question is whether Apple now has a monopoly on this kind of scheme, and can prevent (via patent law) its competitors in the payment space from doing something similar.  When interpreting a patent to determine whether some product or service infringes it, you focus on what are called the  patent "claims."  The claims are like a fence; anything inside the fence is protected from infringement, and anything outside the fence is fair game for your competitors.

One infringes a patent if one performs every step of any claim listed in the patent.  So let's look at claim number 1:

1. A method of communicating between two parties, comprising:

requesting, by an approving entity prior to communication with a device, an initial authorization from a third party authorization entity;

receiving, by the approving entity prior to communication with the device, an initial authorization received from the third party authorization entity, the third party identification being based on a third-party identification of the device as being associated with an account holder and a recognition of one or more hardware components of the device;

receiving a message generated by the device after the initial authorization request, wherein the message includes the identification of the at least one hardware component, and wherein the message pertains to an account associated with the account holder; and 

authenticating the message based upon the initial authorization that the device is authorized to store information related to the account and the identification of the at least one hardware component. 

A lot depends on the exact definition of each word in the claim, which is determined in light of the description in the patent and various other factors, but the claim seems to cover a lot of potential territory.  It appears that one key to the claims is that the "approving entity" (i.e. Apple) can't be involved in identifying that the device goes with the account (i.e. Apple really doesn't want to know who is buying what).  This is made more clear in other claims that refer to the identifying taking place "without commercial entity involvement" (in those claims the term "commercial entity" is used in place of "approving entity.")    If this interpretation is correct then one work-around that would allow competitors to use a similar system would be if the payment service operator (pay pal or google or amazon or whoever) did get involved with checking that the device and the account go together.  Presumably this could be a competitive disadvantage as Apple is marketing Pay by pointing out that Apple receives none of your personal information.