Samsung CryptoCore Cryptographic Module

Certificate

Approved Algorithms (23)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for Samsung CryptoCore Cryptographic Module
  %% 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/>Recovery</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>AES encryption<br/>AES decryption<br/>Cryptographic algorithm self- test and integrity…</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Some services may process<br/>input 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["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 CryptoCore Cryptographic Module
  %% 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/>Recovery</i><br/>src: text:keyword"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>AES encryption<br/>AES decryption<br/>Cryptographic algorithm self- test and integrity…</i><br/>src: securityPolicy.services"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<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,C6 clueLow;
  class C3 clueHigh;

Security Policy, page by page

Samsung Electronics Co., Ltd. Samsung CryptoCore Cryptographic Module Document Version 0.1.17 Last Update: 17-07-2024 ©2024 Samsung Electronics Co., Ltd.

©2024 Samsung Electronics Co., Ltd.

This document is the non-proprietary FIPS 140-3 Security Policy for the Samsung CryptoCore Cryptographic Module. It contains the security 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 1 module.

Purpose and Use: The module provides cryptographic services to applications through an application program interface (API). The module also interacts with the operating system via system calls. Module Embodiment: MultiChipStand Module Characteristics: Cryptographic Boundary: The cryptographic boundary of the module is a single object file named cryptocore.0.2.9.FIPS.1.o, which is statically linked into the position-independent code ©2024 Samsung Electronics Co., Ltd.

libcryptocore.so.0.1.0 shared library. There are no excluded components inside the cryptographic boundary. The module is intended only for single-threaded execution per process. Tested Operational Environment’s Physical Perimeter (TOEPP): The TOEPP of the module is a Samsung Smart TV Q70B with Tizen 7.0. The module is located in the volatile memory controlled by OS Tizen 7.0 installed on hardware platform Samsung Smart TV Q70B. Physical Perimeter Operating System Tizen libc API invocation libcryptocore.so.0.1.0 Cryptographic boundary Cryptographic Functions API invocation Self-Test Application Figure 1: Block Diagram

Tested Module Identification

• Hardware: N/A for this module. Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets): Table 2: Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets) Tested Module Identification
• Hybrid Disjoint Hardware: N/A for this module. Tested Operational Environments - Software, Firmware, Hybrid: ©2024 Samsung Electronics Co., Ltd.

Table 3: Tested Operational Environments - Software, Firmware, Hybrid Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: N/A for this module. CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when so ported if the specific operational environment is not listed on the validation certificate.

There are no components excluded from the security requirements. Modes List and Description: Table 4: Modes List and Description

Approved Algorithms: ©2024 Samsung Electronics Co., Ltd.

Table 5: Approved Algorithms Vendor-Affirmed Algorithms: ©2024 Samsung Electronics Co., Ltd.

Table 6: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: N/A for this module. Non-Approved, Allowed Algorithms with No Security Claimed: N/A for this module. Non-Approved, Not Allowed Algorithms: N/A for this module.

HMAC-SHA2224 HMAC-SHA2256 HMAC-SHA2384 HMAC-SHA2512 ©2024 Samsung Electronics Co., Ltd.

AsymKeyPairKeyGen AsymKeyPairKeyGen AsymKeyPairPubKeyVal HMAC-SHA2256 HMAC-SHA2512 Table 7: Security Function Implementations

©2024 Samsung Electronics Co., Ltd.

AES CTR: the externally loaded counters of AES CTR shall have the property defined in [SP800-38A], 6.5 The Counter Mode.

N/A for this module. N/A for this module. The module passively receives the entropy for seeding/reseeding DRBG while exercising no control over the amount or the quality of the obtained entropy. The random string for seeding/reseeding must supply at least 112 bits of entropy to provide the minimum acceptable security strength that is 112 bits according to [SP800-57pt1r5]. The module employs a SP800-90Ar1 HMAC_DRBG as Random Number Generation service. For DRBG Instantiation to create a seed the module requires a random string of 48 bytes (384 bits) size: 32 bytes (256 bits) for "entropy input" and 16 bytes (128 bits) for "nonce". For periodic DRBG Reseeding to create a reseed the module requires a random string of 64 bytes (512 bits) size: 32 bytes (256 bits) for "entropy input" and 32 bytes (256 bits) for "additional input". For explicit DRBG Reseeding to create a reseed the module requires a random string of 32 bytes (256 bits) size: 32 bytes (256 bits) for "entropy input". The output of the module implemented DRBG is used to generate random bits for

• asymmetric key pair generation that compliant with FIPS 186-4 and SP800-90Ar1,
• signature generation that compliant with FIPS 186-4,
• generation of random number. The calling application is responsible for storage of generated keys returned by the module. It is not possible for the module to output information during the key generating process.

For generating RSA, ECC key pairs, the module implements Asymmetric Key Generation services compliant with FIPS 186-4. The random value used in asymmetric key generation is obtained using Random Number Generation service of the module. In accordance with FIPS 140-3 IG D.H, the module performs Cryptographic Key Generation (CKG) for asymmetric keys as per sections 5.1, 5.2 SP800-133r2 (vendor affirmed) by obtaining a random bit string as per section 4 SP800-133r2 directly from a DRBG without any V, as described in Additional Comments 2 in FIPS 140-3 IG D.H.

N/A ©2024 Samsung Electronics Co., Ltd.

N/A N/A N/A N/A Table 8: Ports and Interfaces As a software-only module, the module does not have physical ports. For the purpose of the FIPS 140-3 validation, the physical ports are interpreted to be the physical ports of the hardware platform on which it runs. The logical interfaces are the application program interface (API) through which applications request services. The control output interface is omitted on purpose because the module does not implement it.

N/A for this module. The module does not support user authentication.

Table 9: Roles The Crypto Officer role is implicitly assumed by the entity accessing the module services. ©2024 Samsung Electronics Co., Ltd.

R,E G,W G,W G,W G,W ©2024 Samsung Electronics Co., Ltd. R,E

©2024 Samsung Electronics Co., Ltd. G,E G,E R,E R,E R,E

R,E N/A N/A G,E G,E R,E R,E N/A Z ©2024 Samsung Electronics Co., Ltd.

©2024 Samsung Electronics Co., Ltd. Z Z G,E G,E

©2024 Samsung Electronics Co., Ltd. G,E G,E

Table 10: Approved Services The approved security service indicator of the module is compliant to the example scenario 2) of [IG] 2.4.C. ©2024 Samsung Electronics Co., Ltd.

The module does not support Software/Firmware loading.

The integrity of the module is verified by comparing MAC calculated on the module at runtime and the value stored in the module, which was calculated at build-time. An approved integrity technique used in the integrity test is HMAC-SHA256 algorithm implemented in the module itself. The integrity test uses a 256-bit key, which resides within the module code and is not considered a SSP. Before executing the integrity test, the module performs CAST of SHA-256 and HMAC-SHA512 algorithms.

The integrity test can be initiated on demand by the operator by calling fips_post() API.

Type of Operational Environment: Modifiable How Requirements are Satisfied: The module runs on a commercially available general-purpose operating system. The operating system is restricted to a single operator (concurrent operators are explicitly excluded). The operational environment is non-configurable for operator, thus the module operates securely by default. The application that requests cryptographic services is the single user of the module, even when the application is serving multiple clients. The operating system provides the capability to separate the module during operation from other functions in the operational environment. Those functions do not obtain information from the module related to the CSPs and do not modify CSPs, PSPs, or the execution flow of the module other than via the interfaces provided by the module itself. The module does not spawn any processes.

The module is comprised of software only and thus does not claim any physical security. ©2024 Samsung Electronics Co., Ltd.

The module does not implement non-invasive attack mitigation techniques to protect the module’s unprotected SSPs from non-invasive attacks referenced in Annex F of FIPS 140-3.

Table 11: Storage Areas The module does not provide persistent storage for keys or SSPs. The module stores SP80090Ar1 DRBG state values and the Entropy buffer for at most the runtime of the module. The module uses pointers to plaintext keys/SSPs that are passed in by the calling application. The module does not store SSP beyond the lifetime of an API call or beyond the runtime of the module. Allocated memory in RAM for SSP is managed by the module.

Table 12: SSP Input-Output Methods SSPs enter the module's cryptographic boundary as cryptographic algorithm API parameters in plaintext. They are associated with memory locations and do not persist across power cycles. The module does not output intermediate key generation values. The module provides the resulting keys as output parameters of key generation service API to the calling application, but they do not cross the physical perimeter. Import and export operations of SSP are plaintext manual electronic entry for the module and user application inside OE physical perimeter (TOEPP) in terms of IG 140-3 9.5.A.

