Samsung TCG Opal SSC Cryptographic Sub-Chip Deneb

Certificate

Approved Algorithms (10)

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

flowchart LR
  %% Deterministic review-risk graph for Samsung TCG Opal SSC Cryptographic Sub-Chip Deneb
  %% 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>Status Output<br/>Show status<br/>self-test</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>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."]
    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?"]
    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"]
    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
  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,C6 clue;
  class I2,I3,I6 infer;
  class R2,R3,R6 risk;
  class E2,E3,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Samsung TCG Opal SSC Cryptographic Sub-Chip Deneb
  %% 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>Status Output<br/>Show status<br/>self-test</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>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,C6 clueLow;

Security Policy, page by page

Samsung TCG Opal SSC Cryptographic Sub-Chip Deneb Document Date: July 18, 2025 Document Version: 1.0

1. Introduction 1.1. Scope This document describes the security policy for Samsung TCG Opal SSC Cryptographic Sub-Chip Deneb, herein after referred to as a “cryptographic module” or “module” in compliance with IG 2.3.B, satisfies all applicable FIPS 140-3 Security Level 2 requirements. This module is dedicated to be embedded Samsung SED to support cryptographic algorithms and robust key management design. The module is integrated in a SoC and used as FIPS 140-3 validated Sub-Chip subsystem module to provide approved security functions subject to various SSD products’ configuration. Table
2. Security Levels 1.2. Acronyms Table
3. Acronyms

2. Cryptographic module specification 2.1. Cryptographic boundary The following photographs show explicitly defined perimeter of the cryptographic module’s physical boundary. A single IC chip package serves as the single-chip physical boundary of the module. Set of hard circuitry cores of Sub-Chip cryptographic subsystem are contained in this physical boundary. Figure
3. External view of the Samsung TCG Opal SSC Cryptographic Sub-Chip The Sub-Chip cryptographic subsystem boundary (i.e. HMI) is essentially composed of dedicated isolated security processor and cryptographic hardware subsystems. The associated firmware that loaded into the HMI provides the required approved mode of operation. • Module type: Hardware • Module embodiment: Single Chip • Module Characteristics: The sub-chip is contained within the Samsung S4LY011A01 SoC implemented within a TCG Opal SED. Figure
4. HMI of the Samsung TCG Opal SSC Cryptographic Sub-Chip

2.2. Version information 2.3. Cryptographic functionality The cryptographic module supports the following Approved algorithms for secure data storage: Table 4. Approved Algorithms NOTE: There are algorithms, modes, and keys that have been CAVP tested but not used by the module. Only the algorithms, modes/methods, and key lengths/curves/moduli shown in this table are used by the module.

1 The “S4LY011A01” version number is NOT the cryptographic boundary of the module, it references the SoC on which it operates on.

Table

5. Security Function Implementations 2.3.2. Non-Approved Algorithm Table
6. Non-Approved Algorithms Not Allowed in the Approved Mode of Operation Following algorithm is not intended to be used as a security function in this module, and not used whatsoever to meet any FIPS 140-3 requirements. The algorithm below is not provided through executable approved service to an operator. Table
7. Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed

2.4. Approved mode of operation The cryptographic module supports an approved and non-approved mode of operation. The module defaults to the approved mode of operation as long as the guidance outlined in Section 11 is followed, and operator can verify that the module enters the default approved mode by confirming that the version is consistent with the version information described in this Security Policy. The module will transition between the approved and non-approved modes depending on the services requested by the operator. The operator can check whether the module is in the approved mode or the nonapproved mode via status response from each service. The module zeroises SSPs when completing a service as described in Table 10, however it is recommended for the Crypto Officer (CO) via procedural guidance set forth in this Security Policy to also perform a power reset to zeroise all SSPs of the module when switching between modes of operation.

Table 8. Ports and Interfaces

4. Roles, services, and authentication The following table defines the roles, authority, associated services, and inputs/outputs supported by the cryptographic module: Table
5. Roles, Service Commands, Input and Output

4.2.1. Approved Services The following table shows all approved services which is implemented by the cryptographic module. E: EXECUTE; W: WRITE; G: GENERATE; Z: ZEROISE E     W      G    Z O            O    O O     O    O O

3 It means that “Write” and “Zeroise” perform in each storage of SSPs that is described in table10.

4 This does not mean to use to comply with Section 7.4.4 of ISO/IEC 19790, but is a service used to support the part of TCG authenticate

5 This does not mean to use to comply with Section 7.4.4 of ISO/IEC 19790, but is a service used to support the part of TCG deauthenticate

E W G Z Table

10. Approved Services The services in this non-Approved mode of operation are non-security relevant, and do not expose/utilize any critical security parameters. The operator can distinguish these via response value; ApprovedMode return
11. N/A Table
12. Non-Approved Services The module supports role-based authentication that requires authentication to assume for the authorization of each role.

FL

ECDSA signature verification

Probability of 1/2192 in a single random attempt. Probability of 1250/2192 in multiple random attempts in a one-minute.

Table 12. Roles and Authentication Table 9 shows each authentication method and strength for a single and multiple attempts. The CO role requires password-based authentication, where each byte can be any of 0x00 to 0xFF. Each password authentication failure holds the cryptographic module for 750ms. This restricts the maximum attempts for a one-minute to less than 80 attempts (60,000ms/750ms). The User role requires password-based authentication, where each byte can be any of 0x00 to 0xFF. Each password authentication failure holds the cryptographic module for 750ms. This restricts the maximum attempts for a one-minute to less than 80 attempts (60,000ms/750ms). The FL role is limited to authenticate functions that verifies 2 steps of ECDSA P-384 with SHA-384 digital signature of firmware to complete a login. The firmware signed6 by Samsung is authenticated by verifying the ECDSA signature which has 192 security strength in every power-on. Each signature verification attempt takes at least 48ms. This can be enforced with up to

