SBC 5400 Session Border Controller

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for SBC 5400 Session Border Controller
  %% 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<br/>firmware load</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>UnAuth</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>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["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 SBC 5400 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["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>update<br/>Upgrade<br/>firmware load</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>UnAuth</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>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,C5,C6 clueLow;

Security Policy, page by page

Ribbon Communications, Inc. SBC 5400 Session Border Controller Firmware Version: 10.01.06 FIPS Security Level: 2 Document Version: 0.6 Prepared for: Prepared by: Ribbon Communications, Inc. Corsec Security, Inc.

4 Technology Park Drive 12600 Fair Lakes Circle, Suite 210

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

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

The SBC 5400 Session Border Controller is validated at the FIPS 140-3 section levels shown in the table below. Table 1: Security Levels SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

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 Controllers (SBC 5400) 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. Ribbon’s SBC 5400 Session Border Controller (see Figure 1 below) is a high-performance air-cooled, 2U, IP encryption appliance that features a unique architecture design that differs from other session border controllers on the market today by aggregating all of the session border functionality

• security, encryption, transcoding, call routing, and session management
• into a single device, and then distributing those functions to embedded and modular hardware within the device. The SBC 5400 provides secure SIP-based communications with robust security, reduced latency, real-time encryption (VOIP 3 signaling and media traffic), media transcoding, flexible SIP session routing, and policy management. Figure 1
• SBC 5400 Session Border Controller The SBC 5400 is designed to fully address the next-generation need of SIP communications by delivering embedded media transcoding, robust security and advanced call routing in a high-performance, medium formfactor device. The SBC 5400 is designed to accommodate up to 75,000 call sessions. Some of the network and security features provided by the module include:

1 IP – Internet Protocol

SIP – Session Initiation Protocol

3 VOIP – Voice Over Internet Protocol

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

• Session-aware firewall, split DMZ 4 , bandwidth & QoS 5 theft protection, topology hiding, DoS 6 /DDoS 7 detection/blocking, rogue RTP 8 protection, IPsec 9 and TLS 10 encryption
• Embedded media transcoding hardware
• H.323 and SIP-I/T interworking
• Stateful call-handling even during overload/attack/outages
• Embedded localized or centralized call-routing options
• Far-end NAT 11 traversal
• TLS, IPsec (IKEv1 12) for signaling encryption
• Secure RTP/RTCP 13 for media encryption
• Support for large number of protocols including IPv4, IPv6, IPv4/IPv6 interworking, SSH 14, SFTP 15, SNMP 16, HTTPS 17, RTP/RTCP, UDP 18, TCP 19, DNS 20, and ENUM 21
• Exceptional scalability even under heavy workloads
• Device management using encrypted and authenticated device management messages
• Controlled menu access and comprehensive audit logs
• Integrated Baseband Management Controller (BMC) The validated module is a solution that delivers end-to-end SIP session control and a networkwide view of SIP traffic and policy management. The module can be deployed as a peering SBC, access SBC, or enterprise SBC. Figure 2 below illustrates a typical deployment scenario of the module. DMZ
• Demilitarized Zone

5 QoS – Quality of Service

6 DoS – Denial of Service

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

RTP – Real-time Transport Protocol

9 IPsec – Internet Protocol Security

10 TLS – Transport Layer Security

11 NAT – Network Address Translation

12 IKEv1 – Internet Key Exchange version 1

13 RTCP – RTP Control Protocol

14 SSH – Secure Shell

15 SFTP – SSH File Transport Protocol

16 SNMP – Simple Network Management Protocol

17 HTTPS – Hypertext Transfer Protocol Secure

18 UDP – User Datagram Protocol

19 TCP – Transmission Control Protocol

DNS – Domain Name System

21 ENUM – E.164 Number Mapping

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

Opti igh-Ava Redun

onal ilability/ dancy

Home Users Application SBC 5400 Service Public Internet / ISP or Service Provider’s Optional Metropolitan Backhaul High-Availability/ Core Network Redundancy Application Enterprise SBC 5400 Service Figure 2

• Typical Deployment of SBC 5400 in a Network Management of the SBC 5400 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 22 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 23 logs, and configuration files over the module’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 5400. To support TLS, the module employs the following certificate management techniques:
• Local
• Local certificates are credentials belonging to the SBC 5400 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 5400 generates its RSA public/private key pairs and Certificate Signing Requests (CSR) internally. The certificate request is signed with SBC 5400’s private key and then sent to a CA. The CA-signed certificate is received back from the CA, verified using the CA public key, and then installed on the SBC 5400. SNMPv3
• Simple Network Management Protocol version 3

23 CDR – Call Detail Records

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

• 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 5400 Session Border Controller 10.01.06 is a Hardware module.

The SBC 5400 Session Border Controller has a MultiChipStand embodiment.

The module does not have any additional characteristics. .

The module’s cryptographic boundary is defined by its hard enclosure (shown in Figure 1). The main hardware components contained within the enclosure include integrated circuits, processors, memories, SSD 24, flash, DSP cards, power supplies, and fans. The primary executing components are:

• SBC SWe application firmware
• Ribbon’s proprietary ConnexIP operating system (with crypto libraries)
• SonusDB (with configuration files and PostGRES)
• HMAC digest files (for integrity checking)

2.2.1 Tested Module Identification – Hardware

The module was tested and found to be compliant with FIPS 140-3 requirements on the hardware versions listed in the table below. Table 2: Tested Module Identification – Hardware

24 SSD – Solid-State Drive

2.2.2 Tested Module Identification – Software, Firmware, Hybrid

(Executable Code Sets) The module does not have any executable code sets. N/A for this module.

2.2.3 Tested Module Identification – Hybrid Disjoint Hardware

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

2.2.4 Tested Operational Environments – Software, Firmware,

Hybrid This section is only applicable to software, firmware, and hybrid modules. N/A for this module.

2.2.5 Vendor-Affirmed Operational Environments – Software,

Firmware, Hybrid There are no vendor-affirmed operational environments claimed. N/A for this module.

The module also includes components that are excluded from the requirements of this standard:

• ASPEED Technology’s onboard AST2400 Server Management Processor (referred to as the Baseboard Management Controller or “BMC”) provides remote monitoring and management functions. This component is excluded from the security requirements of this standard, along with all supporting chips, circuitry and external ports connected to the BMC. Although it physically resides within the cryptographic boundary, the BMC is a completely independent computing platform, with its own CPU, RAM, flash, ports, and operating system.
• The module includes two removable power supplies at the rear of the device (see Figure 5 below). These power supplies provide no security to the module and offer no way to compromise the module in the event of a malfunction. Module opacity is maintained when no power supplies are installed. SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

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

The module employs cryptographic algorithm implementations from the following sources:

• Ribbon Cryptographic Library version 10 (Cert. A5066)
• Ribbon Entropy Library version 10 (Cert. A4087)
• Ribbon IKE KDF 25 Library version 10 (Cert. A5067)
• Ribbon SRTP 26 KDF Library (OCTEON) version (Cert. A5068)
• Ribbon SSH KDF Library version 10 (Cert. A5069)
• Ribbon TLS KDF Library version 10 (Cert. A5070) The module implements the Approved algorithms listed in the table below. KDF
• Key Derivation Function

26 SRTP – Secure Real-Time Transport Protocol

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

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

The vendor affirms the following cryptographic security methods in the table below: Table 5: Vendor-Affirmed Algorithms SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

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.

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.

The table below lists the security function implementations for this module. SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

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

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

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

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

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

Table 6: Security Function Implementations

The following is algorithm-specific information related to the module:

• AES-GCM: The AES-GCM IV 27 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.

27 IV – Initialization Vector

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

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). 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:
• 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.

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 7: Entropy Certificates The table below specifies the module’s entropy sources. Table 8: Entropy Sources SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

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

