Deepfakes y prueba de vida: por qué una selfie ya no alcanza

Durante años, el estándar de facto para verificar identidad a distancia fue: foto del documento, selfie, comparar las dos caras. Funcionaba porque conseguir una cara ajena que se pareciera lo suficiente era caro.

Ya no lo es. Hoy, generar un video convincente de una cara que no existe —o de una cara que existe y no es la tuya— es una tarea de minutos con herramientas al alcance de cualquiera. La consecuencia es que la selfie dejó de ser evidencia. Lo que hay que demostrar no es que existe una imagen de una cara: es que había una persona viva y genuina del otro lado, en ese momento.

La normativa argentina lo dice casi con esas palabras. La Res. UIF 14/2023 exige, para la identificación no presencial, que los factores biométricos se obtengan de un ser humano genuino presente al momento de la identificación, y que el sistema proteja frente a fraudes por ataques físicos y digitales. Esas dos últimas palabras son la clave de toda esta nota, porque nombran dos problemas que la industria trata —y certifica— por separado.

Las dos familias de ataque

Ataque de presentación: engañar a la cámara

Un ataque de presentación (PA, presentation attack) es cualquier intento de engañar al sistema mostrándole algo a la cámara real. El sensor funciona normal; lo que hay adelante es falso.

Ejemplos, de más burdo a más sofisticado:

• Una foto impresa de la persona objetivo.
• Un celular o una tablet mostrando una foto o un video.
• Un video pregrabado reproducido frente a la cámara.
• Una máscara de silicona o una máscara 3D impresa.
• Un maniquí con una foto de alta resolución.

La defensa contra esto se llama PAD (presentation attack detection) y está estandarizada: ISO/IEC 30107-3 define cómo se evalúa. Laboratorios independientes como iBeta hacen ensayos contra esa norma y emiten certificaciones por nivel: el Nivel 1 cubre ataques de bajo costo —foto impresa, pantalla, máscara de papel—; el Nivel 2 sube a máscaras y réplicas de fabricación más cara.

Ataque de inyección: saltearse la cámara

Un ataque de inyección (IA, injection attack) es otra cosa completamente distinta. Acá el atacante no le muestra nada a la cámara: reemplaza la cámara. El stream de video que llega a la aplicación viene de un archivo, de un modelo generativo corriendo en tiempo real o de un intercambio de caras aplicado sobre un video en vivo.

Las vías más comunes:

• Cámara virtual. Software que se registra en el sistema operativo como si fuera una webcam. Existe hace años para streaming legítimo y funciona en un teléfono Android estándar, sin rootear.
• Emuladores. Un dispositivo virtual completo donde el atacante controla todos los sensores.
• Manipulación del dispositivo. Con acceso root o modificando el servicio de cámara del sistema operativo, se puede interceptar el stream aguas arriba de la aplicación.

Para los ataques de inyección el estándar es nuevo: CEN/TS 18099, la primera especificación técnica dedicada a la detección de ataques de inyección de datos biométricos, aprobada por CEN a fines de 2024. Los ensayos de laboratorio contra ella empezaron a estar disponibles recién en 2026, con niveles propios —el Nivel 2 cubre webcam virtual y emulador; el Nivel 3, manipulación del dispositivo con root o a nivel del sistema—. Una norma ISO/IEC dedicada al tema está planificada pero todavía no existe.

Traducido: si un proveedor te muestra una certificación, preguntá contra qué norma, de qué nivel y de qué fecha. Una carta ISO/IEC 30107-3 no responde por inyección. Y una certificación de hace tres años no dice nada sobre los modelos generativos de este año.

Por qué el liveness "activo" no resuelve la inyección

La reacción intuitiva ante los deepfakes es pedir pruebas más difíciles: girá la cabeza, pestañeá, seguí el punto con la mirada, leé estos números en voz alta.

Eso ayuda contra los ataques de presentación —una foto impresa no gira la cabeza— pero no resuelve la inyección, porque las herramientas modernas de intercambio de caras responden a los desafíos en tiempo real: la cara sintética se monta sobre el rostro del atacante, que gira la cabeza de verdad. El desafío se cumple perfecto. El video que llega nunca pasó por una cámara.

Por eso el consenso de la industria se movió de "hacer los desafíos más difíciles" a verificar la procedencia de la captura (capture provenance): en vez de preguntarse solo ¿esto parece una persona viva?, preguntarse también ¿este stream salió realmente de la cámara de un dispositivo real, en esta sesión?.

Las señales típicas de procedencia son: detección de cámara virtual, atestación del dispositivo provista por el sistema operativo, detección de emulador y de root, coherencia temporal entre frames, señales de otros sensores y atadura estricta de la sesión.

Lo que un flujo 100% web puede y no puede hacer

Acá viene la parte incómoda, y preferimos escribirla nosotros antes de que la descubras en una auditoría.

kyc.ar corre íntegramente en el navegador del teléfono. El usuario abre un link, saca las fotos, termina. No instala nada. Esa decisión es la razón principal por la que los flujos terminan: pedirle a alguien que baje una app para abrir una cuenta es donde se cae la mitad de los usuarios.

Y esa misma decisión elimina las defensas anti-inyección más fuertes:

No hay una API de atestación de dispositivo en la web. La propuesta que discute el grupo anti-fraude del ecosistema de navegadores sigue siendo una propuesta, no una API disponible. Los tokens de acceso privado de Apple cubren solo su propio navegador y su propio sistema operativo, y resuelven un problema parecido pero distinto.

Cualquiera que te diga que su solución web detecta inyección con la misma fuerza que una app nativa te está vendiendo humo. Nosotros no podemos, y no conocemos a nadie que pueda.

