AMD ASP Cryptographic CoProcessor ("Raphael")

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for AMD ASP Cryptographic CoProcessor ("Raphael")
  %% 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>update<br/>Recovery</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>Status Output</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>HTTPS<br/>no library/version identified</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>bootloader</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
    R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
    R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
    R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E2["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C5 --> I5 --> R5 --> E5
  C6 --> I6 --> R6 --> E6
  classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
  classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
  classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
  class C2,C3,C5,C6 clue;
  class I2,I3,I5,I6 infer;
  class R2,R3,R5,R6 risk;
  class E2,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for AMD ASP Cryptographic CoProcessor ("Raphael")
  %% 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>update<br/>Recovery</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>Status Output</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>HTTPS<br/>no library/version identified</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>bootloader</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C2,C3,C5,C6 clueLow;

Security Policy, page by page

AMD ASP Cryptographic CoProcessor ("Raphael") version: bc0d0346FIPS001 Document Version: 1.2 Last update: 2024-12-02 Prepared for: Advanced Micro Devices (AMD)

Santa Clara, CA 95054 www.amd.com Prepared by: atsec information security corporation

4516 Seton Center Parkway, Suite 250

Austin, TX 78759 © 2023 Advanced Micro Devices (AMD), atsec information security.

© 2023 Advanced Micro Devices (AMD), atsec information security.

3 of 25

This section is informative to the reader to reference cryptographic services and other services of AMD ASP Cryptographic CoProcessor ("Raphael") (the “module”) from Advanced Micro Devices (AMD) (the “vendor”). Only the components listed in Section 2.1 are subject to the FIPS 140-3 validation. The CMVP (Cryptographic Module Validation Program) makes no statement as to the correct operation of the module or the security strengths of the generated keys (when supported) if the specific operational environment is not listed on the validation certificate. was further consolidated into this document by atsec information security together with other vendor-supplied documentation. In preparing the Security Policy document, the laboratory formatted the vendor-supplied documentation for consolidation without altering the technical statements therein contained. The further refining of the Security Policy document was conducted iteratively throughout the conformance testing, wherein the Security Policy was submitted to the vendor, who would then edit, modify, and add technical contents. The vendor would also supply additional documentation, which the laboratory formatted into the existing Security Policy, and resubmitted to the vendor for their final editing.

Table 1 describes the individual security areas of FIPS 140-3, as well as the security levels of those individual areas. Table 1 - Security Levels © 2023 Advanced Micro Devices (AMD), atsec information security.

5 of 25

Purpose and Use: The AMD ASP Cryptographic CoProcessor ("Raphael") (hereafter referred to as “the module”) supports the Ryzen PRO 7000 Series SoC (System on a Chip) by providing digital signature verification of the key database during secure boot procedures. Module Type: Hybrid Firmware Module Embodiment: Single-chip standalone Module Characteristics: N/A Cryptographic Boundary: The cryptographic boundary of the module is defined as the fips_module binary, which performs self-tests, provides the service indicator, and shows status service, as well as the hardware implementations of RSA and SHA2-384 in the Cryptographic CoProcessor (CCP), which are used to perform signature verification and verify the integrity of the fips_module binary. Tested Operational Environment’s Physical Perimeter (TOEPP): The TOEPP of the module is defined as the Ryzen PRO 7000 Series SoC in which the module operates. Figure 1 - The AMD Ryzen PRO 7000 Series (7945) SoC. Figure 2 shows a block diagram that represents the design of the module. In this diagram, the physical perimeter of the operational environment, defined by the perimeter of the AMD Ryzen PRO SoC (i.e., the enclosure of the SoC), is indicated by a purple dashed line. The cryptographic boundary is represented by the components painted in orange blocks. © 2023 Advanced Micro Devices (AMD), atsec information security.

6 of 25

Components in white are only included in the diagram for informational purposes. They are not included in the cryptographic boundary (and therefore not part of the module’s validation). For example, the processor is responsible for executing the non-cryptographic code in the fips_module firmware component. Figure 2 - Block Diagram

Software Versions: N/A Software, Firmware, Hybrid Tested Operating Environments: Table 2 - Hardware Tested Operating Environments © 2023 Advanced Micro Devices (AMD), atsec information security.

7 of 25

Executable Code Sets: Table 3 - Executable Code Sets Vendor Affirmed Operating Environments: N/A

There are no components within the cryptographic boundary that are excluded from the FIPS 140-

Modes List and Description: Table 4 - Modes List and Description The module implements only one mode of operation, the approved mode, in which the approved services are available. No configuration is necessary for the module to operate and remain in the After passing all pre-operational self-tests and cryptographic algorithm self-tests executed on start-up, the module automatically transitions to the approved mode. Mode change instructions and status indicators: N/A Degraded Mode Description: The module does not implement a degraded mode of operation.

Approved Algorithms: Table 5 - Approved Algorithms Vendor Affirmed Algorithms: The module does not implement vendor affirmed algorithms. Non-Approved, Allowed Algorithms: The module does not implement non-approved algorithms allowed in the approved mode of operation. © 2023 Advanced Micro Devices (AMD), atsec information security.

8 of 25

Non-Approved, Allowed Algorithms with No Security Claimed: The module does not implement non-approved algorithms allowed in the approved mode of operation with no security claimed. Non-Approved, Not Allowed Algorithms: The module does not implement non-approved algorithms not allowed in the approved mode of operation.

The module does not contain any approved KTS or KAS implementations.

There is no algorithm specific information.

The module does not implement any entropy sources or RBGs.

The module does not implement any SSP generation methods.

The module does not implement any automated SSP establishment methods.

The module does not implement any industry protocols. © 2023 Advanced Micro Devices (AMD), atsec information security.

9 of 25

Table 6 - Ports and interfaces Table 6 summarizes the cryptographic module interfaces. The logical interfaces are logically separated from each other by the API design. The power interface is physically separated from any other interface.

The module does not implement a trusted channel.

The module does not implement a control output interface. © 2023 Advanced Micro Devices (AMD), atsec information security.

10 of 25

The module does not implement authentication. Table 7 - Roles The module supports the Crypto Officer role only. This sole role is implicitly and always assumed by the operator of the module. No support is provided for multiple concurrent operators.

The approved service indicator can be retrieved using Microsoft HSTI and through the UEFI interactive shell tool. As the module only offers approved services, the indicator is always set when the module is operational. This is shown by the “FIPS mode: on” output. Table 8 - Approved Services

There are no non-approved services.

The module does not load external software or firmware.

The module does not implement a bypass capability.

The module does not implement a self-initiated cryptographic output capability. © 2023 Advanced Micro Devices (AMD), atsec information security.

11 of 25

The integrity of the firmware component (“fips_module.bin”) of the module is verified by comparing a SHA2-384 digest value calculated at run time with the SHA2-384 digest value stored in the module that was computed at build time.

The integrity test is performed as part of the pre-operational self-tests, which are executed when the module is initialized. The integrity tests can be invoked on demand by powering off and subsequently re-initializing the module or SoC, which will perform (among others) the firmware integrity test. © 2023 Advanced Micro Devices (AMD), atsec information security.

12 of 25

Type of Operating Environment: Non-modifiable: no changes are possible to module firmware code, nor the bootloader firmware code that interacts with the module. How Requirements are Satisfied: The operational environment provides context separation for the memory and registers utilized by the module. When these components are used by the module, no other process or sub-component can access the information concurrently.

The module shall be installed as stated in Section 11. After installation, no configuration of the operational environment is required for the module to operate in an approved mode. Therefore, there are no rules, settings, or restrictions to the configuration of the operational environment. © 2023 Advanced Micro Devices (AMD), atsec information security.

13 of 25

The embodiment of the module is a single chip consisting of production-grade components. The coating is a standard sealing coat applied over the single chip. The module provides no additional physical security techniques. No actions are required to maintain the physical security of the module. © 2023 Advanced Micro Devices (AMD), atsec information security.

14 of 25

This module does not implement any non-invasive security mechanism and therefore this section is not applicable. © 2023 Advanced Micro Devices (AMD), atsec information security.

15 of 25

Table 9 - Storage Areas The module does not perform persistent storage of SSPs; SSPs in use by the module exist in volatile memory only. SSPs are provided to the module by the calling process and are destroyed when released by the respective functions.

s Table 10 - SSP Input-Output

Table 11 - SSP Zeroization Methods All data output is inhibited during zeroization. Table 12 - SSP Information First Table 13 - SSP Information Second © 2023 Advanced Micro Devices (AMD), atsec information security.

16 of 25

The RSA algorithm as implemented by the module conforms to FIPS 186-4, which has been superseded by FIPS 186-5. FIPS 186-4 will be withdrawn on February 3, 2024. © 2023 Advanced Micro Devices (AMD), atsec information security.

17 of 25

Table 14 - Pre-Operational Self-Tests powered on before the module transitions into the operational state. While the module is executing the self-test, services are not available, and data output (via the data output interface) is inhibited until the tests are successfully completed. The module transitions to the operational state only after the pre-operational self-test passed successfully.

Table 15 - Conditional Self-Tests The module performs self-tests on all approved cryptographic algorithms as part of the approved services supported in the approved mode of operation, using the tests shown in Table 15. These self-tests are performed automatically before the firmware test. Services are not available, and data output (via the data output interface) is inhibited during the self-tests. If any of these tests fails, the module transitions to the error state.

The module does not implement any periodic self-tests.

Table 16 - Error States © 2023 Advanced Micro Devices (AMD), atsec information security.

18 of 25

In the error state, the output interface is inhibited, and the module accepts no more inputs or requests (as the module is no longer running). The error code is output through the FW status register, which explains the error that has occurred.

All self-tests can be invoked on demand by unloading and subsequently re-initializing the module. © 2023 Advanced Micro Devices (AMD), atsec information security.

19 of 25

The procedures herein described are directed at OEMs for producing and configuring their BIOS so that the FIPS module is properly enabled to operate as the validated module in conformance with the rules in this Security Policy document. Once properly installed and enabled, no configuration is necessary for the module to operate and remain in the approved mode, as it is the only mode of operation of the module. To enable the FIPS capability

1. Reserve 16KiB at least for AMD Secure Processor level 1 directory, as the FIPS module requires additional 8KiB of ROM space for the AMD Secure Processor L1 Bootloader.
2. The Platform BIOS must include the file with “_FIPS” postfix in the file name as AMD Secure Processor entry 0x1. For example, the file PspBootLoader_stage1_prod_AB_RN_FIPS.sbin has “_FIPS” postfix in the file name. This file is thus a FIPS capable AMD Secure Processor boot loader. Conversely, the file PspBootLoader_stage1_prod_AB_RN.sbin does not have “_FIPS” postfix in the file name, making this file a non-FIPS capable AMD Secure Processor boot loader.
3. Set BIT 32 of AMD Secure Processor soft fuse chain (AMD Secure Processor entry 0xB) to enable FIPS capability. a. The BIT32 in AMD Secure Processor entry 0xB is defined as FIPS capability enablement. If 0, the FIPS capability is OFF; if 1, the FIPS capability is ON (i.e., the module is properly installed as the validated module described in this document). To verify whether FIPS capability is on
4. Boot the system into UEFI shell with secure boot disabled.
5. Use the UEFI shell version of the AFF Tool version 0.3 and beyond. This tool is provided by the vendor. Run the AFF Tool with the command: afftool –fips from the interactive UEFI shell provided by the BIOS. a. If it shows “FIPS mode: on”, this is the FIPS capable module installed. b. If it shows “FIPS mode: off”, the module (described in this document) is disabled. The screenshot in Figure 2 shows the usage of the AFF Tool. The output indicates that the FIPS module is disabled. In this condition, the module does not operate in conformance with this Security Policy document. © 2023 Advanced Micro Devices (AMD), atsec information security.

20 of 25

Figure 3 - AFF Tool indicates that the module was not enabled. The screenshot in Figure 4 again shows the usage of the AFF Tool. The output demonstrates that the FIPS module is enabled and thus will operate as the FIPS validated module according to the rules in this Security Policy document. Figure 4 - AFF Tool indicating that the module is enabled. © 2023 Advanced Micro Devices (AMD), atsec information security.

21 of 25

All the functions, ports and logical interfaces described in this document are available to the Crypto Officer. The module only provides approved functions, and as such there are no special procedures to administer the approved mode of operation.

The module implements only the Crypto Officer. There are no requirements for non-administrator operators.

The bootloader (which acts as the operator of the module) initializes the fips_module component by loading it into memory upon power-on. After the pre-operational self-tests are successfully concluded, the module automatically transitions to the operational state. In the operational state, the module automatically performs the signature verification of the key database using the RSA signature verification service, which is the sole service provided by the module. The key database, RSA public key, and signature are provided as input by the operator of the module (the bootloader). After the successful signature verification of the key database, the module unloads itself from memory, ceasing its operation. All the procedures described above are conducted without any human assistance. To perform the procedures again, the module must be reset, which will trigger a new boot.

There are no maintenance requirements.

The process for performing “End of Life” occurs at the chronological point of 10 years starting from manufacturing date of the module. As stated in Section 9.1, the module does not possess persistent storage of SSPs. The SSP values only exists in volatile memory and those values vanish when the module is powered off. The procedure for secure sanitization of the module at the end of life is simply to power it off, which is the action of zeroization of the SSPs (Section 9.3). As a result of this sanitization via power-off, the SSPs are removed from the module, so that the module may either be distributed to other operators or disposed. © 2023 Advanced Micro Devices (AMD), atsec information security.

22 of 25

The module does not offer mitigation of other attacks and therefore this section is not applicable. © 2023 Advanced Micro Devices (AMD), atsec information security.

23 of 25

Appendix A. Glossary and Abbreviations