Plantillas biométricas irreversibles: qué guarda realmente el sensor

Del vector de rasgos al hash protegido que nunca sale del dispositivo

Publicado el 12 de marzo de 2025 Adrian Vargas Hernandez

Cuando alguien apoya el dedo en un lector de acceso, el sensor no almacena la huella. Tampoco guarda una fotografía del rostro si el terminal trabaja con reconocimiento facial. Lo que queda en la memoria del dispositivo es una plantilla: un vector de números derivado de la captura, con la propiedad de que no permite volver atrás para reconstruir el rasgo original. Esa promesa de irreversibilidad es la que sostiene buena parte del cumplimiento normativo en torno a datos biométricos, y también la que más se malinterpreta en implementaciones reales.

De la captura al vector de rasgos

El primer paso ocurre dentro del propio sensor o en el SoC que lo acompaña. En un módulo óptico de huella, la imagen se normaliza, se segmenta la cresta y se detectan minucias: bifurcaciones, terminaciones y puntos singulares. En reconocimiento facial, una red convolucional ligera extrae un embedding de entre 128 y 512 dimensiones. En ambos casos el resultado es un vector de punto flotante que todavía es reversible en la práctica: existen ataques conocidos que reconstruyen una imagen aproximada a partir de un embedding sin protección.

Guardar ese vector tal cual, sin transformación adicional, es el error más común en terminales de bajo coste. El espacio de almacenamiento es pequeño, la latencia de verificación es buena, pero cualquier volcado de la memoria flash expone el rasgo biométrico de todas las personas registradas.

Proyección sobre una función unidireccional

La protección empieza cuando el vector se proyecta sobre una función que no admite inversa práctica. En un MCU con recursos limitados, esto suele resolverse con una combinación de funciones hash criptográficas y una clave secreta almacenada en un elemento seguro. El esquema típico funciona así: el embedding se cuantiza a enteros de 8 o 16 bits, se aplica una transformación dependiente de la clave y el resultado se reduce a un resumen de longitud fija. La verificación posterior compara resúmenes, no vectores.

El coste de cómputo importa. Un SHA-256 sobre 256 bytes consume pocos milisegundos en un Cortex-M4 a 80 MHz, pero si se repite para cada intento de autenticación conviene medir el impacto en el presupuesto energético del terminal. En la práctica, muchos diseños reservan entre 5 y 15 ms por verificación solo para la capa de protección, lo cual es aceptable cuando el ciclo completo de acceso ronda los 400 ms.

Plantillas cancelables y revocación

Una plantilla cancelable añade una propiedad útil: si el resumen se filtra, se puede revocar y regenerar con una clave distinta sin necesidad de volver a capturar el rasgo. Esto es importante en despliegues con cientos de terminales, donde una clave comprometida en un solo equipo no debería obligar a reinscribir a toda la plantilla de usuarios.

El precio es la tolerancia a colisiones. Al reducir el vector a un resumen corto, dos personas distintas pueden producir plantillas que coincidan en la comparación. Los parámetros habituales buscan una tasa de falsa aceptación por debajo de 1 en 10.000, ajustando la longitud del resumen y el umbral de coincidencia. Bajar ese umbral mejora la seguridad pero dispara los rechazos legítimos, sobre todo con dedos secos o rostros con iluminación lateral.

Límites prácticos en un MCU

No todo esquema académico cabe en un microcontrolador. Las funciones que requieren aritmética de punto flotante extensiva o tablas de gran tamaño se descartan rápido. Los diseños que funcionan en producción suelen apoyarse en operaciones enteras, tablas pequeñas y una clave almacenada en un chip dedicado. La verificación de cumplimiento con exigencias de irreversibilidad pasa por documentar qué transformación se aplica, qué longitud tiene el resumen y cómo se gestiona la revocación cuando un terminal se retira del servicio.

Vale la pena revisar también qué ocurre durante el enrolamiento. Si la captura original se guarda temporalmente en un buffer sin cifrar antes de generar la plantilla, el riesgo vuelve a aparecer por la puerta de atrás. La irreversibilidad solo es real cuando todo el flujo, desde el sensor hasta el almacenamiento, respeta la misma política.

Bitácora de ingeniería: qué estamos probando en el banco de trabajo

Tres frentes abiertos ahora mismo: comprimir modelos hasta que quepan en un NPU modesto, proteger la plantilla biométrica para que no se pueda revertir, y sostener la verificación cuando el enlace con el servidor central se cae durante horas. Cada entrada recoge mediciones reales de terminales en operación, no simulaciones de laboratorio.

  • Ingeniería de modelos Entrada publicada

    Arquitectura de micromodelos para reconocimiento facial en terminales

    El artículo parte de un caso concreto: un terminal de control de acceso con 512 MB de RAM y un NPU de 1 TOPS. Se detalla qué capas se pueden podar sin degradar la tasa de verificación, cómo se aplica cuantización int8 y qué pérdida real de exactitud se observa en pruebas con iluminación variable. También se comparan dos estrategias de destilado y se explica por qué una micromodelo de 1.8 MB puede superar a uno de 6 MB cuando el rostro se captura en movimiento. Se incluyen métricas de latencia por fotograma y consumo energético medido en el propio dispositivo.

    Leer la entrada completa
  • Privacidad y almacenamiento Entrada publicada

    Plantillas biométricas irreversibles: qué guarda realmente el sensor

    Se describe el flujo completo desde la captura hasta el almacenamiento: extracción de características, proyección sobre una función unidireccional y generación de una plantilla cancelable. El texto explica por qué guardar el embedding sin protección es un riesgo legal y técnico, y qué esquemas de protección cumplen con las exigencias de irreversibilidad. Se comentan límites prácticos: colisiones aceptables, revocación de plantillas y coste de cómputo en un MCU. El enfoque es aplicado, con ejemplos de parámetros y no con teoría abstracta.

    Leer la entrada completa
  • Operación y resiliencia Entrada publicada

    Inferencia sin nube: qué ocurre cuando se cae la conexión

    El artículo examina un escenario real: una planta con 40 terminales que pierden conectividad cada vez que se reinicia el enlace satelital. Se propone un pipeline con caché de plantillas cifrada, política de decisión local y sincronización diferida por lotes. Se detallan los compromisos entre tamaño de caché, frescura de datos y riesgo de aceptar una plantilla revocada. También se cubre la reconciliación al recuperar la conexión y cómo evitar duplicados o conflictos de estado. El foco está en la operación, no en la teoría de redes.

    Leer la entrada completa
Configuracion de cookies

Usamos cookies para mantener el sitio estable, recordar opciones basicas y entender que paginas resultan utiles. Puedes aceptar, rechazar o revisar la configuracion antes de continuar.