FIPS 140-2 Non-Proprietary Security Policy Acme Packet .
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: S-Cz8.2.0Date: December 6th, 2019Document Version 3.3 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: December 6th, 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. 31References . 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 . 6Table 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 SCz8.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.Table 5: Non-Approved Disallowed FunctionsAcme Packet 1100 and 3900 Security PolicyPage 6 of 32
Services 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 and 3900 Security PolicyPage 9 of 32
Figure 3: Acme Packet 1100 – Front ViewFigure 4: Acme Packet 1100 – Rear ViewFigure 5: Acme Packet 3900 – Front ViewFigure 6: Acme Packet 3900 – Rear ViewAcme Packet 1100 and 3900 Security PolicyPage 10 of 32
5.Physical SecurityThe module’s physical embodiment is that of a multi-chip standalone device that meets Level 1 PhysicalSecurity requirements. The module is completely enclosed in a rack mountable chassis.Acme Packet 1100 and 3900 Security PolicyPage 11 of 32
6.Operational EnvironmentThe modules support a limited modifiable operational environment as per the FIPS 140-2 Section 4.6.Acme Packet 1100 and 3900 Security PolicyPage 12 of 32
7. Roles and ServicesAs required by FIPS 140-2 Level 2, there are three roles (a Crypto Officer Role, User Role, and Unauthenticated Role) in the module that operatorsmay assume. The module supports role-based authentication, and the respective services for each role are described in the following sections.The below table gives a high-level description of all services provided by the module and lists the roles allowed to invoke each service.Operator RoleSummary of ServicesUser View configuration versions and system performance data Test pattern rules, local policies, and session translations Display system alarms.Crypto-OfficerUnauthenticated Allowed access to all system commands and configuration privilegesRequest AuthenticationShow StatusInitiate self-testsTable 9: Service Summary7.1Operator Services and DescriptionsThe below table provides a full description of all services provided by the module and lists the roles allowed to invoke each service.UCOService NameXConfigureXXXZeroize CSP’sFirmware UpdateBypassService DescriptionInitializes the module for FIPS mode ofoperationClears keys/CSPs from memory and diskUpdates firmwareConfigure bypass using TCP or UDP andviewing bypass service statusKeys and CSP(s)Access Type(s)HMAC-SHA-256 keyR, W, XAll CSP’sFirmware Integrity Key (RSA)HMAC-SHA-256 Bypass KeyZR, XR, W, XAcme Packet 1100 and 3900 Security PolicyPage 13 of 32
UCOXXDecryptService NameDecrypts a block of data Using AES orTriple-DES in FIPS ModeService DescriptionXXEncryptEncrypts a block of data Using AES orTriple-DES in FIPS ModeXXGenerate KeysGenerates AES or Triple-DES forencrypt/decrypt operations.Keys and CSP(s)TLS Session Keys (AES128)TLS Session Keys (AES256)SSH Session Key (AES128)SSH Session Key (AES256)SRTP Session Key (AES-128)SNMP Privacy Key (AES-128)IKE Session Encryption Key (Triple-DES, AES-128, AES-256)IPsec Session Encryption Key (Triple-DES, AES-128 or AES256)TLS Session Keys (AES128)TLS Session Keys (AES256)SSH Session Key (AES128)SSH Session Key (AES256)SRTP Session Key (AES-128)SNMP Privacy Key (AES-128)IKE Session Encryption Key (Triple-DES, AES-128, AES-256)IPsec Session Encryption Key (Triple-DES, AES-128 or AES256)TLS Session Keys (AES128)TLS Session Keys (AES256)SSH Session Key (AES128)SSH Session Key (AES256)SRTP Session Key (AES-128)SNMP Privacy Key (AES-128)IKE Session Encryption Key (Triple-DES, AES-128, AES-256)IPsec Session Encryption Key (Triple-DES, AES-128 or AES256)Access Type(s)XXXXXXXXXXXXXXXXR, WR, WR, WR, WR, WR, WR, WR, WAcme Packet 1100 and 3900 Security PolicyPage 14 of 32
UCOService NameService DescriptionGenerates Diffie-Hellman, EC DiffieHellman, and RSA keys for keytransport/key establishment.XXXXVerifyUsed as part of the TLS, SSH protocolnegotiationGenerate SeedGenerate an entropy input forHash DRBG, CTR DRBGGenerate random number.XXGenerate RandomNumberXXHMACGenerate HMACXXGenerate CertificateGenerate certificateKeys and CSP(s)Diffie-Hellman Public Key (DH)Diffie-Hellman Private Key (DH)EC Diffie-Hellman Public Key (ECDH)EC Diffie-Hellman Private Key (ECDH)SSH authentication private Key (RSA)SSH authentication public key (RSA)TLS authentication private Key (ECDSA/RSA)TLS authentication public key (ECDSA/RSA)TLS premaster secret,TLS Master secret,SRTP Master keyIKE Private Key (RSA)IKE Public Key (RSA)SKEYSEEDSKEYIDSKEYID dSSH authentication private Key (RSA)SSH authentication public key (RSA)TLS authentication private Key (ECDSA/RSA)TLS authentication public key (ECDSA/RSA)Diffie-Hellman Public Key (DH)Diffie-Hellman Private Key (DH)EC Diffie-Hellman Public Key (ECDH)EC Diffie-Hellman Private Key (ECDH)DRBG SeedDRBG Entropy Input StringDRBG CDRBG VDRBG KeySNMP Authentication KeySRTP Authentication KeySSH Integrity KeysTLS Integrity KeysIPsec Session Authentication KeyIKE Session Authentication KeyWeb UI CertificateAccess Type(s)R, WR, WR, WR, WR, WR, WR, WR, WR, WR, WR, WR, WR, WR, WR, WR, WXXXXXXXXR, W, XR, W, XR, W, XR, W, XXXXXXXR, W, XAcme Packet 1100 and 3900 Security PolicyPage 15 of 32
UCOXXService NameAuthenticateService DescriptionAuthenticate UsersKeys and CSP(s)Operator PasswordAccess Type(s)R, W, XR – Read, W – Write, X – Execute, Z - ZeroizeTable 10: Operator Services and Descriptions7.2 Unauthenticated Services and DescriptionsThe below table provides a full description of the unauthenticated services provided by the module:Service NameOn-Demand Self-Test InitializationShow StatusFactory Reset ServiceService DescriptionThis service initiates the FIPS self-test when requested.This service shows the operational status of the moduleThis service restores the module to factory defaults.Table 11: Operator Services and DescriptionNote: TLS, SRTP and SNMP protocols use the Oracle Acme Packet Cryptographic library.Note: SSH, IKEv2 and IPSec use the Oracle Acme Packet Mocana Cryptographic library.7.37.3.1Operator AuthenticationCrypto-Officer: Password-Based AuthenticationIn FIPS-approved mode of operation, the module is accessed via Command Line Interface over the Console ports or via SSH, SNMPv3 or HTTPS overthe Network Management Ports. Other than status functions available by viewing the Status LEDs, the services described are available only toauthenticated operators.MethodProbability of a Single Successful Random AttemptPassword-Based(CO and UserAuthentication tomanagementinterfaces)Passwords must be a minimum of
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 3
FIPS 140-2 Security Policy KeyPair FIPS Object Module for OpenSSL Page 4 of 18 1 Introduction This document is the non-proprietary security policy for the KeyPair FIPS Object Module for OpenSSL (FIPS 140-2 Cert. #3503), hereafter referred to as the Module. The Module is a software library providing a C language application program interface (API) for use by
Wireless Access Points with FIPS 140-2 Level 2 validation from Aruba Networks. This security policy describes how the AP meets the security requirements of FIPS 140-2 Level 2, and how to place and maintain the AP in a secure FIPS 140-2 mode. This policy was prepared as part of the FIPS 140-2 Level 2 validation of the product.
This Security Policy describes how the Dual Interface Security Controller SLE78 and Java Card Platform binary code meets the security requirements of FIPS 140-2 and CM’s operation in a secure FIPS 140-2 mode. This policy was prepared as part of the Level 3 FIPS 140-2 validation of the module. FIPS 140-2
LogRhythm FIPS Object Module FIPS 140-2 Security Policy Page 3 of 33 References Reference Full Specification Name [ANS X9.31] Digital Signatures Using Reversible Public Key Cryptography for the Financial Services Industry (rDSA) [FIPS 140-2] Security Requirements for Cryptographic modules, May 25, 2001 [FIPS 180-4] Secure Hash Standard
FIPS 140-2 mode. This policy was prepared as part of the Level 2 FIPS 140-2 validation of the module. Note This document may be copied in its entirety and without modification. All copies must include the copyright notice and statements on the last page. FIPS 140-2 (Federal Information Processing Standards Publication 140-2 — Security .
918 - OpenSSL FIPS Object Module v1.1.2 - 02/29/2008 140-2 L1 1051 - OpenSSL FIPS Object Module v 1.2 - 11/17/2008 140-2 L1 1111 - OpenSSL FIPS Runtime Module v 1.2 - 4/03/2009 140-2 L1 Note: Windows FIPS algorithms used in this product may have only been tested when the FIPS mode bit was set. While the
FIPS 140-2 Non-Proprietary Security Policy for WatchGuard Technologies Inc. Firebox Page 5 of 52 1 Introduction This document is a FIPS 140-2 Security Policy for WatchGuard [s Firebox Security System. This policy describes how the Firebox M270, M370, M470, M570, and M670 models (hereafter referred to as the
FortiOS 5.2 FIPS 140-2 Security Policy 01-525-296259-20151016 2 Overview This document is a FIPS 140-2 Security Policy for Fortinet Incorporated’s FortiOS 5.2 firmware, which runs on the FortiGate family of security appliances. This policy describes how the FortiOS 5.2 firmware (hereafter referred to as the ‘module’) meets the FIPS 140-2
