Qué es un HSM y por qué su clave privada nunca sale de él

Anatomía física de un HSM

Un HSM es un procesador criptográfico dedicado, diseñado para resistir manipulación física y lógica. No es un “servidor seguro” ni una “caja fuerte digital” en sentido metafórico: es literalmente una caja metálica con sensores de intrusión, mallas conductoras que detectan perforaciones, y circuitería que borra las claves ante cualquier intento de apertura no autorizada.

Los componentes críticos incluyen:

• Procesador criptográfico dedicado: ejecuta operaciones RSA, ECDSA, AES, SHA-2/SHA-3 por hardware, no por software. La velocidad típica es de 1.000 a 20.000 firmas RSA-2048 por segundo.
• Generador de números aleatorios verdaderos (TRNG): basado en ruido térmico o jitter de osciladores. No es un PRNG — la entropía proviene de fenómenos físicos.
• Almacenamiento tamper-responsive: la memoria que guarda las claves está conectada a baterías internas. Si un sensor detecta manipulación, la alimentación se corta y las claves se borran en microsegundos (zeroization).
• Interfaz controlada: el HSM solo expone una API criptográfica (PKCS#11, JCE/JCA, OpenSSL engine, Microsoft CNG). No hay forma de ejecutar código arbitrario ni de extraer material criptográfico por la interfaz.

Los fabricantes principales — Thales Luna, Entrust nShield, Utimaco SecurityServer — producen modelos en formato PCI-e (para insertar en un server) y network-attached (appliance de red). En ambos casos, el boundary criptográfico es el mismo: la clave no sale.

FIPS 140-2: los cuatro niveles explicados

FIPS 140-2 (Federal Information Processing Standard, publicado por NIST) define cuatro niveles de seguridad para módulos criptográficos. No es opcional — es el estándar que determina si un dispositivo puede usarse en infraestructura de clave pública seria.

Para firma digital bajo la Ley 25.506, el estándar de la industria es FIPS 140-2 Level 3. Esto significa que el HSM no solo resiste ataques físicos, sino que los detecta activamente y destruye las claves antes de que un atacante pueda extraerlas. Level 4 existe pero es extremadamente raro en aplicaciones civiles — agrega protección contra fault injection (variaciones de voltaje y temperatura diseñadas para forzar errores computacionales explotables).

La diferencia clave entre Level 2 y Level 3: en Level 2, el dispositivo muestra evidencia de que fue manipulado (sellos rotos, recubrimientos dañados). En Level 3, el dispositivo responde activamente — destruye las claves antes de que la manipulación tenga éxito.

NIST publicó FIPS 140-3 en 2019, que reemplaza gradualmente al 140-2. Los cambios principales incluyen alineación con ISO/IEC 19790:2012 y nuevos requisitos para side-channel resistance. Sin embargo, la mayoría de HSMs desplegados hoy todavía operan bajo certificaciones 140-2 Level 3, y eso es perfectamente válido.

Generación de claves dentro del HSM

La generación de un par de claves RSA o ECDSA dentro del HSM sigue un proceso específico que garantiza que la clave privada nunca exista fuera del boundary criptográfico:

1. Recolección de entropía

El TRNG del HSM muestrea ruido térmico de resistencias o jitter temporal de osciladores en anillo. Esta entropía se acumula en un pool interno. A diferencia de /dev/urandom en Linux (que mezcla entropía de software), el TRNG es puramente hardware.

2. Deterministic Random Bit Generator (DRBG)

La entropía pura alimenta un DRBG (típicamente CTR_DRBG según NIST SP 800-90A) que produce los bits necesarios para la generación de primos. El DRBG se re-seed periódicamente desde el TRNG para evitar degradación del estado interno.

3. Generación de primos (RSA) o selección de escalar (ECDSA)

Para RSA-2048, el HSM genera dos primos p y q de 1024 bits cada uno, verifica primalidad con Miller-Rabin (mínimo 64 iteraciones según FIPS 186-4), y calcula n = p × q. Para ECDSA P-256, selecciona un escalar aleatorio d en el rango [1, n-1] de la curva y calcula el punto público Q = d × G.

4. Almacenamiento interno

La clave privada se almacena en la memoria protegida del HSM, cifrada con una master key (KEK — Key Encryption Key) que a su vez está protegida por el mecanismo de quorum del HSM. La clave pública sí se exporta — es necesaria para generar el CSR (Certificate Signing Request) que se envía a la Autoridad Certificante.

TRNG (ruido térmico)
  ↓
Entropy Pool (acumulación)
  ↓
CTR_DRBG (NIST SP 800-90A)
  ↓
Generación de primos p, q (Miller-Rabin)
  ↓
n = p × q,  e = 65537,  d = e¹ mod λ(n)
  ↓
Clave privada → almacenamiento interno cifrado con KEK
Clave pública  → exportada para CSR

Por qué la clave privada NUNCA sale: la operación de firma ocurre adentro

Este es el punto central que diferencia un HSM de cualquier otra solución. Cuando un sistema necesita firmar un documento, no extrae la clave privada para usarla. En cambio, envía el hash del documento al HSM, y el HSM ejecuta la operación criptográfica internamente.

El flujo es:

1. La aplicación calcula el hash SHA-256 del documento: H = SHA256(documento)
2. Envía H al HSM a través de la interfaz PKCS#11 junto con el identificador de la clave privada (key handle)
3. El HSM verifica la autenticación y autorización del solicitante
4. El procesador criptográfico del HSM ejecuta S = H^d mod n (RSA) o el algoritmo ECDSA con la clave privada d
5. El HSM devuelve únicamente la firma S — la clave privada no sale en ningún momento
6. La aplicación incrusta S en el documento (PAdES, CAdES, XAdES según el formato)

Esto significa que incluso si un atacante compromete completamente el servidor de aplicación, no puede obtener la clave privada. Podría, en teoría, enviar hashes para firmar (si tiene credenciales válidas), pero nunca clonar la clave para usarla independientemente. Y la auditoría del HSM registraría cada operación.

Pensalo así: el HSM es como un notario que firma dentro de una bóveda. Vos le pasás el documento por una ranura, él lo firma adentro, y te devuelve el documento firmado. Nunca te da su sello para que firmes vos.

Infraestructura HSM para firma digital en Argentina

En el marco de la Ley 25.506, un certificador licenciado es la entidad autorizada por el Ente Licenciante (dependiente de la Jefatura de Gabinete) para emitir certificados de firma digital. Para obtener y mantener la licencia, el certificador debe demostrar que sus claves de CA (Certificate Authority) están protegidas en HSMs certificados FIPS 140-2 Level 3 o superior.

Digilogix, por ejemplo, opera como certificador licenciado desde 2015 bajo la Resolución N° 44 del Ente Licenciante. Su infraestructura PKI en Argentina incluye HSMs que protegen tanto las claves de la CA intermedia como las claves de los suscriptores que optan por firma remota (donde la clave del usuario también reside en el HSM del certificador).

La infraestructura sigue la jerarquía IFDRA (Infraestructura de Firma Digital de la República Argentina):

AC-RAÍZ (Ente Licenciante)
  ↓  firma el certificado de CA intermedia
Certificador Licenciado (ej: Digilogix, ENCODE)
  ↓  firma el certificado del suscriptor
Suscriptor (persona física o jurídica)
  ↓  firma documentos con su clave privada
Documento firmado digitalmente

Cada nivel de esta cadena tiene sus claves protegidas en HSM. La AC-RAÍZ tiene su propia ceremonia de claves (key ceremony) donde se genera el par de claves raíz en presencia de múltiples testigos, con quorum de smart cards para activación.

Vectores de ataque contra los que protege un HSM

Entender por qué se usa un HSM requiere entender qué pasa sin uno. Estos son los vectores de ataque relevantes:

Extracción de software (memory dump)

Si la clave privada está en un archivo PKCS#12 en disco (protegido con contraseña), un atacante con acceso root puede volcar la memoria del proceso que la usa, o copiar el archivo y hacer brute-force del password. Con un HSM, no hay archivo que copiar ni memoria de proceso que contenga la clave.

Side-channel attacks

Ataques como timing analysis, power analysis (SPA/DPA), o emanaciones electromagnéticas pueden revelar información sobre claves en procesadores estándar. Los HSMs FIPS 140-2 Level 3+ implementan contramedidas: operaciones en tiempo constante, ruido en el consumo eléctrico, y blindaje EM.

Physical extraction

Técnicas como micro-probing (conectar agujas a las pistas del chip), decapsulación química del die, o FIB (Focused Ion Beam) para rewiring. Los HSMs Level 3+ tienen mallas conductoras multi-capa, sensores de luz, voltaje y temperatura, y zeroization instantánea ante detección.

Fault injection

Variaciones intencionales de voltaje o clock glitching para forzar errores computacionales que filtren bits de la clave. Los HSMs Level 3 detectan condiciones anormales de voltaje y temperatura. Level 4 agrega protección activa contra estas técnicas.

Compromiso del sistema operativo

Un ransomware, rootkit o APT que comprometa el servidor completo. Con un software keystore, el atacante obtiene la clave. Con un HSM, obtiene la capacidad de solicitar firmas (si tiene credenciales), pero no la clave en sí. La primera condición es catastrófica (la clave debe revocarse). La segunda es seria pero contenible (se revocan las credenciales de acceso al HSM, la clave del suscriptor sigue segura).

Cómo funciona la firma remota con HSM

El modelo de firma remota es lo que permite que un usuario firme digitalmente desde cualquier dispositivo sin tener un token USB ni un smart card. La clave privada del suscriptor reside en el HSM del certificador licenciado, y el usuario la activa remotamente mediante autenticación multifactor.

1. Usuario sube documento a la plataforma (Simplisigner)
2. Plataforma calcula hash SHA-256 del documento
3. Plataforma solicita activación de clave al HSM
4. HSM requiere autenticación del suscriptor:
   → Factor 1: credenciales (usuario/contraseña o certificado TLS mutuo)
   → Factor 2: OTP vía app móvil, SMS o push notification
5. HSM verifica autenticación → activa clave privada del suscriptor
6. HSM ejecuta operación de firma: S = sign(H, key_privada)
7. HSM devuelve firma S a la plataforma
8. Plataforma incrusta firma + certificado + timestamp en el documento
9. Documento firmado disponible para descarga/envío

El punto crítico es el paso 6: la operación criptográfica ocurre dentro del HSM. La plataforma nunca ve, maneja ni almacena la clave privada. Simplisigner actúa como el intermediario que orquesta el flujo, pero la criptografía la ejecuta el hardware del certificador licenciado.

Ejemplo de código: solicitud de firma a nivel de API

A nivel de integración, una solicitud de firma remota típicamente se traduce en una llamada API REST al servicio del certificador. Este es un pseudocódigo representativo:

// 1. Calcular hash del documento
const documentBytes = await readFile('contrato.pdf');
const hash = crypto.createHash('sha256').update(documentBytes).digest('base64');

// 2. Solicitar firma al servicio de firma remota
const signatureRequest = {
  // Identificador del certificado del suscriptor en el HSM
  certificateId: "CN=Juan Perez,SERIALNUMBER=CUIL 20-12345678-9,O=Empresa SA",

  // Hash del documento a firmar (base64)
  documentHash: hash,

  // Algoritmo de firma
  signatureAlgorithm: "SHA256withRSA",  // o "SHA256withECDSA"

  // Formato de firma requerido
  signatureFormat: "PAdES",  // PAdES para PDF, CAdES para binario, XAdES para XML

  // Perfil de firma (con timestamp + cadena + revocación)
  signatureProfile: "PAdES-LTA",

  // Token de autenticación del suscriptor (ya autenticado con MFA)
  authToken: "Bearer eyJhbGciOiJSUzI1NiIs..."
};

// 3. POST al endpoint del certificador
const response = await fetch('https://firma.certificador.com.ar/api/v1/sign', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-API-Key': process.env.CERTIFICADOR_API_KEY
  },
  body: JSON.stringify(signatureRequest)
});

