Mifare DESFire

Security Strategy

This specification seeks to define a minimum set of requirements to support scheme interoperability. It does not seek to lay down specific rules for ensuring that schemes have adequate or appropriate security provision.

To promote interoperability at a basic level it is essential that all terminals are able to read the open data sets on the card without having to perform cryptographic operations. The only alternative to this approach is to mandate the use of SAMs for all terminals and impose a security regime that all schemes should follow. For open access it is essential that read access to open citizen applications and data is not protected by scheme specific keys.

PICC Master Key

Every DESFire card has a PICC Master Key. This is identified as key 0 at the card level which is identified as an application with an AID of 000000h. This key controls critical functions at the card level such as creating and deleting applications and changing PICC key settings. For scheme integrity it is important that this key is set and strictly controlled at the scheme level.

Application Master Keys

Every application can have its own Master Key which is identified as key 0 within that application. This key should be used to control the creation and deletion of files within an application. If this permission is not specified then the integrity of scheme applications may be compromised. To avoid the need for controlling a number of different application keys it may be practical to use the same AMK for securing data in all non-value citizen applications.

Proprietary Application Master Keys

Some applications which store or control value, such as e-purses or parking applications should have their own proprietary keys for write access. This is in line with published recommendations for other platforms. Schemes wishing to co-operate in the use of such applications would need to ensure that they share the same cryptographic secrets although this is often provided by a third party.

User Keys

Some schemes may wish to protect individual data items within applications so that read access is at the discretion of the card holder. With javacards it is possible to protect data with the use of PINs associated with individual EFs. This mechanism is not available on the DESFire although it is possible to map PINs on to single DES keys. This will lead to relatively weak DES keys being deployed but the level of security achieved is certainly not less than with a conventional PIN mechanism. How this mapping is achieved is a scheme issue.

Platform Compatibility

In order to accommodate a number of different DESFire platforms in a scheme where common access permission is required then only the basic Authenticate Command (0Ah) can be used. This is because the MF3IC40 platform does not support 3K3DES or AES cryptography. Security features must also be restricted to the use of TDES crypto in DESFire native mode.

The ITSO specification makes the same stipulation. See document [2].

Mifare DESFire 4K Pre-printed Card,Mifare DESFire EV1 4K Silk Screen Printing Cards,Mifare DESFire EV1 4K Blank White Cards,

In this example the same Scheme Key is used across a number of applications involving non-value transactions. It is highly recommended that Scheme Keys be diversified on a per card basis.

NB: Although inter-operability across all DESFire platforms requires the use of Native Mode, this does not prevent proprietary applications employing more secure cryptography such as AES on EV1 platforms where this is considered to be necessary.