MIFARE Classic

MIFARE Classic is the most widely distributed technology when it comes to physical access control and public transport ticketing. It consists of a memory structure and cryptographic keys used to access this memory structure. You can read more about MIFARE Classic here.
The Fidesmo Card supports integration into MIFARE Classic based infrastructures by emulating a MIFARE Classic card, and it can hold multiple virtual cards at the same time, although only one virtual card can be active at a single point in time. The activation and deactivation is carried out by the Fidesmo App.
The MIFARE Classic chip in the Fidesmo Card is a 4 kbyte card with a 4 byte UID. All virtual MIFARE cards within the same Fidesmo Card have the same UID. If you want to get started right away, you can follow our MIFARE tutorial.

How does MIFARE Classic work

MIFARE Classic is basically a memory area of either 1k or 4k in size. The memory area is divided into sectors and each sector into blocks. In the basic 1k version each sector consists of three 16 byte blocks and one 16 byte sector trailer.

Short MIFARE sectors.

The sector trailer is what makes MIFARE a secured memory area. Both “Key A” and “Key B” can be used to control read and write access of the sector. This is done by using the four bytes of “Access bits”. More information regarding how the “Access bits” work in detail can be found in section 8.7.2 of the MIFARE Classic specification.
As you might have noted, the figures shows sector #1 – #31. What is different with sector #0? basically block #0 of sector #0 is not accessible to the user, but has a factory encoded value, including the aforementioned UID of the MIFARE Classic card.
Some readers might also have noted that 32 sectors * (3 blocks + 1 trailer) * 16 bytes only sums up to 2048 bytes. What happens at sector #32? The sector format changes slightly here. Each sector instead have fifteen 16 byte blocks, but still only one 16 byte trailer.

Long MIFARE sectors.

The balance is restored. 32 sectors * (3 blocks + 1 trailer) * 16 bytes + 8 sectors * (15 blocks + 1 trailer) * 16 bytes is now equal to 4096 bytes.
It is important to be aware of this split between small and big sectors when working with a MIFARE Classic 4k card.


The way to interact with the MIFARE Classic card is via our RESTful API exposed in the Fidesmo backend. There are five endpoints:

  • mifare/get – Returns an existing virtual MIFARE card. If there isn’t any yet, it first creates one with a specified number of sectors. Any number of sectors from 1 – 40 are supported. A 1k card comprises 16 sectors and a 4k card comprises 40. There can be exactly one virtual card per application and only that application has access to it.
  • mifare/initialize – Initialize sector trailers of a virtual MIFARE card
  • mifare/read – Read blocks from the virtual MIFARE card
  • mifare/write – Write blocks to the virtual MIFARE card
  • mifare/delete – Delete an existing virtual MIFARE card

The different endpoints are described in detail in the API documentation. Here we will instead focus on how they can be used together to implement a complete MIFARE service. All MIFARE services will need to follow a similar pattern:

  1. Use mifare/get to get the virtual mifare card. The response results in two different paths:
    • If the newCard flag is “true”, use the mifare/initialize endpoint to initialize the sector trailers with Key A, Key B and the Access bits.
    • If the newCard flag is “false”, the card is already present and no initialization is required or possible.
  2. After this, it is possible to use the mifare/read and mifare/write endpoint. Use those to read or write any data that you require for the service delivery. It is recommend to always check the state of the card before overwriting it, since it might have been changed over the MIFARE air interface since the last service delivery. If the virtual card is accessed over the air interface during the service delivery all mifare operations will fail until a new mifare/get is issued.

A typical flow when working with a virtual MIFARE card.

Note that reading and writing is only for sector blocks. Sector trailers can never be read nor written and the mifare/initialize endpoint is strictly write only. This is to prevent Key A and Key B from being returned. In fact, these keys are never visible outside of the Fidesmo Card after a successful call to mifare/initialize.
Optionally, a Service Provider may also delete a virtual mifare card (e.g. if a virtual card with more sectors are required). This is done using the mifare/delete endpoint. Note that this endpoint does not require the mifare/get endpoint to be called first. It just removes the virtual card if there is one.

Updating MIFARE keys

Since the mifare/write operation cannot be used to overwrite the sector trailers with new keys, it is necessary to use the mifare/initialize endpoint. Updating MIFARE keys is equivalent to re-creating the MIFARE Classic virtual card, so we recommend the following sequence:

  • Get hold of the virtual card using mifare/get
  • Read its contents with mifare/read
  • Set the new MIFARE keys by means of mifare/initialize
  • Write the virtual card contents previously read, using mifare/write

MIFARE keys cannot be modified using MIFARE Classic commands through a reader, only using our API. This avoids many potential synchronisation issues.

How does it work?

In the background the Fidesmo Card is using an application that comes bundled with the card. This talks to an embedded MIFARE Classic resource on the card. When we are communicating with the MIFARE Classic chip from the mobile phone (either from the Fidesmo backend or locally from the mobile phone), we are thus communicating over standard NFC. Our solution can hence be used on all NFC capable Android phones.
All MIFARE data communicated between the Fidesmo Card and the Fidesmo backend is also encrypted using Secure Channel Protocol 02 (SCP02) from GlobalPlatform. This means that data from the card such as MIFARE keys are never visible in an unencrypted format in the mobile phone. There is end to end security all the way from the Fidesmo backend servers to the application within the card.