HSM y KMS: donde viven realmente las claves
Los HSM y los KMS son los sistemas donde residen las claves criptográficas que sostienen la seguridad de una organización. Resuelven el problema de almacenar secretos de alto valor sin exponerlos al sistema operativo ni a quien opera la aplicación. Son la pieza invisible sobre la que se apoyan la PKI, el firmado de tokens y la cifra de datos en reposo.
Este artículo forma parte de la serie La evolución de la seguridad en aplicaciones modernas.
Durante años la pregunta “dónde está la clave privada” ha tenido respuestas incómodas: en un archivo .pem dentro de la imagen del contenedor, en una variable de entorno del pipeline, en un gestor de secretos compartido entre decenas de servicios, o en el peor caso, commiteada por error en un repositorio. La criptografía asimétrica del mundo real vive y muere por la protección de la clave privada, y cualquier esquema que permita leerla desde fuera del componente que la usa es, en la práctica, un esquema comprometido. Los HSM y los KMS nacen para romper esa premisa: la clave nunca sale del contenedor criptográfico, solo salen los resultados de operaciones hechas con ella.
Por qué mover las claves fuera del proceso
Una clave privada en memoria de un proceso está expuesta a cualquier cosa que pueda leer ese proceso: un volcado de memoria, un debugger, una vulnerabilidad de lectura arbitraria, un operador con acceso al host. Peor aún, una clave en disco cifrado “en reposo” deja de estarlo en cuanto el proceso la carga, y una vez cargada no hay forma práctica de auditar quién la usa ni cuándo.
El modelo HSM (Hardware Security Module) rompe ese acoplamiento con una frontera física o lógica: la clave se genera dentro del módulo, nunca se exporta en claro, y las operaciones criptográficas (firma, descifrado, derivación) se delegan al módulo vía una API. El software que “usa” la clave no la ve nunca, solo envía datos a firmar y recibe firmas. Esa distinción, aparentemente burocrática, cambia radicalmente el modelo de amenaza: robar la aplicación no equivale a robar la clave.
El modelo KMS (Key Management Service) extiende esa idea al mundo gestionado en la nube. En lugar de operar un dispositivo, el proveedor cloud ofrece una API que hace las mismas operaciones, respaldada por HSM físicos en sus centros de datos. La clave se convierte en un identificador (ARN, resource name) y en un conjunto de políticas IAM que controlan quién puede pedir operaciones sobre ella.
Cómo funciona un HSM físico
Un HSM es un dispositivo, típicamente una tarjeta PCIe, un appliance de red o un token USB, certificado contra estándares como FIPS 140-2 y su sucesor FIPS 140-3 (niveles 1 a 4, siendo 4 el más exigente, con detección activa de manipulación física que cero-iza las claves ante cualquier intrusión) y Common Criteria EAL4+. Fabricantes históricos como Thales (Luna, ProtectServer), Utimaco, Entrust nShield (antes nCipher) y YubiHSM cubren el espectro desde tokens de unos pocos cientos de euros hasta appliances de decenas de miles.
La interfaz estándar para hablar con un HSM es PKCS#11, también llamada Cryptoki, una API en C que modela objetos (claves, certificados, datos) dentro de “slots” y “tokens”. Sobre ella se construyen integraciones con OpenSSL (mediante engines o providers), Java (JCA/JCE con SunPKCS11), y motores de bases de datos o servidores web. Algunos fabricantes ofrecen interfaces adicionales: KMIP (Key Management Interoperability Protocol) para gestión remota, o APIs REST propietarias.
Dentro del HSM las claves se organizan en jerarquías. Hay una Root Key o master key, a menudo respaldada por tarjetas de operador con esquemas de m-de-n (tres de cinco custodios presentes para recuperar una clave), bajo la cual viven claves de cifrado de claves (KEK, Key Encryption Key) y, bajo estas, las claves de datos (DEK, Data Encryption Key). Esta jerarquía permite que las DEK puedan cifrarse con una KEK y almacenarse fuera del HSM sin perder seguridad: para usarlas hay que desenvolverlas dentro del módulo.
Cómo funciona un KMS gestionado
AWS KMS, Google Cloud KMS y Azure Key Vault implementan el mismo patrón en forma de servicio. La diferencia principal con un HSM operado es que la carga operativa (provisión, parches, alta disponibilidad, respaldo) la asume el proveedor, y la interfaz es HTTPS con autenticación IAM en lugar de PKCS#11.
El concepto clave es el envelope encryption. En lugar de cifrar un objeto de 10 GB llamando 10 millones de veces al KMS, la aplicación pide al KMS que genere una DEK, cifra los datos localmente con esa DEK, y almacena junto al objeto la versión de la DEK envuelta por una KEK que vive dentro del KMS. Para descifrar, pide al KMS que desenvuelva la DEK (una sola llamada), descifra localmente, y descarta la DEK en memoria. Así se combinan el rendimiento de la cifra simétrica local con el control de acceso y la auditoría del KMS.
Las tres plataformas añaden variantes según el nivel de aislamiento. AWS KMS ofrece claves multi-tenant estándar y CloudHSM para instancias dedicadas bajo control exclusivo. GCP Cloud KMS distingue Software, HSM y External Key Manager (EKM), este último permitiendo que la KEK resida en un HSM externo al cloud y GCP solo la invoque vía API. Azure separa Key Vault Standard (software), Premium (HSM multi-tenant) y Managed HSM (single-tenant FIPS 140-3 nivel 3). El esquema BYOK (Bring Your Own Key) y su variante más estricta HYOK (Hold Your Own Key) permiten aportar material de clave generado fuera del cloud, útil cuando la regulación exige que la generación ocurra bajo control del cliente.
Integraciones que importan
Una CA (Certification Authority) sin HSM es una CA que no pasa ninguna auditoría seria. La clave raíz de una PKI corporativa vive en un HSM offline, la clave de la subCA emisora en un HSM online con políticas estrictas, y las claves de servidores TLS generadas por PKI se firman contra ese HSM. El mismo patrón aplica al firmado de JSON Web Token: el IdP que emite tokens puede delegar la operación de firma a KMS (AWS KMS Sign, GCP asymmetricSign) de modo que la clave privada del JWT nunca esté en la memoria del servicio de emisión.
En el mundo de las identidades de carga, SPIFFE y SPIRE soporta backends HSM para la clave raíz de la trust domain, y los agentes pueden almacenar las claves de SVID en TPMs locales. Los gestores de secretos modernos, cubiertos en Gestión de secretos, usan KMS como root of trust para sus propias operaciones de cifra internas. Incluso el cifrado de volúmenes (EBS, Persistent Disk, Managed Disk) se apoya en KMS vía envelope encryption transparente.
Una clave en KMS con política IAM laxa no es más segura que una clave en un archivo. El valor del KMS está en la combinación de aislamiento criptográfico y control de acceso granular, no en uno solo de los dos.
Cuándo basta un KMS cloud
Para la mayoría de aplicaciones SaaS que viven enteramente en un proveedor cloud, un KMS gestionado cubre el caso de uso con diferencia mejor coste-beneficio que un HSM operado. La clave está en un entorno certificado FIPS 140-2 nivel 2 o 3 según el servicio, las operaciones se auditan en CloudTrail/Cloud Audit Logs, la rotación es automática, y la integración con el resto del stack (S3, RDS, Secrets Manager) es nativa.
El coste operativo de un HSM físico (redundancia, actualizaciones de firmware, tarjetas de operador, planes de recuperación) rara vez se justifica si el único requisito es “no tener la clave en un archivo”. Para eso, KMS con política IAM restrictiva y logging sobra.
Cuándo exiges HSM dedicado o externo
Hay tres escenarios donde un KMS multi-tenant del cloud no encaja. El primero es regulatorio: sectores como el financiero (PCI DSS para claves PIN, requisitos de bancos centrales), el sanitario en ciertas jurisdicciones, o infraestructuras críticas exigen control físico o al menos aislamiento single-tenant certificado FIPS 140-3 nivel 3 o superior. Managed HSM de Azure, CloudHSM de AWS o Cloud HSM de GCP cubren este escenario sin salir del cloud.
El segundo es soberanía y data residency extrema: una organización que no acepta que la KEK esté bajo control operativo del proveedor cloud. Aquí entra EKM (External Key Manager) y esquemas HYOK: la KEK vive en un HSM on-premise o en un proveedor externo, y el cloud hace llamadas a ese HSM para operaciones criptográficas. Latencia, disponibilidad y coste suben significativamente, pero el cloud no puede descifrar los datos si pierde el acceso al HSM externo.
El tercero es operación on-premise pura: cuando la aplicación no vive en un cloud público, el HSM sigue siendo la referencia. Tokens USB como YubiHSM para entornos pequeños, appliances de red Thales o Entrust para corporativo, integrados vía PKCS#11 con el software que los necesita.
El rendimiento de un HSM se mide en operaciones por segundo. Un appliance de gama media hace unos pocos miles de firmas RSA-2048 por segundo. Si tu aplicación necesita más, necesitas clúster o necesitas KMS cloud.
Post-quantum en el horizonte
La transición a algoritmos post-cuánticos no es teórica. NIST publicó en agosto de 2024 las primeras especificaciones FIPS 203 (ML-KEM, antes Kyber), FIPS 204 (ML-DSA, antes Dilithium) y FIPS 205 (SLH-DSA, antes SPHINCS+). Los fabricantes de HSM están añadiendo soporte de forma progresiva, y los KMS cloud han empezado a anunciar disponibilidad de firmas híbridas clásico+PQC. El planteamiento de “harvest now, decrypt later” hace que las claves de cifra de datos sensibles con vida útil larga sean las primeras candidatas a migrar.
Encaje en el ecosistema
HSM y KMS son la base sobre la que descansan casi todas las demás piezas. PKI los usa para las CA. JSON Web Token y OpenID Connect los usan para firmar tokens. mTLS los usa para las claves de servidor y cliente. Gestión de secretos los usa como raíz de confianza. Cloud Workload Identity se apoya en ellos para firmar las aserciones que prueban identidad de las cargas. No se ven directamente en la arquitectura que dibujas en una pizarra, pero si los quitas, todo lo demás pierde sus garantías.
Artículos relacionados en esta serie
Referencias
- NIST (marzo 2019). FIPS 140-3. Security Requirements for Cryptographic Modules.
- OASIS (2015). PKCS #11 Cryptographic Token Interface Base Specification Version 2.40.
- NIST (agosto 2024). FIPS 203. Module-Lattice-Based Key-Encapsulation Mechanism Standard.
- NIST (agosto 2024). FIPS 204. Module-Lattice-Based Digital Signature Standard.
- AWS (2024). AWS Key Management Service Developer Guide.
- Google Cloud (2024). Cloud KMS and External Key Manager documentation.