A prueba de ataques cuánticos con CNSA 2.0: lo que los contratistas de defensa necesitan para cumplir con NIAP y FIPS 140-3.

Respuesta rápida: CNSA 2.0 es el conjunto de algoritmos resistentes a la computación cuántica de la NSA para los Sistemas de Seguridad Nacional, que requiere ML-KEM-1024 y ML-DSA-87 con plazos específicos para cada categoría, desde el 1 de enero de 2027 (fecha límite de adquisición) hasta la transición completa el 31 de diciembre de 2033. Para los contratistas de defensa y la base industrial de defensa en general, el cumplimiento no es una simple autodeclaración: se realiza mediante la validación del Perfil de Protección NIAP y la certificación CMVP (FIPS 140-3), ambas con retrasos en la validación que hacen que la fecha límite de adquisición de 2027 sea la que realmente importa, y no las fechas más lejanas de 2033 o 2035.

No es ningún secreto que una computadora cuántica relevante para la criptografía (CRQC) tendría el poder de vulnerar los sistemas criptográficos de clave pública de uso generalizado, empleados actualmente para el intercambio de claves asimétricas y las firmas digitales, con consecuencias potencialmente devastadoras para los sistemas. Los sistemas de seguridad nacional (NSS) utilizan la criptografía de clave pública como componente fundamental para proteger la confidencialidad, la integridad y la autenticidad de la información de seguridad nacional.

Anne Neuberger, la principal asesora de ciberseguridad de la Casa Blanca, habló recientemente sobre este tema en el Royal United Services Institute (RUSI) de Londres. Afirmó que la publicación de estos nuevos algoritmos era «un momento trascendental» porque demuestra un progreso real hacia la próxima generación de criptografía.

Explicó que el motivo de este cambio es la preocupación por los CRQC, que, según sus palabras, podrían romper el cifrado "que es la base de la protección de los secretos de seguridad tanto corporativos como nacionales".

Entendamos qué es el Conjunto de algoritmos de seguridad nacional comercial 2.0 (CNSA 2.0).

Puntos Clave

• CNSA 2.0 requiere ML-KEM-1024 y ML-DSA-87 para los Sistemas de Seguridad Nacional, reemplazando el conjunto clásico CNSA 1.0 y el conjunto B anterior.
• El 1 de enero de 2027 es la fecha límite para la adquisición: a partir de esa fecha, todas las nuevas adquisiciones de NSS deberán ser compatibles con los algoritmos CNSA 2.0.
• Para los contratistas de defensa, el cumplimiento no es una declaración voluntaria. Se lleva a cabo mediante la validación del Perfil de Protección NIAP y la certificación CMVP (FIPS 140-3), y ambas tienen plazos de validación que se miden en meses, no en semanas.
• Este requisito se extiende a lo largo de la cadena de suministro: los contratistas principales, los proveedores de segundo nivel y cualquier vendedor comercial que venda componentes en un entorno clasificado o NSS están incluidos en el alcance.
• CNSA 2.0 es un requisito independiente de CMMC, liderado por la NSA, y la suspensión de la Fase II de CMMC por parte del Departamento de Guerra en julio de 2026 no afecta el cronograma de CNSA 2.0.

CNSA 2.0

El CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) es el estándar de cifrado de próxima generación desarrollado por la NSA para proteger los sistemas más sensibles del país, especialmente ante la amenaza real que representa la computación cuántica. Estos algoritmos están diseñados específicamente para ser resistentes a la computación cuántica, lo que garantiza la seguridad a largo plazo incluso en un futuro donde el cifrado tradicional podría ser vulnerado.

CNSA 2.0 será obligatorio para todos los Sistemas de Seguridad Nacional (SSN) que utilicen algoritmos de estándar público, ya sean de reciente diseño o ya implementados. Los conjuntos de cifrado antiguos, como Suite B o CNSA 1.0 , ya no serán suficientes; todos deberán migrar a CNSA 2.0. Según la NSA, esta medida garantiza que los sistemas sean «seguros hoy y resilientes mañana».

¿Qué políticas deben seguirse para cumplir con los requisitos del algoritmo NSS?

Los algoritmos incluidos en CNSA 2.0 fueron seleccionados de entre los estandarizados por el NIST , la autoridad oficial del gobierno estadounidense en materia de cifrado comercial. La NSA eligió las opciones con mejor rendimiento para las necesidades de seguridad nacional, no solo robustas, sino también optimizadas para operaciones de misión crítica. La NSA ha probado y analizado estos algoritmos y considera que son lo suficientemente robustos como para proteger la seguridad nacional de Estados Unidos a largo plazo.

La agencia considera que CNSA 2.0 es apto para proteger desde comunicaciones en el campo de batalla hasta cables diplomáticos. No dejan a los usuarios a oscuras. La NSA está colaborando con el IETF para publicar RFC (Solicitudes de Comentarios), guías técnicas que ayudarán a integrar estos algoritmos de forma segura en sistemas reales. El principio fundamental es que no se trata solo de qué algoritmos se utilizan, sino de cómo se utilizan. 

