SBC SWe Session Border Controller

Certificate

Approved Algorithms (45)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for SBC SWe Session Border Controller
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[high] Firmware update / recovery<br/>/ rollback services<br/><i>Manage SBC license<br/>Upgrade firmware<br/>Soft Error</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>AES for SNMPv3<br/>Manage SBC license<br/>Configure the SBC system</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>IKEV</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    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."]
    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["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"]
    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 SBC SWe Session Border Controller
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[high] Firmware update / recovery / rollback services<br/><i>Manage SBC license<br/>Upgrade firmware<br/>Soft Error</i><br/>src: securityPolicy.services"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>AES for SNMPv3<br/>Manage SBC license<br/>Configure the SBC system</i><br/>src: securityPolicy.services"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<br/>IKEV</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>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 clueHigh;
  class C5,C6 clueLow;

Security Policy, page by page

Ribbon Communications, Inc. SBC SWe Session Border Controller Version: 10.01.06 FIPS Security Level: 1 Document Version: 0.6 Prepared for: Prepared by: Ribbon Communications, Inc.

Westford, MA 01886 United States of America Corsec Security, Inc.

Fairfax, VA 22033 United States of America Phone: +1 855 467 6687 www.ribboncommunications.com Phone: +1 703 267 6050 www.corsec.com

July 8, 2025 Table of Contents 1. 1.1 1.2 2. 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 3. 3.1 4. 4.1 4.2 4.3 4.4 4.5 5. 5.1 5.2 6. 6.1 7. 8. 9. 9.1 9.2 9.3 9.4 9.5 SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

10.3 10.4 10.5 July 8, 2025 SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 List of Tables List of Figures SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc. July 8, 2025

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 Ribbon website (www.ribboncommunications.com) contains information on the full line of services and solutions from Ribbon.
• 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.

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. 1.2 Security Levels The SBC SWe Session Border Controller is validated at the FIPS 140-3 section levels shown in the table below. Table 1: Security Levels N/A N/A N/A SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

The module has an overall security level of 1. SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc. July 8, 2025

2. Cryptographic Module Specification 2.1 Description July 8, 2025

Ribbon Communications, Inc. (hereafter referred to as Ribbon) is a leader in IP 1 networking with proven expertise in delivering secure, reliable and scalable next-generation infrastructure and subscriber solutions. The Ribbon line of Session Border Controller (SBC) solutions help mid-sized and large enterprises take advantage of cost-saving SIP 2 trunking services by securing their network from IP-based attacks, unifying SIP-based communications and controlling traffic in the network. The Ribbon SBC SWe Session Border Controller (SBC SWe) is a software-based, cloud-optimized SBC architected to enable and secure real-time communications in the cloud. Starting at 25 sessions and scaling to tens of thousands per instance, the unique architecture of the SBC SWe allows customers to define where on the performance curve their network needs to reside. The SBC SWe uses a “microservices” architecture designed to separate signaling, media, and transcoding to optimize virtual network resources. It also supports on-demand auto-scaling, with a feedback loop using Key Performance Indicators and the Ribbon Virtual Network Function (VNF) Manager. The SBC SWe features the same code base, resiliency, media transcoding, and security technology found in Ribbon’s hardware-based SBC 5000 Series and SBC 7000 Session Border Controllers. However, as a software solution, customers can deploy the SBC SWe as a VNF on industry-standard servers in a data center environment using a hypervisor, as a VNF in an OpenStack cloud infrastructure, or as a VNF on public cloud or hosted services. Some of the network and security features provided by the SBC SWe are:

• Built-in media transcoding capability Industry-leading user interface for ease of management and ongoing operations Common service orchestration with Ribbon’s centralized call routing and policy management for networkwide intelligence and control Enhanced security/encryption services to protect privacy and ensure compliance Load-balancing of Real Time Communications (RTC) traffic across the cloud for network efficiency Integrated analytics of network traffic to drive orchestration of SBC VNFs TLS 3, IPsec (IKEv1 4) for signaling encryption Secure RTP/RTCP 5 for media encryption

IKEv1

• Internet Key Exchange version 1

SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

• July 8, 2025 Support for large number of protocols including IPv4, IPv6, IPv4/IPv6 interworking, SSH 6, SFTP 7, SNMP 8, HTTPS9, RTP/RTCP, UDP 10, TCP 11, DNS 12, and ENUM 13 Figure 1 below illustrates a typical deployment scenario of the module. Home Users Application Service SBC SWe Public Internet / ISP or Metropolitan Backhaul Enterprise Optional High-Availability/ Redundancy Service Provider’s Core Network SBC SWe Application Service Figure 1. Typical Deployment of SBC SWe in a Network Management of the SBC SWe is accomplished using the following tools:
• Command Line Interface (CLI), which is accessible remotely via SSH over Ethernet management ports.
• Web-based Graphical User Interface (GUI) called Embedded Management Application (EMA), which is accessible remotely via HTTPS over Ethernet management ports. The module also provides an SNMPv3 14 interface for remote management and non-security relevant information about the module’s state and statistics. In addition, the module provides an SFTP interface for transferring the Security Event log, the System Event log, release packages, tone and announcement files, CDR 15 logs, and configuration files over the virtual machine’s Ethernet management ports. 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 SWe.

SNMPv3

• Simple Network Management Protocol version 3

SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 To support TLS, the module employs the following certificate management techniques:

• Local
• Local certificates are credentials belonging to the SBC SWe itself, which it presents to peers in order to prove its identity. Local certificate files must be downloaded to the module before installing the certificates.
• Local-Internal
• The SBC SWe generates and installs RSA key pairs and generates Certificate Signing Requests (CSR) internally. The CSR is sent to a CA, and the issued certificate is then installed on the SBC.
• Remote
• Remote certificates are credentials belonging to CAs. The CA certificates contain public keys only; they do not contain the associated private keys. The CA certificates are Distinguished Encoding Rules (DER) format files.

The SBC SWe Session Border Controller 10.01.06 is a Software module.

The SBC SWe Session Border Controller has a MultiChipStand embodiment.

The module does not have any additional characteristics.

As a software appliance, the module has no physical components. Since the module has no physical characteristics, it makes use of the physical interfaces of the server hosting the virtual environment upon which the module is installed. The hypervisor controls and directs all interactions between the module and the operator, and it is responsible for mapping the module’s virtual interfaces to the host server’s physical interfaces. The module’s cryptographic boundary consists of all functionalities contained within the module’s compiled source code. This comprises the following primary components:

• SBC SWe application software Ribbon’s proprietary ConnexIP operating system (with crypto libraries) SonusDB (with configuration files and PostGRES) HMAC digest files (for integrity checking) The cryptographic boundary is the contiguous perimeter that surrounds all memory-mapped functionality provided by the module when loaded and stored in the host device’s memory. The module is entirely contained within the physical perimeter. SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 Figure 2 shows the logical block diagram of the module executing in memory and its interactions with surrounding software components, as well as the module’s physical perimeter and cryptographic boundary. Virtual Machine HMAC digests SBC SWe application Virtual Machine Virtual Machine Application Application Guest OS Guest OS SonusDB ConnexIP OS KEY: Cryptographic Boundary Physical Perimeter Data Input Data Output Control Input Status Output System Calls Hypervisor Server Hardware Figure 2. Module Block Diagram (with Cryptographic Boundary)

