Do readers for the "Mifare DESFire EV1" smartcard really need to know the card's secret key in order to authenticate the card?

Edited: OK. As there is request for "short answer" here is "executive summary" here it is:

Question: “So all the reading devices must know the secret key, too. But there can be many readers from many vendors (e.g. coffee machines, small USB readers at cash registers, access control panels…), do all of them really have the secret key? Is there a standard on how the key has to be stored?”

Answer: “Yes. Apart from remote/server initiated communication with DESFire card, all readers has to know secret keys too. And Yes – there is standard on how the key has to be stored – use of Secure Access Module – MIFARE SAM (currently AV2 model).

All content below you can forget if not interested ;)

There are basically two families of MIFARE cards: MIFARE Classic and DESFire (and similar derivatives). Additionally there is MIFARE Plus, which has been targeted initially at MIFARE Classic markets (which it fully supports, if configured to do so), has two additional security modes of operation, which add more security to MIFARE Classic infrastructures up to a level similar to DESFire.

There are many authentication protocols used among those MIFARE families, some are quite similar but sometimes differ in small details, which may lead to reading infrastructures NOT being capable of handling another protocol even if they look very similar at first…

What is more important to your question about DESFire EV1: the basic approach for reader side security is the usage of so called "Secure Access Modules" (SAM), which are specialized smart cards, providing security related functionality to the readers/terminals. The SAM holds all keys and also has an engine to conduct security protocols, used within the secure communication between the card an the reader. This is the anchor of reader security in terms of DESFire EV1 usage. The keys might me also be derived individually for each card, so they do NOT use the same key for all the of card's authentication and encryption protocols. The key in a SAM module can be securely uploaded to the SAM in field by using additional encrypted protocols from the host OR by a batch offline upload (from an USB stick for example).

Some RSA based protocols are also supported for signing/verification to ensure some actions are authenticated without the use of shared keys protocols.

The SAM is cleverly planned and pretty solid in terms of security, so putting such a SAM module in a vending machine supports all security requited. Even a DESFire card modification, initiated by a remote host, can be securely established as the SAM can act as a “secure proxy” by establishing a secure channel towards the host and another one towards the card, providing a “re-encryption proxy” in the middle. Of course SAM is standard card being “client” and any command exchange, so the reader has to support those protocols by sending, receiving, forwarding APDUs between participating parties. The SAM also supports direct connections to the reader's chip, acting as a transparent proxy.

It supports 2DES, 3DES, AES, CRYPTO1, RSA, and some proprietary variants of standard algorithms.

SAM has even cleverer concept of “operation counters”, which helps to address the security threat of being stolen and used frequently: each operation decreases a counter. The counters must be periodical increased by a host initiated action, online or offline. Encrypted and signed “scripts” must be brought to the SAM in a way (e.g. USB stick). The keys can be also versioned to support secure roll over of keys during the system lifetime.

The SAM itself has access control logic, based on strong cryptography, to enforce the designed security model. A carefully planned and designed Key Management scheme, supports secure key distribution among the system's many players. Usually, the initial SAM content is distributed by a secure SAM personalisation and controlled delivery to appointed participant (like vending machine vendor), who already has some authentication keys to get initial access to allowed SAM/DESFire card operations. One of typical operation can be authentication keys exchange IF those keys are assigned only to particularly player.

Another comment to UID, its cloning and so on: modern MIFARE products support separate commands to access a RandomUID, to be used in anti-collision protocols, and a static UID to identify the card (optionally also protected by authentication and encryption protocols providing a “secure channel”). This gives to system designers the proper tools to enhance protection against UID cloning or emulation. But many “security designers” are quite lazy anyway and don't use those possibilities even if they exist…

Most of the systems I know indeed use a network connection to authenticate the cards via challenge-response.

I have seen some offline devices that only compare the UID of the card with stored values. This is not secure, however, as you can copy these IDs by emulating an RFID device or simply flashing a special card.

I agree with you regarding the offline devices being promising. I've already successfully tricked some of them by just sending a known UID. I haven't even had to get deeper into the protocol stack as the UID is transmitted at the anti-collision layer already.

If you want to dive deeper into that stuff I would recommend some hardware device to play with. It's quiet a lot of fun seeing these things in action :-)

The state of the art solution would be the PROXMARK http://hackerwarehouse.com/product/proxmark3-kit/

Or a lower budget solution if you just want to copy some cards http://www.instructables.com/id/RFID-Emulator-How-to-Clone-RFID-Card-Tag-/

I also saw some keyring devices for less than 20$ in eBay but can't find them right now.

MIFARE DESFire EV1 can have multiple applications (28), and each application can have multiple files (32) of different types (4). The card itself has a PICC master key plus between 1 and 14 keys per application. The keys of each application are used to control access to its files.

Each service used by your card can be, and probably is, a different application. If the coffee machine keys are compromised (application A), that doesn't imply the compromise of the keys for the access control application (application B) in the same card.

Consider a coffee machine application on the card that uses one key K1 to deduct credit, and another key K2 to add credit to your DESFire EV1 card. The machine you use to get your coffee and that deducts the credit from the card only needs key K1, it doesn't need to have the key K2 to add credit (which is done somewhere else). So if you compromise the key of the coffee machines, the only thing you can do is take money out of cards, and not increase your credit. To add credit you need the keys for that and this may be a procedure done at a different place in a more secure environment and perhaps even by a human operator.

There is always risk of compromise, but it can be mitigated by clever use of the keys and separation of services into different applications. Maybe you have 200 coffee machines spread all over the office area that can work offline, but only need 10 to top up the card and maybe this is even done online for extra security.

The coffee machine can use a security access module to store the keys. If they do it or not, and if they need it, that's another story.