Ni siquiera los sistemas que ya están en funcionamiento se libran de esta normativa. Salvo que reciban una exención formal, todos los equipos desplegados deben actualizarse oportunamente. Esta regla está respaldada por memorandos de seguridad clave como NSM-8 y NSM-10, y políticas como CNSSP 11 y CNSSP 15. 

Los distintos tipos de sistemas seguirán diferentes rutas de transición. Los dispositivos de grado militar o de alta gama se adaptarán según las normas CJCSN 6510 y CNSSAM 01-07-NSM, mientras que los equipos comerciales se mantendrán en CNSA 1.0 por ahora, pero deberán migrar entre 2025 y 2030, dependiendo del sistema. Todas las implementaciones de QR deberán obtener la certificación NIAP y la validación NIST; no se permiten atajos. 

Estas directrices no son solo para funcionarios gubernamentales. La NSA está haciendo público el plan CNSA 2.0 para que los proveedores, socios de la industria y cualquier persona interesada en interactuar con el NSS puedan comenzar a prepararse. Esto incluye la actualización de dispositivos, software y plataformas de comunicación segura.  

A medida que la NSA avanza con CNSA 2.0, también se lleva a cabo una revisión de la terminología técnica. Los algoritmos como ML-KEM y ML-DSA son ahora los únicos nombres aprobados bajo el estándar, reemplazando sus nombres anteriores, CRYSTALS-Kyber y CRYSTALS-Dilithium. Solo se permiten las versiones finales, publicadas como FIPS 203 y 204. Cualquier versión anterior o modificada, incluso si tiene una denominación similar, no cumple con CNSA 2.0.

La siguiente tabla enumera los algoritmos y sus funciones, especificaciones y parámetros. 

Algoritmo	Función	Especificación	Parámetros
Algoritmos de propósito general
Advanced Encryption Standard (AES)	Cifrado de bloques simétricos para la protección de la información	PUBLICACIÓN FIPS 197	Utilice claves de 256 bits para todos los niveles de clasificación.
ML-KEM (anteriormente CRYSTALS Kyber)	Algoritmo asimétrico para el establecimiento de claves	PUBLICACIÓN FIPS 203	ML-KEM-1024 para todos los niveles de clasificación.
ML-DSA (anteriormente CRYSTALS Dilithium)	Algoritmo asimétrico para firmas digitales en cualquier caso de uso, incluida la firma de firmware y software	PUBLICACIÓN FIPS 204	ML-DSA-87 para todos los niveles de clasificación.
Algoritmo hash seguro (SHA)	Algoritmo para calcular una representación condensada de información	FIPS PUB 180-4	Utilice SHA-384 o SHA-512 para todos los niveles de clasificación.
Algoritmos permitidos en aplicaciones específicas
Firma Leighton-Micali (LMS)	Algoritmo asimétrico para firmar digitalmente firmware y software	FIPS PUB 800-208	Todos los parámetros están aprobados para todos los niveles de clasificación. Se recomienda LMS SHA 256/192.
Esquema de firma Xtended Merkle (XMSS)	Algoritmo asimétrico para firmar digitalmente firmware y software	FIPS PUB 800-208	Todos los parámetros aprobados para todos los niveles de clasificación.
Algoritmo hash seguro 3 (SHA3)	Algoritmo utilizado para calcular una representación condensada de información como parte de la integridad del hardware	PUBLICACIÓN FIPS 202	SHA3-384 o SHA3-512 permitidos únicamente para funcionalidad de hardware interno (por ejemplo, comprobaciones de integridad de arranque)

Cronograma de transición y hitos de implementación de CNSA 2.0

La NSA pretende que todos los Sistemas de Seguridad Nacional (NSS) sean resistentes a la computación cuántica para 2035, en consonancia con los objetivos establecidos en el Memorando de Seguridad Nacional-10 (NSM-10). Si bien 2035 es el objetivo final, la transición comienza mucho antes, con hitos clave descritos en la política actualizada CNSSP 15. 

Para los sistemas existentes, cualquier NSS que ya esté validado bajo un perfil NIAP o CSfC seguirá aprobado hasta el final de su período de validación. El período de gracia para los NSS que aún no cumplían con CNSA 1.0 ya ha finalizado: dichos sistemas debían, en un plazo de seis meses a partir de la actualización de CNSSP 15, cumplir con CNSA 2.0 o presentar una solicitud de exención en un plazo de 90 días. Las organizaciones que aún se acojan a una exención vigente deben considerarla como una solución temporal, no como una estrategia de cumplimiento a largo plazo. 

