Publicado em: março 16, 2026
Quando o atacante é o cliente: defendendo-se contra ataques Man-in-the-Middle
Imagine que você criou um aplicativo móvel seguro. Suas conexões são criptografadas, sua infraestrutura é reforçada e sua equipe dorme tranquila. De repente, um pesquisador de segurança aparece com um celular Android com acesso root, uma ferramenta de proxy gratuita e todo o seu tráfego de API exposto em texto simples.
Este é o problema do homem no meio (MitM, na sigla em inglês) e é especialmente complicado porque o atacante nem sempre está à espreita em uma rede Wi-Fi de cafeteria.
Para aplicativos móveis, a preocupação geralmente é com ataques Man-in-the-Middle (MitM), mas também com ataques do tipo "homem no cliente" (man-in-the-client), nos quais os invasores podem controlar o dispositivo do usuário e tentar interceptar a comunicação com o servidor. Às vezes, eles estão sentados em uma mesa, tentando deliberadamente fazer engenharia reversa de como seu aplicativo se comunica com o servidor de processamento. Nenhum controle de segurança isolado impede isso. O que funciona é combinar as defesas certas para cada caso de uso: fixação de certificado, criptografia de ponta a ponta white-box e TLS mútuo white-box são boas opções. Veja a seguir o que cada uma faz, por que é importante e onde apresenta limitações.
Colocação de Certificados: Sua Primeira Linha de Defesa
Quando seu aplicativo se conecta a um servidor, ele normalmente confia em qualquer certificado emitido por uma Autoridade Certificadora reconhecida. O pinning descarta essa regra. Em vez disso, seu aplicativo é programado para confiar apenas em certificados específicos pré-configurados. Se um certificado diferente aparecer durante o handshake, a conexão é recusada, ponto final. O pinning é poderoso, mas cria dores de cabeça operacionais reais que você precisa planejar. A rotação de certificados agora é problema seu. Se o seu certificado fixado expirar e você não tiver lançado uma atualização do aplicativo antes, os usuários legítimos ficarão bloqueados.
Atacantes determinados que também controlam o aplicativo móvel podem burlar o PIN do certificado usando dispositivos com acesso root e ferramentas de análise dinâmica como o Frida para contornar a verificação de pinagem. A pinagem pode ser útil para atender a requisitos de conformidade ou como uma camada adicional de segurança contra ataques Man-in-the-Middle (MitM), mas existem abordagens mais robustas para combater esse tipo de ataque. Isso é especialmente importante quando os atacantes controlam diretamente um dos dispositivos de endpoint.
Criptografia de caixa branca para criptografia de ponta a ponta: protegendo chaves quando você não pode confiar no dispositivo.
A criptografia padrão pressupõe que, mesmo que alguém consiga interceptar seu tráfego, não poderá lê-lo porque as chaves são secretas. Mas em um dispositivo com acesso root, onde o atacante pode controlar uma das extremidades da criptografia, essa premissa deixa de existir. Um atacante pode extrair dados da memória, interceptar as chamadas da sua biblioteca criptográfica e extrair as chaves antes ou depois da criptografia. A criptografia de caixa branca resolve esse problema fundindo a chave e o algoritmo em uma única implementação altamente ofuscada. A chave nunca existe como um valor independente na memória.
Utilizar uma implementação white-box do AES ou algoritmo similar para criptografar as comunicações entre dispositivos móveis e o servidor, além da camada TLS, pode impedir que ataques Man-in-the-Middle (MitM) compreendam os dados. A criptografia adicional reduzirá o desempenho, mas oferece um grande benefício em termos de segurança.
TLS mútuo: garantindo que somente seu aplicativo possa se comunicar com seu servidor.
Em uma conexão TLS padrão, apenas o servidor comprova sua identidade, e seu aplicativo verifica o certificado do servidor e decide se deve confiar nele. O TLS mútuo (mTLS) inverte essa lógica, de modo que ambos os lados se autenticam. Seu aplicativo apresenta um certificado de cliente durante o handshake, e seu servidor interrompe a comunicação com qualquer dispositivo que não possa comprovar que possui o certificado correto.
Na prática, isso significa que, mesmo que um agente malicioso consiga burlar o certificado fixado (certificate pinning), ele ainda não conseguirá acessar seu servidor de processamento sem um certificado de cliente válido. Os agentes maliciosos precisarão usar um cliente válido ou extrair a chave privada do aplicativo. O gerenciamento de certificados em larga escala é complexo. Emitir, rotacionar e revogar certificados de cliente para milhões de usuários exige uma infraestrutura de chave pública (PKI) robusta. É possível, mas não é trivial. Em dispositivos com root, ainda existe o risco de um agente malicioso extrair o certificado de cliente e a chave privada para se passar por uma instância legítima do aplicativo. Isso pode ser significativamente melhorado com implementações de algoritmos de geração de assinatura com tamanhos de chave flexíveis, como o RSA SigGen, ou algoritmos de logaritmo discreto de curva elíptica, como o ECDSA, que podem incorporar a chave privada ao código, dificultando sua extração.
Usando individualmente ou combinando tudo
Cada um desses controles pode ser usado individualmente ou em conjunto. O pinning de certificados impede a interceptação por proxy, mas pode ser contornado em dispositivos com root e apresenta problemas operacionais com certificados rotativos. A criptografia de ponta a ponta (E2EE) de caixa branca protege a confidencialidade da carga útil mesmo sob instrumentação ativa, mas tem impacto no desempenho. O mTLS garante que apenas instâncias legítimas de aplicativos possam se conectar, mas as chaves privadas devem ser protegidas com hardware ou implementações de caixa branca, e os certificados devem ser gerenciados em escala.
Digital.ai Agora é possível fornecer fixação de certificado e há implementações white-box certificadas pelo FIPS para as abordagens E2EE e mTLS. A criptografia E2EE por si só pode ser suficiente para muitos casos de uso, ou todas as abordagens podem ser combinadas para maximizar a segurança.
Também recomendamos
Os três argumentos mais contundentes contra a criptografia de caixa branca — e por que eles não fazem sentido.
Na parte 1 desta série, analisamos onde…
A segurança do seu hardware está funcionando. Esse não é o problema.
Ouvimos uma versão dessa objeção com frequência: “Já estamos…
Conformidade com a Lei de Resiliência Cibernética e Application Security
A maioria das organizações que se aproximam da Lei de Resiliência Cibernética (CRA) está investindo…