Mocana Cryptographic Loadable Kernel Module

Certificate

Approved Algorithms (34)

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

flowchart LR
  %% Deterministic review-risk graph for Mocana Cryptographic Loadable Kernel Module
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>update</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>status output<br/>Show status</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>no library/version identified</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>kernel</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
    R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
    R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
    R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E2["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C5 --> I5 --> R5 --> E5
  C6 --> I6 --> R6 --> E6
  classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
  classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
  classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
  class C2,C3,C5,C6 clue;
  class I2,I3,I5,I6 infer;
  class R2,R3,R5,R6 risk;
  class E2,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Mocana Cryptographic Loadable Kernel Module
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>update</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>status output<br/>Show status</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>no library/version identified</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<br/>kernel</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C2,C3,C5,C6 clueLow;

Security Policy, page by page

Mocana Cryptographic Loadable Kernel Module Version 7.0.0f Non-Proprietary FIPS 140-3 Security Policy Document Version: 1.1 Date: August 01, 2024 DigiCert, Inc.

Module version 7.0.0f hereafter denoted the Module. It contains the security rules under which the module must operate and describes how this module meets the requirements specified in FIPS 140-3 for a Security The Module design corresponds to the Module security rules. The security rules enforced by the Module are described in this document.

The primary purpose of this module is to provide approved cryptographic routines to consuming applications via an Application Programming Interface (API). The Module conforms to [ISO/IEC 19790:2012] Section 7.2 Cryptographic Module Specification. The Module is a software only, multi-chip standalone cryptographic module that runs on a general-purpose computer which is the Tested Operational Environment’s Physical Perimeter (TOEPP). The cryptographic boundary of the Module is the single kernel object (KO), moc_crypto.ko and associated signature file. No components are excluded from the [ISO/IEC 19790:2012] A.2.2 requirements. The Module supports the normal mode of operation under which all of the algorithms, security functions, and services are available; degraded operation is not supported. The Module is intended for use by US Federal agencies or other markets that require FIPS 140-3 validated Security Level 1 software modules. The Module is intended to be used in dedicated purpose IOT (Internet of Things) devices and general-purpose computer systems.

The Cryptographic Module is tested on the following operational environment(s): Table 2

• Tested Operational Environments - Software Digicert also performed the testing of the Module on the following Operational Environment(s) and claims vendor affirmation on them: Table 3
• Vendor Affirmed Operational Environment 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 that is not listed on the validation certificate.

The software block diagram in Figure 1 shows the module, interfaces with the Tested Operational Environment, and the delimitation of its cryptographic boundary, shown shaded in blue. The Cryptographic Boundary is shown in Figure 1 and is comprised of the kernel module, (moc_crypto.ko) and the integrity check signature file (moc_crypto.ko.sig). The dashed line in Figure 2 indicates the Logical Object. The Module's operations occur via API calls from calling applications running within the same process as the Module. Figure 1 – Cryptographic Module Interface Design

The module supports approved and non-approved modes of normal operation:

1. Approved mode (the Approved mode of operation): only approved or allowed security functions with sufficient key security strength can be used.
2. Non-approved mode: When non-approved security functions or approved security functions with insufficient key security strength are used. The Module enters approved mode after pre-operational self-tests have successfully completed. Once the Module is operational, the mode of operation is implicitly assumed depending on the security function invoked and the security strength of the cryptographic keys. To provide an indicator of the current mode of operation, an asynchronous callout event mechanism is provided. The application using the Module can register for a FIPS_eventLog call-out function to be used as the approved-mode/non-approved-mode indicator. The application’s FIPS_eventLog function will be called from the Module at the beginning and end of each approved or non-approved service or algorithm. This FIPS_eventLog and the FIPS_EventType enumeration value provided as a parameter serves as a threadsafe status indicator of the current approved or non-approved mode of operation. The Module uses the scenario of a shared indicator for multiple services, per IG 2.4.C example #3. It uses a dedicated status output interface that is a software callback function. The calling application using the Module registers a callback function to be called at the beginning and end of all services and algorithm implementations. The callback function FIPS_eventLog() is called with an enumeration that specifies the start and stop of services and algorithms. It also specifies whether they are approved or non-approved. The specific crypto-algorithm ID is also provided to this callback function. By interpreting the enumeration and algo-ID in the callback function, the callback function is the software analog of a hardware LED. Whether that function actually turns on and off a H/W LED or logs these FIPS indicator events, is left to the calling application as appropriate for the application domain.

Keys and CSPs shall not be shared between the approved and non-approved mode of operation.

The approved mode of operation is configured at instantiation of the Module by the Cryptographic Officer role by execution of an application or protocol operating system process that uses the Module’s cryptographic functions.

The Module transitions to the non-approved mode of operation when one of the non-approved security functions is utilized. The Module can transition back to the approved mode of operation by utilizing an approved security function.

The Module implements the approved and non-approved but allowed cryptographic functions listed in the table(s) below. Table 4 – Approved Algorithms The XTS algorithm implementation includes a check to ensure Key_1 ≠ Key_2

Note: Other algorithms were tested but not implemented by this module. Note: The module does not have any vendor affirmed algorithms allowed in the approved mode of operation. Note: The module does not have any non-approved but allowed algorithms. Note: The module does not have any non-approved algorithms with no security claimed. Table 5 – Non-Approved Algorithms Not Allowed in the Approved Mode of Operation Note: All the various AES mode (e.g., EAX, XCBC, XTS, etc.) use the same underlying AES

1. The Module provides one operator role: Cryptographic Officer.
2. The Module does not provide any operator authentication.
3. An operator does not have access to any cryptographic services prior to assuming an authorized role.

4. The Module allows the operator to initiate power-up self-tests by power cycling power or reloading the Module into memory.
5. Pre-operational self-tests do not require any operator action.
6. Data outputs are inhibited during key generation, self-tests, zeroization, and error states. Because the logical interface is defined as the API of the Module and the API of the Module is single-threaded, key generation or zeroization must be complete before the API returns control to the calling application.
7. Status information does not contain SSPs or sensitive data that if misused could lead to a compromise of the Module.
8. There are no restrictions on which keys or SSPs are zeroized by the zeroization service.
9. The Module does not support concurrent operators.
10. The Module does not support a maintenance interface or role.
11. The Module does not support manual SSP establishment method.
12. The Module does not have any proprietary external input/output devices used for entry/output of data.
13. The Module does not enter or output plaintext SSPs, except to/from the calling application via API parameters. The module does not support the entry or output of encrypted SSPs.
14. The Module does not store any plaintext SSPs. SSPs provided to the Module by the calling processes are destroyed when released by the appropriate API function calls.
15. The Module does not output intermediate key values.
16. The Module does not provide bypass services or ports/interfaces.
17. AES GCM IV uniqueness: The AES GCM implementation meets Option 1 of IG C.H. The Module supports TLS 1.2 GCM Cipher Suites for TLS, as described in RFCs 5116, 5288 and 5289. The counter portion of the IV is set by the Module within its cryptographic boundary. When the nonce_explicit (counter) part of the IV exhausts the maximum number of possible values for a given session key this condition triggers a handshake to establish a new encryption key per RFC 5246. During operational testing, the Module was tested against an independent version of TLS and found to behave correctly. AES GCM keys are zeroized when the Module is power-cycled and for each new TLS session, a new AES GCM key is established.
18. AES XTS is to be used only for storage purposes, per SP800-38E.

The Module shall be installed within the operating system confines and structures consistent with Digicert’s operating environment specific documentation. For example: on most linux systems, this means that the moc_crypto.ko kernel module will be installed in the file system in “/lib” or “/lib64”, or it may be specified in the operating environment specific documentation to be installed in “/usr/local/lib” as appropriate for the target platform. The Module is automatically started when linked and loaded with an application using the cryptographic functions of the Module.

To update or replace the module, all SSPs shall first be zeroized and the calling application shall be closed. SSP zeroization is performed through the Key Destruction service that is described below. API calls will overwrite the memory occupied by the key information with zeros before that memory is de-allocated. If the calling application is terminated prior to zeroization, the Linux kernel overwrites the keys in physical memory before the physical memory is allocated to another process. The key zeroization process is performed in a sufficient time to prevent compromise of SSPs, taking only a few milliseconds. The previous existing module files shall be removed prior to following the installation directions above, for the new module version. (Random Number Generation) The Module implements a CTR-based DRBG per SP800-90A for creation of symmetric and asymmetric keys. The Module accepts input from entropy sources external to the cryptographic boundary for use as seed material for the Module's approved DRBGs. External entropy can be added via several APIs available to the cryptographic module client application. The calling application of the Module shall use entropy sources that meet the security strength required for the random bit generation mechanism as shown in NIST SP 800-90A Table 3 (CTR_DRBG). A minimum of 384 bits of entropy must be provided by the calling application. The calling application shall provide full entropy for 256-bit keys. Due to the entropy being provided by an external source, the following caveat applies: When operated in approved mode. No assurance of the minimum strength of generated SSPs (e.g., keys). The Module performs DRBG health tests (Instantiate, Generate, Reseed) as defined in section 11.3 of SP800-90A. (Key Management) The application that uses the module is responsible for appropriate destruction and zeroization of the keys. The Module provides API calls for key allocation and destruction. These API calls overwrite the memory occupied by the key information with zeros before that memory is de-allocated. See Key Destruction Service below. (Key/CSP Authorized Access and Use) An authorized application has access to all key data generated during the operation of the Module. (Key/CSP Storage) Private and public keys are provided to the module by the calling process and are destroyed when released by the appropriate API function calls. The module does not perform persistent storage of keys. (Key/CSP Zeroization) The application is responsible for calling the appropriate destruction functions from the API. These functions overwrite the memory with zeros and de-allocate the memory. In case of abnormal termination, the Linux kernel overwrites the keys in physical memory before the physical memory is allocated to another process.

(Key Destruction Service) A context structure is associated with every cryptographic algorithm available in the Module. Context structures hold sensitive information such as cryptographic keys. These context structures must be destroyed via respective API calls when the application software no longer needs to use a specific algorithm. This API call will zeroize all sensitive information before freeing the dynamically allocated memory. This will occur while the application process is still in memory, but no longer needs the specific algorithm, which protects the sensitive information from compromise. See the Mocana Cryptographic API Reference for additional information.

The Module’s ports and associated FIPS defined logical interface categories are listed in Table 6

• Ports and Interfaces. The module’s logical interface (API) provides logical separation of the input and output interfaces. Table 6
• Ports and Interfaces

The module is Level 1 and does not implement any Authentication techniques. The Module supports one operator role, Cryptographic Officer (CO). The cryptographic module does not support multiple concurrent users, bypass capability, or a maintenance role. The Cryptographic Officer role is implicitly identified by the service that is requested.

All services implemented by the Module are listed in Table 8 and Table 9 below. The SSPs modes of access shown in Table 8 are defined as:

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

Table 9– Non-Approved Services

The Module is composed of the following single software component packaged as a kernel object.

• moc_crypto.ko - This is the shared library that contains the cryptographic module code, data, and constants.
• moc_crypto.ko.sig
• This is the Integrity check signature file that contains an HMAC-SHA-256 of the crypto module. Integrity Check The kernel module is protected with the authentication technique HMAC-SHA-256 described in Table 13. The HMAC for the kernel module is calculated during the manufacturing (build) process of the kernel module. This HMAC value is stored either within the resulting “moc_crypto.ko” kernel object or as a separate “moc_crypto.ko.sig” file dependent upon the development tools and target operating systems constraints. During the load of the kernel object, the integrity check of the library code and constants occurs in the module startup function. It verifies the integrity of the kernel module by executing the HMAC-SHA-256 fingerprint algorithm on the moc_crypto.ko file and comparing the result with the signature. This integrity check is performed as part of the function FIPS_powerupSelfTest(). This function is called automatically by the host O/S upon loading the kernel module into memory as shown below.

Figure 3 - Code Example for Self-Test The operator can also explicitly initiate the integrity test on demand by calling the API function: FIPS_StartupSelftestIntegrity(void). Pre-Integrity Check Power up Self Tests: To fulfill the Implementation Guidance 10.3.A, the algorithms used to perform the integrity check are executed before the module integrity check. These are lists in more detail in Table 18 Pre-Operational Self-Test. The following algorithm KAT tests are performed in the FIPS_powerupSelfTest implementation before the integrity check:

• SHA-256
• HMAC-SHA-256 Note: Although not used by the integrity check, the DRBG KAT test is also run during this initial FIPS_powerupSelfTest().

Post-Integrity Check Algorithm Self Tests: As a startup optimization, the self-tests for all other approved algorithms are implemented as Conditional Self-Tests (see Table Table 16). These KAT Self-Tests are performed on-demand. This means that the first time an approved algorithm is used, the CAST test for that algorithm is tested before the approved algorithm processing is done.

The Module has a modifiable operational environment under the FIPS 140-3 definitions. The tested operational environments are listed in Table 2 above. In addition, Digicert claims that the Module can be ported on the Operational Environment(s) listed in Table 3; no statement is made regarding the correct operation of the Module on the Vendor Affirmed Operational Environments.

The FIPS 140-3 Physical Security requirements are not applicable because the Cryptographic Module is software only.

The Module does not implement any mitigation method against non-invasive attack.

The SSPs access methods are described in Table 10 below: Table 10 – SSP Management Methods All SSPs used by the Module are described in this section. All usage of these SSPs by the Module is described in the services detailed in Section 4.2.

CSP

Strengt h (in bits)

Security Functio n / Cert.

Generation

Import /Export

Establish -ment

Storage

Zeroiza- tion

Zeroiza- tion

Use / Related SSPs SHA3- 224, 256, 384, 512 operations

Note: The module does not have PSPs. Table 12 – Non-Deterministic Random Number Generation Specification

The Module performs self-tests to ensure the proper operation of the Module. Per FIPS 140-3 these are categorized as either pre-operational self-tests or conditional self-tests.

Security Level 1 - Pre-operational self–tests are available on demand by power cycling or reloading the Module into memory. The Module is available to perform services only after successfully completing the pre-operational self-tests. The Module performs the following pre-operational self-tests: Table 13 – Pre-Operational Self-Test Note: The module does not perform pre-operational bypass tests. Bypass is not implemented.

The Module performs the following conditional self-tests:

Table 14 – Conditional Self-Tests

The self-tests error states and status indicator are described in table below: Table 15 – Error States and Indicators

Installation is performed by placing the module in the target file system during the OEM or ISV’s manufacturing process. The module initialization is performed automatically by the operating system’s loader when a calling application is loaded into memory. Operation of the module is controlled by the calling application’s use of the module’s API functions. There is no specific guidance for Administrator or non-Administrators.

The Cryptographic Officer will install the Module and associated signature of the Module into the proper location within the computer system. For example, the kernel module and signature file may be installed in the /usr/local/lib directory, which is protected by Linux access control mechanisms. The Module is protected from modification by the integrity self-test performed during start-up. The Module is initialized by the operating system upon loading the Module into memory for use by calling applications. The Module must be operated in approved mode to ensure that FIPS 140-3 validated cryptographic algorithms and security functions are used.

The Module does not implement any mitigation method against other attacks beyond the requirements for FIPS 140-3 Level 1 cryptographic modules.

The following standards are referred to in this Security Policy.

Table 17 – Acronyms and Definitions