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.

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.