Kernel-Independent FIPS Images

Chainguard FIPS Images are now available for deployment on any Linux kernel. Previously, developers were required to provision dedicated hardware and virtual machines (VMs) with the host kernel configured in FIPS mode. In cloud native or shared environments, this requirement significantly increased operational complexity by forcing a dependence on a limited set of FIPS-enabled kernels. For engineering and security teams, that meant patching and maintaining expensive legacy software. For compliance teams, that meant additional obstacles on the path to achieving & maintaining compliance with critical regulations.

Chainguard FIPS Images remove this friction with a novel design that replaces a kernel entropy source with a userspace one. This implementation enables developers to deploy FIPS workloads using any of the latest kernels, hardware, and instance types. Chainguard FIPS Images thus unlock the ability to run FIPS workloads on developer machines, existing CI/CD deployments, and even on readily available non-FIPS managed cloud offerings. All this can be done using the latest userspace runtimes like NodeJS, Python, Go, PHP, .NET, and C/C++, among others.

With Chainguard, you can build better, more secure software by deploying workloads on the latest hardware, most performant instance types, and latest application run times. Chainguard Images offer all that flexibility while maintaining zero CVEs under our SLA, delivering FIPS compliance, and eliminating redundant investments in FIPS-specific operating systems.

In this article, we’ll look more closely at “yesterday’s design” of FIPS deployments, and what Chainguard is doing to make deploying FIPS easier today. 

Generic FIPS Yesterday

Cryptographic protection relies on the secure implementation of a trusted algorithm and a random bit generator that cannot be reasonably predicted at any greater accuracy than random chance. To certify these implementations, the National Institute of Standards and Technology (NIST) operates a cryptographic certification program called the Cryptographic Module Validation Program (CMVP). CMVP validates that implementation is compliant with the relevant standards below. 

• For algorithm implementation, CMVP requires strict compliance with FIPS standards.Thus FIPS modules must sit inside a self-verified cryptographic boundary. 

• For random bit generators, CMVP requires strict compliance with SP 800-90B recommendations and permits entropy sources to sit either inside or outside the FIPS cryptographic boundary.

Traditionally, to achieve this compliance requirement, containers would access SP 800-90B compliant entropy source provided by a certified kernel. See Figure 1 for a graphical representation of this combination.

There is a key issue with this design: while container applications do need access to the kernel entropy source, they do not use the kernel FIPS module. The above design needlessly creates a dependency on a second FIPS cryptographic boundary, resulting in duplicated maintenance and certification efforts.

This design, which requires maintenance of FIPS cryptographic boundaries at the kernel-level, drives significant friction for vendors delivering  FIPS compliant workloads  for  modern cloud-native applications. First, very few versions of the Linux Kernel are certified. Second, Linux Kernel certification timelines are often long and arduous. 

Ultimately, this results in a very limited choice of certified runtimes and compatible underlying hardware for developers to build on. In practice, it means that a certified kernel from a given vendor might be over 5 years old. Outdated kernels typically lack support and optimizations for the latest generation of hardware, and are often incompatible with the latest cloud instance types. It also means when sticking to the same vendor, the application runtimes are equally as out of date and vulnerable.

Chainguard FIPS Today

Chainguard has introduced and implemented a cleaner solution where the FIPS module and the SP 800-90B entropy source can be co-located in the container image userspace. This eliminates the need for a certified Linux kernel for the majority of workloads and streamlines engineering effort for workload deployments. This is why Chainguard FIPS images now ship with a certified userspace SP 800-90B entropy source. See Figure 2 for a graphical representation of this new kernel-independent FIPS.

Under Chainguard’s novel design, the container image for a given FIPS application can be entirely self-contained, minimal, and distroless. Each container image comes with both a certified FIPS module and a certified SP 800-90B entropy source. This container image can be deployed on any user-affirmed operating environment, including the latest generations of hardware and host kernel versions.

Additionally, Chainguard’s design is available for the majority of programming language ecosystems like Python, NodeJS, Go, .NET, PHP, and C/C++, and others. The standard library in each respective ecosystem uses OpenSSL, which has itself been configured at runtime to use a certified FIPS module and a certified SP 800-90B entropy source. In short, this design allows FIPS-compliant cryptography when using most programming language ecosystems. See Chainguard's certifications here.

The majority of our FIPS images are now Kernel-Independent FIPS images, including:

• python-fips: 3.10, 3.11, 3.12, 3.13

• nodejs-fips: 18, 20, 21, 22, 23

• go-fips & go-msft-fips: 1.21, 1.22, 1.23

• dotnet-fips: 6, 7, 8, and soon 9

• php-fips: 8.2, 8.3, and soon 8.4

… and many other applications built on top of these language ecosystems. Check out our full catalog of over 300 Chainguard FIPS images to see what we’re offering.

Developers can run all of these containers across a wide variety of deployments and use cases:

• Developer workstations

• Existing CI/CD pipelines 

• Deployments requiring FIPS certification like FedRAMP and DoD

With a unified codebase, dependencies, and deployment, you can achieve FIPS-by-default, without the arduous, additional effort.

Limitations

There are some workloads that require a kernel SP 800-90B entropy source or a kernel FIPS module. These include but are not limited to: Chainguard FIPS images shipping Java, k8s CNI plugins, LUKS2 full-disk encryption, and StrongSwan VPN. These use cases will continue to require a kernel in FIPS mode.

Fully open-source solution

In implementing our Kernel-Independent FIPS design, Chainguard leaned on our commercial partnerships and strong bonds with the open source community. We relied on fully open source software and have contributed our implementation back to the community. The engineering work to enable OpenSSL to use Jitter Entropy Library was contributed by Chainguard to the OpenSSL project in v3.4.0 release, under a permissive Apache-2.0 license. The Jitter Entropy library technology is used by the majority of FIPS Linux kernels to certify as a SP 800-90B entropy source.

Thanks to the OpenSSL support contract, we were able to achieve rebrand certification of the OpenSSL FIPS module with the Acumen certification lab. Together with Atsec certification lab, we were able to certify SP 800-90B entropy source in record time. 

Ultimately, Chainguard has created a production-grade FIPS container image implementation that is fully open-source.

Chainguard FIPS Images: No Compromise Needed

Chainguard FIPS Images is an ideal solution for SaaS, on-prem, and physical edge device product deployments. Chainguard enables developers to unify their codebases and runtime dependencies between commercial and FIPS product lines, and standardize on their choice of Linux kernel. No longer are engineering organizations required to compromise between choosing the latest and greatest software, compatible hardware, and achieving FIPS compliance.

On our mission to become the safe source for open source, we will make it easier to build better software. That means upgrading kernels faster, staying close to the mainline distribution version, and securing the kernel by default.  

Check out our full catalog of over 300 Chainguard FIPS images, and contact us if you would like to learn more!