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

Revision History Version Change

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. ISO/IEC 24759 Security Section
2. FIPS 140-3 Section Title Level [Number Below]

1 General 2

2 Cryptographic module specification 2

3 Cryptographic module interfaces 2

4 Roles, services, and authentication 2

5 Software/Firmware security 2

6 Operational environment N/A

7 Physical security 2

8 Non-invasive security N/A

9 Sensitive security parameter management 2

10 Self-tests 2

11 Life-cycle assurance 2

12 Mitigation of other attacks N/A

Table

1. Security Levels 1.2. Acronyms Acronym Description CPK Credential Protection Key DRBG Deterministic Random Bit Generator ECDH Elliptic Curve Diffie-Hellman ECDH CK Common Key, shared secret for key agreement ECDH PK Public key for key agreement ECDH SK Secret key for key agreement GRK Grant Key derived from shared secret HMI Hardware Module Interface the Mailbox and DMA are physical ports of the sub-chip KAS-ECC-SSC Key Agreement Scheme (Shared Secret Computation) KAT Known Answer Test KEK Key Encryption Key KPK Key Protection Key LBA Logical Block Address MEK Media Encryption Key NAND NAND Flash Memory NVMe Non-Volatile Memory Host Controller Interface Specification SED Self-Encrypting Drive SSC Security Subsystem Class SSP Sensitive Security Parameter TCG Trusted Computing Group Table
2. 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 Tested Configuration Hardware Version Firmware Version S4LY011A01 S02 SS0200 Table

3. Cryptographic Module Tested Configuration 2.3. Cryptographic functionality 2.3.1. Approved algorithm The cryptographic module supports the following Approved algorithms for secure data storage: Description/ CAVP Algorithm and Mode/ Key Size(s)/ Use/Function Cert Standard Method Key Strength(s) A4353 AES / FIPS 197, SP 800- GCM 256 bits Key Encryption / Decryption 38D A4353 KTS AES-GCM 256 bits Key Transport as per SP 800-38F A4352 DRBG / CTR_ DRBG N/A All Cryptographic Key Generation SP 800-90Arev1 (AES-256) A4351 SHS / FIPS 180-4 SHA-256 N/A Message Digest SHS / FIPS 180-4 SHA-384 N/A Message Digest KBKDF / SP 800- HMAC-SHA-256 256 bits Key Derivation 108rev1 HMAC / FIPS 198-1 SHA-256 256 bits Message Authentication ECDSA / Curve P-384 with SHA- P-384 / 192 bits Key Generation and Digital FIPS 186-4 384 Signature Verification KAS-ECC-SSC / SP 800- staticUnified P-384 / 192 bits2 Shared secret computation 56Ar3 KDA / OnestepNoCounterKdf 256 bits Key Derivation for GRK from ECDH SP 800-56C Rev2 with SHA2-256 CK Vendor CKG / Section 5.2 and 6.1 N/A As per SP 800-133rev2 Section 5.2 Affirmed SP 800-133r2 and 6.1, key generation is performed for "Key Pairs for Key Establishment" and "Direct Generation: of Symmetric Keys" which are Approved key generation methods. The list of CSPs generated by the module: KDK_CPK, KDK_KPK, MEK, KEK, ECDH SK, Root Key E83 ENT (P) / N/A N/A ENT (P) provides a minimum of 256 SP800-90B bits of entropy for approved DRBG seed construction in key generation. 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.

# Name Type Description SF Properties Algorithms

1 Key KTS SP 800-38D and SP 800-38F. 256-bit keys providing 256 AES GCM Cert. #A4353

Transport KTS (key wrapping and bits of encryption strength unwrapping) per IG D.G.

2 Key KAS SP 800-56Arev3. KASECC per Key establishment KAS-ECC-SSC / SP 800-

Agreement IG D.F Scenario 2 path (2). methodology provides 192 bits 56Ar3 Cert. #A4351 of encryption strength KDA / SP 800-56C Rev2 Cert. #A4351 Cert. SHS / FIPS 180-4 #A4351 Table

