Introducción a FIPS 140-2
FIPS 140-2 es un estándar de seguridad desarrollado por los gobiernos de EEUU y Canadá para la certificación de productos de IT capaces de llevar a cabo operaciones criptográficas para la protección de información sensible o importante.
Estos productos IT comúnmente llamados “Módulos criptográficos” en la jerga de FIPS 140-2, deben ser validados por el Programa de Validación de Módulos Criptográficos (CMVP), que verifica que estos cumplen con los requisitos de seguridad de FIPS 140-2 y a su vez, verifica que los algoritmos criptográficos que incorpora el módulo cumplen con el Programa de Validación de Algoritmos Criptográficos (CAVP).
¿Qué dificultades atañen a FIPS 140-2?
Cuando un fabricante desea certificar un producto para que sea conforme con FIPS 140-2, el primer problema que se encuentra, es que, debe desarrollar un producto que cumpla con las 11 áreas relacionadas con el diseño y la implementación del mismo, implementando a su vez, uno o varios algoritmos criptográficos aprobados por el estándar.
Por si fuera poco tener que desarrollar un producto conforme al estándar, el siguiente obstáculo al que se enfrenta el fabricante, es generar toda la documentación necesaria para poder afrontar el CMVP y el CAVP de forma satisfactoria, en función del nivel de seguridad que se desea o que deba cumplir el módulo criptográfico.
En nuestra experiencia, los fabricantes se ven asaltados por dudas que, en la mayoría de los casos, suponen grandes retrasos en el desarrollo y certificación del módulo, llegando en algunos casos a imposibilitar la certificación del mismo. Algunas de las dudas más comunes que suelen surgir son:
- ¿Qué nivel de seguridad debe cumplir el módulo criptográfico?
- ¿Qué componentes hardware/software forman parte del boundary criptografico?
- ¿Qué son las funciones criptográficas aprobadas, no-aprobadas y afirmadas por el fabricante?
- ¿Qué implican los roles de usuario y crypto officer? ¿Qué método de autenticación se debe usar? ¿Qué son realmente los servicios accesibles por cada rol?
- ¿Qué estados debe implementar el Modelo de Estados Finitos?
- ¿Qué tipo de seguridad física requiere el módulo?
- ¿Necesita el módulo pasar los test de EMI/EMC y obtener un FCC-ID?
- ¿Qué operaciones debe realizar el módulo durante los self-test? ¿Qué tipos de ataque debe mitigar?
¿Cómo disipar las dificultades?
Debido a la necesidad de conocer el lenguaje especifico, así como las particularidades de los conceptos especificados por el standard, en jtsec somos conscientes del gran esfuerzo que requiere enfrentarse a FIPS 140-2 por primera vez y, además, de lo que supone hacerlo sin garantías de obtener finalmente la certificación.
Como consultores en FIPS 140-2, las dos premisas principales para nosotros son las de, en primer lugar, hacer que el producto obtenga la certificación lo antes posible y en segundo lugar hacerlo de manera que, el proceso sea lo más simpe y fácil para el fabricante.
Para ello, además de llevar a cabo la generación de toda la documentación necesaria para la certificación, nuestro objetivo es disipar todas las dudas y dificultades encontradas al enfrentarse a la norma por primera vez, dando un sentido más tangible y claro a todos los tecnicismos y conceptos del standard, y ayudando al fabricante a definir el diseño adecuado para su módulo.
De esta forma, acompañamos al fabricante durante el proceso de diseño del módulo, empezando por identificar que nivel de seguridad debe cumplir, ya que, este parámetro es el que fijará las especificaciones necesarias para los requisitos para el resto de áreas de diseño.
Una vez fijado el nivel de seguridad, el siguiente punto relevante, es clarificar que operaciones criptográficas implementará el módulo, para así identificar todos los parámetros críticos de seguridad dependiendo de si el módulo implementa generación de claves simétricas, claves asimétricas, generación y verificación de firmas, generación de números aleatorios, etc. Ya que, identificando cuales son estos parámetros y que uso hace de ellos el módulo, se podrá hacer una definición exhaustiva de que partes hardware/software del módulo conforman el boundary y que partes quedan excluidas del mismo. Este paso es de gran relevancia, ya que, permitirá definir todas las interfaces de entrada y salida del módulo, identificándolas según si son interfaces de entrada/salida de datos criptográficos o entradas de control y salidas de estatus, pudiendo así, establecer el flujo que la información sigue a través del módulo.
En lo referente a los roles de usuario, la dificultad reside en definir que servicios atañen a cada uno de ellos, así como, poder autenticarlos, teniendo en cuenta que en muchas ocasiones los módulos no son capaces de poder implementar un sistema de autenticación como tal o en caso de implementarlo, saber si es un sistema de autenticación adecuado y aceptado por FIPS 140-2.
Dependiendo de los roles de usuario definidos así como de las operaciones criptográficas implementadas, se definirán los estados que compondrán el Modelo de Estados Finito, así como las posibles transiciones que se producen entre ellos, teniendo en cuenta particularidades como, que el módulo no podrá operar ni emitir datos criptográficos por las salidas hasta que se haya completado el self-test de encendido y que, se debe proporcionar un método para comprobar en que estado se encuentra el módulo en cualquier momento y un método para poder ejecutar el self-test de encendido bajo demanda.
Respecto a los self-test, es necesario considerar si solo es necesario llevar a cabo los test de encendido o si, por el contrario, también se necesitan self-test condicionales, dependiendo de si el módulo implementa operaciones criptográficas basadas en claves publica y privadas, si implementa bypass o entrada manual de claves. Es importante también tener en cuenta que durante el self-test de encendido, dependiendo de las características del módulo, será necesario llevar a cabo test de integridad del firmware/software contendido en el módulo y test que comprueben el correcto funcionamiento de los algoritmos criptográficos implementados.
El estándar de FIPS 140-2 considera la necesidad de incorporar protecciones físicas, que pueden variar desde aplicar un simple polímero a los componentes hardware, hasta contener el módulo dentro de cubiertas con posibles interfaces y aberturas de acceso que cuenten con medidas anti-tampering. Del mismo modo, también considera la necesidad de someter el módulo a test de emisiones electromagnéticas (EMI/EMC) para la obtención del FCC-ID, así como de condiciones del entorno (condiciones extremas de temperatura y potencia), para verificar su correcto funcionamiento en función del tipo de módulo y del nivel de seguridad.
Finalmente, es de gran relevancia definir los procesos de gestión de claves como son los de generación, establecimiento, importación y/o zeroización de las mismas realizados por el módulo criptográfico, para asegurar que no se producen revelaciones indeseadas de elementos criptográficos a consecuencia de una gestión inadecuada.
Afrontando la certificación
A la hora de afrontar la certificación, los fabricantes tienen la opción de intentarlo por si mismos o, por el contrario, contar con la asistencia de jtsec.
En el caso de intentar hacerlo por sí mismos, como se ha visto anteriormente, suele conllevar retrasos en los plazos, aumentando los costes y en algunos casos incluso no pasar la certificación, acabando en un laberinto sin salida en cuanto al desarrollo del producto y a la obtención de la certificación. No son pocas las veces que hemos tenido que rescatar proyectos bloqueados por haber tomado decisiones incorrectas.
Sin embargo, en el caso de contar con nuestra asistencia desde el principio, el fabricante se asegura poder realizar un diseño del producto totalmente conforme al estándar, así como el desarrollo de la documentación necesaria en un tiempo lo más reducido posible, pudiendo así optimizar costes, obtener mejores ofertas en la negociación con los laboratorios, y además, obtener la ventaja competitiva que supone pasar la certificación satisfactoriamente.
