Cómo programar etiquetas NFC con diferentes tipos de chips (NTAG, MIFARE y más)
Jul 29, 2026
Dejar un mensaje
La aplicación dice "Escribir correctamente". El lector sigue sin hacer nada.
Este es el mensaje de soporte más común que recibimos después de la primera ejecución de codificación de un cliente. Nada en el flujo de trabajo parecía incorrecto. El teléfono sonó, apareció un cheque verde y la etiqueta se colocó en el producto. En la puerta, o en el quiosco, o en el iPhone del equipo de marketing, no pasa absolutamente nada. Casi nadie que se propone programar etiquetas NFC espera que el error llegue después de que la escritura se haya realizado correctamente.
Antes de continuar, vale la pena saber para quién está escrito, porque los resultados de búsqueda sobre este tema atienden a dos audiencias completamente diferentes. Si tienes una pegatina y un teléfono y quieres tener tu contraseña de Wi-Fi, salta a la sección NTAG, sigue esos dos pasos y terminarás en un minuto. Si está especificando un chip para un lote que tiene que sobrevivir a los iPhones, una revisión de seguridad y una orden de compra, el resto es la información que damos a nuestros propios clientes, incluida la parte en la que le decimos lo que una fábrica no puede hacer por usted.

Casi todas las guías sobre programación de etiquetas NFC tratan la etiqueta como un contenedor genérico: descargue una aplicación, toque Escribir, mantenga el teléfono cerca. Ese modelo funciona exactamente para una situación, que es una única pegatina NTAG21x escrita por un teléfono Android para uso personal. En el momento en que cambia el chip, el volumen o la audiencia incluye usuarios de iPhone, el modelo deja silenciosamente de describir la realidad.
Escribir una etiqueta son tres operaciones separadas, no una
Cuando las personas dicen que quieren programar etiquetas NFC, generalmente describen tres cosas distintas que se activan con el mismo botón en una aplicación de teléfono.
El primero esformateo. Se debe indicar a la memoria de un chip NFC que su área de usuario contiene un mensaje NDEF en lugar de bytes arbitrarios. Esto se hace escribiendo una pequeña estructura de datos conocida como contenedor de capacidades. En las piezas NTAG21x, esto ya se hace a nivel de oblea, por lo que el chip llega con formato NDEF-y solo puede contener NDEF. En MIFARE Classic y algunos otros chips, el formateo es algo que usted realiza y la estructura aterriza en una región programable-una sola vez-. Por lo tanto, el formateo es permanente. No existe un comando para cambiar el formato ni ninguna herramienta de proveedor que le brinde uno.
El segundo esescribiendo la carga útil: un mensaje NDEF que contiene uno o más registros, generalmente un registro URI que apunta a una URL. Esta es la parte que todos imaginan. Las escrituras de carga útil normalmente son repetibles, razón por la cual un equipo de marketing puede redirigir una etiqueta de campaña seis meses después sin tener que volver a pedir hardware.
El tercero esconfiguración: bytes de contraseña, bits de bloqueo, configuración de espejo, condiciones de acceso, claves de autenticación. Esta capa es donde viven las decisiones irreversibles, y es la capa que ningún tutorial para consumidores toca en absoluto. Si planea programar etiquetas NFC para cualquier cosa que tenga un límite de seguridad a su alrededor, la capa de configuración es el proyecto.
Mantener estos tres separados en su cabeza es lo que evita que un lote sea desechado. La mayoría de los errores de escritura que diagnosticamos no son errores de carga útil. Son un estado de formato o un estado de configuración que alguien no sabía que existía.
Tipos de chips de etiquetas NFC comparados antes de programarlos
Toda decisión seria sobre cómo programar etiquetas NFC a escala comienza con esta tabla, porque el límite de memoria y el soporte de plataforma se establecen en el momento de la selección del chip y no se pueden parchear más adelante en el software.
| Chip | Memoria de usuario | Tipo de foro NFC | Estado NDEF de fábrica | Protección con contraseña/clave | iPhone NDEF lectura + escritura |
|---|---|---|---|---|---|
| NTAG 213 | 144 bytes | Tipo 2 | Pre-formateado | Contraseña de 32 bits / PAQUETE de 16 bits | Sí |
| NTAG 215 | 504 bytes | Tipo 2 | Pre-formateado | Contraseña de 32 bits / PAQUETE de 16 bits | Sí |
| NTAG 216 | 888 bytes | Tipo 2 | Pre-formateado | Contraseña de 32 bits / PAQUETE de 16 bits | Sí |
| MIFARE Ultraligero EV1 | 48 o 128 bytes | Tipo 2 | Formateable | Contraseña de 32 bits / PAQUETE de 16 bits | Sí |
| MIFARE Clásico 1K | 1.024 bytes en total, aproximadamente 716 disponibles para NDEF una vez que se deducen el bloque del fabricante y los 16 avances del sector | No es un tipo de foro NFC | Formateable, basado en-sectores | Claves de sector CRYPTO-1 A/B | No |
| MIFARE DESFire EV3 | De 2 KB a 8 KB, basado en archivos- | Tipo 4 | Se debe crear la aplicación | AES-128/3DES, derechos de acceso por archivo | Sí |
| NTAG 424 ADN | 416 bytes en total, divididos en un contenedor con capacidad de 32 bytes, un archivo NDEF de 256 bytes y un archivo de datos protegidos de 128 bytes | Tipo 4 | Archivos pre-aprovisionados | Cinco claves AES-128, autenticación mutua de 3 pasos | Sí |
Cifras NTAG21x, comportamiento de bloqueo-bit y cumplimiento de Tipo 2/ISO/IEC 14443 Tipo A según laFicha técnica del producto NXP NTAG213/215/216. Estructura MIFARE Classic 1K según la hoja de datos de NXP MF1S50yyX (16 sectores × 4 bloques × 16 bytes). DESFire EV3 por MF3D(H)x3. Diseño de memoria de ADN NTAG 424 porNXP.
Dos columnas deciden la mayoría de los proyectos antes de elegir cualquier software: el límite de memoria y la columna del iPhone. Lo que la tabla no puede decirle es el rendimiento. Un chip correctamente especificado aún produce rechazos si el paso de codificación no tiene un pase de verificación detrás, que es el tema de la segunda mitad de este artículo.
NTAG 213, 215 y 216: la opción predeterminada y su techo real
Para aproximadamente cuatro de cada cinco proyectos entrantes, esta familia es la respuesta correcta, y aprender a programar etiquetas NFC NTAG 215 lleva unos noventa segundos con una aplicación de teléfono. El chip se entrega con formato NDEF-, el tipo de registro que se comporta de manera consistente en todos los teléfonos es un registro URI simple, y tanto Android como iOS lo escriben sin ningún trabajo de SDK.