A partir del 1 de enero de 2027, todas las nuevas adquisiciones para el NSS deberán ser compatibles con los algoritmos CNSA 2.0, salvo que se indique claramente una excepción. Para el 31 de diciembre de 2030, todos los equipos y servicios que no sean compatibles con CNSA 2.0 deberán ser retirados gradualmente. Y para el 31 de diciembre de 2031, el uso de los algoritmos CNSA 2.0 será obligatorio en todos los ámbitos, salvo que se especifique lo contrario. 

La transición no se producirá de un día para otro. La NSA prevé un período híbrido en el que los sistemas podrían utilizar tanto CNSA 1.0 como CNSA 2.0, según la madurez de sus respectivos componentes. Los sistemas nuevos y las actualizaciones deberían diseñarse para priorizar CNSA 2.0, y a medida que se finalicen los estándares, estos sistemas deberían, con el tiempo, aceptar únicamente algoritmos CNSA 2.0. 

Las organizaciones de desarrollo de estándares (SDO, por sus siglas en inglés), como la IETF, seguirán publicando material de apoyo, como los RFC. La NSA colabora activamente con ellas para garantizar que estos documentos estén disponibles y sirvan de guía para la configuración de protocolos, además de ayudar a los proveedores a adoptar soluciones resistentes a la computación cuántica de forma eficaz. 

La NSA prevé que todas las transiciones de equipos estén completadas para el 31 de diciembre de 2030, mucho antes de la fecha límite de 2035, lo que permitirá que los sistemas seguros estén preparados para el futuro a tiempo para las amenazas cuánticas a gran escala. 

Cumplimiento de la norma CNSA 2.0 para contratistas de defensa y la DIB.

La norma CNSA 2.0 es obligatoria para los Sistemas de Seguridad Nacional, pero su alcance va mucho más allá de las agencias que los operan. Todos los contratistas de defensa, proveedores de nivel inferior y vendedores comerciales que comercializan componentes destinados a entornos clasificados o sujetos a la normativa NSS están sujetos a ella, ya que el contratista principal debe demostrar el cumplimiento de la norma CNSA 2.0 para todo el sistema, no solo para las piezas que fabrica directamente. Esto extiende el requisito a lo largo de la cadena de suministro, del mismo modo que las cláusulas DFARS ya lo hacen para otras obligaciones de ciberseguridad.

La validación NIAP no es lo mismo que la validación FIPS.

Un error común es considerar la validación FIPS 140-3 como suficiente por sí sola. Si bien es necesaria, no basta para su uso en sistemas de seguridad nacional (NSS). Las directrices de la NSA, bajo la norma CNSSP 11, exigen que los productos criptográficos destinados a NSS también completen la validación NIAP conforme a un perfil de protección aprobado que incorpore algoritmos CNSA 2.0, configurados correctamente según la norma CNSSP 15. Un contratista puede poseer un certificado FIPS 140-3 vigente y aun así no superar la revisión de adquisiciones de NSS si el producto no ha superado la validación NIAP por separado. Ambos procesos tienen plazos independientes y deben ejecutarse en paralelo con suficiente antelación a la adjudicación prevista del contrato, no después de la publicación de la solicitud de propuestas (RFP).

El retraso en la validación es la verdadera limitación.

La fecha límite de adquisición del 1 de enero de 2027 es inamovible, pero el proceso previo no es rápido. La validación CMVP (FIPS 140-3) ha tardado, en promedio, más de 500 días desde la presentación hasta la obtención de un certificado activo, y la infraestructura de pruebas de algoritmos post-cuánticos dentro de este proceso es más reciente y menos predecible que la del algoritmo clásico. Un contratista que presente un módulo compatible con PQC a CMVP a mediados de 2026 no debería esperar un certificado activo antes de que entre en vigor la fecha límite de adquisición. Los contratistas que evalúan proveedores, o que son evaluados ellos mismos, deben preguntar no solo "¿soportan los algoritmos CNSA 2.0?", sino también "¿en qué posición se encuentra su certificado en las colas de CMVP y NIAP, y cuál es la fecha prevista de obtención del certificado?".

¿Qué aparece en el lenguaje de contratación y en las solicitudes de propuestas (RFP)?

Los responsables de contratación ya están incluyendo la compatibilidad con CNSA 2.0 en los criterios de evaluación antes de la fase de 2027, y el efecto práctico es que un proveedor sin un cronograma de validación creíble queda descalificado incluso antes de que se evalúe su mérito técnico. Los contratistas deben esperar que el lenguaje de contratación solicite, como mínimo: qué algoritmos y conjuntos de parámetros de CNSA 2.0 admite un producto (ML-KEM-1024, ML-DSA-87, AES-256, SHA-384/512 y, cuando corresponda, LMS o XMSS para la firma del firmware), el estado actual de validación FIPS 140-3 y NIAP con los números de certificado disponibles, un historial documentado de exenciones si algún componente aún no cumple con los requisitos, y un plan de transición híbrida si el producto actualmente utiliza algoritmos de CNSA 1.0 durante el período de migración.

CMMC es una vía independiente y su estado ha cambiado.

El programa CNSA 2.0 se suele mencionar junto con el programa de Certificación del Modelo de Madurez de Ciberseguridad (CMMC), pero ambos se administran por separado y los contratistas de defensa no deben confundir sus plazos. El 13 de julio de 2026, el Departamento de Guerra suspendió la Fase II del CMMC, el requisito de evaluación de terceros C3PAO que debía entrar en vigor el 10 de noviembre de 2026, y creó un Grupo de Trabajo de Reforma del CMMC para revisar el programa. Los requisitos de autoevaluación de la Fase I, DFARS 252.204-7012 y las obligaciones de cumplimiento de NIST SP 800-171 siguen vigentes durante la revisión; la suspensión interrumpió el mecanismo de evaluación de terceros, no la obligación subyacente de proteger la información de defensa protegida. La fase de adquisición de enero de 2027 del CNSA 2.0 no se ve afectada por la pausa del CMMC; se trata de un requisito NSS liderado por la NSA, no de un entregable del CMMC, y los contratistas deben continuar el trabajo de validación en ambos casos de forma independiente.

Lista de verificación práctica de pruebas para contratistas de defensa

• Inventario de algoritmos: Una lista documentada de todos los módulos criptográficos del producto, los algoritmos y conjuntos de parámetros que utiliza cada uno, y si cada uno es CNSA 1.0, CNSA 2.0 o híbrido.
• Estado de validación: Números de certificado FIPS 140-3/CMVP actuales y estado de validación del perfil de protección NIAP, o una proyección fechada de cuándo estarán activos.
• Documentación de exención: cualquier solicitud de exención activa, su fecha de presentación y el plan de remediación vinculado a la misma.
• Certificación de subnivel: Existen pruebas de que los componentes procedentes de proveedores de segundo nivel cuentan con su propia documentación de conformidad con la norma CNSA 2.0, ya que la certificación de un proveedor principal es tan sólida como la de su cadena de suministro.
• Plan de transición híbrida: Para los productos que aún utilizan algoritmos CNSA 1.0, se incluye un plan con fecha que muestra cómo y cuándo CNSA 2.0 se convertirá en la configuración preferida y, posteriormente, exclusiva.

Ninguno de estos trámites es opcional. Se trata del paquete de pruebas que un oficial de contratación o el equipo de cumplimiento del contratista principal solicitará una vez que se active la fase de adquisición, y elaborarlo a posteriori, en lugar de hacerlo en paralelo con el desarrollo del producto, es lo que convierte una oportunidad de adquisición en una descalificación. Para conocer el proceso completo de validación, los criterios de evaluación de la solicitud de propuestas y la lista de verificación de pruebas, consulte nuestra Guía de Cumplimiento CNSA 2.0 para Contratistas de Defensa y la DIB.

Método general para la transición a los algoritmos CNSA 2.0

A continuación se presentan algunos puntos a tener en cuenta al realizar la transición a los algoritmos CNSA 2.0: 

• NIAP actualizará los perfiles de protección para indicar claramente que los productos deben ser compatibles con los algoritmos CNSA 2.0, basados ​​en las normas NIST y otras normas internacionales. 
• Todo el hardware o software nuevo debe cumplir con los nuevos perfiles. Los sistemas más antiguos también deben cumplirlos cuando se sometan a su próxima actualización para mantener la certificación NIAP. 
• En cuanto las soluciones CNSA 2.0, una vez probadas y validadas, estén listas, deberán convertirse en la configuración predeterminada en todos los sistemas que cumplan los requisitos. 
• El cronograma para la eliminación de algoritmos antiguos y vulnerables se regirá por los perfiles de protección de NIAP y los ciclos de actualización tecnológica de NSM-10. 
• Si los sistemas heredados no se pueden actualizar periódicamente, necesitarán una exención oficial y un plan claro para el cumplimiento futuro para poder seguir funcionando. 

Otros requisitos de la CNSA 2.0 para NSS

El siguiente cronograma forma parte del esfuerzo más amplio de la NSA para preparar los sistemas de seguridad nacional para el futuro, anticipando el desarrollo de potentes computadoras cuánticas. El lanzamiento gradual brinda a la industria y a las agencias tiempo para adaptarse. 

• La firma de software y firmware debe comenzar a transitar de inmediato, y se debe preferir CNSA 2.0 para 2025 y utilizarlo exclusivamente para 2030. 
• Los navegadores web, servidores y servicios en la nube deben admitir y preferir CNSA 2.0 para 2025 y pasar a su uso exclusivo para 2033. 
• Los equipos de red tradicionales, como las VPN y los enrutadores, deberían admitir y preferir CNSA 2.0 para 2026 y utilizarlo exclusivamente para 2030. 
• Se espera que los sistemas operativos admitan y prefieran CNSA 2.0 para 2027 y lo adopten exclusivamente para 2033. 
• Los equipos de nicho, como los dispositivos restringidos y los grandes sistemas PKI, deberían respaldar y preferir la CNSA 2.0 para 2030 y utilizarla exclusivamente para 2033. 
• Las aplicaciones personalizadas y los sistemas heredados deben actualizarse o reemplazarse por completo para cumplir con los estándares CNSA 2.0 para 2033. 

