FIPS 140-2 Non-Proprietary Security Policy Acme Packet 3820 and Acme Packet 4500 FIPS 140-2 Level 2 Validation Firmware Version ECx 6.4.1 and ECx 6.4.1 M1 Hardware Version A1 August 28, 2015 Copyright © 2015, 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. Document Version 3.0 © Oracle Communications Page 1 of 35 Table of Contents 1 Introduction............................................................................................................................................ 4 1.1 About FIPS 140-2 ..........................................................................................................................................4 1.2 About this Document....................................................................................................................................4 1.3 External Resources .......................................................................................................................................4 1.4 Notices..........................................................................................................................................................4 1.5 Acronyms......................................................................................................................................................5 2 Oracle Communications Acme Packet 3820 and Acme Packet 4500 ........................................................... 6 2.1 Product Overview .........................................................................................................................................6 2.2 Validation Level Detail..................................................................................................................................7 2.3 Algorithm Implementations .........................................................................................................................7 2.3.1 FIPS-Approved Algorithms .......................................................................................................................7 2.3.2 Non-Approved Algorithms and Protocols................................................................................................8 2.3.3 Non-Approved but Allowed Algorithms and Protocols ...........................................................................8 2.4 Cryptographic Module Specification ............................................................................................................9 2.5 Module Interfaces ......................................................................................................................................10 2.6 Roles, Services, and Authentication ...........................................................................................................12 2.6.1 Operator Services and Descriptions.......................................................................................................13 2.6.2 Operator Authentication .......................................................................................................................17 2.7 Physical Security.........................................................................................................................................17 2.8 Operational Environment...........................................................................................................................17 2.9 Cryptographic Key Management ...............................................................................................................19 2.10 Self-Tests ....................................................................................................................................................27 2.10.1 Power-On Self-Tests ..........................................................................................................................27 2.10.2 Conditional Self-Tests........................................................................................................................28 2.10.3 Critical Functions Test .......................................................................................................................29 2.11 Mitigation of Other Attacks .......................................................................................................................29 3 Guidance and Secure Operation............................................................................................................. 30 3.1 Crypto Officer Guidance .............................................................................................................................30 3.1.1 Enabling FIPS Mode and General Guidance...........................................................................................30 3.1.2 Placement of Tamper Evidence Labels ..................................................................................................31 3.2 User Guidance ............................................................................................................................................35 3.2.1 General Guidance ..................................................................................................................................35 Document Version 3.0 © Oracle Communications Page 2 of 35 List of Tables Table 1 ­ Acronyms and Terms......................................................................................................................................5 Table 2 ­ Validation Level by DTR Section.....................................................................................................................7 Table 3 ­ Algorithm Certificates for FIPS-Approved Algorithms in the Hifn 8450.........................................................7 Table 4 ­ Algorithm Certificates for FIPS-Approved Algorithms for the BCM5862 .......................................................8 Table 5 ­ Algorithm Certificates for FIPS-Approved Algorithms in Firmware ...............................................................8 Table 6 ­ Acme Packet 3820 Interface Descriptions ...................................................................................................10 Table 7 ­ Acme Packet 4500 Interface Descriptions ...................................................................................................11 Table 8 ­ Logical Interface / Physical Interface Mapping ............................................................................................12 Table 9 ­ Role Mapping ...............................................................................................................................................12 Table 10 ­ Operator Services and Descriptions...........................................................................................................16 Table 11 ­ Unauthenticated Operator Services and Descriptions...............................................................................16 Table 12 ­ Key/CSP Management Details....................................................................................................................26 Table 13 - Power-On Self-Tests....................................................................................................................................27 Table 14 ­ Conditional Self-Tests.................................................................................................................................28 Table 15 ­ Conditional Self Tests and Module Remediation .......................................................................................29 List of Figures Figure 1 ­ Acme Packet 3820 Physical Boundary ..........................................................................................................9 Figure 2 ­ Acme Packet 4500 Physical Boundary ........................................................................................................10 Figure 3 ­ Acme Packet 3820 Tamper Evidence Label Placement / Front ..................................................................31 Figure 4 ­ Acme Packet 3820 Tamper Evidence Label Placement / Rear....................................................................32 Figure 5 ­ Acme Packet 3820 Tamper Evidence Label Placement Top/Front .............................................................32 Figure 6 ­ Acme Packet 3820 Tamper Evidence Label Placement Bottom/Rear ........................................................33 Figure 7 ­ Acme Packet 4500 Tamper Evidence Label Placement Rear ......................................................................33 Figure 8 ­ Acme Packet 4500 Tamper Evidence Label Placement Front.....................................................................33 Figure 9 ­ Acme Packet 4500 Tamper Evidence Label Placement Top/Front .............................................................34 Figure 10 ­ Acme Packet 4500 Tamper Evidence Label Placement Rear Bottom .......................................................35 Document Version 3.0 © Oracle Communications Page 3 of 35 1 Introduction 1.1 About FIPS 140-2 Federal Information Processing Standards Publication 140-2 -- Security Requirements for Cryptographic Modules specifies requirements for cryptographic products to be deployed in a Sensitive but Unclassified environment. The National Institute of Standards and Technology (NIST) and Communications Security Establishment Canada (CSEC) jointly run the Cryptographic Module Validation Program (CMVP). The NIST National Voluntary Laboratory Accreditation Program (NVLAP) accredits independent testing labs to perform FIPS 140-2 testing; the CMVP validates test reports for all cryptographic modules pursuing FIPS 140-2 validation. Validation is the term given to a cryptographic module that is documented and tested against the FIPS 140-2 criteria. More information is available on the CMVP website at http://csrc.nist.gov/groups/STM/cmvp/index.html. 1.2 About this Document This non-proprietary Cryptographic Module Security Policy for the Acme Packet 3820 and Acme Packet 4500 from Oracle Communications provides an overview of the product and a high-level description of how it meets the security requirements of FIPS 140-2. This document also contains details on the cryptographic keys and critical security parameters. This Security Policy concludes with instructions and guidance on running the module in a FIPS 140 mode of operation. The Oracle Communications Acme Packet 3820 and Acme Packet 4500 may also be referred to as the "modules" in this document. 1.3 External Resources The Oracle Communications website (http://www.oracle.com/us/products/enterprise- communications/enterprise-session-border-controller/index.html) contains information on the full line of products from Oracle Communications, including a detailed overview of the Acme Packet 3820 and Acme Packet 4500 solution. The Cryptographic Module Validation Program website contains links to the FIPS 140-2 certificate and Oracle Communications contact information. 1.4 Notices This document may be freely reproduced and distributed in its entirety without modification. Document Version 3.0 © Oracle Communications Page 4 of 35 1.5 Acronyms The following table defines acronyms found in this document: Acronym Term ACLI Acme Command Line Interface AES Advanced Encryption Standard CBC Cipher Block Chaining CSEC Communications Security Establishment of Canada CSP Critical Security Parameter DTR Derived Testing Requirements EMS External Management Server FIPS Federal Information Processing Standard HMAC Hashed Message Authentication Code IP Internet Protocol KAT Known Answer Test NDRNG Non Deterministic Random Number Generation NIST National Institute of Standards and Technology OS Operating System PBX Private Branch Exchange RSA Rivest Shamir Adelman SBC Session Border Controller SHA Secure Hashing Algorithm SIP Session Initiation Protocol SLA Service Level Agreement SNMP Secure Network Management Protocol SRTP Secure Real Time Protocol VOIP Voice Over Internet Protocol VPN Virtual Private Network UC Unified Communications Table 1 ­ Acronyms and Terms Document Version 3.0 © Oracle Communications Page 5 of 35 2 Oracle Communications Acme Packet 3820 and Acme Packet 4500 2.1 Product Overview Oracle Communications session border controllers (SBC) provide critical control functions to deliver trusted, first-class interactive communications--voice, video and multimedia sessions--across IP network borders. They support multiple applications in government, service provider, enterprise and contact center networks--from VoIP trunking to hosted enterprise and residential services to fixed- mobile convergence. The Acme Packet 3820 platform supports up to 4,000 simultaneous signaled sessions for government agencies, smaller service providers, small enterprises and smaller sites within larger organizations. The Acme Packet 4500 is a carrier-class platform supporting up to 32,000 simultaneous signaled sessions, delivering unmatched capabilities and performance. It offers extremely rich functionality, architectural flexibility, signaling protocol breadth, and satisfies all of the performance, capacity, availability and manageability requirements of defense and security­focused government organizations, service providers, enterprises and contact centers. The modules feature Acme Packet's custom hardware design tightly integrated with Acme Packet OS to satisfy the most critical infrastructure security requirements. In government, enterprise, and contact center environments, the Acme Packet 3820 and Acme Packet 4500 secure SIP/H.323 trunking borders to service providers and other 3rd party IP networks and the internet border to remote offices, teleworkers, and mobile employees. In extremely security-conscious organizations, they secure the border to the private VPN connecting other sites. SIP and H.323 interworking capabilities ensure interoperability with and between legacy IP PBX equipment and next- generation unified communications platforms. They control session admission, IP PBX or UC server loads and overloads, IP network transport, and SIP/H.323 session routing to assure SLAs and minimize costs. Regulatory compliance requirements are also satisfied with encryption ensuring session privacy and call/session replication for recording. Document Version 3.0 © Oracle Communications Page 6 of 35 2.2 Validation Level Detail The following table lists the level of validation for each area in FIPS 140-2: FIPS 140-2 Section Title Validation Level Cryptographic Module Specification 2 Cryptographic Module Ports and Interfaces 2 Roles, Services, and Authentication 2 Finite State Model 2 Physical Security 2 Operational Environment N/A Cryptographic Key Management 2 Electromagnetic Interference / Electromagnetic Compatibility 2 Self-Tests 2 Design Assurance 3 Mitigation of Other Attacks N/A Table 2 ­ Validation Level by DTR Section 2.3 Algorithm Implementations 2.3.1 FIPS-Approved Algorithms The module contains the following algorithm implementations: Hifn 8450: bump-in-the-wire processing (HMAC-SHA-1, AES, TRIPLE-DES) Broadcom 5862 (BCM5862): DH, SHA-1, HMAC-SHA1, AES and Triple-DES for SSH and TLS Firmware running on Intel Core Duo T2500, Intel Core Duo T9400 and Intel Celeron M 440: random number generation, SHA-1, SHA-256, RSA, HMAC-SHA-1, HMAC-SHA-256, and Hash_DRBG These cryptographic algorithm implementations have received the following certificate numbers from the Cryptographic Algorithm Validation Program: Algorithm Type Algorithm Standard CAVP Certificate Use Keyed Hash HMAC-SHA-1, HMAC- Message verification FIPS 198-1 519 SHA-256 Hashing SHA-1, SHA-256 FIPS 180-4 912 Message digest Symmetric Key Three key Triple-DES Data encryption / NIST SP 800-67 745 (CBC mode) decryption AES 128 and 256 Data encryption / (CBC, ECB, CTR FIPS 197 928 decryption modes) Table 3 ­ Algorithm Certificates for FIPS-Approved Algorithms in the Hifn 8450 Document Version 3.0 © Oracle Communications Page 7 of 35 Algorithm Type Algorithm Standard CAVP Certificate Use Hashing SHA-1 FIPS 180-4 1378 Message digest Keyed Hash HMAC-SHA1 FIPS 198-1 907 Message verification Symmetric Key Three key Triple-DES Data encryption / NIST SP 800-67 1019 (CBC mode) decryption AES 128 and 256 Data encryption / (CBC, ECB, CTR FIPS 197 1555 decryption modes) Table 4 ­ Algorithm Certificates for FIPS-Approved Algorithms for the BCM5862 Algorithm Algorithm Standard F/W 6.4.1 F/W 6.4.1 Use Type Cert. # M1 Cert. # Hashing SHA-1 Message digest FIPS 180-4 2748 2788 SHA-256 Keyed Hash HMAC-SHA1 Message verification (via HMAC-SHA- FIPS 198-1 2107 2143 HMAC-SHA-256) and module 256 integrity (via HMAC-SHA-1 Asymmetric RSA 2048 Verify operations FIPS 186-2 1697 1724 Key Random Hash DRBG Random number generation Number SP800-90A 762 791 Generation Key Derivation TLS 1.0/1.1, Key derivation Function SSH, SRTP, SP 800-135 480 498 SNMP1 Table 5 ­ Algorithm Certificates for FIPS-Approved Algorithms in Firmware 2.3.2 Non-Approved Algorithms and Protocols The module implements the following non-approved algorithms and protocols: DES ARC4 HMAC-MD5 IPSEC o The FIPS 140-2 module validation does not cover the full protocol implementation for the IKE in IPSec and it is therefore considered a non-Approved service. SNMP V3 is considered non-FIPS mode in F/W version ECx 6.4.1. Unless otherwise noted, Non-Approved algorithms and protocols are not allowed for use in FIPS mode. 2.3.3 Non-Approved but Allowed Algorithms and Protocols The module implements the following non-approved but allowed algorithms and protocols in FIPS Approved Mode: 1 SNMP V3 is only FIPS Approved while running F/W version 6.4.1 M1 only. Document Version 3.0 © Oracle Communications Page 8 of 35 RSA (key transport/key establishment) o Used in FIPS mode for TLS sessions and SSH key establishment in and provides 112-bits of encryption strength, non-compliant less than 112 bits. Diffie-Hellman (key transport/key establishment) o Used in FIPS mode for SSH sessions key agreement/key establishment in and provides 112-bits of encryption strength in FIPS Approved Mode, non-compliant less than 112 bits of encryption strength. Hardware-based random number generator (entropy generation for seeding DRBG) o This RNG is used in FIPS mode only to generate entropy_input to the firmware-based FIPS- approved Hash_DRBG. 2.4 Cryptographic Module Specification The module is the Oracle Communications Acme Packet 3820 and Acme Packet 4500 running firmware versions ECx 6.4.1 and ECx 6.4.1 M1 on hardware version A1. The module is classified as a multi-chip standalone cryptographic module. The physical cryptographic boundary is defined as the module case and all components within the case. No components are excluded from the requirements of FIPS PUB 140-2. The specific models included in the validation are as follows: Acme Packet 3820 o Running network processor AMCC NP3750 @400 Mhz and host processor Intel Celeron M 440 o Running Hifn 8450 and Broadcom 5862 for dedicated, hardware-based cryptographic processing. Acme Packet 4500 o Running network processor AMCC NP3750 @700 Mhz and host processor Intel Core Duo T2500 o Running network processor AMCC NP3750 @700 Mhz and host processor Intel Core Duo T9400 o Running Hifn 8450 and Broadcom 5862 for dedicated, hardware-based cryptographic processing. The physical boundary for the modules are the entire module appliance and are pictured in the images below: Figure 1 ­ Acme Packet 3820 Physical Boundary Document Version 3.0 © Oracle Communications Page 9 of 35 Figure 2 ­ Acme Packet 4500 Physical Boundary The logical boundary for the modules is the entire firmware image. 2.5 Module Interfaces The table below describes the main interfaces on the Acme Packet 3820: Physical Interface Description / Use LEDs2 Indicates if any alarms are active on the module. The LED can be three different colors to indicate the severity of the alarms. Unlit--system is fully functional without any faults Amber--major alarm has been generated Red--critical alarm has been generated. Console Ports Provides console access to the module. The module supports only one active serial console connection at a time. The rear console port is useful for customers who want permanent console access; the front console port provides easy access to the module for a temporary connection. Console port communication is used for administration and maintenance purposes from a central office (CO) location. Tasks conducted over a console port include: Creating the initial connection to the module Accessing and using all functionality available via the ACLI Performing in-lab system maintenance (services described below) Alarm Port3 Closes a circuit when a specific alarm level becomes active. The module features an alarm control signal interface that can be used in a CO location to indicate when internal alarms are generated. The appliances use alarm levels that correspond to three levels of service-disrupting incidents. USB Ports USB ports are disabled. Network Management Used for EMS control, CDR accounting, CLI management, and other Ports management functions Signaling and Media Provide network connectivity for signaling and media traffic. Interfaces Table 6 ­ Acme Packet 3820 Interface Descriptions The table below describes the main interfaces on the Acme Packet 4500: 2 LED's do not provide FIPS Status indicators. FIPS status indicators are only in the form of logical indicators 3 Alarm port does not provide FIPS status indicators. Document Version 3.0 © Oracle Communications Page 10 of 35 Physical Interface Description / Use LCD Reports real-time status, alarms, and general system information LEDs4 Indicates if any alarms are active on the module. The LED can be three different colors to indicate the severity of the alarms. Unlit--system is fully functional without any faults Amber--major alarm has been generated Red--critical alarm has been generated. Console Ports Provides console access to the module. The module supports only one active serial console connection at a time. The rear console port is useful for customers who want permanent console access; the front console port provides easy access to the module for a temporary connection. Console port communication is used for administration and maintenance purposes from a central office (CO) location. Tasks conducted over a console port include: Creating the initial connection to the module Accessing and using all functionality available via the ACLI Performing in-lab system maintenance (services described below) Alarm Port5 Closes a circuit when a specific alarm level becomes active. The module features an alarm control signal interface that can be used in a CO location to indicate when internal alarms are generated. The appliances use alarm levels that correspond to three levels of service-disrupting incidents. USB Ports USB ports are disabled. Network Management Used for EMS control, CDR accounting, CLI management, and other Ports management functions Signaling and Media Provide network connectivity for signaling and media traffic. Interfaces Table 7 ­ Acme Packet 4500 Interface Descriptions The modules provide a number of physical and logical interfaces to the device, and the physical interfaces provided by the module are mapped to four FIPS 140-2 defined logical interfaces: data input, data output, control input, and status output. The logical interfaces and their mapping are described in the following table: FIPS 140-2 Logical Module Physical Interface Information Input/Output Interface Data Input Ethernet Ports (RJ-45), Console Ciphertext (SSH, and TLS packets) Ports (RJ-45), Data Output Ethernet Ports (RJ-45), Console Ciphertext (SSH, and TLS packets) Ports (RJ-45), 4 LED's do not provide FIPS Status indicators. FIPS status indicators are only in the form of logical indicators 5 Alarm port does not provide FIPS status indicators. Document Version 3.0 © Oracle Communications Page 11 of 35 FIPS 140-2 Logical Module Physical Interface Information Input/Output Interface Control Input Console Ports (RJ-45), Network Plaintext control input via console Management Ports (RJ-45), port (configuration commands, On/Off Switch operator passwords), ciphertext control input via network management (EMS control, CDR accounting, CLI management. Status Output Network Management Ports (RJ- Plaintext status output. 45), Console Ports (RJ-45), LCD Screen (4500), LEDs Power Power Plug, N/A On/Off Switch Table 8 ­ Logical Interface / Physical Interface Mapping 2.6 Roles, Services, and Authentication 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 table below provides a mapping of default roles in the module to the roles defined by FIPS 140-2: Operator Role Summary of Services User View configuration versions and a large amount if statistical data for the system's performance Handle certificate information for TLS and SSH functions Test pattern rules, local policies, and session translations Display system alarms. Set the display dimensions for the terminal Connect to module for data transmission Crypto-Officer Allowed access to all system commands and configuration privileges Unauthenticated Show Status Initiate self-tests Table 9 ­ Role Mapping Document Version 3.0 © Oracle Communications Page 12 of 35 2.6.1 Operator Services and Descriptions The services available to the User and Crypto Officer roles in the module are as follows: Service and Service Input Service Output Key/CSP Access Roles Description Configure FIPS License, None HMAC-SHA-256 key Crypto Image integrity Officer Initializes the module (HMAC) value for FIPS mode of operation Firmware Update Signed firmware None Public Key 1 Crypto image Officer Updates the firmware Decrypt Key Byte stream TLS Session Keys User Encrypted byte (TRIPLE-DES) Decrypts a block of stream TLS Session Keys data Using AES or (AES128) TRIPLE-DES in FIPS TLS Session Keys Mode (AES256) TLS Session Keys Decrypts a block of (DES,ARC4 in Non- data using DES or ARC4 FIPS Mode) in Non-FIPS mode SSH Session Key (TRIPLE-DES) SSH Session Key (AES128) SSH Session Key (AES256) SSH Session Keys (DES, ARC4 in Non- FIPS Mode) SRTP Session Key (AES-128) SNMP Privacy Key (AES-128) Private Key 2 Document Version 3.0 © Oracle Communications Page 13 of 35 Service and Service Input Service Output Key/CSP Access Roles Description Encrypt Key Encrypted byte TLS Session Keys User Byte stream stream (TRIPLE-DES) Encrypts a block of data TLS Session Keys Using AES or TRIPLE- (AES128) DES in FIPS Mode TLS Session Keys (AES256) Encrypts a block of data TLS Session Keys using DES or ARC4 in (DES, ARC4 in Non- Non-FIPS mode FIPS Mode) SSH Session Key (TRIPLE-DES) SSH Session Key (AES128) SSH Session Key (AES256) SSH Session Keys (DES, ARC4 in Non- FIPS mode) SRTP Session Key (AES-128) SNMP Privacy Key (AES-128) Public Key 2 Document Version 3.0 © Oracle Communications Page 14 of 35 Service and Service Input Service Output Key/CSP Access Roles Description Generate Keys Key Size AES-Keys or TLS Certificates User TRIPLE-DES Keys in (RSA, Diffie- Generates AES or FIPS mode Hellman) TRIPLE-DES keys for TLS Session Keys encrypt/decrypt DES keys and ARC4 (TRIPLE-DES) operations in FIPS Keys in Non-FIPS TLS Session Keys mode mode (AES128) TLS Session Keys Generates Diffie- (AES256) Hellman and RSA keys TLS Session Keys for key transport/key (DES, ARC4 in non- establishment. FIPS mode) SSH Certificates (Diffie-Hellman) SSH Session Key (TRIPLE-DES) SSH Session Key (AES128) SSH Session Key (AES256) SSH Session Keys (DES, ARC4 in Non- FIPS mode) SRTP Master Key (AES-128) Public Key 2 Verify RSA Signed firmware Verification Public Key 1 User success/failure Verifies the signature of a RSA-signed block Used as part of the TLS Nonce transported as Verification Public Key 2 protocol negotiation part of TLS or SSH success/failure Hash_Drbg seed NDRNG generated entropy_input entropy_input User random bits. Public Key 2 Generate a entropy_input for Hash_Drbg Hash_Drbg Working state Random number Hash_DRBG V User C and V Hash_DRBG Public Generate random Key 2 number. Document Version 3.0 © Oracle Communications Page 15 of 35 Service and Service Input Service Output Key/CSP Access Roles Description HMAC Key, data block HMAC value User HMAC 160-bit key Hash-SHA hash based 1 Message HMAC 160-bit key Authentication Code in 2 (TLS/SSH/SRTP) FIPS mode HMAC 256-bit key Public Key 2 HMAC-MD5 Hash HMAC-MD5 Key based Message (non-FIPS mode) Authentication Code in Non-FIPS mode Zeroize CSPs6 Key, Key pair, Invalidated CSP All CSPs Crypto entropy_input, Officer Clears CSPs from password memory Table 10 ­ Operator Services and Descriptions The module provides for the following unauthenticated services, which do not require authentication as they are not security relevant functions. These services do not affect the security of the module; these services do not create, disclose, or substitute cryptographic keys or CSPs, nor do they utilize any Approved security functions. Service and Service Input Service Output Key/CSP Access Roles Description Show Status None Module status None Unauthenticated enabled/disabled Shows status of the module Initiate self-tests None Console display of None Unauthenticated success/failure. Restarting the module Log entry of provides a way to run success/failure. the self-tests on- demand Table 11 ­ Unauthenticated Operator Services and Descriptions 6 During zeroization the Crypto-Officer must remain in possession of the module until it has rebooted in order to verify that successfully zeroization has completed. Document Version 3.0 © Oracle Communications Page 16 of 35 2.6.2 Operator Authentication 2.6.2.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 SNMP over the Network Management Ports. Other than status functions available by viewing the LCD panel, the services described in Table 10 ­ Operator Services and Descriptions are available only to authenticated operators. Passwords must be a minimum of 8 characters (see Guidance and Secure Operation section of this document). 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/948, which is less than 1/1,000,000. 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/948, which is less than 1/100,000. The module will lock an account after 3 failed authentication attempts; thus, the maximum number of attempts in one minute is 3. Therefore, the probability of a success with multiple consecutive attempts in a one-minute period is 3/948 which is less than 1/100,000. The module will permit an operator to change roles provided the operator knows both the User password and the Crypto Officer password. 2.6.2.2 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 keys. A 2048-bit RSA key has at least 112-bits of equivalent strength. The probability of a successful random attempt is 1/2112, 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 3/2112, which is less than 1/100,000. 2.7 Physical Security The module is a multiple-chip standalone module and conforms to Level 2 requirements for physical security. For details on tamper evidence, please see Section 3.1.2 ­ Placement of Tamper Evidence Labels. 2.8 Operational Environment The module operates in a limited operational model and does not implement a General Purpose Operating System. Document Version 3.0 © Oracle Communications Page 17 of 35 The module meets Federal Communications Commission (FCC) FCC Electromagnetic Interference (EMI) and Electromagnetic Compatibility (EMC) requirements for business use as defined by 47 Code of Federal Regulations, Part15, Subpart B. Document Version 3.0 © Oracle Communications Page 18 of 35 2.9 Cryptographic Key Management The table below provides a complete list of Critical Security Parameters used within the module: Key/CSP Name Description / Generation Storage Establishment / Export Destruction Privileges Use TLS Session TRIPLE-DES CBC Internal Storage: Volatile RAM in Agreement: RSA key Resetting / rebooting the Crypto Officer Keys (TRIPLE- 168-bit, AES- generation by plaintext transport module or power cycling DES, AES-128, 128 bit CBC, FIPS-approved RWD AES-256) AES-256 bit CBC Hash_DRBG Type: Ephemeral Entry: NA in firmware For encryption Association: The system is the Output: None / decryption of one and only owner. TLS session Relationship is maintained by traffic the operating system via protected memory for the Source: respective session. Broadcom SSH Session TRIPLE-DES CBC Internal Storage: Volatile RAM in Agreement: Diffie- Resetting / rebooting the Crypto Officer Keys (TRIPLE- 168-bit, AES- generation by plaintext Hellman module or power cycling DES, AES-128, 128 bit CBC, FIPS-approved RWD AES-256) AES-256 bit CBC Hash_DRBG Type: Ephemeral Entry: NA in firmware For encryption Association: The system is the Output: None / decryption of one and only owner. SSH session Relationship is maintained by traffic the operating system via protected memory for the Source: respective session. Broadcom Document Version 3.0 © Oracle Communications Page 19 of 35 Key/CSP Name Description / Generation Storage Establishment / Export Destruction Privileges Use SRTP Master For derivation Internal Storage: Volatile RAM in Agreement: Diffie- Resetting / rebooting the Crypto Officer Key (AES-128) of the SRTP generation by plaintext Hellman module or power cycling Session Key FIPS-approved RWD Hash_DRBG Type: Ephemeral Entry: NA in firmware Association: The system is the Output: encrypted one and only owner. Relationship is maintained by the operating system via protected memory for the respective session. SRTP Session For encryption NIST SP 800- Storage: Volatile RAM in Agreement: NIST SP Resetting / rebooting the Crypto Officer Key (AES-128) / decryption of 135 KDF plaintext 800-135 KDF module or power cycling SRTP session RWD traffic Type: Ephemeral Entry: NA Association: The system is the Output: None one and only owner. Relationship is maintained by the operating system via protected memory for the respective session. Document Version 3.0 © Oracle Communications Page 20 of 35 Key/CSP Name Description / Generation Storage Establishment / Export Destruction Privileges Use SNMP Privacy For encryption NIST SP 800- Storage: Volatile RAM in Agreement: NIST SP Resetting / rebooting the Crypto Officer Key (AES-128) / encryption of 135 KDF plaintext 800-135 KDF module or power cycling SNMP session RWD traffic Type: Ephemeral Entry: NA Association: The system is the Output: None one and only owner. Relationship is maintained by the operating system via protected memory for the respective session. Diffie-Hellman y=g^x mod p Internal Storage: Volatile RAM in Agreement: NA Resetting / rebooting the Crypto Officer Public Key component; generation by plaintext module or power cycling Generator g is 2 FIPS-approved Entry: NA RWD and p is 2048 Hash_DRBG Type: Ephemeral (group-14) in firmware Output: None Association: The system is the Source: Host one and only owner. Processor Relationship is maintained by the operating system via protected memory for the respective session. Document Version 3.0 © Oracle Communications Page 21 of 35 Key/CSP Name Description / Generation Storage Establishment / Export Destruction Privileges Use Diffie-Hellman x component of Internal Storage: Volatile RAM in Agreement: NA Resetting / rebooting the Crypto Officer Private Key DH; x is 2048 generation by plaintext module or power cycling (group-14) FIPS-approved Entry: NA RWD Hash_DRBG Type: Ephemeral Source: Host in firmware Output: None Processor Association: The system is the one and only owner. Relationship is maintained by the operating system via protected memory for the respective session. HMAC 160-bit 160-bit HMAC- Internal Storage: Flash RAM in plaintext Agreement: NA Re-formatting flash Crypto Officer key 1 SHA-1 for generation by memory message FIPS-approved Type: Static Entry: NA RWD verification Hash_DRBG in firmware Association: The system is the Output: None Source: one and only owner. Broadcom Relationship is maintained by the operating system via protected memory for the respective session. HMAC 160-bit 160-bit HMAC- Internal Storage: Flash RAM in plaintext Agreement: NA Re-formatting flash Crypto Officer key 2 SHA-1 for generation by memory message FIPS-approved Type: Static Entry: NA RWD authentication Hash_DRBG and verification in firmware Association: The system is the Output: None in SSH/TLS, one and only owner. SNMP and SRTP Relationship is maintained by the operating system via Source: Host protected memory for the Processor respective session. Document Version 3.0 © Oracle Communications Page 22 of 35 Key/CSP Name Description / Generation Storage Establishment / Export Destruction Privileges Use Operator Alphanumeric Not generated Storage: Non Volatile RAM in Agreement: NA Issue command Crypto Officer passwords passwords by the plaintext secure_pwd_reset() externally module; Entry: Manual entry via RWD generated by a defined by the Type: Static console or SSH User human user for human user of management session authentication the module Association: controlled by the RWD to the module. operating environment Output: Not Output Source: Host Processor Premaster RSA-Encrypted Internal Storage: Volatile RAM in Agreement: NA Resetting / rebooting the Crypto Officer Secret (48 Premaster generation by plaintext module or power cycling None Bytes) Secret Message FIPS-approved Entry: Input during TLS User Hash_DRBG Type: Ephemeral negotiation Source: Host None in firmware Processor Association: The system is the Output: Output to peer one and only owner. encrypted by Public Key Relationship is maintained by the operating system via protected memory. Master Secret Used for Internal Storage: Volatile RAM in Agreement: NA Resetting / rebooting the Crypto Officer (48 Bytes) computing the generation by plaintext module or power cycling None Session Key FIPS-approved Entry: NA User Hash_DRBG Type: Ephemeral Source: Host Output: NA None in firmware Processor Association: The system is the one and only owner. Relationship is maintained by the operating system via protected memory. Document Version 3.0 © Oracle Communications Page 23 of 35 Key/CSP Name Description / Generation Storage Establishment / Export Destruction Privileges Use Hash_DRBG V 440 bits long Generated as Storage: Volatile RAM in Agreement: NA Resetting / rebooting the Crypto Officer value V used per section plaintext module or power cycling None for generating 10.1.1.2 of SP Entry: NA Hash_DRBG 800-90 Type: Ephemeral User Output: NA None Source: Host Association: The system is the Processor one and only owner. Relationship is maintained by the operating system via protected memory. Hash_DRBG C 440 bits long Generated as Storage: Volatile RAM in Agreement: NA Resetting / rebooting the Crypto Officer constant C used per section plaintext module or power cycling None for generating 10.1.1.2 of SP Entry: NA Hash_DRBG 800-90 Type: Ephemeral User Output: NA None Source: Host Association: The operating Processor environment is the one and only owner. Relationship is maintained by the operating environment via protected memory. Document Version 3.0 © Oracle Communications Page 24 of 35 Key/CSP Name Description / Generation Storage Establishment / Export Destruction Privileges Use Hash_DRBG Input string for Generated as Storage: Volatile RAM in Agreement: NA Resetting / rebooting the Crypto Officer Entropy Input DRBG per section plaintext module or power cycling None String 10.1.1.2 of SP Entry: NA Source: Host 800-90 Type: Ephemeral User Processor Output: NA None Association: The operating environment is the one and only owner. Relationship is maintained by the operating environment via protected memory. Hash_DRBG Seed value for Generated as Storage: Volatile RAM in Agreement: NA Resetting / rebooting the Crypto Officer Seed Value DRBG per section plaintext module or power cycling None 10.1.1.2 of SP Entry: NA Source: Host 800-90 Type: Ephemeral User Processor Output: NA None Association: The operating environment is the one and only owner. Relationship is maintained by the operating environment via protected memory. Public Key 1 RSA Public Entered Storage: Flash in plaintext Agreement: NA Not destroyed as it is a Crypto Officer 2048-bit for encrypted public key RWD firmware load Type: Static Entry: NA verification User operations. Association: The system is the Output: NA R one and only owner. Source: Host Relationship is maintained by Processor the operating environment. Document Version 3.0 © Oracle Communications Page 25 of 35 Key/CSP Name Description / Generation Storage Establishment / Export Destruction Privileges Use Public Key 2 RSA Public Internal Storage: Flash in plaintext Agreement: NA Not destroyed as it is a Crypto Officer 2048-bit for generation by public key RWD key FIPS-approved Type: Static Entry: NA establishment Hash_DRBG User for TLS/SSH Association: The system is the Output: NA R in firmware sessions. one and only owner. Relationship is maintained by Source: Host the operating system via Processor certificates. Private Key 2 RSA Private Internal Storage: Flash in plaintext Agreement: NA Re-formatting flash Crypto Officer 2048-bit for generation by memory RWD key FIPS-approved Type: Static Entry: NA establishment 7 Hash_DRBG User for TLS/SSH Association: The system is the Output: NA R in firmware sessions one and only owner. Relationship is maintained by Source: Host the operating system via Processor protected memory. R = Read W = Write D = Delete Table 12 ­ Key/CSP Management Details Public keys are protected from unauthorized modification and substitution. The module ensures only authenticated operators have access to keys and functions that can generate keys. Unauthenticated operators do not have write access to modify, change, or delete a public key. For the session certificate, the module generates a PKCS10 certificate request (PKCS 10), and a standard Certificate Authority (CA) generates the certificate. 7 Key establishment methodology provides 112-bits of encryption strength Document Version 3.0 © Oracle Communications Page 26 of 35 2.10 Self-Tests The module includes an array of self-tests that are run during startup and periodically during operations to prevent any secure data from being released and to ensure all components are functioning correctly. In the event of any self-test failure, the module will output an error dialog and will shut down. When the module is in an error state, no keys or CSPs will be output and the module will not perform cryptographic functions. The module does not support a bypass function. The following sections discuss the module's self-tests in more detail. 2.10.1 Power-On Self-Tests Power-on self-tests are run upon every initialization of the module and if any of the tests fail, the module will not initialize. The module will enter an error state and no services can be accessed by the users. The module implements the following power-on self-tests: Implementation Self Tests Run Hifn 8450 TRIPLE-DES encrypt known answer test TRIPLE-DES decrypt known answer test AES encrypt known answer test AES decrypt known answer test HMAC-SHA-1 known answer test8 BCM5862 TRIPLE-DES encrypt known answer test TRIPLE-DES decrypt known answer test AES encrypt known answer test AES decrypt known answer test SHA-1 known answer test HMAC-SHA-1 known answer test Firmware SHA-1 and SHA-256 known answer test HMAC-SHA-1 and HMAC-SHA-256 known answer test Hash_DRBG known answer test Firmware integrity check using HMAC-SHA-256 RSA (verify) known answer test KDF KAT Table 13 - Power-On Self-Tests The module performs all power-on self-tests automatically when the module is initialized. All power-on self-tests must be passed before a User/Crypto Officer can perform services. The Power-on self-tests can be run on demand by rebooting the module in FIPS approved Mode of Operation. 8 Note: According to the CMVP FAQ p.57 "If a KAT is implemented for the HMAC-SHA-1, a KAT is not needed for the underlying SHA-1." Document Version 3.0 © Oracle Communications Page 27 of 35 2.10.1.1 Status Output An operator can discern that all power-on self-tests have passed via normal operation of the module and the following log message. FIPS: KAT self test completed successfully. FIPS: System is currently operating in FIPS 140-2 compatible mode. In the event a POST fails, the module will output the following log message: FIPS: ERROR - System is not in FIPS 140-2 compatible mode FIPS: ERROR - failed. For example: FIPS: ERROR - RSA pair wise consistency test failed. Note that data output will be inhibited while the module is in an error state (i.e., when a POST fails). No keys or CSPs will be output when the module is in an error state. 2.10.2 Conditional Self-Tests Conditional self-tests are test that run continuously during operation of the module. If any of these tests fail, the module will enter an error state. The module can be re-initialized to clear the error and resume FIPS mode of operation. No services can be accessed by the operators. The module performs the following conditional self-tests: Implementation Self Tests Run BCM5862 Continuous NDRNG test Firmware DRBG Health Test as specified in SP 800-90 Section 11.3 Continuous test on output of seed mechanism RSA pairwise consistency test for encrypt/decrypt Firmware load test using RSA 2048 Table 14 ­ Conditional Self-Tests 2.10.2.1 Status Output In the event a conditional self-test fails, the module will output the following log message: FIPS: ERROR - System is not in FIPS 140-2 compatible mode FIPS: ERROR - failed. For example: FIPS: ERROR - Continuous RNG test failed. Document Version 3.0 © Oracle Communications Page 28 of 35 Note that data output will be inhibited while the module is in this error state. The module will self- correct this use case as follows: Test Remediation Pairwise consistency test for RSA implementations Generate a new RSA key pair and rerun test Continuous test run on output of FIPS-approved Generate a new value and rerun test Hash_DRBG in firmware Continuous test on output of FIPS-approved Generate a new value and rerun test Hash_DRBG in firmware seed mechanism Table 15 ­ Conditional Self Tests and Module Remediation No keys or CSPs will be output when the module is in an error state. 2.10.3 Critical Functions Test The following are considered critical functions tests: Adding additional entropy to NDRNG; SP 800-90A DRBG critical function tests; KDF KAT performed at power-up. 2.11 Mitigation of Other Attacks The module does not mitigate attacks. Document Version 3.0 © Oracle Communications Page 29 of 35 3 Guidance and Secure Operation This section describes how to configure the module for FIPS-approved mode of operation. Operating the module without maintaining the following settings will remove the module from the FIPS-approved mode of operation. 3.1 Crypto Officer Guidance 3.1.1 Enabling FIPS Mode and General Guidance FIPS Mode is enabled by a license installed by Oracle, which will open/lock down features where appropriate. Additionally, the Crypto Officer must configure and enforce the following initialization procedures in order to operate in FIPS approved mode of operation9: Verify that the firmware version of the module is Version ECx 6.4.1 or ECx 6.4.1 M1. Ensure all media traffic is encapsulated in a TLS, SSH, or SRTP tunnel as appropriate. Ensure that SNMP V3 is configured with AES-128 (Version ECx 6.4.1 M1 only). Ensure all management traffic is encapsulated within a trusted session (i.e., Telnet or FTP should not be used in FIPS mode of operation). Ensure that the tamper evidence labels are applied by Oracle as specified in Section 3.1.2 ­ Placement of Tamper Evidence Labels. The tamper evident labels shall be installed for the module to operate in a FIPS Approved mode of operation. Inspect the tamper evident labels periodically to verify they are intact and the serial numbers on the applied tamper evident labels match the records in the security log. All operator passwords must be a minimum of 8 characters in length. Ensure use of FIPS-approved algorithms for TLS v1.0: TLS_RSA_WITH_Triple-DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_Triple-DES_EDE_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA 9 The licensing may ensure most of these are met. The Crypto Officer should verify all details prior to operation in FIPS mode. Document Version 3.0 © Oracle Communications Page 30 of 35 TLS_DHE_RSA_WITH_AES_256_CBC_SHA Ensure use of FIPS-approved cipher suite algorithms for SSH V2. Ensure RSA keys are at least 2048-bit keys. No 512-bit or 1024-bit keys can be used in FIPS mode of operation. Do not disclose passwords and store passwords in a safe location and according to his/her organization's systems security policies for password storage. 3.1.2 Placement of Tamper Evidence Labels To meet Physical Security Requirements for Level 2, the module enclosure must be protected with tamper evidence labels. The tamper evident labels shall be installed for the module to operate in a FIPS Approved mode of operation. Oracle Communications applies the labels at time of manufacture; the Crypto Officer is responsible for ensuring the labels are applied as shown below. Once applied, the Crypto Officer shall not remove or replace the labels unless the module has shown signs of tampering. In the event of tampering or wear and tear on the labels, the Crypto Officer shall return the module to Oracle Communications, where it will be reimaged and returned with a new set of labels. The Crypto Officer is responsible for Verifying the five labels are attached to the appliance as shown in the diagrams below, Maintaining the direct control and observation of any changes to the module such as reconfigurations where the tamper evident seals or security appliances are removed or installed to ensure the security of the module is maintained during such changes and the module is returned to a FIPS Approved state. Figure 3 ­ Acme Packet 3820 Tamper Evidence Label Placement / Front Document Version 3.0 © Oracle Communications Page 31 of 35 Figure 4 ­ Acme Packet 3820 Tamper Evidence Label Placement / Rear Figure 5 ­ Acme Packet 3820 Tamper Evidence Label Placement Top/Front Document Version 3.0 © Oracle Communications Page 32 of 35 Figure 6 ­ Acme Packet 3820 Tamper Evidence Label Placement Bottom/Rear Figure 7 ­ Acme Packet 4500 Tamper Evidence Label Placement Rear Figure 8 ­ Acme Packet 4500 Tamper Evidence Label Placement Front Document Version 3.0 © Oracle Communications Page 33 of 35 Figure 9 ­ Acme Packet 4500 Tamper Evidence Label Placement Top/Front Document Version 3.0 © Oracle Communications Page 34 of 35 Figure 10 ­ Acme Packet 4500 Tamper Evidence Label Placement Rear Bottom Note that Oracle Communications does offer the purchase of additional labels. If labels need to be replaced, please contact Oracle Communications to return the module for reimaging, and Oracle Communications will reimage the module and provide additional label (internal part number LBL-0140- 60). 3.2 User Guidance 3.2.1 General Guidance The User must not disclose passwords and must store passwords in a safe location and according to his/her organization's systems security policies for password storage. End of Document Document Version 3.0 © Oracle Communications Page 35 of 35