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.

Contents © 2025 Samsung Electronics Co., Ltd.

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

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

1 General 1

2 Cryptographic module specification 1

3 Cryptographic module interfaces 1

4 Roles, services, and authentication 1

5 Software/Firmware security 1

6 Operational environment 1

7 Physical security N/A

8 Non-invasive security N/A

9 Sensitive security parameter management 1

10 Self-tests 1

11 Life-cycle assurance 1

12 Mitigation of other attacks N/A

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).
• Administrators of the cryptographic module.
• Users of the cryptographic module. © 2025 Samsung Electronics Co., Ltd.

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: # Operating System Hardware Platform Processor PAA/Acceleration

1 QSEE 5.24 (64-bit) Samsung Galaxy S23+ Qualcomm Snapdragon 8 Not implemented

2 QSEE 6.1 (64-bit) Samsung Galaxy S24 Qualcomm Snapdragon 8 Not implemented

3 TEEgris 5.0.0 (64-bit) Samsung Galaxy S24 Samsung Electronics Not implemented

4 TEEgris 5.0.0 (64-bit) Samsung Galaxy Tab Active 5 Samsung Electronics Not implemented

5 TEEgris 5.0.0 (64-bit) Samsung Galaxy Tab S9 FE Samsung Electronics Not implemented

Exynos 1380 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. # Operating Hardware Platform System

1 Linux Kernel 5.15 Samsung Electronics Exynos 1380 running on Samsung A35

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: CAVP Algorithm and Mode/Method Description / Key Size(s) / Use / Function Cert Standard Key Strength(s) #A3243 AES AES-ECB Key Length: 128, 192, 256 bits Symmetric Encryption [FIPS 197] and Decryption [SP 800-38A] © 2025 Samsung Electronics Co., Ltd.

CAVP Algorithm and Mode/Method Description / Key Size(s) / Use / Function Cert Standard Key Strength(s) #A3243 AES AES-CBC Key Length: 128, 192, 256 bits Symmetric Encryption [FIPS 197] and Decryption [SP 800-38A] #A3243 AES AES-CTR Key Length: 128, 192, 256 bits Symmetric Encryption [FIPS 197] and Decryption [SP 800-38A] #A3243 AES AES-OFB Key Length: 128, 256 bits Symmetric Encryption [FIPS 197] and Decryption [SP 800-38A] #A3243 AES AES-CMAC Key Length: 128, 192, 256 bits Message Authentication [FIPS 197] [SP 800-38B] #A3243 AES AES-GCM Key Length: 128, 192, 256 bits Authenticated Symmetric [FIPS 197] Encryption and [SP 800-38D] Decryption #A3243 AES AES-KW Key Length: 128, 192, 256 bits Key Wrapping and [FIPS 197] Unwrapping [SP 800-38F] #A3243 ECDSA KeyGen Curve: P-224, P-256, P-384, P- Asymmetric Key [FIPS 186-4] 521 Generation #A3243 ECDSA KeyVer Curve: P-224, P-256, P-384, P- Asymmetric Public Key [FIPS 186-4] 521 Verification #A3243 ECDSA SigGen Curve: P-224, P-256, P-384, P- Digital Signature [FIPS 186-4] 521 Generation #A3243 ECDSA SigVer Curve: P-224, P-256, P-384, P- Digital Signature [FIPS 186-4] 521 Verification #A3243 DRBG CTR_DRBG with Key Length: 256 bits Random Number [SP800-90Arev1] AES-256 Generation Derivation Function Disabled No Prediction Resistance #A3243 HMAC [FIPS 198- SHA-1 Key Length 112 bits or greater Keyed Hash 1] #A3243 HMAC SHA2-224 Key Length 112 bits or greater Keyed Hash [FIPS 198-1] #A3243 HMAC SHA2-256 Key Length 112 bits or greater Keyed Hash [FIPS 198-1] #A3243 HMAC SHA2-2384 Key Length 112 bits or greater Keyed Hash [FIPS 198-1] #A3243 HMAC SHA2-512 Key Length 112 bits or greater Keyed Hash [FIPS 198-1] #A3243 SHS SHA-1 N/A Message Digest [FIPS 180-4] Note: SHA-1 is not used for digital signature generation #A3243 SHS SHA2-224 N/A Message Digest [FIPS 180-4] #A3243 SHS SHA2-256 N/A Message Digest [FIPS 180-4] #A3243 SHS SHA2-384 N/A Message Digest [FIPS 180-4] #A3243 SHS SHA2-512 N/A Message Digest [FIPS 180-4] #A3243 RSA Key Generation Modulus: 2048, 3072 Asymmetric Key [FIPS 186-4] Mode: B.3.3, Generation Primality Tests: C.2 #A3243 RSA Signature Modulus: 2048, 3072 Digital Signature [FIPS 186-4] Generation Generation (PKCS#1 v1.5) and (PKCS-PSS) © 2025 Samsung Electronics Co., Ltd.

