Criptografia em aplicações móveis — fundamentos, algoritmos e princípio de funcionamento

O que é criptografia em aplicações móveis?

Criptografia no contexto de aplicações móveis é a aplicação de algoritmos criptográficos para proteger dados armazenados no dispositivo (data at rest) e transmitidos pela rede (data in transit). No nível do dispositivo, o armazenamento local é criptografado: arquivos, bancos de dados, SharedPreferences e cache. No nível da rede, o tráfego entre o aplicativo e o servidor é criptografado por meio dos protocolos TLS/HTTPS. O objetivo final é garantir que, mesmo com acesso físico ao dispositivo ou interceptação de tráfego, um invasor não consiga ler os dados protegidos sem a chave criptográfica.

Por que a criptografia é necessária em aplicações móveis

Os dispositivos móveis são particularmente vulneráveis à perda de dados: um telefone pode ser facilmente perdido, roubado ou infectado por malware. De acordo com o Ponemon Institute (2023), 42% das empresas afetadas por violações de dados atribuem os incidentes a dispositivos móveis. Sem criptografia, um invasor pode conectar-se ao dispositivo via USB, extrair o banco de dados SQLite e ler todos os dados armazenados. A criptografia resolve esse problema: mesmo que o banco de dados seja extraído, seu conteúdo permanece criptografado. Além disso, nos EUA e na UE existem leis (GDPR, CCPA) que exigem criptografia de dados pessoais e impõem multas de até 4% do faturamento anual por violações. O uso de criptografia não é apenas uma necessidade técnica, mas também legal para qualquer aplicação móvel que lide com dados de usuários.

Criptografia simétrica e assimétrica

Todos os algoritmos de criptografia se dividem em dois tipos principais: simétricos (uma chave para criptografar e descriptografar) e assimétricos (um par de chaves — pública e privada). A escolha do tipo depende do caso de uso: para criptografar dados locais, geralmente são usados algoritmos simétricos devido à sua velocidade, e para troca de chaves e autenticação, são usados os assimétricos.

Na prática, as aplicações móveis usam criptografia híbrida: com um algoritmo assimétrico (por exemplo, ECDH) as partes trocam uma chave de sessão, e todos os dados subsequentes são criptografados com um algoritmo simétrico (AES ou ChaCha20). Essa abordagem combina a velocidade da criptografia simétrica com a segurança da troca assimétrica de chaves. Este método é a base do TLS 1.3, Signal Protocol e Apple iMessage.

Principais algoritmos de criptografia

O desenvolvimento móvel moderno usa vários algoritmos de criptografia padronizados, cada um projetado para tarefas específicas com sua própria área de aplicação.

• AES (Advanced Encryption Standard) — cifra de bloco simétrica certificada pelo NIST em 2001. Usa chaves de 128, 192 ou 256 bits. O modo recomendado é GCM (Galois/Counter Mode), que fornece criptografia autenticada. O AES-256 é usado no Android Keystore, iOS Keychain e todos os protocolos TLS modernos.
• ChaCha20-Poly1305 — cifra de fluxo simétrica desenvolvida por Daniel Bernstein. Fornece o mesmo nível de segurança que o AES-256, mas funciona mais rápido em dispositivos sem aceleração de hardware AES (típico em smartphones Android de baixo custo). O ChaCha20 é usado no TLS 1.3 como alternativa ao AES-GCM e é a cifra principal no Signal Protocol.
• RSA (Rivest-Shamir-Adleman) — algoritmo assimétrico usado para criptografia de chaves e assinaturas digitais. O tamanho mínimo de chave recomendado é 2048 bits. O RSA é mais lento que o ECDH, por isso está sendo substituído pela criptografia de curva elíptica (ECC) em aplicações móveis modernas.
• ECDH (Elliptic Curve Diffie-Hellman) — protocolo assimétrico de troca de chaves baseado em curvas elípticas. Fornece Perfect Forward Secrecy e é usado por padrão no TLS 1.3. A curva Curve25519 (X25519) é a mais comum em aplicações móveis.

Como a criptografia protege os dados dos usuários

A criptografia protege os dados em três cenários principais: perda do dispositivo (criptografia de disco e contêineres do aplicativo), interceptação de tráfego (protocolos de rede TLS/HTTPS) e vazamento do servidor (criptografia de ponta a ponta). Cada cenário requer sua própria abordagem e ferramentas.

Dados em repouso e em trânsito

Os dados em repouso — dados no dispositivo — são criptografados via Android Keystore e iOS Keychain. No Android a partir da versão 7.0, é usada a criptografia baseada em arquivos (File-Based Encryption), e os aplicativos podem criptografar adicionalmente seus dados por meio de EncryptedSharedPreferences e EncryptedFile da biblioteca AndroidX Security. No iOS, todos os aplicativos funcionam por padrão com a Data Protection API, que criptografa arquivos no nível do sistema de arquivos com uma chave vinculada ao código do dispositivo. Para dados em trânsito, é usado TLS 1.2/1.3 com Certificate Pinning obrigatório.

Criptografia de ponta a ponta (End-to-End)

A criptografia de ponta a ponta (E2E) é o nível mais alto de proteção de dados, onde uma mensagem é criptografada no dispositivo do remetente e descriptografada apenas no dispositivo do destinatário. O servidor de armazenamento e transmissão não tem acesso ao conteúdo — ele apenas manipula blobs criptografados. A implementação E2E mais conhecida para aplicações móveis é o Signal Protocol, que usa o algoritmo Double Ratchet em combinação com X3DH (Extended Triple Diffie-Hellman) para a troca inicial de chaves. O Signal Protocol fornece Perfect Forward Secrecy e future secrecy: a comprometimento de uma chave não revela mensagens anteriores ou posteriores. De acordo com um estudo da Universidade Carnegie Mellon (2023), a criptografia E2E em aplicativos de mensagens reduz o risco de vazamento de comunicação em 99,7% em comparação com a criptografia apenas TLS. O uso de E2E é obrigatório para aplicativos das categorias Health & Fitness e Finance de acordo com os requisitos do GDPR e HIPAA. Para implementar E2E em seu próprio projeto, recomenda-se usar a biblioteca Signal Protocol (Java/Swift) ou baseada em Olm (Matrix protocol). Ao escolher uma solução E2E, avalie a compatibilidade com a plataforma: o Signal Protocol requer suporte para envio assíncrono e armazenamento de chaves no cliente, o que complica cenários com vários dispositivos — para tais casos, o Matrix Protocol com seu modelo de salas pode ser uma escolha melhor.

val masterKey = MasterKey.Builder(context)
    .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
    .build()

val encryptedFile = EncryptedFile.Builder(
    context,
    File(context.filesDir, "secret.dat"),
    masterKey,
    EncryptedFile.FileEncryptionScheme.AES256_GCM_HKDF_4KB
).build()

encryptedFile.openFileOutput(applicationContext).use { outputStream ->
    outputStream.write("Sensitive user data".toByteArray(Charsets.UTF_8))
}