4 ms·

A question regarding this - I’ve discovered that using “Express Mode” [0] does allow the transit organization to connect your real credit card to what I assumed

A question regarding this - I’ve discovered that using “Express Mode” [0] does allow the transit organization to connect your real credit card to what I assumed was the tokenized DPAN. How is that possible? 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 https://support.apple.com/en-us/HT212171

aardvark179 4y ago
I’m not sure how they do it but I think it requires a special agreement with the token issuers.
zamnos 4y ago
If you name the transit authority doing this, it'd be possible to look at what the iPhone/Android phone is actually doing. One possibility is the information being shared when using the NFC isn't your CPAN or DPAN at all, but is a 3rd identifier with which they deanonymize you.
- rswail 4y ago
  If you use an EMV card in transit, then the Visa/MC rules say that the same card must be used to pay for the fare. 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.
- _rs 4y ago
  I believe OMNY is one system which operates as OP is describing
kailanb 4y ago
Transport for London does the same. If you add your (real, CPAN) card number to the "Contactless and Oyster" web service, it will also add all of the DPANs you have tapped in with on their network as separate cards.
- rswail 4y ago
  Yes, the DPANs have to be tracked separately so that you use the same device/card to enter as you do to exit. 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.
rswail 4y ago
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.
- gregsadetsky 4y ago
  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?

aardvark179 4y ago

I’m not sure how they do it but I think it requires a special agreement with the token issuers.

zamnos 4y ago

If you name the transit authority doing this, it'd be possible to look at what the iPhone/Android phone is actually doing. One possibility is the information being shared when using the NFC isn't your CPAN or DPAN at all, but is a 3rd identifier with which they deanonymize you.

rswail 4y ago
If you use an EMV card in transit, then the Visa/MC rules say that the same card must be used to pay for the fare. 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.
_rs 4y ago
I believe OMNY is one system which operates as OP is describing

kailanb 4y ago

Transport for London does the same. If you add your (real, CPAN) card number to the "Contactless and Oyster" web service, it will also add all of the DPANs you have tapped in with on their network as separate cards.

rswail 4y ago
Yes, the DPANs have to be tracked separately so that you use the same device/card to enter as you do to exit. 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.

rswail 4y ago

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.

gregsadetsky 4y ago
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?