CryptoManager Root of Trust RT-660

Certificate

Approved Algorithms (49)

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

flowchart LR
  %% Deterministic review-risk graph for CryptoManager Root of Trust RT-660
  %% 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>status output<br/>Self-Test</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>bootloader<br/>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 CryptoManager Root of Trust RT-660
  %% 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>status output<br/>Self-Test</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>bootloader<br/>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

Rambus Inc. CryptoManager Root of Trust RT-660 Last update: July 2024 Prepared by: atsec information security corporation

4516 Seton Center Parkway, Suite 250

Austin, TX 78759 www.atsec.com

Rambus Inc. North First Street, Suite 100 San Jose, CA 95134 United States of America https://www.rambus.com/ ©2024 Rambus Inc. / atsec information security corporation This document can be Rambus® is registered trademark of Rambus Inc. © 2024 Rambus Inc. / atsec information security.

3 of 37

This document is the non-proprietary FIPS 140-3 Security Policy for the CryptoManager Root of Trust RT-660 cryptographic module from Rambus®. It contains a specification of the 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 This document provides all tables and diagrams (when applicable) required by NIST SP 800-140B. The column names of the tables follow the template tables provided in NIST SP 800-140B.

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 © 2024 Rambus Inc. / atsec information security.

4 of 37

The CryptoManager Root of Trust RT-660 cryptographic module (hereafter referred to as “the module” or "CMRT") is a sub-chip hardware module and its embodiment is of the type of single chip. The primary application is to provide Root-of-Trust capabilities to SoCs, where authentication, encrypted content processing using standard protocols, and protection of keys and other sensitive assets are required. CMRT is suited to a wide range of products from low power battery powered devices such as mobile phones, tablets, and wireless handsets, to automotive and AI/ML accelerators. Tested Module Identification – Hardware: Table 2 - Cryptographic Module Tested Configuration CMRT is primarily integrated in the design of Application Specific Integrated Circuits (ASIC). However, it can also be configured in a Field Programmable Gate Array (FPGA). For the purpose of this Cryptographic Module Validation, CMRT is configured and tested on the Xilinx Zynq XC7Z045 FPGA chip soldered into a Xilinx ZC706 base board, which belongs to the Zynq-7000 All Programmable SoC (System on a Chip) series. Modes of Operation The module does not require any installation, configuration or initialization steps. Once the module is power on and the self-tests are successful, the module becomes operational and transitions to approved mode automatically. The mode of operation is assumed based on the service invoked i.e., the module switches back and forth between approved and non-approved modes based on the service called. By default, the module is in approved mode. The non-approved mode of operation is entered when the module utilizes non-approved security functions in Table 9. The module switches back to approved mode of operation when the approved service in Table 8 is called. Algorithms Table 3 lists all security functions of the module, including specific keys employed for approved services, and implemented modes of operation. © 2024 Rambus Inc. / atsec information security.

5 of 37

© 2024 Rambus Inc. / atsec information security.

6 of 37

Table 3 - Approved Algorithms The module does not implement any Non-Approved Algorithms Allowed in the Approved Mode of Operation with or without security claimed. © 2024 Rambus Inc. / atsec information security.

7 of 37

Table 4 lists Non-Approved security functions that are not Allowed in the Approved Mode of Operation: Table 4 - Non-Approved Algorithms Not Allowed in the Approved Mode of Operation Hardware module Photograph The module physical boundary is defined by the FPGA perimeter. Figure 1: Xilinx Zynq XC7Z045 FPGA Block Diagram Figure 2 provides a block diagram in which the CMRT (RT-660) is configured: a FPGA with one or more CPUs that connects to a common bus system. © 2024 Rambus Inc. / atsec information security.

8 of 37

SRAM IFC ROM (SOG)

UPM

Off-Chip Peripherals

