Key management del issuer — el corazón de la seguridad
Toda la seguridad del sistema SSI se reduce a una cosa: la clave privada del issuer. Si esa clave se compromete, cualquier credencial puede ser falsificada. Si se pierde, ninguna credencial nueva puede ser emitida.
Para un sistema gov, key management del issuer no es detalle técnico — es la decisión más crítica de seguridad. Esta guía cubre las prácticas operativas.
El stack de protección
Una clave privada de issuer gob debe estar protegida en múltiples capas:
Capa 1: Hardware Security Module (HSM)
La clave vive físicamente en un HSM. Nunca se exporta. Operaciones criptográficas suceden dentro del HSM. Compromise del servidor no expone la clave.
Capa 2: Control de acceso
Solo personal autorizado puede iniciar operaciones de firma. Multi-factor authentication + biométrica.
Capa 3: Procesos auditables
Cada operación con la clave queda logged. Reviewable por audit team y reguladores.
Capa 4: Continuidad de negocio
Backup seguro de la clave (en HSM secundario, vault físico, etc.) para casos de pérdida del HSM principal.
El HSM — Hardware Security Module
Un HSM es un dispositivo de hardware especializado para operaciones criptográficas. Sus propiedades:
- Claves no-exportables. La clave privada genera dentro del HSM y nunca sale.
- Tamper-resistant. Físicamente protegido contra intentos de extracción.
- Performance optimizado. Operaciones criptográficas rápidas a escala.
- Audited. HSMs gov-grade pasan certificaciones FIPS 140-2/3, Common Criteria, ANSI.
Tipos de HSM:
| Tipo | Costo aproximado | Uso típico |
|---|---|---|
| Cloud HSM | Por mes / por operación | AWS CloudHSM, Azure Key Vault HSM |
| Network HSM | $50k-200k inicial | Thales Luna, Utimaco |
| USB HSM | $50-500 | YubiHSM, otros pequeños |
| TPM en servidor | Built-in | Trust Platform Module |
Para un issuer gob serio: Network HSM (alta gama) o Cloud HSM (más práctico, igual de seguro).
Generación de la clave
Cómo se genera la clave de un issuer:
- 1Ceremonia de generación. Múltiples roles (CISO + arquitecto + auditor) presentes. Documentado.
- 2Algoritmo: Ed25519 default. ECDSA P-256 si requisitos regulatorios específicos.
- 3Generación dentro del HSM. La clave nunca existe fuera del HSM.
- 4Verificación de propiedades. Confirmar que la clave pública corresponde al HSM esperado.
- 5Backup de la clave. Si se permite (HSM ceremoniales), se hace en HSM secundario o se distribuye en partes (key sharing).
Sin ceremonia documentada, no hay garantía de que la clave fue generada correctamente.
Rotación de claves
Una práctica esencial: rotar claves periódicamente para limitar el impacto de un compromiso hipotético.
| Tipo de clave | Frecuencia recomendada |
|---|---|
| Issuer master | Cada 2-3 años (con ceremonia) |
| Issuer operational | Cada 6 meses a 1 año |
| Token / session | Por cada operación |
La rotación requiere:
- Generar nueva clave en HSM.
- Publicar nueva clave pública en el DID Document.
- Mantener clave anterior por período de transición (para verificar credenciales emitidas con ella).
- Finalmente decommissioning de la clave anterior.
El plan de continuidad
¿Qué hace el issuer si el HSM se rompe? Tres scenarios y respuestas:
HSM con falla pero recuperable
Reemplazar hardware, restaurar desde backup encriptado. Servicio interrumpido temporariamente.
HSM destruido sin backup
Catastrófico. La clave es irrecuperable. Re-emitir todas las credenciales con clave nueva.
HSM comprometido (clave robada)
Revocar todas las credenciales emitidas con esa clave. Emitir nuevas. Costo operativo masivo.
Para evitar el segundo y tercer scenario, backup criptográficamente seguro es obligatorio + plan de respuesta a incidentes documentado.
Key sharing — distribución de la clave
Para casos críticos, dividir la clave entre múltiples custodios:
- Algoritmo: Shamir's Secret Sharing.
- División típica: 3-de-5 o 5-de-9 (necesitan 3 o 5 partes para reconstruir).
- Cada parte se guarda en custodio diferente (físico, geográfico, organizacional).
- Reconstitución requiere coordinación entre custodios.
Esto distribuye el riesgo: ninguno solo puede comprometer; todos juntos pueden recuperar.
Auditoría de operaciones
Cada operación con la clave debe ser:
- 1Loggeada. Timestamp + operador + operación + resultado.
- 2Verificable. Logs criptográficamente protegidos contra tampering.
- 3Auditable por terceros. Audit team externo puede revisar.
- 4Retenidos. Por períodos regulatorios (LPDP, ley de archivo público).
- 5Anonimizados cuando aplique. Sin exposición de datos personales en logs.
La ceremonia de cumpleaños
Una práctica especial: ceremony of birthday — celebrar y documentar la generación de cada clave master.
Por qué importa:
- Demuestra que la clave existió desde un momento específico.
- Crea trazabilidad para audit.
- Genera buena cultura de seguridad.
En proyectos gov maduros, estos ceremonies son documentados con video + presencia de testigos externos.
El stack típico
Una implementación de issuer gov típica:
Cloud HSM (AWS / Azure / Google) - 99.99% SLA
↓
Issuer Application (servidor gob)
↓
DID Document publicado vía did:web
↓
Credenciales emitidas firmadas por el HSM
Cada operación es:
- App pide al HSM "firma esto".
- HSM autentica al app (mutual TLS + API key).
- HSM ejecuta firma internamente.
- Devuelve firma sin exponer clave.
Referencias
- NIST SP 800-57 — Key Management Recommendations
- FIPS 140-2/3 — Cryptographic Module Validation
- HashiCorp Vault
Relacionados
- Firmas digitales en 5 minutos — el contexto criptográfico
- Audit trail y compliance — trazabilidad sin tracking — el siguiente nivel