¿Cómo se autentica el código ante una etiqueta con contraseña?
Enviando el comando de autenticación del chip con la contraseña, comprobando la respuesta del chip, y solo entonces leyendo o escribiendo las páginas protegidas, todo en la misma conexión. La autenticación dura como mucho lo que la etiqueta siga alimentada, así que cada conexión nueva empieza sin ella. El comando pertenece al chip, no al tipo de etiqueta.
La secuencia
Una etiqueta protegida con contraseña rechaza las operaciones protegidas hasta que recibe la contraseña correcta, en los chips que ofrecen una; el ajuste y su alcance los cubre la página de la contraseña. El lado del código es una secuencia corta en una sola conexión.
Se conecta, con NfcA en Android o mediante una sesión de etiqueta en iOS, y envía el comando de autenticación del chip con la contraseña, mediante transceive() o sendMiFareCommand. Comprueba la respuesta: en la familia NTAG21x, la contraseña de 32 bits viene con un acuse de 16 bits, PACK, según la ficha del NTAG213 en wakdev.com, y el código compara el acuse que recibe con el que configuró. Solo entonces lee o escribe las páginas protegidas, antes de cerrar.
El comando no forma parte de ningún tipo de etiqueta. Su código y su formato pertenecen al chip, y NTAG21x, MIFARE Ultralight C, ICODE SLIX y NTAG 424 DNA tienen cada uno el suyo; las fichas de chips de wakdev.com enlazan a las hojas de datos que los definen. En los chips ISO/IEC 15693 que tienen contraseñas, los comandos que las manejan están en el rango de los comandos propios, como explica la página de la ISO/IEC 15693.
Lo que termina la autenticación
Una etiqueta pasiva saca su energía del campo del lector, como explica la página de la alimentación, y una autenticación es un estado que guarda el chip. Termina como muy tarde cuando la etiqueta sale del campo; la hoja de datos del chip dice qué otros sucesos la terminan.
Así que un reintento empieza desde el principio. Después de TagLostException en Android o readerTransceiveErrorTagConnectionLost en iOS, la etiqueta que vuelve está sin autenticar, y un código que reanuda con la escritura protegida recibe un rechazo. Lo mismo vale para una sesión de etiqueta nueva en iOS, y para el objeto Tag nuevo que Android crea cada vez que la etiqueta vuelve a alcance.
Mantén la autenticación y las operaciones que desbloquea en una sola conexión y una sola clase de tecnología. Abrir otra clase puede hacer que Android vuelva a seleccionar la etiqueta: en el código abierto, el código de la conexión puede hacerlo en etiquetas ISO-DEP y MIFARE Classic, cuando la clase nueva necesita otra interfaz del controlador, y no hace nada en una etiqueta de tipo 2. Si una reselección termina la autenticación lo fija la hoja de datos del chip, y la pila de un fabricante de teléfonos puede decidir otra cosa, así que quedarse en una sola clase es la elección que se sostiene en todos los teléfonos.
Dónde vive la contraseña
El código envía la contraseña, así que tiene que guardarla. Una sola contraseña compilada en una aplicación está en todas las copias de la aplicación, y quien la extraiga puede reescribir todas las etiquetas que protege. Una contraseña por etiqueta traslada el problema a una tabla que la aplicación descarga, el registro que la página de la contraseña llama una base de datos que no se puede perder.
Una contraseña es además corta. La de la familia NTAG21x es de 32 bits, y algunas familias de chips limitan los intentos fallidos, un ajuste que la página de la contraseña recomienda activar donde exista.
Nada de esto autentica la etiqueta ante la aplicación. Una copia del contenido no lleva contraseña, como explica la página de la contraseña frente a la autenticación, así que una aplicación que necesita saber si una etiqueta es auténtica necesita un chip que responda a un desafío criptográfico.
Lo que no hacen las API de la plataforma
La API NDEF de ninguna de las dos plataformas acepta una contraseña. Ndef.writeNdefMessage() en Android y writeNDEF en iOS escriben en una etiqueta que acepta la escritura, y en una etiqueta protegida fallan como cualquier escritura rechazada, el fallo que la página del error de protección describe desde el lado de quien la usa.
El camino fiable es autenticarse con un comando en bruto y escribir las páginas protegidas también con comandos en bruto, lo que quiere decir construir los bytes NDEF y escribirlos en un orden seguro, como describe la página de las escrituras interrumpidas. Web NFC no ofrece ninguno de los dos pasos.
Preguntas frecuentes
¿Ndef.writeNdefMessage puede escribir en una etiqueta con contraseña?
Por sí solo no. Las API NDEF no aceptan contraseña, así que autentícate con un comando en bruto y escribe en la misma conexión, con comandos en bruto para ir seguro.
¿Por qué mi escritura falla tras un reintento?
La etiqueta salió del campo y volvió sin autenticar. Envía otra vez el comando de autenticación antes de las operaciones protegidas.
¿La contraseña protege el contenido de la lectura?
Solo en los chips y ajustes que protegen la lectura. La mayoría de las configuraciones protegen solo la escritura, como explica la página de la contraseña.
¿Puede una aplicación guardar la contraseña en secreto?
No frente a quien la extraiga de la aplicación. Cualquier aplicación que se autentica guarda la contraseña que envía, así que trátala como un cierre contra la reescritura casual.