La serie 140 de Estándares Federales de Procesamiento de Información ( FIPS ) son estándares de seguridad informática del gobierno de EE. UU. que especifican los requisitos para los módulos criptográficos .
A partir de octubre de 2020 [actualizar], tanto FIPS 140-2 como FIPS 140-3 se aceptan como vigentes y activos. [1] FIPS 140-3 se aprobó el 22 de marzo de 2019 como sucesor de FIPS 140-2 y entró en vigencia el 22 de septiembre de 2019. [2] Las pruebas de FIPS 140-3 comenzaron el 22 de septiembre de 2020 y se han emitido una pequeña cantidad de certificados de validación. Las pruebas de FIPS 140-2 todavía están disponibles hasta el 21 de septiembre de 2021 (posteriormente se cambió para las solicitudes que ya están en curso al 1 de abril de 2022 [3] ), lo que crea un período de transición superpuesto de un año. Los informes de pruebas FIPS 140-2 que permanezcan en la cola CMVP seguirán recibiendo validaciones después de esa fecha, pero todas las validaciones FIPS 140-2 se moverán a la Lista histórica el 21 de septiembre de 2026, independientemente de su fecha de validación final real. [4]
El Instituto Nacional de Estándares y Tecnología (NIST) publica la serie de publicaciones FIPS 140 para coordinar los requisitos y estándares para módulos criptográficos que incluyen componentes de hardware y software para uso de departamentos y agencias del gobierno federal de los Estados Unidos . FIPS 140 no pretende proporcionar condiciones suficientes para garantizar que un módulo que cumpla con sus requisitos sea seguro, y menos aún que un sistema construido utilizando dichos módulos sea seguro. Los requisitos no solo cubren los módulos criptográficos en sí, sino también su documentación y (en el nivel de seguridad más alto) algunos aspectos de los comentarios contenidos en el código fuente.
Las agencias de usuarios que deseen implementar módulos criptográficos deben confirmar que el módulo que están utilizando está cubierto por un certificado de validación existente. Los certificados de validación FIPS 140-1 y FIPS 140-2 especifican el nombre exacto del módulo y los números de versión de hardware, software, firmware y/o subprograma. Para los niveles 2 y superiores, también se incluye la plataforma operativa en la que se aplica la validación. Los proveedores no siempre mantienen sus validaciones de referencia.
El Programa de Validación de Módulos Criptográficos (CMVP, por sus siglas en inglés) es administrado conjuntamente por la División de Seguridad Informática del Instituto Nacional de Normas y Tecnología (NIST, por sus siglas en inglés) del Gobierno de los Estados Unidos y el Establecimiento de Seguridad de las Comunicaciones (CSE, por sus siglas en inglés) del Gobierno de Canadá. El Gobierno de los Estados Unidos exige el uso de módulos criptográficos validados para todos los usos no clasificados de la criptografía. El Gobierno de Canadá también recomienda el uso de módulos criptográficos validados FIPS 140 en aplicaciones no clasificadas de sus departamentos.
FIPS 140-2 define cuatro niveles de seguridad, denominados simplemente "Nivel 1" a "Nivel 4". No especifica en detalle qué nivel de seguridad requiere una aplicación en particular.
Además de los niveles especificados, la Sección 4.1.1 de la especificación describe ataques adicionales que pueden requerir mitigación, como el análisis de potencia diferencial. Si un producto contiene contramedidas contra estos ataques, deben documentarse y probarse, pero no se requieren protecciones para alcanzar un nivel determinado. Por lo tanto, una crítica a FIPS 140-2 es que la norma da una falsa sensación de seguridad en los niveles 2 y superiores porque la norma implica que los módulos serán a prueba de manipulaciones y/o resistentes a las manipulaciones, pero se permite que los módulos tengan vulnerabilidades de canal lateral que permitan la extracción simple de claves.
FIPS 140 impone requisitos en once áreas diferentes:
La norma FIPS 140-1, publicada el 11 de enero de 1994 y retirada el 25 de mayo de 2002, [5] fue desarrollada por un grupo de trabajo del gobierno y la industria, compuesto por vendedores y usuarios de equipos criptográficos. El grupo identificó los cuatro "niveles de seguridad" y las once "áreas de requisitos" que se enumeraron anteriormente, y especificó los requisitos para cada área en cada nivel.
FIPS 140-2 , publicada el 25 de mayo de 2001, tiene en cuenta los cambios en la tecnología disponible y en las normas oficiales desde 1994, así como los comentarios recibidos de las comunidades de proveedores, evaluadores y usuarios. Fue el principal documento de aportación a la norma internacional ISO / IEC 19790 :2006 Requisitos de seguridad para módulos criptográficos publicada el 1 de marzo de 2006. El NIST publicó la Publicación Especial 800-29 en la que se describen los cambios significativos de FIPS 140-1 a FIPS 140-2. [6]
FIPS 140-3 , emitido el 22 de marzo de 2019 y anunciado [7] en mayo de 2019, se encuentra actualmente en el período de transición superpuesto para reemplazar a FIPS 140-2 y alinea la guía del NIST en torno a dos documentos de estándares internacionales: ISO / IEC 19790:2012(E) Tecnología de la información - Técnicas de seguridad - Requisitos de seguridad para módulos criptográficos e ISO / IEC 24759:2017(E) Tecnología de la información - Técnicas de seguridad - Requisitos de prueba para módulos criptográficos . En la primera versión preliminar [8] del estándar FIPS 140-3, el NIST introdujo una nueva sección de seguridad de software, un nivel adicional de garantía (Nivel 5) y nuevos requisitos de Análisis de potencia simple (SPA) y Análisis de potencia diferencial (DPA). Sin embargo, el borrador emitido el 11 de septiembre de 2009 volvió a cuatro niveles de seguridad y limita los niveles de seguridad del software a los niveles 1 y 2.
Debido a la forma en que se configura el proceso de validación, se requiere que un proveedor de software vuelva a validar su módulo validado por FIPS para cada cambio, sin importar cuán pequeño sea, en el software; esta revalidación es necesaria incluso para correcciones obvias de errores o de seguridad. Dado que la validación es un proceso costoso, esto le da a los proveedores de software un incentivo para posponer los cambios en su software y puede dar como resultado un software que no reciba actualizaciones de seguridad hasta la próxima validación. El resultado puede ser que el software validado sea menos seguro que un equivalente no validado. [9]
Esta crítica ha sido refutada más recientemente por algunos expertos de la industria que, en cambio, atribuyen al proveedor la responsabilidad de limitar sus límites de validación. Como la mayoría de los esfuerzos de revalidación se desencadenan por errores y correcciones de seguridad fuera de las operaciones criptográficas centrales, una validación con un alcance adecuado no está sujeta a la revalidación común descrita. [10]
{{cite journal}}: Requiere citar revista |journal=( ayuda )