Comment programmer des balises NFC avec différents types de puces (NTAG, MIFARE et plus)

 

L'écriture d'une balise consiste en trois opérations distinctes, pas une

 

Lorsque les gens disent vouloir programmer des balises NFC, ils décrivent généralement trois choses distinctes qui sont déclenchées par le même bouton dans une application téléphonique.

 

Le premier estformatage. La mémoire d'une puce NFC doit être informée que sa zone utilisateur contient un message NDEF plutôt que des octets arbitraires. Cela se fait en écrivant une petite structure de données appelée conteneur de capacités. Sur les pièces NTAG21x, cela est déjà fait au niveau de la tranche, donc la puce arrive au format NDEF- et ne peut contenir que du NDEF. Sur MIFARE Classic et certaines autres puces, le formatage est quelque chose que vous effectuez, et la structure atterrit dans une région -programmable une seule fois-. Le formatage est donc permanent. Il n'existe pas de commande de déformatage ni d'outil fournisseur qui vous en fournira une.

 

La seconde estécrire la charge utile: un message NDEF contenant un ou plusieurs enregistrements, le plus souvent un enregistrement URI pointant vers une URL. C’est la partie que tout le monde imagine. Les écritures de charge utile sont normalement reproductibles, c'est pourquoi une équipe marketing peut rediriger une balise de campagne six mois plus tard sans réorganiser le matériel.

 

Le troisième estconfiguration: octets du mot de passe, bits de verrouillage, paramètres du miroir, conditions d'accès, clés d'authentification. C’est dans cette couche que résident les décisions irréversibles, et c’est la couche qu’aucun didacticiel destiné aux consommateurs ne touche du tout. Si vous envisagez de programmer des balises NFC pour tout ce qui est entouré d'une limite de sécurité, la couche de configuration est le projet.

 

Garder ces trois éléments séparés dans votre tête est ce qui empêche la mise au rebut d’un lot. La plupart des échecs d’écriture que nous diagnostiquons ne sont pas des échecs de charge utile. Il s’agit d’un état de formatage ou d’un état de configuration dont quelqu’un ignorait l’existence.

 

Comparaison des types de puces d'étiquettes NFC avant de les programmer

 

Toute décision sérieuse sur la manière de programmer des tags NFC à grande échelle commence par ce tableau, car le plafond de mémoire et la prise en charge de la plate-forme sont définis au moment de la sélection de la puce et ne peuvent pas être corrigés ultérieurement dans le logiciel.

 

Ébrécher	Mémoire utilisateur	Type de forum NFC	État NDEF d'usine	Protection par mot de passe/clé	iPhone NDEF lire + écrire
NTAG213	144 octets	Tapez 2	Pré-formaté	Mot de passe 32 bits / PACK 16 bits	Oui
NTAG215	504 octets	Tapez 2	Pré-formaté	Mot de passe 32 bits / PACK 16 bits	Oui
NTAG216	888 octets	Tapez 2	Pré-formaté	Mot de passe 32 bits / PACK 16 bits	Oui
MIFARE Ultraléger EV1	48 ou 128 octets	Tapez 2	Formatable	Mot de passe 32 bits / PACK 16 bits	Oui
MIFARE Classique 1K	1 024 octets au total, soit environ 716 disponibles pour NDEF une fois le bloc fabricant et les 16 segments de fin de secteur déduits	Pas un type de forum NFC	Formatable, basé sur le secteur-	Clés de secteur CRYPTO-1 A/B	Non
MIFARE DESFire EV3	2 Ko à 8 Ko, basé sur un fichier-	Tapez 4	L'application doit être créée	AES-128/3DES, droits d'accès par fichier	Oui
ADN NTAG424	416 octets au total, répartis en un conteneur de capacités de 32 octets, un fichier NDEF de 256 octets et un fichier de données protégées de 128 octets	Tapez 4	Fichiers-préprovisionnés	Cinq clés AES-128, authentification mutuelle en 3 passes	Oui

 

Chiffres NTAG21x, comportement des bits de verrouillage-et conformité de type 2/ISO/IEC 14443 de type A selon leFiche produit NXP NTAG213/215/216. Structure MIFARE Classic 1K selon la fiche technique NXP MF1S50yyX (16 secteurs × 4 blocs × 16 octets). DESFire EV3 par MF3D(H)x3. Disposition de la mémoire ADN NTAG 424 parNXP.

 

Deux colonnes décident de la plupart des projets avant qu'un logiciel ne soit choisi : le plafond de mémoire et la colonne iPhone. Ce que le tableau ne peut pas vous dire, c'est le rendement. Une puce correctement spécifiée produit toujours des rejets si l'étape de codage n'est accompagnée d'aucune passe de vérification, ce qui fait l'objet de la seconde moitié de cet article.

 

NTAG 213, 215 et 216 : le choix par défaut et son véritable plafond

 

Pour environ quatre projets entrants sur cinq, cette famille est la bonne réponse, et apprendre à programmer les balises NFC NTAG 215 prend environ quatre-vingt-dix secondes avec une application téléphonique. La puce est livrée au format NDEF-, le type d'enregistrement qui se comporte de manière cohérente sur chaque combiné est un enregistrement URI simple, et Android et iOS l'écrivent sans aucun travail de SDK.

 

 

C'est également la famille derrière presque tous les programmes de cartes de visite numériques, où une seule vCard ou un seul enregistrement d'URL constitue la totalité de la charge utile, et où le format physique compte généralement plus que la puce. La plupart de ces commandes aboutissentcartes NFC blanches vierges en PVCplutôt que des autocollants, car la carte doit survivre à un portefeuille et prendre une empreinte.

 

Le plafond arrive plus vite que prévu. NTAG213 vous offre 144 octets de mémoire utilisateur et un message NDEF n'est pas seulement votre URL. Il existe un wrapper TLV, un en-tête d'enregistrement, un champ de type et un champ de longueur avant qu'un seul caractère de votre adresse ne soit stocké. Un enregistrement URI compresse les préfixes courants tels quehttps://www.en un seul octet, qui récupère dix à vingt octets, et sur une partie de 144-octets, cette différence est la limite entre l'ajustement et l'échec. Là où les équipes se font prendre, ce n'est pas l'URL elle-même mais les extras : ajoutez un enregistrement de texte pour une étiquette lisible par l'homme, ajoutez un enregistrement d'application Android pour que la balise ouvre une application au lieu d'un navigateur, et qu'une charge utile confortable devienne une erreur de débordement.

 

Notre propre règle empirique, et c'est le genre de chose que vous n'apprenez qu'en encodant quelques millions de ces éléments : si l'URL prévue, y compris les paramètres de requête, dépasse environ 90 caractères, arrêtez de spécifier NTAG213 et montez. La différence de coût unitaire entre 213 et 215 est suffisamment faible pour qu'elle ne vaut presque jamais le risque d'une refonte à mi--programme. Une campagne qui souhaite ensuite ajouter des paramètres UTM ou un numéro de série à chaque URL de balise se heurtera au mur en 213 et ne l'atteindra pas en 215.

 

La protection par mot de passe sur cette famille mérite d'être comprise précisément, car elle est plus faible que ne le suggère le mot « mot de passe ». Une valeur PWD de 32 bits est transmise en clair et vérifiée par la puce, qui contrôle l'accès en écriture, et éventuellement l'accès en lecture, à partir d'une page choisie. Cela empêche un membre curieux du public de réécrire votre tag avec un téléphone. Il ne s’agit pas d’un contrôle cryptographique et ne doit jamais être décrit à un client comme tel. Notez également que toutes les générations ne le prennent pas en charge : l'ancien NTAG203 n'a aucun mécanisme de mot de passe, et la documentation de la bibliothèque indique explicitement que les appels de protection contre lui échouent tout simplement (documentation nfcpy).

 

MIFARE Classic : accessible en écriture sur Android, effectivement absent sur iPhone

 

Voici le piège de compatibilité qui a mis fin à plus de projets NFC que tout autre facteur. Quiconque demande comment écrire NDEF dans MIFARE Classic travaille déjà à contre-courant du format : MIFARE Classic n'est pas un type de balise NFC Forum, c'est une carte ISO/IEC 14443-3A avec un secteur propriétaire et une structure de clé antérieure à l'écosystème NDEF, et la prise en charge de NDEF n'existe que via une convention de mappage superposée.

 

 

Android gère cette convention. iOS ne le fait pas. Le Core NFC d'Apple n'a jamais pris en charge MIFARE Classic, les familles MIFARE prises en charge par la plate-forme étant limitées à Ultralight, Plus et DESFire, une position que les développeurs ont confirmée à plusieurs reprises sur les propres forums d'Apple (Forums des développeurs Apple). Étant donné qu'iOS ne peut pas accéder directement à la mémoire de la carte, un iPhone ne peut pas y écrire de NDEF ni afficher le NDEF qui y est stocké.

 

Ce qui rend cela si dangereux lors de l'évaluation, c'est que les balises MIFARE Classic ne semblent pas mortes sur un iPhone. La carte présente un UID ISO 14443-A, de sorte que l'application Raccourcis l'acceptera volontiers comme déclencheur d'automatisation, et l'analyse en arrière-plan peut toujours lancer un enregistrement NDEF précédemment stocké d'un type pris en charge. Un responsable des achats testant un échantillon sur son iPhone voit une réponse et approuve. Le comportement qu'ils ont observé n'avait rien à voir avec le contenu de la mémoire de la balise, et toute l'approche s'effondre dès que le projet a besoin d'URL par unité que les iPhones peuvent réellement lire.

 

La règle pratique qui en découle : quiconque compare la façon de programmer des balises NFC pour iPhone et Android doit effectuer des tests d'acceptation sur les deux plates-formes avec la puce de production, jamais sur Android seul, et jamais sur un échantillon d'une puce différente de celle figurant sur le bon de commande.

 

Permettez-moi d'être franc sur la recommandation, car "cela dépend de votre cas d'utilisation" n'est pas une réponse utile ici. Si vos balises NFC seront exploitées par des membres du public, spécifiez autre chose que MIFARE Classic.

 

Pour les équipes déjà intégrées à un système d'accès classique-, la décision se réduit à une seule variable, et non aux balises. Il s'agit de la durée de vie restante de votre parc de lecteurs. S'il reste deux ou trois ans à ces lecteurs et qu'aucun smartphone ne touchera jamais les informations d'identification, continuer avec Classic en boucle fermée est un choix défendable, et les questions pratiques deviennent l'approvisionnement en IC et le format UID plutôt que la méthode d'encodage, ce que nous abordons dans nos notes surcommander des balises MIFARE 1K dans un système installé. Si les lecteurs doivent eux-mêmes être remplacés à l’intérieur de cette fenêtre, ne dépensez pas d’argent pour une accréditation de transition. Déplacez l'ensemble du parc vers une pièce basée sur AES-en une seule étape et absorbez le coût une seule fois.

 

Il existe un deuxième piège dans la même famille, suffisamment subtil pour survivre à des cycles complets d'assurance qualité. L'ajout d'un wrapper Smart Poster à un enregistrement, que les outils d'encodage courants proposent comme moyen convivial d'attacher un titre à une URL, modifie le type d'enregistrement. Les enregistrements enveloppés de cette manière ne sont pas du tout récupérés par l'analyse en arrière-plan iOS, quel que soit ce qui est imbriqué à l'intérieur. Les tests Android sont réussis sur tous les appareils, les iPhones ne font rien et il n'y a aucun message d'erreur à diagnostiquer.

 

ADN Ultralight, DESFire et NTAG 424 : où la programmation devient un élément clé de la gestion

 

MIFARE Ultralight EV1 a un comportement proche de NTAG21x et vous y programmez des balises NFC de la même manière, avec un budget mémoire plus petit de 48 ou 128 octets et la même classe de porte de mot de passe. Rien de nouveau sur le plan conceptuel ne se produit.

 

DESFire et NTAG 424 DNA sont une discipline différente. Sur ces parties de type 4, vous n'écrivez pas d'octets dans une carte mémoire plate, vous travaillez sur un système de fichiers avec des droits d'accès par -fichier, et chaque opération significative nécessite d'abord une authentification avec une clé AES-128. NTAG 424 DNA comporte cinq clés AES définies par le client, utilise une authentification mutuelle en 3 passes pour le fichier de données protégé et possède la certification Critères communs EAL4 sur le matériel et les logiciels. Les équipes qui programment des balises NFC pour l'authentification du produit plutôt que pour une simple redirection recherchent généralement cette partie spécifiquement, en raison d'une fonctionnalité.

 

Cette fonctionnalité est Secure Dynamic Messaging, souvent écrite sous le nom de SUN. Lorsqu'elle est activée, l'URL NDEF de la puce présente des changements à chaque clic : la puce reflète son UID et un compteur de lecture croissant de façon monotone dans l'URL, éventuellement cryptée, et ajoute un CMAC calculé avec une clé que seuls vous et la puce détenez. Votre backend peut alors distinguer une vraie balise à partir d’une URL photographiée, et peut distinguer le numéro de robinet 4 du numéro de robinet 4 000.

 

Le configurer correctement est là où la spécification mord. Les règles de mise en miroir ne sont pas de forme libre- : lorsque les données PICC sont chiffrées, la mise en miroir de l'UID et du compteur de lecture devient obligatoire plutôt que facultative, les deux voyagent toujours ensemble et le CMAC doit se trouver à la fin du message NDEF. Concevez votre structure d'URL autour de ces contraintes, et non l'inverse, sinon les décalages ne seront pas résolus et le backend rejettera chaque lecture.

 

L’échec que nous constatons le plus souvent lors des déploiements SUN n’a rien à voir avec tout cela. Chaque serveur de démonstration et d'implémentation de référence publique est livré configuré avec les clés à zéro par défaut -par défaut, car c'est ce qui fait qu'une démo fonctionne immédiatement. Les projets prototypent par rapport à cela, le prototype fonctionne et l'étape de rotation des clés ne figure jamais sur la liste de contrôle de lancement. Les balises sont cryptographiquement nues alors que toutes les personnes impliquées pensent que le déploiement est crypté, c'est pourquoi notre propre procédure de publication d'échantillons vérifie la diversification des clés sur les unités de production plutôt que sur tout ce qui a été utilisé pour la démo.

 

Six opérations que vous ne pouvez pas annuler une fois que vous avez programmé les balises NFC

 

Les réécritures de charge utile sont bon marché. Ce n’est pas le cas. Chacune ci-dessous est une décision qui convertit un lot d'étiquettes en immobilisation, et chacune d'elles a été la cause d'un inventaire mis au rebut que nous avons personnellement dû remplacer.

 

Opération	Ce que ça fait	Pourquoi cela ne peut pas être annulé	Quand il devrait être programmé
Formatage NDEF	Écrit le conteneur de capacités	Atterrit dans une-mémoire programmable unique-	En usine, après confirmation du type de puce
Bits de verrouillage statique	Verrouille les 16 premières pages sur les puces de type 2	Les bits de verrouillage sont définis-uniquement et ne peuvent pas être réinitialisés.	Seulement après la signature du contenu final
Bits de verrouillage dynamique	Couvre 96 octets de données sur NTAG213, 456 sur NTAG215 et 840 sur NTAG216, avec une granularité de 2 pages sur NTAG213 et 16 pages sur NTAG215 et NTAG216, selon la fiche technique NXP citée ci-dessus	Même mécanisme d'ensemble-uniquement, même permanence	Même portail que les serrures statiques
Commutateur de lecture-seule	Définit l'indicateur d'écriture NDEF de manière permanente	Aucune commande inverse n'existe	Jamais avant la fin des essais sur le terrain
Mode LRP sur NTAG 424 DNA	Bascule AES vers un fonctionnement résistant aux fuites-	Activé par SetConfiguration, sans chemin de retour vers le mode AES	Uniquement si un modèle de menace documenté l'exige
Changement de clé sans séquestre	Remplace les clés AES d'usine	La puce n'a pas de chemin de récupération si la nouvelle clé est perdue	Seulement une fois que la garde des clés est formellement attribuée

 

Cette granularité de page est le détail pratique qui manque à la plupart des gens lorsqu'ils demandent comment verrouiller une balise NFC après la programmation. Le verrouillage n'est pas un simple commutateur tout-ou-rien. Sur les NTAG215 et NTAG216, vous pouvez verrouiller des blocs de 16 pages, ce qui rend viable une mise en page mixte : une région de numéro de série verrouillée en usine, une région d'URL de campagne laissée en écriture pour l'équipe marketing. Sur NTAG213, la granularité est de deux pages, plus fine mais sur une carte beaucoup plus petite. Décider de la limite est une tâche de conception, et cela doit se produire avant l’exécution du codage, et non après.

 

L'habitude qui mérite d'être prise est de séparer la porte de codage de la porte de verrouillage. Nous déconseillons aux clients de verrouiller au moment de la commande, et la raison est entièrement commerciale plutôt que technique.

 

D'après notre historique de commandes, la demande après-livraison la plus fréquente n'est pas une réclamation pour défaut, mais un changement de destination, et elle se regroupe au cours de la première année de service. Les déclencheurs habituels sont une migration de page de destination ou un transfert d’agence, dont aucun n’est visible au moment où la commande est passée. Vous n'avez besoin des statistiques d'échec de personne pour agir, car l'asymétrie décide d'elle-même : une étiquette déverrouillée qui n'a jamais besoin d'être changée ne vous coûte rien, tandis qu'une étiquette verrouillée qui doit être changée coûte une commande de remplacement complète plus le travail de réinstallation. Programmez d'abord les balises NFC, exécutez l'essai sur le terrain, verrouillez ensuite.

 

Vérifier la puce est ce que dit la facture

 

 

L'authenticité de la puce n'est pas une préoccupation paranoïaque dans cette catégorie, il s'agit d'un élément d'inspection de routine-à l'arrivée, et il appartient à la même étape de contrôle qualité que toute autre vérification que vous effectuez avant de programmer des balises NFC en quantités de production. Les familles NTAG, MIFARE, Ultralight et ICODE de NXP portent chacune une signature d'originalité basée sur ECC-écrite lors de la production de la puce, 32 octets sur les pièces NTAG21x, qui peut être relue et vérifiée par rapport à la clé publique du fabricant. Une balise qui se comporte parfaitement peut toujours échouer à cette vérification.

 

Cela se produit plus souvent que ne l’admet le marché. Les ingénieurs achetant des étiquettes NTAG21x via les canaux de vente au détail généraux ont signalé à la communauté du fabricant que les échantillons fonctionnaient exactement comme spécifié, contre-miroir inclus, mais qu'ils étaient signalés comme du silicium clone sous vérification d'originalité, et la réponse publiée par NXP est que ces pièces ne sont pas prises en charge et ne conviennent pas à une utilisation sécurisée car le circuit intégré lui-même peut être vulnérable (Communauté NXP).

 

Les conséquences opérationnelles sont plus limitées que ce que l’on pense et méritent d’être précisées. Si votre application est une redirection marketing, une puce clone vous servira de manière adéquate et vous ne vous en soucierez peut-être pas. Si votre application implique une authentification, une preuve d'altération ou toute réclamation anti-contrefaçon adressée à votre propre client, une puce invérifiable invalide l'intégralité du principe et aucun codage correct ne la compense. La vérification prend quelques secondes par échantillon avec une application de lecture, et elle appartient à votre procédure de contrôle qualité entrant plutôt qu'à une autopsie -post-mortem. Lecture connexe pour toute personne dont l'écriture est terminée mais dont le lecteur reste silencieux :pourquoi un autocollant cloné se lit bien et échoue toujours à la porte.

 

La question de sécurité classique MIFARE, reformulée honnêtement

 

Quiconque choisit MIFARE Classic aujourd'hui devrait travailler à partir de son poste de recherche actuel plutôt que de la réputation qu'avait la plateforme il y a dix ans.

 

En 2024, une étude du FM11RF08S, une puce compatible MIFARE Classic lancée en 2020 avec des contre-mesures spécialement conçues pour résister à toutes les attaques connues uniquement par carte -, a vaincu ces contre-mesures et a découvert une porte dérobée matérielle dans le processus. La porte dérobée permet à toute partie qui en a connaissance de compromettre chaque clé définie par l'utilisateur sur la carte dans les minutes qui suivent l'accès physique, et cela est valable même lorsque les clés ont été entièrement diversifiées par carte (Archives ePrint de cryptologie). Les clés de porte dérobée associées ont été identifiées sur un ensemble plus large de pièces, y compris les générations Fudan antérieures et les appareils NXP et Infineon spécifiques.

 

Lisez-le attentivement avant d’en tirer de fausses conclusions. Cela ne veut pas dire que tous ceux qui utilisent MIFARE Classic seront exposés demain, et nous ne le présentons pas comme tel. Des millions d'identifiants Classic fonctionnent dans des environnements à faibles-conséquences où le clonage d'une carte permet à un attaquant d'accéder à un casier de salle de sport. C'est un argument selon lequel l'expression « sécurisé » ne devrait apparaître nulle part dans un document de spécification à côté de cette famille de puces, et que toute personne s'apprêtant à programmer des balises NFC pour les chambres d'hôtel, l'accès au bureau ou le paiement sans espèces sur du silicium classique devrait prévoir une migration vers une partie basée sur AES-dans le même cycle budgétaire.

 

Programmation de tags NFC en masse : ce qui change au-dessus de mille unités

 

Tout ce qui a été décrit jusqu’à présent évolue mal. Une application téléphonique écrit une balise à la fois sans enregistrement de lot, sans passe de vérification et sans moyen de prouver par la suite quelle URL est allée sur quelle unité physique. Il existe trois niveaux de programmation groupée de balises NFC, et le saut entre eux est opérationnel plutôt que technique.

 

Le premier niveau est constitué d'un téléphone et d'une application, viables sur une centaine d'unités, adaptés aux prototypes et aux pilotes internes.

 

Le deuxième niveau est celui où atterrissent la plupart des équipes internes : vous programmez des balises NFC avec un lecteur-enregistreur sur un ordinateur de bureau, piloté par un fichier batch, généralement via un encodeur USB de la classe ACR12xx ou uTrust. Fonctionne bien jusqu'à ce que la puce change. L'outil batch open source - largement utilisé dans cet espace, par exemple, cible spécifiquement l'ACR122 et encode uniquement MIFARE Ultralight et Ultralight C, qui sont des pièces de type 2, donc déplacer ce projet vers une puce de type 4 signifie reconstruire l'outillage plutôt que de modifier un fichier de configuration. Si vous choisissez toujours du matériel pour ce niveau, notreLecteurs NFC USB et de bureau-gamme d'écriturecouvre les modèles de lecteurs attendus par ces chaînes d'outils.

 

La pratique industrielle pour le troisième niveau consiste à pré-encoder pendant la fabrication, et il s'agit du niveau dont la plupart des acheteurs ignorent l'existence. Sur nos lignes situées dans une usine de 3 600 m², le codage se situe entre le collage des puces et l'assemblage final, sur un équipement qui indexe chaque étiquette en position, écrit l'enregistrement et le relit avant que l'étiquette ne continue. La passe de vérification est tout l’intérêt. Une balise qui échoue à la lecture-est rejetée en-ligne plutôt que découverte par un client sur le terrain, et le lot repart avec un fichier de mappage reliant chaque UID ou TID au contenu exact qui y est écrit, ce dont votre CMS ou votre plateforme d'analyse a besoin dès le premier jour. La capacité de collage automatisée sur cinq lignes de production dépasse 100 000 puces par jour, de sorte que l'encodage ne devient pas une contrainte sur les délais de livraison.

 

Ce que cette description laisse délibérément de côté, c’est le seuil d’acceptation. La vérification par relecture-est une porte de réussite/échec, mais le taux d'échec que vous devez contractuellement accepter diffère selon la famille de puces, le facteur de forme et si l'étiquette est plastifiée par la suite ; un autocollant anti-métal et une carte PVC ne se comportent pas de la même manière sur la même ligne. Ce numéro appartient à un devis correspondant à votre version spécifique, pas à un article, et c'est la première chose que nous définissons lorsqu'un nouveau programme démarre.

 

Il convient de préciser clairement où nous traçons nos propres limites de capacités, car ce sont les fournisseurs de pièces qui sont généralement flous. Nous allons pré-programmer les balises NFC avec votre modèle d'URL, sérialiser par unité, vérifier chaque balise et livrer le fichier de mappage. Nous fournirons les clés AES que vous fournissez. Nous ne conserverons pas vos clés de production, nous n'exploiterons pas votre backend de validation et nous ne vous dirons pas qu'une usine peut rendre correcte la conception de la sécurité d'une couche d'application-. Cette partie vous appartient, et tout fournisseur prétendant le contraire vous vend un transfert de risque qui n’existe pas.

 

Neuf questions à régler avant l'exécution de l'encodage

 

Exécutez cette opération avant le bon de commande, et non après l'arrivée des échantillons. Chaque élément a mis fin à au moins un projet qu'il nous a été demandé de sauver.

 

#	Question	Pourquoi il décide de la puce
1	Les iPhones exploiteront-ils ces balises ?	Supprime complètement MIFARE Classic de la considération
2	Quelle est la longueur complète de l'URL, y compris les futurs paramètres ?	Définit le sol à NTAG213, 215 ou 216
3	Un seul enregistrement suffit-il, ou avez-vous également besoin d'un enregistrement de texte ou d'un enregistrement d'application ?	Les enregistrements supplémentaires consomment le même budget mémoire
4	La destination changera-t-elle au cours de la durée de vie du tag ?	Détermine si le verrouillage est un jour acceptable
5	L'application revendique-t-elle son authenticité auprès des utilisateurs finaux ?	Vous pousse vers NTAG 424 DNA ou DESFire
6	Qui détient et fait tourner les clés AES ?	Doit être attribué avant qu’une clé ne soit modifiée
7	Quel est le critère d’acceptation d’un lot livré ?	Définit si-la vérification par relecture est contractuelle
8	Avez-vous besoin d'un UID-pour-fichier de mappage de contenu ?	Doit être spécifié avant l'exécution, non demandé après
9	La vérification de la signature d’originalité fait-elle partie du contrôle qualité entrant ?	Détermine si l'approvisionnement en puces est vérifiable

 

Les équipes qui peuvent répondre aux neuf questions obtiennent généralement une production propre dès la première tentative. Les équipes qui peuvent répondre à six sur neuf découvrent généralement les trois autres de manière coûteuse.

 

Les neuf questions sont la version générique. Celui sur lequel nous travaillons réellement ajoute une dixième colonne, la réponse qui convient à votre build plutôt qu'en général, et cette colonne dépend de choses que cet article ne peut pas voir : votre combinaison de combinés, votre parc de lecteurs, votre processus de plastification et si la sérialisation doit être séquentielle ou aléatoire. Envoyez-nous les neuf premières réponses et nous vous renverrons la version annotée selon vos spécifications.

 

Où cela laisse un acheteur

 

Il n'existe pas de procédure générale pour programmer les tags NFC, seulement une procédure par puce, par plateforme, par volume. Choisissez d'abord la puce contre le plafond de mémoire et la question de l'iPhone. Traitez le formatage, la charge utile et la configuration comme trois portes distinctes. Ne verrouillez jamais avant un essai sur le terrain. Vérifier l'originalité des échantillons entrants. Au-dessus de mille unités, arrêtez de penser aux applications et commencez à penser à la vérification et à la traçabilité.

 

Si une spécification est déjà rédigée, nous serons heureux de l'examiner par rapport aux contraintes de puce ci-dessus et de signaler tout ce qui ne survivra pas à la production, et des échantillons gratuits sont disponibles pour les tester sur vos lecteurs et combinés actuels. Vous pouvez également partir duFormats de balises NFC que nous pré-programmons et vérifions en interne-si la décision de puce est toujours ouverte, ouenvoyer la structure de l'URL et le volume cible pour une révision de l'encodagesi c'est déjà réglé.

 

FAQ