ic-fips — the FIPS 140-3 module boundary

What this is, and what it is not

This crate implements the discipline FIPS 140-3 asks for: a defined module boundary, pre-operational self-tests, per-algorithm known-answer tests (CASTs), a latching error state, an approved mode of operation that refuses unapproved algorithms, and a service indicator that reports whether each call was approved.

It is not a validated module. IronCrypto holds no CMVP certificate, and running [initialize] does not create one. Validation is a laboratory process against a specific binary on specific platforms. What this crate gives you is a codebase that is shaped for that process, and a runtime that tells the truth about its own status — see [ic_ontology::runtime::has] with "fips-validated", which returns false and will keep returning false until a certificate exists.

Claiming otherwise to an auditor, a customer, or an agent would be a misrepresentation, so every surface here is written to make the distinction impossible to miss.

Using it

use ic_fips::{initialize, Mode, ServiceIndicator};

// Runs every known-answer test. Refuses service if any of them fail.
initialize()?;
ic_fips::set_mode(Mode::Approved)?;

// Approved: AES-256-GCM is an approved security function.
assert_eq!(ic_fips::check("aes-256-gcm")?, ServiceIndicator::Approved);

// Refused: ChaCha20-Poly1305 is not approved, so approved mode blocks it
// rather than letting it through with a warning.
assert!(ic_fips::check("chacha20-poly1305").is_err());
# Ok::<(), ic_core::Error>(())