Autores: Jennifer Brady y Apurva Varalikar

Hasta ahora, hemos establecido el cronograma esperado de la transición FIPS 140-3 planificada (clave FIPS 140-3 Fechas) y los términos y definiciones clave que necesita conocer (Parte 1: Términos y definiciones clave). Hoy, nuestra serie de blogs continúa con las diferencias entre FIPS 140-2 y FIPS 140-3. Esta publicación aborda las secciones individuales de ISO / IEC 19790 / ISO / IEC 24759 (a las que nos referiremos como FIPS 140-3) e identifica cómo se asignan y se diferencian de las secciones del estándar FIPS 140-2 y los IG actuales . Esta publicación se centrará en las tres primeras secciones de FIPS 140-2 e IG relacionados, y las secciones 7.2-7.4 de ISO / IEC 19790, a saber, la Especificación del módulo criptográfico, las interfaces y roles del módulo criptográfico, y las secciones Servicios y Autenticación, respectivamente.

Especificación del módulo criptográfico

Tipos de módulos criptográficos / límite criptográfico

El estándar FIPS 140-2 (publicado en 2001) se escribió originalmente con la idea de que todos los módulos eran módulos de hardware. Solo más tarde se agregaron y definieron diferentes tipos de módulos (híbridos, software y firmware) en el IG (IGs 1.9, 1.16 y 1.17). Además, FIPS 140-2 IG 1.9 restringió los módulos híbridos a una validación FIPS 140-2 Nivel 1.

FIPS 140-3 incluirá el módulo de hardware, el módulo de firmware, el módulo de software, el módulo de software híbrido y módulo de firmware híbrido. Define explícitamente cada tipo de módulo en la sección 7.2.2 de la norma. Tampoco existe ninguna restricción en cuanto al nivel en el que se puede validar un módulo híbrido en el nuevo estándar. ¡Esta es una gran noticia para los proveedores con módulos híbridos que buscan ser validados en un nivel superior al nivel 1!

Modos de operación

Dos términos nuevos; «Funcionamiento normal» y «Funcionamiento degradado» se introdujeron en FIPS 140-3 19790 y se indicaron en el blog anterior.

El funcionamiento normal es donde la funcionalidad completa de un módulo criptográfico está disponible y / o configurable. es decir, todos los algoritmos, funciones de seguridad y servicios.

Operación degradada es donde un subconjunto de la funcionalidad está disponible y / o configurable como resultado de la reconfiguración de un estado de error.

Si un módulo admite una operación degradada, entonces el El modo de operación solo se puede ingresar una vez que el módulo sale de un estado de error. ¿Qué significa eso? Un mecanismo o función ha fallado y el módulo ha entrado en estado de error y emite un indicador de error. Una vez que se encuentra en un estado de error, el módulo que admite esta operación degradada puede pasar al modo de operación degradado y continuar funcionando con capacidades reducidas. Aquí hay un par de requisitos adicionales que querrá recordar mientras prepara sus módulos para el nuevo estándar. El módulo debe proporcionar información de estado cuando se ingresa al modo operativo degradado, la función que falló debe aislarse, se deben realizar todas las autopruebas condicionales antes del uso de cualquier función criptográfica en el modo degradado y, por último, pero no menos importante, si hay un intento, mientras se encuentra en el modo de funcionamiento degradado, de utilizar un algoritmo, función de seguridad o proceso no operativo; los servicios deben indicar que se hizo tal intento.

Aquí hay un comentario adicional sobre la operación degradada como se indica en FIPS 140-3. La última frase de la sección 7.2.4.3 establece «Si el módulo no supera las autopruebas preoperativas, el módulo no entrará en funcionamiento degradado». Bueno, espera, dices, pensé que la operación degradada se usaría cuando algo como una autoprueba falla, pero aquí está diciendo que no puedes ingresar. Recuerda, solo puedes ingresar al modo degradado desde un estado de error. , el módulo primero debe ingresar al estado de error y luego ingresar a la operación degradada, mientras que también cumple con los otros requisitos como se discutió anteriormente.

