Qué es un HSM y cómo protege la clave privada

Anatomía física de un HSM

Un HSM combina un procesador criptográfico, almacenamiento protegido e interfaces de acceso. Los mecanismos contra manipulación física, extracción y uso indebido varían según el modelo y el nivel validado; deben comprobarse en su política de seguridad.

Los componentes críticos incluyen:

• Procesador criptográfico: ejecuta los algoritmos admitidos por el módulo. El rendimiento depende del modelo, el algoritmo y el tamaño de clave.
• Generación aleatoria: combina fuentes de entropía y generadores aprobados para crear claves; el diseño se documenta y evalúa para cada módulo.
• Protección del material secreto: puede incluir detección de manipulación y borrado de claves. Su alcance depende del módulo validado.
• Interfaz controlada: operaciones de generación, firma y administración, con permisos y políticas. La exportación, cuando se permite, debe usar los mecanismos protegidos que define el equipo.

Existen HSM conectados por red, tarjetas internas y servicios administrados. La evaluación debe cubrir el módulo y también la autenticación, la administración y la recuperación del servicio.

FIPS 140: qué comprobar en la validación

FIPS 140 define requisitos para validar módulos criptográficos. FIPS 140-3 reemplazó a FIPS 140-2. La validación corresponde a un módulo y una versión concretos; no certifica por sí sola toda una plataforma de firma.

Para evaluar un servicio, solicite el número de certificado del módulo, la versión, el nivel de seguridad y su estado en el registro de NIST. En Argentina, los requisitos del certificador y su arquitectura aprobada deben verificarse además bajo la normativa local.

La tabla resume qué verificar; no sustituye la política de seguridad del módulo. Los mecanismos concretos, las áreas evaluadas y las condiciones de uso figuran en su certificado.

Según el calendario de NIST, las validaciones FIPS 140-2 pasaron a la lista histórica después del 21 de septiembre de 2026. Esa transición regula su aceptación en organismos federales de EE. UU. y Canadá; no revoca por sí sola un certificado de firma argentino. Para una nueva contratación, revise el módulo y la transición a FIPS 140-3.

Generación de claves dentro del HSM

En un flujo de generación interna, el módulo crea el par de claves y aplica la política que determina su uso, copia protegida y exportación. Este es un ejemplo simplificado; no todos los HSM usan la misma arquitectura.

1. Recolección de entropía

La generación requiere fuentes de entropía evaluadas y un generador criptográfico. No basta con llamar aleatorio a un dato: el diseño, las pruebas y la operación del módulo determinan su calidad.

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 recibe nueva entropía del TRNG periódicamente para renovar su estado interno.

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

Para RSA se generan primos y se construye el par de claves; para ECDSA se elige un escalar y se calcula el punto público. Los parámetros y pruebas deben seguir los estándares y algoritmos aprobados para el módulo.

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, porque 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

La operación de firma ocurre dentro del módulo

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)

Con una clave no exportable, el servidor utiliza el servicio sin recibirla en claro. Eso reduce el riesgo de extracción, pero no elimina el abuso de permisos ni las vulnerabilidades del módulo. La auditoría, los límites de uso y la respuesta a incidentes siguen siendo necesarios.

Imagine un notario que firma dentro de una bóveda. Usted le pasa el documento por una ranura y recibe el documento firmado. El sello permanece en manos del notario, dentro de la bóveda.

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.

Nuestro proveedor, certificador licenciado bajo el Ente Licenciante, opera una infraestructura PKI en Argentina que 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: ENCODE, Lakaut)
  ↓  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

Los ataques por tiempo, consumo o emanaciones pueden revelar información sobre una clave. Consulte qué contramedidas y evaluaciones cubre el módulo; un número de nivel no permite asumir resistencia frente a todo ataque.

Physical extraction

La extracción física incluye sondeo del chip y manipulación de sus componentes. La protección y la respuesta a apertura dependen de la construcción y del nivel físico validado; no todos los HSM incorporan los mismos sensores.

Fault injection

La inyección de fallas altera condiciones de operación para inducir errores. Deben revisarse las pruebas y límites del módulo; los requisitos de protección ambiental dependen del nivel validado.

Compromiso del sistema operativo

Si un atacante compromete el servidor y consigue permisos para solicitar firmas, puede abusar de la clave aunque no la extraiga. La respuesta puede exigir bloquear el acceso, investigar firmas y revocar el certificado. El HSM no reemplaza la autorización del firmante ni el monitoreo.

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 (Identik)
2. Plataforma calcula hash SHA-256 del documento
3. Plataforma solicita activación de clave al HSM
4. Servicio de firma requiere autorización del suscriptor:
   → Credenciales y factores habilitados por el certificador
5. Servicio valida la autorización y solicita la operación al HSM
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. Identik 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
});

En este flujo, la aplicación envía el hash al HSM y recibe la firma. La clave privada permanece dentro del perímetro 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:

La diferencia operativa es dónde está el dispositivo y cómo se autoriza su uso. La validez jurídica exige cumplir el conjunto de requisitos aplicables a la firma y al certificado; no se deduce únicamente de que la clave no sea exportable.

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: use los mecanismos protegidos de copia, envoltura de claves o replicación que admita el fabricante, con custodia separada y recuperación probada. No todos los equipos exigen el mismo soporte.
• 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, lo que 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.

Cómo protege el HSM la clave privada

El HSM reduce la exposición de claves en los sistemas que lo utilizan. Para evaluar una firma digital argentina también deben comprobarse la identidad, el certificado emitido por un certificador licenciado, la autorización y la verificación del documento.

En Identik, los certificados de firma digital argentina son emitidos por AC Digilogix S.A.. Namirial es el partner tecnológico. La plataforma organiza el proceso; el certificado y la arquitectura de custodia corresponden al servicio del certificador.