VaultIP RT-130

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for VaultIP RT-130
  %% 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/>No authentication</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 VaultIP RT-130
  %% 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/>No authentication</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

Rambus Inc. VaultIP RT-130 Prepared by: Prepared for: atsec information security corporation Rambus Inc.

4516 Seton Center Parkway, Suite 250 4453 North First Street, Suite 100

Austin, TX 78759 San Jose, CA 95134 www.atsec.com www.rambus.com

©2024 Rambus Inc. / atsec information security.

This document is the non-proprietary FIPS 140-3 Security Policy for the Rambus VaultIP RT-

130 cryptographic module (hereafter referred to as “the module” or RT-130 or only VaultIP).

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 Publication 140-3) for a Security Level 2 module.

VaultIP is a Silicon IP Security Module which includes a complete set of high-level and lowlevel cryptographic functions. It offers key management and crypto functions needed for platform and application security such as Content Protection and Mobile Payment, and can be used stand-alone or as a 'Root of Trust' to support a Trusted Execution Environment-based platform. VaultIP completely shields all key and security sensitive data from all CPUs, interfaces and memory. Security sensitive materials are stored as assets that never leave VaultIP in unencrypted and/or non-authenticated form. Additionally, VaultIP offers hardware security features that are needed when operating in a Trusted Execution Environment (TEE). These features include One-Time-Programmable memory (OTP) access and management, Random Number Generation / entropy source, timers, (short) monotonic/non-volatile counters and import and export of keys and other assets. ©2024 Rambus Inc. / atsec information security.

The module provides a slave and a master interface. The slave interface is used to receive commands from one or more host CPUs. The master interface is used for autonomous data reads and writes from and to an external memory, flash or interface. VaultIP supports many Approved or Allowed cryptographic algorithms. ©2024 Rambus Inc. / atsec information security.

Purpose and Use: The primary application of VaultIP is in mobile communications and consumer electronics appliances, where authentication, encrypted content processing using standard protocols, and protection of keys and other sensitive assets are required. VaultIP is best suited for mobile phones, tablets, wireless handsets, PDA-like devices and set top boxes that have the resources and connectivity to download, store and play back digital media content. These small, battery-powered devices require a low power IP solution with these features available in VaultIP. VaultIP is primarily aimed to be integrated in the design of Application-Specific Integrated Circuits (ASIC). However, it can also be synthesized in a Field-Programmable Gate Array (FPGA). Module Type: Hardware Module Embodiment: SingleChip Module Characteristics [O]: SubChip Cryptographic Boundary: The block diagram in Figure 2 shows the cryptographic module boundary represented with the red line box and the physical boundary shown as the most external thick black line. The orange and grey boxes represent the VaultIP components that comprise the IP core. The VaultIP firmware is stored in Program ROM and Program RAM. Figure 2 shows the details of interfaces that cross the security boundary. Tested Operational Environment’s Physical Perimeter (TOEPP): For the purpose of this Cryptographic Module Validation, VaultIP is synthesized on the Xilinx Zynq XC7Z045 FPGA chip, which belongs to the Zynq-7000 All Programmable SoC series. The Xilinx ZC706 evaluation board for the XC7Z045 SoC provides the hardware environment for developing and evaluating the hardware design of VaultIP. Photograph and Block Diagram The module physical boundary is defined by the Xilinx Zynq XC7Z045 FPGA perimeter. The FPGA is a rectangular enclosure measuring approximately 31 mm x 31 mm x 3 mm. Figure 1 - Xilinx Zynq XC7Z045 FPGA The block diagram of the sub-chip module is shown below. ©2024 Rambus Inc. / atsec information security.

Figure 2: Block Diagram ©2024 Rambus Inc. / atsec information security.

Tested Module Identification

• Hardware: Table 2: Tested Module Identification
• Hardware

There are no components within the cryptographic boundary excluded from the FIPS 140-3 requirements.

Modes List and Description: Table 3: Modes List and Description Once the module is powered on and the self-tests are successful, the module becomes 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 when non-approved services are requested (Section 4.4). The module switches back to approved mode of operation when an approved service in Section 4.3 is called. The module implements the approved service indicator as described in Section 4.3.

