SonicWALL TZ 170 FIPS 140-2 Security Policy Level 2 Version 1.12 May 16, 2006 Copyright © 2006 SonicWALL, Inc. 1 Copyright Notice Copyright © 2006 SonicWALL, Inc. May be reproduced only in its original entirety (without revision). Copyright © 2006 SonicWALL, Inc. 2 Table of Contents Copyright Notice................................................................................................................. 2 Introduction......................................................................................................................... 4 Roles and Services .............................................................................................................. 5 Interfaces............................................................................................................................. 7 Ethernet Interfaces........................................................................................................... 7 Console Interface............................................................................................................. 7 Status LED Interface ....................................................................................................... 7 GUI Administration Interface.......................................................................................... 7 Power Interface................................................................................................................ 7 Security Rules ..................................................................................................................... 8 Operational Environment ................................................................................................ 9 FIPS-mode Operation ...................................................................................................... 9 Definition of Critical Security Parameters........................................................................ 10 Cryptographic Boundary ............................................................................................... 13 Definitions and Glossary ............................................................................................... 14 Copyright © 2006 SonicWALL, Inc. 3 Introduction The SonicWALL TZ 170 (hereafter referred to as "the cryptographic module") is a multiple-chip standalone cryptographic module, hardware version 101-5000072-00 rev A, FW SonicOS Enhanced 2.0, 2.5 and 3.1. The cryptographic module is an Internet security appliance, which provides firewall, virtual private network (VPN), and traffic shaping services. Table 1 ­ Module Security Level Specification Security Requirements Section Level Cryptographic Module Specification 2 Cryptographic Module Ports Interfaces 2 Roles, Services, and Authentication 2 Finite State Machine 2 Physical Security 2 Operational Environment N/A Cryptographic Key Management 2 EMI/EMC 3 Self-Tests 2 Design Assurance 2 Mitigation of Other Attacks N/A Copyright © 2006 SonicWALL, Inc. 4 Roles and Services The cryptographic module provides a User role and a Cryptographic Officer role via role-based authentication. The cryptographic module does not provide a Maintenance role. The User role is referred to as Limited Administrator in the vendor documentation. The Cryptographic Officer role is referred to as Administrator in the vendor documentation. These services are available when the module is configured both in FIPS and non-FIPS mode. The configuration settings required to enable FIPS mode are specified on page 9 of this document. The User role is authenticated using the Limited Administrator password. The User role can query status and non-critical configuration. The authentication mechanisms are discussed in the Security Rules Section. User Role Services · Show Status ­ Monitoring, pinging, traceroute, viewing logs. · Show Non-critical Configuration ­ "Show" commands that enable the User to view VPN tunnel status and network configuration parameters. · Session Management ­ Limited commands that allow the User to perform minimal VPN session management, such as clearing logs, and enabling some debugging events. The Cryptographic Officer role is authenticated using the Administrator password. The Cryptographic Officer role can show all status and configure cryptographic algorithms, cryptographic keys, certificates, and TLS servers used for VPN tunnels. The Crypto Officer sets the rules by which the module encrypts and decrypts data passed through the VPN tunnels. The authentication mechanisms are discussed in the Security Rules Section. Crypto Officer Services · Show Status - Monitoring, pinging, traceroute, viewing logs. · Configuration Settings ­ System configuration, network configuration, User settings, Hardware settings, Log settings, and Security services including initiating encryption, decryption, random number generation, key management, and VPN tunnels. · Session Management ­ Management access for VPN session management, such as setting and clearing logs, and enabling debugging events and traffic management. · Key Zeroization ­ Zeroizing cryptographic keys Copyright © 2006 SonicWALL, Inc. 5 The cryptographic module also supports unauthenticated services, which do not disclose, modify, or substitute CSP, use approved security functions, or otherwise affect the security of the cryptographic module. Unauthenticated services · Self-test Initiation ­ power cycle · Firmware removal ­ reset switch · Status ­ console and LED Separation of roles is enforced by requiring users to authenticate using a password. The User role requires the use of a Limited Administrator password. The Cryptographic Officer role requires the use the Administrator password. Only one user may be logged in at any time. The cryptographic module provides several security services including VPN and IPSec. The cryptographic module provides the Cryptographic Officer role the ability to configure VPN tunnels and network settings. When configured to operate in FIPS mode, the cryptographic module provides only FIPS 140-2 compliant services. Whether or not the device is in FIPS mode is indicated on the System/Settings page. The module supports the following FIPS-approved cryptographic algorithms: · AES (128, 192, and 256-bit) in CBC mode · 3DES in CBC mode · DES in CBC mode (for legacy systems) · SHA-1 · DSA (sign and verify) · RSA PKCS#1 (sign and verify) · HMAC-SHA-1 The Cryptographic Module also provides the following non FIPS-Approved algorithms: · MD5 · RC4 · Diffie-Hellman Copyright © 2006 SonicWALL, Inc. 6 Interfaces Ethernet Interfaces The cryptographic module provides seven Ethernet interfaces. Each Ethernet interface is 10/100 auto-sensing with an RJ-45 connector. The Ethernet interfaces are labeled "wan", "opt", "1", "2", "3","4", and "5". The wan and opt interfaces include link and act (activity) LED's. The numbered interfaces provide link/activity LED's. The Ethernet interfaces provide data input and data output. Console Interface The cryptographic module provides a console interface. The console interface is a RJ-45 serial connector. The serial port provides a serial console. The serial console can be used for basic administration functions. The console interface provides control input and status output. Status LED Interface The cryptographic module provides two Status LED's. The Power LED indicates the module is receiving power. The Test LED indicates the module is initializing and performing self-tests by remaining illuminated until the self-tests have been successfully completed. Under normal operation, the Test LED is not illuminated. If the module enters an error state as a result of a self-test failure or other error, the Test LED will illuminate to indicate that the module is in an error state. GUI Administration Interface The cryptographic module provides a GUI administration interface via the Ethernet interfaces. The GUI interface is not part of the cryptographic boundary. It is an external application that receives status information and sends control information through the Ethernet interfaces. Power Interface The cryptographic module provides one DC power interface. Copyright © 2006 SonicWALL, Inc. 7 Security Rules The cryptographic module has the following security rules: · The cryptographic module provides two distinct operator roles: User role and Cryptographic Officer role. · The cryptographic module provides role-based authentication relying upon passwords. · Passwords must be at least eight characters long, and the password character set is ASCII characters 32-127, which is 96 ASCII characters. This makes the probability 1 in 96^8, which is less than one in 1,000,000 that a random attempt will succeed or a false acceptance will occur for each attempt. After three successive unsuccessful password verification tries, the cryptographic module pauses for one second before additional password entry attempts can be reinitiated. This makes the probability approximately 60/96^8, which is less than one in 100,000 that a random attempt will succeed or a false acceptance will occur in a one-minute period. · The following cryptographic algorithm self-tests are performed by the cryptographic module at power-up: -- Software integrity test (using 16-bit CRC EDC) -- DES-CBC Known Answer Test (hardware and firmware) -- Triple DES-CBC Known Answer Test (hardware and firmware) -- AES-CBC Known Answer Test (hardware and firmware) -- SHA-1 Known Answer Test (firmware) -- HMAC-SHA-1 Known Answer Test (firmware) -- DSA Signing and Verification Known Answer Test (firmware) -- RSA Signing and Verification Known Answer Test (firmware) · The following conditional test is performed by the module: -- Continuous Random Number Generator Test on DRNG. · When a new firmware image is loaded, the cryptographic module verifies the 1024-bit DSA signed SHA-1 hash of the image. If this verification fails, the firmware image loading is aborted. If any of the tests described above fail, the cryptographic module enters the error state. No security services are provided in the error state. Upon successful completion of the Diagnostic Phase, the cryptographic module enters the Command and Traffic Processing State. Security services are only provided in the Command and Traffic Processing State. No VPN tunnels are started until all tests are successfully completed. This effectively inhibits the data output interface. When all tests are completed successfully, the Test LED is turned off. Copyright © 2006 SonicWALL, Inc. 8 Operational Environment Area 6 of the FIPS 140-2 requirements do not apply to this module as the module does not support the loading of unvalidated code. FIPS-mode Operation The module is not configured to operate in FIPS-mode by default. The following steps must be taken to enable FIPS-mode operation. · Set Administrator password to at least eight characters. · Do not enable the RADIUS server on the Users/Settings page. · Use IKE with 3rd Party Certificates for IPSec Keying Mode when creating VPN tunnels. · Use a computer directly connected to a LAN port when loading 3rd Party Certificates. · Use a minimum of 1024-bits for all RSA keys. · Use FIPS-Approved encryption and authentication algorithms when creating VPN tunnels. · Use Group 2 or Group 5 for IKE Phase 1 DH Group. · The same RSA key cannot be used for both signing and encryption. · Do not enable the Group VPN Policy. · Do not enable HTTPS management. · Disable "Notify me when new firmware is available" from the System/Settings page. · Enable FIPS mode from the System/Settings page by checking "FIPS Mode" checkbox. · To ensure that the cryptographic module has not been compromised during its distribution, the Crypto Officer shall confirm that the SonicWALL seal is intact on the exterior of the shipped parcel, and that the module has an intact tamper evident seal. The FIPS mode configuration can be determined by the state of the "FIPS Mode" checkbox on the System/Settings page and verification of the preceding steps. Copyright © 2006 SonicWALL, Inc. 9 Definition of Critical Security Parameters The following are the Critical Security Parameters (CSP) contained in the cryptographic module: · Data encryption keys: AES/TDES/DES keys used to encrypt data under IPSec. · 3rd party certificates for encryption: RSA private key for IKE negotiation. · Diffie-Hellman private key: Diffie-Hellman used for IKE negotiation. · HMAC keys used for IKE negotiation and IPSec. · DRNG seed keys: seed keys used with the DRNG specified in the FIPS 186-2, Appendix 3.1, with the SHA-based `G' function. · DRNG state: the state maintained by the DRNG. · Authentication information: passwords used for operator authentication. Public keys 3rd party certificates for encryption: RSA public key for IKE negotiation. DSA 1024-bit Public Key - Used for signature verification upon firmware load. Diffie-Hellman public key: Diffie-Hellman keys used for IKE negotiation All CSPs are zeroed by using the "Reset to Factory Defaults" command. Definition of CSP Modes of Access Table 2 -- CSP Modes of Access describes the methods of accessing the individual CSPs. All operations require the operator to be in the Cryptographic Officer role. Table 2 -- CSP Modes of Access Access Method Public/Private Data Encryption Keys DRNG seed keys DH Private Authentication Keys and state Key Information Import/upload 3rd party Data encryption keys are DRNG seed keys D-H Private certificates can generated on the module, and state keys cannot Operators import be imported in not loaded or imported. information can be imported authentication plaintext, and never be or uploaded. information manually imported or when established, uploaded. authenticating to into the the module. cryptographic module. Copyright © 2006 SonicWALL, Inc. 10 Access Method Public/Private Data Encryption Keys DRNG seed keys DH Private Authentication Keys and state Key Information Generate D-H Private keys are Public/Private Data encryption keys are DRNG seed keys Authentication generated keys are not agreed upon during the and state are information is internally generated key agreement process. generated as a not generated using the within the part of the FIPS within the FIPS 186-2 module. 186-2 key module. DRNG. generation process. Use Public/Private Data encryption keys are DRNG seed keys D-H Private Authentication keys are used used during the VPN and state are used keys are used information is during the tunnel lifetime. when a VPN during the used when an IPSec tunnel is initiated. IPSec operator logs into negotiation negotiation the module. process process Removal/deletion 3rd party Data encryption keys can DRNG seed keys D-H Keys Passwords are certificates be deleted by the and state are are deleted deleted when loaded on the commands described in deleted when the with the new ones are cryptographic the previous section, or power is removed Zeroization configured or module can be when the "Restore To from the module. service. when the deleted by Factory Defaults" "Restore To following the procedure is used, as Factory procedure described in the user Defaults" described in guidance. All private key procedure is the user information is zeroized. used. All guidance. password information is deleted. Table 3 ­ Roles, Services, CSP Access Matrix Role Service Cryptographic Keys and CSPs Access Operation C.O. User Copyright © 2006 SonicWALL, Inc. 11 X X Show Status N/A X Show Non- N/A critical Configuration X X Session Import/upload ­ authentication information. Management X Update and Import/upload ­ 3rd party certificates Show Generate ­ Data encryption keys Configuration Generate ­ DRNG seed keys and state Generate ­ D-H keys Use ­ RSA Public/Private keys Use ­ Data encryption keys Use ­ DRNG seed keys and state Use - D-H keys X Key Remove ­ Private keys Zeroization Remove ­ Data encryption keys Remove ­ DRNG seed keys and state Remove ­ Authentication information Table 4 ­ Role/Services Matrix displays the cryptographic module services appropriate for each user role. Table 4 ­ Role/Services Matrix Role Service User Role Query device statistics and basic configuration Cryptographic Officer Role Manage 3rd Party Certificates, VPN tunnels, administrator password, and device configuration Copyright © 2006 SonicWALL, Inc. 12 Cryptographic Boundary The Cryptographic Boundary includes the entire device. The chassis is sealed with a tamper-evident seal. The physical security of the module is intact if there is no evidence of tampering with the labels. The location of the tamper-evident labels is indicated in green below: Mitigation of Attacks Area 11 of the FIPS 140-2 requirements do not apply to this module as it has not been designed to mitigate any specific attacks. Copyright © 2006 SonicWALL, Inc. 13 Definitions and Glossary AES Advanced Encryption Standard FIPS Federal Information Processing Standard CSP Critical Security Parameter VPN Virtual Private Network EMC Electromagnetic Compatibility EMI Electromagnetic Interference 3DES Triple Data Encryption Standard DES Data Encryption Standard CBC Cipher Block Chaining DSA Digital Signature Algorithm DRNG Deterministic Random Number Generator RSA Rivest, Shamir, Adelman asymmetric algorithm IKE Internet Key Exchange RADIUS Remote Authentication Dial-In User Service IPSec Internet Protocol Security LAN Local Area Network D-H Diffie-Hellman GUI Graphical User Interface SHA Secure Hash Algorithm HMAC Hashed Message Authentication Code Copyright © 2006 SonicWALL, Inc. 14