CAVP Algorithm and Mode/Method Description / Key Size(s) / Use / Function Cert Standard Key Strength(s) #A3243 RSA Signature Modulus: 1024, 2048, 3072 Digital Signature [FIPS 186-4] Verification Verification (PKCS#1 v1.5) and (PKCS-PSS) #A3243 KBKDF [SP800- KDF Mode: counter Supported Length: 512-4096 Key Derivation 108] MAC Mode: Increment 1 Fixed Data Order: (CVL) HMAC-SHA2-512 after/before/middle fixed data Counter Length: 8, 16, 24, 32 #A3243 RSA Decryption N/A Modulus: 2048 RSADP Decryption Primitive [SP80056Brev2] (CVL) Vendor CKG Section 5 Cryptographic Key Key generation. Affirmed (SP800-133rev2) Generation; SP 800-133rev2 and IG D.H. Note: The cryptographic module performs Cryptographic Key Generation (CKG) for asymmetric keys as per section 5 in SP800133rev2 (vendor affirmed). A seed (i.e., the random value) used in asymmetric key generation is a direct output from SP80090Arev1 CTR_DRBG 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.
• The AES-GCM IV generation method from AES Cert. #A3243 is in compliance with IG C.H, scenario #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. Vendor Name Certificate Number Qualcomm Technologies, Inc. E67 Qualcomm Technologies, Inc. E152 Samsung Electronics Co., Ltd E221 Samsung Electronics Co., Ltd E224 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). Algorithm/Function Use/Function DSA Key Generation DSA keypair generation [FIPS186-4] DSA Signature Generation DSA signature generation [FIPS186-4] DSA Signature Verification DSA signature verification [FIPS186-4] KAS-FFC-SSC [SP800-56A Rev 3] Diffie-Hellman Key Agreement primitive KAS-ECC-SSC [SP800-56A Rev 3] EC Diffie-Hellman Key Agreement primitive Table 6
• Non-Approved Algorithms Not Allowed in the Approved Mode of Operation © 2025 Samsung Electronics Co., Ltd.

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.

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. Physical port Logical interface Data that passes over port/interface N/A Data input interface Arguments for an API call that provide the data to be used or processed by the module N/A Data output interface Arguments output from an API call N/A Control input interface Arguments for an API call used to control and configure module operation N/A Control output interface Not applicable N/A Status output interface Return values, and or log messages Table 7

• Ports and Interfaces © 2025 Samsung Electronics Co., Ltd.

4. Roles, services, and authentication The module supports the single role of Crypto Officer (CO), which performs all services including module installation and configuration. 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. Role Service Input Output CO Symmetric encryption/decryption Input for Encryption: key Output for Encryption: and plain text cipher text; Input for Decryption: key Output for Decryption: and cipher text plain text CO Asymmetric key generation RSA - Padding Method, Modulo Key pair size, ECDSA - Curve Type CO Key wrapping Key Wrapped key CO Digital signature generation Private key, Message Signature Digest CO Digital signature verification Public key, Message Digest, Verification result Signature, RSA - Padding Method, Modulo n, ECDSA - Curve Type CO Message digest generation Message Message digest CO MAC generation Key, message Message authentication code CO Random Number Generation Entropy input string, Random bits Personalization string, Additional input CO Key derivation Key (SP800-108) Derived Key CO RSA Decryption primitive RSA private key, Cipher text Message CO Show status None Module’s status CO Show version None Module’s name/ID and versioning information CO Zeroization SSPs Zeroized and released memory space CO Cryptographic Algorithm Self-Test None Self-test status and Integrity Test CO Module Installation and Configuration None None Table 8