6 The signing key is securely stored in HSM which is under Samsung internal development management.

5. Software/Firmware security - The module applies digital signature verification using ECDSA-384 with SHA-384 for firmware integrity test. - The firmware integrity test is performed every power on reset.

6. Operational environment - The cryptographic module operates in limited operational environment that consists of the module’s firmware. This operational environment does not require any specific security rules, settings/configurations or restrictions to be set. - The cryptographic module does not provide any general-purpose operating system to the operator. - Firmware loading is allowed only for CMVP validated firmware versions. Unauthorized modification of the firmware is prevented by the pre-operational firmware integrity test and conditional firmware load test.

The following physical security mechanisms are implemented in a cryptographic module itself:

• All components are manufactured to production-grade with standard passivation.
• Encased in opaque package within the visible spectrum.
• Apply strong removal-resistant and penetration resistant IC packaging technique. The following table summarizes the actions required by the Crypto Officer Role to ensure that physical security is maintained:

8. Non-invasive security - Non-invasive security is not applicable for this cryptographic module

9. Sensitive security parameter management - Temporary SSPs are zeroised when power on reset. - Firmware integrity temporary values are zeroised after the firmware integrity test is complete. - The zeroisation is performed before overwriting the target SSP with random value which is generated from the DRBG - The AES-GCM IV is generated by the module and complies with FIPS 140-3 IG C.H technique
10. The IV is 96 bits in length, and its generated by the SP 800-90Arev1 DRBG internal to the module’s boundary.

7 Because there is no non-volatile storage in this module without OTP, basically, automatic zeroisation runs instantly either when temporary SSP

as well as SSPs are no longer needed after key generation/use, or every power-on-reset depending on characteristics of volatile memory.

12 Please note this is a SSP generated by the module to be used by the consuming application (outside of the boundary)

13 FIPS 140-3 IG 2.3.B states Transferring SSPs between a sub-chip cryptographic subsystem and an intervening functional subsystem for

Security Level 2 on the same single chip is considered as not having Sensitive Security Parameter Establishment crossing the HMI of the sub-chip module per IG 9.5.A.

Table

14. SSPs The cryptographic module contains an entropy source compliant with SP800-90B. Table
15. Non-Deterministic Random Number Generation Specification

14 The Firmware Verification key is not an SSP per ISO/IEC 19790 Section 7.5.

15 Estimated amount of entropy per the source’s output bit is 0.767252 and Samsung conservatively claims to be set at 0.5 per bit.

10. Self-tests While executing the following self-tests, all data output is inhibited until the self-test is completed. To execute the preoperational tests on-demand, the operator may run the power-cycle of the module. If the self-test fails, the module enters an error state. The module has two error states. The "Rom Mode" error state is entered when the module fails the pre-operational self-test (Firmware integrity test) or the conditional self-test (Firmware load test). The error indicator output by the module is "eSROMReturn_VerifyFail". The "FIPS Fail Mode" error state is entered when the module fails any other conditional self-test (Cryptographic algorithm self-test or Pair-wise consistency test). The error indicator output is "0x4C494146". All data output is inhibited during the self-test and error states. 10.1. Pre-operational test Table
11. List of pre-operational self-tests 10.2. Conditional test m

Table 17. List of Conditional self-tests

11. Life-cycle assurance The followings describe the security rules for secure initialization and operation which the cryptographic module and Crypto Officer shall be enforced under FIPS 140-3 security level 2 compliant manner: 11.1. Secure Initialization [Step 1] Execute the firmware loading into the module [Step 2] Execute Init and Open method [Step 3] Replace the default password via Set_CPIN service if first-time authentication. - Identify the status indicator via Show Status service in the Table 7. - Identify that response information matches the versioning information in Table 3. 11.2. Operational description of module

• The cryptographic module shall maintain logical separation of data input, data output, control input, control output, and power.
• The cryptographic module shall enforce a limited operational environment by the secure firmware load test using ECDSA p-384 with SHA-384.
• The cryptographic module enters the error state upon failure of Self-tests. All commands are rejected in the error state with exception of the Show Status service. Cryptographic services and data output are explicitly inhibited in the error state.
• The module generates at a minimum 256 bits of entropy for use in key generation.
• Bypass capability is not applicable to the cryptographic module
• The module generates symmetric keys that are unmodified outputs from the DRBG. 11.3. Administrator Guidance The Crypto officer shall power up the module and call the “Show Status” service to verify the following output is provided. This confirms that the SoC is running a FIPS validated module that has booted successfully passing the pre-operational selftests.
• - Tested Configuration: S4LY011A01
• - Hardware Version: S02
• - Firmware Version: SS0200 11.4. Non-Administrator Guidance The module generates GCM IV internally in compliance with scenario 2 of IG C.H. The IV length is 96 bits, and the IV value is obtained from the SP 800-90ARev1 approved DRBG implemented by the module.

The cryptographic module has not been designed to mitigate any specific attacks beyond the scope of FIPS 140-3 N/A N/A N/A Table 18. Mitigation of Other Attacks