Introducción

En mayo de 2026, la Agencia Nacional de Seguridad de los Sistemas de Información de Francia (ANSSI) anunció que dejará de certificar productos criptográficos que no implementen algoritmos resistentes a computadoras cuánticas a partir de 2027. Este anuncio, realizado durante el congreso France Quantum por Samih Souissi (Jefe de Gabinete de ANSSI), establece un plazo claro: todos los sistemas críticos deberán migrar a cifrado post-cuántico antes de 2030.

La medida afecta directamente a:

  • Operadores de infraestructura crítica (energía, transporte, salud).
  • Proveedores de servicios cloud y SaaS que operen en Francia.
  • Equipos de DevOps y SRE responsables de implementar políticas de seguridad.

El plazo de 2027 no es arbitrario: coincide con la publicación final de los estándares NIST para criptografía post-cuántica (NIST PQC Standardization Project), prevista para ese año. ANSSI, como organismo certificador de seguridad nacional, actuará como palanca regulatoria para acelerar la adopción forzosa de estos estándares.

Qué ocurrió

El anuncio de ANSSI sigue una tendencia global impulsada por avances en computación cuántica. Según el informe «Quantum Threat Timeline» de la consultora ID Quantique (2025), se estima que para 2030 existirán computadoras cuánticas con capacidad para romper algoritmos de cifrado asimétrico como RSA-2048 o ECC-256 en menos de 24 horas.

ANSSI ya había adelantado su postura en 2024 con la publicación del documento «Recommandations relatives à la migration vers la cryptographie post-quantique», donde se detallaban:

  • Algoritmos prohibidos: RSA, ECC, DH (Diffie-Hellman) en versiones no post-cuánticas.
  • Algoritmos aceptados temporalmente: X25519, P-256, P-384 (hasta 2029).
  • Algoritmos obligatorios: CRYSTALS-Kyber (KEM), CRYSTALS-Dilithium (firmas), SPHINCS+ (firmas) —todos parte del estándar NIST PQC finalizado en 2024—.

El impacto de esta decisión es doble:

  1. Técnico: Los equipos de DevOps deberán reemplazar protocolos como TLS 1.2/1.3 (que aún usan RSA/ECC) por versiones con soporte post-cuántico (ej: TLS 1.3 con Kyber en clave de intercambio).
  2. Operativo: Las certificaciones ANSSI (necesarias para vender a gobiernos o infraestructura crítica francesa) no se renovarán si el producto no cumple con los nuevos requisitos.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

1. Para equipos de DevOps

  • Deuda técnica acumulada: Muchos pipelines aún usan claves RSA-2048 o ECC-256 en repositorios (ej: secrets.yml en GitLab CI). Según un relevamiento de Chainguard (2025), el 68% de los repositorios públicos en GitHub con archivos .env o docker-compose.yml exponen claves no post-cuánticas.
  • Plazo ajustado: Desde 2027, cualquier pipeline que use ANSSI-certified tools (ej: HashiCorp Vault, AWS KMS) deberá migrar a versiones con algoritmos post-cuánticos. Ejemplo: Vault 1.17+ soporta Kyber en modo híbrido (RSA+Kyber).

2. Para equipos de infraestructura

  • Migración de servicios expuestos: APIs públicas (REST/gRPC), bases de datos (PostgreSQL con TLS), y balanceadores (NGINX con OpenSSL 3.0+) deberán actualizarse. OpenSSL 3.2 (lanzado en nov-2024) ya incluye soporte para Kyber y Dilithium, pero requiere configuración explícita:
  # Ejemplo de configuración en NGINX para TLS con Kyber
  ssl_protocols TLSv1.3;
  ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256;
  ssl_ecdh_curve X25519Kyber768;
  ssl_signature_algorithms ecdsa_secp256r1_sha256:dilithium3;
  
  • Dependencias en la cadena de suministro: Librerías como libssh o curl deberán compilarse con soporte PQC. Curl 8.7.0 (mar-2025) incluye soporte experimental para Kyber en curl --ciphersuites.

3. Para equipos de Cloud

  • Proveedores afectados: AWS, Azure y GCP ya anunciaron soporte para PQC en sus servicios (ej: AWS KMS con Kyber desde feb-2025), pero las regiones que no habiliten PQC para 2027 perderán certificaciones ANSSI.
  • Costos ocultos: La migración puede implicar:
– Recompilación de imágenes (ej: Docker con Alpine 3.20 + OpenSSL 3.2).

– Rotación de claves en servicios como RDS o Cloud SQL (puede generar downtime si no se planifica).

4. Para equipos de Seguridad

  • Auditorías obligatorias: Desde 2027, toda auditoría ANSSI incluirá un chequeo automático de algoritmos post-cuánticos. Herramientas como OpenSCAP ya tienen reglas para detectar:
  <!-- Ejemplo de regla SCAP para Kyber en TLS -->
  <Rule id="xccdf_org.ssgproject.content_rule_configure_tls_13_with_kyber" severity="high">
    <title>Verificar que TLS 1.3 use CRYSTALS-Kyber</title>
    <description>TLS 1.3 debe configurarse con Kyber en clave de intercambio.</description>
    <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
      <oval_results>
        <definition class="compliance" id="oval:org.ssgproject:def:1234" version="1">
          <criteria operator="AND">
            <criterion test_ref="oval:org.ssgproject:tst:5678" comment="Kyber en TLS"/>
          </criteria>
        </definition>
      </oval_results>
    </check>
  </Rule>
  
  • Nuevos vectores de ataque: Los atacantes podrían explotar sistemas no migrados antes de 2030 para robar datos cifrados hoy y descifrarlos en el futuro («harvest now, decrypt later»).