5. Security Function Implementations 2.3.2. Non-Approved Algorithm Algorithm Use / Function AES-XTS / Encryption for Dump data FIPS 197, SP 800-38E RSA / SP 800-56B Encryption for dump encryption Key HKDF/ SP 800-56C Rev2 Key Derivation 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. Algorithm Caveat Use / Function No Security Claimed; AES-XTS is only used for proprietary AES-XTS / firmware decryption during ROM initialization; as per FIPS Firmware Decryption FIPS 197, SP 800-38E 140-3 IG 2.4.A this cryptographic operation is applied for good measure. 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.

3. Cryptographic module interfaces Physical port Logical interface Type Data that passes over port/interface Mailbox Signature Data Firmware Data Data Input DMA Signature Data Key Data Plaintext data that has been decrypted by DMA Data Output the cryptographic module Control Input Commands input logically via an API; Mailbox Status Output Status information Power planes Power Input Power input Table
4. Ports and Interfaces

4. Roles, services, and authentication 4.1. Role The following table defines the roles, authority, associated services, and inputs/outputs supported by the cryptographic module: Role Authority Service Input Output Authority Index, Password, Status CreateNamespace Authority List Authority Index, Password, Status DeleteNamespace Authority List Authority Index, Password, Status WriteProtection Authority List SysID Sanitize Authority Index, Password Status CryptoErase Authority Index, Password Status FormatNVM Authority Index, Password Status RevertWithPSID Authority Index, Password Status TPER Reset Authority Index, Password Status Revoke Root Authority Index, Password Status Encryption Key Crypto Officer (CO) Revert Authority Index, Password Status Activate Authority Index, Password Status Reactivate Authority Index, Password Status Authority Index, Password, Status Assign Authority List Authority Index, Password, Status AdminSP.SID Deassign Authority List AdminSP.Admin1 Set CPIN Authority Index, Password Status LockingSP.Admin1~4 GenKey Authority Index, Password Status Erase Authority Index, Password Status Authority Index, Password, Status Grant Authority List Authority Index, Password, Status SetRange Authority List Reactivate Authority Index, Password Status Authority Index, Password, Status Assign Authority List Authority Index, Password, Status Deassign Authority List Set CPIN Authority Index, Password Status User LockingSP.User1~33 GenKey Authority Index, Password Status Erase Authority Index, Password Status Authority Index, Password, Status Grant Authority List Authority Index, Password, Status SetRange Authority List Signature Data, Status Firmware Loader (FL) Bootloader VerifyFW Firmware Data Table
5. Roles, Service Commands, Input and Output

4.2. Service 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 Access rights Approved to Keys Keys and/or Service Description Security Roles and/or SSPs3 Indicator SSPs Functions E W G Z Show status of the module and show Show Status - - module’s versioning information Perform all preoperational and Perform self-tests conditional self-tests - - by power-cycling the module DRBG Provide a random Get Random CTR_ DRBG Internal number generated by - O O O Number (AES-256) State, DRBG the CM Seed Load the KPK for CTR_DRBG, AES- DRBG authority and decrypt GCM, KAS-ECC- Internal Authentication4 - O O O related encryption SSC, KBKDF, SHA, State, DRBG keys HMAC Seed Zeroise the KPK for Unauthentication authority and zeroise

5 - KPK - O Return value

related encryption keys MESSAGE_RESPONSE. Hash Operation Hash operation SHA - - bApprovedMode: 1 // 1: Approved Mode, FW Verify firmware 0: Non-Approved VerifyFW ECDSA Verification FL O signature Mode Key PIN O O DRBG Internal O O O State, DRBG Seed NVMe Command, CTR_DRBG, AES- KEK, KPK, Erase user data in all RevertWithPSID GCM, KBKDF, MEK, CPK, Range by changing O O O O SHA, HMAC KDK_CPK, the data KDK_KPK CO ECDH SK, O O O ECDH PK REK, SMK, O KMK PIN O O Abort all TCG KDK_CPK, KBKDF O O O TPER Reset Communications and KDK_KPK Reset TCG protocol CPK O O O AES-GCM, HMAC KPK, KEK, 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

