GoSuda

Structure of the FIPS 140-2 and FIPS 140-3 Implementations in the Go Standard Cryptographic Library

By Gosunuts views ...

FIPS 140 ( Federal Information Processing Standard Publication 140 )

FIPS 140 is a security certification standard for cryptographic modules established by the U.S. NIST. This standard evaluates whether a specific cryptographic module or library satisfies the security requirements defined by NIST. Accordingly, passing FIPS 140 certification means that the module has officially been recognized as trustworthy in terms of security, and it signifies that the module can be used in fields where security is critical, such as finance, healthcare, and defense.

Since its initial establishment in 1994, FIPS 140 has been revised to FIPS 140-2 in 2001 and to FIPS 140-3 in 2019. Even now, many systems and applications require FIPS 140-2 or FIPS 140-3 certification.

FIPS 140 and Programming Languages

For this reason, cryptographic modules certified under FIPS 140 are used as a de facto standard across various programming languages and environments. Representative examples include OpenSSL, BoringSSL, LibreSSL, and NSS, which are the modules most widely utilized in security-critical applications.

Most FIPS 140 certified modules are written in C or C++. Consequently, languages such as PHP, Python, and JavaScript typically configure FIPS environments by interfacing with these modules through external Provider modules rather than using them directly. However, this approach has several limitations.

  • Version Mismatch Problem

    FIPS 140 certification is granted only for specific versions. Therefore, using the latest version of a module requires going through the certification process again, and this process may result in a version mismatch between the module used by the application and the FIPS certified module. If an unauthorized version is used, the environment is no longer regarded as a FIPS certified environment.

  • Dynamic Loading and Performance Degradation

    Most languages load FIPS 140 certified modules in the form of dynamic libraries. This approach may cause performance degradation during initialization and execution, and if a problem occurs at runtime, it risks directly affecting the stability of the entire application.

  • Security Vulnerabilities

    As mentioned above, in structures that integrate external modules such as the OpenSSL Provider, there is a risk that security vulnerabilities in the module may propagate directly to the application. In addition, the communication layer between the application and the external module itself becomes an additional attack surface, requiring a separate security layer for protection. This increases complexity and may give rise to unforeseen vulnerabilities.

FIPS 140 and Golang

For this reason, Golang has taken a different strategy. Rather than relying on external tools for FIPS 140 certification, Go has chosen to support it directly within its official cryptographic library. Accordingly, developers do not need to install or configure a separate Provider; they can use the standard crypto package as is and simply enable the FIPS certified mode (GOFIPS=1). In this process, the communication boundary with external modules is eliminated, which strengthens security, and operations are simplified because only a statically compiled single binary needs to be deployed.

FIPS 140-2 and Golang

To this end, Golang embedded the BoringCrypto module, derived from BoringSSL, into the Go runtime and obtained FIPS 140-2 certification. BoringCrypto can be enabled on certain distributions since Go version 1.19, and through this, Go applications can configure a FIPS 140-2 certified environment without any separate external module.

However, because BoringCrypto is based on OpenSSL, a dependency on the C language still exists. Therefore, Go applications were not built as fully independent binaries, and there was the constraint that the required C libraries had to be distributed together with 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 refined module began to be provided experimentally from Go version 1.21, and it is currently undergoing NIST's FIPS 140-3 certification review.NIST FIPS 140-3 Modules In Process List

This demonstrates the maturity of Go's cryptographic library, and through it, Go has become able to provide a FIPS 140-3 certified environment as a fully independent single binary.

Furthermore, the Go team went beyond merely satisfying the FIPS 140-3 standard and independently strengthened its security.

  • Fail Fast

    Go's FIPS mode applies a Fail Fast security model, which immediately halts execution with a panic when a non-certified algorithm is invoked. Unlike Provider-based models in other languages, which leave room for fallback, this offers a stricter and clearer assurance in terms of security and regulatory compliance.

  • Hedged Signature

    The FIPS 140-3 standard recommends the RFC6979 method for ECDSA signing. However, Go additionally introduces a Hedged approach, which responds more robustly to side-channel attacks that may arise during the signing process.

  • Enhanced Random Number Generator

    Go's random number generator uses a user-space DRBG (Deterministic Random Bit Generator) while additionally injecting entropy from the operating system kernel, thereby generating high-quality random numbers not only in user space but also in kernel space. Through this, the security of the random number generator is further strengthened.