Edge Security Cryptographic Module

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for Edge Security 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>Firmware Load<br/>Update</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>UnAuth</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>IKEV<br/>IPSEC</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>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 Edge Security 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>Firmware Load<br/>Update</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>UnAuth</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>IKEV<br/>IPSEC</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>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

Ultra Intelligence and Communications Edge Security Cryptographic Module

This is a non-proprietary cryptographic module security policy for the Ultra Intelligence & Communications Edge Security Cryptographic Module with firmware version 1.0 (hereinafter called ESM or the Module). The module is validated at the FIPS 140-3 overall level 2.

Purpose and Use: The module primarily acts as a network boundary protection device by using IPsec VPN or VLAN encryption services. Furthermore, it employs firewall and industrial control protocol packet inspection to provide defense-in-depth capabilities to prevent malicious attacks. The module offers Web GUI management via HTTPS using TLS v1.2 or TLS v1.3. Module Type: Hardware Module Embodiment: MultiChipEmbed Module Characteristics: Cryptographic Boundary: The cryptographic boundary is defined as the entire chassis unit’s physical perimeter encompassing the "top," "front," "left," "right," “rear” and "bottom" surfaces of the case and shown in the figures below.

Figure 1: ESM Module Bottom J4 Connector (Ethernet Port 1) J3 Connector (Ethernet Port Figure 2: ESM Module Top

Tested Module Identification

• Hardware: Table 2: Tested Module Identification
• Hardware The module is a multiple-chip embedded hardware cryptographic module. The module’s operational environment is limited. The module’s firmware version is v1.0, and the module’s hardware version is v1.0.

The exposed electronic components (C16, R45, U11, C15, R46, R47, C18, C20, C21, C22, C23, C24, C27, R39, R40, R41, R44, R54 and TP4) in Figure 2 above are either capacitors or

resistors associated with the power supply circuitry. They are excluded from the physical security requirements as they are only power supply circuitry related (non-security relevant). Modes List and Description: Table 3: Modes List and Description approve mode or non-complaint state mode.

Table 4: Approved Algorithms Table 5: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: Non-Approved, Allowed Algorithms with No Security Claimed: Non-Approved, Not Allowed Algorithms:

Table 6: Security Function Implementations

There are some algorithm modes that were tested but not implemented by the module. Only the algorithms, modes, and key sizes that are implemented by the module are shown in section 2.5. Notes: • No parts of the TLS, SNMP and IKE protocols, other than the KDFs, have been tested by the CAVP and CMVP.

Table 7: Entropy Certificates Table 8: Entropy Sources

The module generates RSA, ECDSA, EC Diffie-Hellman, and Diffie-Hellman asymmetric key pairs compliant with FIPS 186-4, using a NIST SP 800-90Ar1 CTR DRBG for random number generation. In accordance with FIPS 140-3 IG D.H, the cryptographic module performs CKG for asymmetric keys as per section 5.1 of NIST SP 800-133rev2 (vendor affirmed) by obtaining a random bit string directly from an approved DRBG. The random bit string supports the required security strength requested by the calling application (without any V, as described in Additional Comments 2 of IG D.H).

The module provides the following key/SSP establishment services in the approved mode of operation:

• KAS-FFC Shared Secret Computation:
• The module provides SP800-56Arev3 compliant key establishment according to FIPS 140-3 IG D.F scenario 2 path (2) with KAS-FFC shared secret computation. The shared secret computation provides 112 bits of encryption strength.
• KAS-ECC Shared Secret Computation:
• The module provides SP800-56Arev3 compliant key establishment according to FIPS 140-3 IG D.F scenario 2 path (2) with KAS-ECC shared secret computation. The shared secret computation provides between 128 and 256 bits of encryption strength.

The module supports TLS 1.2/1.3, SNMPv3 and IPsec/IKEv2. The module also supports VLAN encryption. The encryption uses AES ECB/CBC with HMAC, or AES-CCM with key size of 128 or 256 bits. Please refer to SSPs Table for more information.

Table 9: Ports and Interfaces

The module supports Identity-based authentication mechanism. Each entity is authenticated by the module upon initial access to the module. There are four roles supported by the module: 3eLocal (Role: Crypto Officer), 3e-CyrptoOfficer (Role: Crypto Officer), 3e-Administrator (Role: User) and End User (Role: User), as detailed below. 3e-Local: This role is defined as a Crypto Officer role and performs all security functions provided by the module. This role performs cryptographic initialization and management functions (e.g., module initialization, input/output of cryptographic keys, audit functions and Operator account management). 3e-Local Role is responsible for managing (creating, deleting) 3e-CryptoOfficer role and 3e-Administrator role. 3e-CryptoOfficer: This role is defined as a Crypto Officer role and inherits all 3e-Local privileges except the ability to create and manage users locally. 3e-Administrator: This role is defined as a User role performs general module configuration. No security management functions are available to the Administrator. The Administrator can also reboot the module if deemed necessary. The Administrator authenticates to the module using a username and password. All Administrators are identical, i.e., they have the same set of services available. End User: This role is defined as a User role and sets up VPN tunnel using IKEv2 to the module and send or receive data to and from the module. End User Role can only use the cryptographic service but cannot configure the device. The End User role is authenticated via its digital certificate and its knowledge of the corresponding private key. The module does not support concurrent operator service.

The module also supports the firmware load test by using RSA 4096 bits with SHA2-256 (RSA Cert. #A3316) for the new validated firmware to be uploaded into the module. A Firmware Load Test Key was preloaded to the module’s binary at the factory and used for firmware load test. In order to load new firmware, the Crypto Officer must authenticate to the module before loading the firmware. This ensures that unauthorized access and use of the module is not performed. The module will load the new update upon reboot. The update attempt will be rejected if the verification fails. Any firmware loaded into the module that is not shown on the module certificate, is out of scope of this validation and requires a separate FIPS 140-3 validation.

The module supports Unauthenticated service, where the unauthenticated users can run the self-test service by power-cycling the module.

The module is provided in the form of binary executable code (Module’s binary file name?). To ensure the software security, the module is digitally signed with RSA 4096 bits with SHA2-256 (RSA Cert. #3316) during the Pre-Operational Self-Test. A Firmware Integrity Test Key (nonSSP) was preloaded to the module’s binary at the factory and used for firmware integrity test only at the pre-operational self-test. The module uses the RSA 4096 bits modulus public key to verify the digital signature. If the firmware integrity test fails, the module would enter to an Error state with all crypto functionality inhibited.

Integrity test is performed as part of the Pre-Operational Self-Tests. It is automatically executed at power-on. The authorized operator can initiate the firmware integrity test on-demand via Web GUI’s reboot command or power cycling.

Type of Operational Environment: Limited Not Applicable as the module is operated in a limited modifiable operational environments and the physical security (section 7) is level 2. The module’s Operational Environment is limited as the module implements the firmware load service to support necessary updates.

Mechanism

Inspection Frequency

Inspection Guidance an attempt of removal; Tracking numbers do not match those recorded. In addition, Please note that the TELs are not orderable. Please contact support@ultra-3eti.com for more information.

Table 13: Mechanisms and Actions Required

Two tamper evidence labels (TELs) are applied at Vendor’s factory, one on each side of the Number: 2 Placement: Please refer to the TELs placement below.

Surface Preparation: N/A Operator Responsible for Securing Unused Seals: N/A Part Numbers: N/A 3e-CryptoOfficer is responsible for checking the integrity of the label by following the guidance listed above. In case of notification of tamper evidence, the 3e-CryptoOfficer shall not power on this module and shall contact 3eTI for factory repair. Any deviation of the TELs placement by unauthorized operators such as tearing, misconfiguration, removal, change, replacement or any other change in the TELs from its original configuration shall mean the module is no longer in the Approved mode of operation.

The module claims no non-invasive security techniques.

m ) ) ) ) Table 15: SSP Input-Output Methods