Access rights Approved to Keys Keys and/or Service Description Security Roles and/or SSPs3 Indicator SSPs Functions E W G Z MEK REK, SMK, O KMK PIN O O KDK_CPK, KBKDF O O O KDK_KPK CPK O O O KEK, KPK O O O DRBG Allocate key to the Internal CreateNamespace O O O specified Namespace AES-GCM, KAS- State, DRBG ECC-SSC, Seed CTR_DRBG, SHA, ECDH CK, HMAC ECDH PK, O O O O ECDH SK REK, SMK, O KMK PIN O O KDK_CPK, KBKDF O O O KDK_KPK CPK O O O KEK, KPK O O O Delete key for the DRBG DeleteNamespace specified Namespace Internal AES-GCM, O O O State, DRBG CTR_DRBG, Seed HMAC MEK O O O O REK, SMK, O KMK PIN O O KDK_CPK, KBKDF O O O Remove key from TCG KDK_KPK WriteProtection boundary on the CPK O O O specified Namespace KPK, KEK O O O AES-GCM, HMAC REK, SMK, O KMK PIN O O KDK_CPK, KBKDF O O O KDK_KPK CPK O O O KEK, KPK O O O Cryptographically DRBG Sanitize erase user data Internal (Delete key) AES-GCM, O O O State, DRBG CTR_DRBG, Seed HMAC MEK O O O O REK, SMK, O KMK PIN O O KDK_CPK, KBKDF O O O KDK_KPK Cryptographically CPK O O O CryptoErase erase user data KEK, KPK O O O (Delete key) AES-GCM, DRBG CTR_DRBG, Internal O O O HMAC State, DRBG

Access rights Approved to Keys Keys and/or Service Description Security Roles and/or SSPs3 Indicator SSPs Functions E W G Z Seed MEK O O O O REK, SMK, O KMK PIN O O KDK_CPK, KBKDF O O O KDK_KPK CPK O O O KEK, KPK O O O Delete the Key DRBG FormatNVM corresponding to the Internal specified Namespace AES-GCM, O O O State, DRBG CTR_DRBG, Seed HMAC MEK O O O O REK, SMK, O KMK PIN O O KDK_CPK, KBKDF O O O KDK_KPK CPK O O O PIN, KEK O O O DRBG Internal O O O Ready to TCG Locking State, DRBG Activate operation CTR_DRBG, AES- Seed GCM, KAS-ECC- KPK, MEK, SSC, KBKDF, SHA, CPK, O O O O HMAC KDK_KPK ECDH SK, O O O ECDH PK REK, SMK, O KMK KDK_CPK, O O O KDK_KPK KBKDF CPK O O O PIN O O DRBG Internal O O O Reset CPINs of all State, DRBG Revert authorities and range Seed information CTR_DRBG, AES- KEK, KPK, GCM, KBKDF, MEK, CPK, O O O O SHA, HMAC KDK_KPK ECDH SK, O O O ECDH PK REK, SMK, O KMK PIN O O KDK_CPK, KBKDF O O O KDK_KPK CPK O O O Revoke Root Revoke and zeroise REK, SMK, CO Encryption Key REK O O O KMK CTR_DRBG, DRBG KBKDF Internal O O O State, DRBG

Access rights Approved to Keys Keys and/or Service Description Security Roles and/or SSPs3 Indicator SSPs Functions E W G Z Seed Root Key O O PIN O O KDK_CPK, KBKDF O O O KDK_KPK CPK O O O KEK O O O DRBG Internal O O O State, DRBG Reactivate Revert and Activate CTR_DRBG, AES- Seed GCM, KAS-ECC- KPK, MEK, SSC, KBKDF, SHA, CPK, O O O O HMAC KDK_KPK ECDH SK, O O O ECDH PK REK, SMK, O KMK PIN O O KDK_CPK, KBKDF O O O KDK_KPK CPK O O O KEK O O O DRBG Internal O O O Set TCG authority’s State, DRBG Set CPIN password CTR_DRBG, AES- Seed GCM, KAS-ECC- KPK, MEK, SSC, KBKDF, SHA, CPK, O O O O HMAC KDK_KPK ECDH SK, CO, O O O ECDH PK USER REK, SMK, O KMK PIN O O KDK_CPK, KBKDF O O O KDK_KPK CPK O O O KEK, KPK O O O DRBG Assign locking object Internal Assign to the specified O O O AES-GCM, State, DRBG Namespace CTR_DRBG, KAS- Seed ECC-SSC, SHA, MEK, ECDH HMAC CK, ECDH O O O O PK, ECDH SK REK, SMK, O KMK PIN O O KDK_CPK, KBKDF O O O KDK_KPK Deassign locking CPK O O O Deassign object to the specified AES-GCM, KEK, KPK O O O Namespace CTR_DRBG, KAS- DRBG ECC-SSC, SHA, Internal O O O HMAC State, DRBG

