![FIPS 140-2 Non-Proprietary Security Policy Acme Packet 1100 [1] And .](/img/49/140sp3490-5601486.jpg)
Transcription
FIPS 140-2 Non-Proprietary Security PolicyAcme Packet 1100 [1] and Acme Packet 3900 [2]FIPS 140-2 Level 1 ValidationHardware Version: 1100 [1] and 3900 [2]Firmware Version: E-CZ8.2.0Date: July 9th, 2019Document Version 3.2 Oracle CorporationThis document may be reproduced whole and intact including the Copyright notice.
Title: Acme Packet 1100 [1] and Acme Packet 3900 [2] Non-Proprietary Security PolicyDate: July 9th, 2019Author: Acumen Security, LLCContributing Authors:Oracle Communications EngineeringOracle Security Evaluations – Global Product SecurityOracle CorporationWorld Headquarters500 Oracle ParkwayRedwood Shores, CA 94065U.S.A.Worldwide Inquiries:Phone: 1.650.506.7000Fax: 1.650.506.7200oracle.comCopyright 2019, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and the contents hereof are subject tochange without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied inlaw, including implied warranties and conditions of merchantability or fitness for a particular purpose. Oracle specifically disclaim any liability with respect to thisdocument and no contractual obligations are formed either directly or indirectly by this document. This document may reproduced or distributed whole andintact including this copyright notice.Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.Acme Packet 1100 and 3900 Security Policyi
TABLE OF CONTENTSSection1.TitlePageIntroduction . 11.1Overview . 11.2Document Organization . 12.Acme Packet 1100 & 3900 . 22.13.Functional Overview . 2Cryptographic Module Specification . 33.1Definition of the Cryptographic Module. 33.2FIPS 140-2 Validation Scope . 43.3Approved or Allowed Security Functions . 43.4Non-Approved But Allowed Security Functions . 63.5Non-Approved Security Functions and Services . 63.6Vendor Affirmed Security Functions . 74.Module Ports and Interfaces . 85.Physical Security . 116.Operational Environment . 127.Roles and Services . 137.1Operator Services and Descriptions . 137.2Unauthenticated Services and Descriptions . 167.3Operator Authentication . 167.3.1Crypto-Officer: Password-Based Authentication. 167.3.2User: Certificate-Based Authentication . 177.48.Key and CSP Management . 17Self-Tests . 268.1Power-Up Self-Tests . 268.1.1Firmware Integrity Test . 268.1.2Mocana Cryptographic Library Self-Tests . 268.1.3Oracle Acme Packet Cryptographic Library Self-tests . 268.2Critical Functions Self-Tests . 278.3Conditional Self-Tests . 279.Crypto-Officer and User Guidance . 289.1Secure Setup and Initialization . 289.2AES-GCM IV Construction/Usage . 2910.Mitigation of Other Attacks. 30Acronyms, Terms and Abbreviations . 31Acme Packet 1100 and 3900 Security Policyii
References . 32Acme Packet 1100 and 3900 Security Policyii
List of TablesTable 1: FIPS 140-2 Security Requirements. 4Table 2: Approved and Allowed Security Functions for Oracle Acme Packet Cryptographic Library. 5Table 3: Approved and Allowed Security Functions for Oracle Acme Packet Mocana Cryptographic Library . 6Table 4: Non-Approved but Allowed Security Functions . 6Table 5: Non-Approved Disallowed Functions . 7Table 6: Vendor Affirmed Functions . 7Table 7: Mapping of FIPS 140 Logical Interfaces to Physical Ports . 8Table 8: Physical Ports . 9Table 9: Service Summary . 13Table 10: Operator Services and Descriptions . 16Table 11: Operator Services and Description . 16Table 12: Crypto-Officer Authentication. 17Table 13: User Authentication . 17Table 14: CSP Table . 25Table 15: Acronyms, Terms, and Abbreviations . 31Table 16: References . 32List of FiguresFigure 1:Figure 2:Figure 3:Figure 4:Figure 5:Figure 6:Acme Packet 1100 . 3Acme Packet 3900 . 3Acme Packet 1100 – Front View . 10Acme Packet 1100 – Rear View . 10Acme Packet 3900 – Front View . 10Acme Packet 3900 – Rear View . 10Acme Packet 1100 and 3900 Security Policyiii
1. Introduction1.1OverviewThis document is the Security Policy for the Acme Packet 1100 [1] and Acme Packet 3900 [2] appliancesmanufactured by Oracle Communications. Acme Packet 1100 [1] and Acme Packet 3900 [2] are also referred to as“the module” or “module”. This Security Policy specifies the security rules under which the module shall operateto meet the requirements of FIPS 140-2 Level 1. It also describes how the Acme Packet 1100 [1] and Acme Packet3900 [2] appliances function to meet the FIPS requirements, and the actions that operators must take tomaintain the security of the modules.This Security Policy describes the features and design of the Acme Packet 1100 [1] and Acme Packet 3900 [2]modules using the terminology contained in the FIPS 140-2 specification. FIPS 140-2, Security Requirements forCryptographic Modules specifies the security requirements that will be satisfied by a cryptographic moduleutilized within a security system protecting sensitive but unclassified information. The NIST/CCCS CryptographicModule Validation Program (CMVP) validates cryptographic modules to FIPS 140-2. Validated products areaccepted by the Federal agencies of both the USA and Canada for the protection of sensitive or designatedinformation.1.2Document OrganizationThe Security Policy document is one document in a FIPS 140-2 Submission Package. The Submission Packagecontains: Oracle Non-Proprietary Security PolicyOracle Vendor Evidence documentFinite State MachineEntropy Assessment DocumentOther supporting documentation as additional referencesWith the exception of this Non-Proprietary Security Policy, the FIPS 140-2 Validation Documentation isproprietary to Oracle and is releasable only under appropriate non-disclosure agreements. For access to thesedocuments, please contact Oracle.Acme Packet 1100 and 3900 Security PolicyPage 1 of 32
2. Acme Packet 1100 & 39002.1Functional OverviewThe Acme Packet 1100 [1] and Acme Packet 3900 [2] appliances are specifically designed to meet the unique priceperformance and manageability requirements of the small to medium sized enterprise and remote office/ branchoffice. Ideal for small site border control and Session Initiation Protocol (SIP) trunking service terminationapplications, the Acme Packet 1100 [1] and Acme Packet 3900 [2] appliances deliver Oracle’s industry leadingESBC capabilities in a small form factor appliance. With support for high availability (HA) configurations, TDMfallback, hardware assisted transcoding and Quality of Service (QoS) measurement, the Acme Packet 1100 [1]and Acme Packet 3900 [2] appliances are a natural choice when uncompromising reliability and performance areneeded in an entry-level appliance. With models designed for the smallest branch office to the largest datacenter, the Acme Packet ESBC product family supports distributed, centralized, or hybrid SIP trunking topologies.Acme Packet 1100 [1] and Acme Packet 3900 [2] appliances address the unique connectivity, security, and controlchallenges enterprises often encounter when extending real-time voice, video, and UC sessions to smaller sites. Theappliances also help enterprises contain voice transport costs and overcome the unique regulatory compliancechallenges associated with IP telephony. TDM fallback capabilities ensure continuous dial out service at remote sitesin the event of WAN or SIP trunk failures. Stateful high availability configurations protect against link and hardwarefailures. An embedded browser based graphical user interface (GUI) simplifies setup and administrationAcme Packet 1100 and 3900 Security PolicyPage 2 of 32
3. Cryptographic Module Specification3.1Definition of the Cryptographic ModuleThe module consists of the Acme Packet 1100 [1] and Acme Packet 3900 [2] appliances running firmware version ECZ8.2.0 on the 1100 and 3900 hardware platforms. The module is classified as a multi-chip standalone cryptographicmodule. The physical cryptographic boundary for the Acme Packet 1100 is defined as the module case and allcomponents within the case. The physical cryptographic boundary for the Acme Packet 3900 is all components withexception of the removable power supplies.A representation of the cryptographic boundary is defined below:Figure 1: Acme Packet 1100Figure 2: Acme Packet 3900Acme Packet 1100 and 3900 Security PolicyPage 3 of 32
3.2FIPS 140-2 Validation ScopeThe Acme Packet 1100 and Acme Packet 3900 appliances are being validated to overall FIPS 140-2 Level 1requirements. See Table 1 below.The Acme Packet 1100 and 3900appliancesare being validated to overallCryptographicModule SpecificationFIPS140-2PortsLevel2 requirements.See TableCryptographicModuleandInterfacesRoles and Servicesand Authentication1 below.SecurityRequirements SectionFinite State Machine ModelPhysical SecurityOperational EnvironmentCryptographic Key ManagementEMI/EMCSelf-TestsDesign AssuranceMitigation of Other AttacksLevel11211N/A1113N/ATable 1: FIPS 140-2 Security Requirements3.3Approved or Allowed Security FunctionsThe Acme Packet 1100 [1] and Acme Packet 3900 [2] appliances contain the following FIPS Approved Algorithmslisted in Table 2 (Oracle Acme Packet Cryptographic Library Acme Packet 1100 and 3900) and Table 3 (Oracle AcmePacket Mocana Cryptographic Library Acme Packet 1100 and 3900):Approved or Allowed Security FunctionsCertificateSymmetric AlgorithmsAESCBC, ECB, CTR, GCM; Encrypt/Decrypt; Key Size 128, 256C 140Triple DES1CBC; Encrypt/Decrypt; Key Size 192C 140Secure Hash Standard (SHS)SHSSHA-1, SHA-256, SHA-384, SHA-512C 140Data Authentication CodeHMACHMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512C 140Asymmetric Algorithms1Triple-DES was CAVP tested but is not utilized by the services associated with the Oracle Acme Packet Cryptographic Library.Acme Packet 1100 and 3900 Security PolicyPage 4 of 32
RSA: FIPS186-4:186-4 KEY(gen): FIPS186-4 Random eALG[ANSIX9.31] SIG(gen) (2048 SHA(1, 256 , 384)ALG[ANSIX9.31] SIG(Ver) (2048 SHA(1, 256, 384))RSAC 140RSA: FIPS186-2 :ALG[ANSIX9.31] SIG(gen) (4096 SHA (256,384))ALG[ANSIX9.31] SIG(Ver) (2048 SHA(1, 256, 384)), (4096 SHA (1, 256, 384))RSA: FIPS186-4:186-4 KEY(gen):FIPS186-4 Random e ALG[ANSIX9.31] SIG(gen) (2048 SHA(1, 256 , 384), (4096 SHA(256,384))SIG(Ver) (2048 SHA(1, 256, 384))RSA: FIPS186-2Signature Verification 9.31:Modulus lengths: 2048, 4096SHAs: SHA-1, SHA-256,SHA-384ECDSAFIPS186-4PKG: CURVES (P-256, P-384 Testing Candidates)SigGen: CURVES (P-256: (SHA-256, 384) P-384: (SHA-256, 384)SigVer: CURVES (P-256: (SHA-256, 384) P-384: (SHA-256, 384))C 140Random Number GenerationDRBGCTR DRBG: [ Prediction Resistance Tested: Not Enabled; BlockCipher Use df: (AES-256)]Hash Based DRBG: [ Prediction Resistance Tested: Not Enabled (SHA-1)C 140SNMP KDF, SRTP KDF, TLS KDFC 140Key establishmentKey DerivationKey TransportKTS (AES Cert. # C 140 and HMAC Cert. # C 140; key establishment methodology provides 128 or 256 bits ofencryption strength);KTSTable 2: Approved and Allowed Security Functions for Oracle Acme Packet Cryptographic LibraryApproved or Allowed Security FunctionsCertificateSymmetric AlgorithmsAES2Triple DESCBC; Encrypt/Decrypt; Key Size 128, 256C 139CBC; Encrypt/Decrypt; Key Size 192C 139Secure Hash Standard (SHS)SHSSHA-1, SHA-256, SHA-384, SHA-512C 139Data Authentication CodeHMAC2HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512C 139Per IG A.13 the same Triple-DES key shall not be used to encrypt more than 2 20 64-bit blocks of data.Acme Packet 1100 and 3900 Security PolicyPage 5 of 32
Asymmetric AlgorithmsRSARSA: 186-4:186-4 KEY(gen): FIPS186-4 Random e PKCS1.5: SIG(Ver) (1024 SHA(1); (2048 SHA (1))C 139Key EstablishmentKey Derivation SSH KDF, IKEv1/IKEv2 KDFC 139Key TransportKTS (AES Cert. # C 139 and HMAC Cert. # C 139; key establishment methodology provides 128 or 256 bits ofencryption strength);KTSTable 3: Approved and Allowed Security Functions for Oracle Acme Packet Mocana Cryptographic LibraryNote: P-384 for ECDSA was CAVP tested but is not utilized by the module’s services.3.4Non-Approved But Allowed Security FunctionsThe following are considered non-Approved but allowed security functions:AlgorithmUsageEC-Diffie-HellmanCVL Certs. #C:140 and #C:139 key agreement; key establishment methodology provides 128 or 192bits of encryption strengthDiffie-HellmanCVL Certs. #C:140 and #C:139 key agreement; key establishment methodology provides 112 bits ofencryption strengthRSA Key WrappingKey wrapping, key establishment methodology provides 112-bits of encryption strengthNDRNGUsed for seeding the NIST SP 800-90A Hash DRBG and CTR DRBG. Per FIPS 140-2 IG 7.14 scenario1 (a).The module provides a minimum of 440 bits of entropy input for the Hash DRBG. The input lengthfor the CTR DRBG depends on the size of the AES key used. If the AES key length is 128 bits, theseed size is 256 bits. If the AES key length is 256 bits, then the seed size is 384 bits.MD5 (TLS 1.0/1.1/1.2)MACing: HMAC MD5, Hashing: MD5Table 4: Non-Approved but Allowed Security Functions3.5Non-Approved Security Functions and ServicesThe following services are considered non-Approved and may not be used in a FIPS-approved mode of operation:ServiceNon-Approved Security FunctionsSSHAsymmetric Algorithms: DSA, Symmetric Algorithms: Rijndael, AES GCM, 192-Bit AES CTRSNMPHashing: MD5, Symmetric Algorithms: DESSRTPHashing: MD5IKEv1, IKEv2Hashing: MD5, Symmetric Algorithms: 192-Bit AES CBCTLS 1.0/1.1/1.2Symmetric Algorithms: DESDiffie-HellmanKey agreement, less than 112 bits of encryption strength.RSA Key WrappingKey wrapping, less than 112 bits of encryption strength.Acme Packet 1100 and 3900 Security PolicyPage 6 of 32
Table 5: Non-Approved Disallowed FunctionsServices listed in the previous table make use of non-compliant cryptographic algorithms. Use of thesealgorithms are prohibited in a FIPS-approved mode of operation. Some of these services may be allowed in FIPSmode when using allowed algorithms (as specified in section 9.1).3.6Vendor Affirmed Security FunctionsThe following services are considered non-Approved and may not be used in a FIPS-approved mode of operation:AlgorithmCKGVendor Affirmed Security FunctionsIn accordance with FIPS 140-2 IG D.12, the cryptographic module performs Cryptographic KeyGeneration (CKG) as per SP800-133 (vendor affirmed). The resulting generated symmetric keysand the seed used in the asymmetric key generation are the unmodified output from an NISTSP 800-90A DRBG.Table 6: Vendor Affirmed FunctionsAcme Packet 1100 and 3900 Security PolicyPage 7 of 32
4.Module Ports and InterfacesThe module interfaces can be categorized as follows the FIPS 140-2 Standard: Data Input InterfaceData Output InterfaceControl Input interfaceStatus Output InterfacePower InterfaceThe table below provides a mapping of ports for the Acme Packet 1100 and Acme Packet 3900:LogicalInterfaceData InputData OutputControl InputStatus OutputPowerPhysical Port 1100Physical Port 3900Information Input/OutputEthernet INT/EXT PortsTDM PortsEthernet MGT PortUSB PortEthernet SFP PortsP0,1,2,3Ethernet MGTPortsT1/E1 TDM portsUSB PortCipher textEthernet INT/EXT PortsTDM PortsEthernet MGT PortUSB PortEthernet SFP PortsP0,1,2,3T1/E1 TDM portsEthernet MGTPortsUSB PortCipher textConsole PortConsole PortReset PinholeReset ButtonT1/E1 TDM portPower SwitchPlaintext control input via console port(configuration commands, operator passwords)Ciphertext control input via network management(EMS control, CDR accounting, CLI management)Ethernet MGT PortEthernet INT/EXT PortsUSB PortT1/E1 TDM portsConsole PortConsole PortEthernet MGT PortsEthernet MGT PortsEthernet INT/EXTEthernet SFP PortsPortsP0,1,2,3T1/E1 TDM portT1/E1 TDM portsLEDsLEDsPower PlugPower PlugPlain textPlain textEthernet MGT PortsEthernet SFP PortsP0,1,2,3USB PortPlaintext status output via console port.Ciphertext status output via network managementN/ATable 7: Mapping of FIPS 140 Logical Interfaces to Physical PortsAcme Packet 1100 and 3900 Security PolicyPage 8 of 32
The table below provides a mapping of ports for the Acme Packet 1100 and Acme Packet 3900:PhysicalInterfaceConsole PortNumberof Ports1100Numberof Ports390011Description / UseProvides console access to the module. The module supports only oneactive serial console connection at a time.Console port communication is used for administration and maintenancepurposes from a central office (CO) location. Tasks conducted over aconsole port include: Configuring the boot process and management network Creating the initial connection to the module Accessing and using functionality available via the ACLI Performing in-lab system maintenance (services described below) Performing factory-reset to zeroize nvram and keys in FlashThis port is used for recovery only by Oracle. e.g. system re-installationafter zeroization.Used for EMS control, CDR accounting, CLI management, and othermanagement functionsProvide network connectivity for signaling and media traffic.These ports are also used for incoming and outgoing data (voice) connections.USB Ports22ManagementEthernet portsSignaling andMedia Ethernetports132(INT/EXT)4(SFPP0,1,2,3)11Provides reset functionality44Used to convert analog signals to digital signalsReset Pinhole –Reset ButtonTDM PortsTable 8: Physical PortsAcme Packet 1100
Acme Packet 1100 and 3900 Security Policy Page 1 of 32 1. Introduction 1.1 Overview This document is the Security Policy for the Acme Packet 1100 [1] and Acme Packet 3900 [2] appliances manufactured by Oracle Communications. Acme Packet 1100 [1] and Acme Packet 3900 [2] are also referred to as "the module" or "module".
