| Standard | FIPS 140-3 |
|---|---|
| Overall level | 1 |
| Module type | Software |
| Embodiment | Multi-Chip Stand Alone |
| Status | Active |
| Sunset date | 4/4/2029 |
| Caveat | No assurance of the minimum strength of generated SSPs (e.g., keys); No assurance of minimum security of SSPs (e.g., keys, bit strings) that are externally loaded, or of SSPs established with externally loaded SSPs |
| Vendor | Eclypses, Inc. |
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;Eclypses, Inc. Eclypses Cryptographic Library Library Version 1.0.0 FIPS 140-3 Security Policy Document Version 1.0
| # | Section | Page |
|---|
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 ISO/IEC 24759 FIPS 140-3 Section Title Security Section 6 Subsection Level
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
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):
1 Apple iOS 13.5 iPhone SE Apple A9 (APL1022) with Cryptography Yes
(64-bit) Extensions (ARM v8) Apple iOS 13.5 iPhone SE Apple A9 (APL1022) (ARM v8) No (64-bit)
3 Apple macOS Big MacBook Intel Core i9 (I9-9880H) with AES-NI, AVX, Yes
Sur 11.3 (64-bit) Pro SSE2, and SSSE3 Apple macOS Big MacBook Intel Core i9 (I9-9880H) No Sur 11.3 (64-bit) Pro
5 Apple macOS Big Mac mini Apple M1 (APL1102) with Cryptography Yes
Sur 11.3 (64-bit) Extensions (ARM v8) Apple macOS Big Mac mini Apple M1 (APL1102) (ARM v8) No Sur 11.3 (64-bit) Google Android 9 Oukitel C16 MediaTek MT6580P (ARM v7) No (32-bit)
8 Google Android 9 Samsung Qualcomm Snapdragon 835 with Yes
(64-bit) Galaxy S8 Cryptography Extensions (ARM v8) Google Android 9 Samsung Qualcomm Snapdragon 835 (ARM v8) No (64-bit) Galaxy S8
10 Microsoft Windows HP ZBook Intel Core i7 (i7-7500U) with AES-NI, AVX, Yes
11 Microsoft Windows HP ZBook Intel Core i7 (i7-7500U) No
12 OpenWRT Linux 19.07 GL.iNet GL- Qualcomm QCA9563 (MIPS 74Kc) No
(32-bit) AR750S This document may be freely reproduced and distributed, but only in its entirety and without modification.
13 Raspbian Linux 5.10 Raspberry Broadcom BCM2711 (ARM v8) No
(32-bit) Pi 4 Model B Rev 1.1
14 Ubuntu Linux HP ZBook Intel Core i7 (i7-7500U) with AES-NI, AVX, Yes
15 Ubuntu Linux HP ZBook Intel Core i7 (i7-7500U) No
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 CAVP Algorithm Standards Modes / Description / Key Sizes Use / Function Cert(s) Methods A1406, AES FIPS 197 [2], CBC 128, 192, and 256 bits Data Encryption / A1422 Decryption NIST SP 800-38A [3] A1407, AES FIPS 197 [2], CTR 128, 192, and 256 bits Data Encryption / A1423 Decryption NIST SP 800-38A [3] A1408, AES FIPS 197 [2], ECB 128, 192, and 256 bits Data Encryption / A1424 Decryption NIST SP 800-38A [3] A1414, CTR_DRBG NIST SP 800-90A [4] AES-128- CTR_DRBG using AES Deterministic Random A1425 NODF without derivation Bit Generation AES-192function NODF AES-256NODF A1413, CTR_DRBG NIST SP 800-90A [4] AES-128-DF CTR_DRBG using AES with Deterministic Random A1426 AES-192-DF derivation function Bit Generation AES-256-DF A1412, Hash_DRBG SHA-1 HASH_DRBGs using SHA Deterministic Random A1419, NIST SP 800-90A [4] SHA- 256 Bit Generation A1427, SHA-512 A1432 A1409, SHA-13 FIPS 180-4 [1] SHA-1 Message Digests Message Digest Creation A1428, Supports input message A39261, lengths from 1 byte to 8 GB A39292 depending on OE A1410, SHA-256 FIPS 180-4 [1] SHA-256 Message Digests Message Digest Creation A1418, Supports input message A39274, lengths from 1 byte to 8 GB A39305 depending on OE A1411, SHA-512 FIPS 180-4 [1] SHA-512 Message Digests Message Digest Creation A39286, Supports input message A39317 lengths from 1 byte to 8 GB depending on OE
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).
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):
Table 4: Physical Ports and Logical Interfaces Physical Logical Interface Description Port N/A Data Input, The logical interface is a C API. All data input, data output, control Data Output, input, and status output are done via the C API. All SSPs are given to Control Input, the API or requested by it via C callbacks. No SSPs are generated by the Module. All SSPs consumed by the module are passed in as Status Output parameters except DRBG entropy and nonce, which are loaded via callback functions that conform with the requirements in NIST SP 800- 90A [4] section 9.1. DRBG entropy and nonce cannot be provided as input parameters to the instantiate function. The Module accepts a C function pointer that implements the Get_entropy_input function defined in NIST SP 800-90A [4] Section 9 in order to request the entropy as required. The Module accepts a second C function pointer to acquire the nonce in a similar manner. Both callback function interfaces are described below. This is the Software Module Interface. N/A Data Input When a DRBG instantiates, it needs entropy. The C API invokes a callback function registered by the library user at the moment the entropy is needed. The callback function requires the library user to acquire the entropy and load it in to either a provided buffer or their own buffer for use by the instantiation procedure. Immediately after use by the instantiation procedure, the entropy buffer (either provided by the Module or by the user) is zeroised. The callback function is provided with the minimum number of bits of entropy required and the minimum/maximum length of the entropy bitstring that must contain the required number of bits of entropy for the desired security strength. 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). The callback function must return the status and entropy bitstring. The callback function must return an error if the minimum number of entropy bits are not available. The instantiation procedure verifies the status and entropy bitstring size constraints and returns an error if the status is not success or the entropy bitstring is not a valid size. This is the DRBG Entropy Callback Function. N/A Data Input When a DRBG instantiates, it may need a nonce, depending on the DRBG algorithm. The API invokes a callback function registered by the library user at the moment the nonce is needed. The callback function must load the nonce in a provided buffer. The instantiation procedure verifies the nonce bitstring size constraints. This is the DRBG Nonce Callback Function. 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 Table 5: Roles, Approved Service Commands, Input, And Output Roles with Service Input Output Service Access Control PAA N/A N/A CO CO Message Digest Data to be digested Message digest, status Perform Conditional Self-Tests N/A Self-test status CO CO Perform Pre-Operational Self- N/A Self-test status Tests CO Random Number Generation Entropy, nonce, and Random number, status personalization string CO Show Module Name / Identifier N/A Module name, version and Versioning Information CO Show Status N/A Approved service status Symmetric Encryption / Key, IC, IV, data Encrypted / decrypted CO Decryption data, status CO Zeroisation N/A Status 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 Role Service Description Security Functions Access Rights to Keys Approved Service Used / SSPs Indicator CO Control PAA Control the use of PAA N/A N/A Service completion CO Message Digest Generate message SHA-1 or N/A Status indicating digest SHA-256 or success or failure SHA-512 CO Perform Perform KAT on AES CBC & N/A Status indicating Conditional Self- algorithms AES CTR & success or failure Tests AES ECB & CTR_DRBG & Hash_DRBG & SHA Perform Pre- Perform library AES CBC & N/A Status indicating CO Operational Self- integrity check and AES CTR & success or failure when Tests KAT on algorithms AES ECB & commanded or CTR_DRBG & application abort on Hash_DRBG & startup SHA CO Random Number Generate random CTR_DRBG or CTR_DRBG V: (G, E) Status indicating Generation numbers Hash_DRBG CTR_DRBG Key: (G, E) success or failure Hash_DRBG V, C: (G, E) DRBG Entropy (W, E, Z) CO Show Module Retrieve information N/A N/A Service completion Name / Identifier about the Module and Versioning Information Show Status Retrieve the approved N/A N/A Non-zero if approved CO service status or zero if not approved CO Symmetric Perform symmetric AES CBC or AES Key: W, E Status indicating Encryption / encryption and AES CTR or success or failure Decryption decryption AES ECB This document may be freely reproduced and distributed, but only in its entirety and without modification.
CO Zeroisation Zeroise SSP AES CBC & AES Key: Z Status indicating AES CTR & DRBG Entropy: Z success or failure for CTR_DRBG V: Z AES ECB & DRBGs; service CTR_DRBG Key: Z CTR_DRBG & Hash_DRBG V, C: Z completion for ciphers Hash_DRBG 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):
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 Key / SSP/ Strength Security Generation Import / Export Establishment Storage Zeroisation Use & Related Name / Function & Cert. Keys Type Number
128 bits, AES CBC N/A Import: Plaintext; Provided by Plaintext in RAM Zeroisation Key used to
192 bits, (A1406, A1422) Export: N/A consuming (temporarily) encrypt or
256 bits Method: Electronic application decrypt data
AES CTR (A1407, A1423) AES ECB (A1408, A1424) ≥112 bits CTR_DRBG N/A Import: Plaintext; Provided by Plaintext in RAM Zeroised Used to DRBG (A1414, A1425) Export: N/A consuming (temporarily) implicitly in instantiate the Entropy Method: Electronic application instantiation DRBG Hash_DRBG immediately (A1412, A1419, upon use A1427, A1432)
128 bits CTR_DRBG N/A Import: N/A; Derived from Plaintext in RAM Zeroisation State of the
CTR_DRBG (A1414, A1425) Export: N/A entropy, nonce, (temporarily) service DRBG V and personalization string CTR_DRBG 128 bits, CTR_DRBG N/A Import: N/A; Derived from Plaintext in RAM Zeroisation State of the (A1414, A1425) Export: N/A entropy, nonce, (temporarily) service DRBG Key 192 bits,
440 bits, Hash_DRBG N/A Import: N/A; Derived from Plaintext in RAM Zeroisation State of the
888 bits (A1412, A1419, Export: N/A entropy, nonce, (temporarily) service DRBG
V, C A1427, A1432) and personalization string 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 Tested Self-Test Conditions For Error Indicator Function Performing Test Library SHA-256 digest of the dynamic library file Library load Failure to load integrity compared to the known digest computed at ecl_g_fips_error build time set to true
All Conditional Self-Tests test the non-PAA implementation. If PAA is available, the PAA implementation is also tested. Table 9: Conditional Self-Tests Tested Function Self-Test Conditions For Error Indicator Performing Test AES CBC AES-128-CBC Encrypt KAT On demand or when Status output: (Certs A1406, AES-128-CBC Decrypt KAT changing the PAA ecl_status_cipher_tes A1422) AES-192-CBC Encrypt KAT option t_failed AES-192-CBC Decrypt KAT AES-256-CBC Encrypt KAT AES-256-CBC Decrypt KAT AES CTR AES-128-CTR Encrypt KAT On demand or when Status output: (Certs A1407, AES-128-CTR Decrypt KAT changing the PAA ecl_status_cipher_tes A1423) AES-192-CTR Encrypt KAT option t_failed AES-192-CTR Decrypt KAT AES-256-CTR Encrypt KAT AES-256-CTR Decrypt KAT This document may be freely reproduced and distributed, but only in its entirety and without modification.
AES ECB AES-128-ECB Encrypt KAT On demand or when Status output: (Certs A1408, AES-128-ECB Decrypt KAT changing the PAA ecl_status_cipher_tes A1424) AES-192-ECB Encrypt KAT option t_failed AES-192-ECB Decrypt KAT AES-256-ECB Encrypt KAT AES-256-ECB Decrypt KAT CTR_DRBG NODF8 CTR-AES-128-NODF Instantiate KAT On demand or when Status output: (Certs A1414, CTR-AES-128-NODF Generate KAT changing the PAA ecl_status_drbg_cata A1425) CTR-AES-192-NODF Instantiate KAT option strophic CTR-AES-192-NODF Generate KAT CTR-AES-256-NODF Instantiate KAT CTR-AES-256-NODF Generate KAT CTR_DRBG DF9 CTR-AES-128-DF Instantiate KAT On demand or when Status output: (Certs A1413, CTR-AES-128-DF Generate KAT changing the PAA ecl_status_drbg_cata A1426) CTR-AES-192-DF Instantiate KAT option strophic CTR-AES-192-DF Generate KAT CTR-AES-256-DF Instantiate KAT CTR-AES-256-DF Generate KAT Hash_DRBG10 HASH-SHA-1 Instantiate KAT On demand or when Status output: (Certs A1412, HASH-SHA-1 Generate KAT changing the PAA ecl_status_drbg_cata A1419, A1427, HASH-SHA-256 Instantiate KAT option strophic A1432) HASH-SHA-256 Generate KAT HASH-SHA-512 Instantiate KAT HASH-SHA-512 Generate KAT SHA-1 SHA-1 Digest KAT On demand or when Status output: (Certs A1409, changing the PAA ecl_status_hash_test_ A1428) option failed SHA-256 SHA-256 Digest KAT On demand, when Status output: (Certs A1410, changing the PAA ecl_status_hash_test_ A1418) option, or prior to the failed library integrity check SHA-512 SHA-512 Digest KAT On demand or when Status output: (Certs A1411, changing the PAA ecl_status_hash_test_ A1433) option failed
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 Reference Reference Title Publishing Entity Publication Date Number [1] FIPS 180-4 NIST 08/2015 [2] FIPS 197 NIST 11/26/2001 [3] NIST SP 800-38A NIST 12/2001 [4] NIST SP 800-90A NIST 06/2015 This document may be freely reproduced and distributed, but only in its entirety and without modification.
Table 11: Abbreviations and Definitions Term Definition AES Advanced Encryption Standard CAST Cryptographic Algorithm Self-Test CBC Cipher Block Chaining mode of operation CSP Critical Security Parameters CTR Counter mode of operation DF Derivation Function DRBG Deterministic Random Bit Generator ECB Electronic Code Book mode of operation IC Initial Count IV Initialization Vector KAT Known Answer Test NODF No Derivation Function PAA Processor Algorithm Acceleration POST Pre-Operational Self-Test PSP Public Security Parameters SDK Software Development Kit SHA Secure Hash Algorithm SSP Sensitive Security Parameters (CSP + PSP) This document may be freely reproduced and distributed, but only in its entirety and without modification.