El cifrado casi nunca se rompe mediante un ataque directo al algoritmo. Con más frecuencia se vulnera la clave, su emisión, almacenamiento, permisos de acceso o la lógica de intercambio. Por eso «clave de cifrado» no es una cadena abstracta de bytes, sino todo el ciclo de vida desde la generación hasta la destrucción, con reglas, roles y rotación.
Qué es una clave de cifrado y qué tipos existen
Una clave de cifrado es un parámetro secreto que controla la transformación de los datos. El mismo algoritmo con distintas claves produce resultados diferentes, y sin la clave correcta recuperar los datos originales es prácticamente imposible. Es importante recordar que la clave es un secreto, no una «contraseña en un fichero de configuración». No se debe copiar ni almacenar donde sea por conveniencia.
La clasificación más básica distingue claves simétricas y asimétricas. La clave simétrica es la misma para cifrar y descifrar. Es rápida y por eso se usa casi siempre para grandes volúmenes de datos. La pareja asimétrica consiste en una clave pública y una privada. Con la pública se puede cifrar o verificar firmas, y con la privada se puede descifrar o firmar.
Además de las claves para cifrar datos existen claves para firma, autenticación, derivación, envoltura de claves y claves de sesión. Esta clasificación es más útil que los nombres de algoritmos, porque ayuda a diseñar correctamente el esquema y los permisos de acceso.
En la práctica casi siempre encontrará un modelo con varios niveles de claves. Hay una clave de larga vida que se protege con máxima rigidez, y claves de corta vida con las que realmente se cifran datos o tráfico. Este enfoque se conoce como «cifrado en sobre» en los proveedores de KMS en la nube, donde la clave de datos se cifra con una clave maestra de nivel superior.
- Clave de cifrado de datos (DEK) - clave de corta vida para un objeto, archivo o sesión concreta.
- Clave de cifrado de claves (KEK) - clave con la que se «envuelve» la DEK.
- Clave de sesión - clave válida únicamente durante una sesión, por ejemplo en TLS.
- Clave de firma - clave para crear una firma digital, normalmente asimétrica.
- Clave de derivación (master) - entrada para una función KDF, de la cual se obtienen claves de trabajo según el contexto.
Longitud de la clave y «resistencia»
La longitud de la clave no es el único factor de seguridad, pero marca el límite inferior para los ataques por fuerza bruta. Para algoritmos simétricos una clave de 128 bits ya ofrece un margen enorme para la mayoría de escenarios, y 256 bits se elige con frecuencia como opción universal con reserva para el futuro. Para AES son habituales claves de 128, 192 o 256 bits, según lo establecido en la especificación oficial del estándar.
La criptografía asimétrica se rige por otra matemática. Ahí la «longitud en bits» no se compara directamente con la simétrica. Por eso es más correcto hablar del nivel objetivo de resistencia y luego elegir el algoritmo y los parámetros. En las recomendaciones del NIST sobre gestión de claves se usa el concepto de security strength y niveles discretos como 112, 128, 192 y 256 bits.
En la elección de la longitud influyen la vida útil de la clave, el valor de los datos y el riesgo de compromiso. Si una clave vive mucho tiempo y protege muchos datos, cualquier fuga es una catástrofe. Si la clave es de corta vida y está ligada al contexto, las consecuencias se localizan. Por eso un esquema bien diseñado suele ser más importante que la carrera por «los números más grandes».
Otro error típico es confundir la clave con los parámetros del modo de operación. Por ejemplo, en modos AEAD como GCM no importa solo la clave, sino también la unicidad del nonce o IV. En OpenSSL se indica que para AES-GCM hay valores por defecto para la longitud del IV y que puede ajustarse, pero lo relevante no es la «magia de la longitud», sino el uso correcto del modo y evitar repeticiones.
| Qué elegir | Para qué | Orientación práctica |
|---|---|---|
| Clave simétrica | Cifrado de datos y flujos | AES-128 o AES-256 según NIST |
| Par pública y privada | Firma, intercambio de claves, identidad | La elección depende del protocolo y la política; como orientación, atender al nivel objetivo de resistencia |
| Clave de envoltura | Protección de claves de datos | Usar cifrado en sobre en un KMS |
Intercambio de claves. Cómo surge el secreto compartido
El principal problema de la simetría es sencillo. Las partes necesitan un secreto compartido, pero no se puede transmitir por la red sin riesgo de interceptación. Por eso el intercambio se resuelve con asimetría o con protocolos de establecimiento de secreto compartido, y luego se cifra el tráfico con simetría.
El ejemplo más extendido es TLS. En TLS 1.3 el protocolo está diseñado para que la sesión se base en Diffie–Hellman, normalmente en su variante ECDHE, para obtener secreto perfecto hacia adelante. La idea es que el compromiso de la clave de larga vida del servidor no debe revelar automáticamente sesiones antiguas. La especificación de TLS 1.3 describe el esquema y los requisitos a nivel de estándar.
Tras obtener el secreto compartido no se puede «usar directamente como clave». El secreto debe transformarse en un conjunto de claves con la longitud y el propósito adecuados, y además vincularse al contexto de la sesión. Para esto se usan funciones de derivación de claves. En protocolos modernos es frecuente HKDF, que está descrito formalmente en un RFC y ofrece el modelo «extract and expand».
Una categoría aparte son las claves derivadas de contraseñas. Una contraseña rara vez sirve como clave criptográfica, porque suele ser predecible y tener poca entropía. Por eso se aplican KDF con coste en tiempo y memoria para encarecer los ataques por fuerza bruta. Históricamente se ha usado mucho PBKDF2, descrito en un RFC y empleado como opción básica compatible.
- Acordar un secreto compartido mediante ECDHE o usar un secreto compartido previamente.
- Pasar el secreto por una KDF para obtener claves de trabajo para cifrado e integridad.
- Separar las claves por finalidad, por ejemplo una para cifrado y otra para autenticación.
- Establecer una duración clara de la sesión y condiciones para regenerar las claves.
Gestión, almacenamiento y rotación. Donde realmente se pierden las claves
La gestión de claves es política e infraestructura. Quién tiene derecho a crear claves, quién puede cifrar, quién puede descifrar, dónde se audita, cómo se realiza la rotación y cómo se retiran las claves. El NIST en sus recomendaciones de key management insiste en procesos y roles, no solo en algoritmos.
En la infraestructura las claves no deben residir en código fuente, variables de entorno ni carpetas compartidas. Para ello se usan KMS y HSM. KMS ofrece políticas centralizadas y auditoría, y HSM aísla las operaciones con la clave dentro de un módulo criptográfico. Si se necesita cumplimiento formal, se atiende a los requisitos para módulos criptográficos descritos en FIPS 140-3.
El cifrado en sobre ayuda a escalar la seguridad. Se genera una clave de datos única por objeto, se cifran los datos con ella y luego se cifra la propia clave de datos con una clave de nivel superior. Este mecanismo lo detallan los proveedores en la nube y permite limitar el acceso al descifrado mediante la política del KMS sin tocar los datos en sí.
La rotación debe planificarse. El periodo criptográfico depende del tipo de clave y de las amenazas. Cuantos más datos cifre una misma clave y cuanto más tiempo permanezca válida, mayor será el coste de una filtración. En las recomendaciones del NIST se discuten los plazos de uso y conservación del material clave. En la práctica se traduce en una regla simple: rote las claves de nivel superior según un calendario y mantenga las claves de datos efímeras o de muy corta vida.
Para sistemas aplicados conviene usar mecanismos de protección de secretos ya disponibles en la plataforma. En Windows, por ejemplo, se puede usar DPAPI mediante las API del sistema y .NET, para no inventar un almacenamiento propio en la aplicación. Para criptografía de servicios resultan cómodas soluciones como el Transit Engine de Vault, donde la aplicación envía datos para cifrar y las claves y políticas viven por separado.
- Almacene las claves en KMS o HSM; conceda acceso con los mínimos permisos necesarios.
- Separe los permisos de «cifrar» y «descifrar» para reducir el riesgo de fugas silenciosas.
- Registre las operaciones con claves e incluya auditoría de eventos.
- Haga que las claves de datos sean de corta vida y use las de larga vida solo como KEK.
- Compruebe que nonce e IV no se repiten donde sea crítico para el modo de operación.
En resumen, la fiabilidad del esquema suele depender de la disciplina. La generación de claves debe ser criptográficamente segura, el intercambio debe ser protocolario, el almacenamiento debe ser centralizado y la rotación debe ser regular. Así la «clave de cifrado de datos» deja de ser un punto débil y pasa a ser un activo de seguridad gestionable.
