> 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/docs.facephi-pt-br/produtos/suite-iad-injection-attack-detection/manual-producto-iad.md).
# Manual do Produto IAD
### 1. Visão geral
Facephi IAD (*Detecção de Ataque por Injeção*) é a solução que protege os processos de verificação biométrica facial contra ataques que inserem dados digitais fraudulentos no fluxo de captura, contornando a câmera física do dispositivo. Ao contrário dos ataques de apresentação tradicionais (em que um impostor mostra uma foto ou máscara à câmera), os ataques de injeção operam **atrás** do sensor, substituindo ou manipulando o stream antes que ele chegue ao serviço biométrico.
IAD foi projetado para detectar sinais compatíveis com ataques de injeção, avaliando se a captura:
* Provém de uma câmera física do dispositivo e não de uma fonte virtual ou intermediária.
* Não apresenta indícios de manipulação por software intermediário (hooking, câmeras virtuais, scripts injetados).
* Não mostra sinais de um ambiente não confiável (emulador, dispositivo com root, navegador com extensões maliciosas).
* Não contém artefatos compatíveis com conteúdo sintético, replay ou reproduzido.
### 2. Por que IAD é necessário
A adoção massiva da biometria facial levou os atacantes a abandonar os ataques físicos (cada vez mais detectáveis por Liveness Passivo) e migrar para técnicas digitais: câmeras virtuais que reproduzem vídeos pré-gravados, manipulação da aplicação cliente ou injeção direta de payloads na rede. Essas técnicas são furtivas porque, da perspectiva do servidor "tudo parece normal": uma câmera foi aberta, um rosto foi capturado, um matching foi realizado.
Sem uma camada específica de IAD, um sistema biométrico bem projetado contra ataques de apresentação continua vulnerável a esse vetor. IAD é a camada que fecha essa lacuna.
### 3. IAD e Liveness Passivo — camadas complementares
É comum confundir IAD com liveness, mas eles respondem a perguntas distintas e ambos são necessários:
| Pergunta | Camada que responde | O que detecta |
| ----------------------------------------------------- | -------------------------- | --------------------------------------------------------------------------------------- |
| É uma pessoa que está diante da câmera? | **PAD / Liveness Passivo** | Fotos impressas, máscaras, vídeos reproduzidos em tela diante da câmera, recortes |
| A captura veio realmente da câmera deste dispositivo? | **IAD** | Câmeras virtuais, deepfakes injetados, manipulação do cliente, emuladores, MITM, replay |
Liveness Passivo (PAD) e IAD respondem a perguntas distintas e complementares. O PAD avalia se há uma pessoa real e viva diante da câmera; o IAD avalia se a captura chegou por um canal legítimo e não foi injetada ou manipulada antes de chegar ao serviço. São planos de defesa diferentes: o PAD analisa o conteúdo da imagem, o IAD analisa a origem e a integridade do canal de entrega (metadados, impressão digital da câmera, ambiente de execução). Por isso, são recomendados em conjunto: cobrem vetores de ataque que o outro, por design, não foi criado para abordar.
**Recomendação de arquitetura**: ativar IAD + Liveness Passivo em todos os fluxos de autenticação e Onboarding com requisitos de segurança média ou superior.
### 4. Tipos de ataque cobertos pelo IAD
Os ataques contra a verificação biométrica facial operam em dois planos complementares, que exigem camadas de defesa distintas. No plano de apresentação, a detecção se alinha à taxonomia de padrões internacionais como ISO/IEC 30107-3 (Presentation Attack Detection). O plano de injeção corresponde a uma família de ameaças mais recente, cuja padronização internacional ainda está em desenvolvimento, e que o IAD aborda de forma específica.
| Plano | Família | Método de ataque | Camada que o aborda |
| ------------ | ------------------- | ----------------------------------------------------------------------------------- | ------------------------------------ |
| Apresentação | Conteúdo físico | Apresentar à câmera uma foto impressa, uma reprodução em tela ou uma máscara | Liveness Passivo (PAD) |
| Injeção | Câmera virtual | Usar uma câmera sintética em vez da câmera física | IAD |
| Injeção | Dispositivo externo | Usar um dispositivo externo para capturar e transmitir vídeo como se fosse a câmera | IAD |
| Injeção | Navegador | Manipular as chamadas à câmera ou o código em fluxos web | IAD |
| Injeção | Rede | Manipular ou substituir o payload em trânsito entre cliente e servidor. | IAD + camada de Integração (seção 8) |
**Detectados pela análise do IAD:**
* **Câmeras virtuais:** uso de uma câmera sintética em vez da câmera física do dispositivo.
* **Dispositivos externos de captura:** dispositivo externo que captura e transmite vídeo se apresentando como câmera legítima.
* **Ataques de navegador:** manipulação das chamadas à câmera ou do código em fluxos web.
O conteúdo injetado pode variar de uma imagem estática roubada a deepfakes ao vivo\
generados por IA, passando por morphs faciais, rostos sintéticos gerados por GAN e cheap\
fakes (renders 3D ou imagens manipuladas).
As seguintes ameaças são detectadas em parte pelo IAD, mas não são resolvidas apenas com sua análise: também exigem as práticas de vinculação de sessão, transporte seguro e políticas de reintento descritas na seção 8 (Responsabilidades do integrador).
* **Ataques de rede:** manipulação ou envio de payloads em trânsito entre cliente e servidor. Sua mitigação efetiva depende da assinatura de sessão e da verificação de coorigem no backend do integrador.
* **Man-in-the-Middle:** interceptação e substituição do payload entre cliente e servidor. É mitigado com TLS e pinning de certificados.
* **Ataques de replay:** reutilização de capturas previamente válidas. A mitigação de replay é uma capacidade em evolução; ela é reforçada com tokenização, TTL e limites de reintento por sessão.
**Considerações de cobertura:**
* A cobertura efetiva de cada família depende da plataforma e do modo de segurança configurado no tenant.
* Diante de sinais ambíguos, o IAD prioriza a segurança: ele pode classificar um ataque de apresentação como de injeção. É uma classificação conservadora e intencional — bloquear o ataque prevalece sobre rotulá-lo com exatidão
### 5. Arquitetura do produto
O IAD é composto por duas camadas que operam de forma coordenada:
#### 5.1. Camada cliente — Selphi IAD Component
SDK Selphi IAD de captura biométrica facial que incorpora o novo componente IAD. Funcionalmente equivalente em fluxo e Integração, incorpora controles antifraude adicionais durante a captura:
* Gerenciamento interno de câmera e permissões com preferência por hardware nativo.
* Coleta de metadados de captura e sinais do ambiente de execução.
* **Verificações de Segurança**: detecção de ambientes não confiáveis sem acesso a informações pessoais do usuário.
* **Análise passiva de imagem**: avaliação de características estatísticas, geométricas e temporais da imagem para identificar padrões compatíveis com reprodução de vídeo, injeção de frames, reescalonamento artificial ou fontes sintéticas em comparação com capturas reais provenientes de um sensor físico. A análise é realizada sem reconstruir a imagem nem extrair informações biométricas.
* Geração de um **IAD bundle**: pacote cifrado com imagens e metadados preparado para validação no servidor.
Plataformas suportadas hoje: **Android, iOS, Plugin Híbridos, Web**
Requisitos do dispositivo (Android; equivalente em iOS, validar com a equipe da Facephi):
* Mínimo 3 GB de RAM.
* Câmera frontal com preview de 1920×1080 ou superior.
O resultado da captura (`SelphiResult`) inclui, além dos campos biométricos padrão (`templateRaw`, `template`, `bestImage`, `bestImageTokenized`, `livenessDiagnostic`), o campo `iad` que contém a informação da análise antifraude pronta para enviar ao serviço de verificação.
#### 5.2. Camada servidor — IAD Service
Microserviço REST stateless que recebe o IAD bundle e devolve um veredicto binário:
* **Captura bona-fide (1):** a captura é legítima.
* **Injeção detectada (0):** foram identificados sinais compatíveis com um ataque de injeção.
O serviço pode ser implantado em duas modalidades:
* **SaaS (recomendado):** implantação gerenciada pela Facephi com atualizações contínuas do modelo e das assinaturas de ameaças. É o modelo preferencial porque garante que a detecção evolua no ritmo das novas ameaças sem exigir intervenção do cliente.
* **On-premise:** implantação na infraestrutura do cliente para ambientes com requisitos regulatórios ou de isolamento de rede específicos.
### 6. API de IAD
A superfície de API exposta ao integrador depende do modelo de implantação. As duas modalidades são funcionalmente equivalentes no que diz respeito à detecção de ataques, mas diferem no contrato de API.
#### 6.1. SaaS — Identity API
Na implantação SaaS, o IAD é invocado através do endpoint `POST /iad` da Identity API. A referência completa, códigos de erro e exemplos de integração estão publicados em:
`docs.facephi.com/api-rest/identity-api/identity-api-reference/security-compliance/injection-attack-detection`
Resumo do contrato:
| Elemento | Valor |
| ------------ | -------------------------------------------------------------------------- |
| Endpoint | `POST {IDENTITY_API_BASE_URL}/iad` |
| Autenticação | Cabeçalho `x-api-key` |
| Content-Type | `application/octet-stream` |
| Corpo | `IAD_BUNDLE` (binary) — pacote cifrado gerado pelo Widget Selphi Antispoof |
Resposta `200`:
```json
{ "attack": true}
```
Onde `attack: true` indica que um ataque foi detectado e `attack: false` indica captura legítima (bona-fide).
A lista completa de códigos está na referência da Identity API vinculada acima.
**Fluxo de integração SaaS**
1. O cliente integra o SDK Selphi IAD (componente antispoof Selphi IAD) e captura o evento `onExtractionFinished`.
2. Do resultado de extração, toma-se a propriedade `encryptedLivenessRaw`, que contém o bundle cifrado.
3. A aplicação cliente envia esse bundle ao **backend do integrador** (não diretamente ao endpoint IAD).
4. O backend do integrador invoca `POST /iad` da Identity API com a API key e o bundle no body.
5. A resposta `{"attack": true|false}` determina a decisão do fluxo.
Exemplo:
{% 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
Na implantação on-premise, o integrador opera diretamente o microserviço IAD Service. Os endpoints publicados são:
| Endpoint | Método | Objetivo |
| --------------------------- | ------ | ---------------------------------------------------------------------------------- |
| `/api/v1/iad/check-capture` | POST | Verifica o IAD bundle e determina se a captura é legítima ou foi injetada |
| `/api/v1/iad/extract-image` | POST | Extrai a imagem validada do payload (uso opcional, conforme o fluxo do integrador) |
| `/api/v1/iad/version` | GET | Devolve a Versão do serviço e o status da Licença |
| `/api/v1/iad/health` | GET | Healthcheck para monitoramento |
> A entrega da modalidade Onprem está sujeita à aprovação do representante comercial.
O esquema completo de request/response e o guia operacional de implantação são entregues junto com a licença on-premise.
**{ "attack": true}**
Requisição:
{% code title="" overflow="wrap" expandable="true" %}
```
POST /api/v1/iad/check-capture
Content-Type: multipart/form-data
file=@iad_bundle.bin
```
{% endcode %}
Resposta (captura legítima):
{% code title="" overflow="wrap" expandable="true" %}
```
{
"capture": {
"probability": 1,
"rejection": [],
"score": 1
},
"capture_type": "FACE"
}
```
{% endcode %}
#### 6.3. Resumo comparativo
| Aspecto | SaaS (Identity API) | On-premise (IAD Service) |
| -------------------------- | -------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
| Endpoint principal | `POST /iad` | `POST /api/v1/iad/check-capture` |
| Autenticação | `x-api-key` cabeçalho | Licença gerenciada pelo integrador |
| Content-Type | `application/octet-stream` | `multipart/form-data` |
| Formato da resposta | `{ "attack": bool }` | `{ "capture": { "probability", "rejection", "score" }, "capture_type" }` |
| Endpoints adicionais | Gerenciados pela Facephi | `/extract-image`, `/version`, `/health` |
| Atualizações de modelo | Contínuas, automáticas | Por meio do versionamento do serviço |
| Documentação de referência | `docs.facephi.com/api-rest/identity-api/identity-api-reference/security-compliance/injection-attack-detection` | Entregue com a licença |
### 7. Integração — fluxo recomendado
{% code title="" overflow="wrap" expandable="true" %}
```
[App cliente]
↓ usa
[Selphi IAD Component] Captura Facial + Verificações de Segurança + IAD bundle
↓ retorna SelphiResult { templateRaw, bestImageTokenized, iad, ... }
↓ ou o evento onExtractionFinished com encryptedLivenessRaw (Web)
[Backend do integrador]
↓ POST com bundle
[API IAD] SaaS: POST /iad
On-prem: POST /api/v1/iad/check-capture
↓ retorna veredicto
[Backend do integrador]
↓ se bona-fide, continua com:
[Serviço de Liveness Passivo] Validação de pessoa viva
[Serviço de Matching / Templates] Verificação de Identidade
```
{% endcode %}
Pontos-chave do fluxo:
1. A captura sempre é realizada com Selphi IAD (não com o componente padrão). Isso garante a geração correta do bundle.
2. O bundle é enviado do **backend do integrador** para a API IAD, não diretamente do cliente. Isso é por design: os serviços biométricos da Facephi são B2B, stateless, e são invocados do lado servidor do integrador.
3. A decisão de continuar o fluxo se o IAD detectar injeção é do integrador, dentro do escopo do modo de segurança configurado no tenant.
4. IAD e liveness são chamadas independentes. Recomendamos invocar o IAD primeiro como filtro prévio.
### 8. Responsabilidades do integrador
Os serviços biométricos da Facephi são microserviços stateless: aplicam controles atômicos de integridade por payload (tokenização, TTL, validação de assinatura), mas **não correlacionam assets entre si**. Isso tem implicações que o integrador deve gerenciar em sua camada de orquestração.
#### 8.1. Vinculação de sessão e coorigem de assets
É responsabilidade do integrador garantir que os diferentes assets de uma mesma operação (Captura Facial, Captura de Documento, IAD bundle, liveness token, etc.) provêm do mesmo dispositivo e da mesma sessão. Isso normalmente é feito assinando os payloads no momento da captura com uma chave de sessão gerada no cliente, e verificando essa assinatura no backend do integrador antes de invocar os serviços biométricos.
Sem essa vinculação, um atacante poderia combinar um IAD bundle legítimo de uma pessoa com um liveness token de outra (ataque conhecido como *stream decoupling*). Essa verificação cruzada não é realizada por nenhum serviço biométrico individual da Facephi, nem poderia ser, porque cada microserviço só vê o asset que lhe é enviado.
Essa corresponsabilidade **não é uma lacuna do produto**: é a prática padrão de integração biométrica em arquiteturas B2B desacopladas, equivalente à forma como qualquer integrador assina e vincula assets em fluxos KYC distribuídos.
#### 8.2. Políticas de reintento
IAD aplica controles por payload. Se o integrador permitir reintentos ilimitados diante de uma rejeição, um atacante pode usar o feedback como oráculo para refinar iterativamente seus payloads até encontrar um que passe nos controles. Recomendamos:
* Limitar o número de reintentos por sessão (tipicamente 3–5).
* Aplicar throttling progressivo entre reintentos.
* Não expor ao cliente o motivo detalhado da rejeição (uma mensagem genérica é suficiente e reduz a superfície de oráculo).
* Registrar e alertar sobre padrões anômalos de reintento.
#### 8.3. Transporte e armazenamento
O bundle IAD trafega cifrado a partir do componente cliente. O integrador é responsável por:
* Usar TLS em todas as comunicações com o IAD Service.
* Aplicar pinning de certificados no cliente móvel para prevenir MITM em dispositivos comprometidos.
### 9. Detecção de ambientes não confiáveis (camada cliente)
Selphi IAD avalia continuamente o ambiente do dispositivo móvel durante a captura e reporta sinais de risco do ambiente. As categorias de ameaça monitoradas na captura incluem, entre outras:
* **Integridade do dispositivo e do sistema:** root, bootloader desbloqueado, ROM não oficial, integridade da biblioteca do SDK, manipulação do carregador de classes.
* **Depuração e instrumentação:** modo desenvolvedor, depurador conectado, ADB ativo, frameworks de hooking ou instrumentação dinâmica.
* **Emulação e ambientes virtualizados:** execução em emulador, interfaces de rede associadas a ambientes virtualizados, emuladores em nuvem.
* **Validação de sensores e interação física:** ausência de sensores físicos esperados, inatividade de sensores presentes.
* **Contexto de instalação e uso do aplicativo:** origem de instalação não confiável, perfis de dispositivo anômalos.
* **Postura de segurança do usuário:** ausência de bloqueio de tela, serviços de acessibilidade ativos.
Os sinais detectados são avaliados segundo o modo de segurança configurado no tenant do integrador e são agregados ao IAD bundle para análise consolidada no backend. O integrador não precisa gerenciar esses sinais individualmente: o resultado consolidado chega na resposta do IAD Service.
O IAD fornece detecção de ambientes não confiáveis, mas os sinais específicos que podem ser avaliados dependem das capacidades disponíveis na plataforma e do componente utilizado. As detecções específicas do dispositivo, como root, bootloader, ADB ou sensores, correspondem a capacidades próprias do ambiente móvel.
> Por postura de segurança, a Facephi não publica a enumeração exaustiva das verificações específicas aplicadas por cada controle, já que essa informação pode ser utilizada por atores hostis para projetar técnicas de evasão.
### 10. Privacidade e dados
* O IAD Service é stateless. Não persiste capturas nem metadados além do processamento da solicitação.
* As Verificações de Segurança do SDK avaliam o estado do dispositivo e do sistema **sem acessar informações pessoais do usuário**.
* A análise passiva de imagem é realizada sem reconstruir a imagem nem extrair informações biométricas adicionais.
* Os modelos de detecção são treinados com datasets de uso interno e não armazenam dados do usuário final.
* Na implantação SaaS, as comunicações são cifradas em trânsito; as chaves de licença e criptografia são gerenciadas segundo as práticas padrão da Facephi.
* Na implantação on-premise, o cliente controla integralmente a infraestrutura, a rede e o armazenamento de logs.
### 11. Suporte e próximo passo
Para obter acesso, licenças, especificações técnicas detalhadas (OpenAPI completo, métricas de desempenho sob NDA) ou discutir um caso de uso específico, entre em contato com o representante comercial da Facephi.
A documentação de integração do componente cliente (Android, iOS, Web) está disponível em `docs.facephi.com/productos/suite-iad-injection-attack-detection`.
\