# FIPS 140-3 Provider Plan
Status date: 2026-09-03
This document describes how `tectonic-bedrock` should expose cryptographic
operations backed by a FIPS 140-3 validated module. It covers the proposed
Cargo features, provider boundary, approved-service policy, operating
environments, release evidence, and the current validation status of AWS-LC
and wolfCrypt 7.0.
FIPS validation applies to an exact cryptographic module, module version,
build configuration, operating environment, and set of approved services. A
Cargo feature or an operating system's FIPS mode is not, by itself, a FIPS
validation.
## Goals
- Provide a strict Bedrock FIPS policy selected with a Cargo feature.
- Support AWS-LC as the first production provider.
- Prepare a wolfCrypt 7.0 provider without claiming validation before its
CMVP certificate is active.
- Prevent pure-Rust or non-approved fallbacks for FIPS security services.
- Retain Bedrock's existing non-FIPS algorithms outside the strict FIPS
profile.
- Record enough build and deployment evidence to identify the selected
certificate and operating environment.
## Cargo features
The FIPS policy and the cryptographic provider should be separate concepts.
Exactly one provider must be selected for a FIPS build.
```toml
[features]
# Policy gate. This feature requires exactly one validated provider.
fips = []
# Production-capable after the AWS-LC dependency and OE are pinned.
fips-aws-lc = ["fips", "dep:aws-lc-rs"]
# Integration and testing only. This must not make a FIPS validation claim.
fips-ready-wolfcrypt7 = ["dep:wolfssl-wolfcrypt"]
# Add this only after wolfCrypt 7 has an active CMVP certificate.
# fips-wolfcrypt7 = ["fips", "dep:wolfssl-wolfcrypt"]
[dependencies]
aws-lc-rs = {
version = "=<compliance-approved-pin>",
optional = true,
default-features = false,
features = ["fips"]
}
wolfssl-wolfcrypt = {
version = "=<vendor-approved-pin>",
optional = true,
default-features = false,
features = ["aead", "digest", "mac", "rand_core", "signature"]
}
```
Compile-time guards should reject ambiguous or incomplete configurations:
```rust
#[cfg(all(feature = "fips-aws-lc", feature = "fips-wolfcrypt7"))]
compile_error!("select exactly one FIPS provider");
#[cfg(all(
feature = "fips",
not(any(feature = "fips-aws-lc", feature = "fips-wolfcrypt7"))
))]
compile_error!("the fips feature requires a FIPS provider");
```
The current `symmetric` feature combines AES, AES-GCM, ChaCha20,
ChaCha20-Poly1305, HKDF, HMAC, and SHA-2. These should be split into
algorithm-level features before implementing the FIPS policy. FIPS builds must
also use `default-features = false`, because Bedrock's current defaults enable
algorithms that are outside the selected validated modules.
Example AWS-LC consumer configuration:
```toml
tectonic-bedrock = {
version = "...",
default-features = false,
features = ["fips-aws-lc"]
}
```
Before wolfCrypt 7 receives a CMVP certificate, it may only be used for
integration work:
```toml
tectonic-bedrock = {
version = "...",
default-features = false,
features = ["fips-ready-wolfcrypt7"]
}
```
## Provider boundary
Bedrock should keep a private provider interface and expose only safe,
provider-neutral public operations.
```rust
pub(crate) trait FipsProvider {
fn initialize() -> Result<FipsStatus, FipsError>;
fn random_fill(output: &mut [u8]) -> Result<(), FipsError>;
// SHA, HMAC, AES-GCM, ECDSA, RSA, ECDH, and provider-specific extensions.
}
pub struct FipsStatus {
pub provider: FipsProviderName,
pub module_version: &'static str,
pub certificate: &'static str,
pub approved_mode: bool,
pub operational_environment: &'static str,
}
```
Initialization must fail closed:
- AWS-LC must pass `aws_lc_rs::try_fips_mode()`. The application should also
record the AWS-LC and FIPS module versions when those APIs are available.
- wolfCrypt must initialize successfully, pass the required POST and CASTs,
pass its integrity test, and report an approved status through the
validated module APIs.
- Bedrock must not infer a validated operating environment solely from
`target_os`, `target_arch`, container metadata, or an OS FIPS-mode flag.
## Service policy
The common provider-neutral subset should initially contain SHA-2, HMAC,
approved random generation, AES-GCM, ECDSA P-256/P-384, RSA signatures with
keys of at least 2048 bits, and P-256/P-384 ECDH. Each operation must also obey
the selected module's approved parameter and IV-generation rules.
| Approved RNG | Yes | Awaiting CMVP validation |
| SHA-256/SHA-384 | Yes | Awaiting CMVP validation |
| HMAC-SHA-256/384 | Yes | Awaiting CMVP validation |
| AES-128/256-GCM | Yes, with approved IV handling | Awaiting CMVP validation |
| ECDSA P-256/P-384 | Yes | Awaiting CMVP validation |
| RSA-PSS/PKCS#1 with RSA >= 2048 | Yes | Awaiting CMVP validation |
| ECDH P-256/P-384 | Yes | Awaiting CMVP validation |
| Generic HKDF | Yes | Awaiting final security policy |
| Ed25519 | Yes | Awaiting final security policy |
| ML-KEM-768/1024 | Yes | CAVP tested; awaiting CMVP validation |
| ML-DSA/SLH-DSA | Not in AWS-LC 3 certificate | CAVP tested; awaiting CMVP validation |
| X25519 and ChaCha20 | Not exposed by the strict profile | Awaiting final security policy |
| Other Bedrock PQ algorithms and HHD | Not exposed by the strict profile | Not exposed by the strict profile |
The AES-GCM API needs particular care. Bedrock currently accepts a
caller-provided nonce, while a validation claim requires following the
selected module's approved IV-generation scenarios. The FIPS API should use
module-generated nonces or a protocol-specific construction whose IV rules
are covered by the security policy.
## AWS-LC validation and version selection
`aws-lc-rs` is not itself a validated module. Its `fips` feature selects an
AWS-LC FIPS module through `aws-lc-fips-sys`. The selected crate version must
be mapped to the exact AWS-LC module, certificate, and security policy.
For Bedrock, the preferred active module is AWS-LC FIPS 3.1.0 static,
certificate 5314. The dependency must not float to the newest major-minor
release: `aws-lc-rs` 1.18 and newer select AWS-LC FIPS 4.x, which is still in
the CMVP review process as of the status date of this document.
The final application owns the exact `Cargo.lock`, native module selection,
SBOM, and build evidence. A compliance owner must approve the exact
`aws-lc-rs` and `aws-lc-fips-sys` pins before release.
### AWS-LC FIPS 3.1.0 static, certificate 5314
Each `Both` entry represents two tested operating environments: processor
acceleration enabled and disabled.
| Amazon Linux 2023 | Amazon EC2 `r8g.metal-24xl` | Graviton4 ARMv9 | Both |
| Amazon Linux 2023 | Amazon EC2 `c6i.metal` | Intel Xeon Platinum 8375C | Both |
This is the complete tested OE list for certificate 5314. No vendor-affirmed
operating environments are claimed.
Sources:
- [NIST certificate 5314](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/5314)
- [Certificate 5314 security policy](https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp5314.pdf)
### AWS-LC FIPS 2.0.0 static, certificate 4816
These environments are retained as reference. Bedrock should not offer this
older module unless a customer explicitly requires it.
| Amazon Linux 2 | EC2 `c5.metal`, 192 GiB memory, 200 GiB EBS | Intel Xeon Platinum 8275CL | Enabled |
| Amazon Linux 2023 | EC2 `c5.metal`, 192 GiB memory, 200 GiB EBS | Intel Xeon Platinum 8275CL | Enabled |
| Ubuntu 22.04 | EC2 `c5.metal`, 192 GiB memory, 200 GiB EBS | Intel Xeon Platinum 8275CL | Enabled |
| Amazon Linux 2 | EC2 `c7g.metal`, 128 GiB memory, 200 GiB EBS | Graviton3 | Enabled |
| Amazon Linux 2023 | EC2 `c7g.metal`, 128 GiB memory, 200 GiB EBS | Graviton3 | Enabled |
| Ubuntu 22.04 | EC2 `c7g.metal`, 128 GiB memory, 200 GiB EBS | Graviton3 | Enabled |
No vendor-affirmed operating environments are claimed.
Sources:
- [NIST certificate 4816](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4816)
- [Certificate 4816 security policy](https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp4816.pdf)
### AWS-LC FIPS 1.0.2 and 1.1.0, certificate 4631
Each row was tested both with and without the indicated processor algorithm
acceleration.
| 1.0.2 | Ubuntu 20.04 | EC2 `c5.metal` | Intel Xeon Platinum 8275CL |
| 1.0.2 | Amazon Linux 2 | EC2 `c5.metal` | Intel Xeon Platinum 8275CL |
| 1.0.2 | Ubuntu 20.04 | EC2 `c6g.metal` | Graviton2 |
| 1.0.2 | Amazon Linux 2 | EC2 `c6g.metal` | Graviton2 |
| 1.0.2 | Amazon Linux 2 | EC2 `c7g.metal` | Graviton3 |
| 1.0.2 | Ubuntu 22.04 | EC2 `c7g.metal` | Graviton3 |
| 1.0.2 | Windows 10 | Dell Latitude 5430 | Intel Core i7-1255U |
| 1.0.2 | Android 12 | Samsung Galaxy S20 | Qualcomm Snapdragon 865 |
| 1.1.0 | iOS 15.5 | Apple iPhone 12 | Apple A14 Bionic |
| 1.1.0 | macOS 12.4 | MacBook Air | Apple M1 |
Certificate 4631 also lists these vendor-affirmed environments. Vendor
affirmation is distinct from a CMVP-tested OE, and the security policy states
that CMVP makes no statement about correct operation when ported outside the
tested environments.
| RHEL 5 | Amazon `m4.4xlarge`, Intel Xeon E5-2686 |
| Amazon Linux 2012 | Amazon `m4.4xlarge`, Intel Xeon E5-2686 |
Sources:
- [NIST certificate 4631](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4631)
- [Certificate 4631 security policy](https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp4631.pdf)
### AWS-LC build support is not an OE validation
The `aws-lc-rs` project can build FIPS configurations for more Rust targets
than are present in the certificate tables, including several Linux,
Windows, macOS, and FreeBSD targets. This is portability and CI support, not a
FIPS validation for those operating environments.
Sources:
- [aws-lc-rs platform support](https://aws.github.io/aws-lc-rs/platform_support.html)
- [AWS-LC FIPS validation inventory](https://github.com/aws/aws-lc/blob/main/crypto/fipsmodule/FIPS.md)
## wolfCrypt 7.0 status
wolfCrypt 7.0 currently has no FIPS 140-3 CMVP module certificate and,
therefore, has no certified operating environments.
| wolfCrypt 7.0 | None | 0 |
wolfCrypt 7.0 has CAVP certificate A8437 for algorithm testing, including
ML-KEM, ML-DSA, SLH-DSA, LMS, SHA/SHAKE, HMAC, and SHA-512 Hash DRBG. A CAVP
algorithm certificate is not a FIPS 140-3 module validation. wolfSSL currently
describes the v7 module as pending submission and says its target operating
environments are still being defined.
Operating environments from wolfCrypt 5.2.1 certificates 4718 and 5041 do not
transfer to wolfCrypt 7.0.
Sources:
- [wolfCrypt FIPS status and v7 roadmap](https://www.wolfssl.com/license/fips/)
- [wolfCrypt 7.0 CAVP announcement](https://www.wolfssl.com/wolfcrypt-is-quantum-safe-and-has-a-fips-140-3-cavp-cert/)
- [NIST active wolfCrypt certificate search](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search?CertificateStatus=Active&ModuleName=wolfcrypt&SearchMode=Basic&ValidationYear=0)
The wolfCrypt integration may proceed using the official Rust wrapper and a
wolfSSL-provided FIPS Ready or commercial bundle, but it must remain labeled
FIPS Ready until all of the following exist:
1. An active wolfCrypt 7 CMVP certificate number.
2. A final non-proprietary security policy.
3. The exact validated source bundle and build instructions.
4. The final list of approved services, algorithms, and parameters.
5. A published table of tested operating environments.
6. A Bedrock deployment matching one of those environments.
The public FIPS Ready source does not carry a module validation. Production
use will also require resolving wolfSSL's GPLv3 or commercial licensing terms.
## Operating-environment registry
The certified OE tables should also be represented in machine-readable data,
for example `fips-operating-environments.toml`:
```toml
[[environment]]
provider = "aws-lc"
module = "3.1.0"
certificate = "5314"
os = "Amazon Linux 2023"
platform = "c6i.metal"
processor = "Intel Xeon Platinum 8375C"
acceleration = ["enabled", "disabled"]
status = "tested"
[[environment]]
provider = "wolfcrypt"
module = "7.0.0"
certificate = ""
status = "not-yet-validated"
```
Release tooling should require an exact registry match for the selected
provider, native module, certificate, operating system, hardware platform,
processor, and acceleration mode. The registry should be updated only from a
published CMVP certificate and security policy.
## CI and release evidence
The FIPS release pipeline should:
1. Build with `default-features = false` and exactly one FIPS provider.
2. Pin the Rust toolchain, C/C++ toolchain, CMake, Go, bindgen, native module,
and Cargo dependency graph.
3. Run the release build on an exact tested OE. For AWS-LC 3.1.0 this means
`c6i.metal` or `r8g.metal-24xl` running Amazon Linux 2023.
4. Verify provider initialization, module integrity, self-tests, approved
mode, and applicable service indicators.
5. Run known-answer, negative, and provider-interoperability tests for every
exposed operation.
6. Reject unsupported feature combinations and non-approved algorithms at
compile time.
7. Archive the final binary hash, `Cargo.lock`, dependency tree, SBOM,
compiler versions, native source hashes, module version, certificate,
security policy, OE identity, and test results.
8. Treat provider, module, compiler, build-flag, and OE changes as
compliance-reviewed release changes.
## Delivery phases
1. Split Bedrock's algorithm features from its current RustCrypto backend
dependencies.
2. Add the `fips` policy and `fips-aws-lc` provider with compile-time guards.
3. Migrate the common approved services to the AWS-LC implementation while
maintaining supported key and wire formats.
4. Add startup validation, version reporting, service restrictions, and the
OE registry.
5. Establish AWS-LC compliance CI on both certificate 5314 environments.
6. Add `fips-ready-wolfcrypt7` and complete provider conformance testing.
7. When wolfCrypt 7 receives an active certificate, import its complete OE
and service tables, pin the validated commercial bundle, and enable
`fips-wolfcrypt7`.
## Claim language
The product should state that it uses a named FIPS 140-3 validated
cryptographic module for specifically listed approved services when built and
operated under the documented configuration. It should not claim that the
entire Bedrock crate, every Bedrock algorithm, an arbitrary FIPS-feature
build, or a FIPS Ready wolfCrypt 7 build is itself FIPS validated.