Table 16: SSP Zeroization Methods

1. The zeroization operations shall be performed under the control of the Crypto Officer role (3e-Local Role or 3e-CyrptoOfficer role).
2. To initiate zeroization, see Section End of Life / Sanitization in this document for more details.
3. The zeroized SSPs cannot be retrieved or reused. Once the command is initiated, the SSPs are overwritten with 0s.

Name

Input - Output Input via TLS- KTS (AES and HMAC)

Storage

Storage Duration

Zeroizatio n

Related SSPs

Table 19: Pre-Operational Self-Tests The module also performs the following Cryptographic Algorithm Self-Tests (CASTs), which can be initiated by rebooting the module. All self-tests run without operator intervention. In the event that a self-test fails, the module will enter an error state until the issue is resolved. Upon self-test failure, the module will go into the SYS_HALT status. Entropy start-up tests per SP800-90B section 4.2 including Repetition Count Test and Adaptive Proportion Test are performed at device power-on and it will run continuously. Any entropy test failures will cause SYS_HALT.

Table 20: Conditional Self-Tests The module also performs the following Entropy start-up tests per SP800-90B section 4.2 including Repetition Count Test and Adaptive Proportion Test are performed at device power-on and it will run continuously. Any entropy test failures will cause SYS_HALT.

• Entropy Source Health Tests:
• SP800-90B Entropy Source Start-up Health Tests:  Repetition Count Test (RCT)  Adaptive Proportion Test (APT)
• SP800-90B Entropy Source Continuous Health Tests:  Repetition Count Test (RCT)  Adaptive Proportion Test (APT)

256 (RSA Cert. #A3316) for the new validated firmware to be uploaded into the module. A

Firmware Load Test Key was preloaded to the module’s binary at the factory and used for firmware load test. In order to load new firmware, the Crypto Officer must authenticate to the

module before loading the firmware. This ensures that unauthorized access and use of the module is not performed. The module will load the new update upon reboot. The update attempt will be rejected if the verification fails.

Table 21: Pre-Operational Periodic Information

Table 22: Conditional Periodic Information The module performs on-demand self-tests initiated by the operator, by power cycling to the module. The full suite of self-tests is then executed. The same procedure may be employed by the operator to perform periodic self-tests. In addition, the Crypto Officer shall perform the periodic test on demand no less than every 90 days to ensure all components are functioning correctly.

Table 23: Error States If any of the above-mentioned self-tests fail, the module reports the cause of the error and enters the Error state. In the Error State, no cryptographic services are provided, and data output is prohibited. The only method to recover from the error state is to reboot the module and perform the self-tests, including the pre-operational firmware integrity test and the conditional CASTs. The module will only enter into the operational state after successfully passing the preoperational firmware integrity test and the conditional CASTs.

The module operates in the approved mode of operation at all times. The 3e-Local shall properly configure the module following the steps listed below:

1. Log in the module over HTTPS and change the default password (if this is the first time of use).
2. Configure the Management VPN tunnel with proper CSPs, such as certificate, private key, trust anchor and key expiration time.

3. If the external authentication server is employed, please use TLS v1.2 or TLS v1.3 or IPSec/IKEv2 to protect the traffic between the authentication server and the module.
4. Configure the Data VPN tunnel with proper SSPs, such as certificate, private key, trust anchor and key expiration time. Or configure the VLAN encryption services with VLAN tag, authentication key and encryption key.
5. Verify that the module is in the approved mode of operation from the Web GUI. After configuration of the above items, reboot the device and the device will come back in full approved mode of operation. Security Rules: The module meets all the Level 2 requirements for FIPS 140-3. Follow the secure operations provided below to place the module in the approved mode. Operating this module without maintaining the following settings will remove the module from the approved mode of operation. The module runs firmware version 1.0. This is the only allowable firmware image (cn9130-cffips.ipsec.6.0.0.00.6.bin) for this current approved mode of operation. The 3e-Local shall load the CMVP FIPS 140-3 validated firmware only to maintain validation. The following module security rules must be followed by the operator to ensure secure operation:
6. The 3e-Local shall not share any SSPs used by the module with any other operator or entity.
7. The 3e-Local is responsible for inspecting the tamper evidence tapes. Other signs of tamper include wrinkles, tears and marks on or around the tape.
8. The 3e-Local shall change the default password (default username: CryptoOfficer; default password: CryptoFIPS) when configuring the module for the first time. Please note that the module firmware enforces the password change upon the 3e-Local first log in.
9. The 3e-Local shall login to make sure CSPs and keys are configured and applied in the module.

No specific Administrator guidance.

No specific non-Administrator guidance.

Crypto Officer (3e-Local Role and 3e-CyrptoOfficer role) should follow the steps below for the secure destruction of the module: Note: This process will cause the module to no longer function after it has wiped all configurations and keys.

1. Access the module via HTTPS over TLS v1.2 or TLS v1.3
2. Authenticate to the module as the CO by using the proper credentials
3. Execute zeroization service: “Factory Default” a. Confirm command

4. Module will begin zeroization process and wipe all security parameters and configurations

Not Applicable as the module does not claim mitigation of other attacks.