(TOEPP) The physical perimeter of the cryptographic module is defined by the hard enclosure around the GPC on which it runs. Figure 3 is a diagram illustrating the hardware components of a GPC (the dashed line surrounding the hardware components represents the module’s physical perimeter and identifies the hardware with which the processors interface. SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

Hardware Management July 8, 2025 RAM DVD Network Interface HDD Clock Generator SCSI/SATA Controller LEDs/LCD North Bridge Serial CPU(s) Audio Cache Power Interface PCI/PCIe Slots Graphics Controller South Bridge USB PCI/PCIe Slots BIOS External Power Supply Plaintext data Encrypted data Control input Status output Physical Perimeter BIOS

• Basic Input/Output System CPU
• Central Processing Unit DVD
• Digital Video Disc HDD
• Hard Disk Drive LCD
• Liquid Crystal Display LED
• Light-Emitting Diode KEY: PCI
• Peripheral Component Interconnect PCIe
• PCI express RAM
• Random Access Memory SATA
• Serial Advanced Technology Attachment SCSI
• Small Computer System Interface USB
• Universal Serial Bus Figure 3. Block Diagram of a GPC 2.2 Tested and Vendor Affirmed Module Version and Identification

This section is only applicable for hardware modules. N/A for this module.

(Executable Code Sets) The module has the following executable code sets shown in the table below. SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 Table 2: Tested Module Identification

• Software, Firmware, Hybrid (Executable Code Sets)

The module does not have hybrid disjoint hardware. N/A for this module.

Hybrid The module was tested and found to be compliant with FIPS 140-3 requirements on the environments listed in the table below. Table 3: Tested Operational Environments - Software, Firmware, Hybrid The module is designed to utilize AES-NI 16 extended instruction set when available by the host platform’s CPU for processor algorithm acceleration (PAA) of its AES implementation.

Firmware, Hybrid The cryptographic module maintains validation compliance when operating in a VM with ConnexIP as the guest OS on any compatible GPC using a KVM hypervisor to provide the virtualization layer. Note that the host GPC may be deployed on-prem or in any of the following supported cloud environments:

July 8, 2025 Table 4: Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid 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. 2.3 Excluded Components The module does not exclude any components from the requirements. 2.4

mode of operation only; non-Approved operations are not supported. Table 5: Modes List and Description 2.5 Algorithms

The module employs cryptographic algorithm implementations from the following sources:

• Ribbon Cryptographic Library version 10 (Cert. A5061) Ribbon Entropy Library version 10 (Cert. A4087) Ribbon IKE KDF17 Library version 10 (Cert. A5062) Ribbon SRTP 18 KDF Library (IPP 19) version 10 (Cert. A5063) Ribbon SSH KDF Library version 10 (Cert. A5064) Ribbon TLS KDF Library version 10 (Cert. A5065) The module implements the Approved algorithms listed in the table below. Ribbon Cryptographic Library

SRTP

• Secure Real-Time Transport Protocol

SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 Table 6: Approved Algorithms - Ribbon Cryptographic Library Ribbon SRTP KDF Library (IPP) Table 7: Approved Algorithms - Ribbon SRTP KDF Library (IPP) Ribbon IKE KDF Library Table 8: Approved Algorithms Properties SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 Table 9: Approved Algorithms - Ribbon IKE KDF Library Table 10: Approved Algorithms - Ribbon IKE KDF Library Table 11: Approved Algorithms - Ribbon SSH KDF Library Table 12: Approved Algorithms - Ribbon TLS KDF Library Table 13: Approved Algorithms - Ribbon Entropy Library

The vendor affirms the following cryptographic security methods in the table below: Table 14: Vendor-Affirmed Algorithms

The table below lists the non-Approved algorithms implemented by the module that are allowed for use in the Approved mode of operation. N/A for this module. SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

The module does not offer any non-Approved algorithms allowed in the Approved mode of operation with no security claimed. N/A for this module.

The module does not offer non-Approved algorithms not allowed in the Approved mode of operation. N/A for this module. 2.6 Security Function Implementations The table below lists the security function implementations for this module. SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 2.7 Table 15: Security Function Implementations Algorithm Specific Information The following is algorithm-specific information related to the module:

• AES-GCM: The AES-GCM IV 20 is used in the following protocols:
• For TLS v1.2, the module supports acceptable AES-GCM cipher suites from section 3.3.1 of NIST SP 800-52rev2. Per scenario 1 in FIPS 140-3 IG C.H, the mechanism for IV generation 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. The module will then trigger a handshake to establish a new encryption key.
• For SRTP, the AES-GCM IV is constructed at its entirety internally deterministically per section

8.2.1 of NIST SP 800-38D. In compliance with RFC 7714, the 96-bit IV is formed by first

concatenating 16 bits of zeroes, the 32-bit Synchronization Source identifier, the 32-bit rollover counter, and the 16-octet sequence number. As described in scenario 3 of FIPS 140-3 IG C.H and, the (key, IV) collision probability does not exceed 2-32 for a given key distributed to one or more cryptographic modules. In the event that the module’s power is lost and then restored, the CO shall establish a new key for use with AES-GCM encryption/decryption.

• PBKDF2: The module uses PBKDF2 option 1a from section 5.4 of NIST SP 800-132. This function takes an input salt that is 128 bits in length with a passphrase containing at least eight characters (in accordance with the module’s password complexity requirements) and produces a random value of 128 bits. The underlying pseudorandom function used in this derivation is SHA-1. The function has an iteration count of 2048. This iteration count allows for user-acceptable key generation times while still doubling the recommended minimum count (1000).

SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 The length of the password/passphrase used in the PBKDF shall be at least 20 characters, and shall consist of lowercase, uppercase, and numeric characters. The upper bound for the probability of guessing the value is estimated to be 1/6220 = 10-36, which is less than 2-112. As specified in NIST SP 800-132, keys derived from passwords/passphrases may only be used in storage applications.

• DH and ECDH: The module implements the DH and ECDH 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 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) ECDSA: Per FIPS 140-3 Implementation Guidance C.K, there is currently no scheduled transition away from elliptic curves over binary fields (i.e., K-233, B-233, K-283, B-283, K-409, B-409, K-571, B-571). However, these curves are now deprecated, and it is strongly recommended to use the SP-800-186-defined prime curves (i.e., P-224, P-256, P-384, P-521) for the generation of the ECDSA signatures. Despite their deprecation status, these curves are still considered Approved. 2.8 RNG and Entropy The module uses its Approved DRBG to generate cryptographic keys and seeds used to generate cryptographic keys. The resulting symmetric key or generated seed is an unmodified output from the DRBG. The table below specifies the module’s entropy certificates. Table 16: Entropy Certificates The table below specifies the module’s entropy sources. NonPhysical 2.9 Table 17: Entropy Sources Key Generation The following is a list of key generation methods that the module implements: SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