©2024 Samsung Electronics Co., Ltd.

Table 13: SSP Zeroization Methods Zeroisation of sensitive data is performed by calling destruction API function destroy_CryptoCoreContainer() by the operator. This functions overwrites the memory occupied by SSPs with “zeros” and deallocates the memory. The application that uses the module is responsible for calling the destruction function destroy_CryptoCoreContainer(). The calling application is responsible for parameters passed in and out of the module. The return of the destroy_CryptoCoreContainer() function indicates the successful completion of the zeroisation procedure. Zeroisation of entropy buffer is performed by calling the fips_cleanup_entropy_buffer() API or successful completion of the module indicates the successful completion of the zeroisation procedure, accordingly. ©2024 Samsung Electronics Co., Ltd.

©2024 Samsung Electronics Co., Ltd.

Table 14: SSP Table 1 ©2024 Samsung Electronics Co., Ltd.

©2024 Samsung Electronics Co., Ltd.

Table 15: SSP Table 2 ©2024 Samsung Electronics Co., Ltd.

Transition from FIPS 186-4 to FIPS 186-5 and SP 800-186 as specified in FIPS 140-3 IG C.K.

HMACSHA2-256 Table 16: Pre-Operational Self-Tests (*) A MAC is calculated over the module FIPS-relevant APIs at runtime and compared to the value stored in the module, which was calculated at build-time. This MAC is calculated between designated memory addresses of the .text and .rodata sections of the object file, excluding relocatable address parts. These sections have read-only and executable attributes in terms of the ELF file. The content of these sections is formed at the module build stage. While the module is performing the Pre-Operational Self-Test, no other functions are available and all output is inhibited. Once PreOperational Self-Test is completed successfully, the module enters the Approved Mode of Operation and cryptographic services are available.

©2024 Samsung Electronics Co., Ltd.

N/A N/A N/A N/A ©2024 Samsung Electronics Co., Ltd. module startup or ondemand module startup or ondemand module startup or ondemand module startup or ondemand module startup or ondemand

HMACSHA2-512 CDHComponent Curve: P224 module startup or ondemand module startup or ondemand module startup or ondemand module startup or ondemand module startup or ondemand ©2024 Samsung Electronics Co., Ltd.

SP80056Ar3 HMACSHA2-256 HMACSHA2-256 N/A ©2024 Samsung Electronics Co., Ltd. module startup or ondemand

Table 17: Conditional Self-Tests None of the keys used for the KAT are considered as SSP. ©2024 Samsung Electronics Co., Ltd.

Table 18: Pre-Operational Periodic Information (*) A MAC is calculated over the module FIPS-relevant APIs at runtime and compared to the value stored in the module, which was calculated at build-time. This MAC is calculated between designated memory addresses of the .text and .rodata sections of the object file, excluding relocatable address parts. These sections have read-only and executable attributes in terms of the ELF file. The content of these sections is formed at the module build stage. ©2024 Samsung Electronics Co., Ltd.

Table 19: Conditional Periodic Information

The module is built into the operational environment and delivered with a device. There is no standalone delivery of the module as a software library. The module is initialized during the loading of the module before any cryptographic functionality is available. The Tizen operating system is responsible for the initialization and loading processes of the module. The module is designed with constructor (default entry point of the ©2024 Samsung Electronics Co., Ltd.

module) which ensures that CAST and POST are initiated automatically when the module is loaded.

The guidance is provided in the document “Samsung CryptoCore Cryptographic Module, Software Version: 0.2.9.FIPS.1, Functional Design, Document Version 0.1.23, Last Update: 1207-2024”.

The guidance is provided in the document “Samsung CryptoCore Cryptographic Module, Software Version: 0.2.9.FIPS.1, Functional Design, Document Version 0.1.23, Last Update: 1207-2024”.

The usual sequence of secure operations:

• create crypto-container: CryptoCoreContainer *sha = create_CryptoCoreContainer(ID_SHA256);
• perform the operation: sha->MD_getHASH(sha, message, message_len_bytes, digest);
• destroy crypto container: destroy_CryptoCoreContainer(sha);

The module does not implement security mechanisms to mitigate other attacks. ©2024 Samsung Electronics Co., Ltd.