FIPS 140-3 Audit Scope

Cryptographic Module Boundary

The cryptographic module boundary encompasses all code that handles key material, performs cryptographic operations, or enforces security policy.

Inside the boundary

Outside the boundary (excluded)

Algorithm Inventory

Approved Algorithms (FIPS 140-3)

Non-approved (restricted by configuration)

Mechanism count

41 PKCS#11 mechanisms registered via C_GetMechanismList:

• 10 RSA (keygen, PKCS#1, PSS with SHA-256/384/512, OAEP)
• 7 EC (keygen, ECDSA, ECDSA-SHA*, ECDH)
• 1 EdDSA
• 7 AES (keygen, GCM, CBC, CBC-PAD, CTR, KW, KWP)
• 7 Digest (SHA-1, SHA-256/384/512, SHA3-256/384/512)
• 9 PQC (ML-KEM-512/768/1024, ML-DSA-44/65/87, SLH-DSA-128s/256s, Hybrid)

Self-Test Coverage (POST) — 17 tests (integrity + 16 KATs) ✅

The KATs run against the configured backend. run_post_algorithms takes the CryptoBackend the module will serve requests with, and the AES-GCM/CBC/CTR, SHA-2, ECDSA and RSA KATs dispatch through it. This matters whenever a backend other than the built-in RustCrypto one is selected: FIPS 140-3 requires a known-answer test for each approved algorithm the module implements, and testing a different implementation than the one in service establishes nothing about it. Until this was wired through, an AWS-LC deployment self-tested RustCrypto, so a broken or miscompiled AWS-LC would have passed POST.

HMAC, SHA3, the PQC algorithms, and the RNG/DRBG health tests are not backend-swapped, so those KATs call the shared implementations directly. The AES-GCM fixed-nonce check is likewise on the shared primitive: the backend's GCM entry point generates its own nonce by design, so there is no interface through which to pass a deterministic one. The GCM roundtrip half of that KAT does go through the backend.

RSA KAT and the RUSTSEC-2023-0071 gate. Release builds of the RustCrypto backend refuse RSA private-key operations because the rsa crate is subject to the Marvin timing attack, so RSA signature generation is not a security function those builds provide. The POST's RSA KAT therefore branches on the backend's reported capability (CryptoBackend::supports_rsa_private_ops) rather than on the build-time gate, so a backend that provides RSA — AWS-LC does — gets the full sign/verify roundtrip against its own implementation. Where private-key operations are refused it runs a verify-only known-answer test against a fixed vector, including a negative case so a verifier that accepts everything cannot pass. This keeps a KAT for every approved function the module actually provides. Before this branch existed the KAT signed unconditionally, so the POST — and therefore C_Initialize — failed on every release build.

All P0 POST KATs have been implemented. Security audit (v0.9.1) upgraded AES-CBC/CTR from circular roundtrip tests to genuine known-answer tests with hardcoded expected ciphertexts, and added RSA PKCS#1 v1.5 KAT.

Continuous RNG Health Test

Per SP 800-90B, a continuous RNG test runs on every C_GenerateRandom call. Previous 32-byte output is stored; identical consecutive outputs cause CKR_FUNCTION_FAILED.

DRBG Health Test ✅

The HMAC_DRBG includes a continuous health test that compares consecutive outputs (Phase 7). A NIST CAVP known-answer test validates DRBG correctness during POST.

Test Suite Summary

Fuzzing Infrastructure

Recommended Audit Firm Requirements

A FIPS 140-3 audit requires a CMVP-accredited laboratory. The audit covers:

1. Security Policy document (see security-policy.md)
2. Finite State Model of the module (documented in architecture.md)
3. Physical Security — N/A for software module (Level 1)
4. Operational Environment — general-purpose OS, no modification required
5. Cryptographic Key Management — key lifecycle, zeroization
6. Self-Tests — POST and conditional tests
7. Design Assurance — source code review, configuration management
8. Mitigation of Other Attacks — N/A for Level 1

Estimated Scope for Level 1 Certification