Xilinx ZYNQ 7045 FPGA – Physical Cryptographic Boundary RT-660 Security Boundary OTP APB RT-660                    NV Management Power Supply cm_sys_inApprovedMode cm_sys_InitDone Core (NMC) sys_cm_enterApprovedMode                                                                                           cm_sys_haltstate cm_sys_lifecycle[31:0] cm_sys_lifecycleValid System Aperture ROM         MPU                           Core (SAC) AXI AXI System Interface       AHB        AHB sys_cm_Clk                 Reset/Boot Ctl                              Core (SIC) SDRAM sys_cm_POResetn                                                                                             APB Timer                                  AES Engine                                Off-Chip                  FLASH sys_cm_HResetn                                                                                                      Peripherals I/O Int Control                              Hash Engine 1 Int, Status   cm_sys_Interrupt[7:0] sys_cm_Interrupt[7:0] Support                       Hash Engine 2 Bus Fabric cm_cyc_CSYSAck                 RISC-V CPU cm_sys_CAc ve                               Block                                                         cm_sys_crdKeyValid PK Engine                      cm_sys_crdKeyDest[3:0] crdSramLS_b crsSramDS_b                                                                                            cm_sys_crdKeyBlockTotalNum[7:0] Power                                 Key Deriva on Core sys_cm_CSysReq                                                                                             cm_sys_crdKeyBlockIden fier[7:0] Management                                    (KDC) cm_sys_crdKeyData[127:0] Core (PMC) Key Transport Core                 cm_sys_crdKeyMetaData[63:0] (KTC)                       sys_cm_crdKeyConsumed Error Aggregator                                                             jtag_TDO sys cm alarms[7:0]                 Core (EAC) Test/Debug                       jtag_DRV_TDO cm_sys_DebugUnlock[127:4] Canary Core                                                                jtag_TCK (CC)                                TRNG Management                     jtag_TDI Core (TMC)                       jtag_TMS cm_sys_FeatureOut[31:0]                 GPIO/FMC                                                                  jtag_TRSTn jtag_mfr_id[10:0] TRNG       cm sys tst fro clk out TRNG              FROs DMAC                                             Test, Char & Valida on I/F TRNG Test, Char and Valida on Interface are disabled Figure 2 – Module Physical boundary, Module Cryptographic boundary, components and interfaces In the block diagram, the physical boundary of the single chip is outlined with the black rectangle and the sub-chip cryptographic sub-system boundary, is outlined with the red rectangle. The white boxes represent the CMRT components that comprise the IP cores (the CMRT firmware is stored in Program ROM and Program RAM). The yellow boxes represent components that are provided in the IP core but must be replaced or adjusted during the configuration process as they are technology dependent (OTP, SRAM, TRNG FROs). Also, the block diagram Figure 2 shows the details of all interfaces and the first hierarchy levels of the CMRT RTL. The greyed-out module components and interfaces are for testing purpose only (like jtag_ pins) and are disabled for the end user of the module. Algorithm Specific Information Hash core: The Hash Core 1 (2) are components integrated in the modules' cryptographic boundary as shown in the block diagram with blocks "Hash Engine 1" and “Hash Engine 2" respectively. Hash Core (HC1) supports SHA2-224, SHA2-256, SHA2-384, SHA2-512, © 2024 Rambus Inc. / atsec information security.

9 of 37

SHA3-224, SHA3-256, SHA3-384, SHA3-512 and corresponding HMAC. Hash Core (HC2) supports SHA2-224, SHA2-256, SHA2-384, SHA2-512, SHA2-512/224, SHA2-512/256 and corresponding HMAC. The KATs are run by the RAM firmware self-tests on both cores. The HC1 is selected by default and the user can select HC2 based on service input parameter. The algorithms implemented in each HC and higher-level algorithms with the approved hash have their own ACVP certificates (See Table 3) per IG C.B. AES-GCM: CMRT is compliant with scenario 2 of FIPS 140-3 IG C.H in [FIPS140-3_IG]. The internal IV is generated in the encryption operation using the RBG-based construction method as defined in section 8.2.2 of [SP800-38D]. The IV length is 96 bits; and the IV is generated from the random data obtained from the CTR_DRBG implemented in the module. © 2024 Rambus Inc. / atsec information security.

