La IN ITI 38/2026 modificó el requisito de prevención y detección de ataques de inyección ya establecido en la IN ITI n.º 36/2026 para la videoconferencia y la Autoridad de Registro electrónica (AR electrónica) de ICP-Brasil. La nueva redacción eliminó la expresión "de forma indetectable" del requisito relativo a la inyección de video pregrabado o generado artificialmente durante la identificación del solicitante. El cambio está vigente desde su publicación, el 20 de octubre de 2026.
Para las Autoridades de Certificación (AC) y las Autoridades de Registro (AR), la revisión exige atención a las evidencias de protección del canal de captura, además de la prueba de vida. La IN 38 también ajustó reglas sobre documentos digitales, validación y calidad biométrica.
¿Qué cambia la IN ITI 38/2026 en el requisito de anti-inyección?
El cambio alcanza el art. 37, §1, II de la IN 36, sobre la solución de videoconferencia de la AC, y el art. 57, VIII, sobre la aplicación de la AR electrónica. Esta última es la modalidad de emisión automatizada de certificados para personas físicas, sin intervención humana y exclusivamente mediante una aplicación móvil, conforme a los arts. 51 y 53.
Antes, la solución debía aplicar medios de prevención y detección para garantizar que ni el solicitante ni un atacante externo pudieran inyectar, "de forma indetectable", video pregrabado o generado artificialmente. La redacción actual elimina esa expresión y mantiene los medios de prevención y detección como parte del requisito.
Estos incisos establecen la exigencia de prevención y detección, pero no especifican un punto obligatorio de bloqueo antes del SDK. La AC debe evaluar la efectividad del conjunto de controles y validar la interpretación jurídica aplicable a su proceso.
La obligación ya estaba vigente: la IN 36 entró en vigor el 5 de mayo de 2026, incluido el art. 57, VIII para la AR electrónica. Para la videoconferencia, el art. 69 concedió 90 días para los mecanismos de los incisos II y III del §1 del art. 37; ese plazo terminó a comienzos de agosto. La IN 38 no abrió una nueva transición y aprobó la versión 4.1 del DOC-ICP-05.03, sobre identificación biométrica en ICP-Brasil.
Las AC y las AR, como entidades de ICP-Brasil, son responsables de la seguridad del proceso de identificación y de los daños que causen, conforme al art. 1, §2 de la IN 36. Esta responsabilidad ya existía antes de la IN 38 y refuerza la importancia de evaluar los controles implementados y las evidencias presentadas por el proveedor de captura.
¿Qué es un ataque de inyección biométrica y por dónde entra?
Un ataque de inyección biométrica es la inserción o sustitución de datos en el flujo biométrico, eludiendo la captura legítima. En biometría facial, una de las vías consiste en sustituir el feed de la cámara que llega al SDK, el kit de desarrollo de software del proveedor.
La diferencia frente al ataque de presentación está en la entrada de los datos. En la presentación, el atacante coloca un artefacto delante de la cámara, como una foto, un video en pantalla o una máscara. En la inyección, introduce los datos directamente en el flujo. El contenido puede estar grabado, manipulado o generado por IA: deepfake describe el medio, mientras que inyección describe la forma de insertarlo.
La guía técnica de Fortface sobre ataques de inyección en biometría facial detalla tres vectores en el canal de captura:
- Cámara virtual: proporciona un feed de software mediante la interfaz de cámara de la aplicación y sustituye la captura por video pregrabado o generado en tiempo real.
- Hook en el canal de captura: intercepta llamadas o datos y sustituye el stream en tránsito, mientras la cámara aparenta funcionar normalmente para la aplicación.
- Emulación de dispositivo: simula el entorno de ejecución y alimenta la cámara con contenido preparado por el atacante.
Estos ejemplos explican la sustitución en la entrada de captura; la inyección también puede ocurrir en otros puntos del procesamiento. Por eso, la protección considera el origen de la señal y la integridad del flujo, además del contenido de la imagen.
¿Por qué la prueba de vida por sí sola no demuestra protección contra la inyección?
La prueba de vida evalúa señales de vivacidad en la imagen, como textura, movimiento y profundidad, entre otros factores, según la tecnología. La anti-inyección evalúa los riesgos asociados al origen de los datos y al canal. Algunos mecanismos de PAD pueden detectar medios inyectados, pero una evaluación aislada de presentación no demuestra la protección de ese canal.
La IN 36 separa los requisitos: el art. 37, §1, I y el art. 57, VII tratan la vivacidad mediante PAD (Presentation Attack Detection, o detección de ataques de presentación); los incisos siguientes tratan la prevención y detección de inyección.
Los alcances de evaluación también son distintos. La ISO/IEC 30107-3 establece métodos de prueba y reporte de resultados para PAD. La CEN/TS 18099:2024 orienta la evaluación de detección de ataques de inyección. Son referencias técnicas para evaluaciones, no entidades certificadoras.
El art. 37, §2 y el art. 57, IX exigen pruebas periódicas independientes para las tecnologías de PAD. La IN 36 no extiende expresamente esta obligación a la inyección ni hace obligatoria la CEN/TS 18099:2024. Un informe específico de anti-inyección es una evidencia útil de eficacia dentro del alcance probado; la conformidad depende del proceso completo. Los requisitos de la IN 36 no son exhaustivos, conforme al art. 1, §1.
¿Qué controles verifican el canal de captura?
La defensa combina verificaciones de la fuente de captura, de la integridad de la aplicación y del entorno de ejecución, con controles en el cliente, en la comunicación y en el servidor. Las técnicas de RASP (Runtime Application Self-Protection, o protección de la aplicación durante su ejecución) ayudan a identificar alteraciones durante la sesión. La cobertura depende de la plataforma y debe acompañar los nuevos métodos de ataque.
Parte de estos controles ya es exigida por la IN 36:
- Videoconferencia: detección y bloqueo de controladores de cámara virtual, detección de integridad y bloqueo de dispositivos comprometidos (art. 37, §1, III).
- AR electrónica: verificación de la integridad de la aplicación y del entorno, sin indicios de desbloqueo de privilegios administrativos; identidad única del dispositivo acreditada por hardware; y cifrado de extremo a extremo en la comunicación con los sistemas de la AC (art. 57, I a III).
La implementación de los mecanismos de bloqueo debe calibrarse para evitar fricción excesiva o el rechazo indebido de usuarios legítimos, lo que puede afectar la experiencia. Esta calibración debe preservar los bloqueos y requisitos de integridad exigidos por la norma.
¿Qué reglas de documentos y biometría cambiaron con la IN 38?
Además de la anti-inyección, la IN 38 introdujo cambios operativos para la identificación:
- Documento físico o digital: la aceptación de documentos digitales y la revocación del art. 70 pueden reducir la fricción en la emisión remota, favoreciendo ganancias de escala y un mayor volumen de transacciones. En la videoconferencia, el cambio permite enviar y presentar un documento físico o digital; en la AR electrónica, la captura y la validación dejan de estar restringidas al documento físico (arts. 38, I y III; 57, V; y 58, II). Se mantienen las validaciones exigidas por la norma.
- Validación de tecnología incorporada: QR Code, MRZ, NFC o un chip pueden validarse antes o durante la videoconferencia, manteniendo la comparación con el documento presentado (art. 38, §1). Cuando no exista un mecanismo oficial de validación, un segundo agente de registro debe verificar la emisión antes del inicio de la validez del certificado (art. 9, I-A).
- Consulta de la licencia de conducir mediante Datavalid: el art. 27 pasa de "todas las emisiones" a las modalidades presencial, videoconferencia y AR electrónica.
- Calidad de la huella digital: la versión 4.1 del DOC-ICP-05.03 reduce de 70 a 40 el puntaje mínimo NFIQ 2.0, medido después de la compresión WSQ. Cambia el umbral, no el estándar de calidad utilizado.
¿Qué deben solicitar la AC y la AR al proveedor de captura?
Como diligencia técnica, conviene solicitar evidencias separadas por capa. Esta es una recomendación para evaluar al proveedor, no una lista de informes exigidos expresamente por la IN 36:
Presentación: informe de PAD conforme a la ISO/IEC 30107-3, con laboratorio, fecha, versión del SDK, alcance y resultados. Los niveles que correspondan deben asociarse al programa del laboratorio.
Inyección: evaluación específica, por ejemplo según la CEN/TS 18099:2024, identificando laboratorio, nivel, plataforma, versiones y resultado de bypass. El alcance debe distinguir los instrumentos de ataque (IAI, Injection Attack Instrument, las muestras biométricas utilizadas) de los métodos de inserción (IAM, Injection Attack Method).
Estas evidencias pueden formar parte de los criterios contractuales de aceptación de la integración entre la AC, sus AR y el proveedor. Parte de los controles depende de quién desarrolla y opera la aplicación, y no solo del SDK de captura. Por eso, es recomendable definir contractualmente las responsabilidades por la implementación, integración y operación de los controles de integridad de la aplicación y del dispositivo, de identidad del dispositivo acreditada por hardware y de protección de la comunicación con los sistemas de la AC. Para la AR electrónica, es esencial comprobar la cobertura de la aplicación móvil exigida por la norma.
¿Cómo trata Fortface la capa de anti-inyección?
Fortface opera la prueba de vida y la anti-inyección como módulos independientes, cada uno con su propia evaluación.
En la presentación, iBeta evaluó Fortface en los niveles Level 1 y Level 2 del programa del laboratorio, conforme a la ISO/IEC 30107-3, con un APCER (Attack Presentation Classification Error Rate) reportado de 0% en ambos niveles. La métrica representa la proporción de presentaciones de ataque clasificadas incorrectamente como legítimas en la prueba.
En la inyección, Antisec evaluó el SDK Web bajo la CEN/TS 18099:2024 entre el 30 de julio y el 18 de agosto de 2026, con un resultado reportado en el nivel High: se ejecutaron 18 ataques, sin bypass observado. La prueba evaluó la detección de inyección y no incluyó comparación biométrica (matching).
Este informe ofrece evidencia de la capa de anti-inyección para integraciones Web dentro del alcance probado. El resultado no debe extrapolarse a iOS o Android: en la AR electrónica, es necesario evaluar la cobertura de los controles en la aplicación móvil de la AC.
“Un deepfake bien elaborado puede engañar al ojo humano y quizá a la prueba de vida. Lo que no puede engañar es la verificación del canal. La anti-inyección actúa antes de los fotogramas; ahí es donde se bloquea un deepfake enviado mediante inyección.” (Ricardo Fristche, CTO de Fortface by Payface)
