Mocana Cryptographic Suite B Module

Certificate

Approved Algorithms (54)

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

flowchart LR
  %% Deterministic review-risk graph for Mocana Cryptographic Suite B 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 Suite B 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 Suite B Module Version 7.0.0f_u1 Non-Proprietary FIPS 140-3 Security Policy Document Version: 1.2 Date: July 23, 2024 DigiCert, Inc.

Suite 500 Lehi, UT 84043 +1 800-896-7973 May be reproduced only in its original entirety [without revision]

version 7.0.0f_u1 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 Level 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, 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 shared object (SO), libmss.so, associated signature file, a persistent status file, and the CPU when PAA is enabled. 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 Mocana Suite B 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 shared library files (libmss.so) and the integrity check signature file (libmss.so.sig), the POST status file (mssp.bin), and the CPU when PAA is enabled. 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: 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 per IG C.I.

Table 5

• 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 6
• 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 The Module implements the approved security functions listed in the table below. Table 7 – Security Function Implementation (SFI)

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 Mocana’s operating environment specific documentation. For example: on most linux systems, this means that the libmss.so shared library 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. (RSA) The calling application of the Module must generate RSA key pairs of at least 2048 bits to operate in approved mode. (ECC) The calling application of the module must generate ECC keys using a P-Curve with a security strength of at least 112 bits to operate in the approved mode of operation.

(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: There is 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 defined logical interface categories are listed in Table 8. The module’s Table 8 – 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 10 and Table 11 below. The SSPs modes of access shown in Table 10 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.
• Z = Zeroize: The Module zeroizes the SSP Table 10
• Approved Services

Table 11 – Non-Approved Services

The Module is composed of the following single software component packaged as a shared object (also known as a shared library).

• libmss.so
• This is the shared library that contains the cryptographic module code, data, and constants.
• libmss.so.sig
• This is the Integrity check signature file that contains an HMAC-SHA-256 of the crypto module.
• mssp.bin
• This is the POST status file. It contains persistent results of the first-run of POST. See POST-integrity-check algorithm self-test. Integrity Check: The shared library is protected with the authentication technique HMAC-SHA-256 described in . The HMAC for the shared library is calculated during the manufacturing (build) process of the shared library. This HMAC value is stored either within the resulting “libmss.so” shared object or as a separate “libmss.so.sig” file dependent upon the development tools and target operating systems constraints. During the load of the shared object, the integrity check of the library code and constants occurs in the module startup function. It verifies the integrity of the shared library by executing the HMAC-SHA-256 fingerprint algorithm on the libmss.so 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 shared object into memory as shown below. #ifdef __ENABLE_MOCANA_FIPS_LIB_CONSTRUCTOR__ static void FIPS_constructor() __attribute__((constructor)); void FIPS_constructor() { FIPS_powerupSelfTest(); } #endif 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 14. 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 16). These CASTs are performed on-demand. The first time a FIPS algorithm is used, the CAST test for that algorithm is tested before the FIPS algorithm processing is done.

After the CAST test for each algorithm is run, the status of each algorithm CAST test is stored as an array within the FIPS module so that subsequent usage of each algorithm can detect the CAST test for that module has completed successfully and no longer needs to run. If the CAST test fails for an algorithm, then a global CAST status is set to a failure code and subsequent calls to FIPS cryptographic functions will fail. The FIPS module provides an API to allow the Cryptographic Officer to initiate the FIPS powerup selftests on demand. This includes all CAST tests. Additionally, an API is provided to enable the Cryptographic Officer to persist the state of these self-tests. The state of the self-test is stored in the mssp.bin file. During Module startup, the presence of the previously saved state of self-tests is detected. If the saved-state is more recent than the O/S boot time, then the saved state information for the self-tests is loaded as the starting state. This will enable a cryptographic officer to execute a single run of all conditional self-tests after each boot of the operating system, and subsequent applications using the same Module will not have to re-run the conditional self-tests. Note that the Pre-Integrity Check Power up Self Tests, and Integrity Check described above are always run within each instance of the Module.

The Module has a modifiable operational environment under the FIPS 140-3 definitions. The tested operational environments - Software are listed in Table 2 above. In addition, Mocana 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 Mocana Cryptographic Suite B Module is software only.

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

The SSPs access methods are described in Table 12 below: Table 12 – 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. Table 13 – SSPs

Table 14 – 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 15 – 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 16 – Conditional Self-Tests

The self-tests error states and status indicator are described in table below: Table 17 – 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 There is no specific guidance for Administrator or non-Administrators. The module is provided with supporting documentation which includes an API Reference document and Operating Environment document.

The Cryptographic Officer will install the Module and associated signature of the Module into the proper location within the computer system. For example, the shared memory library 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 the approved mode to ensure that FIPS 140-3 validated cryptographic

The Module does not implement any mitigation method against other attacks beyond the requirements for

The following standards are referred to in this Security Policy. Table 18 – References

Table 19 – Acronyms and Definitions