Mifare Ultralight Features and Hints

Multiple ticketing, secured data storage, implementation hints,
features and hints for a secured and optimized application development using mifare Ultralight cards.

Memory features
In addition to the user memory area the mifare Ultralight offers the features of an OTP1 area and lock bytes to lock the OTP and user area. The usages of LOCK bits are described in [M028630]. A mifare Ultralight dedicated 4-byte WRITE-command provides a high transaction speed. All the add-on features are dedicated to support special application functionality e.g. ticketing.

Using OTP memory for multiple ticketing
The 4 OTP bytes, which are pre-set to “0” at the delivery, can be set to “1” only once. This gives the possibility to interpret them as an irreversible counter. Therefore, the number of “1” bits in Page 3 can be considered as counter value. This counter can be
incremented by changing a bit from “0” to”1”. The counter cannot be decremented due to a “1” bit of Page 3 cannot be cleared. In this case this 4-byte offers a number of 32 states that could be used to allow a certain number of passing turn-styles.
Example:
An example of a four rides ticket is shown in figure 1. For this application a ticket issuing the OTP memory of the mifare® Ultralight has to be pre-set to “FFFFFFF0hex”.

Figure 1: Example of a four rides ticket

For every access, the 4-byte OTP (page 3) has to be checked and updated (as shown in Figure 2) to ensure the validity of the tickets. Using the same command flow the counter might be extended to a number of 31 times just by changing the initial memory content. E.g. “FFFFFC00hex” or “FC00FC00hex” might be used for a 10 times counter initial value, or “FFF00000hex” for a 20 times counter initial value, which has to be written into the OTP memory while issuing the ticket.

Figure 2: Ticket Counter Command flow
Remark:
With the initial value “00000000hex” for 32 times counter, the rotate left at the very first access check after selling the ticket has to be exchanged into another initial WRITE command.

Transaction Speed
Although the mifare Ultralight offers the 16-byte Compatibility Write command to be compatible with the mifare Classic environment, the use of the 4 byte Write command is recommended, if the application requires a fast transaction. The Write saves approximately 20% of the transaction time2 compared to the Compatibility Write, as can be seen in Table 1.

Command 4 pages 12 pages
REQA 0.4 ms 0.4 ms
Anticollision level 1 + 2 & Select 3.7 ms 3.7 ms
Read 2.0 ms 6.0 ms
Write 18.7 ms 56 ms
Compatibility Write 24.0 ms 72 ms
Halt 0.5 ms 0.5 ms
∑ (approximately) 25.3 ms 30.6 ms 66.6 ms 82.6 ms

Table 1: Transaction time
The transaction time2 as shown in Table 1 counts the time needed for
–the communication from the reader to the mifare Ultralight,
–the response time of the mifare Ultralight and
–the communication from the mifare Ultralight back to the reader.

Proposed Security Mechanism
Mifare Ultralight has been designed to support the faster application with the cheapest solution. Therefore it does not address any security feature except the unique identity (UID). From the application point of view this means, no authentication has to be performed and no key is needed. Performing a mifare authentication generates an error, and the mifare Ultralight goes back to the Idle (or Halt) state. But if requires, smarter secured application using mifare Ultralight can be created using
an intelligent reader with the respective application software. A lot of cryptographic technologies are available to assist you. One successfully implemented approach is demonstrated in the following sections. This approach uses a 16-byte Master key (Mk), which is used to add the confidentiality and integrity of the storage data.

Confidentiality of stored Data
As the mifare Ultralight pages can be read without any authentication, anyone can read the pages using any standard reader. But if the stored data is encrypted with a secured key then these are just some bytes to one who does not have the secret key and information regarding the encryption method. Therefore by storing the encrypted data in mifare Ultralight memory, one can add the confidentiality to the data itself. As an example a 3-DES [FIPS46-3] may be used for this encryption.

Datastored = f (key, dataorigin ,UID)

7-byte UID of the mifare® Ultralight has to be incorporated in the security system to confirm the uniqueness of the tickets and a 16-byte Master Key (Mk) has to be defined by the application provider. To decrease the threat on the Master key (Mk), for each card, a Card key (Ck) is derived from the Master Key (Mk) using the well known key diversification. The steps to be followed are:
–Expand the 7-byte UID,( 56 (7×8) bits (b55 – b0)) to 64 bits to get 8-byte extended UID (UIDe) by adding the odd parity (p) in the least significant bit position for each 7 bits as shown in table 2: (Byte0 to Byte7, 8 bytes are the bytes of UIDe whereas b0-b55 are the bits of original UID)

p7b55b54b53b52b51b50b49p7 p6b48b47b46b45b44b43b42p6 p5b41b40b39b38b37b36b35p5 ……… p1b13b12b11b10b9b8b7p1 p0b6b5b4b3b2b1b0p0
Byte7 Byte6 Byte5 ……… Byte1 Byte0

Table 2: Expanding of the UID to get UIDe

• Derive the Card key (Ck) as follows:
• Encrypt the plain data using the Card Key (Ck) in CBC (send) mode.
• Use standard initial vector (IV) of all ‘00’s, IV= “0000000000000000h”
• As DES works with 8-byte block wise, organize the data in multiple of 8 by adding the standard padding [ISO/IEC 9797-1] with all zeros ‘00h’. As example (‘xx’ is the data bytes ):

2 padding bytes: xx xx xx xx xx xx 00 00
7 padding bytes: xx 00 00 00 00 00 00 00

The complete scheme is shown in the following figures (figure 3 & figure 4):

Figure 3: Data encryption scheme

Therefore the data has to be decrypted after reading it from the card.

Figure 4: Data decryption scheme