Profundicemos en los detalles técnicos de los algoritmos de firma basados ​​en funciones hash y exploremos su importancia en la criptografía postcuántica (PQC).

Comprensión de la firma basada en hash en CNSA 2.0

Los esquemas de firma basados ​​en funciones hash son una parte fundamental de la estrategia de resistencia cuántica de CNSA 2.0 para proteger el software y el firmware de larga duración. Estos algoritmos son idóneos para tareas en las que una firma debe mantener su fiabilidad durante años, como la firma de firmware.  

Los dos principales algoritmos basados ​​en hash aprobados por la NSA para los Sistemas de Seguridad Nacional (NSS) son: 

• LMS (Esquema de firma Leighton-Micali) 
• XMSS (Esquema de firma Merkle ampliado) 

Ambos métodos están estandarizados por el NIST en la norma SP 800-208 y han sido validados conforme a las Normas Federales de Procesamiento de Información (FIPS) . La NSA recomienda su uso, en particular, en sistemas que requieren mecanismos de firma con estado, donde cada firma debe ser rastreada para garantizar que no se reutilice una clave, lo cual es un requisito fundamental para mantener la seguridad a lo largo del tiempo.

La NSA prefiere LMS con SHA-256, según se define en la Sección 4.2 del estándar NIST. Esta configuración específica ofrece un buen equilibrio entre rendimiento y seguridad, y es ideal para dispositivos integrados o sistemas de hardware que no suelen recibir actualizaciones frecuentes. 

Por otro lado, HSS (Esquema de Firma Jerárquica) y XMSSMT (XMSS multiárbol), aunque relacionados con LMS/XMSS, no están permitidos en CNSA 2.0. La NSA ha declarado explícitamente que estas variantes multiárbol no cumplen con los estándares requeridos para el uso de NSS. 

Otro algoritmo, SLH-DSA (también conocido como SPHINCS+), no está aprobado para su uso en NSS bajo la CNSA 2.0, a pesar de estar basado en hash. Esto garantiza que solo los algoritmos mejor evaluados y listos para su implementación sean confiables para fines de seguridad nacional. 

Política de uso de SHA-3 y funciones hash según CNSA 2.0

En CNSA 2.0, el uso de SHA-3 solo está permitido en circunstancias muy limitadas. En concreto, los proveedores pueden usar SHA3-384 o SHA3-512 en componentes de hardware internos que no interactúan con sistemas externos. Esto incluye casos de uso como el arranque seguro o las comprobaciones de integridad del sistema, donde el proceso criptográfico permanece completamente dentro de un entorno controlado por el proveedor. La NSA ha hecho esta excepción para acelerar la transición a la criptografía postcuántica sin interrumpir los procesos internos establecidos. 

Sin embargo, SHA-3 no está aprobado como función hash de propósito general en CNSA 2.0. Su uso solo está permitido cuando está claramente definido por un estándar criptográfico aprobado, como dentro de LMS según lo especificado por NIST SP 800-208, o para aplicaciones internas muy específicas. De manera similar, SHAKE, otra variante de la familia SHA-3, tampoco está permitido para un uso criptográfico generalizado. La postura de la NSA es clara: depender de SHA-3 fuera de sus casos de uso aprobados crea una complejidad innecesaria, aumenta la carga de las pruebas de interoperabilidad y puede socavar la confiabilidad de los sistemas diseñados para cumplir con estrictos estándares de seguridad nacional.

La familia SHA-2, especialmente SHA-384 y SHA-512, sigue siendo la base de la política de funciones hash de CNSA 2.0. SHA-384 continúa siendo el estándar, mientras que SHA-512 está permitido cuando el rendimiento lo justifica, aunque los sistemas que lo utilizan deben evaluar cuidadosamente los posibles impactos en la interoperabilidad.  

Si un sistema criptográfico incorpora SHA-3 u otras variantes de hash como parte de una función definida dentro de un algoritmo aprobado por la NSA, como LMS o XMSS, esto está permitido, pero solo dentro de los límites del diseño de dicho algoritmo. La aplicación general o externa de SHA-3 fuera de estas definiciones sigue sin cumplir con la norma CNSA 2.0. 

La NSA ha dejado abierta la posibilidad de incluir en el futuro otros algoritmos aprobados por el NIST, pero solo bajo condiciones muy específicas: el algoritmo debe ser ampliamente adoptado, superar las evaluaciones de seguridad independientes de la NSA y mantener la compatibilidad con otros sistemas. Por ahora, la prioridad sigue siendo utilizar el conjunto actual de algoritmos rigurosamente probados para evitar la fragmentación entre los sistemas que protegen los datos de seguridad nacional.

Requerimientos de Validación

Al utilizar LMS o XMSS, hay diferentes pasos de validación dependiendo de lo que haga el sistema: 

• Si un sistema solo verifica firmas, debe pasar la prueba CAVP (Programa de Validación de Algoritmos Criptográficos). 

• Si también genera firmas (es decir, actúa como firmante), debe validarse bajo CMVP (Programa de Validación de Módulos Criptográficos). 

La generación de firmas es más sensible porque implica la gestión del estado criptográfico, que, si se utiliza incorrectamente (como la reutilización de claves), puede exponer el sistema a ataques. Por eso, no se permiten exenciones; la validación es obligatoria. 

La NSA subraya que la firma digital y la gestión del estado deberían implementarse idealmente en hardware, como un HSM (Módulo de Seguridad de Hardware) , para minimizar los errores humanos o de software. Incluso durante las operaciones de copia de seguridad, los estados clave deben conservarse para evitar cualquier posibilidad de reutilización del estado.

Se espera que los proveedores que no forman parte de NSS, pero que proporcionan código o productos que interactúan con NSS, cumplan con los mismos estándares de calidad criptográfica. Esto significa que cualquier código involucrado en la verificación de firmas debe ser capaz de superar la validación CAVP, incluso si el firmante no forma parte de NSS. 

Para las evaluaciones de productos comerciales, la NSA no espera que la generación de firmas se produzca dentro del "Objetivo de Evaluación" (TOE), sino únicamente la verificación de firmas. Por lo tanto, las pruebas CAVP son suficientes para demostrar el cumplimiento de la norma CNSA 2.0 en la mayoría de los casos. 

A menudo, el firmware no se puede actualizar una vez implementado. Por lo tanto, elegir ahora un algoritmo de firma resistente a la computación cuántica, como LMS o XMSS, para el firmware es crucial. La NSA insiste en iniciar la transición cuanto antes, en lugar de esperar a que otros algoritmos (como ML-DSA) se validen. Esto garantiza que exista una raíz de confianza criptográfica a largo plazo antes incluso de que el resto del sistema comience a actualizarse a los estándares post-cuánticos. 

Alternativas cuánticas para NSS

Para preparar los Sistemas de Seguridad Nacional (NSS) para la era cuántica, la NSA ha abordado opciones criptográficas alternativas, como: 

• Las claves precompartidas (PSK) pueden ayudar a reducir las amenazas cuánticas, pero su eficacia puede variar; las organizaciones deben consultar la guía de la NSA o CSfC antes de confiar en ellas. 
• Las computadoras cuánticas plantean un riesgo mucho mayor para la criptografía de clave pública que para la criptografía simétrica; los algoritmos simétricos con tamaños de clave grandes (como los de CNSA 2.0) todavía se consideran seguros. 
• La NSA está actuando ahora frente a las amenazas cuánticas porque los Sistemas de Seguridad Nacional (NSS) tienen una vida útil prolongada, los sistemas construidos hoy pueden estar en uso durante décadas y necesitan protección a prueba de futuro. 
• La distribución de claves cuánticas (QKD) utiliza la física cuántica para compartir de forma segura claves de cifrado, pero no ofrece protección criptográfica completa y no se considera una solución práctica para NSS. 
• La NSA no recomienda el uso de QKD para la NSS y aconseja a las agencias que no inviertan ni implementen sistemas QKD sin una consulta directa. 
• Los generadores de números aleatorios cuánticos (RNG) utilizan efectos cuánticos para generar aleatoriedad; cualquier RNG certificado por estándares apropiados es aceptable si se implementa correctamente. 

Adaptación de la criptografía híbrida

El objetivo es equilibrar una protección sólida con una implementación práctica y basada en estándares, teniendo en cuenta la compatibilidad con versiones anteriores. Los siguientes puntos describen las consideraciones necesarias y la orientación de la NSA. 

• Una solución híbrida combina múltiples algoritmos criptográficos (clásicos + resistentes a los cuánticos) para fortalecer el intercambio de claves o la autenticación. 
• La NSA confía únicamente en los algoritmos CNSA 2.0 y no requiere soluciones híbridas para la seguridad del NSS, aunque se pueden utilizar configuraciones híbridas por motivos de interoperabilidad o limitaciones técnicas. 
• El uso de criptografía híbrida puede añadir complejidad a la implementación y las pruebas, aumentando el riesgo de errores y fallos de configuración. 
• Las soluciones híbridas también pueden ralentizar los esfuerzos de estandarización, ya que los protocolos deben acordar cómo combinar y gestionar múltiples algoritmos. 
• En casos como IKEv2 (un protocolo VPN), la NSA apoya una solución híbrida debido a restricciones técnicas con límites en el tamaño de la clave pública: primero se utiliza una clave más pequeña y luego una cifrada más grande. 
• La NSA no apoya el uso de soluciones híbridas o no estándar resistentes a la computación cuántica en los sistemas de misión, a menos que se indique específicamente; dichas soluciones pueden provocar incompatibilidad o ineficiencia. 
• En casos especiales, se pueden utilizar soluciones híbridas con superposiciones de clave simétrica (como RFC 8773 o 8784), pero estas son excepciones, no la norma. 