• CKG
• ECDSA KeyGen
• RSA KeyGen

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.

The module employs the following industry protocols:

• IPsec (IKEv1 and IKEv2)
• SRTP
• SSH
• TLS v1.2 SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

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 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

FIPS 140-3 defines the following logical interfaces for cryptographic modules:

• Data Input
• Data Output
• Control Input
• Status Output The physical ports/interfaces found on the front bezel of the SBC 5400 Session Border Controller are shown in Figure 3 below. The physical ports/interfaces found behind the front bezel of the module are shown in Figure 4 below (note that the front bezel LEDs can also be seen on the module’s front panel when the bezel is not in place). Locator LED Alarm LED Active LED Status LED Power LED Figure 3
• Front Bezel LEDs on Bezel SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

Alarm LED Fan Control LEDs Figure 4

• Front Panel LEDs Behind Bezel The physical ports and interfaces found on the rear panel of the SBC 5400 Session Border Controller are shown in Figure 5 below. DSP2x Cards Power Supplies with LEDs Media Ports with LEDs Field Service Port with LEDs SSD Slot Integrated Latch Management Ports (Mgmt 0/1/2/3) with LEDs HA Ports with LEDs Figure 5
• Rear Panel Ports/Interfaces A mapping of the module’s 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. SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

Table 9: Ports and Interfaces Also identified in Figure 5 are the BMC Serial Port (an RS-232 serial port) and the Field Service Port (a 1 Gbps Ethernet port). These ports are used to connect with the BMC (serial for local connections, Ethernet for remote connections), and the CO must use these ports in order to perform the module’s initial setup and configuration as described in section 11.1.2. Beyond this, these external ports shall not be used while the module is operational. Use of these external ports is prohibited while the module is operating in its Approved mode. The module also includes a front-facing USB 28 port that allows for the connection of external devices for firmware image downloads. Use of this port for any purpose is prohibited while the module is operating in its Approved mode. Additionally, the module includes a back panel alarm port. This port is not operational and provides no Figure 5 shows a populated SSD slot. The module stores SSPs in both plaintext and ciphertext form on the SSD. The CO shall ensure that the SSD is not removed from the SSD slot.

28 USB – Universal Serial Bus

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

4. Roles, Services, and Authentication

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, results of any previous authentication will be cleared. 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 10: 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 SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

• At least one lowercase letter
• At least one uppercase letter
• 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

The module supports the following vendor-defined groups and capabilities:

Security Event logs and management audit logs and cannot execute any commands stopping or starting these audit log services.

• 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 11: Roles

Descriptions of the services available are provided in the table below. 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. SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

G,E Z W SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

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

Establish IPsec connection

Establish an IPsec session using IKE

Global FIPS status indicator

Command and parameters

Command response, status output

IPsec IKE

Crypto Officer - ECDH Private Key: G,E - ECDH Public Key: G,E - ECDH Peer Public Key: W,E - DH Private Key: G,E - DH Public Key: G,E - DH Peer Public Key: W,E - IKE RSA Private Key: G,E - IKE RSA Public Key: G,R - IKE Shared Secret: W,E - IKE SKEYID: G,E - IKE Pre-shared Secret: G,E - IKE Encryption Key: G,E - IKE Authentication Key: G,E - IPsec Shared Secret: G,E - IPsec Encryption Key: G,E - IPsec Authentication Key: G,E - AES GCM IV: G,E - IKE Key Derivation Key: G,E User - ECDH Private Key: G,E - ECDH Public Key: G,E - ECDH Peer Public Key: W,E - DH Private Key: G,E - DH Public Key: G,E - DH Peer Public Key: W,E - IKE RSA Private Key: G,E - IKE RSA Public Key: G,R - IKE Shared Secret: W,E - IKE SKEYID: G,E - IKE Pre-shared

G,E G,E G,E G,E G,E SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

G,E SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

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

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

Establish TLS connection

Establish TLS connection

Global FIPS status indicator

Command and parameters

Command response, status output

