Trunk Pack Module (TPM) 6300 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 ..............................................................................13 6. ACCESS CONTROL POLICY ............................................................................................................................15 ROLES AND SERVICES ..............................................................................................................................................15 UNAUTHENTICATED SERVICES: ...............................................................................................................................16 DEFINITION OF CRITICAL SECURITY PARAMETERS (CSPS) ......................................................................................16 DEFINITION OF CSPS MODES OF ACCESS .................................................................................................................17 7. OPERATIONAL ENVIRONMENT ....................................................................................................................19 8. SELF TESTS .........................................................................................................................................................20 9. PHYSICAL SECURITY POLICY .......................................................................................................................20 PHYSICAL SECURITY MECHANISMS .........................................................................................................................20 10. EMI/EMC.............................................................................................................................................................21 11. MITIGATION OF OTHER ATTACKS POLICY ...........................................................................................21 Page 2 1. Module Overview The TPM-6300 family consists of the TPM-6300-D6 and TPM-6300-D21, which are multi-chip embedded cryptographic modules whose primary purpose is to provide VoIP services. The cryptographic boundary is defined as the perimeter of the PCB. The diagram below illustrates the cryptographic boundary. The TPM-6300-D21 is equipped with 21 Digital Signal Processors (DSPs), whereas the TPM- 6300-D6 is a lower-capacity variant with only 6 DSPs assembled on the PCB. Figure 1 ­ Images of the Cryptographic Module Above: TPM-6300-D21 module Below: TPM-6300-D6 module mounted on a TP-8410 base-board Page 3 The following table lists the module version numbers: Product Hardware part number Firmware version TPM-6300 D21 FASB00645 5.60AV.004.002 TPM-6300 D6 FASB00646 5.60AV.004.002 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, 911 Triple-DES with 128 or 192 bit keys o Algorithm certificate numbers: 657, 736 HMAC SHA-1 o Algorithm certificate numbers: 402, 403 SHA-1 o Algorithm certificate numbers: 754, 755 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 reading clock values from the on-board Digital Signal Processors, which are not synchronized with the host processor's clock. Jitter and clock drift are the sources of uncertainty which drive the NDRNG. The following security rules must be followed to maintain the Approved mode of operation: 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 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 Page 6 IPsec must always be enabled for SNMP and TPNCP 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 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 Page 7 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. k. Add the module's IP and host name to your PC's hosts file, commonly Page 9 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. 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 Page 10 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. 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. Page 11 4. Ports and Interfaces The cryptographic module provides the following physical ports and logical interfaces: Gigabit Ethernet: Data In/Out, Control In, Status Out Time Difference Modulation Bus: Data In/Out, Control In, Status Out Memory Bus: Control In, Status Out I2C Bus: Control In, Status Out UTOPIA Bus: Data In/Out, Control In, Status Out Asynchronous Transfer Mode: N/A Serial: Disabled Power: Power In LEDs (Qty. 4): Status Output, as follows: o Packet transmit activity LED (orange) o Packet receive activity LED (red) o Device ready LED (green) o General failure LED (yellow) PCI: N/A (reserved for future use) Page 12 5. Identification and Authentication Policy Assumption of roles The TPM-6300 supports 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 (a.k.a SIP agent) Verification 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 Shelf Controller Role-based operator authentication Digital Signature Verification or knowledge of a shared secret RADIUS Server Role-based operator authentication Knowledge of a shared secret Page 13 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. Due to performance constraints, the module is not capable of supporting enough authentication attempts to have a greater probability of 1/100,000 that multiple random authentication attempts within a given minute will be successful. 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 14 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 (Controller) 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 Crypto Officer (Security Security Settings Administrator) Restart Page 15 Lock/Unlock Show Status Configure Settings FW Upgrade Load Private Key Zeroize Self-Tests Shelf Controller through Security Settings Trunk Pack Network Restart Control Protocol (TPNCP) 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 IKE Session Authentication Key IKE Pre-Shared Key: Device Private Key SKEYID IPsec Session Encryption Key SKEYID_d IPsec Session Authentication Key SKEYID_a DH Private Key SKEYID_e TLS Session Key IKE Session Encryption Key TLS Integrity Key Page 16 SSHv2 Encryption Key SRTP Integrity Key SSHv2 Integrity Key SRTP Salting Key RADIUS Secret SRTCP Encryption Key DRNG State SRTCP Integrity Key SRTP Master Key SRTCP Salting Key SRTP Master Salt Passwords SRTP Encryption Key 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 17 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 18 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 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. Page 19 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 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 embedded cryptographic module includes production-grade components compliant with Level 1 physical security requirements. Page 20 10. EMI/EMC The FCC does not support standalone testing of embedded components. The AudioCodes Mediant 8000 VoIP Gateway, a product which includes the TPM-6300 module, has been tested for conformance with FCC 47 Code of Federal Regulations, Part 15, Subpart B, Unintentional Radiators, Digital Devices, Class A. 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 21