Chapter 6: FIPS 140-3 Validation Path

6.1 Overview of the FIPS 140-3 Framework

NIST FIPS 140-3 was approved by the U.S. Secretary of Commerce on March 22, 2019 as the successor to FIPS 140-2 (approved May 25, 2001). Unlike its predecessor, FIPS 140-3 does not define cryptographic module security requirements from scratch; instead it formally adopts ISO/IEC 19790:2025 (Information technology — Security techniques — Security requirements for cryptographic modules) as the normative body and ISO/IEC 24759:2025 (Test requirements for cryptographic modules) as the testing body. For the first time, the United States and the international standards community operate cryptographic module validation on a single normative core, and joint operation with the Canadian Centre for Cyber Security (CCCS) follows naturally.

TLS Lite targets resource-constrained hosts — IoT gateways, industrial PLCs, medical devices — where the embedded cryptographic module itself becomes the validation subject. The X25519 key exchange, ed25519 signatures, HKDF-Expand, and AES-GCM authenticated encryption that the TLS Lite envelope binds together are each enumerated in the FIPS 140-3 test catalogue. This chapter does more than quote the normative text; it walks an implementer step by step through the practical path of placing a module with a valid Validation Certificate inside a TLS Lite host.

FIPS 140-3 validation operates on two axes. First, CAVP (Cryptographic Algorithm Validation Program) issues per-algorithm validation — for example, certifying that the AES-GCM implementation of a given module passes every NIST SP 800-38D test vector. Second, CMVP (Cryptographic Module Validation Program) issues whole-module validation. Beyond algorithmic correctness, CMVP audits 11 areas including physical boundary, self-tests, key management, operational environment, and role-based authentication, with an accredited NVLAP laboratory providing the test report and NIST plus CCCS assigning the final certificate number.

Operators frequently confuse "vendor affirmation" with a CMVP certificate. Vendor affirmation is a manufacturer's self-declaration of "FIPS 140-3 compatibility" and carries no legal force. U.S. federal procurement (under the Federal Information Security Modernization Act, FISMA) and Korean public procurement (CC EAL plus KCMVP) recognize only modules bearing an actual certificate number. This chapter walks the formal certificate path.

6.2 Major Changes from FIPS 140-2 to 140-3

FIPS 140-3 introduces material change in twelve areas relative to FIPS 140-2. The most significant is that the normative body itself shifted from a NIST-authored standard to the adoption of ISO/IEC 19790:2025, which structurally enables mutual recognition with non-U.S. validation authorities in Korea, Japan, and the EU. Table 6-1 summarizes the twelve change areas.

The most operationally consequential change is the strengthened requirement on non-deterministic random bit generation. FIPS 140-3 mandates not only SP 800-90A (DRBG mechanisms) but also SP 800-90B (entropy source assessment) and SP 800-90C (RBG construction). The TLS Lite envelope's nonce generation and X25519 private-key generation both depend on this RBG, so evidence of conformance for the hardware entropy source on the host board (which must pass continuous health tests) becomes part of the validation package.

6.3 Security Levels 1 to 4

FIPS 140-3 defines four security levels rather than a single grade. A module receives a level for each of the 11 areas, and the overall module level is determined by the lowest area level — the weakest-link rule. Table 6-2 summarizes the area-by-area requirements.

For the TLS Lite target market (IoT and industrial), Level 2 or Level 3 is the most common requirement. General gateways and consumer IoT devices typically suffice at Level 1, while industrial PLCs, medical devices, and financial payment terminals require Level 2 to 3. Level 4 is reserved for extreme threat environments such as nuclear facilities and national secret communications; as of May 2026, only about 12 Level 4 modules are listed on the CMVP register.

A module manufacturer's validation lead has observed in retrospective notes that the leap from Level 2 to Level 3 is fundamentally the transition from "tamper-evident" to "tamper-responsive." This is not merely a thicker tamper seal — it requires a hardware redesign that embeds tamper-detection circuitry inside the silicon, wired directly to immediate key-zeroization logic. Non-recurring engineering (NRE) cost typically grows by a factor of 8 to 15, and the schedule slips by six months or more.

6.4 CMVP Procedure and Average Timelines