// 4. La respuesta contiene la firma (NO la clave privada)
const result = await response.json();
// result.signature = "MEUCIQD7..."  (firma en base64)
// result.certificate = "MIIFgTCC..."  (certificado del firmante)
// result.timestamp = "MIIJpQYJ..."  (sello de tiempo RFC 3161)
// result.ocspResponse = "MIIB0woB..."  (respuesta OCSP para revocación)

// 5. Incrustar firma en el PDF
const signedPdf = embedPAdESSignature(documentBytes, {
  signature: result.signature,
  certificate: result.certificate,
  timestamp: result.timestamp,
  ocspResponse: result.ocspResponse,
  certChain: result.certificateChain
});

Observe que en ningún momento del flujo aparece la clave privada. El hash entra al HSM, la firma sale. Eso es todo. La clave privada es un secreto que existe únicamente dentro del boundary criptográfico del hardware.

Comparación: software keystore vs. token USB vs. HSM

Las tres opciones para almacenar claves criptográficas tienen características radicalmente diferentes:

El token USB fue durante años la única opción práctica para firma digital. Cumple la Ley 25.506 porque la clave no es exportable. Pero tiene limitaciones operativas severas: requiere presencia física, no escala, y es fácil de perder (lo que implica revocar el certificado y empezar de cero).