• 2.10 July 8, 2025 CKG ECDSA KeyGen RSA KeyGen Key Establishment

The following is a list of key agreement methods that the module implements:

• IKEv1 with DH or ECDH for Key Agreement IKEv2 with DH or ECDH for Key Agreement SRTP with DH or ECDH for Key Agreement SSH with DH or ECDH for Key Agreement TLS v1.2 with DH or ECDH for Key Agreement The module implements the DH and ECDH 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) Key confirmation is not supported by the module.

Key transport information does not apply to the module. 2.11 Industry Protocols The module employs the following industry protocols:

• IPsec (IKEv1 and IKEv2) SRTP SSH TLS v1.2 The KDFs associated with these protocols shall only be used within the context of their respective protocols. No parts of these protocols, other than the Approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP. SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 3. Cryptographic Module Interfaces 3.1 Ports and Interfaces The module supports the following logical interfaces:

• As a virtual appliance, 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 consists of an application and OS running in a virtual machine. The OS (ConnexIP) communicates directly with the hypervisor, which virtualizes ports and interfaces for the module. A mapping of the virtual ports and interfaces to the defined logical interfaces is provided in the table below. Note that the module does not output control information, and thus has no specified control output interface. N/A N/A N/A N/A N/A Table 18: Ports and Interfaces SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025

4. Roles, Services, and Authentication 4.1 Authentication Methods Module operators are required to authenticate to the module for assumption of an authorized role. The module supports identity-based authentication. Role assumption is implicit, as module operator roles are assigned to their The module can support multiple operator sessions concurrently from multiple client devices. The maximum number of simultaneous sessions allowed per operator can be configured for any number from 1 to
5. Each session remains active (logged in) and secured until the operator logs out or is automatically logged out from inactivity. When the module is powered off, result of any previous authentication will be cleared, and module operators will need to re-authenticate in order to re-assume their respective roles. The table below lists the authentication methods and the strength of the authentication mechanisms. Table 19: Authentication Methods The strength objectives of the authentication mechanisms are as follows: • For each attempt to use an authentication mechanism, the probability shall be less than one in 1,000,000 that a random attempt will succeed or a false acceptance will occur. • For multiple attempts to use an authentication mechanism during a one-minute period, the probability shall be less than one in 100,000 that a random attempt will succeed or a false acceptance will occur. To meet the stated strength objectives for password-based authentication, password policies shall be configured such that all passwords shall require: • • • Between 8 and 24 characters At least one lowercase letter At least one uppercase letter SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

• July 8, 2025 At least one digit At least one special character The Crypto Officer shall set the module’s password policies after the initial setup of the module. Password policies can be set via the EMA or CLI.
• Using the CLI, password policies are configured using the following command: % set system admin <SYSTEM NAME> passwordRules
• Using the EMA, password policies are configured by navigating to Administration -> Users and Application Management -> Application Management from the SBC main screen. The CO shall ensure that the checkbox for “Use Separate Password Rules for Administrators” is unchecked. Once set, the module enforces the password policies on all subsequent attempts to change a password. The CO shall also ensure that the default brute force password attack mitigation remains enabled. Per the default settings, the module will lock an account for 30 seconds after three (3) consecutive failed login attempts. The CO can view and/or configure the brute force password attack settings by navigating to the Administration -> Users and Application Management -> Application Management window from the Using the EMA SBC main screen. Using the CLI, the CO can view and/or configure the brute force password attack settings using the following command: % show system admin <systemName> accountManagement bruteForceAttack 4.2 Roles The module supports the following vendor-defined groups and capabilities:
• Calea
• Read-write access to Lawful Intercept tables and Read access to other tables. Only an Admin user can add or remove user from this group. Only one user named “Calea” is allowed in this group, and the “Calea” user cannot be part of any other group.
• functions only available to admin users.
• SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

