AMD ASP Cryptographic CoProcessor ("Turin")

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for AMD ASP Cryptographic CoProcessor ("Turin")
  %% 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/>firmware load</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>UnAuth<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>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."]
    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 ("Turin")
  %% 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/>firmware load</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>UnAuth<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>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,C5,C6 clueLow;

Security Policy, page by page

Advanced Micro Devices (AMD) AMD ASP Cryptographic CoProcessor ("Turin") Prepared by: atsec information security corporation

4516 Seton Center Pkwy, Suite 250

Austin, TX 78759 Document version: 1.1 www.atsec.com Last update: 2025-10-08

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

This document is the non-proprietary FIPS 140-3 Security Policy for the AMD ASP Cryptographic CoProcessor ("Turin") cryptographic module. It contains the security rules under which the module must operate and describes how this module meets the requirements as specified in FIPS PUB 140-3 (Federal Information Processing Standards Publication 140-3) intact and including this notice.

Table 1: Security Levels © 2025 Advanced Micro Devices (AMD), atsec information security.

Purpose and Use: The AMD ASP Cryptographic CoProcessor ("Turin") cryptographic module (hereafter referred to as “the module”) is defined as a sub-chip hardware module in a single chip embodiment, with hardware and firmware components implementing general purpose cryptographic algorithms. Module Type: Hardware Module Embodiment: SingleChip Module Characteristics: SubChip Cryptographic Boundary: The module consists primarily of the ARM Cortex-A5, Random Bit Generation hardware, Security Infrastructure Block, Cryptographic CoProcessor, and OTP fuses. These hardware components are sub-components of the “IOD” (EPYC EIOD2.0), which itself is a smaller die in the larger single chip embodiment, the EPYC SoC. OTP fuses are used to persistently store FIPS support enablement and versioning information, security state information, and Entropy Source configuration values (sample rate, sample count, RCT and APT cutoffs). In addition, there is a ROM firmware component (“libROM”) permanently stored inside the EPYC SoC, and an overlay firmware component (“overlay firmware”) permanently stored inside SPI flash storage, outside the EPYC SoC, which is loaded into the IOD SRAM on startup. The block diagram in Figure 2 shows the design of the module when the module is operational and the firmware components are loaded into the SRAM. In this diagram, the physical boundary of the module, defined by the perimeter of the EPYC SoC (i.e., the enclosure of the SoC), is indicated by a dashed purple line. The cryptographic boundary is represented by the components painted in orange blocks. Solid orange lines indicate the flow of data within the cryptographic module (i.e., internal paths). Dashed green lines are used to denote the logical interfaces defined in Section 3. 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). Tested Operational Environment’s Physical Perimeter (TOEPP): The TOEPP is the EPYC SoC (shown in Figure 1), a rectangular enclosure measuring approximately 72 mm x 75.4 mm x 5.30 mm. © 2025 Advanced Micro Devices (AMD), atsec information security.

Figure 1: AMD EPYC 9B45 SoC Figure 2: Block Diagram © 2025 Advanced Micro Devices (AMD), atsec information security.

Identification Tested Module Identification

• Hardware: Table 2: Tested Module Identification
• Hardware

There are no components excluded from the requirements of the FIPS 140-3 standard.

Modes List and Description: Table 3: Modes List and Description After passing all pre-operational self-tests and conditional self-tests executed on startup, the module automatically transitions to the approved mode. No operator intervention is required to reach this point. In the operational state, the module accepts service requests from calling applications through its logical interfaces. The operator can verify that the module is operational by requesting the RL_ARCL_GetState service and comparing the returned ArclState value with 4. The module automatically switches between the approved and non-approved modes depending on the services requested by the operator. The status indicator of the mode of

Approved Algorithms: © 2025 Advanced Micro Devices (AMD), atsec information security.

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

Table 4: Approved Algorithms Vendor-Affirmed Algorithms: Table 5: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: N/A for this module. Non-Approved, Allowed Algorithms with No Security Claimed: Table 6: Non-Approved, Allowed Algorithms with No Security Claimed Non-Approved, Not Allowed Algorithms: © 2025 Advanced Micro Devices (AMD), atsec information security.