Approved Algorithms: ©2024 Rambus Inc. / atsec information security.

©2024 Rambus Inc. / atsec information security.

©2024 Rambus Inc. / atsec information security.

©2024 Rambus Inc. / atsec information security.

Table 4: Approved Algorithms Vendor-Affirmed Algorithms: Table 5: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: Table 6: Non-Approved, Allowed Algorithms Non-Approved, Allowed Algorithms with No Security Claimed: ©2024 Rambus Inc. / atsec information security.

Table 7: Non-Approved, Allowed Algorithms with No Security Claimed ©2024 Rambus Inc. / atsec information security.

Table 8: Non-Approved, Not Allowed Algorithms

©2024 Rambus Inc. / atsec information security.

©2024 Rambus Inc. / atsec information security.

©2024 Rambus Inc. / atsec information security.

©2024 Rambus Inc. / atsec information security.

Table 9: Security Function Implementations

AES-GCM IV (IG C.H): VaultIP is compliant with scenario 2 of FIPS 140-3 IG C.H in [FIPS1403_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]. VaultIP generates an IV with a length of 96 bits, initialized with random data obtained from the SP800-90Ar1 DRBG implemented in the module. AES-XTS (IG C.I): The AES algorithm in XTS mode can be only used for the cryptographic protection of data on storage devices, as specified in [SP800-38E]. VaultIP implements a check to ensure that the two AES keys used in XTS-AES algorithm are not identical, meeting the requirement of FIPS 140-3 IG C.I in [FIPS140-3_IG]. SP800-56Ar3 assurances (IG D.F): To comply with the assurances found in Section 5.6.2 of SP 800-56Ar3, the keys for KAS-ECC must be generated using the approved key generation services specified in Section 2.9. The module performs full public key validation on the generated public keys. Additionally, the module performs full public key validation on the received public keys. If the module is used to perform key agreement with the “One-Pass Diffie-Hellman”, “Static Unified Model”, or “One-Pass Unified Model” schemes, a trusted third party is used to obtain the assurance of private key possession for the static peer public key. RSA modulus size (IG C.F): In compliance with FIPS 186-5, the RSA Signature Generation uses module sizes greater or equal to 2048 bits. The 1536 bits RSA is used in approved mode for FIPS 186-2 signature verification, the 1024-bit modulus is used in approved mode for FIPS 186-4 signature verification and the modulus size for FIPS 186-5 signature verification are

SP800-56Br2 assurances (IG D.G): The entity using the IUT must obtain required assurances listed in section 6.4 of SP 800-56Br2 as follows: • The entity requesting the RSA key unwrapping (un-encapsulation) service from the module, shall only use an RSA private key that was generated by an active FIPS validated module that implements FIPS 186-5 compliant RSA key generation service and performs the key pair validity and the pairwise consistency as stated in section

6.4.1.1 of the SP 800-56Br2. Additionally, the entity shall renew these assurances

over time by using any method described in section 6.4.1.5 of the SP 800-56Br2. Legacy use (IG C.M): Per SP800-131r2, the SHA-1 with FIPS 186-4 RSA and ECDSA Digital Signature Verification is used in approved mode (for legacy use), the FIPS 186-4 ECDSA Signature Verification with P-192 is used in approved mode (for legacy use), RSA Digital Signature Verification is used in approved mode (for legacy use) with 1024-bit or 1536-bit modulus. ©2024 Rambus Inc. / atsec information security.

Table 10: Entropy Certificates Table 11: 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 DRBG does not employ a derivation function. The DRBG is seeded and reseeded with 384 bits of entropy input (corresponding to 384 bits of entropy) provided from the entropy source inside the module. This corresponds to scenario 1 of IG 9.3.A. The module complies with the Public Use Document (URL provided in section 11.2) for ESV certificate E167 by reading entropy data from the SHA2-256 conditioning function, which corresponds to the conditioned GetEntropy() function. Outputs of multiple GetEntropy() calls are concatenated to receive the entropy input length greater than 256 bits. The output is truncated to get the entropy input string which is not a multiple of 256. The 384 bits of entropy source output is obtained by calling the GetEntropy() twice, with each call providing 256 bits of output. The second call output is truncated to 128 bits and concatenated to the 256-bit output from the first call. The operational environment on the ESV certificate is identical to the Xilinx Zynq XC7Z045 FPGA, in which the sub-chip components are contained. There are no maintenance requirements for the entropy source.

