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:
É 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.
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:
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:
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
O cliente integra o SDK Selphi IAD (componente antispoof Selphi IAD) e captura o evento
onExtractionFinished.Do resultado de extração, toma-se a propriedade
encryptedLivenessRaw, que contém o bundle cifrado.A aplicação cliente envia esse bundle ao backend do integrador (não diretamente ao endpoint IAD).
O backend do integrador invoca
POST /iadda Identity API com a API key e o bundle no body.A resposta
{"attack": true|false}determina a decisão do fluxo.
Exemplo:
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:
/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:
Resposta (captura legítima):
6.3. Resumo comparativo
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
Pontos-chave do fluxo:
A captura sempre é realizada com Selphi IAD (não com o componente padrão). Isso garante a geração correta do bundle.
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.
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.
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.
Atualizado