• Roles, Service Commands, Input and Output Service Description Approved Keys and/or Roles Access Indicator Security SSPs rights to Functions Keys and/or SSPs Symmetric Encrypt a plain AES-ECB, AES key CO W, E Return code “1” encryption/ text or Decrypt AES-CBC, denotes use of decryption a cipher text AES-OFB, approved security AES-CTR, service AES-GCM © 2025 Samsung Electronics Co., Ltd.

Service Description Approved Keys and/or Roles Access Indicator Security SSPs rights to Functions Keys and/or SSPs Asymmetric Generate CKG, RSA private key, CO G, R, W Return code “1” key generation asymmetric key CTR_DRBG, RSA public key, denotes use of pair RSA KeyGen, ECDSA private approved security ECDSA KeyGen, key, service ECDSA KeyVer ECDSA public key, Key wrapping Encrypt or AES-KW AES key CO W, E Return code “1” decrypt a key wrapping key denotes use of value approved security service Digital Generate digital RSA SigGen, RSA private key, CO W, E Return code “1” signature signature ECDSA SigGen ECDSA private denotes use of generation key, approved security service Digital Verify digital RSA SigVer, RSA public key, CO W, E Return code “1” signature signature ECDSA SigVer ECDSA public denotes use of verification key, approved security service Message Generate SHA-1, None CO N/A Return code “1” digest message digest SHA2-224, denotes use of generation SHA2-256, approved security SHA2- 384, service SHA2-512 MAC Generate AES-CMAC, HMAC key, CO W, E Return code “1” generation message HMAC-SHA-1, CMAC key, denotes use of authentication HMAC-SHA2-224, approved security code HMAC-SHA2-256, service HMAC-SHA2-384, HMAC-SHA2-512 Random Generate CTR_DRBG Entropy input CO G, R, E Return code “1” Number random number string, denotes use of Generation DRBG seed, approved security DRBG service internal state V value, DRBG key, Key derivation Derive keying KBKDF KBKDF key- CO W, E Return code “1” material derivation key denotes use of approved security service RSA Decryption with RSA Decryption RSA private key CO W, E Return code “1” Decryption RSADP Primitive denotes use of primitive approved security service Show status Provide N/A N/A CO N/A N/A Module’s current status (status message) Show version Provide N/A N/A CO N/A N/A Module’s name and version information Zeroization Zeroize SSP N/A ALL SSPs CO Z N/A © 2025 Samsung Electronics Co., Ltd.

Service Description Approved Keys and/or Roles Access Indicator Security SSPs rights to Functions Keys and/or SSPs Cryptographic Initiate AES-ECB, N/A CO N/A N/A Algorithm Self- cryptographic AES-CMAC, Test and algorithm self- AES-GCM, Integrity Test test and AES-KW, integrity test DRBG, ECDSA Sign, ECDSA verify, HMAC-SHA2-256, KBKDF, RSA Sign, RSA Verify, SHA-1, SHA2-256, SHA2-512 Module Run N/A N/A CO N/A N/A Installation and cryptographic Configuration algorithm selftest and integrity test at the module start-up Table 9

