End to end system security risk considerations for implementing MIFARE Classic

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

General countermeasures for Classic cards
Modify block after reading

Data stored on a card can be cryptographically bound to some counters11 which are updated after each read command. Every time a block is read, the content of this block is modified. If an attacker has managed to get access to a block, its content will no longer be valid after the block has been read again. With this measure the attacker needs to retrieve the data every time when the card has been accessed. Please be aware that, when the attacker can read out the data and then use a fraudulent card before the legitimate user, the legitimate user is locked out.
If the infrastructure keeps track of this bonded data, this measure can also be used to detect fraudulent cards. The fraudulent card can be detected as soon as the fraudulent card (or the legitimate card) with a wrong bonded data is presented to a reader. This gives information about the fact that there are fraudulent cards (at least one), not which one is fraudulent.
The card can be taken to the protected back-office and a sector can be accessed which will never be accessed in the field, and hence is very unlikely to be copied. This only works if the provision to check that the card is genuine works, see 5.5.2 for that specific type of card.
Note that this method can remain effective to detect fully copied cards, also if the new attacks from Radboud University Nijmegen (see chapter 2) becomes practical. The card of whoever comes first (legitimate user or attacker) will be accepted and the transaction counters will be updated. Once the other card comes (either the attacker or the legitimate user), it has the wrong transaction counters and it will be clear that a fraudulent card exists: either this one or the one presented earlier.
Remark: A MIFARE Classic transaction is not atomic. Updating the content of a data block in the field can cause the data in the block to become corrupted if the card is withdrawn from the RF field before the write action has been completed. The reader should, therefore, store the data that has to be written till a successful update has been confirmed or till another card is presented. The reader should only provide the requested service when the update of the block has been successful.

Expose faked keys at unauthorized moments and locations
There are situations when MIFARE Classic is used for access control where, depending on the UID, it can be concluded that the user will not get access to the building. For example doors or gates where the user never has access to, doors or gates where the user does not have access to at the actual time that the card is presented and doors or gates where the user has no access to because the user already is in the building and first needs to get out before the card can be used to get in again.
In those cases there is no reason for the reader to try to authorize with the card and in that way allow an attacker to make two failed traces and from that recover the key.
Rather than the reader not authorizing with the card based on the UID and whether the card will be acceptable at the actual time and location it is here suggested to let the reader try to authorize with the card using a fake key, i.e. a key that will not work for the card. This will still provide an attacker with a key, but when he goes to the legitimate card holder and tries to read the data on the card, he will find out that it does not work.
(When the reader would just refuse to authenticate, the attacker could repeatedly get back to the reader until the reader starts an authentication and then know that the real key can be retrieved from two traces.)

Block cards after incomplete transactions
When an attacker forces the system to make two failed authentications he can recover the key in seconds. On the other hand, if a card is slowly moved in the field, the number of failed authentications can be even higher because there is not enough power to complete the transactions. Alarming when two failed transactions occur is therefore not a useful counter measure.
However it is useful to lock a card (with a UID from the whitelist) in the system, after a failed authentication when the card is not determined to be an authentic card (by reading the cryptographic data which is bound to the card with diversified keys) within a few minutes.
The attacker can retrieve the key within seconds after two failed authentications. However he needs to go back to the legitimate user to, using that retrieved key, get the correct data from the legitimate card. That is unlikely to happen within a minute, where on the other hand it is unlikely that a legitimate user would within a minute not be able to make the transaction (even if he, hands full with bags and boxes, tries to make a failed move with his pocket to the reader and then has to put his stuff down to get the card out of his pocket).
So when a failed authentication is not followed by reading the correct data off the card within the timeout value, the card will be (temporarily) blocked in the system. When an attacker tries this attack, the legitimate user next time will not be granted access to the building and have to go to the reception desk or the security desk. There the suspicious card can be provided with new keys. This can be done at a secure terminal (e.g. the reception or security desk) or at a designated reader in front of the receptionist, where the receptionist can be instructed to carefully hold the card to the reader and keep it there until the gate opens.
Note: If the card is withdrawn to early during the process of updating keys, then it may be rendered unusable as the new key may be partly written. No doubt this will happen at occasions and then the user needs to get a new card.
This mechanism could lead to a denial of service attack. The attacker will not get access, but he can repeat the process of locking out the user repeatedly. In that case the user can be provided with another card which will have another UID and the user can be warned that there is someone trying to steal his identity. The user could opt for a metal card holder to avoid that this happens again if the risk for this is deemed high.
To avoid attackers trying many UIDs at random, it is good that an alarm is given when the reader detects many of the cases above: failed authentication without being able to read the expected data from the card within the time limit.
Note: It is normal that a reader reads UIDs that do not belong to the system. A user can have multiple RFID cards in his wallet, including the one which will give access. Therefore getting a few of those events is not abnormal. Testing hundreds of UIDs at high speed is abnormal however.

Implement rolling keys
Implementing rolling keys will make it harder for an attacker to grab the right keys and maintain them. In this case the remark of section 5.6.1 is even more valid, since updating the keys means updating the sector trailer. If the content of the sector trailer becomes
corrupted, the entire sector could become inoperable. The measure can therefore only be used in a controlled environment when the reader has physical control over the card (e.g. a machine that grabs the card).
In general, given the complications, this mechanism is not recommended.

Implement key diversification
Implementing key diversification for all keys (literally all, no exception) on the card will make attack #5 more difficult. Key diversification ensures that all cards have different keys, hence an attacker cannot benefit from the knowledge of knowing one key of another card to mount attack #5 on the target card. He needs to find at least one key of the target card and this requires at least one extra interaction with the card to perform attack #1 or #2, or to read out UID in order to then perform attack #3. Then the attacker needs to find the user of the cards back in order to perform attack #5.

Metal card holder
A user can protect (shield) his card by putting it into a metal holder. The card can then not be interrogated by an attacker as long as it is in the holder. This also holds against attacks #4 and #5 (as long as the card stays in the metal holder).

MIFARE Mini 320 byte Card IC MF1ICS20
MIFARE Classic Card IC MF1ICS50
MIFARE Classic 4 Kb Card IC MF1 IC S70
End to end system security risk considerations for implementing contactless cards