Access rights Approved to Keys Keys and/or Service Description Security Roles and/or SSPs3 Indicator SSPs Functions E W G Z Seed MEK, ECDH CK, ECDH O O O O PK, ECDH SK REK, SMK, O KMK PIN O O KDK_CPK, KBKDF O O O KDK_KPK CPK O O O KEK, KPK O O O DRBG Internal Grant Key to the O O O Grant State, DRBG specified Authority AES-GCM, KASSeed ECC-SSC, ECDH CK, CTR_DRBG, SHA, ECDH PK, HMAC, KDA O O O O ECDH SK, GRK REK, SMK, O KMK PIN O O KDK_CPK, KBKDF O O O KDK_KPK CPK O O O KEK, KPK O O O Generate key DRBG GenKey materials Internal AES-GCM, O O O State, DRBG CTR_DRBG, Seed HMAC MEK O O O O REK, SMK, O KMK PIN O O KDK_CPK, KBKDF O O O KDK_KPK CPK O O O PIN O O DRBG Internal Cryptographically O O O State, DRBG Erase erase user data within CTR_DRBG, AES- Seed a specific LBA Range GCM. KAS-ECC- KEK, KPK O O O SSC, KBKDF, SHA, MEK, CPK, HMAC KDK_KPK, O O O O ECDH PK, ECDH SK REK, SMK, O KMK PIN O O KDK_CPK, KBKDF O O O KDK_KPK Lock or Unlock the SetRange CPK O O O specified Range KPK, KEK, O O O AES-GCM, HMAC MEK REK, SMK, O

Access rights Approved to Keys Keys and/or Service Description Security Roles and/or SSPs3 Indicator SSPs Functions E W G Z KMK Table