• Approved Services Service Description and Algorithms Roles Indicator Input/Output Accessed DSA Key DSA Key Generation DSA CO Return code “0” denotes use of nonGeneration [FIPS186-4] approved security service DSA Signature DSA Signature Generation DSA CO Return code “0” denotes use of nonGeneration [FIPS186-4] approved security service DSA Signature DSA Signature Verification DSA CO Return code “0” denotes use of nonVerification [FIPS186-4] approved security service Diffie-Hellman Key Diffie-Hellman Key KAS-FFC-SSC CO Return code “0” denotes use of nonAgreement primitive Agreement primitive approved security service [SP800-56A Rev 3] EC Diffie-Hellman EC Diffie-Hellman Key KAS-ECC-SSC CO Return code “0” denotes use of nonKey Agreement Agreement primitive approved security service primitive [SP800-56A Rev 3] 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. The approved security service indicator of the module is compliant to the example scenario 2) of [IG] 2.4.C. © 2025 Samsung Electronics Co., Ltd.

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.

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.

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

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.

9. Sensitive security parameter management Key/SSP Strength Security Function Generation Import / Establi- Storage Zeroisation Use & related Name/Type and Cert. Number Export shment keys AES keys 128, 192 AES-ECB, N/A Import from None Tested platform’s RAM for By calling Symmetric (CSP) and 256 AES-CBC, calling the lifetime of API call, OPENSSL_cleanse Encryption / bits AES-OFB, application under the module control function or cycling the Decryption AES-CTR, within power to the tested AES-GCM TOEPP Note: The module does platform not provide persistent Algo Cert. #A3243 No Export keys/ SSPs storage. AES key 128, 192 AES-KW N/A Import from None Tested platform’s RAM for By calling Key wrapping wrapping key and 256 Calling the lifetime of API call, OPENSSL_cleanse and unwrapping (CSP) bits Algo Cert. #A3243 application under the module control. function or cycling the within power to the tested TOEPP Note: The module does platform not provide persistent No Export keys/ SSPs storage CMAC keys 128, 192 AES-CMAC N/A Import from None Tested platform’s RAM for By calling CMAC (CSP) and 256 calling the lifetime of API call, OPENSSL_cleanse Generation bits Algo Cert. #A3243 application under the module control. function or cycling the within Note: The module does power to the tested TOEPP not provide persistent platform keys/ SSPs storage. No Export HMAC keys Min 112 HMAC-SHA-1, N/A Import from None Tested platform’s RAM for By calling Keyed Hash (CSP) bits HMAC-SHA2-224, calling the lifetime of API call, OPENSSL_cleanse HMAC-SHA2-256, application under the module control. function or cycling the HMAC-SHA2-384, within Note: The module does power to the tested HMAC-SHA2-512, TOEPP not provide persistent platform keys/ SSPs storage. Algo Cert. #A3243 No Export © 2024 Samsung Electronics Co., Ltd.

Key/SSP Strength Security Function Generation Import / Establi- Storage Zeroisation Use & related Name/Type and Cert. Number Export shment keys RSA private Equal to DRBG, Internally Import and None Tested platform’s RAM for By calling Digital Signature key 2048-bit, RSA KeyGen, generated Export to the lifetime of API call, OPENSSL_cleanse Generation (CSP) 3072-bit RSA SigGen conformant to Calling under the module control. function or cycling the RSA key SP800-133r2 application Note: The module does power to the tested Related: RSA Algo Cert. #A3243 (CKG) using FIPS within not provide persistent platform public key 186-4 RSA key TOEPP. keys/ SSPs storage. generation method, and the random value used in the key generation is generated using SP800-90Arev1 DRBG RSA public Equal to RSA SigVer Internally derived Import and None Tested platform’s RAM for By calling Digital Signature key 2048-bit, per the FIPS 186-4 Export to the lifetime of API call, OPENSSL_cleanse Verification (PSP) 3072-bit Algo Cert. #A3243 RSA key Calling under the module control. function or cycling the RSA key generation method application Note: The module does power to the tested Related: RSA within not provide persistent platform private key TOEPP. keys/ SSPs storage. ECDSA private Equal to DRBG, Internally Import and None Tested platform’s RAM for By calling Digital Signature key 224-bit, ECDSA KeyGen, generated Export to the lifetime of API call, OPENSSL_cleanse Generation (CSP) 256-bit, ECDSA KeyVer, conformant to Calling under the module control. function or cycling the 384-bit, ECDSA SigGen, SP800-133r2 application Note: The module does power to the tested Related: ECDSA 521-bit (CKG) using FIPS within not provide persistent platform public key ECC key Algo Cert. #A3243 186-4 ECDSA key TOEPP. keys/ SSPs storage. generation method, and the random value used in the key generation is generated using SP800-90Arev1 DRBG ECDSA public Equal to ECDSA SigVer Internally derived Import and None Tested platform’s RAM for By calling Digital Signature key 224-bit, per the FIPS 186-4 Export to the lifetime of API call, OPENSSL_cleanse Verification (PSP) 256-bit, Algo Cert. #A3243 ECDSA key calling under the module control. function or cycling the 384-bit, generation method application Note: The module does power to the tested Related: ECDSA 521-bit within not provide persistent platform private key ECC key TOEPP. keys/ SSPs storage © 2024 Samsung Electronics Co., Ltd.

