¿Cómo proteger las etiquetas RAIN RFID para aplicaciones retail?

El riesgo de que esto ocurra es, por supuesto, relativamente bajo, pero el impacto sería desastroso. La recepción de artículos en el centro de distribución fallaría por niveles elevados de «artículos faltantes», los recuentos de stock en tienda serían inexactos y el proceso de checkout se ralentizaría al tener que volver a los códigos de barras. Por tanto, prevenirlo es de máxima importancia, y los estándares RFID (GS1 EPC Gen2v2) ofrecen mecanismos para hacerlo. Existen varios mecanismos para evitar cambios en etiquetas RFID programadas.

Sin embargo, hacer imposible cualquier cambio en las etiquetas RFID entra en conflicto directo con la necesidad de funciones de privacidad para el consumidor: la posibilidad de desactivar una etiqueta o, de forma más sutil, reducir la distancia de lectura u ocultar el número único en la etiqueta son funciones críticas. Por ello, debe encontrarse un buen equilibrio entre seguridad y privacidad.

Este blog aborda las capacidades de seguridad y privacidad de RAIN RFID y las mejores prácticas para utilizarlas.

Mecanismos de seguridad: bloqueo y contraseñas

Existen dos mecanismos estrechamente relacionados para proteger las etiquetas:

1. Contraseñas: se necesita una contraseña para ejecutar determinadas acciones
2. Bloqueo: define qué es posible con y sin contraseña

Las etiquetas RAIN RFID tienen dos contraseñas:

1. Contraseña de acceso: se utiliza para permitir o impedir la lectura y escritura de memorias específicas del chip
2. Contraseña kill: se utiliza para permitir o impedir la desactivación del chip

No todos los chips tienen contraseñas, ya que esto no es obligatorio según el estándar. Por ejemplo, el Impinj Monza R6 no tiene contraseña de acceso ni contraseña kill, lo que significa que el chip no puede desactivarse ni protegerse con contraseña para escritura. El Monza R6-P y el R6-A sí tienen contraseñas kill y de acceso. El comando lock es obligatorio en el estándar.

Con el comando «lock» puedes definir el comportamiento del chip en relación con las contraseñas. Escribir contraseñas por sí solo no hace nada: deben activarse mediante el bloqueo de las etiquetas.

Al utilizar el comando lock existen cuatro configuraciones posibles:

1. Puedes escribir en la memoria incluso sin contraseña de acceso
2. Puedes escribir en la memoria cuando proporcionas la contraseña de acceso
3. Ya no puedes escribir en la memoria, incluso aunque tengas la contraseña de acceso
4. Siempre puedes escribir en la memoria, y ya no puedes cambiarlo ni protegerlo con contraseña

La configuración puede definirse para cada área de memoria: memoria EPC, donde se almacena la información del producto y el número de serie, contraseña kill, contraseña de acceso, etc. Por supuesto, cuando la contraseña está protegida contra escritura, también está protegida contra lectura; de lo contrario, cualquiera podría obtenerla fácilmente. La memoria EPC no puede protegerse contra lectura mediante contraseñas y bloqueo.

Cuando la contraseña está compuesta solo por ceros, no es posible desactivar la etiqueta. Por tanto, primero debes escribir una contraseña kill que no esté compuesta solo por ceros antes de poder utilizarla para desactivar una etiqueta.

La escritura de la configuración de bloqueo y de las contraseñas suele realizarse durante la codificación de las etiquetas.

Mecanismos de privacidad: reducción del rango de lectura y ocultación de parte del EPC

La función de privacidad más básica de las etiquetas RFID es el comando kill. Al ejecutar este comando, la etiqueta no volverá a funcionar. Esto es perfecto para la privacidad del consumidor, pero dificulta procesos como la gestión automatizada de devoluciones y exigiría aplicar una nueva etiqueta una vez que el producto haya sido devuelto.

Para superar esto, se han introducido dos mecanismos de privacidad más sofisticados:

1. Reducción del rango de lectura: cambiar dinámicamente el rango de lectura a solo unos pocos centímetros, en lugar de unos pocos metros
2. Ocultar la parte sensible del EPC: hacer ilegible el identificador de producto y/o el número de serie

Ambos mecanismos están protegidos con la contraseña de acceso.

Estas funciones de privacidad actualmente solo están disponibles en los chips NXP UCODE 8/8m, aunque se espera que otros fabricantes de chips las incorporen pronto.

