FIPS 140-3 Security Policy

Module: Craton Shield Cryptographic Module | Version: 0.6.0 | Date: 2026-03-28 Target Level: FIPS 140-3 Level 1 (Software Module)

---

1. Module Identification

---

2. Cryptographic Boundary

The FIPS 140-3 module boundary encompasses the vs-crypto crate and its direct cryptographic dependencies. All cryptographic operations enter and exit through the CryptoProvider trait interface.

2.1 Components Within Boundary

2.2 Components Outside Boundary

All other Craton Shield crates (e.g., vs-can-monitor, vs-ota-validator, vs-key-manager) are outside the cryptographic boundary. They invoke cryptographic services solely through the CryptoProvider trait.

Full boundary diagram: docs/certification/fips-140-3-boundary.md.

---

3. Approved Algorithms

---

4. Non-Approved Algorithms

The following algorithms are feature-gated behind the pq-software feature flag and are excluded from the FIPS 140-3 module boundary:

These algorithms are accessed through the separate PostQuantumProvider trait. When the pq-software feature is disabled (default), no post-quantum code is compiled.

Operator requirement: For FIPS-validated operation, the pq-software feature must remain disabled.

---

5. Key Management

5.1 Key Storage

5.2 Key Lifecycle

5.3 Key Zeroization

• All types containing key material derive Zeroize and ZeroizeOnDrop.
• Key material is zeroed when the SoftwareCryptoProvider is dropped.
• Explicit zeroization is available through the zeroize() method.
• Stack-based storage eliminates heap residue risk.
• Zeroization is verified through dedicated tests (tests/zeroization.rs).

---

6. Self-Tests

6.1 Power-On Self-Tests (POST)

The module executes Known Answer Tests (KATs) during vs-crypto::init() before any cryptographic service is available. All POST must pass for the module to enter the Operational state.

Full KAT specification: docs/certification/fips-140-3-kat-plan.md.

6.2 Periodic Self-Tests

The periodic_self_test() function re-executes all POST KATs on demand. Integrators should invoke this function at a frequency appropriate for their deployment context (recommended: at least once per ignition cycle for automotive applications).

6.3 Self-Test Failure

If any self-test fails:

1. The module transitions to the Error state.
2. All cryptographic service functions return VsError::SelfTestFailed.
3. No cryptographic output is produced.
4. The module remains in the Error state until re-initialized.

---

7. Error Reporting

All errors are reported through the VsError return type. The module does not use exceptions, panics, or global error state.

---

8. Operator Guidance

8.1 FIPS-Validated Operation

To operate the module in FIPS-validated mode, operators must:

1. Disable the pq-software feature flag (default configuration).
2. Provide a cryptographically secure RNG function pointer at initialization.
3. Call vs-crypto::init() and verify successful return before using any cryptographic service.
4. Invoke periodic_self_test() at appropriate intervals.
5. Ensure the SoftwareCryptoProvider is properly dropped (or zeroize() called) when the module is no longer needed.

8.2 Physical Security

FIPS 140-3 Level 1 does not impose physical security requirements beyond production-grade components. For deployments requiring higher assurance, operators should consider:

• Hardware security modules (HSM) for key storage
• Secure boot enforcement at the platform level
• Physical tamper detection on the gateway ECU

8.3 Firmware Update

When updating the module:

1. Verify the update image signature using the OTA validator before applying.
2. After update, the module will re-execute POST on next initialization.
3. Confirm POST passes before resuming operations.

---

9. References