10 of 37

FPGA Power port

Power Interface

interface is used to receive commands from one or more host CPU and send the appropriate response. The master interface is used for autonomous data reads and writes from and to an external memory, flash or interface. Additionally, CMRT includes physical ports for showing the crypto module status via Table 5 describes all the cryptographic module’s interfaces. There is a mapping between the physical ports and the corresponding logical interfaces with the data that pass over them. sys_cm_alarms[7:0] Control Input Alarm signals from the Host SoC to RTcm_sys_lifecycle[31:0] cm_sys_FeatureOut[31:0] Bus Master (Write) Data Output (Key Transport Data for KTC transfer. KTC is a dedicated cm_sys_crdKeyValid Core -KTC) secure interface to deliver keys to the cm_sys_crdKeyDest[3:0] Host SoC. cm_sys_crdKeyData[127:0] cm_sys_crdKeyMetaData[63:0] Bus Master (Read) Control Input (Key Transport Control signals for KTC transfer sys_cm_crdKeyConsumed Core) Table 5 - Ports and Interfaces All data output via the Data Output interfaces is inhibited during zeroization and preoperational self-tests. © 2024 Rambus Inc. / atsec information security.

11 of 37

The module provides a role-based authentication with session management. Cryptographic Officer (with role identifier CO) role and User role (2 different users can be created, with role identifier U0 to U1) are supported and all services require an authorized role. No concurrent operators are supported. Table 6 describes the authorized role(s) in which the service can be performed with

2 The generated key is stored within the module and not output as part of service

3 The internally generated shared secret is used for approved service and the imported shared secret is used

for non-approved service. © 2024 Rambus Inc. / atsec information security.

12 of 37

Table 6 - Roles, Service Commands, Input and Output

Except for Hard Reset, the Login service must be executed before any other CMRT services can be requested. After logging in, an operator (Crypto Officer or U0 to U1 User) may assume a different role only after logging out followed by logging back in as the different role. The process to login is divided into two main stages: the initialization stage is included in the below bullets 1,2,3; the finalization stage is included in the below bullets 4,5. Precisely, during login the following happens:

1. An entity accessing the module requests a role identifier (CO or U0 to U1 User) and provides the ECDSA P-256 public key (the role authentication key) and 128-bit nonce.
2. The module calculates SHA2-256 hash of the public key and compares it to the value found in the OTP root table for the requested role. If the role hasn’t been

4 Internally generated EC Diffie-Hellman private key is used for approved ECDH services and imported EC

Diffie-Hellman private key is used for non-approved ECDH services. © 2024 Rambus Inc. / atsec information security.

13 of 37

created, or the hash of the public key doesn’t match the value expected, an error is returned.

3. If the hash of the public key matches the values found in the OTP root table, the module returns the session identifier and its own 128-bit nonce.
4. The entity accessing the module then returns the signature using SHA2-256 on the The purpose of this signature is to prove that the entity is in possession of the
5. The module verifies the provided signature using the provided public key. Upon successful signature verification, the authentication succeeds. If the signature verification fails, an error is returned. At power-on of the module, the CO is the only available role and only the CO can create up to two new users. cycle (new login is required).

Table 8 lists the approved services supported by the module. Each service provides an security services, this bit is set and the indicator sent back to the caller is 1. © 2024 Rambus Inc. / atsec information security.

14 of 37

5 If the key generation service is requested to return prime factors then resulting key will be identified by the

module as “RSA-PF” instead of just “RSA” in all other cases. © 2024 Rambus Inc. / atsec information security.

15 of 37

© 2024 Rambus Inc. / atsec information security.

16 of 37

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. © 2024 Rambus Inc. / atsec information security.

17 of 37

E = Execute: The module uses the SSP in performing a cryptographic operation. Z = Zeroise: The module zeroises the SSP.

