Purpose
For the UTA project using the Mifare Ultralight smartcard, the Card Manufacturer will write application data onto each Ultralight at card manufacture time. For auditing and security reasons, the cards shall not be delivered to UTA in the default condition described in the MF0ICU1 Functional Specification MIFARE Ultralight [5].

This document defines the data that the Card Manufacturer shall write to the Ultralight cards, and thus the state of the EEPROM memory when the Card Manufacturer delivers the card orders.

This document is written primarily for the Card Manufacturer, who will write the application data to the cards. It may also be used as a reference by developers who will design, implement or maintain code that will use the application data that the Card Manufacturer writes to the cards.

Scope
This document applies to all and only Ultralight-based smart cards that are to be issued by UTA or others for use in the UTA EFCS, including Test and Production cards.

This document only describes the information to be written by the Card Manufacturer. It does not include information that ERG/UTA will write to the cards after delivery from the Card Manufacturer.

This document defines technical requirements only. It does not define procedural requirements, e.g. for protecting the secret cryptographic key values, auditing the use of the keys, or assigning customer-defined card numbers.

Terminology
The following table contains a list of common acronyms/terms and their meanings.

Table 1: Terminology


 Term

 Definition

 BCC0, BCC1

 Ultralight check Byte0 and Byte1. See NXP Functional  Specification [5], section 6.5.1, for the calculation of these  check bytes.

 Card Manufacturer

 The organisation that manufactures and electrically initialises  the card. This organization is sometimes called the “Card  Supplier”.

 Chip Supplier

 The organization that supplies the Integrated Circuit (IC) for  the card, in this case NXP.

 Customer ID

 An 8 decimal digit number provided in a card order as a  unique identifier for each card. This number will be augmented  with a Luhn check digit and become the Card ID, which is both  encoded electronically and printed on the card.

 EFCS

 Electronic Fare Collection System

 IC

 Integrated Circuit

 OTP

 One Time Programmable

 PICC

 Proximity Integrated Circuit(s) Card

 NXP

 NXP Semiconductors, formerly Philips Semiconductors

 UID

 The card’s Unique Identifier, or chip serial number

 ‘0’ to ‘9’ and ‘A’ to ‘F’

 Represents the sixteen hexadecimal digits.

 ‘0xXY’

 Represent a byte value using hexadecimal notation, e.g.  ‘0x9F’.

 ‘xx’

 Represents a hexadecimal byte value that changes.

Number representation
This document expresses all hexadecimal representations of numeric values in big-endian format, i.e. most significant byte and nybble on the left, least significant byte and nybble on the right. This is not necessarily the order in which the bytes are sent to or stored on the card.

Each byte is represented by the bits b8 to b1, where b8 is the most significant bit (msb) and b1 is the least significant bit (lsb). This convention is consistent with ISO/IEC 7816-4:2005 [2]. In each representation the left bit is the MSB.

References

The following materials are to be used in conjunction with or are referenced by this document.

[1.] ISO/IEC 7812-1:2000(E)

Identification cards - Identification of issuers - Part 1: Numbering system
Second edition, 2000-09-15

[2.] ISO/IEC 7816-4

Identification cards – Integrated circuit cards – Part 4: Organization, security and commands for interchange,
Second edition 2005-01-15.

[3.] ISO/IEC 14443-3:2001(E)

Identification cards – Contactless integrated circuit(s) cards – Proximity cards – Part 3: Initialization and anticollision, First edition, 2001-02-01.

[4.] ISO/IEC 14443-4

Identification cards – Contactless integrated circuit(s) cards – Proximity cards – Part 4: Transmission protocol, First edition, 2001-02-01.

[5.] MF0ICU1 Functional Specification MIFARE Ultralight

NXP Semiconductors, Rev. 3.4, 4 February 2008
Functional Spec V3.4

[6.] ISO/IEC 9797-1:1999(E) Information technology – Security techniques – Message Authentication Codes (MACs) – Part 1: Mechanisms using a block cipher

First edition 1999-12-15

Card Configuration – Ultralight Version 1

This section specifies the data that the Card Manufacturer will write to each card.

The chip used for Version 1 will be Mifare Ultralight from NXP. The specification for this chip is [5]. Mifare Ultralight is compliant with ISO/IEC 14443 (see [3] and [4]).

