Harvest Now Decrypt Later: Qué Credenciales Migrar Primero a PQC

Harvest now, decrypt later (HNDL) es una estrategia de ciberespionaje activa: adversarios capturan hoy tráfico cifrado con RSA o ECC para descifrarlo cuando los ordenadores cuánticos maduren, estimado entre 2030 y 2035 según el NIST. Las credenciales que una PYME debe migrar primero son las de mayor vida útil y acceso privilegiado: claves SSH de administración, certificados de CA privada, configuraciones VPN IPsec y tokens de API de larga duración.

Las revelaciones de Snowden en 2013 confirmaron lo que los servicios de inteligencia ya practicaban a escala industrial: la interceptación y almacenamiento masivo de tráfico cifrado en tránsito. El programa MUSCULAR de la NSA y el GCHQ capturaba datos cifrados con la lógica de que algún día se encontraría la forma de descifrarlos. Ese algún día ahora tiene estimación técnica: un ordenador cuántico con unos 4.000 qubits tolerantes a fallos puede ejecutar el algoritmo de Shor y romper RSA-2048 en horas. Para datos que requieren confidencialidad durante una década —expedientes médicos, contratos de adquisición, bases de clientes con datos RGPD— el riesgo es presente y concreto, no hipotético. El coste de almacenar cinco años de tráfico TLS de una empresa de 50 empleados es inferior a 200 euros en infraestructura cloud: trivial para un actor estado-nación con motivación. Esta asimetría —baratísimo interceptar, carísimo proteger mal— es lo que hace el HNDL tan efectivo como vector de ataque a largo plazo.

La intuición habitual es que los datos más sensibles —contratos, datos de pacientes, propiedad intelectual— son el objetivo principal del HNDL. Es parcialmente correcto, pero pasa por alto el vector más rentable: las credenciales de acceso. Una clave SSH de administrador de sistemas o las claves privadas de una CA interna tienen una vida útil media de 3 a 7 años; si un adversario descifra en 2030 el tráfico VPN capturado en 2025, no necesita explotar vulnerabilidades: entra con credenciales completamente válidas. Este patrón de acceso —legítimo a ojos del SIEM— es mucho más difícil de detectar que un ataque convencional: sin fuerza bruta, sin alertas de comportamiento anómalo, sin logs sospechosos hasta que el daño ya está hecho. La diferencia entre robar credenciales por HNDL y descifrar un documento confidencial es que las credenciales siguen funcionando como llave maestra; el documento ya no importa si puedes entrar directamente al sistema. Por eso la prioridad de migración PQC debe empezar por las credenciales de acceso privilegiado, no por los datos en reposo.

Prioridad crítica — migrar antes de 2028

• Claves SSH de administración: vida útil media de 3-7 años; raramente rotadas según nuestra experiencia en auditorías de infraestructura en España
• Certificados de CA privada (PKI interna): si firman tokens de autenticación o VPN, son las claves maestras de toda la infraestructura
• Configuraciones VPN IPsec con DH Group ≤14 o IKEv1: vulnerables ya a precomputación con hardware clásico avanzado, no solo cuántico
• Tokens de API y claves JWT con expiración superior a 12 meses: especialmente si dan acceso a datos RGPD o a sistemas de producción
• Claves de cifrado de bases de datos retenidas más de 3 años con información regulatoria

Segunda oleada — 2028-2031

• Certificados TLS de cara pública: desde 2025 tienen vida máxima de 398 días (Apple/Google), lo que reduce el riesgo HNDL considerablemente
• Claves de firma de código (binarios, scripts CI/CD): importantes pero con impacto más localizado y fácil de rotar
• Certificados S/MIME de correo corporativo: prioridad media si el email contiene negociaciones de alto valor
• Claves de cifrado de backups offline: migrar en paralelo con la actualización del plan de recuperación ante desastres

En agosto de 2024, el NIST publicó los primeros estándares de criptografía post-cuántica finalizados: FIPS 203 (ML-KEM, basado en CRYSTALS-Kyber, para cifrado e intercambio de claves), FIPS 204 (ML-DSA, basado en CRYSTALS-Dilithium, para firmas digitales) y FIPS 205 (SLH-DSA, basado en SPHINCS+, para firmas basadas en hash). Ya no es una propuesta ni un borrador: son estándares publicados con soporte nativo en OpenSSL 3.5 (2025), disponibles en libreSSL y en las últimas versiones de OpenSSH. Google Chrome activó por defecto el intercambio de claves híbrido X25519Kyber768 en TLS 1.3 durante 2024, lo que significa que parte del tráfico HTTPS de tu empresa ya puede estar usando PQC sin que lo hayas configurado activamente. Para una PYME, el mensaje práctico es que la excusa esperar a que maduren los estándares ya no existe: los algoritmos están listos, el software los soporta, y la ventana de migración ordenada se está cerrando. La estrategia recomendada es la migración híbrida —combinar RSA-2048 con ML-KEM en paralelo— que permite validar compatibilidad sin cortar servicios ni asumir riesgos de disponibilidad.

En las evaluaciones de infraestructura que hemos realizado en empresas de entre 30 y 200 empleados en España, el hallazgo más frecuente no es que usen RSA-2048 —eso ya estaba descontado—. El problema real es que no saben cuántas claves tienen, dónde están almacenadas, quién las gestiona ni cuándo expiran. Sin un inventario de activos criptográficos —lo que el NIST SP 800-208 denomina crypto agility assessment— no existe migración posible, solo sustituciones parciales que dejan huecos críticos y una falsa sensación de seguridad. Hemos visto organizaciones que compraron soluciones VPN post-cuánticas para su perímetro principal pero seguían operando una CA interna en Windows Server 2012 firmando con SHA-1. Una aclaración honesta antes de continuar: no recomendamos a todas las PYMEs migrar a PQC completa de forma inmediata; si la vida útil de confidencialidad de tus datos no supera los tres años y no operas en sectores regulados como finanzas, salud o infraestructuras críticas, el riesgo HNDL es bajo-medio y puede abordarse en el próximo ciclo de inversión. Lo que sí recomendamos sin excepciones es hacer el inventario ahora: tiene coste pequeño, beneficio inmediato, y de paso descubres vulnerabilidades que no tienen nada que ver con la criptografía cuántica.

En cinco de los últimos doce proyectos de auditoría encontramos claves SSH de administrador que llevaban más de tres años sin rotarse, generadas con RSA-2048. En ninguno de los cinco casos el equipo IT sabía que existían. El riesgo cuántico resultó ser lo de menos; el riesgo inmediato era acceso no auditado de ex-empleados.

• Inventario criptográfico: listar cada clave, certificado y algoritmo con fecha de creación y expiración (openssl x509 -text, ssh-keygen -l, Keyfactor, Venafi o scripts propios)
• Clasificar por vida útil y criticidad: priorizar todo lo que tenga vida útil superior a 3 años o que dé acceso privilegiado a sistemas de producción
• Auditar proveedores SaaS y cloud: exigir su roadmap PQC por escrito; AWS, Azure y GCP ya publican planes públicos con fechas concretas
• Piloto híbrido: configurar VPN o SSH en modo híbrido RSA + ML-KEM antes del corte total para validar compatibilidad sin romper producción
• Actualizar política de rotación: SSH admin no más de 12 meses, CA interna no más de 2 años, documentarlo en el SGSI (obligatorio si aplica ENS o ISO 27001)