También es la familia detrás de casi todos los programas de tarjetas de presentación digitales, donde un único registro vCard o URL es toda la carga útil y donde el formato físico generalmente importa más que el chip. La mayoría de esos pedidos terminan enTarjetas NFC de PVC blancas en blancoen lugar de pegatinas, porque la tarjeta tiene que sobrevivir a una billetera y tomar una huella.
El techo llega más rápido de lo que la gente espera. NTAG213 le brinda 144 bytes de memoria de usuario y un mensaje NDEF no es solo su URL. Hay un contenedor TLV, un encabezado de registro, un campo de tipo y un campo de longitud antes de que se almacene un solo carácter de su dirección. Un registro URI comprime prefijos comunes comohttps://www.en un solo byte, que recupera de diez a veinte bytes, y en una parte de 144-bytes esa diferencia es la línea entre encajar y fallar. Lo que atrapa a los equipos no es la URL en sí, sino los extras: agregue un registro de texto para una etiqueta legible por humanos, agregue un registro de aplicación de Android para que la etiqueta abra una aplicación en lugar de un navegador, y una carga útil cómoda se convierte en un error de desbordamiento.
Nuestra propia regla general, y este es el tipo de cosas que sólo se aprende codificando unos pocos millones de estas: si la URL deseada, incluidos los parámetros de consulta, supera los 90 caracteres, deje de especificar NTAG213 y avance. La diferencia de costo unitario entre 213 y 215 es lo suficientemente pequeña como para que casi nunca valga la pena correr el riesgo de un rediseño a mitad del -programa. Una campaña que luego quiera agregar parámetros UTM o un número de serie a cada URL de etiqueta llegará al muro en 213 y no en 215.
Vale la pena entender la protección con contraseña en esta familia precisamente porque es más débil de lo que sugiere la palabra "contraseña". Un valor PWD de 32 bits se transmite en claro y el chip lo verifica, lo que controla el acceso de escritura y, opcionalmente, el acceso de lectura, desde una página elegida en adelante. Evita que un miembro curioso del público reescriba su etiqueta con un teléfono. No es un control criptográfico y nunca debe describirse como tal a un cliente. Tenga en cuenta también que no todas las generaciones lo admiten en absoluto: el antiguo NTAG203 no tiene ningún mecanismo de contraseña, y la documentación de la biblioteca es explícita en que las llamadas de protección simplemente fallan (documentación nfcpy).
MIFARE Classic: grabable en Android, efectivamente ausente en iPhone
Aquí está la trampa de la compatibilidad que ha acabado con más proyectos NFC que cualquier otro factor. Cualquiera que pregunte cómo escribir NDEF en MIFARE Classic ya está trabajando en contra del formato: MIFARE Classic no es un tipo de etiqueta NFC Forum, es una tarjeta ISO/IEC 14443-3A con un sector propietario y una estructura clave que es anterior al ecosistema NDEF, y el soporte NDEF existe solo a través de una convención de mapeo superpuesta.

