Skip to content

Criptografia em Aplicativos Móveis

A criptografia desempenha um papel especialmente importante na proteção dos dados do usuário — ainda mais em um ambiente móvel, onde o acesso físico ao dispositivo do usuário por parte de atacantes é um cenário provável. Este capítulo fornece um panorama dos conceitos criptográficos e das melhores práticas relevantes para aplicativos móveis. Essas melhores práticas são válidas independentemente do sistema operacional móvel.

Conceitos-Chave

O objetivo da criptografia é fornecer confidencialidade, integridade de dados e autenticidade constantes, mesmo diante de um ataque. A confidencialidade envolve garantir a privacidade dos dados por meio do uso de criptografia. A integridade de dados lida com a consistência dos dados e a detecção de adulteração e modificação de dados por meio do uso de hashing. A autenticidade garante que os dados venham de uma fonte confiável.

Um algoritmo de criptografia converte dados em texto simples (plaintext) em texto cifrado (ciphertext), o que oculta o conteúdo original. Os dados em texto simples podem ser restaurados a partir do texto cifrado por meio da descriptografia. Existem dois tipos de criptografia: simétrica (a criptografia e a descriptografia usam a mesma chave secreta) e assimétrica (a criptografia e a descriptografia usam um par de chaves pública e privada). As operações de criptografia simétrica não protegem a integridade dos dados, a menos que sejam usadas com um modo de cifra aprovado que suporte criptografia autenticada com um vetor de inicialização (IV) aleatório que atenda ao requisito de "unicidade" NIST SP 800-38D - "Recomendação para Modos de Operação de Cifra de Bloco: Modo Galois/Contador (GCM) e GMAC", 2007.

Algoritmos de criptografia de chave simétrica usam a mesma chave para criptografia e descriptografia. Esse tipo de criptografia é rápido e adequado para processamento de dados em massa. Como todos que têm acesso à chave podem descriptografar o conteúdo criptografado, esse método requer um gerenciamento cuidadoso de chaves e controle centralizado sobre a distribuição de chaves.

Algoritmos de criptografia de chave pública operam com duas chaves separadas: a chave pública e a chave privada. A chave pública pode ser distribuída livremente, enquanto a chave privada não deve ser compartilhada com ninguém. Uma mensagem criptografada com a chave pública só pode ser descriptografada com a chave privada e vice-versa. Como a criptografia assimétrica é várias vezes mais lenta que as operações simétricas, ela normalmente é usada apenas para criptografar pequenas quantidades de dados, como chaves simétricas para criptografia em massa.

Hashing não é uma forma de criptografia, mas usa criptografia. Funções de hash mapeiam partes arbitrárias de dados em valores de comprimento fixo de forma determinística. Embora seja fácil calcular o hash a partir da entrada, é muito difícil (ou seja, inviável) determinar a entrada original a partir do hash. Além disso, o hash muda completamente quando até um único bit da entrada é alterado. Funções de hash são usadas para armazenar senhas, verificar integridade (por exemplo, assinaturas digitais ou gerenciamento de documentos) e gerenciar arquivos. Embora as funções de hash não forneçam uma garantia de autenticidade, elas podem ser combinadas como primitivas criptográficas para fazê-lo.

Códigos de Autenticação de Mensagem (MACs) combinam outros mecanismos criptográficos (como criptografia simétrica ou hashes) com chaves secretas para fornecer proteção de integridade e autenticidade. No entanto, para verificar um MAC, várias entidades precisam compartilhar a mesma chave secreta e qualquer uma dessas entidades pode gerar um MAC válido. HMACs, o tipo mais comum de MAC, dependem de hashing como primitiva criptográfica subjacente. O nome completo de um algoritmo HMAC geralmente inclui o tipo da função de hash subjacente (por exemplo, HMAC-SHA256 usa a função de hash SHA-256).

Assinaturas combinam criptografia assimétrica (ou seja, usando um par de chaves pública/privada) com hashing para fornecer integridade e autenticidade, criptografando o hash da mensagem com a chave privada. No entanto, diferentemente dos MACs, as assinaturas também fornecem a propriedade de não-repúdio, pois a chave privada deve permanecer exclusiva do signatário dos dados.