TLS v1.2

Crypto Officer - ECDH Private Key: G,E - ECDH Public Key: G,R - ECDH Peer Public Key: W,E - DH Private Key: G,E - DH Public Key: G,R - DH Peer Public Key: W,E - TLS Private Key: G,W,E - TLS Public Key: G,R,W - TLS Peer Public Key: W,E - TLS Session Key: G - TLS Authentication Key: G - TLS Pre-Master Secret: G,E - TLS Master Secret: G,E - AES GCM IV: G,E User - ECDH Private Key: G,E - ECDH Public Key: G,R - ECDH Peer Public Key: W,E - DH Private Key: G,E - DH Public Key: G,R - DH Peer Public Key: W,E - TLS Private Key: G,W,E - TLS Public Key: G,R,W - TLS Peer Public Key: W,E - TLS Session Key: G - TLS Authentication Key: G - TLS Pre-Master Secret: G,E - TLS Master Secret: G,E - AES GCM IV: G,E

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

Perform SFTP functions

Perform FTP functions over SSH

Global FIPS status indicator

Command and parameters

Command response, status output

SSH

Crypto Officer - ECDH Private Key: G,E - ECDH Public Key: G,R - ECDH Peer Public Key: W,E - DH Private Key: G,E - DH Public Key: G,R - DH Peer Public Key: W,E - SSH Private Key: G,W,E - SSH Public Key: G,R - SSH Peer Public Key: W,E - SSH Session Key: G - SSH Authentication Key: G - SSH Shared Secret: G,E - SFTP Private Key: G,E - SFTP Public Key: G,E - SFTP Peer Public Key: G,E - AES GCM IV: G,E User - ECDH Private Key: G,E - ECDH Public Key: G,R - ECDH Peer Public Key: W,E - DH Private Key: G,E - DH Public Key: G,R - DH Peer Public Key: W,E - SSH Private Key: G,W,E - SSH Public Key: G,R - SSH Peer Public Key: W,E - SSH Session Key: G,E - SSH Authentication Key: G,E - SSH Shared Secret: G,E

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

The module does not offer any non-Approved services.

The cryptographic module has the capability of loading firmware from an external source. Upon load, the module will verify the integrity of the load package with a 2048-bit RSA signature verification (the public key is loaded in write-protected flash at the factory). If the check fails, the new firmware is ignored and the current firmware 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 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

Only validated firmware may be loaded to maintain the module’s validation. The new image shall include updated versioning information to represent the newly loaded image. Any firmware loaded into this module that is not shown on the module certificate is out of the scope of this validation and requires a separate FIPS 140-3 validation. 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 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

At module start-up, the integrity of all firmware components within the cryptographic boundary is checked automatically using an approved integrity technique implemented within the cryptographic module itself. The module employs a series of HMAC SHA2-256 digests to test each firmware component; unsuccessful verification of any of the digest values will cause the module to enter a critical error state.

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 manually. When using this method, the operator is not required to assume an authorized role. SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

The SBC 5400 Session Border Controller is a hardware cryptographic module with a Limited operational environment and complaint with level 2 physical security requirements. Therefore, per section 7.5 of the CMVP Management Manual, requirements for this section are not applicable. SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

The SBC 5400 is a multi-chip standalone hardware cryptographic module. All SSPs are stored and protected within the module’s production-grade enclosure. All components within the module are production grade with standard passivation. The module’s chassis is opaque within the visible spectrum. The chassis’ front bezel and rear panel provide only a limited set of ventilation holes, obscuring visual access to the module’s internal components. Tamper-evident labels must be applied to the chassis to provide physical evidence of attempts to remove protected components. Table 13: Mechanisms and Actions Required

The module ships with six (6) vendor-branded serialized labels. For the module to operate in its Approved mode, the CO shall place five (5) of the labels on the appliance.

The figures Error! Reference source not found. provide the label placement locations. Figure 6 – Label Placement (Label 1) SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

3 2

