old reader with new desfire cards

[Andreas Schmidt]

We are using a print solution from Nuance (equitrac express) and an older pay terminal from inepro. This terminal reads 10 digits from our older cards and compare it with the database in equitrac to authenticate the user. Now we have new desfire cards and a 17-digits ID in the database for user with these cards, but ... and this is the problem ... the pay terminal reads only 10 digits, not the first or last ... we don't know. So, it reads 583274237 instead of 36113185115030020.
So, i see two Options:
- buying a new terminal reading both types of Cards or
- develope a little program to convert the 17 digits in the 10 digits reading by the terminal and modify the database entries.

But, what is the algorithm?

Can anyone help?

Thanks in advance
Andreas

---

+ 0  |  - 0

[TapLinx Support]

Hi Andreas,

Did you initialize the MIFARE DESFire before using it? Or do you identify the card with the UID? The UID of MIFARE products are usually seven bytes long.

The TapLinx team

---

+ 0  |  - 0

[Andreas Schmidt]

Hello.

Yes, we know that. The UID of the new card is 7 bytes long, UID of the older cards only 4 bytes. That is no problem for our print solution, only the terminal to pay money to enhance the value of their print accounts does not read the UID exactly. We thought we can translate the 17 digits of the 7 bytes UID in 10 digits like the older Cards, so described here: https://www.nxp.com/docs/en/application-note/AN10927.pdf (3.3.2)

Is that a possible way?

Thanks
Andreas

---

+ 0  |  - 0

[TapLinx Support]

Hi Andreas,

the UID is used in the anti-collision loop. Yes, older MIFARE Classic cards uses 4 byte UID. But the space for 4 byte UIDs is exhausted, therefore all new MIFARE cards uses 7 byte UID.

This approach is not very robust. Why you do not personalize the card with 16 byte data block (in case of a Classic)? Then the card UID is needless and you can ignore the UID completely.

Please take in mind, MIFARE DESFire cards can be configured to use a random UID in the anti-collision loop. Then your approach to track a card will not work.

How the anti-collision is implemented, depends on the reader manufacturer’s software. I recommend to get the user manual of your reader.

The TapLinx team

---

+ 0  |  - 0

[Andreas Schmidt]

The students get their cards fully configured and we get the UID (or whatever) from our IT-Service Center and fill up the database of our Software. When a student wants to enhance his value and use our pay terminal, this ID is used to authenticate the user. It works fine with the older cards for many years, but now ...???

These cards are used for open doors and go to the mensa also, so i think they don't use a random ID, but i really don't know.

Andreas

---

+ 0  |  - 0

[TapLinx Support]

Hi Andreas,

It seems that you use MIFARE Classic cards. But identifying a user only with the UID is a security flaw! The UID can be copied very easily and a simple tag can be used to modify the UID to a certain user’s UID.

Let me explain it with a picture. You have a passport with a picture and a lot of other security features. But for the decision if a person can come in, you do not open the passport and compare the picture, you only read the passport number printed on the cover side. If the printed number is one of the expected, it is passed.

You wrote, your “IT-Service Center” prepare the cards, so it should also save the Student ID in a block and set the access to read-only (and make the write access impossible). This always works, regardless if it is a 4-byte-UID card or a 7-byte-UID card.

The TapLinx team

---

+ 0  |  - 0

[Andreas Schmidt]

Hi.

We know all (or not) about these security features and we are sure that the sensitive data on the cards are read only. We don't know which data used for open a door. Bu we know that we are using the UID of the Card to identify the user who wants to raise his credit für printing ... at least until today. Now, the Reader of the pay terminal reads a wrong value that does not correspond with the entry in our database. He shoud read a ‭804CC0227D4204‬(hex), but reads ‭22C40EFD‬ (hex).
So we have to raise up their credits manually, which takes a lot time.

Thanks for all your help and patience.
Andreas

---

+ 0  |  - 0

[Author]

Posts