[tonyb]

The part I'm not quite following is when the tokenization takes place.

If it takes place per transaction then the PAN must be saved in the phone somewhere and the phone would have to be online to do the tokenization in real-time.

If it is a one-time tokenization that happens when the card is added isn't that token just as valulable as the PAN since the token can be used across merchants? Maybe the 3-D secure piece of the puzzle protects the token but I think this still means the phone has to be on-line to use the NFC payment feature.

[drewcrawford]

My understanding is that this operates on basically the same principle as RSA SecureID. You have an unlimited-use token stored in a dedicated chip, that for all practical purposes is impossible to access, short of, let's say, a scanning electron microscope.

That chip, with its unlimited-use token then generates one-time tokens which are sent over the payment network.

In theory the chip could issue an arbitrary number of tokens if criminals got ahold of it. But in practice, it stores a little bit of the data it needs to make a token in the neighboring TouchID chip, which operates on essentially the same principle (stores fingerprint data and missing payment data in secure hardware location, only lets it out if fingerprint sensor looks good).

To summarize you have to steal both the phone (or both chips anyway) plus the fingerprint information so the chips are useful. But wait, you say--I did steal the fingerprint data! The user left fingerprints on the back of the phone!

Well, you've got me there. But hopefully by the time your very sophisticated gang of gloved thieves has bagged and dusted your phone for prints, you've made your way to iCloud.com and revoked the phone's forever-time token, so all future one-time tokens will be considered invalid.

Keep in mind, the standard being replaced here is one where you carry all your payment information around in your pocket in plaintext. This scheme is a massive improvement on that. There's an old saying that seems relevant here: I don't have to outrun the bear, I have to outrun you. There's tremendous amount of value in being marginally safer than the next guy.

[debt]

I would think compromise of the token, while bad, is way less bad than compromise of the PAN. I would think it's much easier to regenerate the one-time token than to create a new PAN.

[iknowthisstuff]

The token seems to be generated randomly (per transaction) in the Secure Element. See my above post.

[tonyb]

I don't think that is quite correct. There is per-transaction stuff going on but it isn't being tokenized for every transaction.

The token is stored in the secure element but is generated by the Token Service Provider (for example Visa Token Service).

After reading the EVM token spec linked in the post[1] and the developer guide I think I'm able to answer my own question.

The card is only tokenized once (or at least not per-transaction). For in-app purchases it is using 3-D Secure and for NFC is it using EMV, both of which provide some per-transaction security. Unlike a standard card the token will only work with 3-D Secure or EMV. For example a standard Chip&Pin card could still have it's mag-strip data extracted by a malicious POS system and used at a merchant that only uses magstripe terminals. With Apple Pay (and any other network token based system) a copied token would be worthless because it can't be used at a magstripe terminal.

Basically the phone is acting both as an automated 3-D secure checkout (it is processed by the processors just like 3-D secure but the authentication process is automated) and as a contactless EMV card without the downside of also having a magstrip with the PAN on it.

[1]http://www.emvco.com/specifications.aspx?id=263