BoringCrypto

Certificate

Approved Algorithms (33)

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"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Status Output<br/>Self-Test<br/>Show Status</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"]
    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"]
    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"]
    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
  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 C3,C5,C6 clue;
  class I3,I5,I6 infer;
  class R3,R5,R6 risk;
  class 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)"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Status Output<br/>Self-Test<br/>Show Status</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 C3,C5,C6 clueLow;

Security Policy, page by page

Google, LLC. BoringCrypto Software Version: 2023042800 Date: January 10, 2025 Public Material

• May be reproduced only in its original entirety (without revision).

Introduction Federal Information Processing Standards Publication 140-3

• Security Requirements for Cryptographic Modules specifies requirements for cryptographic modules to be deployed in a Sensitive but Unclassified environment. The National Institute of Standards and Technology (NIST) and Canadian Centre for Cyber Security (CCCS) Cryptographic Module Validation Program (CMVP) run the FIPS 140 program. The NVLAP accredits independent testing labs to perform FIPS 140 testing; the CMVP validates modules meeting FIPS

140 validation. Validated is the term given to a module that is documented and tested against the FIPS

Additional information is available on the CMVP website at: https://csrc.nist.gov/projects/cryptographic-module-validation-program About this Document This non-proprietary Cryptographic Module Security Policy for BoringCrypto from Google, LLC provides an overview of the product and a high-level description of how it meets the overall Level 1 security requirements of FIPS 140-3. The BoringCrypto module is also referenced in this document as the “module”. Disclaimer The contents of this document are subject to revision without notice due to continued progress in methodology, design, and manufacturing. Google, LLC. shall have no liability for any error or damages of any kind resulting from the use of this document. Notices This document may be freely reproduced and distributed in its entirety without modification. Public Material

• May be reproduced only in its original entirety (without revision).

List of Figures Public Material

• May be reproduced only in its original entirety (without revision).

1. General This document describes the cryptographic module Security Policy (SP) for the Google, LLC. BoringCrypto (Software version: 2023042800) cryptographic module (also referred to as the “module” hereafter). It contains 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. The following table lists the level of validation for each area in FIPS 140-3: Section FIPS 140-3 Section Title Security Level

10 Self-tests 1

11 Life-cycle assurance 1

12 Mitigation of other attacks N/A

Table 1 - Security Level Public Material

• May be reproduced only in its original entirety (without revision).

2. Cryptographic Module Specification 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. The boundary of the module is defined as a single object file, bcm.o, and its instantiation in memory. The module version is: 2023042800. The module was tested on the following operational environments: Operating # Hardware Platform Processor PAA/Acceleration System Google Tensor G3 64-

1 Android 14 Google Pixel 8 With and without PAA

2 Android 14 Google Pixel 7 With and without PAA

bit and 32-bit Google Tensor 64-bit

3 Android 14 Google Pixel 6 With and without PAA

and 32-bit Qualcomm Snapdragon

4 Android 14 Google Pixel 5a With and without PAA

5 IN762 IN762 With and without PAA

with Linux 5.15.110 Google Prodimage

6 Tau t2a Ampere Altra With and without PAA

with Linux 5.10.0 Gigabyte GA-Z170X-

7 Ubuntu 23.04 Intel Core i7-6700K With and without PAA

8 Debian Linux 6.4.4 n2d AMD EPYC 7B12 With and without PAA

Table 2 - Tested Operational Environments The cryptographic module is also supported on the following operational environments for which operational testing and algorithm testing was not performed: # Operating System Hardware Platform

1 x86_64 architecture

Linux 4.X ARMv7 architecture ARMv8 architecture

2 x86_64 architecture

Linux 5.X ARMv7 architecture ARMv8 architecture

3 x86_64 architecture

Linux 6.X ARMv7 architecture ARMv8 architecture Table 3 - Vendor Affirmed Operational Environments Public Material

• May be reproduced only in its original entirety (without revision).

