Un ataque de inyección en biometría facial sustituye el flujo de la cámara por un stream sintético antes de que el SDK (kit de desarrollo de software del proveedor) reciba cualquier frame. El liveness (detección de vivacidad biométrica) analiza el contenido de los frames, no su origen. Por eso un rostro fabricado con calidad suficiente puede pasar: el módulo evalúa lo que llega, no cómo llegó.
Esta guía describe los tres vectores técnicos de un ataque de inyección, explica por qué el liveness no los cubre y detalla qué deben verificar los controles específicos de anti-inyección para cerrar este perímetro. Los datos de certificación y producción provienen de entornos reales, con el laboratorio y la referencia identificados.
¿Qué distingue un ataque de inyección de un ataque de presentación?
Un ataque de presentación coloca un artefacto físico frente a la cámara, como una foto impresa o una máscara de silicona. El liveness detecta este tipo de fraude mediante el análisis de los frames en busca de señales de artefactos, como textura incompatible, ausencia de profundidad, reflejos anómalos, bordes artificiales y patrones de movimiento inconsistentes, entre otros indicadores que el análisis puede identificar.
Un ataque de inyección ignora la cámara. El stream sintético entra en el canal de datos antes del SDK. El liveness nunca ve la cámara real: solo los frames fabricados, que pueden haberse generado con el rostro legítimo del titular de la cuenta, con resolución e iluminación controladas.
La norma que certifica la resistencia a ataques de presentación es ISO/IEC 30107-3 (PAD, Presentation Attack Detection). La norma que certifica la resistencia a ataques de inyección es CEN/TS 18099:2024. Un proveedor puede obtener la certificación de una norma y no de la otra, ya que cada una corresponde a un proceso de evaluación. El perímetro de inyección permanece abierto.
¿Cuáles son los tres vectores de un ataque de inyección?
Los vectores llegan por distintas capas de la pila técnica. Cada uno explota un punto diferente antes del SDK.
Cámara virtual
El atacante instala un controlador de cámara virtual en el dispositivo. El sistema operativo registra ese controlador como un sensor físico legítimo, con el mismo identificador de hardware que una cámara real. Se llama al SDK, que recibe el feed sintético y lo procesa con normalidad.
Las herramientas de transmisión en vivo y grabación usadas en estudios virtuales están disponibles gratuitamente y se utilizan en este vector. El contenido inyectado puede ser un video pregrabado con deepfake o un stream en tiempo real generado por un modelo de IA alimentado con fotos públicas del objetivo.
El vector es detectable porque los controladores de software tienen un patrón de comunicación con el sistema operativo diferente al de los sensores de hardware. Los módulos de anti-inyección verifican esa firma antes de procesar el frame.
Hook en el canal de captura
No se instala ninguna cámara virtual. Un código intercepta la llamada de la cámara en el nivel del sistema operativo antes de que llegue al SDK. El stream se sustituye durante la transmisión. Desde el punto de vista de la aplicación, la cámara funciona con normalidad.
Este vector es más sofisticado: no instala ningún controlador visible, no aparece en la lista de dispositivos y no deja un rastro identificable mediante un análisis estático. La detección exige verificar la integridad del canal durante la ejecución.
Emulación de dispositivo
No hay hardware físico. Un emulador simula el dispositivo completo y alimenta la cámara con contenido sintético. El backend recibe solicitudes de un dispositivo que no existe como objeto físico. La emulación puede incluir el rostro del objetivo generado con herramientas de deepfake en tiempo real.
El vector se identifica mediante la huella digital del entorno: los emuladores tienen patrones de consumo de batería y comportamiento de sensores inerciales diferentes de los dispositivos reales. La detección no exige analizar la cámara.
¿Por qué el liveness no detecta ataques de inyección?
El liveness evalúa si los frames están vivos: si el rostro presentado tiene una textura y profundidad compatibles con una persona real, entre otros indicadores que el análisis puede identificar. Los frames llegan al SDK ya construidos. El liveness analiza lo que recibe.
En un ataque de inyección, el frame se fabricó antes de entrar en el canal. Con herramientas modernas de generación de video, es posible producir un deepfake en tiempo real con micromovimientos faciales e iluminación adaptativa. El liveness ve un rostro vivo porque recibió un rostro construido para parecer vivo.
El liveness cubre el artefacto físico. El anti-inyección cubre el origen de la señal. Son capas de control sobre vectores distintos. Contratar solo liveness y declarar que el sistema está protegido contra la inyección es un vacío de perímetro, no una decisión de arquitectura.
¿Cómo verifican el canal los controles de anti-inyección?
El anti-inyección actúa antes de que el SDK procese el frame. La verificación ocurre en el canal.
El SDK verifica si el dispositivo que responde es un sensor físico real. Los controladores de cámaras virtuales tienen un patrón de comunicación con el sistema operativo diferente al de los sensores de hardware. La diferencia es estructural y detectable.
La verificación del canal ocurre durante la ejecución. Las técnicas de RASP (Runtime Application Self-Protection) identifican adulteraciones durante la sesión activa. La ofuscación del SDK impide analizar el código para mapear vectores de ataque mediante ingeniería inversa.
Los emuladores tienen una huella digital diferente de la del hardware físico. El ciclo de batería y el comportamiento de los sensores inerciales distinguen ambos entornos sin exigir un análisis de cámara.
Ninguna de estas verificaciones aparece en la interfaz del usuario legítimo. El control opera completamente en la capa de infraestructura.
¿Qué prueba la certificación CEN/TS 18099:2024?
CEN/TS 18099:2024 es el primer estándar técnico específico para controles de anti-inyección en biometría. Publicado por el Comité Europeo de Normalización, define la metodología de prueba para ataques realizados con IAI (Injection Attack Instrument, el instrumento de ataque por inyección): cualquier contenido sintético inyectado en el canal de captura antes del SDK.
El estándar tiene tres niveles; High es el más alto. Para alcanzarlo, el sistema debe resistir al menos 15 especies distintas de IAI, con un BPCER (Bona fide Presentation Classification Error Rate, o tasa de rechazo de usuarios legítimos por parte del módulo de anti-inyección) máximo del 15%.
La certificación no es autodeclaratoria. El laboratorio reconocido define los ataques, ejecuta el protocolo y firma el informe. El proveedor no controla qué especies de IAI se prueban dentro del conjunto exigido por el estándar.
El laboratorio Antisec realizó la certificación del módulo de anti-inyección de Fortface entre el 30 de julio y el 18 de agosto de 2026. Resultado: 18 ataques ejecutados, 15 especies distintas de IAI, 0 bypasses. BPCER: 2%, dentro del límite aceptable del estándar, del 15%.
Para los responsables de contratos: un BPCER del 2% significa que 98 de cada 100 usuarios legítimos pasan el control sin fricción adicional. El límite del 15% aceptado por el estándar muestra cuánto se encuentra el resultado por debajo del umbral mínimo exigido.
¿Cuál es el riesgo operativo de los ataques de inyección en producción?
La sofisticación de los ataques aumentó con la popularización de las herramientas de generación de video. Un ataque que en 2022 exigía infraestructura especializada hoy funciona en una laptop con una GPU de consumo, con deepfakes generados en tiempo real a partir de fotos públicas del objetivo.
Estos intentos utilizan el rostro real del titular de la cuenta. El ataque es silencioso: la cámara parece funcionar y el liveness pasa. No hay ninguna anomalía en el log de la sesión ni una alerta visible.
“Un ataque de inyección no dispara una alarma. Convence al sistema de que funciona con normalidad. Por eso el control debe estar certificado por un laboratorio reconocido: una declaración del proveedor no cubre este vector.” Ricardo Fritsche, CTO, Payface
Para profundizar
Para entender cómo la elección de un segundo proveedor de biometría afecta el perímetro de control y la cobertura de vectores, el post Qué preguntar antes de sumar un segundo proveedor de biometría cubre los criterios de evaluación de la tasa de aprobación por segmento y las estructuras de división del tráfico.