Table 9 lists the non-approved services supported by the CryptoManager Root of Trust RT-660 module that can only be used in the non-Approved mode of operation. The indicator bit 31 of the service return code for non-approved services output a 0. Table 9 - Non-Approved Services © 2024 Rambus Inc. / atsec information security.

18 of 37

The integrity tests (EDC and approved integrity techniques) are listed in section 10.1.1 below. Integrity tests are performed as part of the Pre-Operational Self-Tests.

The module provides the Hard Reset service to perform self-tests on demand. PreOperational Self-Tests can also be performed by powering off and powering on the module.

Verilog RTL has been used as hardware design language for hardware components. The First Stage Bootloader (fboot), Second Stage Bootloader (sboot) and the Application Firmware are written in C language. The module includes the following executable codes:

• First-stage bootloader realized in a sea-of-gates (located in the Program ROM)
• Second-stage bootloader binary executable code (sboot) located in OTP
• Application Firmware binary executable (Supervisor Application) running in RAM © 2024 Rambus Inc. / atsec information security.

19 of 37

The module operates in a non-modifiable environment and is validated at a Security Level

2 in Physical Security. Once the module is operational, it does not allow the loading of any

additional software or firmware. There are no further requirements for this security area. © 2024 Rambus Inc. / atsec information security.

20 of 37

The module is a sub-chip hardware module configured in a Xilinx Zynq XC7Z045 FPGA and is defined as a single-chip embodiment. serves as a protective shell for the processing silicon chip. The IHS lid, the substrate with provide opacity in the visible spectrum. Table 10 - Physical Security Inspection Guidelines © 2024 Rambus Inc. / atsec information security.

21 of 37

Until NIST SP 800-140F that replaces the ISO/IEC 19790:2012 Annex F defines the noninvasive security mechanisms, the non-invasive mechanisms per IG 12.3 are addressed in the below section 12 "Mitigation of other attacks". The non-invasive Security area is N/A. © 2024 Rambus Inc. / atsec information security.

22 of 37

) e e © 2024 Rambus Inc. / atsec information security.

23 of 37

6 Although the module supports imported EC Diffie-Hellman key pair it is not used by approved services and

hence is not considered as CSP. As listed in the table 9 EC Diffie-Hellman using imported key pair is indicated as non-approved. © 2024 Rambus Inc. / atsec information security.

24 of 37

) Table 11 – SSPs From above table, the module manages two different types of assets: static and dynamic. Static assets are stored in the non-volatile memory file in the OTP filesystems and dynamic asset are stored in the memory file of the SRAM filesystems. Assets are stored in plaintext within the module and protected from unauthorized disclosure and modification.

CMRT includes a Deterministic Random Bit Generator based on the CTR_DRBG (with and without prediction resistance; with derivation function) algorithm and AES-256 as the underlying cipher according to [SP800-90ARev1]. CMRT uses this engine to:

• Generate symmetric keys in OTP and SRAM memories with the Generate Symmetric Key service.
• Generate asymmetric keys in OTP and SRAM memories with the Generate EC Key Pair or Generate RSA Key Pair services.
• Provide random data with the Get TRNG service. CMRT includes a [SP800-90B] compliant True Random Number Generator (TRNG) to provide entropy input to the CTR_DRBG. This TRNG automatically seeds the CTR_DRBG, as part of the TRNG Management Core (TMC) driver initialization process. This process includes the gathering of enough entropy. After the initialization process, the Crypto Officer and U0 to U1 (User) can use the Get TRNG service to obtain random numbers from the TMC. The CTR_DRBG provides 256 bits of security strength. The module also performs CTR_DRBG health tests according to section 11.3 of [SP80090ARev1]. Table 12 describes the Entropy Source available in CMRT, called ENT (P). © 2024 Rambus Inc. / atsec information security.

25 of 37

Table 12 - Non-Deterministic Random Number Generation Specification

The symmetric and asymmetric key generation methods (vendor affirmed) implemented in the module are compliant with [SP800-133Rev2] section 4 example 1.