Funções de Derivação de Chave (KDFs) derivam chaves secretas de um valor secreto (como uma senha) e são usadas para transformar chaves em outros formatos ou aumentar seu comprimento. KDFs são semelhantes a funções de hash, mas também têm outros usos (por exemplo, são usadas como componentes de protocolos de acordo de chave multipartidária). Embora tanto as funções de hash quanto as KDFs devam ser difíceis de reverter, as KDFs têm o requisito adicional de que as chaves que produzem devem ter um nível de aleatoriedade.

Identificando Algoritmos Criptográficos Inseguros e/ou Obsoletos

Ao avaliar um aplicativo móvel, você deve garantir que ele não use algoritmos e protocolos criptográficos que tenham vulnerabilidades conhecidas significativas ou que sejam insuficientes para os requisitos modernos de segurança. Algoritmos considerados seguros no passado podem se tornar inseguros com o tempo; portanto, é importante verificar periódicamente as melhores práticas atuais e ajustar as configurações de acordo.

Verifique se os algoritmos criptográficos estão atualizados e em conformidade com os padrões do setor. Algoritmos vulneráveis incluem cifras de bloco desatualizadas (como DES e 3DES), cifras de fluxo (como RC4), funções de hash (como MD5 e SHA1) e geradores de números aleatórios comprometidos (como Dual_EC_DRBG e SHA1PRNG). Observe que mesmo algoritmos certificados (por exemplo, pelo NIST) podem se tornar inseguros com o tempo. Uma certificação não substitui a verificação periódica da solidez de um algoritmo. Algoritmos com vulnerabilidades conhecidas devem ser substituídos por alternativas mais seguras. Além disso, os algoritmos usados para criptografia devem ser padronizados e abertos à verificação. Criptografar dados usando algoritmos desconhecidos ou proprietários pode expor o aplicativo a diferentes ataques criptográficos, o que pode resultar na recuperação do texto simples.

Inspecione o código-fonte do aplicativo para identificar instâncias de algoritmos criptográficos conhecidamente fracos, como:

Os nomes das APIs criptográficas dependem da plataforma móvel específica.

Certifique-se de que:

  • Os algoritmos criptográficos estão atualizados e em conformidade com os padrões do setor. Isso inclui, mas não se limita a cifras de bloco desatualizadas (por exemplo, DES), cifras de fluxo (por exemplo, RC4), bem como funções de hash (por exemplo, MD5) e geradores de números aleatórios comprometidos como Dual_EC_DRBG (mesmo que sejam certificados pelo NIST). Todos esses devem ser marcados como inseguros e não devem ser usados e removidos do aplicativo e do servidor.
  • Os comprimentos das chaves estão em conformidade com os padrões do setor e fornecem proteção suficiente por um longo período. Uma comparação de diferentes comprimentos de chave e a proteção que eles fornecem, levando em conta a Lei de Moore, está disponível online.
  • Através do NIST SP 800-131A - "Transição do Uso de Algoritmos Criptográficos e Comprimentos de Chave", 2024, o NIST fornece recomendações e orientações sobre como alinhar-se com recomendações futuras e fazer a transição para chaves criptográficas mais fortes e algoritmos mais robustos.
  • Os meios criptográficos não são misturados entre si: por exemplo, você não assina com uma chave pública ou tenta reutilizar um par de chaves usado para uma assinatura para fazer criptografia.
  • Os parâmetros criptográficos são bem definidos dentro de uma faixa razoável. Isso inclui, mas não se limita a: salt criptográfico, que deve ter pelo menos o mesmo comprimento que a saída da função de hash, escolha razoável da função de derivação de senha e contagem de iterações (por exemplo, PBKDF2, scrypt ou bcrypt), IVs sendo aleatórios e únicos, modos de criptografia de bloco adequados ao propósito (por exemplo, ECB não deve ser usado, exceto em casos específicos), gerenciamento de chaves sendo feito corretamente (por exemplo, 3DES deve ter três chaves independentes) e assim por diante.

Algoritmos recomendados:

  • Algoritmos de confidencialidade: AES-GCM-256 ou ChaCha20-Poly1305
  • Algoritmos de integridade: SHA-256, SHA-384, SHA-512, BLAKE3, a família SHA-3
  • Algoritmos de assinatura digital: RSA (3072 bits ou mais), ECDSA com NIST P-384 ou EdDSA com Edwards448.
  • Algoritmos de estabelecimento de chave: RSA (3072 bits ou mais), DH (3072 bits ou mais), ECDH com NIST P-384

Observação: As recomendações são baseadas na percepção atual do setor sobre o que é considerado apropriado. Elas estão alinhadas com as recomendações do NIST além de 2030, mas não necessariamente levam em conta os avanços na computação quântica. Para obter conselhos sobre criptografia pós-quântica, consulte a seção "Post-Quantum") abaixo.

Além disso, você deve sempre contar com hardware seguro (se disponível) para armazenar chaves de criptografia, realizar operações criptográficas, etc.

Para obter mais informações sobre a escolha de algoritmos e melhores práticas, consulte os seguintes recursos:

Post-Quantum

Algoritmos de Criptografia de Chave Pública

Em 2024, o NIST aprovou o CRYSTALS-Kyber como um mecanismo de encapsulamento de chave (KEM) pós-quântico para estabelecer um segredo compartilhado em um canal público. Esse segredo compartilhado pode então ser usado com algoritmos de chave simétrica para criptografia e descriptografia.

Assinaturas

Em 2024, o NIST aprovou SLH-DSA e ML-DSA como algoritmos de assinatura digital recomendados para geração e verificação de assinaturas pós-quânticas.

Problemas Comuns de Configuração

Comprimento de Chave Insuficiente

Mesmo o algoritmo de criptografia mais seguro se torna vulnerável a ataques de força bruta quando esse algoritmo usa um tamanho de chave insuficiente.

Certifique-se de que o comprimento da chave atenda aos padrões do setor aceitos.

Criptografia Simétrica com Chaves Criptográficas Embutidas no Código

A segurança da criptografia simétrica e de hashes com chave (MACs) depende do sigilo da chave. Se a chave for divulgada, a segurança obtida pela criptografia é perdida. Para evitar isso, nunca armazene chaves secretas no mesmo local que os dados criptografados que elas ajudaram a criar. Um erro comum é criptografar dados armazenados localmente com uma chave de criptografia estática e embutida no código e compilar essa chave no aplicativo. Isso torna a chave acessível a qualquer pessoa que possa usar um desmontador.

Chave de criptografia embutida no código significa que uma chave é:

  • parte dos recursos do aplicativo
  • valor que pode ser derivado de valores conhecidos
  • embutida no código

Primeiro, certifique-se de que nenhuma chave ou senha esteja armazenada no código-fonte. Isso significa que você deve verificar o código nativo, código JavaScript/Dart, código Java/Kotlin no Android e Objective-C/Swift no iOS. Observe que chaves embutidas no código são problemáticas mesmo que o código-fonte seja ofuscado, pois a ofuscação é facilmente contornada por instrumentação dinâmica.

Se o aplicativo estiver usando TLS bidirecional (ambos os certificados do servidor e do cliente são validados), certifique-se de que:

  • A senha do certificado do cliente não esteja armazenada localmente ou esteja bloqueada no Keychain do dispositivo.
  • O certificado do cliente não seja compartilhado entre todas as instalações.

Se o aplicativo depender de um contêiner criptografado adicional armazenado nos dados do aplicativo, verifique como a chave de criptografia é usada. Se um esquema de encapsulamento de chave for usado, certifique-se de que o segredo mestre seja inicializado para cada usuário ou que o contêiner seja recriptografado com uma nova chave. Se você puder usar o segredo mestre ou a senha anterior para descriptografar o contêiner, verifique como as alterações de senha são tratadas.

As chaves secretas devem ser armazenadas em armazenamento seguro do dispositivo sempre que a criptografia simétrica é usada em aplicativos móveis. Para obter mais informações sobre as APIs específicas da plataforma, consulte os capítulos "Armazenamento de Dados no Android" e "Armazenamento de Dados no iOS".

Funções de Derivação de Chave Impropriamente Utilizadas

