Securing authenticity of mifare cards, protection against cloning

Question

I am designing a workflow for issuing and acquiring of voucher cards for a client and the chosen technology for the cards has been mifare desfire.

I have a lot of experience with credit cards and we want to make the technology as POS friendly as possible, so the acquiring process could be made as simple as possible to plug into existing POS application workflows.

Also, the HSM is one of those really credit-card centric ones, so if I want to keep the security benefits of having a super-secured locked down HSM, I need to use "industry standards" cryptography.

The card being closed-loop I have total control over all of the components of the issuing and acquiring process. My naive first idea was to have the card generate a signature for the transaction, but looking at the card commands specification, nothing really corresponds to this, it's hardly more than a data store with encrypted communication.

So the answer could be "use the channel encryption Luke", but this encryption then needs to happen between the POS and the device meaning that either the POS needs to do an online call during the duration of the contactless swipe (bad mobile internets etc) or the POS needs to know the card keys, which isn't nice.

So my question is, did I really understand it right and the only way to secure this thing in acquiring is to:

1. share the secret with the POS network
2. have the POS behave like a channel to the host exchanging the secure messages, but I'm not sure if this is even an option

Am I missing something?

Answer 1

Indeed, I was not missing anything, the only options really are:

1. share the master secret key of the issuing scheme to the entire POS network (a ba-ad idea)
2. use a server-side HSM to create session keys for the NFC communication meaning that the POS and the server need to exchange an API request/response cycle in mid-swipe for the POS to be able to authenticate with the card

Apparently, Mifare was designed as a low-cost, low-risk solution - something that if broken would enable the attacker to get less value out of it than the effort of breaking it, and it's remarkably secure in this role.

There are other technologies (e.g. https://en.wikipedia.org/wiki/Java_Card) which allow you to do more secure & more robust workflows, and they come with a price tag to match it.

---

EDIT in the end I opted for a server-side API where

1. the server component has access to the card keys via the HSM and
2. can answer to the card-challenge string with the challenge-response string
3. and in the same API response sends the session key to the appliance
4. the session key is in turn protected using same kind of technologies a PIN block would be secured (session keys, DUKPT, secure key storage on the appliance).

Where "appliance" is the "appliance which speaks to the Mifare card". The end result seems "good enough" because:

1. the individual card master keys are not shared to the appliances - most implementations depend on the card master key to somehow be shared and this is a no-go for my use case
2. only one API call is needed to the HSM in the cloud to make the communication happen - most of the other implementations I have seen do full pass-through card <-> HSM meaning 2-4 calls at minimum during the card swipe movement - which is a no-go for my use case
3. at worst case the attacker can figure out the session key of the individual exchange - and this if and only if he managed to break through the same kind of cryptography protecting PIN blocks in the PCI industry

So I'm guessing this is the sweet spot for what I need.

Answer 2

DESfire EV1 is now considered safe (post-2008), and cannot be cloned. Buy them directly from NXP. The secret keys cannot be sniffed, since they never leave the card. The UID is irrelevant, and setting it random may confound even a medium-skilled actor.

Here is a link to code for handling DESfire cards (albeit on a Teensy 3.2, using Arduino's slightly simplified C++)

link: https://www.codeproject.com/Articles/1096861/DIY-electronic-RFID-Door-Lock-with-Battery-Backup

excerpt: Mifare Desfire EV1 Cards In 2009 the next generation came on the market: the Mifare Desfire EV1 cards which have been improved once again and until today no attack is known. So if you use Desfire EV1 cards you do not need a Stainless Steel Wallet. Buying Desfire EV1 cards is more difficult. There are not so many offers and the cheaper ones require that you buy quantities of 50, 100 or even 500 cards. I found these two companies which sell also smaller amounts: RyscCorp and Smartcard Focus. You can also order from Smartcard America who sell via eBay but their shipping is very expensive to other countries. Be carefull with counterfeit offers from China on eBay: There is no guarantee that chinese clones fulfill the same security criteria as original NXP cards. Comparison Mifare Classic <-> Desfire Mifare Classic Mifare Desfire EV1 Unique Identifier 4 bytes UID can always be read without encryption 7 bytes UID can always be read without encryption in normal mode, but requires the PICC master key in random ID mode. EEPROM Storage On a card with 1kB memory: 16 sectors of 4 blocks of 16 bytes each (Blocks and sectors have fixed size) Up to 28 applications of which each can contain up to 32 files of variable size Keys Each sector can be protected with two keys (key A and key B) with different permissions per key Each application can be protected with up to 14 different keys with different permissions per key Encryption Proprietary (Crypto-1, 48 bit) DES (56 bit), 2K3DES (112 bit), 3K3DES (168 bit), AES (128 bit) Security Encryption has been cracked in 2008 No attacks known today While Classic cards are completely static, the Desfire cards store data in " files" of dynamic size that are contained in " applications". What is an application? An application is nothing more than a container for files. Imagine a RFID card issued to the students of a university. With the same card the student can eat in the canteen and he can park his car. In this example there would be two independent applications on the card: One canteen application and one parking application. The student can charge money for lunch and for parking which is stored in a file in the corresponding application. Each application has one or multiple encryption keys (the application keys) which allow to change the value stored in the respective application. Each key may have only read permission, only write permission or both. Additionally the card has another important key: The PICC master key, which is the "god key". The PICC master key allows to create and delete applications, assign keys to each application or even format the entire card. But interestingly the PICC master key can NOT access the data stored in the applications. Neither the canteen nor the parking deck know the PICC master key. They have only access to their corresponding application but not outside of it.