Onboarding biométrico: cómo se engaña y cómo se protege

Qué se mostró en DEF CON 34

La primera charla, «The Glass Perimeter», de Dan Borgogno (Faraday) y Javier Bernardo (Strike Security), analizó durante más de seis meses frameworks biométricos que usan bancos y grandes proveedores. Los autores informaron una tasa de evasión del 100%, con suplantaciones físicas de alta fidelidad y con una técnica que hace que el SDK biométrico reciba cuadros que no provienen de la cámara, aunque tenga protección contra manipulación.

La segunda, «Your Bank Thinks I'm You», de Xavier Riofrío Machado y Alex Tipan, atacó aplicaciones financieras en producción con un teléfono Android y herramientas de código abierto. Evadieron la detección de root, interceptaron con Frida la función que entrega el mejor cuadro de la prueba de vida y lo reemplazaron por uno propio. El servidor aceptó combinaciones de plantilla y foto armadas por ellos, y los rostros sintéticos generados con IA a partir de fotos pasaron la prueba de vida sin ser detectados.

Las pruebas se hicieron con autorización. Según contó Riofrío a Clarín, lo lograron en el alta de clientes nuevos y en el reenrolamiento, el proceso que se usa cuando alguien reinstala la aplicación o cambia de teléfono. Borgogno resumió la dificultad de fondo: «Es muy difícil verificar que los datos obtenidos no hayan sido modificados cuando el atacante tiene control total de la aplicación y del teléfono donde vive».

Ataque de presentación y ataque de inyección

La prueba de vida verifica si la captura corresponde a una persona presente ante la cámara. Está pensada para detectar ataques de presentación, como una foto impresa, una pantalla con un video o una máscara. La norma ISO/IEC 30107-3:2023 define cómo se prueba esa detección, que se conoce como PAD.

Lo que se vio en DEF CON pertenece en buena parte a otra familia, el ataque de inyección. Frente a la cámara no hay nada falso. Las imágenes fabricadas entran entre el sensor y el software que las analiza, mediante una cámara virtual, un emulador o una aplicación modificada. Su detección (IAD) tiene una especificación propia, la CEN/TS 18099:2024.

Los marcos internacionales ya separan los dos casos. La guía de identidad digital del NIST (SP 800-63A-4, de julio de 2025) exige en toda verificación remota controles para detectar cámaras virtuales, emuladores y dispositivos alterados. La especificación europea ETSI TS 119 461 pide que la detección de inyección sea probada por un laboratorio acreditado antes de fines de 2026.

En la práctica, un proveedor puede tener vigente una evaluación de detección de presentación y no haber sido evaluado nunca contra inyección. Y si las imágenes llegan manipuladas, el detector de deepfakes analiza lo que el atacante eligió entregarle.

Cuando la persona frente a la cámara es real

En el caso de La Plata, según la acusación, cada persona cobraba unos 80.000 pesos por escanear sus ojos, y las cuentas abiertas con esas identidades habrían recibido más de 27.000 millones de pesos de casinos online clandestinos. La causa sigue en investigación y no hay condena.

En el esquema que describe la causa, quien se registraba era real, estaba presente y coincidía con su documento, así que la verificación biométrica habría dado un resultado correcto. Quién iba a usar la cuenta quedaba fuera de lo que ese control mide.

Para este riesgo sirven otras señales. Algunas aparecen durante el alta, como dispositivos, redes o teléfonos compartidos entre titulares sin relación entre sí, o varias altas desde un mismo equipo en pocos días. Otras aparecen después, como la cantidad de cuentas por persona o cuentas nuevas que reciben muchos ingresos pequeños y los transfieren enseguida.

El consentimiento tampoco alcanza. Una persona real puede prestar su identidad a cambio de dinero, y su consentimiento no dice quién va a usar la cuenta.

Qué exige la normativa argentina

El BCRA permite abrir cuentas sin presencia física si los medios usados cumplen con la prevención del lavado de activos y aseguran la integridad y autenticidad de la información (punto 4.16 del texto ordenado sobre depósitos de ahorro). El estándar de identificación lo fija la UIF. Para las entidades financieras rige la Resolución 14/2023; las billeteras que ofrecen cuentas de pago tienen su propia resolución.

El artículo 25 de la Resolución 14/2023, en la redacción de la Resolución 199/2024, admite la identificación no presencial con «técnicas biométricas rigurosas, almacenables, auditables y no manipulables» y exige «protección frente a fraudes por ataques físicos y digitales». También pide un análisis de riesgo del procedimiento y la conservación de la evidencia con fecha y hora.

