FIPS 140 Certification and Golang
FIPS 140 (Federal Information Processing Standard Publication 140)
FIPS 140 is a security certification standard for cryptographic modules established by the US NIST. This standard evaluates whether a specific cryptographic module or library satisfies the security requirements defined by NIST. Therefore, passing FIPS 140 certification signifies that the module possesses officially trustworthy security and can be utilized in security-critical domains such as finance, healthcare, and national defense.
FIPS 140 was initially established in 1994, subsequently revised to FIPS 140-2 in 2001, and then to FIPS 140-3 in 2019. To date, many systems and applications continue to require FIPS 140-2 or FIPS 140-3 certification.
FIPS 140 and Programming Languages
For these reasons, FIPS 140-certified cryptographic modules are used as a de facto standard across various programming languages and environments. Notable examples include OpenSSL, BoringSSL, LibreSSL, and NSS, which are the most widely utilized modules in security-critical applications.
Most FIPS 140-certified modules are written in C or C++. Consequently, languages such as PHP, Python, and Javascript configure FIPS environments by integrating with these modules via external Provider modules, rather than directly using them. However, this approach presents several limitations.
Version Mismatch Issues
FIPS 140 certification is granted only for specific versions. Therefore, to use the latest version of a module, the certification process must be repeated, which can lead to version discrepancies between the module used by the application and the FIPS-certified module. If an unauthorized version is used, the environment will no longer be considered a FIPS-certified environment.
Dynamic Loading and Performance Degradation
Most languages load FIPS 140-certified modules as dynamic libraries. This method can cause performance degradation during initialization and execution, and if issues arise during runtime, there is a risk of directly impacting the overall stability of the application.
Security Vulnerabilities
As previously stated, in a structure where external modules like OpenSSL Provider are integrated, there is a risk of security vulnerabilities in those modules directly propagating to the application. Furthermore, the communication layer itself between the application and external modules becomes an additional attack surface, necessitating a separate security layer to protect it. This increases complexity and can introduce unforeseen vulnerabilities.
FIPS 140 and Golang
For these reasons, Golang adopted a different strategy. Go chose to directly support FIPS 140 certification within its official cryptographic library, rather than relying on external tools. Consequently, developers can simply activate FIPS-certified mode (GOFIPS=1) while continuing to use the standard crypto package, without the need to install or configure a separate Provider. This process eliminates communication boundaries with external modules, enhancing security, and simplifies operations as only a single statically compiled binary needs to be deployed.
FIPS 140-2 and Golang
To achieve this, Golang integrated the BoringCrypto module, derived from BoringSSL, into the Go runtime to obtain FIPS 140-2 certification. BoringCrypto can be activated in specific distributions of Go versions 1.19 and later, allowing Go applications to establish a FIPS 140-2 certified environment without requiring separate external modules.
However, since BoringCrypto is based on OpenSSL, a dependency on the C language still exists. Thus, Go applications were not built as completely independent binaries, and there was a constraint to distribute the necessary C libraries alongside them.
FIPS 140-3 and Golang
To overcome these limitations, the Go team improved the existing Go standard crypto library to conform to the FIPS 140-3 specification. This enhanced module began to be experimentally provided starting with Go version 1.21, and its NIST FIPS 140-3 certification review is currently in progress.List of Modules In Process for NIST FIPS 140-3 Review
This demonstrates the maturity of the Go cryptographic library, enabling Go to provide a FIPS 140-3 certified environment as a completely independent single binary.
Furthermore, the Go team did not merely meet the FIPS 140-3 standard but also independently enhanced its security.
Fail Fast
Go's FIPS mode implements a Fail Fast security model, where calling an uncertified algorithm immediately halts execution with a panic. Unlike other language's Provider-based models, which allow for fallback possibilities, this provides a more stringent and unambiguous assurance in terms of security and regulatory compliance.
Hedged Signature
The FIPS 140-3 standard recommends the RFC6979 method for ECDSA signatures. However, Go additionally incorporates a Hedged approach, which provides stronger resistance against side-channel attacks that may occur during the signing process.
Enhanced Random Number Generator
Go's random number generator utilizes a user-space DRBG (Deterministic Random Bit Generator) while also injecting additional entropy into the operating system kernel, thereby generating high-quality random numbers not only in user space but also in kernel space. This further enhances the security of the random number generator.