Page Layout

Pages 0x00 & 0x01 – Manufacturer Pages

This page shall be configured per the NXP specification ([5]).

Page 0x02 – Lock Page

After the card data as defined in section 0 has been written to the card, the Card Manufacturer shall set the Lock bits as follows:

Table 2: Lock Bytes


 Page 0x02

Byte 0x00

Byte 0x01

Byte 0x02

Byte 0x03

BCC1

Internal

Lock0
‘0x30’

Lock1
‘0x00’

Legacy Note

Some cards exist in the field with Lock0 = 0x60. This does NOT protect the magic numbers in Page 0x04, and incorrectly protects the unused Page 0x06.

These cards shall be supported by the EFCS.

All future cards shall be initialized with Lock0 = 0x30.

Page 0x03 – OTP Page

The Card Manufacturer shall write all ‘0’s to all bytes in the OTP page 0x03 of EEPROM memory.

Pages 0x04 to 0x05 – Card Data

The Card Manufacturer shall write the following data to these pages:
Page 0x04: Fixed values representing a unique card format identifier.
Page 0x05: Card ID bytes 1-4 – these bytes shall be calculated

Pages 0x06 to Page 0x0F

All bytes in these pages shall be set to ‘0x00’.

Card ID

The Customer ID numbers supplied shall be 9 decimal digits.

A decimal zero (‘0’) digit shall be appended to the right of the Customer ID, creating a 10 decimal digit Card ID.

The resulting Card ID shall be written to Pages 0x05 as a 32-bit binary number, stored in big-endian format.

Card Configuration – Ultralight Version 2

This section specifies the data that the Card Manufacturer will write to each card.

The chip used for Version 1 will be Mifare Ultralight from NXP. The specification for this chip is [5]. Mifare Ultralight is compliant with ISO/IEC 14443 (see [3] and [4]).

Page Layout

Pages 0x00 & 0x01 – Manufacturer Pages

This page shall be configured per the NXP specification ([5]).

Page 0x02 – Lock Page

After the card data has been written to the card, the Card Manufacturer shall set the Lock bits as follows:

Table 3: Lock Bytes


 Page 0x02

Byte 0x00

Byte 0x01

Byte 0x02

Byte 0x03

BCC1

Internal

Lock0
‘0x70’

Lock1
‘0x00’

Page 0x03 – OTP Page

The Card Manufacturer shall write all ‘0’s to all bytes in the OTP page 0x03 of EEPROM memory.

Pages 0x04 to 0x06 – Card Data

The Card Manufacturer shall write the following data to these pages:
Page 0x04: Fixed values representing a unique card format identifier and cryptographic key version number.
Page 0x05: Card ID bytes 1-4 – these bytes shall be calculated
Page 0x06: MAC bytes 1 to 4 – these bytes shall be calculated

Pages 0x07 to Page 0x0F

All bytes in these pages shall be set to ‘0x00’.

Card ID

Specific Customer ID ranges will be provided with each card order.
The Customer ID numbers supplied shall be 9 decimal digits.
The card manufacturer shall use the Luhn formula to calculate a Luhn code across the 9 decimal digits of the Customer ID number.
The Luhn code shall be appended to the right of the Card ID, creating a 10 decimal digit Card ID.
The resulting Card ID shall be written to Pages 0x04 and 0x05, shall be written to the card as a 32-bit binary number, stored in big-endian format.
The Luhn code shall be calculated according to ISO/IEC 7812-1:2000(E) [1].

MAC

The algorithm used to generate the MAC shall be ISO/IEC 9797-1 ([6]), with block cipher DEA, padding method 2, MAC algorithm 4 and MAC length 32 bits.
The data to be encrypted shall be a byte-wise concatenation of:

  • The 4 bytes of Page 0x00
  • The 4 bytes of Page 0x01
  • The 4 bytes of Page 0x04
  • The 4 bytes of Page 0x05
  • The 4 bytes of Page 0x06

Cryptographic Key

The cryptographic key shall be supplied via a separate process. Each key shall be supplied with a version number.

A card order shall specify the key version to be used to encode the MAC for the cards produced for that order. The key version used shall be written to Page 0x04 byte 0x03.

Cryptographic Key Diversification

The diversification algorithm shall be defined separately.