System level security measures for MIFARE installations

Mitigation of attacks on cards :
attacks on cards. Note that some terminal side attacks, once successful, enable certain attacks on cards. Those attacks are also considered in this chapter.
Key elements in designing secure systems that can mitigate attacks on cards:
These are the key elements in designing secure systems:
1. Key diversification With key diversification each card has a key or keyset which is different from each other card.
2. Fraud detection The ability to find out that a fraudulent card exists.
3. Mechanism to stop deployment of fraudulent cards This can be either or both of:
a. Black listing / whitelisting A mechanism by which the terminals can be instructed to accept or reject certain cards.
b. MAC over the to-be-protected card contents and UID. Calculate a MAC over the card content including the UID and use a key for the MAC that is not present on the card (only present in terminals).
4. Key renewal With key renewal the system has the ability to update the keys in the cards in the field, and use those new keys by the terminals. When a consumer presents a card that holds old keys, the keys will be updated to a new set of keys, and then the transaction will be performed.
We will discuss these concepts below. First some terminology though, followed by an overview of the effectiveness of the various defenses.
Terminology:
Every MIFARE DESFire EV1 and MIFARE Plus has an ID. This is either a unique ID (UID) (meaning that there are no two genuine MIFARE cards that have the same UID) or in other cases an ID which is likely to be different from IDs of other cards by a high likelihood. In the case of non unique IDs the likelihood of being able to acquire another card with the same ID as one that an attacker has access to, or even the ability to acquire two cards with the same ID is so low that it is neglectably small for a commercially viable criminal business case. Therefore we treat the non-unique IDs in this document as if they were unique IDs.
An emulator is a piece of hardware and software which can emulate the MIFARE DESFire EV1 or MIFARE Plus, including a UID that can be freely chosen. This free choice of UID makes the emulator different from a genuine MIFARE card. A laptop plus a < $25 reader device can act as an emulator if the right software is implemented. Although no emulators are currently known for MIFARE DESFire EV1 or MIFARE Plus, the possible existence of those tools is not considered to be harming in itself. MIFARE DESFire EV1 and MIFARE Plus are designed such that the protection fully comes from the ability to keep the keys secret.

Overview of effectiveness:
See Table 1 for an overview of the effectiveness of five sets of mitigation measures. The mitigation measures are discussed in more detail thereafter.

Table 1. O verview of effectiveness of the mitigation measures          
# Mitigation measures Attack Deployment using the attacked card Attack Deployment using other legitimate cards of the system Attack Deployment using new blank genuine cards Attack Deployment via emulators
1 Key diversification No protection Effective protection (regardless of fraud detection) as long as the master key for key diversification in the terminal is not compromised. Effective protection (regardless of fraud detection) as long as the master key for key diversification in the terminal is not compromised. No protection
2 Key diversification + fraud detection + black/whitelisting Effective protection from the moment of updating the black/whitelist Effective protection (regardless of fraud detection) as long as the master key for key diversification in the terminal is not compromised.
Otherwise: effective protection from the moment of updating the black/whitelist
Effective protection (regardless of fraud detection) as long as the master key for key diversification in the terminal is not compromised
Otherwise: effective protection from the moment of updating the black/whitelist
Effective protection from the moment of updating the black/whitelist.
If the master key for key diversification in the terminal would get compromised then the protection is not effective.
3 Key diversification + MAC over the UID and content Partially effective protection.
Residual risk: card can be brought back into a previously valid state of that card.
Effectiveness: Not possible to put any value on the card, but only previously valid states. This holds as long as the key used in the terminal for the MAC is not compromised. When that key has been compromised: no protection.
Effective protection (regardless of fraud detection) as long as neither the master key for key diversification in the terminal nor the key in the terminal for the MAC calculation is compromised.
When the master key for key diversification has been compromised: partly effective protection, see “Deployment using the attacked card”. When the key in the terminal for the MAC has been compromised: see row 1 above.
Effective protection (regardless of fraud detection) as long as neither the master key for key diversification in the terminal nor the key in the terminal for the MAC is not compromised.
When only the master key for key diversification has been compromised: still effective protection. When only the key in the terminal for MAC has been compromised: still effective protection When both keys the terminal have been compromised: see row 1 above.
Partly effective protection.
Residual risk: A previously valid state of the attacked card can be put on multiple instances of emulators.
Effectiveness: Not possible to put any value on the card, but only previously valid states.
This holds as long as the key used in the terminal for the MAC is not compromised.When that key has been compromised: no protection.
4 Key diversification + fraud detection + black/whitelisting + MAC over the UID and content See 3 above until the moment that the black/whitelist has been updated, thereafter see row 2. See row 3 above. See row 3 above. See 3 above until the moment that the black/whitelist has been updated, thereafter see row 2.
5 Methods 2, 3 or 4 with additionally the ability to do key renewal in the field. Before updating the keys: same as in the original method.
After a terminal key has been broken and this card is presented to an updating terminal, the original protection is regained. (this only holds if the keys for updating had not been compromised as well or if the updating transaction cannot be recorded by an attacker).
For cards that are never presented to an updating terminal, original protection is regained once cards with keys derived from the compromised master key are no longer accepted.
Before updating the keys: same as in the original method.
After a terminal key has been broken and this card is presented to an updating terminal, the original protection is regained.
For cards that are never presented to an updating terminal, original protection is regained once cards with keys derived from the compromised master key key / MACs calculated with the compromised MAC key are no longer accepted by non-updating terminals.
Before updating the keys: same as in the original method.
After a terminal key has been broken and this card (being a fraudulent card) is presented to an updating terminal, the updating of the keys will fail. That means that fraudulent cards cannot pass updating terminals. This event can also lead to blacklisting (in methods 2 and 4). Finally full original protection is regained once cards with keys derived from the compromised master key key / MACs calculated with the compromised MAC key are no longer accepted by non-updating terminals.
The same holds as for new blank genuine cards.