• CMRT implements symmetric key generation for AES and HMAC keys using random data (Random in Generation column Table 11) obtained from the SP800-90ARev1 compliant CTR_DRBG. The method in in accordance with SP800-133r2 section 6.1 i.e. the Direct Generation of Symmetric Keys.
• RSA and Elliptic Curve DSA (ECDSA) asymmetric key pairs are generated in accordance with [SP800-133Rev2] section 5.1 i.e. which maps to FIPS 186-4. A seed (i.e. the random value) used in asymmetric key generation is obtained from
• Elliptic Curve Diffie-Hellman key pairs are generated in accordance with [SP800133Rev2] section 5.2 i.e. key generation method specified in [SP800-56ARev3] section 5.6.1.2. used by approved key-establishment schemes which maps to FIPS 186-4. CMRT implements key derivation methods (KDF in Generation column Table 11, in compliance with [SP800-108Rev1] and [SP800-56CRev2] one step and two step KDF) based on a HMAC-SHA-256 counter mode PRF that uses a shared secret and keyderivation key to generate symmetric and HMAC keys. The symmetric generated key is compliant with [SP800-133Rev2] section 6.2.2. The [SP800-56CRev2] one step and two step KDF use a shared secret computed with ECDSA and EC Diffie-Hellman key pair internally generated by the module. Intermediate key generation values are not output from the cryptographic module during or after processing the service.

There is no manual key import or export method used in the module. Symmetric key, HMAC key, asymmetric key pair and secret assets are imported (Import Key service) and exported (Export Key service) encrypted with the AES-KWP [SP 80038F]. The AES key-wrapping-key used by the AES-KWP algorithm cannot be exported by any methods. In addition, the module offers KTC port to output symmetric key, and HMAC key using the service Key Output. The keys are output in plaintext from the module through the KTC interface.

Assets are stored upon creation with data structures related to asset storage location (SRAM filesystem or OTP filesystem), asset name, asset type and usage policy, asset ownership and asset data (key and SSPs). When invoking an asset creation service, the asset ownership is matching the logged-in role (CO or U0 to U1 User). If there is a © 2024 Rambus Inc. / atsec information security.

26 of 37

mismatch between the login role and the service requested, the service is stopped and an error is returned. Once an asset is created, the ownership and usage attributes of the asset remain until the asset is deleted or the asset filesystem is zeroized. The asset usage is exclusively reserved for the owner of the asset and only the owner of the asset has access it to. The only exception is when an asset is specifically created with the attribute "FIPS_OWNER_ALL" in which case both CO and User roles can access it. Note however that only CO can create such asset. The crypto officer can move any dynamic asset. A User can only move its own dynamic assets. The crypto officer can delete any asset. A User can only delete its own assets.

CMRT provides the EC Diffie-Hellman key agreement scheme compliant with [SP80056ARev3] and scenario 2 of IG D.F

• path (1) EC Diffie-Hellman SSC with ephemeral Unified scheme and
• path (2) EC Diffie-Hellman SSC with ephemeral Unified scheme followed by key derivation with [SP800-56CRev2] compliant using one-step or two step KDF. The key agreement scheme provides between 112 to 256 bits of security strength. The key agreement scheme uses EC Diffie-Hellman key pairs internally generated by the module. The usage of imported EC Diffie-Hellman / ECDSA key pair is considered a nonapproved service. CMRT also provides key wrapping. As explained in section 9.3, keys can be entered in encrypted form through the key wrapping method using AES in KWP mode [SP800-38F] with keys between 128 to 256 bits, compliant with IG D.G approved Key Transport Method. SSP establishment methodology (AES key wrapping) provides between 128 and

It is the user’s responsibility to use the establishment method with an appropriate key size to ensure FIPS compliance. Using an insufficient AES key size for AES Key Wrapping or an insufficient EC Diffie-Hellman key size for KAS will reduce the security strength of the wrapped key or the established secret/ derived key respectively.

