Hay una verdad incómoda en seguridad que casi nunca se planifica: todo el cifrado que despliegas hoy tendrá que cambiar en algún momento. No es una hipótesis, es historia repetida. Algoritmos que parecían sólidos, como MD5, SHA-1, RSA con claves cortas, acabaron retirados, y cada retirada pilló a alguien sin estar preparado. La pregunta relevante, por tanto, no es si tendrás que cambiar de cifrado, sino si podrás hacerlo sin parar el servicio cuando llegue el momento.
A esa capacidad la llamamos criptoagilidad: la capacidad de una infraestructura, y muy en particular de tu infraestructura de clave pública (PKI), para adoptar nuevos conjuntos de cifrado de manera dinámica, ordenada y sin disrupción. Es, esencialmente, una propiedad de diseño. Y, como toda propiedad de diseño, se decide mucho antes de necesitarla.
Conviene ser claros sobre de dónde venimos. En el primer número de IronSights ya dibujamos el panorama: por qué la ciberseguridad poscuántica y posagéntica obliga a inventariar las dependencias críticas. Pero allí la criptoagilidad asomaba solo de pasada, casi como una palabra suelta. Este artículo no repite aquel diagnóstico: se detiene a propósito en ese concepto concreto, porque es la pieza que convierte aquel inventario en capacidad real de actuar. Y no va aislado: forma parte del mismo hilo que recorre todo lo que publicamos este mes, la idea de que las decisiones técnicas que envejecen bien son las que te dejan cambiar sin tener que rehacerlo todo. La criptoagilidad es esa misma idea aplicada al cifrado.
Por qué ahora: del «si» al «cómo»
El contexto que hace urgente todo esto ya lo contamos en el número anterior, así que no nos repetimos: en agosto de 2024 el NIST publicó los primeros estándares poscuánticos (FIPS 203, 204 y 205) y el reloj del «harvest now, decrypt later» (capturar hoy tráfico cifrado para descifrarlo mañana) ya corre para cualquier dato que deba seguir siendo confidencial dentro de diez o quince años.
Lo que cambia al tener los estándares sobre la mesa es la pregunta. Ya no es si habrá que migrar, sino cómo. Y resulta que el cuello de botella casi nunca es el algoritmo nuevo, sino si tu infraestructura puede adoptarlo sin pararse. Porque la transición criptográfica no es un evento: es un proceso de años en organizaciones medianas y grandes, y «ya migraremos cuando toque» falla porque, cuando toque, no habrá tiempo. La única forma de afrontar un proceso largo es que la infraestructura sea ágil desde antes de empezarlo. Ahí entra la criptoagilidad.
Dónde se esconde la rigidez
El obstáculo para cambiar de cifrado casi nunca es el algoritmo nuevo. Es la rigidez acumulada en sistemas que se diseñaron asumiendo que el cifrado jamás cambiaría. Conviene saber dónde se esconde, porque suele estar repartida por todo el mapa:
- Algoritmos «a fuego» en el código. Aplicaciones que invocan directamente un algoritmo concreto en lugar de pedirlo a una capa configurable. Cambiarlo implica tocar, recompilar y volver a desplegar código, a veces de sistemas que nadie quiere tocar.
- Certificate pinning rígido. Anclar un cliente a un certificado o a una clave concretos da seguridad hoy y crea un problema el día en que esa clave debe rotar. La rigidez disfrazada de control es la peor, porque se defiende como buena práctica.
- Negociación de protocolo limitada. Servicios que no negocian suites de cifrado, sino que imponen una sola, no pueden convivir con clientes nuevos y antiguos durante una transición. Y toda transición real exige convivencia.
- Bibliotecas y dependencias desactualizadas. Si tu stack arrastra librerías criptográficas viejas, no podrás adoptar algoritmos nuevos aunque quieras. La cadena de suministro de software es, además, una superficie de riesgo en sí misma.
- HSM, dispositivos embebidos e IoT. El hardware de seguridad y los dispositivos con ciclos de vida largos son los que peor envejecen: a veces el algoritmo está literalmente grabado en el silicio, y «actualizar» significa sustituir equipos en campo.
- Certificados de vida larga y gestión manual. Si renovar un certificado es un trámite manual que da respeto tocar, no tienes agilidad: tienes una bomba de relojería documental esperando su fecha de caducidad.
Qué aspecto tiene una PKI ágil
Una infraestructura criptoágil no es la que usa el algoritmo más moderno, sino la que puede cambiarlo sin drama. En la práctica, eso descansa sobre unos cuantos principios que, no por casualidad, se parecen mucho a los de una buena arquitectura de software.
- Inventario criptográfico. No puedes proteger ni migrar lo que no sabes que tienes. El primer paso siempre es el mismo: saber qué algoritmos, claves, certificados y protocolos están en uso, dónde, con qué vigencia y quién depende de ellos. Sin inventario, cualquier plan de migración es una conjetura cara.
- Abstracción de la criptografía. Las aplicaciones no deberían «saber» qué algoritmo usan; deberían pedir un servicio criptográfico a una capa que decida, y pueda cambiar, la implementación por debajo. Esa indirección es lo que convierte una migración en un cambio de configuración en lugar de un cambio de código. Es, una vez más, separación de responsabilidades aplicada a la seguridad.
- Negociación y suites configurables. Los servicios deben poder ofrecer y aceptar varias suites de cifrado, de modo que clientes nuevos y antiguos coexistan durante la transición. La compatibilidad temporal no es una debilidad: es lo que evita el corte de servicio mientras todo el ecosistema se pone al día.
- Gestión automatizada del ciclo de vida. Certificados de vida corta y rotación automática hacen que cambiar una clave o un algoritmo sea una rutina, no una emergencia. Cuando rotar es trivial, migrar también lo es. Cuando rotar da miedo, migrar es imposible.
- Enfoque híbrido durante la transición. En la migración poscuántica, los certificados y handshakes híbridos, que combinan un algoritmo clásico con uno poscuántico, permiten ganar protección sin renunciar a la interoperabilidad mientras el resto del mundo avanza. Es la forma prudente de no quedarse ni demasiado pronto sin compatibilidad ni demasiado tarde sin protección.
El primer paso no es migrar: es saber dónde estás
La tentación, ante un cambio así, es correr a desplegar algoritmos nuevos. Es el orden equivocado. La criptoagilidad empieza por entender tu superficie criptográfica actual: qué usas, dónde está enterrada la rigidez y qué se rompería si tuvieras que cambiar mañana. A partir de ahí se prioriza por riesgo, teniendo en cuenta datos sensibles de larga vida, sistemas expuestos o dependencias difíciles de actualizar. Y a partir de ahí se planifica una transición por capas, no un apagón. Aquel inventario que defendíamos en el primer IronSights era el punto de partida, no la meta.
Cómo lo enfocamos en Irontec
Para nosotros, la criptografía poscuántica no es un tema de divulgación: es trabajo. Desde la unidad de Ciberseguridad defendemos desde hace tiempo que ya existen conjuntos de cifrado poscuánticos (PQC) que permiten a las organizaciones empezar a trazar su hoja de ruta hoy, sin esperar a tener encima la urgencia. Y no lo miramos solo desde la defensa: a través de MultiQuantum, nuestra plataforma de optimización discreta, trabajamos directamente con computación cuántica real: la conectamos con Pasqal Cloud, uno de los principales proveedores mundiales de computación cuántica de átomos neutros. Así, conocemos las dos caras de la moneda, tanto la que amenaza el cifrado actual y la que hay que adoptar para resistirla.