Table 7: Non-Approved, Not Allowed Algorithms

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

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

Table 8: Security Function Implementations

Digital signature generation using SHA-1 is non-approved and not allowed in approved services. For RSA key pair generation, signature generation, and signature verification, the module supports modulus sizes 2048, 3072, and 4096 bits. Additionally, the module supports a modulus size of 1024 and 1536 bits for RSA signature verification. All supported modulus sizes have been CAVP tested. Legacy use and FIPS 186-5: In compliance with FIPS 140-3 IG C.K, the digital signature algorithm implementations have been CAVP tested against FIPS 186-5 where possible. FIPS 186-2 CAVP testing was performed for RSA signature verification with a 1536-bit modulus. FIPS 186-4 CAVP testing was performed for digital signature verification using SHA-1 and RSA only. © 2025 Advanced Micro Devices (AMD), atsec information security.

Table 9: Entropy Certificates Table 10: Entropy Sources The module provides an SP800-90Ar1-compliant Deterministic Random Bit Generator (DRBG) using CTR_DRBG mechanism with AES-256 for generation of key components of asymmetric keys, and random number generation. The module complies with the Public Use Document for ESV certificate E173 by reading entropy data from the 2048-bit FIFO, which corresponds to the GetEntropy() function. This function outputs 128 bits of entropy. The module constructs the 384-bit entropy input for the DRBG by requesting GetEntropy() three times and concatenating the result. The DRBG does not employ a derivation function, does not support a personalization string, and does not support additional input. Consequently, the 384-bit entropy input is used directly as the DRBG seed, for both seeding and reseeding. The operational environment on the ESV certificate is identical to the IOD in the EPYC SoC, in which the sub-chip components are contained. Thus, the module is compliant with scenario 1 of IG 9.3.A. There are no maintenance requirements for the entropy source.

The module implements Cryptographic Key Generation (CKG, vendor affirmed), compliant with SP 800-133r2. When random values are required, they are obtained from the SP 800 90Ar1 approved DRBG, compliant with Section 4 of SP 800-133r2. The following methods are implemented:

• ECDSA key pair generation: compliant with SP 800-133r2, Section 5.1, which maps to FIPS 186-5. The method described in Appendix A.2.1 of FIPS 186-5 (“ECDSA Key Pair Generation using Extra Random Bits”) is used.
• RSA key pair generation: compliant with SP 800-133r2, Section 5.1, which maps to FIPS 186-5. The method described in Appendix A.1.3 of FIPS 186-5 (“Generation of Random Primes that are Probably Prime”) is used. Intermediate key generation values are not output from the module and are explicitly zeroized after processing the service. Additionally, the module implements an SP 800-108r1 compliant KBKDF, using the HMAC SHA-

256 PRF and a 32-bit counter. This implementation can be used to derive secret keys when

provided with a pre-existing key-derivation key. The resulting SSPs can be stored by the module in the Key Storage Block (if specified by the operator) or output as an API output parameter. © 2025 Advanced Micro Devices (AMD), atsec information security.

The module does not implement any automated key establishment methods.

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

Table 11: Ports and Interfaces The logical interfaces are logically separated from each other by the API design. The module does not implement a control output interface. The power interface is physically separated from any other interface. © 2025 Advanced Micro Devices (AMD), atsec information security.

The module does not implement any authentication methods.

Table 12: Roles No support is provided for multiple concurrent operators.

W,E W,E G,R © 2025 Advanced Micro Devices (AMD), atsec information security.

G,R G,E,Z G,R G,R G,E,Z W,E W,E © 2025 Advanced Micro Devices (AMD), atsec information security.