• July 8, 2025 Security Auditor
• Read-only access to view the security logs and management audit logs. The commands executed by the Security Auditor are logged in the Management Audit log. The module supports two defined roles that operators may assume:
• Crypto Officer
• The CO is responsible for initializing the module for first use, which includes the configuration of passwords, public and private keys, and other SSPs. The CO is also responsible for the management of all keys and SSPs, including their zeroization, and is the only operator that can install and configure the module for Approved mode of operation. The CO has access to all User services. The CO role consists of the vendordefined roles “Administrator”, “Calea”, “Field Service”, and “Operator”.
• User
• 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 and SSH. Users can also change their own passwords. The User role consists of the vendor-defined roles “Guest” and “Security Auditor”. The table below lists the supported roles. Table 20: Roles 4.3 Approved Services Descriptions of the services available are provided in the table below. When configured according to the guidance in section 11, the module only executes in an Approved mode of operation. Thus, as allowed per section C.H 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 FIPS mode indicator) and an implicit indication (via the successful completion of the service). The keys and Sensitive Security Parameters (SSPs) listed in the table indicate the type of access required using the following notation:
• G = Generate: The module generates or derives the SSP. R = Read: The SSP is read from the module (e.g., the SSP is output). W = Write: The SSP is updated, imported, or written to the module. E = Execute: The module uses the SSP in performing a cryptographic operation. n/a n/a SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 n/a n/a n/a n/a n/a n/a n/a n/a n/a R,W G,E Z Z W SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 n/a n/a n/a n/a W W n/a Perform ondemand selftests SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 G,E G,E G,E G,E G,E SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 G,E SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 G,E G,R G,W,E G,R G G,E G,R G,W,E G,R G SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 G,E G,R G,W,E G,R G G,E G,E G,R G,W,E G,R G,E SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 G,E SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 G,E G,R G,W,E G,R,W G G,E G,R G,W,E G,R,W G SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 n/a n/a manual ondemand selftests n/a n/a n/a 4.4 W Table 21: Approved Services Non-Approved Services The module does not provide any non-Approved services in the non-Approved mode of operation. 4.5 External Software/Firmware Loaded The cryptographic module has the capability of loading software from an external source. All loads comprise a complete image replacement that replaces the existing module image in its entirety, thus forming a completely public key is loaded in write-protected flash at the factory). If the check fails, the new software is ignored and the current software remains loaded. If successful, the module will force an automatic reboot and will perform the required pre-operational integrity test using HMAC SHA digests. Per FIPS 140-3 IG 10.3.F, the integrity test inherently meets the firmware load test requirement when the load constitutes a full image replacement. SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 Only validated software may be loaded to maintain the module’s validation. The new image shall include updated versioning information to represent the newly loaded image. Prior to any execution of the new image, module operators shall zeroize all persistent keys using one of the methods described in section 9.3. All ephemeral keys are zeroized on module reboot. SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

5. Software/Firmware Security 5.1 Integrity Techniques July 8, 2025 At module start-up, all software components of the cryptographic module are verified using an approved integrity technique implemented within the cryptographic module itself. The module employs a series of HMAC SHA2-256 digests; unsuccessful verification of any of the digest values will cause the module to enter a critical error state. 5.2 Initiate on Demand The CO can initiate the pre-operational integrity tests on demand by issuing a reset/reboot command over the module’s management interfaces. Also, the module can be made to perform pre-operational self-tests by rebooting or power-cycling the module’s VM manually (when using this method, the operator is not required to assume an authorized role). SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

6. Operational Environment 6.1 Operational Environment Type and Requirements July 8, 2025 The SBC SWe Session Border Controller comprises a software cryptographic library that executes in a Modifiable operational environment. The module was tested and found to be compliant with FIPS 140-3 requirements on a Dell EMC PowerEdge r740 server with an Intel Xeon processor running Ribbon’s ConnexIP OS as the guest OS in a VM managed by a VMware ESXi 7.0 hypervisor. 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 persistent storage within the operational environment. Processes that are spawned by the module are owned by the module and are not owned by external processes or operators. SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

7. July 8, 2025 Physical Security The SBC SWe is a multi-chip standalone software cryptographic module and does not include physical security mechanisms. Therefore, per ISO/IEC 19790:2012 section 7.7.1, the requirements for physical security are not applicable. SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

