> For the complete documentation index, see [llms.txt](https://docs.facephi.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.facephi.com/productos/suite-iad-injection-attack-detection/manual-producto-iad.md). # Manual Producto IAD ### 1. Visión general Facephi IAD (*Injection Attack Detection*) es la solución que protege los procesos de verificación biométrica facial frente a ataques que insertan datos digitales fraudulentos en el flujo de captura, eludiendo la cámara física del dispositivo. A diferencia de los ataques de presentación tradicionales (donde un impostor muestra una foto o máscara a la cámara), los ataques de inyección operan **detrás** del sensor, sustituyendo o manipulando el stream antes de que llegue al servicio biométrico. IAD está diseñado para detectar señales compatibles con ataques de inyección, evaluando si la captura: * Procede de una cámara física del dispositivo y no de una fuente virtual o intermedia. * No presenta indicios de manipulación por software intermedio (hooking, cámaras virtuales, scripts inyectados). * No muestra señales de un entorno no confiable (emulador, dispositivo rooteado, navegador con extensiones maliciosas). * No contiene artefactos compatibles con contenido sintético, replay o reproducido. ### 2. Por qué IAD es necesario La adopción masiva de la biometría facial ha empujado a los atacantes a abandonar los ataques físicos (cada vez más detectables por liveness pasiva) y migrar hacia técnicas digitales: cámaras virtuales que reproducen vídeos pregrabados, manipulación de la aplicación cliente o inyección directa de payloads en la red. Estas técnicas son sigilosas porque desde la perspectiva del servidor "todo parece normal": una cámara abrió, una cara fue capturada, un match se produjo. Sin una capa específica de IAD, un sistema biométrico bien diseñado contra ataques de presentación sigue siendo vulnerable a este vector. IAD es la capa que cierra ese hueco. ### 3. IAD y liveness pasivo: capas complementarias Es habitual confundir IAD con liveness, pero responden a preguntas distintas y se necesitan ambas: | Pregunta | Capa que responde | Qué detecta | | ------------------------------------------------------------ | ------------------------- | ------------------------------------------------------------------------------------------- | | ¿Es una persona la que está delante de la cámara? | **PAD / Liveness pasivo** | Fotos impresas, máscaras, vídeos reproducidos en pantalla frente a la cámara, recortes | | ¿La captura vino realmente de la cámara de este dispositivo? | **IAD** | Cámaras virtuales, deepfakes inyectados, manipulación del cliente, emuladores, MITM, replay | El liveness pasivo (PAD) y IAD responden a preguntas distintas y complementarias. PAD evalúa si hay una persona real y viva frente a la cámara; IAD evalúa si la captura llegó por un canal legítimo y no fue inyectada o manipulada antes de llegar al servicio. Son planos de defensa diferentes: PAD analiza el contenido de la imagen, IAD analiza el origen y la integridad del canal de entrega (metadatos, huella de cámara, entorno de ejecución). Por eso se recomiendan juntos: cubren vectores de ataque que el otro, por diseño, no está pensado para abordar. **Recomendación de arquitectura**: activar IAD + liveness pasivo en todos los flujos de autenticación y onboarding con requisitos de seguridad media o superior. ### 4. Tipos de ataque que IAD cubre Los ataques contra la verificación biométrica facial operan en dos planos complementarios, que requieren capas de defensa distintas. En el plano de presentación, la detección se alinea con la taxonomía de estándares internacionales como ISO/IEC 30107-3 (Presentation Attack Detection). El plano de inyección corresponde a una familia de amenazas más reciente, cuya estandarización internacional aún se encuentra en desarrollo, y que IAD aborda de forma específica. | Plano | Familia | Método de ataque | Capa que lo aborda | | ------------ | ------------------- | ------------------------------------------------------------------------------------ | ------------------------------------- | | Presentación | Contenido físico | Presentar a la cámara una foto impresa, una reproducción en pantalla o una máscara | Liveness pasivo (PAD) | | Inyección | Cámara virtual | Usar una cámara sintética en lugar de la cámara física | IAD | | Inyección | Dispositivo externo | Usar un dispositivo externo para capturar y transmitir vídeo como si fuera la cámara | IAD | | Inyección | Navegador | Manipular las llamadas a la cámara o el código en flujos web | IAD | | Inyección | Red | Manipular o sustituir el payload en tránsito entre cliente y servidor | IAD + capa de integración (sección 8) | **Detectados por el análisis de IAD:** * **Cámaras virtuales:** uso de una cámara sintética en lugar de la cámara física del dispositivo. * **Dispositivos externos de captura:** dispositivo externo que captura y transmite vídeo presentándose como cámara legítima. * **Ataques de navegador:** manipulación de las llamadas a la cámara o del código en flujos web. El contenido inyectado puede ser desde una imagen estática robada hasta deepfakes en directo\ generados por IA, pasando por morphs faciales, rostros sintéticos generados por GAN y cheap\ fakes (renderizados 3D o imágenes manipuladas). Las siguientes amenazas se detectan en parte por IAD, pero no se resuelven solo con su análisis: requieren además las prácticas de vinculación de sesión, transporte seguro y políticas de reintento descritas en la sección 8 (Responsabilidades del integrador). * **Ataques de red:** manipulación o envío de payloads en tránsito entre cliente y servidor. Su mitigación efectiva depende de la firma de sesión y la verificación de co-origen en el backend del integrador. * **Man-in-the-Middle:** interceptación y sustitución del payload entre cliente y servidor. Se mitiga con TLS y pinning de certificados. * **Replay attacks:** reutilización de capturas previamente válidas. La mitigación de replay es una capacidad en evolución; se refuerza con tokenización, TTL y límites de reintento por sesión. **Consideraciones de cobertura:** * La cobertura efectiva de cada familia depende de la plataforma y del modo de seguridad configurado en el tenant. * Ante señales ambiguas, IAD prioriza la seguridad: puede clasificar un ataque de presentación como de inyección. Es una clasificación conservadora e intencional: bloquear el ataque prevalece sobre etiquetarlo con exactitud ### 5. Arquitectura del producto IAD se compone de dos capas que operan de forma coordinada: #### 5.1. Capa cliente: Selphi IAD Component SDK Selphi IAD de captura biométrica facial que incorpora el nuevo componente IAD. Funcionalmente equivalente en flujo e integración, incorpora controles antifraude adicionales durante la captura: * Gestión interna de cámara y permisos con preferencia por hardware nativo. * Recolección de metadatos de captura y señales del entorno de ejecución. * **Security Checks**: detección de entornos no confiables sin acceso a información personal del usuario. * **Análisis pasivo de imagen**: evaluación de características estadísticas, geométricas y temporales de la imagen para identificar patrones compatibles con reproducción de vídeo, inyección de frames, reescalado artificial o fuentes sintéticas frente a capturas reales procedentes de un sensor físico. El análisis se realiza sin reconstruir la imagen ni extraer información biométrica. * Generación de un **IAD bundle**: paquete cifrado con imágenes y metadatos preparado para validación en servidor. Plataformas soportadas hoy: **Android, iOS, Plugin Híbridos, Web** Requisitos del dispositivo (Android; equivalente en iOS, validar con el equipo de Facephi): * Mínimo 3 GB de RAM. * Cámara delantera con preview de 1920×1080 o superior. El resultado de la captura (`SelphiResult`) incluye, además de los campos biométricos estándar (`templateRaw`, `template`, `bestImage`, `bestImageTokenized`, `livenessDiagnostic`), el campo `iad` que contiene la información del análisis antifraude lista para enviar al servicio de verificación. #### 5.2. Capa servidor: IAD Service Microservicio REST stateless que recibe el IAD bundle y devuelve un veredicto binario: * **Bona-fide capture (1):** la captura es legítima. * **Injection detected (0):** se han identificado señales compatibles con un ataque de inyección. El servicio puede desplegarse en dos modalidades: * **SaaS (recomendado):** despliegue gestionado por Facephi con actualizaciones continuas del modelo y de las signaturas de amenazas. Es el modelo preferente porque garantiza que la detección evoluciona al ritmo de las nuevas amenazas sin requerir intervención del cliente. * **On-premise:** despliegue en infraestructura del cliente para entornos con requisitos regulatorios o de aislamiento de red específicos. ### 6. API de IAD La superficie de API expuesta al integrador depende del modelo de despliegue. Las dos modalidades son funcionalmente equivalentes en lo que respecta a la detección de ataques, pero difieren en el contrato de API. #### 6.1. SaaS: Identity API En despliegue SaaS, IAD se invoca a través del endpoint `POST /iad` de Identity API. La referencia completa, códigos de error y ejemplos de integración están publicados en: `docs.facephi.com/api-rest/identity-api/identity-api-reference/security-compliance/injection-attack-detection` Resumen del contrato: | Elemento | Valor | | ------------- | ------------------------------------------------------------------------------ | | Endpoint | `POST {IDENTITY_API_BASE_URL}/iad` | | Autenticación | Header `x-api-key` | | Content-Type | `application/octet-stream` | | Body | `IAD_BUNDLE` (binary): paquete cifrado generado por el Widget Selphi Antispoof | Respuesta `200`: ```json { "diagnostic": "NoLive", "reason": "UntrustedContent" } ``` Donde `diagnostic` es el veredicto: `NoLive` indica que se ha detectado un ataque y `Live` indica captura legítima (bona-fide). `reason` detalla el motivo del rechazo, y vale `None` cuando la captura se acepta. El listado completo de códigos está en la referencia de Identity API enlazada arriba. **Flujo de integración SaaS** 1. El cliente integra el SDK Selphi IAD (Selphi IAD componente antispoof) y captura el evento `onExtractionFinished`. 2. Del resultado de extracción, se toma la propiedad `encryptedLivenessRaw`, que contiene el bundle cifrado. 3. La aplicación cliente envía ese bundle al **backend del integrador** (no directamente al endpoint IAD). 4. El backend del integrador invoca `POST /iad` de Identity API con la API key y el bundle en el body. 5. La respuesta `{"diagnostic": "Live"|"NoLive"}` determina la decisión del flujo. Ejemplo: {% code title="" overflow="wrap" expandable="true" %} ``` const onExtractionFinished = (extractionResult) => { fetch(YOUR_BACKEND_URL, { method: 'POST', headers: { 'Content-Type': 'application/octet-stream' }, body: extractionResult.detail.encryptedLivenessRaw }) .then(response => response.json()) .then(result => console.log('RESULT FROM SERVICE', result)); } ``` {% endcode %} #### 6.2. On-premise: IAD Service En despliegue on-premise, el integrador opera directamente el microservicio IAD Service. Los endpoints publicados son: | Endpoint | Método | Propósito | | ------------------------------- | ------ | -------------------------------------------------------------------------------- | | `/api/v1/iad/liveness/evaluate` | POST | Verifica el IAD bundle y determina si la captura es legítima o ha sido inyectada | | `/api/v1/iad/extract` | POST | Extrae la imagen validada del payload (uso opcional, según flujo del integrador) | | `/api/v1/iad/version` | GET | Devuelve versión del servicio y estado de licencia | | `/api/v1/iad/health` | GET | Healthcheck para monitorización | > La entrega de la modalidad Onprem esta sujeta a aprobación de representante comercial. El esquema completo de request/response y la guía operacional de despliegue se entregan junto con la licencia on-premise. **Ejemplo: liveness/evaluate (on-prem)** Request: {% code title="" overflow="wrap" expandable="true" %} ``` POST /api/v1/iad/liveness/evaluate Content-Type: multipart/form-data capture=@iad_bundle.bin ``` {% endcode %} Response (captura legítima): {% code title="" overflow="wrap" expandable="true" %} ``` { "diagnostic": "Live", "reason": "None", "probability": 1, "score": 1, "sdkDuration": 12, "queueDuration": 3 } ``` {% endcode %} {% hint style="warning" %} El campo multipart se llama `capture`. El nombre antiguo `file` no se acepta desde la versión 2.0.0. {% endhint %} #### 6.3. Resumen comparativo | Aspecto | SaaS (Identity API) | On-premise (IAD Service) | | --------------------------- | -------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | | Endpoint principal | `POST /iad` | `POST /api/v1/iad/liveness/evaluate` | | Autenticación | `x-api-key` header | Licencia gestionada por el integrador | | Content-Type | `application/octet-stream` | `multipart/form-data`, con el campo `capture` | | Forma de la respuesta | `{ "diagnostic", "reason" }` | `{ "diagnostic", "reason", "probability", "score", "sdkDuration", "queueDuration" }` | | Endpoints adicionales | Gestionados por Facephi | `/extract`, `/version`, `/health`, `/config` | | Actualizaciones de modelo | Continuas, automáticas | Vía versionado del servicio | | Documentación de referencia | `docs.facephi.com/api-rest/identity-api/identity-api-reference/security-compliance/injection-attack-detection` | Entregada con la licencia | El SaaS expone un subconjunto del contrato: publica el veredicto (`diagnostic` y `reason`) y deja dentro las cifras de tiempo y de confianza que el motor calcula. ### 7. Integración: flujo recomendado {% code title="" overflow="wrap" expandable="true" %} ``` [App cliente] ↓ usa [Selphi IAD Component] Captura facial + Security Checks + IAD bundle ↓ devuelve SelphiResult { templateRaw, bestImageTokenized, iad, ... } ↓ o el evento onExtractionFinished con encryptedLivenessRaw (Web) [Backend del integrador] ↓ POST con bundle [API IAD] SaaS: POST /iad On-prem: POST /api/v1/iad/liveness/evaluate ↓ devuelve veredicto [Backend del integrador] ↓ si bona-fide, continúa con: [Servicio de Liveness pasivo] Validación de persona viva [Servicio de Matching / Templates] Verificación de identidad ``` {% endcode %} Puntos clave del flujo: 1. La captura siempre se realiza con Selphi IAD (no el componente estándar). Esto garantiza la generación correcta del bundle. 2. El bundle se envía desde el **backend del integrador** a la API IAD, no directamente desde el cliente. Esto es por diseño: los servicios biométricos de Facephi son B2B, stateless, y se invocan desde el lado servidor del integrador. 3. La decisión de continuar el flujo si IAD detecta inyección es del integrador, dentro del marco del modo de seguridad configurado en el tenant. 4. IAD y liveness son llamadas independientes. Recomendamos invocar IAD primero como filtro previo. ### 8. Responsabilidades del integrador Los servicios biométricos de Facephi son microservicios stateless: aplican controles de integridad atómicos por payload (tokenización, TTL, validación de firma) pero **no correlacionan assets entre sí**. Esto tiene implicaciones que el integrador debe gestionar en su capa de orquestación. #### 8.1. Vinculación de sesión y co-origen de assets Es responsabilidad del integrador garantizar que los distintos assets de una misma operación (captura facial, captura de documento, IAD bundle, liveness token, etc.) provienen del mismo dispositivo y de la misma sesión. Esto se consigue habitualmente firmando los payloads en el momento de la captura con una clave de sesión generada en el cliente, y verificando esa firma en el backend del integrador antes de invocar los servicios biométricos. Sin esta vinculación, un atacante podría combinar un IAD bundle legítimo de una persona con un liveness token de otra (ataque conocido como *stream decoupling*). Esta verificación cruzada no la realiza ningún servicio biométrico individual de Facephi, ni puede realizarla, porque cada microservicio solo ve el asset que se le envía. Esta corresponsabilidad **no es un gap del producto**: es la práctica estándar de integración biométrica en arquitecturas B2B desacopladas, equivalente a cómo cualquier integrador firma y vincula assets en flujos KYC distribuidos. #### 8.2. Políticas de reintento IAD aplica controles por payload. Si el integrador permite reintentos ilimitados ante un rechazo, un atacante puede usar el feedback como oráculo para refinar iterativamente sus payloads hasta encontrar uno que pase los controles. Recomendamos: * Limitar el número de reintentos por sesión (típicamente de 3 a 5). * Aplicar throttling progresivo entre reintentos. * No exponer al cliente el motivo detallado del rechazo (un mensaje genérico es suficiente y reduce la superficie de oráculo). * Logar y alertar sobre patrones de reintento anómalos. #### 8.3. Transporte y almacenamiento El bundle IAD viaja cifrado desde el componente cliente. El integrador es responsable de: * Usar TLS en todas las comunicaciones con el IAD Service. * Aplicar pinning de certificados en el cliente móvil para prevenir MITM en dispositivos comprometidos. ### 9. Detección de entornos no confiables (capa cliente) Selphi IAD evalúa de forma continua en el entorno del dispositivo móvil durante la captura y reporta señales de riesgo del entorno. Las categorías de amenaza que se monitorizan en captura incluyen, entre otras: * **Integridad del dispositivo y del sistema:** root, bootloader desbloqueado, ROM no oficial, integridad de la librería del SDK, manipulación del cargador de clases. * **Depuración e instrumentación:** modo desarrollador, depurador conectado, ADB activo, frameworks de hooking o instrumentación dinámica. * **Emulación y entornos virtualizados:** ejecución en emulador, interfaces de red asociadas a entornos virtualizados, emuladores cloud. * **Validación de sensores e interacción física:** ausencia de sensores físicos esperables, inactividad de sensores presentes. * **Contexto de instalación y uso de la aplicación:** origen de instalación no confiable, perfiles de dispositivo anómalos. * **Postura de seguridad del usuario:** ausencia de bloqueo de pantalla, servicios de accesibilidad activos. Las señales detectadas se evalúan según el modo de seguridad configurado en el tenant del integrador y se agregan al IAD bundle para su análisis consolidado en backend. El integrador no necesita gestionar estas señales individualmente: el resultado consolidado llega en la respuesta del IAD Service. IAD proporciona detección de entornos no confiables, pero las señales concretas que pueden evaluarse dependen de las capacidades disponibles en la plataforma y del componente utilizado. Las detecciones específicas de dispositivo, como root, bootloader, ADB o sensores, corresponden a capacidades propias del entorno móvil. > Por postura de seguridad, Facephi no publica la enumeración exhaustiva de comprobaciones específicas que aplica cada control, ya que esa información puede ser utilizada por actores hostiles para diseñar técnicas de evasión. ### 10. Privcidad y datos * El IAD Service es stateless. No persiste capturas ni metadatos más allá del procesamiento de la petición. * Los Security Checks del SDK evalúan el estado del dispositivo y del sistema **sin acceder a información personal del usuario**. * El análisis pasivo de imagen se realiza sin reconstruir la imagen ni extraer información biométrica adicional. * Los modelos de detección se entrenan con datasets de uso interno y no almacenan datos del usuario final. * En despliegue SaaS, las comunicaciones se cifran en tránsito; las claves de licencia y cifrado se gestionan según las prácticas estándar de Facephi. * En despliegue on-premise, el cliente controla íntegramente la infraestructura, la red y el almacenamiento de logs. ### 11. Soporte y siguiente paso Para obtener acceso, licencias, especificaciones técnicas detalladas (OpenAPI completo, métricas de rendimiento bajo NDA) o discutir un caso de uso específico, contactar con el representante comercial de Facephi. La documentación de integración del componente cliente (Android, iOS, Web) está disponible en `docs.facephi.com/productos/suite-iad-injection-attack-detection`. \