Apple, Google & Samsung Pay (+ Wearables) don't store you card details
======================================================================

From time to time I have heard people talk about the potential for
credit/debit card details being leaked on mobile payment devices and
wearables. Now I am not expert but from the little (high level)
understanding I have of this process, that cannot actually happen.
Common mobile payment systems and contactless wearables (like a
payment ring, keychain/fob or watch) don't even have the "real" card
details and they don't need them! This is because the entire system is
based on "tokens".

Rather than your actual card number (a.k.a. "Primary Account Number"
or "PAN") they have a payment token in its place. This token is often
called a "Device Account Number" (DAN) or "Device Primary Account
number" (DPAN). If you were to gain access to it, it might look like a
normal card number but it isn't and how it can be used is quite
different compared with the PAN. You are not going to type it into a
website and buy stuff online or encode it on a magnetic strip and use
it in a store. Both would simply fail because it is not like a normal
credit/debit card number.

A good comparison would be physical tokens in the real world. At many
fairgrounds, theme parks or arcades you can trade your real money for
tokens which can be used as payment, but these tokens are limited in
that you can only use them within the designated environment. This
(somewhat) diminishes the value to a thief.

The main limitation of a DAN is that it is no good on its own, it must
be combined with a  single use, unique number. Sometimes these are
called a dynamic cryptogram[1]. In addition to being single use, the
number will only be usable with the current merchant.

These dynamic cryptograms can only be generated by your device or a
Token Service Provider (TSP), who are further up the financial chain
than the mere merchant you are dealing with directly. Your device and
the TSP have some extra data, that is never received by the merchant
(or stored by anyone else) and it is certainly never exposed over the
contactless connection. It is yet another token, the payment token
key. This key is also often also referred to as a cryptogram but I
will call it a key here for simplicity and to avoid confusing it with
the dynamic kind.

Your device uses data about the transaction (e.g. the id of the
merchant you are buying from, time stamp, price of transaction, etc.)
and combines this with information the device has such as the DAN,
expiry date and the payment token "key". With a bit of calculation it
ends up with that dynamic cryptogram. Since some of the data varies
(merchant, price, timestamp, etc.) that dynamic cryptogram is always
different. The unknown parts (especially your key) however make it
impossible for anyone without this knowledge to calculate it.

Once done, the DAN (along with its expiry date) and the dynamic
cryptogram can be passed to the merchant. Upstream in the payment
processing, the TSP will eventually receive this. The TSP has enough
information to perform the calculation again, since it receives the
merchant id, price, time stamp, DAN, expiry date, etc. and it already
knows the the payment token key associated with your DAN. If its
calculation results in the same dynamic cryptogram then it can be
certain that your device authorised the transaction (since nobody else
should know it). The TSP also knows something your device does not,
your real card number (PAN), which it also has stored in its database
and associated with your DAN. This PAN can now be used to actually
charge you.

To reiterate the DAN is useless for payment without an appropriate
dynamic cryptogram, and a potential bad actor cannot work out a valid
one because they do not have the payment token key needed for
generation. Even if they intercepted the payment early on and tried to
reuse it, it is tied to a particular merchant because the merchant id
was part of the data set used for the dynamic cryptogram's generation.
More importantly, the TSP would reject a reused number anyway because
it is designed to be single use and it was already used!

P.S. Now of course, if the bad actor gets access to your actual device
and can authenticate, then yes they could use these details just as
you can. My point here however is that copying (all) the details off
the device to use them elsewhere is far from straightforward and your
PAN is not even there in the first place.

* * *

[1] Dependent on the merchant's equipment a dynamic "card verification
value" (CVV) might be used instead of the dynamic cryptogram. They are
generated and are used in a similar way, so I just stick with the term
dynamic cryptogram for the rest of the explanation.

~ Here's How Google Pay, Apple Pay & Samsung Pay Protect Your Card
 Details:
https://www.advantio.com/blog/heres-how-google-pay-apple-pay-samsung-pay-protect-your-card-details

~ How Apple Pay Works Under the Hood [FreeCodeCamp]:
https://www.freecodecamp.org/news/how-apple-pay-works-under-the-hood-8c3978238324/

~ How Apple Pay works under the hood [Codeburst]:
https://codeburst.io/how-does-apple-pay-actually-work-f52f7d9348b7

* * *

You are viewing proxied material from sdf.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.