BoringCrypto

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for BoringCrypto
  %% 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</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/>HTTPS<br/>library named: boringssl</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 BoringCrypto
  %% 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</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/>HTTPS<br/>library named: boringssl</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

Google, LLC BoringCrypto Date: September 10. 2025 Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

This document describes the cryptographic module Security Policy (SP) for the Google, LLC BoringCrypto (software version: 20240407) cryptographic module (also referred to as the “module” hereafter). It contains a specification of the security rules under which the cryptographic module operates, including the security rules derived from the requirements of the FIPS 140-3 standard. The module meets the overall Level 1 security requirements of FIPS 140-3.

Purpose and Use: The Google, LLC BoringCrypto module is an open-source, general-purpose cryptographic library which provides FIPS 140-3 approved cryptographic algorithms to serve BoringSSL and other user-space applications. Module Embodiment: MultiChipStand Module Characteristics: Cryptographic Boundary: The boundary of the module is defined as a single object file, bcm.o, and its instantiation in memory. Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

Tested Operational Environment’s Physical Perimeter (TOEPP): The TOEPP is the enclosure of the general purpose computer the module is running on. Figure 1: Block Diagram

Tested Module Identification

• Software: Table 2: Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets) Tested Operational Environments - Software: Google, LLC 2025 Version 1.0 Public Material
• May be reproduced only in its original entirely (without revision)

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

The module contains no excluded components.

Modes List and Description: Table 4: Modes List and Description The module supports two modes of operation: Approved and Non-approved. The module will be in approved mode when all power up self-tests have completed successfully, and only Approved Approved algorithm is invoked (see table below). The module does not enforce a general Approved mode, use the service indicators to determine whether a given service is operated in an Approved mode. Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

Approved Algorithms: Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

Table 5: Approved Algorithms Vendor-Affirmed Algorithms: Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

Table 6: Vendor-Affirmed Algorithms N/A for this module. Non-Approved, Allowed Algorithms with No Security Claimed: N/A for this module. Table 7: Non-Approved, Not Allowed Algorithms

Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

Table 8: Security Function Implementations

AES-CTR Reuse of a counter value under the same AES key in AES-CTR is a serious cryptographic vulnerability. The developer integrating the module must prevent this vulnerability by never providing a counter start value that is the same or earlier than the last counter value used under that key for AES-CTR encryption. AES-GCM In the case of AES-GCM, the IV generation method is user-selectable, and the value can be computed in more than one manner. The module does not implement the TLS protocol but offers cryptographic primitives that can be used by an external operator/application to implement TLS. The following restrictions must be followed when an external operator/application uses the module’s AES-GCM within a TLS implementation. In the context of the TLS protocol version 1.3, AES-GCM encryption and decryption is used compliant to Scenario 5 in FIPS 140-3 IG C.H. The module is compliant with NIST SP 80052rev2 and the mechanism for IV generation is compliant with RFC 8446. The module ensures that it is strictly increasing and thus cannot repeat. When the IV exhausts the maximum number of possible values for a given session key, the first party (client or server) to encounter this condition may either send a TLS 1.3 KeyUpdate message to establish a new encryption key, or fail. In either case, the module prevents any IV duplication and thus enforces the security property. Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

In the context of the TLS protocol version 1.2, AES-GCM encryption and decryption is used compliant to Scenario 1 in FIPS 140-3 IG C.H. The module is compatible with TLS protocol version 1.2 using AES-GCM ciphersuites as specified in NIST SP 800-52rev2, Section 3.3.1, and the mechanism for IV generation is compliant with RFC 5288. The module ensures that it is strictly increasing and thus cannot repeat. When the IV exhausts the maximum number of possible values for a given session key, the first party (client or server) to encounter this condition may either trigger a handshake to establish a new encryption key in accordance with RFC 5246 or fail. In either case, the module prevents any IV duplication and thus enforces the security property. The module’s IV is generated internally by the module’s Approved DRBG, which is internal to the module’s boundary. The IV is 96 bits in length per NIST SP 800-38D, Section 8.2.2 and FIPS 140-3 IG C.H scenario 2. The selection of the IV construction method is the responsibility of the user of this cryptographic module. In approved mode, only internally generated IVs, or the TLS modes described above, are considered compliant for use. Per IG C.H, in the event module power is lost and restored, the consuming application must ensure that any of its AES-GCM keys used for encryption or decryption are re-distributed. AES-KW / AES-KWP 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. Counter DRBG The CTR_DRBG is used without a derivation function. IG D.L requires that a CTR_DRNG used without a derivation function shall be seeded from an entropy source producing full-entropy outputs, and the entropy source shall be located within the TOEPP. The module relies on passively provided entropy and it is the responsibility of the developer integrating the module to ensure that the entropy used to seed the DRBG comes from a source located within the TOEPP which CMVP has evaluated as producing full entropy output. KAS-ECC-SSC and KAS-FFC-SSC 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. Hashing The module does not perform truncation of hash outputs except as part of the approved SHA2224, SHA2-512/256, and SHA2-384 algorithms. These algorithms inherently produce hash outputs of 224, 256, and 384 bits, respectively, as defined by FIPS 180-4. The module complies with IG C.L because no additional or manual truncation of hash outputs is implemented by the module in any other context. Legacy Use Algorithms SHA-1 is categorized as Legacy Use when using as part of digital signature verification. 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. It is the responsibility of the developer integrating the module to ensure this restriction is met. Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

