Mediant Virtual Edition SBC and Cloud Edition SBC

Certificate

Approved Algorithms (31)

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

flowchart LR
  %% Deterministic review-risk graph for Mediant Virtual Edition SBC and Cloud Edition SBC
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>Update<br/>Upgrade</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>Status Output</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>HTTPS</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
    R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
    R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
    R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E2["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C5 --> I5 --> R5 --> E5
  C6 --> I6 --> R6 --> E6
  classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
  classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
  classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
  class C2,C3,C5,C6 clue;
  class I2,I3,I5,I6 infer;
  class R2,R3,R5,R6 risk;
  class E2,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Mediant Virtual Edition SBC and Cloud Edition SBC
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>Update<br/>Upgrade</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>Status Output</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>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/>linux<br/>application</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C2,C3,C5,C6 clueLow;

Security Policy, page by page

AudioCodes Ltd. Mediant Virtual Edition SBC and Cloud Edition SBC Software Version: 7.6 FIPS Security Level: 1 Document Version: 0.8 Prepared for: Prepared by: AudioCodes Ltd. Corsec Security, Inc.

1 Hayarden Street 12600 Fair Lakes Circle, Suite 210

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

Abstract This is a non-proprietary Cryptographic Module Security Policy for the Mediant Virtual Edition SBC and Cloud Edition SBC (version: 7.6) from AudioCodes Ltd. (AudioCodes). This Security Policy describes how the Mediant Virtual Edition SBC and Cloud Edition SBC 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 Virtual Edition SBC and Cloud Edition SBC represent two deployments of the same software image that differ only in the product labeling, which is defined by an initialization file parameter that is set by the vendor. Collectively, these deployments are referred to in this document as “Mediant VE and CE SBCs”, “SBCs” or “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 Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

1. General AudioCodes Ltd. (hereafter referred to as AudioCodes) is a leading vendor of advanced networking and media processing solutions for the for the digital workplace. The AudioCodes Mediant family of Session Border Controllers (SBCs) offers a line of versatile IP1 communications platforms that connect VoIP2 and TDM3 networks, built on years of carrier-grade VoIP deployments and expertise. AudioCode’s SBCs 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 Virtual Edition SBC and Cloud Edition SBC each forms 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. It can function as a peering SBC, access SBC, or enterprise SBC. The AudioCodes Mediant Virtual Edition SBC and Cloud Edition SBC are software-based SBCs that may be installed in a virtual environment or hosted in a cloud computing environment. The SBCs provide proven performance, resiliency, and security featuring real-time encryption (VoIP signaling and media traffic), DSP 5 -based media 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 B2BUA6
• SIP Interworking
• Extensive PBX7 interoperability
• Transport Mediation between SIP over UDP8/TCP9/TLS10/WebSocket, IPv4/IPv6, RTP11/SRTP12 SDES13/DTLS14
• Header Manipulation
• Local and far-end NAT15 traversal
• Integrated WebRTC gateway with support for WebSocket, Opus, VP816 video coder, lite ICE17, DTLS, RTP multiplexing, and secure RTCP18 with feedback

1 IP – Internet Protocol

2 VoIP – Voice Over Internet Protocol

3 TDM – Time-Division Multiplexing

SIP

• Session Initiation Protocol DSP
• Digital Signal Processing

6 B2BUA – Back-to-Back User Agent

7 PBX – Private Branch Exchange

UDP – User Datagram Protocol

9 TCP – Transport Control Protocol

10 TLS – Transport Layer Security

11 RTP – Real-time Transport Protocol

SRTP – Secure Real-time Transport Protocol

13 SDES – Session Description Protocol Security Descriptions

14 DTLS – Datagram Transport Layer Security

15 NAT – Network Address Translation

16 VP8 – Video coding format developed by Google

ICE – Interactive Connectivity Establishment

18 RTCP – Real-Time Transport Control Protocol

Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

• Denial of service protection with DoS19/DDoS20 line rate protection,
• VOIP firewall and deep packet inspections with rogue RTP detection and prevention
• Encryption and authentication with support for TLS, DTLS, SRTP, HTTPS21, SSH22, SFTP23, and SNMP24
• Topology hiding and user privacy
• Traffic separation with VLAN 25 /physical interface separation for multiple media, control and OAMP 26 interfaces
• Call Admission Control
• Full Quality of Experience (QoE) monitoring: Jitter, Packet Loss, Delay and MOS27 Management of the SBC is accomplished via the following methods:
• Command Line Interface (CLI), which is accessible using the following means: o remotely via Ethernet management ports over SSH 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
• 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 SBC. 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 PEM28 format. These files contain public keys only, while the matching private key is contained in the associated RSA private key file.

19 DoS – Denial of Service

20 DoS/DDoS – Denial-of-Service/Distributed Denial-of-Service

21 HTTPS – Hypertext Transfer Protocol Secure

23 SFTP – SSH (or Secure) File Transfer Protocol

24 SNMP – Simple Network Management Protocol

25 VLAN – Virtual Local Area Network

26 OAMP – Operations, Administration, Maintenance, and Provisioning

MOS – Mean Opinion Score

28 PEM – Privacy Enhanced Mail

Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

• 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 10 below. The Mediant Virtual Edition SBC and Cloud Edition SBC is validated at the FIPS 140-3 section levels shown in Table

1. Table 1 – Security Levels The module has an overall security level of
2. Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

2. Cryptographic Module Specification The Mediant VE and CE SBCs version 7.6 is a software cryptographic module with a multiple-chip standalone embodiment that meets overall Level 1 FIPS 140-3 requirements. The module is designed to operate within a modifiable operational environment and executes as a virtual appliance. The sections below describe the operational environments, algorithm implementations, module boundary, and modes of operation.

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

• Tested Operational Environments The cryptographic module maintains validation compliance when operating in a virtual machine (VM) with AudioCodes’ custom OS as the guest OS on any compatible GPC using one of the following hypervisors to provide the virtualization layer: Table 3
• Vendor Affirmed Operational Environments Note that the host GPC may be deployed on-prem or in one of the following supported cloud computing environments:
• OpenStack
• Amazon Web Services
• Google Cloud Platform
• Microsoft Azure The CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when ported to an operational environment not listed on the validation certificate.

The module employs the cryptographic algorithm implementations from the sources listed in Table 4 below. Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

Table 4

• Cryptographic Algorithm Sources Number Validation certificates for each Approved security function are listed in Table 5. 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 5
• Approved Algorithms

29 SSH – Secure Shell

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

31 CVL – Component Validation List

RFC – Request for Comments

33 TLS – Transport Layer Security

Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

34 CCM – Counter with Cipher Block Chaining - Message Authentication Code

36 DRBG – Deterministic Random Bit Generator

38 ECDSA – Elliptic Curve Digital Signature Algorithm

Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

39 KAS-ECC-SSC – Key Agreement Scheme - Elliptic Curve Cryptography - Shared Secret Computation

KAS-FFC-SSC – Key Agreement Scheme - Finite Field Cryptography - Shared Secret Computation

41 RSA – Rivest Shamir Adleman

Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

D.G. D.G. Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

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 internal to the module (the module requests a minimum number of 256 bits of Table 6 – 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.

As a virtual appliance, the cryptographic module has no physical characteristics, it makes use of the physical interfaces of the server upon which the virtual appliance is installed. Figure 1 below illustrates a block diagram of a typical GPC and the module’s physical perimeter. Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

Hardware Network DVD RAM Management Interface HDD Clock SCSI/SATA Generator Controller LEDs/LCD CPU Serial I/O Hub Audio Cache PCI/PCIe Slots USB BIOS Power Graphics PCI/PCIe Interface Controller Slots External Power Supply KEY: BIOS

• Basic Input/Output System PCIe
• PCI express Plaintext Data CPU
• Central Processing Unit HDD
• Hard Disk Drive Encrypted Data SATA
• Serial Advanced Technology Attachment DVD
• Digital Video Disc Control Input SCSI
• Small Computer System Interface USB
• Universal Serial Bus Status Output PCI
• Peripheral Component Interconnect RAM
• Random Access Memory Physical Perimeter LED
• Light Emitting Diode LCD
• Liquid Crystal Display Figure 1
• GPC Block Diagram The module consists of binary packaged into an executable that can be run in a virtual environment. The hypervisor controls and directs all interactions between the module and the physical appliance, and it is responsible for mapping the module’s virtual interfaces to the host server’s physical interfaces. The physical perimeter of the cryptographic module is defined by the hard enclosure around the server on which it runs. The cryptographic boundary of the module (shown by the red dotted line in Figure 2 below) consists of the AudioCodes Mediant SBC application and AudioCodes’ custom OS running in a virtual machine. The module’s physical perimeter is illustrated by the black dotted line. Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

Virtual Machine                 Virtual Machine   Virtual Machine Mediant VE/CE SBCs                   Application       Application Custom Linux based on                      Guest OS          Guest OS CentOS Stream 8 KEY: Cryptographic Boundary                                                           Vmware ESXi 7.0 Physical Perimeter Data Input                                                         Server Hardware Data Output Control Input                               CPU                Memory            Storage        Ports Status Output System Calls Host Device Figure 2 – AudioCodes Mediant VE and CE SBCs Cryptographic Boundary There are no module components excluded from the requirements.

The module supports the Approved mode of operation only. When installed, configured, and operated according to this Security Policy, the module does not support a non-Approved mode of operation. Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

3. 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. As a software cryptographic module, the module has no physical characteristics. Its interfaces are logical; the hypervisor provides virtualized ports and interfaces for the module that map to the host server’s physical ports and interfaces. The module relies on the physical and electrical characteristics, manual controls, and physical indicators of the host server. The module was tested and validated on an HP ProLiant DL360 Gen10 server. The following is a list of the physical interfaces implemented on the tested host server:

• 1 GbE and 10 GbE SFP+ Ethernet ports
• Serial port
• Video port
• LEDs44
• AC45 Power port The virtual machine hosting the module virtualizes the physical interfaces. Table 7 below provides the mapping of the FIPS-defined interfaces and the module’s physical and logical interfaces. Table 7
• Ports and Interfaces LED
• Light-Emitting Diode

45 AC – Alternating Current

Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

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

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 8 below lists the supported roles, along with the services (including input and output) available to each role. Table 8
• Roles, Service Commands, Input and Output Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

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 (outside the module boundary but within the physical perimeter) 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.

The module has the capability to load software in the form of a complete image replacement from an external source. As such a replacement will constitute a new module, only FIPS-validated software may be loaded to maintain the module’s validation. Services and functions provided by the newly loaded software image are not performed until the pre-operational self-tests have executed successfully via a power-on reset. All software 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 software image is ignored and the previous-loaded software 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 software.

Descriptions of the services available to authenticated module operators are provided in Table 9 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 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:

• 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. Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

Table 9 – Approved Services Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

46 CA – Certificate Authority

Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

*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 Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

5. Software/Firmware Security The module software takes the form of a single software 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 software. 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 issuing a reset/reboot command over its management interfaces. Also, the module can be made to perform pre-operational self-tests by rebooting or power-cycling the module’s VM or host device (when using this method, the operator is not required to assume an authorized role). Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

6. Operational Environment The module is designed to operate within a modifiable operational environment. The module was tested and found to be compliant with FIPS 140-3 requirements on the operational environment identified in Table
7. The cryptographic module has control over its own SSPs. The process and memory management functionality of the guest OS and the hypervisor prevents unauthorized access to plaintext private and secret keys, intermediate key generation values and other SSPs by external processes during module execution. The module only allows access to SSPs through its well-defined interfaces. The operational environment provides the capability to separate individual application processes from each other by preventing uncontrolled access to CSPs and uncontrolled modifications of SSPs regardless of whether this data is in the process memory or stored on virtual storage within the operational environment. Processes that are spawned by the module are owned by the module and are not owned by external processes or operators. Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

7. Physical Security The cryptographic module is software module and does not include physical security mechanisms. Therefore, per ISO/IEC 19790:2021 section 7.7.1, the requirements for physical security are not applicable. Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

8. Non-Invasive Security This section is not applicable. There are currently no approved non-invasive mitigation techniques referenced in ISO/IEC 19790:2021 Annex F. Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

9. Sensitive Security Parameter Management The module supports the keys and other SSPs listed in Table 10 below. Table 10 – 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 Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

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. 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 Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

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
• RFC5647

Table 11 below specifies the module’s entropy sources. Table 11 – Non-Deterministic Random Number Generation Specification Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

10. Self-Tests Both pre-operational and conditional self-tests are performed by the module. Pre-operational tests are performed between the time a cryptographic module is powered on 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.

Pre-operational self-tests are executed automatically at module power-up without action from the module operator. The module performs the following pre-operational self-test(s): • Software Integrity Test on the module software image (using ECDSA P-256 with SHA2-256 digital signature verification)

The module performs the following conditional self-tests:

• Conditional cryptographic algorithm self-tests (CASTs)
• Crypto Library:
• AES ECB encrypt KAT48 (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

48 KAT – Known Answer Test

Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

• Entropy “Stuck” Test
• Entropy Repetition Count Test (performed over 1024 samples)
• Entropy Adaptive Proportion Test (performed over 1024 samples)
• KDF Library:
• TLS v1.2 KDF KAT
• TLS v1.3 KDF KAT
• SSH KDF KAT 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 software integrity test are performed prior to the integrity test itself; all other CASTs are executed immediately after the successful completion of the software 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 software load test using ECDSA P-256 signature verification (upon loading of a new image)

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 image verification 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 Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

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

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

The module is available as a file containing the virtual appliance image. The Crypto Officer is responsible for all initial setup activities, including configuring the virtual machine, installing the guest operating system, and installing the Mediant SBC application software. For detailed guidance regarding these activities, please see the AudioCodes Installation Manual, Mediant Virtual Edition (VE) SBC. To setup the module, the CO must follow the instructions found under the document entry “Installing Mediant VE SBC on VMware vSphere ESXi” for the Virtual Edition. Once the module is installed with network settings properly configured, the Crypto Officer must then enable Approved mode operation.

The CO shall configure the module for Approved mode. operation This ensures that the system will use only Approved cryptographic algorithms and key strengths. To configure the module for operation in the Approved mode, 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 Software SBC, Virtual (VE), Cloud (CE), and Server (SE) Editions, Version 7.6 To configure the module for operation in the Approved mode, the CO must perform the following actions:
• The CO must enable Approved mode. Using the CLI, the CO must issue the FIPSmode enable command. Using the Web Interface, the module’s 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 Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

• 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 AudioCodes User’s Manual. For operation in the Approved mode, 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 User’s Manual. For securing RADIUS 49 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:

49 RADIUS – Remote Authentication Dial In User Service

Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

o 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.

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

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 an 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 host server or VM. 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 virtual RAM, as well as on virtual storage media within the VM. All ephemeral keys used by the module are zeroized on reset and power cycle. Private keys and CSPs on the virtual machine’s flash and hard disk can be zeroized by using a CLI command. The public key used for the image verification test is stored in the virtual machine’s flash and hard disk and cannot be zeroized. Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

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. Authorized operators 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 correlate 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). When executing on an on-prem virtual environment, the module name will be reported as “Mediant Virtual Edition”. When executing in a cloud-based environment, the module name will be reported as “Mediant Cloud Edition”.

The list below provides additional guidance for module administrators:

• The CO shall re-instantiate 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 software and employs a digital signature verification technique to test its integrity. All SSPs must be zeroized prior to the loading and subsequent execution of new software via the following CLI command: Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

write factory clear-keys-and-certs 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. • To maintain an Approved mode of operation, the CO must ensure that only FIPS-validated software is loaded. Any operation of the module after loading non-validated software constitutes a departure from this Security Policy.

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-FFC-SSC and KAS-ECC-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:
• 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 Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

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 Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

Appendix A. Acronyms and Abbreviations Table 12 provides definitions for the acronyms and abbreviations used in this document. Table 12 – Acronyms and Abbreviations Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

Mediant Virtual Edition SBC and Cloud Edition SBC 7.6 ©2024 AudioCodes Ltd.

Prepared by: Corsec Security, Inc.

12600 Fair Lakes Circle, Suite 210

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