BCM58202B0

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for BCM58202B0
  %% 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>Firmware Load<br/>Recovery</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>status output<br/>UnAuth</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>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."]
    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?"]
    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"]
    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
  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,C6 clue;
  class I2,I3,I6 infer;
  class R2,R3,R6 risk;
  class E2,E3,E6 evidence;

flowchart LR
  %% Deterministic clue tier for BCM58202B0
  %% 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>Firmware Load<br/>Recovery</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>status output<br/>UnAuth</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>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,C6 clueLow;

Security Policy, page by page

Broadcom, Inc. BCM58202B0 Document Version: 1.2 Date: April 09, 2025 Broadcom Public Material – May be reproduced only in its original entirety (without revision).

Broadcom Public Material – May be reproduced only in its original entirety (without revision).

this module meets the requirements as specified in FIPS PUB 140-3 (Federal Information Processing Standards Publication 140-3) for an overall Security Level 3 module.

The FIPS 140-3 security levels for the Module are as follows from Table 1: Table 1: Security Levels

The Module is a highly integrated SoC (System on a Chip). It is marketed with part number BCM58202PB0KFBG10 and is ideally suited for end point security protection applications. Broadcom Public Material – May be reproduced only in its original entirety (without revision).

2 – Cryptographic Module Specification

Purpose and Use: The Module is intended for use by US Federal agencies or other markets that require FIPS 140-3 validated cryptographic based security systems to protect sensitive information, access, usage, of computer, telecommunication systems, and property. The Module is intended to be used in commercial personal computers, point of sales terminals, access control devices in physically or electronically access restricted areas. Module Type: Hardware Module Embodiment: SingleChip Cryptographic Boundary: The physical form of the Module is depicted in Figure 1. The Module is a single-chip embodiment. The cryptographic module is encapsulated in an opaque and tamper resistant package material. The cryptographic boundary is the outer perimeter of the IC packaging. Figure 1

• [Model 1] Broadcom Public Material
• May be reproduced only in its original entirety (without revision).

Tested Module Identification

• Hardware: BCM58202B0 cryptographic module is tested with the following configuration. 2.1 Table 2: Tested Module Identification
• Hardware

There were no components that were excluded from the cryptographic boundary. Modes List and Description: Table 3: Modes List and Description does not support a non-Approved mode of operation. The module cannot be configured to operate in a non-compliant state. The Cryptographic Officer (CO) can confirm the Approved Broadcom Public Material – May be reproduced only in its original entirety (without revision).

In addition, the CO can confirm they are using the appropriate version of the module by consulting the output of the “Get info” service: Global Indicator (4) Global Indicator: 00 00 ff ff SBL Version (2) SBL Version: 01 01 SBI Version (2) SBI Version: 01 00 AAI Version (2) AAI Version: 02 01 CHIP Version: BCM58202PB0KFBG10 BCM58202B0 is configured during manufacturing to operate in the Approved mode. The CO is responsible for confirming the appropriate versions of the SBI and AAI are loaded; no additional configuration is required.

Approved Algorithms: The Module implements the Approved cryptographic algorithms listed in the table below. 4) Broadcom Public Material – May be reproduced only in its original entirety (without revision).

4) 4) 4) Table 4: Approved Algorithms KAS [56Ar3] - Per [IG] D.F Scenario 2 path (2), compliant key agreement scheme where testing is performed end-to-end for the shared secret computation and a KDA compliant with SP80056Cr2 without key confirmation. Vendor-Affirmed Algorithms: The Module implements the Vendor Affirmed cryptographic algorithms listed. Broadcom Public Material – May be reproduced only in its original entirety (without revision).

[D.H] Table 5: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: N/A for this module. Non-Approved, Allowed Algorithms with No Security Claimed: N/A for this module. Non-Approved, Not Allowed Algorithms: N/A for this module.

Broadcom Public Material – May be reproduced only in its original entirety (without revision).

Broadcom Public Material – May be reproduced only in its original entirety (without revision).

Broadcom Public Material – May be reproduced only in its original entirety (without revision).

Table 6: Security Function Implementations

The module does not have any algorithm specific information.

Table 7: Entropy Certificates The Module uses the following entropy sources: Table 8: Entropy Sources The entropy source produces 4 bits of entropy per 32 bit sample. When instantiating the DRBG, the module will collect a total of 3072 bits from the entropy source, which has a total of 384 bits of entropy. Per SP800-90Arev1, the module must provide security_strength bits of entropy (i.e., 256-bits) plus another security_strength/2 (i.e., 128-bits) to instantiate a CTR_DRBG to a security strength of 256 bits.

For Key Generation methods, see Section 2.6 Security Function Implementations above. Broadcom Public Material – May be reproduced only in its original entirety (without revision).

Key Agreement Information For Key Establishment methods, see Section 2.6 Security Function Implementations above. The module supports KAS-ECC per SP800-56Ar3 using the Ephemeral Unified scheme with the NISTrecommended curve P-256, as tested under CAVP Cert. #A3751. The module employs the SP 800-56Cr2 OneStepKDF, which was validated under CAVP Cert. #A3752. No key confirmation is supported. Key and seed generation is performed in compliance with NIST SP 800-133r2, Section 4, per 140-3 IG D.H without any post-processing. ECDSA Key Generation was tested under CAVP Cert. #A3751 using extra random bits, whereby an extra 64 bits are generated from the Approved DRBG (CAVP Cert. #A3753. Full public key validation is performed according to SP 800-56Ar3, Section 5.6.2.3.3, on both the generated public key, as well as any received public key. All temporary values used during the key agreement process are zeroized after the shared key is established. Key Transport Information For Key Transport methods, see Section 2.6 Security Function Implementations above.

The module does not implement any Industry Protocols> Broadcom Public Material – May be reproduced only in its original entirety (without revision).

The Module’s ports and associated defined logical interface categories are listed below. below contains several BCM58202B0 pins. Unused Interface Groups will be marked as “Disabled” because they are disabled by the cryptographic module. The Module does not provide control output to other cryptographic modules or peripherals performing any cryptographic operations. Table 9: Ports and Interfaces Broadcom Public Material – May be reproduced only in its original entirety (without revision).

Note: The module does not support Control Output. Broadcom Public Material – May be reproduced only in its original entirety (without revision).

Authentication is accomplished via a 256-bit ECDSA-based signature verification process using KOP-PUB. During the manufacturing process, the ECDSA private key, KDI-EC-PRIV, is loaded into SOTP of the Module and the corresponding public key, KDI-EC-PUB, resides in SRAM. KDI-ECPUB is used to authenticate the module to the operator during the establishment of a secure session. session does not persist across power cycles. The Cryptographic Officer must be authenticated to establish a secure session before any cryptographic services are rendered. In addition to the CO, the Module supports services which do not require authentication, listed as UA in Approved Services table. The Module does not support a maintenance role or bypass capability. The Module does not support concurrent operators. The role of the CO is authenticated via the establishment of a mutually authenticated KAS session with ECDSA-based signatures. CO authentication is not carried over a terminated secure session or power cycle. A new secure session requires a complete CO authentication process. Table 10: Authentication Methods

The Module supports a single distinct operator role, the Cryptographic Officer (CO). Broadcom Public Material – May be reproduced only in its original entirety (without revision).

The Roles Table below lists all operator roles supported by the Module. The Module does not support concurrent operators. The CO’s Public Key is installed in the SBI. It is protected with the SBI signature. SBI is also integrity protected with a CRC32 checksum. Only one CO public key is present in the SBI. The BCM58202B0 Cryptographic Module supports a single operator role: Cryptographic Officer. Only the authorized operator can establish a secure session with the cryptographic module. The cryptographic module implements identity-based operator authentication to allow only the authorized operator to Authentication is accomplished via a 256-bit ECDSA-based signature verification process. A single 256-bit ECDSA public key is embedded in the SBI. The 256-bit ECDSA public key is used to authenticate the CO during the establishment of a secure session between the module and the CO on the external host system. Table 11: Roles

All approved services implemented by the Module are listed in the table below: The SSPs modes of access shown in the table below are defined as:

Broadcom Public Material – May be reproduced only in its original entirety (without revision).

Broadcom Public Material – May be reproduced only in its original entirety (without revision).

Broadcom Public Material – May be reproduced only in its original entirety (without revision).

ha PRIV: G,E Broadcom Public Material – May be reproduced only in its original entirety (without revision).

Broadcom Public Material – May be reproduced only in its original entirety (without revision).

All approved services implemented by the Module are listed in the table below: NOTE: There are no Non-Approved services available.

The module supports external firmware loads per IG 10.3.F, Additional Comment #3A. Both the Secure Boot Image (SBI) and Authenticated Application Image (AAI) are externally loaded into the module during initialization at every power-on. Each externally loaded image must have a valid ECDSA or RSA signature verified before the image is accepted. The hash of the public keys used to validate the candidate images are loaded prior to the firmware images themselves. The public keys are embedded in the SBI and AAI headers respectively. The hash of the embedded keys are validated against the preloaded hash values. Broadcom Public Material – May be reproduced only in its original entirety (without revision).

The Module is composed of the following firmware components:

• SBL : Incorporated in on-chip ROM, immutable
• SBI : Secure Boot Image, in binary, validated by SBL
• AAI : Authenticated Application Image, in binary, validated by SBI SBI and AAI are loaded from companion external flash at every power-on; they are both signed, and CRC protected in the companion external flash device when the Module is powered down. SBI and AAI installation in the companion flash memory is performed during manufacturing. The module will automatically retrieve the SBI and AAI images for validation and load. Upon powering up of the Module, SBL validates the SBI signature before SBI execution and SBI validates AAI signature before AAI is loaded and executes. SBI and AAI perform a CRC-32 integrity test of their respective executable image. SBI is validated with an ECDSA P-384 signature upon load and AAI is validated with an RSA 2048-bit signature upon load. Once validated, both SBI and AAI perform a 32-bit CRC integrity check upon execution.

The operator can initiate the integrity test on demand by power cycling the Module. Broadcom Public Material – May be reproduced only in its original entirety (without revision).

Type of Operational Environment: Limited How Requirements are Satisfied: The Module has a limited operational environment under the FIPS 140-3 definitions. The Module includes a firmware load service using ECDSA and RSA to support necessary updates. Firmware versions validated to FIPS 140-3 will be explicitly identified on a validation certificate issued by the CMVP. Any firmware not identified in this Security Policy does not constitute the Module defined by this Security Policy or covered by this validation. Broadcom Public Material – May be reproduced only in its original entirety (without revision).

The BCM58202B0 Cryptographic Module is a single chip device offering the following physical security mechanisms:

• The module package is of production-grade packaging material and uses standard passivation techniques.
• The module is enclosed in a hard, opaque, tamper resistant and evident enclosure.
• CO can periodically examine the device package for visual evidence of tampering like, scratch marks.
• There is no opening on the package for service or ventilation purposes.
• No tamper-evident seal is required on the Module package.
• Asserting the MANU_DEBUG signal will zeroize all SSPs in non-volatile memory (OTP), overwriting them with 1s. Zeroisation is executed in hardware and complete in microseconds. Table 13: Mechanisms and Actions Required The nominal operating temperature of the module is 0C to 70C. The nominal voltage range is 3.0V to 3.6V. Table 14: EFP/EFT Information

Broadcom Public Material – May be reproduced only in its original entirety (without revision).

Table 15: Hardness Testing Temperatures Broadcom Public Material – May be reproduced only in its original entirety (without revision).

At present, SP800-140F does not define any non-invasive attack mitigation methods and as such, this section is not applicable. Broadcom Public Material – May be reproduced only in its original entirety (without revision).

Table 17: SSP Input-Output Methods

Table 18: SSP Zeroization Methods Broadcom Public Material – May be reproduced only in its original entirety (without revision).

All usage of these SSPs by the Module are described in the services detailed in Section 4.3 Broadcom Public Material – May be reproduced only in its original entirety (without revision).

Name DRBG-EI and Seed DRBG-State

Input - Output

Storage RAM:Plaintext RAM:Plaintext

Storage Duration Until use completes Until use completes

Zeroization Z2 Z2

Related SSPs DRBG-State:Initializes DRBG-EI and Seed:Derived From KKAS-PRIV:Generates KKAS-PUB:Generates KAPP-AES:Generates KAPP-HMAC:Generates KAPP-PRIV:Generates KAPP-PUB:Generates

Table 19: SSP Table 1 Broadcom Public Material – May be reproduced only in its original entirety (without revision).

Table 20: SSP Table 2 Broadcom Public Material – May be reproduced only in its original entirety (without revision).

The Module performs self-tests to ensure the proper operation of the Module. Per FIPS 140-3 these are categorized as either preoperational self-tests or conditional self-tests. Conditional self–tests are periodically performed by the Module every 10 minutes or by power cycling the Module. The Module accepts one service request at a time. The Module will postpone periodic self-testing while critical operations are in progress. The Module will process a service request after the periodic self-test in progress. The Module logs the latest three (3) self-test errors in the Module’s persistent registers, preserved across reset cycles. The CO can consult the error log by invoking Get Error Log service. The Module performs the following pre-operational self-tests in table below Table 21: Pre-Operational Self-Tests