CMVP is the module validation program jointly operated by NIST and CCCS. The operational queue (Modules in Process List) is updated weekly on the NIST CSRC site. As of May 2026, the average timeline is shown in Table 6-3.

As of May 2026, the NIST CSRC Modules in Process page lists approximately 380 modules in the queue, of which roughly 75% are in "Review Pending" state awaiting NIST and CCCS adjudication. The lengthening dwell time reflects the FIPS 140-3 transition deadline of September 22, 2026, after which all FIPS 140-2 certificates retire. Since the second half of 2024, all new and renewal submissions have funneled into the 140-3 path, exceeding NIST processing capacity by a factor of about 1.6.

Two practical implications follow. First, any new module aimed at market entry must allocate at least 18 months of validation lead time inside the overall product roadmap. Second, the OEM rebranding path — embedding an already-certified module into one's own host — is dramatically faster than self-certification. For most TLS Lite implementers, the latter is the rational choice.

6.5 Approved vs Allowed Algorithms

FIPS 140-3 classifies algorithms into three tiers. Approved (algorithms that NIST has formally approved), Allowed (algorithms that may be used inside an Approved module as auxiliary functions), and Non-Approved (algorithms forbidden in FIPS mode). Table 6-4 maps the TLS Lite algorithm set onto these tiers.

The cipher-suite pool defined by the TLS Lite envelope is deliberately confined to FIPS-Approved algorithms. Specifically, TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384 for record protection, X25519 (or P-256 ECDHE) for key exchange, and ed25519 (or ECDSA-P-256) for signatures. While TLS_CHACHA20_POLY1305_SHA256 is recommended in RFC 8446, it is absent from the FIPS 140-3 Approved list and therefore must not be negotiated on a FIPS-mode host (either by suppressing the TLS extension or by server refusal even when the client offers it). This conditional logic is specified in TLS Lite Phase 2 §B.3 cipher negotiation.

6.6 Module Boundary and Self-Tests

Every FIPS 140-3 validation begins by defining the Cryptographic Module Boundary. The boundary must be declared as physical (chip, board, box), logical (DLL, SO, library), or hybrid. The TLS Lite reference implementation wia/tls-lite-host:1.0.0, when configured with the OpenSSL 3.x FIPS provider, is defined as a logical boundary. Inside the boundary live the cryptographic primitives (AES, SHA, HMAC, X25519, ed25519), the DRBG, the self-test code, and the key-storage interface. Envelope serialization, logging, and API handlers reside outside the boundary.

Table 6-6 lists the self-test categories required by FIPS 140-3 and their triggers.

The heart of POST is the Known-Answer Test (KAT). On every boot, the module verifies that each algorithm produces the exact expected output for test vectors pre-burned into the module image. The pseudocode below illustrates the POST that the TLS Lite reference implementation executes on boot.

// FIPS 140-3 Power-on Self-test (POST) pseudocode
// TLS Lite reference implementation — wia/tls-lite-host:1.0.0

module_state = INITIALIZING

function fips_post():
    // 1. Pre-operational: module binary integrity
    expected_hmac = "0x3F8A...C217"   // Burned at build time
    actual_hmac   = HMAC_SHA256(module_binary, integrity_key)
    if (actual_hmac != expected_hmac):
        module_state = ERROR
        emit_audit("FIPS_POST_FAIL", "integrity")
        return REFUSE_TO_START

    // 2. KAT: AES-128-GCM
    pt  = "0x00112233...EEFF"
    key = "0x00010203...0F"
    iv  = "0xCAFEBABE...01"
    ct_expected = "0xA1B2C3...D4E5"
    ct_actual   = AES_128_GCM_Encrypt(pt, key, iv)
    if (ct_actual != ct_expected):
        module_state = ERROR
        emit_audit("FIPS_POST_FAIL", "AES-128-GCM")
        return REFUSE_TO_START

    // 3. KAT: SHA-256
    msg = "abc"
    h_expected = "0xBA7816BF...AD15"
    h_actual   = SHA256(msg)
    if (h_actual != h_expected):
        module_state = ERROR
        emit_audit("FIPS_POST_FAIL", "SHA-256")
        return REFUSE_TO_START

    // 4. KAT: HMAC-SHA-256
    // 5. KAT: ECDSA-P-256 sign / verify
    // 6. KAT: X25519 (ECDH)
    // 7. KAT: ed25519 sign / verify
    // 8. KAT: HKDF-SHA-256
    // 9. DRBG instantiate + generate (SP 800-90A)
    // 10. Continuous DRBG seed comparison

    module_state = OPERATIONAL
    emit_audit("FIPS_POST_OK", "all-algorithms")
    return READY

