L’essentiel
Référence pour projets HF sécurisés. Le composant ne sécurise pas une mauvaise gestion des clés.
Trois points à établir avant de conclure :
- génération et capacité de la référence
- applications, fichiers et droits associés
- trace d’authentification avec les clés de test
Une carte peut héberger plusieurs applications, chacune avec ses fichiers, droits et clés. Le cahier des charges doit donc nommer génération, capacité, arborescence, modes de communication et stratégie de diversification. La sécurité du composant ne protège pas une clé partagée sans contrôle ni un système de gestion incapable de révoquer correctement les droits.
Une arborescence d’applications plutôt qu’une mémoire à plat
Cette famille organise sa mémoire comme un petit système de fichiers. Au niveau de la carte, une clé maître contrôle la création et la suppression des applications. Chaque application est repérée par un identifiant de 3 octets, l’AID, possède son propre jeu de clés, jusqu’à 14, et contient des fichiers de types distincts : données standard, données avec sauvegarde, valeur, enregistrements linéaires ou cycliques. Les droits de lecture, d’écriture et de modification sont définis fichier par fichier et renvoient chacun à un numéro de clé.
Ce découpage fait cohabiter sur une même carte le contrôle d’accès, la restauration et l’impression, chaque exploitant ne détenant que les clés de son application. Encore faut-il que les AID ne se chevauchent pas : un plan d’applications arrêté avant l’encodage évite qu’un second service découvre après coup que son identifiant est déjà occupé.
Chiffrement, modes de communication et UID aléatoire
Les générations actuelles s’authentifient en AES 128 bits ; des cartes plus anciennes fonctionnent encore en DES ou triple DES. Chaque fichier se lit en clair, avec code d’authentification (MAC) ou entièrement chiffré, et ce choix doit correspondre à la configuration du lecteur. La carte peut aussi présenter un UID aléatoire à chaque entrée dans le champ : la vie privée du porteur est protégée, mais tout système qui identifie la carte par son UID devient inutilisable. La mémoire se commande couramment en 2, 4 ou 8 Ko. Une application de contrôle d’accès limitée à un fichier d’identifiant occupe peu de place ; c’est l’ajout ultérieur d’autres services, avec leurs fichiers d’enregistrements, qui justifie une capacité supérieure. Les fichiers valeur et avec sauvegarde s’écrivent en transaction : une carte retirée du champ avant validation conserve son état précédent.
Ce que nous faisons à la personnalisation
En production, nous créons les applications et les fichiers selon le plan transmis, chargeons les clés, de préférence diversifiées à partir de l’UID pour qu’une carte compromise ne livre pas la clé du parc, puis remplaçons la clé maître de la carte. Le rapport d’encodage associe à chaque UID réel les AID créés. Sur demande, des cartes prélevées dans le lot sont relues avec les clés convenues pour confirmer arborescence et droits avant expédition.
Sources primaires
Catalogue officiel des parties consacrées aux objets de proximité sans contact.
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.
Ces noms servent uniquement à identifier les composants étudiés. Aucune affiliation, licence ni approbation de NXP n’est revendiquée.
À lire ensuite
01 / PUCEFamille HF pour migration
Les modes, la migration et les exigences du lecteur sont expliqués pour éviter une compatibilité supposée.
02 / PUCEFamille HF historique
L’architecture mémoire, les usages historiques et les points d’attention sont replacés dans le contexte d’un parc existant.
03 / USAGEBadges RFID pour bureaux et coworking, collaborateurs et visiteurs
Associer accès, identité visuelle et cycle de vie du collaborateur sans confondre leurs rôles.
Questions fréquentes
Une carte de cette famille peut-elle recevoir une nouvelle application après livraison ?
Oui, si la mémoire libre le permet et si l’on détient la clé maître de la carte, ou si ses paramètres autorisent la création sans authentification. Un encodeur de bureau suffit : l’exploitant ajoute son application avec ses propres clés, sans toucher aux fichiers déjà présents. Prévoyez la capacité en conséquence, 2, 4 ou 8 Ko selon la référence.
Pourquoi un lecteur ne voit-il qu’un numéro changeant sur ces cartes ?
L’option d’UID aléatoire est activée. À chaque présentation, la carte annonce un identifiant différent pendant l’anticollision. Pour obtenir un numéro stable, le lecteur doit s’authentifier dans une application puis lire l’UID réel ou un identifiant stocké dans un fichier. Un lecteur qui se contente de l’anticollision ne peut pas exploiter ces cartes.
Des cartes d’une génération récente fonctionnent-elles sur des lecteurs configurés pour la précédente ?
Les générations récentes reprennent les commandes des précédentes, avec les mêmes algorithmes. Un lecteur configuré pour une application AES ou triple DES doit donc la retrouver, tant que l’AID, les fichiers et les clés sont identiques. Les fonctions nouvelles restent simplement inutilisées. Un essai sur le lecteur en place confirme ce comportement avant la série.