Cradlepoint Kernel Cryptographic Module

Certificate

Approved Algorithms (24)

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

flowchart LR
  %% Deterministic review-risk graph for Cradlepoint Kernel Cryptographic Module
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>update</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>Status Output</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>IKEV<br/>IPSEC<br/>HTTPS</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>kernel<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."]
    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 Cradlepoint Kernel Cryptographic Module
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>update</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>Status Output</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>IKEV<br/>IPSEC<br/>HTTPS</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>kernel<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,C5,C6 clueLow;

Security Policy, page by page

Ericsson Enterprise Wireless Solutions, Inc. Ericsson Cradlepoint Kernel Cryptographic Module Versions: 1.0, 2.0 FIPS Security Level: 1 Document Version: 0.8 Prepared for: Prepared by: Ericsson Enterprise Wireless Corsec Security, Inc. Solutions, Inc.

1100 W. Idaho Street, Floor 8 12600 Fair Lakes Circle, Suite 210

Boise, ID 83702-5389 Fairfax, VA 22033 United States of America United States of America Phone: +1 888 331 2968 Phone: +1 703 267 6050 www.cradlepoint.com www.corsec.com

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

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

NetCloud for Branch makes it easy to accelerate connecting to the Internet and critical applications from anywhere. Designed for traditional medium branches or locations requiring flexible connectivity, reliable performance, and simplified management, this all-in-one, compact endpoint includes full-featured routing, security, and Wi-Fi without needing extra hardware or complicated configurations. The Ericsson Cradlepoint Kernel Cryptographic Module is a cryptographic library running as part of the NetCloud operating system (OS) kernel that provides cryptographic services for Ericsson endpoints. The module offers symmetric encryption/decryption, digital signature verification, hashing, message authentication, and key establishment functions to support secure communications protocols. The module uses the Ericsson Cradlepoint Cryptographic Module 1.0 (FIPS 140-3 certificate #4770) as a bound module to provide cryptographic support for the module’s integrity testing. This requires an instance of the validated version of the Ericsson Cradlepoint Cryptographic Module to be installed on the system for the primary module to operate in an Approved manner. The Ericsson Cradlepoint Kernel Cryptographic Module is validated at the FIPS 140-3 section levels shown in Table 1. Table 1 – Security Levels

1 WAN – Wide Area Network

2 IoT – Internet of Things

©2026 Ericsson Enterprise Wireless Solutions, Inc.

The module has an overall security level of 1. Ericsson Cradlepoint Kernel Cryptographic Module ©2026 Ericsson Enterprise Wireless Solutions, Inc.

2. Cryptographic Module Specification The Ericsson Cradlepoint Kernel Cryptographic Module (versions 1.0 and 2.0) is a software module with a multichip standalone embodiment. The module is designed to operate within a modifiable operational environment. The module comprises kernel loadable components, a static kernel binary, an integrity test utility, and digest files for testing integrity. All module components are contained within the host platform’s physical enclosure.

The module was tested and found to be compliant with FIPS 140-3 requirements on the environments listed in Table

2. Table 2 – Tested Operational Environments The vendor affirms the module’s continued validation compliance when operating on the environments listed in Table
3. Table 3 – Vendor-Affirmed Operational Environments The cryptographic module maintains validation compliance when operating on any general-purpose computer (GPC) provided that the GPC uses any single-user operating system/mode specified on the validation certificate, or another compatible single-user operating system. The CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when ported to an operational environment not listed on the validation certificate. The sections below describe the module boundary, algorithm implementations, and modes of operation. Ericsson Cradlepoint Kernel Cryptographic Module ©2026 Ericsson Enterprise Wireless Solutions, Inc.

Validation certificates for each Approved security function are listed in Table 4 below. Note that there are algorithms, modes, and key/moduli sizes that have been CAVP-tested but are not used by any Approved service of the module. The update from version 1.0 to version 2.0 removes all Triple DES functions and adds AES-CTR encryption/decryption as an Approved algorithm. Only the algorithms, modes/methods, and key lengths/curves/moduli shown in Table 4 are used by an Approved service of the module. Table 4 – Approved Algorithms

4 PUB – Publication

5 CBC – Cipher Block Chaining

6 ECB – Electronic Codebook

7 PUB – Publication

8 PUB – Publication

GCM – Galois/Counter Mode

10 HMAC – (Keyed-) Hash Message Authentication Code

11 KTS – Key Transport Scheme

12 Per FIPS 140-3 Implementation Guidance D.G, AES-GCM is an Approved key transport technique.

13 SHS – Secure Hash Standard

Ericsson Cradlepoint Kernel Cryptographic Module ©2026 Ericsson Enterprise Wireless Solutions, Inc.

Table 5 lists the Approved algorithms that are provided by the bound module and used by this module in the Approved mode. The table includes only those algorithms used by the primary module. Table 5

• Approved Algorithms (provided by the Bound Module) The module implements the non-Approved but allowed algorithms shown in Table 6 below. Table 6
• Non-Approved Algorithms Allowed in the Approved Mode of Operation The module does not implement any non-Approved algorithms allowed in the Approved mode of operation for which no security is claimed. The module does not implement any non-Approved algorithms not allowed in the Approved mode of operation. key transport. Ericsson Cradlepoint Kernel Cryptographic Module ©2026 Ericsson Enterprise Wireless Solutions, Inc.

As a software cryptographic module, the module has no physical components. The physical perimeter of the cryptographic module is defined by the host platform on which the module is installed. The module’s cryptographic boundary comprises all functionalities contained within the module’s compiled source code. Several of the module’s components are contained within a FIT 17 image called fit.itb.padded. These components are:

• Version 1.0 o /lib/modules/4.4.100-coconut/kernel/crypto/*.ko (cryptographic kernel object files) o /lib/modules/4.4.100-coconut/kernel/crypto/ocf/*.ko (cryptographic kernel object files)
• Version 2.0 o /lib/modules/5.4.164-coconut/kernel/crypto/*.ko (cryptographic kernel object files) o /lib/modules/5.4.164-coconut/kernel/crypto/ocf/*.ko (cryptographic kernel object files) The remaining components are:
• /dev/mmcblk0pX (static kernel binary partition)
• /service_manager/verify_kernel_hmac.pyc (integrity test utility)
• /etc/rc (script file for executing integrity test utility)
• /etc/hmacs (file containing the HMAC digest values for the FIT image, integrity test utility, and rc script) The cryptographic boundary is the contiguous perimeter that surrounds all memory-mapped functionality provided by the module when loaded and stored in the host platform’s memory. The module is entirely contained within the physical perimeter of the host platform. Figure 1 shows the logical block diagram of the module executing in memory, its location with respect to the operating system and other supporting applications, and its interactions with surrounding software components, as well as the host platform’s physical perimeter and module’s cryptographic boundary.

17 FIT – Flattened uImage Tree

Ericsson Cradlepoint Kernel Cryptographic Module ©2026 Ericsson Enterprise Wireless Solutions, Inc.

User Space Cradlepoint                             Integrity Cryptographic                               test              /etc/hmacs Module                                  utility Calling application                               rc script Kernel Space FIT image KEY:                                                                       Static kernel image Cryptographic Boundary               Other kernel Other kernel mechanisms Other kernel                        Loadable kernel objects (*.ko) mechanisms Other kernel mechanisms Physical Perimeter                     mechanisms Data Input Data Output Control Input Control Output Status Output                       Storage            Memory         CPU                      Ports System Calls Host Device Figure 1 – Module Block Diagram

The module only implements one mode of operation, the Approved mode, in which the Approved and allowed cryptographic functions are available. The module transitions to the Approved mode of operation automatically after the module completes its pre-operational self-tests. No configuration is necessary for the module to operate and remain in the Approved mode. Ericsson Cradlepoint Kernel Cryptographic Module ©2026 Ericsson Enterprise Wireless Solutions, Inc.

FIPS 140-3 defines the following logical interfaces for cryptographic modules: As a software library, the cryptographic module has no direct access to any of the host platform’s physical ports/interfaces. The logical interfaces are the kernel-level APIs 18 by which module services are requested. A mapping of the FIPS-defined interfaces and the module’s ports and interfaces can be found in Table 7. Note that Table 7 – Ports and Interfaces

18 API – Application Programming Interface

Ericsson Cradlepoint Kernel Cryptographic Module ©2026 Ericsson Enterprise Wireless Solutions, Inc.

4. Roles, Services, and Authentication The sections below describe the module’s authorized roles, services, and operator authentication methods.

The module supports the following role(s) that authorized operators can assume:

• Crypto Officer (CO)
• The CO role performs cryptographic initialization or management functions and general security services.
• User
• The User role performs general security services, including cryptographic operations and other approved security functions. The module does not support multiple concurrent operators. The calling application that loaded the module is its only operator. Table 8 below lists the supported roles, along with the services (including input and output) available to each role. Table 8
• Roles, Service Commands, Input and Output

19 MAC – Message Authentication Code

Ericsson Cradlepoint Kernel Cryptographic Module ©2026 Ericsson Enterprise Wireless Solutions, Inc.

The module does not support authentication methods; operators implicitly assume an authorized role based on the service selected.

Descriptions of the services available to the authorized roles are provided in Table 9 below. The module is an integrated component of Ericsson’s NetCloud OS and offers crypto functions to applications and other kernel components installed on Cradlepoint devices. While the module includes implementations of nonApproved security functions that can be called by other Ericsson kernel modules, all such invocations will return failure codes to the caller. This effectively limits the service offerings to Approved services only. As allowed for this scenario per section 2.4.C of FIPS 140-3 Implementation Guidance, the module provides indicators for the use of Approved services through a combination of an explicit indication (via a Global Approved mode indicator) and an implicit indication (via the API return value of the service). The keys and Sensitive Security Parameters (SSPs) listed in the table indicate the type of access required using the following notation:

• G = Generate: The module generates or derives the SSP.
• R = Read: The SSP is read from the module (e.g., the SSP is output).
• W = Write: The SSP is updated, imported, or written to the module.
• E = Execute: The module uses the SSP in performing a cryptographic operation.
• Z = Zeroize: The module zeroizes the SSP. Table 9
• Approved Services Ericsson Cradlepoint Kernel Cryptographic Module ©2026 Ericsson Enterprise Wireless Solutions, Inc.

*Per FIPS 140-3 Implementation Guidance 2.4.C, the Show Status, Zeroize, and Show Versioning Information services do not require an Approved security **Triple-DES functionality is available only in version 1.0 of the module. The module does not support a non-Approved mode of operation and offers no non-Approved services.

20 IV – Initialization Vector

Ericsson Cradlepoint Kernel Cryptographic Module ©2026 Ericsson Enterprise Wireless Solutions, Inc.

5. Software/Firmware Security All software components within the cryptographic boundary are verified when they are loaded into memory during boot time using approved integrity techniques (refer to section 10.1 for details regarding the module’s integrity test techniques). The module implements an HMAC SHA2-256 for the integrity test of each module component; failure of a test will cause the kernel to panic, and the module will enter a critical error state. The module’s integrity check is performed automatically at module instantiation (i.e., when the module is loaded into memory for execution) without action from the module operator. The CO can initiate the pre-operational tests on demand by power-cycling the host platform or rebooting the OS. The Ericsson Cradlepoint Kernel Cryptographic Module is not delivered to end-users as a standalone offering. Rather, it is a pre-built integrated component of Ericsson’s solutions. Ericsson does not provide end-users with any mechanisms to directly access the module, its source code, its APIs, or any information sent to/from the module. Thus, end-users have no ability to independently load the module onto target platforms. No configuration steps are required to be performed by end-users, and no end-user action is required to initialize the module for operation. Ericsson Cradlepoint Kernel Cryptographic Module ©2026 Ericsson Enterprise Wireless Solutions, Inc.

6. Operational Environment The Ericsson Cradlepoint Kernel Cryptographic Module comprises a software cryptographic library that executes in a modifiable operational environment. The cryptographic module has control over its own SSPs. The process and memory management functionality of the host platform’s OS prevents unauthorized access to plaintext private and secret keys, intermediate key generation values and other SSPs by external processes during module execution. The module only allows access to SSPs through its well-defined API. The operational environment provides the capability to separate individual application processes from each other by preventing uncontrolled access to CSPs and uncontrolled modifications of SSPs regardless of whether this data is in the process memory or stored on persistent storage within the operational environment. Processes that are spawned by the module are owned by the module and are not owned by external processes/operators. Please refer to section 2.1 of this document for a list/description of the applicable operational environments. Ericsson Cradlepoint Kernel Cryptographic Module ©2026 Ericsson Enterprise Wireless Solutions, Inc.

7. Physical Security The cryptographic module is software module and does not include physical security mechanisms. Therefore, per ISO/IEC 19790:2021 section 7.7.1, requirements for physical security are not applicable. Ericsson Cradlepoint Kernel Cryptographic Module ©2026 Ericsson Enterprise Wireless Solutions, Inc.

8. Non-Invasive Security This section is not applicable. There are currently no approved non-invasive mitigation techniques referenced in ISO/IEC 19790:2021 Annex F. Ericsson Cradlepoint Kernel Cryptographic Module ©2026 Ericsson Enterprise Wireless Solutions, Inc.

Management Table 10 – SSPs The calling application (running outside the module’s cryptographic boundary) supports IPsec-v3. This application negotiates the protocol session’s keys and the value in the first 32 bits of the nonce, with the last 64 bits being deterministic. It relies on the cryptographic module to perform the AES GCM encryption for ESP within IPsec-v3. The AES GCM IV generation method complies with scenario #1 in FIPS 140-3 IG C.H. Ericsson Cradlepoint Kernel Cryptographic Module ©2026 Ericsson Enterprise Wireless Solutions, Inc.

The GCM IV construction is compliant with RFC 4106 and RFC 5282. The IV is only used in the context of the AES GCM mode encryption within the IPsec-v3 protocol. When the IV exhausts the maximum number of possible values for a given security association, either party to the security association that encounters this condition triggers a rekeying with IKEv2 to establish a new encryption key for the security association.

The module includes no DRBGs; it does not generate cryptographic keys or seeds for the generation of cryptographic keys.

There is no mechanism within the module’s cryptographic boundary for the persistent storage of SSPs. The module uses SSPs passed in on the stack by the calling application and does not store these SSPs beyond the lifetime of the API call.

As a software cryptographic module, there is no mechanism within the module boundary for the persistent storage of keys and CSPs. Maintenance, including protection and zeroization, of any keys and CSPs that exist outside the module’s cryptographic boundary is the responsibility of the end-user. The application that uses the module is responsible for appropriate destruction and zeroization of the key material. The module provides functions for key allocation and destruction, which overwrites the memory that is occupied by the key information with zeroes before it is deallocated. When a calling application calls the appropriate API function, that operation overwrites memory with zeroes and then frees that memory. Memory is automatically overwritten by zeroes when freeing the cipher handler. The following methods are available:

• crypto_free_cipher()
• key zeroization for single raw cipher handle
• crypto_free_ablkcipher()
• key zeroization method for asynchronous raw cipher handle
• crypto_free_blkcipher ()
• key zeroization method for synchronous raw cipher handle
• crypto_free_skcipher()
• key zeroization method for symmetric ciphers
• crypto_free_shash()
• key zeroization method for synchronous message digest handle

The module requires no entropy sources, as it does not implement an Approved DRBG. Ericsson Cradlepoint Kernel Cryptographic Module ©2026 Ericsson Enterprise Wireless Solutions, Inc.

10. Self-Tests Both pre-operational and conditional self-tests are performed by the module. Pre-operational tests are performed between the time the cryptographic module is instantiated and before the module transitions to the operational state. Conditional self-tests are performed by the module during module operation when certain conditions exist. The following sections list the self-tests performed by the module, their expected error status, and the error resolutions.

The module performs the following pre-operational self-tests:

• Software integrity test for the integrity test utility using an HMAC SHA2-256 digest
• Software integrity test for the FIT image file using an HMAC SHA2-256 digest
• Software integrity test for the ‘rc’ script file using an HMAC SHA2-256 digest When the kernel boots, the module begins to load. Upon loading, the module automatically executes the module’s cryptographic algorithm self-tests (CASTs). If all CASTs are successful, the module then executes the preoperational integrity tests by calling an ‘rc’ script that invokes the integrity test utility. This utility leverages the HMAC and SHA2-256 implementations from the bound module to compute one digest from the FIT file image, a second digest from its own image, and a third digest for the ‘rc’ script. The integrity test utility then compares the newly-computed digest values to the pre-computed digest values in order to make the determination of pass or fail. The HMAC and SHA2-256 implementations used by the module’s integrity test utility to verify to the module’s HMAC digest files are provided by the bound module operating in its Approved mode of operation. As required by FIPS 140-3, the HMAC and SHA KATs from the bound module are performed when the bound module is loaded for execution and prior to the primary module’s invocation of these algorithms for the integrity tests.

The module performs the following conditional self-tests:

• Conditional cryptographic algorithm self-tests (CASTs)
• AES CBC encrypt KAT21 (128-bit)
• AES CBC decrypt KAT (128-bit)
• AES ECB encrypt KAT (128-bit)
• AES ECB decrypt KAT (128-bit)
• AES GCM encrypt KAT (128-bit)
• AES GCM decrypt KAT (128-bit)
• HMAC KATs (SHA-1, SHA2-256, SHA2-384, SHA2-512)
• SHA-1 KAT
• SHA-2 KATs (SHA2-256, SHA2-384, SHA2-512)

21 KAT – Known Answer Test

Ericsson Cradlepoint Kernel Cryptographic Module ©2026 Ericsson Enterprise Wireless Solutions, Inc.

o Triple-DES CBC decrypt KAT (3-Key)22

Module operators can initiate the pre-operational self-tests and conditional CASTs on demand and for periodic testing of the module by power-cycling the host platform or rebooting the OS. This will again call the ‘rc’ script to perform the module’s CASTs and pre-operational integrity test using the HMAC and SHA implementations provided by the bound module.

Upon failure of any self-test, the module logs an error message to the kernel ring buffer and enters a critical error state. In this state, the kernel is panicked, and the module will not load; hence, the module will have no ability to perform cryptographic services or output data over the data output interfaces. Evidence of the failure can be observed by module operators by entering the ‘log’ command at the command line. To recover, the host platform must be rebooted or power-cycled. If the pre-operational self-tests complete successfully, then the module can resume normal operations. If the module continues to experience self-test failures after reinitializing, then the module will not be able to resume normal operations, and the CO should contact Ericsson Enterprise Wireless Solutions, Inc. for assistance.

22 Triple-DES self-tests are performed only in version 1.0 of the module.

Ericsson Cradlepoint Kernel Cryptographic Module ©2026 Ericsson Enterprise Wireless Solutions, Inc.

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

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

The module is an integrated component of Ericsson's proprietary NetCloud operating system and is pre-installed on Ericsson’s Cradlepoint devices prior to distribution to end-users; thus, no independent installation steps are required. Ericsson does not provide any mechanisms for end-users to directly access the module, its source code, its APIs, or any information sent between the module and the calling application.

This module is designed to support Ericsson devices; Ericsson's applications and kernel modules are the sole consumers of the cryptographic services provided by the module. No end-user action is required to initialize the module for operation; the calling application performs any actions required to initialize the module. The pre-operational integrity test and cryptographic algorithm self-tests are performed automatically when the module is loaded for execution, without any specific action from the calling application or the end-user. End-users have no means to short-circuit or bypass these actions. Failure of any of the initialization actions will result in a failure of the module to load for execution.

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

There are no specific management activities required of the CO role to ensure that the module runs securely. However, if any irregular activity is noticed or the module is consistently reporting errors, then Ericsson Enterprise Wireless Solutions, Inc. Customer Support should be contacted. The following list provides additional guidance for module administrators: Ericsson Cradlepoint Kernel Cryptographic Module ©2026 Ericsson Enterprise Wireless Solutions, Inc.

• The module outputs a mode indicator upon completion of the pre-operational self-test and CASTs. The CO can review this value to determine the module’s operational status. When the module is in the Approved mode, the CO will find the value “1” written in the file /proc/sys/crypto/fips_enabled. Otherwise, the file will contain “0” (or will not exist at all).
• The crypto_get_version() API command can be used to obtain the module’s versioning information. This information will include the module name and version, which can be correlated with the module’s validation record.

The following list provides additional policies for non-administrators: • In the event that power to the module is lost and subsequently restored, the calling application must ensure that any AES-GCM keys used for encryption or decryption are re-distributed. Ericsson Cradlepoint Kernel Cryptographic Module ©2026 Ericsson Enterprise Wireless Solutions, Inc.

12. Mitigation of Other Attacks This section is not applicable. The module does not claim to mitigate any attacks beyond the FIPS 140-3 Level 1 requirements for this validation. Ericsson Cradlepoint Kernel Cryptographic Module ©2026 Ericsson Enterprise Wireless Solutions, Inc.

Appendix A. Acronyms and Abbreviations Table 11 provides definitions for the acronyms and abbreviations used in this document. Table 11 – Acronyms and Abbreviations Ericsson Cradlepoint Kernel Cryptographic Module ©2026 Ericsson Enterprise Wireless Solutions, Inc.

Ericsson Cradlepoint Kernel Cryptographic Module ©2026 Ericsson Enterprise Wireless Solutions, Inc.

Prepared by: Corsec Security, Inc.

12600 Fair Lakes Circle, Suite 210

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