// During normal operation, CRT runs on every key generation
function on_key_generation(alg):
    keypair = alg.generate()
    test_sig = alg.sign(keypair.priv, "test-vector")
    ok = alg.verify(keypair.pub, "test-vector", test_sig)
    if (!ok):
        emit_audit("FIPS_CRT_FAIL", alg)
        zeroize(keypair)
        return REFUSE_KEY
    return keypair

The crucial failure-handling rule is: upon entering Error State, no cryptographic service shall respond. A self-test failure signals module compromise, and continuing to serve from a compromised module is equivalent to accepting tampered communication as legitimate. The TLS Lite envelope class defines a host-level error code (WIA-TLS-LITE-MODULE-ERROR) that the host returns when its module enters Error State, ensuring operators can detect and isolate the failure immediately.

6.7 Approved Algorithm Inventory Declaration

One of the principal deliverables in a FIPS 140-3 validation package is the Security Policy document. Inside it, every algorithm offered by the module in Approved Mode is enumerated together with its parameters. The JSON snippet below illustrates the inventory that the TLS Lite reference implementation declares in its Security Policy (the actual document is published as PDF).

{
  "module": "WIA TLS Lite Cryptographic Module",
  "version": "1.0.0",
  "fips_140_3_level": 2,
  "validation_certificate": "PENDING-CMVP-2026Q4",
  "approved_algorithms": [
    {
      "name": "AES",
      "modes": ["GCM-128", "GCM-256"],
      "ref": "FIPS 197 + SP 800-38D",
      "cavp_cert": "A-4521"
    },
    {
      "name": "SHA-2",
      "modes": ["SHA-256", "SHA-384"],
      "ref": "FIPS 180-4",
      "cavp_cert": "A-4522"
    },
    {
      "name": "SHA-3",
      "modes": ["SHA3-256"],
      "ref": "FIPS 202",
      "cavp_cert": "A-4523"
    },
    {
      "name": "HMAC",
      "modes": ["HMAC-SHA-256"],
      "ref": "FIPS 198-1",
      "cavp_cert": "A-4524"
    },
    {
      "name": "HKDF",
      "modes": ["HKDF-SHA-256"],
      "ref": "SP 800-56C Rev. 2",
      "cavp_cert": "A-4525"
    },
    {
      "name": "ECDSA",
      "modes": ["P-256", "P-384"],
      "ref": "FIPS 186-5",
      "cavp_cert": "A-4526"
    },
    {
      "name": "X25519",
      "modes": ["ECDH-Curve25519"],
      "ref": "SP 800-186 + RFC 7748",
      "cavp_cert": "A-4527"
    },
    {
      "name": "Ed25519",
      "modes": ["sign-verify"],
      "ref": "FIPS 186-5 + RFC 8032",
      "cavp_cert": "A-4528"
    },
    {
      "name": "DRBG",
      "modes": ["HMAC-DRBG-SHA-256"],
      "ref": "SP 800-90A Rev. 1",
      "cavp_cert": "A-4529"
    }
  ],
  "non_approved_algorithms_disabled_in_fips_mode": [
    "ChaCha20-Poly1305",
    "MD5",
    "SHA-1 (signature only)",
    "3DES",
    "RC4"
  ],
  "tls_lite_cipher_suites_approved": [
    "TLS_AES_128_GCM_SHA256",
    "TLS_AES_256_GCM_SHA384"
  ],
  "tls_lite_cipher_suites_disabled_fips": [
    "TLS_CHACHA20_POLY1305_SHA256"
  ]
}