VaultIP provides services for generating symmetric and asymmetric keys compliant with [SP800-133r2] section 4 example 1 (vendor affirmed). VaultIP implements symmetric key generation for AES and HMAC keys (”Asset Load (random)” service), using random data obtained from a Deterministic Random Bit Generator (DRBG) compliant with [SP800-90Ar1]. VaultIP implements asymmetric key generation for ECDSA and EC Diffie-Hellman key pairs ("Key pair generation" service) with the following methods:

• ECDSA key pairs are generated in accordance with [SP800-133r2] section 5.1 which maps to [FIPS186-5] appendix A.3.1. A seed (i.e. the random value) used in asymmetric key generation is directly obtained from the [SP800-90Ar1] DRBG.
• EC Diffie-Hellman key pairs are generated in accordance with [SP800-133r2] section

5.2 i.e. key generation method specified in [SP800-56Ar3] section 5.6.1.2.1 used by

approved key-establishment schemes which maps to [FIPS186-5]. ©2024 Rambus Inc. / atsec information security.

Intermediate key generation values are not output from the cryptographic module during or after processing the service. VaultIP implements a key-based key derivation function (KBKDF) in Counter or Feedback modes ("Asset Load (derive)" service) using HMAC-SHA-256 or AES-CMAC [SP800-108r1upd1].

Vault IP also provides EC Diffie-Hellman key agreement compliant with [SP800-56Ar3] and using SHA-256 as a one-step key derivation function compliant with section 4.1 of [SP80056Cr2] according to scenario 2 path (2) of IG D.F. The key agreement scheme provides between 112 and 256 bits of security strength. VaultIP provides SSP transport to the dynamic assets entered in encrypted form:

• Key wrapping with AES-KWP, 128, 192 or 256-bit keys, compliant with [SP800-38F] and IG D.G. Security strength ranges from 128 to 256 bits.
• Key un-encapsulation with KTS-IFC and 2048, 3072-bit keys, compliant with [SP80056Br2] and IG D.G. Security strength is 112 or 128 bits.

The module does not implement any industry protocol. ©2024 Rambus Inc. / atsec information security.

Table 12: Ports and Interfaces The slave and master interfaces connect the VaultIP RT-130 to the AXI bus system. The slave interface is used to receive commands from one or more host CPUs 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. ©2024 Rambus Inc. / atsec information security.

Table 13: Authentication Methods The Crypto Officer role is initialized via the “Provision Random HUK” service, which accepts the 32-bit Login PIN and instructs the module to generate the Hardware Unique Key (HUK) and install the 32-bit Login PIN. The Login PIN is stored in One Time Programmable (OTP) memory and is protected against disclosure, modification, and substitution like any CSP. It cannot be altered except by zeroization of the whole OTP memory. After power-up, the module will require the authentication of the Crypto Officer role before allowing execution of most services (exceptions listed in the table below). Authentication is installation. If the comparison succeeds, then the Login service succeeds and the module is unlocked. Otherwise, the module enters the firmware error state and must be hard reset to allow a new authentication attempt. The Crypto Officer role is always authenticated, both in approved mode and non-approved modes of operation. No authentication data can be output by any of the available services.

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

s ©2024 Rambus Inc. / atsec information security.

s E ©2024 Rambus Inc. / atsec information security.

s E E E ©2024 Rambus Inc. / atsec information security.

s ©2024 Rambus Inc. / atsec information security.

s ©2024 Rambus Inc. / atsec information security.

s Z ©2024 Rambus Inc. / atsec information security.

s ©2024 Rambus Inc. / atsec information security.

s W W Z ©2024 Rambus Inc. / atsec information security.

s E ©2024 Rambus Inc. / atsec information security.

