AMD ASP Cryptographic CoProcessor ("Genoa")

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for AMD ASP Cryptographic CoProcessor ("Genoa")
  %% 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</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>show status<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/>linux<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 ("Genoa")
  %% 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</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>show status<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/>linux<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 ("Genoa") Module Version: 0000000DFIPS2001 Document Version: 1.1 Last update: 2025-01-08 Prepared by: atsec information security corporation

4516 Seton Center Parkway, Suite 250

Austin, TX 78759 www.atsec.com © 2025 Advanced Micro Devices (AMD), atsec information security.

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

3 of 27

0. Introduction 0.1. Overview This section is informative to the reader to reference cryptographic services and other services of AMD ASP Cryptographic CoProcessor ("Genoa") (the “module”) from Advanced Micro Devices (AMD) (the “vendor”). Only the components listed in Section 2.2 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. 0.2. This Security Policy Document This Security Policy describes the features and design of the module named AMD ASP Cryptographic CoProcessor ("Genoa")1 using the terminology contained in the FIPS 140-3 specification. The FIPS 140-3 Security Requirements for Cryptographic Module specifies the security requirements that will be satisfied by a cryptographic module utilized within a security system protecting sensitive but unclassified information. The NIST/CCCS Cryptographic Module Validation Program (CMVP) validates cryptographic module to FIPS 140-3. Validated products are accepted by the Federal agencies of both the USA and Canada for the protection of sensitive or designated information. The Security Policy document is one document in a FIPS 140-3 Submission Package. In addition to this document, the Submission Package contains:  The validation report prepared by the lab.  The Entropy Assessment Report (EAR) if applicable.  Other supporting documentation and additional references. and including this notice. Other documentation is proprietary to their authors. 0.3. How this Security Policy was Prepared 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. ASP: AMD Secure Processor © 2025 Advanced Micro Devices (AMD), atsec information security.

5 of 27

This document is the non-proprietary FIPS 140-3 Security Policy for version 0000000DFIPS2001 of the AMD ASP Cryptographic CoProcessor ("Genoa") 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 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 © 2025 Advanced Micro Devices (AMD), atsec information security.

6 of 27

2. Cryptographic Module Specification The following subsections describe the cryptographic module and how it conforms to the FIPS 140-

2.1. Module Overview, Embodiment, Type The AMD ASP Cryptographic CoProcessor ("Genoa") (hereafter referred to as “the module”) is defined as a hybrid firmware module in a single chip embodiment, with hardware (the coprocessor) and firmware components implementing general purpose cryptographic algorithms. The module supports the AMD EPYC 9000 Series SoC (System on a Chip) by providing digital signature verification of the key database during secure boot procedures. The module resides within the Ryzen SoC that contains the module, the processor, the firmware, and other components in a single chip embodiment (Figure 1). Figure 1: The AMD EPYC 9000 Series SoC, representing all versions of the single chip tested platforms. The Operational Environments tested for the module are described in Section 2.4 2.2. Module Design, Components and Versions 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 EPYC

9000 Series 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. These components are further described in Table 2. Table 2: Components in the Cryptographic Boundary © 2025 Advanced Micro Devices (AMD), atsec information security.

7 of 27

The flow of information between the components and the relation between that data and the module’s FIPS interfaces are depicted through arrows. The arrows are colored differently to facilitate visualization. The color does not identify the type of data: the type of data flow (namely, data input, data output, status output and control input) is indicated by labels pointing to the arrows. 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_firmware component. Figure 2: Block diagram 2.2.1. Components Excluded from Security Requirements There are no components within the cryptographic boundary that are excluded from the FIPS 140-

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

8 of 27

2.3. Security Level The module is validated according to FIPS 140-3 at overall security level 1. The security levels of individual areas are indicated in Table 1. 2.4. Tested Operational Environments The module has been tested on the operational environments indicated in Table 3 with the corresponding module variants and configuration options. Table 3: Tested Operational Environments There are no vendor affirmed operational environments. 2.5. Modes of Operation of the Module The module only implements one mode of operation, the approved mode, in which the approved cryptographic functions are available. The module transitions to this sole mode of operation automatically after the module completes its pre-operational self-tests and cryptographic algorithm self-tests performed on initialization. No configuration is necessary for the module to operate and remain in the approved mode. 2.6. Security Functions 2.6.1. Approved Security Functions Table 4 lists all approved security functions (cryptographic algorithms) of the module, including specific key lengths employed for approved services, and implemented modes or methods of operation of the algorithms. Table 4: Approved Algorithms © 2025 Advanced Micro Devices (AMD), atsec information security.

