Mediant 800 Session Border Controller/Media Gateway, Mediant 2600/4000B/9080B Session Border Controllers, and MediaPack 1288 Media Gateway

Certificate

Approved Algorithms (43)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for Mediant 800 Session Border Controller/Media Gateway, Mediant 2600/4000B/9080B Session Border Controllers, and MediaPack 1288 Media Gateway
  %% 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>7.6</i>"]
    C2["[high] Firmware update / recovery<br/>/ rollback services<br/><i>Upgrade Image<br/>Load License Key File</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Load License Key File<br/>Configure the SBC System<br/>Configure VOIP Network, Media and SIP Settings,…</i>"]
    C4["[high] Physical/logical<br/>interfaces (some 'blocked<br/>in firmware')<br/><i>RS-232 Serial Port<br/>USB<br/>RS-232 Serial Port (Micro-USB)</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>HTTPS</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>application</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 Mediant 800 Session Border Controller/Media Gateway, Mediant 2600/4000B/9080B Session Border Controllers, and MediaPack 1288 Media Gateway
  %% 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>7.6</i><br/>src: certificate.firmwareVersions"]
    C2["[high] Firmware update / recovery / rollback services<br/><i>Upgrade Image<br/>Load License Key File</i><br/>src: securityPolicy.services"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Load License Key File<br/>Configure the SBC System<br/>Configure VOIP Network, Media and SIP Settings,…</i><br/>src: securityPolicy.services"]
    C4["[high] Physical/logical interfaces (some 'blocked in firmware')<br/><i>RS-232 Serial Port<br/>USB<br/>RS-232 Serial Port (Micro-USB)</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/>HTTPS</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<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 C1,C2,C3,C4 clueHigh;
  class C5,C6 clueLow;

Security Policy, page by page

AudioCodes Ltd. Mediant 800 Session Border Controller/Media Gateway, Mediant 2600/4000B/9080B Session Border Controllers, and MediaPack 1288 Media Gateway Hardware Models: Mediant 800 (P/N GGWC00001), Mediant 2600 (P/N GTPM00769), Mediant 4000B (P/N GTPM00894), Mediant 9080B (P/N GGWZ00047), and MediaPack 1288 (P/N GTPM01021) Firmware Version: 7.6 FIPS Security Level: 1 Document Version: 0.8 Prepared for: Prepared by: AudioCodes Ltd.

Airport City, Lod 70151 Israel Corsec Security, Inc.

Fairfax, VA 22033 United States of America Phone: +972 3 976 4000 www.audiocodes.com Phone: +1 703 267 6050 www.corsec.com

September 26, 2024 Abstract This is a non-proprietary Cryptographic Module Security Policy for the Mediant 800 Session Border Controller/Media Gateway, Mediant 2600/4000B/9080B Session Border Controllers, and MediaPack 1288 Media Gateway (firmware version: 7.6) from AudioCodes Ltd. (AudioCodes). This Security Policy describes how the Mediant SBCs and Media Gateways meet 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 Cryptographic Module Validation Program (CMVP) website, which is maintained by the National Institute of Standards and Technology (NIST) and the Canadian Centre for Cyber Security (CCCS). This document also describes how to run the module in an Approved mode of operation. This policy was prepared as part of the Level 1 FIPS 140-3 validation of the module. The Mediant SBCs and Media Gateways are referred to in this document collectively 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 AudioCodes website (www.audiocodes.com) contains information on the full line of products from AudioCodes.
• 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. Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

September 26, 2024 Table of Contents 1. 2. 2.1 2.2 2.3 2.4 3. 4. 4.1 4.2 4.3 4.4 5. 6. 7. 8. 9. 9.1 9.2

Appendix A. Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

September 26, 2024 List of Tables List of Figures Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

1. September 26, 2024 General AudioCodes Ltd. (hereafter referred to as AudioCodes) is a leading vendor of advanced networking and media processing solutions for the digital workplace. The AudioCodes Mediant family of Session Border Controllers (SBCs) and Media Gateways (GWs) offer a line of versatile IP1 communications platforms that connect VoIP2 and TDM3 networks, built on years of carrier-grade VoIP deployments and expertise. AudioCodes’s SBCs and Media Gateway provide the interoperability, security and quality assurance that service providers need to connect their enterprise and residential customers reliably and securely to SIP4 trunk and hosted telephony services. The Mediant SBCs and Media Gateways form an effective demarcation point between a business’s VoIP network and the service provider’s SIP trunk, performing SIP protocol mediation and media handling (interoperability), and securing the enterprise VoIP network. They can function as a peering SBC, access SBC, or enterprise SBC.

• The Mediant 800 (see Figure 1) is a hybrid SBC and media gateway that offers a complete connectivity solution for small-to-medium sized enterprises. It supports up to 400 SBC sessions. Figure 1
• Mediant 800
• The Mediant 2600 (see Figure 2) is an enterprise session border controller (E-SBC) designed to serve medium-sized businesses. It supports up to 600 concurrent sessions. Figure 2
• Mediant 2600
• The Mediant 4000 (see Figure 3) is a mid-to-high scale capacity SBC designed for deployment in large organizations and as an access SBC for service providers. It supports up to 5,000 concurrent SBC sessions.

TDM

• Time-Division Multiplexing

Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

September 26, 2024 Figure 3

• Mediant 4000
• The Mediant 9080 (see Figure 4) is a high-capacity SBC designed for deployment in large enterprise and contact center locations, and as access and peering SBCs for service provider environments. It supports up to 70,000 SBC sessions. Figure 4
• Mediant 9080
• The MediaPack 1288 (see Figure 5) is a hybrid SBC that provides a high-density analog media gateway. It offers a cost-effective solution for organizations transitioning to all-IP that need to integrate large numbers of analog devices (such as legacy phones, fax machines and modems) into their new infrastructure. It supports 300 SBC sessions. Figure 5
• MediaPack 1288 The Mediant 800, Mediant 2600, Mediant 4000B, and Mediant 9080B are 1U5 devices; the MediaPack 1288 is a 3U device. The Mediant SBCs and Media Gateways are IP encryption appliances with proven performance, resiliency, and security featuring real-time encryption (VoIP signaling and media traffic), DSP 6 -based media U
• Rack Unit

Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

September 26, 2024 transcoding, a flexible and intuitive SIP routing engine, and an integrated WebRTC gateway. Some of the network and security features provided by the SBCs include:

• SIP B2BUA7 SIP Interworking Extensive PBX8 interoperability Transport Mediation between SIP over UDP9/TCP10/TLS11/WebSocket, IPv4/IPv6, RTP12/SRTP13 SDES14/DTLS15 Header Manipulation Local and far-end NAT16 traversal Integrated WebRTC gateway with support for WebSocket, Opus, VP817 video coder, lite ICE18, DTLS, RTP multiplexing, and secure RTCP19 with feedback Denial of service protection with DoS20/DDoS21 line rate protection, VOIP firewall and deep packet inspections with rogue RTP detection and prevention Encryption and authentication with support for TLS, DTLS, SRTP, HTTPS22, SSH23, SFTP24, and SNMP25 Topology hiding and user privacy Traffic separation with VLAN 26 /physical interface separation for multiple media, control and OAMP 27 interfaces Call Admission Control Full Quality of Experience (QoE) monitoring: Jitter, Packet Loss, Delay and MOS28 Management of the module is accomplished via the following methods:
• Command Line Interface (CLI), which is accessible using the following means: o remotely via SSH over Ethernet management ports o locally via direct attachment to the RS-232 serial port using a VT100 terminal or a general-purpose computer with a terminal emulation program o locally via direct attachment using a VGA monitor and USB-enabled keyboard (Mediant 9080B only)

SDES

• Session Description Protocol Security Descriptions DTLS
• Datagram Transport Layer Security

ICE

• Interactive Connectivity Establishment

HTTPS

• Hypertext Transfer Protocol Secure

OAMP

• Operations, Administration, Maintenance, and Provisioning

Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

September 26, 2024 • Web-based Graphical User Interface (GUI) called the Web Interface, which is accessible remotely via HTTPS over Ethernet management ports. • SNMPv3 operations, which are used for remote configuration and obtaining information about the module’s state and statistics. • INI Configuration file, which is a text-based file with .ini file extension containing configuration settings. This file may be loaded to the SBC using SNMPv3 or by using the CLI (over SSH) or Web Interface for automatic configuration/commissioning. These management interfaces provide authorized operators access to the module for configuration and management of all facets of the module’s operation, including system configuration, troubleshooting, security, and service provisioning. Using any of the management interfaces, an operator is able to monitor, configure, control, receive report events, and retrieve logs from the modules. To support TLS and SSH, the following types of RSA certificates may be imported to the module using the module’s Web Interface (over TLS) or CLI (over SSH): • X.509 certificate file – plaintext base64 encoded PEM29 format. These files contain public keys only, while the matching private key is contained in the associated RSA private key file. • RSA private key file – plaintext base64 encoded PEM format. These files contain the private key associated with the RSA public key in the X.509 certificate file. • Root certificate file (CA Public keys) – chains of X.509 certificates in plaintext base64 encoded PEM format. These are used to validate peer certificates and serve as a possible chain used for self-signed certificates to be sent to the peer. The Root certificate file contains public keys only; they do not contain the associated private keys. The module generates RSA keypairs and Certificate Signing Requests (CSRs). The CSR is signed with the module’s private key and then sent to a CA. The CA then signs the certificate and sends it back, where it is then installed for use. The module also generates self-signed certificates corresponding to the internally generated RSA keypairs. The module provides the option to import certain CSPs by loading a text-based file with a *.ini file extension (INI file) in encrypted form using the module’s Web Interface (over TLS) or CLI (over SSH). The module also supports an Automated Update mechanism whereby an INI file is downloaded from a server over HTTPS. The CSPs that may be imported through an INI file are indicated as such in Table

12. The Mediant SBCs and Media Gateways are validated at the FIPS 140-3 section levels shown in Table
13. Table 1 – Security Levels [Number Below]

Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

September 26, 2024 [Number Below] N/A N/A The module has an overall security level of 1. Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

2. September 26, 2024 The Mediant SBCs and Media Gateways represent a hardware module with a multi-chip standalone embodiment. The sections below describe the operational environments, algorithm implementations, module boundary, and modes of operation. 2.1 Operational Environments Table 2 below lists the module configuration(s) used for validation testing. Table 2

• Cryptographic Module Tested Configurations 7.6 7.6 7.6 7.6 7.6 2.2 Algorithm Implementations The module employs the cryptographic algorithm implementations from the sources listed in Table 3 below. Table 3
• Cryptographic Algorithm Sources 7.6 7.6 7.6 Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

September 26, 2024 7.6 7.6 *The Crypto Accelerator and KDF Accelerator implementations are provided by the Cavium chip; they are not available on the Intelbased M9080. Validation certificates for each Approved security function are listed in Table 4. The module also includes implementations that are used solely to support self-tests; only the implementations in the table below are used by the module during operation. Table 4

• Approved Algorithms

30 This table includes vendor-affirmed algorithms that are approved but CAVP testing is not yet available.

RFC

• Request for Comments

Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

44 KAS-ECC-SSC

• Key Agreement Scheme - Elliptic Curve Cryptography - Shared Secret Computation

KAS-FFC-SSC

• Key Agreement Scheme - Finite Field Cryptography - Shared Secret Computation

Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

D.G. D.G. September 26, 2024 D.G. D.G. D.G. D.G. KTS

• Key Transport Scheme Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

September 26, 2024 N/A The vendor affirms the following cryptographic security methods:

• Approved DRBG to generate seeds for generation of asymmetric keys. The resulting generated seed is an unmodified output from the DRBG. The module’s DRBG is seeded via entropy generated from a CPU jitterbased entropy source which is internal to the module (the module requests a minimum of 256 bits of Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

September 26, 2024 Table 5

• Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed The module does not include any non-Approved algorithms allowed in the Approved mode of operations. The module does not include any non-Approved algorithms not allowed in the Approved mode of operations. 2.3 Cryptographic Boundary The cryptographic boundary is defined by the physical enclosure of the Mediant SBCs and Media Gateways and includes all internal hardware as well as the Mediant SBCs and Media Gateways 7.6 firmware. The main hardware components consist of integrated circuits, processors, memories, SSD50, SAS51 HDD52, flash, DSP cards, power supplies, fans, and the enclosure containing all of these components. The bulleted list below specifies the hardware and firmware components of the cryptographic module that are excluded from the security requirements, as well as the rationale for exclusion.
• Excluded Hardware Components o
• Excluded Firmware Components
• 2.4 The power supply modules are excluded from the security requirements. The power supply modules only supply power. They cannot be used to cause a compromise. The module’s physical security is maintained in the absence of these components. Thus, these components have been excluded from the module validation. There are no excluded firmware components. Modes of Operation The module supports the Approved mode of operation only. When installed, configured, and operated according to Section 11 of the Security Policy, the module does not support a non-Approved mode of operation.

SAS

• Serial Attached Small Computer System Interface

Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

3. September 26, 2024 Cryptographic Module Interfaces FIPS 140-3 defines the following logical interfaces for cryptographic modules: • • • • • Note that the module does not output control information, and thus has no specified control output interface. The Mediant 800 contains the physical ports and interfaces shown in Figure 6 and Figure
4. Table 6 provides the mapping of the FIPS-defined interfaces and the module’s physical and logical interfaces for • • • • • • • • ©2024 AudioCodes Ltd.

September 26, 2024 N/A The Mediant 2600 and Mediant 4000B include the physical ports and interfaces shown in Figure 8 and Figure

9. Figure 8 – Mediant 2600/Mediant 4000B Front Ports and Interfaces Figure 9 – Mediant 2600/Mediant 4000B Rear Ports and Interfaces Table 7 provides the mapping of the FIPS-defined interfaces and the module’s physical and logical interfaces for Table 7 – Ports and Interfaces (Mediant 2600/Mediant 4000B) • • • • • • • • N/A The Mediant 9080B contains the physical ports and interfaces shown in Figure 10 and Figure
10. Figure 10 – Mediant 9080B Front Ports and Interfaces ©2024 AudioCodes Ltd.

September 26, 2024 Figure 11

• Mediant 9080B Rear Ports and Interfaces Table 8 provides the mapping of the FIPS-defined interfaces and the module’s physical and logical interfaces for the Mediant 9080B. Table 8
• Ports and Interfaces (Mediant 9080B) N/A
• N/A N/A N/A
• ©2024 AudioCodes Ltd.

September 26, 2024

• The MediaPack 1288 contains the physical ports and interfaces shown in Figure 12 and Figure 13. Figure 12
• MediaPack 1288 Front Ports and Interfaces Figure 13
• MediaPack 1288 Rear Ports and Interfaces Table 9 provides the mapping of the FIPS-defined interfaces and the module’s physical and logical interfaces for the MediaPack 1288. Table 9
• Ports and Interface (MediaPack 1288) Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

4. September 26, 2024 Roles, Services, and Authentication The sections below describe the module’s authorized roles, services, and operator authentication methods. 4.1 Authorized Roles The module supports two roles that operators may assume:

• Crypto Officer (CO) role
• The CO is responsible for initializing the module for first use, which includes the configuration of passwords, public and private keys, and other CSPs. The CO is also responsible for the management of all keys and CSPs, including their zeroization, and is the only operator that can configure the module for Approved mode operation. The CO has access to all User services and can also perform services via SNMPv3.
• User role
• The User has read-only privileges and can show the status and statistics of the module, show the current status of the module, and connect to the module remotely using HTTPS or SSH. Users can also change their own passwords. The CO and User roles are tied to administrative roles supported by the module. The CO role is equivalent in terms of privileges to the AudioCodes-defined “Security Administrator” and “Master” administrative role. The User role is equivalent to the AudioCodes-defined “Monitor” role. Both roles can access the Web Interface and CLI. Table 10 below lists the supported roles, along with the services (including input and output) available to each Table 10
• Roles, Service Commands, Input and Output Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

September 26, 2024 N/A Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

4.2 September 26, 2024 N/A N/A Authentication Methods Each operator has their own account with a username and password, which are used to authenticate to the module. Passwords are stored on non-volatile storage media in hashed form using SHA2-256. For SSH/SFTP, operators can also utilize RSA or ECDSA Public keys. Note that, while the module supports authentication mechanisms, no claims are being made with regards to compliance to the Level 2/3 role-based and identity-based authentication requirements since it is being certified at Level 1. 4.3 Externally Loaded Firmware The module has the capability to load firmware in the form of a complete image replacement from an external source. As such a replacement will constitute a new module, only FIPS-validated firmware may be loaded to maintain the module’s validation. Services and functions provided by the newly loaded firmware image are not performed until the pre-operational self-tests have executed successfully via a power-on reset. All firmware images are digitally signed, and a conditional self-test (using an ECDSA signature verification with P-256 curve) is performed during the reset. If the signature test fails, the new firmware image is ignored and the previous-loaded firmware image remains current. SSP zeroization takes place prior to execution of the new image. The module’s versioning information is updated to reflect the addition/update of the newly loaded firmware. 4.4 Services Descriptions of the services available to the authorized roles are provided in Table 11 below. As allowed 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 successful completion of the service). Please note that the keys and Sensitive Security Parameters (SSPs) listed in the table indicate the type of access required using the following notation: Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

• September 26, 2024 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 11
• Approved Services N/A N/A N/A N/A N/A N/A N/A N/A Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

September 26, 2024 N/A N/A N/A Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

September 26, 2024 N/A N/A Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

September 26, 2024 (N/A) Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

September 26, 2024 Establish nonsecurityrelated Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

September 26, 2024 (N/A) Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

September 26, 2024 N/A Manual OnDemand SelfTests N/A N/A *Per FIPS 140-3 Implementation Guidance 2.4.C, the Show Status, Zeroize, and Show Versioning Information services do not require an Approved security The module does not provide any non-Approved services. Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

5. September 26, 2024 Software/Firmware Security The module firmware takes the form of a single firmware image that includes multiple files (configuration files, executable files, packages, and other associated files). The image is verified using an approved integrity technique implemented within the cryptographic module itself. The module implements an ECDSA P-256 (SHA2-256) digital signature verification for the integrity test of the firmware. The approved integrity technique consists of single ECDSA signature verification; failure of the integrity check will cause the module to enter a critical error state. The CO can initiate the pre-operational tests on demand by resetting or power-cycling the module (see section

Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

6. September 26, 2024 Operational Environment The module employs a limited operational environment (as it is designed to accept only controlled firmware changes that successfully pass the software/firmware load test). The module does not provide a general-purpose operating system (OS). All services provided by the module are provided by the module’s firmware and external interfaces. The module’s processor executes the firmware on the tested configurations specified in section 2.1 of this document. Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

7. September 26, 2024 Physical Security As a multi-chip standalone hardware module, the module includes an enclosure composed of hard, productiongrade, metal components necessary to meet FIPS 140-3 level 1 physical security requirements. The module enclosure completely encloses all of its internal components, and all integrated circuits are coated with commercial standard passivation. Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

8. September 26, 2024 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. Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

September 26, 2024 9. Sensitive Security Parameter Management 9.1 The module supports the keys and other SSPs listed in Table 12 below. Table 12

• SSPs The indicators provided by zeroization methods specified in this column are implicit as the normal, non-error, status output of the function performing Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

September 26, 2024 Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

September 26, 2024 HMAC-SHA2256 HMAC-SHA2384 Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

September 26, 2024 HMAC-SHA2256 HMAC-SHA2384 HMAC-SHA2256 HMAC-SHA2384 Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

HMAC-SHA2256 September 26, 2024 HMAC-SHA2384 TLS PreMaster Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

September 26, 2024 with a zerovalue Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

September 26, 2024 with a zerovalue AES GCM encryption is used in the context of several secure communications protocols. The module meets the (key/IV) pair uniqueness requirements from NIST SP 800-38D as follows:

• For TLS v1.2, the module supports acceptable AES GCM cipher suites from section 3.3.1.1 of NIST SP 80052rev2. The mechanism for IV generation falls into scenario 1 in FIPS 140-3 IG C.H and is compliant with RFC 5288. The counter portion of the IV is strictly increasing. When the IV exhausts the maximum number of possible values for a given session key, a failure in encryption will occur and a handshake to establish a new encryption key will be required. It is the responsibility of the module operator (i.e., the first party, client, or server) to trigger this handshake in accordance with RFC 5246 when this condition is encountered.
• For TLS v1.3, the module supports acceptable AES GCM cipher suites from section 3.3.1.2 of NIST SP 80052rev2. The protocol’s implementation is contained within the boundary of the module, and the generated IV is only used in the context of the AES GCM encryption executing the provisions of the TLS

The mechanism for IV generation falls into scenario 5 in FIPS 140-3 IG C.H and is compliant with RFC 8446. Each session employs a “per-record nonce”, a 64-bit sequence number (or IV) maintained separately for reading and writing records. Each sequence number is set to 0 at the beginning of a connection and whenever the key is changed (the first record transmitted under a particular traffic key uses sequence number 0), and the appropriate sequence number is incremented by one after reading or writing each record. Because the size of sequence numbers is 64 bits, they should not wrap. If a sequence number needs to wrap, it is the responsibility of the module operator to either rekey or terminate the connection.

• For SSH v2, the mechanism for IV generation falls into scenario 1 in FIPS 140-3 IG C.H and is compliant with RFC 5647. Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

September 26, 2024 A new IV parameter is generated by the module for each AES GCM encryption. The IV consists of a 4-byte fixed field and an 8-byte invocation counter. The fixed field of the IV remains the same for the duration of the session, while the invocation counter is treated as a 64-bit integer and is incremented by one when performing an encryption of a new binary packet. If the invocation counter reaches its maximum value

264

• 1, the next encryption is performed with the invocation counter set to either 0 or 1. No more than

264

• 1 encryptions are performed in the same session. When a session is terminated for any reason, it is

the responsibility of the module operator to derive a new key and a new initial IV. The module also complies with the following RFCs:

• RFC 4252
• RFC 4253
• RFC 5647 9.2 Table 13 below specifies the module’s entropy sources. Table 13
• Non-Deterministic Random Number Generation Specification Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

September 26, 2024 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 powered up 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. 10.1 Pre-Operational Self-Tests The module performs the following pre-operational self-test(s):

• 10.2 Firmware Integrity Test on the module firmware image (using ECDSA P-256 with SHA2-256 digital signature verification) Conditional Self-Tests The module performs the following conditional self-tests:
• Conditional cryptographic algorithm self-tests (CASTs)
• Crypto Library:
• AES ECB encrypt KAT56 (128-bit length)
• AES ECB decrypt KAT (128-bit length)
• AES CCM encrypt KAT (128-bit length)
• AES CCM decrypt KAT (128-bit length)
• AES GCM encrypt KAT (256-bit length)
• AES GCM decrypt KAT (256-bit length)
• CTR DRBG instantiate/generate/reseed KAT (AES, 256-bit, with derivation function)
• ECDSA sign KAT (P-256 curve)
• ECDSA verify KAT (P-256 curve)
• HMAC KATs (SHA-1, SHA2-256, SHA2-384)
• RSA sign KAT (2048-bit; SHA2-256; PKCS#1.5 scheme)
• RSA verify KAT (2048-bit; SHA2-256; PKCS#1.5 scheme)
• SHA-2 KATs (SHA2-224, SHA2-512)
• SHA-3 KATs (SHA3-256)
• FFC DH Shared Secret “Z” Computation KAT (2048-bit)
• ECC CDH Shared Secret “Z” Computation KAT (P-256 curve)
• Entropy Library:
• SHA3-256 KAT
• Entropy “Stuck” Test
• Entropy Repetition Count Test (performed over 1024 samples)
• Entropy Adaptive Proportion Test (performed over 1024 samples)

Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

• KDF Library:
• TLS v1.2 KDF KAT
• TLS v1.3 KDF KAT
• SSH KDF KAT
• Crypto Accelerator:
• AES ECB encrypt and decrypt KATs57 (128-bit length)
• RSA sign KAT (2048-bit; SHA2-256; PKCS#1.5 scheme)
• RSA verify KAT (2048-bit; SHA2-256; PKCS#1.5 scheme)
• SHA KATs (SHA1, SHA2-256)
• KDF Accelerator:
• TLS v1.2 KDF KAT
• TLS v1.3 KDF KAT
• SSH KDF KAT September 26, 2024 To ensure all conditional CASTs are performed prior to the first operational use of the associated algorithm, all CASTs are performed during the module’s initial power-up sequence. The CASTs for algorithms used in the pre-operational firmware integrity test are performed prior to the integrity test itself; all other CASTs are executed immediately after the successful completion of the firmware integrity test.
• Conditional pair-wise consistency tests (PCTs)
• ECDSA key generation PCT (upon generation of a key pair for ECDSA digital signature functions)
• RSA sign/verify PCT (upon generation of a key pair for RSA digital signature functions)
• DH key generation PCT (upon generation of a key pair for DH key agreement functions)
• ECDH key generation PCT (upon generation of a key pair for ECDH key agreement functions)
• Conditional manual SSP entry test (upon direct entry of an SSP)
• Conditional Critical Functions Tests
• Image Verification Test using ECDSA P-256 signature verification (upon loading of a new image) 10.3 Self-Test Failure Handling Upon failure of a pre-operational self-test, conditional CAST, or conditional PCT, the module enters a “Fatal” error state, keys are zeroized, and the module is automatically reset, with reset reason of “FIPS Failure”. An error is written to syslog. All access to the cryptographic functionality and CSPs is disabled. All data outputs via data output interfaces are inhibited (with the exception of syslog status messages) and the management interfaces will not respond to any commands while the module is in this state. A successful reboot is needed to clear the error condition and return to a normal operational state. Upon failure of the conditional firmware load test, the module enters a “Soft Error” state and with error status logged in syslog and the load process aborted. The error state is then automatically cleared, and the module resumes normal operation.

Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

September 26, 2024 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. 11.1 Secure Installation The CO shall be responsible for receiving, installing, initializing, and maintaining the module. To operate the module in the Approved mode, the CO shall configure the module via the Web Interface or the CLI as directed by this Security Policy. After the CO has finished installation of the module, the management interfaces can be accessed to configure the module in the Approved mode of operation, which is outlined in section 11.2 below. 11.2 Initialization The CO shall configure the module for the Approved mode. This ensures that the system will use only Approved cryptographic algorithms and key strengths. To configure the module for Approved operation, the CO may use the CLI or the Web Interface. Please refer to the following documents for general information on the use of the module’s management interfaces:
• AudioCodes Reference Guide, Command-Line Interface for Media Gateways & SBCs, Version 7.6 AudioCodes User’s Manual, Mediant 800, Version 7.6 AudioCodes User’s Manual, Mediant 2600 Enterprise SBC, Version 7.6 AudioCodes User’s Manual, Mediant 4000 SBC, Version 7.6 AudioCodes User’s Manual, Mediant 9000 SBC Series, Mediant 9000 Rev. B / Mediant 9030 / Mediant 9080, Version 7.6 AudioCodes User’s Manual, MediaPack 1288 Analog Gateway, Version 7.6 To configure the module for Approved operation, the CO must perform the following actions:
• The CO must enable Approved mode. Using the CLI, the CO must issue the FIPS mode: Enabled command. Using the Web Interface, the module’s Approved mode can be set on the Security Settings page (Setup menu -> IP Network tab -> Security folder -> Security Settings) and clicking the <Enable FIPS> button. Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

• September 26, 2024 General information for configuring TLS contexts (settings that define the TLS parameters used for management and other TLS applications) using the Web Interface is addressed in the “Configuring TLS Certificates” chapter of the applicable device User’s Manual. For Approved operation, the CO shall open the TLS Contexts table on the TLS Contexts page (Setup menu -> IP Network tab -> Security folder > TLS Contexts) and ensure that the contexts are configured according to the following guidance:
• For the “DH Key Size” parameter, the CO may select any supported size except 1024.
• For “Cipher Server” and “Cipher Client” parameters (applicable to TLS versions 1.0
• 1.2), the CO shall ensure that only Approved ciphers are used by adding the following to the cipher string to the cipher string list: !RC4:!aNULL:!eNULL:!AECDH:!ADH:!CAMELLIA:!ARIA128:!SEED:!kRSA:!3DES
• For “Cipher Server TLS1.3” and “Cipher Client TLS 1.3” parameters (applicable to TLS version 1.3), the CO shall ensure that only Approved ciphers are used by removing the following cipher string from the cipher string list: TLS_CHACHA20_POLY1305_SHA256
• General information for configuring SRTP is addressed in the “Configuring SRTP” chapter of each of the AudioCodes User’s Manual. For operation in the Approved mode, the CO shall open the Media Security page (Setup menu -> Signaling & Media tab -> Media folder -> Media Security) and ensure that the settings are configured according to the following guidance:
• For the “Media Security Behavior” parameter, the CO shall select “Mandatory” from the dropdown list.
• For the “Aria Protocol Support” parameter, the CO shall ensure it is set to “Disable”. For secure key transfer, the CO shall ensure that derived session keys are transferred to endpoints using TLS (i.e., force TLS). The CO shall click “New” or “Edit” on the SIP Interfaces table (Setup menu -> Signaling & Media tab -> Core Entities folder -> SIP Interfaces) and ensure that the settings on the UDP and TCP ports of each SIP interface are configured according to the following guidance:
• For the “UDP Port” parameter, the CO shall enter “0”.
• For the “TCT Port” parameter, the CO shall enter “0”. General information for configuring remote management is addressed in the ''Configuring Secured (HTTPS) Web'' chapter of the appropriate User’s Manual. For securing RADIUS58 connections for operation in the Approved mode, the CO shall open the Web Settings page (Setup menu -> Administration tab -> Web & CLI folder -> Web Settings) and ensure that the settings are configured according to the following guidance:

Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

• September 26, 2024 For the “'Secured Web Connection (HTTPS)” parameter, the CO shall select “HTTPS Only” from the drop-down list. Configuring the module into Approved mode will zeroize all persistent CSPs and reset the module. 11.3 Startup No additional startup steps are required to be performed by end-users. 11.4 Administrator Guidance The Crypto Officer is responsible for initialization and security-relevant configuration and management of the module. Once installed, commissioned, and configured, the CO is responsible for maintaining the status of the module to ensure that it is running in its Approved mode. The Crypto Officer shall monitor the module’s status regularly. If any irregular activity is noticed, or the module is consistently reporting errors, customers should contact AudioCodes Customer Support. Please refer to section 11 for guidance that the Crypto Officer must follow for the module to be considered running in the Approved mode of operation.

The module provides a default login password for first-time module access for the CO only. The CO is required to change the default login password as part of the initial configuration.

The pre-operational self-tests are automatically performed at power-up. The CO may initiate the pre-operational self-tests by issuing the reset command over the module’s management interfaces or power-cycling the module. Using the CLI, resetting the module is accomplished by issuing the reload now command. Using the Web interface, resetting the module is accomplished from the Maintenance Actions page (Setup menu -> Administration tab -> Maintenance folder -> Maintenance Actions) and clicking the <Reset> button on the toolbar.

There are many CSPs within the module’s cryptographic boundary including symmetric keys, private keys, public keys, and login password hashes. CSPs reside in multiple storage media including RAM, non-volatile flash, and hard disk. All ephemeral keys used by the module are zeroized on reset and power cycle. Private keys and CSPs on the non-volatile flash and hard disk of the module can be zeroized by using a CLI command. The public key used for the image verification test is stored in non-volatile flash and hard disk and cannot be zeroized. Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

September 26, 2024 Using the CLI, keys and CSPs are zeroized using the clear security-files command. Successful return from this command indicates the completion of the zeroization process. The SNMPv3 Authentication Password and SNMPv3 Privacy Password, may be zeroized by the CO entering an allzero value using the Web Interface or CLI or importing a new .ini file with a zero value. Both methods will overwrite and zeroize these CSPs. Completion of the manual entry process or of the .ini file load process indicates the completion of the zeroization process.

On the first power up, the module is, by default, in an unconfigured operational state. During initial configuration and setup, the module is explicitly set to operate in the Approved mode of operation. An authorized operator can access the module via the CLI and determine the mode of the module.

• Using the CLI, the mode status can be viewed by issuing the show system security status command. When the module is properly configured per this Security Policy, the command will return the following message: FIPS mode: Enabled
• Using the Web Interface, the module’s operational status can also be viewed on the Security Settings page (Setup menu -> IP Network tab -> Security folder -> Security Settings). Module operators can also access the module’s versioning information and match it to the versioning information shown on the module’s FIPS validation certificate.
• Using the CLI, the module version can be viewed by issuing the show system version command.
• Using the Web Interface, the version information can be viewed on the Device Information page (Monitor menu -> Monitor tab -> Summary folder -> Device Information).

The list below provides additional guidance for module administrators:

• The CO shall power-cycle the module if the module has encountered a fatal error and becomes nonoperational. If power-cycling the module does not correct the error condition, the module is considered to be compromised or malfunctioned and should be sent back to AudioCodes for repair or replacement.
• The module allows for the loading of new firmware and employs a digital signature verification technique to test the integrity of the image. All SSPs must be zeroized prior to the loading and subsequent execution of new firmware. This can be accomplished via the following CLI command: write factory clear-keys-and-certs Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

September 26, 2024 This can also be accomplished via the Software Upgrade wizard. When using the wizard, ensure that the “Use existing configuration” checkbox on the Load ini file wizard page is cleared and do not select a file to load. This will restore the module configuration back to factory default settings.

• 11.5 To maintain an Approved mode of operation, the CO must ensure that only FIPS-validated firmware is loaded. Any operation of the module after loading non-validated firmware constitutes a departure from this Security Policy. Non-Administrator Guidance The User does not have the ability to configure sensitive information on the module, with the exception of their password. The User must be diligent to pick strong passwords and must not reveal their password to anyone. Additionally, the User should be careful to protect any secret or private keys in their possession. The following list provides additional policies below that must be followed by module operators:
• In the event that the module’s power is lost and then restored, a new key for use with the AES GCM encryption shall be established.
• In order to comply with the key entry requirements described in section 9.5.A of the Implementation Guidance for FIPS PUB 140-3 and the CMVP, entry of plaintext private keys and CSPs using the CLI via the serial port must be accomplished using a non-networked general-purpose computing device.
• The module implements the KAS-ECC-SSC and KAS-FFC-SSC key agreement schemes specified in NIST SP 800-56Arev3. This specification requires that certain checks are performed to provide assurance regarding the keys being used. The following assurance checks are performed by the cryptographic module: o o
• Assurances of domain parameter validity (section 5.5.2 of NIST SP 800-56Arev3) Assurances required by the key pair owner (section 5.6.2.1 of NIST SP 800-56Arev3) Assurances required by the public key recipient (section 5.6.2.2 of NIST SP 800-56Arev3) Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

September 26, 2024 12. Mitigation of Other Attacks The module does not claim to mitigate any attacks beyond the FIPS 140-3 Level 1 requirements for this validation. Therefore, per ISO/IEC 19790:2021 section 7.12, requirements for this section are not applicable. Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

September 26, 2024 Appendix A. Acronyms and Abbreviations Table 14 provides definitions for the acronyms and abbreviations used in this document. Table 14

• Acronyms and Abbreviations Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

N/A September 26, 2024 Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

U U.S. September 26, 2024 Mediant SBCs and Media Gateways ©2024 AudioCodes Ltd.

Prepared by: Corsec Security, Inc.

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

Referenced URLs

• www.audiocodes.com
• www.corsec.com
• https://csrc.nist.gov/Projects/cryptographic-module-validation-