AES: qué es, algoritmo de cifrado simétrico y dónde se aplica

Tamaños de clave AES y niveles de seguridad

AES admite tres tamaños de clave, cada uno correspondiente a un nivel específico de fortaleza criptográfica. La elección del tamaño de clave afecta la seguridad, el rendimiento y los requisitos de recursos del dispositivo.

Regla práctica: para aplicaciones móviles use AES-256 por defecto. La diferencia de rendimiento entre AES-128 y AES-256 en dispositivos modernos con soporte AES-NI no supera el 10–15%, pero el nivel de seguridad se duplica. Según el análisis cuántico (Grassl et al., 2016), descifrar AES-128 requeriría 2^77 operaciones cuánticas mediante el algoritmo de Grover, mientras que AES-256 requeriría 2^149, lo que hace que AES-256 sea resistente a ataques cuánticos durante los próximos 20–30 años. Incluso AES-128 proporciona protección suficiente para la gran mayoría de escenarios comerciales: la fuerza bruta de una clave de 128 bits requeriría más energía de la que existe en el universo según la estimación de Bruce Schneier. Sin embargo, los estándares de seguridad (GDPR, HIPAA, PCI DSS) a menudo exigen explícitamente AES-256, por lo que los proyectos en producción deben usar la longitud de clave máxima.

Modos de operación AES

AES como cifrador de bloques cifra bloques de tamaño fijo (128 bits). Para cifrar datos de longitud arbitraria se utilizan modos de operación. La selección del modo afecta críticamente la seguridad: el modo incorrecto puede anular la fortaleza de AES.

• ECB (Electronic Codebook) — el modo más simple y más inseguro. Cada bloque se cifra independientemente con la misma clave. Bloques de texto plano idénticos producen bloques de texto cifrado idénticos, permitiendo recuperar la estructura de los datos. Prohibido en todos los estándares de seguridad modernos. NUNCA use ECB en aplicaciones móviles.
• CBC (Cipher Block Chaining) — cada bloque de texto cifrado anterior se usa como vector de inicialización (IV) para el siguiente. Requiere un IV aleatorio para cada mensaje. Vulnerable a ataques de padding oracle cuando se implementa incorrectamente. Adecuado para cifrado de archivos pero requiere MAC (HMAC) para la integridad de datos.
• GCM (Galois/Counter Mode) — el modo recomendado para aplicaciones móviles. Proporciona cifrado autenticado (AEAD): cifrado + verificación de integridad en una sola operación. Utiliza un contador para la generación de flujo de clave y multiplicación en campo de Galois para autenticación. GCM requiere un nonce único (12 bytes) para cada mensaje. Recomendado por NIST, usado en TLS 1.2/1.3 y Android Keystore.
• CCM (Counter with CBC-MAC) — un modo AEAD alternativo basado en CTR + CBC-MAC. Más lento que GCM y no soporta procesamiento en paralelo. Se utiliza en protocolos ZigBee y 802.11 (Wi-Fi). Para aplicaciones móviles, se prefiere GCM.

Para proyectos móviles use AES-256-GCM con un nonce de 12 bytes. GCM resuelve dos problemas simultáneamente: cifrado de datos y autenticación, previniendo ataques de padding oracle y chosen ciphertext. Android Keystore e iOS CryptoKit soportan AES-GCM de forma nativa sin necesidad de primitivas criptográficas adicionales. Al trabajar con GCM, es crítico no reutilizar nunca el nonce con la misma clave — esto destruye completamente la seguridad del cifrado. Genere un nuevo nonce aleatorio para cada cifrado y guárdelo junto con el texto cifrado.

Implementación de AES en aplicaciones móviles

Veamos un ejemplo de implementación segura de AES-256-GCM en Android usando Jetpack Security. El código siguiente demuestra el ciclo completo: creación de una clave AES-256 mediante MasterKey, cifrado y descifrado de una cadena con datos autenticados adicionales (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)
}

La característica clave de esta solución es que AES-256-GCM se usa en dos niveles: para cifrar pares clave-valor (PrefValueEncryptionScheme) y para proteger los nombres de las claves (PrefKeyEncryptionScheme usa AES-256-SIV, resistente a la reutilización de nonce). MasterKey se genera usando el algoritmo AES-256-GCM y se almacena en Android Keystore, protegido por hardware en dispositivos con Trusted Execution Environment. En dispositivos sin soporte de hardware (TEE), la clave se cifra mediante Bouncy Castle, lo que sigue siendo más seguro que almacenarla en SharedPreferences.

Para el cifrado directo de grandes volúmenes de datos (por ejemplo, imágenes o archivos), use AES-256-GCM mediante EncryptedFile de AndroidX Security. Para la exportación de claves (por ejemplo, para copia de seguridad), use cifrado adicional con una contraseña de usuario mediante PBKDF2 con 100000+ iteraciones.

AES en iOS mediante CryptoKit

En iOS, las operaciones AES se organizan a través del framework CryptoKit (Swift 5.0+). Una clave AES-256 se crea mediante SymmetricKey(size: .bits256) y se almacena en Secure Enclave — un criptoprocesador hardware aislado de la CPU principal y del sistema operativo. CryptoKit proporciona dos implementaciones de AES: AES.GCM (recomendado) y AES.CBC (para compatibilidad con formatos heredados). El cifrado se realiza mediante el método seal(), que toma datos, clave y nonce (12 bytes), y devuelve AES.GCM.SealedBox — una estructura que contiene el texto cifrado y la etiqueta de autenticación. El descifrado se realiza mediante open(). Apple recomienda encarecidamente no usar CommonCrypto directamente: CryptoKit selecciona automáticamente los parámetros óptimos, protege contra ataques de canal lateral y utiliza la aceleración hardware AES-NI en procesadores Apple Silicon. En dispositivos con Secure Enclave, las claves nunca salen del módulo hardware, evitando el robo incluso con una compromisión total de la aplicación. Para la serialización de claves, use el método withUnsafeBytes seguido de almacenamiento en Keychain mediante SecItemAdd con el atributo kSecAttrAccessible = kSecAttrAccessibleWhenUnlockedThisDeviceOnly.