DesFire EV1 Tag and DesFire EV2 chip compatability

Hey everyone, quick question. I have a 9561T RFID tag (ISO 1444A, 13.56 MHz) that interfaces with DESFire EV1 credentials. If I implant the xDF2 chip, will I be able to clone this tag? In other words, is DESFire EV2 backward compatible with EV1 and classic? Also, what is the best reader/writer to use?

Unfortunately, DESFire chips aren’t currently cloneable.

Or ever.

I wouldn’t go that far, Mifare Classic was once considered ‘secure’.

Obviously with it actually being encryption it’s much less likely, but bugs are found in encryption implementations and random number generators every so often.

Definitely not for the foreseeable future, or very likely at all, but it could still happen!

2 Likes

Not cloneable, but UID Modifiable…so getting closer

https://labs.ksec.co.uk/product/mifare-desfire-compatible-uid-modifiable-emulator-card/

2 Likes

Just to clear up any confusion. The xDF2 Does not have a changeable UID. So no, you will not be able to clone your card onto the implant. You would need to talk with the administrator and enroll the implant as a new card in the system and have it associated with your credentials.

That is a good idea. After doing more research into my specific tag, I am 99% sure that it uses Mifare classic. I will buy the xM1 to emulate my door tag. If I am wrong then I can always replace it with the xDF2 and get it enrolled.

Thanks everyone.

Have you scanned it with TagInfo or NFC Tools? That would be they easiest way to confirm

To answer your original question

I checked this our a while ago and the answer I found in the NXP information was, “It can be” Read into that what you will…

Yes it is backward compatible meaning you can configure AIDs on it to have 3DES keys like the EV1 (only EV2 has AES keys), but basically you have to format your apps such that they work like apps do on the EV1.

The DESFire chip is an odd mix of customizable “apps” but have a hard set functionality… you get a menu of specific application “types” that each have specific ways of dealing with data I/O and storage, and that’s all you get. What you can customize is the size of memory each app will take up (like setting a file size), and the AID (application ID) it uses so you can address it with a specific AID on the chip. You can define multiple AIDs on a single chip. There are limits of course, like the total memory size of the chip… you can’t create three 4k AIDs on an 8k chip… but the point is, to get the most out of a DESFire chip you really should read the spec docs and consider writing some software that interacts with the chip. Simply defining an NDEF AID (well known AID) and taking up all 8kB with it… that’s the lowest possible use case for such a capable chip.

3 Likes

Haha, that is a real bugbear of yours isn’t it?

no not really… it’s a useful capability… but what does get me is situations where someone comes to me asking if they can store secret data on it or want to write some kind of application that stores critical data on chip, or has some kind of advanced application they want to use it for… but they come locked in the mindset that the chip is just a storage medium and you access that storage via NDEF… so basically they think the only way to do what they want is to format the whole thing for NDEF and then write binary data in there as an NDEF record and do all this nonsense to try to protect what is inherently designed to be unprotected and readable by everyone.

I indicate they should start with the data sheets, and explore the AID file types, encryption keys, things like secure sessions where the session comms between reader and chip are encrypted by DH key exchanges and even UID randomizing features of private mode… but nobody really does that… they start by formatting all 8k for an NDEF applet and start banging away on their idea.

Like deciding screws are better than nails, so you replace your hammer with a screwdriver and use it to bang nails into your wall.

3 Likes