AWS-LC Cryptographic Module (dynamic)

Certificate

Derived Review-Risk Graph (review prompts, not findings)

flowchart LR
  %% Deterministic review-risk graph for AWS-LC Cryptographic Module (dynamic)
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>update<br/>Recovery<br/>upgrade</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>UnAuth<br/>Status Output</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>HTTPS</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
    R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
    R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
    R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E2["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C5 --> I5 --> R5 --> E5
  C6 --> I6 --> R6 --> E6
  classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
  classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
  classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
  class C2,C3,C5,C6 clue;
  class I2,I3,I5,I6 infer;
  class R2,R3,R5,R6 risk;
  class E2,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for AWS-LC Cryptographic Module (dynamic)
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>update<br/>Recovery<br/>upgrade</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>UnAuth<br/>Status Output</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<br/>HTTPS</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<br/>application</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C2,C3,C5,C6 clueLow;

Security Policy, page by page

Amazon Web Services, Inc AWS-LC Cryptographic Module (dynamic) Document version: 1.2 Last update: 2026-01-20 © 2026 Amazon Web Services, Inc., atsec information security.

Prepared by: atsec information security corporation

4516 Seton Center Pkwy, Suite 250

Austin, TX 78759 www.atsec.com © 2026 Amazon Web Services, Inc., atsec information security.

2 of 48

© 2026 Amazon Web Services, Inc., atsec information security.

4 of 48

This document is the non-proprietary FIPS 140-3 Security Policy for version AWS-LC FIPS 1.29.1 of the AWSLC Cryptographic Module (dynamic). It contains the security rules under which the module must operate and describes how this module meets the requirements as specified in FIPS PUB 140-3 (Federal Information Processing Standards Publication 140-3) for an overall Security Level 1 module.

This Security Policy describes the features and design of the module named AWS-LC Cryptographic Module (dynamic) using the terminology contained in the FIPS 140-3 specification. The FIPS 140-3 Security Requirements for Cryptographic Module specifies the security requirements that will be satisfied by a cryptographic module utilized within a security system protecting sensitive but unclassified information. The NIST/CCCS Cryptographic Module Validation Program (CMVP) validates cryptographic module to FIPS 140-3. Validated products are accepted by the Federal agencies of both the USA and Canada for the protection of sensitive or designated information. including this notice. Other documentation is proprietary to their authors. In preparing the Security Policy document, the laboratory formatted the vendor-supplied documentation for consolidation without altering the technical statements therein contained. The further refining of the Security Policy document was conducted iteratively throughout the conformance testing, wherein the Security Policy was submitted to the vendor, who would then edit, modify, and add technical contents. The vendor would also supply additional documentation, which the laboratory formatted into the existing Security Policy, and resubmitted to the vendor for their final editing. © 2026 Amazon Web Services, Inc., atsec information security.

7 of 48

Purpose and Use: The AWS-LC Cryptographic Module (dynamic) (hereafter referred to as “the module”) provides cryptographic services to applications running in the user space of the underlying operating system through a C language Application Program Interface (API). Module Type: Software Module Embodiment: MultiChipStand Cryptographic Boundary: The block diagram in Figure 1 shows the cryptographic boundary of the module, its interfaces with the operational environment and the flow of information between the module and operator (depicted through the arrows). The cryptographic boundary is defined as the AWS-LC Cryptographic Module (dynamic) which is a cryptographic library consisting of the bcm.o file (version AWS-LC FIPS 1.29.1). This file is dynamically linked to the userspace application during the compilation process. Tested Operational Environment’s Physical Perimeter (TOEPP): The PAA provided by the processor is located within the module’s physical perimeter and outside of the module’s cryptographic boundary. Figure 1: Block Diagram

Tested Module Identification – Software, Firmware, Hybrid (Executable Code Sets): © 2026 Amazon Web Services, Inc., atsec information security.

8 of 48

Table 2: Tested Module Identification – Software, Firmware, Hybrid (Executable Code Sets) Tested Operational Environments - Software, Firmware, Hybrid: Table 3: Tested Operational Environments - Software, Firmware, Hybrid

Modes List and Description: Table 4: Modes List and Description Mode Change Instructions and Status: When the module starts up successfully, after passing a set of cryptographic algorithms self-tests (CASTs) and the pre-operational self-test, the module is operating in the approved mode of operation by default and can only be transitioned into the non-approved mode by calling one of the non-approved services listed in the NonApproved Services table. The module will transition back to approved mode when approved service is called. Section 4 provides details on the service indicator implemented by the module. The service indicator identifies © 2026 Amazon Web Services, Inc., atsec information security.

9 of 48

Approved Algorithms: © 2026 Amazon Web Services, Inc., atsec information security.

10 of 48

© 2026 Amazon Web Services, Inc., atsec information security.

11 of 48

Vendor-Affirmed Algorithms: Table 6: Vendor-Affirmed Algorithms N/A for this module. © 2026 Amazon Web Services, Inc., atsec information security.

12 of 48

Name Shared Secret Computation with EC Diffie-Hellman Authenticated Encryption/Decryption with AES KW, AES- KWP Encryption/Decryption with AES

Type KAS-SSC BC-Auth BC-UnAuth

Description SP800-56Arev3. KAS- ECC-SSC per IG D.F Scenario 2 path (1). SP800-38F. Authenticated encryption, Authenticated decryption SP800-38A and SP 800- 38E. Encryption and Decryption

Properties

Algorithms KAS-ECC-SSC Sp800- 56Ar3: (A5425, A5426, A5433, A5434) AES-KW: (A5422, A5427, A5429, A5431) AES-KWP: (A5422, A5427, A5429, A5431) AES-CBC: (A5422, A5427, A5429, A5431) AES-CTR: (A5422, A5427, A5429, A5431) AES-ECB: (A5422, A5423, A5427, A5428, A5429, A5430, A5431,

© 2026 Amazon Web Services, Inc., atsec information security.

13 of 48

Name Signature Generation with RSA Signature Generation with ECDSA Key Generation with RSA Key Generation with ECDSA Signature Verification with ECDSA Signature Verification with RSA Key Verification with ECDSA Key Derivation with TLS KDF Key Derivation with SSH KDF Key Derivation with KDA HKDF Key Derivation with PBKDF Message Digest with SHA

Type DigSig-SigGen DigSig-SigGen AsymKeyPair-KeyGen CKG AsymKeyPair-KeyGen CKG DigSig-SigVer DigSig-SigVer AsymKeyPair-KeyVer KAS-135KDF KAS-135KDF KAS-56CKDF PBKDF SHA

Description FIPS186-5. Digital signature generation FIPS186-5. Digital signature generation FIPS186-5. Key generation FIPS186-5. Key generation FIPS186-5. Digital signature verification FIPS186-5. Digital signature verification FIPS186-5. Key verification SP800-135rev1. Key derivation SP800-135rev1. Key derivation SP800-56Crev1. Key derivation SP800-132. Key derivation FIPS180-4 and FIPS202. Message digest using SHA

Properties

Algorithms A5432, A5435) AES-XTS Testing Revision 2.0: (A5422, A5427, A5429, A5431) RSA SigGen (FIPS186- 5): (A5425, A5426, A5433, A5434) ECDSA SigGen (FIPS186-5): (A5425, A5426, A5433, A5434) RSA KeyGen (FIPS186- 5): (A5425, A5426, A5433, A5434) ECDSA KeyGen (FIPS186-5): (A5425, A5426, A5433, A5434) ECDSA SigVer (FIPS186-5): (A5425, A5426, A5433, A5434) RSA SigVer (FIPS186- 5): (A5425, A5426, A5433, A5434) ECDSA KeyVer (FIPS186-5): (A5425, A5426, A5433, A5434) KDF TLS: (A5425, A5426, A5433, A5434) KDF SSH: (A5425, A5426, A5433, A5434) KDA HKDF Sp800- 56Cr1: (A5425, A5426, A5433, A5434) PBKDF: (A5425, A5426, A5433, A5434) SHA-1: (A5425, A5426, A5433, A5434) SHA2-224: (A5425, A5433, A5434) SHA2-256: (A5425, A5433, A5434) SHA2-384: (A5425, A5433, A5434) SHA2-512: (A5425, A5433, A5434) SHA2-512/224: (A5425, A5433, A5434) SHA2-512/256: (A5425, A5433, A5434)

© 2026 Amazon Web Services, Inc., atsec information security.

14 of 48

Table 9: Security Function Implementations © 2026 Amazon Web Services, Inc., atsec information security.

15 of 48

The module offers three AES GCM implementations. The GCM IV generation for these implementations complies respectively with IG C.H under Scenario 1, Scenario 2, and Scenario 5. The GCM shall only be used in the context of the AES-GCM encryption executing under each scenario, and using the referenced APIs explained next. Scenario 1, TLS 1.2 For TLS 1.2, the module offers the GCM implementation via the functions EVP_aead_aes_128_gcm_tls12() and EVP_aead_aes_256_gcm_tls12(), and uses the context of Scenario 1 of IG C.H. The module is compliant with SP800-52rev2 and the mechanism for IV generation is compliant with RFC5288. The module supports acceptable AES-GCM ciphersuites from Section 3.3.1 of SP800-52rev2. The module explicitly ensures that the counter (the nonce_explicit part of the IV) does not exhaust the maximum number of possible values of 2^{64-1} for a given session key. If this exhaustion condition is observed, the module returns an error indication to the calling application, which will then need to either abort the connection, or trigger a handshake to establish a new encryption key. In the event the module’s power is lost and restored, the consuming application must ensure that a new key for use with the AES-GCM key encryption or decryption under this scenario shall be established. Scenario 2, Random IV In this implementation, the module offers the interfaces EVP_aead_aes_128_gcm_randnonce() and EVP_aead_aes_256_gcm_randnonce() for compliance with Scenario 2 of IG C.H and SP800-38D Section 8.2.2. The module generates the IV and then performs AES GCM encryption without outputting the IV to the calling application. The 96-bit AES-GCM IV, is generated randomly internal to the module using module’s approved DRBG. Scenario 5, TLS 1.3 For TLS 1.3, the module offers the AES-GCM implementation via the functions EVP_aead_aes_128_gcm_tls13() and EVP_aead_aes_256_gcm_tls13(), and uses the context of Scenario 5 of IG C.H. The protocol that provides this compliance is TLS 1.3, defined in RFC8446 of August 2018, using the ciphersuites that explicitly select AES-GCM as the encryption/decryption cipher (Appendix B.4 of RFC8446). The module supports acceptable AES-GCM ciphersuites from Section 3.3.1 of SP800-52rev2. The module implements, within its boundary, an IV generation unit for TLS 1.3 that keeps control of the 64-bit counter value within the AES-GCM IV. If the exhaustion condition is observed, the module will return an error indication to the calling application, who will then need to either trigger a re-key of the session (i.e., a new key for AES-GCM), or terminate the connection. In the event the module’s power is lost and restored, the consuming application must ensure that new AESGCM keys encryption or decryption under this scenario are established. TLS 1.3 provides session resumption, but the resumption procedure derives new AES-GCM encryption keys.

The length of a single data unit encrypted or decrypted with AES XTS shall not exceed 220 AES blocks, that is 16MB, of data per XTS instance. An XTS instance is defined in Section 4 of SP 800-38E. The XTS mode shall only be used for the cryptographic protection of data on storage devices. It shall not be used for other purposes, © 2026 Amazon Web Services, Inc., atsec information security.

16 of 48

such as the encryption of data in transit. To meet the requirement stated in IG C.I, the module implements a check to ensure that the two AES keys used in AES XTS mode are not identical.

The module provides password-based key derivation (PBKDF2), compliant with SP 800-132. The module supports option 1a from Section 5.4 of SP 800-132, in which the Master Key (MK) or a segment of it is used directly as the Data Protection Key (DPK). In accordance with SP 800-132 and FIPS 140-3 IG D.N, the following requirements shall be met:

• Derived keys shall only be used in storage applications. The MK shall not be used for other purposes. The module accepts a minimum length of 112 bits for the MK or DPK.
• Passwords or passphrases, used as an input for the PBKDF2, shall not be used as cryptographic Keys.
• The minimum length of the password or passphrase accepted by the module is 14 characters. This results in the estimated probability of guessing the password to be at most 10-14. Combined with the minimum iteration count as described below, this provides an acceptable trade-off between user experience and security against brute-force attacks.
• A portion of the salt, with a length of at least 128 bits (this is verified by the module to determine the service is approved), shall be generated randomly using the SP 800-90Ar1 DRBG provided by the module.
• The iteration count shall be selected as large as possible, if the time required to generate the key using the entered password is acceptable for the users. The module restricts the minimum iteration count to be 1000.

The module offers ECDH shared secret computation services compliant to the SP 800-56ARev3 and meeting IG D.F scenario 2 path (1). To meet the required assurances listed in section 5.6 of SP 800-56ARev3, the module shall be used together with an application that implements the “TLS protocol” or “SSH protocol” and the following steps shall be performed. • The entity using the module, must use the module's "Key Pair Generation" service for generating ECDH ephemeral keys. This meets the assurances required by key pair owner defined in the section

• As part of the module's shared secret computation (SSC) service, the module internally performs the public key validation on the peer's public key passed in as input to the SSC function. This meets the public key validity assurance required by the sections 5.6.2.2.1/5.6.2.2.2 of SP 800-56Arev3.
• The module does not support static keys therefore the "assurance of peer's possession of private key" is not applicable.

RSA SigGen (FIPS 186-5) has been CAVP tested with all the supported RSA modulus lengths (i.e., 2048, 3072, 4096). This is documented in the Approved Algorithms table of the Security Policy. All modulus sizes for SigVer have also been CAVP tested. There is no RSA signature with keys for which CAVP testing is not available. The minimum number of the Miller-Rabin tests used in primality testing complies with Table B.1 in FIPS 186-5. The RSA SigVer (FIPS 186-4) and (FIPS 186-5) have been CAVP tested with the modulus sizes of © 2026 Amazon Web Services, Inc., atsec information security.

17 of 48

1024 (FIPS 186-4) and 2048, 3072, 4096 (FIPS 186-5). All modulus sizes in which testing is available have been

tested by the CAVP.

The cryptographic module implements the following cryptographic algorithms for legacy use. Algorithms designated as “Legacy” can only be used on data that was generated prior to the Legacy Date specified in FIPS 140-3 IG C.M:

• RSA SigVer (FIPS 186-4) with 1024-bit keys.
• RSA SigVer (FIPS 186-4) with SHA-1.
• ECDSA SigVer (FIPS 186-4) with SHA-1. SHA-1 is only approved when used for message digest and for signature verification as a legacy option. The use of SHA-1 for digital signature generation is non-approved. Starting January 1 of 2031 SHA-1 will be nonapproved for all purposes.

The module does not establish SSPs using an approved key transport scheme (KTS). However, it does offer approved authenticated algorithms that can be used by an external operator/application as part of an approved KTS.

The module does not establish SSPs using an approved key agreement scheme (KAS). However, it does offer some or all of the underlying KAS cryptographic functionality to be used by an external operator/application as part of an approved KAS.

The module provides an SP800-90Arev1-compliant Deterministic Random Bit Generator (DRBG) using CTR_DRBG mechanism with AES-256, with a derivation function, for generation of key components of asymmetric keys, and random number generation. The DRBG is seeded with 256-bit of entropy input provided from an external entity to the module. This corresponds to scenario 2 (b) of IG 9.3.A i.e., the DRBG that receives a LOAD command from external entropy source outside of module's cryptographic boundary. The calling application shall use an entropy source that meets the security strength required for the CTR_DRBG as shown in NIST SP 800-90Arev1, Table 3 and should return an error if minimum strength cannot be met. Per the IG 9.3.A requirement, the module includes the caveat "No assurance of the minimum strength of generated keys (e.g., keys)".

The key generation methods implemented by the module are specified in the Vendor-Affirmed Algorithms table. The key derivation methods implemented by the module are specified in the Security Function Implementations table. © 2026 Amazon Web Services, Inc., atsec information security.

18 of 48

The key establishment methods implemented by the module are specified in the Security Function Implementations table.

The module implements the SSH key derivation function for use in the SSH protocol (RFC 4253 and RFC 6668). GCM with internal IV generation in the approved mode is compliant with versions 1.2 and 1.3 of the TLS protocol (RFC 5288 and 8446) and shall only be used in conjunction with the TLS protocol. Additionally, the module implements the TLS 1.2 and TLS 1.3 key derivation functions for use in the TLS protocol. No parts of the SSH, TLS, other than those mentioned above, have been tested by the CAVP and CMVP. © 2026 Amazon Web Services, Inc., atsec information security.

19 of 48

Table 10: Ports and Interfaces The module does not implement the Control Output interface. © 2026 Amazon Web Services, Inc., atsec information security.

20 of 48

Table 11: Roles The module does not support concurrent operators.

W,E W,E © 2026 Amazon Web Services, Inc., atsec information security.

21 of 48

G,W,E G,W,E G,E,Z © 2026 Amazon Web Services, Inc., atsec information security.

22 of 48

m G,E,Z C): G,R W,E © 2026 Amazon Web Services, Inc., atsec information security.

