La criptografía sostiene conexiones que rara vez se presentan como una sola arquitectura: HTTPS, VPN, certificados de dispositivos, firmware firmado, acceso remoto, MQTT, bases de datos, copias de seguridad y credenciales de máquinas. En una operación industrial, esas piezas pueden permanecer activas durante diez, veinte o más años.
Prepararse para la era postcuántica no significa que los mecanismos actuales hayan dejado de funcionar. Significa reconocer que algunos algoritmos de clave pública usados hoy —como RSA y las curvas elípticas— no ofrecen una respuesta suficiente frente a un computador cuántico criptográficamente relevante. La migración necesita comenzar antes de que esa capacidad exista, porque renovar una flota industrial toma años.
Qué cambia con un computador cuántico
Gran parte del intercambio de claves y de las firmas digitales actuales depende de problemas matemáticos que el algoritmo de Shor podría resolver eficientemente en un computador cuántico suficientemente grande y tolerante a fallos. Eso afectaría mecanismos basados en factorización y logaritmos discretos, incluidos RSA, Diffie–Hellman y criptografía de curvas elípticas.
La criptografía simétrica se comporta de otra manera. El algoritmo de Grover reduce teóricamente el margen de búsqueda exhaustiva, pero no elimina AES ni las funciones hash. Por eso una estrategia PQC no consiste en reemplazar todo indiscriminadamente: se priorizan el establecimiento de claves, las firmas, los certificados y la gestión de identidades, manteniendo tamaños simétricos adecuados.
Capturar ahora, descifrar después
Un adversario puede almacenar hoy tráfico cifrado y esperar una capacidad futura para intentar descifrarlo. Este riesgo importa cuando planos, fórmulas, historiales de proceso, credenciales de larga vigencia o información estratégica deben conservar confidencialidad por más tiempo que la transición tecnológica prevista.
La pregunta práctica es: ¿el dato seguirá siendo sensible cuando un atacante pueda disponer de mejores capacidades? Si la respuesta es sí, esperar a la llegada de esa capacidad deja una ventana que no se puede reparar retroactivamente.
ML-KEM, ML-DSA y SLH-DSA: funciones diferentes
En 2024, NIST publicó sus primeros estándares finales de criptografía postcuántica. No son nombres intercambiables; cada uno resuelve una función distinta:
| ESTÁNDAR | FUNCIÓN | USO INDUSTRIAL POSIBLE |
|---|---|---|
| ML-KEM · FIPS 203 | Encapsulación de claves para establecer un secreto compartido. | TLS, túneles, gateways, APIs y enlaces entre edge y núcleo. |
| ML-DSA · FIPS 204 | Firma digital de propósito general. | Firmware, software, comandos autorizados, evidencias y certificados cuando el ecosistema lo permita. |
| SLH-DSA · FIPS 205 | Firma basada en hash, con supuestos criptográficos diferentes. | Firmas de larga duración o esquemas que requieran diversidad, considerando firmas más grandes. |
ML-KEM no cifra por sí solo todos los datos ni reemplaza una política TLS completa. Permite acordar el secreto del que se derivan claves simétricas. Del mismo modo, ML-DSA no protege confidencialidad: verifica autenticidad e integridad mediante firmas.
Durante la transición, una construcción híbrida combina un mecanismo postcuántico con uno clásico. La sesión busca conservar seguridad incluso si una de las familias presenta una debilidad, mientras los clientes antiguos mantienen una ruta compatible y controlada.
Por qué una infraestructura industrial no migra como un sitio web
En TI empresarial suele ser posible actualizar navegadores, bibliotecas o servicios administrados con ciclos relativamente cortos. En OT conviven PLC, gateways, cámaras, sensores, estaciones de ingeniería y equipos certificados cuyo firmware puede no admitir algoritmos nuevos.
- Vida útil extensa: algunos activos seguirán operando cuando los algoritmos actuales ya no sean la opción recomendada.
- Disponibilidad: una incompatibilidad criptográfica puede interrumpir supervisión, telemetría o acceso de mantenimiento.
- Recursos limitados: claves, firmas y handshakes PQC tienen tamaños y costos diferentes.
- Dependencias de proveedor: la migración puede requerir firmware, módulos criptográficos, PKI o soporte contractual.
- Entornos desconectados: rotación, revocación y actualización deben funcionar con enlaces intermitentes.
- Seguridad funcional: cambiar una ruta de comunicación exige probar también comportamiento degradado y reversa.
Los equipos incapaces de migrar no deben quedar invisibles. Pueden segmentarse detrás de gateways actualizables, túneles híbridos o zonas de confianza con controles compensatorios, dejando registrada su deuda criptográfica y una fecha de retiro.
Crypto-BOM: convertir criptografía implícita en un inventario gobernable
Un Crypto-BOM —inventario o lista de materiales criptográficos— permite relacionar cada mecanismo con el activo, proveedor, dato y proceso que protege. No basta con anotar “usa TLS”. Se necesita conocer versión, biblioteca, algoritmo negociado, certificado, autoridad, fecha de expiración, ubicación de claves y capacidad de actualización.
Como mínimo, el inventario debería cubrir:
- protocolos externos e internos: TLS, MQTT, OPC UA, VPN, SSH y enlaces propietarios;
- certificados de servidores, usuarios, dispositivos y autoridades intermedias;
- firmas de firmware, contenedores, paquetes, modelos y configuraciones;
- cifrado de bases de datos, discos, respaldos y exportaciones;
- JWT, secretos compartidos, API keys y mecanismos de autenticación;
- HSM, TPM, secure elements y gestores de claves;
- dependencias criptográficas incluidas en sistemas de terceros;
- propietario, criticidad, periodo de confidencialidad y ruta de actualización.
Este inventario permite descubrir dos riesgos diferentes: sistemas vulnerables a largo plazo y sistemas que, aun usando algoritmos fuertes, carecen de rotación, validación de certificados o protección adecuada de claves.
Una ruta de migración que preserve la continuidad
1. Descubrir y priorizar
Ordenar superficies según exposición, vida del dato, criticidad operacional, posibilidad de actualización y dependencia de terceros. Los canales que transportan secretos de larga duración suelen justificar pilotos tempranos.
2. Diseñar agilidad criptográfica
Separar algoritmos de la lógica de negocio, versionar formatos, permitir múltiples suites y evitar identificadores rígidos. La agilidad no es aceptar cualquier algoritmo: es cambiar de forma controlada entre opciones aprobadas.
3. Construir un piloto aislado
Probar primero una ruta representativa con clientes controlados. Medir tamaño de handshake, CPU, memoria, latencia, pérdida de paquetes, renovación de certificados y comportamiento frente a enlaces inestables.
4. Introducir operación híbrida
Ofrecer mecanismos clásicos y postcuánticos con telemetría de negociación. Los clientes compatibles usan el grupo híbrido; los heredados siguen una ruta delimitada. Esto permite observar adopción antes de exigirla.
5. Separar confidencialidad y autenticidad
El intercambio con ML-KEM puede avanzar antes que una PKI completamente basada en ML-DSA. Firmas de artefactos y actualizaciones pueden comenzar con doble firma clásica y postcuántica mientras se valida la cadena operacional.
6. Ensayar reversa y recuperación
Cada cambio debe tener criterios de éxito, rollback, responsables y evidencia. También se debe comprobar restauración de claves y backups; una migración que no puede recuperarse no está lista para producción.
7. Elevar requisitos a proveedores
Solicitar algoritmos soportados, SBOM y Crypto-BOM, política de actualizaciones, fechas de soporte, capacidad de rotación y una hoja de ruta PQC por producto. Las afirmaciones generales de “preparado para quantum” no sustituyen evidencia interoperable.
Decisiones para una transición sólida
- Delimitar el alcance postcuántico. ML-KEM en un endpoint protege una parte del recorrido; certificados, firmware, SSH, MQTT, backups y dispositivos también deben incorporarse al inventario.
- Conservar compatibilidad durante el despliegue. La ruta clásica puede retirarse progresivamente según la evidencia de adopción.
- Integrar los estándares con los controles existentes. Algoritmos, protección de claves, configuración y segmentación forman una misma arquitectura.
- Observar la migración. Registrar el grupo negociado, el tipo de cliente y el impacto permite dirigir cada etapa sin exponer secretos.
- Incluir los datos en reposo. Respaldos, exportaciones y archivos de larga vida también forman parte de la exposición histórica.
Qué puede comenzar hoy una organización industrial
No es necesario esperar una renovación completa. Una organización puede nombrar un responsable, crear su Crypto-BOM, clasificar datos por vida de confidencialidad, comprobar versiones de OpenSSL y bibliotecas, preguntar a proveedores por sus planes y habilitar un piloto híbrido en un canal no crítico.
El resultado inicial es una arquitectura que conoce dónde usa criptografía, puede evolucionarla sin detener la operación y conserva evidencia de cada decisión.
Cómo se relaciona esta preparación con RY2Core
RY2Core articula señales del mundo físico, procesamiento Edge industrial, interoperabilidad industrial, contexto operacional, decisiones y evidencia. La seguridad necesita acompañar ese recorrido completo y poder evolucionar sin reconstruir la plataforma.
Esta capacidad arquitectónica no equivale a declarar que cada dispositivo, protocolo o integración utiliza hoy algoritmos postcuánticos. Significa diseñar límites, versiones, gateways y mecanismos de reversa que permitan incorporar estándares nuevos a medida que el ecosistema y los requisitos operacionales lo permitan.
Comunicación e identidad
Los protocolos, certificados y mecanismos de establecimiento de claves deben poder evolucionar. Personas, servicios y dispositivos necesitan identidades verificables durante todo su ciclo de vida, incluso cuando una parte de la flota permanezca temporalmente en tecnología heredada.
Integridad de la evidencia operacional
La seguridad industrial no termina en la confidencialidad. También debe permitir determinar qué ocurrió, cuándo ocurrió, qué activo participó, quién autorizó una acción y si la evidencia fue modificada. Una decisión industrial debe conservar su contexto y su evidencia.
PQC en Edge y en la convergencia OT/TI
La transición no puede diseñarse exclusivamente desde servicios centrales. Dispositivos, gateways, nodos Edge y sistemas corporativos ofrecen capacidades distintas de procesamiento, memoria, tráfico y actualización. La arquitectura debe decidir dónde ejecutar cada función según criticidad, latencia, conectividad y continuidad operacional.
Un sistema OT también puede depender indirectamente de VPN, certificados, APIs, servidores de actualización o sistemas de identidad TI. Por eso la ruta completa debe considerar convergencia OT/TI, IIoT y dependencias externas, no solamente el algoritmo presente en un controlador.
Preparación postcuántica en RY2Core
Área: Cybersecurity / Industrial Infrastructure
Tema: Post-Quantum Cryptography
Enfoque: Crypto-agility, Edge, identidad e integridad de evidencia
Estado: Investigación y evaluación arquitectónica