Tema 19
La fortaleza matemática de un algoritmo sirve de poco si las claves se generan mal, se exponen en código fuente, se reutilizan sin control o se almacenan de forma insegura. En sistemas reales, buena parte de la seguridad depende más de la gestión correcta de claves que del algoritmo elegido sobre el papel.
En los temas anteriores vimos algoritmos, protocolos, certificados y autenticación. Sin embargo, toda esa estructura descansa sobre un activo extremadamente sensible: la clave. Si una clave privada, una clave de cifrado o un secreto compartido caen en manos equivocadas, el atacante puede leer, falsificar o suplantar sin necesidad de romper el algoritmo.
Por eso la gestión de claves no es un detalle administrativo. Es una disciplina central de la seguridad criptográfica aplicada.
La gestión de claves es el conjunto de procesos, controles y herramientas usados para administrar claves y secretos durante toda su vida útil. Esto incluye generación, distribución, almacenamiento, activación, rotación, respaldo, recuperación, revocación y destrucción segura.
No se trata solo de “guardar una clave”. Se trata de controlar quién puede usarla, para qué propósito, durante cuánto tiempo y bajo qué condiciones.
En criptografía moderna, el algoritmo suele ser público y ampliamente conocido. Lo que debe mantenerse protegido es la clave. Ese es justamente el principio de Kerckhoffs aplicado a sistemas reales.
Si la clave queda expuesta, el atacante puede aprovechar la fortaleza del propio sistema a su favor. Podrá descifrar mensajes, generar MAC válidos, firmar datos fraudulentos o hacerse pasar por una identidad legítima.
| Tipo | Uso | Sensibilidad |
|---|---|---|
| Clave simétrica | Cifrado o autenticación con secreto compartido | Muy alta |
| Clave privada | Firma, descifrado o autenticación asimétrica | Crítica |
| Clave pública | Verificación o cifrado hacia el titular | No secreta, pero debe validarse |
| API key o token | Acceso a servicios y plataformas | Alta |
| Secretos de aplicación | Integraciones, bases de datos, webhooks | Alta |
Una clave no existe simplemente como un valor estático. Tiene un ciclo de vida. Desde que se crea hasta que se destruye, atraviesa distintas etapas que deben ser controladas.
Perder visibilidad sobre cualquiera de estas etapas puede degradar seriamente la seguridad del sistema.
La seguridad comienza en la generación. Una clave predecible, demasiado corta o derivada de una fuente débil puede comprometer todo el esquema desde el inicio.
Las claves deben generarse usando fuentes de aleatoriedad adecuadas y mecanismos criptográficamente seguros. En especial para claves privadas, secretos maestros o material raíz, la calidad de la entropía es fundamental.
No todas las claves deben servir para todo. Una buena práctica esencial es separar claves por uso, entorno y sistema. La misma clave no debería reutilizarse simultáneamente para desarrollo y producción, ni para cifrado y autenticación, ni para servicios sin relación entre sí.
Esta separación reduce impacto en caso de compromiso y facilita rotaciones, auditorías y límites operativos.
Una vez generada, la clave debe llegar a quien corresponde sin quedar expuesta durante el proceso. Esa distribución puede ser uno de los puntos más delicados del sistema.
Enviar secretos por correo, chat informal, tickets sin protección o archivos planos compartidos es una práctica riesgosa. Los entornos maduros utilizan mecanismos de provisión controlados, cifrados y auditables.
Guardar una clave en texto plano dentro de un archivo de configuración, una variable incrustada en el código o una hoja compartida es uno de los errores más comunes. El almacenamiento debe minimizar exposición y restringir acceso a las entidades que realmente necesitan usar el secreto.
Esto implica controles de acceso, cifrado en reposo cuando corresponde, segregación de responsabilidades y reducción del número de copias existentes.
Un cofre de secretos, o secrets vault, es una herramienta diseñada para almacenar y entregar secretos de forma centralizada, controlada y auditable. En lugar de dispersar claves por archivos, scripts o repositorios, se concentran bajo políticas y permisos específicos.
Estos cofres suelen permitir control de acceso granular, registro de uso, rotación automatizada y entrega dinámica de credenciales o tokens.
Un HSM, Hardware Security Module, es un dispositivo especializado para generar, almacenar y usar claves criptográficas con fuertes garantías de aislamiento y resistencia física o lógica. Su objetivo es reducir al máximo la exposición del material secreto, especialmente de claves de alto valor.
En muchos casos, la clave nunca abandona el HSM en forma exportable. El sistema externo le pide operaciones, como firmar o descifrar, pero el material sensible permanece dentro del módulo.
Los HSM suelen justificarse cuando la clave protegida tiene valor especialmente alto, por ejemplo:
No todos los secretos requieren un HSM, pero para ciertos contextos es una medida muy relevante.
Aunque pueden complementarse, un cofre de secretos y un HSM no son exactamente lo mismo.
| Aspecto | Cofre de secretos | HSM |
|---|---|---|
| Función principal | Guardar y distribuir secretos | Proteger y operar con claves de alto valor |
| Forma | Software o servicio gestionado | Hardware especializado |
| Uso típico | Credenciales, tokens, secretos de apps | Firma, PKI, material raíz, operaciones críticas |
| Exportación de clave | Puede permitirse según política | Suele limitarse o prohibirse |
Una buena gestión de claves aplica el mismo principio de mínimo privilegio que cualquier otro control de seguridad. Solo deben acceder a una clave quienes realmente la necesitan y únicamente para el uso permitido.
Esto significa evitar secretos compartidos innecesariamente, reducir cuentas con acceso administrativo y separar roles de operación, auditoría y administración.
Rotar una clave significa reemplazarla por otra nueva según una política definida o ante un evento que lo justifique. El objetivo es limitar el tiempo de exposición acumulada y reducir impacto si el secreto fue comprometido sin ser detectado.
La rotación puede ser periódica, por incidente, por cambio operativo o por vencimiento del material criptográfico.
Rotar claves no siempre es tan simple como generar una nueva y borrar la anterior. Muchas veces hay sistemas dependientes, sesiones activas, datos cifrados previamente o integraciones que todavía esperan el secreto viejo.
Por eso la rotación requiere planificación, compatibilidad temporal, ventanas de transición y mecanismos para evitar interrupciones o pérdida de acceso a datos antiguos.
En sistemas bien diseñados, las claves tienen versión o identificador. Esto permite saber qué clave protegió qué dato, cuál está vigente, cuál está en retirada y cuál ya no debe usarse.
El versionado es especialmente importante cuando se cifran datos almacenados a largo plazo o cuando múltiples servicios deben coordinar el cambio de material criptográfico.
Proteger demasiado una clave al punto de volverla irrecuperable también puede ser un problema. Si una clave crítica se pierde sin respaldo adecuado, ciertos datos o servicios pueden quedar inutilizables de forma irreversible.
Por eso la gestión madura contempla respaldos seguros, custodia controlada, procedimientos de recuperación y medidas para equilibrar disponibilidad con confidencialidad.
Cuando una clave se considera comprometida, obsoleta o ya no autorizada, debe retirarse de circulación. En contextos asimétricos esto puede implicar revocar certificados; en secretos simétricos o tokens, implica invalidar su uso y reemplazarlos por nuevo material.
La revocación o retiro debe ser visible para los sistemas que dependen de esa clave. De lo contrario, podría seguir aceptándose material inseguro sin que los participantes lo adviertan.
La gestión de claves necesita trazabilidad: saber quién creó una clave, quién accedió, desde dónde, con qué propósito, cuándo se rotó y cuándo dejó de estar vigente. Sin trazabilidad, es muy difícil investigar incidentes o demostrar control operativo.
Por eso las soluciones maduras incorporan logs, alertas, aprobación de cambios y evidencia de uso o administración.
Este tema conecta con gran parte del curso:
Una arquitectura criptográfica sólida no termina al elegir buenos algoritmos o protocolos. Recién se vuelve realmente confiable cuando el material secreto se gobierna con procedimientos, herramientas y controles adecuados durante todo su ciclo de vida.
En el próximo tema cerraremos el curso analizando ataques criptográficos, errores de implementación, buenas prácticas globales y el panorama post-cuántico, donde muchas de estas decisiones vuelven a ponerse a prueba.