Por que um resultado de disponibilidade do telefone não é suficiente

Porque o telefone não é seu. Um resultado de verificação de atividade calculado no aplicativo e enviado ao seu servidor como "aprovado" é uma declaração feita por um dispositivo que, nos casos que lhe interessam, está sob o controle do atacante. Ele pode modificar o aplicativo, executá-lo em um emulador ou fornecer a ele vídeos que nunca foram capturados por uma câmera. Um servidor que aceita a declaração terceirizou sua verificação mais importante para a pessoa que está sendo verificada.

A solução é mais um princípio do que uma funcionalidade: o telefone coleta evidências e o servidor decide. Mantenha o que foi capturado, calcule novamente o veredicto a partir disso em uma infraestrutura que você controla e trate o veredicto do próprio dispositivo como uma entrada entre várias.

O que um invasor pode alterar no dispositivo?

Em seus próprios telefones, quase tudo acontece antes que os dados saiam do aparelho.

• O resultado em si. Se o aplicativo enviarliveness: trueUm aplicativo modificado ou uma solicitação interceptada podem enviar o mesmo valor sem que ninguém esteja em frente à câmera.

• Transmissão da câmera. Uma câmera virtual, um emulador ou uma câmera conectada. API É possível apresentar um vídeo pré-gravado ou gerado como se fosse ao vivo. A lógica de transmissão ao vivo do aplicativo funciona corretamente, mesmo com entradas falsas.

• O momento certo. Uma ferramenta de reprodução pode reenviar uma sessão genuína capturada anteriormente.

O Instituto Nacional de Padrões e Tecnologia dos EUA descreve o segundo caso diretamente. Sua diretriz de comprovação de identidade, SP 800-63A-4 (abre num novo separador) (julho de 2025), define ataques de injeção como a inserção de "mídia modificada ou falsificada entre o ponto de captura (por exemplo, um dispositivo) e o elemento que realiza a comparação", e observa que esses ataques são cada vez mais combinados com ferramentas de IA generativa. O instituto acrescenta que a detecção de ataques de captura e apresentação em tempo real dificulta esses ataques, mas "não é suficiente para lidar com todos os casos possíveis desse tipo de ataque".

Por que uma boa verificação de atividade no dispositivo não resolve isso?

Porque um ataque de apresentação e um ataque de injeção são problemas diferentes.

Um ataque de apresentação coloca algo na frente de uma câmera real: uma foto, uma tela, uma máscara. Uma boa detecção de presença no dispositivo é projetada para capturar esses elementos, e NIST Espera-se que seja testado: o SP 800-63A-4 exige a detecção de ataques de apresentação para coleta biométrica remota com uma taxa de aceitação de apresentação de ataque de impostor inferior a 0,07, testada em conformidade com ISO / IEC 30107-3:2023. NIST É um padrão americano, mas é uma referência útil para consultar com um fornecedor.

Um ataque de injeção nunca apresenta nada diretamente à câmera. A verificação no próprio dispositivo pode ser excelente e ainda assim passar, porque analisa exatamente o vídeo que recebeu. Os únicos pontos onde o ataque pode ser detectado são as próprias evidências e os sinais sobre como foram capturadas, examinados em locais inacessíveis ao atacante.

O que o servidor deveria verificar novamente?

Quatro práticas, em ordem de quanto elas agregam.

1. Guarde a gravação, não apenas o enquadramento.

Uma única foto de selfie não comprova muito sobre a transmissão ao vivo. Faça uma gravação curta do desafio. Isso dá ao servidor algo para reanalisar e ao revisor algo para assistir. Toden Nos SDKs, a selfie é capturada automaticamente assim que os desafios são concluídos, e um breve vídeo de verificação de atividade é gravado para análise no servidor, conforme descrito no SDK documentação (abre num novo separador) .

2. Recalcular o veredicto a partir da gravação.

Para um desafio cuja resposta é visível no vídeo, verifique a resposta no servidor. Um desafio de flash na tela é o caso mais claro: as cores exibidas na tela devem aparecer, em ordem, como reflexos no rosto. Toden A verificação de identidade reanalisa o vídeo gravado no servidor para confirmar se a sequência de flashes aparece no rosto.

3. Registre como as evidências foram coletadas.

Algumas ferramentas de injeção deixam rastros: um nome de dispositivo de câmera que pertence a um software de câmera virtual conhecido, uma câmera com capacidades implausíveis, sinais de um emulador. Nenhum desses elementos, por si só, é prova suficiente, mas, em conjunto, indicam o quanto se pode confiar nos pixels. Toden Os sinais de integridade de captura alimentam um campo de decisão.verification.cameraSuspectIsso ocorre quando sinalizam uma possível injeção, permitindo que um fluxo de trabalho encaminhe essas sessões para revisão. A documentação de tomada de decisão (abre num novo separador) lista esse campo juntamente com os demais.

4. Sempre que possível, faça com que o desafio venha do servidor.

O padrão mais forte é um desafio que o servidor emite e verifica posteriormente. Os chips de passaporte são o exemplo de referência: em NFC Na verificação por chip (abre num novo separador) , o servidor executa uma autenticação passiva nos próprios dados do chip ("o cliente nunca decide a autenticidade"), enquanto a autenticação ativa solicita que o chip assine um desafio único, algo que uma cópia de um chip genuíno não pode fazer. A mesma ideia se aplica a qualquer verificação: quanto menos o cliente escolher, menos ele poderá falsificar.

O que deve acontecer quando o servidor discorda do telefone?

É aqui que muitos projetos exageram. Uma discrepância no servidor é uma forte evidência de que algo está errado, mas nem sempre é prova de fraude. A luz pode distorcer um reflexo. Uma câmera frontal barata pode desfocar um aceno de cabeça. O nome de uma câmera virtual pode pertencer a uma ferramenta legítima de acessibilidade ou transmissão ao vivo.

Portanto, encare uma discrepância como um sinal de risco, não como um veredito. Toden Uma incompatibilidade na sequência de flash é registrada como um sinal de risco, em vez de resultar em falha na verificação por si só. Seu fluxo de trabalho define o que isso significa para o seu produto.

Um exemplo de rota razoável:

Forneça aos revisores tanto a gravação quanto a sinalização. Assistir ao vídeo costuma ser a maneira mais rápida de distinguir um rosto iluminado pelo sol de um rosto reproduzido.

Perguntas a fazer a qualquer fornecedor de equipamentos de som ao vivo

Independentemente de você usar ou não Toden Essas questões diferenciam um projeto baseado na confiança no telefone de um projeto baseado na verificação do servidor:

1. O veredito de atividade é calculado no dispositivo, no servidor ou em ambos? Se em ambos, qual deles decide?

2. Que provas são guardadas e um revisor pode consultá-las?

3. Como detectar vídeos que não foram gravados por uma câmera real?

4. Como a detecção de ataques de apresentação foi testada e em relação a qual padrão?

5. O que acontece quando o servidor discorda do dispositivo: uma falha grave ou um sinal que posso rotear?

A regra para retirar

A confiança em uma verificação deriva do ponto menos confiável por onde ela passa. Se a decisão final for tomada em um telefone que você não controla, esse telefone define o seu limite. Transfira a decisão para o servidor, mantenha as evidências em que ela se baseou e use o telefone para o que ele faz de melhor: guiar uma pessoa real por uma captura de forma rápida.