Algorithm Description / CAVP Cert and Mode/Method Key Size(s) / Key Use / Function Standard Strength(s) 128, 192, 256-bit AES keys with 128. Symmetric Encryption, A4687 FIPS 197 CBC, ECB, CTR SP 800-38A 192, 256-bit key Symmetric Decryption strength Symmetric 128, 192, 256-bit AES Authenticated keys with 128. A4687 FIPS 197 GCM Encryption, Symmetric SP 800-38D 192, 256-bit key Authenticated strength Decryption 128, 192, 256-bit AES keys with 128. Symmetric message A4687 FIPS 197 GMAC SP 800-38D 192, 256-bit key authentication strength Symmetric AES 128-bit keys with Authenticated A4687 FIPS 197 CCM 128-bit key Encryption, Symmetric SP 800-38C strength Authenticated Decryption 128, 192, 256-bit AES Symmetric Key keys with 128. A4687 FIPS 197 KW, KWP Wrapping, Symmetric SP 800-38F 192, 256-bit key Key Unwrapping strength DRBG A4687 SP 800- CTR_DRBG AES-256 Random Bit Generation 90Arev1 P-224, P-256, PKey Pair Generation, 384, P-521 with ECDSA Signature Generation, Asymmetric Digital A4687 112, 128, 192, FIPS 186-4 Signature Verification, Signature Services 256-bit key Public Key Verification strength Generate, Verify HMAC-SHA-1, HMAC-SHA-224, Key Length: 8- Symmetric Generation, HMAC A4687 HMAC-SHA-256, 524288 Increment Symmetric FIPS 198-1 HMAC-SHA-384, 81 Authentication HMAC-SHA-512 HMAC-SHA-512/256 Key Generation, RSA (1024, 2048, Asymmetric Digital A4687 Signature Generation, FIPS 186-4 3072, 4096) Signature Services Signature Verification HMAC key lengths < 112 bits are disallowed by SP 800-131Ar2. Public Material

• May be reproduced only in its original entirety (without revision).

Algorithm Description / CAVP Cert and Mode/Method Key Size(s) / Key Use / Function Standard Strength(s) PKCS 1.5 and PSS Note: Key size

for Signature Verification Digital Signature SHA-1, SHA-224, Generation, Digital SHS SHA-256, SHAA4687 Hashing Signature Verification, FIPS 180-4 384, SHA-512, non-Digital Signature SHA-512/256 Applications P-224, P-256, P- Asymmetric Key KAS-ECC-SSC KAS-ECC-SSC 384 and P-521 Agreement Scheme A4687 SP 800- ephemeralUnified, with 112, 128, Shared Secret 56Arev3 staticUnified 192, 256-bit key Computation per SP strength 800-56Arev3 Asymmetric Key 2048/244, KAS-FFC-SSC Agreement Scheme 2048/256-bit keys A4687 SP 800- KAS-FFC-SSC dhEphem Shared Secret with 112-bit key 56Arev3 Computation per SP strength 800-56Arev3 HMAC SHA2-224, HMAC SHA2-256, HMAC SHA2-384, KDA HKDF HMAC SHA2-512, Hash Based Key A4687 KDA HKDF Sp800-56Cr1 HMAC SHA2- Derivation 512/256 112-512-bit security strength TLS v1.2 KDF CVL TLS v1.2 KDF SHA2-256, SHA2A4687 TLS Key Derivation RFC7627 RFC7627 384, SHA2-512 CVL TLS v1.3 KDF SHA2-256, SHA2A4687 TLS v1.3 KDF TLS Key Derivation DHE, PSK, PKS-DHE 384 Table 4

• Approved Algorithms No part of the TLS protocol, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP. Algorithm Caveat Use / Function CKG [IG D.H] Cryptographic key generation per SP 800133rev2 and IG D.I * Generation of asymmetric keys for signature generation per [133] section 5.1. * Generation of asymmetric keys for key establishment per [133] section 5.2. * Symmetric key derivation for industry Public Material
• May be reproduced only in its original entirety (without revision).

standard protocols from a key agreement shared secret per [133] section 6.2.1. Table 5

• Vendor Affirmed Algorithms The module does not implement any Non-Approved Algorithms Allowed in the Approved Mode of Operation. (SP 800-140B tables ‘Non-Approved Algorithms Allowed in the Approved Mode of Operation’ has been omitted) The module does not implement any Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed. (SP 800-140B tables ‘Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed’ has been omitted) Algorithm/Function Use/Function MD5, MD4 Non-Approved Hashing POLYVAL Non-Approved authenticated encryption DES, Triple-DES (non-compliant) Non-Approved encryption/decryption AES (non-compliant) Non-Approved encryption/decryption DH (non-compliant) Non-Approved key agreement RSA PKCS #1 v1.5 key wrapping (non-compliant) Non-Approved key wrapping TLS 1.0/1.1 KDF (non-compliant) Non-Approved TLS key derivation Table 6
• Non-Approved Algorithms Not Allowed in the Approved Mode of Operation Name Type Description SP Properties Algorithms/CAVP Cert KAS-ECC-SSC KAS SP 800-56Arev3. P-224, P-256, P-384, KAS-ECC-SSC Sp800KAS_ECC_SSC per IG D.F P- 521 curves 56Ar3/A4687 Scenario 2, path (1) providing 128, 192, or

strength KAS-ECC KAS SP 800-56Arev3. P-224, P-256, P-384, KAS-ECC-SSC Sp800KAS_ECC_SSC per IG D.F P- 521 curves 56Ar3/A4687 Scenario 2, path (2). No key providing 128, 192, or TLS v1.2 KDF confirmation, key derivation 256 bits of encryption RFC7627/A4687 per IG 2.4.B. SP 800-135. strength TLS v1.3 KDF/A4687 KDFs (TLS v1.2 RFC6727, TLS v1.3) KAS-FFC-SSC KAS SP 800-56Arev3. 2048/244, 2048/256- KAS-FFC-SSC Sp800KAS_ECC_SSC per IG D.F bit keys with 112-bit 56Ar3/A4687 Scenario 2, path (1) of encryption strength KAS-FFC KAS SP 800-56Arev3. 2048/244, 2048/256- KAS-FFC-SSC Sp800KAS_FFC_SSC per IG D.F bit keys with 112-bit 56Ar3/A4687 Scenario 2, path (2). No key of encryption strength TLS v1.2 KDF confirmation, key derivation RFC7627/A4687 per IG 2.4.B. SP 800-135. TLS v1.3 KDF/A4687 KDFs (TLS v1.2 RFC6727, TLS v1.3) Public Material

• May be reproduced only in its original entirety (without revision).

KTS KTS SP 800-38F. AES-KW, AES- 128, 192, 256-bit keys AES-KW/A4687 KWP with 128, 192, or 256- AES-KWP/A4687 bit encryption strength Table 7

• Security Function Implementation (SFI) Figure 1
• BoringCrypto cryptographic boundary Public Material
• May be reproduced only in its original entirety (without revision).

3. Cryptographic Module Interfaces The Data Input interface consists of the input parameters of the API functions. The Data Output interface consists of the output parameters of the API functions. The Control Input interface consists of the actual API input parameters. The Status Output interface includes the return values of the API functions. The module does not implement a power input interface or a control output interface. Logical interface Data that passes over port/interface Data Input API input parameters Data Output API output parameters and return values Control Input API input parameters Status Output API return values Table 8

• Ports and Interfaces 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. Public Material
• May be reproduced only in its original entirety (without revision).

4. Roles, services, and authentication

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.

The module does not support operator authentication. Role Authentication Method Authentication Strength Crypto Officer (CO) n/a n/a Table 9

• Roles and Authentication

The Approved services supported by the module and access rights within services accessible over the module’s public interface are listed in the table below: Role Service Input Output CO Module Initialization N/A Return code CO Symmetric Encryption Plaintext, AAD, IV encryption Return code, ciphertext, tag key CO Symmetric Decryption Ciphertext, AAD, IV, tag, Return code, plaintext decryption key CO Keyed Hashing Message, key Return code, Message Authentication Code CO Hashing Message Return code, hash CO Random Bit Generation API call parameters Return code, random bits CO Signature Generation Message, signing key Return code, signature CO Signature Verification Signature, verification key Return code CO Key Wrap API call parameters, Return code, wrapped key unwrapped key, wrapping key CO Key Unwrap API call parameters, wrapped Return code, unwrapped key key CO Key Agreement API call parameters Return code, shared secret CO Key Derivation KDA API call parameters, shared Return code, derived key secret CO TLS Key Derivation API call parameters, TLS pre- Return code, TLS Key master secret CO Key Generation API call parameters Return code, key pair CO Key Verification API call parameters, key pair Return code CO On-Demand Self-Test N/A Return code CO Zeroization N/A N/A CO Show Status API call parameters Return code, status Table 10

• Roles, Service Commands, Input and Output Public Material
• May be reproduced only in its original entirety (without revision).

Approved services are listed in Table 11

• Approved Services. The SSPs listed in the table indicate the access required using below notation: 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. The indicator is provided as part of the API and is not a separate call. When a call is made to the module to perform an action using an algorithm, the response contains the indicator as part of the return value automatically. There is not a separate call just to determine the indicator status other than the general status parameter as to whether the entire module is in the approved state or not. Public Material
• May be reproduced only in its original entirety (without revision).

Approved Security Access rights Service Description Keys/SSP’s Role Indicator Functions to Keys/SSP’s Module Initialization Initializes the module N/A N/A CO N/A N/A Perform symmetric AES CBC, ECB, Symmetric Encryption AES Key, AES-GCM Key CO W, E 1 encryption operations CTR, GCM, CCM Perform symmetric AES CBC, ECB, Symmetric Decryption AES Key, AES-GCM Key CO W, E 1 decryption operations CTR, GCM, CCM Perform keyed hashing Keyed Hashing HMAC, GMAC HMAC Key, AES-GCM Key CO W, E 1 operations Perform hashing Hashing SHS N/A CO N/A 1 operations DRBG Seed, CTR_DRBG V, G, E Random Bit CTR_DRBG Key Generate random numbers CTR_DRBG CO 1 Generation CTR_DRBG W, E Entropy Input RSA Signature Generation Key, W, E CTR_DRBG, RSA, Signature Generation Perform signing operations ECDSA Signing Key CO 1 ECDSA CTR_DRBG V, CTR_DRBG E Key RSA Signature Verification Perform verification Signature Verification RSA, ECDSA Key, CO W, E 1 operations ECDSA Verification Key AES Wrapping Key W, E Perform key encryption Key Wrap AES KW, KWP Unwrapped Key CO W 1 operations Wrapped Key G, R AES Wrapping Key W, E Perform key decryption Key Unwrap AES KW, KWP Wrapped Key W 1 operations CO Unwrapped Key G, R EC DH Private Key & EC DH Perform key agreement KAS-ECC-SSC, Key Agreement KAS-FFC-SSC Public Key, DH Private Key CO G, E 1 operations & DH Public Key Public Material

• May be reproduced only in its original entirety (without revision).

Approved Security Access rights Service Description Keys/SSP’s Role Indicator Functions to Keys/SSP’s Other Party EC DH Public Key, Other Party DH Public W, E Key Shared Secret G, R Perform key derivation KDA HKDF Shared Secret W, E Key Derivation KDA CO 1 operations Sp800-56Cr2 Derived Key G, R TLS Pre-Master Secret W, E Perform key derivation TLS Key Derivation TLS KDF TLS Master Secret CO G, E 1 operations TLS Key G, R CTR_DRBG V, CTR_DRBG E Key RSA Signature Generation Perform generation CTR_DRBG, RSA, Key Generation ECDSA Key & RSA Signature CO 1 operations Verification Key, G, E, R ECDSA Signing Key & ECDSA Verification Key Perform key pair ECDSA Signing Key, ECDSA Key Verification ECDSA CO W, E 1 verification operations Verification Key Execute self-tests on On-Demand Self-Test N/A N/A CO N/A 1 demand Zeroization Zeroize all SSPs N/A All keys CO Z N/A Obtain the module status Show Status N/A N/A CO N/A N/A and versioning information Table 11

• Approved Services Non-Approved Services are listed in the Table 12 below: Service Description Algorithms Accessed Role Indicator TLS 1.0/1.1 KDF Perform hashing operations when used with MD5 & SHA-1 CO 0 the TLS protocol version 1.0 and 1.1 Hashing Perform hashing operations MD4, MD5 CO 0 Public Material
• May be reproduced only in its original entirety (without revision).

Hashing Used as part of AES-GCM-SIV POLYVAL CO 0 Symmetric Perform symmetric encryption and/or DES CO 0 encryption/decryption decryption operations Triple-DES AES Key Transport Perform RSA PKCS #1 v1.5 key transport RSA CO 0 Table 12 - Non-Approved Services Public Material

• May be reproduced only in its original entirety (without revision).

5. Software/Firmware Security 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 does not support software loading.

The form of the module is a single object file, bcm.o.

6. Operational Environment The module runs on a GPC, which is a modifiable operational environment, running one of the operating systems specified in Table
7. 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.
8. Physical Security As a software module, the physical security requirements are not applicable.
9. Non-invasive Security The module does not claim any non-invasive security measures. Public Material – May be reproduced only in its original entirety (without revision).

9. Sensitive Security Parameter Management Security Use & Key/SSP Import/ Strength Function Cert Generation Establishment Storage Zeroisation related Name/Type Export Number keys Input via API Plaintext in in plaintext RAM until Power- AES encrypt AES Key 192 A4687 External N/A (Electronic function cycle host / decrypt Entry) completion Input via API Plaintext in AES encrypt AES-GCM in plaintext RAM until Power- / decrypt /

192 A4687 External N/A

Key (Electronic function cycle host generate / Entry) completion verify AES key wrapping; Input via API Plaintext in wraps AES 128 in plaintext RAM until Power- Unwrapped Wrapping 192 A4687 External N/A (Electronic function cycle host Key; Key 256 Entry) completion unwraps Wrapped Key Public Material

• May be reproduced only in its original entirety (without revision).