¿Cómo puede ayudar la consultoría de cifrado?

Si te preguntas por dónde empezar tu camino hacia la era post-cuántica, Encryption Consulting está aquí para ayudarte. Puedes contar con nosotros como tu socio de confianza; te guiaremos en cada paso con claridad, seguridad y experiencia práctica.

• Descubrimiento e inventario criptográfico

  Esta es la fase fundamental donde generamos visibilidad de su infraestructura criptográfica existente. Identificamos qué sistemas están en riesgo ante amenazas cuánticas y evaluamos la preparación de su configuración actual, incluyendo su PKI, HSM y aplicaciones. El objetivo es identificar qué activos criptográficos existen, dónde se utilizan y su nivel de criticidad. Escaneo exhaustivo de certificados, claves criptográficas, algoritmos, bibliotecas y protocolos en todo su entorno de TI, incluyendo puntos finales, aplicaciones, API, dispositivos de red, bases de datos y sistemas embebidos.

  Identificación de todos los sistemas (locales, en la nube, híbridos) que utilizan criptografía, como servidores de autenticación, HSM, balanceadores de carga, VPN y más. Recopilación de metadatos clave, como tipos de algoritmos, tamaños de clave, fechas de vencimiento, fuentes de emisión y cadenas de certificados. Creación de una base de datos de inventario detallada de todos los componentes criptográficos que sirva como base para la evaluación y planificación de riesgos.

• Evaluación PQC

  Una vez establecida la visibilidad, realizamos entrevistas con las partes interesadas clave para evaluar el panorama criptográfico en cuanto a vulnerabilidad cuántica y determinar la preparación de su entorno para la transición a PQC. Analizamos los elementos criptográficos para detectar la exposición a amenazas cuánticas, en particular aquellos que dependen de RSA, ECC y otros algoritmos que pronto serán vulnerados. Revisamos la configuración de la infraestructura de clave pública y los módulos de seguridad de hardware , y si admiten la integración de algoritmos post-cuánticos. Analizamos las aplicaciones en busca de dependencias criptográficas codificadas e identificamos aquellas que requieren refactorización. Entregamos un informe detallado con un inventario de activos criptográficos vulnerables, clasificaciones de gravedad del riesgo y priorización para la migración.

• Estrategia y hoja de ruta de PQC

  Una vez identificados los riesgos, trabajamos con usted para desarrollar una estrategia de migración personalizada y por fases que se ajuste a sus requisitos comerciales, técnicos y regulatorios. Creamos una estrategia de adopción de PQC a medida que refleje su tolerancia al riesgo, las mejores prácticas del sector y sus necesidades de preparación para el futuro. Diseñamos sistemas y flujos de trabajo que faciliten la transición de algoritmos criptográficos a medida que evolucionan los estándares. Actualizamos las políticas de seguridad, los procedimientos de gestión de claves y las normas internas de cumplimiento para alinearlas con las recomendaciones del NIST y la NSA (CNSA 2.0). Elaboramos una hoja de ruta de migración paso a paso con objetivos a corto, mediano y largo plazo, desglosados ​​en fases manejables, como la prueba piloto, la implementación híbrida y la implementación completa.

• Evaluación de proveedores y prueba de concepto

  En esta etapa, le ayudamos a identificar y probar las herramientas, tecnologías y socios adecuados para sus objetivos poscuánticos. Le ayudamos a definir los requisitos técnicos y comerciales para las RFI/RFP, incluyendo la compatibilidad de algoritmos, la compatibilidad de integración, el rendimiento y la madurez de los proveedores. Identificamos a los principales proveedores que ofrecen PKI con capacidad PQC, gestión de claves y soluciones criptográficas. Realizamos pruebas de concepto (PoC) en entornos aislados para evaluar el rendimiento, la facilidad de integración y la adecuación general a sus casos de uso. Entregamos una matriz comparativa de proveedores y un informe de recomendaciones basado en los resultados de PoC reales.

