What is FIPS 140-2/140-3

FIPS 140 (Federal Information Processing Standard 140) is a US/Canadian government standard that specifies security requirements for cryptographic modules — the hardware or software that performs encryption, decryption, hashing, signing, and key management. It doesn’t define which algorithms to use (that’s FIPS 197 for AES, FIPS 186 for DSA/ECDSA, etc.). Instead, it validates that a specific implementation correctly performs approved algorithms and adequately protects cryptographic keys from extraction or tampering.

Why it matters

• Federal mandate — US federal agencies must use FIPS 140-validated modules for cryptographic operations (FISMA requirement). No validation = can’t be used in government systems.
• FedRAMP requirement — cloud services seeking FedRAMP authorization must use FIPS 140-2/3 validated cryptographic modules. This affects AWS, Azure, GCP government regions.
• Financial and healthcare — PCI DSS references FIPS 140 for key management. HIPAA doesn’t mandate it explicitly but auditors frequently require it as evidence of “reasonable safeguards.”
• HSM procurement — when buying Hardware Security Modules, the FIPS 140 level determines physical security guarantees. Level 3 is the standard for CA private keys and payment processing.
• Implementation assurance — a FIPS-validated module has been tested by an accredited lab (CMVP program). This catches implementation bugs (side channels, weak RNG, incorrect algorithm implementation) that code review alone might miss.

How it works

Security Levels:

1. Level 1 — basic requirements. Approved algorithms correctly implemented. No physical security. Example: OpenSSL FIPS module running on a standard server.
2. Level 2 — tamper-evidence (seals, coatings that show if opened). Role-based authentication for operators. Example: HSM with tamper-evident seals.
3. Level 3 — tamper-resistance (active zeroization if tampered). Identity-based authentication (not just role-based). Physical separation between interfaces. Example: Thales Luna, Entrust nShield HSMs used for CA keys.
4. Level 4 — environmental failure protection (voltage, temperature attacks trigger zeroization). Complete envelope of protection. Rare — used in military/intelligence applications.

Validation process:

1. Vendor submits cryptographic module to a CMVP-accredited lab (CST lab)
2. Lab tests against FIPS 140 requirements (algorithm correctness, key management, self-tests, physical security)
3. Lab submits report to CMVP (NIST + CCCS)
4. CMVP reviews and issues validation certificate
5. Module listed on NIST CMVP validated modules list

In real systems

AWS in FIPS mode:

# Use FIPS endpoints for AWS services
aws kms encrypt --endpoint-url https://kms-fips.us-east-1.amazonaws.com \
  --key-id alias/my-key --plaintext fileb://data.bin

# AWS GovCloud and FIPS endpoints use FIPS 140-2 Level 3 HSMs (AWS CloudHSM)
# Standard AWS KMS uses FIPS 140-2 Level 2 validated HSMs

OpenSSL FIPS module:

# Check if OpenSSL is running in FIPS mode
openssl version -a | grep FIPS
# Or programmatically:
openssl list -providers | grep fips

# Enable FIPS mode in OpenSSL 3.x (openssl.cnf):
[openssl_init]
providers = provider_sect
[provider_sect]
fips = fips_sect
[fips_sect]
activate = 1

HSM for CA private keys (FIPS 140-2 Level 3):

# Thales Luna Network HSM
# - CA private key generated inside HSM, never exported
# - All signing operations happen inside the HSM
# - Tamper-resistant: opening the case zeroizes all keys
# - FIPS 140-2 Level 3 validated (certificate #3753)

# PKCS#11 interface for CA software:
pkcs11-tool --module /usr/lib/libCryptoki2_64.so --list-objects --type privkey

Java in FIPS mode:

// Use BouncyCastle FIPS provider
Security.addProvider(new BouncyCastleFipsProvider());
// All crypto operations now use FIPS-validated implementations
// Non-approved algorithms (MD5, DES) throw exceptions

Where it breaks

FIPS mode disables non-approved algorithms — enabling FIPS mode in OpenSSL or Java disables MD5, DES, RC4, and other non-approved algorithms. Legacy applications that use MD5 for checksums (not security-critical) or connect to systems requiring deprecated algorithms will break. You must audit all cryptographic usage before enabling FIPS mode — not just TLS, but also database connections, LDAP, SNMP, and internal protocols.

Validation lag — FIPS validation takes 12-24 months. By the time a module is validated, the software version is often outdated. You may be required to run an older, validated version rather than the latest (patched) version. This creates a tension between “use validated crypto” and “use patched software.” The CMVP’s “Historical” status for modules with known vulnerabilities helps, but the lag remains a real operational constraint.

“FIPS-compliant” vs “FIPS-validated” — vendors claim “FIPS compliance” when they use approved algorithms but haven’t undergone actual CMVP validation. This is meaningless for federal compliance — only modules with a CMVP certificate number on the NIST validated modules list count. Always ask for the certificate number and verify it at csrc.nist.gov/projects/cryptographic-module-validation-program.

Operational insight

The practical impact of FIPS 140 on PKI operations: your CA’s private key must be stored in a FIPS 140-2 Level 3 (or higher) HSM if you’re operating under federal requirements or WebTrust audit. This means the key is generated inside the HSM, never exported, and all signing operations happen on the HSM hardware. If the HSM fails, you can’t “restore the key from backup” to a non-FIPS device — you need another validated HSM. This makes HSM high-availability (HA) and disaster recovery planning critical. Budget for redundant HSMs from day one, not after the first hardware failure takes your CA offline.

Related topics

• What is a Certificate Authority
• PKI Hierarchy Design
• What are Hardware Security Modules
• NIST SP 800-57 Key Management
• What is PKCS