23 of 48

W,E,Z Z Z C): Z © 2026 Amazon Web Services, Inc., atsec information security.

24 of 48

Z © 2026 Amazon Web Services, Inc., atsec information security.

25 of 48

Name

Description

Indicator

Inputs

Outputs

Security Functions RSA Key Verification with ECDSA Key Derivation with TLS KDF Key Derivation with SSH KDF Key Derivation with KDA HKDF Key Derivation with PBKDF Message Digest with SHA Random Number Generation with DRBG Message Authentication Generation with HMAC Message Authentication Generation with AES Authenticated Encryption/Decryp tion with AES CCM Authenticated Encryption/Decryp tion with AES GCM Message Digest with SHAKE

SSP Access

Table 12: Approved Services For the above table, the convention below applies when specifying the access permissions (types) that the service has for each SSP.

• G = Generate: The module generates or derives the SSP.
• R = Read: The SSP is read from the module (e.g., the SSP is output).
• W = Write: The SSP is updated, imported, or written to the module.
• E = Execute: The module uses the SSP in performing a cryptographic operation.
• Z = Zeroize: The module zeroizes the SSP. For the role, CO indicates “Crypto Officer”. The module implements a service indicator that indicates whether the invoked service is approved. The service indicator is a return value 1 from the FIPS_service_indicator_check_approved function. This function is used together with two other functions. The usage is as follows: © 2026 Amazon Web Services, Inc., atsec information security.

