Following the breakdown of Mifare Classic security, NXP has released a new generation of contactless cards to fill the gap, the Mifare Plus. To ease the migration of the existing applications, this new chip keeps the memory model of the Mifare Classic : the card is structured as an array of 16-byte blocks, and the blocks are grouped into sectors of 4 or 16 blocks. The security (authentication and access control) is done on a per-sector basis. The two benefits of Mifare Plus are its new security scheme (EAL 4+ certified), based on state-of-art AES cipher with 128-bit keys, and its optional Random-ID for ISO 14443-3 anti-collision, useful to address card-holder-privacy concerns.
Type X or type S
Mifare Plus comes in two types.
Mifare Plus X is the full-featured product, allowing end-to-end AES-ciphered communication and a so-called ‘Proximity Check’ feature that makes it possible to prevent relay attacks, by measuring precisely the time elapsed between reader’s commands and card’s answers.
The command set of Mifare Plus X includes a function to select one-out-of-many Mifare Plus ‘Virtual Cards’ that could be emulated by a single NFC device.
Mifare Plus S is a lightweight version of the product, optimized to be a cost-effective drop-in replacement for Mifare Classic. It doesn’t support the ‘Proximity Check’ and has only limited support for the ‘Virtual Card’ scheme. More than that, it doesn’t support the Security Level 2 (see below).
The Mifare Plus has four different modes of operation, known as ‘Security Level’ 0, 1, 2 and 3. The Security Level is a static parameter of the card, the reader application can’t decide to operate the card arbitrary at one security level or at the other, it must operate the card given the card’ Security Level . Using a specific AES-secured exchange, the application may switch the card from one Security Level to a higher one, but this operation is not reversible (it is impossible to go from one Security Level to a lower one).
Security Level 0 is the out-of-factory configuration. In this mode, the card is not secured at all, and even not usable to store data. Before all, the AES keys to be used all among the card’s life-cycle must be loaded, and the card must be switched to a higher Security Level. Pay attention that all the AES keys are transmitted in plaintext, so it is very important to do this personalization step in a trusted environment.
In Security Level 1, the Mifare Plus emulates a plain-old Mifare Classic. This gives the opportunity to replace existing Mifare Classic cards without the need to replace the readers or the handler applications. But as the card keeps on using the broken CRYPTO1 cipher, the security of the system is not better… Yet an optional AES-based 3-pass authentication makes it possible to check whether the card is a real card and not an emulator, but per-se it doesn’t protect the data from unauthorized reading or modification.
In Security Level 2, the Mifare Plus uses the CRYPTO1 stream cipher just as Mifare Classic, but instead of using static 6-byte Mifare keys, the keys are generated dynamically by an AES-based 3-pass authentication. This is said to combine the security of AES with ‘the speed of CRYPTO1’. Anyway, in a typical architecture, the CRYPTO1 is implemented in the reader (by the NXP RC chipset actually) where AES is implemented in software on a very fast host computer. The gain in speed of ciphering remains small towards the overall bandwidth of the card-to-application channel; it may even be not significant enough to balance the added exchanges (loading of the CRYTO1 key into the reader after every AES authentication). Also, the Mifare Plus S doesn’t support the Security Level 2.
In Security Level 3, the Mifare Plus doesn’t use CRYPTO1 anymore, but only AES. The new features (optional Random-ID, Virtual Card, Proximity Check) are available only at this Level.
Note that in Level 0 as in Level 3, communication is standard-compliant (ISO 14443-4 “T=CL”) where Security Levels 1 and 2 uses legacy Mifare frames (ISO 14443-3 type A).
Compliance between SpringCard contactless readers and Mifare Plus
Whatever the Security Level, all SpringCard contactless readers are fully able to communicate with the Mifare Plus chips (anti-collision loop and retrieval of UID, ISO 14443-3 A or ISO 14443-B communication protocols).
In Security Level 1 and 2, as the Mifare Plus’ UID is 7-byte long where the UID of a Mifare Classic is only 4-byte long, an upgrade had to be written in the CRYPTO1 authentication algorithm. This is available in firmware version 1.51 and newer. Earlier versions must be upgraded to be able to read and write data on a Mifare Plus at Level 1 or Level 2.
Using the card in Security Level 1 means only calling some functions embedded in the reader (Mifare Classic function set), but the other Security Levels involve a new function set (AES authentication, ciphering and MACing, read and write commands on top of T=CL) that has to be implemented in the host computer. This requires a major redesign of the host applications. If the host is a microcontroller with limited resources, adding support for Mifare Plus could be difficult or even impossible without changing the hardware.
SpringCard APIs for Mifare Plus
As is has already been done for Desfire and Mifare UltraLight C, SpringCard has developed a convenient software library to ease the development of applications using Mifare Plus cards. This library is available as both as source code and as binary in the latest SDKs (PC/SC and SpringProx Legacy), together with a small sample software that shows how to personalize the card in Level 0, to change the Security Level (0 to 1, 1 to 2 or 3, 2 to 3) and to operate the card in Security Level 3, including
- AES authentication (and generation of the session keys for ciphering and MACing)
- Read and write functions with various options
- Virtual Card feature
When the card is at Security Level 1, the existing samples for Mifare Classic could be used unchanged. The Security Level 2 is not implemented, as it isn’t available in Mifare Plus S that is expected to be the most frequently chosen one.
Documentation of the API is available online :
Choosing between Mifare Plus, Desfire EV1 or Mifare UltraLight C
The NXP Mifare family has now 3 contactless smartcards using ‘modern’ cryptography schemes for improved security.
Desfire EV1 is a full-featured microcontroller-based card, featuring 3DES and AES cryptography, a structured memory model (files within directories), and partially compliant with smartcard-standards (ISO 7816-4). Available capacities are 2KB, 4KB or 8KB.
Mifare UltraLight C is a low-cost wired-logic card with only 140 bytes of memory (the typical target is the market of disposable contactless tickets). A single 3DES key makes it possible to ensure that the card is genuine.
Just in-between, the Mifare Plus has a flat memory model (blocks) but with a good isolation between sectors, 2KB or 4KB of storage, and AES cryptography. The key advantage is the memory mapping that is the same as Mifare Classic, so existing applications that store data in the cards may be upgraded without major changes in their logic (yet changes in the security scheme and in the command set are not trivial…). But on the other hand, if the only need is to have a serial number or to store a small amount of data, Mifare UltraLight C does the job perfectly and is cheaper. As for Desfire EV1, its compliance to 7816-4 standard is the key in interoperable schemes (including future uses of NFC phones to emulate contactless cards), where the two other products remain totally proprietary.