Ataque de injeção em biometria facial é a substituição do feed de câmera por um stream sintético antes que o SDK (kit de desenvolvimento do fornecedor) receba qualquer frame. O liveness (detecção de vivacidade biométrica) analisa o conteúdo do frame, não a sua origem. O detector recebe um rosto válido porque o rosto que recebe é válido.
Este guia descreve os três vetores técnicos de um ataque de injeção, explica por que o liveness não os cobre e detalha o que controles específicos de anti-injeção precisam verificar para fechar esse perímetro. Os dados de certificação e produção vêm de ambientes reais, com laboratório e referência identificados.
O que distingue um ataque de injeção de um ataque de apresentação?
Um ataque de apresentação coloca um artefato físico na frente da câmera, como uma foto impressa ou uma máscara de silicone. O liveness detecta esse tipo de fraude analisando o frame em busca de sinais de artefato, como textura incompatível, ausência de profundidade, reflexos anômalos, bordas artificiais e padrões de movimento inconsistentes, entre outros indicadores que a análise pode identificar.
Um ataque de injeção ignora a câmera. O stream sintético entra no canal de dados antes do SDK. O liveness nunca vê a câmera real: só o frame fabricado, que pode ter sido gerado com a face legítima do titular da conta, em resolução e iluminação controladas.
A norma que certifica resistência a ataques de apresentação é a ISO/IEC 30107-3 (PAD, Presentation Attack Detection, ou Detecção de Ataque de Apresentação, em português). A norma que certifica resistência a ataques de injeção é a CEN/TS 18009:2024. Um fornecedor pode obter a certificação em uma norma e não obter a segunda, considerando que é um processo de avaliação. O perímetro de injeção permanece aberto.
Quais são os três vetores de um ataque de injeção?
Os vetores chegam por camadas diferentes da pilha técnica. Cada um explora um ponto distinto antes do SDK.
Câmera virtual
O atacante instala um driver de câmera virtual no dispositivo. O sistema operacional registra esse driver como sensor físico legítimo, com o mesmo identificador de hardware de uma câmera real. O SDK é chamado, recebe o feed sintético e o processa normalmente.
Ferramentas de transmissão de lives e gravações em estúdios virtuais são usadas nesse vetor e estão disponíveis gratuitamente. O conteúdo injetado pode ser um vídeo pré-gravado com deepfake ou um stream em tempo real gerado por modelo de IA alimentado com fotos públicas do alvo.
O vetor é detectável porque drivers de software têm padrão de comunicação com o sistema operacional diferente de sensores de hardware. Módulos de anti-injeção verificam essa assinatura antes de processar o frame.
Hook no canal de captura
Sem câmera virtual instalada. Um código intercepta a chamada de câmera no nível do sistema operacional antes de ela chegar ao SDK. O stream é substituído em trânsito. Do ponto de vista do aplicativo, a câmera está funcionando normalmente.
Esse vetor é mais sofisticado: não instala nenhum driver visível, não aparece na lista de dispositivos e não deixa rastro identificável por varredura estática. A detecção exige verificação de integridade do canal em tempo de execução.
Emulação de dispositivo
Sem hardware físico. Um emulador simula o dispositivo completo e alimenta a câmera com conteúdo sintético. O backend recebe requisições de um dispositivo que não existe como objeto físico. A emulação pode incluir a face do alvo gerada com ferramentas de deepfake em tempo real.
O vetor é identificável pela fingerprint do ambiente: emuladores têm padrão de consumo de bateria e comportamento de sensores inerciais diferentes de dispositivos reais. A detecção não exige análise de câmera.
Por que o liveness não detecta ataques de injeção?
O liveness avalia a vivacidade do frame: se o rosto apresentado tem textura e profundidade compatíveis com uma pessoa real. O frame chega ao SDK já construído. O liveness analisa o que recebe.
Num ataque de injeção, o frame foi fabricado antes de entrar no canal. Com ferramentas modernas de geração de vídeo, é possível produzir um deepfake em tempo real com micromovimentos faciais e iluminação adaptativa. O liveness vê um rosto vivo porque recebeu um rosto construído para parecer vivo.
O liveness cobre o artefato físico. O anti-injeção cobre a origem do sinal. São camadas de controle sobre vetores distintos. Contratar apenas liveness e declarar o sistema protegido contra injeção é um gap de perímetro, não uma escolha de arquitetura.
Como os controles de anti-injeção verificam o canal?
O anti-injeção age antes de o SDK processar o frame. A verificação ocorre no canal.
O SDK verifica se o dispositivo que está respondendo é um sensor físico real. Drivers de câmera virtual têm padrão de comunicação com o sistema operacional diferente de sensores de hardware. A diferença é estrutural e detectável.
A verificação do canal acontece em tempo de execução. Técnicas de RASP (Runtime Application Self-Protection) identificam adulteração durante a sessão ativa. A ofuscação do SDK impede que o código seja analisado para mapear vetores de ataque por engenharia reversa.
Emuladores têm fingerprint diferente de hardware físico. Ciclo de bateria e comportamento de sensores inerciais distinguem os dois ambientes sem exigir análise de câmera.
Nenhuma dessas verificações aparece na interface do usuário legítimo. O controle opera inteiramente na camada de infraestrutura.
O que a certificação CEN/TS 18009:2024 testa?
A CEN/TS 18009:2024 é o primeiro padrão técnico específico para controles de anti-injeção em biometria. Publicado pelo Comitê Europeu de Normalização, o padrão define a metodologia de teste para Artificial Image Injection (IAI), ou seja, a injeção de imagens artificiais: qualquer conteúdo sintético injetado no canal de captura antes do SDK.
O padrão tem três níveis; High é o mais alto. Para atingi-lo, o sistema precisa resistir a pelo menos 15 espécies distintas de IAI, com BPCER (Bona fide Presentation Classification Error Rate, ou taxa de rejeição de usuários legítimos pelo módulo de anti-injeção) máximo de 15%.
A certificação não é autodeclaratória. O laboratório acreditado define os ataques, executa o protocolo e assina o laudo. O fornecedor não controla quais espécies de IAI são testadas dentro do conjunto exigido pelo padrão.
O laboratório Antisec conduziu a certificação do módulo de anti-injeção do Fortface entre 30 de julho e 18 de agosto de 2026. Resultado: 18 ataques executados, 15 espécies de IAI distintas, 0 bypass. BPCER: 2%, com limite aceitável pelo padrão em 15%.
Para gestores de contrato: um BPCER de 2% significa que 98 de cada 100 usuários legítimos passam pelo controle sem fricção adicional. O limite de 15% aceito pelo padrão mostra o quanto o resultado está abaixo do patamar mínimo exigido.
Qual é o risco operacional de ataques de injeção em produção?
A sofisticação dos ataques aumentou com a popularização de ferramentas de geração de vídeo. Um ataque que em 2022 exigia infraestrutura especializada roda hoje em notebook com GPU de consumo, com deepfakes gerados em tempo real a partir de fotos públicas do alvo.
Essas tentativas usam a face real do titular da conta. O ataque é silencioso: a câmera parece funcionar e o liveness passa. Não há anomalia no log de sessão, não há alerta visível.
"Um ataque de injeção não dispara alarme. Ele convence o sistema de que está funcionando normalmente. Por isso o controle precisa ser certificado por laboratório acreditado: declaração de fornecedor não cobre esse vetor." Ricardo Fritsche, CTO, Payface
Perguntas frequentes
Ataque de injeção e deepfake são a mesma coisa?
Deepfake é o conteúdo: um vídeo sintético da face de uma pessoa. Ataque de injeção é o vetor: o método de substituir o feed de câmera por esse conteúdo antes que o SDK receba o frame. Um ataque de injeção pode usar um deepfake, mas pode também usar outro tipo de conteúdo sintético. Deepfake sem o vetor de injeção não ultrapassa o liveness de aplicação.
Certificação iBeta (ISO/IEC 30107-3) protege contra ataques de injeção?
A iBeta certifica resistência a ataques de apresentação, seguindo a ISO/IEC 30107-3 PAD. O vetor testado é o artefato físico na frente da câmera. Ataques de injeção ficam fora do escopo desse padrão. Um sistema pode ter certificação iBeta Level 2 e nenhum controle de anti-injeção.
O que é BPCER na certificação CEN/TS 18009:2024?
BPCER (Bona fide Presentation Classification Error Rate) é a taxa de usuários legítimos que o controle de anti-injeção classifica como atacantes e bloqueia. O padrão CEN/TS 18009:2024 nível High aceita até 15%. Um BPCER de 2% significa que 2 em cada 100 usuários legítimos encontram alguma fricção adicional no canal de anti-injeção.
Como validar se um fornecedor tem anti-injeção certificado?
Solicitar o laudo da certificação CEN/TS 18009:2024, emitido por laboratório acreditado, com identificação do nível obtido e data de validade. Declaração do fornecedor sem laudo não documenta o perímetro técnico. A referência do relatório e o código da carta devem constar no documento.
Ataque de injeção funciona em dispositivos iOS?
Sim. O vetor de hook no canal de captura e o de emulação de dispositivo funcionam em iOS com adaptações. A câmera virtual via driver de sistema operacional é mais restrita no iOS pelo modelo de sandboxing da Apple. Os outros dois vetores não dependem de driver instalado.
Por que a taxa de rejeição do liveness e o BPCER de anti-injeção são métricas distintas?
A taxa de rejeição do liveness mede o percentual de usuários legítimos que o módulo reprova por considerar a captura inválida. O BPCER mede o percentual que o módulo de anti-injeção reprova por considerar o canal comprometido. São módulos separados, com métricas separadas. A taxa de rejeição total do sistema combina os dois; tratá-las como a mesma métrica produz comparações incorretas entre fornecedores.
Para aprofundar
Para entender como a escolha do segundo fornecedor de biometria afeta o perímetro de controle e a cobertura de vetores, o post O que perguntar antes de somar um segundo provedor de biometria cobre os critérios de avaliação de taxa de aprovação por segmento e as estruturas de divisão de tráfego.
Fontes
- CEN/TS 18009:2024 — Biometric data injection attack detection. European Committee for Standardization, 2024.
- ISO/IEC 30107-3:2023 — Biometric presentation attack detection: testing and reporting. International Organization for Standardization.
- Antisec Serviços de Informática Ltda. Relatório de certificação CEN/TS 18009:2024 — Fortface SDK Web (ref. ANTISEC-IAD-FORTFACE-WEB-2026-a4232aa02db). Agosto de 2026.
- iBeta Quality Assurance. PAD Evaluation Report — ISO/IEC 30107-3 Level 1 e Level 2. Julho–agosto de 2024.