La norma no define qué son ataques físicos y digitales. Leída junto con los marcos técnicos internacionales, la frase abarca las dos familias que se mostraron en DEF CON. Es una lectura general; el análisis de cada procedimiento de alta corresponde a cada sujeto obligado y a sus asesores.

Qué controles recomiendo

• Calcule el resultado en el servidor, con la evidencia que recibe y procesa el backend. Un puntaje o un veredicto que llega desde la aplicación pudo haber sido alterado en el teléfono.
• Valide las atestaciones del dispositivo (Play Integrity en Android, App Attest en iOS) en el backend, contra un desafío que emitió el propio servidor, y úselas como una señal entre otras. Los módulos que ocultan el root también intentan engañarlas.
• Ate cada verificación a una sola solicitud de alta, con vencimiento corto y un límite de intentos. Los rechazos repetidos pasan a revisión.
• Compare el rostro con una referencia externa al teléfono, como el registro del RENAPER. Si la única referencia es la foto del DNI capturada en la misma sesión, el atacante controla las dos imágenes.
• En el reenrolamiento y el cambio de teléfono, pida un factor que ya estaba registrado, como el dispositivo anterior o una aplicación autenticadora, y avise al dispositivo anterior. Un código por SMS a la misma línea se pierde con un duplicado de la tarjeta SIM.
• Conserve la evidencia de cada control: resultado, puntajes, cantidad de intentos, versión del SDK y fecha y hora con sello de tiempo. La UIF exige su resguardo (artículo 22, inciso a, de la Resolución 14/2023).
• Antes de contratar o renovar, pruebe su propio flujo con un teléfono con root oculto, una cámara virtual, una sesión aprobada reutilizada en otra solicitud, dos altas con el mismo rostro y distinto DNI, y un reenrolamiento solo con la cara.

Cómo funciona en Identik

La verificación de identidad de Identik usa la tecnología de Namirial Onboarding, nuestro partner tecnológico, con prueba de vida pasiva y detección de deepfakes activadas. La evaluación biométrica se ejecuta en los servidores de Namirial y el resultado llega al backend de la entidad por webhook, sin pasar por el navegador. Si la entidad obtiene su propia credencial del RENAPER, que la otorga para una finalidad declarada, la validación contra el registro se suma al mismo flujo. Para operaciones de mayor riesgo, Namirial ofrece revisión humana y videoidentificación con un operador.

En un flujo por navegador no existe una atestación como Play Integrity o App Attest, y una cámara virtual entrega lo que el atacante elija. Detectarla depende de la tecnología de verificación y de las señales que pondere la entidad. La aplicación móvil de cada entidad, con su login y su política de dispositivos, queda fuera de nuestro control.

En la firma digital, el certificado lo emite AC Digilogix, el certificador licenciado con el que trabajamos. El rostro interviene una sola vez, en la emisión. El titular presenta su DNI, cuyos datos se validan contra el RENAPER, y completa una prueba de vida. La clave privada queda en el HSM del certificador y cada firma se autoriza con un PIN y un código de un solo uso por correo electrónico o aplicación autenticadora. El momento que más hay que proteger es la emisión, porque quien la supere con una identidad ajena configura él mismo esos factores.

Cada documento firmado sale con una constancia que registra los firmantes, los métodos de autenticación, las marcas de tiempo, la IP, el navegador y el hash SHA-256, con un código para verificarla.

Riofrío le dijo a Clarín que «el problema aparece cuando las organizaciones asumen que una solución o un proveedor es infalible». La advertencia vale también para las tecnologías que elegimos nosotros.

Qué preguntarle a su proveedor

1. ¿Qué evaluaciones independientes tiene, con fecha y versión del producto, en detección de presentación (ISO/IEC 30107-3) y en detección de inyección (CEN/TS 18099)? ¿Cubren el navegador y la aplicación nativa?
2. ¿Dónde se calcula el resultado y qué recibe el backend de la entidad?
3. ¿Contra qué referencia se compara el rostro?
4. ¿Cómo se ata una verificación aprobada a una sola solicitud y cuántos intentos admite?
5. ¿Qué evidencia entrega, por cuánto tiempo la conserva y en qué plazo informa un bypass conocido?
6. ¿La entidad puede hacer sus propias pruebas adversarias sin incumplir el contrato?