26 of 48

• STEP 1: Should be called before invoking the service. int before = FIPS_service_indicator_before_call();
• STEP 2: Make a service call i.e., API function for performing a service. Func();
• STEP 3: Should be called after invoking the service. int after = FIPS_service_indicator_after_call();
• STEP 4: Return value 1 indicates approved service was invoked. int ret = FIPS_service_indicator_check_approved(before, after); Alternatively, all the above steps can be done by using a single call using the function CALL_SERVICE_AND_CHECK_APPROVED(approved, func).

Table 13: Non-Approved Services

Not applicable. © 2026 Amazon Web Services, Inc., atsec information security.

27 of 48

The integrity of the module is verified by comparing a HMAC value calculated at run time on the bcm.o file, with the HMAC-SHA2-256 value stored within the module that was computed at build time. The HMAC key for the integrity verification is embedded in the module.

The module provides on-demand integrity test. The integrity test can be performed on demand by reloading the module. Additionally, the integrity test can be performed using the On-Demand Integrity Test service, which calls the BORINGSSL_integrity_test function. © 2026 Amazon Web Services, Inc., atsec information security.

28 of 48

Type of Operational Environment: Modifiable How Requirements are Satisfied: The module runs on a commercially available general-purpose operating system executing on the hardware specified in section

2. The module shall be compiled and installed as stated in section
3. The Crypto Officer shall confirm that the module is installed correctly by following steps listed in section 11.1.

Instrumentation tools like the ptrace system call, gdb and strace, userspace live patching, as well as other tracing mechanisms offered by the Linux environment such as ftrace or systemtap, shall not be used in the operational environment. The use of any of these tools implies that the cryptographic module is running in a non-validated operational environment. © 2026 Amazon Web Services, Inc., atsec information security.

29 of 48

The module is software only; therefore, this section is not applicable. © 2026 Amazon Web Services, Inc., atsec information security.

30 of 48

The module does not implement any non-invasive security mechanisms; therefore, this section is not applicable. © 2026 Amazon Web Services, Inc., atsec information security.

31 of 48

Name API input parameters API output parameters

From Operator calling application (TOEPP) Cryptographic module

To Cryptographic module Operator calling application (TOEPP)

Format Type Plaintext Plaintext

Distribution Type Manual Manual

Entry Type Electronic Electronic

SFI or Algorithm

Table 14: Storage Areas Table 15: SSP Input-Output Methods operational environment. © 2026 Amazon Web Services, Inc., atsec information security.

32 of 48

Name AES Key HMAC Key Entropy Input DRBG Seed DRBG Internal State (V, Key) RSA Public Key RSA Private Key EC Public Key

Description AES key used for encryption, decryption, and computing MAC tags HMAC key for Message Authentication Generation Entropy input used to seed the DRBGs DRBG seed derived from entropy input as defined in SP 800-90Ar1 Internal state of CTR_DRBG RSA public key used for RSA key generation, signature verification RSA private key used for RSA key generation, signature generation EC public key used for EC key generation, key verification,

Size - Strength 128-256 bits - 128-256 bits 112-524288 bits - 112-256 bits 256 bits - 256 bits 256 bits - 256 bits V: 128 bits, Key: 256 bits - 256 bits 1024, 2048, 3072, 4096 bits - 80-150 bits 2048, 3072, 4096 bits - 112-150 bits P-224, P-256, P-384, P-521 - 112-256 bits

Type - Category Symmetric key - CSP Authentication key - CSP Entropy - CSP DRBG seed - CSP Internal state - CSP Public key - PSP Private key - CSP Public key - PSP

Generated By Random Number Generation with DRBG Random Number Generation with DRBG Key Generation with RSA Key Generation with RSA Key Generation with ECDSA

Established By

Used By Authenticated Encryption/Decryption with AES KW, AES- KWP Encryption/Decryption with AES Message Authentication Generation with AES Authenticated Encryption/Decryption with AES CCM Authenticated Encryption/Decryption with AES GCM Message Authentication Generation with HMAC Random Number Generation with DRBG Random Number Generation with DRBG Random Number Generation with DRBG Signature Verification with RSA Signature Verification with RSA (legacy) Signature Generation with RSA Shared Secret Computation with EC Diffie-Hellman Signature Verification

Table 16: SSP Zeroization Methods All data output is inhibited during zeroization.

© 2026 Amazon Web Services, Inc., atsec information security.

33 of 48

Name EC Private Key Shared Secret TLS Pre- Master Secret TLS Master Secret TLS Derived Key (AES/HMAC) HKDF Derived Key SSH Derived Key PBKDF Derived Key

Description signature verification, shared secret computation EC private key used for EC key generation, key verification, signature generation, shared secret computation Shared Secret generated by KAS- ECC-SSC TLS Pre-Master secret used for deriving the TLS Master Secret TLS Master secret used for deriving the TLS Derived Key TLS Derived Key from TLS Master Secret KDA HKDF derived key SSH KDF derived key PBKDF derived key

Size - Strength P-224, P-256, P-384, P-521 - 112-256 bits P-224, P-256, P-384, P-521 - 112-256 bits P-224, P-256, P-384, P-521 - 112-256 bits 384 bits - 112-256 bits AES: 128-256 bits HMAC: 112 to 256 bits - AES: 128-256 bits HMAC: 112 to 256 bits 2048 bits - 112-256 bits 128 to 512 bits - 112 to 256 bits 128 to 4096 bits - N/A

Type - Category Private key - CSP Shared secret - CSP TLS pre-master secret - CSP TLS master secret - CSP Symmetric key - CSP Symmetric key - CSP Symmetric key - CSP Symmetric key - CSP