8. July 8, 2025 Non-Invasive Security This section is not applicable. There are currently no approved non-invasive mitigation techniques references in Annex F of ISO/IEC 19790:2012. SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 9. Sensitive Security Parameters Management 9.1 Storage Areas The table below lists sensitive security parameters (SSPs) storage areas for this module. Section 9.4 selects from the storage areas listed and specifies the appropriate parameter in the “Storage” column if applicable to a specific SSP. 9.2 Table 22: Storage Areas SSP Input-Output Methods The table below lists SSP input and output methods for this module. Section 9.4 selects from the input and output methods listed and specifies the appropriate parameter in the “Inputs/Outputs” column if applicable to a specific SSP. Table 23: SSP Input-Output Methods SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

9.3 July 8, 2025 SSP Zeroization Methods The table below lists SSP zeroization methods for this module. Section 9.4 selects from the zeroization methods listed and specifies the appropriate parameter in the “Zeroization” column if applicable to a specific SSP. Table 24: SSP Zeroization Methods 9.4 The module supports the keys and other SSPs listed in the tables below. Note that all SSP imports and exports are electronic and performed within the TOEPP. SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

n/a - n/a July 8, 2025 n/a - n/a n/a - n/a SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 n/a - n/a n/a - n/a n/a - n/a n/a - n/a SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 n/a - n/a n/a - n/a n/a - n/a Table 25: SSP Table 1 SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

9.5 July 8, 2025 N/A Table 26: SSP Table 2 Transitions The following list specifies applicable transition periods or timeframes where an algorithm or key length transitions from Approved to non-Approved:

• SHA-1: The module includes an implementation of SHA-1 for hashing and digital signature verification. This implementation will be non-Approved for all uses starting January 1, 2031. SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 10. Self-Tests The module performs pre-operational self-tests and conditional self-tests. Pre-operational tests are performed between the time the cryptographic module is instantiated and before the module transitions to the operational state. Conditional self-tests are performed by the module during module operation when certain conditions exist. The following sections list the self-tests performed by the module, their expected error status, and the error resolutions. 10.1 Pre-Operational Self-Tests The module performs the following pre-operational self-test(s): 10.2 Table 27: Pre-Operational Self-Tests Conditional Self-Tests The module performs the following conditional self-tests: SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 "Z" "Z" SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 Table 28: Conditional Self-Tests 10.3 Periodic Self-Test Information The operator may conduct on demand by rebooting or power-cycling the module’s VM or host server. On-demand self-test information for pre-operational and conditional self-tests are shown in the tables below. SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 Table 29: Pre-Operational Periodic Information Table 30: Conditional Periodic Information SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

10.4 July 8, 2025 Error States The table below describes the error states and status indicators of the module. 10.5 Table 31: Error States Operator Initiation of Self-Tests The operator may initiate self-tests on demand by issuing the reboot command or power cycling the module’s VM or host server. SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 11. Life-Cycle Assurance 11.1 Installation, Initialization, and Startup Procedures

The module is in an unconfigured operational state upon the initial power-up. The Crypto Officer shall be responsible for all initial setup activities, including configuring the virtual machine, installing the guest operating system, and installing the SBC SWe application software. For detailed guidance regarding these activities, please see the SBC Core 10.1.x Documentation webpage on Ribbon’s online Documentation and Support Portal and refer to the following document entries:

• EMA User Guide CLI Reference Guide Installing SBC SWe on Virtual and Private Cloud Environments The SBC SWe Session Border Controller is available as a software package that includes both the application software and the operating system. It can be downloaded from the Ribbon Support Portal (login credentials are required for portal access). The SBC SWe must be installed on a VMware-based virtual environment. The CO must follow the applicable guidance found under the document entry “Installing SBC SWe on VMware”, which includes:
• creating the virtual machine uploading the SBC software installing the SBC OS installing the SBC application in a standalone or high availability configuration The next step is to configure the module’s application software. The CO must follow the instructions under the document entry “SBC SWe Configuration Procedures”, which provides detailed guidance for setting deploymentspecific system settings and configuring various module features. Once the module is installed with network settings properly configured, the Crypto Officer must then initialize the module into Approved mode.

Prior to initializing the module for operation in the Approved mode, SNMPv3 must be reconfigured. All trap targets with securityLevel set for authPriv and authNoPriv must be disabled. The following steps using the CLI provide an example: % show oam snmp trapTarget EMS_-10.54.71.176 ipAddress 10.54.71.176; port 162; trapType v3; targetUsername emstrapuser; SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 targetSecurityLevel authPriv; state enabled; % set oam snmp trapTarget EMS_-10.54.71.176 state disabled % commit To initialize the module for operation in the Approved mode, the CO may use the CLI or the EMA. The sections below describe these initialization methods. 11.1.2.1 Initialization using CLI When using the CLI, the CO shall complete the following procedure:

1. Log in to the CLI using the default username “admin” and password “admin”.
2. Switch to “configure private” mode using the following command: > configure private
3. Execute the following commands: % set profiles security tlsProfile defaultTlsProfile v1_0 disabled v1_1 disabled v1_2 enabled % set profiles security EmaTlsProfile defaultEmaTlsProfile v1_0 disabled v1_1 disabled v1_2 enabled % set profiles security ikeProtectionProfile AesSha1IkeProfile algorithms dhGroup modp2048 % set oam snmp version v3only % set system admin <system_name> fips-140-3 mode enabled % commit NOTE: Once the “fips-140-3 mode” is set to ‘enabled’, it cannot be disabled through the configuration. A fresh software installation is required to set the operational mode back to ‘disabled’. Setting “fips-140-3 mode” to ‘enabled’ accomplishes the following: • • • regenerates all SSH keys. regenerates encryption keys used by the system configuration database. zeroizes all persistent CSPs from the system and causes the server to reboot after confirmation. 11.1.2.2 Initialization using EMA + CLI The EMA does not include all of the commands necessary to enable/disable the Approved mode. The user must use the CLI to complete the procedure. When using the EMA and CLI, the CO shall complete the following procedure:
4. Log in to the EMA using the default username “admin” and password “admin”.
5. Navigate to All -> Profiles -> Security -> TLS Profile. The TLS Profile window is displayed, with the TLS Profile List pane.
6. Select the radio button corresponding to the defaultTlsProfile. The Edit Selected TLS Profile pane is displayed.
7. Set the fields V1_0 and V1_1 to “Disabled”. Set the field V1_2 to “Enabled”. Click Save to save the changes.
8. Navigate to All -> Profiles -> Security -> EMA TLS Profile. The EMA TLS Profile window is displayed, with the EMA TLS Profile List pane.
9. Select the radio button corresponding to the defaultEmaTlsProfile. The Edit Selected EMA TLS Profile pane is displayed.
10. Set the fields V1_0 and V1_1 to “Disabled”. Set the field V1_2 to “Enabled”. Click Save to save the changes.
11. Navigate to All -> OAM -> Snmp. The Snmp window is displayed, with the Edit Snmp pane. SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025

9. Set the Version field to “V3only”. Click Save to save the changes.
10. Log in to the CLI and execute the following commands: % set system admin <system_name> fips-140-3 mode enabled % commit Setting “fips-140-3 mode” to ‘enabled’ accomplishes the following: • • • regenerates all SSH keys. regenerates encryption keys used by the system configuration database. zeroizes all persistent CSPs from the system and causes the server to reboot after confirmation.

After completion and confirmation of the above steps, the module’s VM will reboot. After this reboot, and on all subsequent reboots, the module will be operating in its Approved mode. The following steps are required for module startup. 11.1.3.1 Restoring EMA in Platform Mode To restore service to the EMA in Platform Mode after “fips-140-3 mode” is set to ‘enabled’, CA certificates and newly-generated SBC certificates must be imported using the CLI. • Import CA Certificates – Use the following procedure to import up to twenty CA certificates and associate them with the EmaTlsProfile named "defaultEmaTlsProfile." > configure private % set system security pki certificate intermediateCaCert fileName intCaCert.der state enabled type remote % set system security pki certificate rootCaCert fileName rootCaCert.der state enabled type remote % commit % set profiles security EmaTlsProfile defaultEmaTlsProfile ClientCaCert intermediateCaCert % set profiles security EmaTlsProfile defaultEmaTlsProfile ClientCaCert rootCaCert % commit • Import SBC Certificates – The SBC enables importing SBC server certificates generated with either of two different methods: those generated externally and those generated locally in the SBC. Use the following procedure to import an externally-generated SBC key and certificate in PKCS#12 format:

1. Transfer the PKCS#12 formatted key/certificate file to the SBC and save it as opt/sonus/external/<filename>.p12.
2. Install the certificate using the following steps (the following example uses a certificate named "sbxCert.p12" with a passPhrase "sonus"): > configure private % set system security pki certificate sbxCert fileName sbxCert.p12 passPhrase sonus state enabled type local % commit % set profiles security EmaTlsProfile defaultEmaTlsProfile serverCertName sbxCert % commit SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 Use the following procedure to generate an SBC key and CSR locally in the SBC, and then import as a PEM externally-signed certificate: The CO shall ensure that only keys providing at least 112 bits of encryption strength are used for signing certificate requests.

1. Generate a CSR: > configure private % set system security pki certificate sbxCert type local-internal % exit > request system security pki certificate sbxCert generateCSR keySize keySize2K csrSub "/C=US/ST=MA/L=Westford/O=Sonus Networks Inc./CN=www.sonusnet.com"
2. Copy the CSR output from the request in step 1 and obtain a signed certificate in a PEM formatted file from the appropriate Certificate Authority.
3. Transfer the certificate to the SBC and save it as /opt/sonus/external/<filename>.pem.
4. Install the certificate using the following steps (the following example uses the certificate file name "sbxCert.pem"): > configure private % set system security pki certificate sbxCert fileName sbxCert.pem % set profiles security EmaTlsProfile defaultEmaTlsProfile serverCertName sbxCert 11.1.3.2 11.2 Administrator Guidance The Crypto Officer is responsible for initialization and security-relevant configuration and management of the module. Once the module is properly configured, the Crypto Officer is responsible for maintaining and monitoring the status of the module to ensure that it is running in its Approved mode. For details regarding the general management of the module, please refer to the appropriate entries on Ribbon’s SBC Core 10.1.x Documentation webpage. SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

Operational mode status of the module can be viewed by navigating to Administration -> Users and Application Management -> Fips-140-3 from the SBC main screen via the EMA and selecting the desired SBC system from the dropdown menu. When running in Approved mode, the radio button marked “Enabled” will be selected. 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 Ribbon Customer Support.

The module’s versioning information can be viewed by navigating to Monitoring -> Dashboard -> System Status from the SBC main screen via the EMA. The System Status window display will include the hardware type and SBC application version, which can be correlated with the module name and software version (respectively) on the module’s validation record.

Procedures for loading a new module image can be found under the appropriate entries on Ribbon’s Upgrading SBC Core Software webpage.

When configuring the module for high availability, the VMs for the active instance and the standby instance must reside on the same physical host for operation in the Approved mode. For connection details, refer to the instructions found under the online document entry “Setting Up Logical Connection Between High Availability Nodes”.

This section notes additional policies below that must be followed by the CO:

• Once the “fips-140-3 mode” is set to ‘enabled’, it cannot be disabled through the configuration. A fresh software installation is required to set the operational mode back to ‘disabled’.
• To ensure correct functioning and compliance with this Security Policy, module operators must use phones that support TLS v1.2.
• When using local certificate management mode, certificates are first stored in encrypted form on the external workstation prior to being sent to the module via SSH. To ensure that the certificate file can be properly decrypted and installed once sent to the module, module operators must ensure the following:
• The encryption algorithm used on the external workstation must be 128-bit AES in CBC mode, and the salt length used on the external workstation as input to the PBKDF2 must be 128 bits. SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

• 11.3 July 8, 2025 As the Certificate Load Key used by the module to decrypt the loaded certificate is established using PBKDF2 as specified in NIST SP 800-132, the same passphrase that was used on the external workstation must be entered into the module in order to derive the correct key. Non-Administrator Guidance With the exception of the User password, User role operators do not have the ability to configure sensitive information on the module. The User must be diligent to select strong passwords in adherence to the password policies set by the CO from section 4.1 and must not reveal their password to anyone. Additionally, User role operators should be careful to protect any secret or private keys to which they have access. 11.4 Design and Rules By design, the module follows or enforces the following rules of operation:
• 11.5 The module provides two distinct operator roles: User and Cryptographic Officer. An operator does not have access to any cryptographic services prior to assuming an authorized role. The module performs all self-tests without any operator action required. The module inhibits data output during key generation, self-tests, zeroization, and error states. Status information output by the module does not contain CSPs or sensitive data that if misused could lead to a compromise of the module. The module does not support a maintenance interface or role. The module does not support manual SSP establishment methods. The module does not have any proprietary external input/output devices used for entry/output of data. The module does not output intermediate key values. The module does not provide bypass services or ports/interfaces. End of Life As the module does not persistently store SSPs, secure sanitization of the module consists of performing the zeroization methods described in section 9.3 above. This will ensure that any SSPs in volatile memory are zeroized. SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

July 8, 2025 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:2012 section 7.12, requirements for this section are not applicable. SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

Appendix A. Acronyms and Abbreviations Table 32 provides definitions for the acronyms and abbreviations used in this document. Table 32. Acronyms and Abbreviations SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc. July 8, 2025

SBC SWe Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc. July 8, 2025

Prepared by: Corsec Security, Inc.

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

Referenced URLs

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