El HSM resuelve estos problemas porque centraliza las claves de miles de suscriptores en un dispositivo de alta disponibilidad, permitiendo firma remota sin comprometer la seguridad. Es más caro por unidad, pero el costo se amortiza entre todos los suscriptores que atiende.

Consideraciones operativas

Operar un HSM no es plug-and-play. Requiere procedimientos específicos:

• Key ceremony: la generación de claves de CA requiere un ritual formal con múltiples participantes, cada uno con una smart card que contiene un fragmento (share) de la master key. Se necesita un quórum mínimo para activar el HSM (típicamente M-de-N, por ejemplo 3 de 5).
• Backup seguro: los HSMs permiten clonar claves a otro HSM del mismo modelo usando protocolos seguros. No se puede hacer backup a disco. Si se pierde el HSM y no hay clón, las claves se pierden para siempre.
• Actualización de firmware: las actualizaciones del firmware del HSM requieren autenticación del fabricante y del operador. Un firmware no firmado no se puede instalar — esto previene la inyección de código malicioso.
• Monitoreo continuo: temperatura, intentos de acceso fallidos, operaciones por segundo, estado de batería interna. Una alerta de batería baja es crítica — si la batería muere, las claves protegidas por tamper-response se borran.
• Fin de vida: cuando un HSM se retira de servicio, se ejecuta un procedimiento de destrucción de claves (zeroization) verificable. El certificador debe documentar esto ante el Ente Licenciante.

Conclusión: el HSM es el foundation de la firma digital

Sin un HSM, no hay garantía de que la clave privada no fue copiada, exportada o comprometida. Y sin esa garantía, la presunción de autoría e integridad que establece el Artículo 7 de la Ley 25.506 se debilita. El HSM no es un lujo de seguridad — es el requisito técnico que sustenta la validez legal de la firma digital en Argentina.

Cuando un certificador licenciado le dice que su clave está “protegida en un HSM”, lo que está diciendo es: su clave privada nació dentro de un procesador criptográfico certificado FIPS 140-2 Level 3, nunca va a salir de ahí, y cada operación de firma se ejecuta dentro de ese hardware con autenticación multifactor y auditoría completa. Eso es lo que separa la firma digital de cualquier otra forma de firma electrónica.