• Pruebas piloto y escalamiento

  Antes de la implementación completa, validamos todo mediante pruebas piloto controladas para garantizar la viabilidad en el mundo real y minimizar las interrupciones del negocio. Probamos los nuevos modelos criptográficos en un entorno de pruebas o no productivo, generalmente para una o dos aplicaciones. Validamos la interoperabilidad con los sistemas existentes, las dependencias de terceros y los componentes heredados. Recopilamos la retroalimentación de los equipos de TI, los arquitectos de seguridad y las unidades de negocio para perfeccionar el plan. Una vez que todo se prueba con éxito, facilitamos una implementación fluida y escalable, reemplazando gradualmente los algoritmos criptográficos heredados, minimizando las interrupciones y garantizando que los sistemas se mantengan seguros y conformes. Monitoreamos continuamente el rendimiento y proporcionamos optimización continua para mantener su defensa cuántica sólida, eficiente y preparada para el futuro.

• Implementación de PQC

  Una vez que el plan esté listo, es hora de ponerlo en marcha. Esta es la etapa final, donde ejecutamos la migración completa, integrando PQC en su entorno operativo, garantizando al mismo tiempo el cumplimiento normativo y la continuidad. Implementamos modelos híbridos que combinan algoritmos clásicos y de seguridad cuántica para mantener la retrocompatibilidad durante la transición. Implementamos la compatibilidad con PQC en su PKI, aplicaciones, infraestructura, servicios en la nube y API. Ofrecemos capacitación práctica a sus equipos, junto con documentación técnica detallada para el mantenimiento continuo. Configuramos sistemas de monitoreo y procesos de gestión del ciclo de vida para monitorear el estado criptográfico, detectar anomalías y respaldar futuras actualizaciones.

La transición a la criptografía cuántica segura es un gran paso, pero no tiene por qué darlo solo. Con Encryption Consulting a su lado, contará con la orientación y la experiencia necesarias para construir una estrategia de seguridad resiliente y preparada para el futuro. 

Póngase en contacto con nosotros en [email protected] y permítanos crear una hoja de ruta personalizada que se ajuste a las necesidades específicas de su organización.

Conclusión

En conclusión, la transición a la CNSA 2.0 marca un paso crucial para proteger los Sistemas de Seguridad Nacional contra las amenazas cuánticas emergentes. Con plazos claros, algoritmos confiables y una guía estructurada, la NSA está sentando las bases para un entorno criptográfico preparado para el futuro. La adopción temprana, la agilidad criptográfica y el cumplimiento de los estándares serán esenciales para garantizar sistemas seguros, interoperables y resilientes al adoptar capacidades criptográficas poscuánticas.

Preguntas frecuentes

¿Es CNSA 2.0 de cumplimiento obligatorio por ley para las empresas comerciales?

La CNSA 2.0 es obligatoria para los Sistemas de Seguridad Nacional y sus proveedores, no para el sector comercial en general. Se vuelve vinculante para una empresa en el momento en que vende un producto o componente a un Sistema de Seguridad Nacional o a un entorno clasificado, ya sea directamente o como subcontratista de un contratista principal.

¿Cuál es la diferencia entre la validación FIPS 140-3 y la validación NIAP?

La norma FIPS 140-3 (CMVP) valida que un módulo criptográfico implemente correctamente sus algoritmos. La validación NIAP, por separado, confirma que el producto cumple con un perfil de protección aprobado y que está configurado correctamente según la norma CNSSP 15 para su uso en sistemas de seguridad nacional (NSS). La adquisición de sistemas NSS requiere ambas certificaciones; la validación FIPS por sí sola no cumple con los requisitos para obtener la designación aprobada por la NSA.

¿La suspensión de la Fase II de CMMC retrasa los plazos de CNSA 2.0?

No. CMMC y CNSA 2.0 son programas independientes. La suspensión de la Fase II de CMMC por parte del Departamento de Guerra en julio de 2026 detuvo las evaluaciones de terceros sobre CMMC que estaban siendo revisadas por un Grupo de Trabajo de Reforma; no modificó el cronograma de CNSA 2.0 de la NSA ni la fecha límite de adquisición del 1 de enero de 2027.

¿Cuánto tiempo tarda la validación FIPS 140-3 para un módulo compatible con PQC?

La validación de CMVP ha tardado, en promedio, más de 500 días desde la presentación de la solicitud hasta la obtención de un certificado activo, y la infraestructura de pruebas post-cuánticas dentro de este proceso es más reciente que la del algoritmo clásico. Los contratistas que aspiren a la fase de adquisición de enero de 2027 deben haberse inscrito en la lista de espera mucho antes de mediados de 2026 para tener una posibilidad realista de obtener un certificado activo para esa fecha.

¿Debe preocuparse un proveedor de segundo nivel por la CNSA 2.0 si nunca trata directamente con el gobierno?

Sí, si el componente que suministra termina dentro de un sistema entregado a un entorno NSS. Los contratistas principales deben demostrar el cumplimiento de CNSA 2.0 para el sistema completo, lo que significa que el requisito se extiende a cada proveedor de nivel inferior y proveedor comercial en esa cadena de suministro.

Fuente: 

• Preguntas frecuentes sobre CSI_CNSA_2.0_.PDF 
• https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF