Ideem ZSM Cryptographic Module

Certificate

Approved Algorithms (53)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for Ideem ZSM 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>Recovery</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>AES for Multi-party Symmetric Encryption/Decryption<br/>AES for Symmetric Encryption/Decryption<br/>AES-XTS for Symmetric Encryption/Decryption</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>HTTPS<br/>library named: openssl</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Some services may process<br/>input before, or without,<br/>operator authentication."]
    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["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 Ideem ZSM 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>Recovery</i><br/>src: text:keyword"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>AES for Multi-party Symmetric Encryption/Decryption<br/>AES for Symmetric Encryption/Decryption<br/>AES-XTS for Symmetric Encryption/Decryption</i><br/>src: securityPolicy.services"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>HTTPS<br/>library named: openssl</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>application</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C2,C5,C6 clueLow;
  class C3 clueHigh;

Security Policy, page by page

Ideem, Inc. Ideem ZSM Cryptographic Module Software Version: 1.0 FIPS Security Level: 1 Document Version: 1.0 Prepared for: Prepared by: Ideem, Inc.

Kansas City, MO 64112 United States of America Corsec Security, Inc.

Fairfax, VA 22033 United States of America Phone: +1 816 280 4456 www.useideem.com Phone: +1 703 267 6050 www.corsec.com

February 19, 2025 Abstract This is a non-proprietary Cryptographic Module Security Policy for the Ideem ZSM Cryptographic Module (version: 1.0) from Ideem, Inc. (Ideem). This Security Policy describes how the Ideem ZSM Cryptographic Module meets the security requirements of Federal Information Processing Standards (FIPS) Publication 140-3, which details the U.S. and Canadian government requirements for cryptographic modules. More information about the FIPS 140-3 standard and validation program is available on the National Institute of Standards and Technology (NIST) and the Canadian Centre for Cyber Security (CCCS) Cryptographic Module Validation Program (CMVP) website at http://csrc.nist.gov/groups/STM/cmvp. This document also describes how to run the module in a secure Approved mode of operation. This policy was prepared as part of the Level 1 FIPS 140-3 validation of the module. The Ideem ZSM Cryptographic Module is referred to in this document as Ideem Cryptographic Module or the module. References This document deals only with operations and capabilities of the module in the technical terms of a FIPS 140-3 cryptographic module security policy. More information is available on the module from the following sources:

• The Ideem website www.useideem.com contains information on the full line of services and solutions from Ideem.
• The search page on the CMVP website (https://csrc.nist.gov/Projects/cryptographic-module-validationprogram/Validated-Modules/Search) can be used to locate and obtain vendor contact information for technical or sales-related questions about the module. Document Organization ISO/IEC 19790 Annex B uses the same section naming convention as ISO/IEC 19790 section 7 - Security requirements. For example, Annex B section B.2.1 is named “General” and B.2.2 is named “Cryptographic module specification,” which is the same as ISO/IEC 19790 section 7.1 and section 7.2, respectively. Therefore, the format of this Security Policy is presented in the same order as indicated in Annex B, starting with “General” and ending with “Mitigation of other attacks.” If sections are not applicable, they have been marked as such in this document. Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 Table of Contents 1. 1.1 1.2 2. 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 3. 3.1 4. 4.1 4.2 4.3 4.4 5. 5.1 5.2 6. 6.1 7. 8. 9. 9.1 9.2 9.3 9.4 Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 List of Tables List of Figures Figure 4 - Logical Diagram of the Cryptographic Module Running on Different Virtual Machines in the Same Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

1. 1.1 Overview February 19, 2025 Ideem ZSM Cryptographic Module randomly splits keys across servers and mobile devices so that they are never in any single place to be stolen. The advanced protocols used in Ideem Cryptographic Module ensure that even if servers or devices are breached and completely controlled by an attacker, the secrets and credentials cannot be stolen. The result is that digital assets remain safe, even if all else fails and attackers get inside the network. Furthermore, Ideem Cryptographic Module frequently refreshes the random split key process by distributing different, random key parts to each Ideem server or device. As a result of the refresh, even in the extremely unlikely case that an attacker breaches the server and steals a key part, the key part alone is useless, and it becomes obsolete as soon as the next refresh takes place. This provides a very high level of security and enables enterprise servers to be used with a much lower level of risk. 1.2 Security Levels The Ideem ZSM Cryptographic Module is validated at the FIPS 140-3 section levels shown below. Table 1: Security Levels N/A N/A Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 2. Cryptographic Module Specification 2.1 Description

Ideem Cryptographic Module is able to protect all types of standard cryptographic keys for all purposes, including encryption/decryption, digital signing, and authentication. Ideem’s technology for securing keys secure multiparty computation (MPC) is fully transparent to the calling application.

The Ideem ZSM Cryptographic Module 1.0 is a Software module.

The Ideem ZSM Cryptographic Module has a MultiChipStand embodiment. The module is designed to utilize the following processor algorithm acceleration (PAA) instructions sets for its AES and SHA implementations:

• AES-NI instruction set, when executing on the RHEL 9.2 operational environment
• Neon instruction set, when executing on the iOS 16.5 or Android 13 operational environments. The module was tested and found to be compliant with FIPS 140-3 requirements on the environments listed in section 2.2.4 of this Security Policy.

The module does not have any additional characteristics.

As a software cryptographic module, the module takes on the physical characteristics of the host platform. The physical perimeter of the cryptographic module is defined by each host device on which the module is installed. The cryptographic boundary is the contiguous perimeter that surrounds all memory-mapped functionality provided by the module when loaded and stored in the host platform’s memory. The module is entirely contained within the physical perimeter. The module’s cryptographic boundary consists of all functionalities contained within the module’s compiled source code. The module’s software component comprises 3 shared library files and 3 digest files for testing integrity. All hardware and software components are contained within the host platform’s physical enclosure. Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 The module’s cryptographic boundary consists of all functionalities contained within the module’s compiled source code. On the RedHat and Android operating systems the module is comprised of the following binary files:

• libcrypto.so (cryptographic primitives library file) libsecurikey.so (cryptographic primitives library file) libssl.so (TLS protocol library file) libcrypto.hmac (an HMAC digest file for libcrypto integrity check) libsecurikey.hmac (an HMAC digest file for libsecurikey integrity check) libssl.hmac (an HMAC digest file for libssl integrity check) and on the iOS operating system:
• libcrypto.dylib (cryptographic primitives library file)
• libsecurikey.dylib (cryptographic primitives library file)
• libssl.dylib (TLS protocol library file)
• libcrypto.hmac (an HMAC digest file for libcrypto integrity check)
• libsecurikey.hmac (an HMAC digest file for libsecurikey integrity check)
• libssl.hmac (an HMAC digest file for libssl integrity check) The module is entirely contained within the physical perimeter.

(TOEPP) Figure 1 illustrates a block diagram of a typical GPC and the module’s physical perimeter. Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

Hardware Management February 19, 2025 DVD Network Interface RAM HDD Clock Generator SCSI/SATA Controller LEDs/LCD Serial CPU I/O Hub Audio Cache Power Interface PCI/PCIe Slots USB BIOS PCI/PCIe Slots Graphics Controller External Power Supply KEY: Plaintext Data Encrypted Data Control Input Status Output Physical Perimeter BIOS

• Basic Input/Output System CPU
• Central Processing Unit SATA
• Serial Advanced Technology Attachment SCSI
• Small Computer System Interface PCI
• Peripheral Component Interconnect LED
• Light Emitting Diode PCIe
• PCI express HDD
• Hard Disk Drive DVD
• Digital Video Disc USB
• Universal Serial Bus RAM
• Random Access Memory LCD
• Liquid Crystal Display Figure 1. GPC Block Diagram Figure 2 below shows the logical block diagram of the module executing in memory and its interactions with surrounding software components, as well as the module’s physical perimeter and logical cryptographic boundary. Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

HMAC SHA digests February 19, 2025 MPC Library (AES, ECDSA, and RSA) TLS Library Calling Application Operating System CPU Memory Storage Ports Host Device Figure 2. Module Block Diagram (with Cryptographic Boundaries) 2.2 Tested and Vendor Affirmed Module Version and Identification

This section is only applicable to hardware modules. N/A for this module.

(Executable Code Sets) The table below lists the executable code sets of the module. The module count is 3. Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 1.0 1.0 1.0 Table 2: Tested Module Identification

• Software, Firmware, Hybrid (Executable Code Sets)

This section is only applicable to hybrid modules. N/A for this module.

Hybrid The module was tested and found to be compliant with FIPS 140-3 requirements on the environments listed in the table below. 9.2 9.2 1.0 1.0 1.0 1.0 1.0 1.0 Table 3: Tested Operational Environments - Software, Firmware, Hybrid

Firmware, Hybrid The vendor affirms the module’s continued validation compliance when operating on the platforms listed below. The table below also lists operational environments that support the mixed configuration. Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 Table 4: Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid The mixed configuration operating environments refer to a distributed system where two instances of the cryptographic module are configured to execute the multi-party services in communication with each other, via the calling Application.

1. Each logical component of the Cryptographic Module is installed on a different machine (Figure 3).
2. Each logical component of the Cryptographic Module is installed on a different virtual machine running in a single hypervisor on a single physical machine (Figure 4).
3. Each logical component of the Cryptographic Module is installed on a different Docker container running on a single machine (Figure 5)
4. Each logical component of the Cryptographic Module is part of a different process running on the same machine (Figure 6).
5. All logical components of the Cryptographic Module are part of a single process (Figure 7). Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 Application Application Ideem ZSM Cryptographic Module Client Ideem ZSM Cryptographic ModuleServer Operational Environment Operational Environment General Purpose Hardware General Purpose Hardware Host Device Key: Logical Boundary Physical Boundary Figure 3 - Logical Diagram of the Cryptographic Module Running on Different Machines Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 Application Application Ideem ZSM Cryptographic Module Client Ideem ZSM Cryptographic Module Server VM 1 VM 2 Hypervisor Operational Environment General Purpose Hardware Host Device KEY: Logical Boundary Physical Boundary Figure 4 - Logical Diagram of the Cryptographic Module Running on Different Virtual Machines in the Same Hypervisor Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 Application Application Ideem ZSM Cryptographic Module Client Ideem ZSM Cryptographic Module Server Docker Container 1 Docker Container 2 Operational Environment General Purpose Hardware Host Device KEY: Logical Boundary Physical Boundary Figure 5 - Logical Diagram of the Cryptographic Module Running on Different Docker Containers Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 Application Application Ideem ZSM Cryptographic Module Client Ideem ZSM Cryptographic Module Server Process 1 Process 2 Operational Environment General Purpose Hardware Host Device KEY: Logical Boundary Physical Boundary Figure 6 - Logical Diagram of the Cryptographic Module Running on Different Processes Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 Application Application Ideem ZSM Cryptographic Module Client Ideem ZSM Cryptographic Module Server Single Process Operational Environment General Purpose Hardware Host Device KEY: Logical Boundary Physical Boundary Figure 7 - Logical Diagram of the Cryptographic Module Running on a Single Process Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 The cryptographic module maintains validation compliance when operating on any general-purpose computer (GPC) provided that the GPC for the software module uses any single-user operating system/mode specified on the validation certificate, or another compatible single-user operating system. The module also maintains compliance when operating in a virtual environment provided by any of the following supported hypervisors:

• VMware ESXi 6 and above 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 not listed on the validation certificate. 2.3 Excluded Components The module does not exclude any components from the requirements. 2.4 Modes of Operation

By design, the module only supports operation in the Approved mode. 2.5 Table 5: Modes List and Description Algorithms

The module employs cryptographic algorithm implementations from the following sources:

• Ideem ZSM Multi-party Cryptographic Library (Cert. A5055) Ideem ZSM Single-party Cryptographic Library (Cert. A5056) The module implements the Approved algorithms listed below. Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 Table 6: Approved Algorithms

The vendor affirms the following cryptographic security methods: Table 7: Vendor-Affirmed Algorithms ©2024 Ideem, Inc.

The module does not offer any non-Approved algorithms allowed in the Approved mode of operation. N/A for this module.

The module does not offer any non-Approved algorithms allowed in the Approved mode of operation with no security claimed. N/A for this module.

The module does not offer non-Approved algorithms not allowed in the Approved mode of operation. N/A for this module. 2.6 Security Function Implementations The table below lists the security function implementations for this module. Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 8.2.1 Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 Table 8: Security Function Implementations 2.7 Algorithm Specific Information The information below provides algorithm information of references to specifications.

• AES GCM IV: As per I.G. C.H Key/IV Pair Uniqueness Requirements from SP 800-38D, AES GCM IV implements scenario 1.
• AES GCM encryption is used in the context of the TLS protocol versions 1.2. To meet the AES GCM (key/IV) pair uniqueness requirements from NIST SP 800-38D, the module complies with FIPS 140-3 IG C.H as follows:
• For TLS v1.2, the module supports acceptable AES GCM cipher suites from section 3.3.1 of NIST SP 800-52rev2. Per scenario 1 in FIPS 140-3 IG C.H, the mechanism for IV generation is compliant with RFC 5288. The counter portion of the IV is strictly increasing. When the IV exhausts the maximum number of possible values for a given session key, a failure in encryption will occur and a handshake to establish a new encryption key will be required. It is the responsibility of the module operator (i.e., the first party, client, or server) to trigger this handshake in accordance with RFC 5246 when this condition is encountered. In the event that power to the module is lost and subsequently restored, the calling application must ensure that any AES GCM keys used for encryption or decryption are re-distributed.
• RSA: As per FIPS 186-5 Appendix A.1, RSA KeyGen implements the method discussed in A.1.3 Generation of Random Primes that are Probably Prime.
• ECDSA: As per FIPS 186-5 Appendix A.2, ECDSA KeyGen implements the method discussed in A.2.2 ECDSA Key Pair Generation by Rejection Sampling. As per section C.K of the Implementation Guidance, Ideem ZSM Multi-party Cryptographic Library is complaint with FIPS 186-5, as the FIPS 186-4 CAVP tests for ECDSA KeyGen, KeyVer, SigGen, and SigVer are mathematically identical to the FIPS 186-5 CAVP tests.
• PBKDF2: As per SP 800-132 section 5.4, PBKDF2 implements option 1a from section 5.4 of NIST SP 800132. The iteration count shall be selected as large as possible, as long as the time required to generate the resultant key is acceptable for module operators. The minimum iteration count shall be 1000. The length of the password/passphrase used in the PBKDF shall be of at least 20 characters, and shall consist of lower-case, upper-case, and numeric characters. The upper bound for the probability of guessing the value is estimated to be 1/6220 = 7.044-35, which is less than 2-112. Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 As specified in NIST SP 800-132, keys derived from passwords/passphrases may only be used in storage applications. 2.8 RBG and Entropy The module does not have any entropy certificates. N/A for this module. The calling application provides a minimum number of 256 bits of entropy. The calling application and its entropy source are outside the module cryptographic boundary. The calling application shall use entropy sources that meet the security strength required for the Counter DRBG as shown in Table 3 of SP 800-90A Rev. 1. This entropy shall be supplied by means of a callback function. The callback function must return an error if the minimum entropy strength cannot be met. N/A for this module. 2.9 Key Generation Please refer to Table 8: Security Function Implementations for specification of the module’s key generation methods. 2.10 Key Establishment

Please refer to Table 8: Security Function Implementations for specification of the module’s key agreement methods.

Please refer to Table 8: Security Function Implementations for specification of the module’s transport methods. 2.11 Industry Protocols The module implements the following industry protocol:

• TLS v1.2 1

1 No parts of the TLS protocol, other than the KDF, have been tested by the CAVP or CMVP.

Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 3. 3.1 Ports and Interfaces The module supports the following logical interfaces:

• As a software library, the cryptographic module has no direct access to any of the host platform’s physical ports; it communicates only to the calling application via its well-defined API. The table below contains a mapping of Table 9: Ports and Interfaces Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 4. Roles, Services, and Authentication 4.1 The module does not support authentication mechanisms; operators implicitly assume an authorized role (or set of roles) based on the service selected. N/A for this module. 4.2 Roles The module supports a Crypto Officer (CO) that authorized operators can assume. The CO role performs cryptographic initialization or management functions and general security services. The module also supports the following role:

• User
• The User role performs general security services, including cryptographic operations and other approved security functions. The module does not support multiple concurrent operators. The calling application that loaded the module is its only operator. The table below lists the supported roles. 4.3 Table 10: Roles Approved Services Descriptions of the services available are provided in the tables in this section. This module is a software library that provides cryptographic functionality to calling applications. As such, the security functions provided by the module are considered the module’s security services. Indicators for Approved services (in the case of this module, those security functions with algorithm validation certificates and all required self-tests) are provided via API return value. When invoking a security function, the calling application provides inputs via an internal structure, or “context”. Upon each service invocation, the module will determine if the invoked security function is an Approved service. To access the resulting value, the calling application must pass the finalized context to the indicator API associated with that security function (note the indicator check must be performed prior to any context cleanup is performed). The indicator API will return “1” to indicate the usage of an Approved service. Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 The keys and Sensitive Security Parameters (SSPs) listed in the table indicate the type of access required using the following notation:

• 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 = Zeroize: The module zeroizes the SSP. N/A Perform preoperational Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

N/A February 19, 2025 Z Z Z Z Z Z Z Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 N/A W,E W,E W,E W,E W,E W,E W,E W,E W,E W,E G,R,E Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 W,E W,E W,E G,E G,R G,R W,E W,E Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 W,E W,E W,E W,E G,R,E W,E W,E W,E W,E W,E W,E W,E G,E Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 Table 11: Approved Services W,E R,W,E R,W,E G,R G,R * Per FIPS 140-3 Implementation Guidance 2.4.C, the Show Status and Show Versioning Information services do not require a service indicator. 4.4 Non-Approved Services The module does not offer any non-Approved services. N/A for this module. Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

5. Software/Firmware Security 5.1 Integrity Techniques February 19, 2025 All software components within the cryptographic boundary are verified using an approved integrity technique implemented within the cryptographic module itself. The module implements independent HMAC SHA2-256 checks for the integrity test of each library file; failure of the integrity test for any file will cause the module to enter a critical error state. The calling application is responsible for the initialization process and loading of the library. The module is designed with a default entry point (DEP) that ensures that the pre-operational self-tests are initiated automatically when the module is loaded without action from the module operator. 5.2 Initiate on Demand The CO can initiate the pre-operational tests on demand by issuing the securikey_fips_self_test() call. Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

6. Operational Environment 6.1 Operational Environment Type and Requirements February 19, 2025 The Ideem ZSM Cryptographic Module comprises a software cryptographic library that executes in a Modifiable operational environment. The cryptographic module has control over its own SSPs. The process and memory management functionality of the host platform’s OS prevents unauthorized access to plaintext private and secret keys, intermediate key generation values and other SSPs by external processes during module execution. The module only allows access to SSPs through its well-defined API. The operational environments provide the capability to separate individual application processes from each other by preventing uncontrolled access to CSPs and uncontrolled modifications of SSPs regardless of whether this data is in the process memory or stored on persistent storage within the operational environments. Processes that are spawned by the module are owned by the module and are not owned by external processes/operators. Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

7. February 19, 2025 Physical Security The cryptographic module is a multi-chip standalone software module and does not include physical security mechanisms. Therefore, per section 7.5 of the FIPS PUB 140-3 Management Manual this section is not applicable. Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

8. February 19, 2025 Non-Invasive Security This section is not applicable. There are currently no approved non-invasive mitigation techniques references in Annex F of ISO/IEC 19790. Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 9. Sensitive Security Parameters Management 9.1 Storage Areas The table below lists sensitive security parameters (SSPs) storage areas for this module. 9.2 Table 12: Storage Areas SSP Input-Output Methods The table below lists SSP input and output methods for this module. Table 13: SSP Input-Output Methods 9.3 SSP Zeroization Methods The table below lists SSP zeroization methods for this module. Table 14: SSP Zeroization Methods 9.4 The module supports the keys and other SSPs listed in the table below. Note that all SSP imports and exports are electronic and performed withing the Tested OE’s Physical Parameter (TOEPP). Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 a peer-topeer Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 n/a - n/a Table 15: SSP Table 1 Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 Table 16: SSP Table 2 Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 10. Self-Tests The module performs pre-operational self-tests and conditional self-tests. Pre-operational tests are performed between the time the cryptographic module is instantiated and before the module transitions to the operational state. Conditional self-tests are performed by the module during module operation when certain conditions exist. The following sections list the self-tests performed by the module, their expected error status, and the error resolutions. In normal operation, the module uses MPC techniques to spread the load of cryptographic operation between several nodes. However, for self-testing, the module is able to perform all of the steps of each algorithm within the boundary of the module. 10.1 Pre-Operational Self-Tests The module performs the following pre-operational self-test(s): Table 17: Pre-Operational Self-Tests 10.2 Conditional Self-Tests The module performs the following conditional self-tests: P-256; SHA2256 Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

P-224; SHA2256 P-224; SHA2256 February 19, 2025 Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 10.3 Table 18: Conditional Self-Tests The module does not implement automatic periodic self-tests, however the operator can perform all module selftests on demand by issuing the securikey_fips_self_test() call. Table 19: Pre-Operational Periodic Information Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a Table 20: Conditional Periodic Information Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

10.4 February 19, 2025 Error States The tables below describe the error states the status indicators of the module. Table 21: Error States

February 19, 2025 11. Life-Cycle Assurance The sections below describe how to ensure the module is operating in its validated configuration, including the following:

• Procedures for secure installation, initialization, startup, and operation of the module Maintenance requirements Administrator and non-Administrator guidance Operating the module without following the guidance herein (including the use of undocumented services) will result in non-compliant behavior and is outside the scope of this Security Policy. 11.1 Installation, Initialization, and Startup Procedures

As the module is an integrated component of Ideem’s product application software, module operators have no ability to independently load the module onto the target platform. The module is distributed to the end operator as part of an SDK 2 developed by Ideem. The module is distributed as a package containing the pre-compiled binaries and HMAC digest files. The module and its calling application are to be installed on a platform specified in section 2.2 or one where portability is maintained. For correct operation the module must be installed on both a server RHEL environment) and client (iOS or Android) side. Ideem does not provide any mechanisms to directly access the module, its source code, its APIs, or any information sent between it and other Ideem applications.

This module is designed to support the Ideem application solely, and this application are the sole consumers of the cryptographic services provided by the module. No end-user action is required to initialize the module for operation; the calling application performs any actions required to initialize the module. The pre-operational integrity test and conditional CASTs are performed automatically via a default entry point (DEP) when the module is loaded for execution, without any specific action from the calling application or the end-user. End-users have no means to short-circuit or bypass these actions. Failure of any of the initialization actions will result in a failure of the module to load for execution.

No startup steps are required to be performed by end-users.

Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

11.2 February 19, 2025 Administrator Guidance There are no specific management activities required of the CO role to ensure that the module runs securely. If any irregular activity is observed, or if the module is consistently reporting errors, then Ideem Customer Support should be contacted. The following list provides additional guidance for the CO:

• The CO can initiate the pre-operational self-tests and conditional CASTs on demand for periodic testing of the module by re-instantiating the module.
• The CO may call the securikey_fips_self_test() API command to initiate the pre-operational self-tests and conditional CASTs on demand for MPC algorithms.
• The fips_post_status() API command returns TRUE(1) if the module’s self-tests have passed but returns FALSE(0) otherwise.
• The securikey_fips_get_module_information() API command returns the module’s versioning information as a string. 11.3 Non-Administrator Guidance The following list provides additional policies for the User role:
• The cryptographic module’s services are designed to be provided to a calling application. Excluding the use of the NIST-defined elliptic curves as trusted third-party domain parameters, all other assurances from FIPS PUB 186-4 (including those required of the intended signatory and the signature verifier) are outside the scope of the module and are the responsibility of the calling application.
• The module performs assurances for its key agreement schemes as specified in the following sections of NIST SP 800-56Arev3: o
• Section 5.5.2 (for assurances of domain parameter validity) Section 5.6.2.1 (for assurances required by the key pair owner) The module includes the capability to provide the required recipient assurance of ephemeral public key validity specified in section 5.6.2.2.2 of NIST SP 800-56Arev3. However, since public keys from other modules are not received directly by this module (those keys are received by the calling application), the module has no knowledge of when a public key is received. Invocation of the proper module services to validate another module’s public key is the responsibility of the calling application.
• The length of a single data unit encrypted or decrypted with the AES-XTS shall not exceed 2²⁰ AES blocks; that is, 16 MB of data per AES-XTS instance. An XTS instance is defined in section 4 of NIST SP 800-38E. The AES-XTS mode shall only be used for the cryptographic protection of data on storage devices. The AES-XTS shall not be used for other purposes, such as the encryption of data in transit. The module implements the check to ensure that the two AES keys used in the XTS-AES algorithm are not identical. Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

• February 19, 2025 The module supports importing GCM IVs generated externally for decryption purposes. The operator shall not perform AES GCM encryption when the IV is provided from outside the cryptographic boundary of the module. Importing an external AES GCM IV will result in a non-conformance. Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 12. Mitigation of Other Attacks 12.1 Attack List Key Leakage: The use of MPC techniques within the module ensures that knowledge of a key share provides no information about the logical key that it is a part of and that compromising a single module gives an attacker no knowledge about the secret and private keys used by that module. 12.2 Mitigation Effectiveness Secure multi-party computation is used to generate and split a cryptographic key into two or more key shares, such that knowledge of a key share provides no information about the logical key. The original key is never stored nor recomputed, so leakage of the key share from a single module gives an attacker no knowledge about the private keying material used by that module. 12.3 Guidance and Constraints There is no further guidance or constraints. 12.4 Additional Information There is no additional information. Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 Appendix A. Acronyms and Abbreviations Table 22 provides definitions for the acronyms and abbreviations used in this document. Table 22. Acronyms and Abbreviations Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

February 19, 2025 Ideem ZSM Cryptographic Module 1.0 ©2024 Ideem, Inc.

Prepared by: Corsec Security, Inc.

Fairfax, VA 22033 United States of America Phone: +1 703 267 6050 Email: info@corsec.com http://www.corsec.com

Referenced URLs

• www.useideem.com
• www.corsec.com
• http://csrc.nist.gov/groups/STM/cmvp
• https://csrc.nist.gov/Projects/cryptographic-module-validation-