GoSudaEstructura de las implementaciones de FIPS 140-2 y FIPS 140-3 en la biblioteca estándar de criptografía de Go
FIPS 140 (Federal Information Processing Standard Publication 140)
FIPS 140 es la norma de certificación de seguridad para módulos criptográficos establecida por el NIST de los Estados Unidos. Esta norma 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 posee una seguridad oficialmente confiable, lo que implica que puede utilizarse en sectores donde la seguridad es crítica, como las finanzas, la salud y la defensa.
Desde su primera publicación en 1994, FIPS 140 fue revisada en 2001 como FIPS 140-2 y en 2019 como FIPS 140-3. Hasta la fecha, muchos sistemas y aplicaciones siguen exigiendo la certificación FIPS 140-2 o FIPS 140-3.
FIPS 140 y los lenguajes de programación
Por esta razón, los módulos criptográficos certificados según FIPS 140 se utilizan como un estándar de facto en diversos lenguajes de programación y entornos. Entre los ejemplos representativos se encuentran OpenSSL, BoringSSL, LibreSSL y NSS, que son los módulos más ampliamente empleados en aplicaciones donde la seguridad es fundamental.
La mayoría de los módulos certificados según FIPS 140 están escritos en C o C++. Por ello, lenguajes como PHP, Python o JavaScript suelen configurar entornos FIPS mediante la integración con módulos Provider externos, en lugar de utilizar directamente dichos módulos. Sin embargo, este enfoque presenta varias limitaciones.
Problema de desajuste de versiones
La certificación FIPS 140 se otorga únicamente para versiones específicas. Por lo tanto, para utilizar una versión más reciente del módulo es necesario someterse nuevamente al proceso de certificación, lo que puede provocar un desajuste de versiones entre el módulo utilizado por la aplicación y el módulo certificado FIPS. Si se emplea una versión no autorizada, el entorno deja de considerarse un entorno certificado FIPS.
Carga dinámica y degradación del rendimiento
La mayoría de los lenguajes cargan los módulos certificados FIPS 140 como bibliotecas dinámicas. Este método puede causar degradación del rendimiento durante la inicialización y la ejecución, y si surge un problema en tiempo de ejecución existe el riesgo de afectar directamente la estabilidad de toda la aplicación.
Vulnerabilidades de seguridad
Como se mencionó anteriormente, en estructuras que integran módulos externos, como el Provider de OpenSSL, existe el riesgo de que las vulnerabilidades de seguridad de dicho módulo se propaguen directamente a la aplicación. Además, la propia capa de comunicación entre la aplicación y el módulo externo constituye una superficie de ataque adicional, por lo que se requiere una capa de seguridad independiente para protegerla. Esto aumenta la complejidad y puede generar vulnerabilidades imprevistas.
FIPS 140 y Golang
Por estas razones, Golang adoptó una estrategia diferente. Go no depende de herramientas externas para la certificación FIPS 140, sino que optó por un método en el que la biblioteca criptográfica oficial lo admite directamente. Así, los desarrolladores no necesitan instalar ni configurar Providers adicionales, sino que pueden usar el paquete estándar crypto tal como está y simplemente activar el modo FIPS (GOFIPS=1). Además, al eliminarse el límite de comunicación con módulos externos, la seguridad se fortalece y, dado que basta con distribuir un único binario compilado estáticamente, la operación se simplifica.
FIPS 140-2 y Golang
Para ello, Golang incorporó en el tiempo de ejecución de Go el módulo BoringCrypto, derivado de BoringSSL, y obtuvo la certificación FIPS 140-2. BoringCrypto puede activarse en ciertas distribuciones a partir de Go 1.19, lo que permite a las aplicaciones Go configurar un entorno certificado FIPS 140-2 sin módulos externos adicionales.
Sin embargo, dado que BoringCrypto se basa en OpenSSL, sigue existiendo una dependencia del lenguaje C. Por ello, las aplicaciones Go no se compilaban como binarios completamente independientes, y existía la limitación de tener que distribuir junto con ellas las bibliotecas C necesarias.
FIPS 140-3 y Golang
Para superar estas limitaciones, el equipo de Go mejoró la biblioteca estándar criptográfica de Go para que cumpliera con la norma FIPS 140-3. Este módulo mejorado comenzó a ofrecerse de forma experimental desde Go 1.21 y actualmente se encuentra en proceso de evaluación para la certificación FIPS 140-3 por parte del NIST.Lista de módulos en proceso de evaluación FIPS 140-3 del NIST
Esto demuestra la madurez de la biblioteca criptográfica de Go y, gracias a ello, Go puede proporcionar un entorno certificado FIPS 140-3 mediante un único binario completamente independiente.
Además, el equipo de Go no se limitó a cumplir con la norma FIPS 140-3, sino que también reforzó la seguridad por su cuenta.
Fail Fast
El modo FIPS de Go aplica el modelo de seguridad Fail Fast, de modo que, si se invoca un algoritmo no certificado, se detiene la ejecución inmediatamente mediante un panic. A diferencia de los modelos basados en Providers de otros lenguajes, que pueden dejar posibilidades de fallback, este enfoque ofrece garantías más estrictas y claras en términos de seguridad y cumplimiento normativo.
Hedged Signature
La norma FIPS 140-3 recomienda el método RFC6979 para las firmas ECDSA. No obstante, Go introduce además el método Hedged, que responde con mayor eficacia a los ataques de canal lateral que pueden producirse durante el proceso de firma.
Generador de números aleatorios reforzado
El generador de números aleatorios de Go utiliza un DRBG (Deterministic Random Bit Generator) en espacio de usuario, y además inyecta entropía adicional del kernel del sistema operativo, de modo que genera números aleatorios de alta calidad tanto en el espacio de usuario como en el espacio del kernel. De este modo, se refuerza aún más la seguridad del generador de números aleatorios.