Introducing modularized kernel cryptography in Amazon Linux

Post Syndicated from Mahak Arora original https://aws.amazon.com/blogs/compute/introducing-modularized-kernel-cryptography-in-amazon-linux/

We are introducing modularized kernel cryptography in Amazon Linux 2023, an approach that separates Federal Information Processing Standard (FIPS) 140-3 cryptographic components into an independent kernel module that can be certified once and reused across subsequent kernel versions. In this post, we describe how this modular approach works, what it means for FIPS compliance workflows, and how customers can prepare for adoption.

Previously, when any part of the kernel changed, the entire kernel binary had to go through FIPS re-certification because the cryptographic code was embedded within it. With this modular approach, only the standalone cryptographic module undergoes validation, which means non-cryptographic kernel changes no longer require full re-certification. This can help customers who need both security updates and FIPS-validated cryptography while reducing disruption.

FIPS 140-3 validation can be a critical requirement for customers in regulated environments, including federal contractors. Previously, this re-certification process meant customers had to wait 12-18 months for each new kernel version to complete validation before they could adopt it. With the modular approach, once the module is validated it is designed to carry forward across kernel updates, whether minor or major releases, through a streamlined update process rather than repeating the full certification cycle, as long as the module itself remains unchanged. This is particularly relevant as customers face growing pressure to apply security patches rapidly while helping to maintain continuous compliance.

The FIPS re-certification process can be time-intensive with unpredictable timelines given current NIST Cryptographic Module Validation Program (CMVP) processing volumes. To help address this, we isolate all FIPS-scoped cryptographic algorithms, self-tests, and integrity checks into a single loadable kernel module that defines its own FIPS 140-3 cryptographic boundary with a stable interface to the kernel. This reduces what must be re-validated because instead of certifying the entire kernel binary which contains millions of lines of non-cryptographic code, only the standalone module containing the cryptographic implementation falls within the certification scope. For subsequent kernel versions using an unchanged module, re-validation can follow a more streamlined process rather than requiring a full certification cycle, helping our customers adopt kernel updates without the re-certification delays they previously faced, as long as the certified module itself remains unchanged.

We submitted the module for FIPS 140-3 validation. Based on current CMVP processing timelines, validation is expected to complete in 2027. The module interface boundary is designed to remain stable across kernel versions. Changes to the module are required if the kernel internal cryptographic API changes or if new algorithms need to be added to the FIPS scope. In many of these cases, changes can be absorbed by the interface layer without modifying the certified module itself, reducing the need for full re-certification.

Technical overview

The modular capability is included in AL2023 kernel 6.18 and later versions. The module loads automatically at boot with no kernel rebuild or configuration change required. To operate in FIPS mode, follow the enablement guide referenced in the customer guidance section below. This change does not affect other FIPS user-space modules such as OpenSSL, libgcrypt, and NSS.

The following diagram illustrates the architectural shift:

Diagram showing kernel cryptography architecture before and after modularization, with the FIPS crypto module separated from the kernel binary

Figure 1. Kernel cryptography architecture before and after modularization.

The implementation spans two areas described below. The kernel build process produces the module as a separate artifact, and a boot-time mechanism loads and connects it to the running kernel.

A restructured kernel build

In the standard kernel build, crypto source code is compiled and statically linked together with other non-crypto components that are not in scope for FIPS to produce the final kernel image. With this change, the build process separates the FIPS-relevant cryptographic components from the kernel image by defining customized compilation rules. Crypto components that are FIPS-related and were previously built into the kernel are now automatically collected and linked separately into a standalone crypto kernel module. The new build process requires no changes to existing build workflows.

Boot-time module plug-in mechanism

Immediately after kernel boot starts, the crypto kernel module is loaded and initialized. Low-level interfaces such as function addresses are connected back to the kernel binary interface so that the module integrates seamlessly with the running kernel. Once loaded, kernel crypto subsystems and their services behave as if they were built in, with the same algorithmic implementations and call paths. This process was designed to not have a material impact on performance. This loading process is independent of FIPS mode configuration because FIPS mode controls how cryptographic algorithms behave at runtime while modularization determines how they are built and delivered within the kernel. To learn more about the design and implementation, see the detailed writeup on LWN.net.

Industry impact and benefits

Once the module completes validation, modularized kernel cryptography can help customers in regulated industries update kernels more frequently while maintaining their FIPS validation status. Customers who previously faced 12-18 month re-certification delays with each kernel version can instead adopt updates as they are released, whether they operate in financial services, healthcare, government, or any sector requiring FIPS-validated cryptography. This can help customers who want to apply critical security patches without a full certification cycle before deployment.

Customer guidance

When evaluating kernel options, customers should consider their specific regulatory requirements, the validation status of cryptographic modules, and their system requirements in accordance with all applicable authorization processes.

Customers who require a completed FIPS 140-3 certificate should continue using AL2023 kernel 6.1, which maintains active validation through 2029-09-22. The modularized crypto module is included in kernel 6.18 and initializes automatically at boot. The module is designed to not require configuration changes and preserves current behavior for non-FIPS workloads. Customers planning FIPS adoption can begin evaluation and testing ahead of formal certification.

Once validation is complete, customers can transition production workloads to kernel 6.18 or later with the validated module by following the FIPS Mode enablement guide for configuration.

Conclusion

To enable FIPS mode on AL2023, refer to our FIPS Mode enablement guide. For regular updates and best practices, follow the AWS Security Blog and FIPS-related FAQs on Amazon Linux 2023. You can also reach out to your AWS account team for help finding the resources you need.

If you have questions about this post, contact AWS Support.