Algoritmos criptográficos (como criptografia simétrica ou alguns MACs) esperam uma entrada secreta de um determinado tamanho. Por exemplo, o AES usa uma chave de exatamente 16 bytes. Uma implementação nativa pode usar a senha fornecida pelo usuário diretamente como uma chave de entrada. Usar uma senha fornecida pelo usuário como uma chave de entrada tem os seguintes problemas:

  • Se a senha for menor que a chave, o espaço completo da chave não é usado. O espaço restante é preenchido (espaços às vezes são usados para preenchimento).
  • Uma senha fornecida pelo usuário realisticamente consistirá principalmente em caracteres exibíveis e pronunciáveis. Portanto, apenas alguns dos possíveis 256 caracteres ASCII são usados e a entropia é diminuída aproximadamente por um fator de quatro.

Certifique-se de que as senhas não sejam passadas diretamente para uma função de criptografia. Em vez disso, a senha fornecida pelo usuário deve ser passada para uma KDF para criar uma chave criptográfica. Escolha uma contagem de iterações apropriada ao usar funções de derivação de senha. Por exemplo, o NIST recomenda uma contagem de iterações de pelo menos 10.000 para PBKDF2 e para chaves críticas onde o desempenho percebido pelo usuário não é crítico, pelo menos 10.000.000. Para chaves críticas, é recomendável considerar a implementação de algoritmos reconhecidos pela Password Hashing Competition (PHC) como Argon2.

Geração Impropria de Números Aleatórios

Uma vulnerabilidade comum em aplicativos móveis é o uso inadequado de geradores de números aleatórios. Geradores de Números Pseudoaleatórios (PRNGs) regulares, embora suficientes para uso geral, não são projetados para fins criptográficos. Quando usados para gerar chaves, tokens ou outros valores críticos para segurança, eles podem tornar os sistemas vulneráveis a previsão e ataque.

A questão fundamental é que dispositivos determinísticos não podem produzir verdadeira aleatoriedade. PRNGs simulam aleatoriedade usando algoritmos, mas sem entropia suficiente e força algorítmica, a saída pode ser previsível. Por exemplo, UUIDs podem parecer aleatórios, mas não fornecem entropia suficiente para uso seguro.

A abordagem correta é usar um Gerador de Números Pseudoaleatórios Criptograficamente Seguro (CSPRNG). CSPRNGs são projetados para resistir a análise estatística e previsão, tornando-os adequados para gerar valores não adivinháveis. Todos os valores sensíveis à segurança devem ser gerados usando um CSPRNG com pelo menos 128 bits de entropia.

Hashing Impropriamente Utilizado

Usar a função de hash errada para um determinado propósito pode comprometer tanto a segurança quanto a integridade dos dados. Cada função de hash é projetada com casos de uso específicos em mente, e aplicá-la incorretamente introduz risco.

Para verificações de integridade, escolha uma função de hash que ofereça forte resistência a colisões. Algoritmos como SHA-256, SHA-384, SHA-512, BLAKE3 e a família SHA-3 são apropriados para verificar integridade e autenticidade de dados. Evite algoritmos considerados inseguros como MD5 ou SHA-1, pois são vulneráveis a ataques de colisão.

Não use funções de hash de propósito geral como SHA-2 ou SHA-3 para hashing de senhas ou derivação de chave, especialmente com entrada previsível.

Implementações Personalizadas de Criptografia

Inventar funções criptográficas proprietárias é demorado, difícil e provavelmente falhará. Em vez disso, podemos usar algoritmos bem conhecidos que são amplamente considerados seguros. Os sistemas operacionais móveis oferecem APIs criptográficas padrão que implementam esses algoritmos.

Inspecione cuidadosamente todos os métodos criptográficos usados no código-fonte, especialmente aqueles que são aplicados diretamente a dados sensíveis. Todas as operações criptográficas devem usar APIs criptográficas padrão para Android e iOS (escreveremos sobre elas em mais detalhes nos capítulos específicos da plataforma). Qualquer operação criptográfica que não invoque rotinas padrão de provedores conhecidos deve ser inspecionada de perto. Preste muita atenção a algoritmos padrão que foram modificados. Lembre-se de que encoding não é o mesmo que criptografia! Sempre investigue mais quando encontrar operadores de manipulação de bits como XOR (OU exclusivo).

