preparación poscuántica: cómo proteger sistemas antes de que cambie la criptografía

La preparación poscuántica consiste en localizar y sustituir, de forma planificada, los mecanismos criptográficos que podrían quedar expuestos cuando existan ordenadores cuánticos suficientemente potentes. Para una empresa no significa apagar sus sistemas actuales ni comprar una solución milagrosa: significa saber dónde se usa la criptografía, qué información debe seguir siendo confidencial durante años y cómo migrar sin interrumpir servicios críticos.

La amenaza no exige esperar a que una máquina cuántica pueda romper el cifrado actual. Un atacante puede capturar hoy comunicaciones protegidas y conservarlas para intentar descifrarlas en el futuro. Por eso, la pregunta útil no es solo cuándo llegará ese equipo, sino qué datos seguirán teniendo valor cuando llegue y cuánto tiempo requiere la organización para cambiar sus dependencias criptográficas.

El riesgo empieza con los datos que deben seguir siendo secretos

Los algoritmos de clave pública más extendidos, como RSA y la criptografía de curva elíptica, sustentan tareas como el intercambio de claves y las firmas digitales. Un ordenador cuántico criptográficamente relevante podría amenazar esos mecanismos. No implica que cualquier cifrado vaya a desaparecer: los algoritmos simétricos, como AES, tienen un perfil distinto y pueden seguir utilizándose con parámetros adecuados. La evaluación debe distinguir entre funciones y algoritmos, en lugar de tratar toda la seguridad como una sola pieza.

El escenario de capturar ahora y descifrar después es especialmente pertinente para historiales médicos, expedientes legales, propiedad intelectual, credenciales de larga duración y comunicaciones diplomáticas o financieras. Si un documento debe conservar su confidencialidad durante veinte años, una migración que tarde cinco años merece atención aunque la capacidad de romper los sistemas actuales todavía no exista.

En cambio, un dato público, de corta vida o que pierde valor al terminar una transacción puede tener una prioridad menor. Esto no lo exime de buenas prácticas de seguridad, pero ayuda a asignar recursos según el impacto real. El riesgo depende de la vida útil de la información, de la exposición del sistema y del tiempo necesario para cambiarlo.

El primer trabajo no es comprar tecnología: es hacer inventario

Una organización rara vez conoce todos los lugares donde sus sistemas dependen de criptografía. Puede aparecer en conexiones TLS, redes privadas virtuales, certificados, firmas de software, autenticación de dispositivos, copias de seguridad, servicios en la nube, aplicaciones antiguas y componentes integrados en equipos industriales. El inventario debe abarcar tanto los activos propios como los servicios de proveedores.

Conviene registrar, como mínimo, qué algoritmo se usa, para qué función, quién mantiene el componente, dónde se ejecuta, qué datos protege y cuánto tarda en renovarse o sustituirse. También hay que identificar dependencias indirectas: una aplicación puede usar una biblioteca criptográfica incluida dentro de otra herramienta, sin que el equipo de desarrollo la haya seleccionado conscientemente.

Cómo priorizar sin convertir el inventario en un proyecto interminable

Un registro inicial no necesita ser perfecto para resultar útil. Puede comenzar por los sistemas de mayor impacto y ampliarse por etapas. Una matriz sencilla cruza tres factores: sensibilidad y vida útil de los datos, exposición del servicio y dificultad de sustitución. Así se distinguen las plataformas que requieren una prueba temprana de aquellas que pueden esperar a una renovación prevista.

• Prioridad alta: datos confidenciales de larga duración, servicios expuestos a Internet y sistemas cuyo cambio exige ciclos extensos de certificación o compra.
• Prioridad media: servicios relevantes, pero con información de vigencia limitada o componentes que pueden actualizarse mediante una versión próxima.
• Prioridad menor: sistemas aislados o datos de bajo impacto, siempre que la clasificación se revise y no oculte dependencias compartidas.

Por ejemplo, una entidad sanitaria podría dar prioridad al archivo clínico y a los canales de intercambio con laboratorios, mientras programa la actualización de una aplicación interna que solo almacena datos operativos recientes. La decisión no se basa en que un sector esté automáticamente en peligro, sino en la duración del secreto y el coste de una exposición futura.

Estándares poscuánticos y decisiones que conviene separar

El Instituto Nacional de Estándares y Tecnología de Estados Unidos (NIST) publicó en 2024 sus primeros estándares de criptografía poscuántica: ML-KEM para encapsulación e intercambio de claves, ML-DSA para firmas digitales y SLH-DSA como alternativa de firma basada en funciones hash. Estos nombres son referencias importantes para los planes de transición, pero su publicación no convierte cualquier producto que los anuncie en una opción automáticamente adecuada.

La elección depende del uso. El establecimiento de claves, la firma de código y la autenticación requieren mecanismos distintos. También deben evaluarse el tamaño de claves y firmas, el consumo de memoria, la latencia, la compatibilidad con protocolos, la disponibilidad en bibliotecas mantenidas y las exigencias regulatorias aplicables. En dispositivos con recursos limitados, por ejemplo, el tamaño de los mensajes puede afectar más que el coste de cálculo.

Durante una transición, algunas organizaciones probarán configuraciones híbridas que combinan mecanismos clásicos y poscuánticos. La idea es mantener protección frente a amenazas conocidas mientras se incorpora un algoritmo nuevo, pero el resultado depende de una implementación correcta y de protocolos compatibles. No basta con sumar algoritmos: hay que comprobar cómo se combinan, qué ocurre ante errores y si las bibliotecas y los extremos de la conexión los soportan de verdad.

