BSI TR-02102-1 y la criptografía poscuántica: las recomendaciones de 2026

BSI TR-02102-1 es la directriz técnica sobre mecanismos criptográficos publicada por la Oficina Federal de Seguridad de la Información de Alemania (BSI, Bundesamt für Sicherheit in der Informationstechnik). La versión 2026-01, fechada el 23 de enero de 2026, recomienda el acuerdo de claves poscuántico híbrido, considera el acuerdo de claves clásico utilizado en solitario como recomendado solo hasta finales de 2031 (finales de 2030 cuando las necesidades de protección son muy elevadas) y establece claves RSA de al menos 3000 bits. Es una directriz técnica, no una ley, y este artículo muestra cómo convertir esos tres puntos en una configuración TLS que pueda comprobar.

Qué es TR-02102-1 y qué no es

TR-02102-1 enumera los mecanismos criptográficos que el BSI considera adecuados, con longitudes de clave y un horizonte temporal asociados a cada uno. Es una orientación. Por sí sola no crea ninguna obligación para una empresa privada. Solo se vuelve vinculante cuando otro elemento la hace vinculante: un contrato con un cliente alemán, una norma sectorial, un requisito de contratación pública o una política criptográfica interna que la cite. Esta última frase es nuestra lectura de cómo se utiliza el documento en la práctica, no una cita de la directriz.

De ello se derivan dos consecuencias para los equipos que prestan servicio a clientes alemanes. En primer lugar, cite siempre la versión. Todas las cifras de este artículo proceden de la versión 2026-01, y conviene volver a citarlas a partir de la versión vigente en el momento de la auditoría. En segundo lugar, un cuestionario de proveedores que pregunta si cumple con TR-02102-1 pregunta en realidad si su configuración desplegada coincide con los mecanismos recomendados y sus horizontes. Los hitos fechados se resumen en nuestra página de referencia sobre BSI TR-02102-1, y el BSI publica la propia directriz en PDF: BSI TR-02102-1.

La posición de la versión 2026-01 sobre el acuerdo de claves

La directriz recomienda el acuerdo de claves poscuántico híbrido. Híbrido significa combinar un acuerdo de claves clásico, como Diffie-Hellman de curva elíptica (ECDH), con un mecanismo de encapsulación de claves (KEM) poscuántico, de modo que la clave de sesión siga siendo segura si cualquiera de los dos componentes resiste. En TLS 1.3, el componente poscuántico que se usa hoy en producción es ML-KEM (Module-Lattice-based Key Encapsulation Mechanism), normalizado por el NIST como FIPS 203 el 13 de agosto de 2024.

Hay dos fechas importantes. El acuerdo de claves clásico utilizado en solitario se recomienda solo hasta finales de 2031. Cuando las necesidades de protección son muy elevadas, la fecha pasa a ser finales de 2030. Se trata de recomendaciones con un horizonte, no de una fecha de desconexión impuesta por un regulador.

El acuerdo de claves va primero por una razón física, no normativa. El tráfico TLS grabado solo está protegido por el intercambio de claves que generó sus claves de sesión. Un atacante que almacena hoy el texto cifrado puede descifrarlo más adelante si el intercambio de claves llega a ser vulnerable, un patrón conocido como «almacenar ahora, descifrar después» (harvest now, decrypt later, HNDL). Las firmas y los certificados no tienen esa propiedad: una firma verificada hoy no puede falsificarse de forma retroactiva. Por eso el horizonte del acuerdo de claves llega antes que cualquier migración de firmas.

RSA de al menos 3000 bits, y lo que no le aporta

La versión 2026-01 establece una longitud mínima de clave RSA de 3000 bits. En la práctica, las autoridades de certificación, los módulos de seguridad hardware y las bibliotecas TLS trabajan con claves RSA de 3072 bits, que cumplen el umbral y cuentan con amplia compatibilidad. Comprobar la longitud de clave de un certificado desplegado requiere un solo comando.

openssl x509 -in server.crt -noout -text | grep -i public-key

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out server.key
openssl req -new -key server.key -out server.csr

Conviene ser preciso sobre lo que esto consigue. Una clave RSA más larga eleva el nivel de seguridad clásico. No hace que la clave sea resistente a la computación cuántica: RSA, ECDSA, EdDSA, ECDH, Diffie-Hellman de cuerpo finito y DSA quedan todos rotos por el algoritmo de Shor en un ordenador cuántico suficientemente grande, sea cual sea el tamaño de la clave. El mínimo de 3000 bits y la recomendación de acuerdo de claves híbrido responden a dos problemas distintos, y cumplir uno no satisface el otro.

