Craton HSM

Certification Plan

This page describes the roadmap for the FIPS 140-3 Level 1 certification of the Craton HSM enterprise build. The core (pure-Rust) build is not part of this plan — its cryptographic primitives are not CAVP tested and are unsuitable for CMVP submission. The enterprise build re-uses the same module envelope (roles, finite state model, self-test harness, CSP management, audit log, zeroization) but links AWS-LC via aws-lc-rs, which already holds FIPS validation.

Nothing on this page should be read as a current claim of certification. The module has no CMVP certificate number. All dates below are internal targets and will slip if scope, budget, or laboratory queue changes.

Module Under Test

Field	Value
Module name	Craton HSM Enterprise Cryptographic Module
Module type	Software
Target security level	1
Cryptographic library	AWS-LC via `aws-lc-rs` (pinned to the validated version at submission time)
Operating environments	Linux x86_64, Linux aarch64, Windows x86_64 (final list set with the laboratory)

Module Boundary

The cryptographic boundary is the process address space of the application loading libcraton_hsm.*. Inside the boundary:

The PKCS#11 C ABI layer and its input validation.
The HsmCore coordinator, session manager, object store, token/PIN subsystem.
The CryptoBackend trait and its AWS-LC implementation.
Self-test harness (POST + conditional) and the software integrity check.
Audit log and chained hashing.
Key material containers (RawKeyMaterial with mlock/VirtualLock and zeroize-on-drop).

Outside the boundary: the gRPC daemon, admin CLI, cluster/Raft, KMIP adapter, cloud and HSM passthrough backends, authentication providers (LDAP/OIDC/certificate), and build tooling. These components call into the module through its public API and are evaluated separately for each compliance regime.

Prehashed signing mechanisms (for example CKM_SHA256_RSA_PKCS) currently pass through the module's own prehash handling before reaching the backend. To keep the FIPS boundary clean these mechanisms are rejected in FIPS mode; callers sign against the raw digest mechanism and pre-compute the digest themselves, or use the non-prehashed mechanism variant.

Target Platforms

The final list of tested operational environments will be agreed with the laboratory. The current engineering baseline is:

Linux x86_64 with glibc 2.31 or newer (Ubuntu 22.04 LTS, RHEL 9).
Linux aarch64 (Ubuntu 22.04 LTS on Graviton / Ampere).
Windows Server 2022 x86_64.

Each platform must be listed individually on the certificate and retested on any significant change. Additional platforms can be added post-validation via the CMVP Revalidation process.

Deliverables

FIPS 140-3 submission requires a defined document set. The status reflects the state of the enterprise build as of this writing:

Deliverable	Description	Status
Security Policy	ISO 19790 §7 compliant document covering all 11 areas	Draft held in `craton-hsm-core/docs/security-policy.md`; will be rewritten against the enterprise boundary before submission
Finite State Model	State diagram, transitions, triggers	Drafted, see self-tests
Algorithm testing (CAVP/ACVP)	ACVP request/response vectors for every approved algorithm	Test runner work in progress
Power-On Self-Tests	KATs for AES, RSA, ECDSA, SHA-2, HMAC, HKDF, DRBG + software integrity test	Implemented, covered under self-tests
Pairwise consistency tests	Sign/verify or encap/decap after every key pair generation	Implemented
Software integrity	HMAC-SHA256 over the module binary with per-build `.hmac` sidecar	Implemented
Reproducible build	Deterministic build from pinned toolchain and dependencies	Infrastructure in place, needs documented procedure for the laboratory
Source code review	Laboratory reads the full source under NDA	Pending laboratory engagement

Laboratory Strategy

The certification path engages a single NVLAP-accredited CMVP laboratory rather than multiple labs in parallel. Selection criteria:

Active NVLAP accreditation for FIPS 140-3 (not 140-2 only).
Prior validations of software-only modules at Level 1.
Experience with Rust FFI boundaries and C libraries built under CMake.
Capacity to begin within three months of contract signature.
US-based for CMVP queue interaction.

Candidate laboratories under evaluation include Leidos, UL, Gossamer Security Solutions, Lightship Security, and atsec information security. Final selection depends on quote, timeline, and Rust familiarity.

Timeline

Phase	Duration	Activities
Pre-engagement	2–3 months	Complete ACVP runner, finalise POST, freeze Security Policy draft, select laboratory
Laboratory engagement	3–6 months	Submit Implementation Under Test, CAVP/ACVP testing, source review, address findings
CMVP validation	3–12 months	Laboratory submits the report to CMVP; CMVP review; certificate issuance
Maintenance	Ongoing	Track algorithm deprecations, pin validated `aws-lc-rs` releases, plan re-validations

The CMVP queue is the dominant timing risk. A twelve-month wait after laboratory sign-off is not unusual. Target certificate issuance is Q3 2027; slippage to Q1 2028 should be assumed in customer planning.

Reproducible Build Requirement

Independent build reproduction is not strictly required by FIPS 140-3 Level 1, but it is required by our own supply-chain policy and by several customers in regulated industries. The FIPS build must be:

Produced from a tagged commit with a Cargo.lock committed to the repository.
Pinned to an exact Rust toolchain version (declared in rust-toolchain.toml).
Pinned to a validated aws-lc-rs release whose underlying AWS-LC version matches the certificate we intend to reference.
Built in an isolated environment (container or VM) with no network access after dependency fetch.
Accompanied by the matching .hmac sidecar produced by tools/compute-integrity-hmac.sh / .ps1 against the resulting binary.

The SUPPLY_CHAIN.md document in craton-hsm-enterprise tracks the exact procedure. Any deviation from the published build recipe invalidates the integrity HMAC and fails POST.

Budget

Item	Low	High
Laboratory fees	$50,000	$100,000
CMVP submission	$0	$0
Internal preparation engineering	$30,000	$50,000
Re-testing contingency	$0	$50,000
Total	$80,000	$200,000

Risks

Risk	Impact	Mitigation
CMVP queue delay	6–12 month schedule slip	Communicate longer timeline to customers; do not tie product commitments to the certificate
AWS-LC validation lapses or is superseded	Forced re-pin and potential re-test	Track AWS-LC certificate status; maintain a migration window
Algorithm deprecation during the process	Re-testing, possible Security Policy rewrite	Monitor NIST SP 800-131A transitions quarterly
Post-submission code changes	Could trigger re-validation	Feature freeze on the FIPS boundary once the IUT is submitted
Budget overrun	Delay or scope cut	Build 25% contingency into the approved budget