System level security measures for MIFARE installations

Security recommendations on design contactless card systems such that they are better resilient against attacks and that the impact of attacks, if they were to succeed.

When designing contactless systems, e.g. based on MIFARE DESFire or MIFARE Plus it is important to design the system such that it is resilient against attacks, of course in a balance between costs, risks and impact when some of those risks materialize.
MIFARE DESFire EV1 and MIFARE Plus both have Common Criteria (CC) EAL4+ certification and are thereby the chips which currently have the highest certified resilience against attacks of chips for similar purposes in the industry. It means that these chips have been tested to withstand attacks with power analysis, light attacks and many more and found to be able to withstand those attacks.
Like for any chip that has Common Criteria certification of any level, MIFARE Plus and MIFARE DESFire EV1 having CC certification does not mean with absolute certainty that these chips can never be successfully attacked at any time in future. Attack methods get increasingly more sophisticated and so do the defenses that NXP builds into the chips. Unlike security in PCs, which can be generally updated and thereby increased over time, the MIFARE Plus and MIFARE DESFire EV1 chips are as they are and new defenses can (and will) only be built into future generations of chips.
The systems in which those chips are deployed can be designed such that if there ever would be an attacker being able to successfully attack the chip that the impact of this attack is limited and that the damage can be repaired.
This document describes design considerations for systems deploying MIFARE Plus or MIFARE DESFire EV1 to reduce the chances of attacks being successful and then to reduce the impact in the unlikely case that an attack were to be successful.
This document does not describe security design for the backend of such systems, e.g. the way in which terminals are connected to the central IT system.
This document was written with the scope of the chips that have the highest resistance against attacks. However, for other chips, like MIFARE DESFire (the predecessor of MIFARE DESFire EV1) and MIFARE Ultralight the same considerations hold. For MIFARE Classic there is a separate document, with some other countermeasures which are specific for that type of chip.

Example of a vulnerable system and a system with limited recovery opportunities
Before discussing solutions to “close the holes”, let’s look at two examples of what can be the impact of an attack on systems which are not designed to mitigate attacks or to deal with them when they occur.

Using the same key in all cards
Imagine an Automatic Fare Collection (AFC) system in a city. Let’s assume that all keys in all cards are the same. Even if there are multiple keys on a card (keyset), but the same keyset is on all cards then that makes no difference for this example.
Imagine now a criminal organization who invested a considerable amount of time and money to reverse engineer the chip in order to get a key out of a chip on a valid card for that AFC system and imagine the currently unlikely case that they succeed.
Having the key allows them to read out the content of the chip in the card. Having the key and the card contents, they can put this information on blank cards and sell those in the streets. To the system those blank cards will look the same as the original card and people can travel on them. The only difference is the UID, but unless the system is designed with whitelists, which is not practical for systems with many cards (see below), the system has no way to tell that it is the UID of a card that is not part of the AFC system.
Alternatively hackers could on the Internet publish software and the key to allow everyone who has a reader (which can be obtained for less then $25) to update the balance on their own legitimate cards.

No update mechanism for keys
Imagine again an Automatic Fare Collection (AFC) system in a city. Let’s assume this time that all keys in all cards are different and derived from encrypting the UID and other information by a master key (as explained in section 3.1 below).
Now imagine that a criminal organization is able to obtain the master key by bribery or by attacks on a stolen Secure Application Module (SAM, see section 4.1 below), which, although in most systems having a very low chance of happening, cannot be ruled out. Note that the master key is not present in any chip which is normally in the hand of consumers, so a device with the master key first needs to be stolen before an attack can be started (and then the attack must also be successful). All of this makes is less likely than an attack on a card.
Imagine finally that this system has no way to update (renew) keys on cards that are already in the field. In that situation the system is left in the same state as described above in which all keys are the same. Using the master key, hackers could for each card calculate the keys and deploy this as described above.