Design an Access Control System based on Mifare DESFire EV3 NFC-tags

An Access Control System is mandatory for each company or authority building. In former times the access was based on keys that were issued to employes. The next step was to use NFC tags like the Mifare Classic tags that are still in use in many hotels, although the encryption scheme of these cards was broken many years ago and they are insecure to use. One of the most modern NFC tags is the Mifare DESFire tag, available in generations EV1, EV2 and EV3. If you need more information about the tag visit the company’s website.

Mifare DESFire is a trademark of NXP Semiconductors N.V., Netherlands.

Purpose of an Access Control System (ACS)

An ACS has to take care of the following tasks:

• only persons with a “permit” are allowed to enter the room or building
• the entry is done in a defined timeframe or period of time
• deny the access when the access right is withdrawn

Here are some definitions about the wording: usually a building has several rooms and in an ideal world each room has a lock that needs to be opened. But do we need an individual access right for every room ? The answer is “no”, it should better to talk about “door groups” (see below for an explanation and example).

The access is granted to persons, but do we need individual rights for every person or are there better solutions ? The answer is: we should talk about access profiles instead.

Screenshot of the Door Opener Application showing that the access is granted

ACS for an university as example

Let us take an university as a simplified example for an ACS and we will think about the rights for 3 groups of people:

• Group A: Students (are allowed to enter the building and visit the lecture rooms)
• Group B: Teachers (are allowed to enter the building, lecture rooms and the teacher area)
• Group C: Technicians (are allowed to enter the building, lecture rooms and the rooms with technical equipment)

For this example we will use 3 door groups:

• Door group 1: building and lecture halls doors
• Door group 2: teachers area
• Door group 3: technical equipment rooms

Time-framed Access

Let us assume that the students need an access right from Monday to Friday between 7 and 19 clock (7 am to 7 pm). A teacher needs an access during the same time-frame as the students, but of course need time for preparation and necessary rework… and sometimes on the weekend as well. Last but not least, technicians need an all day access, as the planned maintenance may take place on the weekend and during night, but immediately repairs may happen all the day. In the end we are talking about these time profiles:

• Students: Monday to Friday from 07–19 clock
• Teacher: Monday to Sunday from 06–20 clock
• Technicians: Monday to Sunday every time

Technical Equipment (NFC sensors)

Each access controlled door needs a NFC sensor (or “reader”), a controller unit and an electrical door opener that releases the door lock. The controller unit can be centralized or available at each sensor. The “central” solution may be cheaper, but this depends on the permanent availability of the network. If this network is “down” no more access is possible (think of the technicians that arrive in the night to solve the problems, but do not get any access to the building). For this reason you should consider of intelligent controller units that can indepentely decide about granting or denying any access to the room.

Using a Blacklist or Validity time-frame

Granting an access is easy, but how can we withdraw an access right ? An access card is usually issued by the HR department (teacher and technicians) and the students office for students. You visit the office and get the access card. For the withdraw workflow we need to deploy the information about the blocked card — this can be done by a network (much preferred) or a special “blocking card” that contains the identification data of the blacklisted card and has to be manually presented to each reader (offline deployment). Another way could be the usage of a Validity timestamp on the tag — any access is granted only between the first and last date. Btw: the Blacklist comcept is not realized within the sample apps.

Logfile usage

A NFC based ACS easily allows to log or monitor the access to every room. The logging takes place on every usage when tapping an access card to a sensor, additionally the logging can get stored in parts on the DESFire tag as the tag supports a Cyclic Record File.

That was much of theoretical stuff, let’s dive into the practical section.

Necessary apps for an ACS

We need 3 apps for the 3 areas of responsibility:

• app for issuing and maintenance of Access Cards (read and write access to the tag)
• app for students and/or a kiosk for informing about the granted individual access rights (read access only)
• app that runs on the controller at the door (read access, optional a write access for offline updates of thetag data)
• (optional) using an app on an Android device for the Host-based Card Emulation of a DESFire tag. This feature is NOT available on iPhone devices, because Apple does not grant the access to the NFC system.