Android maneja esa convención. iOS no. Core NFC de Apple nunca ha sido compatible con MIFARE Classic, y las familias MIFARE compatibles con la plataforma se limitan a Ultralight, Plus y DESFire, una posición que los desarrolladores han confirmado repetidamente en los propios foros de Apple (Foros de desarrolladores de Apple). Debido a que iOS no puede acceder a la memoria de la tarjeta directamente, un iPhone no puede escribirle NDEF y no puede mostrar el NDEF almacenado en ella.
Lo que hace que esto sea tan peligroso durante la evaluación es que las etiquetas MIFARE Classic no aparecen muertas en un iPhone. La tarjeta presenta un UID ISO 14443-A, por lo que la aplicación Atajos lo aceptará gustosamente como activador de automatización, y el escaneo en segundo plano aún puede iniciar un registro NDEF previamente almacenado de un tipo compatible. Un líder de adquisiciones que prueba una muestra en su iPhone ve una respuesta y cierra la sesión. El comportamiento que vieron no tuvo nada que ver con el contenido de la memoria de la etiqueta, y todo el enfoque colapsa en el momento en que el proyecto necesita URL por unidad que los iPhones realmente puedan leer.
La regla práctica que se desprende de esto: cualquiera que compare cómo programar etiquetas NFC para iPhone versus Android debe realizar pruebas de aceptación en ambas plataformas con el chip de producción, nunca solo en Android y nunca en una muestra de un chip diferente al de la orden de compra.
Permítanme ser directo acerca de la recomendación, porque "depende de su caso de uso" no es una respuesta útil aquí. Si miembros del público van a aprovechar sus etiquetas NFC, especifique cualquier cosa excepto MIFARE Classic.
Para los equipos que ya están dentro de un sistema de acceso basado en Classic-, la decisión se reduce a una variable y no son las etiquetas. Es la vida útil restante de su patrimonio lector. Si a esos lectores les quedan dos o tres años y ningún teléfono inteligente tocará la credencial, continuar con Classic en un circuito cerrado es una decisión defendible, y las cuestiones prácticas pasan a ser el origen de IC y el formato UID en lugar del método de codificación, que es lo que cubrimos en nuestras notas sobreordenar etiquetas MIFARE 1K en un sistema instalado. Si los lectores deben ser reemplazados dentro de esa ventana, no gaste dinero en una credencial de transición. Mueva todo el patrimonio a una parte basada en AES-en un solo paso y absorba el costo una vez.
Hay una segunda trampa en la misma familia, lo suficientemente sutil como para sobrevivir a ciclos completos de control de calidad. Agregar un contenedor Smart Poster a un registro, que las herramientas de codificación comunes ofrecen como una forma amigable de adjuntar un título a una URL, cambia el tipo de registro. Los registros empaquetados de esa manera no son detectados en absoluto por el escaneo en segundo plano de iOS, independientemente de lo que esté anidado en su interior. Las pruebas de Android pasan en todos los dispositivos, los iPhone no hacen nada y no hay ningún mensaje de error en ningún lugar para diagnosticar.
Ultralight, DESFire y NTAG 424 DNA: donde la programación se convierte en gestión clave
MIFARE Ultralight EV1 tiene un comportamiento cercano al NTAG21x y usted programa etiquetas NFC de la misma manera, con un presupuesto de memoria más pequeño de 48 o 128 bytes y la misma clase de puerta de contraseña. No sucede nada conceptualmente nuevo.
DESFire y NTAG 424 DNA son una disciplina diferente. En estas partes de Tipo 4, no está escribiendo bytes en un mapa de memoria plana, está operando en un sistema de archivos con derechos de acceso por archivo- y cada operación significativa requiere autenticarse primero con una clave AES-128. NTAG 424 DNA incluye cinco claves AES definidas por el cliente, utiliza autenticación mutua de 3 pasos para el archivo de datos protegido y cuenta con la certificación Common Criteria EAL4 tanto en hardware como en software. Los equipos que programan etiquetas NFC para la autenticación de productos en lugar de una simple redirección suelen buscar esta parte específicamente, debido a una característica.
Esa característica es Mensajería dinámica segura, a menudo escrita como SUN. Cuando está habilitado, la URL NDEF que el chip presenta cambia con cada toque: el chip refleja su UID y un contador de lectura que aumenta monótonamente en la URL, opcionalmente encriptado, y agrega un CMAC calculado con una clave que solo usted y el chip tienen. Luego, su backend puede distinguir una etiqueta real de una URL fotografiada y puede distinguir el toque número 4 del toque número 4000.
Configurarlo correctamente es donde la especificación muerde. Las reglas de duplicación no son de forma-libre: cuando los datos PICC están cifrados, la duplicación del UID y el contador de lectura se vuelve obligatoria en lugar de opcional, los dos siempre viajan juntos y el CMAC debe ubicarse al final del mensaje NDEF. Diseñe su estructura de URL en torno a esas restricciones, no al revés, o las compensaciones no se resolverán y el backend rechazará cada lectura.
El fracaso que vemos con mayor frecuencia en los despliegues de SUN no tiene nada que ver con nada de eso. Cada implementación de referencia pública y servidor de demostración se envía configurado con las claves-todo-cero predeterminadas de fábrica, porque eso es lo que hace que una demostración funcione desde el primer momento. Proyecta el prototipo en contra de eso, el prototipo funciona y el paso de rotación clave nunca llega a la lista de verificación de lanzamiento. Las etiquetas salen criptográficamente desnudas mientras todos los involucrados creen que la implementación está encriptada, razón por la cual nuestro propio procedimiento de publicación de muestra verifica la diversificación de claves en las unidades de producción en lugar de lo que se usó para la demostración.
Seis operaciones que no podrás revertir una vez que programes etiquetas NFC
Las reescrituras de carga útil son baratas. Estos no lo son. Cada una de las siguientes es una decisión que convierte un lote de etiquetas en un activo fijo, y cada una ha sido la causa del inventario desechado que hemos tenido que reemplazar personalmente.
| Operación | que hace | Por qué no se puede deshacer | Cuando se debe programar |
|---|---|---|---|
| Formato NDEF | Escribe el contenedor de capacidades. | Aterriza en una-vez-memoria programable | En la fábrica, después de confirmar el tipo de chip. |
| Brocas de bloqueo estático | Bloquea las primeras 16 páginas en chips Tipo 2 | Los bits de bloqueo solo se configuran-y no se pueden restablecer | Solo después de que se apruebe el contenido final |
| Bits de bloqueo dinámico | Cubre 96 bytes de datos en NTAG213, 456 en NTAG215 y 840 en NTAG216, con una granularidad de 2 páginas en NTAG213 y 16 páginas en NTAG215 y NTAG216, según la hoja de datos de NXP citada anteriormente. | Mismo mecanismo-solo conjunto, misma permanencia | La misma puerta que las cerraduras estáticas. |
| Interruptor-de solo lectura | Establece el indicador de escritura NDEF de forma permanente | No existe ningún comando inverso | Nunca antes de completar la prueba de campo |
| Modo LRP en NTAG 424 DNA | Cambia AES a un funcionamiento-resistente a fugas | Habilitado por SetConfiguration, sin ruta de regreso al modo AES | Solo si un modelo de amenaza documentado lo requiere |
| Cambio de clave sin depósito en garantía | Reemplaza las claves AES de fábrica | El chip no tiene ruta de recuperación si se pierde la nueva clave | Sólo una vez que se asigne formalmente la custodia de las llaves. |
Esa granularidad de la página es el detalle práctico que la mayoría de la gente pasa por alto cuando preguntan cómo bloquear una etiqueta NFC después de la programación. El bloqueo no es un único interruptor de todo-o-nada. En NTAG215 y NTAG216 puede bloquear bloques de 16 páginas, lo que hace viable un diseño mixto: una región de número de serie bloqueada en fábrica, una región de URL de campaña que se deja grabable para el equipo de marketing. En NTAG213 la granularidad es de dos páginas, más fina pero en un mapa mucho más pequeño. Decidir el límite es una tarea de diseño y debe ocurrir antes de ejecutar la codificación, no después.
El hábito que vale la pena desarrollar es separar la puerta de codificación de la puerta de bloqueo. Aconsejamos a los clientes que no bloqueen el sistema en el momento de realizar el pedido, y el motivo es más comercial que técnico.
En nuestro historial de pedidos, la solicitud posterior-a la entrega más frecuente no es un reclamo por defecto, es un cambio de destino y se agrupa dentro del primer año de servicio. Los desencadenantes habituales son una migración de la página de destino o un traspaso de agencia, ninguno de los cuales es visible en el momento en que se realiza el pedido. No necesita las estadísticas de fallas de nadie para actuar en consecuencia, porque la asimetría lo decide por sí sola: una etiqueta desbloqueada que nunca necesita cambiarse no le cuesta nada, mientras que una etiqueta bloqueada que necesita cambiarse cuesta una orden de reemplazo completa más la mano de obra de reinstalación. Programe las etiquetas NFC primero, ejecute la prueba de campo y luego bloquee.
Verificar el chip es lo que dice la factura
La autenticidad del chip no es una preocupación paranoica en esta categoría, es un elemento de inspección entrante-de rutina y pertenece al mismo paso de control de calidad que cualquier otra verificación que ejecute antes de programar etiquetas NFC en cantidades de producción. Cada una de las familias NTAG, MIFARE, Ultralight e ICODE de NXP lleva una firma de originalidad basada en ECC-escrita en la producción del chip, de 32 bytes en piezas NTAG21x, que se puede leer y verificar con la clave pública del fabricante. Una etiqueta que se comporta perfectamente aún puede no pasar esa verificación.
Esto sucede más de lo que admite el mercado. Los ingenieros que compran etiquetas NTAG21x a través de canales minoristas generales han informado a la propia comunidad de fabricantes que las muestras funcionan exactamente como se especifica, incluido el contrarreflejo, pero se reportan como silicio clonado bajo verificación de originalidad, y la respuesta publicada de NXP es que dichas piezas no son compatibles y no son adecuadas para un uso seguro porque el IC en sí puede ser vulnerable (Comunidad NXP).
La consecuencia operativa es más limitada de lo que la gente supone y vale la pena señalarla con precisión. Si su aplicación es una redirección de marketing, un chip clonado le servirá adecuadamente y es posible que no le importe. Si su aplicación implica autenticación, evidencia de manipulación o cualquier reclamo de anti-falsificación realizado a su propio cliente, un chip no verificable invalida toda la premisa y ninguna cantidad de codificación correcta lo compensa. La verificación toma unos segundos por muestra con una aplicación de lectura y pertenece a su procedimiento de control de calidad entrante y no a una autopsia. Lectura relacionada para cualquiera que complete su escritura pero cuyo lector permanezca en silencio:¿Por qué una pegatina clonada se lee bien y sigue fallando en la puerta?.
La pregunta de seguridad clásica de MIFARE, reformulada con honestidad
Cualquiera que especifique MIFARE Classic hoy debería trabajar desde la posición de investigación actual en lugar de la reputación que tenía la plataforma hace una década.
En 2024, un estudio del FM11RF08S, un chip compatible con MIFARE Classic lanzado en 2020 con contramedidas diseñadas específicamente para resistir todos los ataques conocidos-solo a tarjetas, derrotó esas contramedidas y descubrió una puerta trasera de hardware en el proceso. La puerta trasera permite que cualquier parte que tenga conocimiento de ella comprometa todas las claves definidas por el usuario-en la tarjeta a los pocos minutos de acceder físicamente, y esto se mantiene incluso cuando las claves se han diversificado completamente por tarjeta (Archivo ePrint de criptología). Se identificaron claves de puerta trasera relacionadas en un conjunto más amplio de piezas, incluidas generaciones anteriores de Fudan y dispositivos NXP e Infineon específicos.
Léelo detenidamente antes de sacar una conclusión equivocada. Este no es un argumento de que todos los que usan MIFARE Classic estarán expuestos mañana, y no lo presentamos como tal. Millones de credenciales clásicas operan en entornos de baja-consecuencias donde, al clonar una tarjeta, un atacante obtiene acceso a un casillero de gimnasio. Es un argumento que la frase "seguro" no debería aparecer en ningún documento de especificaciones junto con esta familia de chips, y que cualquiera que esté a punto de programar etiquetas NFC para habitaciones de hotel, acceso a oficinas o pagos sin efectivo en silicio clásico debería fijar el precio de una migración a una parte basada en AES-en el mismo ciclo presupuestario.
Programación de etiquetas NFC a granel: lo que cambia por encima de mil unidades
Todo lo descrito hasta ahora escala mal. Una aplicación de teléfono escribe una etiqueta a la vez sin registro de lote, sin pase de verificación y sin forma de demostrar posteriormente qué URL fue a qué unidad física. Hay tres niveles sobre cómo programar etiquetas NFC de forma masiva, y el salto entre ellos es más operativo que técnico.
El primer nivel es un teléfono y una aplicación, viable para aproximadamente cien unidades, apropiada para prototipos y pilotos internos.
El segundo nivel es donde-la mayoría de los equipos internos aterrizan: usted programa etiquetas NFC con un lector-escritor en una computadora de escritorio, controlado por un archivo por lotes, generalmente a través de un codificador USB en la clase ACR12xx o uTrust. Funciona bien hasta que cambia el chip. La herramienta por lotes de código abierto- ampliamente utilizada en este espacio, por ejemplo, apunta específicamente al ACR122 y solo codifica MIFARE Ultralight y Ultralight C, que son partes de Tipo 2, por lo que mover ese proyecto a un chip de Tipo 4 significa reconstruir las herramientas en lugar de editar un archivo de configuración. Si aún elige hardware para este nivel, nuestroGama de lectores-escritores NFC USB y de escritoriocubre los modelos de lector que esperan estas cadenas de herramientas.
La práctica industrial para el tercer nivel es la pre-codificación durante la fabricación, y este es el nivel que la mayoría de los compradores no saben que existe. En nuestras líneas, en una planta de 3600 m², la codificación se realiza entre la unión del chip y el ensamblaje final, en equipos que indexan cada etiqueta en su posición, escriben el registro y lo leen antes de que la etiqueta avance. El pase de verificación es el punto. Una etiqueta que no se puede leer-se rechaza en-línea en lugar de ser descubierta por un cliente en el campo, y el lote sale con un archivo de mapeo que vincula cada UID o TID con el contenido exacto escrito en él, que es lo que su CMS o plataforma de análisis necesita desde el primer día. La capacidad de unión automatizada en cinco líneas de producción supera los 100.000 chips por día, por lo que la codificación no se convierte en una limitación en el tiempo de entrega.
Lo que esa descripción omite, deliberadamente, es el umbral de aceptación. La verificación de lectura-es una puerta de aprobación/rechazo, pero la tasa de falla que usted debe aceptar contractualmente difiere según la familia de chips, el factor de forma y si la etiqueta se laminará posteriormente; una pegatina anti-metal y una tarjeta de PVC no se comportan de la misma manera en la misma línea. Ese número pertenece a una cita de su compilación específica, no a un artículo, y es lo primero que configuramos cuando se inicia un nuevo programa.
Vale la pena indicar claramente dónde trazamos nuestros propios límites de capacidad, porque es la parte que los proveedores suelen desdibujar. Pre-programaremos etiquetas NFC con su plantilla de URL, las serializaremos por unidad, verificaremos cada etiqueta y entregaremos el archivo de mapeo. Proporcionaremos las claves AES que usted proporcione. No conservaremos sus claves de producción, no operaremos su backend de validación y no le diremos que una fábrica puede hacer que el diseño de seguridad de una capa de aplicación-es correcto. Esa parte es tuya, y cualquier proveedor que afirme lo contrario te está vendiendo una transferencia de riesgo que no existe.
Nueve preguntas que resolver antes de la ejecución de la codificación
Ejecute esto antes de la orden de compra, no después de que lleguen las muestras. Cada elemento ha puesto fin a al menos un proyecto que nos pidieron rescatar.
| # | Pregunta | ¿Por qué decide el chip? |
|---|---|---|
| 1 | ¿Los iPhone aprovecharán estas etiquetas? | Elimina completamente MIFARE Classic de la consideración |
| 2 | ¿Cuál es la longitud total de la URL, incluidos los parámetros futuros? | Establece el piso en NTAG213, 215 o 216 |
| 3 | ¿Es suficiente un registro o también necesita un registro de texto o un registro de aplicación? | Los registros adicionales consumen el mismo presupuesto de memoria |
| 4 | ¿Cambiará el destino durante la vida útil de la etiqueta? | Determina si el bloqueo es alguna vez aceptable |
| 5 | ¿La aplicación hace un reclamo de autenticidad a los usuarios finales? | Te lleva a NTAG 424 DNA o DESFire |
| 6 | ¿Quién sostiene y rota las claves AES? | Debe asignarse antes de cambiar cualquier clave. |
| 7 | ¿Cuál es el criterio de aceptación para un lote entregado? | Define si la verificación-de retrolectura es contractual. |
| 8 | ¿Necesita un archivo de asignación de UID-a-contenido? | Debe especificarse antes de la ejecución, no solicitarse después |
| 9 | ¿La verificación de la firma de originalidad es parte del control de calidad entrante? | Determina si el abastecimiento de chips es auditable |
Los equipos que pueden responder a las nueve normalmente obtienen una producción limpia en el primer intento. Los equipos que pueden responder seis de nueve normalmente descubren las tres restantes de forma costosa.
Las nueve preguntas son la versión genérica. La que realmente trabajamos agrega una décima columna, la respuesta adecuada para su construcción y no en general, y esa columna depende de cosas que este artículo no puede ver: su combinación de teléfonos, su estado de lectura, su proceso de laminación y si la serialización tiene que ser secuencial o aleatoria. Envíenos las primeras nueve respuestas y le devolveremos la versión comentada según sus especificaciones.
Dónde deja esto al comprador
No existe un procedimiento general sobre cómo programar etiquetas NFC, solo un procedimiento por chip, por plataforma, por volumen. Primero, elija el chip contra el techo de memoria y la pregunta del iPhone. Trate el formato, la carga útil y la configuración como tres puertas separadas. Nunca cierre antes de una prueba de campo. Verificar la originalidad de las muestras entrantes. Por encima de mil unidades, deja de pensar en aplicaciones y empieza a pensar en verificación y trazabilidad.
Si ya se ha redactado una especificación, estaremos encantados de revisarla según las limitaciones del chip mencionadas anteriormente y marcar todo lo que no sobrevivirá a la producción, y hay muestras gratuitas disponibles para probar en sus lectores y teléfonos reales. También puedes empezar desde elFormatos de etiquetas NFC que pre-programamos y verificamos internamente-si la decisión sobre el chip aún está abierta, oenviar la estructura de la URL y el volumen objetivo para una revisión de codificaciónsi ya está arreglado.
Preguntas frecuentes
¿Puedo programar cualquier etiqueta NFC con mi iPhone?
No. iOS Core NFC no es compatible con MIFARE Classic, mientras que NTAG21x, MIFARE Ultralight, DESFire y NTAG 424 DNA sí lo son. Si su implementación tiene que funcionar en iPhones, descarte MIFARE Classic antes de realizar el pedido.
¿Cuántos datos puede contener una etiqueta NFC?
La memoria de usuario es de 144 bytes en NTAG213, 504 bytes en NTAG215 y 888 bytes en NTAG216, y 416 bytes en NTAG 424 DNA en tres archivos separados.
¿Se puede deshacer la programación de etiquetas NFC?
El contenido de la carga útil normalmente se puede reescribir, pero el formato, los bits de bloqueo, el interruptor-de solo lectura y el modo LRP son permanentes una vez aplicados. Programe cada paso de bloqueo después de la prueba de campo, nunca en el momento del pedido.
¿Cómo sé si mis etiquetas NFC utilizan chips originales?
Lea la firma de originalidad basada en ECC-y compárela con la clave pública del fabricante, porque una verificación fallida indica silicio clonado independientemente de qué tan bien funcione la etiqueta.
¿Cómo se programan las etiquetas NFC de forma masiva?
Ya sea con un codificador USB controlado por un archivo por lotes o pre-programado durante la fabricación con-lectura-en línea en línea. Por encima de mil unidades, haga que el archivo de asignación de UID-a-contenido forme parte de la especificación en lugar de una solicitud posterior.
Envíeconsulta