Conceptos adicionales

Esté atento al SP 800-140 documentos que CMVP publicará en los próximos meses para ver si los IG de FIPS 140-2 que no se abordaron en la norma ISO 19790: 2012 / ISO 24759: 2014 se tratan en una de las publicaciones especiales. la sección uno puede ser absorbida por un manual de administración de CMVP basado en la web, mientras que otros pueden continuar siendo tratados como IGs.

Interfaces de módulos criptográficos

El blog anterior abordó los tipos de interfaces introducido en el documento ISO (HMI: Interfaz del módulo de hardware, SFMI: Interfaz del módulo de software o firmware, HSMI : Interfaz del módulo de software híbrido o HFMI: Interfaz del módulo de firmware híbrido), por lo que no vamos a discutirlos en este momento. En cambio, vamos a tocar las interfaces de entrada y salida.

Interfaces tradicionales y nuevas

FIPS 140-2 y FIPS 140-3 contienen: las cuatro interfaces lógicas: entrada de datos, salida de datos, entrada de control y salida de estado. FIPS 140-3 introduce una quinta interfaz, denominada interfaz de salida de control. Se utiliza una interfaz de salida de control para la salida de comandos. Las señales y los datos de control se utilizan para controlar o indicar el estado de funcionamiento. Esta salida de control puede ser información que se envía a otro módulo criptográfico. La interfaz de alimentación también es una interfaz necesaria en todos los módulos de software, excepto en los de software.

Trusted Channel

Otro concepto introducido en FIPS 140-3 es el de un «canal de confianza» que es similar al concepto FIPS 140-2 de una «ruta confiable» (Sección 4.7.4 e IG 2.1). Es un enlace de comunicaciones seguro entre el módulo criptográfico y el dispositivo de punto final que envía y recibe datos del módulo, con el objeto de proteger los CSP desprotegidos.

Similar al FIPS 140-2 IG 2.1, no existen requisitos para el uso de un canal confiable para los niveles de seguridad 1 y 2 en FIPS 140-3. FIPS 140-3 tiene varios requisitos para los niveles de seguridad 3 y 4, tales como: CSP de texto plano sin protección, componentes clave y datos de autenticación, que necesitan usar un canal confiable cuando se transmiten entre el módulo y un remitente / receptor. El canal de confianza debe evitar modificaciones, sustituciones y divulgaciones no autorizadas. Los servicios que usan un canal confiable deben emplear autenticación basada en identidad, y el módulo debe proporcionar un indicador de estado cuando se usa el canal confiable.

FIPS 140-3 establece un requisito adicional para un módulo que usa un canal confiable en nivel de seguridad 4 que no vimos en el FIPS 140-2 o IG 2.1 anterior. Un módulo de nivel 4 que usa un canal confiable debe usar autenticación basada en identidad de múltiples factores para todos los servicios que usan el canal confiable.

Roles, servicios y autenticación

Roles

El estándar FIPS 140-2 (sección 4.3.1) requiere que un módulo admita tanto un rol de oficial de cifrado como un rol de usuario, y que el soporte de un rol de mantenimiento sea opcional. FIPS 140-3 todavía tiene estos mismos tres roles, pero solo se requiere el rol de oficial de cifrado (sección 7.4.2). El rol de usuario y el rol de mantenimiento ahora son opcionales.

Servicios

Servicios requeridos

Hay tres servicios requeridos en el estándar FIPS 140-2: mostrar estado , realizar autopruebas y realizar la función de seguridad aprobada (sección 4.3.2). Estos mismos tres servicios se requieren en FIPS 140-3, además de dos servicios adicionales requeridos: mostrar información de versiones de módulos y realizar la puesta a cero (sección 7.4.3.1). El «mostrar información de versión del módulo» requiere que el módulo criptográfico muestre el nombre / identificador del módulo y la información de versión, que se puede verificar con un certificado de validación. Las especificaciones del servicio de puesta a cero se definen en la sección 7.9.7 y se abordarán en un blog futuro.

Servicio de derivación

Tanto FIPS 140-2 como FIPS 140-3 contienen el servicio de derivación opcional. FIPS 140-3 indica específicamente que un operador que puede configurar una derivación La capacidad en el módulo debe asumir una función autorizada. Si bien el estándar FIPS 140-2 no establece específicamente ese requisito, la mayoría de la autenticación asumida para una función autorizada era necesaria dado que el servicio podría usarse revelar CSP y / afectar la seguridad de la información protegida por el módulo (IG 3.1).

Salida criptográfica autoiniciada

Una nueva capacidad, abordada en FIPS 140-3, es la «Capacidad de salida criptográfica autoiniciada». Aquí, el módulo puede realizar operaciones criptográficas u otras funciones de seguridad aprobadas sin la intervención de ningún operador. El cripto-oficial puede configurar esta capacidad, mientras que esta configuración puede ser persistente durante los reinicios. Se requieren dos acciones internas para activar el servicio y el módulo debe indicar que el servicio está activado.

Carga de software / firmware

La carga de software / firmware se aborda en FIPS 140-2 estándar, y en IG 9.7, en el contexto de la autoprueba requerida al cargar software / firmware. FIPS 140-2 no lo trata como un servicio como vemos en FIPS 140-3 (sección 7.4.3.4). Algunos de los requisitos que se establecen en el documento incluyen que, para que el módulo siga siendo un módulo validado, cualquier software / firmware que se cargue debe ser validado por una autoridad de validación. Aquí, toda la salida de datos debe inhibirse hasta que el software / firmware se haya completado con éxito; la prueba de carga de software / firmware debe realizarse antes de que se ejecute el código; el módulo no ejecutará el código cargado hasta que las autopruebas preoperativas se hayan ejecutado con éxito y, por último, pero no menos importante, la información de versión de los módulos debe actualizarse para reflejar la adición / actualización del software / firmware.

Comentario adicional

Los servicios no autenticados no se tratan explícitamente en FIPS 140-3, por lo que necesitaremos ver si este concepto, que se aborda en la IG 3.1 actual, se transfiere en cualquiera de los documentos SP800-140. Más sobre esto se abordará en blogs futuros.

Autenticación

FIPS 140-3 es similar a FIPS 140-2 para la autenticación en los niveles de seguridad 1-3: (ISO 19790: Nivel 1: sin requisitos de autenticación; Nivel 2: autenticación mínima basada en roles; Nivel 3: autenticación basada en identidad). La mayor diferencia es que para el nivel 2, se agregó la palabra «mínimo», que se corresponde con la aclaración que se aborda en IG 3.4. La autenticación de nivel 4, en el estándar FIPS 140-3 basado en ISO, toma la autenticación un nivel, no solo requiriendo autenticación basada en identidad. Para la autenticación de nivel 4, debe estar basada en identidad de múltiples factores.

Un par de elementos adicionales a tener en cuenta en esta sección es que FIPS 140-2 especificó la fuerza de autenticación requerida por el módulo. La fuerza no está definida en FIPS 140-3, pero debe especificarse en la política de seguridad del módulo. Lo más probable es que cada autoridad de validación incluya una fuerza de autenticación en su documentación adicional.

Los mecanismos de autenticación aprobados no se pueden implementar mediante procedimientos documentados o reglas de seguridad (es decir, políticas). Esto significa que el módulo debe configurar y hacer cumplir las restricciones de tamaño de la contraseña. Esto puede afectar la forma en que operan varios de los módulos actuales. , tenga en cuenta esto mientras prepara sus módulos para los requisitos ISO.

En resumen

Hay mucho que aprender sobre las diferencias entre FIPS 140-2 y FIPS 140-3. Si bien hay una gran cantidad de similitudes, también hay bastantes cambios. Nuestra serie sobre este tema continuará, abordando un área nueva con cada publicación. Como siempre, si tiene alguna pregunta, no dude en contactarnos directamente. Nuestro equipo siempre está aquí para ayudar.