Samsung Kernel Cryptographic Module

Certificate

Approved Algorithms (12)

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

flowchart LR
  %% Deterministic review-risk graph for Samsung Kernel 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/>no library/version identified</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 Kernel 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/>no library/version identified</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 Kernel Cryptographic Module Software Version: 2.3 Document Version 1.3 Last Update: July 21, 2025 © 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.

Contents © 2025 Samsung Electronics Co., Ltd.

This document is a non-proprietary FIPS 140-3 Security Policy for the Samsung Kernel 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 140-3 (Federal Information Processing Standards Publication 140-3) for an Table 1. Security Levels Purpose of the Security Policy There are three major reasons for which a security policy is needed:

• It is required for a FIPS 140-3 validation,
• To provide a specification of the cryptographic security that will allow individuals and organizations to determine whether the cryptographic module, as implemented, satisfies the 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 a part of the package of documents that is submitted for FIPS 140-3 conformance validation of the module. It is intended for the following people:
• Developers.
• FIPS 140-3 testing laboratory.
• The Cryptographic Module Validation Program (CMVP). © 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 Kernel Cryptographic Module (hereafter referred to as “the module” or SKC) is a software module running on a multi-chip standalone general-purpose computing platform. The module’s software version number is 2.3. The module provides cryptographic services to Kernel through an application program interface (API). The binary image that contains the Samsung Kernel Cryptographic Module for the appropriate platform is boot.img. The module has been tested on the following platforms. Table
3. 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 ported to an operational environment which is not listed on the validation certificate. The following platforms have not been tested as part of the FIPS 140-3 Level 1 certification however Samsung affirms that these platforms are 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 any of the operating systems listed below. Table
4. Vendor Affirmed Operational Environments Modes of operation When the module starts up, the Self-tests are executed automatically and the module enters the operational state if the self-tests pass. A failure of the self-test invokes a panic and the only way to recover the state is to reboot. Table 4 lists all Approved security functions of the module, including specific key size(s) employed for approved services, and implemented modes of operation. The module is in the Approved mode of operation when the module utilizes the services that use the security functions listed in the Table
5. The Approved mode of operation is configured in the system by default and can only be transitioned into the non-Approved mode by calling one of the non-Approved services listed in Table 10. © 2025 Samsung Electronics Co., Ltd.

Table

4. Approved Algorithms Table
5. Non-approved Algorithms Not Allowed in Approved Mode of Operation © 2025 Samsung Electronics Co., Ltd.

In addition, the module does not support the following algorithms.

• Non-Approved Algorithms Allowed in Approved Mode of Operation
• Non-Approved Algorithms Allowed in Approved Mode of Operation with No Security Claimed 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. 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 and comprises the following object files components. The object files are generated from the sources through the kernel build process. The module is intended only for single-process execution. Table 6. The module objects list © 2025 Samsung Electronics Co., Ltd.

Internal Samsung Kernel Kernel Cryptographic Cryptographic calling Module code fips140_integrity. boundary o fips140_post.o fips140_test.o Kernel fips140_out.o invocation … TOEPP Physical (.rodata, .text, .init.te xt) perimeter Figure

1. Module’s Cryptographic Boundary
2. 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
3. Ports and Interfaces
4. Roles, services and authentication The module supports Crypto Officer (CO) role. The cryptographic module does not provide any authentication methods. The module does not allow concurrent operators. The Crypto Officer is implicitly assumed based on the service requested. The module does not implement a bypass capability. The module does not implement a selfinitiated cryptographic output capability. The module does not support Software/Firmware loading The module provides the following services to the Crypto Officer. © 2025 Samsung Electronics Co., Ltd.

Table 8. Roles, Service Commands, Input and Output © 2025 Samsung Electronics Co., Ltd.

Table 9. Approved Services R = Read: The SSP is read from the module (e.g. the SSP is output). © 2025 Samsung Electronics Co., Ltd.

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. Table

10. Non-Approved Services
11. Software/Firmware security Integrity techniques 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. #A3242) algorithm. The software integrity test key (non-SSP) was preloaded to the module’s binary in 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 a HMAC-SHA2-256 digest which is compared to a value computed at build time. If at load time the MAC does not match the stored, known MAC value, the module would enter to an Error state with all crypto functionality inhibited. Integrity test on-demand Integrity test is performed as part of the Pre-Operational Self-Tests. It is automatically executed at power-on. The operator can power-cycle or reboot the tested platform to initiate the software integrity test on-demand.
12. Operational environment The module operates in a modifiable operational environment per FIPS 140-3 level 1 specifications. The module runs within a commercially available kernel of the general-purpose operating system. The module is executing on the hardware specified in the Table
13. The operating is restricted to a single operator. Only a single instance of the module is allowed in the Operational environment. The operating environment is non-configurable for the operator. 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. The module does not spawn any processes. © 2025 Samsung Electronics Co., Ltd.

7. Physical security The module is comprised of software only and thus does not claim any physical security.
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.
9. Sensitive security parameters management The following table summarizes the keys and Sensitive Security Parameters (SSPs) that are used by the cryptographic services implemented in the module: Table
10. SSPs Notes: • The module protects all keys/SSPs through the memory separation and protection mechanisms provided by the Kernel. • The module doesn’t operate with any PSP. © 2025 Samsung Electronics Co., Ltd.

SSP entry and output 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 Approved and Non-Approved services listed in Table 4. and Table 5 are working with separate data blocks, so sharing SSP at switching between approved/non-approved is impossible. SSP storage The module does not provide persistent storage for keys or SSPs. The module uses pointers to plaintext keys/SSPs that are passed in by the calling application. The module does not store any SSP beyond the lifetime of an API call. Allocated memory in RAM for SSP is managed by the module. SSP zeroization The zeroization mechanism for all of the CSPs is to replace 0s in the memory which originally store the CSPs. Zeroization of the sensitive data within the module and is performed automatically in the frame of release of early allocated crypto handler, by calling function crypto_free_<transformation type>() e.g. crypto_free_skcipher() for symmetric cyphers or crypto_free_shash() for hashes. In addition, powering down the tested platform also has all SSPs zeroized. 10. Self-tests All the pre-operational self-test and conditional self-tests are performed automatically in the frame of module initialization routine at the kernel boot up. The module performs Cryptographic Algorithm Self-Tests (CASTs) first, and then subsequently conducts the software integrity test. The Self-tests do not require any operator intervention. If any of the Self-tests fail, the module enters the Error state. In the Error state, all output interfaces are inhibited and no cryptographic operations are allowed. The module can be recovered from the Error state by module reboot only. 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 Cryptographic algorithm self-tests The module performs Cryptographic Algorithm Self-Tests at module initialization to ensure that the algorithms work as expected, before any security function or process is invoked via module interface, as detailed below. © 2025 Samsung Electronics Co., Ltd.

Table

12. Cryptographic Algorithm Self-Tests Periodic/Self-tests on-demand The module performs on-demand self-tests initiated by the operator (via calling fips140_post() service), by powercycling, or rebooting the tested platform. The pre-operational software integrity test and the full suite of self-tests listed in Table 12 are executed. The same procedure may be employed by the operator to perform periodic selftests. If any of the tests fail, the module will enter error state. Error state and status indicators The module has a variable (skc_fips_enabled) indicating the status of the Self-test. It contains 0 if the Self-test was failed and it contains 1 if the Self-test was successful. The kernel logs contains message: FIPS : POST - integrity test failed in case of integrity test is failed, FIPS : <alg name>, test failed, err=<test number>
13. Life-cycle assurance Configuration management Perforce is used as the repository for both source code and documents. All source code and documents are maintained in an internal server. Release is based on the Changelist number, which is automatically generated. Every check-in process creates a new Changelist number. Versions of controlled items include information about each version. For documentation, document version number inside the document provides the current version of the document. Version control maintains all the previous versions and the version control system automatically numbers revisions. For source code, unique information is associated with each version such that source code versions can be associated with binary versions of the final product. The source code of the module available in the Samsung internal Perforce repository, as listed in Functional Design document, is used to build target binary. © 2025 Samsung Electronics Co., Ltd.

Secure initialization and startup This cryptographic module is built-in along with the Linux Kernel. The module is initialized during the Kernel bootup before any cryptographic functionality is available. The Kernel is responsible for the initialization and loading processes of the module. The module is designed with module init entry point which ensures that the Preoperational self-tests and CASTs are initiated automatically when the module is loaded. Delivery and operation The module is provided directly to solution developers and is not available for direct download to the general public. The module sources are stored and maintained at a secure development facility with controlled access. The development team and the manufacturing factory share a secured internal server for exchanging binary software images. The factory is also a secure site with strict access control to the manufacturing facilities. The module binary is installed on the mobile devices (phone and tablets) using direct binary image installation at the factory. The mobile devices are then delivered to mobile service operators. Users cannot install or modify the module. Samsung vets all service providers and establishes secure communication with them for delivery of tools and software updates. If the binary is modified by an unauthorized entity, the device has a feature to detect the change and thus not accept the binary modified by an unauthorized entity. 12. Mitigation of other attacks The module does not implement security mechanisms to mitigate other attacks. © 2025 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 CMVP               Cryptographic Module Validation Program CSP                Critical Security Parameter DRBG               Deterministic Random Bytes Generator 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 POST               Pre-Operational Self-Test RNG                Random Number Generator SHA                Secure Hash Algorithm SHS                Secure Hash Standard References