A dynamic asset is deleted from the SRAM filesystem using the Delete Dynamic Asset service executed by the owner of the asset. This service can also be executed by the crypto officer on any of the assets. The SRAM filesystem and all the dynamic assets that it contains are zeroized following the execution of the Zeroize service with parameter “FIPS_ZEROIZE_DYNAMIC”. This service can only be executed by the crypto officer. In addition, when the module is hard reset or powered off, all the dynamic assets of the SRAM filesystem are deleted. A static asset is deleted from the OTP filesystem using the Delete Static Asset service executed by the owner of the asset. This service can also be executed by the crypto officer on any of the assets. The OTP filesystem and all the statics assets that it contains are zeroized following the execution of the Zeroize service with parameter “FIPS_ZEROIZE_STATIC”. The static memory becomes unusable. The process is not reversible and is ending the life of the module. The program RAM is still running. This service can only be executed by the crypto officer. © 2024 Rambus Inc. / atsec information security.

27 of 37

The filesystems and all the assets that they contain are zeroized following the execution of the Zeroize service with parameter “FIPS_ZEROIZE_ALL”. The execution of this service is the secure sanitization of the module and corresponds to the decommissioned of the module lifecyle. The module is no more functional after the execution of the service. This service can only be executed by the crypto officer. Zeroization of assets is performed by writing zeroes (in the case of dynamic assets) and ones (in the case of static assets) to the SRAM or OTP location of the asset. Zeroization of the SRAM filesystem is performed by writing zeroes to each word present in the SRAM buffer. Zeroization of the OTP filesystem and root table is performed by writing ones to each word present in the OTP storage area. The operation is performed in a time that is not sufficient to compromise SSPs. Additionally, the module processes one input message at a time: when a Zeroization or Delete Asset service is processed no other input message accessing the asset storage filesystems can be executed. Finally, temporary SSPs generated for use during other services are zeroized when they are no longer needed, by overwriting the memory location of the SSPs with zeroes. The zeroization indicator is provided by the Zeroize service. When the Zeroize service is called, its return value indicates the output status. If the return value is 0, the zeroization has completed successfully. Otherwise, the zeroization has not completed successfully. When temporary SSPs are generated and zeroized during a service of this module, this is implicitly indicated by the successful completion of this service. © 2024 Rambus Inc. / atsec information security.

28 of 37

After successful installation of the FPGA in which CMRT is configured, the CMRT automatically performs the initialization process. During initialization the pre-operational self-tests are performed without user intervention to ensure that the module is not corrupted and that the cryptographic algorithms within the module work as expected. During the execution of the self-tests, services are not available and no data output is possible. If the pre-operational self-tests succeed, then the CMRT proceeds with performing conditional algorithm self tests as specified in section 10.2.1. If the pre-operational selftests fail, then CMRT transitions to the Error state and a corresponding error indication is given. CMRT permits the initiation of the pre-operational or conditional self-tests on demand for periodic testing of the module. In order to perform the on demand self-tests that initiates the firmware integrity tests and KATs, the Crypto Officer shall power-off and power-on or do a hard reset of the module. The Self-tests service listed Table 8 performs all the KATs of the firmware application loaded in RAM.

The integrity tests are performed for fboot (first stage bootloader), sboot (second stage bootloader), RAM firmware image (the application firmware). At power-on, the following happens: 1. the ROM integrity is checked automatically by a hardware 32 bit CRC 2. if the integrity check succeeds, the fboot, located in ROM, is executed and the KAT SHA2-256 is performed 3. if the KAT succeeds, the integrity of sboot, located in OTP, is checked by computing the SHA2-256 hash digest of the sboot firmware and compared to the value stored in OTP 4. if the integrity check succeeds, sboot is executed and the SHA2-256 and ECDSA KATs are performed 5. if the KATs succeed, the signature of the RAM firmware image (stored in the footer of the image) is verified using ECDSA P-256 with SHA-256 6. if this integrity test succeeds, the rest of the CASTs located in the application firmware is performed If one of the KATs or integrity checks fail, the CMRT transitions to the Error state and a corresponding error indication is given. SP800-90B health tests (APT and RCT) are performed at start-up on 1,024 samples and at runtime.