10. Approved Services 4.2.2. Non-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. Service Description Algorithms Accessed Role Indicator GetDumpKey Return Dump Key CTR_ DRBG (AES-256) DumpEncryption Encrypt Dump Data RSA (Non-approved algorithm) Decrypt encrypted Firmware AES-XTS (Non-approved FWDecryption binary algorithm) Verify and Decrypt encrypted AES-XTS (Non-approved FWVerifyNDecryption Firmware binary algorithm) Output the public key and SHA GetCSR signature for certification ECDSA Sig Gen SHA VerifyCert Verity the chain of certification AES-GCM SHA CTR_ DRBG (AES-256) Return value ECDSA SigGen, KeyGen MESSAGE_RESPONSE.bAppr KeyExchange ECDH agreement ECDH ovedMode: 0 N/A HKDF(HMAC) (Non-approved // 1: Approved Mode, 0: Nonalgorithm) Approved Mode Output the hashed certification GetDigest SHA chain SHA Generate the signature with CTR_ DRBG (AES-256) Challenge transcript ECDSA SigGen Output the signature, mac and SHA Finish enc for checking the common secret HMAC Output the hashed and signed CTR_ DRBG (AES-256) GetMeasurements with firmware and configuration ECDSA SigGen HKDF(HMAC) (Non-approved KeyUpdate Update the common secret algorithm) Table
12. Non-Approved Services 4.3. Authentication The module supports role-based authentication that requires authentication to assume for the authorization of each role. Role Authentication Method Authentication Strength Password Probability of 1/264 in a single random attempt. CO (Min: 8 bytes, Max: 44 bytes) Probability of 80/264 in a multiple random attempts in a one-minute. Password Probability of 1/264 in a single random attempt. User (Min: 8 bytes, Max: 44 bytes) Probability of 80/264 in a multiple random attempts in a one-minute.

Probability of 1/2192 in a single random attempt. FL ECDSA signature verification 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 1,250 attempts in a minute.

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.

7. Physical security 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: Physical Security Recommended Frequency Inspection/Test Guidance Details Mechanisms of Inspection/Test Inspect the entire perimeter whether gathering of Opaque covering internal components are visible. Stop the service if tampering is found. Inspect the damage such as removing epoxy As often as feasible overfill, separation from the PCB of the silicon die, Tamper evident solder ball deterioration (diameter, pitch) IC packaging No functioning normally if tampering is found. Stop the service. Table
8. Inspection/Testing of Physical Security Mechanisms

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. Key/SSP Security Use & Size / Generation or Import Name/ Function and Storage7 Zeroisation8 related Strength Establishment /Export Type Cert. Number keys RevertWithPSID TPER Reset CreateNamespace SP 800- DeleteNamespace DRBG A4352

256 bits / 90Arev1 WriteProtection

Internal CTR_DRBG N/A Sanitize

State9 (AES-256) CryptoErase (AES-256) FormatNVM MEK, KEK, Activate ECDH SK, HW Revert KDK_CPK, internal10 Revoke Root Encryption Key KDK_KPK, Entropy Reactivate Root Key Set CPIN input: A4352 Assign

DRBG Seed CTR_DRBG ENT (P) N/A Deassign Nonce: Grant (AES-256)

256 bits GenKey

/ 256 bits Erase SetRange RevertWithPSID TPER Reset CreateNamespace DeleteNamespace WriteProtection Sanitize CryptoErase FormatNVM 8-44 A4351 Electronic CPK PIN11 N/A SRAM Activate bytes SHA-256 input Revert KPK Revoke Root Encryption Key Reactivate Set CPIN Assign Deassign Grant GenKey

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.

10 Approved DRBG SSPs reside only inside the hardware DRBG IP and there is no way for operator to access and handle.

11 The PIN is also known as a Password in the context of this document. The terms are interchangeable.

Key/SSP Security Use & Size / Generation or Import Name/ Function and Storage7 Zeroisation8 related Strength Establishment /Export Type Cert. Number keys Erase SetRange Import / RevertWithPSID SP 800- TPER Reset

CPK 108rev1 SRAM CreateNamespace Password

KBKDF DeleteNamespace ed) WriteProtection Sanitize CryptoErase FormatNVM Activate Revert SP 800- Import / Revoke Root Encryption Key

256 bits / A4351 90Arev1 Export Reactivate

KDK_CPK SRAM CPK

256 bits KBKDF CTR_DRBG (Encrypt Set CPIN

(AES-256) ed) Assign Deassign Grant GenKey Erase SetRange Unauthentication RevertWithPSID TPER Reset CreateNamespace DeleteNamespace WriteProtection Sanitize CryptoErase SP 800- FormatNVM

KPK 108rev1 N/A SRAM Activate KEK

KBKDF Revert Reactivate Set CPIN Assign Deassign Grant GenKey Erase SetRange RevertWithPSID TPER Reset CreateNamespace DeleteNamespace WriteProtection SP 800- Import / Sanitize

256 bits / A4351 90Arev1 Export CryptoErase

KDK_KPK SRAM KPK

256 bits KBKDF CTR_DRBG (Encrypt FormatNVM

(AES-256) ed) Activate Revert Revoke Root Encryption Key Reactivate Set CPIN Assign

Key/SSP Security Use & Size / Generation or Import Name/ Function and Storage7 Zeroisation8 related Strength Establishment /Export Type Cert. Number keys Deassign Grant GenKey Erase SetRange SP 800- Import / RevertWithPSID P-384 / A4351 KAS- 90Arev1 Export CreateNamespace ECDH SK SRAM Activate GRK 192-bit ECC-SSC CTR_DRBG (Encrypt Revert (AES-256) ed) Reactivate Import / Set CPIN P-384 / A4351 KAS- SP 800-56Ar3 Export Assign ECDH PK SRAM Deassign GRK 192-bit ECC-SSC KAS-ECC-SSC (Encrypt Grant ed) Erase CreateNamespace P-384 / A4351 SP 800-56Ar3 Assign ECDH CK N/A SRAM GRK 192-bit KAS-ECC-SSC KAS-ECC-SSC Deassign Grant 256-bit / A4353 SP 800-56Cr2 GRK N/A SRAM Grant ECDH CK 256-bit AES-GCM KDA RevertWithPSID TPER Reset CreateNamespace DeleteNamespace WriteProtection Sanitize CryptoErase SP 800- Import / FormatNVM

