First of all, congrats on your journey! and that seems like a great personal advancement already!
Now…
If your head of security is worth it’s salt…
The only (decent) reason to change into Desfire is to leverage at least it’s encryption capabilities.
If I’m thinking of the most basic possible desfire access control, you would have one “site key”, yes, but that key will never be passed into the cards themselves.
What the system does with it is…
When you present a card to be added into the system, that core key is used in conjunction with the card’s UID (and/or more stuff) to generate a secret passphrase, stored onto the card.
The “site key” is used then just to erase/modify said passphrase. So… admin only, never access.
When the card is presented against a reader, then the reader would query the UID and/or type of card, then if it’s acceptable, it should ask the Desfire to validate with an encrypted passphrase.
This would be just a very basic system, and not only there is more to leverage from Desfire cards, but there are also some more security practices to be used there, but this is enough to compare against the Mifare Classic…
On the Mifare Classic you cannot ask the card to validate a specific encrypted passphrase. Either you validate against UID/secret, or you don’t.
This distinction makes it so that, on Desfires:
- You cannot find the master key on the card
- Without the master key, you cannot clone the card
- (if the system is well built, even with the master key, you still cannot clone a card)
That said… This is all assuming your work’s Security guy actually knows what it does.
Because I’ve seen more places migrating into Desfire, but continuing to read only the UID, than I’ve seen places actually leveraging any DF security features. ![]()