A modo de comparación, NIST IR 8547 propone declarar obsoletos los algoritmos vulnerables a la computación cuántica con un nivel de seguridad de 112 bits, lo que incluye RSA-2048, después de 2030, y prohibir todos los algoritmos de clave pública vulnerables a la computación cuántica después de 2035. Ese documento es un borrador público inicial publicado el 12 de noviembre de 2024 y sigue siendo un borrador: NIST IR 8547 (ipd). Un mínimo alemán de 3000 bits y una propuesta estadounidense, aún en borrador, de declarar obsoletas las claves de 2048 bits apuntan en la misma dirección, desde dos textos distintos con dos estatus distintos.

Trasladar la recomendación a una configuración TLS

La directriz recomienda un mecanismo, el acuerdo de claves híbrido. Elegir el grupo concreto de TLS 1.3 es una decisión de implementación, y lo que sigue es nuestra correspondencia práctica, no una cita. Los grupos híbridos registrados en la IANA son X25519MLKEM768 (codepoint 0x11EC, 4588), SecP256r1MLKEM768 (0x11EB, 4587) y SecP384r1MLKEM1024 (0x11ED, 4589), que figuran en el registro de parámetros TLS de la IANA. Su uso en TLS 1.3 se describe en RFC 10024 (agosto de 2026). Las versiones actuales de Chrome, Edge y Firefox ya ofrecen X25519MLKEM768 por defecto, por lo que activarlo en el servidor cambia de inmediato lo que negocian los navegadores reales.

Paso 1: confirmar que la biblioteca admite los grupos

Se necesita OpenSSL 3.5 o posterior para disponer de los grupos TLS ML-KEM en OpenSSL. Compruébelo antes de modificar cualquier configuración del servidor.

openssl version
openssl list -tls-groups | grep -i mlkem

Paso 2: ofrecer primero el grupo híbrido y mantener una alternativa clásica

El orden importa: el grupo híbrido va primero y los grupos clásicos quedan detrás para que los clientes más antiguos sigan conectándose. No elimine nunca la alternativa clásica en el mismo cambio.

# nginx, built against OpenSSL 3.5 or later
ssl_protocols TLSv1.3 TLSv1.2;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;

# Apache httpd with mod_ssl, OpenSSL 3.5 or later
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLOpenSSLConfCmd Groups X25519MLKEM768:X25519:prime256v1

Los nombres de las directivas y su compatibilidad varían entre distribuciones y entre compilaciones de una misma versión del servidor, así que verifíquelo con su propio paquete en lugar de darlo por supuesto. Las recetas completas para nginx, Apache, HAProxy y Caddy están en nuestra guía para activar ML-KEM en los servidores web más comunes. Haga las pruebas en preproducción antes de pasar a producción.

Paso 3: verificar lo que realmente se negocia

openssl s_client -connect example.de:443 -tls1_3 -groups X25519MLKEM768 </dev/null | grep -i negotiated

Un handshake correcto muestra el grupo negociado. Repita la misma prueba sin el grupo híbrido para confirmar que los clientes clásicos siguen conectándose.

Cómo se compara el horizonte alemán con otros calendarios

Las fechas alemanas no existen de forma aislada. Si presta servicio a clientes en varios países, el horizonte aplicable más temprano es el que marca el plan.

Las evidencias que pedirá un cliente o auditor alemán

NIS2, Directiva (UE) 2022/2555, artículo 21(2)(h), exige políticas y procedimientos relativos a la utilización de la criptografía y, en su caso, del cifrado. Para las entidades financieras, las normas técnicas de regulación de DORA, Reglamento Delegado (UE) 2024/1774 de la Comisión, artículo 6, exigen una política de cifrado y controles criptográficos que incluya disposiciones para actualizar o cambiar la tecnología criptográfica en función de la evolución del criptoanálisis. Ninguno de los dos textos menciona algoritmos poscuánticos.

Nuestra interpretación, claramente identificada como tal: mencionar TR-02102-1 y su versión dentro de esa política, junto con los mecanismos que acepta y el horizonte que aplica, es una forma práctica de demostrar que la política se apoya en una referencia reconocida y cuenta con un desencadenante de revisión. Mantenga los artefactos simples y fechados: la propia política, un inventario de endpoints TLS con sus grupos negociados y los tamaños de clave de sus certificados, y un resultado de escaneo por endpoint. Nuestra página sobre NIS2 artículo 21(2)(h) expone lo que exige la directiva. Este artículo es informativo y no constituye asesoramiento jurídico.

Siguiente paso: comprobar qué negocian hoy sus servidores

Antes de redactar cualquier plan, mida el estado actual. Escanee su dominio con PQC Status para ver qué versiones de TLS, grupos de acuerdo de claves y algoritmos de certificado ofrece realmente su servidor, incluido si se negocia un grupo híbrido ML-KEM. Un escaneo describe únicamente la configuración TLS visible desde el exterior: no es una certificación ni una declaración de conformidad. Utilice el resultado como primera línea de su inventario, después active el grupo híbrido en preproducción, mantenga la alternativa clásica y registre el antes y el después de cada endpoint.