Certificación FIPS 140 y Golang

FIPS 140 (Publicación 140 del Estándar Federal de Procesamiento de Información)

FIPS 140 es un estándar de certificación de seguridad de módulos criptográficos establecido por el NIST de EE. UU. Este estándar evalúa si un módulo o biblioteca criptográfica específica cumple con los requisitos de seguridad definidos por el NIST. Por lo tanto, superar la certificación FIPS 140 significa que el módulo ha adquirido confiabilidad en seguridad oficialmente, lo que implica que puede ser utilizado en campos críticos para la seguridad como finanzas, medicina y defensa.

FIPS 140 fue establecido inicialmente en 1994, luego fue revisado a FIPS 140-2 en 2001 y a FIPS 140-3 en 2019. Hasta la fecha, muchos sistemas y aplicaciones aún requieren la certificación FIPS 140-2 o FIPS 140-3.

FIPS 140 y Lenguajes de Programación

Por esta razón, los módulos criptográficos con certificación FIPS 140 se utilizan como un estándar de facto en varios lenguajes de programación y entornos. Ejemplos representativos incluyen OpenSSL, BoringSSL, LibreSSL y NSS, que son los módulos más ampliamente utilizados en aplicaciones donde la seguridad es crítica.

La mayoría de los módulos certificados FIPS 140 están escritos en C o C++. Por esta razón, lenguajes como PHP, Python y Javascript configuran entornos FIPS vinculando estos módulos a través de módulos Provider externos, en lugar de usarlos directamente. Sin embargo, este enfoque tiene algunas limitaciones.

• Problema de Incompatibilidad de Versiones

  La certificación FIPS 140 se otorga solo para una versión específica. Por lo tanto, para usar la versión más reciente del módulo, debe pasar por el proceso de certificación nuevamente, y esto puede causar una incompatibilidad de versiones entre el módulo utilizado por la aplicación y el módulo certificado FIPS. Si se utiliza una versión no autorizada, el entorno ya no se considerará un entorno certificado FIPS.

• Carga Dinámica y Degradación del Rendimiento

  La mayoría de los lenguajes utilizan módulos certificados FIPS 140 cargándolos como bibliotecas dinámicas. Este método puede causar una degradación del rendimiento durante la inicialización y ejecución, y existe el riesgo de que los problemas que surjan durante el tiempo de ejecución afecten directamente la estabilidad general de la aplicación.

• Vulnerabilidades de Seguridad

  Como se mencionó anteriormente, en una arquitectura que vincula módulos externos como OpenSSL Provider, existe el riesgo de que las vulnerabilidades de seguridad de ese módulo se propaguen directamente a la aplicación. Además, la capa de comunicación entre la aplicación y el módulo externo en sí se convierte en una superficie de ataque adicional, lo que requiere una capa de seguridad separada para protegerla. Esto puede aumentar la complejidad y generar vulnerabilidades inesperadas.

FIPS 140 y Golang

Por estas razones, Golang ha adoptado una estrategia diferente. Go ha optado por admitir la certificación FIPS 140 directamente en su biblioteca criptográfica oficial, sin depender de herramientas externas. Por lo tanto, los desarrolladores solo necesitan activar el modo certificado FIPS (GOFIPS=1) mientras usan el paquete crypto estándar, sin necesidad de instalar o configurar un Provider separado. Esto elimina los límites de comunicación con módulos externos, lo que mejora la seguridad, y simplifica la operación, ya que solo se necesita distribuir un único binario compilado estáticamente.

FIPS 140-2 y Golang

Para ello, Golang obtuvo la certificación FIPS 140-2 al integrar el módulo BoringCrypto, derivado de BoringSSL, en el tiempo de ejecución de Go. BoringCrypto se puede activar en ciertas distribuciones a partir de la versión Go 1.19, lo que permite que las aplicaciones Go configuren un entorno certificado FIPS 140-2 sin módulos externos separados.

Sin embargo, dado que BoringCrypto se basa en OpenSSL, todavía existe una dependencia del lenguaje C. Por lo tanto, las aplicaciones Go no se construían como binarios completamente independientes, y existía la restricción de tener que distribuir las bibliotecas C necesarias junto con ellas.

FIPS 140-3 y Golang

El equipo de Go superó estas limitaciones mejorando la biblioteca criptográfica estándar de Go para cumplir con la especificación FIPS 140-3. Este módulo mejorado comenzó a ofrecerse experimentalmente a partir de la versión Go 1.21, y actualmente se encuentra en proceso de revisión de certificación FIPS 140-3 por parte del NIST.Lista de módulos en proceso de revisión FIPS 140-3 del NIST

Esto demuestra la madurez de la biblioteca criptográfica de Go, y a través de ella, Go puede proporcionar un entorno certificado FIPS 140-3 como un único binario completamente independiente.

Además, el equipo de Go no solo se limitó a cumplir con el estándar FIPS 140-3, sino que también reforzó la seguridad por sí mismo.

• Fail Fast

  El modo FIPS de Go aplica el modelo de seguridad Fail Fast, deteniendo la ejecución inmediatamente con un panic si se invoca un algoritmo no certificado. A diferencia de los modelos basados en Provider de otros lenguajes que dejan abierta la posibilidad de un fallback, esto proporciona una garantía más estricta y clara en términos de seguridad y cumplimiento normativo.

• Hedged Signature

  El estándar FIPS 140-3 recomienda el método RFC6979 para la firma ECDSA. Sin embargo, Go ha ido más allá al introducir el método Hedged, lo que lo hace más resistente a los ataques de canal lateral que pueden ocurrir durante el proceso de firma.

• Generador de Números Aleatorios Mejorado

  El generador de números aleatorios de Go utiliza un DRBG (Deterministic Random Bit Generator) en el espacio de usuario, pero también inyecta entropía adicional al kernel del sistema operativo, generando números aleatorios de alta calidad no solo en el espacio de usuario sino también en el espacio del kernel. Esto mejora aún más la seguridad del generador de números aleatorios.