Media Pack (MP) Family Security Policy Document Version 1.5 AudioCodes April 7, 2010 Copyright AudioCodes 2009. May be reproduced only in its original entirety [without revision]. TABLE OF CONTENTS 1. MODULE OVERVIEW ..........................................................................................................................................3 2. SECURITY LEVEL ................................................................................................................................................4 3. MODES OF OPERATION .....................................................................................................................................4 4. PORTS AND INTERFACES ................................................................................................................................12 5. IDENTIFICATION AND AUTHENTICATION POLICY ..............................................................................14 6. ACCESS CONTROL POLICY ............................................................................................................................16 ROLES AND SERVICES ..............................................................................................................................................16 UNAUTHENTICATED SERVICES: ...............................................................................................................................17 DEFINITION OF CRITICAL SECURITY PARAMETERS (CSPS) ......................................................................................17 DEFINITION OF CSPS MODES OF ACCESS .................................................................................................................18 7. OPERATIONAL ENVIRONMENT ....................................................................................................................21 8. SELF TESTS .........................................................................................................................................................21 9. PHYSICAL SECURITY POLICY .......................................................................................................................21 PHYSICAL SECURITY MECHANISMS .........................................................................................................................21 10. EMI/EMC.............................................................................................................................................................22 11. MITIGATION OF OTHER ATTACKS POLICY ...........................................................................................22 Page 2 1. Module Overview The Media Pack (MP) family consists of the MP-112 and MP-124, which are multi-chip standalone cryptographic modules whose primary purpose is to provide VoIP services. The cryptographic boundary is defined as the perimeter of each enclosure. The diagram below illustrates the cryptographic boundary. The MP-112 is a VoIP gateway for two telephones; the MP-124 provides the same function to 24 telephones. Other than that, the services provided by the two modules are identical. Figure 1 ­ Image of the Cryptographic Module The following table lists the module version numbers: Product Hardware part number Firmware version MediaPack 112 GGWV00281 5.60A.025.001 MediaPack 124 GGWU00022 5.60A.025.001 Page 3 2. Security Level The cryptographic module meets the overall requirements applicable to Level 1 security of FIPS 140-2. Table 1 - Module Security Level Specification Security Requirements Section Level Cryptographic Module Specification 1 Module Ports and Interfaces 1 Roles, Services and Authentication 2 Finite State Model 1 Physical Security 1 Operational Environment N/A Cryptographic Key Management 1 EMI/EMC 1 Self-Tests 1 Design Assurance 3 Mitigation of Other Attacks N/A 3. Modes of Operation Approved mode of operation The following table lists the relevant configuration parameters and the values permitted for FIPS mode. To check if the device is operating in FIPS mode, verify the setting of all the parameters below using one of the available device management interfaces, e.g. SSH. Page 4 Parameter Permitted values Notes TLS_FIPS140_Mode 1 Enables self-tests and Approved function implementation TLSVersion 1 Disables SSL 2.0 and SSL 3.0 HTTPSRequireClientCertificate 1 Enables mutual TLS authentication in HTTPS MutualAuthenticationMode 1 Mutual TLS authentication in SIP SIPSRequireClientCertificate 1 Mutual TLS authentication in SIP VerifyServerCertificate 1 Mutual TLS authentication in SIP AUPDVerifyCertificates 1 Enables peer certificate verification for the Automatic Update Facility TelnetServerVerifyPeerCertificate 1 Mutual TLS authentication in Telnet HTTPSCipherString 'EDH-RSA-DES- Selects DH ciphersuites for TLS CBC3-SHA:DHE- RSA-AES128-SHA' TelnetServerEnable 0 or 2 Selects TLS tunneling of telnet data HTTPSOnly 1 Disables plain-text HTTP EnableSIPS 1 Enables SIP/TLS tunneling SIPTransportType 2 Selects TLS as SIP transport BOOTPDisable 1 Disables BOOTP/TFTP at startup SSHRequirePublicKey 1 Force usage of RSA keys in SSH SSHAdminKey Non-blank key RSA administrator key for SSH DenyAuthenticationTimer 20 or higher Limits failed authentication attempts to three per minute EnableTPNCPSecurity 1 Disables TPNCP control IniFileURL and CmpFileURL https://... or Selects transport for the Automatic Update ftps://... Facility ActivityListToLog afl, ard, spc, swu, Selects which events are reported to dr, fb, naa Syslog. Parameter Value Change (PVC) (all except "pvc") logging is prohibited. DisableRS232 1 Disables the serial console port WebAuthMode 0 Selects HTTP basic authentication SnmpTrustedMgr_0 IP address of EMS Defines the IP address of the allowed EMS. This setting must not be zero. Page 5 In FIPS mode, the cryptographic module will support the following Approved algorithms: RSA with 1024 or 2048 bit keys for digital signature generation and verification o Algorithm certificate number: 346, 443 AES with 128, 192, or 256 bit keys o Algorithm certificate numbers: 740, 741, 912 Triple-DES with 128 or 192 bit keys o Algorithm certificate numbers: 657, 737 HMAC SHA-1 o Algorithm certificate numbers: 402, 403, 508 SHA-1 o Algorithm certificate numbers: 754, 755, 899 DRNG - FIPS 186-2 o Algorithm certificate number: 430 The module also supports the following non-Approved algorithms: Diffie Hellman Group 2, with 80-bit key strength HMAC-MD5 within RADIUS and TLS DES RC4 MD5 An NDRNG is is used to provide seed data to the FIPS 186-2 RNG, the NDRNG is based on the sampling of voltage and current generated by the internal power supply. Thermal noise - which occurs naturally in the module - is the source of uncertainty which drives the NDRNG. The following security rules must be followed to maintain the Approved mode of operation. Detailed instructions are provided in the Operator Guidance document: TLS must always be used instead of SSL 2.0, 3.0 and only with DH cipher suites Mutual authentication is required for TLS MD5, HMAC MD5 are not to be used unless mandated by an Acceptable Key Establishment Protocol The module is shipped with a self-generated RSA key-pair and self-signed certificate; this must be replaced by a CA-signed key pair, prior to usage Page 6 Telnet must only be used within a TLS tunnel HTTPS must always be used instead of HTTP A TLS session must be enabled for SIP IPsec must always be enabled for SNMP Keys must only be imported through a dedicated physical link or a secure tunnel Passwords shall be configured to be at least four characters The RADIUS secret shall be configured to be at least four characters The module shall be configured to restrict the number of failed authentication attempts to three per minute The serial port should be disabled Note: The module supports SSHv2 for crypto officer access, and does not support SSHv1. Note: SNMPv3 does not provide FIPS 140-2 Approved security. 3.1 Initial Device Set-up The following instructions are a step-by-step guide to setting up a device in FIPS 140 Approved mode. The device is assumed to be in factory-default condition, and the environment secure. a. Connect the device to a management PC using an Ethernet cross-over cable, establishing a private network . b. Power up the device by connecting the electric cabling. TPM-6300 modules should be properly seated in a Mediant-type chassis. Consult the product's installation manual for related details. c. Obtain the device's IP address using a network monitor; the device will issue a GARP as part of the start-up process. Record this IP address for later use, and modify your PC's IP configuration to match the device's subnet (e.g. if the device has IP address 10.10.1.10, set your IP address to 10.10.1.20). d. Wait for the device LEDs to turn green, indicating firmware start-up has completed. e. Using a web browser, navigate to http://xx.xx.xx.xx where xx.xx.xx.xx denotes the device's Page 7 IP address recorded above. The default username and password are Admin (case- sensitive). Verify that the web interface functions correctly. f. If your network provides PKI services, obtain the appropriate data from your security administrator and skip to the next bullet; otherwise follow the instructions below to establish a minimal PKI configuration (intended to serve as an example only; installation of the OpenSSL toolkit for Windows is assumed). Create a text file called ca.cnf and copy the following text into it: [ req ] default_bits = 1024 distinguished_name = req_distinguished_name prompt = no output_password = password [ req_distinguished_name ] C = US ST = New York L = Poughkeepsie O = Corporate CN = Local CA emailAddress = test@corp.com [ ca ] default_ca = CA_default # The default ca section [ CA_default ] dir = ./testCA # Where everything is kept certs = $dir/certs # Where the issued certs are kept new_certs_dir = $dir/newcerts # default place for new certs. database = $dir/index.txt # database index file. certificate = $dir/cacert.pem # The CA certificate serial = $dir/serial # The current serial number private_key = $dir/private/cakey.pem# The private key RANDFILE = $dir/private/.rand # private random number file default_md = sha1 # which md to use. policy = policy_anything [ policy_anything ] countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional Page 8 Issue these commands at your PC's prompt: mkdir testCA mkdir testCA\private mkdir testCA\certs mkdir testCA\newcerts mkdir testCA\crl openssl req -config ca.cnf -x509 -newkey rsa:1024 -keyout testCA\private\cakey.pem -out testCA\cacert.pem -batch copy /y testCA\cacert.pem root.pem echo 01 > testCA\serial copy /y nul testCA\index.txt openssl req -config ca.cnf -new -keyout dev_pkey.pem -out server.csr - nodes -batch openssl ca -config ca.cnf -in server.csr -subj /CN=acDevice -days 3650 - notext -passin pass:password -out dev_cert.pem -batch openssl req -config ca.cnf -new -keyout pc_pkey.pem -out server.csr - nodes -batch openssl ca -config ca.cnf -in server.csr -subj /CN=acManager -days 3650 -notext -passin pass:password -out pc_cert.pem -batch del server.csr openssl pkcs12 -export -inkey pc_pkey.pem -in pc_cert.pem -out pc_key.pfx -passout pass:1234 g. On the device's web interface, locate the navigation tree on the left pane and click "Full". Click "Security Settings" and select the "Certificates" page. h. Upload the file dev_cert.pem as the device's server certificate. Upload the file root.pem as the trusted root certificate. Upload the file dev_pkey.pem as the device's private key. Save the configuration to flash using the "Burn" button. i. Import the generated certificates into your browser (e.g. in Firefox, click Tools - Advanced - Encryption - View Certificates); add root.pem as a trusted authority, and import pc_key.pfx as a personal certificate (in the example above, the import password is 1234). Notes: 1. Make sure that SSL 2.0/3.0 usage is disabled in your browser. 2. Make sure that your browser selects your personal certificate automatically, when the server requests it. j. Delete the files dev_pkey.pem, pc_pkey.pem and pc_key.pfx from your PC. Page 9 k. Add the module's IP and host name to your PC's hosts file, commonly C:\WINDOWS\system32\drivers\etc\hosts , e.g.: 127.0.0.1 localhost 10.10.1.10 acDevice l. Using an SSH key-generation utility such as PuTTYGen, create an RSA 1024-bit key for SSH authentication (see the product reference manual for further instructions). Record the generated public key. m. Create a text file called device.ini with the desired configuration, e.g.: ; Sample configuration TLS_FIPS140_Mode = 1 TLSVersion = 1 HTTPSRequireClientCertificate = 1 MutualAuthenticationMode = 1 SIPSRequireClientCertificate = 1 VerifyServerCertificate = 1 AUPDVerifyCertificates = 1 TelnetServerVerifyPeerCertificate = 1 HTTPSCipherString = 'EDH-RSA-DES-CBC3-SHA:DHE-RSA-AES128-SHA' HTTPSOnly = 1 EnableSIPS = 1 SIPTransportType = 2 BOOTPDisable = 1 SSHServerEnable = 1 SSHRequirePublicKey = 1 SSHAdminKey = 'AAAAB3NzaC1yc2EAAAABJQAAAIEAorGT9I1XQC......' DenyAuthenticationTimer = 20 EnableTPNCPSecurity = 1 ActivityListToLog = '' DisableRS232 = 1 WebAuthMode = 0 SnmpTrustedMgr_0 = 10.10.1.20 NTPServerIp = 10.10.1.20 NTPServerUTCOffset = 10800 Notes: 1. The value of SSHAdminKey is the RSA key generated in the previous step. 2. The value of NTPServerIp is the IP address of your PC. Note that the module cannot function without proper NTP configuration; if you use Microsoft Windows, NTP services would be provided automatically. 3. The value of NTPServerUTCOffset is the time zone, in seconds; in this example, 10800 denotes a time zone of GMT+3. n. Upload the file device.ini to the device, using the "Device actions" menu. Make sure to restart the device after loading the configuration. Verify that the new configuration is functional. Page 10 Note: Navigate your browser to https://acDevice in order to access the device through the configured host name. Microsoft Internet Explorer cannot be used to connect to the device; Use an alternative browser such as Mozilla Firefox. o. If desired, upgrade to the latest FIPS 140 validated firmware image, using the Software Upgrade wizard. The wizard will reject any image not digitally signed by AudioCodes. p. Using SSH, connect to the device's command-line interface. Type the following command to verify FIPS status: /SEC/FST The device should display FIPS mode status ("ON") and a self-test output code of 0 ("passed"). q. Configuration is now complete. If desired, reconfigure the device to its production IP address (and production NTP server address) before powering off. Page 11 3.2 Non-Approved Mode of Operation The previous section discussed initial set-up of the module, bringing it into Approved mode of operation. To return the device to Non-Approved mode of operation, the operator shall perform the zeroization procedure as described below. The operator shall not change any of the configuration parameters discussed above, to a non- Approved value, while in Approved mode of operation. 3.3 Zeroization To zeroize all security parameters, connect to the device using SSH and issue the command: /SEC/ZEROIZE The device will respond with the message "Zeroization complete" and reboot with default configuration. 4. Ports and Interfaces The MP-112 provides the following physical ports and logical interfaces: Ethernet Port: Data In/Out, Control In, Status Out RJ-11 (Qty. 2): Data In/Out, Control In, Status Out, Power Out Reset Button: Control In Serial: Disabled Power: Power In LEDs (Qty. 6): Status Output, as follows: o Two port status LEDs (telephone line in session) o Ethernet activity LED o General failure LED o Device ready LED o Power LED The MP-124 provides the following physical ports and logical interfaces: Ethernet Ports (Qty. 2): Data In/Out, Control In, Status Out Page 12 Centronics D-Type Connector: Data In/Out, Control In, Status Out, Power Out Reset Button: Control In Serial: Control In, Status Out Power: Power In LEDs (Qty. 28): Status Output, as follows: o 24 port status LEDs (telephone line in session) o Ethernet activity LED o General failure LED o Device ready LED o Power LED Page 13 5. Identification and Authentication Policy Assumption of roles The MP devices support several distinct operator roles as defined in the table below. No feedback during authentication will weaken the strength of the authentication mechanism. The module does not retain the authenticated state across power cycles. Table 2 - Roles and Required Identification and Authentication Role Type of Authentication Authentication Data User Role-based operator authentication Digital Signature Verification (a.k.a. SIP agent) Element Management Role-based operator authentication Digital Signature System Verification or knowledge of a shared secret Monitor Identity-based operator authentication Digital Signature Verification plus Username and Password Administrator Identity-based operator authentication Digital Signature Verification plus Username and Password Crypto Officer Identity-based operator authentication Digital Signature Verification (a.k.a. Security Administrator) and/or Username and Password RADIUS Server Role-based operator authentication Knowledge of a shared secret Page 14 Table 3 ­ Strengths of Authentication Mechanisms Authentication Mechanism Strength of Mechanism Username and Password The password is a minimum of four characters (maximum of 19 characters) selected from the set of 94-printable and human readable characters. The probability that a random attempt will succeed is 1/94^4, which is less than 1/1,000,000. The module will only allow three failed authentication attempts per minute, which ensures that the probability of multiple random authentication attempts being successful is less than 1/100,000. Digital Signature Verification The minimum signature size supported by the module is 1024 bits, which has an effective strength of 80 bits. The probability that a random attempt will succeed is 1/2^80, which is less than 1/1,000,000. The module is limited to 40 signature verifications per second, therefore the probability of multiple random authentication attempts being successful is about 1/(2^68), which is much lower than 1/100,000. Knowledge of a Shared Secret The smallest RADIUS shared secret that is supported is four characters chosen from the set of 94-printable and human readable characters. The probability that a random attempt will succeed is 1/94^4, which is less than 1/1,000,000. The module will only allow 60 failed RADIUS authentication attempts per minute, as there is a one second timeout after each failed attempt, which ensures that the probability of multiple random authentication attempts being successful is less than 1/100,000. Page 15 Notes: The roles of Monitor, Administrator, and Crypto Officer are assumed when connecting to the module using mutually-authenticated TLS (hence digital signature verification is required); username and password are required after the digital signature verification, in order to distinguish between the three roles. The Crypto Officer role may be assumed when connecting to the module using SSHv2 and an RSA key (i.e. digital signature verification alone). 6. Access Control Policy Roles and Services Table 4 ­ Services Authorized for Roles Role Authorized Services User (SIP agent) Establish VoIP Session Terminate VoIP Session Element Management Security Settings System Restart Lock/Unlock Show Status Configure Settings FW Upgrade Load Private Key Self-Tests Monitor Show Status Administrator Restart Lock/Unlock Show Status Configure Settings FW Upgrade Self-Tests Page 16 Crypto Officer (Security Security Settings Administrator) Restart Lock/Unlock Show Status Configure Settings FW Upgrade Load Private Key Zeroize Self-Tests RADIUS Server Facilitate Authentication Unauthenticated Services: The cryptographic module supports the following unauthenticated services: Self-tests: This service executes the suite of self-tests required by FIPS 140-2 and is invoked by power cycling the module. Definition of Critical Security Parameters (CSPs) The following are CSPs contained in the module: IKE Shared Secret TLS Integrity Key IKE Pre-Shared Key: SSHv2 Encryption Key SKEYID SSHv2 Integrity Key SKEYID_d RADIUS Secret SKEYID_a DRNG State SKEYID_e SRTP Master Key IKE Session Encryption Key SRTP Master Salt IKE Session Authentication Key SRTP Encryption Key Device Private Key SRTP Integrity Key IPsec Session Encryption Key SRTP Salting Key IPsec Session Authentication Key SRTCP Encryption Key DH Private Key SRTCP Integrity Key TLS Session Key SRTCP Salting Key Page 17 Passwords Definition of Public Keys: The following are the public keys contained in the module: FW Verification Key Device Public Key DH Public Key DH Peer Public Key Peer Certificate Root Certificate SSHv2 administrator public key Definition of CSPs Modes of Access Table 5 defines the relationship between access to CSPs and the different module services. The modes of access shown in the table are defined as follows: Read (R) Write (W) Zeroize (Z) None (N) Page 18 Table 5 ­ CSP Access Rights within Services IPsec Session Authentication Key IKE Session Authentication Key IPsec Session Encryption Key TLS Session Encryption Key SSH Session Encryption Key IKE Session Encryption Key SSH Session Integrity Key TLS Session Integrity Key RADIUS Shared Secret IKE Pre-Shared Key Device Private Key IKE Shared Secret DH Private Key DRNG State SKEYID_d SKEYID_a SKEYID_e Passwords SKEYID Service/CSPs Establish R R R R R R R R R R R R R R R N N N N VoIP Session W W W W W W W W W W W W W Terminate R R R R R R R R R R R R R R R N N N N VoIP Session W W W W W W W W W W W W W Security R R R R R R R R R R R R R R R R R W W Settings W W W W W W W W W W W W W W W W Restart N N N N N N N N N N N N N N N N N N N Lock/Unlock R R R R R R R R R R R R R R R R R N N W W W W W W W W W W W W W W W Show Status R R R R R R R R R R R R R R R R R N N W W W W W W W W W W W W W W W Configure R R R R R R R R R R R R R R R R R N N Settings W W W W W W W W W W W W W W W FW Upgrade R R R R R R R R R R R R R R R R R N N W W W W W W W W W W W W W W W Load Private R R R R R R R R R R R R R R R R W N N Key W W W W W W W W W W W W W W W Facilitate R N N N N N N N N N N N N N N N N R R Auth. W Zeroize Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Self-Tests N N N N N N N N N N N N N N N N N N N Page 19 Table 5 (cont.) SRTCP Encryption Key SRTP Encryption Key SRTCP Integrity Key SRTP Integrity Key SRTCP Salting Key SRTP Master Key SRTP Master Salt SRTP Salting Key Service/CSPs Establish R R R R R R R R VoIP Session W W W W W W W W Terminate R R R R R R R R VoIP Session W W W W W W W W Security N N N N N N N N Settings Restart N N N N N N N N Lock/Unlock N N N N N N N N Show Status N N N N N N N N Configure N N N N N N N N Settings FW Upgrade N N N N N N N N Load Private N N N N N N N N Key Facilitate N N N N N N N N Auth. Zeroize Z Z Z Z Z Z Z Z Self-Tests N N N N N N N N Page 20 7. Operational Environment The FIPS 140-2 Area 6 Operational Environment requirements are not applicable because the module supports a limited operational environment that only allows the loading of trusted firmware images signed by AudioCodes. 8. Self Tests The cryptographic module shall perform the following tests: A. Power up Self-Tests: 1. Cryptographic algorithm tests: a. Triple-DES KAT (IPsec, TLS) b. AES KAT (IPsec, TLS, sRTP) c. RSA Sign/Verify KAT (IPsec, TLS) d. HMAC SHA-1 KAT (IPsec, TLS, sRTP) e. FIPS 186-2 DRNG Known Answer Test f. SHA-1 Known Answer Test Upon successful completion of the power-up self tests, the module displays the following message via syslog: "FIPS140 self-test: All tests passed successfully". 2. Firmware Integrity Test (32-bit Checksum) B. Conditional Self-Tests: 1. Continuous Random Number Generator (RNG) test ­ performed on the NDRNG and FIPS 186-2 DRNG 2. RSA Pairwise Consistency Test 3. Firmware Load Test (RSA signature validation) At any time, the operator shall be capable of commanding the module to perform the power-up self-test by power cycling the module. 9. Physical Security Policy Physical Security Mechanisms The multi-chip standalone cryptographic module includes production-grade components Page 21 compliant with Level 1 physical security requirements. 10. EMI/EMC The module has been tested for conformance with FCC 47 Code of Federal Regulations, Part 15, Subpart B, Unintentional Radiators, Digital Devices, Class B. 11. Mitigation of Other Attacks Policy The module has not been designed to mitigate specific attacks beyond the scope of FIPS 140-2 requirements. Page 22