Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Sorry for the long answer, but there are 2 different questions:

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.



Thank you for your answer, I’m really grateful!

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?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: