Com programar etiquetes NFC amb diferents tipus de xip (NTAG, MIFARE i més)

 

Escriure una etiqueta és tres operacions separades, no una

 

Quan la gent diu que vol programar etiquetes NFC, normalment descriuen tres coses diferents que es desencadenen amb el mateix botó en una aplicació de telèfon.

 

El primer ésformatació. S'ha de dir a la memòria d'un xip NFC que la seva àrea d'usuari conté un missatge NDEF en lloc de bytes arbitraris. Això es fa escrivint una petita estructura de dades coneguda com a contenidor de capacitat. A les peces NTAG21x, això ja es fa al nivell de l'hòstia, de manera que el xip arriba amb format NDEF-i només pot contenir NDEF. A MIFARE Classic i alguns altres xips, el format és una cosa que realitzeu i l'estructura arriba a una-regió-programable única. Per tant, el format és permanent. No hi ha cap ordre sense format, ni cap eina de proveïdor que us doni una.

 

El segon ésescrivint la càrrega útil: un missatge NDEF que conté un o més registres, sovint un registre URI que apunta a una URL. Aquesta és la part que tothom fotografia. Les escriptures de càrrega útil normalment es poden repetir, per això un equip de màrqueting pot redirigir una etiqueta de campanya sis mesos més tard sense reordenar el maquinari.

 

El tercer ésconfiguració: bytes de contrasenya, bits de bloqueig, paràmetres de mirall, condicions d'accés, claus d'autenticació. Aquesta capa és on viuen les decisions irreversibles, i és la capa que no toca cap tutorial de consumidors. Si teniu previst programar etiquetes NFC per a qualsevol cosa amb un límit de seguretat al seu voltant, la capa de configuració és el projecte.

 

Mantenir aquests tres separats al cap és el que impedeix que un lot es descarti. La majoria dels errors d'escriptura que diagnosticem no són errors de càrrega útil. Són un estat de format o un estat de configuració que algú no sabia que existia.

 

Tipus de xip d'etiquetes NFC comparats abans de programar-los

 

Totes les decisions serioses sobre com programar etiquetes NFC a escala comença amb aquesta taula, perquè el sostre de memòria i el suport de la plataforma s'estableixen en el moment de la selecció del xip i no es poden aplicar més endavant al programari.

 

Xip	Memòria d'usuari	Tipus de fòrum NFC	Estat NDEF de fàbrica	Protecció amb contrasenya / clau	iPhone NDEF lectura + escriptura
NTAG 213	144 bytes	Tipus 2	Pre-formatat	PWD de 32 bits / PACK de 16 bits	Sí
NTAG 215	504 bytes	Tipus 2	Pre-formatat	PWD de 32 bits / PACK de 16 bits	Sí
NTAG 216	888 bytes	Tipus 2	Pre-formatat	PWD de 32 bits / PACK de 16 bits	Sí
MIFARE Ultralight EV1	48 o 128 bytes	Tipus 2	Formatable	PWD de 32 bits / PACK de 16 bits	Sí
MIFARE Classic 1K	1.024 bytes en total, aproximadament 716 disponibles per a NDEF un cop es dedueixin el bloc del fabricant i els 16 tràilers del sector	No és un tipus de fòrum NFC	Formatable, basat en-sectors	Claus sectorials CRYPTO-1 A/B	No
MIFARE DESFire EV3	De 2 KB a 8 KB, basat en fitxer-	Tipus 4	S'ha de crear l'aplicació	AES-128/3DES, drets d'accés per fitxer	Sí
ADN NTAG 424	416 bytes en total, dividits en un contenidor de capacitat de 32 bytes, un fitxer NDEF de 256 bytes i un fitxer de dades protegit de 128 bytes	Tipus 4	Fitxers-provisionats prèviament	Cinc claus AES-128, autenticació mútua de 3 passades	Sí

 

Xifres NTAG21x, comportament-bit de bloqueig i compliment tipus 2/ISO/IEC 14443 tipus A segons laFull de dades de producte NXP NTAG213/215/216. Estructura MIFARE Classic 1K per full de dades NXP MF1S50yyX (16 sectors × 4 blocs × 16 bytes). DESFire EV3 per MF3D(H)x3. Disseny de memòria d'ADN NTAG 424 perNXP.

 

Dues columnes decideixen la majoria dels projectes abans de triar qualsevol programari: el sostre de la memòria i la columna de l'iPhone. El que la taula no et pot dir és el rendiment. Un xip especificat correctament encara produeix rebutjos si el pas de codificació no té cap pas de verificació darrere, que és l'objecte de la segona meitat d'aquest article.

 

NTAG 213, 215 i 216: l'opció predeterminada i el seu sostre real

 

Per a aproximadament quatre de cada cinc projectes d'entrada, aquesta família és la resposta correcta, i aprendre a programar etiquetes NFC NTAG 215 triga uns noranta segons amb una aplicació de telèfon. El xip s'envia amb format NDEF-, el tipus de registre que es comporta de manera coherent a tots els telèfons és un registre URI senzill, i tant Android com iOS l'escriuen sense cap tipus de treball amb l'SDK.

 

 

També és la família darrere de gairebé tots els programes de targetes de visita digitals, on una única vCard o un registre d'URL és la càrrega útil sencera, i on el format físic sol importar més que el xip. La majoria d'aquestes comandes acabentargetes NFC de PVC blanc en blancen lloc d'adhesius, perquè la targeta ha de sobreviure a una cartera i agafar una impressió.

 

El sostre arriba més ràpid del que la gent espera. NTAG213 us ofereix 144 bytes de memòria d'usuari i un missatge NDEF no és només el vostre URL. Hi ha un embolcall TLV, una capçalera de registre, un camp de tipus i un camp de longitud abans que s'emmagatzemi un sol caràcter de la vostra adreça. Un registre URI comprimeix prefixos comuns com arahttps://www.en un únic byte, que recupera de deu a vint bytes, i en una part de 144-bytes aquesta diferència és la línia entre ajustar i fallar. On els equips queden atrapats no és l'URL en si, sinó els extres: afegiu un registre de text per a una etiqueta llegible per persones, afegiu un registre d'aplicació d'Android perquè l'etiqueta obri una aplicació en lloc d'un navegador i una càrrega útil còmoda es converteixi en un error de desbordament.

 

La nostra pròpia regla general, i aquest és el tipus de coses que només s'aprèn codificant uns quants milions d'aquests: si l'URL previst, inclosos els paràmetres de consulta supera uns 90 caràcters, deixeu d'especificar NTAG213 i aneu cap amunt. La diferència de cost unitari entre 213 i 215 és prou petita que gairebé mai no val la pena el risc d'un redisseny mitjà-programa. Una campanya que més tard vulgui afegir paràmetres UTM o un número de sèrie a cada URL d'etiquetes arribarà al mur al 213 i no al 215.

 

La protecció de contrasenya d'aquesta família val la pena entendre's precisament, perquè és més feble del que suggereix la paraula "contrasenya". Un valor PWD de 32 bits es transmet en clar i es comprova pel xip, que permet l'accés d'escriptura i, opcionalment, l'accés de lectura, des d'una pàgina escollida en endavant. Impedeix que un curiós membre del públic reescrigui la teva etiqueta amb un telèfon. No és un control criptogràfic i mai s'ha de descriure a un client com un. Tingueu en compte també que no totes les generacions ho admeten en absolut: el NTAG203 anterior no té cap mecanisme de contrasenya, i la documentació de la biblioteca és explícita que les crides de protecció contra ell simplement fallen (documentació nfcpy).

 

MIFARE Classic: Es pot escriure a Android, efectivament absent a l'iPhone

 

Aquí teniu la trampa de compatibilitat que ha acabat amb més projectes NFC que qualsevol altre factor. Qualsevol que demani com escriure NDEF a MIFARE Classic ja està treballant en contra del format: MIFARE Classic no és un tipus d'etiqueta de fòrum NFC, és una targeta ISO/IEC 14443-3A amb un sector propietari i una estructura de claus anteriors a l'ecosistema NDEF, i el suport NDEF només existeix a través d'una convenció de mapeig a la part superior.

 

 

Android gestiona aquesta convenció. iOS no. El Core NFC d'Apple mai no ha donat suport a MIFARE Classic, amb les famílies MIFARE compatibles amb la plataforma limitades a Ultralight, Plus i DESFire, una posició que els desenvolupadors han confirmat repetidament als fòrums d'Apple (Fòrums de desenvolupadors d'Apple). Com que iOS no pot adreçar la memòria de la targeta directament, un iPhone no pot escriure-hi NDEF i no pot mostrar-hi NDEF emmagatzemat.

 

El que fa que això sigui tan perillós durant l'avaluació és que les etiquetes MIFARE Classic no semblen mortes en un iPhone. La targeta presenta un UID ISO 14443-A, de manera que l'aplicació Dreceres l'acceptarà encantada com a activador d'automatització, i l'exploració en segon pla encara pot iniciar un registre NDEF emmagatzemat anteriorment d'un tipus compatible. Un responsable de contractació que prova una mostra al seu iPhone veu una resposta i s'apaga. El comportament que van veure no tenia res a veure amb el contingut de la memòria de l'etiqueta, i tot l'enfocament es col·lapsa en el moment en què el projecte necessita URL per unitat que els iPhones puguin llegir.

 

La regla pràctica que surt d'això: qualsevol persona que compare com programar etiquetes NFC per a iPhone i Android hauria de fer proves d'acceptació a ambdues plataformes amb el xip de producció, mai només a Android, i mai en una mostra d'un xip diferent al de l'ordre de compra.

 

Permeteu-me ser contundent sobre la recomanació, perquè "depèn del vostre cas d'ús" no és una resposta útil aquí. Si els membres del públic tocaran les vostres etiquetes NFC, especifiqueu qualsevol cosa excepte MIFARE Classic.

 

Per als equips que ja estan dins d'un sistema d'accés basat en-clàssic, la decisió es redueix a una variable i no són les etiquetes. És la vida útil restant del vostre patrimoni lector. Si aquests lectors els queden dos o tres anys i cap telèfon intel·ligent mai tocarà la credencial, continuar amb Classic en un bucle tancat és una trucada defensable, i les qüestions pràctiques es converteixen en l'aprovisionament d'IC ​​i el format UID en lloc del mètode de codificació, que és el que cobrim a les nostres notes sobreordenar etiquetes MIFARE 1K en un sistema instal·lat. Si els mateixos lectors han de ser reemplaçats dins d'aquesta finestra, no gasteu diners en una credencial de transició. Mou tota la propietat a una part basada en AES-en un sol pas i absorbeix el cost una vegada.

 

Hi ha una segona trampa a la mateixa família, prou subtil com per sobreviure a cicles complets de control de qualitat. Si afegiu un embolcall de pòster intel·ligent a un registre, que les eines de codificació habituals ofereixen com una manera senzilla d'adjuntar un títol a un URL, canvia el tipus de registre. Els registres embolicats d'aquesta manera no són recollits per l'exploració de fons d'iOS, independentment del que hi hagi niat dins. Les proves d'Android es passen a tots els dispositius, els iPhones no fan res i no hi ha cap missatge d'error enlloc per diagnosticar.

 

Ultralight, DESFire i NTAG 424 DNA: on la programació es converteix en gestió de claus

 

MIFARE Ultralight EV1 es troba a prop de NTAG21x en comportament i programeu etiquetes NFC de la mateixa manera, amb un pressupost de memòria més petit de 48 o 128 bytes i la mateixa classe de porta de contrasenya. No passa res conceptualment nou.

 

DESFire i NTAG 424 DNA són una disciplina diferent. En aquestes parts de tipus 4, no esteu escrivint bytes en un mapa de memòria plana, esteu operant en un sistema de fitxers amb drets d'accés per-fitxers i cada operació significativa requereix autenticar-vos primer amb una clau AES-128. NTAG 424 DNA porta cinc claus AES definides pel client, utilitza l'autenticació mútua de 3 passades per al fitxer de dades protegit i porta la certificació Common Criteria EAL4 tant en maquinari com en programari. Els equips que programen etiquetes NFC per a l'autenticació del producte en lloc de la simple redirecció solen buscar aquesta part específicament, a causa d'una característica.

 

Aquesta característica és Secure Dynamic Messaging, sovint escrit com SUN. Amb aquesta activació, l'URL NDEF que el xip presenta canvis a cada toc: el xip reflecteix el seu UID i un comptador de lectura monòtonament creixent a l'URL, opcionalment xifrat, i afegeix un CMAC calculat amb una clau només tu i el xip. Aleshores, el vostre backend pot distingir una etiqueta real d'un URL fotografiat i pot distingir el toc número 4 del toc número 4.000.

 

Configurar-lo correctament és on pica l'especificació. Les regles de rèplica no són de forma lliure-: quan les dades PICC estan xifrades, la rèplica de l'UID i el comptador de lectura esdevé obligatòria en lloc d'opcional, les dues sempre viatgen juntes i el CMAC s'ha de situar al final del missatge NDEF. Dissenyeu la vostra estructura d'URL al voltant d'aquestes limitacions, no al revés, o els desplaçaments no es resoldran i el backend rebutjarà cada lectura.

 

El fracàs que veiem més sovint als desplegaments de SUN no té res a veure amb això. Cada implementació de referència pública i servidor de demostració s'envia configurat amb les claus-per defecte de fàbrica-zero, perquè això és el que fa que una demostració funcioni de manera immediata. Projecte prototip contra això, el prototip funciona i el pas de rotació de claus mai arriba a la llista de verificació de llançament. Les etiquetes surten nues criptogràficament, mentre que tots els implicats creuen que el desplegament està xifrat, per això el nostre propi procediment d'alliberament de mostra comprova la diversificació de claus a les unitats de producció en lloc del que s'ha utilitzat per a la demostració.

 

Sis operacions que no podeu revertir un cop programeu les etiquetes NFC

 

Les reescriptures de càrrega útil són barates. Aquests no ho són. Cadascun d'ells a continuació és una decisió que converteix un lot d'etiquetes en un actiu fix, i cadascuna ha estat la causa de l'inventari desballestat que personalment hem hagut de substituir.

 

Funcionament	Què fa	Per què no es pot desfer	Quan s'hauria de programar
Format NDEF	Escriu el contenidor de capacitat	Aterra en una-memoria programable-temps	A la fàbrica, després de confirmar el tipus de xip
Bits de bloqueig estàtics	Bloqueja les primeres 16 pàgines als xips de tipus 2	Els bits de bloqueig només s'estableixen-i no es poden restablir	Només després de tancar el contingut final
Bits de bloqueig dinàmics	Cobriu 96 bytes de dades a NTAG213, 456 a NTAG215 i 840 a NTAG216, amb una granularitat de 2 pàgines a NTAG213 i 16 pàgines a NTAG215 i NTAG216, segons el full de dades de NXP citat anteriorment	El mateix conjunt-mecanisme, la mateixa permanència	La mateixa porta que els panys estàtics
Interruptor de només lectura-	Estableix la marca d'escriptura NDEF permanentment	No existeix cap comanda inversa	Mai abans de la finalització de la prova de camp
Mode LRP a l'ADN NTAG 424	Canvia l'AES a un funcionament-resistent a les fuites	Habilitat per SetConfiguration, sense camí de tornada al mode AES	Només si un model d'amenaça documentat ho requereix
Canvi de clau sense custodia	Substitueix les claus AES de fàbrica	El xip no té camí de recuperació si es perd la nova clau	Només un cop s'assigna formalment la custòdia de les claus

 

La granularitat de la pàgina és el detall pràctic que la majoria de la gent es perd quan pregunta com bloquejar una etiqueta NFC després de programar-la. El bloqueig no és un únic canvi de tot-o-res. A NTAG215 i NTAG216 podeu bloquejar blocs de 16 pàgines, la qual cosa fa que un disseny mixt sigui viable: una regió de número de sèrie bloquejada a la fàbrica, una regió d'URL de campanya deixada per escriure per a l'equip de màrqueting. A NTAG213, la granularitat és de dues pàgines, més fina però en un mapa molt més petit. Decidir el límit és una tasca de disseny i ha de passar abans de l'execució de la codificació, no després.

 

L'hàbit que val la pena construir és separar la porta de codificació de la porta de bloqueig. Aconsellem als clients que no bloquegin al moment de la comanda, i el motiu és totalment comercial més que tècnic.

 

Al llarg del nostre historial de comandes, la sol·licitud de post{0}}entrega més freqüent no és una reclamació d'un defecte, és un canvi de destinació i s'agrupa durant el primer any de servei. Els desencadenants habituals són una migració de la pàgina de destinació o un traspàs d'una agència, cap dels quals és visible en el moment en què es fa la comanda. No necessiteu les estadístiques de fallades de ningú per actuar en això, perquè l'asimetria ho decideix per si sola: una etiqueta desbloquejada que no cal canviar mai no us costa res, mentre que una etiqueta bloquejada que cal canviar costa una comanda de substitució completa més la mà d'obra de reinstal·lació. Programeu primer les etiquetes NFC, executeu la prova de camp i bloquegeu després.

 

La verificació del xip és el que diu la factura

 

 

L'autenticitat del xip no és una preocupació paranoica en aquesta categoria, és un element d'inspecció-de rutina i pertany al mateix pas de control de qualitat que qualsevol altra comprovació que feu abans de programar etiquetes NFC en quantitats de producció. Les famílies NTAG, MIFARE, Ultralight i ICODE d'NXP porten cadascuna una signatura d'originalitat basada en ECC-escrita a la producció de xips, 32 bytes en peces NTAG21x, que es pot llegir i verificar amb la clau pública del fabricant. Una etiqueta que es comporta perfectament encara pot fallar aquesta comprovació.

 

Això passa més del que admet el mercat. Els enginyers que compren etiquetes NTAG21x a través de canals minoristes generals han informat a la comunitat del fabricant que les mostres funcionen exactament tal com s'especifica, inclosa la duplicació del comptador, però informen com a silici clonat sota verificació d'originalitat, i la resposta publicada de NXP és que aquestes peces no són compatibles i no són aptes per a un ús segur perquè el propi IC pot ser vulnerable (Comunitat NXP).

 

La conseqüència operativa és més limitada del que la gent suposa, i val la pena dir-ho amb precisió. Si la vostra aplicació és una redirecció de màrqueting, un xip de clon us servirà adequadament i és possible que no us importi. Si la vostra aplicació implica autenticació, proves de manipulació o qualsevol reclamació contra-falsificació feta al vostre propi client, un xip no verificable invalida tota la premissa i cap quantitat de codificació correcta ho compensa. La verificació triga uns segons per mostra amb una aplicació de lectura i pertany al vostre procediment de control de qualitat entrant en lloc d'una -mortem post. Lectures relacionades per a qualsevol persona que hagi acabat d'escriure, però el lector roman en silenci:per què un adhesiu clonat es llegeix bé i encara falla a la porta.

 

La pregunta de seguretat clàssica de MIFARE, reafirmada amb honestedat

 

Qualsevol persona que especifiqui MIFARE Classic avui hauria de treballar des de la posició actual de recerca en lloc de la reputació que tenia la plataforma fa una dècada.

 

L'any 2024, un estudi del FM11RF08S, un xip compatible MIFARE Classic llançat el 2020 amb contramesures dissenyades específicament per resistir tots els atacs coneguts de targetes-només, va derrotar aquestes contramesures i va descobrir una porta posterior de maquinari en el procés. La porta del darrere permet a qualsevol part que en conegui comprometre totes les claus definides per l'usuari-a la targeta en qüestió de minuts després de l'accés físic, i això es manté fins i tot quan les claus s'han diversificat completament per targeta (Arxiu Criptologia ePrint). Les claus de la porta posterior relacionades es van identificar en un conjunt més ampli de peces, incloses les generacions anteriors de Fudan i els dispositius NXP i Infineon específics.

 

Llegeix-ho atentament abans de treure'n una conclusió equivocada. Aquest no és un argument que tothom que faci servir MIFARE Classic estigui exposat demà, i no el presentem com un. Milions de credencials Classic funcionen en entorns de baixes-conseqüències en què la clonació d'una targeta permet que un atacant accedeixi a un armari de gimnàs. És un argument que la frase "segur" no hauria d'aparèixer enlloc d'un document d'especificacions al costat d'aquesta família de xips, i que qualsevol persona que estigui a punt de programar etiquetes NFC per a habitacions d'hotel, accés a oficines o pagament sense efectiu amb silici clàssic hauria de valorar una migració a una part basada en AES-en el mateix cicle pressupostari.

 

Programació d'etiquetes NFC a granel: què canvia per sobre de mil unitats

 

Tot el que s'ha descrit fins ara s'escala malament. Una aplicació de telèfon escriu una etiqueta a la vegada sense cap registre per lots, sense cap pas de verificació i sense cap manera de demostrar després quin URL va anar a quina unitat física. Hi ha tres nivells sobre com programar etiquetes NFC a granel, i el salt entre ells és operatiu més que tècnic.

 

El primer nivell és un telèfon i una aplicació, viables per aproximadament un centenar d'unitats, adequats per a prototips i pilots interns.

 

El segon nivell és on arriben la majoria dels-equips interns: programeu etiquetes NFC amb un escriptor lector en un escriptori, impulsat per un fitxer per lots, normalment mitjançant un codificador USB de la classe ACR12xx o uTrust. Funciona bé fins que canvia el xip. L'eina per lots de codi obert-àmpliament utilitzada en aquest espai, per exemple, s'adreça específicament a l'ACR122 i només codifica MIFARE Ultralight i Ultralight C, que són parts de tipus 2, de manera que moure aquest projecte a un xip de tipus 4 significa reconstruir l'eina en lloc d'editar un fitxer de configuració. Si encara esteu escollint maquinari per a aquest nivell, el nostreInterval d'escriptura-de lectors NFC d'escriptori i USBcobreix els models de lectors que esperen aquestes cadenes d'eines.

 

La pràctica del sector per al tercer nivell és la pre-codificació durant la fabricació, i aquest és el nivell que la majoria dels compradors no saben que existeix. A les nostres línies d'una planta de 3.600 m², la codificació es troba entre la unió de xips i el muntatge final, en un equip que indexa cada etiqueta en posició, escriu el registre i el torna a llegir abans que l'etiqueta passi. La passada de verificació és el punt sencer. Una etiqueta que falla la lectura-es rebutja-en línia en lloc de ser descoberta per un client al camp, i el lot surt amb un fitxer de mapes que enllaça cada UID o TID amb el contingut exacte escrit en ella, que és el que el vostre CMS o plataforma d'anàlisi necessita el primer dia. La capacitat d'enllaç automatitzat en cinc línies de producció supera els 100.000 xips per dia, de manera que la codificació no es converteix en la limitació del temps de lliurament.

 

El que aquesta descripció deixa de banda, deliberadament, és el llindar d'acceptació. La verificació de lectura-retorn és una porta d'aprovació/falla, però la taxa de fracàs que hauríeu d'acceptar contractualment difereix segons la família de xips, el factor de forma i si l'etiqueta s'està laminant després; un adhesiu anti-metall i una targeta de PVC no es comporten de la mateixa manera en la mateixa línia. Aquest número pertany a una cita de la vostra compilació específica, no a un article, i és el primer que establim quan s'inicia un programa nou.

 

Val la pena indicar-ho clarament on tracem el nostre propi límit de capacitat, perquè és el que solen desdibuixar els proveïdors de peces. -Preprogramarem etiquetes NFC amb la vostra plantilla d'URL, serialitzarem per unitat, verificarem totes les etiquetes i lliurarem el fitxer de mapatge. Proporcionarem les claus AES que proporcioneu. No conservarem les vostres claus de producció, no operarem el vostre backend de validació i no us direm que una fàbrica pot fer que un disseny de seguretat de la-aplicació sigui correcte. Aquesta part és vostra i qualsevol proveïdor que afirma el contrari us ven una transferència de risc que no existeix.

 

Nou preguntes per resoldre abans de l'execució de codificació

 

Executeu-ho abans de l'ordre de compra, no després que arribin les mostres. Cada element ha finalitzat almenys un projecte que ens han demanat rescatar.

 

#	Pregunta	Per què decideix el xip
1	Els iPhones tocaran aquestes etiquetes?	Elimina totalment MIFARE Classic de la consideració
2	Quina és la longitud completa de l'URL, inclosos els paràmetres futurs?	Estableix el sòl a NTAG213, 215 o 216
3	N'hi ha prou amb un registre o necessiteu també un registre de text o un registre d'aplicació?	Els registres addicionals consumeixen el mateix pressupost de memòria
4	Canviarà la destinació durant la vida útil de l'etiqueta?	Determina si el bloqueig és acceptable
5	L'aplicació fa una reclamació d'autenticitat als usuaris finals?	Us porta a NTAG 424 DNA o DESFire
6	Qui manté i gira les tecles AES?	S'ha d'assignar abans de canviar qualsevol clau
7	Quin és el criteri d'acceptació d'un lot lliurat?	Defineix si la verificació-relectura és contractual
8	Necessites un fitxer d'assignació d'UID-a-contingut?	S'ha d'especificar abans de la carrera, no sol·licitar després
9	La verificació de la signatura d'originalitat forma part del control de qualitat entrant?	Determina si l'obtenció de xips és auditable

 

Els equips que poden respondre als nou solen obtenir una producció neta al primer intent. Els equips que poden respondre sis de nou solen descobrir els tres restants de manera cara.

 

Les nou preguntes són la versió genèrica. La que realment treballem afegeix una desena columna, la resposta adequada per a la vostra compilació i no en general, i aquesta columna depèn de les coses que aquest article no pot veure: la vostra combinació de telèfons, el vostre estat del lector, el vostre procés de laminació i si la serialització ha de ser seqüencial o aleatòria. Envieu-nos les nou primeres respostes i us tornarem la versió anotada contra la vostra especificació.

 

On això deixa un comprador

 

No hi ha cap procediment general sobre com programar etiquetes NFC, només un procediment per xip, per plataforma i per volum. Trieu el xip contra el sostre de la memòria i la pregunta de l'iPhone primer. Tracteu el format, la càrrega útil i la configuració com tres portes separades. No tanqueu mai abans d'una prova de camp. Comproveu l'originalitat de les mostres entrants. Per sobre de mil unitats, deixa de pensar en aplicacions i comença a pensar en la verificació i la traçabilitat.

 

Si ja s'ha redactat una especificació, ens complau revisar-la amb les restriccions de xip anteriors i marcar qualsevol cosa que no sobreviurà a la producció, i hi ha mostres gratuïtes disponibles per provar-les als vostres lectors i telèfons reals. També podeu començar des delFormats d'etiquetes NFC que pre-programem i verifiquem a-casasi la decisió del xip encara està oberta, oenviar l'estructura de l'URL i el volum objectiu per a una revisió de codificaciósi ja està arreglat.

 

Preguntes freqüents