Document Version 1.3 ©Oracle Corporation
This document may be reproduced whole and intact including the Copyright notice.
FIPS 140-2 Non-Proprietary Security Policy
Acme Packet 4600 [1] and Acme Packet 6300 [2] and Acme Packet
6350 [3]
FIPS 140-2 Level 1 Validation
Hardware Version: 4600 [1], 6300 [2], and 6350 [3]
Firmware Version: S-Cz8.2.0
Date: December 6th
, 2019
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350 Security Policy
i
Title: Acme Packet 4600 [1], Acme Packet 6300 [2] and Acme Packet 6350 [3] Non-Proprietary Security Policy
Date: December 6th
, 2019
Author: Acumen Security, LLC.
Contributing Authors:
Oracle Communications Engineering
Oracle Security Evaluations – Global Product Security
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracle.com
Copyright © 2019, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and the contents
hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or
conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a
particular purpose. Oracle specifically disclaim any liability with respect to this document and no contractual obligations are formed either
directly or indirectly by this document. This document may reproduced or distributed whole and intact including this copyright notice.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350 Security Policy
ii
TABLE OF CONTENTS
Section Title Page
1. Introduction.................................................................................................................................................. 1
1.1 Overview............................................................................................................................................................. 1
1.2 Document Organization...................................................................................................................................... 1
2. Acme Packet 4600 [1], Acme Packet 6300 [2] and Acme Packet 6350 [3] ......................................................... 2
2.1 Functional Overview........................................................................................................................................... 2
3. Cryptographic Module Specification............................................................................................................... 3
3.1 Definition of the Cryptographic Module ............................................................................................................ 3
3.2 FIPS 140-2 Validation Scope ............................................................................................................................... 4
3.3 Approved or Allowed Security Functions ........................................................................................................... 4
3.4 Non-Approved But Allowed Security Functions ................................................................................................. 6
3.5 Non-Approved Security Functions and Services................................................................................................. 7
3.6 Vendor Affirmed Security Functions................................................................................................................... 7
4. Module Ports and Interfaces.......................................................................................................................... 8
5. Physical Security.......................................................................................................................................... 13
6. Operational Environment ............................................................................................................................ 14
7. Roles and Services....................................................................................................................................... 15
7.1 Operator Services and Descriptions ................................................................................................................. 15
7.2 Unauthenticated Services and Descriptions..................................................................................................... 18
7.3 Operator Authentication .................................................................................................................................. 18
7.3.1 Crypto-Officer: Password-Based Authentication .......................................................................................................18
7.3.2 User: Certificate-Based Authentication......................................................................................................................19
7.4 Key and CSP Management................................................................................................................................ 19
8. Self-Tests .................................................................................................................................................... 27
8.1 Power-Up Self-Tests.......................................................................................................................................... 27
8.1.1 Firmware Integrity Test..............................................................................................................................................27
8.1.2 Mocana Cryptographic Library Self-Tests...................................................................................................................27
8.1.3 Oracle Acme Packet Cryptographic Library Self-Tests................................................................................................27
8.1.4 Nitrox Self-Tests .........................................................................................................................................................27
8.1.5 Octeon Self-tests ........................................................................................................................................................28
8.2 Critical Functions Self-Tests.............................................................................................................................. 28
8.3 Conditional Self-Tests ....................................................................................................................................... 28
9. Crypto-Officer and User Guidance................................................................................................................ 29
9.1 Secure Setup and Initialization ......................................................................................................................... 29
9.2 AES-GCM IV Construction/Usage...................................................................................................................... 30
10. Mitigation of Other Attacks...................................................................................................................... 31
Acronyms Terms and Abbreviations.................................................................................................................... 32
References......................................................................................................................................................... 33
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350 Security Policy
iii
List of Tables
Table 1: FIPS 140-2 Security Requirements............................................................................................................ 4
Table 2: FIPS Approved and Allowed Security Functions for Oracle Acme Packet Cryptographic Library.................... 5
Table 3: FIPS Approved and Allowed Security Functions for Oracle Acme Packet Mocana Cryptographic Library..... 6
Table 4: FIPS Approved and Allowed Security Functions for Cavium Nitrox ............................................................ 6
Table 5: FIPS Approved and Allowed Security Functions for Cavium Octeon........................................................... 6
Table 6: Non-Approved but Allowed Security Functions ........................................................................................ 7
Table 7: Non-Approved Disallowed Functions ....................................................................................................... 7
Table 8: Vendor Affirmed Functions...................................................................................................................... 7
Table 9: Mapping of FIPS 140 Logical Interfaces to Physical Ports........................................................................... 8
Table 10: Physical Ports........................................................................................................................................ 9
Table 11: Mapping of FIPS 140 Logical Interfaces to Physical ports....................................................................... 10
Table 12: Physical Ports...................................................................................................................................... 11
Table 13: Service Summary................................................................................................................................. 15
Table 14: Operator Services and Descriptions...................................................................................................... 18
Table 15: Operator Services and Descriptions...................................................................................................... 18
Table 16: Crypto-Officer Authentication.............................................................................................................. 19
Table 17: User Authentication ............................................................................................................................ 19
Table 18: CSP Table ............................................................................................................................................ 26
Table 19: Acronyms............................................................................................................................................ 32
Table 20: References .......................................................................................................................................... 33
List of Figures
Figure 1: Acme Packet 4600.................................................................................................................................. 3
Figure 2: Acme Packet 6300.................................................................................................................................. 3
Figure 3: Acme Packet 6350.................................................................................................................................. 3
Figure 4: Acme Packet 4600 - Front View .............................................................................................................. 9
Figure 5: Acme Packet 4600 - Rear View................................................................................................................ 9
Figure 6: Acme Packet 6300 - Front View ............................................................................................................ 11
Figure 7: Acme Packet 6300 - Rear View.............................................................................................................. 11
Figure 8: Acme Packet 6350 - Front View ............................................................................................................ 12
Figure 9: Acme Packet 6350 - Rear View.............................................................................................................. 12
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 1 of 33
1. Introduction
1.1 Overview
This document is the Security Policy for the Acme Packet 4600, the Acme Packet 6300 and the Acme Packet 6350
appliances manufactured by Oracle Corporation. Acme Packet 4600, the Acme Packet 6300 and the Acme Packet
6350 are also referred to as “the module” or “module”. This Security Policy specifies the security rules under
which the module shall operate to meet the requirements of FIPS 140-2 Level 1. It also describes how the Acme
Packet 4600, the Acme Packet 6300 and the Acme Packet 6350 appliances function in order to meet the FIPS
requirements, and the actions that operators must take to maintain the security of the modules.
This Security Policy describes the features and design of the Acme Packet 4600, the Acme Packet 6300 and the
Acme Packet 6350 modules using the terminology contained in the FIPS 140-2 specification. FIPS 140-2, Security
Requirements for Cryptographic Modules specifies the security requirements that will be satisfied by a
cryptographic module utilized within a security system protecting sensitive but unclassified information. The
NIST/CCCS Cryptographic Module Validation Program (CMVP) validates cryptographic modules to FIPS 140-2.
Validated products are accepted by the Federal agencies of both the USA and Canada for the protection of
sensitive or designated information.
1.2 Document Organization
The Security Policy document is one document in a FIPS 140-2 Submission Package. The Submission Package
contains:
• Oracle Non-Proprietary Security Policy
• Oracle Vendor Evidence document
• Finite State Machine
• Entropy Assessment Document
• Other supporting documentation as additional references
With the exception of this Non-Proprietary Security Policy, the FIPS 140-2 Validation Documentation is
proprietary to Oracle and is releasable only under appropriate non-disclosure agreements. For access to these
documents, please contact Oracle.
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 2 of 33
2. Acme Packet 4600 [1], Acme Packet 6300 [2] and Acme Packet 6350 [3]
2.1 Functional Overview
The Acme Packet 4600, the Acme Packet 6300 and the Acme Packet 6350 appliances are specifically designed to
meet the unique price performance and manageability requirements of the small to medium sized enterprise and
remote office/ branch office. Ideal for small site border control and Session Initiation Protocol (SIP) trunking
service termination applications, the Acme Packet 4600, the Acme Packet 6300 and the Acme Packet 6350
appliances deliver Oracle’s industry leading ESBC capabilities in a small form factor appliance. With support for
high availability (HA) configurations, hardware assisted transcoding and Quality of Service (QoS) measurement,
the Acme Packet 4600, the Acme Packet 6300 and the Acme Packet 6350 appliances are a natural choice when
uncompromising reliability and performance are needed in an entry-level appliance. With models designed for
the smallest branch office to the largest data center, the Acme Packet ESBC product family supports distributed,
centralized, or hybrid SIP trunking topologies.
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350 appliances address the unique connectivity,
security, and control challenges enterprises often encounter when extending real-time voice, video, and UC
sessions to smaller sites. The appliances also helps enterprises contain voice transport costs and overcome the
unique regulatory compliance challenges associated with IP telephony. TDM fallback capabilities ensure
continuous dial out service at remote sites in the event of WAN or SIP trunk failures. Stateful high availability
configurations protect against link and hardware failures. An embedded browser based graphical user interface
(GUI) simplifies setup and administration
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 3 of 33
3. Cryptographic Module Specification
3.1 Definition of the Cryptographic Module
The module consists of the Acme Packet 4600, the Acme Packet 6300 and the Acme Packet 6350 appliances
running firmware version S-Cz8.2.0 on hardware platforms 4600, 6300 and 6350. The modules are classified as a
multi-chip standalone cryptographic module. The physical cryptographic boundary for the Acme Packet 4600, the
Acme Packet 6300 and the Acme Packet 6350 is all components with exception of the removable power supplies.
A representation of the cryptographic boundary is defined as the chassis of the module as shown in the Figures
below:
Figure 1: Acme Packet 4600
Figure 2: Acme Packet 6300
Figure 3: Acme Packet 6350
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 4 of 33
3.2 FIPS 140-2 Validation Scope
The Acme Packet 4600 [1] and Acme Packet 6300 [2] and Acme Packet 6350 [3] appliances are being validated to
overall FIPS 140-2 Level 1 requirements. See Table 1 below.
Security Requirements Section Level
Cryptographic Module Specification 1
Cryptographic Module Ports and Interfaces 1
Roles and Services and Authentication 2
Finite State Machine Model 1
Physical Security 1
Operational Environment N/A
Cryptographic Key Management 1
EMI/EMC 1
Self-Tests 1
Design Assurance 3
Mitigation of Other Attacks N/A
Table 1: FIPS 140-2 Security Requirements
3.3 Approved or Allowed Security Functions
The appliances contain the following FIPS Approved Algorithms listed in Table 2 (Oracle Acme Packet
Cryptographic Library Acme Packet 4600, 6300 and 6350), Table 3 (Oracle Acme Packet Mocana Cryptographic
Library Acme Packet 4600, 6300 and 6350), Table 4 (Cavium Nitrox) and Table 5 (Cavium Octeon):
Approved or Allowed Security Functions Cert#
SymmetricAlgorithms
AES CBC, ECB, GCM; Encrypt/Decrypt; Key Size = 128, 256
CTR; Encrypt; Key Size = 128,256
C 143
Triple DES1
CBC; Encrypt/Decrypt; Key Size = 192 C 143
Secure Hash Standard (SHS)
SHS SHA-1, SHA-256, SHA-384, SHA-512 C 143
Data Authentication Code
HMAC HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512 C 143
AsymmetricAlgorithms
1
Triple-DES was CAVP tested but is not utilized by the services associated with the Oracle Acme Packet Cryptographic Library.
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 5 of 33
Approved or Allowed Security Functions Cert#
RSA RSA: FIPS186-4:
186-4 KEY(gen): FIPS186-4_Random_e
ALG[ANSIX9.31] SIG(gen) (2048 SHA(1, 256 , 384)
ALG[ANSIX9.31] SIG(Ver) (2048 SHA(1, 256, 384))
RSA: FIPS186-2 :
ALG[ANSIX9.31] SIG(gen) (4096 SHA (256,384))
ALG[ANSIX9.31] SIG(Ver) (2048 SHA(1, 256, 384)), (4096 SHA (1, 256, 384))
RSA: FIPS186-4:
186-4 KEY(gen):
FIPS186-4_Random_e ALG[ANSIX9.31] SIG(gen) (2048 SHA(1, 256 , 384), (4096 SHA
(256,384))
SIG(Ver) (2048 SHA(1, 256, 384))
RSA: FIPS186-2
Signature Verification 9.31:
Modulus lengths: 2048, 4096
SHAs: SHA-1, SHA-256, SHA-384
C 143
ECDSA Firmware: FIPS186-4
PKG: CURVES (P-256, P-384 Testing Candidates)
SigGen: CURVES (P-256: (SHA-256, 384) P-384: (SHA-256, 384)
SigVer: CURVES (P-256: (SHA-256, 384) P-384: (SHA-256, 384))
C 143
Random NumberGeneration
DRBG Firmware:
CTR_DRBG: [ Prediction Resistance Tested: Not Enabled; BlockCipher_Use_df: (AES-
256)]
Hash_Based DRBG: [ Prediction Resistance Tested: Not Enabled (SHA-1)
C 143
Key establishment
Key Derivation Firmware: SNMP KDF, SRTP KDF, TLS KDF C 143
Key Transport
KTS Firmware: KTS (AES Cert. # C 143 and HMAC Cert. # C 143; key establishment methodology provides 128 or
256 bits of encryption strength);
Table 2: FIPS Approved and Allowed Security Functions for Oracle Acme Packet Cryptographic Library
Approved or Allowed Security Functions Cert #
SymmetricAlgorithms
AES CBC; Encrypt/Decrypt; Key Size = 128, 256 C 141
Triple DES2
CBC; Encrypt/Decrypt; Key Size = 192 C 141
Secure Hash Standard (SHS)
SHS SHA-1, SHA-256, SHA-384, SHA-512 C 141
Data Authentication Code
2
Per IG A.13 the same Triple-DES key shall not be used to encrypt more than 2^20 64-bit blocks of data.
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 6 of 33
HMAC HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512 C 141
AsymmetricAlgorithms
RSA RSA: 186-4:
186-4 KEY(gen): FIPS186-4_Random_e PKCS1.5: SIG(Ver) (1024 SHA(1); (2048 SHA (1))
C 141
Key Establishment
Key Derivation SSH KDF, IKEv1/IKEv2 KDF C 141
Key Transport
KTS KTS (AES Cert. # C 141 and HMAC Cert. # C 141; key establishment methodology provides 128 or 256 bits
of encryption strength);
Table 3: FIPS Approved and Allowed Security Functions for Oracle Acme Packet Mocana Cryptographic Library
Note: P-384 for ECDSA was CAVP tested but is not utilized by the module’s services.
Note: Triple-DES was CAVP tested but is not utilized by the services associated with the Oracle Acme Packet
Cryptographic Library Acme Packet for the 4600, 6300 and 6350. The services that are associated with Oracle
Acme Packet Cryptographic Library are SNMP, SRTP and TLS.
Approved or Allowed Security Functions Cert #
SymmetricAlgorithms
AES CBC; Encrypt/Decrypt; Key Size = 128, 256 5257
Triple DES3 CBC; Encrypt/Decrypt; Key Size = 192 2659
CVL
CVL RSADP, Mod Size 2048 1728
Table 4: FIPS Approved and Allowed Security Functions for Cavium Nitrox
Approved or Allowed Security Functions Cert #
SymmetricAlgorithms
AES ECB; Encrypt/Decrypt; Key Size = 128
CTR; Encrypt; Key Size = 128
5256
Key Establishment
Key Derivation SRTP KDF 1727
Table 5: FIPS Approved and Allowed Security Functions for Cavium Octeon
3.4 Non-Approved But Allowed Security Functions
The following are considered non-Approved but allowed security functions:
Algorithm Usage
EC-Diffie-Hellman CVL Certs. #C143, #C141 and #1727, key agreement; key establishment methodology
3
Per IG A.13 the same Triple-DES key shall not be used to encrypt more than 2^20 64-bit blocks of data.
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 7 of 33
Algorithm Usage
provides 128 or 192 bits of encryption strength
Diffie-Hellman CVL Certs. #C143, #C141 and #1727, key agreement; key establishment methodology
provides 112 bits of encryption strength
RSA Key Wrapping Key wrapping, key establishment methodology provides 112-bits of encryption strength
NDRNG Used for seeding the NIST SP 800-90A Hash_DRBG and CTR_DRBG. Per FIPS 140-2 IG 7.14
scenario 1 (a).
The module provides a minimum of 440 bits of entropy input for the Hash_DRBG. The input
length for the CTR_DRBG depends on the size of the AES key used. If the AES key length is 128
bits, the seed size is 256 bits. If the AES key length is 256 bits, then the seed size is 384 bits.
MD5 (TLS 1.0/1.1/1.2) MACing: HMAC MD5, Hashing: MD5
Table 6: Non-Approved but Allowed Security Functions
3.5 Non-Approved Security Functions and Services
The following services are considered non-Approved and may not be used in a FIPS-approved mode of operation:
Service Non-Approved Security Functions
SSH Asymmetric Algorithms: DSA, Symmetric Algorithms: Rijndael, AES GCM, 192-Bit AES CTR
SNMP Hashing: MD5, Symmetric Algorithms: DES
SRTP Hashing: MD5
IKEv1/IKEv2 Hashing: MD5, Symmetric Algorithms: 192-Bit AES CBC
TLS 1.0/1.1/1.2 Symmetric Algorithms: DES
Diffie-Hellman Key agreement, less than 112 bits of encryption strength.
RSA Key Wrapping Key wrapping, less than 112 bits of encryption strength.
Table 7: Non-Approved Disallowed Functions
Services listed in the previous table make use non-compliant cryptographic algorithms. Use of these algorithms
are prohibited in a FIPS-approved mode of operation. These services are allowed in FIPS mode when using
allowed algorithms (as specified in section 9.1).
3.6 Vendor Affirmed Security Functions
The following services are considered non-Approved and may not be used in a FIPS-approved mode of operation:
Algorithm Vendor Affirmed Security Functions
CKG In accordance with FIPS 140-2 IG D.12, the cryptographic module performs Cryptographic Key
Generation (CKG) as per SP800-133 (vendor affirmed). The resulting generated symmetric keys
and the seed used in the asymmetric key generation are the unmodified output from an NIST
SP 800-90A DRBG.
Table 8: Vendor Affirmed Functions
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 8 of 33
4. Module Ports and Interfaces
The module interfaces can be categorized as follows the FIPS 140-2 Standard:
• Data Input Interface
• Data Output Interface
• Control Input interface
• Status Output Interface
• Power Interface
The table below provides a mapping of ports for the Acme Packet 4600:
Logical Interface Physical Ports Information Input/Output
Data Input Ethernet SFP Ports (P0,1,2,3)
Ethernet RJ-45 ports (P4 and P5)
Ethernet MGT Ports
(Mgmt0, Mgmt1, Mgmt2)
Cipher text
Plain text
Data Output Ethernet SFP Ports (P0,1,2,3)
Ethernet RJ-45 ports (P4 and P5)
Ethernet MGT Ports
(Mgmt0, Mgmt1, Mgmt2)
Cipher text
Plain text
Control Input Ethernet SFP Ports (P0,1,2,3)
Ethernet RJ-45 ports (P4 and P5)
Console Port
Reset Button
Power Switch
Ethernet MGT Ports
(Mgmt0, Mgmt1, Mgmt2)
Plaintext control input via console port
(configuration commands, operator
passwords)
Ciphertext control input via network
management (EMS control, CDR
accounting, CLI management)
Status Output Ethernet SFP Ports (P0,1,2,3)
Ethernet RJ-45 ports (P4 and P5)
Console Port
Alarm Port
Ethernet MGT Ports (Mgmt0, Mgmt1,
Mgmt2)
LEDs
LCD
Plaintext status output via console
port.
Ciphertext status output via network
management
Power Power Plug N/A
Table 9: Mapping of FIPS 140 Logical Interfaces to Physical Ports
The table below provides a mapping of ports for the Acme Packet 4600:
Physical Interface Number of Ports Description / Use
Console Port 1 Provides console access to the module. The module supports only one
active serial console connection at a time.
Console port communication is used for administration and
maintenance purposes from a central office (CO) location. Tasks
conducted over a console port include:
• Configuring the boot process and management network
• Creating the initial connection to the module
• Accessing and using functionality available via the ACLI
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 9 of 33
Physical Interface Number of Ports Description / Use
• Performing in-lab system maintenance (services described
below)
• Performing factory-reset to zeroize nvram and keys
Alarm Port 1 Provides status output
USB Ports 1 This port is used for recovery. e.g. system re-installation after
zeroization.
Ethernet
Management ports
3
(Mgmt0, Mgmt1,
Mgmt2)
Used for EMS control, CDR accounting, CLI management, and other
management functions
Signaling and Media
Ethernet ports
6
(SFP P0,1,2,3
RJ-45 P4, P5)
Provide network connectivity for signaling and media traffic.
These ports are also used for incoming and outgoing data (voice)
connections.
Table 10: Physical Ports
Figure 4: Acme Packet 4600 - Front View
Figure 5: Acme Packet 4600 - Rear View
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 10 of 33
The table below provides a mapping of ports for the Acme Packet 6300 and Acme Packet 6350:
Logical Interface Physical Ports Information Input/Output
Data Input Ethernet Ports (Slot 0 P0,1
and Slot 1 P0,1)
Ethernet MGT Ports
(Mgmt0, Mgmt1, Mgmt2)
Cipher text
Plain text
Data Output Ethernet Ports (Slot 0 P0,1
and Slot 1 P0,1)
Ethernet MGT Ports
(Mgmt0, Mgmt1, Mgmt2)
Cipher text
Plain text
Control Input Console Port
Reset Button
Power Switch
Ethernet Ports (Slot 0 P0,1
and Slot 1 P0,1)
Ethernet MGT Ports
(Mgmt0, Mgmt1, Mgmt2)
Plaintext control input via console port
(configuration commands, operator passwords)
Ciphertext control input via network management
(EMS control, CDR accounting, CLI management)
Status Output Console Port
Alarm Port
Ethernet Ports (Slot 0 P0,1
and Slot 1 P0,1)
Ethernet MGT Ports
(Mgmt0, Mgmt1, Mgmt2)
LEDs
LCD
Plaintext status output via console port.
Ciphertext status output via network management
Power Power Plug N/A
Table 11: Mapping of FIPS 140 Logical Interfaces to Physical ports
The table below describes the interfaces on the Acme Packet 6300 and Acme Packet 6350:
Physical
Interface
Number
of Ports
6300
Number
of Ports
6350
Description / Use
Console Port 1 1 Provides console access to the module. The module supports only one
active serial console connection at a time.
Console port communication is used for administration and maintenance
purposes from a central office (CO) location. Tasks conducted over a
console port include:
• Configuring the boot process and management network
• Creating the initial connection to the module
• Accessing and using functionality available via the ACLI
• Performing in-lab system maintenance (services described below)
• Performing factory-reset to zeroize nvram and keys in Flash
Alarm Port 1 1 Provides status output
USB Ports 1 1 This port is used for recovery. e.g. system re-installation after zeroization.
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 11 of 33
Physical
Interface
Number
of Ports
6300
Number
of Ports
6350
Description / Use
Management
Ethernet ports
3
(Mgmt0,
Mgmt1,
Mgmt2)
3
(Mgmt0,
Mgmt1,
Mgmt2)
Used for EMS control, CDR accounting, CLI management, and other management
functions.
Signaling and
Media Ethernet
ports
4
(Slot 0 P0,1
and Slot 1
P0,1)
2
(Slot 0 P0,1
and Slot 1
P0,1)
Provide network connectivity for signaling and media traffic.
These ports are also used for incoming and outgoing data (voice) connections.
Table 12: Physical Ports
Figure 6: Acme Packet 6300 - Front View
Figure 7: Acme Packet 6300 - Rear View
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 12 of 33
Figure 8: Acme Packet 6350 - Front View
Figure 9: Acme Packet 6350 - Rear View
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 13 of 33
5. Physical Security
The module’s physical embodiment is that of a multi-chip standalone device that meets Level 1 Physical Security
requirements. The module is completely enclosed in a rack mountable chassis.
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 14 of 33
6. Operational Environment
The modules support a limited modifiable operational environment as per the FIPS 140-2 Section 4.6.
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 15 of 33
7. Roles and Services
As required by FIPS 140-2 Level 2, there are three roles (a Crypto Officer Role, User Role, and Unauthenticated Role) in the module that
operators may assume. The module supports role-based authentication, and the respective services for each role are described in the following
sections. The below table gives a high-level description of all services provided by the module and lists the roles allowed to invoke each service.
Operator Role Summary of Services
User • View configuration versions and system performance data
• Test pattern rules, local policies, and session translations
• Display system alarms.
Crypto-Officer Allowed access to all system commands and configuration privileges
Unauthenticated • Request Authentication
• Show Status
• Initiate self-tests
Table 13: Service Summary
7.1 Operator Services and Descriptions
The below table provides a full description of all services provided by the module and lists the roles allowed to invoke each service.
U CO Service Name Service Description Keys and CSP(s) Access Type(s)
X Configure Initializes the module for FIPS mode of operation HMAC-SHA-256 key R, W, X
X Zeroize CSP’s Clears keys/CSPs from memory and disk All CSP’s Z
X Firmware
Update
Updates firmware Firmware Integrity Key (RSA) R, X
X Bypass Configure bypass using TCP or UDP and viewing
bypass service status
HMAC-SHA-256 Bypass Key R, W, X
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 16 of 33
U CO Service Name Service Description Keys and CSP(s) Access Type(s)
X X Decrypt Decrypts a block of data Using AES or Triple-DES in
FIPS Mode
TLS Session Keys (AES128)
TLS Session Keys (AES256)
SSH Session Key (AES128)
SSH Session Key (AES256)
SRTP Session Key (AES-128)
SNMP Privacy Key (AES-128)
IKE Session Encryption Key (Triple-DES,
AES-128, AES-256)
IPsec Session Encryption Key (Triple-
DES, AES-128 or AES-256)
X
X
X
X
X
X
X
X
X X Encrypt Encrypts a block of data Using AES or Triple-DES in
FIPS Mode
TLS Session Keys (AES128)
TLS Session Keys (AES256)
SSH Session Key (AES128)
SSH Session Key (AES256)
SRTP Session Key (AES-128)
SNMP Privacy Key (AES-128)
IKE Session Encryption Key (Triple-DES,
AES-128, AES-256)
IPsec Session Encryption Key (Triple-
DES, AES-128 or AES-256)
X
X
X
X
X
X
X
X
X X Generate Keys Generates AES or Triple-DES for encrypt/decrypt
operations.
TLS Session Keys (AES128)
TLS Session Keys (AES256)
SSH Session Key (AES128)
SSH Session Key (AES256)
SRTP Session Key (AES-128)
SNMP Privacy Key (AES-128)
IKE Session Encryption Key (Triple-DES,
AES-128, AES-256)
IPsec Session Encryption Key (Triple-
DES, AES-128 or AES-256)
R, W
R, W
R, W
R, W
R, W
R, W
R, W
R, W
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 17 of 33
U CO Service Name Service Description Keys and CSP(s) Access Type(s)
Generates Diffie-Hellman, EC Diffie-Hellman, and RSA
keys for key transport/key establishment.
Diffie-Hellman Public Key (DH)
Diffie-Hellman Private Key (DH)
EC Diffie-Hellman Public Key (ECDH)
EC Diffie-Hellman Private Key (ECDH)
SSH authentication private Key (RSA)
SSH authentication public key (RSA)
TLS authentication private Key
(ECDSA/RSA)
TLS authentication public key
(ECDSA/RSA)
TLS premaster secret,
TLS Master secret,
SRTP Master key
IKE Private Key (RSA)
IKE Public Key (RSA)
SKEYSEED
SKEYID
SKEYID_d
R, W
R, W
R, W
R, W
R, W
R, W
R, W
R, W
R, W
R, W
R, W
R, W
R, W
R, W
R, W
R, W
X X Verify Used as part of the TLS, SSH protocol negotiation SSH authentication private Key (RSA)
SSH authentication public key (RSA)
TLS authentication private Key
(ECDSA/RSA)
TLS authentication public key
(ECDSA/RSA)
Diffie-Hellman Public Key (DH)
Diffie-Hellman Private Key (DH)
EC Diffie-Hellman Public Key (ECDH)
EC Diffie-Hellman Private Key (ECDH)
X
X
X
X
X
X
X
X
X X Generate Seed Generate an entropy_input for Hash_DRBG, CTR
DRBG
DRBG Seed
DRBG Entropy Input String
R, W, X
R, W, X
X X Generate
Random
Number
Generate random number. DRBG C
DRBG V
DRBG Key
R, W, X
R, W, X
R, W, X
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 18 of 33
U CO Service Name Service Description Keys and CSP(s) Access Type(s)
X X HMAC Generate HMAC SNMP Authentication Key
SRTP Authentication Key
SSH Integrity Keys
TLS Integrity Keys
IPsec Session
Authentication Key
IKE Session
Authentication Key
X
X
X
X
X
X
X X Generate
Certificate
Generate certificate Web UI Certificate R, W, X
X X Authenticate Authenticate Users Operator Password R, W, X
R – Read, W – Write, X – Execute, Z - Zeroize
Table 14: Operator Services and Descriptions
Note: TLS, SRTP and SNMP protocols use the Oracle Acme Packet Cryptographic library.
Note: SSH, IKEv2 and IPSec use the Oracle Acme Packet Mocana Cryptographic library.
7.2 Unauthenticated Services and Descriptions
The below table provides a full description of the unauthenticated services provided by the module:
Service Name Service Description
Authentication Request authentication to an authorized role.
On-Demand Self-Test Initialization This service initiates the FIPS self-test when requested.
Show Status This service shows the operational status of the module
Table 15: Operator Services and Descriptions
7.3 Operator Authentication
7.3.1 Crypto-Officer: Password-Based Authentication
In FIPS-approved mode of operation, the module is accessed via Command Line Interface over the Console ports or via SSH or SNMPv3 over the
Network Management Ports. Other than status functions available by viewing the Status LEDs, the services described are available only to
authenticated operators.
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 19 of 33
Method Probability of a Single Successful Random Attempt Probability of a Successful Attempt within a Minute
Password-Based
(CO and User
Authentication
to management
interfaces)
Passwords must be a minimum of 8 characters. The
password can consist of alphanumeric values, {a-z, A-Z, 0-9,
and special characters], yielding 94 choices per character.
The probability of a successful random attempt is 1/94^8,
which is less than 1/1,000,000.
Passwords must be a minimum of 8 characters. The password can
consist of alphanumeric values, {a-z, A-Z, 0-9, and special characters],
yielding 94 choices per character Assuming 10 attempts per second via
a scripted or automatic attack, the probability of a success with
multiple attempts in a one-minute period is 600/94^8, which is less
than 1/100,000.
SNMPv3
Passwords
Passwords must be a minimum of 8 characters. The
password can consist of alphanumeric values, {a-z, A-Z, 0-9,
and special characters], yielding 94 choices per character.
The probability of a successful random attempt is 1/94^8,
which is less than 1/1,000,000.
Passwords must be a minimum of 8 characters. The password can
consist of alphanumeric values, {a-z, A-Z, 0-9, and special characters],
yielding 94 choices per character. Assuming 10 attempts per second
via a scripted or automatic attack, the probability of a success with
multiple attempts in a one-minute period is 600/94^8, which is less
than 1/100,000.
Password-Based
(SIP
Authentication
Challenge
Response)
Passwords must be a minimum of 12 numeric characters. 0-
9, yielding 10 choices per character. The probability of a
successful random attempt is 1/10^12, which is less than
1/1,000,000.
Passwords must be a minimum of 12 numeric characters. 0-9, yielding
10 choices per character. Assuming 10 attempts per second via a
scripted or automatic attack, the probability of a success with multiple
attempts in a one-minute period is 600/10^12, which is less than
1/100,000.
Table 16: Crypto-Officer Authentication
7.3.2 User: Certificate-Based Authentication
The module also supports authentication via digital certificates for the User Role as implemented by the TLS and SSH protocols. The module
supports a public key based authentication with 2048-bit RSA and 2048-bit ECDSA keys.
Method Probability of a Single Successful Random Attempt Probability of a Successful Attempt within a Minute
Certificate-
Based
A 2048-bit RSA/ECDSA key has at least 112-bits of equivalent
strength. The probability of a successful random attempt is 1
/2^112, which is less than 1/1,000,000.
Assuming the module can support 60 authentication attempts in one
minute, the probability of a success with multiple consecutive
attempts in a one-minute period is 60/2^112, which is less than
1/100,000.
Table 17: User Authentication
7.4 Key and CSP Management
The following keys, cryptographic key components and other critical security parameters are contained in the module. No parts of the SSH, TLS,
or SNMP protocol, other than the KDF, have been tested by the CAVP and CMVP.
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 20 of 33
CSP Name Generation/Input Establishment/ Export Storage Use
Operator Passwords Generated by the crypto
officer as per the module
policy
Agreement: NA
Entry: Entry via console or SSH
management session
Output: Output as part of HA
direct physical connection
Non Volatile RAM Authentication of the crypto officer and
user
Firmware Integrity
Key (RSA)
Generated externally Entry: RSA (2048 bits) entered
as part of Firmware image
Output: Output as part of HA
direct physical connection
Flash Public key used to verify the integrity of
firmware and updates
DRBG Entropy Input
String
Generated internally from
hardware sources
Agreement: NA
Entry: NA
Output: None
Volatile RAM Used in the random bit generation
process
DRBG Seed Generated internally from
hardware sources
Agreement: NA
Entry: NA
Output: None
Volatile RAM Used in the random bit generation
process
DRBG Key Internal value used as part
of SP 800-90A CTR_DRBG
Agreement: NA
Entry: NA
Output: None
Volatile RAM Used in the random bit generation
process
DRBG V Internal value used as part
of SP 800-90A DRBG
Agreement: NA
Entry: NA
Output: None
Volatile RAM Used in the random bit generation
process
DRBG C Internal value used as part Agreement: NA Volatile RAM Used in the random bit generation
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 21 of 33
CSP Name Generation/Input Establishment/ Export Storage Use
of SP 800-90A HASH_DRBG
Entry: NA
Output: None
process
Diffie-Hellman Public
Key (DH) 2048-bit
Internal generation by FIPS-
approved CTR_DRBG in
firmware
Agreement: Diffie-Hellman
Entry: NA
Output: None
Volatile RAM Used to derive the secret session key
during DH key agreement protocol
Diffie-Hellman
Private Key (DH) 224
bit
Internal generation by FIPS-
approved CTR_DRBG
Agreement: Diffie-Hellman
Entry: NA
Output: None
Volatile RAM Used to derive the secret session key
during DH key agreement protocol
ECDH Public Key (P-
256)
Internal generation by FIPS-
approved CTR_DRBG in
firmware
Agreement: EC Diffie-Hellman
Entry: NA
Output: None
Volatile RAM Used to derive the secret session key
during ECDH key agreement protocol
ECDH Private Key (P-
256)
Internal generation by FIPS-
approved CTR_DRBG
Agreement: EC Diffie-Hellman
Entry: NA
Output: None
Volatile RAM Used to derive the secret session key
during ECDH key agreement protocol
SNMP Privacy Key
(AES-128)
NIST SP 800-135 KDF Agreement: NIST SP 800-135
KDF
Entry: NA
Output: Output as part of HA
direct physical connection
Volatile RAM For encryption / decryption of SNMP
session traffic
SNMP Authentication Internal generation by FIPS- Agreement: NA Volatile RAM 160-bit HMAC-SHA-1 for message
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 22 of 33
CSP Name Generation/Input Establishment/ Export Storage Use
Key (HMAC-SHA1) approved CTR_DRBG in
firmware Output: Output as part of HA
direct physical connection
authentication and verification in
SNMP
SRTP Master Key
(AES-128)
Internal generation by FIPS-
approved Hash_DRBG in
firmware
Agreement: Diffie-Hellman
Entry: NA
Output: encrypted or output as
part of HA direct physical
connection
Volatile RAM Generation of SRTP session keys
SRTP Session Key
(AES-128)
NIST SP 800-135 KDF Agreement: NIST SP 800-135
KDF
Entry: NA
Output: Output as part of HA
direct physical connection
Volatile RAM For encryption / decryption of SRTP
session traffic
SRTP Authentication
Key (HMAC-SHA1)
Derived from the master
key
Agreement: NA
Output: Output as part of HA
direct physical connection
Volatile RAM 160-bit HMAC-SHA-1 for message
authentication and verification in SRTP
SSH Authentication
Private Key (RSA)
Internal generation by FIPS-
approved CTR_DRBG
Agreement: RSA (2048 bits)
Output: Output as part of HA
direct physical connection
Flash Memory RSA private key for SSH authentication
SSH Authentication
Public Key (RSA)
Internal generation by FIPS-
approved CTR_DRBG
Agreement: RSA (2048 bits)
Output: Output as part of HA
direct physical connection
Flash Memory RSA public key for SSH authentication.
SSH Session Keys (
AES-128, AES-256)
Derived via SSH KDF.
Note: These keys are
generated via SSH (IETF RFC
4251). This protocol
Agreement: Diffie-Hellman Volatile RAM Encryption and decryption of SSH
session
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 23 of 33
CSP Name Generation/Input Establishment/ Export Storage Use
enforces limits on the
number of total possible
encryption/decryption
operations.
SSH Integrity Keys
(HMAC-SHA1)
Derived via SSH KDF. Agreement: NA
Output: Output as part of HA
direct physical connection
Volatile RAM 160-bit HMAC-SHA-1 for message
authentication and verification in SSH
TLS Authentication
Private Key
(ECDSA/RSA)
Internal generation by FIPS-
approved CTR_DRBG
Agreement: RSA (2048bits);
ECDSA (P- 256/P-384)
Output: Output as part of HA
direct physical connection
Flash Memory ECDSA/RSA private key for TLS
authentication
TLS Authentication
Public Key
(ECDSA/RSA)
Internal generation by FIPS-
approved CTR_DRBG
Agreement: RSA (2048bits);
ECDSA (P- 256/P-384)
Output: Output as part of HA
direct physical connection
Volatile RAM ECDSA/RSA public key for TLS
authentication.
TLS Premaster Secret
(48 Bytes)
Internal generation by FIPS-
approved CTR_DRBG in
firmware
Agreement: NA
Entry: Input during TLS
negotiation
Output: Output to peer
encrypted by Public Key
Volatile RAM Establishes TLS master secret
TLS Master Secret
(48 Bytes)
Derived from the TLS Pre-
Master Secret
Agreement: NA Volatile RAM Used for computing the Session Key
TLS Session Keys (
AES-128, AES-256)
Derived from the TLS
Master Secret
Note: These keys are
generated via TLS (IETF RFC
5246). This protocol
Agreement: RSA key transport Volatile RAM Used for encryption & decryption of
TLS session
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 24 of 33
CSP Name Generation/Input Establishment/ Export Storage Use
enforces limits on the
number of total possible
encryption/decryption
operations.
TLS Integrity Keys
(HMAC-SHA1)
Internal generation by FIPS-
approved CTR_DRBG in
firmware
Agreement: NA
Output: Output as part of HA
direct physical connection
Volatile RAM 160-bit HMAC-SHA-1 for message
authentication and verification in TLS
SKEYSEED
(20 Bytes)
Derived by using key
derivation function defined
in SP800-135 KDF (IKEv2).
Agreement: NIST SP 800-135
KDF
Entry: NA
Output: Output as part of HA
direct physical connection to
another box
Volatile RAM 160 bit shared secret known only to IKE
peers. Used to derive IKE session keys
SKEYID
(20 Bytes)
Derived by using key
derivation function defined
in SP800-135 KDF (IKEv2).
Agreement: NIST SP 800-135
KDF
Entry: NA
Output: Output as part of HA
direct physical connection to
another box
Volatile RAM 160 bit secret value used to derive
other IKE secrets
SKEYID_d
(20 Bytes)
Derived using SKEYID, Diffie
Hellman shared secret and
other non-secret values
through key derivation
function defined in
SP800135 KDF
(IKEv1/IKEv2).
Agreement: NIST SP 800-135
KDF
Entry: NA
Output: Output as part of HA
direct physical connection to
another box
Volatile RAM 160 bit secret value used to derive IKE
session keys
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 25 of 33
CSP Name Generation/Input Establishment/ Export Storage Use
IKE Pre-Shared Key Preloaded by the Crypto
Officer.
Agreement: NA
Output: Output as part of HA
direct physical connection to
another box
Flash Memory Secret used to derive IKE skeyid when
using pre-shared secret authentication
IKE Session
Encryption Key
(Triple-DES, AES-128,
AES-256 bit)
Derived via key derivation
function defined in SP800-
135 KDF (IKEv1/IKEv2)
Agreement: NIST SP 800-135
KDF
Entry: NA
Output: Output as part of HA
direct physical connection to
another box
Volatile RAM Triple-DES, AES 128 and 256 key used
to encrypt data
IKE Session
Authentication Key
(HMAC-SHA-512)
Derived via key derivation
function defined in SP800-
135 KDF (IKEv1/IKEv2)
Agreement: NIST SP 800-135
KDF
Entry: NA
Output: Output as part of HA
direct physical connection to
another box
Volatile RAM 512 bit key HMAC-SHA-512 used for
data authentication
IKE Private Key
(RSA 2048 bit)
Internal generation by FIPS-
approved CTR_DRBG in
firmware
Agreement: RSA (2048 bits)
Output: Output as part of HA
direct physical connection to
another box
Volatile RAM RSA 2048 bit key used to authenticate
the module to a peer during IKE
IKE Public Key
(RSA 2048-bit)
Internal generation by FIPS-
approved CTR_DRBG in
firmware
Agreement: RSA (2048 bits)
Output: Output as part of HA
direct physical connection to
another box
Volatile RAM RSA 2048 bit public key for TLS
authentication.
IPsec Session
Encryption Key
Derived via a key derivation
function defined in SP800-
Agreement: NIST SP 800-135 Volatile RAM Triple-DES, AES 128 or 256 bit key used
to encrypt data
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 26 of 33
CSP Name Generation/Input Establishment/ Export Storage Use
(Triple-DES, AES-128
or AES-256 bit)
135 KDF (IKEv1/IKEv2). KDF
Entry: NA
Output: Output as part of HA
direct physical connection to
another box
IPsec Session
Authentication Key
(HMAC-SHA-512)
Derived via a key derivation
function defined in SP800-
135 KDF (IKEv1/IKEv2).
Agreement: NIST SP 800-135
KDF
Entry: NA
Output: Output as part of HA
direct physical connection to
another box
Volatile RAM 512 bit HMAC-SHA-512 key used for
data authentication for IPsec traffic
Web UI Certificate Internal generation by FIPS
approved CTR_DRBG in
firmware
Agreement: NA
Output: TLS session with
operator
Flash Web server certificate
Bypass Key (HMAC-
SHA-256)
Internal generation by FIPS-
approved CTR_DRBG in
firmware
Agreement: NA
Output: NA
Flash Memory 256-bit HMAC-SHA-256 used to protect
bypass table
Table 18: CSP Table
Note: When the module generates symmetric keys or seeds used for generating asymmetric keys, unmodified DRBG output is used as the
symmetric key or as the seed for generating the asymmetric keys.
Note: All keys generated by the module use the direct output of a FIPS approved DRBG. This meets the requirements of SP 800-133.
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 27 of 33
8. Self-Tests
The modules include an array of self-tests that are run during startup and conditionally during operations to
prevent any secure data from being released and to ensure all components are functioning correctly. Self-tests
may be run on-demand by power cycling the module.
8.1 Power-Up Self-Tests
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350 appliances perform the following power-up self-
tests when power is applied to the module. These self-tests require no inputs or actions from the operator:
8.1.1 Firmware Integrity Test
• Firmware Integrity Test (RSA 2048/SHA-256)
8.1.2 Mocana Cryptographic Library Self-Tests
• AES (Encrypt/Decrypt) Known Answer Test;
• Triple-DES (Encrypt/Decrypt) Known Answer Test;
• SHA-1 Known Answer Test;
• SHA-256 Known Answer Test;
• SHA-384 Known Answer Test;
• SHA-512 Known Answer Test;
• HMAC-SHA-1 Known Answer Test;
• HMAC-SHA-256 Known Answer Test;
• HMAC-SHA-384 Known Answer Test;
• HMAC-SHA-512 Known Answer Test; and
• RSA Verify Test.
8.1.3 Oracle Acme Packet Cryptographic Library Self-Tests
• SHA-1 Known Answer Test;
• SHA-256 Known Answer Test;
• SHA-512 Known Answer Test;
• HMAC-SHA-1 Known Answer Test;
• HMAC-SHA-256 Known Answer Test;
• HMAC-SHA-384 Known Answer Test;
• HMAC-SHA-512 Known Answer Test;
• AES (Encrypt/Decrypt) Known Answer Test;
• AES GCM (Encrypt/Decrypt) Known Answer Test;
• SP 800-90A DRBG Known Answer Test;
• RSA sign/verify Known Answer Test; and
• ECDSA sign/verify Known Answer Test.
8.1.4 Nitrox Self-Tests
• AES (Encrypt/Decrypt) Known Answer Test;
• Triple-DES (Encrypt/Decrypt) Known Answer Test; and
• RSA Sign/Verify Known Answer Test.
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 28 of 33
8.1.5 Octeon Self-tests
• AES (Encrypt/Decrypt) Known Answer Test
When the modules are in a power-up self-test state or error state, the data output interface is inhibited and
remains inhibited until the module can transition into an operational state. While the CO may attempt to restart
the module to clear an error, the module will require re-installation in the event of a hard error such as a failed
self-test.
8.2 Critical Functions Self-Tests
Acme Packet 4600 [1], Acme Packet 6300 [2] and Acme Packet 6350 [3] appliances perform the following critical
self-tests. These critical function tests are performed for each SP 800-90A DRBG implemented within the module.
• SP 800-90A Instantiation Test
• SP 800-90A Generate Test
• SP 800-90A Reseed Test
• SP 800-90A Uninstantiate Test
8.3 Conditional Self-Tests
The module performs the following conditional self-tests when called by the module:
• Pair Wise consistency tests to verify that the asymmetric keys generated for RSA, and ECDSA work correctly by
performing a sign and verify operation;
• Continuous Random Number Generator test to verify that the output of approved-DRBGs is not the same as
the previously generated value;
• Continuous Random Number Generator test to verify that the output of entropy is not the same as the
previously generated value;
• Bypass conditional test using HMAC-SHA-256 to ensure the mechanism governing media traffic is functioning
correctly, and;
• Firmware Load test using a 2048-bit/SHA-256 RSA-Based integrity test to verify firmware to be loaded into the
module.
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 29 of 33
9. Crypto-Officer and User Guidance
The modules include an array of self-tests that are run during startup and conditionally during operations to
prevent any secure data from being released and to ensure all components are functioning correctly. Self-tests
may be run on-demand by power cycling the module.
FIPS Mode is enabled by a license installed by Oracle, which will open/lock down features where appropriate.
This section describes the configuration, maintenance, and administration of the cryptographic module.
9.1 Secure Setup and Initialization
The operator shall set up the device as defined in the Session Border Controller ACLI Configuration Guide. The
Crypto-Officer shall also:
• Verify that the firmware version of the module is Version S-Cz8.2.0.
• A new account for the Crypto-Officer and User shall be created as part of Setup and Initialization process.
Upon creation of the new CO and User accounts the “default” accounts shipped with the module shall be
disabled.
• Ensure all traffic is encapsulated in a TLS, SSH, or SRTP tunnel as appropriate.
• HTTPS shall be enabled and configure the web server certificate prior to connecting to the WebUI over TLS.
• Ensure that SNMP V3 is configured with AES-128/HMAC only.
• Ensure IKEv1 and IKEv2 is using AES CBC or CTR mode for encryption and HMAC-SHA-512 for authentication
• Ensure SSH is configured to use AES CTR mode for encryption.
• Ensure SSH and IKEv1/IKEv2 only use Diffie-Hellman group 14 in FIPS approved mode.
• Ensure all management traffic is encapsulated within a trusted session (i.e., Telnet should not be used in FIPS
mode of operation).
• Ensure RSA keys are at least 2048-bit keys for TLS, IKEv1/IKEv2. No 512-bit or 1024-bit keys can be used in FIPS
mode of operation.
• All operator passwords must be a minimum of 8 characters in length.
• Ensure use of FIPS-approved algorithms for TLS:
o TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
o TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
o TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
o TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
o TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
o TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
• Be aware that when configuring High Availability (HA), only a local HA configuration to a directly connected box
via a physical cable over the management port is allowed in FIPS Approved Mode. Remote HA is not allowed in
FIPS Approved mode.
• Be aware that HA configuration data that contains keys and CSP’s must never be transported over an untrusted
network. Ensure that the HA ports used for the transport of HA data (including keys and CSP’s) are bound to a
private IP address range during setup.
• Be aware that only the HA state transactions between the two devices over the direct physical connection are
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 30 of 33
permitted over those dedicated ports.
• RADIUS and TACACS+ shall not be used in FIPS approved mode.
• 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-2 validation.
Services in Table 7 of Section 3.5 make use non-compliant cryptographic algorithms. Use of these algorithms will place
the module in a non-Approved mode of operation.
9.2 AES-GCM IV Construction/Usage
The AES-GCM IV is used in the following protocols:
• TLS: The TLS AES-GCM IV is generated in compliance with TLSv1.2 GCM cipher suites as specified in RFC 5288
and section 3.3.1 of NIST SP 800-52rev1. Per RFC 5246, when the nonce_explicit part of the IV exhausts the
maximum number of possible values for a given session key, the module will trigger a handshake to establish a
new encryption key.
In case the module’s power is lost and then restored, the key used for the AES GCM encryption or decryption shall
be redistributed.
Note: IKE/IPSec does not use AES GCM.
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 31 of 33
10.Mitigation of Other Attacks
The module does not mitigate attacks beyond those identified in FIPS 140-2.
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 32 of 33
Acronyms Terms and Abbreviations
Term Definition
AES Advanced Encryption Standard
BBRAM Battery Backed RAM
CMVP Cryptographic Module Validation Program
CDR Call Data Record
CSEC Communications Security Establishment Canada
CSP Critical Security Parameter
DHE Diffie-Hellman Ephemeral
DRBG Deterministic Random Bit Generator
ESBC Enterprise Session Border Controller
ECDSA Elliptic Curve Digital Signature Algorithm
ESBC Enterprise Session Border Controller
EDC Error Detection Code
EMS Enterprise Management Server
HA High Availability
HMAC (Keyed) Hash Message Authentication Code
IKE Internet Key Exchange
KAT Known Answer Test
KDF Key Derivation Function
LED Light Emitting Diode
MGT Management
NIST National Institute of Standards and Technology
POST Power On Self Test
PUB Publication
RAM Random Access Memory
ROM Read Only Memory
SHA Secure Hash Algorithm
SNMP Simple Network Management Protocol
SRTP Secure Real Time Protocol
TDM Time Division Multiplexing
TLS Transport Layer Security
Table 19: Acronyms
Acme Packet 4600, Acme Packet 6300 and Acme Packet 6350
Page 33 of 33
References
The FIPS 140-2 standard, and information on the CMVP, can be found at
http://csrc.nist.gov/groups/STM/cmvp/index.html.
More information describing the module can be found on the Oracle web site at
https://www.oracle.com/industries/communications/enterprise/products/session-border-controller/index.html.
This Security Policy contains non-proprietary information. All other documentation submitted for FIPS 140-2
conformance testing and validation is “Oracle - Proprietary” and is releasable only under appropriate non-disclosure
agreements.
Document Author Title
FIPS PUB 140-2 NIST FIPS PUB 140-2: Security Requirements for Cryptographic Modules
FIPS IG NIST Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module
Validation Program
FIPS PUB 140-2 Annex A NIST FIPS 140-2 Annex A: Approved Security Functions
FIPS PUB 140-2 Annex B NIST FIPS 140-2 Annex B: Approved Protection Profiles
FIPS PUB 140-2 Annex C NIST FIPS 140-2 Annex C: Approved Random Number Generators
FIPS PUB 140-2 Annex D NIST FIPS 140-2 Annex D: Approved Key Establishment Techniques
DTR for FIPS PUB 140-2 NIST Derived Test Requirements (DTR) for FIPS PUB 140-2, Security Requirements for
Cryptographic Modules
NIST SP 800-67 NIST Recommendation for the Triple Data Encryption Algorithm TDEA Block Cypher
FIPS PUB 197 NIST Advanced Encryption Standard
FIPS PUB 198-1 NIST The Keyed Hash Message Authentication Code (HMAC)
FIPS PUB 186-4 NIST Digital Signature Standard (DSS)
FIPS PUB 180-4 NIST Secure Hash Standard (SHS)
NIST SP 800-131A NIST Recommendation for the Transitioning of Cryptographic Algorithms and Key Sizes
PKCS#1 RSA
Laboratories
PKCS#1 v2.1: RSA Cryptographic Standard
Table 20: References