AES: o que é, algoritmo de criptografia simétrica e onde é usado

Tamanhos de chave AES e níveis de segurança

AES suporta três tamanhos de chave, cada um correspondendo a um nível específico de força criptográfica. A escolha do tamanho da chave afeta a segurança, o desempenho e os requisitos de recursos do dispositivo.

Regra prática: para aplicativos móveis use AES-256 por padrão. A diferença de desempenho entre AES-128 e AES-256 em dispositivos modernos com suporte AES-NI não é superior a 10–15%, mas o nível de segurança dobra. De acordo com a análise quântica (Grassl et al., 2016), quebrar o AES-128 exigiria 2^77 operações quânticas através do algoritmo de Grover, enquanto o AES-256 exigiria 2^149, tornando o AES-256 resistente a ataques quânticos pelos próximos 20–30 anos. Mesmo o AES-128 fornece proteção suficiente para a grande maioria dos cenários comerciais: a força bruta de uma chave de 128 bits exigiria mais energia do que existe no universo de acordo com a estimativa de Bruce Schneier. No entanto, os padrões de segurança (GDPR, HIPAA, PCI DSS) frequentemente exigem explicitamente AES-256, portanto, projetos em produção devem usar o comprimento máximo de chave.

Modos de operação AES

AES como cifra de bloco criptografa blocos de tamanho fixo (128 bits). Para criptografar dados de comprimento arbitrário, são usados modos de operação. A seleção do modo afeta criticamente a segurança: o modo errado pode anular a força do AES.

• ECB (Electronic Codebook) — o modo mais simples e mais inseguro. Cada bloco é criptografado independentemente com a mesma chave. Blocos de texto simples idênticos produzem blocos de texto cifrado idênticos, permitindo recuperar a estrutura dos dados. Proibido em todos os padrões de segurança modernos. NUNCA use ECB em aplicativos móveis.
• CBC (Cipher Block Chaining) — cada bloco de texto cifrado anterior é usado como vetor de inicialização (IV) para o próximo. Requer um IV aleatório para cada mensagem. Vulnerável a ataques de padding oracle quando implementado incorretamente. Adequado para criptografia de arquivos, mas requer MAC (HMAC) para integridade dos dados.
• GCM (Galois/Counter Mode) — o modo recomendado para aplicativos móveis. Fornece criptografia autenticada (AEAD): criptografia + verificação de integridade em uma única operação. Usa um contador para geração de fluxo de chave e multiplicação em campo de Galois para autenticação. GCM requer um nonce único (12 bytes) para cada mensagem. Recomendado pelo NIST, usado em TLS 1.2/1.3 e Android Keystore.
• CCM (Counter with CBC-MAC) — um modo AEAD alternativo baseado em CTR + CBC-MAC. Mais lento que GCM e não suporta processamento paralelo. Usado em protocolos ZigBee e 802.11 (Wi-Fi). Para aplicativos móveis, GCM é preferível.

Para projetos móveis use AES-256-GCM com um nonce de 12 bytes. GCM resolve dois problemas simultaneamente: criptografia de dados e autenticação, prevenindo ataques de padding oracle e chosen ciphertext. Android Keystore e iOS CryptoKit suportam AES-GCM nativamente sem necessidade de primitivas criptográficas adicionais. Ao trabalhar com GCM, é crítico nunca reutilizar o nonce com a mesma chave — isso destrói completamente a segurança da criptografia. Gere um novo nonce aleatório para cada criptografia e armazene-o junto com o texto cifrado.

Implementação de AES em aplicativos móveis

Vamos ver um exemplo de implementação segura de AES-256-GCM no Android usando Jetpack Security. O código abaixo demonstra o ciclo completo: criação de uma chave AES-256 via MasterKey, criptografia e descriptografia de uma string com dados autenticados adicionais (AAD).

import androidx.security.crypto.MasterKey
import androidx.security.crypto.EncryptedSharedPreferences

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

val securePrefs = EncryptedSharedPreferences.create(
    context,
    "secure_prefs",
    masterKey,
    EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
    EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
)

fun storeSecureData(key: String, value: String) {
    securePrefs.edit().putString(key, value).apply()
}

fun readSecureData(key: String): String? {
    return securePrefs.getString(key, null)
}

A principal característica desta solução é que o AES-256-GCM é usado em dois níveis: para criptografar pares chave-valor (PrefValueEncryptionScheme) e para proteger os nomes das chaves (PrefKeyEncryptionScheme usa AES-256-SIV, resistente à reutilização de nonce). O MasterKey é gerado usando o algoritmo AES-256-GCM e armazenado no Android Keystore, protegido por hardware em dispositivos com Trusted Execution Environment. Em dispositivos sem suporte de hardware (TEE), a chave é criptografada via Bouncy Castle, o que ainda é mais seguro que armazenar em SharedPreferences.

Para criptografia direta de grandes volumes de dados (por exemplo, imagens ou arquivos), use AES-256-GCM via EncryptedFile do AndroidX Security. Para exportação de chaves (por exemplo, para backup), use criptografia adicional com uma senha de usuário via PBKDF2 com 100000+ iterações.

AES no iOS via CryptoKit

No iOS, as operações AES são organizadas através do framework CryptoKit (Swift 5.0+). Uma chave AES-256 é criada via SymmetricKey(size: .bits256) e armazenada no Secure Enclave — um criptoprocessador de hardware isolado da CPU principal e do sistema operacional. O CryptoKit fornece duas implementações de AES: AES.GCM (recomendado) e AES.CBC (para compatibilidade com formatos legados). A criptografia é realizada através do método seal(), que recebe dados, chave e nonce (12 bytes), e retorna AES.GCM.SealedBox — uma estrutura contendo o texto cifrado e o tag de autenticação. A descriptografia é feita através de open(). A Apple recomenda fortemente não usar CommonCrypto diretamente: o CryptoKit seleciona automaticamente os parâmetros ideais, protege contra ataques de canal lateral e utiliza a aceleração de hardware AES-NI em processadores Apple Silicon. Em dispositivos com Secure Enclave, as chaves nunca saem do módulo de hardware, impedindo o roubo mesmo com comprometimento total do aplicativo. Para serialização de chaves, use o método withUnsafeBytes seguido de armazenamento no Keychain via SecItemAdd com o atributo kSecAttrAccessible = kSecAttrAccessibleWhenUnlockedThisDeviceOnly.