NXP Semiconductors has recently warned their customers that they are running out of unique IDs for the Mifare Classic family. A detailed application note is also available to give precize answers to technical questions.
Since the beginning, every card in the Mifare Classic family (1k, 4k, Mini) has a 32-bit identifier, said to be unique (4-byte UID according to ISO 14443-3 A standard). The reader uses this identifier to “see” and to select the card (anticollision + activation loop). Afterwards, the reader’s Crypto1 engine also has to know this identifier in order to perform the mutual authentication, to gain read or write access on card’s data.
Theoretically, 32 bits would mean that 4.2 billion cards coul’d be issued with different IDs (4 294 967 296 exactly). But as some values have been reserved or assigned by ISO to different uses, only 3.7 billion unique IDs were practically available. Therefore, NXP expects to run out of unique identifiers for Mifare Classic by the end of 2010.
Fortunately, ISO 14443 standard allows longer IDs: either 7-byte IDs (“cascade level 2”, widely used for years, by Mifare UltraLight and Desfire for instance) or 10-byte IDs (“cascade level 3”, but with no practical example at the date of writing). To overcome the 32-bit limit, NXP will introduce a new generation of Mifare Classic cards using 7-byte IDs. As a consequence, applications working with card IDs may have to be updated to accept longer numbers.
All SpringCard readers, whatever the version, support the whole ISO 14443 standard, including 7- or 10-byte IDs. But the Crypto1 authentication scheme has to be slightly updated to support the longer ID. In our contactless products (SpringProx, CSB, Prox’N’Roll, etc), this is implemented since version 1.51. Therefore, customers that need to read/write new Mifare Classic cards having 7-byte IDs (as well as Mifare Plus) shall make sure that their products run firmware 1.51 or newer.