W,E W,E G,R G,E,Z G,E,Z (V, W,E © 2025 Advanced Micro Devices (AMD), atsec information security.

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

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

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

a Z © 2025 Advanced Micro Devices (AMD), atsec information security.

G,E,Z G,E,Z © 2025 Advanced Micro Devices (AMD), atsec information security.

(V, G G,E,Z G,E,Z (V, W,E Table 13: Approved Services For the above table, the convention below applies when specifying the access permissions (types) that the service has for each SSP.

• Generate (G): The module generates or derives the SSP.
• Read (R): The SSP is read from the module (e.g. the SSP is output).
• Write (W): The SSP is updated, imported, or written to the module.
• Execute (E): The module uses the SSP in performing a cryptographic operation. © 2025 Advanced Micro Devices (AMD), atsec information security.

• Zeroize (Z): The module zeroizes the SSP. • N/A: The module does not access any SSP or key during its operation. The module provides three different API layers, each with distinct services:

1. The ARCL layer, which provides high-level cryptographic (both approved and nonapproved) and non-cryptographic functionality.
2. The CCP HAL layer, which provides non-approved, low-level cryptographic functionality.
3. The SIB HAL layer, which provides non-approved, low-level functionality to interact with the Key Storage Block, Entropy Source, DRBG, and Security State. The ARCL API layer provides the RL_ARCL_GetState function which returns the ArclState, ArclVersion, and FipsIndicatorStatus values: • The ArclState value serves as the module’s status indicator and is used to indicate the error states. • The ArclVersion value contains the module’s versioning information. The FipsIndicatorStatus value serves as the approved service indicator. If this value is set to 2, the previously requested ARCL service was approved. If this value is set to any other value, the service was non-approved. The CCP HAL and SIB HAL layers only provide non-approved services.

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

Table 14: Non-Approved Services

Upon startup, the libROM firmware component loads the overlay firmware from external storage (SPI flash) into the sub-chip cryptographic subsystem. The integrity of the overlay firmware is determined by verifying an RSA-PSS 4096 with SHA-384 signature stored in the firmware that was computed at build time. If the signature verification fails, the firmware load test fails. The public key used to verify this signature is stored inside the libROM firmware component of the module, the private key associated with this public key is controlled by the vendor. All data output is inhibited during the execution of the firmware load test and the firmware loading process. © 2025 Advanced Micro Devices (AMD), atsec information security.

The integrity of the libROM component of the module is verified by comparing a SHA-384 digest value calculated at runtime with the SHA-384 digest value stored in the module that was computed at build time. The integrity of the overlay firmware component of the module is discussed in Section 4.5.

The module provides the RL_ARCL_SelfTest service to perform self-tests on demand. Among those self-tests is the integrity test, as part of the pre-operational self-tests. More details on the API are provided by the vendor in its developer’s manual. © 2025 Advanced Micro Devices (AMD), atsec information security.

Type of Operational Environment: Limited How Requirements are Satisfied: Any SSPs contained within the module are protected by the hardware and firmware restrictions implemented by the Key Storage Block. Only the module has access to these SSPs, and access is only possible through the defined interfaces.

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. © 2025 Advanced Micro Devices (AMD), atsec information security.

Table 15: Mechanisms and Actions Required © 2025 Advanced Micro Devices (AMD), atsec information security.

The module does not implement any non-invasive security mechanisms. © 2025 Advanced Micro Devices (AMD), atsec information security.

Name API input parameter s API output parameter s

From Operator calling application (TOEPP) Cryptographi c module

To Cryptographi c module Operator calling application (TOEPP)

Format Type Plaintex t Plaintex t

Distributio n Type Manual Manual

Entry Type Electroni c Electroni c

SFI or Algorith m

Table 16: Storage Areas approved and non-approved modes of operation using a “virtual queue” mechanism: virtual queue 0 is exclusively used for approved services, whereas virtual queue 1 is always used for non- approved services. The module does not perform persistent storage of SSPs; SSPs in use by the module exist in volatile memory only. m Table 17: SSP Input-Output Methods © 2025 Advanced Micro Devices (AMD), atsec information security.

Table 18: SSP Zeroization Methods All data output is inhibited during zeroization. h © 2025 Advanced Micro Devices (AMD), atsec information security.

h n © 2025 Advanced Micro Devices (AMD), atsec information security.

h Table 19: SSP Table 1 © 2025 Advanced Micro Devices (AMD), atsec information security.

d n © 2025 Advanced Micro Devices (AMD), atsec information security.

The SHA-1 algorithm as implemented by the module will be non-approved for all purposes, starting January 1, 2030. © 2025 Advanced Micro Devices (AMD), atsec information security.

While the module is executing the self-tests, services are not available, and data output (via the data output interface) is inhibited until the tests are successfully completed. The module does not return control to the calling application until the tests are completed.

s d Table 21: Pre-Operational Self-Tests automatically when the module is initialized. If this test fails, the module transitions to the hard error state.

As part of the initialization, the libROM firmware component loads the overlay firmware component and performs the firmware load test on the overlay firmware. Only if this test succeeds, will the module move to the operational state. Similar to the pre-operational integrity test, if the firmware load test fails, the module transitions to the hard error state. © 2025 Advanced Micro Devices (AMD), atsec information security.

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

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

n Table 22: Conditional Self-Tests Upon generation of an ECDSA or RSA key pair, the module will perform a pair-wise consistency test (PCT) as shown in the table above, which provides some assurance that the generated

Table 23: Pre-Operational Periodic Information © 2025 Advanced Micro Devices (AMD), atsec information security.

Table 24: Conditional Periodic Information

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

Table 25: Error States In the Soft Error state, the module outputs the error type through the status indicator and status output interface. Moreover, the data input and data output interfaces are inhibited, and the module only accepts control input. In the Hard Error state, no input or output is possible at all.

The operator can request on-demand self-tests by invoking the RL_ARCL_SelfTest service. This service executes all self-tests listed above. © 2025 Advanced Micro Devices (AMD), atsec information security.

To detect any potential tampering during delivery of the module, the user can verify the Thermoform or JEDEC tray is securely strapped and vacuum sealed in the moisture barrier bag. Additionally, the SoC itself provides tamper evidence as specified in Section 7. Upon delivery, no further installation or configuration is required for the hardware to operate as the validated module in conformance with the rules in this Security Policy document. The module implicitly transitions between the approved mode and the non-approved mode when appropriate.

All the functions, ports and logical interfaces described in this document are available to the Crypto Officer. The module implicitly transitions between the approved mode and the nonapproved mode contingent on the service that is invoked. Therefore, there are no special procedures to administer the approved or non-approved modes.

The module implements only the Crypto Officer. There are no requirements for nonadministrator operators.

The process for performing “End of Life” occurs at the chronological point of 10 years starting from manufacturing date of the module. The module does not possess persistent storage of SSPs. The SSP value only exists in volatile memory and that value vanishes 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. As a result of this sanitization via power-off, the SSP is removed from the module, so that the module may either be distributed to other operators or disposed. © 2025 Advanced Micro Devices (AMD), atsec information security.

The module does not implement security mechanisms to mitigate other attacks. © 2025 Advanced Micro Devices (AMD), atsec information security.

A Glossary and Abbreviations AES                   Advanced Encryption Standard API                   Application Programming Interface ARCL                  AMD Root of Trust Crypto Library ASP                   AMD Secure Processor CAST                  Cryptographic Algorithm Self-Test CAVP                  Cryptographic Algorithm Validation Program CBC                   Cipher Block Chaining CBC-MAC               Cipher Block Chaining Message Authentication Code CCP                   Cryptographic Co-Processor CFB                   Cipher Feedback CMAC                  Cipher-based Message Authentication Code CMVP                  Cryptographic Module Validation Program CSP                   Critical Security Parameter CTR                   Counter DRBG                  Deterministic Random Bit Generator ECB                   Electronic Code Book ECDSA                 Elliptic Curve Digital Signature Algorithm FIPS                  Federal Information Processing Standards GCTR                  Galois Counter HAL                   Hardware Abstraction Layer HMAC                  Keyed-Hash Message Authentication Code IAPM                  Integrity-Aware Parallelizable Mode IV                    Initialization Vector JEDEC                 Joint Electron Device Engineering Council KAT                   Known Answer Test KSB                   Key Storage Block MAC                   Message Authentication Code NIST                  National Institute of Science and Technology OFB                   Output Feedback OTP                   One-Time Programmable PCT                   Pair-wise Consistency Test PKI                   Public Key Infrastructure PSP                   Public Security Parameter PSS                   Probabilistic Signature Scheme ROM                   Read-Only Memory RSA                   Rivest Shamir Adleman RTL                   Register-Transfer Level SHA                   Secure Hash Algorithm SHAKE                 Secure Hash Algorithm with Keccak SIB                   Security Infrastructure Block SoC                   System on Chip SRAM                  Static Random-Access Memory SSP                   Sensitive Security Parameter TRNG                  True Random Number Generator XOF                   Extendable Output Function XTS                   XEX-based Tweaked-codebook mode with cipher text Stealing © 2025 Advanced Micro Devices (AMD), atsec information security.

B References FIPS 140-3 FIPS PUB 140-3 - Security Requirements For Cryptographic Modules March 2019 https://doi.org/10.6028/NIST.FIPS.140-3 FIPS 140-3 IG Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program https://csrc.nist.gov/CSRC/media/Projects/cryptographic-modulevalidation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf FIPS 180-4 Secure Hash Standard (SHS) August 2015 https://doi.org/10.6028/NIST.FIPS.180-4 FIPS 186-2 Digital Signature Standard (DSS) January 2000 https://csrc.nist.gov/files/pubs/fips/186-2/final/docs/fips186-2.pdf FIPS 186-4 Digital Signature Standard (DSS) July 2013 https://doi.org/10.6028/NIST.FIPS.186-4 FIPS 186-5 Digital Signature Standard (DSS) February 2023 https://doi.org/10.6028/NIST.FIPS.186-5 FIPS 197 Advanced Encryption Standard (AES) November 2001; Updated May 2023 https://doi.org/10.6028/NIST.FIPS.197-upd1 FIPS 198-1 The Keyed-Hash Message Authentication Code (HMAC) July 2008 https://doi.org/10.6028/NIST.FIPS.198-1 FIPS 202 SHA-3 Standard: Permutation-Based Hash and ExtendableOutput Functions August 2015 https://doi.org/10.6028/NIST.FIPS.202 SP 800-38A Recommendation for Block Cipher Modes of Operation: Methods and Techniques December 2001 https://doi.org/10.6028/NIST.SP.800-38A SP 800-38B Recommendation for Block Cipher Modes of Operation: the CMAC Mode for Authentication May 2005; Updated October 2016 https://doi.org/10.6028/NIST.SP.800-38B SP 800-38D Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC November 2007 https://doi.org/10.6028/NIST.SP.800-38D SP 800-38E Recommendation for Block Cipher Modes of Operation: the XTS-AES Mode for Confidentiality on Storage Devices January 2010 https://doi.org/10.6028/NIST.SP.800-38E SP 800-90Ar1 Recommendation for Random Number Generation Using Deterministic Random Bit Generators June 2015 https://doi.org/10.6028/NIST.SP.800-90Ar1 SP 800-90B Recommendation for the Entropy Sources Used for Random Bit Generation © 2025 Advanced Micro Devices (AMD), atsec information security.

January 2018 https://doi.org/10.6028/NIST.SP.800-90B SP 800-108r1 Recommendation for Key Derivation Using Pseudorandom Functions August 2022; Updated February 2024 https://doi.org/10.6028/NIST.SP.800-108r1-upd1 SP 800-131Ar2 Transitioning the Use of Cryptographic Algorithms and Key Lengths March 2019 https://doi.org/10.6028/NIST.SP.800-131Ar2 SP 800-133r2 Recommendation for Cryptographic Key Generation June 2020 https://doi.org/10.6028/NIST.SP.800-133r2 SP 800-140Br1 Cryptographic Module Validation Program (CMVP) Security Policy Requirements: CMVP Validation Authority Updates to ISO/IEC 24759 and ISO/IEC 19790 Annex B November 2023 https://doi.org/10.6028/NIST.SP.800-140Br1 © 2025 Advanced Micro Devices (AMD), atsec information security.