Getting that to you won’t be a problem but won’t be right away,I will have to do that during the week since I’m using a phone friend for the scan,I’ll get back to you during the week.
There are certain chips that support a “privacy” feature which randomizes the UID each time. The only way to get the real uid is to authenticate using a cryptographic key. The desfire chip can do this as well as various smartcard chips like the p60 and p71
So with the P71, if someone enables this feature, then the initial ATR response will have a random UID (but I’m assuming a static manufacturer/vendor ID). Then the reader sends some kind of challenge that the P71 recognizes and it then does a second ATR but with the real UID?
That would be interesting to test on my unlocked P71 card. How is it enabled?
It’s so strange dealing with overlapping standards but basically contactless doesn’t actually really produce an ATR. The reader will produce an ATR based on what it knows about the contactless chip it’s talking to. Contactless can produce an ATS value but getting this over a pc/sc compliant reader is not standardized.
Also I don’t think the ATR actually contains the UID. When it comes to ISO14443A, the reader will send out a sort of beacon command to any chips in the field, and they will respond with their UID. Then the reader will issue a select command with a specific uid that it wants to talk to, and all other chips hearing this select command will go silent and let the selected chip respond.
This is typically how you should be obtaining the uid of any chip you are talking to, which means things like door locks and other simple reader devices should always be able to work with any type of chip that is ISO14443A compliant… however we know there are plenty of readers and door locks that do not work with certain types of iso14443a chips, even if the byte count of the uid is the same as other chips the lock or reader does work with. For example, a lock might work with a ultralight or ntag chip but not a desfire chip. This makes no sense because all of those chips work exactly the same way when it comes to iso14443a interrogation and selection. The problem is that these readers and door lock products are using crap firmware written by some dummy that is very likely issuing read commands to the ultralight and ntag chips to get the memory contents of the first free memory pages and pulling the UID from that instead of the iso selection process.
Anyway, point here is that the p71 and other chips with privacy mode will generate a random uid once powered, and report that random uid to the reader in response to any beacon command it hears. When the reader wants to talk to that chip, it will select that particular uid and that is the uid reader will talk to the chip with during the contactless session, even if you issue other commands to get the real uid of the chip, that is akin to issuing memory read commands to get the uid from an ntag vs the iso selection process. Getting the real uid of a chip with privacy mode involves special commands and data processing. It does not change the uid in the middle of the contactless session. It can’t, that would confuse the reader and violate the ISO standard.
Hiiiiii! I’ve been away on medical leave for a month, but I’m back. I’ve missed you all!
This is an Ingenico terminal. I work in the point of sale industry. It’s not dramatically different from the VeriFones, but they seem to function slightly better. All of these devices are tricky to use, repair, and keep in the field for long because of their tamper detection requirements (I can go into detail if you want).
This is true with the Ingenico. That’s the sweet spot. That function at least is way better than the VeriFone.
I really wish my laptop had an NFC reader in roughly the same spot…