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…