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.

Mitigation of attacks on terminals
When the cards are properly protected using the methods described above, there are still attacks on terminals to take care of. The terminals need to hold the master key or master keys from which the diversified keys are computed. When a master key becomes compromised then an attacker can calculate all diversified keys of all cards. Below some methods are discussed to mitigate attacks on terminals.

Usage of a Secure Application Module (SAM)
The terminal must protect the master keys. A Secure Application Module (SAM) can hold keys and can on request perform cryptographic operations using those master keys, however not hand out the master keys themselves, nor the diversified keys.If an attacker would steal and reverse engineer a terminal, then he may be able to use the SAM to change the data on a card, but cannot extract the key to deploy this key on other equipment. And the SAM can be configured to have an upper limit on the number of operations that it can perform using the master key until it has to re-sync with the backend, which will not happen of course once the theft has been detected and the SAM got blacklisted in the backend system. Furthermore, the SAM can be configured such that it needs to authenticate itself towards the backend after power up. This means that an attacker who would steal the terminal and would drop power cannot use the SAM to modify cards. The MIFARE SAM is a chip that is designed to withstand a multitude of attacks. For this chip the same considerations regarding strengths of attacks holds as described before for the cards. However the complexity of attacking a SAM is even higher than for the MIFARE cards. Where the MIFARE cards that belong the system, e.g. in the case of AFC, can just be bought from the AFC operator in a large quantity (since it is sold to the general public), in case of the SAM every SAM needs first to be stolen from a terminal. Attacks where multiple devices are needed will hence be very complicated.

Use different master keys for different purposes
It can be that there are different types of terminals which can / need to be protected differently.Let’s assume an AFC system which has a great number of terminals placed at unmonitored platforms in train stations. Those terminals will only decrease the balance on the card. The system also has (many fewer) terminals placed in buildings where they are monitored. Those terminals are used to increase the balance on the cards, e.g. in transactions that take the users credit card. In such a system cards could be configured to allow decrementing the balance with one key and increment the value using another key (e.g. on MIFARE Plus X using value operations). In this case each card has a keyset consisting of two keys. Each of those two keys is derived from a different master key using (at least) the UID. The master key that is used to derive the diversified keys for the incrementing operation is only deployed to the terminals that are monitored.If an unmonitored terminal on a platform were stolen and reverse engineered and if a master key would be extracted, then this key can only be used for decrementing operations, which are not commercially attractive. The master key which is used to derive keys for the incrementing operation receives in this setup an extra layer of protection by being in monitored locations and potentially also by more tamper resistance of the terminals in which they are deployed. A higher level of tamper protection can be affordable because of the lower amount of those terminals used for incrementing. Finally it is good to have the master keys for updates of the keys/keysets to be different from the keys used for normal operation. Those master keys for updating would only have to be deployed in the field during a period of updating of keys, and only to a selected set of terminals where this updating takes place (the updating terminals).

What else is there to consider for designing a secure system?
Limiting attack opportunities

Although MIFARE DESFire EV1 and MIFARE Plus have been tested as part of their CC EAL4+ certification to be able to withstand attacks that make millions of traces of interactions with the card, it is wise to limit unusual behavior. E.g. if the same card is interacting with a terminal it is OK to accept several tens of failed authentications, which would be a legitimate case if someone moves a card slowly towards the terminal. However if many more failed authentications occur it is good practice for the terminal to stop the interaction with the card and at least log the event. This is only one of the examples of dealing with unusual behavior.

Checking of MACs
Request and check MACs that are used in the communication between the terminal and the card. Separate information is available on security considerations for the communication with the cards.

Relay attacks
MIFARE Plus X supports proximity detection, which can be used to counter relay attacks. In relay attacks the communication between a legitimate card and a legitimate terminal is relayed between the card on a distance (e.g. in another country) and the terminal. If proximity detection is not implemented then such an attack is likely to succeed. If proximity detection is implemented then the attack will fail if the distance is beyond a certain minimum limit. Also here it is important to limit the amount of trials that card can make with a certain terminal by letting the terminal refuse to interact with the card after a number (multiple tens) of failed authentications.

Privacy is a concern among several user communities. MIFARE Plus and MIFARE DESFire EV1 have several privacy protection mechanisms, one of them being the use of Random ID in the anti-collision process. See further the documentation of the respective chips.

Backend security
As said in the beginning of this document, the security that goes beyond the terminal is out of scope for this document. Those security threats include among others: The software integrity in the terminals. If an attacker is capable to download fraudulent software into the terminal he could let the terminal open the gate if a card out of a certain set is presented without lowering the balance on the card. Communication between terminal and backend. If an attacker can e.g. modify the blacklists or whitelists then this affects the security of the system.