s G G G G G,E,Z G ©2024 Rambus Inc. / atsec information security.

s :E E E ©2024 Rambus Inc. / atsec information security.

s E E G,E,Z :E E ©2024 Rambus Inc. / atsec information security.

s Z Z Z Z Z ©2024 Rambus Inc. / atsec information security.

s :Z D D Table 15: Approved Services The following convention is used to specify access rights to SSPs:

• Generate (G): The module generates or derives the SSP.
• Write (W): The SSP is updated, imported, or written to the module.
• Execute (E): The module uses the SSP in performing a cryptographic operation. Each service utilizing approved security functions provides an indicator implemented as follows:
• Each service will return output parameters as part of an “output token”.
• Security-relevant services will include a field in the output token called the “FIPSApproved Service indication” (FAsvc). If the FAsvc bit is not present, the service is not
• If this bit is present and set, the service is considered approved. If the bit is present but not set, the service is considered non-approved.
• The Provision Random HUK service does not set the “FAsvc” bit in the output token; instead, it sets the “FIPSApproved” bit on the generated HUK as the service indicator.

©2024 Rambus Inc. / atsec information security.

©2024 Rambus Inc. / atsec information security.

Table 16: Non-Approved Services

Upon startup, the ROM firmware component loads the RAM firmware from external storage into the sub-chip cryptographic subsystem. The integrity of the RAM firmware is determined by verifying an ECDSA P-256 with SHA2-256 signature stored in the firmware that was computed at build time. If the signature verification fails, the firmware load test fails. The ©2024 Rambus Inc. / atsec information security.

public key used to verify this signature is provided with the RAM firmware, the private key associated with this public key is controlled by the vendor. The hash of the public key is compared with a hash value stored in ROM to ensure the authenticity of the provided public key. All data output is inhibited during the execution of the firmware load test and the firmware loading process. ©2024 Rambus Inc. / atsec information security.

The module employs a CRC24 as integrity technique to integrity verify the ROM code during startup.

Integrity tests are performed when the module is powered on. The integrity test can be performed on demand by powering off and powering on the module. ©2024 Rambus Inc. / atsec information security.

Type of Operational Environment: Non-Modifiable How Requirements are Satisfied: N/A ©2024 Rambus Inc. / atsec information security.

Table 17: Mechanisms and Actions Required The integrated heat spreader (IHS) serves as a protective shell for the processing silicon chip. Interface material (TMI) are production-grade components. They provide opacity in the visible spectrum. ©2024 Rambus Inc. / atsec information security.

The module does not implement any non-invasive security mechanisms. ©2024 Rambus Inc. / atsec information security.

Table 18: Storage Areas The Static Asset Store and Dynamic Asset Store maintain internal separation of the SSPs (including CSPs) in approved and non-approved modes of operation. Each asset internally maintains a "Fips Approved" bit which indicates if the asset can be used in an approved service or not. SSPs that are not stored in an Asset Store are only transiently used for a specific service. They are by definition exclusive between approved and non-approved services.

©2024 Rambus Inc. / atsec information security.

Table 19: SSP Input-Output Methods Table 20: SSP Zeroization Methods ©2024 Rambus Inc. / atsec information security.

SSP zeroization when overwriting RAM or OTP memory is performed without delay. Additionally, control is not returned to the operator until the zeroization is completed, preventing any potential compromise of the zeroized SSP. All data output is inhibited during zeroization. The Asset Delete, Zeroize OTP, and Dynamic Asset Store Reset services provide an explicit indicator when the service (i.e., zeroization) completes: Result output parameter. Automatic SSP zeroization is indicated to the operator by successful completion of the relevant service.

©2024 Rambus Inc. / atsec information security.

n n ©2024 Rambus Inc. / atsec information security.

©2024 Rambus Inc. / atsec information security.

n ©2024 Rambus Inc. / atsec information security.

Table 21: SSP Table 1 ©2024 Rambus Inc. / atsec information security.

©2024 Rambus Inc. / atsec information security.

©2024 Rambus Inc. / atsec information security.

©2024 Rambus Inc. / atsec information security.

©2024 Rambus Inc. / atsec information security.

The SHA-1 algorithm as implemented by the module will be non-approved for all purposes, starting January 1, 2030. ©2024 Rambus Inc. / 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 process service requests from the operator until the tests are completed.

Table 23: Pre-Operational Self-Tests automatically when the module is initialized. If this test fails, the module transitions to the Hardware Error state.

As part of the initialization, the ROM firmware component performs the SHA2-256 and ECDSA and performs the firmware load test on the RAM firmware. Only if these tests succeed, will the RAM firmware be executed. Finally, the RAM firmware automatically performs the rest of the CASTs listed in the table below, before transitioning to the operational state. If any of the tests state. ©2024 Rambus Inc. / atsec information security.

©2024 Rambus Inc. / atsec information security.

©2024 Rambus Inc. / atsec information security.

5) 5.6.2.1.4 Table 24: Conditional Self-Tests

©2024 Rambus Inc. / atsec information security.

Table 25: Pre-Operational Periodic Information ©2024 Rambus Inc. / atsec information security.

Table 26: Conditional Periodic Information

©2024 Rambus Inc. / atsec information security.

Name

Description encountered an error

Conditions load test failure CAST failure PCT failure DMA error

Recovery Method

Indicator MODULE_STATUS register

Table 27: Error States In the Hardware Error state, no firmware input or output is possible at all, only the hardware registers such as the MODULE_STATUS register. In the Firmware Error state, only the Show status, Show version and Hard Reset services are available. Cryptographic functions and data output are inhibited.

To perform the on-demand self-tests that includes the pre-operational self-tests and CASTs, the Crypto Officer shall power-off and power-on or perform a hard reset of the module. ©2024 Rambus Inc. / atsec information security.

VaultIP synthesized in the Xillinx Zynq XC7Z045 FPGA is a single chip hardware module. The chip is delivered from the vendor via a trusted delivery courier. Upon reception of VaultIP, the customer should verify that the package does not have any irregular tears or openings. The chip comes preloaded with the following code packages:

• 914-130939-460_VaultIP-130-939_Firmware-cfgA_FW4.6.3.zip.
• 915-130939-430_VaultIP-130-939_HW4.3.1.zip

The Public Use Document related to the ESV certificate is posted here: https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validationprogram/documents/entropy/E167_PublicUse.pdf 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 version" service and verify the following outputs:

• 00040301 is the hardware version
• 01040603 is the firmware version
• 0000d82c is the EIP-130 component name The combination of these outputs maps to a unique module with name VaultIP RT-130 with versions 4.6.3, 4.3.1. The module implicitly transitions between the approved mode and the non-approved mode contingent on the service that is invoked. Therefore, there are no special procedures to administer the approved or non-approved modes.

The Crypto Officer shall consider the following requirements and restrictions when using the module. •   AES GCM IV see Section 2.7 •   AES XTS see Section 2.7 •   SP800-56Ar3 assurances see Section 2.7 •   RSA modulus size see Section 2.7 •   SP800-56Br2 assurances see Section 2.7 •   Legacy use see Section 2.7

Secure sanitization of the module consists of performing the Zeroize OTP service then powering off the module. This will zeroize all SSPs in non-volatile and volatile memory. ©2024 Rambus Inc. / atsec information security.

The module does not implement security mechanisms to mitigate other attacks. ©2024 Rambus Inc. / atsec information security.

