Gap Analysis

This page summarises the current deviations between Craton HSM's default (pure-Rust) build and a FIPS 140-3 Level 1 submission. It is not a replacement for a laboratory-produced Implementation Under Test report. The intent is to be honest about what a CMVP reviewer would flag if the core build were submitted as-is, and to document what remediation would require.

The enterprise build with the awslc-backend feature resolves the primary blocker — unvalidated primitives — by routing all classical cryptography through AWS-LC. The enterprise track is covered in the certification-plan.

Status at a Glance

What Blocks CMVP Submission of the Core Build

A CMVP reviewer looking at the default build would reject the submission on the grounds that the cryptographic primitives themselves are not validated:

• AES (aes-gcm, aes, cbc, ctr, aes-kw) — RustCrypto crates, no CAVP certificate.
• RSA (rsa crate) — pure-Rust; no CAVP certificate.
• ECDSA / ECDH (p256, p384) — RustCrypto; no CAVP certificate.
• SHA-2 / SHA-3 (sha2, sha3) — RustCrypto; no CAVP certificate.
• HMAC, PBKDF2 — RustCrypto; no CAVP certificate.
• Post-quantum (ml-dsa, ml-kem, slh-dsa) — pre-1.0 crates; FIPS 203/204/205 have no CAVP infrastructure yet.

The envelope is in good shape — self-tests, POST, CSP handling, key lifecycle, audit log, and finite state model all exist — but the primitives drive the verdict. Switching the backend to AWS-LC via the awslc-backend feature is the only credible remediation; re-submitting RustCrypto crates for CAVP testing would require several orders of magnitude more engineering effort than the switch.

What Is Already in Place

The following items were implemented during the core build's internal hardening work and apply equally to both backends.

Approved DRBG

All cryptographic random bit generation is routed through an HMAC_DRBG (HMAC-SHA256) per SP 800-90A via a DrbgRng adapter that implements rand::CryptoRng. The DRBG is seeded from the operating system entropy source, runs with prediction resistance (fresh entropy on every generate call), and executes a continuous health test that compares consecutive outputs. A NIST CAVP known-answer test validates the DRBG at POST time.

Direct use of OsRng as a CSPRNG for key generation is prohibited and enforced by code review; all key generation paths (RSA, EC, Ed25519, AES) take a &mut DrbgRng or equivalent.

Self-Test Coverage

17 tests run at module load time: one HMAC-SHA256 integrity check of the module binary plus 16 known-answer tests covering every approved primitive. See self-tests for the full matrix.

Pairwise consistency tests run after every C_GenerateKeyPair for RSA, ECDSA P-256/P-384, Ed25519, ML-DSA, SLH-DSA (sign/verify) and ML-KEM (encap/decap). The continuous RNG health test runs on every C_GenerateRandom.

Software Integrity

An HMAC-SHA256 keyed with an embedded compile-time constant is computed over the module binary at C_Initialize and compared against a .hmac sidecar file next to the library. Mismatch fails POST and puts the module in error state. Without a sidecar file (development and test builds) the check is skipped with a warning; under the FIPS build feature the sidecar is mandatory.

CSP Management

All key material lives in RawKeyMaterial, a wrapper that:

• Locks its pages into physical RAM via mlock(2) (Unix) or VirtualLock (Windows) at allocation.
• Overwrites bytes with zeroize() and releases the memory lock in Drop.
• Redacts itself in Debug output with [REDACTED].

PIN hashes, DRBG internal state, storage encryption keys, and intermediate multi-part operation buffers all carry Zeroizing<Vec<u8>> or ZeroizeOnDrop. The full CSP inventory appears in security-policy.md in the core repository.

Key Lifecycle (SP 800-57)

Keys carry CKA_START_DATE / CKA_END_DATE attributes and transition automatically between pre-activation, active, deactivated, compromised, and destroyed states. Deactivated keys can verify and decrypt but cannot sign, encrypt, wrap, or derive.

Finite State Model and Audit

The module-level state machine (Power Off, POST Running, Initialized, Authenticated, Error) and the PKCS#11 session state machine are documented and enforced in src/session/session.rs. The audit log records every significant operation with a chained SHA-256 hash and an fips_approved flag per IG 2.4.C.

Remaining Items

These items do not block the enterprise submission but remain open against the long-form plan.

Recommended Remediation

For any deployment that needs a FIPS-validated cryptographic core today:

1. Build with cargo build --release --features awslc-backend.
2. Configure algorithms.crypto_backend = "awslc" and algorithms.fips_approved_only = true in craton_hsm.toml.
3. Generate the integrity sidecar with tools/compute-integrity-hmac.sh (or the PowerShell equivalent on Windows).
4. Validate that C_Initialize returns CKR_OK and that C_GetMechanismList returns only approved mechanisms.
5. Treat the result as "FIPS-aligned operational mode backed by a validated library." Do not claim CMVP validation of Craton HSM itself until the enterprise submission is issued.

See fips-mode for the full operator procedure and certification-plan for the submission roadmap.