Así que, aunque desde el punto de vista de la seguridad bastaría con impedir cualquier modificación del chip bloqueando permanentemente todas las memorias y contraseñas, esto también desactivaría de forma permanente todas las funciones de privacidad, una situación claramente no deseada. Por tanto, el uso de contraseñas es el camino adecuado.

Gestión de contraseñas

El reto, por supuesto, es cómo gestionar las contraseñas. El enfoque más sencillo sería utilizar una sola contraseña, igual para todas las etiquetas de una organización. Sin embargo, si esa contraseña se filtra, todas las etiquetas quedan vulnerables.

Incluso si la contraseña no se filtrara, aún sería posible obtenerla mediante fuerza bruta, es decir, probando todas las contraseñas. Si asumimos que un solo lector necesita aproximadamente 5 milisegundos para probar una contraseña, y sabemos que 2 elevado a 32 equivale a 4.294.967.296 posibilidades, se puede calcular que se necesitarían como máximo 248 días para «adivinar» la contraseña. De media serían 124 días. Y, como las etiquetas son baratas y fáciles de conseguir, se pueden ejecutar varios lectores en paralelo para intentar obtener sus contraseñas. Con algo de esfuerzo, una contraseña puede recuperarse en cuestión de días.

Para hacerlo significativamente más seguro, se necesita una solución en la que la contraseña sea diferente en todas y cada una de las etiquetas, de modo que si una contraseña se ve comprometida no tenga impacto en las demás. Sin embargo, tener una contraseña por etiqueta y almacenarla en una base de datos no sería muy escalable: requeriría una comunicación cliente-servidor cada vez que se quiera desactivar una etiqueta o habilitar una función de privacidad.

Por suerte, este problema se ha resuelto muchas veces en situaciones similares. Con una función hash criptográfica unidireccional es posible calcular una contraseña basándose en el valor del EPC y un secreto, es decir, otra contraseña única por marca. Una función hash unidireccional funciona así:

1. Si tienes el EPC y el secreto, puedes calcular la contraseña.
2. Si tienes la contraseña y el EPC, no puedes calcular el secreto.

Esto significa que, aunque recuperes una o varias contraseñas mediante fuerza bruta, no puedes obtener las contraseñas de otras etiquetas. También significa que solo necesitas un secreto por marca, que puede distribuirse de forma segura. No hace falta una base de datos de contraseñas. Es un mecanismo muy escalable, seguro y fiable.

Escalar la solución para retailers multimarca

Aunque esta solución funciona bien para un retailer monomarca, resulta más compleja para retailers multimarca que venden productos de distintos orígenes. No podrán imponer su propia estrategia de gestión de contraseñas a las marcas, porque sería imposible implementarla en la supply chain.

Proponemos que cada marca implemente la gestión de contraseñas como se ha descrito anteriormente y distribuya las claves de seguridad a los retailers que venden sus productos. Cada serie de GS1 Company Prefixes tendría su propio secreto. Cuando un retailer quiere habilitar una función de privacidad en un EPC, obtiene el Company Prefix de ese EPC y lo utiliza para obtener el secreto correcto, que puede emplearse para generar la contraseña necesaria.

Esta solución combina las ventajas de tener contraseñas únicas por etiqueta, al tiempo que facilita su implementación para marcas y retailers.

El riesgo evidente de esta solución está en la gestión de las claves de las marcas: si un retailer filtra accidentalmente la clave de una o varias marcas, seguirían produciéndose problemas. Existen mejores prácticas del sector para la distribución de claves que deberían seguirse.

Y si una marca no quiere compartir el secreto con los retailers, aún podría ofrecer un servicio API en el que el retailer presente un EPC y reciba una contraseña a cambio. Esto obviamente requiere conectividad, pero es la forma de trabajo más segura.

Conclusión: hace falta estandarización

En conjunto, con una configuración adecuada de los parámetros de bloqueo en el chip y estableciendo contraseñas, es posible proteger los chips RFID frente a modificaciones no autorizadas de forma escalable y, al mismo tiempo, permitir la privacidad del consumidor. Por supuesto, todo esto está integrado por defecto en la solución Nedap iD Cloud.

Dado que esta solución solo funcionará si todos utilizan estos métodos, recomendamos firmemente que el sector estandarice este enfoque para que todos los retailers y consumidores puedan beneficiarse de una implementación de RAIN RFID segura y respetuosa con la privacidad.