Deux puces NFC, deux philosophies d’intégration
NTAG et MIFARE Classic fonctionnent tous deux à 13,56 MHz et reposent sur une communication sans contact de type NFC. Pourtant, ils ne répondent pas exactement au même besoin. Le choix ne doit pas se limiter à la capacité mémoire ou au prix du tag : il dépend du lecteur utilisé, du niveau de sécurité attendu, du format des données et de la compatibilité avec les smartphones.
Une puce NTAG est généralement pensée pour transporter un message NDEF standardisé : une URL, un identifiant, un texte, une donnée d’application ou un enregistrement destiné à être lu par un téléphone. Elle s’intègre naturellement dans un prototype IoT où le tag sert de point d’entrée vers une application mobile ou un service distant.
MIFARE Classic est davantage une mémoire organisée en secteurs, avec des clés d’authentification et des droits d’accès. Cette architecture peut être utile pour reproduire un système existant, tester une logique de badges ou prototyper une segmentation des données. En revanche, son mécanisme de sécurité historique, Crypto1, ne doit plus être considéré comme une protection robuste pour un produit exposé à un attaquant.
La première question est donc fonctionnelle : le tag doit-il simplement publier une information compatible NFC, ou doit-il participer à un système de contrôle d’accès fondé sur des secteurs et des clés ? Pour un nouveau projet, cette distinction permet souvent d’écarter rapidement une technologie mal adaptée.
NTAG : le choix naturel pour les usages NDEF et smartphone
Les puces NTAG appartiennent à la famille des tags NFC Forum Type 2. Elles utilisent la technologie sans contact conforme à la famille ISO/IEC 14443-A et sont conçues pour être détectées par de nombreux téléphones NFC, lecteurs USB et modules embarqués compatibles. Les références NTAG213, NTAG215 et NTAG216 sont couramment utilisées en prototypage, avec des capacités utilisateur différentes.
La mémoire disponible n’est pas égale à la capacité nominale annoncée sur la référence. Une partie est réservée aux informations de configuration, à l’identification de la puce et aux mécanismes de protection. À titre pratique, un NTAG213 offre une zone utilisateur adaptée à de courtes URL ou à des identifiants, tandis qu’un NTAG216 convient mieux à des contenus NDEF plus volumineux. La capacité exacte doit être vérifiée dans la fiche technique du fabricant avant de figer le format de données.
Le contenu est généralement encodé au format NDEF, défini par le NFC Forum. Un enregistrement NDEF peut contenir une URI, du texte, un type MIME ou une donnée propre à une application. Cette standardisation est importante : un smartphone n’a pas besoin de connaître la structure interne complète de la puce pour interpréter une URL ou transmettre un message à une application.
Dans un prototype de maintenance industrielle, par exemple, un NTAG fixé sur un équipement peut contenir un identifiant d’actif et une URL courte. L’application mobile lit le tag, authentifie l’utilisateur auprès du serveur, puis récupère la procédure, l’historique des interventions et les alertes associées. Le tag ne stocke alors pas les données sensibles ; il sert de lien physique entre l’équipement et le système d’information.
MIFARE Classic : une mémoire sectorisée adaptée aux systèmes hérités
MIFARE Classic organise la mémoire en secteurs composés de blocs de 16 octets. Une version 1K comporte 16 secteurs, tandis qu’une version 4K utilise une organisation plus étendue avec des secteurs de tailles différentes. Dans chaque secteur, le dernier bloc est généralement le trailer sector : il contient deux clés d’accès, les bits de contrôle et parfois des données spécifiques selon l’architecture retenue.
Cette structure permet de séparer des zones fonctionnelles. Un secteur peut être réservé à l’identifiant d’un utilisateur, un autre à des compteurs ou à des paramètres locaux, avec des droits distincts en lecture et en écriture. La logique est intéressante pour simuler un badge d’accès, un titre de transport ou un système industriel existant qui dialogue déjà avec des lecteurs MIFARE Classic.
Il faut toutefois distinguer la compatibilité radio de la compatibilité applicative. Un lecteur qui prend en charge ISO/IEC 14443-A ne prend pas nécessairement en charge les commandes propriétaires MIFARE Classic. De même, un smartphone capable de lire des tags NFC Forum peut ne pas gérer correctement l’authentification Crypto1, selon le système d’exploitation, le modèle de téléphone et les évolutions de sécurité du constructeur.
MIFARE Classic peut aussi être lu comme une mémoire brute par certains outils de développement, mais cela ne garantit pas qu’un téléphone affichera automatiquement son contenu. Pour un prototype destiné à être manipulé par le grand public, cette incertitude opérationnelle est un risque à traiter dès la phase de conception.
Comparaison technique pour orienter un prototype
| Critère | NTAG | MIFARE Classic |
|---|---|---|
| Positionnement | Tag NFC Forum Type 2, orienté NDEF et interaction mobile | Carte ou badge sectorisé, souvent utilisé dans des systèmes existants |
| Norme radio | ISO/IEC 14443-A, selon la référence et la documentation fabricant | ISO/IEC 14443-A avec commandes et mécanismes spécifiques MIFARE |
| Format de données | NDEF ou mémoire utilisateur selon l’application | Blocs de 16 octets, secteurs et blocs de contrôle |
| Compatibilité smartphone | Généralement élevée pour les fonctions NDEF | Variable, notamment pour l’authentification et l’écriture |
| Protection courante | Verrouillage permanent, mot de passe selon les modèles, signature d’originalité sur certaines références | Clés par secteur et authentification Crypto1 |
| Cas d’usage pertinent | URL, identification d’actif, configuration IoT, marketing produit, maintenance | Prototype compatible avec un parc de lecteurs MIFARE Classic ou reproduction d’un système historique |
| Risque principal | Capacité limitée et protection insuffisante pour des secrets critiques | Crypto1 compromis et compatibilité mobile non garantie |
La sécurité doit être évaluée au niveau du système
Le principal piège consiste à confondre contrôle d’écriture et sécurité. Sur un NTAG, un verrouillage ou un mot de passe peut empêcher une modification triviale de la mémoire, mais il ne transforme pas le tag en coffre-fort. Selon le modèle et la configuration, les données peuvent rester lisibles, copiables ou rejouables. Une URL présente dans un tag ne doit donc pas être considérée comme une preuve d’authenticité.
MIFARE Classic fournit une authentification par secteur, mais Crypto1 a fait l’objet de recherches publiques ayant démontré des faiblesses importantes. Un attaquant disposant d’un accès physique au badge peut potentiellement exploiter ces faiblesses, cloner des données ou retrouver des clés mal configurées. Cette technologie peut rester acceptable pour un environnement de démonstration, un banc de test ou une contrainte de compatibilité, mais elle est difficile à recommander pour un nouveau système de contrôle d’accès ou de paiement.
Pour un produit IoT nécessitant une authentification forte, il est préférable d’examiner des composants NFC dotés d’un élément sécurisé, de fonctions cryptographiques modernes ou d’une authentification cryptographique dynamique. Certaines familles de tags disposent par exemple de signatures, de compteurs ou de mécanismes d’authentification plus adaptés à la lutte contre le clonage. Le choix doit s’appuyer sur une analyse de menace : valeur de l’actif, accès physique, durée de validité du tag, conséquences d’une copie et possibilité de vérifier le tag côté serveur.
Une architecture robuste conserve les données sensibles sur le serveur et limite le contenu du tag à un identifiant ou à un jeton révocable. Le serveur peut ensuite vérifier le contexte, l’identité de l’utilisateur, la date, le compteur d’utilisation et l’état de l’actif. Cette approche réduit l’impact d’un tag copié, même si elle ne remplace pas une authentification cryptographique lorsque le niveau de risque l’exige.
Choisir selon le lecteur, l’application mobile et le cycle de vie
Avant d’acheter un lot de tags, il faut tester la chaîne complète : puce, antenne, boîtier, lecteur, application et système backend. La portée réelle dépend fortement de l’antenne, de l’accord d’impédance, de l’environnement métallique et de l’orientation du tag. Une puce performante dans une carte nue peut devenir difficile à lire lorsqu’elle est collée sur un moteur, un emballage métallique ou un équipement contenant une batterie.
Pour un prototype mobile, la séquence de validation peut être structurée ainsi :
- Choisir une référence précise et récupérer sa fiche technique complète.
- Définir le format NDEF ou la cartographie mémoire avant d’écrire les premières données.
- Tester la lecture avec plusieurs modèles de smartphones et plusieurs versions de système d’exploitation.
- Mesurer la distance, le temps de détection et le taux d’échec dans le boîtier final.
- Vérifier le comportement lorsque le tag est réécrit, verrouillé, partiellement endommagé ou présenté plusieurs fois.
- Tester les scénarios réseau : téléphone hors ligne, serveur indisponible, jeton expiré et utilisateur non autorisé.
Un lecteur NFC embarqué dans un microcontrôleur offre davantage de contrôle qu’un smartphone, mais il impose de gérer les états de communication, les délais, l’anticollision et les commandes propres à la puce. Dans un prototype basé sur un module PN532 ou un circuit équivalent, il faut vérifier explicitement si la bibliothèque utilisée gère le type de tag visé, les commandes d’écriture et les éventuelles fonctions de protection. Une bibliothèque qui sait lire une UID ne sait pas nécessairement interpréter ou sécuriser un contenu NDEF.
Recommandations par scénario de prototypage
- Badge d’identification d’équipement : choisir un NTAG avec une URL ou un identifiant court, puis faire porter la logique métier par le backend. Cette solution est simple à tester avec un smartphone et évolutive côté logiciel.
- Configuration d’un capteur IoT : utiliser un NTAG pour transmettre les paramètres initiaux, comme l’identifiant réseau, le profil de mesure ou une URL de provisioning. Les secrets Wi-Fi ou les clés privées ne doivent pas être stockés en clair dans une mémoire NFC ordinaire.
- Reproduction d’un système de badge existant : retenir MIFARE Classic uniquement si les lecteurs, les bibliothèques et le protocole applicatif imposent cette compatibilité. Il faut documenter les clés, les secteurs et les droits dans un environnement de test isolé.
- Contrôle d’accès ou authentification anti-clonage : ne pas sélectionner MIFARE Classic pour sa seule présence de clés sectorielles. Comparer des solutions plus récentes intégrant une authentification cryptographique et une gestion de clés adaptée.
- Prototype de traçabilité logistique : préférer un NTAG pour un identifiant lisible par mobile, mais valider l’antenne dans le conditionnement réel. Pour une lecture longue distance ou simultanée de nombreux objets, la technologie UHF RFID selon EPC Gen2 est souvent plus appropriée que le NFC.
- Produit grand public : privilégier la compatibilité NDEF et la simplicité de l’expérience utilisateur. Un tag qui nécessite une application spécialisée ou un téléphone compatible MIFARE Classic augmente fortement le support nécessaire.
Bonnes pratiques de conception et de déploiement
Le prototype doit distinguer clairement trois couches : l’identité radio, le contenu applicatif et la confiance accordée au contenu. L’UID ou le numéro de série du tag peut aider au diagnostic, mais il ne constitue pas systématiquement un secret et ne doit pas être utilisé seul pour autoriser une opération sensible. Le contenu NDEF doit être versionné afin de permettre l’évolution du format sans rendre les tags déjà déployés inutilisables.
Pour un déploiement industriel, prévoir une procédure d’initialisation contrôlée. Chaque tag doit être associé à un enregistrement backend, testé, puis marqué comme actif. Les opérations d’écriture doivent être journalisées avec l’identifiant de l’opérateur, la date et la version du contenu. Si le tag est verrouillé définitivement, cette décision doit intervenir après les tests d’intégration, jamais au début du prototypage.
La lisibilité mécanique est aussi importante que le protocole. Il faut mesurer les performances sur les matériaux finaux, notamment le métal, les liquides, les composites et les surfaces courbes. Une étiquette NFC prévue pour du carton peut nécessiter une antenne spéciale ou un espace isolant lorsqu’elle est placée sur un boîtier métallique. La température, l’humidité, les chocs et les produits de nettoyage doivent également être pris en compte pour la traçabilité en usine ou en logistique.
Enfin, documenter les limites de la solution : distance de lecture attendue, appareils testés, taille maximale du message, comportement hors ligne, politique de remplacement et procédure de révocation. Cette documentation évite qu’un prototype correctement démontré en laboratoire soit déployé comme une solution de sécurité sans avoir été conçu pour cela.
Le choix recommandé pour un nouveau projet
Pour un projet de prototypage NFC démarrant sans contrainte de compatibilité historique, NTAG est généralement le meilleur point de départ. La prise en charge de NDEF, l’interaction naturelle avec les smartphones et la disponibilité de références à différentes capacités réduisent le temps d’intégration. Cette option convient particulièrement à l’identification d’actifs, au provisioning IoT, à la maintenance assistée et aux parcours mobiles.
MIFARE Classic se justifie surtout par une contrainte existante : lecteur déjà installé, protocole imposé, badge à reproduire ou besoin de tester une mémoire sectorisée dans un environnement contrôlé. Il ne devrait pas être choisi comme nouvelle base de sécurité pour un système exposé, car Crypto1 ne fournit pas le niveau de confiance attendu par les applications sensibles.
Le critère déterminant reste donc l’architecture globale. Pour identifier un objet, le tag peut être simple et le serveur porter la logique. Pour authentifier un objet, il faut une fonction cryptographique adaptée. Pour lire plusieurs articles à distance dans une chaîne logistique, il faut peut-être quitter le NFC au profit de la RFID UHF. Un bon prototype ne cherche pas seulement à faire fonctionner une puce : il vérifie que la technologie reste cohérente avec le scénario d’usage, le matériel final, les contraintes de sécurité et le mode de déploiement.
FAQ : NTAG et MIFARE Classic en pratique
Un NTAG est-il compatible avec tous les smartphones NFC ?
La compatibilité est généralement élevée lorsque le tag contient un message NDEF standard, mais elle dépend du système d’exploitation, du modèle de téléphone et du comportement de l’application. Il faut tester les appareils réellement ciblés, notamment pour l’écriture, les tags protégés et les contenus volumineux.
Peut-on utiliser un NTAG pour stocker un mot de passe Wi-Fi ?
C’est techniquement possible dans certains formats NDEF, mais déconseillé si le contenu est lisible par toute personne approchant son téléphone. Pour un provisioning IoT, mieux vaut utiliser un jeton temporaire, un échange authentifié ou une procédure d’enrôlement qui ne révèle pas durablement un secret.
MIFARE Classic est-il interdit dans un prototype ?
Non. Il peut être pertinent pour tester un lecteur existant ou reproduire un système ancien. En revanche, ses mécanismes Crypto1 ne doivent pas être présentés comme une sécurité moderne. Le prototype doit préciser s’il valide une compatibilité fonctionnelle ou un niveau de protection.
La capacité mémoire suffit-elle à choisir une référence NTAG ?
Non. Il faut aussi vérifier la mémoire utilisateur réellement disponible, le format NDEF, le type de verrouillage, la distance de lecture dans le boîtier et la compatibilité avec les lecteurs. Une URL courte ou un identifiant nécessite peu de mémoire ; un contenu structuré ou plusieurs enregistrements peut justifier une référence plus capacitaire.
Quand faut-il préférer la RFID UHF au NFC ?
La RFID UHF selon EPC Gen2 est plus adaptée à la lecture à plusieurs mètres et à l’identification simultanée de nombreux articles. Le NFC reste pertinent lorsque l’utilisateur doit présenter volontairement un objet à proximité d’un téléphone ou d’un lecteur, avec une interaction courte et maîtrisée.
Auteur
Matteo Grünfeld