If one of the Conditional Tests fail, the CMRT transitions to the Error state and a corresponding error indication is given.

After successful completion of the pre-operational self test, the module automatically performs all cryptographic algorithm self tests listed in the below table without any user intervention. The CASTs consist in Known Answer Tests for all the approved cryptographic © 2024 Rambus Inc. / atsec information security.

29 of 37

algorithms including their separate implementations (HC1 and HC2) and SP800-90ARev1, m 2) © 2024 Rambus Inc. / atsec information security.

30 of 37

CMRT performs Pairwise Consistency Tests for generated RSA and EC keypairs. Both EC and RSA key pair generation are tested by the generation and verification of a digital signature using newly generated keys. This is compliant with IG 10.3.A Additional Comment 1.

Table 14 - Error States From Table 14 there are two options to clear the Error state: Both actions will cause the assets in the SRAM (dynamic assets) to be zeroized. The module has to be restarted to return to the operational state. © 2024 Rambus Inc. / atsec information security.

31 of 37

CMRT configured in the Xilinx Zynq XC7Z045 FPGA is a single chip hardware module. The chip is delivered from the vendor via a trusted delivery courier. Upon reception of CMRT, the customer should verify that the package does not have any irregular tears or openings. The delivery packages (HW: 950-660931-13 and FW: 951-602931-131) directly map the module HW and FW versions. When the CMRT module is delivered as part Xilinx Zynq XC7Z045 FPGA with the above listed module versions, the signals greyed out in Figure 2 are disabled and cannot be enabled again. Customers who intend to purchase the soft IP core to be added to their own SoC should note that these signals can be enabled by updating the RTL code in order to facilitate module testing before finalizing the production version. Specifically, TRNG test, Char & Validation I/F when enabled through RTL code, can be used to allow exercising specific test features for algorithm testing and trigger error for the purposes of functional testing during FIPS validation.

Rambus provides the following documentation part of the delivered module's package:

• RT-660 CryptoManager RoT External Ref Spec [Last Revision May27.2021; 007660130-222/914]
• CMRT RT-660 FPGA Hardware Reference Manual [Version: 1.0; Doc Number: 007660130-412/931]
• RT-660
• FIPS 140-3 Embedded Software Architecture Specification [Version 1.02; Last Revision Novembter15, 2021; Doc Number: 005-660130-320/931]
• CMRT HLOS Programmer's Guide [007-602131-321/911 Rev B, 2021-08-31]

The module is configured as a FIPS140-3 module at factory for the Xilinx Zynq XC7Z045 FPGA tested implementation. In this FPGA configuration the Crypto Officer should execute the "Show Status" service to verify:

• the hardware version output as BUILDER_VERSION = 0x60000931
• the firmware version output as Sboot version: 2022-02-24-g801c166
• the supervisor version output as 2022-02-24-g801c166
• the module approved mode status output as "FIPS Mode: 1" The hash value of the Crypto Officer’s authentication key is provisioned in the OTP root table. Once the CO is authenticated, they can call the “Create User” service to add two new Users (U1, U2).

The module is operating in approved mode, using the approved services listed in section

© 2024 Rambus Inc. / atsec information security.

32 of 37

The Crypto Officer shall consider the following requirements and restrictions when using the module. • AES-GCM see section 2. © 2024 Rambus Inc. / atsec information security.

33 of 37

The module is designed to mitigate side-channel attacks which involve statistically analyzing power consumption measurements and injection of fault. The module supports Differential Power Analysis (DPA) protections and Fault Injection Attack (FIA) protections as countermeasures to mitigate those attacks. © 2024 Rambus Inc. / atsec information security.

34 of 37