9 of 27

The module does not implement any vendor-affirmed algorithms. 2.6.2. Non-Approved Security Functions Allowed in Approved Services The module does not offer any non-approved cryptographic algorithms that are allowed in approved services. 2.6.3. Non-Approved Security Functions Allowed in Approved Services with No Security Claimed The module does not offer any non-approved cryptographic algorithms that are allowed in approved services but claim no security. 2.6.4. Non-Approved Security Functions Not Allowed in Approved Services The module does not offer any non-approved cryptographic algorithms not allowed in approved services. 2.7. Rules of Operation The bootloader (which acts as the operator of the module) initializes the fips_firmware component by loading it into memory upon power-on. After the pre-operational self-tests and cryptographic algorithm self-tests performed on initialization 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. © 2025 Advanced Micro Devices (AMD), atsec information security.

10 of 27

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

11 of 27

4. Roles, Services and Authentication 4.1. Roles Table 6 lists the roles supported by the module with corresponding services with input and output. The module supports the Crypto Officer role only. This sole role is implicitly and always assumed by the operator of the module. Table 6: Roles, Service commands, Input, and Output 4.2. Authentication The module does not support authentication for roles. 4.3. Services The module provides services to operators that assume the available role. All services are described in detail in the user documentation. The next subsections define the services that utilize approved, allowed, and non-approved security functions in this module. For the respective tables, the convention below applies when specifying the access permissions (types) that the service has for each SSP.  Generate (G): The service establishes the SSP by generation, agreement, or derivation.  Read (R): The SSP exists in the module and is read by the service, and may be output.  Write (W): The caller provides the SSP to the service to be imported into the module; written; or updated if the SSP already exists in the module.  Execute (E) (or use): The service uses the SSP in performing a cryptographic operation. Other access types identify the provenance of the SSP.  Zeroize (Z): The service zeroizes the SSP.  N/A: The service does not access any SSP or key during its operation. © 2025 Advanced Micro Devices (AMD), atsec information security.

12 of 27

The module provides only one approved service with approved parameters, and no non-approved services. The approved service indicator is thus considered a global indicator and it is set after Table 7 lists the approved services in this module, the roles that can request the service, the algorithms involved, the Sensitive Security Parameters (SSPs) involved and how they are In the service tables, CO specifies the Crypto Officer role. There are no non-approved services. © 2025 Advanced Micro Devices (AMD), atsec information security.

13 of 27

5. Software/Firmware Security 5.1. Integrity Techniques The integrity of the firmware component of the module (“fips_firmware”) 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. 5.2. On-Demand Integrity Test Integrity tests are performed as part of the pre-operational self-tests. The integrity test may be invoked on-demand in two ways: through the On-Demand Self-Test service, and through the OnDemand Integrity Test service. The module provides the On-Demand Self-Test service to perform self-tests on demand. This service performs the same cryptographic algorithm tests executed during initialization, i.e., the cryptographic algorithm self-tests and the pre-operational self-tests. This service is invoked by powering-off and reloading the SoC. The On-Demand Integrity Test service can be used to perform only the on-demand pre-operational self-tests. This service is invoked by calling the integrity test API using the module’s logical interfaces. More details on the API are provided by the vendor in its developer’s manual. © 2025 Advanced Micro Devices (AMD), atsec information security.

14 of 27

6. Operational Environment 6.1. Applicability The module operates in a non-modifiable operational environment per FIPS 140-3 level 1 specifications: no changes are possible to module firmware code, nor the bootloader firmware code that interacts with the module. 6.2. Tested Operational Environments Please see Section 2.4. 6.3. Policy and Requirements 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 bootloader acts as the sole operator of the module, thus there are no concurrent operators. 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. The module does not have the capability of loading software or firmware from an external source. © 2025 Advanced Micro Devices (AMD), atsec information security.

15 of 27

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

16 of 27