La criptografía cuántica, incluida la distribución cuántica de claves, no es sinónimo de criptografía poscuántica. Esta última utiliza algoritmos ejecutables en sistemas informáticos convencionales y está diseñada para resistir ataques cuánticos conocidos. La distribución cuántica requiere infraestructura especializada y resuelve un problema diferente; no sustituye por sí sola la gestión de identidades, las firmas ni una arquitectura segura.

Una hoja de ruta que reduce riesgos sin romper servicios

Una migración sólida se organiza como un programa de ingeniería y gestión de proveedores, no como una actualización puntual. El orden puede variar, pero estas etapas permiten avanzar con control:

1. Definir responsables y alcance. Involucrar a seguridad, arquitectura, desarrollo, compras, operaciones y cumplimiento. Acordar qué sistemas se analizan y quién acepta los riesgos temporales.
2. Completar y clasificar el inventario. Vincular algoritmos con datos, aplicaciones, proveedores y fechas de renovación. Registrar también componentes sin soporte o con ciclos de actualización largos.
3. Solicitar información a proveedores. Preguntar qué estándares implementan, en qué versiones, cómo gestionan certificados y claves, qué compatibilidad ofrecen y cuál es su calendario de soporte. Las respuestas deben ser verificables, no promesas comerciales.
4. Probar en un entorno controlado. Medir interoperabilidad, rendimiento, tamaños de mensajes, uso de memoria y comportamiento ante fallos. Una prueba útil incluye clientes antiguos, redes con limitaciones y procesos de recuperación.
5. Desplegar por fases y mantener reversión. Empezar por servicios bien delimitados, observar métricas y ampliar solo cuando la operación sea estable. La opción de volver temporalmente a una configuración anterior debe estar definida y protegida, no improvisarse durante un incidente.
6. Revisar y retirar mecanismos obsoletos. Confirmar que la nueva configuración se aplica en todos los entornos y que no quedan rutas alternativas que negocien algoritmos débiles sin supervisión.

La llamada agilidad criptográfica es la capacidad de cambiar algoritmos, claves y parámetros con un coste controlado. Para conseguirla hacen falta límites claros entre las aplicaciones y las bibliotecas criptográficas, configuración centralizada, pruebas automatizadas y procesos de renovación de certificados. Si cada equipo integra algoritmos directamente en el código, la futura sustitución se convierte en una serie de proyectos independientes y difíciles de coordinar.

Errores que encarecen la transición

Un error frecuente es esperar a que exista una fecha exacta para el llamado «Q-Day». La capacidad relevante no puede predecirse con precisión y las cadenas de suministro pueden tardar años en responder. Esperar a una certeza total deja poco margen para sistemas con ciclos de vida largos. El error opuesto también es posible: sustituir todo de inmediato, sin conocer compatibilidades ni priorizar datos, puede provocar interrupciones y gastos que no reducen el riesgo más urgente.

También conviene evitar decisiones guiadas solo por un sello de «poscuántico». Deben comprobarse la versión del estándar, la implementación concreta, el mantenimiento, las auditorías y el soporte en los protocolos necesarios. Un algoritmo robusto dentro de una integración defectuosa no ofrece una solución completa.

Otro riesgo consiste en olvidar las firmas. La conversación suele centrarse en mantener la confidencialidad, pero las firmas digitales sostienen la autenticidad de actualizaciones, documentos, certificados y transacciones. La transición de una firma puede afectar a equipos que deben validar software durante muchos años, por lo que necesita planificación propia, incluida la gestión de certificados y la compatibilidad con dispositivos antiguos.

Por último, cambiar algoritmos no corrige fallos básicos: claves expuestas, privilegios excesivos, copias inseguras o sistemas sin parches siguen siendo problemas inmediatos. La preparación poscuántica debe integrarse en la gestión de riesgos existente, no desplazar controles que protegen frente a amenazas actuales.

Qué debería decidir una organización durante los próximos meses

Una primera decisión razonable es asignar un responsable, reunir a los equipos que gestionan criptografía y establecer un inventario inicial de los sistemas con datos sensibles de larga duración. Después, se pueden solicitar planes concretos a los proveedores críticos y elegir una o dos pruebas piloto representativas. El objetivo de esas pruebas no es demostrar que todo está resuelto, sino descubrir límites de rendimiento, compatibilidad y operación antes de comprometer un despliegue amplio.

Si la empresa desarrolla software, puede añadir requisitos de agilidad criptográfica a la arquitectura y a las nuevas compras. Si depende principalmente de servicios externos, debería incorporar preguntas y compromisos de transición en la evaluación de proveedores. En ambos casos, es útil conservar decisiones, supuestos y excepciones: el mapa cambiará conforme evolucionen los estándares, los productos y las recomendaciones de seguridad.

La preparación poscuántica más eficaz empieza por entender qué se protege y cuánto tiempo debe seguir protegido. Con un inventario priorizado, pruebas verificables y una ruta por fases, una organización puede reducir la exposición futura sin caer en compras precipitadas ni aplazar indefinidamente el trabajo. El siguiente paso práctico es identificar un sistema de alto impacto y confirmar, con datos y responsables, cómo podría migrarse.