Securing RFID membership cards

Question

Let's say I issue RFID-enabled membership cards for events. People can have their credit cards, personal ID, etc tied to this membership card. When they come to my events, they can use this card to pay for things, verify age, etc.

From what I understand, RFID cards are fairly trivial to duplicate and thus steal remotely.

What are reasonable things I could do to protect against this?

An idea I had - record a changing nonce on the RFID card. Every time we scan the card, we check if the nonce matches what we have in the database. If it doesn't match, that card is marked as compromised. If it does match, then we authorize the transaction, overwrite a new nonce to the card, and save that to the database. (in addition to things like checking that the card doesn't look counterfeited)

Answer 1

You can issue shielded containers for the cards. These are plastic sleeves that feature a thin sheet of metal on either side of the sleeve, making it impossible to scan the card. When the user needs to authenticate or verify, they can simply take the card out. There are more luxurious shielded containers that separate the plate from the card when pinched together, making the process easier and quicker.

Of course, this does not offer any protection to users willfully allowing their card to be duplicated.

The problem with your suggested solution is that when a counterfeit card is used before the legitimate one, the counterfeit will maintain functionality while the legitimate card will be marked counterfeit. At best this will serve as an indicator the card being offered is either copied or a copy.

I'm afraid that is as much as you can do to protect a static token.

Answer 2

You should use smart cards. They can handle crypto and only disclose their contents on presentation of a key, as well as encrypting the reader/card communication so sniffing won't work.

For contacted cards I guess a PKI card would work, where the card proves it has the private key to a particular certificate, and you use that to pull the user's record from a database. The problem is that you can't actually store any meaningful data on it (besides a private key), which requires the usage of a database and thus prevents offline usage of the card. I don't know if there are any contacted cards that simply store arbitrary data and give it back on presentation of a key.

For contactless cards (NFC) there are Mifare cards which can store data and only disclose them on presentation of a key. They don't do crypto (there is no concept of asymmetric crypto, it's only simple things like "give me key for data block XX, if key is OK I give you back the block's contents") but on the other hand can store arbitrary data and thus allow offline devices to still interact with the card with the system remaining secure (if implemented correctly).

The keys themselves aren't bruteforceable (too much possibilities) but some cards had flaws (Mifare classic for example) that allowed to get a sector's key and then use another flaw to retrieve all other sector's keys from the knowledge of a single one. However these flaws have been fixed in latest revisions of the cards.

For your application, the following cards may be suitable :

• Mifare Ultralight EV1 - uses a 32-bit key to protect the data stored on it, though the communication with the reader isn't encrypted and it's thus vulnerable to sniffing.
• Mifare Ultralight C - uses 3DES crypto between the reader and card, better security than the above.
• Mifare Plus - upgraded version of Mifare Classic which mitigates its vulnerabilities, uses keys and proprietary roll-your-own crypto, not sure if any flaws have been discovered in this new revision since the Classic vulnerabilities were fixed.
• Mifare DESFire EV2 - latest revision of the DESFire series, supports AES crypto.

No matter which card you choose from this list I suggest you implement it like this :

• one data block with some user ID or reference to the user's record in the database, set to public access so no key (or a default, low-security key) is needed. You may also use the card's UID but beware, they may not be unique.

• once that block (or UID) is read the computer attached to the reader looks up the user in the database and gets his unique, per-card key to authenticate and retrieve other confidential data blocks to actually prove the user is who he's pretending to be (via a nonce or a secret value stored there) and someone didn't just clone the publicly available user ID from the first sector.

• you can encrypt the card's data one more time (you may use the card's UID as an IV) with a key only your infrastructure knows (preferably unique per-user), that way if someone still manages to get ahold of the confidential data stored on the card, they won't make much sense of it.

• don't use UIDs for anything sensitive, you should assume they aren't unique, can be easily read and duplicated (despite what NXP says about the uniqueness of the UID, there are "magic" Mifare counterfeits available that allow changing the UID using a custom command).