System level security measures for MIFARE installations
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).