For test purposes I’m providing sample apps for these purposes (just debug-apk’s without source code, for downloading see the links at the end of the article).

Issuing and Maintenance Application

The lifecycle of an access right starts by issuing a tag with the rights stored on it. That usually takes place in the Human Rights (HR) department or in the Students Office where the NFC tag gets personalized. The sample app contains an application (app identifier “ACCEC0”) that has 5 files in total:

• File 00: identity data (card holder name and ID; Card UID), stored in a Standard File
• Files 01, 02, 03: access rights for door groups 1, 2 and 3, stored in a Standard File
• File 04: a Cyclic Record File for logging purposes (stores the last 10 usages of the tag)

The access rights files contains informations in which time-frame and on which days the access is granted (Monday to Friday and Saturday and Sunday). Additionally a Validity Period is given in between the access is possible (first and last date).

The data is stored in pure UTF-8 encoded, human readable data. A production system will encode the data in full binary form.

Let’s have a look to the data stored in the files.

File 00 contains identity data of the card holder and the tag in use:

Students Name   |11223344|041a5dc2d37580

Name of the tag | student| 7 bytes real
holder          | identNr| card UID

File 01 holds the access rights for door group 01 (e.g. building entry doors):

10|07:00|17:00|06:00|20:00|10.03.24|31.03.24
|checkbox Mo-Fr enabled
 |checkbox Sa+Su enabled
   |Mo-Fr. From
        |Mo-Fr To
              |Sa+Su From
                    |Sa+Su To
                          |Validity Start data
                                   |Validity End Data  

Files 02 and 03 hold the access rights for teacher’s and technician’s rooms — as a student don’t have access the first 2 characters are set to “00” and the validity dates at the end are set to “00.00.00”:

00|07:00|17:00|06:00|20:00|00.00.00|00.00.00
00|07:00|17:00|06:00|20:00|00.00.00|00.00.00

The last File 04 is a Cyclic Record File holding a maximum of 10 entries (“records”). A Cyclic Record File stored new entries up to the maximum limit of records, if a new record needs to get written the oldest one gets deleted (“cycle”). This file type is the best way to store logfiles on the DESFire tag.

01|17.03.2024 12:49:12|00Granted
02|17.03.2024 12:54:59|00Granted
03|17.03.2024 12:55:03|04NSaSuAc
|door (group) number
  |timestamp of tag tapped to the reader
                      |2 character status code
                         |short explanation

Each line represents a logfile entry, documenting the door (group) and the timestamp when the tag was tapped to the reader. The next part is the 2 characters access status code (“00” means the access was granted, all other codes show that the access was denied for several reasons. The last 7 characts give a short explanation of the reason for granting or denying.

Application description

1. The first action is to tap a Mifare DESFire tag to the NFC reader. If the tag was never used for this system the application “ACCEC0” is created and in this application the 5 files (see above) are created as well.
2. If it is a blank card enter the cardholder name und his/her identification number, e.g. the employee or students ID. The Card UID is filled by the app and contains the real Card UID.
3. Choose a “Time Profile” template (“Student”, “Teacher” or “Technician”) or enter the individual data in the following form (see the right screenshot above).
4. Enter a validity period (“Valid From” to “Valid To”) for the access rights. The entered dates are valid for all doors.
5. For each Door Group en- or disable the access on the two slots “Monday to Friday” and “Saturday and Sunday”). Change the times “from” or “to” to your individual settings.

When your changing the data in steps 4 or 5 the button on the top changes its color from blue (“read mode”) to red (“write mode”). The next time you are tapping the tag to the reader the updated information is written on the tag:

If you don’t like to write the changed data simply click on the button and all changes are reset.

When you are in “read mode” and tap the tag to the reader, a short summary about the information on the tag is shown:

Left side: access rights before changing, right side after changing the access right for door group 03 (the “Monday to Friday” access was enabled)

Door Opener Application

