Craton HSM

FIPS 140-3 Overview

FIPS 140-3 Overview

FIPS 140-3 is the U.S. federal standard for validating the security of cryptographic modules, published by NIST and maintained by the Cryptographic Module Validation Program (CMVP). It supersedes FIPS 140-2 and is based on ISO/IEC 19790:2012. A module is "FIPS 140-3 validated" only after a CMVP-accredited laboratory has tested it, NIST has reviewed the report, and a certificate number has been issued and listed on the public CMVP register.

This page describes where Craton HSM stands with respect to FIPS 140-3, what the term "FIPS mode" means operationally, and which algorithms the module treats as approved.

Current Status

Craton HSM is not CMVP validated. It has never been submitted to a CMVP-accredited laboratory and does not hold a certificate number. Claims on this site that describe FIPS behaviour refer to design conformance, not a validation result.

Two distinct tracks run in parallel:

TrackScopeStatus
Core (pure-Rust backend)Gap analysis, design conformance to Level 1Not CMVP validated. No submission planned for the RustCrypto build.
Enterprise (aws-lc-rs backend)Formal Level 1 submission using the validated AWS-LC cryptographic libraryPlanned. Target submission Q3 2027. See certification-plan.

The core build documents every design decision against the FIPS 140-3 checklist (self-tests, CSP management, finite state model, zeroization, approved algorithm enforcement) so that the enterprise build can re-use the envelope unchanged. The cryptographic primitives themselves are the gating factor: the default RustCrypto crates are not CAVP tested, and nothing about the envelope can change that. See gap-analysis.

What "FIPS Mode" Means

"FIPS mode" in Craton HSM is an operational configuration that combines a build-time choice and a runtime policy:

  1. The module is built with the awslc-backend feature, which links the FIPS-validated AWS-LC library via aws-lc-rs.
  2. algorithms.crypto_backend = "awslc" selects that backend at runtime.
  3. algorithms.fips_approved_only = true enables strict approved-mode enforcement. Mechanisms outside the approved list are rejected with CKR_MECHANISM_INVALID.

When FIPS mode is enabled:

  • All classical cryptographic operations (AES, RSA, ECDSA, ECDH, SHA-2, HMAC, DRBG) are routed through AWS-LC.
  • Non-approved mechanisms — Ed25519, SHA-1 for signing, ML-DSA, ML-KEM, SLH-DSA, composite/hybrid mechanisms — are rejected at init time.
  • C_GetMechanismList returns only the approved subset.
  • Each audit log entry carries an fips_approved boolean so operators can prove which operations used approved algorithms.

See fips-mode for the full operator procedure.

Approved vs Non-Approved Algorithms

The following table reflects the enforcement policy when FIPS mode is active. Algorithm approval reflects NIST's current stance; it is not a statement about CMVP certification of Craton HSM itself.

CategoryApprovedNot approved
Symmetric encryptionAES-128/192/256 in GCM, CBC, CTR(none in scope)
Key wrapAES-KW, AES-KWP (SP 800-38F)(none in scope)
RSA signingPKCS#1 v1.5 and PSS with SHA-256/384/512, keys >= 2048 bitsRSA < 2048, SHA-1 as signature hash
RSA encryptionOAEP with SHA-256/384/512, keys >= 2048 bitsPKCS#1 v1.5 encryption
Elliptic curveECDSA and ECDH on P-256 and P-384All other curves
Edwards curve—Ed25519 (not yet FIPS-approved)
DigestsSHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512SHA-1 (digest-only use remains available outside signing)
MACHMAC-SHA256, HMAC-SHA384, HMAC-SHA512HMAC-SHA1
KDFPBKDF2-HMAC-SHA256 (SP 800-132) for PIN hashing—
RNGHMAC_DRBG (SP 800-90A) seeded from the OS entropy sourceDirect use of OsRng for key material
Post-quantum—ML-DSA, ML-KEM, SLH-DSA, composite PQC mechanisms

Post-quantum mechanisms are implemented and available in non-FIPS mode. They are excluded from the FIPS mode allow-list because FIPS 203, 204 and 205 are published but have no CAVP test infrastructure yet, and the upstream crates are still pre-1.0.

Further Reading