MIFARE Classic Crypto1, contactless card, end-to-end system security, vulnerabilities, threat and attack analysis, countermeasures

Countermeasures against emulators
The goal of the countermeasures is to detect fraudulent use of a card emulator.
The use of emulators can be detected in the backend by using the method described in chapter 5.6.1 (Modify block after reading) and it can be made more difficult by using key diversification for all keys on the card as described in chapter 5.6.5 (Implement key diversification). Note that the countermeasures below will loose all or part of their effectiveness once the new attacks from Radboud University Nijmegen (see chapter 2) can be made practical to work with little resources and in a reasonably limited time.

The countermeasures in this report attempt to achieve the following:
–Make it highly unlikely that a card of an innocent person who does not take part in the attack is copied in its entirety to an emulator card.
–Make it highly likely that such a partially copied card will – even by off line readers – be identified as a fraudulent card. The actions normally resulting from hotlisting can therefore be taken immediately with a very low residual risk that an innocent person is falsely accused.
–Proactively hotlist cards

The most effective countermeasure to detect fraudulent use of a card emulator is the use of transaction counters. This measure is described in the application note with general guidelines on how to securely integrate contactless cards. See Reference [4] for more information. However this is only effective for systems which are real-time on-line, so that every reader can know what the valid transaction counter is for that card.

Distribution of authentication data
A reader should first read out authentication data9 from a data block on the card every time it interrogates a card. This authentication data must be cryptographically bound to the UID using a key and algorithm that are not related to MIFARE.
This counter measure can be implemented in many different variations. An example would be to reserve 10 data blocks to store authentication data. The readers will then determine which block to read based on an application specific algorithm that uses the UID, the reader location, the date and the time of the day as input, where the time of day is used very coarse, so e.g. the hour, but not exactly on the hour.
In attack scenario 4.1.1, when the attacker manages to copy only partial information to an emulator card and presents that to a reader, the reader will, by using the algorithm mentioned above, determine which of the authentication data blocks to read out. If the attacker chose the wrong combination of time and location to make the attack (he won’t be able to know what the right combination is) the reader will ask for an authentication data block that is not on the (fraudulent) card. Based on that the reader – even off line readers – can immediately determine that a fraudulent card is presented and take the same actions taken as when a hotlisted card is presented.
Using 10 data blocks, there is a 90% chance that the reader will try to read a block that does not hold the right data. Taking more blocks will result in a higher chance.
Chances to predict the intervals when the block will be reused that the attacker had harvested earlier will get reduced when each day another random permutation of the daily order of those 10 blocks will be used before this is even diversified by UID and location.

Infrequent access of partial authentication data
The attacker eavesdrops the communication. To make it harder for an attacker to copy the entire card, the application can be set to only occasionally access part of the authentication, for example only once a week and then even at different times. That will make it very hard for an attacker to eavesdrop the communication at the right time to read the content of that block and copy it to an emulator card.

Provision to check if card is genuine
This provision can be used in the back office of the application, where attacks are unlikely. Keys of sectors that are never accessed by a reader cannot be retrieved (depending on the type of card, see Table 2).

The application can put partial authentication in sectors that will not be used in the “public” part of the infrastructure. A card can be taken for verification to a reader in the secure part of the infrastructure.