This inventory must be demonstrably one-to-one with the code paths inside the real module. The CMVP reviewer cross-checks every Security Policy entry against evidence that the algorithm is present in the module and, conversely, that no algorithm outside the inventory is reachable in FIPS mode. Adding a single line to the inventory therefore typically converts to roughly one extra month of test scheduling. The deliberately narrow cipher-suite pool of the TLS Lite envelope is a direct response to this cost structure.

6.8 Key Lifecycle Management

FIPS 140-3 §7.9 (Sensitive Security Parameter Management) governs the full key lifecycle — generation, agreement, storage, use, export, and destruction — and prescribes per-stage controls. TLS Lite handles three key types inside the envelope: session keys (AES-128-GCM keys), key-exchange private keys (X25519 priv), and signing private keys (ed25519 priv). Each lifecycle is designed to meet the Level 2 requirements of Table 6-2.

Session keys are derived freshly on every TLS Lite handshake via HKDF-Expand-Label and zeroized immediately on session close. Zeroization is not a plain free() call; it must be an explicit write of zero bytes into memory (for instance OpenSSL's OPENSSL_cleanse), and the call must survive compiler optimization either through a volatile qualifier or a memory barrier.

Key-exchange private keys (X25519 priv) are envelope-scoped ephemerals — generated and destroyed per envelope to guarantee forward secrecy. Signing private keys (ed25519 priv) are long-term keys bound to the host identifier, stored inside the OS keystore or an HSM (Hardware Security Module), and never leave the module boundary in plaintext. To exit the boundary they must be wrapped with SP 800-38F AES Key Wrap.

6.9 Operational Environment and Modes

FIPS 140-3 allows a module to operate in two modes — Approved Mode and Non-Approved Mode. The separation must be enforced by code, the operator must be explicitly notified of the active mode (for example via boot log and admin console indication), and keys or CSPs must never cross between modes. The TLS Lite reference implementation forces Approved Mode via the environment variable WIA_TLS_LITE_FIPS_MODE=1; in this mode the ChaCha20-Poly1305 cipher suite is automatically removed from negotiation.

The operational environment itself carries level-dependent requirements. Level 1 permits any general-purpose OS, while Level 2 and above require the OS to be evaluated under Common Criteria (ISO/IEC 15408) at EAL2 or higher. In Korea, KCC (Korea Common Criteria) certified options include RHEL, SUSE, Tmax OS, and Inbox OS; whether KCC certification is recognized as equivalent to U.S. NIAP (National Information Assurance Partnership) certification is established on a case-by-case basis under existing mutual-recognition arrangements.

Note on Korean Edition: KCMVP and Domestic Module Validation

The Korean Edition of this chapter discusses the Korea Cryptographic Module Validation Program (KCMVP) operated by the National Intelligence Service (NIS) IT Security Certification Center, the role of the Telecommunications Technology Association (TTA), the Korea Internet & Security Agency (KISA) test laboratory, and the Korea Institute of Information Security and Cryptology (KIISC) cryptography committee. Readers needing operational mapping to Korean domestic algorithms (SEED, HIGHT, LEA, ARIA, KCDSA, EC-KCDSA, LSH), to Samsung Knox KCMVP certifications, or to the SK Telecom and KT 5G security gateways embedding KCMVP modules should consult the Korean Edition. The substantive technical content of the present chapter applies uniformly across jurisdictions. For convenience, Table 6-5 summarises how KCMVP and CMVP differ in scope.

6.10 Wiring the Validation Package

TLS Lite Phase 4 §C.6 defines how an operator attaches the FIPS certificate of their embedded module to the envelope metadata. The module_validation object inside the envelope carries the program identifier (CMVP or KCMVP), the certificate number, the security level, and the validation expiry date. A federation peer inspects this metadata and, if it fails to match the local policy (for example, "Level 2 or higher only"), can refuse the envelope.

Implementers can validate the chapter's deliverables against the following checklist. (a) The simulator's cipher panel at simulator/index.html#cipher shows TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, X25519, and ed25519 as Approved. (b) The same panel shows TLS_CHACHA20_POLY1305_SHA256 as Disabled in FIPS mode. (c) The module emits a single structured audit line with the POST result on boot. (d) The Security Policy algorithm inventory is in one-to-one correspondence with the real code paths. (e) Hosts that target KCMVP-aligned deployment additionally negotiate the ARIA and SEED cipher-suite variants.

Normative references touched in this chapter

• NIST FIPS 140-3 (Security Requirements for Cryptographic Modules, 2019)
• ISO/IEC 19790:2025 (Security requirements for cryptographic modules)
• ISO/IEC 24759:2025 (Test requirements for cryptographic modules)
• NIST SP 800-140A through F (CMVP Documentation Requirements)
• NIST SP 800-131A Rev. 2 (Transitioning the Use of Cryptographic Algorithms and Key Lengths)
• NIST SP 800-56A Rev. 3 / 56B Rev. 2 / 56C Rev. 2 (Key Establishment)
• NIST SP 800-90A Rev. 1 / 90B / 90C (RBG, Entropy, Construction)
• NIST SP 800-38D (GCM)
• FIPS 180-4 (Secure Hash Standard)
• FIPS 197 (AES)
• FIPS 202 (SHA-3)
• FIPS 186-5 (Digital Signature Standard)
• FIPS 198-1 (HMAC)
• CMVP Implementation Guidance (IG) for FIPS 140-3
• NIST CSRC CMVP Modules in Process List (csrc.nist.gov)
• IETF RFC 8446 (TLS 1.3) · RFC 9147 (DTLS 1.3) · RFC 7748 (Curve25519) · RFC 8032 (Ed25519)

Implementation worksheet

1. Inspect the module_validation object schema in the Phase 1 envelope definition under spec/.
2. Collect the CMVP or KCMVP certificate number and level for the cryptographic module embedded in the host.
3. Run ./cli/tls-lite.sh envelope --fips to produce a sample envelope in Approved Mode.
4. Verify on the simulator's #cipher panel that the cipher-suite pool matches FIPS mode expectations.
5. For Korean market deployments, attach the KCMVP certificate and enable ARIA cipher-suite negotiation.
6. Execute the §C.6 FIPS conformance suite under https://github.com/WIA-Official/wia-tls-lite-conformance.

Cross-standard composition recap

Like every other Phase 1-4 chapter of the TLS Lite eBook, this chapter composes with the wider WIA Standards family. Carrying FIPS 140-3 validation metadata inside the envelope dovetails directly with the WIA-AIR-SHIELD trust list so that entries can be filtered automatically by "Level 2 or higher CMVP or KCMVP certified module". Combined with WIA-OMNI-API credential storage rooted in a FIPS Level 2 HSM, a single host can run multiple WIA standards on one key chain while preserving a uniform validation grade across them.

Chapter 6 Endnotes

1. NIST, FIPS 140-3: Security Requirements for Cryptographic Modules, March 22, 2019. csrc.nist.gov/publications/detail/fips/140/3/final
2. ISO/IEC 19790:2025, Information security, cybersecurity and privacy protection — Security requirements for cryptographic modules. iso.org/standard/85940.html
3. ISO/IEC 24759:2025, Test requirements for cryptographic modules. iso.org/standard/85941.html
4. NIST CSRC, CMVP Modules In Process List. csrc.nist.gov/projects/cmvp/modules-in-process
5. NIST SP 800-131A Rev. 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths, March 2019.
6. NIST SP 800-56A Rev. 3, Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography, April 2018.
7. NIST SP 800-56C Rev. 2, Recommendation for Key-Derivation Methods in Key-Establishment Schemes, August 2020.
8. NIST SP 800-90A Rev. 1, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, June 2015.
9. NIST SP 800-90B, Recommendation for the Entropy Sources Used for Random Bit Generation, January 2018.
10. FIPS 180-4, Secure Hash Standard (SHS), August 2015.
11. FIPS 197, Advanced Encryption Standard (AES), November 2001 (Updated May 2023).
12. FIPS 202, SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions, August 2015.
13. FIPS 186-5, Digital Signature Standard (DSS), February 2023.
14. CMVP, Implementation Guidance for FIPS 140-3. csrc.nist.gov/projects/cmvp/fips-140-3-ig-announcements
15. National Intelligence Service (Korea), KCMVP — Cryptographic Module Validation Program. nis.go.kr
16. GitHub: WIA-Official/wia-standards-public/tls-lite — chapter source, errata, and reproducible assets.