AWS-LC Cryptographic Module (static)

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for AWS-LC Cryptographic Module (static)
  %% 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>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 (static)
  %% 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>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 (static) Prepared by: atsec information security corporation

4516 Seton Center Pkwy, Suite 250

Austin, TX 78759 www.atsec.com

This document is the non-proprietary FIPS 140-3 Security Policy for version AWS-LC FIPS

2.0.0 of the AWS-LC Cryptographic Module (static). 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

This Security Policy describes the features and design of the module named AWS-LC Cryptographic Module (static) 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. intact and 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.

Purpose and Use: The AWS-LC Cryptographic Module (static) (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 Module Characteristics: 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 (static) which is a cryptographic library consisting of the bcm.o file (version AWS-LC FIPS 2.0.0). This file is statically linked to the userspace application during the compilation process. Tested Operational Environment’s Physical Perimeter (TOEPP): The TOEPP is the general-purpose computer on which the module is installed. Figure 1: Block Diagram

Identification Tested Module Identification

• Hardware: N/A for this module. Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets): Table 2: Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets) Tested Module Identification
• Hybrid Disjoint Hardware: N/A for this module. Tested Operational Environments - Software, Firmware, Hybrid:

Table 3: Tested Operational Environments - Software, Firmware, Hybrid Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: N/A for this module. CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when so ported if the specific operational environment is not listed on the validation certificate.

The module does not claim any excluded components.

Modes List and Description: Table 4: Modes List and Description When the module starts up successfully, after passing the pre-operational self-test and the cryptographic algorithms self-tests (CASTs), 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 Non-Approved 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 The module does not implement a degraded mode of operation.

Table 5: Approved Algorithms Vendor-Affirmed Algorithms:

Table 6: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: N/A for this module. The module does not implement non-approved algorithms that are allowed in the approved mode of operation. Non-Approved, Allowed Algorithms with No Security Claimed: Table 7: Non-Approved, Allowed Algorithms with No Security Claimed Non-Approved, Not Allowed Algorithms:

Table 8: Non-Approved, Not Allowed Algorithms

Name

Type

Description

Properties

Algorithms AES-GCM AES-GCM AES-GCM AES-GCM

Table 9: Security Function Implementations

GCM IV 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 AES-GCM IV is generated randomly internal to the module using module’s approved DRBG. The DRBG seeds itself from the entropy source. The GCM IV is 96 bits in length. Per Section 9, this 96bit IV contains 96 bits of entropy. Scenario 5, TLS 1.3 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 AES-GCM 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. AES XTS 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, such as the encryption of data in transit. Key Derivation using SP 800-132 PBKDF2 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 80090Ar1 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. Compliance to SP 800-56ARev3 assurances The module offers ECDH shared secret computation services compliant to the SP 80056ARev3 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” 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 5.6.2.1 of SP 800-56ARev3.
• 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.

N/A for this module. N/A for this module. The module provides an SP800-90Arev1-compliant Deterministic Random Bit Generator (DRBG) using CTR_DRBG mechanism with AES-256 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 with entropy obtained from inside the physical perimeter of the operational environment but 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".

The module implements Cryptographic Key Generation (CKG, vendor affirmed), compliant with SP 800-133Rev2. When random values are required, they are obtained from the SP 800-90ARev1 approved DRBG, compliant with Section 4 of SP 800-133Rev2. The following methods are implemented: ECDSA (FIPS 186-5, A.2.2 Rejection Sampling): P-224, P-256, P 384, P-521 elliptic curves with 112-256 bits of key strength. RSA (FIPS 186-5, A.1.3 Random Probable Primes): 2048, 3072, 4096 bits with 112, 128, 149 bits of key strength. Additionally, the module implements the following key derivation methods per SP800133Rev2 section 6.2: KDA HKDF (SP 800-56CRev1): 112-256 bits of key strength, using (HMAC) SHA-1, SHA2-224, SHA2-256, SHA2-384, SHA2-512. PBKDF (SP 800-133Rev2, option 1a): 112-256 bits of key strength, using (HMAC) SHA-1, SHA2-224, SHA2-256, SHA2-384, SHA2-512. SSH KDF (SP 800-135Rev1): 112-256 bits of key strength, using AES-128, AES-192, AES-256 with SHA-1, SHA2-224, SHA2-256, SHA2-384, SHA2-512. KDF TLS (SP 800-135Rev1): 112-256 bits of key strength, using SHA2-256, SHA2-384, SHA2512.

The module implements SSP agreement and SSP transport methods as listed in the Security Function Implementations table.

The module implements the SSH key derivation function for use in the SSH protocol (RFC

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.

Table 10: Ports and Interfaces As a Software module, the module interfaces are defined as Software or Firmware Module Interfaces (SMFI), and there are no physical ports. The module does not implement a control

N/A for this module. The module does not support authentication.

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

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.

• 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. 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:
• 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

The module does not support loading of external software or firmware.

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 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.

Type of Operational Environment: Modifiable How Requirements are Satisfied: The module should be compiled and installed as stated in section 11. The user should confirm that the module is installed correctly by following steps 4 and 5 listed in section 11.

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.

Temp/Voltage Type LowTemperature HighTemperature LowVoltage HighVoltage

Temperature or Voltage

EFP or EFT

Result

Temperature Type LowTemperature HighTemperature

Temperature

N/A for this module. The module is comprised of software only and therefore this section is not applicable.

Table 14: EFP/EFT Information

Table 15: Hardness Testing Temperatures

The module claims no non-invasive security techniques.

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 16: Storage Areas Table 17: SSP Input-Output Methods operational environment. The SSPs are provided to the module via API input parameters in the calling application running on the same operational environment. Table 18: SSP Zeroization Methods

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

Description AES key used for encryption, decryption, and computing MAC tags HMAC key for Message Authenticatio n 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

Size - Strengt h 128-256 bits - 128-256 bits 112- 524288 bits - 112-256 bits 256 bits - 256 bits 256 bits - 256 bits 256 bits - 256 bits 1024, 2048, 3072, 4096 bits - 80-150 bits 2048, 3072, 4096 bits - 112-150 bits

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

Generate d By Random Number Generation with DRBG Random Number Generation with DRBG Key Generation with RSA Key Generation with RSA

Establishe d By

Used By Key Wrapping/Unwrappin g with AES KW, AES- KWP Key Wrapping/Unwrappin g with AES GCM Key Wrapping/Unwrappin g with AES CCM Encryption/Decryptio n with AES Message Authentication Generation with AES Authenticated Encryption/Decryptio n with AES CCM Authenticated Encryption/Decryptio n with AES GCM Message Authentication Generation with HMAC Random Number Generation with DRBG Random Number Generation with DRBG Random Number Generation with DRBG Key Generation with RSA Signature Verification with RSA Signature Generation with RSA Key Generation with RSA

Name EC Public Key EC Private Key Shared Secret TLS Pre- Master Secret TLS Master Secret TLS Derived Key (AES/HMAC) KDA Derived Key

Description EC public key used for EC key generation, key verification, 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

Size - Strengt h 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 112-256 bits - N/A 384 bits - N/A AES: 128- 256 bits HMAC: 112 to 256 bits - AES: 128-256 bits HMAC: 112 to 256 bits 112 to 256 bits - N/A

Type - Category Public key - PSP Private key - CSP Shard secret - CSP TLS pre- master secret - CSP TLS master secret - CSP Symmetric key - CSP Symmetric key - CSP

Generate d By Key Generation with ECDSA Key Generation with ECDSA Key Derivation with TLS KDF Key Derivation with KDA HKDF Key Derivation with TLS KDF Key Derivation with KDA HKDF

Establishe d By Shared Secret Computation with EC Diffie- Hellman

Used By Shared Secret Computation with EC Diffie-Hellman Key Generation with ECDSA Signature Verification with ECDSA Shared Secret Computation with EC Diffie-Hellman Signature Generation with ECDSA Key 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 Key Derivation with TLS KDF Key Derivation with KDA HKDF

Name SSH Derived Key PBKDF Derived Key Password Intermediat e Key Generation Value

Description SSH KDF derived key PBKDF derived key Password for PBKDF Intermediate key generation value

Size - Strengt h 112 to 256 bits - N/A 112 to 256 bits - N/A 112- 524288 bits - N/A 224-4096 bits - 112-256 bits

Type - Category Symmetric key - CSP Symmetric key - CSP Password - CSP Intermediate value - CSP

Generate d By Key Derivation with SSH KDF Key Derivation with PBKDF Key Generation with RSA Key Generation with ECDSA

Establishe d By

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

The SHA-1 algorithm as implemented by the module will be non-approved for all purposes, starting January 1, 2030.

Table 21: 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. The software integrity test is performed after a set of conditional cryptographic algorithm self-tests (CASTs). The set of CASTs executed before the software integrity test consists of HMAC-SHA2-256 KAT, which is used in the pre-operational self-test, and the SHA2-256 KAT.

Table 22: Conditional Self-Tests Conditional Cryptographic Algorithm Tests The module performs self-tests on approved cryptographic algorithms, using the tests shown in Table 22. Data output through the data output interface is inhibited during the selftests. The CASTs are performed in the form of Known Answer Tests (KATs), in which the calculated output is compared with the expected known answer (that are hard-coded in the module). A failed match causes a failure of the self-test. If any of these self-tests fails, the module transitions to error state. Conditional Pair-Wise Consistency Tests pairwise consistency test (PCT) using sign and verify functions when the keys are generated (Table 22). If any of these self-tests fails, the module transitions to error state and is aborted.

Table 23: Pre-Operational Periodic Information Table 24: Conditional Periodic Information The module does not support periodic self-tests.

Table 25: Error States 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, SHS, DRBG, HMAC, KAS-ECC-SSC, TLS KDF, KDA HKDF, PBKDF2 can be invoked by unloading and subsequently re-initializing the module. The CASTs for ECDSA and RSA can be invoked by requesting the corresponding Key Generation 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.

The module bcm.o is embedded into the usersapce application 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/tags/AWS-LC-FIPS-2.0.0.zip The downloaded zip file can be verified by issuing the “sha256sum AWS-LC-FIPS-2.0.0.zip” command. The expected SHA2-256 digest value is: 6241EC2F13A5F80224EE9CD8592ED66A97D426481066FEAA4EFC6F24E60BBC96 After the zip file is extracted, the instructions listed below will compile the module. The compilation instructions must be executed separately on platforms that have different processors and/or operating systems. Due to six possible combinations of OS/processor, the module count is six (i.e., there are six separate binaries generated, one for each entry listed in the Tested Operational Environments table). Amazon Linux 2 and Amazon Linux 2023: 1. s u d o y u m g r o u p i n s t a l l " De v e l o p me n t To o l s "

3 . c d a ws - l c - f i p s - 2 0 2 2 - 1 1 - 0 2 /

6 . c ma k e 3 - DFI PS=1 . .

Ubuntu 22.04: 1. s udo a pt - ge t i ns t a l l bui l d- e s s e nt i a l

2 . s u d o a p t - g e t i n s t a l l c ma k e

3 . Ge t l a t e s t Go l a n g a r c h i v e f o r y o u r a r c h i t e c t u r e

4. s udo t a r - C / us r / l oc a l - xz f go*. t a r . gz

5 . c d a ws - l c - f i p s - 2 0 2 2 - 1 1 - 0 2 /

8 . c ma k e - DFI PS=1 - DGO_ EXECUTABLE=/ u s r / l o c a l / g o / b i n / g o . .

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. . / t ool / bs s l i s f i ps

Lastly, the user can call the “show version” service using awslc_version_string function and the expected output is “AWS-LC FIPS 2.0.0” 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 "static" part can be done using following command with an application that was used for static linking. The "T" in the output confirms that the module is statically linked. Command: nm <application_name> | grep awslc_version_string Example Output: 0000000000a5bdff T awslc_version_string

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.

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.