8. Non-Invasive Security The module claims no non-invasive security techniques. © 2025 Advanced Micro Devices (AMD), atsec information security.

17 of 27

9. Sensitive Security Parameter Management Table 8 summarizes the Sensitive Security Parameters (SSPs) that are used by the cryptographic services implemented in the module in the approved services (Table 7). Table 8: SSPs The module does not generate SSPs. 9.2. SSP Establishment The module does not implement automated SSP establishment. The module only supports manual distribution, electronic entry of the RSA public key, which is provided in plaintext by the bootloader operator via the data input interface. No other SSPs are entered into the module. No SSPs are output from the module. SSPs are provided to the module by the calling process and are destroyed when released by the respective functions. The module does not perform persistent storage of SSPs; keys in use by the module exist in 9.5. SSP Zeroization The module’s functions deallocates and zeroizes temporary SSP values in volatile memory used during the function’s execution. The zeroization consists of writing zeroes to the memory location used by the SSP before deallocating the area. The module does not overwrite the SSP with another The zeroization service for the SSP in volatile memory consists of powering off the SoC, which will remove power from the volatile memory. This action will cause the value of the SSP in volatile memory to be overwritten by random values. The successful act of powering off the SoC serves as the implicit indicator of zeroization. © 2025 Advanced Micro Devices (AMD), atsec information security.

18 of 27

9.6. Random Number Generation The module does not implement random number generation. © 2025 Advanced Micro Devices (AMD), atsec information security.

19 of 27

10. Self Tests The module performs pre-operational self-tests and conditional self-tests. 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. All the self-tests are listed in Table 9, with the respective condition under which those tests are (CASTs) are performed. Table 9: Self-tests The module performs pre-operational tests automatically when the module is initialized. The preoperational self-tests ensure that the module is not corrupted and that the cryptographic algorithms work as expected. The module transitions to the operational state only after the preoperational self-tests are passed successfully. The types of pre-operational self-tests are described in the next sub-sections. The integrity of the firmware component of the module (“fips_firmware”) 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. If the comparison verification fails, the module transitions to the error state (Section 10.3). The SHA2-384 algorithm goes through its conditional algorithm self-test before the integrity test is performed (Table 9). 10.2. Conditional Tests 10.2.1. Cryptographic Algorithm Self-Tests The module performs self-tests on all approved cryptographic algorithms automatically on initialization, using the tests shown in Table
11. Data output through the data output interface is inhibited during the self-tests. 10.2.2. Periodic/On-Demand Self-Test The module performs on-demand self-tests initiated by the operator, by powering off and powering the SoC back on. The full suite of self-tests in Table 9 is then executed. © 2025 Advanced Micro Devices (AMD), atsec information security.

20 of 27

The same procedure may be employed by the operator to perform periodic self-tests. 10.3. Error States If the module fails any of the self-tests, the module enters the error state. In the error state, the module outputs the error type through the status indicator and status output interface. In the error state, the data output interface is inhibited, and the module accepts no more inputs or requests. The module does not implement a control output interface. Table 10 lists the error state and the status indicator (through the FW_STATUS variable) values that explains the error that has occurred. Table 10: Error States To recover from the error state (clearing the error condition), the module shall be restarted or reset. © 2025 Advanced Micro Devices (AMD), atsec information security.

21 of 27

11. Life-Cycle Assurance 11.1. Delivery and Operation 11.1.1. Secure Installation, Initialization, Start-up, and Operation The procedures herein described are directed at OEMs for producing and configuring their BIOS so that the FIPS module is properly installed 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
12. Reserve at least 16KiB for the AMD Secure Processor level 1 directory, as the FIPS module requires additional 8KiB of ROM space for the AMD Secure Processor L1 Bootloader.
13. Set BIT 32 of the 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). Please note that above configuration is only applicable for OEMs integrating the module in as part of the production process. Once the module is distributed to end users, no further installation is required. Also, it is not possible to disable the FIPS capability once the SoC has left the OEM production process. To verify whether FIPS capability is enabled
14. Boot the system into a Linux shell.
15. If the system fails to boot: one of the self-tests failed, and the module is stuck in the error state.
16. Otherwise, use the ‘dmidecode’ tool with type 11 as the root user to fetch FIPS status: ‘sudo dmidecode -t 11’: a. If it shows “FipsStatus: PASS”, the FIPS capable module is installed and has passed all required self-tests. b. If it shows “FipsStatus: FAIL” or “FipsStatus:” the module (described in this document) is disabled or not installed correctly. The screenshot in Figure 3 shows the usage of dmidecode. The output indicates that FIPS module is installed and thus will operate as the FIPS validated module according to the rules in this Security Policy document. Note that the module version is shown here as “FipsId”. The “CcpVersion” string is unrelated to the FIPS requirements and should be disregarded. © 2025 Advanced Micro Devices (AMD), atsec information security.

