Eclypses Cryptographic Library

Certificate

Approved Algorithms (22)

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

flowchart LR
  %% Deterministic review-risk graph for Eclypses Cryptographic Library
  %% 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</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>application</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."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
    R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
    R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E2["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["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"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C6 --> I6 --> R6 --> E6
  classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
  classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
  classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
  class C2,C3,C6 clue;
  class I2,I3,I6 infer;
  class R2,R3,R6 risk;
  class E2,E3,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Eclypses Cryptographic Library
  %% 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</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<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,C3,C6 clueLow;

Security Policy, page by page

Eclypses, Inc. Eclypses Cryptographic Library Library Version 1.0.0 FIPS 140-3 Security Policy Document Version 1.0

This document may be freely reproduced and distributed, but only in its entirety and without modification. iii

The module meets the overall requirements of FIPS 140-3 Level 1. Table 1: Module Security Levels This document may be freely reproduced and distributed, but only in its entirety and without modification.

The cryptographic boundary is defined as the ‘Eclypses Cryptographic Library’. The ‘Eclypses Cryptographic Library’ (hereafter referred to as the "Module") version 1.0.0 is a software library supporting FIPS 140-3 approved cryptographic algorithms. The Module is a Software Module with the ability to use PAA when present. The Module is a proprietary implementation, general- purpose cryptographic library with an API targeted toward high performance and minimal footprint. It was designed to have no dependencies or interactions with the operating system or any other libraries; the only interactions are to perform cryptographic algorithms when requested by application code. It was designed to support a wide range of operating environments with as much common code as possible. For this reason, the Software Module designation was chosen. Figure 1: Cryptographic Boundary and Physical Perimeter The Eclypses Cryptographic Library Module consists of the following files, depending on operational environment (refer to Table 2 for OE numbers in brackets):

• libecl.so, libecl.so.sha256
• Google Android 9 (32-bit) [7]
• Google Android 9 (64-bit) [8, 9]
• OpenWRT Linux 19.07 (32-bit) [12]
• Raspbian Linux 5.10 (32-bit) [13]
• Ubuntu Linux 20.04 (64-bit) [14, 15] This document may be freely reproduced and distributed, but only in its entirety and without modification.

• libecl.dylib, libecl.dylib.sha256
• ecl.dll, ecl.dll.sha256 Table 2: Tested Operational Environments (OE) This document may be freely reproduced and distributed, but only in its entirety and without modification.

B Refer to Table 1: Module Security Levels for the security rating of the Module and security levels of individual areas. The cryptographic boundary is defined by the library and API. All implementation is inside the boundary. The library contains only cryptographic functions, and the library performs all cryptographic functions itself without dependency on any other library, application, or operating system functionality.

There is only one mode of operation: Normal Approved Mode. The software development kit (SDK) package clearly indicates the compliance mode by including "FIPS" in the package name to indicate the compliance. There is a service (Show Status) the library user can call to verify that Normal Approved Mode is enabled. The Module name may be validated by using the Show Module Name / Identifier service. An exact match to the below listed Module name validates the correctness. The approved Module name is: Eclypses Cryptographic Library The Module version may be validated by using the Versioning Information service. An exact match to the below listed Module version validates the correctness. The approved Module version is: 1.0.0 This document may be freely reproduced and distributed, but only in its entirety and without modification.

The module supports the Approved algorithms listed in Table 3. Table 3: Approved Algorithms

1 SHA-1 Large Data Test (LDT) only applicable to OE #3, 5, 10, and 14 (w/ PAA enabled) from Table 2.

3 SHA-1 shall only be used for non-digital signature applications (ref: NIST SP 800-131r2, Section 9).

4 SHA-256 LDT only applicable to OE #3, 4, 6, 10, 11, 14, and 15 from Table 2.

6 SHA-512 LDT only applicable to OE #3, 4, 6, 10, 11, 14, and 15 from Table 2.

This document may be freely reproduced and distributed, but only in its entirety and without modification.

This section documents the security rules enforced by the cryptographic module to implement the security requirements of a FIPS 140-3 Level 1 Module.

For AES, the CSP (key) is used by the Symmetric Encryption / Decryption service. The library user shall protect or zeroise their copy of the key after keying. The Zeroisation service is provided to zeroise the library's key, and the library user shall use this service when the AES module is no longer needed for encryption or decryption. For DRBGs, the CSP (entropy) is used by the Random Number Generation service. As soon as the entropy has been consumed as part of the Random Number Generation service, it is zeroised. The library user shall zeroise any additional copies of the entropy they may have. The Zeroisation service is provided to zeroise the library's CSP (the current state of the DRBG, including V, C, and/or Key, depending on the DRBG), and the library user shall use this service when the DRBG module is no longer needed to generate random bits.

There is no assurance of minimum strength of generated random strings or SSPs. As such, the Module cannot create keys and can only import keys. There is also no assurance of minimum security of SSPs that are externally loaded (or of SSPs established with externally loaded SSPs). The DRBGs produce random strings, but the library cannot use them as keys. The library user may use the random strings as they choose. The AES services use keys provided by the library user. The library user shall protect the user provided cryptographic keys.

All services return a status code to indicate to the library user the success or failure of the operation. The only exceptions to this rule are the Control PAA service and Show Module Name/Identifier and Versioning Information service, which indicate success by their completion. The library user shall check every status code and take appropriate action based on the result. This document may be freely reproduced and distributed, but only in its entirety and without modification.

When utilizing the Message Digest service, the output for SHA-1 shall only be used for nondigital signature applications (ref: NIST SP 800-131r2, Section 9).

When the consuming application starts, the Module automatically commands the Perform Pre- Operational Self-Tests service, which includes the Perform Conditional Self-Tests service in addition to the library integrity test. The Perform Pre-Operational Self-Tests service will set the error state if the library integrity check or the Conditional Self-Tests fail. All output is inhibited while in an error state; therefore, all output is inhibited until the library integrity check and Conditional Self-Tests pass. For AES, if the Module is in an error state, encryption and decryption each return an error status. No encryption or decryption is performed while in the error state. For DRBGs, if the Module or instance is in an error state, instantiation and generation each return an error status. No random bits are created while in the error state. For SHA, if the Module is in an error state, feeding data to be digested returns an error status. No message digest update is performed while in the error state.

The Module has a self-test flag to indicate when self-tests are running. While this flag is set, all output is inhibited. All self-test results are zeroised and are not output.

The Module is in an error state during zeroisation. Since output is inhibited while in an error state, output is inhibited during zeroisation.

To use PAA on ARM64 platforms, the PAA availability must be known or probed by the library user in some way, and then communicated to the library using the Control PAA service. The Perform Conditional Self-Tests service must then be commanded for the PAA option to take effect (the PAA and non-PAA were self-tested during the Pre-Operational Self-Tests, which includes the Conditional Self-Tests in addition to the library integrity test; the self-test This document may be freely reproduced and distributed, but only in its entirety and without modification.

requirement here is just part of the PAA enable/disable procedure). This applies to the following operational environments (refer to Table 2 for OE numbers in brackets):

• [1] Apple iOS 13.5 (64-bit) Apple A9 (APL1022) with Cryptography Extensions (ARM v8)
• [5] Apple macOS Big Sur 11.3 (64-bit) Apple M1 (APL1102) with Cryptography Extensions (ARM v8)
• [8] Google Android 9 (64-bit) Qualcomm Snapdragon 835 with Cryptography Extensions (ARM v8) To use PAA on x86_64 platforms, the choice must be communicated to the library using the Control PAA service. If the user chooses to allow PAA, the library probes to determine if PAA is available and uses it if so. The Perform Conditional Self-Tests service must then be commanded for the PAA option to take effect (the PAA and non-PAA were self-tested during the Pre-Operational Self-Tests, which includes the Conditional Self-Tests in addition to the library integrity test; the self-test requirement here is just part of the PAA enable/disable procedure). This applies to the following operational environments (refer to Table 2 for OE numbers in brackets):
• [3] Apple macOS Big Sur 11.3 (64-bit) Intel Core i9 (I9-9880H) with AES-NI, AVX, SSE2, and SSSE3
• [10] Microsoft Windows 10 Pro 20H2 (64-bit) Intel Core i7 (i7-7500U) with AES-NI, AVX, SSE2, and SSSE3
• [14] Ubuntu Linux 20.04 (64-bit) Intel Core i7 (i7-7500U) with AES-NI, AVX, SSE2, and SSSE3 This document may be freely reproduced and distributed, but only in its entirety and without modification.

This document may be freely reproduced and distributed, but only in its entirety and without modification.

N/A

Data Input

Upon module initialization the module queries the CPU to determine if PAA is available. If PAA is available both non-PAA and PAA cryptographic algorithms are self-tested (refer to Section 10).

This document may be freely reproduced and distributed, but only in its entirety and without modification.

There is one role for this Module: Cryptographic Officer (aka. Crypto Officer or CO).

The Crypto Officer role is supported for installation of the dynamic library. The Crypto Officer controls access to the dynamic library to ensure it is not tampered with before and after installation. The Crypto Officer can use all the cryptographic services of the Module.

The role names are abbreviated as: CO = Crypto Officer This document may be freely reproduced and distributed, but only in its entirety and without modification.

The module does not support authentication; all services are assigned to the CO role. There is only one role (CO), which does not require authentication to assume. The module is a level 1 software module that does not support authentication mechanisms.

The module supports the following Approved Services described in Table 6. Table 6: Approved Services This document may be freely reproduced and distributed, but only in its entirety and without modification.

CO

Zeroisation

Zeroise SSP

AES CBC & AES CTR & AES ECB & CTR_DRBG & Hash_DRBG

AES Key: Z DRBG Entropy: Z CTR_DRBG V: Z CTR_DRBG Key: Z Hash_DRBG V, C: Z

Status indicating success or failure for DRBGs; service completion for ciphers

SSP access rights are defined as follows: G = Generate: The module generates or derives the SSP. R = Read: The SSP is read from the module (e.g., the SSP is output). Read access is N/A for the Module. 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. This document may be freely reproduced and distributed, but only in its entirety and without modification.

The executable code is provided as a dynamic library (ecl) along with an associated set of C header files used by consuming applications to interface to the library. The Eclypses Cryptographic Library Module consists of the following files, depending on operational environment (refer to Table 2 for OE numbers in brackets):

• libecl.so, libecl.so.sha256
• Google Android 9 (32-bit) [7]
• Google Android 9 (64-bit) [8, 9]
• OpenWRT Linux 19.07 (32-bit) [12]
• Raspbian Linux 5.10 (32-bit) [13]
• Ubuntu Linux 20.04 (64-bit) [14, 15]
• libecl.dylib, libecl.dylib.sha256
• Apple iOS 13.5 (64-bit) [1, 2]
• Apple macOS Big Sur 11.3 (64-bit) [3, 4, 5, 6]
• ecl.dll, ecl.dll.sha256
• Microsoft Windows 10 Pro 20H2 (64-bit) [10, 11] The Perform Pre-Operational Self-Test service runs a self-test on the SHA-256 algorithm to verify it is operating correctly. It then performs a SHA-256 hash calculation on the copy of the dynamic library (ecl) currently being executed (found via dynamic linker functions on most OEs; found in the APK on Android). This hash digest is compared against the hash digest stored in the hash file, which was calculated when the dynamic library (ecl) was built. Finally, the Perform Conditional Self-Tests service is performed. The Pre-Operational Self-Test, which includes the Conditional Self-Tests in addition to the library integrity test, succeeds only if the calculated hash digest of the library in use matches the stored hash from when the library was built and the Conditional Self-Tests succeed. Pre-Operational Self-Test, which includes the Conditional Self-Tests in addition to the library integrity test, runs automatically when the consuming application starts (when the library is loaded on Android) due to the use of default entry points. The Pre-Operational Self-Test checks the dynamic library to ensure integrity. If the Pre-Operational Self-Test fails for any reason, a message is printed to standard error (the assert logcat on Android) and the C abort() function is called to force termination of the application. If the abort() is ignored (on systems that can ignore it), there is still a flag set which prevents any of the algorithms from passing This document may be freely reproduced and distributed, but only in its entirety and without modification.

their Conditional Self-Tests, and since those cannot pass, all algorithms inhibit output. The consuming application user can initiate the Pre-Operational Self-Test, which includes the Conditional Self-Tests in addition to the library integrity test, at any time using the Perform Pre- Operational Self-Tests service. This document may be freely reproduced and distributed, but only in its entirety and without modification.

The module is a software library and the physical embodiment is provided by the multiplechip standalone general purpose computing platform on which it is installed. All operational environments for the module are classified as modifiable. The tested operating systems and tested platforms are detailed in Table 2. All operational environments the Module is certified for support default entry points, which are required for the Pre-Operational Self-Test. Modifying the operational environment to disable the default entry point renders the Module in an error state so it cannot be used. The Module has no other interaction with the operational environment, so all requirements for Level 1 are satisfied by all operational environments the Module is certified for. There are no security rules, settings, or restrictions on the configuration of the operational environment imposed by the Module. The Module has no interaction with the operational environment beyond probing the hardware for PAA in certain cases and reading the library integrity hash file. Consuming applications may define security rules, settings, or restrictions on the configuration of the operational environment. All operational environments the Module is certified for segregate processes. Each process is logically separated from all other processes by the operating system and hardware. The Module functions entirely within a single process. The operational environment enforces process separation by the use of virtual memory. The virtual memory system uses the memory management unit (MMU) hardware to prevent processes from accessing the memory image of another process.

Not applicable because the Module is purely software.

The Module does not implement non-invasive mitigation techniques. This document may be freely reproduced and distributed, but only in its entirety and without modification.

The Module does not permanently store SSPs. The only SSPs are the current state of any instance of any parts of the Module. The SSPs the Module creates are only kept in memory state structures. The Module provides zeroisation services to ensure all SSPs are zeroised when no longer needed. The SSPs created by the Module are for Module use only to perform cryptographic services.

Table 7: SSPs V V, C RBG state information and intermediate generated values are CSPs. As noted in the table above, any entropy input is defined as a CSP. It is zeroised immediately after use. CSPs may be provided in plaintext form because they will be maintained within the This document may be freely reproduced and distributed, but only in its entirety and without modification.

operational environment. The Module does not store or transmit any CSP entered. The DRBG entropy is loaded when needed during instantiation. The minimum number of bits of entropy required and the minimum/maximum entropy bitstring length are specified in the load request and the minimum number of bits of entropy is believed to have been provided if the load returns a successful status (refer to Table 4 for additional detail). Additionally, if the length of the bitstring loaded is less than the minimum bits of entropy required or the status is not success, the instantiation fails under the assumption that insufficient entropy was available; otherwise, the number of bits loaded is believed to contain the minimum required bits of entropy for the security strength desired. The minimum number of bits of entropy provided is equal to the security strength for each Hash DRBG and each CTR_DRBG with derivation function (i.e., 128, 192, or 256 bits), and equal to the sum of the block size and key length for each CTR_DRBG without derivation function (i.e., 256, 320, or 384 bits). FIPS caveat: no assurance of minimum strength of generated random strings. The DRBG SSPs (V, C, Key) are derived from SSPs entered into the module in an approved manner defined in the DRBG algorithm.

The Module does not have any PSPs.

The Module does not incorporate any non-deterministic random number generators. Entropy provided to the (NIST SP 800-90A) DRBGs must be provided by an approved random source (NIST SP 800-90B).

The Module provides zeroisation services that will zeroise all SSPs on demand. The zeroisation is optimized to run in the least number of processor instructions to complete as quickly as possible. The zeroisation is initiated by the library user and the indication of completion is the function call returning. This document may be freely reproduced and distributed, but only in its entirety and without modification.

All cryptographic operations are inhibited during error states and while self-tests are being performed. Any attempted cryptographic operation during an error state or while self-tests are being performed will result in an error status (i.e., ecl_status_output_inhibited) and/or zeroised output.

All Pre-Operational Self-Tests test the non-PAA implementation. If PAA is available, the PAA implementation is also tested. Table 8: Pre-Operational Self-Tests

All Conditional Self-Tests test the non-PAA implementation. If PAA is available, the PAA implementation is also tested. Table 9: Conditional Self-Tests This document may be freely reproduced and distributed, but only in its entirety and without modification.

This document may be freely reproduced and distributed, but only in its entirety and without modification.

To resolve errors, restart the consuming application or command the Perform Pre-Operational Self- Tests service. The Module can be used if the Perform Pre-Operational Self-Tests service returns success.

The Module's consuming application can use any of the Perform Pre-Operational Self-Tests or Perform Conditional Self-Test services at any time to perform a periodic self-test. If the on demand self-tests fail, the module will return ECL_FALSE. This document may be freely reproduced and distributed, but only in its entirety and without modification.

Module code is stored and managed within private and secure configuration management systems, GIT and Azure DevOps. The Module documentation is stored in the same repository to maintain the history synchronized with the source code. Module code utilizes versioning along with release notes providing guidance in the use of each iteration of Module’s code. The Module has a semantic version number. The Git configuration management system assigned a message digest to each commit which uniquely identifies the version. Configuration management systems retaining Module code are periodically backed up using a solution that allows both full and incremental restoration. A comprehensive developer guide documenting the entire API is provided. The developer guide provides all Administrator guidance. The developer guide is versioned and managed within the same secure configuration management systems. The configuration management system is protected with user authentication measures to prevent unauthorized access. All changes can be made only by authorized individuals. An automated system is in place to notify other users when any change has been made to prevent unknown changes from being made. All changes are made on development branches in Git and are reviewed by separate people before releasing to production. The only maintenance required is to install new versions of the Module when they are made available to fix discrepancies or add features. The update procedure is the same as the installation procedure, with the new Module file(s) replacing the existing ones. Any new version of the Module is outside the scope of this validation and requires a separate FIPS 140-3 validation.

The Crypto Officer shall install the dynamic library and library integrity hash file in a standard location that is protected from modification by Users. The dynamic library path shall be restricted to protected paths to avoid library interposition. The library install location must be in a path that is MAX_PATH or PATH_MAX (depending on operating system) characters or less. The dynamic library and library integrity hash file must be collocated and shall be protected This document may be freely reproduced and distributed, but only in its entirety and without modification.

against modification by Users.

The Crypto Officer shall configure their iOS app project according to instructions detailed in the SDK. This will ensure the proper embedded locations of the library and integrity hash file in the IPA.

The Crypto Officer shall configure their Android app project according to instructions detailed in the SDK. This will ensure the proper embedded locations of the library and integrity hash file in the APK.

There is no authentication component to the Module, so no further setup is required. No zeroisation is required during installation.

All Pre-Operational Self-Tests and Conditional Self-Tests are performed at power-on. Where PAA is available, the PAA and non-PAA versions are tested as part of the Perform PreOperational Self-Tests service, which includes the Perform Conditional Self-Tests service in addition to the library integrity test. To set the PAA option for use after the Pre-Operational Self-Tests, the Module requires the conditional self-test services to be commanded again after setting the desired PAA options. All algorithms have self-tests to verify the algorithm is working correctly. The Perform PreOperational Self-Test service commands all algorithm self-tests after first verifying library integrity. A library user can command the Perform Conditional Self-Test service to run at any time. A library user can command the Perform Pre-Operational Self-Test service, which includes the Perform Conditional Self-Tests service in addition to the library integrity check, to run again at any time. This document may be freely reproduced and distributed, but only in its entirety and without modification.

This module is not designed to mitigate other attacks beyond the scope of FIPS 140-3 requirements. This document may be freely reproduced and distributed, but only in its entirety and without modification.

Table 10: References This document may be freely reproduced and distributed, but only in its entirety and without modification.

Table 11: Abbreviations and Definitions This document may be freely reproduced and distributed, but only in its entirety and without modification.