KIOXIA FIPS TC58NC1030GTB Crypto Sub-Chip

Certificate

Approved Algorithms (10)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for KIOXIA FIPS TC58NC1030GTB Crypto Sub-Chip
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C1["[high] Firmware / bootloader<br/>versions disclosed<br/>(identity, not provenance)<br/><i>SC01CN</i>"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>Firmware Load<br/>update</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>Status Output<br/>Show Status</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system</i>"]
  end
  subgraph Inference["Derived inference"]
    I1["Component identity is<br/>disclosed, but provenance<br/>and patch lineage are not."]
    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"]
    R1["Do the vendor version<br/>strings obscure the<br/>upstream baseline, fork<br/>lineage, or known-CVE<br/>exposure?"]
    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"]
    E1["SBOM / component baselines<br/>· patch and backport<br/>manifest · CVE disposition"]
    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
  C1 --> I1 --> R1 --> E1
  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 C1,C2,C3,C6 clue;
  class I1,I2,I3,I6 infer;
  class R1,R2,R3,R6 risk;
  class E1,E2,E3,E6 evidence;

flowchart LR
  %% Deterministic clue tier for KIOXIA FIPS TC58NC1030GTB Crypto Sub-Chip
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C1["[high] Firmware / bootloader versions disclosed (identity, not provenance)<br/><i>SC01CN</i><br/>src: certificate.firmwareVersions"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>Firmware Load<br/>update</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>Status Output<br/>Show Status</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system</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 C1 clueHigh;
  class C2,C3,C6 clueLow;

Security Policy, page by page

KIOXIA FIPS TC58NC1030GTB Crypto Sub-Chip KIOXIA CORPORATION Rev 3.0.5 Dec 23, 2024

This document explains precise specification of the security rules about KIOXIA FIPS TC58NC1030GTB Crypto Sub-Chip. The Cryptographic Module (CM) meets the requirements of FIPS 140-3 Security Level 2 Overall. The Table below shows the security level detail. [Number Below] N/A N/A N/A Table 1 ‐ Security Levels This document is non-proprietary and may be reproduced in its original entirety. Section 1.1 - Acronyms AES Advanced Encryption Standard CM SSP DRBG Deterministic Random Bit Generator HMAC The Keyed-Hash Message Authentication code KAT Known Answer Test POST Power on Self-Test CAST Cryptographic Algorithm Self-Test PSID Printed SID SED Self-Encrypting Drive SHA Secure Hash Algorithm SID Security ID TCG Trusted Computing Group Dec 23, 2024

Section 2

• Cryptographic Module Specification KIOXIA FIPS TC58NC1030GTB Crypto Sub-Chip (listed in Section2.1 Product Version) is used for solid state drive data security. The CM is a single chip hardware module implemented as a sub-chip compliant with IG 2.3.B in the TC58NC1030GTB 0002 SoC (see Figure 1 in Section 7). Overall Security Rating of the CM is Level 2 (See Table 1 in Section 1 for individual security area levels). The CM is embedded in TCG OPAL compliant solid state drive controllers which provides user data encryption/decryption through build-in HW engines. The CM provides various cryptographic services using approved algorithms. The CM has multiple functions, but they do not support the degraded operation. The physical boundary of the CM is the TC58NC1030GTB 0002 SoC and the logical boundary of the CM is The CM has one approved mode of operation and CM is always in approved mode of operation after initial operations are performed (See Section 11). In approved mode, the CM provides services defined in Table 7 in Section 4.2. Section 2.1
• Product Version The CM is validated with the following versions: Table 2 ‐ Cryptographic Module Tested Configuration Section 2.2
• Security Functions The CM executes the following approved algorithms: Dec 23, 2024

N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Note 1: The “CAVP Cert” of KTS comes from the fact that KTS is composed of AES256-CBC and HMAC-SHA2-256 (#A2402). Note 2: 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. Table 3 ‐ Approved Algorithms The CM does not have any Non-approved algorithms allowed in the approved mode of operation. ECB mode is used as a prerequisite of XTS mode. ECB is not directly used in services of the Cryptographic Module. The CM performs a check that the XTS Key1 and XTS Key2 are different according to IG C.I. AES-XTS is only used for encryption/decryption of data stored in solid state drives equipped with this CM. Dec 23, 2024

Section 2.3

• Module Configuration Overview block diagram of the CM is shown below. Figure 1
• Configuration of module and peripheral components Components of the CM is shown with gray background blocks include processor, memories (volatile and non-volatile memory) and HW circuitry for cryptographic processing. Cryptographic algorithms implemented as FW are shown in light-gray background block. Physical ports bordering outside the CM’s boundary and the data passing over them are also indicated (see Section 3 for details on physical ports and interfaces). Section 3
• Cryptographic Module Interfaces Note 1: Control output is omitted in the table above because the CM does not implement this type of interface. Table 4 ‐ Ports and Interfaces Dec 23, 2024

Section 4

• Roles, Services, and Authentication The relation between Roles and Services in this CM is shown below. external firmware is verified (RSASSA-PKCS#1-v1_5). Dec 23, 2024

… … … … N/A Note: There are LockingSP.Users from user 1 to user 192, but user 3 to user 191 are omitted in the table above. Dec 23, 2024

Table 5 ‐ Roles, Service Commands, Input and output The CM supports the configuration of roles and services. The authenticated operator is expected to configure locked bands for data storage, the associated role and the lock-based authentication data (PIN) per Table 5 (refer to section 11 for detail settings to maintain secure operation). Bands that are not configured are considered unprotected or plaintext. This configuration enables Data Read/Write service using the lock-based authentication model (IG 4.1.A). To Read/Write data from/to each band, an operator must unlock the bands with appropriate authenticated roles. Once the bands are unlocked, Read and Write access to the bands must be controlled by a trusted operator outside of the module who has authenticated the associated role until powered off. The module prevents Data read/write service for locked bands. If Read and Write access needs to be inhibited prior to power off, the operator who authenticates the role must set the bands to the locked state again. Section 4.1

• Roles and Authentication This section describes roles, authentication method, and strength of authentication. … … … Note 1: All roles to be authenticated are FIPS Crypto Officer Note 2: There are LockingSP.Users from user 1 to user 192, but user 3 to user 191 are omitted in the table above. Table 6 ‐ Identification and Authentication Policy The CM provides a role-based PIN authentication function. The CM stores PINs that has been previously hashed with SHA2-256, and verifies the PIN entered by the operator matches the stored information at the time of authentication. PINs can be changed by executing the Set PIN Service (see Section4.2) with appropriate roles authenticated. The CM refuses to set a PIN less than 8 bytes, and responds with an error if such Dec 23, 2024

a setting is attempted. Therefore, the probability that a random attempt will succeed is 1 / 264 < 1 / 1,000,000 (the CM accepts any value (0x00-0xFF) as each byte of PIN). The CM waits 1ms when authentication attempt fails, so the maximum number of authentication attempts is 60,000 times in 1 min. succeed is 60,000 / 2 Consequently, the probability that random attempts in 1min will < 1 / 100,000. Initial PINs of AdminSP.Admin1, LockingSP.Admin2-4 and LockingSP.User1-192 are set to null (i.e., data length is 0). These role’s authentication data are need to be replaced upon the first-time authentication. Otherwise, the operator who assumes these roles cannot execute services except Set PIN and services that does not need authorized roles. Section 4.2

• Services This section describes services which the CM provides. E 1-4 G E +1” N/A N/A N/A E 1-4 DRBG Internal Value 1-4 G, Z E G, Z E AES256-CBC E KTS W, R CKG(Hash_DRBG) E The letters (G, R, W, E, Z) mean Generate, Read, Write, Execute and Zeroise respectively. Dec 23, 2024

+1” 1-4 E G, Z +1” E G, Z E E W, R N/A N/A N/A E W, E E 1-4 E G, Z E G, Z E E W, R 1-4 +1” E W, E E , E 1-4, W, R E Only the CMVP validated version is to be used Dec 23, 2024

W, E, Z W, E, Z N/A N/A N/A N/A N/A N/A Z Z Z Z Z Z Z N/A Z Z Z Z Z Z Z W, E E G G G E, Z G N/A E E W W Note 1: “CKG(Hash_DRBG)” means direct use of Hash_DRBG output as a key. Note 2: A cryptographic module is required to provide services “Show module’s versioning information”, “Show status”, “Perform self-tests”, “Perform approved security functions” and “Perform zeroisation”. In this CM, “Show module’s information” zeroisation” is executed by the Zeroisation service. All other services fall under “Perform approved security functions”. Need to input PSID, which is public drive-unique value used for the zeroisation service. Dec 23, 2024

Table 7 ‐ Approved services The CM does not provide Non-approved services. Section 5

• Software/Firmware Security Firmware Security of components in this CM is shown below. ROM Code: ・ Form of the executable code: ELF format ・ Integrity verification method: 32bit CRC ・ Method for integrity test on demand: Power cycling Firmware image (User Code): ・ Form of the executable code: ELF format ・ Integrity verification method: Approved signature verification (RSASSA-PKCS#1-v1_5, see table 3) ・ Method for integrity test on demand: Power cycling The CM supports the partial loading that replaces the current Firmware image, excluding the ROM Code, with a new Firmware image loaded from outside the module. In this case the CM becomes another validated one. Section 6
• Operational Environment Operational Environment requirements are not applicable because the CM does not employ operating systems and operates in a limited operational environment under the FIPS 140-3 definitions. Section 7
• Physical Security The CM is a sub-chip enclosed in a single chip that is an opaque package. Gathering information of the module’s internal construction or components is impossible without forcing the package to open. In this case, it is confirmed package damage as a tamper-evidence. Operators of the CM can ensure that the physical security is maintained to confirm the package has no obvious attack damage. If the operator discovers tamper evidence, the CM should be removed. Dec 23, 2024

Front Back Figure 2 - TC58NC1030GTB 0002 SoC Section 8

• Non-invasive security The CM does not apply Non-invasive security. Section 9
• Sensitive security parameter management The CM uses keys and SSPs in the following table. N/A 4) N/A / N/A Dec 23, 2024

4) N/A 6) + N/A N/A The following service are applicable, Cryptographic Erase, Cryptographic Erase for Band of Single User Mode, Cryptographic Erase and Initialize Band State, Set Band Position and Size, Set Band Position and Size for Band of Single User Mode, Revert, Sanitize, Format Namespace, Namespace Create/Delete and Band Set Enable. Zeroised after input to related algorithm. Dec 23, 2024

Table 9 ‐ SSPs Table 10 ‐ Non-Deterministic Random Number Generation Specification For the Entropy Source listed in the table above, self-tests are performed each time before data is obtained (see Section 10 for details of these self-tests). When these tests detect that the Entropy Source cannot generate the sufficient amount of entropy, the CM is transient to error state. The CM can be recovered from the error state by rebooting the module, and the obtaining of Entropy data is attempted again. If the CM continuously enters in error state in spite of several trials of reboot, the CM may be sent back to factory to recover from error state. The Entropy Source is a hardware module inside the CM boundary. The Entropy Source supplies the Hash_DRBG with 1024 bits entropy input. From Table 10 this input contains about

384 bits of entropy, which is sufficient entropy to obtain 256 bits of security strength.

Section 10

• Self Tests The CM runs self-tests in the following table. Dec 23, 2024

Table 11 ‐ Self Tests As shown in the table above, self-tests are performed automatically at the CM startup and before execution certain security functions. Operator can also initiate self-test on-demand for periodic testing by using the Reset service which is automatically invoked when the module is powered-off and powered-on (rebooted). If the self-tests fail, the CM reports error status and enters to the error state. In this case, the CM must be powered-off to clear error condition. When power-on is executed again, self-tests are also executed like an on-demand operator reset. If the CM continuously enters in error state in spite of several trials of reboot, the CM may be sent back to factory to recover from error Section 11 – Life-cycle Assurance In the SSD’s manufacturing process, installation is executed as below:

1. The Firmware described in Section 2.1 is downloaded into the CM.
2. Initial SSPs are generated.
3. Initial authentication information is set to the CM.
4. System area including SSPs generated in Step2 and Step3 are encrypted and calculated message authentication code. Initial operations to setup this CM are following: loaded into the CM can be confirmed. Dec 23, 2024

2. Load system area including SSPs into the CM.
3. Execute range state setting method.
4. Execute download port setting method.
5. Execute service execution state setting method.
6. Execute namespace setting method. The CM switches to approved mode after the initial operation success. When the initial operation succeeds, the CM indicates success on the Status Output interface. Users can confirm that the CM is in approved mode by executing Show Status service and checking that the startup is successfully completed. For secure operation, the following settings must be maintained:  Data Locking Protection is Enabled  Each Band is set to be locked when power-on. Bands that are not configured are considered unprotected or plaintext. (Refer to SSD setting procedure11 ) As described in Section 2, the CM is used by being embedded in the solid state drive. Therefore, there are no maintenance requirements for the CM alone. Guidance for this module is provided to solid state drive developers who embed the CM. The usage and maintenance of solid state drives with the CM built-in are outside of the scope of this document. Section 12 – Mitigation of Other Attacks The CM does not mitigate other attacks beyond the scope of FIPS 140-3 requirements. For maintaining secure condition, the SSD needs several setting at least. Owners of the SSD that embeds the CM must use it securely according to the followings:
7. TCG LockingSP is enabled by Activate method.
8. Both ReadLockEnabled and WriteLockEnabled are set to “True” for each band (included Global Range) and it must not be modified.
9. For each band, “Power Cycle" of LockOnReset setting is not change.
10. If the LockingSP has been made disabled, the Activate method is re-executed before PowerCycle is performed. Dec 23, 2024