Integrity of stored Data
As the mifare Ultralight pages can be updated without satisfying any security measures (anyone can easily update the memory), the content of the memory lacks guaranteed integrity. To avoid this inconvenience we propose a security checksum which has to be calculated over the bytes in pages 2 to used end and has to be appended with the data. For this purpose MAC (Message Authentication Code) [ISO/IEC 9797-1] may be a good choice. The complete scheme is shown in figure 5:

Checksum = f (key,usedmemory(inc.page2 & 3),UID)

–Use the same Initial Vector (IV) and Card Key(Ck) used in the previous section
–If number of used pages is odd or number of data bytes is not a multiple of 8-byte, add standard padding with all ‘00’. As example (‘xx’ is the data bytes ):
3 padding bytes: xx xx xx xx xx 00 00 00
6 padding bytes: xx xx 00 00 00 00 00 00
Either the encrypted data and/or the checksum can be stored in the mifare Ultralight user memory. In this case the data is protected against damage and being copied from one mifare Ultralight to another one, as long as the key is kept secret.3 If high level security features are required, other members of the mifare card IC family can be used in the application, e.g. the mifare Classic or the mifare ProX. Please note, the DES operation may be performed using a DESFire SAM module. This SAM module will facilitate the system in the following ways:

The key can be stored once
–The key cannot be read back
–The module provide one step functions for calculation of DES/ 3DES
–The Cryptographic operations are fast enough for real time operations

Using mifare Ultralight in an existing mifare Classic application

The mifare Ultralight offers the feature to be used in an existing mifare Classic application. Therefore the mifare Ultralight command structure is compatible to the mifare Classic one. Because the mifare Ultralight addresses a different application category (single trip ticketing, fast and cheap transactions), some application changes have to be done anyway, but the existing mifare transaction command structure and the mifare Reader may be used with the mifare Ultralight.

Differences: mifare Classic – mifare Ultralight
The basic differences between mifare Classic and mifare Ultralight are: I) The mifare Ultralight uses a 7-byte UID instead of 4-byte (like mifare Classic). There are 2 possibilities to select a mifare Ultralight card. It suggests to use the anticollision cascade level 2 (as specified in the ISO14443A – 3) to get the complete UID and select one mifare Ultralight (see 3.1.1). If the reader does not support the ISO cascade level 2 anti-collision and there is no chance to update the reader to do so, a combination of anti-collision cascade level 1 (using the first 3 bytes of the UID) and a read of block 0 after the Select can be used instead. Please note that this workaround has the limitation that there is no chance to fully RESOLVE a collision between two cards in case of the unlikely event, that the first part of the UID is equal. The collision can only be DETECTED, allowing the reader to inform the user to present only one card to the reader (see 3.1.2). II) The mifare Ultralight doesn’t need the authentication and no keys, as it uses no encryption. III) The mifare Ultralight only uses “Read”, “Write” and “C.Write” (mifare Classic compatible write command with 16 Bytes).
No Value-commands are used.

.

.

.

.