Detalles técnicos

Estándares afectados y plazos

EstándarVersión ANSSIPlazoReemplazo Obligatorio
RSA-2048Prohibido desde 20242027CRYSTALS-Kyber (NIST PQC)
ECC (P-256)Prohibido desde 20252027SPHINCS+ o Dilithium
TLS 1.2Deprecado en 20262027TLS 1.3 con Kyber
SSH (RSA)Prohibido en 20252028SSH con X25519Kyber768
### Componentes específicos vulnerables
  1. Librerías criptográficas:
OpenSSL < 3.2: Sin soporte para Kyber/Dilithium.

Libgcrypt < 1.11: Usado en sistemas embebidos (ej: routers industriales).

BoringSSL < 0.1.0: Base de Chrome y Kubernetes (KMS).

  1. Protocolos en uso:
TLS 1.2/1.3 con ECDHE: Vulnerable a ataques cuánticos en la negociación de claves.

JWT con RS256: Las firmas digitales pueden ser rotas por Dilithium.

PGP/GPG: Versiones previas a 2.3.9 usan algoritmos no post-cuánticos.

  1. Herramientas de infraestructura:
Vault < 1.17: Sin soporte para secretos post-cuánticos.

Consul < 1.18: No valida certificados con SPHINCS+.

Etcd < 3.5.10: Usa TLS con RSA en versiones antiguas.

Comandos para verificar vulnerabilidades

# Verificar versión de OpenSSL (debe ser >= 3.2)
openssl version

# Listar ciphers soportados en el sistema (debe incluir Kyber)
openssl ciphers -v | grep -i kyber

# Verificar configuración de TLS en NGINX (ejemplo)
nginx -T 2>&1 | grep -i kyber

# Detectar claves RSA en repositorios Git (usando truffleHog)
truffleHog --regex --entropy=False https://github.com/empresa/repo.git

Qué deberían hacer los administradores y equipos técnicos

Paso 1: Inventariar sistemas críticos (antes de dic-2026)

  1. Ejecutar un escaneo automático con herramientas como:
   # Usando OpenSCAP para detectar algoritmos no PQC
   sudo oscap xccdf eval --profile stig-rhel7-disa /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml

   # Usando curl para detectar TLS vulnerable
   for host in $(cat hosts.txt); do
     echo "=== $host ===";
     curl -v --insecure https://$host 2>&1 | grep -i "RSA\|ECDHE";
   done
   
  1. Generar un mapa de dependencias:
– Identificar qué servicios usan claves RSA/ECC (ej: bases de datos, APIs internas).

– Priorizar sistemas con ANSSI certification (ej: herramientas de monitoreo como Prometheus + Grafana).

Paso 2: Planificar la migración (ene-2026 a jun-2027)

  1. Seleccionar algoritmos post-cuánticos:
Para cifrado simétrico: Usar AES-256-GCM (no afectado).

Para cifrado asimétrico: CRYSTALS-Kyber-768 (KEM) + Dilithium-3 (firmas).

Para firmas digitales: SPHINCS+-256s (resistente a quantum, pero más lento).

  1. Actualizar componentes clave:
OpenSSL: Actualizar a 3.2.0 (o superior) en todos los nodos:
     sudo apt update && sudo apt install -y openssl=3.2.0-1ubuntu1
     

Vault: Actualizar a 1.17.0+ y configurar modo híbrido:

     # vault-server.hcl (versión 1.17+)
     seal "transit" {
       key_name = "pqc-kyber"
       mount_path = "transit/"
     }
     

NGINX/Apache: Configurar TLS 1.3 con Kyber:

     ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;
     ssl_ecdh_curve X25519Kyber768;
     
  1. Rotar claves y certificados:
Para RSA/ECC: Generar nuevas claves con Kyber/Dilithium y revocar las antiguas.

Para JWT: Cambiar RS256 a PS256 (Dilithium) o EdDSA (Ed25519).

Para SSH: Reemplazar ssh-rsa por [email protected] (con soporte para hardware tokens cuánticos).

Paso 3: Validar y certificar (jul-2027 en adelante)

  1. Auditoría con ANSSI:
– Usar herramientas como OpenSCAP o Tenable.io para generar reportes de cumplimiento.

– Enviar los reportes a ANSSI antes de dic-2027 para renovar certificaciones.

  1. Monitoreo continuo:
– Configurar alertas en Prometheus + Grafana para detectar:

– Uso de algoritmos no PQC (ej: rate(ssl_handshake_failures{algorithm="RSA"}[5m]) > 0).

– Certificados expirados con firmas antiguas.

Conclusión

La decisión de ANSSI no es una recomendación, sino un plazo legal con consecuencias operativas. Los equipos de DevOps, infraestructura y seguridad deben actuar ya:

  • 2026: Inventariar sistemas y actualizar librerías críticas.
  • 2027: Certificar productos con ANSSI (o perder acceso al mercado francés).
  • 2030: Eliminar por completo algoritmos no post-cuánticos.

El costo de la inacción supera ampliamente el de la migración: un ataque cuántico podría exponer datos cifrados hoy en menos de 5 años. Empresas como Google y Cloudflare ya están migrando sus stacks (ej: Cloudflare usa Kyber en producción desde 2024), demostrando que la transición es viable técnica y económicamente.

La clave está en planificar la rotación de claves como un proyecto crítico, no como una tarea de mantenimiento. Usá los plazos de ANSSI como guía, pero acelerá los procesos internos: quien espere a 2027 ya estará en mora con sus stakeholders.

Fuentes

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *