Analisando os ataques de deepfake de Conheça Seu Cliente (KYC)

Onde o endurecimento se encaixa na superfície de ataque de deepfake 

Um rosto já não é prova de identidade. Essa é a verdade incômoda que os bancos estão aprendendo à medida que rostos e documentos gerados por IA começam a passar despercebidos pelas verificações de Conheça Seu Cliente (KYC, na sigla em inglês), que foram criadas para um mundo anterior à IA generativa. 

As câmeras aparecem em alguns momentos específicos do fluxo de identidade de um aplicativo bancário, não apenas uma vez no cadastro. O exemplo mais óbvio é a abertura de conta: um novo cliente fotografa um documento de identidade emitido pelo governo e, em seguida, tira uma selfie ou grava um breve vídeo ao vivo para que o aplicativo possa comparar o rosto no documento com o rosto em frente à lente e confirmar a presença de uma pessoa real (detecção de vivacidade). Muitos bancos também acionam a verificação por câmera como parte da autenticação em duas etapas: uma grande transferência bancária, uma redefinição de senha ou a adição de um novo beneficiário podem exigir uma nova verificação. Algumas instituições realizam verificações periódicas a cada 1 ou 2 anos, ou sempre que os sinais de risco aumentam. Em todos os casos, a câmera não é o único mecanismo de segurança; ela geralmente é combinada com verificações de dispositivos, senhas de uso único ou sinais comportamentais. É por isso que os ataques de deepfake são frequentemente combinados com roubo de identidade, malware, phishing e outras técnicas para burlar as camadas de segurança implementadas. 

É tentador tratar a "fraude com deepfakes" como um problema único com uma única solução. Mas não se trata de um ponto único de falha. Uma verificação KYC percorre um processo de múltiplas etapas, começando na cena física em frente à lente, passando pelo dispositivo, o ambiente de execução do aplicativo, o modelo de decisão no dispositivo, a rede, a decisão do servidor e, finalmente, a sessão em andamento. Um atacante precisa apenas de uma vulnerabilidade em uma dessas etapas; um defensor precisa proteger todas elas. 

Nenhum controle de segurança isolado cobre todo esse pipeline, sendo necessários múltiplos fornecedores de segurança ou componentes desenvolvidos internamente para proteger a superfície de ataque. Este artigo percorre o pipeline de ponta a ponta, focando nos três estágios que um produto de fortalecimento de aplicações e RASP como o Arxan Security realmente mitiga (estágios 2, 3 e 5), e apresenta um relato honesto de quem cobre o restante.  

Superfície de ataque de deepfake KYC: sete estágios de pipeline, cada um com seu próprio ataque e controle.

Etapa 1 — A Camada Física/de Apresentação: O rosto é mesmo real? 

Antes mesmo do dispositivo ou aplicativo entrar em ação, o ataque já ocorre na própria lente: fotos, telas e máscaras. Os mecanismos de Detecção de Ataques de Apresentação (PAD), avaliados segundo a norma ISO/IEC 30107-3, detectam esses ataques por meio da análise de sensores. Essa é a responsabilidade do fornecedor de identidade, que utiliza técnicas como análise de textura, profundidade, reflexão e abordagens proprietárias para garantir que o que é mostrado à câmera seja real. 

Etapa 2 — A Camada de Dispositivo/Captura: A câmera é mesmo real? 

Esta etapa aborda a questão que a maioria das pessoas nunca considera: se a "câmera" que alimenta a verificação de identidade é realmente uma câmera. Em um dispositivo com root ou jailbreak, ou dentro de um emulador, um atacante pode substituir o componente da câmera e injetar um vídeo deepfake pré-renderizado diretamente na API da câmera. O software recebe frames que parecem perfeitamente capturados, mas contêm qualquer coisa que o invasor deseje. Este é o ataque de injeção, e é um passo para inserir deepfakes de IA no aplicativo. 

Isso se enquadra perfeitamente no território do RASP: detecção de root e jailbreak, detecção de emuladores e detecção de interceptação da API da câmera durante a execução do aplicativo. O MASVS-Resilience-1 exige que o aplicativo valide a integridade da plataforma e abrange esse aspecto da proteção contra ataques de deepfake com câmeras.  

Etapa 3 — A Camada de Tempo de Execução: O aplicativo ainda é o mesmo? 

Suponha que o dispositivo seja genuíno. A próxima questão é se o código do aplicativo que realiza a verificação foi adulterado. Os agentes maliciosos podem interceptar ou modificar o software de identidade usando frameworks de instrumentação como Frida ou Xposed. Eles também podem reempacotar o aplicativo com a verificação de vivacidade desativada, de modo que a função de verificação simplesmente retorne "aprovado", independentemente do que a câmera veja. 

Este é o caso de uso padrão de proteção contra adulteração, e é a especialidade da Arxan Security, onde somos pioneiros e os melhores: ofuscação para dificultar a localização do software de identidade, instrumentação e detecção de hooking para limitar as ferramentas de hacking disponíveis e verificações de integridade que detectam binários modificados em tempo de execução. Os padrões MASVS-Resilience-2, 3 e 4 correspondem diretamente a esses controles: anti-análise estática, anti-análise dinâmica e anti-adulteração. 

Etapa 4 — A Camada de Decisão do Lado do Cliente: O Modelo no Dispositivo Foi Enganado? 

Quando um vídeo sintético é bom o suficiente para convencer um modelo não adulterado instalado no dispositivo, apenas um modelo melhor ajuda. A detecção passiva de vídeos em tempo real e de deepfakes no dispositivo é uma capacidade do fornecedor de identidade — os mesmos fornecedores da Fase 1, apenas com uma disciplina diferente. 

Etapa 5 — A Camada de Transporte: Este resultado realmente veio do aplicativo? 

Mesmo com um dispositivo limpo e um aplicativo sem adulterações, o resultado da verificação ainda precisa chegar ao servidor. Os agentes maliciosos exploram essa etapa com interceptação do tipo "homem no meio", ataques de repetição e abuso direto da API. Técnicas como capturar uma resposta legítima de "verificado" e reproduzi-la, ou ignorar completamente o aplicativo e se comunicar com a API KYC com resultados falsificados, são comuns. 

Os controles padrão são bem conhecidos: criptografia de ponta a ponta, atestação de aplicativos cliente, fixação de certificados e um design de API seguro. A Arxan Security oferece fixação de certificados e criptografia whitebox que podem ser usadas para criptografia de ponta a ponta segura, atestação e protocolos como o TLS Mútuo (mTLS). Em uma avaliação típica de ameaças Man-in-the-Middle (MiTM), o ataque se concentra exclusivamente na interceptação da comunicação. Para aplicativos cliente, como aplicativos bancários, os agentes de ameaças controlam as camadas de hardware, software e comunicação. A criptografia whitebox da Arxan vai além e protege a camada de transporte, protegendo a chave que existe no binário e na memória do aplicativo. A combinação da criptografia whitebox com criptografia de ponta a ponta e protocolos de atestação impede que os agentes de ameaças ultrapassem a camada de transporte. Mais detalhes sobre os controles de MitM podem ser encontrados aqui: https://digital.ai/catalyst-blog/quando-o-atacante-é-o-cliente-defendendo-ataques-mitm/  

Etapa 6 — A Camada de Decisão do Lado do Servidor: O Backend Captou o Que o Dispositivo Não Captou? 

Assim como a camada de decisão do lado do cliente, parte ou todo o modelo para processar imagens da câmera pode ser tratado no lado do servidor. A arquitetura cliente versus servidor varia de acordo com o fornecedor de identidade, a plataforma e o software aplicativo. A re-verificação no servidor, a análise de sinais e a lógica de decisão e orquestração da própria empresa identificam o que o modelo do lado do cliente não detectou.  

Estágio 7 — Camada Comportamental/de Sessão: O restante da sessão ainda se parece com o cliente? 

Os agentes maliciosos geralmente apresentam um padrão de comportamento que pode diferir dos usuários típicos. A avaliação contínua de risco, a identificação de dispositivos e a biometria comportamental são gerenciadas por plataformas de fraude/risco ou por um mecanismo de risco interno, e não pelo fornecedor de identidade ou pela camada RASP. 

Por que os limites são importantes 

A segurança do software provém de uma defesa em profundidade. Isso se aplica à sobreposição de diferentes recursos de segurança, como ofuscação e verificação de integridade, com desenvolvimento e infraestrutura de aplicativos seguros por trás disso. Ter clareza sobre quem é responsável por cada etapa é o que realmente garante a eficácia da defesa. Um fornecedor de ponta em Detecção de Ataques de Apresentação (PAD) e verificação de vivacidade é inútil se o binário que executa seu SDK puder ser modificado para sempre retornar "aprovado". Da mesma forma, uma camada RASP robusta não consegue detectar um deepfake bem elaborado apresentado a um aplicativo não adulterado. 

O sistema só se mantém íntegro se o responsável por cada etapa estiver realmente cuidando da sua respectiva etapa. Em nossa experiência, a fraude geralmente evita os controles mais rigorosos e, em vez disso, explora as brechas deixadas nas camadas de segurança.  

O Takeaway 

As funcionalidades de reforço de segurança de aplicações e RASP da Arxan Security mitigam três das sete etapas da superfície de ataque de deepfakes em processos KYC., e eles são As três etapas que um fornecedor de identidade não consegue cobrir sozinho. Na camada de dispositivo/captura, a detecção de root, jailbreak, emulador e interceptação da API da câmera impede que um invasor injete um deepfake antes mesmo que um único frame chegue ao SDK de identidade. Na camada de tempo de execução. — nossa especialidade original, onde continuamos sendo a referência — ofuscação, instrumentaçãoA detecção de hooking e as verificações de integridade binária impedem que os atacantes simplesmente alterem a verificação de atividade para sempre retornar "aprovado". Na camada de transporte, O recurso de fixação de certificado e a criptografia de caixa branca garantem que o resultado "verificado" que chega ao servidor seja o resultado realmente produzido pelo aplicativo, e não uma reprodução ou falsificação. resultarCada um desses controles mapeia diretamente para o MASVS.-A resiliência de 1 a 4 oferece aos clientes um padrão auditável que respalda a alegação. Ignorar qualquer uma delas pode resultar em falsificação, adulteração ou interceptação do resultado de um fornecedor de identidade robusto antes mesmo de chegar ao sistema de back-end. O fornecedor de identidade, a infraestrutura de tomada de decisão do lado do servidor e a plataforma de prevenção a fraudes/riscos são responsáveis ​​pelas outras quatro etapas. enquanto A segurança da Arxan é o que garante a confiabilidade dos resultados de ponta a ponta.