Em todas as implementações de criptografia, você precisa garantir que o seguinte sempre ocorra:

  • Chaves de trabalho (como chaves intermediárias/derivadas em AES/DES/Rijndael) são removidas adequadamente da memória após o uso ou em caso de erro.
  • O estado interno de uma cifra deve ser removido da memória o mais rápido possível.

Criptografia Impropriamente Implementada

O Advanced Encryption Standard (AES) é o padrão amplamente aceito para criptografia simétrica em aplicativos móveis. É uma cifra de bloco iterativa baseada em uma série de operações matemáticas vinculadas. O AES executa um número variável de rodadas na entrada, cada uma das quais envolve substituição e permutação dos bytes em um bloco de entrada. Cada rodada usa uma chave de rodada de 128 bits que é derivada da chave AES original.

Até o momento, nenhum ataque criptoanalítico eficiente contra o AES foi descoberto. No entanto, detalhes de implementação e parâmetros configuráveis, como o modo de cifra de bloco, deixam alguma margem para erro.

Modos de Cifra de Bloco Comprometidos

A criptografia baseada em bloco é realizada em blocos de entrada discretos (por exemplo, o AES tem blocos de 128 bits). Se o texto simples for maior que o tamanho do bloco, o texto simples é dividido internamente em blocos do tamanho de entrada determinado e a criptografia é realizada em cada bloco. Um modo de operação de cifra de bloco (ou modo de bloco) determina se o resultado da criptografia do bloco anterior impacta os blocos subsequentes.

Evite usar o modo ECB (Electronic Codebook). O ECB divide a entrada em blocos de tamanho fixo que são criptografados separadamente usando a mesma chave. Se vários blocos divididos contiverem o mesmo texto simples, eles serão criptografados em blocos de texto cifrado idênticos, o que torna os padrões nos dados mais fáceis de identificar. Em algumas situações, um atacante também pode ser capaz de reproduzir os dados criptografados.

Para novos projetos, prefira modos de criptografia autenticada com dados associados (AEAD), como Galois/Counter Mode (GCM) ou Counter with CBC-MAC (CCM), pois eles fornecem confidencialidade e integridade. Se GCM ou CCM não estiverem disponíveis, o modo Cipher Block Chaining (CBC) é melhor que o ECB, mas deve ser combinado com um HMAC e/ou garantir que nenhum erro seja dado, como "erro de preenchimento", "erro de MAC" ou "falha na descriptografia", para ser mais resistente a ataques de oráculo de preenchimento. No modo CBC, os blocos de texto simples são XORados com o bloco de texto cifrado anterior, garantindo que cada bloco criptografado seja único e aleatório, mesmo que os blocos contenham as mesmas informações.

Ao armazenar dados criptografados, recomendamos usar um modo de bloco que também proteja a integridade dos dados armazenados, como o Galois/Counter Mode (GCM). Este último tem o benefício adicional de que o algoritmo é obrigatório para cada implementação TLSv1.2 e, portanto, está disponível em todas as plataformas modernas. Para proteger a integridade e autenticidade dos dados usando o modo CBC, é recomendável combinar as técnicas do modo Counter (CTR) e do Cipher Block Chaining-Message Authentication Code (CBC-MAC) no que é chamado de Modo CCM (NIST, 2004).

Para obter mais informações sobre modos de bloco eficazes, consulte as diretrizes do NIST sobre seleção de modo de bloco.

Vetor de Inicialização Previsível

Os modos CBC, OFB, CFB, PCBC, GCM requerem um vetor de inicialização (IV) como entrada inicial para a cifra. O IV não precisa ser mantido em segredo, mas não deve ser previsível: deve ser aleatório e único/não repetível para cada mensagem criptografada. Certifique-se de que os IVs sejam gerados usando um gerador de números aleatórios criptograficamente seguro. Para obter mais informações sobre IVs, consulte o artigo sobre vetores de inicialização do Crypto Fail.