N/A for this module. N/A for this module. The module passively receives entropy, per IG 9.3.A case 2(b), and shall be provided at least

384 bits of entropy. Use a SP 800-90B compliant entropy source with at least 256 bits of

security strength. Entropy is supplied to the Module via callback functions. The callback functions shall return an error if the minimum entropy strength cannot be met. The caveat “No assurance of the minimum strength of generated SSPs (e.g., keys)” is applicable.

The module provides several key generation methods.

• Generation of asymmetric keys for key generation per SP 800-133r2 section 5.1 CKG and FIPS 186-5.
• Generation of asymmetric keys for key establishment per SP 800-133r2 section 5.2 CKG and SP 800-56Arev3.
• Derivation of symmetric keys for industry standard protocols from a key agreement shared secret per SP 800-133r2 section 6.2.1 and SP 800-135rev1 TLS v1.2 KDF / RFC

• Derivation of symmetric keys from a key agreement shared secret per SP 800-133r2 section 6.2.1 and SP 800-56Cr2 KDA HKDF. The module does not have a key generation service for symmetric keys; however, a calling application may create one using output from the module’s Approved DRBG.

The module provides the cryptographic building blocks for key agreement in its SP 800-56Arev3 KAS-ECC-SSC and KAS-FFC-SSC algorithms. A calling application may link these to the module’s SP 800-135rev1 TLS v1.2 KDF or RFC 8446 TLS v1.3 KDF to form a complete key agreement scheme. No other part of the TLS protocol, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP.

The module does not implement any complete industry protocols, however it provides the key agreement and key derivation cryptographic algorithm building blocks to allow calling applications to implement the industry standard TLS v1.2 RFC 7627 or TLS v1.3 protocols using FIPS approved key establishment. The key establishment and generation primitives are described in sections 2.9 and 2.10, and the use of AES-GCM within them described in section 2.7. Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

Table 9: Ports and Interfaces consists of the actual API input parameters. The Status Output interface includes the return values of the API functions. As a software module, control of the physical ports is outside the module scope. However, when the module is performing self-tests, or is in an error state, all output on the module’s logical data output interfaces is inhibited. The module does not implement a power interface or a control output interface.

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

Table 10: Roles The cryptographic module only implements a Crypto Officer (CO) role. The CO role is implicitly assumed by the entity accessing services implemented by the module. An operator is considered the owner of the thread that instantiates the module and, therefore, only one concurrent operator is allowed.

Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

W,E G,E G,E Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

G,E W,E E W,E W,E W Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

G,R G,R W,E Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

G,R G,E G,R G,R G,R G,R E Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

W,E Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

Z Z Z Z Table 11: Approved Services The Approved services supported by the module and access rights within services accessible over the module’s public interface are listed in the table above. The corresponding FIPS_service_indicator_xxx function can be called to query the approved algorithm status of the proceeding service call, or the macro CALL_SERVICE_AND_CHECK_APPROVED can be used to automatically check the approved Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

service indicator and inform the calling application whether the service called through the macro was FIPSStatus::APPROVED or FIPSStatus::NOT_APPROVED.

Table 12: Non-Approved Services Non-Approved Services are listed in the table above.

The module does not support external software loading.

The pre-operational integrity test is performed using HMAC-SHA-256.

The integrity test can be executed on demand by power-cycling the host platform and reloading the module.

The module is open-source. To build the approved version of the module the following tools are required to build and compile the module. Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

Type of Operational Environment: Modifiable The module runs on a GPC, which is a modifiable operational environment, running one of the operating systems specified in Table 2. Each tested operating system manages processes and threads in a logically separated manner. The module’s user is considered the owner of the calling application that instantiates the module. No special configuration of the operating system is required. The module is designed to ensure that the power-up tests are initiated automatically when the module is loaded.

As a software module, the physical security requirements are not applicable.

The module does not claim any non-invasive security measures.

Table 13: Storage Areas The module has no persistent SSP storage, all SSPs are stored ephemerally in RAM and are zeroised once no longer needed.

Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

Name AES Key AES-GCM Key AES Wrapping Key Wrapped Key

Descriptio n AES Key AES-GCM Key AES Wrapping Key Any calling application

Size - Strengt h 128 192 256 - 128 192 256 128 192 256 - 128 192 256 128 192 256 - 128 192 256 Any - Any

Type - Category Symmetri c Key - CSP Symmetri c Key - CSP Symmetri c Key - CSP Any - CSP

Generate d By

Establishe d By

Used By Decryption Encryption Authenticated Decryption Authenticated Encryption Message Authenticatio n AES- KeyWrap

Table 14: SSP Input-Output Methods The software module inputs and outputs SSP only as part of its API, and normally they are input unwrapping, where the wrapped key is entered or output encrypted.

Table 15: SSP Zeroization Methods The software module has no persistent SSP storage and the zeroisation method for all SSP is currently holds. h n Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

h Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

h n Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

h n n Table 16: SSP Table 1 Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

Output Duration Table 17: SSP Table 2

Table 18: Pre-Operational Self-Tests Pre-operational self-tests are run upon the initialization of the module. The CAST (Cryptographic Algorithm Self-Test) for HMAC-SHA2-256 is performed before the integrity test. Self-tests do not require operator intervention to run. If any of the tests fail, the module will not initialize and enter an error state where no services can be accessed.

Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

Table 19: Conditional Self-Tests Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

Conditional cryptographic algorithm self-tests (CAST) are run prior to the first use of the cryptographic algorithm. CASTs do not require operator intervention to run. If any of the tests fail, the module will enter an error state and no services can be accessed. Pair-wise consistency tests (PCT) are run during the module’s operation when a new asymmetric keypair is generated. If any of these tests fail, the module will enter an error state, where no services can be accessed by the operators. The module can be re-initialized to clear the error and resume approved mode of operation. Table 20: Pre-Operational Periodic Information Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

Table 21: Conditional Periodic Information A level 1 module does not require automatic periodic self-testing, however self-tests can be

Table 22: Error States The module’s single error state is shows above. Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

The cryptographic module is initialized by loading the module before any cryptographic functionality is available. In User Space the operating system is responsible for the initialization process and loading of the library. General guidance about the module can be found at https://boringssl.googlesource.com/boringssl. This includes information about the APIs, building and specific information related to FIPS can be found at https://boringssl.googlesource.com/boringssl.git/+/refs/heads/fips20230428/crypto/fipsmodule/FIPS.md (note this still mentions 140-2, but the information there is the same). The module is open source and must be built on a Linux workstation using the tools in section

Once the above tools have been obtained, issue the following command to create a CMake toolchain file to specify the use of Clang: printf "set(CMAKE_C_COMPILER \"clang\")\nset(CMAKE_CXX_COMPILER \"clang++\")\n" > ${HOME}/toolchain The FIPS 140-3 validated release of the module can be obtained by downloading the tarball containing the source code at the following location: https://commondatastorage.googleapis.com/chromium-boringssl-fips/boringssl85897d07196b7bf164dbd4673fc78b762aff3e8b.tar.xz or by issuing the following command: wget https://commondatastorage.googleapis.com/chromium-boringssl-fips/boringssl85897d07196b7bf164dbd4673fc78b762aff3e8b.tar.xz 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. The downloaded tarball file can be verified using the below SHA-256 digest value: b1c87a2746e831dd51448038d8ec7d0ba256d949e73dace0c9a1484889d82d1a By issuing the following command: sha256sum boringssl-85897d07196b7bf164dbd4673fc78b762aff3e8b.tar.xz The tarball can be extracted using the following command: tar xJ < boringssl-85897d07196b7bf164dbd4673fc78b762aff3e8b.tar.xz After the tarball has been extracted, the following commands will compile the module: Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)

cd boringssl mkdir build && cd build ninja bcm.o Retrieving Module name and version The following methods will provide the module name and versions:

• FIPS_module_name()
• BoringCrypto
• FIPS_version()
• 20240407

CSP Sharing Non-Approved cryptographic algorithms shall not share the same key or CSP as an approved algorithm. As such, Approved algorithms shall not use the keys generated by the module’s NonApproved key generation methods or the converse.

The module does not support a non-administrator role.

The source code for the module is maintained in a git repository. While in development, work on the code is maintained internally, before eventually being released externally. BoringCrypto is released publicly to https://boringssl.googlesource.com/boringssl (this is the generic version, available under the Building for Linux instructions). The version number is determined by the developer releasing the version, though git attaches hashes to every single file and branch in the repository.

The module is not designed to mitigate against attacks that are outside of the scope of FIPS 140-3. Google, LLC 2025 Version 1.0 Public Material – May be reproduced only in its original entirely (without revision)