Deteção de Vivacidade Biometria: Métodos, Métricas e Testes (PT-PT)
Um guia técnico sobre deteção de vivacidade biométrica: métodos ativos e passivos, ataques de apresentação e injeção, métricas PAD, testes, implementação e erros comuns de avaliação.

A deteção de vivacidade é um controlo biométrico que estima se uma amostra provém de uma pessoa real presente durante a captura, e não de uma fotografia, reprodução, máscara ou outro artefacto. Na verificação facial, ajuda a responder “é esta uma captura ao vivo?” antes que um sistema de correspondência facial separado responda “esta face corresponde à referência?”
O termo padrão para detetar artefactos apresentados a um sensor biométrico é deteção de ataque de apresentação, ou PAD. Vivacidade e PAD são frequentemente usados de forma intercambiável em discussões de produtos, mas o limite é importante: os ataques também podem injetar mídia sintética ou reproduzida no caminho dos dados sem apresentar nada à câmara física.
Principais pontos
- Vivacidade e correspondência facial respondem a perguntas diferentes. Um estranho ao vivo pode passar na vivacidade e ainda ser a pessoa errada; uma imagem precisa da pessoa certa pode corresponder, sendo uma reprodução.
- Métodos passivos e ativos criam diferentes compensações. As verificações passivas observam uma captura normal, enquanto as verificações ativas pedem ao utilizador para concluir uma ação solicitada.
- A defesa PAD e injeção cobrem diferentes caminhos de ataque. Um fluxo de captura forte deve considerar tanto o sensor quanto o pipeline de software depois dele.
- Uma única percentagem de precisão não é suficiente. A avaliação requer taxas de erro de ataque, taxas de erro de utilizador genuíno, condições de teste, fatias demográficas e de dispositivo, latência e comportamento de repetição.
- O teste deve assemelhar-se à implementação pretendida. Instrumentos de ataque, câmaras, compressão, iluminação, geografia e população de utilizadores afetam os resultados.
O que a deteção de vivacidade faz
Um fluxo remoto de verificação facial geralmente contém várias decisões distintas:
- Integridade da captura: A amostra originou-se através do caminho esperado da câmara e da aplicação?
- Deteção de ataque de apresentação: O sensor parece estar a observar uma característica biométrica real, e não um instrumento de ataque?
- Qualidade biométrica: A amostra é adequada para análise?
- Correspondência facial: A face capturada é suficientemente semelhante à referência confiável?
- Risco contextual: Os sinais do dispositivo, rede, conta e comportamento apoiam a mesma conclusão?
Colapsar estas decisões num único resultado “verificado” torna as fraquezas difíceis de localizar. Mantê-las separadas permite que uma equipa ajuste a política, explique os resultados e responda de forma diferente a baixa qualidade, suspeita de falsificação, incompatibilidade de identidade e alto risco contextual.
A vivacidade é, portanto, um controlo dentro de uma decisão de identidade, não uma prova de identidade por si só.
Ataques de apresentação e ataques de injeção
Um ataque de apresentação ocorre no sensor biométrico. O atacante apresenta algo destinado a ser capturado como se fosse a pessoa alvo. Exemplos incluem:
- uma imagem facial impressa ou exibida;
- uma reprodução de vídeo noutro ecrã;
- um recorte ou artefacto parcial;
- uma máscara bidimensional ou tridimensional;
- maquilhagem, próteses ou outra modificação de aparência.
Um ataque de injeção altera o caminho de captura. Mídia pré-gravada, alterada ou gerada pode ser inserida numa câmara virtual, aplicação, interface do sistema operativo, emulador ou solicitação de rede. A câmara física pode nunca ver a amostra forjada.
Esta distinção muda a defesa. O PAD pode detetar evidências visuais ou comportamentais associadas a um artefacto apresentado, mas um fluxo injetado pode evitar as condições físicas que o método PAD espera. As defesas podem, portanto, incluir integridade da aplicação, captura confiável, resistência à reprodução, vinculação de sessão, autenticação de carga útil, deteção de câmara virtual e verificações de consistência do lado do servidor, além da análise biométrica.
Vivacidade passiva, ativa e híbrida
Vivacidade passiva
A vivacidade passiva analisa uma captura sem pedir ao utilizador para realizar um desafio conspícuo. Dependendo da implementação, pode inspecionar textura, pistas de profundidade, reflexos, movimento, formação de imagem, consistência temporal ou outros sinais.
O principal benefício é o baixo custo de interação: a verificação pode ocorrer durante uma selfie comum ou uma captura curta. A desvantagem é que a sua segurança depende muito do conjunto de ataques testados, canal de captura, modelo e limite. “Passivo” descreve a experiência do utilizador, não um nível universal de garantia.
Vivacidade ativa
A vivacidade ativa pede ao utilizador para responder a um prompt, como mudar a pose da cabeça ou seguir uma sequência aleatória. A resposta pode adicionar evidências de desafio-resposta e tornar uma reprodução fixa menos útil.
As desvantagens são o tempo adicional, requisitos de acessibilidade, necessidades de localização e erro do utilizador. Desafios previsíveis ou reutilizáveis também podem perder valor, então o design do desafio e a vinculação da sessão importam tanto quanto o gesto visível.
Vivacidade híbrida
Um fluxo híbrido combina análise passiva com um desafio ativo, muitas vezes escalando apenas quando o resultado passivo é incerto ou o risco circundante é maior. Isso pode preservar um caminho curto para a maioria dos utilizadores genuínos, enquanto recolhe mais evidências em casos selecionados.
| Método | Interação do utilizador | Principal força | Principal limitação | Padrão útil |
|---|---|---|---|---|
| Passivo | Captura normal | Baixa fricção | Depende das condições de captura e ataques testados | Triagem padrão |
| Ativo | Ação solicitada | Adiciona evidências de desafio-resposta | Mais abandono e trabalho de acessibilidade | Casos de maior risco ou incertos |
| Híbrido | Condicional | Pode equilibrar evidências e fricção | Mais complexidade de política e orquestração | Escalação baseada em risco |
A escolha certa depende da ação que está a ser protegida. Recuperação de conta, transferências de alto valor, verificações de idade, acesso de funcionários e integração inicial de clientes não justificam necessariamente o mesmo limite ou interação.
Como é produzida uma decisão de vivacidade
Embora as implementações difiram, um fluxo bem estruturado geralmente segue estas etapas:
- Iniciar uma sessão vinculada. O backend cria uma tentativa de curta duração associada ao utilizador, ação, dispositivo e política esperados.
- Guiar a captura. A interface verifica o enquadramento, visibilidade, iluminação e movimento, enquanto fornece instruções acessíveis.
- Proteger o caminho de entrada. A aplicação limita as oportunidades de reprodução e substituição e vincula a amostra à sessão atual.
- Verificar a qualidade da amostra. A entrada inutilizável é separada de ataques suspeitos; pedir uma captura melhor é diferente de rejeitar fraude.
- Executar análise PAD ou de vivacidade. O sistema produz pontuações ou evidências categóricas com base no método configurado.
- Corresponder a identidade quando necessário. Uma comparação biométrica separada liga a captura ao vivo a uma referência confiável.
- Combinar sinais de risco. Dispositivo, IP, histórico de tentativas, velocidade e contexto da conta podem alterar a ação necessária.
- Aplicar política. O resultado pode ser aprovar, tentar novamente, aumentar a segurança, revisão manual ou recusar.
- Registrar a decisão. Os dados de auditoria devem identificar versões, limites, evidências, tempo e o motivo do resultado.
As repetições merecem regras explícitas. Tentativas ilimitadas dão aos atacantes mais oportunidades e podem ocultar problemas operacionais. Limites excessivamente estritos, no entanto, podem punir utilizadores genuínos com câmaras mais antigas, deficiências, conectividade deficiente ou iluminação difícil.
As métricas que importam
A ISO/IEC 30107 separa erros envolvendo apresentações de ataques de erros envolvendo utilizadores genuínos. Os termos PAD comuns incluem:
- APCER — Taxa de Erro de Classificação de Apresentação de Ataque: a proporção de apresentações de ataque de um tipo especificado que são classificadas incorretamente como legítimas.
- BPCER — Taxa de Erro de Classificação de Apresentação Genuína: a proporção de apresentações genuínas classificadas incorretamente como ataques.
Estes valores devem ser interpretados em conjunto e num ponto de operação declarado. A diminuição de um limite pode rejeitar mais ataques, ao mesmo tempo que rejeita mais utilizadores genuínos. Agregar todos os ataques numa única média pode ocultar fraquezas contra um instrumento específico, como reproduções ou máscaras.
Outras medidas operacionais também são necessárias:
- falha na aquisição ou conclusão;
- taxas de repetição e abandono;
- latência da decisão;
- resultados por dispositivo, sistema operativo, câmara e condição de rede;
- resultados em grupos demográficos relevantes;
- taxa de revisão manual e concordância do revisor;
- fraudes confirmadas e resultados falsos positivos após a implementação.
A correspondência facial introduz as suas próprias medidas de falsa correspondência e falsa não correspondência. Estas não devem ser apresentadas como métricas de vivacidade. Um relatório completo nomeia o subsistema, a população, o limite, o conjunto de testes e o denominador para cada taxa.
O que o teste PAD independente prova — e o que não prova
A avaliação independente é valiosa porque fornece um plano de teste repetível, instrumentos de ataque documentados e resultados produzidos fora da própria demonstração do fornecedor. A ISO/IEC 30107-3 especifica princípios para testes e relatórios PAD.
A certificação ou os testes de laboratório não provam que todas as implementações terão desempenho idêntico. Leia o escopo:
- Qual produto e versão foram testados?
- O modo era ativo, passivo ou ambos?
- Quais espécies de ataque e níveis de apresentação foram incluídos?
- Quais dispositivos, câmaras e condições ambientais foram usados?
- Quais limites e regras de repetição foram aplicados?
- O teste cobriu apenas ataques de apresentação ou também ataques de injeção?
Uma implementação pode divergir de um resultado de laboratório através de diferentes câmaras, compressão, integração do SDK, limites, orientação de captura ou política. Trate o relatório como evidência sobre uma configuração definida e, em seguida, adicione testes para o ambiente real.
Como avaliar um sistema de vivacidade
1. Definir a ação protegida
Declare o que acontece após uma aprovação e o dano causado por uma aceitação falsa ou rejeição falsa. A consequência de abrir uma conta de baixo risco pode diferir da autorização de recuperação de conta ou de uma grande transferência.
2. Construir um modelo de ataque
Listar instrumentos de apresentação e caminhos de injeção relevantes. Incluir reproduções e impressões comuns antes de se concentrar apenas em mídia sintética sofisticada. Considerar se um atacante possui uma imagem de alta qualidade, um vídeo, documentos de identidade, credenciais de conta ou controlo do dispositivo.
3. Exigir evidências com escopo
Solicitar resultados por ataque no limite de operação proposto, não um número “99%” sem rótulo. Rever erros de utilizador genuíno, conclusão, latência, cobertura de dispositivos, acessibilidade e escopo de teste independente, juntamente com o desempenho do ataque.
4. Testar a integração real
Executar o SDK de produção ou componente de captura nos dispositivos, navegadores, largura de banda e iluminação que os seus utilizadores realmente possuem. Testar interrupção, negação de permissão, segundo plano, repetições, emuladores, câmaras virtuais e sessões reutilizadas.
5. Avaliar a decisão completa
Testar correspondência facial, evidências de documentos ou bases de dados, vinculação de sessão, sinais de dispositivo e rede, lógica de escalonamento, ferramentas de revisão, registos de auditoria e caminhos de recuperação. Um resultado de vivacidade não pode compensar uma referência de registo fraca ou um fallback inseguro.
6. Monitorizar após o lançamento
Acompanhar as mudanças de resultados por versão do produto, segmento de dispositivo, geografia, canal de aquisição e política. As alterações podem indicar um novo ataque, uma regressão do modelo, um problema específico da câmara ou uma alteração na mistura de tráfego. Preservar evidências versionadas para que as decisões históricas permaneçam explicáveis.
Erros comuns de avaliação
Tratar a vivacidade como prova de identidade
Uma pessoa real pode usar o documento de outra pessoa ou uma identidade sintética. Emparelhe a evidência de presença com uma referência confiável e outros controlos de diligência devida do cliente.
Comparar fornecedores com um único número de destaque
As percentagens sem denominadores, tipos de ataque, limites e erros de utilizador genuíno não são comparáveis. Peça a curva de operação ou os resultados no limite que pretende usar.
Ignorar o caminho de injeção
O PAD voltado para a câmara e a integridade da aplicação resolvem problemas relacionados, mas diferentes. Teste se a mídia pré-gravada ou gerada pode ignorar o caminho do sensor esperado.
Confundir baixa qualidade com fraude
Desfoque, brilho, oclusão, necessidades de acessibilidade e baixa largura de banda podem causar incerteza. Uma repetição de qualidade deve usar mensagens e políticas diferentes de um ataque suspeito.
Bloquear todas as tentativas incertas
A política binária pode aumentar os falsos positivos e excluir utilizadores genuínos. A repetição baseada em risco, o aumento ativo, outro fator e a revisão treinada são muitas vezes mais seguros do que forçar um detetor a decidir tudo.
Deixar a recuperação mais fraca do que o registo
Os atacantes visam o caminho mais fácil. Se a recuperação da conta ou a redefinição de fator ignorar a garantia original, uma forte vivacidade de integração não protege o ciclo de vida da conta.
Uma lista de verificação de implementação
Antes do lançamento, confirme que:
- a ação protegida e a garantia exigida estão documentadas;
- as ameaças de apresentação e injeção são modeladas separadamente;
- os resultados dos testes identificam versões, limites, dispositivos, instrumentos de ataque e denominadores;
- os resultados de vivacidade, qualidade e correspondência facial permanecem separados;
- as sessões e capturas são de curta duração, vinculadas e resistentes à reprodução;
- as políticas de repetição, escalonamento, revisão e recuperação têm limites explícitos;
- as jornadas de acessibilidade e de dispositivos de baixo custo são testadas;
- os registos preservam o motivo, a evidência, a configuração e a versão para cada decisão;
- a monitorização pode detetar mudanças por tipo de ataque e segmento de utilizador;
- a retenção de privacidade e os controlos de acesso correspondem à sensibilidade dos dados biométricos.
Usar o Didit para vivacidade dentro de um fluxo de trabalho de identidade
A Didit oferece Vivacidade Passiva a 0,10 $ por verificação e Vivacidade Ativa a 0,15 $ por verificação. As suas certificações listadas incluem iBeta Nível 1 PAD. As equipas podem combinar vivacidade com Verificação de ID, correspondência facial e Análise de Dispositivo e IP num fluxo de trabalho, e depois escolher quando repetir, aumentar a segurança, rever ou parar.
O pacote completo de KYC está listado a 0,33 $ e combina Verificação de ID, Vivacidade Passiva, Correspondência Facial e Análise de IP. Os preços atuais dos módulos são publicados na página de preços. Estes factos do produto descrevem os controlos disponíveis; uma organização ainda deve definir limites e regras de revisão para o seu próprio risco, utilizadores e obrigações regulamentares.
Perguntas frequentes
A deteção de vivacidade é o mesmo que reconhecimento facial?
Não. A vivacidade estima se uma amostra biométrica provém de uma pessoa real e presente. A correspondência facial compara essa amostra com uma referência para estimar se elas representam a mesma pessoa. Muitos fluxos precisam de ambos.
O que é deteção de ataque de apresentação?
PAD é a deteção automatizada de tentativas de interferir num sistema biométrico no sensor, apresentando um artefacto ou uma característica alterada. É o termo orientado por padrões comumente associado aos controlos de vivacidade.
A vivacidade passiva ou ativa é melhor?
Nenhuma é universalmente melhor. Os métodos passivos geralmente reduzem a interação, enquanto os métodos ativos adicionam evidências de desafio-resposta à custa de fricção e trabalho de acessibilidade. Avalie ambos contra o mesmo modelo de ataque, população de utilizadores, dispositivos e política de operação.
A deteção de vivacidade pode impedir deepfakes?
Pode ser uma camada contra alguns ataques de mídia sintética, mas não é uma defesa completa contra deepfakes. Os controlos de injeção, captura confiável, sinais forenses e de proveniência, correspondência facial, risco contextual e recuperação segura permanecem necessários.
O que significam APCER e BPCER?
APCER mede as apresentações de ataque classificadas incorretamente como genuínas; BPCER mede as apresentações genuínas classificadas incorretamente como ataques. Ambos dependem dos tipos de ataque testados e do limite de operação.
Uma certificação PAD cobre ataques de injeção?
Não automaticamente. O escopo da certificação deve ser lido cuidadosamente. O teste PAD concentra-se em ataques de apresentação sob condições definidas; a injeção e as defesas do caminho da aplicação podem exigir avaliação separada.
Com que frequência a vivacidade deve ser usada?
O uso deve seguir o risco da ação. Pode ser apropriado no registo, recuperação, autenticação de alto risco ou transações sensíveis, mas a captura biométrica repetida também cria custos de privacidade e experiência do utilizador.
Referências principais
- NIST glossary: Presentation Attack Detection
- ISO/IEC 30107-1:2023 biometric presentation attack detection framework
- ISO/IEC 30107-3:2023 PAD testing and reporting
- NIST FATE Part 10: Performance of passive, software-based PAD
- NIST SP 800-63B-4: Authentication and authenticator management
- FIDO Alliance face verification certification program
A vivacidade funciona melhor quando a sua afirmação permanece estreita e testável: adiciona evidências de que uma amostra biométrica veio de uma pessoa real na captura. As decisões de identidade, autorização e risco contínuo devem ser construídas em torno dessa evidência, em vez de inferidas a partir dela.
Artigos relacionados
- Deteção de VPNs e Proxies: Sinais, Limites e Políticas (PT-PT)
- Deepfakes: Tipos, Deteção e Defesa (PT-PT)
- KYC Desvendado: Processo, Requisitos e APIs (PT-PT)
- Japão: As Orientações Revisadas de AML/CFT da FSA (Março de 2026) e a Era Baseada no Risco (PT-PT)
- Cripto no Japão e Conformidade EPISP: Travel Rule, KYC e o Cronograma 2025–2027 (PT-PT)
- Leitura de Chip NFC vs. Carregamento de Fotos: A Verificação de Identidade Prioriza o Chip (PT-PT)