FIPS 140

La serie 140 de Estándares Federales de Procesamiento de Información ( FIPS , por sus siglas en inglés) son estándares de seguridad informática del gobierno de los Estados Unidos que especifican los requisitos para los módulos criptográficos .

A partir de octubre de 2020 , FIPS 140-2 y FIPS 140-3 se aceptan como vigentes y activos. ^{[ 1 ]} FIPS 140-3 fue aprobado el 22 de marzo de 2019 como sucesor de FIPS 140-2 y entró en vigor el 22 de septiembre de 2019. ^{[ 2 ]} Las pruebas de FIPS 140-3 comenzaron el 22 de septiembre de 2020 y se ha emitido un pequeño número de certificados de validación. Las pruebas de FIPS 140-2 siguen disponibles hasta el 21 de septiembre de 2021 (posteriormente se cambió para las solicitudes que ya estaban en curso al 1 de abril de 2022 ^{[ 3 ]} ), creando un período de transición superpuesto de un año. Los informes de prueba de FIPS 140-2 que permanezcan en la cola de CMVP seguirán recibiendo validaciones después de esa fecha, pero todas las validaciones de FIPS 140-2 se trasladarán a la Lista histórica el 21 de septiembre de 2026 independientemente de su fecha de validación final real. ^{[ 3 ]}

El Instituto Nacional de Estándares y Tecnología (NIST) publica la Serie de Publicaciones 140 para coordinar los requisitos y estándares de los módulos criptográficos, que incluyen componentes de hardware y software, para su uso por los departamentos y agencias del gobierno federal de los Estados Unidos . FIPS 140 no pretende proporcionar condiciones suficientes para garantizar la seguridad de un módulo que cumpla con sus requisitos, y mucho menos la seguridad de un sistema construido con dichos módulos. Los requisitos abarcan no solo 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 usuarias que deseen implementar módulos criptográficos deben confirmar que el módulo que utilizan cuenta con un certificado de validación vigente. Los certificados de validación FIPS 140-1 y FIPS 140-2 especifican el nombre exacto del módulo, el hardware, el software, el firmware y/o los números de versión del applet. Para los niveles 2 y superiores, también se indica la plataforma operativa sobre la que se aplica la validación. Los proveedores no siempre mantienen actualizadas sus validaciones de referencia.

El Programa de Validación de Módulos Criptográficos (CMVP) es operado conjuntamente por la División de Seguridad Informática del Instituto Nacional de Estándares y Tecnología (NIST) del Gobierno de los Estados Unidos y el Centro de Seguridad de las Comunicaciones (CSE) 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 según la norma FIPS 140 en las aplicaciones no clasificadas de sus departamentos.

La norma FIPS 140-2 define cuatro niveles de seguridad, denominados simplemente "Nivel 1" a "Nivel 4". No especifica en detalle qué nivel de seguridad requiere cada aplicación.

• La norma FIPS 140-2 Nivel 1, la más baja, impone requisitos muy limitados; en términos generales, todos los componentes deben ser de "grado de producción" y deben estar ausentes diversos tipos graves de inseguridad.
• La norma FIPS 140-2 Nivel 2 añade requisitos para la detección de manipulaciones físicas y la autenticación basada en roles.
• La norma FIPS 140-2 de nivel 3 añade requisitos de resistencia a la manipulación física (lo que dificulta que los atacantes accedan a la información confidencial contenida en el módulo) y de autenticación basada en la identidad, así como una separación física o lógica entre las interfaces por las que los "parámetros de seguridad críticos" entran y salen del módulo, y sus otras interfaces.
• El nivel 4 de la norma FIPS 140-2 hace más estrictos los requisitos de seguridad física y exige robustez frente a ataques ambientales.

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 incluye contramedidas contra estos ataques, deben estar documentadas y probadas, pero no se requieren protecciones para alcanzar un nivel determinado. Por lo tanto, una crítica a FIPS 140-2 es que la norma genera una falsa sensación de seguridad en los niveles 2 y superiores, ya que implica que los módulos serán a prueba de manipulaciones o resistentes a ellas, pero se permiten vulnerabilidades de canal lateral que permiten la extracción sencilla de claves.

La norma FIPS 140 impone requisitos en once áreas diferentes:

• Especificación del módulo criptográfico (qué debe documentarse)
• Puertos e interfaces del módulo criptográfico (qué información entra y sale, y cómo debe segregarse).
• Roles, servicios y autenticación (quién puede hacer qué con el módulo y cómo se verifica esto).
• Modelo de estados finitos (documentación de los estados de alto nivel en los que puede encontrarse el módulo y cómo se producen las transiciones).
• Seguridad física ( resistencia a la manipulación y robustez frente a condiciones ambientales extremas)
• Entorno operativo (qué tipo de sistema operativo utiliza el módulo y en qué sistema operativo se utiliza)
• Gestión de claves criptográficas (generación, introducción, salida, almacenamiento y destrucción de claves)
• EMI / EMC
• Autoevaluaciones (qué se debe evaluar y cuándo, y qué se debe hacer si una prueba falla)
• Garantía de diseño (qué documentación debe proporcionarse para demostrar que el módulo ha sido bien diseñado e implementado).
• Mitigación de otros ataques (si un módulo está diseñado para mitigar, por ejemplo, los ataques TEMPEST , su documentación debe indicar cómo).

La norma FIPS 140-1, publicada el 11 de enero de 1994 y retirada el 25 de mayo de 2002, ^{[ 4 ]} fue desarrollada por un grupo de trabajo gubernamental e industrial, compuesto por proveedores y usuarios de equipos criptográficos. El grupo identificó los cuatro "niveles de seguridad" y las once "áreas de requisitos" mencionados anteriormente, y especificó los requisitos para cada área en cada nivel.

La norma FIPS 140-2 , publicada el 25 de mayo de 2001, tiene en cuenta los cambios en la tecnología disponible y las normas oficiales desde 1994, así como los comentarios recibidos de proveedores, evaluadores y usuarios. Fue el principal documento de entrada para 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, que describe los cambios significativos de FIPS 140-1 a FIPS 140-2. ^{[ 5 ]}

FIPS 140-3 , publicado el 22 de marzo de 2019 y anunciado ^{[ 2 ]} 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 con 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 del borrador ^{[ 6 ]} del estándar FIPS 140-3, el NIST introdujo una nueva sección de seguridad de software, un nivel de garantía adicional (Nivel 5) y nuevos requisitos de Análisis de potencia simple (SPA) y Análisis de potencia diferencial (DPA). Sin embargo, el borrador publicado 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 está configurado el proceso de validación, un proveedor de software debe revalidar su módulo validado por FIPS con cada cambio, por pequeño que sea, en el software; esta revalidación es necesaria incluso para correcciones obvias de errores o problemas de seguridad. Dado que la validación es un proceso costoso, esto incentiva a los proveedores de software a posponer los cambios en su software y puede resultar en que el software no reciba actualizaciones de seguridad hasta la siguiente validación. El resultado puede ser que el software validado sea menos seguro que su equivalente no validado. ^{[ 7 ]}

Esta crítica ha sido refutada más recientemente por algunos expertos de la industria que, en cambio, responsabilizan al proveedor de delimitar su alcance de validación. Dado que la mayoría de los esfuerzos de revalidación se desencadenan por errores y correcciones de seguridad ajenas a las operaciones criptográficas principales, una validación con un alcance adecuado no está sujeta a la revalidación común descrita. ^{[ 8 ]}

• Criterios comunes
• FIPS 140-2
• FIPS 140-3
• ISO/IEC 19790
• Categoría: Normas de seguridad informática
• Categoría: Estándares de criptografía