The Module performs the following conditional self-tests in the table below Broadcom Public Material – May be reproduced only in its original entirety (without revision).

Broadcom Public Material – May be reproduced only in its original entirety (without revision).

Broadcom Public Material – May be reproduced only in its original entirety (without revision).

Table 22: Conditional Self-Tests Broadcom Public Material – May be reproduced only in its original entirety (without revision).

Table 23: Pre-Operational Periodic Information Broadcom Public Material – May be reproduced only in its original entirety (without revision).

Table 24: Conditional Periodic Information Conditional self–tests are periodically performed by the Module every 10 minutes. Broadcom Public Material – May be reproduced only in its original entirety (without revision).

Self-tests can be initiated by power cycling or issuing a reset to the Module.

The Module is manufactured and fully tested in secure environments under authorized access control. The Module is installed in the final product with the companion external flash device in the manufacturing facility. The CO must ensure the appropriate versions of the SBI and AAI are loaded in the companion external flash device upon first power up of the Module using the “Get Info” service. The CO should also visually inspect the Module for tamper evidence. The Module is a single chip device that does not provide any maintenance service access. At the end of life of the Module, all CSPs shall be zeroised by setting MANU_DEBUG pin high and Installation and Initialization: The following steps must be performed in order to securely install, initialize, and start up the BCM58202B0 cryptographic module in the FIPS 140-3 Approved mode of operation: The Module should be installed in the final product with the companion external flash device in the manufacturing facility. The manufacturing process includes a Module customization step which installs SBI and AAI in the module, initializes the Module with per device unique AES and HMAC keys, binding the Module and the flash device. Broadcom Public Material – May be reproduced only in its original entirety (without revision).

The CO must ensure the appropriate versions of the SBI and AAI are loaded in the companion external flash device upon first power up of the Module using the “Get Info” service. The CO should also visually inspect the Module for tamper evidence. Delivery: The CO must ensure the appropriate versions of the SBI and AAI are loaded in the companion external flash device upon first power up of the Module using the “Get Info” service. The CO should also visually inspect the Module for tamper evidence.

Before the Module is installed in the end product, the module package should be inspected for integrity and to be free of any tamper evidence. The Module should be installed in the final product with the companion external flash device in a secure manufacturing facility. The manufacturing process includes a Module customization step which installs SBI and AAI in the module. To ensure the appropriate versions of the SBI and AAI are loaded in the companion external flash device, execute the “Get Info” service upon first power up of the Module. Verify the expected versions are reported. While the Module is in service in the end product, it is recommended to perform a visual inspection of the Module at least every 6 months to ensure that the Module package is still intact and void of any tamper evidence. “Get Info” service should be run to ensure that the correct SBI and AAI versions are in operation. Upon the termination of service of the Module, all critically sensitive parameters in the Module should be zeroized by setting the MANU_DEBUG pin high and power cycling the Module. Then, the Module can be disposed of responsibly.

Same as above for Administration Guidance.

Rules of Operation

1. The Module provides one distinct operator roles: Cryptographic Officer.
2. The Module provides identity-based authentication.
3. The Module clears previous authentications on power cycle. Broadcom Public Material – May be reproduced only in its original entirety (without revision).

4. An operator does not have access to any cryptographic services prior to assuming an authorized role.
5. The Module allows the operator to initiate power-up self-tests by power cycling power or resetting the Module.
6. All self-tests do not require any operator action.
7. Data output is inhibited during key generation, self-tests, zeroization, and error states.
8. Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of the Module.
9. There are no restrictions on which keys or SSPs are zeroized by the zeroization service.
10. The Module does not support concurrent operators.
11. The Module does not support a maintenance interface or role.
12. The Module does not support manual SSP establishment method.
13. The Module does not have any proprietary external input/output devices used for entry/output of data.
14. The Module does not enter or output plaintext CSPs.
15. The Module does not output intermediate key values.
16. The Module does not provide bypass services or ports/interfaces.

The Module is a single chip device that does not provide any maintenance service access.

At the end of life of the Module, all CSPs shall be zeroised by setting MANU_DEBUG pin high and power cycling the Module.

The Module does not implement any mitigation method against other attacks. References and Definitions The following standards are referred to in this Security Policy. Broadcom Public Material – May be reproduced only in its original entirety (without revision).

References Broadcom Public Material – May be reproduced only in its original entirety (without revision).

Acronyms and Definitions Broadcom Public Material – May be reproduced only in its original entirety (without revision).