Samsung SCrypto Cryptographic Module

Certificate

Approved Algorithms (27)

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

flowchart LR
  %% Deterministic review-risk graph for Samsung SCrypto 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</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>self-test<br/>Status output<br/>Show status</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>HTTPS<br/>library named: openssl<br/>library named: nss</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>kernel</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 Samsung SCrypto 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</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"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>HTTPS<br/>library named: openssl<br/>library named: nss</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<br/>kernel</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

Samsung Electronics Co., Ltd. Samsung SCrypto Cryptographic Module Software Version: 2.7 Document Version 1.4 Last Update: 7-02-2025 © 2025 Samsung Electronics Co., Ltd.

1 of 27

Contents © 2025 Samsung Electronics Co., Ltd.

2 of 27

©2025 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact, © 2025 Samsung Electronics Co., Ltd.

3 of 27

This document is the non-proprietary FIPS 140-3 Security Policy for the Samsung SCrypto 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 Table 1 - Security Levels Purpose of the Security Policy There are three major reasons that a security policy is needed:

• It is required for FIPS 140-3 validation.
• To provide a specification of the cryptographic security that will allow individuals and organizations to determine whether a cryptographic module, as implemented, satisfies a stated security policy.
• To describe to individuals and organizations the capabilities, protection, and access rights provided by the cryptographic module, thereby allowing an assessment of whether the module will adequately serve the individual or organizational security requirements. Target Audience This document is part of the package of documents that are submitted for FIPS 140-3 conformance validation of the module. It is intended for the following people:
• Developers.
• FIPS 140-3 testing lab.
• The Cryptographic Module Validation Program (CMVP). © 2025 Samsung Electronics Co., Ltd.

4 of 27

2. Cryptographic module specification The following section describes the cryptographic module and how it conforms to the FIPS 140-3 specification in each of the required areas. Module overview The Samsung SCrypto Cryptographic Module (hereinafter referred to as “the module”) is a software module implementing general-purpose cryptographic algorithms. The module is running on a multi-chip standalone general-purpose computing platform. The version of the module is 2.7. The module provides cryptographic services to applications through an application program interface (API). The module also interacts with the operating system via system calls. The module has been tested on the following platforms: Table 2 - Tested Operational Environments The 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. The following platform has not been tested as part of the FIPS 140-3 Level 1 certification, however Samsung affirms that the platform is compliance to the tested and validated platforms. Additionally, Samsung also affirms that the Module will function the same way and provide the same security services on the operating system listed in Table 3 below. Table
3. Vendor Affirmed Operational Environment Modes of operation The module supports both Approved and Non-Approved modes of operation. The Module will be in approved mode when all pre-operational self-tests have completed successfully and only approved algorithms/services are invoked. See Table 4 and Table 9 below for a list of the supported approved/allowed algorithms/services. The non-approved mode is entered when a non-approved algorithm/non-approved service is invoked. See Table 6 and Table 10 for a list of non-approved algorithms/non-approved services. When the module is initialized, the self-tests are executed automatically. After successful completion of self-test, the module enters operational state. Module supports only normal operation. Degraded operation is not supported. The following table shows the Approved algorithms that can be used in Approved Mode of Operation: © 2025 Samsung Electronics Co., Ltd.

5 of 27

1] © 2025 Samsung Electronics Co., Ltd.

6 of 27

Table 4 - Approved Algorithms Notes:

• There are some algorithm modes that were tested but not implemented by the module. Only the algorithms, modes, and key sizes that are implemented by the module are shown in Table 3 above. #2. The DRBG with Cert. #A3243 is called to generate the IV inside the module, and the IV length is 96 bits. The new AES-GCM key will be generated if the module loses power. Table 5
• Entropy Certificate In addition to the above listed Approved/Allowed services, the cryptographic module also provides nonApproved services; however, any use of the module’s non-Approved services causes the module to operate in a non-approved manner. Thus, operators shall not utilize any of the following non-Approved service(s). Table 6
• Non-Approved Algorithms Not Allowed in the Approved Mode of Operation

7 of 27

Please note that due to the lack of the associated self-tests to DSA, KAS-ECC-SSC and KAS-FFC-SSC algorithms, Table 6 lists those algorithms as the Non-Approved Algorithms Not Allowed in the Approved Mode of Operation. The “Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed” table defined in SP 800-140B is missing because the module does not implement any such algorithms. The “Non-Approved Algorithms Allowed in the Approved Mode of Operation” table defined in SP 800-140B is missing because the module does not implement any such algorithms. Cryptographic boundary The module is defined as a multi-chip standalone software module, with the boundary of the Tested Operational Environment’s Physical Perimeter (TOEPP) being defined as the physical perimeter of the tested platform enclosure around which everything runs. The physical perimeter is the hardware platform on which the module is installed. The cryptographic boundary of the module is the SCrypto cryptographic module, a single object module file named fipscanister.o, which is linked to create the executable files scrypto_v2.7_x64_qsee_release.a for the tested platform running QSEE 5.24, QSEE 6.1 (64-bit) and scrypto_v2.7_x64_teegris500_sys_release.so for the tested platform running TEEgris 5.0.0 (64-bit). Figure 1 below illustrates a block diagram of a typical GPC and the module’s physical perimeter. The module’s cryptographic boundary consists of all functionalities contained within the module’s compiled source code. Physical Cryptographic Boundary (the module) perimeter Samsung SCrypto Application Cryptographic Module Figure 1 – Module’s block diagram © 2025 Samsung Electronics Co., Ltd.

8 of 27

3. Cryptographic module 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 module does not implement a trusted channel. The logical interfaces are the application program interface (API) through which applications request services. The following table summarizes the logical interfaces. Table 7 – Ports and Interfaces © 2025 Samsung Electronics Co., Ltd.

9 of 27

The module supports the single role of Crypto Officer (CO), which performs all services including module The Crypto Officer role is implicitly assumed by the entity accessing the module services. The module does not support user authentication. The module does not implement a bypass capability. The module does not implement a self-initiated cryptographic output capability. The module does not support Software loading. n, © 2025 Samsung Electronics Co., Ltd.

10 of 27

© 2025 Samsung Electronics Co., Ltd.

11 of 27

Table 9

• Approved Services Table 10
• Non-Approved Services G = Generate: The module generates or derives the SSP. R = Read: The SSP is read from the module (e.g. the SSP is output). W = Write: The SSP is updated, imported, or written to the module. E = Execute: The module uses the SSP in performing a cryptographic operation. Z = Zeroise: The module zeroises the SSP. © 2025 Samsung Electronics Co., Ltd.

12 of 27

5. Software/Firmware security Integrity technique The module is provided in the form of binary executable code. To ensure the software security, the module is protected by HMAC-SHA2-256 (HMAC Certs. #A3243) algorithm. The software integrity test key (non-SSP) was preloaded to the module’s binary at the factory and used for software integrity test only at the pre-operational selftest. At module’s initialization, the integrity of the runtime executable is verified using an HMAC-SHA2-256 digest which is compared to a value computed at build time. If at the load time the MAC does not match the stored, known MAC value, the module would enter an Error state with all crypto functionality inhibited. On-demand integrity test Integrity tests are performed as part of the Pre-Operational Self-Tests. It is automatically executed at power-on. It can also be invoked by self-test service or powering-off and reloading the module. © 2025 Samsung Electronics Co., Ltd.

13 of 27

6. Operational environment The module operates in a modifiable operational environment per FIPS 140-3 level 1 specifications. The module runs on a commercially available general-purpose operating system executing on the hardware tested platform specified in Table
7. The operating system shall be restricted to a single operator mode of operation (i.e., concurrent operators are explicitly excluded). The external application that makes calls to the cryptographic module is the single user of the module, even when the application is serving multiple clients. The operational environment 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. © 2025 Samsung Electronics Co., Ltd.

14 of 27

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

15 of 27

8. Non-invasive security 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. © 2025 Samsung Electronics Co., Ltd.

16 of 27

9. Sensitive security parameter management © 2024 Samsung Electronics Co., Ltd.

17 of 27

© 2024 Samsung Electronics Co., Ltd.

18 of 27

Table 12 – Non-Deterministic Random Number Generation Specification The module employs an Approved SP 800-90Arev1 CTR_DRBG for creation of random numbers. The module uses the physical entropy source (ESV Certs. #E67, E152, E221 or E224) from the operational environment as the source of random numbers for DRBG seeds. The Entropy Source produces the random numbers from an entropy pool maintained by the underlying Operating System. The module is a software module that contains an approved DRBG that is seeded exclusively The module performs the Repetition Count Test (RCT) and Adaptive Proportion Test (APT) as the Health Test to the entropy source that is used to instantiate the Use of RBG output 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. SSP entry and output All keys and SSPs that are entered from or output to the module are entered from or output to the invoking application running on the same device. Keys/SSPs entered into the module are electronically entered in plain text form. Keys/SSPs are output from the module in plain text form if required by the calling application. The module does not support manual key entry or key output. Keys or other CSPs can only be exchanged between the module and the calling application using appropriate API calls. The module does not output intermediate key generation values.

The module performs two independent internal actions for the output of plaintext CSPs:

1. The module calls the random number generator service and verifies that the service has been completed without any errors.
2. The module performs the Pair-wise Consistency test and verifies that the test is completed without any errors. Only after the successful completion of these two actions will the module allow the output of plaintext CSPs. SSP storage Keys are not stored inside the cryptographic module. A pointer to a plaintext key is passed through the algorithm APIs. Intermediate keys stored in the module’s memory are immediately replaced with 0s in the memory after use. Keys residing in internally allocated data structures (during the lifetime of an API call) can only be accessed using the module defined API. The operating system protects memory and process space from unauthorized access. Only the calling application that creates or imports keys can use or export such keys. All API functions are executed by the invoking calling application in a non-overlapping sequence such that no two API functions will execute concurrently. SSP zeroization The zeroization mechanism for all of the CSPs is to replace 0s in the memory which originally stored the CSPs. Zeroization of sensitive data is performed automatically by calling zeroization API function OPENSSL_cleanse() for temporarily stored CSPs or cycling the power to the tested platform. In addition, the module provides functions to explicitly destroy CSPs related to random number generation services. The calling application is responsible for parameters passed in and out of the module. Input and output interfaces are inhibited while zeroization is performed.

10. Self-tests The module performs a series of power-up self-tests, that covers all of its approved algorithms. The module executes all self-tests when the module is initialized during the boot process. Self-tests can also be manually invoked by calling FIPS_SCRYPTO_post(1). When the module passes all of its power-up Self-tests, the module sets an internal variable to reflect this. A calling application can call the FIPS_status() API to obtain the value of this internal variable (1 if the Self-test was successful, and 0 otherwise if the Self-test failed). In addition to Known Answer Tests (KATs) for each of the module’s cryptographic algorithms, the module also performs a binary integrity test to check for corruption. If any KAT self-test or the integrity test fails, the module sets its error flag (static variable), returns an error code to the API function caller to indicate the error, enters an error state (FIPS_ERR), and inhibits Crypto APIs that return cryptographic information. While the module is executing the self-tests, services are not available, and input and output are inhibited. Pre-operational self-test The module performs Pre-operational Self-tests automatically when the module is loaded into memory (i.e. at power on). The Pre-operational Self-tests contain pre-operational software integrity test to ensure that the module is not corrupted. The integrity test is performed on the runtime image of the module using HMAC-SHA2-256. Prior to software integrity test, a CAST for HMAC-SHA2-256 is performed. If the CAST on the HMAC-SHA-256 is successful, the HMAC value of the runtime image is recalculated and compared with the stored HMAC value precomputed at compilation time (for details, see also Section 5). While the module is performing the Pre-operational Self-tests no other functions are available and all output is inhibited. Once Pre-operational Self-tests are completed successfully, the module enters operational mode and cryptographic services are available. Conditional self-tests Conditional cryptographic algorithm self-tests The module performs conditional cryptographic algorithm self-tests (CASTs) at module initialization to ensure that the algorithms work as expected, before any security function or process is invoked via module interface. The module performs self-tests that cover all Approved cryptographic algorithms supported in the approved mode of operation using the Known-answer Tests (KAT) as shown in the table below. None of the keys used for the KAT are considered as SSP. © 2023 Samsung Electronics Co., Ltd.

22 of 27

SP800-108 KDF

KBKDF KAT

Start-up, on-demand

Table 13

• Self-Tests The Entropy Source is outside of the module cryptographic boundary, but it is within the boundary of the TOEPP, and the module itself does not perform Entropy Source Health Tests. Table 14
• Entropy Source Health Tests The module performs Pair-wise Consistency Tests (PCT) on the cryptographic algorithms shown in the following table. If any of the PCT fail, the module enters the Error state. Table 15
• Pair-wise consistency tests Periodic self-tests The module provides the service to perform both Pre-operational self-test and CASTs on-demand by calling SCRYPTO_post() function. This service performs all the cryptographic algorithm tests listed in Table 13 and preoperational software integrity test. During the execution of the on-demand self-tests, no other functions are available and all output is inhibited. If any of the tests fail, the module will enter the Error state. Error state and status indicators The module has an API indicating the status of the Self-test FIPS_status(). It returns 1 while the modules is in the operational state otherwise 0 while the modules is in the Error state. In the Error state, no cryptographic services are provided, and data output is prohibited. © 2023 Samsung Electronics Co., Ltd.

23 of 27

11. Life-cycle assurance Secure installation 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. Secure initialization and startup The module is initialized during the loading of the module before any cryptographic functionality is available. The operating system is responsible for the initialization and loading processes of the module. The module is designed with constructor (default entry point of the module) which ensures that the cryptographic algorithm self-tests (CASTs) and pre-operational self-test are initiated automatically when the module is loaded. Secure operation The module is provided directly to solution developers and is not available for direct download to the general public. The module is installed on an operating system specified in Section 2.1. Additional Rules of Operation:
12. The writable memory areas of the module (data and stack segments) are accessible only by the application so that the operating system is in "single user" mode, i.e. only the application has access to that instance of the module.
13. The operating system is responsible for multiprocessing operations so that other processes cannot access the address space of the process containing the module.
14. Only the services defined in Table 9 shall be used in Approved Mode of operation. Maintenance requirements The module does not support maintenance role. End of life The module does not provide persistent storage for keys, SSPs, user data, etc. The module does not store any sensitive information beyond the lifetime of an API call. Intermediate CSPs stored in the memory of the module are immediately replaced with 0s in the memory after use. The end user of the operating system is also responsible for zeroizing SSPs when the cryptographic module is no longer deployed or intended for further use by the operator. © 2023 Samsung Electronics Co., Ltd.

24 of 27

12. Mitigation of other attacks The module does not implement security mechanisms to mitigate other attacks. © 2023 Samsung Electronics Co., Ltd.

25 of 27

Glossary and Abbreviations © 2023 Samsung Electronics Co., Ltd.

26 of 27

References FIPS180-4 Secure Hash Standard (SHS) August 2015 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf FIPS186-4 Digital Signature Standard (DSS) July 2013 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf FIPS197 Advanced Encryption Standard November 2001 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf FIPS198-1 The Keyed Hash Message Authentication Code (HMAC) July 2008 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.198-1.pdf IG Implementation Guidance for FIPS 140-3 and the Cryptographic Module Validation Program October, 2022 https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validationprogram/documents/fips%20140-3/FIPS%20140-3%20IG.pdf PKCS#1 Public Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 February 2003 https://www.ietf.org/rfc/rfc3447.txt SP800-38A NIST Special Publication 800-38A - Recommendation for Block Cipher Modes of Operation Methods and Techniques December 2001 https://csrc.nist.gov/publications/detail/sp/800-38a/final SP800-38B NIST Special Publication 800-38B - Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication May 2005 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38b.pdf SP800-56Ar3 NIST Special Publication 800-56A Revision 3 - Recommendation for Pair Wise KeyEstablishment Schemes Using Discrete Logarithm Cryptography April 2018 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf SP800-90Ar1 NIST Special Publication 800-90A Revision 1 - Recommendation for Random Number Generation Using Deterministic Random Bit Generators June 2015 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf SP800-133r2 NIST Special Publication 800-133 Revision 2 - Recommendation for Cryptographic Key Generation June 2020 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133r2.pdf © 2023 Samsung Electronics Co., Ltd.

27 of 27