Entonces, ¿qué sí se puede hacer?

Bastante, en realidad. La respuesta no es resignarse: es apilar defensas que no dependan de la atestación del dispositivo, y ser explícito sobre dónde está el techo.

1. Prueba de vida certificada, evaluada del lado del servidor

El motor de prueba de vida que usamos está certificado iBeta PAD niveles 1 y 2 contra ISO/IEC 30107-3. Eso cubre —bien— toda la familia de ataques de presentación: foto impresa, pantalla, video pregrabado, máscara.

Un detalle de diseño que importa más de lo que parece: la evaluación corre en el servidor. El cliente no decide si pasó o no; el cliente ni siquiera se entera del puntaje.

2. La sesión de prueba de vida es de un solo uso y está atada a la verificación

Este es el punto de falla más común en las integraciones de liveness, y por eso lo tratamos como regla dura: el identificador de la sesión biométrica es de un solo uso y queda atado a la sesión de verificación que lo creó. Antes de leer ningún resultado se verifica esa pertenencia.

Sin esa atadura, un atacante puede completar una prueba de vida legítima con su propia cara y después presentar ese resultado en otra sesión. Cada reintento genera además una sesión biométrica nueva, no reutiliza la anterior.

3. El puntaje nunca sale de la plataforma

Ni el puntaje de vivacidad ni el de similitud facial se devuelven jamás por la API ni por los webhooks. Hacia afuera va una decisión —aprobado, a revisión, rechazado— y motivos legibles.

No es purismo: exponer el número es regalarle al atacante una función de costo. Con un puntaje visible, se puede iterar sobre un ataque hasta que dé 0,01 por encima del umbral. Con un aprobado/rechazado, no.

4. Bandas explícitas, con una zona gris que va a revisión humana

La comparación entre la selfie y la foto del documento no devuelve un sí o un no: devuelve una banda. Por encima de un umbral, aprueba automático. Por debajo de otro, rechaza. En el medio hay una zona gris que va a revisión humana, con toda la evidencia a la vista.

Un motor sin zona gris es un motor que está tomando la decisión difícil solo, siempre. Y en biometría la zona difícil es donde viven los falsos rechazos, que en un onboarding son clientes perdidos.

5. Imágenes de auditoría como evidencia

Cada prueba de vida deja una imagen de referencia y varias imágenes de auditoría, cifradas y guardadas con su fecha y hora. Sirven para tres cosas: alimentar la comparación facial (se compara contra todas y se toma la mejor), sostener una revisión humana con material real, y cumplir con la conservación de evidencia que exige la normativa.

6. Defensa en el otro extremo: que el documento tampoco sea una pantalla

El ataque más barato no es un deepfake: es una foto del DNI de otra persona, sacada de una pantalla. Por eso el análisis anti-copia del documento —proporción, luminancia, comparación entre dos capturas en ángulos distintos para ver si los elementos ópticos cambian— es parte de la misma defensa. Lo contamos en detalle en cómo se valida un DNI argentino.

7. Límites de intento y sesiones que expiran

Un ataque de inyección exitoso normalmente requiere varios intentos de calibración. Los límites de reintento por sesión, la expiración de los links y el hecho de que cada intento genere una sesión biométrica nueva encarecen mucho ese proceso. No lo hacen imposible; lo hacen caro, que en seguridad suele ser el objetivo realista.

Cómo cambió el panorama, sin exagerar

Los reportes de amenazas de la industria biométrica vienen señalando el mismo desplazamiento desde 2024: los ataques de inyección superaron a los de presentación como vector principal, empujados por la disponibilidad de herramientas de intercambio de caras en tiempo real y por lo fácil que es instalar una cámara virtual en un teléfono común.

Somos deliberadamente prudentes con los porcentajes: casi todas las cifras que circulan vienen de proveedores del rubro, sobre sus propias bases de tráfico, con metodologías que no son públicas. La tendencia cualitativa está bien establecida y es suficiente para tomar decisiones; los números puntuales conviene tratarlos como lo que son, material comercial.

Lo que sí es verificable: no existe todavía un benchmark independiente y público que mida la tasa real de detección de inyección de los motores comerciales. La norma para hacerlo se aprobó recién a fines de 2024 y los ensayos empezaron en 2026. Cualquiera que hoy afirme un número de detección de inyección lo está afirmando sobre sus propios datos.

Qué preguntarle a un proveedor de prueba de vida

1. ¿Contra qué norma está certificado el motor: ISO/IEC 30107-3, CEN/TS 18099, o ambas?
2. ¿Qué nivel, qué laboratorio y de qué fecha es la carta? ¿Me la pasás?
3. ¿La evaluación corre en el cliente o en el servidor?
4. ¿El identificador de la sesión biométrica es de un solo uso y está atado a la verificación?
5. ¿Devuelven el puntaje al integrador? (Si la respuesta es sí, preguntá por qué.)
6. ¿Qué pasa con un caso en la zona gris?
7. ¿Qué evidencia queda guardada, cifrada con qué y por cuánto tiempo?
8. Si el flujo es 100% web: ¿qué defensas anti-inyección tienen, y cuáles reconocen que no tienen?

Esa última es la que más rápido separa a un proveedor honesto de uno que no lo es. La respuesta correcta no es "todas". Es una lista concreta de lo que sí, y una lista igual de concreta de lo que no.

Para seguir

• KYC en Argentina: qué exige la normativa — por qué la prueba de vida no es opcional para un sujeto obligado.
• Cómo se valida un DNI argentino — la otra mitad de la cadena.

Si estás evaluando proveedores y querés una conversación técnica sin diapositivas, escribinos.