Requisitos de cifrado del CRA para fabricantes de productos

La Cyber Resilience Act (CRA, Regulation (EU) 2024/2847, Reglamento de Ciberresiliencia) establece su requisito de cifrado en el Anexo I, Parte I (2)(e): proteger la confidencialidad de los datos almacenados, transmitidos o tratados de otro modo, por ejemplo cifrando los datos pertinentes en reposo o en tránsito mediante mecanismos que reflejen el estado de la técnica. No menciona algoritmos poscuánticos. Las obligaciones de notificación del artículo 14 se aplican desde el 11 de septiembre de 2026 y el reglamento se aplica en su totalidad desde el 11 de diciembre de 2027, de modo que los equipos de producto están eligiendo ya la criptografía de dispositivos que seguirán recibiendo soporte mucho después de esas fechas.

Qué dice el requisito y qué no dice

El Anexo I tiene dos partes. La Parte I enumera los requisitos esenciales de ciberseguridad del propio producto, entre ellos su comercialización sin vulnerabilidades explotables conocidas, una configuración segura por defecto y el requisito de confidencialidad del punto (2)(e). La Parte II enumera los requisitos de gestión de vulnerabilidades que se extienden a lo largo del periodo de soporte declarado por el fabricante. El texto está disponible en EUR-Lex (Regulation (EU) 2024/2847) y nuestro resumen fechado se encuentra en la página dedicada al reglamento CRA.

De ello se derivan tres consecuencias para un equipo de producto:

• El requisito se basa en resultados. Menciona la confidencialidad y los mecanismos que reflejen el estado de la técnica, no RSA, ni ECDH, ni ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, normalizado en NIST FIPS 203).
• La referencia evoluciona. Un mecanismo defendible en el momento de la evaluación de la conformidad puede dejar de serlo mientras el producto sigue recibiendo soporte.
• Nada en el texto le obliga a incorporar hoy criptografía poscuántica. Del mismo modo, nada salva un diseño cuya criptografía no pueda modificarse cuando evolucione el estado de la técnica.

Es posible que normas armonizadas detallen más adelante cómo cumplir el Anexo I, y la conformidad con una norma armonizada publicada en el Diario Oficial otorga una presunción de conformidad. Mientras dicha norma no exista ni se haya publicado, su contenido es desconocido: no planifique basándose en suposiciones sobre lo que dirá acerca de la criptografía. El contenido jurídico de esta página es informativo y no constituye asesoramiento jurídico.

Las fechas del calendario del CRA

Para un dispositivo con un periodo de soporte de varios años, el horizonte de planificación no es 2027. Es la última fecha en la que todavía debe proporcionar actualizaciones de seguridad a las unidades vendidas justo antes del fin del soporte.

Qué puede significar razonablemente el estado de la técnica a lo largo de un periodo de soporte

El CRA no publica una lista de algoritmos, por lo que la forma honesta de razonar sobre el estado de la técnica es examinar lo que las autoridades públicas y los organismos de normalización han publicado efectivamente, respetando su estatus.

Fuentes primarias: la hoja de ruta de la UE, BSI TR-02102-1, las preguntas frecuentes de la ANSSI sobre PQC, NIST IR 8547 ipd y los plazos de migración del NCSC.

Nuestra interpretación, presentada expresamente como tal: ninguno de estos textos convierte la criptografía poscuántica en una obligación del CRA, y ninguna autoridad ha afirmado que la criptografía clásica incumpla hoy el Anexo I. Sin embargo, un producto cuyo periodo de soporte se extiende más allá de 2030 se comercializa en un periodo para el que varias autoridades ya han publicado fechas de retirada del establecimiento de claves clásico. La posición técnica defendible es, por tanto, la agilidad: la capacidad de cambiar de algoritmo mediante una actualización ordinaria, documentada en el expediente de diseño.

Criptoagilidad en el firmware

La agilidad es una propiedad de la implementación, no una frase en una política. Cuatro preguntas determinan si un dispositivo ya comercializado puede seguir el estado de la técnica, y es más fácil responderlas antes del tape-out que después. Tratamos el tema en mayor profundidad en el artículo sobre criptoagilidad.

