Bob's Blog

What Does "FIPS" Really Mean?

People often casually refer to "FIPS compliance", but what do they really mean?

Well, we don't know yet, we need to ask for more detail. It probably has to do with using approved cryptography, but that could refer to different aspects of it. They could mean that their system:

1. Implements a certain set of cryptographic algorithms, and possibly...
2. Also has been audited, and found to be a complete and correct implementation of the cryptographic suite, and possibly...
3. Also has been shown to be supported by an approved patch notification system, including digitally signed update packages and/or source code archives.

In the case of a computer system running Linux, It might also mean that the operating system itself, the Linux kernel, along with various applications running on it, has all be configured to only use a narrow set of cryptographic algorithms with specific key lengths.

This is something that you need to do correctly or not at all. Let's see what all this is about.

"FIPS" stands for Federal Information Processing Standard. It's a set of formal definition by the U.S. Government.

There are several specific FIPS documents! But if someone mentions "FIPS compliance" they are probably talking about FIPS 140, which has to do with using specific cryptographic software to protect information.

Cybersecurity certification exams require you to memorize a large amount of terminology and acronyms, of which a significant fraction is outdated or even wrong. If you have taught certification test-prep courses, as I have, then you have had to recite the same content many times. I have to be careful — their content claimed that the document was FIPS 140-2 while that had been superceded by the newer FIPS 140-3 for a year or two.

FIPS 140 is the document in question, of course you should always make sure to refer to the current version.

It seems that FIPS 140-3 has had a difficult history, complicated by its increased focus on hardware security and disagreement between U.S. Government agencies.

What's in FIPS 140?

If you look at FIPS 140 online expecting to read details of cryptographic algorithms, you will be disappointed.

FIPS 140 is about policy, processes, and procedures. As for which cryptographic algorithms to use for symmetric encryption, asymmetric encryption, key agreement, hash functions, and digital signatures, and for the details of how those algorithms work, it refers you to other FIPS documents and to Specifically, NIST Special Publications. NIST SP 800-140C and SP 800-140D, which in turn reference ISO/IEC 19790 and 24759 as published in specific versions and years.

A company such as Oracle or Canonical or Red Hat (now a part of IBM), or an organization such as the OpenSSL or FreeBSD project, can submit their software implementation to be validated by U.S. NIST, the National Institute of Standards and Technology, or the Canadian Centre for Cyber Security.

Then there's the issue of updates. Does NIST/CCCS approve of how they announce and manage patches and updates? The OpenSSL organization could announce the discovery of a weakness in their shared library and other tools, provided updates through some trusted channel. But then the Linux distributions maintained by Oracle, Canonical, and Red Hat include OpenSSL, and they also handle announcements and updates through their online repositories of packages.

What Should the Cryptographic Suite Include?

We need a toolkit that includes at least one component for each of these categories:

1. Symmetric cipher, to encrypt data.
2. Asymmetric cipher, to play various roles in authentication and symmetric key agreement.
3. Hash function, for integrity checking and authentication. It will be the core of an HMAC or Hash-based Message Authentication Code verifying both data integrity and sender authentication.
4. Key agreement or key establishment function, allowing two hosts to agree upon a shared session key to be used with a symmetric cipher. This might be based on an asymmetric cipher, or it might be something like the classic Diffie-Hellman algorithm.
5. Key derivation function, to significantly increase the entropy, and thus the resistance to attack and brute-force search, of a human-chosen key or pass phrase.

Some of those need further details defined. Symmetric block ciphers can operate in several different modes. Symmetric and asymmetric ciphers, HMAC, and key agreement functions all need to specify the size of a key or similar parameter. (For example, the size of the finite field for DSA, the modulus for classic Diffie-Hellman, or the order of the base point for elliptic-curve cryptography)

We need at least one tool for each those tasks. In the U.S., the NSA has specified what they must be in the case of systems handling Government information.

NSA announced Suite A and Suite B cryptography in 2005. They published Suite B, and said that Suite A exists for use in more sensitive settings. They made some minor adjustments throug the following years, almost entirely in required key lengths.

Then, in 2018, NSA announced that Suite B no longer matter, and the CNSA or Commercial National Security Algorithm Suite should be used to protect information up to the Top Secret level. The NSA said that it was planning for a transition to quantum-resistant cryptography, also called quantum-safe or post-quantum. CNSA included:

• AES with 256-bit keys, using an appropriate block cipher mode for the application. (e.g., AES-GCM-256 in the case of TLS data streams, etc.)
• ECDH and ECDSA, Elliptic-Curve Diffie-Hellman and Elliptic-Curve Digital Signature Algorithm, both using curve P-384 published by NIST.
• Classic Diffie-Hellman with a minimum 3072-bit modulus.
• RSA with a minimum 3072-bit modulus.
• SHA-2-384 (or SHA-2-512).

By mid-2023 the NSA seemed to have removed all discussion of CNSA from its website.

And So, In Summary...

For a Linux server to be truly FIPS 140 compliant, you have three requirements:

First, you must use an approved distribution such as Oracle, Red Hat, or Ubuntu.

Second, configure the kernel to only use CNSA algorithms for kernel tasks. Those include storage encryption with LUKS, managed by cryptsetup, and IPsec. You do this by booting the kernel with the fips=1 parameter. This used to be relatively easy to configure — edit a file and add that parameter in two places, rebuild the GRUB boot loader configuration, and reboot:

# vim /etc/default/grub
[... magic happens here ...]
# grep GRUB_CMDLINE_LINUX /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet fips=1"
GRUB_CMDLINE_LINUX="quiet fips=1"
# update-grub
# reboot

Beware: systemd meddling that began with RHEL 8 breaks the above simple solution, forcing you to deal with the file whose name can be generated with:
/boot/loader/entries/$(cat /etc/machine-id)-$(uname -r).conf
Booting the PC architecture was already overly complex. So of course systemd made it worse. See these pages for hints:
https://access.redhat.com/solution/3710121
https://access.redhat.com/solution/3766391
https://uapi-group.org/specifications/specs/boot_loader_specification/
systemd-boot(7) manual page
Supposedly the /bin/kernel-install script can safely handle it for you, if you aren't doing a normal kernel upgrade through the package manager.

Third, configure applications to only use CSNA algorithms for their tasks. This has also become more complicated starting with RHEL 8. For the SSH service, this used to be done entirely in /etc/ssh/sshd_config. Starting with RHEL 8, you must also modify /etc/crypto-policies/back-ends/opensshserver.config to make your system compliant to the DoD's STIG, or Security Technology Implementation Guide.

If you added another network service such as a web server by building it from source, you may need to also modify its configuration. I have pages explaining examples for Nginx's nginx and Apache's httpd