Key diversification:
The principle of key diversification is that no two cards will hold the same key or keyset. Every card has a UID and this UID can be used to determine the key / keyset to be used.
Except for the smallest systems it is unpractical for the terminal to hold a list of all the keys / keysets of all cards. Hence the key / keysets must be calculated from the UID. This is normally done by a process as illustrated in Fig 1.

 ISO MIFARE DESFire EV1 Smart Card 2k byte/16k bit,Mifare DESFire EV1 2K Proximity Contactless Cards,Mifare DESFire EV1 2K Printing Cards,

The terminal holds a Master Key. The UID and other information concatenated and encrypted and the result is the diversified key. There are various cryptographic ways to do the key diversification operation. See [2] for the ways that the MIFARE SAM (Secure Application Module) performs key diversification. Even if your system does not deploy SAMs at the moment, it can be beneficial to use the same algorithm as the SAMs do, since this algorithm has been cryptographically verified, and it allows introducing SAMs later without having to change the keys on the card.
If each card holds a keyset (consisting of multiple keys for multiple purposes), the process in Fig 1 is carried out for each of those keys in the keyset (except e.g. a key to retrieve the UID, see section 5.4).
The resulting key / keyset is written on the cards during the personalization step, after the personalization station has read out the UID of the card.
The terminal first reads the UID and then calculates the diversified key / keyset it needs for the operation. Then this key / keyset is used to set up the secure communication to the card.

Fraud detection:
There are many ways of fraud detection which we cannot discuss here in any detail. In general it will come down to bringing together all transaction logs from all terminals and then detecting anomalies. Examples include: cards which suddenly get a higher balance without having been recharged with a value, cards which are used at two places within a time that does not allow for physical transportation of the cards between those places. Various system integrators have developed a variety of sophisticated algorithms for this.
Alternatively, when fraud becomes massive then it will become known. When fraud becomes massive then many people are involved and it is unlikely that no information will leak out.

Blacklists/whitelists:
When blacklists or whitelists are used, the terminals are designed to hold a list with either all UIDs that are authorized for the system (in case of whitelisting) or all UIDs which have to be blocked (in case of blacklisting) or a combination of both.
The system of whitelisting is more restrictive. However it is only usable in small systems. In larger systems, e.g. in an AFC system with millions of cards a whitelisting system would lead to an amount of data that terminals cannot handle.
The blacklists or whitelists must be updated after fraud has been detected. Terminals which are online can receive this information immediately after detection. Terminals which are normally off line must be put online at some time (e.g. terminals in busses get updated when the bus gets into the garage). Alternatively blacklists and whitelists can be distributed via other media, e.g. in a hotel the updates for the lists can be coded on the guest cards and be taken over by the terminal in the door when the guest presents the card.
A blacklist or whitelist system can be complemented with an “alarmlist”. This list will have UIDs which should trigger an alarm. Not only will the terminal potentially block the operation, but it will also give an alarm, e.g. to a guard who can arrest the fraudster.

MAC over content and UID:
A MAC is short for Message Authentication Code. It is a cryptographic calculation over, in this case, the data on the card that is to be protected concatenated with the UID of the card. This MAC is calculated by the terminal and the result is written onto the card.
When a terminal gets presented a card, it reads all the relevant data as well as the UID and the MAC. It will first calculate a MAC over the relevant data and the UID and compare the result with the MAC that was read from the card. If they do not match the terminal will block the operation and could trigger an alarm if so desired.
The key which is used for the MAC calculation can also be a diversified key. It does not harm, however the importance of it is less than with the keys on the card. When an attacker would even be able to obtain all data and the MAC, a good MAC algorithm has as property that it is impossible to derive the key from those pieces of data. If a diversified key is used, then in the terminal the point of attack will not be the diversified key used for the MAC, but the master key from which the diversified key is calculated. When that is obtained, the attacker can himself calculate all required diversified keys.

Key renewal in the field:
Both MIFARE Plus and MIFARE DESFire EV1 have the ability to do updating of keys on cards which are deployed towards the users of the system already.
The terminal will authenticate with an appropriate key in the card (which key depends on the access rights and how the system has been further set up). Then the terminal can write a new key or set of keys in the card.
We assume here that the keys used for updating in the card have not been compromised or that the updating messages cannot be recorded. If that were not true, the attacker could learn the new key.
When a master key used for key diversification would have been compromised (see 4.1 for ways to make compromising of master keys very unlikely), a new master key could be generated and deployed to all terminals. To a limited number of terminals, let’s call them the updating terminals, also the master key for updating of the keys in the cards would be deployed. Terminals in vulnerable environments will not get the keys to update keys in the cards, these are called non-updating terminals.
When a user presents his card to the updating terminal, the terminal will read out the version number of the key/keyset used in the card and based on this first update the keys in the card to the keys for this card derived from the new masterkey. After this has been done the normal transaction, e.g. opening of the gate, would take place.
All considerations for key renewal are more complex than can be explained in this document. However one element is to take care of is the time of the total transaction, so the key updating plus the normal transaction, so that the user is not experiencing so much delay that he will think that the card does not work and removes it from the terminal to try again.
Note that any fraudulent modifications made to a card between the moment that a key is compromised and the moment that the keyset has been renewed are not undone by the key renewal and they have to be separately taken care of.
When a MAC key is compromised and has to be updated there is no special interaction with the card needed. The transaction will verify the MAC with the old key and compute the new MAC with the new key. It is recommended though that somewhere on the card there is a version indication of the key that is used for the MAC so that immediately the right one can be chosen.
After an update period the compromised master key for key derivation / the compromised key for MAC calculation is no longer deployed. This means that cards which have not passed an updating terminal will be rejected by other terminals and the user has to be told to first update his card in an updating terminal.

How the countermeasures help to mitigate the risks:
Table 1 describes the mitigation measures.
Row #1: Key diversification only.
If only key diversification is used the impact of attacks is already strongly reduced. Since the key that is obtained is only valid for cards with the same UID, it needs either the originally attacked card or an emulator for the attack to be successfully deployed. Sending out the key and attack software to a wide set of recipients to modify their own legitimate card is countered by this measure.
This of course only works as long as the master key for key diversification is not compromised, since when an attacker has this master key then he can compute the keys for each card himself.
Row #2: Key diversification, fraud detection and black/whitelisting.
If key diversification is used, then it is possible in a system with black/whitelisting to additionally exclude the fraudulent card or replicas thereof based on the UID from the moment that the black/whitelist is updated.
Since due to key diversification the compromised key is only usable with a card or emulator with the same UID, the blocking of the UID guarantees that the attack is countered.
If the master key for key diversification were compromised, then the deployment of a fraudulous card is only blocked from the moment that the black/whitelist is updated. However when the attacker uses an emulator, he can just choose another UID and calculate the keys for that card using the compromised master key. The fraud will continue in that case.
Row #3: Key diversification and MAC over UID and content.
In case a fraud detection and/or black/whitelisting system cannot be implemented, the usage of MAC over the combination of sensitive content and the UID can still provide a level of protection.
In this case, key diversification makes sure that only the original card or emulators can be used to deploy the attack, since the compromised key will only work if the UID is the same.
It is possible to revert the card back to a previously valid state by writing back that data plus the MAC which was then valid. And this can be done on the originally attacked card as well as on emulators that emulate the same UID, of which there can of course exist many copies.
It is not possible to put any desired value on the card, since then the MAC would fail.
If the master keys for key diversification would be compromised, the attacker can calculate the keys for all other cards based on the UID. So then any card can be brought back to a previously valid state and deployment via an emulator is possible. However introducing new cards with new UIDs is not possible, since there is no “previously valid state” for such cards, since they have never been in the system before.

If the key for the MAC calculation were compromised, the MAC is no longer effective and the system would be equal to a system with key diversification only as described in row 1.
Row #4: Key diversification, fraud detection, black/whitelisting and MAC over UID and content.
When combining #2 and #3, the combined benefits can be obtained.
Row #5: The other methods extended with key renewal in the field.
As long as no keys have been updated, the effectiveness is as in the original method.
The new master key or key for MAC is first deployed into all terminals, in addition to the old one, so that all terminals can deal with both old (not yet updated) and new cards (with updated keys).
If the keys on the card need to be updated, the updating terminals will in addition have the master key to derive the card update keys1 from. These are the (again diversified) keys which are needed to update a key on the card.
When a card is presented to an updating terminal, it will update the keys and only then perform the transaction using the new keys. From that moment the protection for that card is in effect again.
When a card is presented with a UID which does not belong to the system, the authentication with the key update key will fail, since such cards do not have the right key update key. All updating terminals will then not let the transaction take place. The system could based on the failure to update the keys blacklist the card and deploy that blacklist also to non-updating terminals.
For emulators the same holds in principle, however emulators can at no cost assume another UID and would then work again with non-updating terminals. Emulators will finally be stopped once the compromised key is no longer deployed to the non-updating terminals.