• Negociación, no constantes. Los identificadores de algoritmo, los grupos con nombre y los tamaños de clave proceden de la configuración o del handshake del protocolo, nunca de una constante compilada ni de un búfer de tamaño fijo. Las claves y los textos cifrados de ML-KEM son mucho mayores que los valores de curva elíptica, por lo que una estructura dimensionada para claves de 32 bytes constituye un bloqueo a nivel de hardware.
• Margen. Prevea memoria flash, RAM y tiempo de handshake para material de clave de mayor tamaño. Mídalo en el dispositivo de destino, no en una estación de trabajo.
• Frontera de la biblioteca. Invoque la criptografía a través de una interfaz interna ligera para que el proveedor pueda sustituirse. Fije la versión mínima en la compilación: los grupos TLS de ML-KEM requieren OpenSSL 3.5 o posterior.
• Alternativa clásica. Dé preferencia al establecimiento de claves híbrido y mantenga un grupo clásico detrás, de modo que el dispositivo siga conectándose cuando el extremo remoto sea más antiguo.

En una compilación de prueba, compruebe qué puede ofrecer realmente la pila y qué negocia un endpoint del dispositivo:

openssl version
# ML-KEM TLS groups require OpenSSL 3.5 or later
openssl list -tls-groups

# read-only test against a device endpoint, hybrid first, classical fallback
openssl s_client -connect device.example.com:443 -tls1_3 \
  -groups X25519MLKEM768:X25519 </dev/null

El grupo híbrido que conviene preferir hoy es X25519MLKEM768 (codepoint IANA 0x11EC), con SecP256r1MLKEM768 o SecP384r1MLKEM1024 cuando se requiera una curva del NIST; el perfil del IETF para el acuerdo de claves híbrido poscuántico y tradicional en TLS 1.3 es el RFC 10024 (agosto de 2026). Los grupos preestándar basados en borradores de Kyber, como X25519Kyber768Draft00, están obsoletos y deberían eliminarse del firmware de los dispositivos. Realice pruebas en preproducción antes de pasar a producción y mantenga el grupo clásico en la lista.

Los planos de gestión de dispositivos merecen la misma revisión. OpenSSH 9.9 añadió mlkem768x25519-sha256, OpenSSH 10.0 lo convirtió en el acuerdo de claves por defecto y OpenSSH 10.1 emite una advertencia cuando una conexión negocia un acuerdo de claves no poscuántico, según las notas de versión de OpenSSH.

Firma de actualizaciones: la parte que no podrá corregir más tarde

Las claves de transporte se renuevan en cada sesión. Una raíz de confianza grabada en el silicio, no. El tráfico registrado solo está protegido por el intercambio de claves, motivo por el cual el establecimiento de claves híbrido es lo primero, mientras que las firmas pueden migrarse más adelante; pero la firma de actualizaciones es la única vía de firma en la que una migración tardía puede resultar imposible, porque el verificador reside en código de arranque inmutable.

Medidas prácticas, por orden de valor:

1. Prevea más de una ranura de verificación o jerarquía de claves, de modo que un nuevo algoritmo de firma pueda introducirse mediante una actualización y no mediante una retirada del producto.
2. Decida ya qué familia de firma poscuántica podría aceptar el producto: ML-DSA (FIPS 204), SLH-DSA (FIPS 205), o los esquemas con estado basados en hash LMS y XMSS de NIST SP 800-208, que requieren una gestión estricta del estado para evitar la reutilización de una clave de un solo uso.
3. Mantenga el código y los parámetros de verificación de firmas en una etapa actualizable cuando el modelo de seguridad lo permita, limitando la etapa inmutable a la verificación de esa etapa actualizable.
4. Documente la renovación de claves: quién custodia las claves, cómo se retira una clave comprometida u obsoleta y cómo un dispositivo desplegado recibe la nueva.

CNSA 2.0 ya fija finales de 2030 para el uso exclusivo de sus algoritmos en la firma de software y firmware de los National Security Systems de EE. UU. No se trata de una obligación de la UE, pero es una fecha publicada para el mismo problema técnico y constituye un elemento razonable cuando argumente qué significa el estado de la técnica para un producto con soporte más allá de 2030.

Relacionar el requisito con evidencias

Siguiente paso: medir lo que su producto muestra en la red

Antes de redactar una sola línea de documentación del CRA, averigüe qué negocian realmente hoy sus propios endpoints y servidores de actualización. Puede analizar su dominio con PQC Status de forma gratuita para ver las versiones de TLS, los grupos híbridos ML-KEM, los conjuntos de cifrado y la cadena de certificados que observa un cliente externo. Un análisis 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 y avance después hacia el firmware: tamaños de clave en las estructuras, versiones de las bibliotecas en la compilación y número de ranuras de verificación en su cadena de arranque.