Key/SSP Strength Security Function Generation Import / Establi- Storage Zeroisation Use & related Name/Type and Cert. Number Export shment keys KBKDF key- At least 112 KBKDF N/A Import from None Tested platform’s RAM for By calling Key Derivation derivation key bits calling the lifetime of API call, OPENSSL_cleanse (CSP) Algo Cert. #A3243 application under the module control. function or cycling the within Note: The module does power to the tested TOEPP not provide persistent platform keys/ SSPs storage. No Export Entropy input 384 bits CTR_DRBG Obtained from the Import to the None Tested platform’s RAM for By calling Random Number string Entropy Source module via the lifetime of API call, OPENSSL_cleanse Generation (CSP) Algo Cert. #A3243 within TOEPP Module’s under the module control. function or cycling the API within Note: The module does power to the tested TOEPP not provide persistent platform keys/ SSPs storage Export: No DRBG seed 256 bits CTR_DRBG Internally Derived N/A None Tested platform’s RAM for By calling Random Number (CSP) from entropy input the lifetime of API call, OPENSSL_cleanse Generation Algo Cert. #A3243 string as defined by under the module control. function or cycling the SP800-90Arev1 Note: The module does power to the tested not provide persistent platform keys/ SSPs storage DRBG 256 bits CTR_DRBG Internally Derived N/A None Tested platform’s RAM for By calling Random Number internal Algo Cert. #A3243 from entropy input the lifetime of API call, OPENSSL_cleanse Generation s tate V string as defined by under the module control. function or cycling the value (CSP) SP800-90Arev1 Note: The module does power to the tested not provide persistent platform keys/ SSPs storage DRBG key 256 bits CTR_DRBG Internally Derived N/A None Tested platform’s RAM for By calling Random Number (CSP) Algo Cert. #A3243 from entropy input the lifetime of API call, OPENSSL_cleanse Generation string as defined by under the module control. function or cycling the SP800-90Arev1 Note: The module does power to the tested not provide persistent platform keys/ SSPs storage Table 11

• SSPs

Entropy sources Minimum number of bits of entropy Details Snapdragon(R) 8 Gen 2 Mobile Platform developed by Entropy Per Sample: 0.420625 bits; ESV Cert. #E67 Qualcomm Technologies, Inc. Sample Size: 4 bits Physical Entropy Source. Used to seed approved SP800-90Arev1 Implementation Name: Entropy Source of the DRBG. The entropy source is located inside the module’s physical Qualcomm(R) Pseudo Random Number Generator perimeter, but the outside the module’s boundary Snapdragon(R) 8 Gen 3 Mobile Platform developed by Entropy Per Sample: 0.342458 bits; ESV Cert. #E152 Qualcomm Technologies, Inc. Sample Size: 4 bits Physical Entropy Source. Used to seed approved SP800-90Arev1 Implementation Name: Entropy Source of the DRBG. The entropy source is located inside the module’s physical Qualcomm(R) Pseudo Random Number Generator perimeter, but the outside the module’s boundary Samsung Electronics Exynos 2400 developed by Entropy Per Sample: 0.5 bits; ESV Cert. #E221 Samsung Electronics Co., Ltd. Sample Size: 1 bit Physical Entropy Source. Used to seed approved SP800-90Arev1 Implementation Name: Samsung TRNG DRBG. The entropy source is located inside the module’s physical perimeter, but the outside the module’s boundary Samsung Electronics Exynos 1380 developed by Entropy Per Sample: 0.5 bits; ESV Cert. #E224 Samsung Electronics Co., Ltd. Sample Size: 1 bit Physical Entropy Source. Used to seed approved SP800-90Arev1 Implementation Name: Samsung TRNG DRBG. The entropy source is located inside the module’s physical perimeter, but the outside the module’s boundary Table 12

