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

Countermeasures
The table below indicates possible countermeasures for each type of chip. Note that all countermeasures are meant to be general guidelines, that they have their limitations and that they are not meant to be complete. Therefore please note that it is customer’s responsibility to come to conclusions as to what and how to implement.

Table 2. Applicability of countermeasures per card IC type
Countermeasure MIFARE Classic MIFARE Classic emulation in SmartMX MIFARE Plus in MIFARE Classic mode Other MIFARE Classic

implementations

(non-NXP)

         
Countermeasure against restoring an old state on the same valid MIFARE card: use a decrementing transaction counter; variation A Yes Yes Yes Unknown, depends on implementation
Countermeasure against restoring an old state on the same valid MIFARE card: use a decrementing transaction counter; variation B No Yes No Unknown, depends on implementation
Distribution of authentication data No No Yes Unknown, depends on implementation
Infrequent access to partial authentication data No No Yes Unknown, depends on implementation
Provision to check if card is genuine No No Yes Unknown, depends on implementation
Modify block after reading Yes Yes Yes Yes
Expose faked keys at unauthorized moments and locations Yes Yes Yes Yes
Block cards after incomplete transactions Yes Yes Yes Yes

Countermeasure against copying of one card to another: cryptographically bind card contents to the UID.
As mentioned in section 3.1 there is a possible defense against attacks that would copy data from one MIFARE Classic card onto another: cryptographically bind the data to the UID.
This countermeasure should stay effective even once the latest attacks from Radboud University Nijmegen (see attacks #4 and #5 in chapter 2) become practical.
This countermeasure would become ineffective once some company would produce counterfeited MIFARE Classic (emulator) cards that would allow programming the UID.

Countermeasure against restoring an old state on the same valid MIFARE card: use a decrementing transaction counter
The essence of the countermeasure against restoring a card content back to a previously valid state is to have an element on the card that cannot be restored and to cryptographically bind all the data on the card to that element.
That element can be created as a counter in a value block which is initialized to the highest possible value and which will then be configured in a way that only Read, Decrement, Restore and Transfer operations are possible.
For this implementation it is important to take measures for anti-tearing protection. If a card is removed from the field before the write command has been completed, the counter may be corrupted and it must be possible to recover from that situation.
The following is a mechanism that is a defense against this attack and provides antitearing protection.
This countermeasure has two variations, which differs in the first part only (how the card is setup). The first mechanism should be effective on all chips, but puts more restrictions on the usage of the card. The other comes with less restrictions, but is only applicable to some cards.

Variation A working for all (NXP) chips:
Reserve two blocks on the card to be value blocks for this purpose and there must be no other value8 block on the chip.
–This means, do not allow increment, decrement, restore or transfer on any other block. Therefore the access conditions C1C2C3 <> 000, C1C2C3 <> 110 AND C1C2C3 <> 001 should be set for all other blocks. Please not that this must only be done after writing the data to the chip as described below.
–Lock the sector trailers of all sectors in such a way that the access conditions can never be updated anymore. E.g. C1C2C3 = 111 (no modification possible). It is important that C1C2C3 <> 001, C1C2C3 <> 011 and C1C2C3 <> 101.
–Continue with the common part below.

Variation B working for a selected set of chips (see Table 2):
–Reserve two blocks for this purpose in a sector. There must be no other value block in this sector.
–Do not allow increment, decrement, restore or transfer on any other block in the sector. This means C1C2C3 <> 000, C1C2C3 <> 110 AND C1C2C3 <> 001.
–Lock the sector trailer of this block in such a way that the access conditions can never be updated anymore. E.g. C1C2C3 = 111 (no modification possible). Please note this must only be done after writing the data to the card as described below. It is Important hat C1C2C3 <> 001, C1C2C3 <> 011 and C1C2C3 <> 101.

Common for variation A and B
–Use these two blocks for counters Cnt1 and Cnt2
–Initialize Cnt1 and Cnt2 to the highest possible value.
–Set the access conditions for the two blocks to C1C2C3 = 001 (only allowing Read and Decrement, Restore, Transfer)
–Put all the application data on the card. Note that for reasons of anti-tearing it will be needed to take measures that there is enough redundant data on the card for incomplete data to be recovered. That is however not new and different mechanisms exist and are therefore not further addressed here.
–Calculate a MAC over the data and over the value of the counter as held in Cnt1 and Cnt2. Also include the UID in this MAC to avoid copying to other cards.
–Write the MAC to the card as well.
 
Once the card is initialized as described above, this is the usage in the normal operation
–Read the values of Cnt1 and Cnt2. Process an error routine (see below) if the values are not identical or not readable as value block.
–If Cnt1 and Cnt2 = 0, then the card has been exhausted and needs to be replaced.
–Read the data information from the card and also read the MAC
–Compute a MAC over the (error corrected) data, UID and the value of the counter
–Compare the MAC that is calculated with the MAC that was read from the card. If not the same then the card was last time taken out of the field after the –MAC was written but before the counters were written, or the card has been tampered with. Execute the error routine below.
–Make the update of the data on the card
–Calculate the new MAC over the new data and Cnt1 – 1 (equals Cnt2 –1)
–Write the new MAC to the card
–Decrement Cnt1 (using Decrement and Transfer) by 1
–Decrement Cnt2 (using Decrement and Transfer) by 1

Error handling
–If Cnt1 = Cnt2 – 1 and the MAC matches using the value of Cnt1, then decrement Cnt2 by 1 (using Decrement and Transfer). Apparently last time Cnt1 was updated, but Cnt2 was not.
–If Cnt1 is not readable as value block and the MAC matches using the value of Cnt2 –1, then use Restore from Cnt2 followed by Transfer to Cnt1. This puts the right value back in Cnt1. Last time apparently the card was taken out of the field while updating Cnt1 and this corrupted Cnt1.
–If Cnt2 is not readable as value field and the MAC matches using the value of Cnt1, then use Restore from Cnt1 followed by Transfer to Cnt2. This puts the right value back in Cnt2. Apparently last time the card was taken out of the field while updating Cnt2 and this corrupted Cnt2.
–If Cnt2 = Cnt1 then calculate the MAC using Cnt1 + 1 (=Cnt2 + 1). If this matches then the card was last time apparently taken out of the field after the MAC was written, but before the counters were written. In that case
-Decrement Cnt1 (using Decrement and Transfer) by 1
-Decrement Cnt2 (using Decrement and Transfer) by 1
–If Cnt1 and Cnt2 both are unreadable or if Cnt1 and Cnt2 differ other than Cnt1 = Cnt2 –1: the card has been tampered with.
This countermeasure will also stay effective against the new attacks from Radboud University Nijmegen (see chapter 2). This countermeasure is courtesy to contributions of Radboud University Nijmegen, HID Global and TNO ICT.