L’essentiel
Pour migration ou nouvelle architecture HF. Ne pas migrer sans vérifier lecteurs, clés et logiciel.
Trois points à établir avant de conclure :
- modes supportés par les lecteurs installés
- structure des secteurs, applications et clés
- migration d’un groupe pilote sans couper l’ancien parc
La différence structurante n’est pas uniquement l’algorithme : secteurs et blocs d’un côté, applications et fichiers avec droits distincts de l’autre. Une migration exige l’inventaire des lecteurs, la stratégie de clés, la personnalisation et le logiciel d’émission. Testez un groupe pilote tout en conservant un retour possible vers le parc existant.
Deux organisations de mémoire opposées
La première famille découpe sa mémoire en secteurs de quatre blocs de 16 octets, dont le dernier porte deux clés de 48 bits et les bits d’accès ; le détail des blocs et des versions de 1 et 4 Ko figure sur notre fiche consacrée à cette famille. Retenez qu’une carte de 1 Ko n’offre que 752 octets de données une fois déduits les blocs de clés et le bloc fabricant. La carte dialogue au niveau ISO/IEC 14443-3, avec un algorithme propriétaire dont les faiblesses sont publiquement documentées.
La seconde famille dialogue au niveau ISO/IEC 14443-4 et range ses données dans des applications, chacune avec ses fichiers et jusqu’à 14 clés, authentifiées en 3DES ou en AES ; notre fiche sur l’architecture à applications en détaille les types de fichiers. Pour la comparaison, retenez que les droits s’y définissent fichier par fichier et que chaque service détient ses propres clés, là où la première famille protège chaque secteur par une paire de clés.
Conséquences pour les lecteurs qui ne lisent que l’UID
Beaucoup d’installations d’accès n’exploitent que l’identifiant. Un lecteur de ce type lit en général les deux familles, mais la seconde propose une option d’identifiant aléatoire : une fois activée, la carte présente un UID différent à chaque passage et devient inutilisable pour un système fondé sur l’UID. À l’inverse, certaines cartes de la première famille portent un identifiant de 4 octets non unique, ce qui pèse sur un parc important.
Ce que chaque famille implique en production
Pour la première famille, nous écrivons vos clés de secteur et vos données dans les blocs indiqués, puis modifions les bits d’accès selon votre schéma. Pour la seconde, la carte sort de fabrication avec une clé maîtresse de transport : créer l’application, ses fichiers et ses clés suppose que vous nous fournissiez le schéma d’application et un procédé d’échange de clés, ou que vous personnalisiez vous-même des cartes livrées vierges. Dans les deux cas, un échantillon personnalisé est à valider sur votre lecteur avant la série.
Sources primaires
Documentation fabricant sur les variantes, l’interface et les limites de la famille.
NXP Semiconductors · source primaire ↗MIFARE DESFire EV3Documentation fabricant sur l’interface, la mémoire, les fichiers et les fonctions de la génération EV3.
Marques. MIFARE et DESFire sont des marques déposées de NXP B.V. MIFARE et MIFARE Classic sont des marques de NXP B.V.
Ces noms servent uniquement à identifier les composants étudiés. Aucune affiliation, licence ni approbation de NXP n’est revendiquée.
À lire ensuite
01 / COMPARATIFModes de sécurité pour migration HF
Une comparaison orientée migration, modes de fonctionnement et gestion des clés.
02 / COMPARATIFEM4100 ou T5577, badge 125 kHz en lecture seule ou réinscriptible
Lecture seule et configuration réinscriptible répondent à des usages et risques différents.
03 / PRODUITCartes RFID 13,56 MHz personnalisées
Une famille HF large : la fréquence seule ne suffit jamais à confirmer l’interopérabilité.
Questions fréquentes
Un lecteur prévu pour la première famille lit-il les cartes de la seconde ?
Il lit généralement l’identifiant, car les deux familles partagent l’interface ISO/IEC 14443 A. En revanche, il ne peut pas accéder aux fichiers de la seconde sans prendre en charge ses commandes et ses clés 3DES ou AES. Si votre système lit des données en secteur, une mise à jour du lecteur ou de son firmware devient nécessaire.
Faut-il désactiver l’identifiant aléatoire sur une carte à applications ?
Oui, dès que le contrôleur d’accès identifie le porteur par l’UID. Une fois l’option activée, l’UID réel ne se lit qu’après authentification, et le lecteur voit une valeur différente à chaque présentation. Cette option se fixe lors de la personnalisation et doit figurer explicitement dans la spécification de commande.
Qui détient les clés d’une carte à applications livrée vierge ?
La carte quitte la fabrication avec une clé maîtresse de transport connue. L’exploitant, ou son intégrateur, la remplace lors de la personnalisation par ses propres clés, puis crée ses applications. Tant que cette clé n’est pas changée, n’importe qui peut reconfigurer la carte ; les cartes vierges se stockent donc comme un stock sensible.