256 bits / A4353 90Arev1 Export Activate

256 bits AES-GCM CTR_DRBG (Encrypt Revert

(AES-256) ed) Reactivate Set CPIN Assign Deassign Grant GenKey Erase SetRange Import RevertWithPSID (Encrypt TPER Reset SP 800- ed)/ DeleteNamespace Sanitize

MEK12 N/A SRAM CryptoErase KEK

256 bits CTR_DRBG (Plaintext FormatNVM

(AES-256) & Activate Encrypte Revert d) Reactivate

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.

Key/SSP Security Use & Size / Generation or Import Name/ Function and Storage7 Zeroisation8 related Strength Establishment /Export Type Cert. Number keys Set CPIN Assign Deassign GenKey Erase SetRange SP 800- RevertWithPSID

256 bits / A4351 TPER Reset

SMK 108rev1 N/A SRAM Root Key

256 bits HMAC CreateNamespace

256 bits / A4351 WriteProtection

KMK 108rev1 N/A SRAM Root Key

256 bits HMAC Sanitize

KBKDF CryptoErase FormatNVM Activate Revert Revoke Root Encryption Key SP 800- Reactivate

256 bits / A4353 Set CPIN

REK 108rev1 N/A SRAM Root Key

256 bits AES-GCM Assign

KBKDF Deassign Grant GenKey Erase SetRange SP 800-

256 bits / A4351 90Arev1 Revoke Root Encryption

Root Key N/A OTP REK

256 bits KBKDF CTR_DRBG Key

(AES-256) Firmware P-384 / A4351 Physically protected PSP Verificatio Manufacturing N/A ROM N/A 192-bit ECDSA stored in the ROM n Key14 Table

14. SSPs The cryptographic module contains an entropy source compliant with SP800-90B. Entropy sources Minimum number of bits of entropy Details Cert #E83 - 0.5 entropy per bit15 Provides entropy input and nonce ENT (P) - Minimum of 256 bits of entropy for DRBG seed to construct a seed for CTR_DRBG (Total seed length of 512 bits) Table
15. Non-Deterministic Random Number Generation Specification

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 Algorithm Type Description Conditions Firmware Curve P-384 with SHA-384 signature ECDSA Module initialization integrity test verifications for firmware integrity Table
11. List of pre-operational self-tests 10.2. Conditional test Algorith Type Description Conditions m Cryptographic KAT: Curve P-384 with SHA-384 signature ECDSA algorithm self- Module initialization verification test Cryptographic KAT: AES-256 GCM mode encryption and AES algorithm self- Module initialization decryption test Cryptographic HMAC algorithm self- KAT: HMAC with SHA-256 Module initialization test Cryptographic SHS algorithm self- KAT: SHA-256 hash digest Module initialization test Cryptographic SHS algorithm self- KAT: SHA-384 hash digest Module initialization test Cryptographic KAT: Key based key derivation using KBKDF algorithm self- Module initialization HMAC with SHA-256 test Cryptographic KAS-ECC- KAT: ECDH P-384 Shared secret algorithm self- Module initialization SSC computation test Cryptographic KAT: OneStepNoCounter KDF with SHA2KDA algorithm self- Module initialization test Pair-wise The module executes a PCT every time a KAS-ECCconsistency key is generated. Module computes dG Key generation SSC test and compares to public key Q.

ECDSA signature verification is performed Firmware load ECDSA if new FW is downloaded or at every Firmware load test test power-on-reset Cryptographic KATs: SP 800-90Arev1 Health testing on DRBG algorithm self- Instantiate, Generate and Reseed Module initialization test functions Cryptographic Start up and Conditional SP800-90B ENT (P) algorithm self- Heath tests: Repetition count test, Module initialization and Continuously test Adaptive proportion test 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.

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