Generated By Key Generation with ECDSA Key Derivation with TLS KDF Key Derivation with KDA HKDF Key Derivation with TLS KDF Key Derivation with KDA HKDF Key Derivation with SSH KDF Key Derivation with PBKDF

Established By Shared Secret Computation with EC Diffie- Hellman

Used By with ECDSA Key Verification with ECDSA Signature Verification with ECDSA (legacy) Shared Secret Computation with EC Diffie-Hellman Signature Generation with ECDSA Key Derivation with TLS KDF Key Derivation with SSH KDF Key Derivation with KDA HKDF Key Derivation with TLS KDF Key Derivation with KDA HKDF Key Derivation with TLS KDF Key Derivation with KDA HKDF

© 2026 Amazon Web Services, Inc., atsec information security.

34 of 48

Name Password Intermediate Key Generation Value

Description Password for PBKDF Intermediate key generation value

Size - Strength 14-128 characters - N/A 224-4096 bits - 112-256 bits

Type - Category Password - CSP Intermediate value - CSP

Generated By Key Generation with RSA Key Generation with ECDSA

Established By

Used By Key Derivation with PBKDF Key Generation with RSA Key Generation with ECDSA

N/A Table 17: SSP Table 1 © 2026 Amazon Web Services, Inc., atsec information security.

35 of 48

The SHA-1 algorithm as implemented by the module will be non-approved for all purposes, starting January 1, 2031. © 2026 Amazon Web Services, Inc., atsec information security.

36 of 48

Table 19: Pre-Operational Self-Tests The module performs the pre-operational self-test automatically when the module is loaded into memory; the pre-operational self-test is the software integrity test that ensures that the module is not corrupted. While the module is executing the pre-operational self-test, services are not available, and input and output are inhibited. If the pre-operational self-test fails, the module transitions to the Error state. The software integrity test is performed after a set of conditional cryptographic algorithm self-tests (CASTs). The set of CASTs includes the self-test for HMAC-SHA2-256 algorithm used in the pre-operational self-test.

© 2026 Amazon Web Services, Inc., atsec information security.

37 of 48

© 2026 Amazon Web Services, Inc., atsec information security.

38 of 48

© 2026 Amazon Web Services, Inc., atsec information security.

39 of 48

© 2026 Amazon Web Services, Inc., atsec information security.

40 of 48

Table 20: Conditional Self-Tests © 2026 Amazon Web Services, Inc., atsec information security.

41 of 48

Data output through the data output interface is inhibited during the self-tests.

Table 21: Pre-Operational Periodic Information © 2026 Amazon Web Services, Inc., atsec information security.

42 of 48

© 2026 Amazon Web Services, Inc., atsec information security.

43 of 48

Table 22: Conditional Periodic Information

© 2026 Amazon Web Services, Inc., atsec information security.

44 of 48

Name

Description operational the data output interface is inhibited

Conditions

Recovery Method

Indicator generates a new key, if the PCT still does not pass, eventually the module will be aborted after 5 tries.

Table 23: Error States In the error states, the output interface is inhibited. If the module fails any of the self-tests, the module enters an error state. To recover from any error state, the module must be rebooted.

The software integrity tests and the CASTs for AES, SHA, SHA3, DRBG, TLS KDF, KDA HKDF, PBKDF2 can be invoked by unloading and subsequently re-initializing the module. The CASTs for ECDSA, KAS-ECC-SSC and RSA can be invoked by requesting the corresponding Key Generation, Shared Secret Computation or Digital Signature services. Additionally, all the CASTs can be invoked by calling the BORINGSSL_self_test function. The PCTs can be invoked on demand by requesting the Key Generation service. © 2026 Amazon Web Services, Inc., atsec information security.