As already written this is a sample application showing a behavior of a real tag reader at a real door. Select a Door Group Number (1..3) and tap a tag to the reader. Depending on the access rights stored on the tag the access is granted (written in large green letters) or denied (written in large red letters), followed by a short information about the reason in case of a “non open” verification):

Please note: although it is a sample application it is working real time, meaning: if the actual time (“Timestamp”) is not in the allowed timeframe for this door and day slot we receive a “Denied” verification result.

The last option is to click on “Logfile” and tap the tag to the reader — now the card holder gets an updated logfile presented in the form below:

Just a note: there are 2 entries with a ”NO ACCESS” result, meaning that the card was updated using the Maintenance Application.

Card Holder Application

This is just a simple service app that can run on the Android devices of card holders or a kiosk inside the building, show the stored access rights and logfile data on the tag:

This application does not have any write rights and is for information purposes only.

Frequently Asked Questions (FAQ) section

• How is the data secured on the tag ? The security concept of a Mifare DESFire tag is one of the best available. Each read or write access to a file within an application is secured by a key. We could setup the file to be read- or writable without a key by using the magic key number 14 (“0Eh”). All files on the tag do not run this insecure setup, we are using different keys for different tasks: combined read & write access with key number 1, read access using key number 3 and write access is possible using key number 4.
• What algorithm is used for the keys ? The app is using the AES algorithm with 16 bytes key length (“AES-128”).
• What communication mode is used for file access ? The complete communication including storage is done in Plain Communication Mode. For a real world application I’m recommending the “Full Encrypted Communication Mode”, but for the sake of easy reading I stayed with the Plain mode.
• What keys were used within the app ? I’m using the insecure way of simply using the default keys (“00000000000000000000000000000000h”). In a real world application you have to personalize the keys by your individual ones, but for this task an addition step (“change key”) needs to get performed (skipped for simplicity).
• Can I view the data on the tag ? The most easy way is to use the Card Holder Application for this task, but if you are using a Mifare DESFire app (e.g. my “Mifare DESFire Beginner Tutorial App”) you are been able to read and write to the Standard Data Files (file numbers 00 to 03) on the tag by using the default AES key. Please note: change of the data on the tag outside the Maintenance App can lead to undesired behavior or crashes, so please do not write to the tag !
• Are there other issues with the tag setup ? Yes, for the sake of simplicity I nether changed (“personalized”) the application keys nor I changed the Master Application Key (it is still the “fabric” default DES-key). Another “issue” is to not change the application settings to prevent the listing or deletion of files without authentication with the Application Master Key.
• Is the source code available ? I’m sorry, but I’m providing the apps as Debug Applications (“APK-files”) only.
• Do the apps run on my Android device ? I compiled the apps for (minimum) Android 6 (SDK 23) up to Android 14 (SDK 34) using Android Studio Iguana | 2023.2.1 and Open JDK 17.0.9+0–17.0.9b1087.7–11185874 aarch64. Of course — your Android device needs a NFC reader unit to operate.
• Can I use an app to emulate real tags ? Of course, as long as you stay on Android you are beeing able to emulate a real DESFire tag by using Host-based Card Emulation (“HCE”). I have already done this within another project and I can confirm — it is possible to exchange the real Mifare DESFire tag with a HCE emulated one and the Access Control System is still running like a charm.
• What source do you recommend to learn how to work with DESGFire tags ? Well, I recently published a tutorial for this purpose here on medium.com (“Mifare DESFire EV3 — a beginner tutorial (Android Java) using the DESFire for Android tools”).
• I do have a real Mifare DESFire EV1 / EV2 / EV3 tag — does the applications work with my tag as well ? As my apps are downwards compatible to generation EV1 the apps will work with generations EV2 and EV3 as well.
• Where do I get the sample apps ? All 3 sample apps are available for download on my GitHub repository — you will find 3 folders with the ready to use apps (“.apk files”): AccessControlSystemDESFire (https://github.com/AndroidCrypto/AccessControlSystemDESFire)

Happy coding !