Never Trust an Unvalidated Crypto Implementation
Imagine you need a safe to store valuables. You could build your own safe from scratch, but unless it has been independently tested and certified, you have no way to know whether it actually resists attacks. FIPS 140-2 is the certification standard for cryptographic "safes" — the software and hardware modules that perform encryption, decryption, and key management.
FIPS 140-2 (Federal Information Processing Standard Publication 140-2) is a US government standard published by NIST that defines security requirements for cryptographic modules. It does not invent new algorithms — AES, SHA-256, and RSA are still the underlying math. Instead, it certifies that the implementation of those algorithms is correct, tamper-resistant, and does not leak sensitive information through side channels.
Security Levels
FIPS 140-2 defines four security levels, each adding more stringent physical and logical protections:
- Level 1: Software-only implementations. Basic algorithm correctness. No physical security requirements. Suitable for low-risk applications.
- Level 2: Adds tamper-evidence (e.g., seals on hardware). Role-based authentication required.
- Level 3: Adds tamper-resistance and identity-based authentication. Zeroizes keys if tamper is detected.
- Level 4: Highest level. Complete physical envelope protection. Any penetration attempt destroys the module. Used in HSMs (Hardware Security Modules) for the most sensitive environments.
Most government and regulated-industry requirements specify Level 1 or Level 2 for software modules, with Level 3 or 4 for hardware key storage.
Architectural Impact: FIPS Mode
When building systems for government or highly regulated industries, you cannot simply install the default OpenSSL package from your Linux distribution's repository and call it done. You must:
- Use FIPS-validated builds: Specific versions of libraries (e.g., OpenSSL with FIPS Object Module, BoringCrypto, or Red Hat's FIPS-validated OpenSSL) that have completed the NIST validation process and received a certificate number.
- Enable FIPS mode at the OS level: Modern Linux distributions (RHEL, Ubuntu in FIPS mode) can be configured so the kernel enforces FIPS-compliant algorithm selection system-wide.
- Restrict algorithm selection: In FIPS mode, weak or unapproved algorithms (MD5, RC4, DES, SHA-1 for signatures) are disabled. Attempting to use them causes an error rather than silently falling back. On Linux, the kernel exposes whether FIPS mode is active as a simple readable flag in
/proc/sys/crypto/fips_enabled.
A common failure mode: a team enables FIPS mode on their servers but their application uses a language runtime (e.g., a Python version or Java JDK) that links against a non-FIPS-validated crypto library. The OS is in FIPS mode, but the application bypasses it entirely. Compliance requires validating the entire cryptographic call chain — OS, runtime, and application library — not just the operating system.
Interviewers often ask: "What does it mean to run in FIPS mode, and what breaks?" The key insight is that FIPS mode is not just a configuration flag — it disables entire algorithm families. Common breakage points include: TLS connections that negotiate SHA-1 or RC4 cipher suites, SSH configurations using deprecated MACs, and application code that uses MD5 for non-security purposes (like cache keys or checksums). A strong answer demonstrates you understand FIPS as a system-wide constraint, not just a library setting.