Samsung BoringCrypto Android

Certificate

Approved Algorithms (28)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for Samsung BoringCrypto Android
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>On-Demand 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["Some services may process<br/>input 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["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 Samsung BoringCrypto Android
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>On-Demand Self-Test<br/>Show Status</i><br/>src: securityPolicy.services"]
    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 clueHigh;
  class C5,C6 clueLow;

Security Policy, page by page

Samsung BoringCrypto Android Software Version: 2022061300 Date: 09/18/2025 Prepared by: www.acumensecurity.net Samsung Electronics Co., Ltd. Version 1.1 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-3 program. The NVLAP accredits independent testing labs to perform FIPS 140-3 testing; the CMVP validates modules meeting FIPS 140-3 validation. Validated is the term given to a module that is documented and tested against the FIPS 140-3 criteria. 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 Samsung BoringCrypto Android from Samsung Electronics Co., Ltd. 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 Samsung BoringCrypto Android 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. Samsung Electronics Co., Ltd. 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. Samsung Electronics Co., Ltd. Version 1.1 Public Material
• May be reproduced only in its original entirety (without revision).

1. This document describes Samsung Electronics Co., Ltd.’s cryptographic module Security Policy (SP) for the Samsung BoringCrypto Android (Software version: 2022061300) 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 is a software module and has a Multi-Chip Stand Alone embodiment. 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: N/A N/A N/A Table 1 - Security Levels Samsung Electronics Co., Ltd. Version 1.1 Public Material

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

2. Cryptographic Module Specification Samsung BoringCrypto Android module by Samsung Electronics Co., Ltd. is an general-purpose cryptographic library which provides approved cryptographic algorithms to serve BoringSSL and other user-space applications. The module is intended for use in environment specified in Table 2 below and any general-purpose environment that requires cryptographic primitives. The Tested Operational Environment’s Physical Perimeter (TOEPP) of the module is the physical perimeter of the tested environment, which is listed in Table 2 below. The module is a software module and has a Multi-Chip Stand Alone embodiment. The installation instructions are provided in Section 11 of this document. The boundary of the module is defined as a single object file, bcm.o. The module version is: 2022061300. The module was tested on the following operational environments: # Samsung Electronics Co., Ltd. Version 1.1 Public Material

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

Table 2 - Tested Operational Environments Table 3 below lists all the approved algorithms implemented in the module: Samsung Electronics Co., Ltd. Version 1.1 Public Material

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

N/A There are algorithms that have been CAVP-tested on the same certificate but are not used by any approved service of the module Only the algorithms, modes/methods, and key lengths/curves/moduli shown in this table are used by an approved service of the module. No parts of this protocol, other than the approved cryptographic algorithms and the KDFs, have been tested by the Samsung Electronics Co., Ltd. Version 1.1 Public Material

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

Table 3 - Approved Algorithms Samsung Electronics Co., Ltd. Public Material

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

Table 5 - Non-Approved Algorithms Not Allowed in the Approved Mode of Operation Figure 1 - Samsung BoringCrypto Android boundary Samsung Electronics Co., Ltd. Version 1.1 Public Material

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

AES GCM encryption and decryption are used in the context of the TLS protocol version 1.2 (compliant to Scenario 1a in FIPS 140-3 IG C.H). The module is compliant with NIST SP 800-52 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, users of the module must not utilize GCM with an externally generated IV. 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 implements the KDF TLS 1.2, and other cryptographic primitives used in TLS 1.2, but does not implement the TLS 1.2 protocol itself.

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 SP800-131Arev2. Therefore, 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.

The module supports two modes of operation: Approved and Non-approved. The module will be in approved mode when all self-tests have completed successfully, and only Approved algorithms are invoked. See Table 4 above for a list of the supported Approved algorithms. The non-Approved mode is entered when a non-Approved algorithm is invoked. See Table 6 for a list of non-Approved algorithms. Samsung Electronics Co., Ltd. Version 1.1 Public Material

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

3. Cryptographic Module Interfaces functions. Table 6 - Ports and Interfaces The module does not implement a power input interface or a control output interface. 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. Samsung Electronics Co., Ltd. Version 1.1 Public Material

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

4. Roles, Services, and Authentication 4.1 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 operator is allowed, and no concurrent operators are allowed. 4.2 The module does not support operator authentication. 4.3 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 below: N/A N/A N/A Table 7 - Roles, Service Commands, Input and Output Approved services are listed in Table
5. 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. Samsung Electronics Co., Ltd. Version 1.1 Public Material – May be reproduced only in its original entirety (without revision).

Samsung Electronics Co., Ltd. W, E W, E W, E N/A N/A G, E G, R W, E G, W, E G, W, E Version 1.1 Public Material

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

D.G W, E G, W, E G W, E G, E G, W, E G, W, E N/A N/A N/A N/A N/A N/A Z N/A N/A N/A Table 8 - Approved Services Samsung Electronics Co., Ltd. Version 1.1 Public Material

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

Non-Approved Services are listed in the Table 9 below: Table 9 - Non-Approved Services Samsung Electronics Co., Ltd. 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-SHA2-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. Please refer to Section 11.1 for instructions on compiling the source code into executable. 5.1 Module Format 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 approved 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 specific security rules, settings or restrictions to the configuration of the operational environment applies to the module. The module is designed to ensure that all the self-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. Samsung Electronics Co., Ltd. Version 1.1 Public Material – May be reproduced only in its original entirety (without revision).

9. Sensitive Security Parameter Management All the SSPs are zeroized implicitly when host platform is restarted. The various SSPs used by the module are listed in Table 10 below: As specified in Section 2.1.1, usage of externally generated IV is only allowed for AES-GCM decryption in the approved mode of operation. Samsung Electronics Co., Ltd. Version 1.1 Public Material

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

HMAC-SHA2224, HMACSHA2-256, HMAC-SHA2384, HMACSamsung Electronics Co., Ltd. Version 1.1 Public Material

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

N/A N/A N/A Samsung Electronics Co., Ltd. Version 1.1 Public Material

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

N/A N/A N/A N/A N/A N/A N/A N/A Powercycle N/A N/A Powercycle Table 10

• SSP Samsung Electronics Co., Ltd. Version 1.1 Public Material
• May be reproduced only in its original entirety (without revision).

Table 11 - Non-Deterministic Random Number Generation Specification 10. Self-Tests ISO/IEC 19790 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. The self-tests can be requested on demand by power cycling the host platform. The module has a single error state, which is called the error state. This state is entered upon failure of a self-test. The module indicates this error state by providing the output status “*** KAT failed” where *** is the algorithm name (example: ECDSA-sign KAT failed). 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 and further reboots of the host platform. 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:

• Software Integrity Test (HMAC-SHA2-256)

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. Samsung Electronics Co., Ltd. Version 1.1 Public Material

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

The module implements the following CASTs:

• ECDSA Signature Generation KAT (P-256)
• ECSDA Signature Verification KAT (P-256)
• RSA Signature Generation KAT (2048 bits, PKCSv1.5)
• RSA Signature Verification KAT (2048 bits, PKCSv1.5)
• SP800-56Arev3 KAS-ECC KAT (P-256)
• AES CBC Encryption KAT (128 bits)
• AES CBC Decryption KAT (128 bits)
• AES-GCM Encryption KAT (128 bits)
• AES-GCM Decryption KAT (128 bits)
• CAST, performed on DRBG, per SP800-90Arev1 Section 11.3 (Instantiate, Generate, Reseed)
• TLS v1.2 KDF KAT
• SHA-1 KAT
• SHA2-256 KAT
• SHA2-512 KAT
• HMAC-SHA2-256 KAT 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 conditional pairwise consistency tests. The below PCTs are executed whenever a new key pair is generated:
• ECDSA Pairwise Consistency Test
• EC DH Pairwise Consistency Test
• RSA Pairwise Consistency Test Samsung Electronics Co., Ltd. Version 1.1 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. There are no maintenance requirements applicable. 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/fips20220613/crypto/fipsmodule/FIPS.md (note this still mentions 140-2, but the information there is the same).

The module is open source. A Linux workstation with the following tools is required to build and compile the module: Android 13 git 2.23 or later (https://git-scm.com/download/linux) base64, curl, sha256sum (these should come with the Linux installation)

Once a Linux workstation with the above tools has been obtained, issue the following commands to download and verify repo: curl 'https://gerrit.googlesource.com/git-repo/+/e778e57f11/repo?format=TEXT' | base64 -d > ~/repo chmod u+x ~/repo gpg --recv-key 8BB9AD793E8E6153AF0F9A4416530D5E920F5C65 curl https://storage.googleapis.com/git-repo-downloads/repo.asc | gpg --verify - ~/repo Download the manifest from https://ci.android.com/builds/submitted/8918218/aosp_arm64userdebug/latest/manifest_8918218.xml by clicking the Download button. Verify the manifest using the following command: Sha256sum ~/manifest_8918218.xml Manually validate that the output from the final command indicates the following expected hash values for this file: fae7a587167b3b3ebdf5b2c53335a1d1827beddcf23d2788d07f3bbbe9ff7182 manifest_8918218.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_8918218.xml ~/repo sync -q -c -j 20 Samsung Electronics Co., Ltd. Version 1.1 Public Material

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

Once downloaded, the module can be built using the following command: . build/envsetup.sh lunch aosp_arm64-eng m clean m test_fips

The following methods will provide the module name and versions:

• FIPS_module_name()
• BoringCrypto
• FIPS_version()
• 2022061300 Samsung Electronics Co., Ltd. Version 1.1 Public Material
• May be reproduced only in its original entirety (without revision).

12. Mitigation of Other Attacks The module is not designed to mitigate attacks which are outside of the scope of FIPS 140-3. Samsung Electronics Co., Ltd. Version 1.1 Public Material

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

References and Standards The following Standards are referenced in this Security Policy: Abbreviation FIPS 140-3 FIPS 180-4 FIPS 186-4 FIPS 197 FIPS 198-1 IG SP 800-38A SP 800-38C SP 800-38D SP 800-38F SP 800-52 SP 800-56A SP 800-90A SP 800-131A SP 800-133 SP 800-135 Full Specification Name Security Requirements for Cryptographic modules Secure Hash Standard (SHS) Digital Signature Standard (DSS) Advanced Encryption Standard The Keyed-Hash Message Authentication Code (HMAC) Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program Recommendation for Block Cipher Modes of Operation: Three Variants of Ciphertext Stealing for CBC Mode Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography Recommendation for Random Number Generation Using Deterministic Random Bit Generators Transitioning the Use of Cryptographic Algorithms and Key Lengths Recommendation for Cryptographic Key Generation Recommendation for Existing Application-Specific Key Derivation Functions Samsung Electronics Co., Ltd. Version 1.1 Public Material

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

Acronyms Acronym AES API CAVP CBC CCCS CFB CKG CMVP CO CRNGT CSP CTR DES DH DRBG DSS EC ECB ECC EC DH ECDSA FIPS GCM GMAC GPC HMAC IG IV KAS KAT KDF KW KWP LLC MAC MD4 MD5 N/A NIST Definition Advanced Encryption Standard Application Programming Interface Cryptographic Algorithm Validation Program Cipher-Block Chaining Canadian Centre for Cyber Security Cipher Feedback Cooperative Key Generation Crypto Module Validation Program Cryptographic Officer Continuous Random Number Generator Test Critical Security Parameter Counter-mode Data Encryption Standard Diffie-Hellman Deterministic Random Bit Generator Digital Signature Standard Elliptic Curve Electronic Code Book Elliptic Curve Cryptography Elliptic Curve Diffie-Hellman Elliptic Curve Digital Signature Authority Federal Information Processing Standards Galois/Counter Mode Galois Message Authentication Code General Purpose Computer Key-Hashed Message Authentication Code Implementation Guidance Initialization Vector Key Agreement Scheme Known Answer Test Key Derivation Function Key Wrap Key Wrap with Padding Limited Liability Company Message Authentication Code Message Digest algorithm MD4 Message Digest algorithm MD5 Not-Applicable National Institute of Standards and Technology NVLAP National Voluntary Lab Accreditation Program Samsung Electronics Co., Ltd. Version 1.1 Public Material

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

OFB PAA RAM RFC RSA SHA SHS SP SSL TLS Triple-DES Output Feedback Processor Algorithm Accelerator Random Access Memory Request For Comment Rivest Shamir Adleman Secure Hash Algorithm Secure Hash Standard Special Publication Secure Socket Layer Transport Layer Security Triple Data Encryption Standard Samsung Electronics Co., Ltd. Version 1.1 Public Material

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

Referenced URLs

• www.acumensecurity.net
• https://csrc.nist.gov/projects/cryptographic-module-validation-program
• https://boringssl.googlesource.com/boringssl
• https://boringssl.googlesource.com/boringssl.git/+/refs/heads/fips-
• https://git-scm.com/download/linux
• https://gerrit.googlesource.com/git-repo/+/e778e57f11/repo?format=TEXT
• https://storage.googleapis.com/git-repo-downloads/repo.asc
• https://ci.android.com/builds/submitted/8918218/aosp_arm64-
• https://android.googlesource.com/platform/manifest