Skip to content

aws_sigv4_sign: FIPS-validated SigV4 signing (investigation) #814

Closed

Description

@szedan-rh

Summary

The aws_sigv4_sign filter (added in #802) computes its SigV4
HMAC-SHA256 through the aws-sigv4 crate, which uses the pure-Rust
hmac/sha2 (RustCrypto) primitives. Those are not FIPS-validated,
so request signing is not FIPS-compliant today. This issue tracks the
investigation and decision for FIPS-validated signing.

Follow-up to #802. Flagged in review (heads-up on the "FIPS
considerations" note in filters/src/aws/sigv4.rs).

Background / analysis

  • aws-sigv4 (v1.5.1) hardwires HMAC-SHA256 to RustCrypto in
    src/sign/v4.rs (use hmac::...; use sha2::Sha256;). It exposes
    no feature flag or seam to swap the crypto backend — its features
    (sign-http, sign-eventstream, sigv4a, http1) all concern what
    is signed, not how the crypto runs, and hmac/sha2 are
    non-optional dependencies.
  • This repo's TLS layer already uses aws-lc-rs, which has a
    FIPS-140-3-validated build mode — but that does not extend to the
    signing computation, which goes through the separate, non-validated
    RustCrypto path.
  • Therefore FIPS-validated signing cannot be achieved by configuring
    aws-sigv4; it requires routing the signing crypto through a validated
    module.

Options to evaluate

  1. Build the canonical request / string-to-sign via aws-sigv4 but
    compute the HMAC-SHA256 signing-key derivation ourselves through
    aws-lc-rs (FIPS mode) — it is already a dependency.
  2. Route the signing HMAC through an OpenSSL FIPS provider (introduces a
    C/FFI dependency into an otherwise OpenSSL-free tree).
  3. Upstream a pluggable-crypto backend into aws-sigv4 (largest effort,
    not on our timeline).

Acceptance criteria (investigation)

  • Documented feasibility of computing SigV4 HMAC-SHA256 via
    aws-lc-rs FIPS vs an OpenSSL FIPS provider.
  • A recommended approach with trade-offs (dependency footprint,
    build/deploy friction, maintenance).
  • Explicit note that aws-sigv4 cannot be configured for this, so a
    custom signing path is required.

Implementation to be split out once the approach is chosen.

Activity

  1. self-assigned this
    on Aug 25, 2026
  2. added theissue type on Sep 24, 2026
  3. added this to the v0.4.0 milestone on Sep 24, 2026
  4. added
    blockerThis is blocking other work significantly
    on Sep 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

Projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions