Pluton Security Processor ROM

Certificate

Vendor resources (verify with the vendor)

Approved Algorithms (2)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for Pluton Security Processor ROM
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C1["[high] Firmware / bootloader<br/>versions disclosed<br/>(identity, not provenance)<br/><i>Rembrandt B1 = 0x8262_0B00</i>"]
    C2["[high] Firmware update / recovery<br/>/ rollback services<br/><i>Load Firmware</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Show Status<br/>Perform Self- Tests</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I1["Component identity is<br/>disclosed, but provenance<br/>and patch lineage are not."]
    I2["Trusted code is reachable<br/>through update and<br/>recovery paths."]
    I3["Some services may process<br/>input 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"]
    R1["Do the vendor version<br/>strings obscure the<br/>upstream baseline, fork<br/>lineage, or known-CVE<br/>exposure?"]
    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"]
    E1["SBOM / component baselines<br/>· patch and backport<br/>manifest · CVE disposition"]
    E2["update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["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
  C1 --> I1 --> R1 --> E1
  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 C1,C2,C3,C6 clue;
  class I1,I2,I3,I6 infer;
  class R1,R2,R3,R6 risk;
  class E1,E2,E3,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Pluton Security Processor ROM
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C1["[high] Firmware / bootloader versions disclosed (identity, not provenance)<br/><i>Rembrandt B1 = 0x8262_0B00</i><br/>src: certificate.firmwareVersions"]
    C2["[high] Firmware update / recovery / rollback services<br/><i>Load Firmware</i><br/>src: securityPolicy.services"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Show Status<br/>Perform Self- Tests</i><br/>src: securityPolicy.services"]
    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 C1,C2,C3 clueHigh;
  class C6 clueLow;

Security Policy, page by page

Pluton Security Processor ROM – Security Policy FIPS 140-3 Security Policy (Non-Proprietary) Pluton™ Security Processor ROM Ryzen 7 Pro 6850H with Radeon Graphics Rembrandt B1 = 0x8262_0B00 1.1 This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).

Pluton Security Processor ROM – Security Policy The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS DOCUMENT. under the Creative Commons Attribution-NoDerivs-NonCommercial VLicense (which allows redistribution of the work). To view a copy of this license, visithttp://creativecommons.org/licenses/bynd-nc/1.0/ or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA. rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these The example companies, organizations, products, people and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred. Microsoft, Pluton security processor, Azure, Active Directory, Visual Basic, Visual Studio, Windows, the Windows logo, Windows NT, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).

Pluton Security Processor ROM – Security Policy Contents 1.1. 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 10. 10.1. 10.2. 10.3. 11. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).

Pluton Security Processor ROM – Security Policy 11.1. 11.2. 12. Version history 1.0 1.1 This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).

Pluton Security Processor ROM – Security Policy Microsoft’s Pluton™ Security Processor Read-Only Memory (ROM) module (the “module”, or “Pluton ROM”) is a sub-chip cryptographic subsystem in the AMD Ryzen 6000 Series System on a Chip (SOC). The module is a single chip hardware module that implements FIPS 140-3 approved cryptographic algorithms. This document is the FIPS 140-3 Security Policy for the module. It contains a specification of the rules under which the module must operate and describes how the module meets security requirements as specified in ISO/IEC 19790:2012 and the Federal Information Processing Standards Publication 140-3 (FIPS PUB 140-3) for a Security Level 2 module, when achieving its primary functional objective. This document is intended for the FIPS 140-3 testing lab, the Cryptographic Module Validation Program (CMVP), and administrators and users of the module. The overall security level that this module is validated at is Level 2. The following table lists the security levels of individual areas for this validation, as required by the CMVP Security Policy Requirements (NIST SP 800-140B), ISO/IEC 19790 Annex B, and ISO/IEC 24759 section 6.14. N/A N/A N/A [Number Below] Table 1: Security Levels This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).

Pluton Security Processor ROM

• Security Policy 2. Cryptographic Module Specification 2.1. Module Description The primary functional objective of the Pluton™ Security Processor ROM module is to validate digitally signed files before they are imported into the Pluton Security Processor. The module and the Pluton Security Processor are embedded security subsystems within AMD’s SOC silicon die. While the module incorporates other hardware elements, the following on-die design blocks are relevant to the primary functional objective of the module.
• The ARM Cortex R4 processor, which is configured to boot from the Pluton image at a specific address in the ROM.
• The Pluton ROM image, which is compiled by its developer before the Graphic Data System (GDS) Integrated Circuits (IC) layout of the SOC is finalized and fabricated.
• The Pluton ROM, to which the compiled Pluton image is written as part of the process to complete the SOC GDS IC layout.
• Pluton RAM, which provides runtime temporary stack or data spaces exclusive to the R4 processor when the R4 processor is executing the Pluton image.
• The Pluton AES engine, which is a hardware implementation of the AES block cipher for encryption and decryption of data.
• The Pluton SHA engine, which is a hardware implementation for performing hashing operations in authenticating and checking the integrity of blocks of data.
• The Pluton Public Key Acceleration (PKA) engine, which provides hardware acceleration to perform prime finite field arithmetic functions autonomously to support ECC public key operations. 2.2. Modes of Operation The mode in which the module operates is implicitly the approved mode. The module has only an approved mode and, therefore, all services are approved services. 2.3. Operational Environments and Configurations The module resides in all AMD Ryzen 6000 Series SOCs, regardless of SKU or model. This is a nonmodifiable operational environment. The Ryzen 6000 Series includes multiple SKUs, e.g. Ryzen 3, This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).

Pluton Security Processor ROM – Security Policy Ryzen 5, Ryzen 7, and Ryzen 9, among others. The specific SKU and model used for testing in this validation is identified in the table below. Apart from the Pluton ROM image, the rest of the module is comprised of integrated circuits fabricated on silicon dies as hardware components. Table 2: Cryptographic Module Tested Configuration Figure 1: Processor Photograph This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).

Pluton Security Processor ROM – Security Policy 2.4. Algorithms and Security Functions The following tables present the cryptographic algorithms and security functions used in the module in its single mode of operation. Table 3 lists the FIPS 140-3 approved algorithms used in the module, and tables 4-5 list the non-approved algorithms that may be used in certain modes of operation in # Table 4: Non-Approved Algorithms Allowed in the Approved Mode of Operation Table 5: Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).

Pluton Security Processor ROM – Security Policy Table 6: Non-Approved Algorithms Not Allowed in the Approved Mode of Operation 2.5. Cryptographic Boundaries The module’s physical boundary per IG 2.3.B is the physical perimeter of the AMD SOC. Consequently, the module qualifies as a single-chip cryptographic module. As a Sub-Chip Cryptographic Subsystem, the cryptographic boundary consists of the circuitry cores of sub-chip cryptographic subsystem and the Hardware Module Interface (HMI) interfaces documented in Section 3 of this document. Figure 2 visualizes the cryptographic boundary of the module, and Figure 3 provides a photograph of the physical boundary of the SOC. Figure 2: Cryptographic Boundary (HMI) This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).

Pluton Security Processor ROM – Security Policy Figure 3: Photograph of the SOC with Red Overlay Identifying the Physical Boundary The module’s primary functional objective is to validate the SHA2-256 ECDSA P-384 signature of a firmware application. If the signature is valid, the firmware application may be imported and loaded into the Pluton RAM for the R4 processor to execute. (Note that the module itself contains no firmware per CMVP definitions.) As a result, firmware applications remain outside of the FIPS cryptographic boundary. No components within the boundary are excluded from the security requirements. All information processed by the component is strictly for internal use of the module towards its security function and does not impact the secure operation of the module or the correctness of control, status, or data outputs. The inclusion of specific firmware applications would be the subject of another validation under CMVP which extends the module’s current functionality and CMVP validation assessment verdicts. 2.6. Design and Rules of Operation The module is a sub-chip embedded in the AMD Ryzen 6000 Series SOC, which is a single-chip standalone device. The primary functional objective of the hardware module is to validate digitally signed files before they are imported into the module. The module is an embedded security subsystem within AMD’s SOC. No user installation or maintenance is required. The FIPS 140-3 functional requirements are always invoked when the validated hardware version listed is used. The other sections of this document provide additional details on the design of the module and rules for its operation. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).

Pluton Security Processor ROM – Security Policy

3. Cryptographic Module Interfaces As indicated in the table below, all status and control ports are accessed through the Pluton registers and the API command handlers implemented in the Pluton ROM image. For data input, direct access to memory through the address spaces maintained by the Pluton registers and the API command handlers implemented in the Pluton ROM image are used. This direct access to memory, the Pluton registers, and API commands defines the FIPS interfaces across the module’s cryptographic boundary. Error statuses available through these interfaces do not reveal any sensitive materials to the interface initiators. Table 7: Ports and Interfaces
4. Roles, Services, and Authentication The module supports a single role, Crypto Officer, which may use any of the module’s services. The Crypto Officer role is implicitly assumed by the party accessing services implemented by the Module. There is no non-Crypto Officer role in approved mode. The module does not support cryptographic bypass. The following table identifies all services offered in each role, with corresponding input and output. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).

Pluton Security Processor ROM – Security Policy 2. Details on authentication methods are N/A as the module does not provide authentication of users and is not required to as the module services that access approved security functions fall into the categories of FIPS 180-4 hash algorithms and FIPS 186-4 digital signature verification, per IG 4.1.A. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).

Pluton Security Processor ROM – Security Policy The following table identifies the approved services of the module. The module does not include a zeroization service because the single SSP accessed by the module (ECDSA public key used for firmware signature verification) is a Public Security Parameter (PSP) that is hardcoded in the ROM code. This PSP is immutable and thus is considered protected. N/A N/A N/A This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).

Pluton Security Processor ROM – Security Policy R, E N/A N/A N/A N/A This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).

Pluton Security Processor ROM – Security Policy N/A N/A 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 = Zeroise: The module zeroises the SSP. The module implements only approved services. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).

Pluton Security Processor ROM – Security Policy

5. Software/Firmware Security The module’s executable code is stored in non-reconfigurable memory on the SOC, as defined by FIPS 140-3 IG 5.A. The SOC non-reconfigurable memory will not change or degrade for a minimum of 10 years, guaranteeing firmware security. This design requires no integrity testing. As a sub-chip embedded in the AMD SOC, the module is expected to last the lifetime of the SOC. The non-reconfigurable memory of the SOC should not degrade for at least 10 years. The module and SOC are determined to be end-of-life at the discretion of the user within this period. At end-of-life, the user should discontinue use of the SOC. As the module does not generate, establish, or import any CSPs, no sanitization process is required.
6. Operational Environment The Operational Environment requirements do not apply, as the module’s operational environment is non-modifiable and the physical security level claimed is Level
7. Apart from the Pluton ROM image, the rest of the module is comprised of integrated circuits fabricated on silicon dies as hardware components. The Pluton ROM image is non-modifiable as it is written to the SOC as part of the process to complete the SOC GDS IC layout before wafer fabrication. The module cannot be modified and no code can be added or removed.
8. Physical Security The module is a sub-chip embedded in the AMD Ryzen 6000 Series SOC, which is a single-chip standalone device. The module is embedded in all AMD Ryzen 6000 SOC models and SKUs. The SOC conforms to the FIPS 140-3 Level 2 requirements for physical security. The SOC resides in a package which provides opaqueness in the visible spectrum and protection against environmental or other physical damage. It is contained in a tamper-evident enclosure which deters direct observation, probing, or manipulation and provides evidence of attempts to tamper with or remove the module. No operator-applied tamper evident seals or security appliances are required, as the seals are applied as part of manufacturing the SOC. The following table identifies the physical security mechanisms of the module and the protocol for maintaining them. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).

Table 10: Physical Security Inspection Guidelines The following photographs show the tamper-evident enclosure. The image at left shows the module Figure 4: Module before Tampering (Left) and after Tampering (Right) As a Level 2 module that does not implement EFP/EFT, the module is not subject to hardness testing. 8. Non-Invasive Security The module does not implement non-invasive attack mitigation techniques to protect the unprotected SSPs from non-invasive attacks. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).

Pluton Security Processor ROM – Security Policy 9. Sensitive Security Parameters Management The module does not generate, establish, or import any critical security parameters (CSPs). The ECC public key used for firmware application signature verification is a Public Security Parameter (PSP) that is hardcoded in the ROM code. This PSP is immutable and thus is considered protected. N/A N/A N/A Table 11: SSPs The module does not implement non-deterministic random number generation. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).

Pluton Security Processor ROM

• Security Policy 10. Self-Tests 10.1. Pre-Operational Self-Tests The module does not perform pre-operational self-tests and is not required to per IG 5.A, as explained in section 5 Software/Firmware Security. 10.2. Conditional Self-Tests The module runs conditional cryptographic algorithm self-tests during its crypto subsystem initialization after every power on or reset. No operator intervention is required. The following conditional cryptographic algorithm tests are included.
• SHA2-256 Known Answer Test.
• AES-128 encrypt ECB Known Answer Test (only used for self-test).
• AES-128 decrypt ECB Known Answer Test (only used for self-test). If these self-tests succeed, the module becomes operational and waits for commands from the platform processor of the AMD SOC. If any self-test fails, the module halts and no cryptographic function may be performed. To recover from the halt and to re-initialize the module, either a power off / power on cycle or a reset event must be triggered from outside the module. Upon receiving the “load firmware” command from the platform processor of the AMD SOC, the module automatically performs the following conditional cryptographic algorithm self-test.
• ECDSA Signature Verification Known Answer Test on P-384 curve with SHA2-256 The test must pass before the module will perform firmware application signature verification. The test data, key-pair, and signature used in this known answer test are hard-coded in the ROM. If the self-test succeeds, the firmware application image inferred by the “load firmware” command is loaded to the Pluton RAM. The handler of the “load firmware” command inside the module validates the SHA2-256 ECDSA P-384 signature of the firmware application. If the signature is valid, the handler jumps out of the ROM image and passes the R4 processor execution control to the firmware application. If the self-test fails or the firmware application signature is not valid, the handler returns a failure status to the platform processor of the AMD SOC, and the module returns to its ready state. At This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).

Pluton Security Processor ROM – Security Policy that point, the platform processor stops sending commands to the module and may trigger a power off / power on cycle, a reset event, or a retry using a firmware image from the recovery portion. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).

Pluton Security Processor ROM – Security Policy 10.3. Error States The following diagram presents the finite state model for the module, including all module states. Figure 5: Finite State Model Diagram This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).

Pluton Security Processor ROM

• Security Policy The states depicted in the finite state diagram map to the required operational and error states as follows.
• Power On/Off state: The module is in a Power Off state until power is applied to the underlying SOC platform, at which point the module enters the Power On state shown in the diagram. There is a single power source and no standby or hibernation state.
• General Initialization state: This is the same state as the Power On state, as shown in the finite state diagram. There is no additional action taken by the module between power on and selftest.
• Approved state: All approved services are available in the approved state, as shown in the diagram: Load Firmware, PCR3 Extend, All PCR Extend, and Decommission. As the Crypto Officer role is the only role implemented, the approved state is equivalent to a Crypto Officer state.
• CSP entry state: This state is N/A for this module as it does not support CSP entry.
• User state: This state is N/A for this module as no User role is implemented.
• Self-test state: The module is in a self-test state at two points pictured in the finite state diagram: immediately after power on, shown as the SHA/AES self test state, and after the load firmware command is handled, shown as the ECDSA self test state.
• Error state: The module is in an error state at two points pictured in the diagram: when a hard error is encountered, shown as Error State: Module Halts, and when a soft error is encountered, shown as Return Failure Status to Caller. When the module halts due to a hard error, a power cycle / reset must be triggered to re-initialize the module. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).

Pluton Security Processor ROM – Security Policy

11. Life-Cycle Assurance 11.1. Crypto Officer Guidance The operation of the module does not need FIPS 140-3 specific guidance. The FIPS 140-3 functional requirements are always invoked. The module is determined to be a FIPS 140-3 validated module by using the validated product described in this Security Policy. No Crypto Officer installation or maintenance is required. 11.2. User Guidance The operation of the module does not need FIPS 140-3 specific guidance. The FIPS 140-3 functional requirements are always invoked. The module is determined to be a FIPS 140-3 validated module by using the validated product described in this Security Policy. No User installation or maintenance is required.
12. Mitigation of Other Attacks The module does not claim any mitigation of other attacks. This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).

Referenced URLs

• http://creativecommons.org/licenses/by-