Security Use & Key/SSP Import/ Strength Function Cert Generation Establishment Storage Zeroisation related Name/Type Export Number keys Key Input via API Transport; wrapped Unwrapped (Electronic Wrapped in by AES Wrapped Entry) / RAM until PowerAny N/A External N/A2 Wrapping Key Output via function cycle host Key; API wrapped completion becoming (Electronic Unwrapped Output) Key Input via API Key in plaintext Transport; (Electronic Wrapped by Plaintext in Entry) / AES Unwrapped RAM until PowerAny N/A External Output via N/A Wrapping Key function cycle host API in Key; completion plaintext becoming (Electronic Wrapped Output) Key Module only wraps or unwraps the key, transporting the key would be performed by the calling application. Public Material

• May be reproduced only in its original entirety (without revision).

Security Use & Key/SSP Import/ Strength Function Cert Generation Establishment Storage Zeroisation related Name/Type Export Number keys Input via API in plaintext ECDSA (Electronic signature

112 Plaintext in

Entry) / generation; ECDSA 128 Internally per FIPS RAM until PowerA4687 Output via N/A Paired with Signing Key 192 186-4 function cycle host API in ECDSA

256 completion

plaintext Verification (Electronic Key Output) Input via API in plaintext ECDSA (Electronic

112 Plaintext in signature

128 Internally per FIPS RAM until Power- verification;

192 186-4 function cycle host Paired with

256 completion ECDSA

plaintext Signing Key (Electronic Output) Public Material

• May be reproduced only in its original entirety (without revision).

Security Use & Key/SSP Import/ Strength Function Cert Generation Establishment Storage Zeroisation related Name/Type Export Number keys EC DH; Paired with Input via API EC DH in plaintext Public Key; (Electronic Used with

112 Plaintext in

Entry) / Other Party EC DH 128 Internally per SP RAM until PowerA4687 Output via N/A EC DH Private Key 192 800-56Arev3 function cycle host API in Public Key;

256 completion

plaintext Establishes (Electronic Shared Output) Secret, TLS Pre-Master Secret Input via API EC DH; in plaintext Paired with (Electronic EC DH

112 Plaintext in

Entry) / Private Key; EC DH 128 Internally per SP RAM until PowerA4687 Output via N/A Establishes Public Key 192 800-56Arev3 function cycle host API in Shared

256 completion

plaintext Secret, TLS (Electronic Pre-Master Output) Secret Public Material

• May be reproduced only in its original entirety (without revision).

Security Use & Key/SSP Import/ Strength Function Cert Generation Establishment Storage Zeroisation related Name/Type Export Number keys EC DH; Used with EC DH

112 Input via API Plaintext in

Other Party Private Key;

128 in plaintext RAM until Power-

EC DH A4687 External N/A Establishes

192 (Electronic function cycle host

256 Entry) completion

Secret, TLS Pre-Master Secret DH; Paired with DH Input via API Public Key; in plaintext Used with (Electronic Plaintext in Other Party Entry) / DH Private Internally per SP RAM until Power- DH Public

112 A4687 Output via N/A

Key 800-56Arev3 function cycle host Key; API in completion Establishes plaintext Shared (Electronic Secret, TLS Output) Pre-Master Secret Input via API DH; Paired in plaintext with DH (Electronic Plaintext in Private Key; Entry) / DH Public Internally per SP RAM until Power- Establishes

112 A4687 Output via N/A

Key 800-56Arev3 function cycle host Shared API in completion Secret, TLS plaintext Pre-Master (Electronic Secret Output) Public Material

• May be reproduced only in its original entirety (without revision).

Security Use & Key/SSP Import/ Strength Function Cert Generation Establishment Storage Zeroisation related Name/Type Export Number keys DH; Used with DH Input via API Plaintext in Private Key; Other Party in plaintext RAM until Power- Establishes DH Public 112 A4687 External N/A (Electronic function cycle host Shared Key Entry) completion Secret, TLS Pre-Master Secret EC DH or DH; Established by EC DH Input via API Private Key, in plaintext EC DH (Electronic Public Key, Plaintext in Entry) / Other Party Shared At least KAS-ECC-SSC, RAM until PowerN/A External Output via EC DH Secret 112-bit KAS-FFC-SSC function cycle host API in Public Key, completion plaintext DH Private (Electronic Key, DH Output) Public Key, Other Party DH Public Key, Derives Derived Key Input via API Plaintext in At least in plaintext RAM until Power- Keyed HMAC Key A4687 External N/A 112-bit (Electronic function cycle host hashing Entry) completion Public Material

• May be reproduced only in its original entirety (without revision).

Security Use & Key/SSP Import/ Strength Function Cert Generation Establishment Storage Zeroisation related Name/Type Export Number keys Input via API RSA in plaintext signature (Electronic RSA Plaintext in generation;

Signature Internally per FIPS RAM until Power- Paired with

128 A4687 Output via N/A

Generation 186-4 function cycle host RSA

Key completion Signature plaintext Verification (Electronic Key Output) Input via API RSA in plaintext signature (Electronic RSA 80 Plaintext in verification; Entry) / Signature 112 Internally per FIPS RAM until Power- Paired with A4687 Output via N/A Verification 128 186-4 function cycle host RSA API in Key 150 completion Signature plaintext Generation (Electronic Key Output) Key Output via Plaintext in Derivation; API in Internally per SP RAM until Power- Derived Derived Key 112

• 512 A4687 plaintext N/A 800-56Cr2 function cycle host from (Electronic completion Shared Output) Secret TLS key TLS Pre- Input via API Plaintext in derivation; Master At least in plaintext KAS-ECC, KAS- RAM until PowerA4687 External Derives TLS Secret 112-bit (Electronic FFC function cycle host Master (other SSP) Entry) completion Secret Public Material
• May be reproduced only in its original entirety (without revision).

Security Use & Key/SSP Import/ Strength Function Cert Generation Establishment Storage Zeroisation related Name/Type Export Number keys TLS key derivation; Plaintext in Derived TLS Master Internally Derived At least RAM until Power- from TLS Secret A4687 via SP 800-135 N/A N/A 112-bit function cycle host Pre-Master (other SSP) KDF (TLS) completion Secret, Derives TLS Key Output via TLS; Plaintext in Internally Derived API in Derived At least RAM until PowerTLS Key A4687 via SP 800-135 plaintext N/A from TLS 112-bit function cycle host KDF (TLS) (Electronic Master completion Output) Secret Plaintext in RAM until DRBG Internally per SP DRBG PowerDRBG Seed 384 bits A4687 N/A N/A Seeding 800-90Ar1 uninstantiated cycle host material or module shutdown Plaintext in RAM until DRBG CTR_DRBG Internally per SP DRBG Power-

128 bits A4687 N/A N/A internal

V 800-90Ar1 uninstantiated cycle host state or module shutdown Public Material

• May be reproduced only in its original entirety (without revision).

Security Use & Key/SSP Import/ Strength Function Cert Generation Establishment Storage Zeroisation related Name/Type Export Number keys Plaintext in RAM until DRBG CTR_DRBG Internally per SP DRBG Power-

256 bits A4687 N/A N/A internal

Key 800-90Ar1 uninstantiated cycle host state or module shutdown Input via API Plaintext in CTR_DRBG in plaintext RAM until Power- DRBG Entropy 384 bits A4687 External N/A (Electronic function cycle host entropy Input Entry) completion Table 13

• SSP’s Entropy sources Minimum number of bits of entropy Details Use of a SP 800-90B compliant entropy source with at least 256 bits of security strength. Entropy is supplied to the Module via callback Shall provide module at least 384 bits of functions. The callback functions shall return an Passive Entropy entropy 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. Table 14
• Non-Deterministic Random Number Generation Specification Public Material
• May be reproduced only in its original entirety (without revision).

10. Self-tests FIPS 140-3 requires the module to perform self-tests to ensure the integrity of the module and the correctness of the cryptographic functionality. Some functions also require conditional tests during normal operation of the module. Self-tests can be requested on demand by power cycling the host platform. The module has a single error state, just called the error state. The failure of a self-test will cause the module to enter the error state. The module indicates this error state by providing the output status “Aborted”. The module can be recovered by terminating execution of the host program and reclamation by the host operating system. The supported tests are listed and described in this section.

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. The module implements the following pre-operational self-tests: Type Test Software Integrity Test HMAC-SHA-256 Table 15

• Pre-operational Self-tests

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. The module implements the following CASTs: Type Test ECDSA Signature Generation (P-256) ECSDA Signature Verification (P-256) RSA Signature Generation (2048 bits) RSA Signature Verification (2048 bits) SP800-56Arev3 KAS-ECC-SSC (P-256) SP800-56Arev3 KAS-FFC-SSC (2048 bits) AES CBC Encryption (128 bits) KAT AES CBC Decryption (128 bits) AES-GCM Encryption (128 bits) AES-GCM Decryption (128 bits) TLS v1.2 KDF TLS v1.3 KDF HKDF SHA-1 SHA2-256 SHA2-512 Public Material

• May be reproduced only in its original entirety (without revision).

Type Test HMAC-SHA2-256 CAST performed on DRBG, per SP800-90Arev1 Section 11.3 Table 16

• Conditional Algorithm Self-tests Conditional self-tests are run during the module’s operation. 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 reinitialized to clear the error and resume approved mode of operation. The module implements the following addition conditional self-tests: Type Test ECDSA Key Pair generation SP800-56Arev3 EC DH Key Pair generation Pair-wise Consistency Test SP800-56Arev3 DH Key Pair generation RSA Key Pair generation Table 17
• Conditional Self-tests Public Material
• May be reproduced only in its original entirety (without revision).

11. Life-Cycle Assurance 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 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 Android version of the module is also maintained in a git repository. Once the generic version is available, it is imported into the Android repository. As with the generic version, while development on the port is performed, it is handled in an internal git repository. Once it is ready for release it is published publicly to https://ci.android.com. The version number is determined by the Android repository build number (the numeric part of the manifest filename). Only the Android version of the module is released as a pre-compiled version (as opposed to a selfcompiled version. The Android manifest specifies all the configuration information needed to duplicate the build. Documentation that isn’t included in text files stored in git is maintained in Google Docs. All documents (whether spreadsheets, documents, presentations or anything else) are automatically version tracked along with the owner. Like git, Docs uses access control lists to control access to the design documentation for the module. All internal systems (both git and Google Docs) utilize the Google ID for login and access control over the repositories.

The module is open source. A Linux workstation with the following tools is required to build and compile the module: Target Tools Platform Android

• repo git repository tool 2.4.0 (https://gerrit.googlesource.com/git-repo)
• clang compiler version 16.0.0 (http://releases.llvm.org/download.html) Linux
• go programming language version 1.21.1 (https://golang.org/dl/) Public Material
• May be reproduced only in its original entirety (without revision).

• ninja build system version 1.11.1 (https://github.com/ninjabuild/ninja/releases)
• cmake version 3.27.4 (https://cmake.org/download/) Table 18
• Build Tools

The necessary Android build tools that are configured as part of the manifest. Running the envsetup.sh script will ensure that the proper environment is set to build the library for Android. Download the manifest from https://ci.android.com/builds/submitted/10050109/aosp_cf_arm64_phone-userdebug/latest by clicking the Download button. Verify the manifest using the following command: sha256sum ~/manifest_10050109.xml Manually validate that the output from the final command indicates the following expected hash values for this file: 5f8701016e3c39503e26c81e0facb6ab386319b94f5d2508288907e652060d92 manifest_10050109.xml The module can be obtained by issuing the following commands: mkdir aosp cd aosp ~/repo init -u https://android.googlesource.com/platform/manifest --depth 1 ~/repo init -m ~/manifest_10050109.xml ~/repo sync -q -c -j 50 To build the correct test tools (the test_fips components below, not the module), the following additional steps need to be followed: cd external/boringssl git fetch https://android.googlesource.com/platform/external/boringssl refs/changes/99/2775199/2 && git cherry-pick FETCH_HEAD git fetch https://android.googlesource.com/platform/external/boringssl refs/changes/28/2778328/2 && git cherry-pick FETCH_HEAD cd src/util/fipstools nano break-kat.go Change the first line of the file to be: //go:build ignore Save and exit Once downloaded, the module and testing components can be built using the following commands: croot . build/envsetup.sh lunch aosp_arm64-eng m clean m test_fips Public Material

• May be reproduced only in its original entirety (without revision).

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/boringssla430310d6563c0734ddafca7731570dfb683dc19.tar.xz or by issuing the following command: wget https://commondatastorage.googleapis.com/chromium-boringssl-fips/boringssla430310d6563c0734ddafca7731570dfb683dc19.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: 2d5339b756dbf1ceb4fdc4b1c8f19e32ded055292dc57827a6592f15ca9d359f By issuing the following command: sha256sum boringssl-a430310d6563c0734ddafca7731570dfb683dc19.tar.xz The tarball can be extracted using the following command: tar xJ < boringssl-a430310d6563c0734ddafca7731570dfb683dc19.tar.xz After the tarball has been extracted, the following commands will compile the module: cd boringssl mkdir build && cd build && cmake -GNinja -DCMAKE_TOOLCHAIN_FILE=${HOME}/toolchain -DFIPS=1 DCMAKE_BUILD_TYPE=Release .. ninja && ninja run_tests Retrieving Module name and version The following methods will provide the module name and versions:

• FIPS_module_name()
• BoringCrypto
• FIPS_version()
• 2023042800 Public Material
• May be reproduced only in its original entirety (without revision).

In the case of AES-GCM, the IV generation method is user-selectable, and the value can be computed in more than one manner. 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 SP800-52rev2 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. 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 SP800-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 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.

The module allows the use of 1024-bit RSA keys for legacy purposes including signature generation, which is disallowed in Approved mode as per NIST SP 800-131A. Therefore, the cryptographic operations with the Non-Approved key sizes will result in the module operating in Non-Approved mode. The elliptic curves utilized shall be the validated NIST-recommended curves and shall provide a minimum of 112 bits of encryption strength.

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 Non-Approved key generation methods or the converse. Public Material

• May be reproduced only in its original entirety (without revision).

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 algorithms are invoked. See Table 4 above for a list of the supported Approved algorithms. The nonApproved mode is entered when a non-Approved algorithm is invoked. See Table 6 for a list of nonApproved algorithms. 12. Mitigation of Other Attacks The module is not designed to mitigate against attacks that are outside of the scope of FIPS 140-3. Public Material

• May be reproduced only in its original entirety (without revision).

13. References and Standards The following Standards are referenced in this Security Policy: Abbreviation Full Specification Name FIPS 140-3 Security Requirements for Cryptographic modules FIPS 180-4 Secure Hash Standard (SHS) FIPS 186-4 Digital Signature Standard (DSS) FIPS 197 Advanced Encryption Standard FIPS 198-1 The Keyed-Hash Message Authentication Code (HMAC) IG Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program SP 800-38A Recommendation for Block Cipher Modes of Operation: Three Variants of Ciphertext Stealing for CBC Mode SP 800-38D Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC SP 800-38F Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping SP 800-56Arev3 Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography SP 800-90Ar1 Recommendation for Random Number Generation Using Deterministic Random Bit Generators SP 800-90B Recommendation for the Entropy Sources Used for Random Bit Generation SP 800-131Ar2 Transitioning the Use of Cryptographic Algorithms and Key Lengths SP 800-133r2, Recommendation for Cryptographic Key Generation [133] SP 800-135rev1 Recommendation for Existing Application-Specific Key Derivation Functions Table 19 – References and Standards
14. Acronyms Acronym Definition ADB Android Debug Bridge AES Advanced Encryption Standard API Application Programming Interface CAVP Cryptographic Algorithm Validation Program CBC Cipher-Block Chaining CCCS Canadian Centre for Cyber Security CFB Cipher Feedback CKG Cooperative Key Generation CMVP Crypto Module Validation Program CO Cryptographic Officer CPU Central Processing Unit CRNGT Continuous Random Number Generator Test CSP Critical Security Parameter CTR Counter-mode CVL Component Validation List Public Material – May be reproduced only in its original entirety (without revision).

Acronym Definition DEP Default Entry Point DES Data Encryption Standard DH Diffie-Hellman DRBG Deterministic Random Bit Generator DSS Digital Signature Standard EC Elliptic Curve ECB Electronic Code Book ECC Elliptic Curve Cryptography EC DH Elliptic Curve Diffie-Hellman ECDSA Elliptic Curve Digital Signature Authority EMC Electromagnetic Compatibility EMI Electromagnetic Interference FCC Federal Communications Commission FIPS Federal Information Processing Standards GCM Galois/Counter Mode GMAC Galois Message Authentication Code GPC General Purpose Computer GPOS General Purpose Operating System HMAC Key-Hashed Message Authentication Code IETF Internet Engineering Task Force IG Implementation Guidance IV Initialization Vector KAS Key Agreement Scheme KAT Known Answer Test KDF Key Derivation Function KTS Key Transport Scheme KW Key Wrap KWP Key Wrap with Padding LLC Limited Liability Company MAC Message Authentication Code MD4 Message Digest algorithm MD4 MD5 Message Digest algorithm MD5 N/A Not-Applicable NIST National Institute of Standards and Technology NDRNG Non-Deterministic Random Number Generator NVLAP National Voluntary Lab Accreditation Program OFB Output Feedback PAA Processor Algorithm Accelerator RAM Random Access Memory RFC Request For Comment RSA Rivest Shamir Adleman Public Material

• May be reproduced only in its original entirety (without revision).

Acronym Definition SHA Secure Hash Algorithm SHS Secure Hash Standard SP Special Publication SSL Secure Socket Layer TCBC Triple-DES Cipher-Block Chaining TDEA Triple Data Encryption Algorithm TECB Triple-DES Electronic Code Book TLS Transport Layer Security Triple-DES Triple Data Encryption Standard Table 20

• Acronyms Public Material
• May be reproduced only in its original entirety (without revision).