Preste atenção às bibliotecas criptográficas usadas no código: muitas bibliotecas de código aberto fornecem exemplos em suas documentações que podem seguir más práticas (por exemplo, usar um IV embutido no código). Um erro popular é copiar e colar o código de exemplo sem alterar o valor do IV.

Usando a Mesma Chave para Criptografia e Autenticação

Um erro comum é reutilizar a mesma chave para criptografia CBC e CBC-MAC. A reutilização de chaves para diferentes propósitos geralmente não é recomendada, mas no caso do CBC-MAC o erro pode levar a um ataque MitM ("CBC-MAC", 2024.10.11).

Vetores de Inicialização em Modos de Operação com Estado

Observe que o uso de IVs é diferente ao usar os modos CTR e GCM, nos quais o vetor de inicialização é frequentemente um contador (no CTR combinado com um nonce). Portanto, aqui usar um IV previsível com seu próprio modelo com estado é exatamente o que é necessário. No CTR, você tem um novo nonce mais contador como entrada para cada nova operação de bloco. Por exemplo: para um texto simples de 5120 bits de comprimento: você tem 20 blocos, então precisa de 20 vetores de entrada consistindo de um nonce e contador. Já no GCM, você tem um único IV por operação criptográfica, que não deve ser repetido com a mesma chave. Consulte a seção 8 da documentação do NIST sobre GCM para obter mais detalhes e recomendações do IV.

Ataques de Oráculo de Preenchimento devido a Implementações de Preenchimento ou Operação de Bloco Mais Fracas

Antigamente, o preenchimento PKCS1.5 (no código: PKCS1Padding) era usado como mecanismo de preenchimento ao fazer criptografia assimétrica. Este mecanismo é vulnerável ao ataque de oráculo de preenchimento. Portanto, é melhor usar OAEP (Optimal Asymmetric Encryption Padding) capturado em PKCS#1 v2.0 (no código: OAEPPadding, OAEPwithSHA-256andMGF1Padding, OAEPwithSHA-224andMGF1Padding, OAEPwithSHA-384andMGF1Padding, OAEPwithSHA-512andMGF1Padding). Observe que, mesmo ao usar OAEP, você ainda pode enfrentar um problema conhecido como ataque de Manger, conforme descrito no blog da Kudelskisecurity.

Observação: AES-CBC com PKCS #7 mostrou-se vulnerável a ataques de oráculo de preenchimento também, desde que a implementação dê avisos, como "erro de preenchimento", "erro de MAC" ou "falha na descriptografia". Consulte The Padding Oracle Attack e The CBC Padding Oracle Problem para um exemplo. Em seguida, é melhor garantir que você adicione um HMAC após criptografar o texto simples: afinal, um texto cifrado com uma MAC com falha não precisará ser descriptografado e pode ser descartado.

Protegendo Chaves no Armazenamento e na Memória

Quando o despejo de memória faz parte do seu modelo de ameaça, as chaves podem ser acessadas no momento em que são usadas ativamente. O despejo de memória requer acesso root (por exemplo, um dispositivo root ou jailbreak) ou requer um aplicativo modificado com Frida (para que você possa usar ferramentas como Fridump). Portanto, é melhor considerar o seguinte, se as chaves ainda forem necessárias no dispositivo:

  • Chaves em um Servidor Remoto: você pode usar cofres de chaves remotos, como Amazon KMS ou Azure Key Vault. Para alguns casos de uso, desenvolver uma camada de orquestração entre o aplicativo e o recurso remoto pode ser uma opção adequada. Por exemplo, uma função sem servidor em execução em um sistema Function as a Service (FaaS) (por exemplo, AWS Lambda ou Google Cloud Functions) que encaminha solicitações para recuperar uma chave de API ou segredo. Existem outras alternativas, como Amazon Cognito, Google Identity Platform ou Azure Active Directory.
  • Chaves dentro de Armazenamento com Suporte de Hardware Seguro: certifique-se de que todas as ações criptográficas e a própria chave permaneçam no Trusted Execution Environment (TEE) (por exemplo, use Android Keystore) ou Secure Enclave (por exemplo, use o Keychain). Consulte os capítulos [Armazenamento de Dados no Android](0x05d-Testing-Data-Storage.md#st