Appendix A.               Glossary and Abbreviations AES                 Advanced Encryption Standard ASIC                Application-Specific Integrated Circuit CAST                Cryptographic Algorithm Self-Test CAVP                Cryptographic Algorithm Validation Program CBC                 Cipher Block Chaining CBC-MAC             Cipher Block Chaining Message Authentication Code CCM                 Counter with Cipher Block Chaining Message Authentication Code CKG                 Cryptographic Key Generation CMAC                Cipher-based Message Authentication Code CMVP                Cryptographic Module Validation Program CPU                 Central Processing Unit CRC                 Cyclic Redundancy Check CTR                 Counter Mode DMA                 Direct Memory Access DRBG                Deterministic Random Bit Generator ECB                 Electronic Code Book ECC                 Elliptic Curve Cryptography ECDSA               Elliptic Curve Digital Signature Algorithm ECIES               Elliptic Curve Integrated Encryption Scheme ESV                 Entropy Source Validation FIPS                Federal Information Processing Standards Publication FPGA                Field Programmable Gate Array GCM                 Galois Counter Mode GMAC                Galois Message Authentication Code HMAC                Keyed-Hash Message Authentication Code HUK                 Hardware Unique Key ICM                 Integer Counter Mode IFC                 Integer Factorization Cryptography IV                  Initialization Vector KAS                 Key Agreement Scheme KAT                 Known Answer Test KDF                 Key Derivation Function KTS                 Key Transport Scheme KWP                 AES Key Wrap with Padding MAC                 Message Authentication Code NIST                National Institute of Science and Technology OAEP                Optimal Asymmetric Encryption Padding OTP                 One-Time Programmable PCT                 Pair-wise Consistency Test PDA                 Personal Digital Assistant PIN                 Personal Identification Number PSS                 Probabilistic Signature Scheme RAM                 Random-Access Memory ROM                 Read-Only Memory RSA                 Rivest, Shamir, Adleman SHA                 Secure Hash Algorithm SIV                 Synthetic Initialization Vector SoC                 System on Chip SSP                 Sensitive Security Parameter TCM                 Tightly-Coupled Memory TEE                 Trusted Execution Environment XTS                 XEX-based Tweaked-codebook mode with cipher text Stealing ©2024 Rambus Inc. / atsec information security.

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-validationprogram/fips-140-3-ig-announcements FIPS180-4 Secure Hash Standard (SHS) August 2015 http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf FIPS186-2 Digital Signature Standard (DSS) Jan 2000 https://csrc.nist.gov/files/pubs/fips/186-2/final/docs/fips186-2.pdf FIPS186-4 Digital Signature Standard (DSS) July 2013 http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf FIPS186-5 Digital Signature Standard (DSS) February 2023 https://doi.org/10.6028/NIST.FIPS.186-5 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 ExtendableOutput 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 RFC 5639 Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation March 2010 https://doi.org/10.17487/RFC5639 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 ©2024 Rambus Inc. / atsec information security.

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-38C NIST Special Publication 800-38C - Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality May 2004 http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication80038c.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-38E NIST Special Publication 800-38E - Recommendation for Block Cipher Modes of Operation: The XTS AES Mode for Confidentiality on Storage Devices January 2010 http://csrc.nist.gov/publications/nistpubs/800-38E/nist-sp-800-38E.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 SP800-56Ar3 NIST Special Publication 800-56A Revision 3 - Recommendation for Pair Wise Key Establishment Schemes Using Discrete Logarithm Cryptography April 2018 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.80056Ar3.pdf SP800-56Br2 Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography March 2019 https://doi.org/10.6028/NIST.SP.800-56Br2 SP800-56Cr2 Recommendation for Key Derivation through Extraction-thenExpansion August 2020 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.80056Cr2.pdf SP800-90Ar1 NIST Special Publication 800-90A - Revision 1 - Recommendation for Random Number Generation Using Deterministic Random Bit Generators June 2015 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.80090Ar1.pdf SP800-90B NIST Special Publication 800-90B - Recommendation for the Entropy Sources Used for Random Bit Generation January 2018 https://doi.org/10.6028/NIST.SP.800-90B ©2024 Rambus Inc. / atsec information security.

SP800-108r1- NIST Special Publication 800-108 - Recommendation for Key upd1 Derivation Using Pseudorandom Functions (Revised) August 2022 https://doi.org/10.6028/NIST.SP.800-108r1-upd1 SP800-133r2 NIST Special Publication 800-133 Revision 2 - Recommendation for Cryptographic Key Generation June 2020 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800133r2.pdf SP800-140Br1 NIST Special Publication 800-140Br1 - CMVP Security Policy Requirements November 2023 https://doi.org/10.6028/NIST.SP.800-140Br1 ©2024 Rambus Inc. / atsec information security.