Mifare Plus in a nutshell

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).

Security Levels

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.

Why one shouldn’t trust card’s serial number

Both ISO 14443 and ISO 15693 mandates that the contactless/proximity cards or tags all have a ‘more-or-less unique’ physical identifier, that is required to identify the card or tag during the initial discovery process (and during the anti-collision loop when there’s more than one card in the field).

This identifier is called UID in 14443-A and in 15693, PUPI in 14443-B. But whatever the name, we write ‘more-or-less unique’, because nothing mandates this identifier to be actually unique (PUPI stands for Pseudo-Unique PICC identifier). Sometimes it is a random number, sometimes a fixed number shared by a large set of cards. More than that, nothing makes it technically impossible to have two cards with the same physical identifier.

Anyway, in the early years of 13.56MHz technologies, a lot of systems have been designed that use this physical identifier as the only ‘key’ to recognize either a human (the card holder) or an object (RFID-tagged). Nowadays, a lot of systems still rely on this ‘key to access services or to claim credentials. This could be loyalty coupons, stadium or gymnasium entry, physical access control, whatever service where the physical identifier is the pointer to some database records.

SpringCard has always adviced its customers not to rely on the physical identifier for any ‘serious’ application, where someone could steal money or enter a place he shouldn’t simply by cloning a physical identifier, because  it has been known for years that ‘forging’ a physical identifier is not difficult for the man of the art :

  • Tools used in the laboratories or for production (Micropross or SmartWare to name a few) are able to emulate any card, and require no specific skills (just some money anyway),
  • Tools used by RFID-enthouastics (or RFID-hackers) such as ProxMark iii or OpenPICC are able to do the same just by writing a few lines of code – and they cost almost nothing,
  • NFC chipsets are now widely available. As a ‘good-practice’, their manufacturer don’t let the user define freely all the bytes of the identifier when running in card emulation mode, but I wouldn’t bet that no backdoor exists to overcome this.

Anyway, it is generally admitted that the risk was ‘acceptable’ in most situations, mostly because the tools that may emulate a card don’t look like a card, so any visual inspection of the card (or just a human presence or a camera nearby) is likely to prevent the fraud. But this is not true, as we’ll see now.

Atmel has a family of contactless memory cards called CryptoRF. The biggest one is a 8-kB card called AT88SC6416CRF. Note that the very-first page of its datasheet clearly says ‘User-defined Anticollision Polling Response‘. It looks like Atmel has opened Pandora’s box, making it possible to put any physical identifier in their cards – in other words, making it possible to clone very easily any physical identifier (and of course, as they are real cards, they can be printed to look just like the genuine one).

Here’s a step by step demo (it has been done using ‘console’ access to SpringCard Prox’N’Roll running in legacy mode, but this is transposable to any product supporting ISO 14443-B). We use two cards to demonstrate how we clone the identifier :

  • The ‘source’ card is a ‘Mobib’ card (Calypso-compliant, STIB network),
  • The ‘target’ card is an Atmel AT88SC6416CRF. It is totally blank (out of factory), and one may get free samples rather easily at Atmel’s.

Mobib card

1. We retrieve launch the card discovery process (‘poll’ command) and retrieve the PUPI of an ISO 14443-B card. This is our Mobib.

CryptoRF card

2. Let’s do the same with our Atmel memory card. Out of factory, they all have the same PUPI : FFFFFFFF.

3. We send three  commands to the cards :

– a. we select the card (this is an ATTRIB, but we do not use the ‘attrib’ command as the card is not T=CL compliant),

– b. we select the first user zone (seems to be required before trying to access system zone),

– c. the system zone is write-protected, we gain access by sending the password (default password specified in datasheet).

4. Et voila ! The Atmel card has exactly the same identifier as the genuine Mobib.

Note that we should have also changed the protocol bytes that follow the PUPI in card’s ATQB. This would have only required one more command.

So, the moral is, never trust the identifier returned by the card. Even the database-centric architectures shall implement a decent dynamic authentication between the card and the ‘system’ (application, server, SAM, whatever) to ensure a decent security level.