22 of 27

Figure 3: dmidecode indicating that FIPS module is installed. The screenshots in Figure 4 and Figure 5 again shows the usage of dmidecode. The output demonstrates that FIPS module is not installed. In this condition, the module does not operate in conformance with this Security Policy document. Note that “FipsStatus” will either show “FAIL” or a blank string to indicate FIPS module is not installed. There is no functional difference between these two outputs. Finally, note that “FipsId” is also blank in this case. Figure 4: dmidecode indicating that FIPS module is not installed (first case). Figure 5: dmidecode indicating that FIPS module is not installed (second case). 11.1.2. Maintenance Requirements There are no maintenance requirements. © 2025 Advanced Micro Devices (AMD), atsec information security.

23 of 27

11.1.3. End of Life 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.4, the module does not possess persistent storage of SSPs. The SSP value only exists in volatile memory and that value vanishes when the SoC 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.5) . 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. 11.2. Administrator Guidance 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. 11.3. Non-Administrator Guidance The module implements only the Crypto Officer. There are no requirements for non-administrator operators. © 2025 Advanced Micro Devices (AMD), atsec information security.

24 of 27

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

25 of 27

A. Glossary and Abbreviations AES                 Advanced Encryption Standard CAVP                Cryptographic Algorithm Validation Program CMVP                Cryptographic Module Validation Program DRBG                Deterministic Random Bit Generator FIPS                Federal Information Processing Standards KAT                 Known Answer Test NIST                National Institute of Science and Technology OS                  Operating System PAA                 Processor Algorithm Acceleration PKCSPSS             Public-Key Cryptography Standards Probabilistic Signature Scheme PSP                 Public Security Parameter RSA                 Rivest, Shamir, Addleman SHA                 Secure Hash Algorithm SHS                 Secure Hash Standard © 2025 Advanced Micro Devices (AMD), atsec information security.

26 of 27

B. References Implementation Guidance for FIPS 140-3 and the Cryptographic Module Validation Program. (2022, March 14). Implementation Guidance for FIPS 140-3 and the Cryptographic Module Validation Program. Retrieved 03 8, 2021, from https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/ documents/fips 140-3/FIPS 140-3 IG.pdf National Institute of Standards Technology. (2019, March). FIPS PUB 140-3. Security Requirements for Cryptographic Modules. FIPS PUB 140-3. Security Requirements for Cryptographic Modules. Retrieved from https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf FIPS PUB 180-4. Secure Hash Standard (SHS). (2012, March). FIPS PUB 180-4. Secure Hash Standard (SHS). Gaithersburg, MD 20899-8900: National Institute of Standards & Technology. Retrieved from http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf FIPS PUB 186-4. Digital Signature Standard (DSS). (2013, July). FIPS PUB 186-4. Digital Signature Standard (DSS). https://doi.org/10.6028/NIST.FIPS.186-4. doi:https://doi.org/10.6028/NIST.FIPS.186-4 ISO/IEC. (2012, August). ISO/IEC 19790:2012 Information technology

• Security techniques
• Security requirements for cryptographic modules. ISO/IEC 19790:2012 Information technology
• Security techniques
• Security requirements for cryptographic modules. Retrieved from https://www.iso.org/standard/52906.html ISO/IEC. (2017, March). ISO/IEC 24759:2017 Information technology
• Security techniques
• Test requirements for cryptographic modules. ISO/IEC 24759:2017 Information technology
• Security techniques
• Test requirements for cryptographic modules. Retrieved from https://www.iso.org/standard/72515.html © 2025 Advanced Micro Devices (AMD), atsec information security.

27 of 27