1. How does "Express Mode" work?
"Express Mode" is using the NFC "card" without any smarts from the phone, which is why it works when the phone itself doesn't have power. This is also why "transit cards" work in Express Mode because they are just NFC cards, but with a different "app" on the card that supports different processes than an EMV "credit/debit" card. EMV cards are probably the "dumbest" smart cards out there.
So effectively, it is exactly like using a physical NFC card. The NFC field powers the card. The "card" in the wallet only has the DPAN, the CPAN is not stored or used at all after the card is "enrolled".
2. Online enquiries with my "real" CPAN?
In terms of that online enquiry where you are typing the CPAN into the website, under PCI rules, they are not allowed to see the CPAN outside of PCI scope, which has strict rules on how that information is stored and used.
They usually use a "transit acquirer" to process their EMV transactions. What this acquirer does is that it processes the EMV taps under PCI rules, but also provides the transit provider with: a) a "one way hash" of the card. This is unique to the CPAN, but unable to be reversed back to be the CPAN. b) the transit information related to the tap (eg station of entry/exit etc) c) the transit provider can store trip information against the one way hash.
So when you type in the full CPAN on the transit provider's website, that is securely (ie iframes and the like) sent to the acquirer, which sends back the one way hash. The same hash is used to identify the trips that the transit provider keeps info about.
So they aren't "seeing" the CPAN (at least if their PCI auditor is doing their job properly). What they "see" is the one way hash that they can use in their system.
It makes sense that hashing allows the transit provider to link the CPAN to the taps.
Having checked, the CPAN is not inputted via an iframe on the transit provider’s site - it’s sent via https, but directly to the site’s web host. Is that necessarily non PCI compliant (or only non compliant if they store it - which they might not)? Are there PCI bounties..?
My bigger problem with all of this is that someone who comes in temporary contact with a credit card can get that person’s transit history. Is that not a security risk?
You shouldn't be able to see anything about the DPANs except the 6+4 information though and perhaps some detail of which device it is on.
Transit providers are not allowed to use the EMV card purely as "identification".
I answered elsewhere on the thread about how the transit provider is able to use the EMV as an identifier after it has been used for payment, with a one way hash sent to the transit provider.
Specifically: there’s a transit org (I’ve tried to reach them about this issue, to no avail) that lets you enter your (real, CPAN) credit card number on their public web site and get back your “own” (if it happens to be your card…) transit history i.e. the times when you tapped your iPhone/Android on their NFC/tap enabled turnstiles.
So, they /do/ seem to have a way to either get the CPAN when the card is tapped, or maybe they can tokenize the CPAN in the same way as the phone and then compare the tokens…?
I thought that could not be possible but it 100% works. To me it’s a huge security problem. But again, I have not heard back from them at all.
Do you understand how they do it? Thanks
[0] https://support.apple.com/en-us/HT212171