45 of 48

The module bcm.o is embedded into the shared library libcrypto.so which can be obtained by building the source code at the following location [1]. The set of files specified in the archive constitutes the complete set of source files of the validated module. There shall be no additions, deletions, or alterations of this set as used during module build. [1] https://github.com/aws/aws-lc/archive/refs/heads/fips-NetOS-2024-06-11.zip The downloaded zip file can be verified by issuing the “sha256sum aws-lc-fips-NetOS-2024-06-11.zip” command. The expected SHA2-256 digest value is: 952c4a23cea54e2ada37dde18d4d95228736f1d2c303a056c9bb39de55c9cd89 After the zip file is extracted, the cmake flags listed below must be used to compile the module. The compilation must be executed separately for each platform. Due to four possible combinations of OS/processor, the module count is four (i.e., there are four separate binaries generated, one for each entry listed in the Tested Module Identification – Software, Firmware, Hybrid (Executable Code Sets) table). -DFIPS=1 \ -Dlibdir=${libdir} \ -Dbindir=${bindir} \ -DENABLE_EXPERIMENTAL_BIG_ENDIAN_SUPPORT=ON \ -DCMAKE_BUILD_TYPE=Release \ -GNinja \ Upon completion of the build process, the module’s status can be verified by the command below. If the value obtained is “1” then the module has been installed and configured to operate in FIPS compliant manner. ./tool/bssl isfips Lastly, the user can call the “show version” service using awslc_version_string function and the expected output is “AWS-LC FIPS 1.29.1” which is the module version. This will confirm that the module is in the operational mode. Additionally, the “AWS-LC FIPS” also acts as the module identifier and the verification of the "dynamic" part can be done using following command with an application that was used for dynamic linking. The "U" in the output confirms that the module is dynamically linked. Command: nm <application_name> | grep awslc_version_string Example Output: “ U awslc_version_string”

The approved and non-approved modes of operation are specified in section 2.4. The approved services that include the administrative functions are specified in section 4.3. All the logical interfaces are specified in section 3.1. The procedures of installation, initialization, startup, that are specified in section 11.1, and the operational environment requirements, that are specified in section 6, must be followed.

The approved and non-approved modes of operation are specified in section 2.4. The approved and nonapproved cryptographic algorithms are specified in section 2.5. The approved security functions are specified in © 2026 Amazon Web Services, Inc., atsec information security.

46 of 48

section 2.6. The algorithm-specific information is specified in section 2.7. The approved services are specified in section 4.3, the non-approved services are specified in section 4.4. The logical interfaces available to users are specified in section 3.1. The user is responsible for following the procedures of installation, initialization, startup that are specified in section 11.1. The configuration settings and restrictions regarding the operational environment are specified in section 6.2.

When the module is at end of life, for the GitHub repo, the README will be modified to mark the library as deprecated. After a 6-month window, more restrictive branch permissions will be added such that only administrators can read from the FIPS branch. The module does not possess persistent storage of SSPs. The SSP value only exists in volatile memory and that value vanishes when the module is powered off. So as a first step for the secure sanitization, the module needs to be powered off. Then for actual deprecation, the module will be upgraded to newer version that is approved. This upgrade process will uninstall/remove the old/terminated module and provide a new replacement. © 2026 Amazon Web Services, Inc., atsec information security.

47 of 48

RSA timing attacks: RSA is vulnerable to timing attacks. In a setup where attackers can measure the time of RSA decryption or signature operations, blinding must be used to protect the RSA operation from that attack.

The module provides the mechanism to use the blinding for RSA. When the blinding is on, the module generates a random value to form a blinding factor in the RSA key before the RSA key is used in the RSA cryptographic operations. © 2026 Amazon Web Services, Inc., atsec information security.

48 of 48