FIPS 140-2 Non-Proprietary Security Policy Acme Packet 4500 Document Version 2.5 December 5, 2014 Prepared For: Prepared By: Oracle Corporation SafeLogic Inc. 500 Oracle Parkway 530 Lytton Ave, Suite 200 Redwood Shores, CA 94065 Palo Alto, CA 94301 www.oracle.com www.safelogic.com Copyright © 2014, 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 2.5 © Oracle Communications Page 1 of 40 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 4500 ......................................................................................................... 6 2.1 Product Overview................................................................................................................................................ 6 2.2 Validation Level Detail ........................................................................................................................................ 6 2.3 Algorithm Implementations ................................................................................................................................ 7 2.3.1 FIPS-Approved Algorithms........................................................................................................................... 7 2.3.2 Non-Approved Algorithms .......................................................................................................................... 8 2.4 Cryptographic Module Specification ................................................................................................................... 8 2.5 Module Interfaces............................................................................................................................................... 9 2.6 Roles, Services, and Authentication .................................................................................................................. 10 2.6.1 Operator Services and Descriptions .......................................................................................................... 11 2.6.2 Operator Authentication ........................................................................................................................... 18 2.7 Physical Security ............................................................................................................................................... 18 2.8 Operational Environment ................................................................................................................................. 18 2.9 Cryptographic Key Management ...................................................................................................................... 20 2.10 Self-Tests......................................................................................................................................................... 31 2.10.1 Power-On Self-Tests ................................................................................................................................ 33 2.10.2 Conditional Self-Tests .............................................................................................................................. 34 2.11 Mitigation of Other Attacks ............................................................................................................................ 35 3 Guidance and Secure Operation........................................................................................................................ 36 3.1 Crypto Officer Guidance .................................................................................................................................... 36 3.1.1 Enabling FIPS Mode and General Guidance .............................................................................................. 36 3.1.2 Placement of Tamper Evidence Labels...................................................................................................... 37 3.2 User Guidance................................................................................................................................................... 40 3.2.1 General Guidance...................................................................................................................................... 40 Document Version 2.5 © Oracle Communications Page 2 of 40 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 ......................................................... 7 Table 5 – Algorithm Certificates for FIPS-Approved Algorithms for Firmware ................................................................ 8 Table 6 – Acme Packet 4500 Interface Descriptions ...................................................................................................... 10 Table 7 – Logical Interface / Physical Interface Mapping............................................................................................... 10 Table 8 – Role Mapping .................................................................................................................................................. 11 Table 9 – Operator Services and Descriptions ............................................................................................................... 17 Table 10 – Unauthenticated Operator Services and Descriptions ................................................................................. 17 Table 11 – Key/CSP Management Details ...................................................................................................................... 32 Table 12 - Power-On Self-Tests ...................................................................................................................................... 33 Table 13 – Conditional Self-Tests ................................................................................................................................... 34 Table 14 – Conditional Self Tests and Module Remediation.......................................................................................... 35 List of Figures Figure 1 – Physical Boundary for Acme Packet 4500 ....................................................................................................... 9 Figure 2 – Tamper Evidence Label Placement Rear........................................................................................................ 38 Figure 3 – Tamper Evidence Label Placement Front ...................................................................................................... 38 Figure 4 – Tamper Evidence Label Placement Top/Front............................................................................................... 39 Figure 5 – Tamper Evidence Label Placement Rear Bottom........................................................................................... 40 Document Version 2.5 © Oracle Communications Page 3 of 40 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 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 mode of operation. The Oracle Communications Acme Packet 4500 may also be referred to as the “module” in this document. 1.3 External Resources The Oracle Communications website (http://www.oracle.com) contains information on the full line of products from Oracle Communications, including a detailed overview of the 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 2.5 © Oracle Communications Page 4 of 40 1.5 Acronyms The following table defines acronyms found in this document: Acronym Term AES Advanced Encryption Standard CBC Cipher Block Chaining CSEC Communications Security Establishment of Canada CSP Critical Security Parameter DTR Derived Testing Requirement Federal Information Processing FIPS Standard GPC General Purpose Computer GPOS General Purpose Operating System HMAC Hashed Message Authentication Code KAT Known Answer Test NIST National Institute of Standards and Technology RSA Rivest Shamir Adelman SHA Secure Hashing Algorithm Table 1 – Acronyms and Terms Document Version 2.5 © Oracle Communications Page 5 of 40 2 Oracle Communications 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. Oracle Communications’ SBC is configured on Acme Packet OS, which operates on both the Acme Packet 4500 and 3820 platforms. The Acme Packet 4500 is a carrier-class platform supporting up to 32,000 simultaneous signaled sessions, delivering unmatched capabilities and performance in a 1U form factor. It offers extremely rich functionality, architectural flexibility and 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. In government, enterprise and contact center environments, the Acme Packet 4500 secure SIP/H.323 trunking borders to service provider 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. 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 Document Version 2.5 © Oracle Communications Page 6 of 40 FIPS 140-2 Section Title Validation Level 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, bulk IPSec processing (HMAC-SHA1, 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: random number generation, SHA-1, SHA-256, RSA, HMAC-SHA1, HMAC-SHA256, 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-SHA1 FIPS 198-1 519 Message verification Hashing SHA-1 FIPS 180-4 912 Message digest Three key Triple-DES Data encryption / Symmetric Key NIST SP 800-67 745 (CBC mode) decryption AES 128 and Data encryption / FIPS 197 928 256(CBC, CTR decryption modes) Table 3 – Algorithm Certificates for FIPS-Approved Algorithms in the Hifn 8450 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 NIST SP 800-67 1019 Data encryption / (CBC mode) decryption AES 128 and FIPS 197 1555 Data encryption / 256(CBC, CTR decryption modes) Table 4 – Algorithm Certificates for FIPS-Approved Algorithms for the BCM5862 Document Version 2.5 © Oracle Communications Page 7 of 40 CAVP Certificate Algorithm Type Algorithm Standard for Intel Core Duo Use T2500 Hashing SHA-1 FIPS 180-4 1373 Message digest SHA-256 Keyed Hash HMAC-SHA1 FIPS 198-1 900 Message verification HMAC-SHA256 and module integrity (via HMAC-SHA256) Asymmetric RSA FIPS 186-2 753 Verify operations Key Hash_DRBG SP800-90A 68 Random Number Random Number (hash based) Generation Generation Table 5 – Algorithm Certificates for FIPS-Approved Algorithms for Firmware 2.3.2 Non-Approved Algorithms The module implements the following non-approved algorithms: • DES • ARC4 • HMAC-MD5 • RSA (allowed for use in FIPS mode of operation) o Used in FIPS mode for TLS sessions key establishment in and provides 112-bits of encryption strength • Diffie-Hellman o Used for key agreement in SSH and IPSEC sessions; key establishment methodology provides 112-bits of encryption strength (allowed for use in FIPS Mode of operation). Used for key agreement in SSH and IPSEC sessions; key establishment methodology o provides less than 112-bits of encryption strength (non-compliant). • Hardware-based random number generator o This RNG is used in FIPS mode only to generate entropy_input to the firmware-based FIPS-approved Hash_DRBG. Unless otherwise noted, Non-approved algorithms are not used in FIPS mode. 2.4 Cryptographic Module Specification The module is the Oracle Communications Acme Packet 4500 running firmware version C6.3 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 firmware is excluded from validation. Document Version 2.5 © Oracle Communications Page 8 of 40 The specific model included in the validation is as follows: • Acme Packet 4500 o Running network processor AMCC NP3750 @700 Mhz and host processor Intel Core Duo T2500 o Running Hifn 8450 and Broadcom 5862 for dedicated, hardware-based cryptographic processing The physical boundary is pictured in the image below: Figure 1 – Physical Boundary for Acme Packet 4500 2.5 Module Interfaces The table below describes the main interfaces on the Acme Packet 4500: Physical Interface Description / Use LCD Reports real-time status, alarms, and general system information LEDs 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) Document Version 2.5 © Oracle Communications Page 9 of 40 Physical Interface Description / Use Alarm Port 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 Provides access to external Flash based memory Network Management Used for EMS control, RADIUS accounting, CLI management, SNMP queries Ports and traps, and other management functions Signaling and Media Provide network connectivity for signaling and media traffic. Interfaces Table 6 – Acme Packet 4500 Interface Descriptions The module provides 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 Network Management Ports Ciphertext (IPSec, SSH, and TLS Signaling and Media Interfaces packets) Data Output Network Management Ports Ciphertext (IPSec, SSH, and TLS Signaling and Media Interfaces packets) Control Input Console Port Plaintext control input (configuration commands, operator passwords) Status Output Network Management Ports Plaintext status output. Console Ports Plaintext key output during LEDs manual key generation and configuration. Power Power Plug N/A On/Off Switch Table 7 – Logical Interface / Physical Interface Mapping 2.6 Roles, Services, and Authentication As required by FIPS 140-2 Level 2, there are two roles (a Crypto Officer role and User 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: Document Version 2.5 © Oracle Communications Page 10 of 40 Operator Role Summary of Services FIPS 140-2 Role User Crypto Officer • View configuration versions and a large amount if statistical data for the system’s performance • Handle certificate information for IPSec and TLS functions • Test pattern rules, local policies, and session translations • Display system alarms. • Set the display dimensions for the terminal Allowed access to all system commands and configuration Superuser Crypto Officer privileges Allowed access to all system commands and configuration LI Admin Crypto Officer privileges, including LI features (if available) Remote IT system Connect to module for data transmission User Unauthenticated user Allowed access to view status and perform self test Crypto Officer-2 Table 8 – Role Mapping 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 FIPS License, Crypto HMAC 256-bit key, Configure None IPSec Session Keys Image integrity Officer (TRIPLE-DES) Initializes the module (HMAC) value for FIPS mode of IPSec Session Keys Manual key value. operation, configure (AES128) manual keys IPSec Session Keys (AES256) HMAC 160-bit key 1 Document Version 2.5 © Oracle Communications Page 11 of 40 Service and Service Input Service Output Key/CSP Access Roles Description Decrypt Key Byte stream TLS Session Keys User Encrypted byte (TRIPLE-DES) TLS Session Keys Decrypts a block of stream (AES128) data Using AES or TLS Session Keys TRIPLE-DES in FIPS (AES256) Mode TLS Session Keys (DES, ARC4 in Decrypts a block of Non-FIPS Mode) data using DES or ARC4 IPSec Session in Non-FIPS mode Keys (TRIPLE- DES) IPSec Session Keys (AES128) IPSec Session Keys (AES256) SSH Session Key (TRIPLE-DES) SSH Session Key (AES128) SSH Session Key (AES256) SSH Session Keys (DES, ARC4 in Non-FIPS mode) Private Key 2 Document Version 2.5 © Oracle Communications Page 12 of 40 Service and Service Input Service Output Key/CSP Access Roles Description Encrypt Key Encrypted byte TLS Session Keys User Byte stream stream (TRIPLE-DES) TLS Session Keys Encrypts a block of data (AES128) Using AES or TRIPLE- TLS Session Keys DES in FIPS Mode (AES256) TLS Session Keys Encrypts a block of data (DES, ARC4 in using DES or ARC-4 in Non-FIPS Mode) Non-FIPS mode IPSec Session Keys (TRIPLE- DES) IPSec Session Keys (AES128) IPSec Session Keys (AES256) SSH Session Key (TRIPLE-DES) SSH Session Key (AES128) SSH Session Key (AES256) SSH Session Keys (DES, ARC4 in Non-FIPS mode) Public Key 2 Document Version 2.5 © Oracle Communications Page 13 of 40 Service and Service Input Service Output Key/CSP Access Roles Description Generate Keys Key Size AES-Key TLS Session Keys User TRIPLE-DES-Key in (TRIPLE-DES) TLS Session Keys Generates AES or FIPS Mode (AES128) TRIPLE-DES keys for TLS Session Keys encrypt/decrypt DES-Key (AES256) operations in FIPS ARC4 Key in Non- TLS Session Keys Mode FIPS mode (DES, ARC4 in non-FIPS mode) Generates DES or IPSec Session ARC4 keys for Keys (TRIPLE- encrypt/decrypt DES) operations in non-FIPS IPSec Session Mode Keys (AES128) IPSec Session Keys (AES256) SSH Session Key (TRIPLE-DES) SSH Session Key (AES128) SSH Session Key (AES256) SSH Session Keys (DES, ARC4 in Non-FIPS mode) Public Key 2 Document Version 2.5 © Oracle Communications Page 14 of 40 Key Establishment Key Size AES-Key User IPSec Session TRIPLE-DES-Key in Keys (TRIPLE- DH public key FIPS mode DES) for establishing AES IPSec Session or TRIPLE-DES Keys (AES128) DES key and ARC4 Key in Non-FIPS session keys in FIPS IPSec Session mode mode Keys (AES256) SSH Session Key DH public key (TRIPLE-DES) for establishing DES or SSH Session Key ARC4 session keys in (AES128) Non-FIPS mode SSH Session Key (AES256) SSH Session Keys (DES, ARC4 in Non-FIPS mode) Public Key 2 Document Version 2.5 © Oracle Communications Page 15 of 40 Key Establishment Key Size AES-Key User IPSec Session TRIPLE-DES-Key in Keys (TRIPLE- DH private key FIPS mode DES) for establishing AES IPSec Session or TRIPLE-DES Keys (AES128) DES key and ARC4 Key in Non-FIPS session keys in FIPS IPSec Session mode mode Keys (AES256) SSH Session Key DH private key (TRIPLE-DES) for establishing DES or SSH Session Key ARC4 session keys in (AES128) Non-FIPS mode SSH Session Key (AES256) SSH Session Keys (DES, ARC4 in Non-FIPS mode) Public Key 2 Data block to sign RSA Signed data Sign Private Key 1 User Private Key 2 RSA Private key block Public Key 2 Signs a block with RSA RSA Signed data Verification Verify Public Key 1 User Public Key 2 block success/failure Verifies the signature RSA Public key of a RSA-signed block HWRNG generated entropy_input Hash_Drbg seed entropy_input User random bits. Public Key 2 Generate a entropy_input for Hash_Drbg Working state Hash_DRBG V Hash_Drbg Random number User C and V Hash_DRBG Generate random Public Key 2 number. Document Version 2.5 © Oracle Communications Page 16 of 40 Service and Service Input Service Output Key/CSP Access Roles Description HMAC Key, data block HMAC value HMAC 160-bit User key 1 HMAC-SHA Hash-based HMAC 160-bit Message key 2 Authentication Code in HMAC 160-bit FIPS mode key 3 HMAC 256-bit key HMAC-MD5 Hash- Public Key 2 based Message Authentication Code in HMAC-MD5 Key non-FIPS mode (non-FIPS mode) Zeroize CSPs Key, Key pair, Invalidated CSP All CSPs Crypto entropy_input, Officer password Clears CSPs from memory Table 9 – 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 Module status Crypto Show Status None None enabled/disabled Officer-2 Shows status of the module Console display of None Crypto Initiate self-tests None success/failure. Officer-2 Restarting the module Log entry of success/failure. provides a way to run the self-tests on- demand Table 10 – Unauthenticated Operator Services and Descriptions Document Version 2.5 © Oracle Communications Page 17 of 40 2.6.2 Operator Authentication 2.6.2.1 Crypto-Officer: Password-Based Authentication In FIPS 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 LEDs and the LCD panel, the services described in Table 9 – Operator Services and Descriptions are available only to authenticated operators. Passwords must be a minimum of 6 characters (see Guidance and Secure Operation section of this document). The password can consist of alphanumeric values, {a-zA-Z0-9], yielding 62 choices per character. The probability of a successful random attempt is 1/626, 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/626, 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/626 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, SSH, and IPSec 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 60/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 2.5 © Oracle Communications Page 18 of 40 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 2.5 © Oracle Communications Page 19 of 40 2.9 Cryptographic Key Management The table below provides a complete list of Critical Security Parameters used within the module: Key/CSP Name Description / Use Generation Storage Establishment / Export Destruction Privileges TLS Session Internal Storage: Volatile RAM in Agreement: NA TRIPLE-DES CBC Resetting / rebooting the Crypto Officer 168-bit key plaintext module or power cycling Keys (TRIPLE- generation by Entry: NA DES) FIPS-approved RWD Hash_DRBG Type: Ephemeral For encryption / Output: None decryption of TLS in firmware Association: The system is the session traffic one and only owner. Source: Relationship is maintained by Broadcom the operating system via protected memory for the respective session. Storage: Volatile RAM in Agreement: NA TLS Session AES CBC 128-bit Internal Resetting / rebooting the Crypto Officer Keys (AES128) key generation by plaintext module or power cycling FIPS-approved Entry: NA RWD Hash_DRBG Type: Ephemeral For encryption / Output: None decryption of TLS in firmware Association: The system is the session traffic one and only owner. Source: Relationship is maintained by Broadcom the operating system via protected memory for the respective session. Document Version 2.5 © Oracle Communications Page 20 of 40 Key/CSP Name Description / Use Generation Storage Establishment / Export Destruction Privileges Storage: Volatile RAM in Agreement: NA TLS Session AES CBC 256-bit Internal Resetting / rebooting the Crypto Officer Keys (AES256) key generation by plaintext module or power cycling FIPS-approved Entry: NA RWD Hash_DRBG Type: Ephemeral Output: None For encryption / in firmware decryption of TLS Association: The system is the session traffic one and only owner. Relationship is maintained by Source: the operating system via Broadcom protected memory for the respective session. Storage: Non-Volatile RAM in IPSec Session TRIPLE-DES CBC Manually Manually entering a new Crypto Officer Agreement: NA Keys (TRIPLE- 168-bit key value and overwriting the entered plaintext DES) old value RWD Entry: Manual Source: HIFN Type: Static Output: None Association: The system is the one and only owner. Relationship is maintained by the operating system via protected memory for the respective session. Document Version 2.5 © Oracle Communications Page 21 of 40 Key/CSP Name Description / Use Generation Storage Establishment / Export Destruction Privileges Storage: Non-Volatile RAM in Agreement: NA IPSec Session AES CBC, CTR Manually Manually entering a new Crypto Officer Keys (AES128) 128-bit key entered plaintext value and overwriting the Entry: Manual old value RWD Type: Static Source: HIFN Output: None Association: The system is the one and only owner. Relationship is maintained by the operating system via protected memory for the respective session. Storage: Non-Volatile RAM in IPSec Session AES CBC, CTR Manually Manually entering a new Crypto Officer Agreement: NA Keys (AES256) 256-bit key entered plaintext value and overwriting the Entry: Manual old value RWD Source: HIFN Type: Static Output: None Association: The system is the one and only owner. Relationship is maintained by the operating system via protected memory for the respective session. Document Version 2.5 © Oracle Communications Page 22 of 40 Key/CSP Name Description / Use Generation Storage Establishment / Export Destruction Privileges Storage: Volatile RAM in Agreement: NA SSH Session TRIPLE-DES CBC Internal Resetting / rebooting the Crypto Officer Key (TRIPLE- 168-bit key generation by plaintext module or power cycling FIPS-approved Entry: NA DES) RWD Hash_DRBG Type: Ephemeral For encryption / Output: None decryption of SSH in firmware Association: The system is the session traffic one and only owner. Source: Relationship is maintained by Broadcom the operating system via protected memory for the respective session. Storage: Volatile RAM in SSH Session AES CBC 128-bit Internal Resetting / rebooting the Crypto Officer Agreement: NA Key (AES128) generation by plaintext module or power cycling FIPS-approved Entry: NA For encryption / RWD Hash_DRBG Type: Ephemeral decryption of SSH session traffic Output: None in firmware Association: The system is the Source: one and only owner. Broadcom Relationship is maintained by the operating system via protected memory for the respective session. Document Version 2.5 © Oracle Communications Page 23 of 40 Key/CSP Name Description / Use Generation Storage Establishment / Export Destruction Privileges Storage: Volatile RAM in Agreement: NA SSH Session AES CBC 256-bit Internal Resetting / rebooting the Crypto Officer Key (AES256) key generation by plaintext module or power cycling FIPS-approved Entry: NA RWD Hash_DRBG Type: Ephemeral Output: None For encryption / in firmware decryption of SSH Association: The system is the session traffic one and only owner. Relationship is maintained by Source: the operating system via Broadcom protected memory for the respective session. Storage: Volatile RAM in Diffie Hellman y=g^x mod p Internal Resetting / rebooting the Crypto Officer Agreement: NA Public Key component; generation by plaintext module or power cycling Generator g is 2 FIPS-approved Entry: NA RWD Hash_DRBG Type: y is ephemeral / p is and p is 1024 bits (group-2), 1536 Output: None static in firmware (group-5) and 2048 (group-14) Association: The system is the one and only owner. Source: Host Relationship is maintained by Processor the operating system via protected memory for the respective session. Document Version 2.5 © Oracle Communications Page 24 of 40 Key/CSP Name Description / Use Generation Storage Establishment / Export Destruction Privileges Storage: Volatile RAM in Agreement: NA Diffie Hellman x component of Internal Resetting / rebooting the Crypto Officer Private Key DH; x is 1024 bits generation by plaintext module or power cycling FIPS-approved Entry: NA (group-2), 1536 RWD Hash_DRBG Type: Ephemeral (group-5) and Output: None 2048 (group-14) in firmware 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. Storage: Flash RAM in HMAC 160-bit 160-bit HMAC- Manually Re-formatting flash Crypto Officer Agreement: NA key 1 SHA1 for entered plaintext memory message Entry: Manual RWD verification Type: Static Output: None Source: HIFN Association: The system is the one and only owner. Relationship is maintained by the operating system via protected memory for the respective session. Document Version 2.5 © Oracle Communications Page 25 of 40 Key/CSP Name Description / Use Generation Storage Establishment / Export Destruction Privileges Storage: Flash RAM in Agreement: NA HMAC 160-bit 160-bit HMAC- Internal Re-formatting flash Crypto Officer key 2 generation by plaintext memory SHA1 for FIPS-approved Entry: NA message RWD Hash_DRBG Type: Static verification Output: None in firmware Association: The system is the Source: Broadcom one and only owner. Relationship is maintained by the operating system via protected memory for the respective session. Storage: Flash RAM in HMAC 160-bit 160-bit HMAC- Internal Re-formatting flash Crypto Officer Agreement: NA key 3 SHA1 for generation by plaintext memory message FIPS-approved Entry: NA RWD Hash_DRBG verification Type: Static Output: None in firmware Source: Host Association: The system is the Processor one and only owner. Relationship is maintained by the operating system via protected memory for the respective session. Document Version 2.5 © Oracle Communications Page 26 of 40 Key/CSP Name Description / Use Generation Storage Establishment / Export Destruction Privileges Storage: RAM plaintext Agreement: NA HMAC 256-bit 80-bit HMAC- Hard coded Update firmware Crypto Officer key SHA256 for Type: Static Entry: NA integrity check RWD Association: The system is the Output: None Source: Host Processor one and only owner. Relationship is maintained by the operating system via protected memory for the respective session. Storage: Non-Volatile RAM in Agreement: NA Operator Alphanumeric Not generated Issue command Crypto Officer passwords by the passwords plaintext secure_pwd_reset() externally module; Entry: Manual entry via RWD generated by a defined by the console or SSH Type: Static User human user for human user of management session RWD authentication to the module Association: controlled by the the module. Output: In encrypted operating system form only if using Source: Host RADIUS authentication Processor Document Version 2.5 © Oracle Communications Page 27 of 40 Key/CSP Name Description / Use Generation Storage Establishment / Export Destruction Privileges Storage: Volatile RAM in Agreement: NA Premaster RSA-Encrypted Internal Resetting / rebooting the Crypto Officer Secret (48 Premaster Secret generation by plaintext module or power cycling None Bytes) Entry: Input during TLS Message FIPS-approved 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. Storage: Volatile RAM in Agreement: NA Master Secret Used for Internal Resetting / rebooting the Crypto Officer (48 Bytes) computing the generation by plaintext module or power cycling None Entry: NA Session Key FIPS-approved User Hash_DRBG Type: Ephemeral None Output: NA Source: Host in firmware Association: The system is the Processor one and only owner. Relationship is maintained by the operating system via protected memory. Document Version 2.5 © Oracle Communications Page 28 of 40 Key/CSP Name Description / Use Generation Storage Establishment / Export Destruction Privileges Hash_DRBG V Storage: Volatile RAM in Agreement: NA 440 bits long Generated as Resetting / rebooting the Crypto Officer value V used for per section plaintext module or power cycling None Entry: NA generating 10.1.1.2 of SP User 800-90 Type: Ephemeral Hash_DRBG None Output: NA Association: The system is the Source: Host Processor one and only owner. Relationship is maintained by the operating system via protected memory. Hash_DRBG C Storage: Volatile RAM in Agreement: NA 440 bits long Generated as Resetting / rebooting the Crypto Officer constant C used per section plaintext module or power cycling None Entry: NA for generating 10.1.1.2 of SP User Type: Ephemeral Hash_DRBG 800-90 Output: NA None Association: The operating Source: Host Processor environment is the one and only owner. Relationship is maintained by the operating environment via protected memory. Document Version 2.5 © Oracle Communications Page 29 of 40 Key/CSP Name Description / Use Generation Storage Establishment / Export Destruction Privileges Hash_DRBG Storage: Volatile RAM in Agreement: NA Input string for Generated as Resetting / rebooting the Crypto Officer DRBG per section plaintext module or power cycling None Entropy Input Entry: NA 10.1.1.2 of SP String User Type: Ephemeral Source: Host 800-90 Output: NA Processor None Association: The operating environment is the one and only owner. Relationship is maintained by the operating environment via protected memory. Hash_DRBG Storage: Volatile RAM in Agreement: NA Seed value for Generated as Resetting / rebooting the Crypto Officer DRBG per section plaintext module or power cycling None Seed Value Entry: NA 10.1.1.2 of SP User Type: Ephemeral Source: Host 800-90 Output: NA Processor None Association: The operating environment is the one and only owner. Relationship is maintained by the operating environment via protected memory. Document Version 2.5 © Oracle Communications Page 30 of 40 Key/CSP Name Description / Use Generation Storage Establishment / Export Destruction Privileges Storage: Flash in plaintext Agreement: NA Public Key 1 RSA Public 2048- Internal As this key is public, it does Crypto Officer bit for verify generation by not need to be destroyed RWD FIPS-approved Type: Static Entry: NA operations. User Hash_DRBG R Association: The system is the Output: NA Source: Host in firmware Processor one and only owner. Relationship is maintained by the operating system via certificates. Storage: Flash in plaintext Agreement: NA Public Key 2 RSA Public 2048- Internal As this key is public, it does Crypto Officer bit for generation by not need to be destroyed. RWD FIPS-approved Type: Static Entry: NA key User Hash_DRBG establishment for R Association: The system is the Output: NA TLS sessions. in firmware one and only owner. Relationship is maintained by Source: Host the operating system via Processor certificates. Storage: Flash in plaintext Private Key 1 RSA Private 2048- Internal Re-formatting flash Crypto Officer Agreement: NA bit for sign generation by memory RWD FIPS-approved Type: Static Entry: NA operations. User Hash_DRBG R Source: Host Association: The system is the Output: NA in firmware Processor one and only owner. Relationship is maintained by the operating system via protected memory. Document Version 2.5 © Oracle Communications Page 31 of 40 Key/CSP Name Description / Use Generation Storage Establishment / Export Destruction Privileges Storage: Flash in plaintext Agreement: NA Private Key 2 RSA Private 2048- Internal Re-formatting flash Crypto Officer bit for generation by memory RWD FIPS-approved Type: Static Entry: NA key User 1 Hash_DRBG establishment R for TLS sessions Association: The system is the Output: NA in firmware one and only owner. Source: Host Relationship is maintained by Processor the operating system via protected memory. R = Read W = Write D = Delete Table 11 – 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. All keys can be zeroized by the Crypto Officer using the Zeroize CSPs service. The Crypto Officer can also return the module to Oracle Communications, where it can be reimaged. The reimaging process at Oracle also zeroizes all CSPs but is a different feature than the Zeroize CSPs service that is available to the Crypto Officer. 1 Key establishment methodology provides at least 112-bits of encryption strength Document Version 2.5 © Oracle Communications Page 32 of 40 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 shutdown. 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 known answer test • AES known answer test HMAC-SHA1 known answer test2 • BCM5862 • TRIPLE-DES known answer test • AES known answer test • SHA1 known answer test • HMAC-SHA1 known answer test Intel Core Duo T2500 • SHA1 and SHA256 known answer test • HMAC-SHA1 and HMAC-SHA256 known answer test • Hash_DRBG test • DRBG Health Test as specified in SP 800-90 Section 11.3 • Module integrity check using HMAC-SHA256 • RSA known answer test Table 12 - 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 Mode of Operation. 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. 2 Note: According to the CMVPFAQ p.57 “If a KAT is implemented for the HMAC-SHA-1, a KAT is not needed for the underlying SHA-1.” Document Version 2.5 © Oracle Communications Page 33 of 40 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 Hifn 8450 • None (not applicable) BCM5862 • Continuous HWRNG test Intel Core Duo • Manual key entry test on manually-entered IPSec hash T2500 authentication and data encryption keys via duplicate entry verification • Continuous Hash_DRBG test • Continuous test on output of seed mechanism • RSA pairwise consistency test for sign/verify and encrypt/decrypt Table 13 – Conditional Self-Tests The module does not perform a firmware load test because no additional firmware can be loaded in the module while operating in FIPS mode. 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 2.5 © Oracle Communications Page 34 of 40 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 keypair 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 Manual key entry test on manually-entered IPSec hash Prompt operator to re-enter value authentication and data encryption keys Table 14 – Conditional Self Tests and Module Remediation No keys or CSPs will be output when the module is in an error state. 2.11 Mitigation of Other Attacks The module does not mitigate attacks. Document Version 2.5 © Oracle Communications Page 35 of 40 3 Guidance and Secure Operation This section describes how to configure the module for FIPS mode of operation. Operating the module without maintaining the following settings will remove the module from the FIPS mode of operation. 3.1 Crypto Officer Guidance 3.1.1 Enabling FIPS Mode and General Guidance FIPS Mode is enabled by a license key 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 mode of operation3: • Verify that the firmware version of the module is Version C6.3. No other version can be loaded or used in FIPS mode of operation. • Ensure all media traffic is encapsulated in an IPSec or TLS tunnel as appropriate. • Ensure all management traffic is encapsulated within an SSH session (i.e., Telnet should not be used in FIPS mode of operation). • Ensure USB ports are not 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 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 6 characters in length. • When using RADIUS for authentication, ensure a secure tunnel (via IPSec or TLS) is established between the module and the RADIUS server. • Booting from an external device is not allowed in FIPS mode of operation. The image must be booted from flash memory, which is configured with the following command: 3 The licensing may ensure most of these are met. The Crypto Officer should verify all details prior to operation in FIPS mode. Document Version 2.5 © Oracle Communications Page 36 of 40 ACMEPACKET# configure terminal ACMEPACKET# bootparam • 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 TLS_DHE_RSA_WITH_AES_256_CBC_SHA • Ensure RSA keys are at least 2048-bit keys. No 512-bit or 1024-bit keys can be used in FIPS mode of operation. • Ensure only FIPS-approved algorithms are used for IPSec sessions: Triple-DES AES128CBC AES256CBC AES128CTR AES256CTR HMAC-SHA1 • Ensure the console windows used while manually entering keys are closed immediately after the configuration is complete. • 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 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, Document Version 2.5 © Oracle Communications Page 37 of 40 • Maintaining the direct control and observation of any changes to the module such as reconfigurations to ensure the security of the module is maintained during such changes. Figure 2 – Tamper Evidence Label Placement Rear Figure 3 – Tamper Evidence Label Placement Front Document Version 2.5 © Oracle Communications Page 38 of 40 Figure 4 – Tamper Evidence Label Placement Top/Front Document Version 2.5 © Oracle Communications Page 39 of 40 Figure 5 – 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). To apply replacement labels, see instructions at the beginning of this section. 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 2.5 © Oracle Communications Page 40 of 40