Figure 7 – Label Placement (Label

2. Figure 8 – Label Placement (Label
3. Figure 9 – Label Placement (Labels 4 and
4. SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

Prior to affixing the labels, the front bezel must be attached, and the appliance surfaces must first be cleaned as follows:

• The label application areas on the grey faceplate must be cleaned with mild soap and water to remove any surface oils that may be present.
• The label application areas on the black enclosure and plated steel mesh can be cleaned in the same manner or with isopropyl alcohol. After applying the labels, allow at least 72 hours for the label adhesive to cure.

The CO is responsible for:

• securing and having control at all times of any unused labels.
• maintaining direct control and observation of any changes to the module where the tamper-evident labels are removed or installed to ensure that the security of the module is maintained during such changes and that the module is returned to its Approved state.
• performing periodic inspection of the module for evidence of tampering (see the table in section 7.1) for details). The CO must visually inspect the tamper-evident labels for tears, rips, dissolved adhesive, and other signs of attempted tampering. If evidence of tampering is found during periodic inspection, the CO must zeroize the keys and contact Ribbon Customer Support.

Additional labels can be requested directly from Ribbon (FIPS Physical Security Kit part no. 550-06508). To request additional labels, the CO can contact Ribbon Customer Service. The CO must be sure to include contact information and the shipping address, as well as the appliance serial number. SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

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

9. Sensitive Security Parameters Management

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. Table 14: Storage Areas

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 15: SSP Input-Output Methods SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

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 16: SSP Zeroization Methods 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 module’s TOEPP. SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

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

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

Name Config Database (CBD) Key CA Public Key ECDH Private Key ECDH Public Key ECDH Peer Public Key DH Private Key DH Public Key DH Peer Public Key IKE RSA Private Key IKE RSA Public Key IKE Pre-shared Secret IKE SKEYID

Input - Output External to RAM via DER file format RAM to External via Plaintext Certificate External to RAM via Plaintext Certificate RAM to External via Plaintext External to RAM via Plaintext Certificate External to CDB on SSD via CLI (SSH) External to CDB on SSD via EMA (TLS)

Storage SSD:Plaintext RAM:Plaintext RAM:Plaintext RAM:Plaintext RAM:Plaintext RAM:Plaintext RAM:Plaintext RAM:Plaintext SSD:Encrypted SSD:Encrypted RAM:Plaintext RAM:Plaintext

Storage Duration Until reboot Session Session Session Session Session Session Until zeroized Until zeroized Until reboot or session termination Until reboot or session termination

Zeroization Command via CLI or EMA Reboot Reboot Session Termination Reboot Session Termination Reboot Session Termination Reboot Session Termination Reboot Session Termination Reboot Session Termination Command via CLI or EMA Command via CLI or EMA Reboot Session Termination Reboot Session Termination

Related SSPs

Table 17: SSP Table 1 SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

Name IKE Shared Secret IKE Encryption Key IKE Authentication Key IKE Key Derivation Key IPsec Shared Secret IPsec Encryption Key IPsec Authentication Key SSH Private Key SSH Public Key SSH Peer Public Key SSH Session Key SSH Authentication Key TLS Private Key TLS Public Key TLS Peer Public Key TLS Session Key TLS Authentication Key SRTP Session Key SRTP Authentication Key SFTP Private Key

Input - Output External to RAM via Plaintext Certificate External to RAM via DER file format External to RAM via Plaintext Certificate External to RAM via Plaintext Certificate

Storage RAM:Plaintext RAM:Plaintext RAM:Plaintext RAM:Plaintext RAM:Plaintext RAM:Plaintext RAM:Plaintext SSD:Plaintext SSD:Plaintext RAM:Plaintext RAM:Plaintext RAM:Plaintext SSD:Encrypted SSD:Encrypted RAM:Plaintext RAM:Plaintext RAM:Plaintext RAM:Plaintext RAM:Plaintext SSD:Encrypted

Storage Duration Until reboot or session termination Until reboot or session termination Until reboot or session termination Until reboot or session termination Until reboot or session termination Until reboot or session termination Until reboot or session termination Until reboot or session termination Until reboot or session termination Until reboot or session termination Until reboot or session termination Until reboot or session termination Until reboot or session termination Until reboot or session termination Until reboot or session termination

Zeroization Reboot Session Termination Reboot Session Termination Reboot Session Termination Reboot Session Termination Reboot Session Termination Reboot Session Termination Reboot Session Termination Command via CLI or EMA Command via CLI or EMA Reboot Session Termination Reboot Session Termination Reboot Session Termination Command via CLI or EMA Command via CLI or EMA Reboot Session Termination Reboot Session Termination Reboot Session Termination Reboot Session Termination Reboot Session Termination Command via CLI or EMA

Related SSPs

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

Name SFTP Public Key SFTP Peer Public Key SNMPv3 Privacy Key SNMPv3 Authentication Key Certificate Load Key SRTP Master Key SSH Shared Secret TLS Pre-Master Secret TLS Master Secret RADIUS Shared Secret DRBG Entropy Input String DRBG Seed DRBG 'V' Value DRBG 'Key' Value Crypto Officer password User password Image Verify Key AES GCM IV

Input - Output External to RAM via Plaintext Certificate External to RAM via Plaintext Certificate External to CDB on SSD via CLI (SSH) External to CDB on SSD via EMA (TLS) Backup to External via TLS External to CDB on SSD via CLI (SSH) External to CDB on SSD via EMA (TLS) Backup to External via TLS RAM to External via Encrypted Form External to CDB on SSD via CLI (SSH) External to CDB on SSD via EMA (TLS) External to CDB on SSD via CLI (SSH) External to CDB on SSD via EMA (TLS) External to CDB on SSD via CLI (SSH) External to CDB on SSD via EMA (TLS) RAM to External via Encrypted Form External to RAM via Plaintext Certificate

Storage SSD:Plaintext RAM:Plaintext SSD:Encrypted SSD:Encrypted RAM:Plaintext RAM:Plaintext RAM:Plaintext RAM:Plaintext RAM:Plaintext SSD:Encrypted RAM:Plaintext RAM:Plaintext RAM:Plaintext RAM:Plaintext SSD:Encrypted SSD:Encrypted Flash Memory:Plaintext Spinning Media:Plaintext RAM:Plaintext

Storage Duration Until reboot or session termination Until reboot Until reboot or session termination Until reboot or session termination Until reboot or session termination Until reboot or session termination Until reboot Until reboot Until reboot Until reboot Until reboot

Zeroization Command via CLI or EMA Reboot Session Termination Command via CLI or EMA Command via CLI or EMA Reboot Reboot Session Termination Reboot Session Termination Reboot Session Termination Reboot Session Termination Command via CLI or EMA Reboot Reboot Reboot Reboot Command via CLI or EMA Command via CLI or EMA Command via CLI or EMA Reboot

Related SSPs

Table 18: SSP Table 2 SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

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 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

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.

The module performs the following pre-operational self-tests: Table 19: Pre-Operational Self-Tests

The module performs the following conditional self-tests: SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

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

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

Table 20: Conditional Self-Tests

The operator may perform pre-operational and conditional self-tests on demand by issuing a reset/reboot command over the management interfaces of the module; rebooting the module; or power-cycling the module. On-demand self-test information for pre-operational and conditional self-tests are shown in the tables below. Table 21: Pre-Operational Periodic Information SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

Table 22: Conditional Periodic Information

The table below describes the error states and status indicators of the module. SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

The operator may initiate self-tests on demand by issuing a reset/reboot command over the management interfaces of the module; rebooting the module; or power-cycling the module. SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

% show oam snmp trapTarget EMS_-10.54.71.176

ipAddress 10.54.71.176;

port 162;

trapType v3;

targetUsername emstrapuser;

targetSecurityLevel authPriv;

state enabled;

% set oam snmp trapTarget EMS_-10.54.71.176 state disabled

% commit

The SBC 5400 Session Border Controller is delivered in an uninitialized factory state. The CO shall be responsible for performing all initial setup activities, including configuring the platform and installing the SBC application firmware. 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 The CO shall also be responsible for configuring the module as a FIPS-recognized module, ensuring that it operates in its Approved mode. For these activities, physical access to the module shall be limited to the Crypto Officer. Before the product can be considered a FIPS-recognized module, the CO must place tamper-evident labels on the module. To apply the labels, the CO must follow the application guidance provided in section 7.2 of this document. The next setup steps are to configure the management interfaces and to install the SBC application firmware. To setup the SBC 5400, the CO must follow the instructions found under the online document entry “Installing SBC

5400 Hardware”, which provides detailed guidance for installing rack mount kits, mounting the SBC chassis,

attaching the front bezel, connecting cables (for media, high availability, and power), and powering on the SBC. Once these steps have been completed, the Crypto Officer must then perform the FIPS-specific activities required to 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: 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. SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

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.

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:

1. Log in to the EMA using the default username “admin” and password “admin”.
2. Navigate to All -> Profiles -> Security -> TLS Profile. The TLS Profile window is displayed, with the TLS Profile List pane.
3. Select the radio button corresponding to the defaultTlsProfile. The Edit Selected TLS Profile pane is displayed.
4. Set the fields V1_0 and V1_1 to “Disabled”. Set the field V1_2 to “Enabled”. Click Save to save the changes.
5. Navigate to All -> Profiles -> Security -> EMA TLS Profile. The EMA TLS Profile window is displayed, with the EMA TLS Profile List pane.
6. Select the radio button corresponding to the defaultEmaTlsProfile. The Edit Selected EMA 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 -> OAM -> Snmp. The Snmp window is displayed, with the Edit Snmp pane.
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: SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

• 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 system will reboot. After this reboot, and on all subsequent reboots, the module will be in its Approved mode. The following steps are required for module startup.

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 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.
3. Generate a CSR: SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

After “fips-140-3 mode” is set to ‘enabled’, the SNMP Authentication Keys and SNMPv3 Privacy Keys must be

reconfigured for all SNMPv3 users (this applies to all SNMPv3 users for authPriv/authNoPriv security level trap

targets).

1. Use the following CLI commands to reconfigure the keys:

% set oam snmp users <username> authKey <colon separated hex string>

% set oam snmp users <username> privKey <colon separated hex string>

% commit

2. Enable the authPriv/authNoPriv trap targets:

% set oam snmp trapTarget <trap_target_name> state enabled

% commit

> 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

The Crypto Officer shall receive the module from Ribbon via trusted couriers (e.g., United Parcel Service, Federal Express, and Roadway). On receipt, the Crypto Officer must check the package for any irregular tears or openings. If any such damage exists, the CO shall indicate that on the shipping document of the carrier and contact Ribbon Communications, Inc. immediately for instructions. The CO shall retain the packing list, making sure all items on the list are present (including all the components of the universal rack mount kit that is shipped with the module). The Crypto Officer is responsible for initialization and security-relevant configuration and management of the module. Once installed, commissioned, and 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 additional 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 5400 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 firmware 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 active instance and the standby instance must be directly connected with no intervening systems for operation in the Approved mode. For connection details, refer to the instructions found under the online document entry “Setting Up Physical 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 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

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

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 complexity policies set by the CO from section 4.1 and must not reveal their password to anyone. Additionally, the User should be careful to protect any secret or private keys in their possession.

By design, the module follows or enforces the following rules of operation:

• 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. SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

12. Mitigation of Other Attacks The module does not claim to mitigate any attacks beyond the FIPS 140-3 Level 2 requirements for this validation. Therefore, per ISO/IEC 19790:2012 section 7.12, requirements for this section are not applicable. SBC 5400 Session Border Controller 10.01.06 ©2025 Ribbon Communications, Inc.

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

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

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