Appendix A. Glossary and Abbreviations AES          Advanced Encryption Standard CAVP          Cryptographic Algorithm Validation Program CBC          Cipher Block Chaining CFB          Cipher Feedback CMAC           Cipher-based Message Authentication Code CMVP           Cryptographic Module Validation Program CTR          Counter Mode DSA          Digital Signature Algorithm DRBG           Deterministic Random Bit Generator ECB          Electronic Code Book ECC          Elliptic Curve Cryptography FIPS          Federal Information Processing Standards Publication FSM          Finite State Model GCM           Galois Counter Mode HMAC           Hash Message Authentication Code KAS          Key Agreement Scheme KAT          Known Answer Test KDF          Key Derivation Function KWP           AES Key Wrap with Padding MAC           Message Authentication Code NIST          National Institute of Science and Technology OFB          Output Feedback PR          Prediction Resistance PSS          Probabilistic Signature Scheme RNG           Random Number Generator RSA          Rivest, Shamir, Addleman SHA          Secure Hash Algorithm SHS          Secure Hash Standard SSP          Sensitive Security Parameter © 2024 Rambus Inc. / atsec information security.

35 of 37

Appendix B. References FIPS140-3 FIPS PUB 140-3 - Security Requirements For Cryptographic Modules March 2019 https://doi.org/10.6028/NIST.FIPS.140-3 FIPS140-3_IG Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program https://csrc.nist.gov/Projects/cryptographic-module-validation-program/fips-140-3-igannouncements FIPS180-4 Secure Hash Standard (SHS) August 2015 http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf FIPS186-4 Digital Signature Standard (DSS) July 2013 http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf FIPS197 Advanced Encryption Standard November 2001 http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf FIPS198-1 The Keyed Hash Message Authentication Code (HMAC) July 2008 http://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf FIPS202 SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions August 2015 http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf PKCS#1 Public Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 February 2003 http://www.ietf.org/rfc/rfc3447.txt RFC3394 Advanced Encryption Standard (AES) Key Wrap Algorithm September 2002 http://www.ietf.org/rfc/rfc3394.txt RFC5649 Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm September 2009 http://www.ietf.org/rfc/rfc5649.txt SP800-38A NIST Special Publication 800-38A - Recommendation for Block Cipher Modes of Operation Methods and Techniques December 2001 http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf SP800-38B NIST Special Publication 800-38B - Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication May 2005 http://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf SP800-38D NIST Special Publication 800-38D - Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC November 2007 http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf SP800-38F NIST Special Publication 800-38F - Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping December 2012 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf © 2024 Rambus Inc. / atsec information security.

36 of 37

SP800- NIST Special Publication 800-56A Revision 3 - Recommendation for PairWise Key 56ARev3 Establishment Schemes Using Discrete Logarithm Cryptography April 2018 https://doi.org/10.6028/NIST.SP.800-56Ar3 SP800- Recommendation for Key Derivation through Extraction-then-Expansion 56CRev2 August 2020 https://doi.org/10.6028/NIST.SP.800-56Cr2 SP800- NIST Special Publication 800-90A - Revision 1 - Recommendation for Random Number 90ARev1 Generation Using Deterministic Random Bit Generators June 2015 http://dx.doi.org/10.6028/NIST.SP.800-90Ar1 SP800-90B (Second DRAFT) NIST Special Publication 800-90B - Recommendation for the Entropy Sources Used for Random Bit Generation January 2016 http://dx.doi.org/10.6028/NIST.SP.800-90B SP800- NIST Special Publication 800-108 - Recommendation for Key Derivation Using 108Rev1 Pseudorandom Functions August 2022 https://doi.org/10.6028/NIST.SP.800-108r1 SP800-133r2 NIST Special Publication 800-133 Revision 2 - Recommendation for Cryptographic Key Generation June 2020 http://dx.doi.org/10.6028/NIST.SP.800-133r2 SP800-140B NIST Special Publication 800-140B - CMVP Security Policy Requirements March 2020 http://dx.doi.org/10.6028/NIST.SP.800-140B © 2024 Rambus Inc. / atsec information security.

37 of 37