• Non-Deterministic Random Number Generation Specification Random number generation 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 from one known entropy source located inside the module’s physical perimeter but outside the module’s boundary. The module provides at least 256 bits of entropy to instantiate the DRBG. 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 module’s DRBG. Use of RBG output The module’s SP800-90Arev1 CTR_DRBG is used to generate random numbers for key generation. 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. Algorithm Test Condition AES AES-ECB with 128 bits Encryption KAT Start-up, on-demand AES-ECB with 128 bits Decryption KAT AES-CMAC AES-CMAC with 128 bits MAC Generation KAT Start-up, on-demand AES-CMAC with 256 bits MAC Generation KAT AES-GCM AES-GCM with 256 bits Authenticated Encryption KAT Start-up, on-demand AES-GCM with 256 bits Authenticated Decryption KAT AES-KW AES-KW with 256 bits Encryption KAT Start-up, on-demand AES-KW with 256 bits Decryption KAT DRBG CTR_DRBG Instantiate KAT Start-up, on-demand CTR_DRBG Generate KAT CTR_DRBG Reseed KAT Note: DRBG Health Tests as specified in NIST SP 80090Arev1 Section 11.3 are performed ECDSA ECDSA P-256 with SHA2-256 SigGen KAT Start-up, on-demand ECDSA ECDSA P-256 with SHA2-256 SigVer KAT Start-up, on-demand HMAC HMAC-SHA2-256 KAT Start-up, on-demand RSA RSA 2048 modulus with SHA2-256 SigGen KAT Start-up, on-demand RSA RSA 2048 modulus with SHA2-256 SigVer KAT Start-up, on-demand SHA SHA-1 KAT Start-up, on-demand SHA2-256 KAT SHA2-512 KAT © 2023 Samsung Electronics Co., Ltd.

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. Algorithm Test Condition SP800-90B Repetition Count Test (RCT) and Adaptive Proportion Test (APT) Start-up, Continuous and Entropy Source on-demand Table 14
• Entropy Source Health Tests Conditional pair-wise consistency 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. Algorithm Test Condition ECDSA Pair-wise consistency test After key pair generation prior to the first exportation, or prior to the first operational use RSA Pair-wise consistency test After key pair generation prior to the first exportation, or prior to the first operational use 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.

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.

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

Glossary and Abbreviations AES Advanced Encryption Specification CAST Cryptographic Algorithm Self-Test CAVP Cryptographic Algorithm Validation Program CBC Cipher Block Chaining CFB Cipher Feedback CMAC Cipher-based Message Authentication Code CMVP Cryptographic Module Validation Program CSP Critical Security Parameter CTR Counter mode of AES CVL Component Validation List DSA Digital Signature Algorithm ECC Elliptic Curve Cryptography FIPS Federal Information Processing Standards Publication HMAC Hash Message Authentication Code KAT Known-answer Test MAC Message Authentication Code NIST National Institute of Science and Technology OFB Output Feedback POST Pre-Operational Self-Test PSS Probabilistic Signature Scheme RNG Random Number Generator RSA Rivest, Shamir, Addleman SHA Secure Hash Algorithm SHS Secure Hash Standard © 2023 Samsung Electronics Co., Ltd.

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.