IP-20G, IP-20C, IP-20S, IP-20C-HP, IP-20N, IP-20A, IP-50C, IP-50E

Certificate

Approved Algorithms (35)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for IP-20G, IP-20C, IP-20S, IP-20C-HP, IP-20N, IP-20A, IP-50C, IP-50E
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C1["[high] Firmware / bootloader<br/>versions disclosed<br/>(identity, not provenance)<br/><i>Release 12.0.1</i>"]
    C2["[high] Firmware update / recovery<br/>/ rollback services<br/><i>Change Password</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Show Status</i>"]
    C4["[high] Physical/logical<br/>interfaces (some 'blocked<br/>in firmware')<br/><i>(1x) ACT LED (1x) RJ45 External Alarms</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>IKEV</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"]
    I1["Component identity is<br/>disclosed, but provenance<br/>and patch lineage are not."]
    I2["Trusted code is reachable<br/>through update and<br/>recovery paths."]
    I3["Some services may process<br/>input before, or without,<br/>operator authentication."]
    I4["Interface reachability may<br/>vary by boot stage and<br/>lifecycle state."]
    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"]
    R1["Do the vendor version<br/>strings obscure the<br/>upstream baseline, fork<br/>lineage, or known-CVE<br/>exposure?"]
    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?"]
    R4["Are interfaces blocked<br/>before the bootloader<br/>runs, or only after<br/>approved mode starts?"]
    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"]
    E1["SBOM / component baselines<br/>· patch and backport<br/>manifest · CVE disposition"]
    E2["update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E4["lifecycle reachability<br/>matrix · boot-stage<br/>interface timing ·<br/>factory/recovery/error-state<br/>access controls"]
    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
  C1 --> I1 --> R1 --> E1
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C4 --> I4 --> R4 --> E4
  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 C1,C2,C3,C4,C5,C6 clue;
  class I1,I2,I3,I4,I5,I6 infer;
  class R1,R2,R3,R4,R5,R6 risk;
  class E1,E2,E3,E4,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for IP-20G, IP-20C, IP-20S, IP-20C-HP, IP-20N, IP-20A, IP-50C, IP-50E
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C1["[high] Firmware / bootloader versions disclosed (identity, not provenance)<br/><i>Release 12.0.1</i><br/>src: certificate.firmwareVersions"]
    C2["[high] Firmware update / recovery / rollback services<br/><i>Change Password</i><br/>src: securityPolicy.services"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Show Status</i><br/>src: securityPolicy.services"]
    C4["[high] Physical/logical interfaces (some 'blocked in firmware')<br/><i>(1x) ACT LED (1x) RJ45 External Alarms</i><br/>src: securityPolicy.portsAndInterfaces"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<br/>IKEV</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 C1,C2,C3,C4 clueHigh;
  class C5,C6 clueLow;

Security Policy, page by page

Ceragon Networks IP-20G, IP-20C, IP-20S, IP-20C-HP, IP-20N, IP-20A, IP-50C, IP-50E Firmware: 12.0.1 Hardware: IP-20N and IP-20A, with TEL P/N: BS-0341-2 and with components:

• IP-20 TCC-B2-XG-MC: N000082H003
• IP-20 TCC-U: N000082H005
• IP-20 RMC-B: N000082H004 IP-20G, IP-20C, IP-20S, IP-20C-HP, IP-50C and IP-50E (Rev. 6) Prepared by: Acumen Security

Rockville, MD 20850 www.acumensecurity.net

Ceragon Networks Ltd. assumes no liability resulting from any inaccuracies or omissions in this document, or from use of the information obtained herein. Ceragon reserves the right to make changes to any products described herein to improve reliability, function, or design, and reserves the right to revise this document and to make changes from time to time in content hereof with no obligation to notify any person of revisions or changes. Ceragon does not assume any liability arising out of the application or use of any product, software, or circuit described herein; neither does it convey license under its patent rights or the rights of others. It is possible that this publication may contain references to, or information about Ceragon products (machines and programs), programming, or services that are not announced in your country. Such references or information must not be construed to mean that Ceragon intends to announce such Ceragon products, programming, or services in your country. This document, Ceragon products, and 3rd Party software products described in this document may include or or other media. Laws in the United States and other countries preserve for Ceragon, its licensors, and other 3rd products described in this document may not be copied, reproduced, reverse engineered, distributed, merged or modified in any manner without the express written permission of Ceragon. Furthermore, the purchase of Ceragon products shall not be deemed to grant either directly or by implication, estoppel, or otherwise, any except for the normal non-exclusive, royalty free license to use that arises by operation of law in the sale of a product. Restrictions of the software or documentation may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any language or computer language, in any form or by any means, without prior written permission of Ceragon. License Agreements The software described in this document is the property of Ceragon and its licensors. It is furnished by express license agreement only and may be used only in accordance with the terms of such an agreement. High Risk Materials Ceragon and its supplier(s) specifically disclaim any express or implied warranty of fitness for any high-risk activities or uses of its products including, but not limited to, the operation of nuclear facilities, aircraft navigation or aircraft communication systems, air traffic control, life support, or weapons systems (“High Risk Use”). Any High Risk is unauthorized, is made at your own risk and you shall be responsible for any and all losses, damage or claims arising out of any High-Risk Use. Ceragon Networks Ltd. © 2025 Version 0.1 Public Material

• May be reproduced only in its original entirety (without revision).

List of Figures Ceragon Networks Ltd. © 2025 Version 0.1 Public Material

• May be reproduced only in its original entirety (without revision).

Introduction This is a non-proprietary FIPS 140-3 Security Policy for Ceragon Networks Ltd. and the following Ceragon Networks products: IP-20G, IP-20C, IP-20S, IP-20C-HP, IP-20N, IP-20A, IP-50C, and IP-50E. Below are the details of the certified products: Hardware Version #:

• IP-20N and IP-20A, with TEL P/N: BS-0341-2 and with components:
• IP-20 TCC-B2-XG-MC: N000082H003
• IP-20 TCC-U: N000082H005
• IP-20 RMC-B: N000082H004 IP-20G, IP-20C, IP-20S, IP-20C-HP, IP-50C, and IP-50E (Rev. 6) Firmware Version #: 12.0.1 FIPS 140-3 Security Level: 2 Purpose This document was prepared as part of the Federal Information Processing Standard (FIPS) 140-3 validation process. The document describes how the Ceragon Networks IP-20G, IP-20C, IP-20S, IP-20CHP, IP-20N, IP-20A, IP-50C and IP-50E meet the security requirements of FIPS 140-3. It also provides instructions to individuals and organizations on how to deploy the product in a secure Approved mode of operation. The target audience of this document is anyone who wishes to use or integrate any of these products into a solution that is meant to comply with FIPS 140-3 requirements. Document Organization The Security Policy document is one document in a FIPS 140-3 Submission Package. In addition to this document, the Submission Package contains: Vendor Evidence document Finite State Machine Other supporting documentation as additional references This Security Policy and the other validation submission documentation were produced by Acumen Security, LLC. under contract to Ceragon Networks. With the exception of this Non-Proprietary Security Policy, the FIPS 140-3 Submission Package is proprietary to Ceragon Networks and is releasable only under appropriate non-disclosure agreements. Ceragon Networks Ltd. © 2025 Version 0.1 Public Material
• May be reproduced only in its original entirety (without revision).

1. The Ceragon Networks IP-20G, IP-20C, IP-20S, IP-20C-HP, IP-20N, IP-20A, IP-50C and IP-50E (the module) are multi-chip standalone hardware modules validated at FIPS 140-3 Security Level
2. Specifically, the modules meet that following security levels for individual sections in FIPS 140-3 standard: N/A N/A N/A Table 1 - Security Levels
3. The IP-20 and IP-50 series radios provide a service-centric microwave platform for HetNet1 hauling. The platform includes a full complement of wireless products that provide backhaul and fronthaul solutions. Powered by a software-defined engine and sharing a common operating system, IP-20 and IP-50 Release 12.0.1, the IP-20 and IP-50 platforms deliver ultra-high capacities while supporting any radio transmission technology, any network topology, and any deployment configuration. 2.1 Cryptographic Boundary The cryptographic boundary for the modules is defined as encompassing the "top," "front," "left," "right," and "bottom" surfaces of the case and all portions of the "backplane" of the case. The following figures provide a physical depiction of the cryptographic modules: Heterogenous Network Ceragon Networks Ltd. © 2025 Version 0.1 Public Material – May be reproduced only in its original entirety (without revision).

Figure 1

• IP-20G Figure 2
• IP-20C Figure 3
• IP-20S Ceragon Networks Ltd. © 2025 Version 0.1 Public Material
• May be reproduced only in its original entirety (without revision).

Figure 4

• IP-20C-HP Figure 5
• IP-20N and IP-20A Figure 6
• IP-50C Ceragon Networks Ltd. © 2025 Version 0.1 Public Material
• May be reproduced only in its original entirety (without revision).

Figure 7

• IP-50E (Rev. 6) The IP-20G, IP-20C, IP-20S, IP-20C-HP, IP-50C and IP-50E are fixed configuration. The IP-20N and IP-20A are modular configuration, and have slots to insert the following cards:
• Traffic and Control Card (TCC): The Traffic Control Card (TCC) provides the control functionality for the IP-20N and IP-20A units. It also provides Ethernet management and traffic interfaces. There are two variants of this card:
• IP-20 TCC-B2-XG-MC: N000082H003: Required for Multi-Carrier ABC configurations. Provides

2 x FE Ethernet management interfaces, 2 x GbE optical interfaces, 2 x GbE electrical

interfaces, and 2 x dual mode electrical or cascading interfaces.

• IP-20 TCC-U: N000082H005: Provides 6 x 1/10GE optical interfaces and 2 x RFU or 1/2.5 GbE electrical PoE interfaces. Two of the optical interfaces (1 and 2) can be configured as cascading interfaces. Supports up to two Multi-Carrier ABC groups, with capacity of 2.5 Gbps (nonconfigurable). Supports multiple high-capacity configurations with Link Bonding.
• Radio Modem Card-B (IP-20 RMC-B: N000082H004): The Radio Modem Card (RMC) provides the modem interface between the Indoor Unit (IDU) and the Radio Frequency Unit (RFU). The models included in this validation have been tested in the following configurations: Indoor unit Outdoor unit Ceragon Networks Ltd. © 2025 Public Material
• May be reproduced only in its original entirety (without revision).

o o o

• Table 2 - Cryptographic Module Tested Configuration Additionally, the following cards can be configured on IP-20N and IP-20A modules. These cards provide port density, but do not contain any security-relevant functionality:
• 2.2 Ethernet/Optical Line Interface Card (E/XLIC) STM-1/OC3 STM-1 RST TDM E1/T1 10Gb Ethernet/Optical Line Interface Card (LIC-X-E10) Radio Interface Card (RIC-D) Modes of Operation The module operates in the Approved mode of operation (when configured as per the instructions in Section 11 of this document). Any usage of the non-Approved services described in Table 17 would result in a non-Approved mode of operation. 2.3 Cryptographic Algorithms The following table lists the Approved algorithms supported by the modules: Ceragon Networks Ltd. © 2025 Public Material
• May be reproduced only in its original entirety (without revision).

d HMACSHA1 GCM IV generation tested in accordance with IG C.H, scenario 1 TLSv1.2 following RFCs 5516, 5246, 5288, and

5289 as well as SSH following RFCs 4251, 4252, 4253, 4254 and 5647. The IV is generated only for use with GCM

encryption within the protocol being used. The TLS cipher suites supported by the module are identified in section

11.4.2 of this document which are included in SP 800-52 Rev2 section 3.3.1. The module also internally generates

IVs for TLS 1.3 (RFC 8446) in accordance with scenario 5 in IG C.H. In the case the module’s power is lost and then restored, a new key for use with AES-GCM encryption/decryption is established. Ceragon Networks Ltd. © 2025 Version 0.1 Public Material

• May be reproduced only in its original entirety (without revision).

d HMACSHA2-256 HMACSHA2-384 HMACSHA2-512 (SP80090Arev1) Ceragon Networks Ltd. © 2025 Version 0.1 Public Material

• May be reproduced only in its original entirety (without revision).

d Ceragon Networks Ltd. © 2025 Version 0.1 Public Material

• May be reproduced only in its original entirety (without revision).

d Ceragon Networks Ltd. © 2025 Version 0.1 Public Material

• May be reproduced only in its original entirety (without revision).

d Ceragon Networks Ltd. © 2025 Version 0.1 Public Material

• May be reproduced only in its original entirety (without revision).

d Ceragon Networks Ltd. © 2025 Version 0.1 Public Material

• May be reproduced only in its original entirety (without revision).

d Ceragon Networks Ltd. © 2025 Version 0.1 Public Material

• May be reproduced only in its original entirety (without revision).

Vendoraffirmed d KAS-FFCSSC (SP80056arev3) DiffieHellman KAS-ECCSSC (SP80056arev3) (SP800135-r1) SP800133rev2 Note that no parts of the SSH, SNMPv3, IKEv1 and TLS protocols, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP. In accordance with FIPS 140-3 IG D.H, the cryptographic module performs Cryptographic Key Generation (CKG) as per SP 800-133r2 (vendor affirmed). The resulting generated symmetric keys and the seed used in the asymmetric key generation are the unmodified output from an NIST SP 800-90A DRBG. Ceragon Networks Ltd. © 2025 Version 0.1 Public Material

• May be reproduced only in its original entirety (without revision).

d (SP800SNMPv3 HMACSHA2-256 Ceragon Networks Ltd. © 2025 Version 0.1 Public Material

• May be reproduced only in its original entirety (without revision).

d Table 3

• Approved Algorithms *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. Only the algorithms, modes/methods, and key lengths/curves/moduli shown in this table are used by an approved service of the module. Table 4
• Non-Approved Algorithms Not Allowed in the Approved Mode of Operation 3. Cryptographic Module Interfaces The modules provide a number of physical ports/logical interfaces to the device, and the physical ports provided by the module are mapped to four FIPS 140-3 defined logical interfaces: data input, data output, Ceragon Networks Ltd. © 2025 Version 0.1 Public Material
• May be reproduced only in its original entirety (without revision).

the following diagrams/tables: Figure 8

• IP-20G Physical Ports Note that only one FE interface appears in the figure. With the addition of a Y-connector, the single port can be used to provide two FE interfaces. Ceragon Networks Ltd. © 2025 Version 0.1 Public Material
• May be reproduced only in its original entirety (without revision).

N/A Table 5

• IP-20G Ports and Interfaces Figure 9
• IP-20C Physical Ports Ceragon Networks Ltd. © 2025 Version 0.1 Public Material
• May be reproduced only in its original entirety (without revision).

N/A Table 6

• IP-20C Ports and Interfaces Ceragon Networks Ltd. © 2025 Version 0.1 Public Material
• May be reproduced only in its original entirety (without revision).

Figure 10

• IP-20S Physical Ports N/A Table 7
• IP-20S Ports and Interfaces Ceragon Networks Ltd. © 2025 Version 0.1 Public Material
• May be reproduced only in its original entirety (without revision).

Figure 11

• IP-20C-HP Physical Ports Ceragon Networks Ltd. © 2025 Version 0.1 Public Material
• May be reproduced only in its original entirety (without revision).

N/A Table 8

• IP-20C-HP Ports and Interfaces Figure 12
• IP-20 TCC-U: N000082H005 (IP-20N and IP-20A) Physical Ports Ceragon Networks Ltd. © 2025 Version 0.1 Public Material
• May be reproduced only in its original entirety (without revision).

Table 9

• IP-20 TCC-U: N000082H005 (IP-20N and IP-20A) Ports and Interfaces Figure 13
• IP-20 TCC-B2-XG-MC: N000082H003 (IP-20N and IP-20A) Physical Ports Note that only one FE interface appears in the figure. With the addition of a Y-connector, the single port can be used to provide two FE interfaces. Ceragon Networks Ltd. © 2025 Version 0.1 Public Material
• May be reproduced only in its original entirety (without revision).

Table 10 –IP-20 TCC-B2-XG-MC: N000082H003 (IP-20N and IP-20A) Ports and Interfaces Figure 14

• IP-20 RMC-B: N000082H004 (IP-20N and IP-20A) Physical Ports Table 11
• IP-20 RMC-B: N000082H004 (IP-20N and IP-20A) Ports and Interfaces Ceragon Networks Ltd. © 2025 Version 0.1 Public Material
• May be reproduced only in its original entirety (without revision).

Figure 15

• IP-50C Physical Ports9 The WiFi port is disabled. Ceragon Networks Ltd. © 2025 Version 0.1 Public Material
• May be reproduced only in its original entirety (without revision).

N/A Table 12

• IP-50C Ports and Interfaces Ceragon Networks Ltd. © 2025 Version 0.1 Public Material
• May be reproduced only in its original entirety (without revision).

Figure 16

• IP-50E Physical Ports Ceragon Networks Ltd. © 2025 Version 0.1 Public Material
• May be reproduced only in its original entirety (without revision).

N/A N/A Table 13

• IP-50E Ports and Interfaces 4. Roles, services, and authentication The following sections provide details about roles supported by the module, how these roles are authenticated, and the services the roles are authorized to access. 4.1 Authorized Roles The module supports several different roles, including multiple Cryptographic Officer roles and a User Configuration of the module can occur over several interfaces and at different levels depending upon the role assigned. There are multiple levels of access for a Cryptographic Officer as follows:
• Security Officer, admin, SNMP User: Entities assigned this privilege level have complete access to configure and manage the module.
• Tech, Operator, Viewer: These entities have more limited access to manage the module. For example, they can only manage the configuration of the data traffic interface. The Users of the module are the remote peers to and from which backhaul traffic is transmitted. The Users are connected over a secure session protected using the Session keys. The Session keys are established from the remote peer using the Master Key to encrypt them. Successful decryption of the Session keys by the module, authenticates the User to the module. The CO is responsible for configuring the Master Key and the User role to pass encrypted data. Once the User is authenticated to the module, encrypted data can be transferred to and from the remote peer. If the CO does not configure the data-path for encryption, the User can still send un-encrypted data (bypass mode). The following table specifies roles, with corresponding service with input and output: Ceragon Networks Ltd. © 2025 Version 0.1 Public Material
• May be reproduced only in its original entirety (without revision).

Perform SelfTests N/A N/A N/A N/A N/A Ceragon Networks Ltd. © 2025 Version 0.1 Public Material

• May be reproduced only in its original entirety (without revision).

4.2 Authentication Mechanisms before being allowed access to services, which requires the assumption of an authorized role. The module employs the authentication methods described in the table below to authenticate Crypto-Officers and Unauthenticated users are only able to access the module LEDs and power cycle the module. Ceragon Networks Ltd. © 2025 Version 0.1 Public Material

• May be reproduced only in its original entirety (without revision).

Table 15

• Roles and Authentication 4.3 Services The services (approved and non-approved) that require operators to assume an authorized role (CryptoOfficer or User) as well as unauthenticated services are listed in the tables below. The module supports when the module is in the non-Approved mode. Please note that the keys and Sensitive Security Parameters (SSPs) listed below use the following indicators to show the type of access required:
• G = Generate: The module generates or derives the SSP. R = Read: The SSP is read from the module (e.g. the SSP is output). E = Execute: The module uses the SSP in performing a cryptographic operation. initiate ondemand (via powercycle) Perform SelfTests N/A s N/A N/A N/A N/A N/A N/A N/A N/A (R/W) N/A Ceragon Networks Ltd. © 2025 Version 0.1 Public Material
• May be reproduced only in its original entirety (without revision).

KAS-ECCline KAS-ECCSSC KAS-FFCSSC s (R/W/Z) (R/W/Z) (R/W/Z) (R/W/Z) (R/W/Z) Ceragon Networks Ltd. © 2025 Version 0.1 Public Material

• May be reproduced only in its original entirety (without revision).

SNMPv3based AESCFB128 (Selfinitiated KAS-FFCSSC s (G/E/Z) (G/E/Z) (G/E/Z) (R/W/Z) (R/W/Z) (R/W/Z) (R/W/Z) (R/W/Z) (R/W) (R/W/Z) (R/W/Z) Only available on MIPS CPU based models Ceragon Networks Ltd. © 2025 Version 0.1 Public Material

• May be reproduced only in its original entirety (without revision).

s N/A N/A N/A (Z) (Z) (Z) (Z) Ceragon Networks Ltd. © 2025 Version 0.1 Public Material

• May be reproduced only in its original entirety (without revision).

s N/A N/A N/A n, N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Ceragon Networks Ltd. © 2025 Version 0.1 Public Material

• May be reproduced only in its original entirety (without revision).

N/A N/A N/A s N/A N/A N/A N/A N/A N/A Table 16

• Approved Services N/A N/A N/A N/A N/A N/A Table 17
• Non-Approved Services 5. Software/Firmware Security The module performs a Firmware Integrity Test using a 160-bit error detection code (EDC) at power-on. If the EDC fails to compute properly, the module enters a hard error state where all cryptographic functions are disabled. Repeated failures of the integrity test will result in a reset to the factory default state. The integrity test may be performed on-demand by power-cycling the module. The module also performs a firmware load test (RSA 4096 with SHA2-256) covering the entire binary image, when a new FW is uploaded to the module. The signature is calculated and verified upon uploading of the new FW. If the test fails, the image will be discarded. Ceragon Networks Ltd. © 2025 Version 0.1 Public Material
• May be reproduced only in its original entirety (without revision).

6. Operational Environment FIPS 140-3 Operational Environment requirements are not applicable since the module is a hardware module with a limited operational environment. The module runs Release 12.0.1 which includes Wind River Linux 4.1.0 or 4.14 depending on the CPU architecture.
7. The appliances have a multi-chip standalone embodiment. The appliances are contained in a hard metal chassis, which is defined as the cryptographic boundary of the module. The appliances’ chassis is opaque within the visible spectrum. The enclosure of the appliances have been designed to satisfy Level 2 physical security requirements. Each of the appliances needs Tamper Evidence Labels (TELs) to meet Security Level 2 requirements. These labels are installed (as seen in the respective model images) at the factory before delivery to the customer, for the IP-20G, IP-20C, IP-20S, IP-20C-HP, IP-50C and IP-50 E. For IP-20N and IP-20A, the CO must place the twenty (20) TELs according to Figure 21-24 (below). The preparation instructions of the module prior to installation of the tamper seals are as follows: • Use caution to avoid touching the adhesive in such a way as to leave fingerprints and damage • The curing time (drying time) for the labels is at least sixty minutes. • The labels must be replaced whenever cards are added to or removed from the unit. Replacement labels can be ordered from Ceragon Networks, part number BS-0341-2. • When replacing a label, gently cut the label, replace the module, and apply a new label in place The extra tamper seals shall be in possession of the CO at all times. The CO shall observe any changes to the module such as reconfigurations where the tamper evident seals are removed or installed to ensure the security of the module is maintained during such changes and the module is returned to an Approved mode of operation. The Crypto Officer shall periodically (defined by organizational security policy, recommendation is once a month) monitor the state of all applied TELs for evidence of tampering. If tamper is detected, the CO must take the device out of commission, inspect it and if deemed safe, return it to the Approved state. Table 18 – Physical Security Inspection Guidelines Ceragon Networks Ltd. © 2025 Version 0.1 Public Material – May be reproduced only in its original entirety (without revision).

Figure 17

• IP-20G TEL Application Locations Ceragon Networks Ltd. © 2025 Version 0.1 Public Material
• May be reproduced only in its original entirety (without revision).

Ceragon Networks Ltd. © 2025 Version 0.1 Public Material

• May be reproduced only in its original entirety (without revision).

Figure 18

• IP-20C TEL Application Locations Ceragon Networks Ltd. © 2025 Version 0.1 Public Material
• May be reproduced only in its original entirety (without revision).

Figure 19

• IP-20C-HP TEL Application Locations Ceragon Networks Ltd. © 2025 Version 0.1 Public Material
• May be reproduced only in its original entirety (without revision).

Ceragon Networks Ltd. © 2025 Version 0.1 Public Material

• May be reproduced only in its original entirety (without revision).

Ceragon Networks Ltd. © 2025 Version 0.1 Public Material

• May be reproduced only in its original entirety (without revision).

Figure 20

• IP-20S TEL Application Locations Ceragon Networks Ltd. © 2025 Version 0.1 Public Material
• May be reproduced only in its original entirety (without revision).

Figure 21

• IP-20N and IP-20A Bottom Figure 22
• IP-20N and IP-20A Front Ceragon Networks Ltd. © 2025 Version 0.1 Public Material
• May be reproduced only in its original entirety (without revision).

Figure 23

• IP-20N and IP-20A Top Figure 24
• IP-20N and IP-20A Back Ceragon Networks Ltd. © 2025 Version 0.1 Public Material
• May be reproduced only in its original entirety (without revision).

Figure 25

• IP-50C/IP-50E TEL Application Locations Ceragon Networks Ltd. © 2025 Version 0.1 Public Material
• May be reproduced only in its original entirety (without revision).

8. Non-invasive Security FIPS 140-3 Non-invasive Security requirements are not applicable. Ceragon Networks Ltd. © 2025 Version 0.1 Public Material

• May be reproduced only in its original entirety (without revision).

9. Sensitive security parameter management N/A N/A N/A N/A N/A N/A N/A Use & related keys N/A Zeroisation N/A Storage N/A Establishment Import/Export Strength Key/SSP Name/Type Security Function and Cert. Number The following table identifies each of the Keys/SSPs associated with the modules:

N/A N/A 80056Arev3 SP 80056Arev3 N/A N/A SP 80056Arev3 N/A N/A 0.1 Use & related keys Zeroisation Storage Import/Export Generation Security Function and Cert. Number Key/SSP Name/Type Ceragon Networks Ltd. © 2025 Public Material

• May be reproduced only in its original entirety (without revision). Version

SP 80056Arev3 N/A SP 80056Arev3 N/A N/A RSA 2048bit N/A 0.1 Use & related keys Zeroisation Storage Import/Export Generation Security Function and Cert. Number Key/SSP Name/Type Ceragon Networks Ltd. © 2025 Public Material

• May be reproduced only in its original entirety (without revision). Version

N/A 800135rev1 N/A N/A N/A N/A N/A 800135rev1 N/A 800135rev1 0.1 Use & related keys Establishment N/A Zeroisation Import/Export Storage Generation or 256bits Strength Key/SSP Name/Type Security Function and Cert. Number Ceragon Networks Ltd. © 2025 Public Material

• May be reproduced only in its original entirety (without revision). Version

N/A 800135rev1 N/A N/A N/A N/A N/A RSA 2048bit RSA 2048bit KAS-FFCSSC, N/A N/A 0.1 SP 80056Arev3 Use & related keys Establishment N/A Zeroisation Import/Export Storage Generation Strength Key/SSP Name/Type Security Function and Cert. Number Ceragon Networks Ltd. © 2025 Public Material

• May be reproduced only in its original entirety (without revision). Version

N/A 800135rev1 or 384bits N/A N/A 800135rev1 HMAC SHA1, SHA2256, SHA2384 N/A N/A 800135rev1 N/A N/A 800135rev1 0.1 Use & related keys Establishment N/A Zeroisation Import/Export Storage Generation Strength Key/SSP Name/Type Security Function and Cert. Number Ceragon Networks Ltd. © 2025 Public Material

• May be reproduced only in its original entirety (without revision). Version

N/A 0.1 N/A N/A N/A 800135rev1 N/A N/A 800135rev1 N/A Use & related keys Zeroisation Storage Establishment Import/Export Generation Security Function and Cert. Number Strength Key/SSP Name/Type Ceragon Networks Ltd. © 2025 Public Material

• May be reproduced only in its original entirety (without revision). Version

N/A N/A N/A 0.1 N/A Use & related keys Zeroisation Storage Establishment Import/Export Generation Security Function and Cert. Number Strength Key/SSP Name/Type N/A N/A N/A N/A Ceragon Networks Ltd. © 2025 Public Material

• May be reproduced only in its original entirety (without revision). Version

Use & related keys Zeroisation Storage Establishment Import/Export Generation Security Function and Cert. Number Strength Key/SSP Name/Type Table 19

• SSPs 0.1 Ceragon Networks Ltd. © 2025 Public Material
• May be reproduced only in its original entirety (without revision). Version

9.1 Generation The module generates symmetric and asymmetric keys in compliance with the requirements of the FIPS 140-3 standard. Specifically, symmetric keys are generated using output of the Approved SP 800-90A DRBG and in compliance with IG D.H. Asymmetric keys are generated as part applicable key generation standards. See Table 19 for additional details. 9.2 Import/Export All keys are entered into or output from the module in a secure manner. Specifically, the Session Keys are output from the module encrypted with an approved KTS using a Master Key with the AES-KW algorithm. Additionally, SSPs provisioned by an operator can be entered using an approved KTS employing AES-GCM or AES and HMAC within the SSH, TLS, or IPsec protocols. See Table 19 for additional details. 9.3 Storage SSPs are stored in plaintext in non-volatile and volatile memory. See Table 19 for additional details. 9.4 Zeroization Procedures SSPs stored in volatile memory are zeroized automatically when no longer needed. SSPs stored in nonvolatile memory are zeroized after repeated failure of the Pre-Operational Self-Tests or upon hardzeroization command issued. The zeroization will permanently erase SSPs stored in Flash by overwriting with zeroes. When zeroization occurs via power cycle or the zeroization command the module provides an indicator in the console log. When zeroization occurs via session termination the zeroization indicator is provided via session log. For CSPs that are zeroized after use, the indicator is that the service continues. If there is a zeroization error, the service in process will be terminated. See Table 19 for additional details. Table 20

• Non-Deterministic Random Number Generation Specification

10. Self-tests Self-tests are health checks that ensure that the cryptographic algorithms within the module are operating correctly. The self-tests identified in FIPS 140-3 broadly fall within two categories:
11. Pre-Operational Self-Tests
12. Conditional Self-Tests When the module is powered on, its power-up self-tests are executed without any operator intervention. CASTs are performed prior to first usage of an algorithm. The operator may run periodic self-tests by power-cycling the module. Conditional tests are performed when a specific condition is met, such as usage of the entropy source or generation of key-pair. 10.1 Pre-Operational Self-Tests The cryptographic module performs the following Pre-Operational Self-Tests on: o o 10.2 Firmware Integrity Test: 160-bit Error detection code (EDC) Pre-operational Bypass Test Conditional Self-Tests The HW-based entropy source is conditionally tested (when entropy is consumed by any of the FW components). Tests are APT and RCT (mentioned in the SP 800-90B document). The cryptographic module performs the following conditional self-tests: • Conditional Cryptographic Algorithm Self-Tests: o Management Security Algorithms Implementation (Firmware) (Cert. #A2758): o HMAC-SHA2-256 CAST o SHA-1 CAST o SHA2-512 CAST o AES-128 ECB Decrypt CAST o AES KeyWrap Encrypt CAST o AES KeyWrap Decrypt CAST o AES-256 GCM Encrypt CAST o RSA PKCS#1 Sign/Verify CASTs o ECDSA Sign/Verify CASTs o DH Shared Secret Computation CAST o ECDH Shared Secret Computation CAST o TLS 1.2 KDF CAST o TLS 1.3 KDF CAST o SSH KDF CAST o DRBG CAST o IKE KDF Implementation (Firmware) (Cert. #A2756): o IKE KDF CAST o SNMP KDF Implementation (Firmware) (Cert. #A2757): Ceragon Networks Ltd. © 2025 Version 0.1 Public Material – May be reproduced only in its original entirety (without revision).

• SNMP KDF CAST
• Linux Kernel Crypto Implementation (Firmware) (Cert. #A2755):
• AES-256 CBC Encrypt CAST
• AES-256 CBC Decrypt CAST
• HMAC-SHA2-256 CAST
• SHA2-256 CAST
• AES Core Implementation (Hardware):
• AES-256 OFB Encrypt CAST (Cert. #AES 4014)
• AES-256 OFB Decrypt CAST (Cert. #AES 4014)
• AES-256 CTR Encrypt CAST (Cert. #A680)
• AES-256 CTR Decrypt CAST (Cert. #A680)
• Entropy Self-tests
• SP 800-90B Repetition Count Test
• SP 800-90B Adaptive Proportion Test
• SP 800-90A Health Tests
• 10.3 Conditional Pair-wise Consistency Self-Tests:
• Pairwise Consistency Test (PWCT) for RSA
• Pairwise Consistency Test (PWCT) for ECDSA
• Pairwise Consistency Test (PWCT) for DSA Conditional software/firmware load test
• Firmware Load Test (RSA 4096/SHA2-256 Signature Verification) Conditional Bypass Test Self-Tests Error Handling If any of the identified POSTs fail, the module will not enter an operational state and will instead provide an error message “Failed powerOnSelfTest”. If the failure persists after power-cycle, the module will then be placed in a Default State (where all keys/CSPs are zeroized) and the Approved mode enabled flag is reset to disabled. The module will enter the non-approved mode. Event logs will be updated accordingly. If either of the SP 800-90B self-tests fail, the repeated random numbers are discarded, and an error is reported. If the PWCT fails, the key pair is discarded, and an error is reported. If the Firmware Load Test fails, the new firmware is not loaded. If the conditional Bypass self-test fails, the error is reported, and the module does not transition into or out of bypass. During execution of the self-tests, firmware loading, zeroization, and while in an error state, data output is inhibited. 11. Life-cycle assurance This section describes the configuration and administration of the cryptographic module. Ceragon Networks Ltd. © 2025 Version 0.1 Public Material
• May be reproduced only in its original entirety (without revision).

11.1 Secure Operation When configured as per this section of the Security Policy, the module only runs in the Approved mode of operation, with the exception of the non-Approved Services identified in Table

17. The non-Approved services described may make use of non-compliant cryptographic algorithms or plaintext data transfers. Use of these services is prohibited in an Approved mode of operation. The Crypto Officer is responsible for ensuring that any of the non-Approved Services (Table 17) in Section 4.3 are not used. Once the module is properly configured as outlined below, the non-Approved Services will not be available for use. 11.2 Installation The module hardware is shipped in sealed boxes to indicate tamper. Upon delivery, the recipient should inspect the package to verify that there has been no tampering. IP-20G, IP-20C, IP-20S, IP-20C-HP, IP-50C, and IP-50E have a fixed configuration with TELs applied at factory. The Crypto Officer must verify at installation time that the TELs are affixed and intact. IP-20N, and IP-20A have variable configurations and the CO must verify that they are configured as per one of the approved configurations identified in Section 2.1, Table
18. Moreover, the Crypto Officer must verify at installation time that the TELs are affixed and intact. The tamper evident seals installed as indicated in Section 7 are required for the module to be operated in the Approved mode of operation. Please refer to the figures in Section 7 of this document for the proper placement of TELs. 11.3 Initialization The CO must follow these steps to place the module in an Approved mode of operation. For the exact CLI command syntax or GUI instructions, please refer to the below referenced sections of the FIPS Security Configuration Guide for precise details.
19. Enable Password Enforcement to enforce password strength.

- Select Quick Configuration > Security > Access Control. - In the Password change for first login field, select Yes. - In the Enforce password strength field, select Yes. 2. Configure failure login attempts for wrong passwords to 3 attempts (default value).

- In the Failure login attempts to block user field, select the number of failed login attempts (3) that will trigger blocking. 3. For radio encryption mode, configure Master Key and enable Payload Encryption.

Ceragon Networks Ltd. © 2025 Version 0.1 Public Material

• May be reproduced only in its original entirety (without revision).

4. Enable SNMP v3 (default) and disable SNMPv1 and v2. Add SNMP users as appropriate following the password complexity requirements specified for CO operators in Section 4 above. Ensure that “AES” and “SHA” are selected for the privacy and authentication ciphers, respectively.

Select Quick Configuration > Security > Protocols. The Quick Configuration Security Protocols page opens (Figure 41). In the SNMP Admin field, select Enable to enable SNMP In the V1V2 Blocked field, select Yes to block SNMPv1 and SNMPv2 access so that only SNMPv3 access will be enabled. 5. Disable Telnet

Select Quick Configuration > Security > Protocols. In the Telnet Admin field, select Disable. Click Apply. 6. Disable HTTP and enable HTTPS

Select Quick Configuration > Security > Protocols. In the HTTP protocol field, select HTTPS 7. [Optional step] in case of External Protection configuration (relevant for IP-20G, IP-20C, IP-20S, IP-20CHP), enable Protection Admin and supply a pre-shared key. -

8. [Optional step] In case of TCC Redundancy (relevant for IP-20N, IP-20A), enable Protection Admin, and make sure TCC Protection switch mode is set to Cold Switch Over Note: Hot Switch Over (HSO) shall not be used in the Approved Mode Web GUI: Platform > Shelf Management > Main Card Redundancy (In the TCC Protection switch mode field, select Cold Switch Over) 9. Change the default CO password -

10. Enable Approved Admin configuration, i.e., set operation mode to ‘Approved mode’. Ceragon Networks Ltd. © 2025 Version 0.1 Public Material

• May be reproduced only in its original entirety (without revision).

- 7.1 Enabling ‘Approved Mode’ Once the final step is performed the module will prompt the CO to reboot. Upon successful reboot the module will enter the Approved mode of operation. Once the module has been configured, the Approved mode status can be verified by selecting the Security Summary from the Web EMS main menu. The field for “FIPS Mode Admin” shows “enabled”. 11.4

Management Protocols such as Telnet, RADIUS, TACACS+, HTTP, SNMPv1, and SNMPv2, Syslog, Hot Standby, NTP are not approved for use in the Approved mode and shall remain disabled. When in FIPS 140-3 compliant mode, only the following algorithms are used for SSH and TLS communications.

When in the Approved mode, the module supports only the following symmetric encryption algorithm:

• aes128-ctr
• aes192-ctr
• aes256-ctr
• aes128-gcm@openssh.com
• aes256-gcm@openssh.com The following Message Authentication Code (MAC) algorithm is supported in the Approved mode:
• hmac-sha1 The following key exchange algorithms are supported in the Approved mode:
• ecdh-sha2-nistp256 ecdh-sha2-nistp384 ecdh-sha2-nistp521 diffie-hellman-group14-sha256 diffie-hellman-group16-sha512 diffie-hellman-group18-sha512

When in the Approved mode, only the following cipher suites are available for TLSv1.2 communications:

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA Ceragon Networks Ltd. © 2025 Version 0.1 Public Material
• May be reproduced only in its original entirety (without revision).

When in the Approved mode, only the following cipher suites are available for TLSv1.3 communications:

• TLS_AKE_WITH_AES_256_GCM_SHA384 TLS_AKE_WITH_AES_128_GCM_SHA256

There are no specific maintenance actions required. 12. Mitigation of other attacks The module does not claim to mitigate any other attacks beyond those specified in FIPS 140-3. Ceragon Networks Ltd. © 2025 Version 0.1 Public Material

• May be reproduced only in its original entirety (without revision).

Referenced URLs

• www.acumensecurity.net