NXP MIFARE DESFire Protocol
The following information has been extracted from this document
https://github.com/revk/DESFireAES/blob ... ESFire.pdf
Testing can be performed using the PN532 NFC RFID Module
https://www.electroschematics.com/nfc-r ... ule-pn532/
Arduino Library for testing the PN532 NFC RFID Module
https://github.com/elechouse/PN532
Extract of the Document
This document is reverse engineered from various sources and may not be 100% correct.
Overview
It is useful to understand what these cards/fobs can do for you!
The card itself has some top level settings, but the idea is that the card can be used with one or more applications.
This means the same card can be used for travel, access control, currency, all sorts.
Each application is independent of the others on the card and is identified by a 3 byte application id (AID).
So you select the application you want, and then you can access files that are stored relating to that application.
In practice this sharing of applications may not happen generally as someone will own the card, but it can in theory.
With access control I have each site as an application and so one card can work multiple sites independently, which is convenient.
The files within an application are small data storage areas, and there are actually several types of file.
The card itself has a total capacity (e.g. 4k), but typically the data stored is small, such as a value or identity.
The different types of files include values (e.g. points or currency), or simple binary data, or records of fixed length.
One of the clever features is a record file that automatically overwrites the oldest entry when full, ideal for some sort of log of events.
There is also a system to ensure integrity (e.g. backup files, and a commit stage after setting up changes).
The files themselves have access permissions controlling read and write and change.
The access control is done using keys. Each application can have one or more keys. You select the application and then authenticate with a key.
Having done this, the access rights you have depend on what key you used.
There are also application level access controls and controls on the top level card itself.
Each application can have unto 14 keys (a master key and up to 13 others), and the top level card has a master key as well.
These keys can use DES, 3DES, or AES encryption.
This manual only covers AES. Note, only symmetric authentication exists, i.e. card and reader need same key, and there is no support for public key where one side can check the other without knowing its secret key.
This is a security consideration, as extracting a key from a reader or code means you can make cards that match that key, so consider not storing keys in flash/EEPROM, etc.
The card also allows encryption of the communications, so you cannot snoop data passively when a card is being used.
There are also a number of different types of cards with different storage and features.
I am testing using the DESFire EV1 4k cards.
Mifare DESFire Protocol
Communications
I am assuming you have a way to talk to the card.
I am using a PN532 which handles the RATS and anti collision and selecting the card and so on, and gives me a 4 or 7 byte card ID.
I can then do an InDataExchange which allows me to send a command sequence of bytes and get a response sequence of bytes.
Each command starts with a one byte command code, and may have a number of data bytes following depending on the command.
The simplest command is one byte only, e.g. 60 gets version details of the card.
I will be quoting bytes using hex within this document, so that is 0x60.
Each response starts with a one byte status code, and may have a number of data bytes following depending on the command and response.
The simplest response is one byte, and 00 means success.
There is a way to wrap these commands in an ISO message format, and to perform ISO equivalent versions of commands, which may be better.
But this document is trying to cover the native DESFire commands and how they work.
It is important to also realise that there is a whole process to authenticate or encrypt the message and response payloads, explained later.
This is important to ensure communications cannot be snooped on.
I am assuming you have a way to talk to the card.
I am using a PN532 which handles the RATS and anti collision and selecting the card and so on, and gives me a 4 or 7 byte card ID.
I can then do an InDataExchange which allows me to send a command sequence of bytes and get a response sequence of bytes.
Each command starts with a one byte command code, and may have a number of data bytes following depending on the command.
The simplest command is one byte only, e.g. 60 gets version details of the card.
I will be quoting bytes using hex within this document, so that is 0x60.
Each response starts with a one byte status code, and may have a number of data bytes following depending on the command and response.
The simplest response is one byte, and 00 means success.
There is a way to wrap these commands in an ISO message format, and to perform ISO equivalent versions of commands, which may be better.
But this document is trying to cover the native DESFire commands and how they work.
It is important to also realise that there is a whole process to authenticate or encrypt the message and response payloads, explained later.
This is important to ensure communications cannot be snooped on.