VSX Version R67.10 with R7x hotfix FIPS 140-2 Non-Proprietary Security Policy FIPS 140-2 Level 1 Validation Document Version 1.8 May 31, 2013 © Copyright 2012, 2013 Check Point Software Technologies Ltd. Documentation produced by Rosenberry Associates, Inc. under contract to Check Point. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Table of Contents INTRODUCTION............................................................................................................. 3 PURPOSE....................................................................................................................... 3 REFERENCES ................................................................................................................. 3 DOCUMENT SET FOR SUBMISSION.................................................................................... 3 VSX ................................................................................................................................. 4 OVERVIEW ..................................................................................................................... 4 CRYPTOGRAPHIC MODULE .............................................................................................. 6 MODULE INTERFACES ..................................................................................................... 8 ROLES AND SERVICES..................................................................................................... 9 Remote Crypto Officer Role .................................................................................... 10 Local Crypto Officer Role ........................................................................................ 12 User Role ................................................................................................................ 14 Authentication Mechanisms .................................................................................... 15 Unauthenticated Services ....................................................................................... 16 PHYSICAL SECURITY ..................................................................................................... 16 OPERATIONAL ENVIRONMENT ........................................................................................ 16 CRYPTOGRAPHIC KEY MANAGEMENT ............................................................................. 16 SELF-TESTS................................................................................................................. 21 DESIGN ASSURANCE..................................................................................................... 23 MITIGATION OF OTHER ATTACKS.................................................................................... 23 SECURE DELIVERY AND OPERATION ..................................................................... 23 SECURE DELIVERY........................................................................................................ 23 FIPS MODE CONFIGURATION ........................................................................................ 24 Local Crypto-Officer Configuration Steps ................................................................ 24 Management Station Configuration Steps............................................................... 26 Remote Crypto-Officer Configuration Guidelines .................................................... 27 CRYPTO-OFFICER GUIDANCE ........................................................................................ 36 Management ........................................................................................................... 37 Termination ............................................................................................................. 37 USER GUIDANCE .......................................................................................................... 37 ACRONYMS ................................................................................................................. 38 APPENDIX: DEFINING ADVANCED DIFFIE-HELLMAN GROUPS FOR IKE ............ 39 CAUSE......................................................................................................................... 39 SOLUTION .................................................................................................................... 39 To define Diffie-Hellman group 14:.......................................................................... 39 To define Diffie-Hellman group 15:.......................................................................... 40 To define Diffie-Hellman group 16:.......................................................................... 40 To define Diffie-Hellman group 17:.......................................................................... 41 To define Diffie-Hellman group 18:.......................................................................... 42 © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 2 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Introduction Purpose This non-proprietary cryptographic module Security Policy describes the Check Point Software Technologies Ltd. (Check Point) VSX cryptographic module, Version R67.10 with R7x hotfix. This security policy describes how the Check Point VSX module meets the security requirements of FIPS 140-2 and how to configure and operate the module in the FIPS 140- 2 Approved mode. This policy was prepared to support the Level 1 FIPS 140-2 validation testing of the module. FIPS 140-2 (Federal Information Processing Standards Publication 140-2 — Security Requirements for Cryptographic Modules) details the U.S. Government requirements for cryptographic modules. More information about the FIPS 140-2 standard and validation program is available on the NIST website at http://csrc.nist.gov/groups/STM. Check Point’s VSX Version R67.10 with R7x hotfix is alternatively referenced in this document as Check Point VSX, VSX, the module, and the software. References This document deals only with operations and capabilities of the module in the technical terms of a FIPS 140-2 cryptographic module. More information is available on the module from the following sources: • The Check Point website (http://www.checkpoint.com/) contains information on the full line of products from Check Point. • The NIST Validated Modules website (http://csrc.nist.gov/groups/STM/cmvp/validation.html) provides contact information for answers to technical or sales-related questions regarding the module. Document Set for Submission This Security Policy document is one document in a complete FIPS 140-2 Submission Package. In addition to this document, the complete Submission Package contains: • Security Policy Document (This document) titled, VSX Version R67.10 with R7x hotfix FIPS 140-2 Non-Proprietary Security Policy • Finite State Machine Document titled, VSX Version R67.10 with R7x hotfix FIPS 140-2 Finite State Machine © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 3 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. • Vendor Evidence Documentation titled, VSX Version R67.10 with R7x hotfix Vendor Evidence Documentation The FIPS 140-2 Validation Submission Documentation is Check Point – proprietary, with the exception of the Non-Proprietary Security Policy Document. VSX Overview Check Point’s VSX (Virtual System Extension) is a security and VPN solution, designed to meet the demands of large-scale environments. Based on the proven security of Check Point Security Gateway, VSX provides comprehensive protection for multiple networks or VLANs within complex infrastructures. It securely connects them to shared resources such as the Internet and/or a DMZ, and allows them to safely interact with each other. VSX is supported by IPS™ Services, which provide up-to-date preemptive security. VSX incorporates the same patented Stateful Inspection and Application Intelligence technologies used in the Check Point Security Gateway product line. It runs on high speed platforms (known as VSX gateways) to deliver superior performance in high-bandwidth environments. Administrators manage VSX via Check Point’s Security Management server or Provider-1 Multi-Domain Server (MDS), delivering a unified management architecture that supports enterprises and service providers. A VSX gateway contains a complete set of virtual devices that function as physical network components, such as Security Gateway, routers, switches, interfaces, and even network cables. Centrally managed, and incorporating key network resources internally, VSX allows businesses to deploy comprehensive firewall and VPN functionality, while reducing hardware investment and improving efficiency. Figure 1 shows a typical configuration where VSX is deployed on a LAN. Each “virtual” Security Gateway is known as a Virtual System in VSX terminology, and functions as an independent firewall, protecting a specific network and providing the same security and networking functionality as a physical gateway. © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 4 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Figure 1. Typical VSX Deployment – One VSX Gateway for Multiple Networks This deployment example shows: A VSX Gateway, which directs traffic to the Virtual System protecting the destination network. VSX virtual networks reside on a single configurable VSX gateway or cluster that defines and protects multiple independent networks, together with their virtual components. Four Virtual Systems, each handling packet traffic to and from discrete networks. Virtual Systems connect to internal protected networks using VLAN interfaces. The Virtual System inspects all traffic and passes or rejects it according to rules contained in its Rule Base. One Virtual Switch providing connectivity for all the Virtual Systems to the Internet router. "Virtual" interfaces and network cables (known as Warp Links) providing point-to-point connections between the Virtual Systems and the Virtual Switch. A VLAN switch, which is connected to the VSX gateway via an 802.1q VLAN trunk. Figure 1 above illustrates how a single VSX gateway, in this case containing four Virtual Systems, protects all four networks. The use of VLANs provides scalability as well as granularity, allowing administrators to provision additional Virtual Systems and protected networks quickly and without impacting the existing IP address structure. © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 5 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. In contrast, physical networks consist of many hardware components. Figure 2 shows a deployment with four physical Security Gateways, each protecting a separate network. Each Security Gateway is a separate, physical machine that is hard-wired to the perimeter router and its corresponding network. Figure 2. Separate Physical Gateways Protecting Each Network Cryptographic Module Check Point VSX is a firmware module intended to run on any standard general purpose computer (GPC). Note, within this Security Policy GPC denotes a standard computer hardware platform (Intel x86), excluding any operating system. The term GPC excludes other processing platforms such as smart phones, and smart cards. The module is packaged with a custom built operating system (Check Point Secure Platform) that is installed on the GPC before the module. When installation is complete, the module is locked in FIPS approved mode. © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 6 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. The Check Point VSX cryptographic module is considered to be a multi- chip standalone module for FIPS 140-2. It includes a hardened operating system that is not general purpose and does not implement physical security mechanisms. FIPS 140-2 validation testing was performed using the following operational environment configuration: • Module firmware and Check Point SecurePlatform™ Operating System Version NGX R67 • General Purpose Computer (GPC) with dual Intel Xeon processors 2.33GHz FIPS 140-2 validation is maintained so long as the same module is installed onto any GPC with a compatible 32 bit x86 code-compatible CPU, e.g. Intel® Xeon®, AMD Opteron®, etc. The following figure shows the GPC model Check Point Power-1 9070 (2 x Intel Xeon 5410 "Harpertown" 2.33GHz 1333MHz FSB) used for testing. Logically, the cryptographic boundary is composed of the Secure Platform Operating System integrated with the Check Point VSX software. Physically, the cryptographic boundary of the module is the PC case, which physically encloses the complete set of hardware and software. The physical ports, logical interfaces, and FIPS logical interfaces are described in Table 2. The CMVP allows vendor porting of a validated level 1 firmware cryptographic module from the GPC specified on the validation certificate to a GPC that was not included as part of the validation status, as long as no source code modifications are required. The validation status is maintained on the new GPC without re-testing the cryptographic module on the new GPC. The CMVP makes no statement as to the correct operation of the module when so ported if the specific operational environment is not listed on the validation certificate. The module meets the FIPS 140-2 requirements for an overall Level 1 validation. The following table summarizes the individual FIPS 140-2 requirements sections as outlined in the FIPS 140-2 Derived Test © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 7 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Requirements (DTR) document, as well as the level implemented by the module for each section. Section Section Title Level 1 Cryptographic Module Specification 1 2 Cryptographic Module Ports and Interfaces 1 3 Roles, Services, and Authentication 2 4 Finite State Model 1 5 Physical Security 1 6 Operational Environment N/A 7 Cryptographic Key Management 1 8 EMI/EMC 1 9 Self-tests 1 10 Design Assurance 3 11 Mitigation of Other Attacks N/A Table 1 –Security Level Implemented Per FIPS 140-2 Test Section Although the module consists entirely of software, the FIPS 140-2 evaluated platforms are standard Personal Computer enclosures, which each meet the applicable FCC EMI and EMC requirements for business use as defined by 47 Code of Federal Regulations, Part15, Subpart B. Module Interfaces As a multi-chip standalone module implemented on a standard (PC), the physical ports of the module include the computer’s network ports, keyboard/mouse ports, USB ports, and serial ports. All of these physical ports are separated into logical interfaces by the module software, and these software logical interfaces are then mapped into FIPS 140-2 logical interfaces, as described in the following table. © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 8 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. FIPS 140-2 Logical Logical Interface Standard PC Physical Interface Port Data input interface User Interface (UI) for the Network ports VSX, Network Layer IP interface Data output interface User Interface (UI) for the Network ports VSX, Network Layer IP interface Control input interface User Interface (UI) for the Keyboard ports, USB ports, VSX, Network Layer IP serial ports, network ports, interface power switch Status output interface User Interface (UI) for the Network ports, serial ports, VSX, Network Layer IP video port, LCD Display. interface, Log files Power interface n/a Power connector Table 2 – Mapping Standard PC Physical Ports and Logical Interfaces to FIPS 140-2 Interfaces The logical interfaces are separated by the UIs that distinguish between data input, data output, control input and status output through the dialogues. Similarly, the module distinguishes between different forms of data, control and status traffic over the Network ports by analyzing the packets header information and contents. Log files are only utilized for status output. Roles and Services The module supports three distinct roles: • Remote Crypto-Officer • Local Crypto-Officer • Client User It uses digital signatures, pre-shared keys, and passwords for authentication. The Local Crypto-Officer role is responsible for the installation, minimal configuration, and removal of the VSX. These operations are performed locally using physical access to the PC the module is installed on. The Remote Crypto-Officer role performs primary configuration of VSX. After authenticating, the Remote Crypto-Officer uses a powerful set of management tools to configure and monitor the module. The remote management session uses TLS to ensure security. © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 9 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. The User role is for clients that are accessing the module from remote locations. These operators can authenticate through IKE using either pre- shared keys or digital certificates. Once authenticated, an encrypted tunnel is established between the VSX and the client using IPSec. This section lists system services available to each of the above roles. All of the listed services are available in FIPS mode and in non-FIPS mode except the System Management Command to apply an upgrade or hotfix (patch) is not available in FIPS mode. Figure 3. – Easy to Use Management Tools Note Do not apply upgrades, hotfixes or patches as any change to the validated module firmware will invalidate the FIPS module. Remote Crypto Officer Role The role of the Remote Crypto-Officer includes refinement of administrative permissions, generation and destruction of keys, user access control and creation of the information database. Each management server (i.e., Remote Crypto-Officer) authenticates to the module through TLS using digital certificates. After authenticating, the Remote Crypto-Officers use Check Point management software to manage the module over the secure TLS session. © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 10 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Descriptions of the services available to the Remote Crypto Officer role are provided in the Table 3 below. Service Description Input Output Critical Security Parameter (CSP) Access TLS Access the module’s TLS handshake TLS outputs and RSA key pair for TLS to create a parameters, TLS data management (read secure session for inputs, data access); Session remotely managing keys for manage- the module. ment (read/write access); DRBG SP 800-90A seed key, V & C values (read access) Create and Define users and user Commands and Status of None Configure groups allows the configuration commands and Users/User Crypto-Officer to data (policy files) configuration Groups create permission for data (policy files) individual users or a whole group of users; set permissions such as access hours, user priority, authentication mechanisms, protocols allowed, filters applied, and types of encryption Create and Define external and Virtual System Policy file Same parameters as configure internal network Wizard inputs defining the for TLS and for IPsec internal virtual parameters such as IP Virtual Device and IKE (See Table TLS or IPsec addresses, VLAN 5) and IKE tags, Net Mask, devices. Default Gateway, Define and Configure and install Commands and Status of None Implement security policies that configuration commands and Security Polices are applied to the data (policy files) configuration (including the network and users. data (policy files) rule sets These policies contain governing the a set of rules that automatic, govern the alternating communications bypass) flowing into and out of the module, and provide the Crypto- Officer with a means to control the types of traffic permitted to flow through the module. These policies include the rules that govern the automatic, alternating bypass state of the module. © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 11 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Service Description Input Output Critical Security Parameter (CSP) Access Management of Configure the digital Commands and Status of RSA key pair for IKE keys certificates and/or pre- configuration commands and (read/write access); shared keys for use data (policy files) configuration pre-shared keys for by IPSec and IKE data (policy files) IKE (read/write access) Initialization of Establish trust Commands and Status of RSA key pair for Secure Internal between management configuration commands management Communication server and the VSX data (SIC policy) (read/write access) (SIC) module to allow configuration of the module’s services Monitoring Provides detailed Commands Status of None information for both commands and monitoring of status connection activities information and the system status (logs) Status Output The output indicators Service Inputs Service Outputs CSPs that are described for all accessed by the services. services used. Table 3 – Remote Crypto Officer Services, Descriptions, Inputs and Outputs Local Crypto Officer Role Local operators authenticate to the module using a user name and password. Once authenticated, the operator implicitly assumes the role of Local Crypto-Officer and can access the various utilities and configurations available to that role. Table 4 contains a list of all of the services available to the Local Crypto- Officer, a description of those services along with the relevant CLI commands, the inputs to the services, and the outputs of the services. Service Description with CLI commands Input Output CSP FIPS mode Switch to FIPS mode and enable Command and any Status of None integrity check. options commands Power-up self Power up the Module powers AES- test. system or power up without CMAC cycle the system. error. firmware integrity key, Manage CLI Switch between standard and Commands, any Status of Local settings expert CLI modes (expert); options, and commands Crypto- Logout of the CLI (exit); password (for Officer Change the logged in Local switching between password Crypto-Officer’s password CLI modes) (read/write (passwd) access) © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 12 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Service Description with CLI commands Input Output CSP View local help List available commands and their Commands Status of None documentation respective descriptions (help or ?) commands and status information (help information) Get and set View/change date (date); Commands, any Status of None date and time view/change time (time); options, and date commands and view time zone (timezone) or time settings status information (date, time, or time zone information) System Display or clear audit logs (audit); Commands, any Status of None management backup the system configuration options, and commands and commands (backup); configuration status restore the system configuration parameters information (restore); (logs) reboot the module (reboot); shutdown the module (shutdown); apply an upgrade or hotfix (patch) – not available in FIPS mode System Change logging options (log); Commands and Status of None diagnostic Display top 15 processes ranked any options commands and commands by CPU usage (top); status display or send diagnostic information information (diag) (process list or diagnostic information) Check Point Install licenses, configure the Command Status of None module SNMP daemon, modify the list of (cpconfig), menu commands/me commands Unix groups authorized to register options, and nu options and a cryptographic token and configuration status configure the one time SIC information information password (all functionality is (configuration provided through text-based information) menuing system after executing cpconfig) Network Ping network hosts (ping); Commands and Status of None diagnostic trace the route of packets to a host any options commands and commands (traceroute); status show network statistics (netstat) information (diagnostic information) © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 13 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Service Description with CLI commands Input Output CSP Network Show and modify the kernel’s ARP Commands, any Status of None configuration cache (arp); options, and commands and commands show, set, or remove hostname to configuration status IP mappings (hosts); information information show, configure, and store (configuration network interface settings information) (ifconfig); configure virtual LAN interfaces (vconfig); show and configure routing entries (route); get or modify the system’s host name (hostname); get or set the system’s domain name (domainname); show, add, or remove domain name servers (dns); interactive script for configuring the network and security settings of the system (sysconfig) Key/CSP The Local Crypto-Officer can None None All CSPs zeroization zeroize all of the module’s CSPs stored on by reformatting the hard drive the the module is installed on. module’s hard drive Password Enable local crypto officers to log User ID and Authentication Password Authentication in to the CLI. Password Status Status Output The output indicators described for Service Inputs Service CSPs that all services. Outputs are accessed by the services used. Non-Approved Service Upgrade and Enables a local crypto officer to Commands and N/A N/A Hotfix Service apply software upgrades and any options hotfixes. Do not use as any change to the validated module firmware will invalidate the module. Table 4 – Local Crypto-Officer Services, Descriptions, Inputs and Outputs User Role The User role access the module’s IPSec and IKE services, Status Output services, and authenticates to the module using digital certificates or pre- shared keys (available for IKE). © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 14 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Service descriptions and inputs/outputs are listed in Table 5: Service Description Input Output CSP IKE Access the module’s IKE IKE inputs IKE outputs, RSA key pair for IKE functionality in order to and data status, and (read access); authenticate to the module and data Diffie-Hellman key pair negotiate IKE and IPSec for IKE (read/write session keys access); pre-shared keys for IKE (read access) IPSec Access the module’s IPSec IPSec IPSec Session keys for IPSec services in order to secure inputs, outputs, (read/write access) network traffic commands, status, and and data data Status The output indicators described Service Service CSPs that are accessed Output for all services. Inputs Outputs by the services used. Table 5 – User Services, Descriptions, Inputs and Outputs Authentication Mechanisms The module implements password-based authentication, RSA-based authentication, and HMAC-based authentication mechanisms. Authentication Type Strength RSA-based authentication RSA encryption/decryption (role-based methodology) (TLS handshake) is used to authenticate to the module during the TLS handshake. This mechanism is as strong as the RSA algorithm using a key pair of either 2048 or 4096 bits. Using a 2048 bit key pair is generally considered equivalent to brute forcing a 112 bit key (i.e., a 1 in 2^112 chance of false positive). RSA-based authentication RSA signing/verifying (role-based methodology) is (IKE) used to authenticate to the module during IKE. This mechanism is as strong as the RSA algorithm using a key pair of either, 2048 and 4096 bits. Using a 2048 bit key pair is generally considered equivalent to brute forcing a 112 bit key (i.e., a 1 in 2^112 chance of false positive). Password-based Passwords (identity-based methodology) are required authentication to be between 6 and 128 characters long, a mixture of alphabetic and numeric characters, at least four different characters, and not to be simple dictionary words or common strings such as “qwerty.” Considering only the case sensitive English alphabet and the numerals 0-9 using a 6 digit password with repetition, the number of potential passwords is 62^6. SHA-1 HMAC generation/verification (role-based Pre-shared key-based authentication (IKE) methodology) is used to authenticate to the module during IKE with pre-shared keys (at least 6 characters in length). Table 6 – Estimated Strength of Authentication Mechanisms © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 15 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Each authentication mechanism shown in Table 6 demonstrates that a single, random authentication attempt has less than a 1:1,000,000 chance at success (i.e., a false positive). Repeated attempts to randomly guess the authentication data within a 1- minute period would require the following attempt rates: • IKE / HMAC: ( (94^6) / (100,000 *60) ) = 114,978 attempts per second • RSA-based: ( (2^112) / (100,000 *60) ) = 8.6538281 × 1026 attempts per second The cryptographic module cannot process repeated authentication attempts at these frequencies. Additionally, when operating in Approved Mode, the module only allows a maximum of three unsuccessful password-based attempts before imposing a 60 minute lockout period. The module successfully meets the FIPS 140-2 requirements for strength of authentication for all of its authentication mechanisms. Unauthenticated Services The cryptographic module does not provide any unauthenticated services. All module services are available only to authenticated operators assuming either a Crypto Officer or a User role. Physical Security The physical security of this module will not be tested. Check Point VSX is a firmware module and runs on a production grade GPC. Operational Environment The FIPS 140-2 Operational Environment requirements do not apply to this module. Check Point VSX does not provide a general-purpose operating system nor does it provide a mechanism to load new software. The cryptographic module is firmware and was tested under the Check Point SecurePlatform™ operating system on the processor types provided by General Purpose Computing platforms in the configurations shown in section Cryptographic Module on page 6. These processor types are also reflected in the module’s cryptographic algorithm validation certificates. Cryptographic Key Management Check Point adheres to FIPS-Approved cryptographic standards and provides the strongest cryptography available. Check Point VSX’s efficient implementation of standard cryptographic algorithms ensures the highest level of interoperability. In addition, the module’s implementations provide some of the fastest system performance available in software. © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 16 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. VSX provides the capability to use TLSv1 to secure management sessions. The module supports IPSEC/ESP for data encryption and IPSEC/ESP for data integrity. It implements all IKE modes: main, aggressive, and quick, using ISAKMP as per the standard. The Check Point VSX cryptographic module implements the following FIPS-Approved algorithms (NIST-assigned algorithm validation certificate numbers shown in boxed items): Data Encryption: Advanced Encryption Standard (AES) in CBC mode (128 or 256 bit keys) – as per NIST FIPS PUB 197 VSX Version R67.10 with R7x hotfix Certificate #1837 Triple DES in CBC modes (168 bit keys) – as per NIST PUB FIPS 46-3 (withdrawn) and NIST Special Publication 800-67 VSX Version R67.10 with R7x hotfix Certificate #1190, #1191 Data Packet Integrity: HMAC-SHA-1 (20 byte) – as per NIST PUB FIPS 198, RFC 2104 (HMAC: Keyed-Hashing for Message Authentication), and RFC 2404 (The Use of HMAC-SHA-1-96 within ESP and AH). VSX Version R67.10 with R7x hotfix Certificate #1091, #1092 Data Hashing: Secure Hash Standard supporting SHA-1, SHA-256, SHA-384, and SHA-512, as per NIST PUB FIPS 180-3 VSX Version R67.10 with R7x hotfix Certificate #1617, #1618 © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 17 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. DRBG: DRBG SP 800-90A Implementation VSX Version R67.10 with R7x hotfix Certificate #147 HASH-DRBG with SHA-256 and a seed length of 440 bits in accordance with SP800-90A. Digital Signatures: RSA – PKCS#1 and X9.31 key generation VSX Version R67.10 with R7x hotfix Certificate #926 The RSA implementation is used both for signature generation and verification (per PKCS#1). The module implements the following protocols permitted for use in a FIPS-Approved mode of operation (per FIPS 140-2 Implementation Guidance 7.1): Session Security: • TLS v1.0 – as per RFC 2246. TLS v1.0 is equivalent to Secure Socket Layer (SSL) v3.1. • IPSec Key Wrapping (Key Agreement / Key Establishment): Encryption strength is determined by using the equation provided in FIPS 140-2 Implementation Guidance 7.5 and NIST Special Publication 800-57, Part 1. Encryption strength is a function of the key size implemented. The module supports IKEv2 by default and IKEv1 for compatibility. • In FIPS mode the Diffie-Hellman key agreement methodology implemented by the module (used by IKE) provides between 80 and 128 bits of encryption strength. Less than 80 bits is non- compliant with FIPS. Check Point recommends that only Diffie- © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 18 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Hellman Groups 14 to 18 be used, to provide between 112 and 128 bits of encryption strength. • The RSA key wrapping methodology (used by TLS), provides 112 bits or 150 bits of encryption strength. • The module supports key entry though TLS using 3-key Triple- DES session keys. Triple-DES (Cert. #1191), key wrapping; key establishment methodology provides 112 bits of encryption strength) In addition, the Check Point VSX provides the following algorithms that are not approved for FIPS: • CAST (40 or 128 bit keys) • HMAC-MD5 (16 bytes) – as per RFC 2104 (HMAC: Keyed-Hashing for Message Authentication) and RFC 2403 (The Use of HMAC- MD5-96 within ESP and AH). • MD5 • DES • AES CMAC The following is a list of the Critical Security Parameters (CSPs) implemented by the module: Key Key type Generation Storage Use Local Crypto- N/A Entered by Local Crypto- Officer local crypto Stored on disk (/etc/password) - plaintext Officer passwords officer authentication RSA key pair RSA key pair Outside of Stored on disk in P12 format Authentication for (2048 or crypto- during TLS ($CPDIR/conf/sic_cert.p12) management 4096 bits) boundary) (considered plaintext) handshake RSA key pair RSA key pair Outside of Stored on disk for IKE (2048 or Crypto Authentication ($FWDIR$/database/fwauth.NDBX) – 4096 bits) boundary plaintext during IKE Pre-shared IKE pre- Outside of Stored on disk Authentication keys for IKE shared key crypto- during IKE ($FWDIR$/database/fwauth.NDB) (SHA-1 (48 – 512 boundary - plaintext HMAC) bits) Diffie- Diffie- Generated by RAM only (public parameters stored on Key exchange Hellman key Hellman key IKE disk during IKE pairs pairs (2048, negotiations ($FWDIR/database/objects.C and 3072, 4096, $FWDIR/state/local/FW1/local.objects) 6144, 8192 - plaintext bits) Session keys Triple-DES Generated by Secure IPSec for IPSec keys (168 IKE traffic bits), AES negotiations RAM only - plaintext (128, 256 © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 19 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Key Key type Generation Storage Use Bits) Session keys Triple-DES Generated by Cached to disk Secure TLS for keys (168 TLS traffic (SIC) ($CPDIR$/database/session.NDBX) - management bits) handshake plaintext HMAC HMAC Generated by Cached to disk Authenticated session key TLS ($CPDIR$/database/session.NDBX) - TLS traffic for handshake plaintext management Integrity AES CMAC Outside of Hard-coded into the cphash binary Power-up check key crypto- integrity test boundary SP 800-90A Seed Key of Generated by RAM only, but entropy used to generate Random bit Hash_DRGB 440 bits gathering keys is cached to disk generator seed keys according to entropy ($CPDIR/registry/HKLM_registry.data and SP 800-90A. $CPDIR/registry/HKLM_registry.data.old) – plaintext SP 800-90A Internal state Internal state RAM only Random bit Hash_DRBG for the derived from generator V & C values Hash_DRBG seed value Table 7 – Listing of the Module’s CSPs The Local Crypto-Officer passwords are used to authenticate the Local Crypto-Officer to the CLI. Additionally, these passwords are used to switch CLI modes and to access the bootloader. These passwords are configured by the local Crypto-Officer over the CLI or by the Remote Crypto-Officer over an authenticated, encrypted management session. These passwords are stored on the module’s hard drive, and can be zeroized by changing the password or reformatting the hard drive. The RSA key pair for remote management sessions is generated externally by the management software. This key pair is loaded onto the module during the setup of secure communications with a management station over a secure TLS session. This key pair is stored on the module’s hard drive and can be zeroized by reformatting the hard drive containing the module’s software or re-initializing SIC. The RSA key pair used by IKE is generated external to the module by the management software. This key pair is loaded onto the module over a secure TLS session established between the module and the management software. The Local Crypto Officer configures the module to import external keys from the management station. This key pair is stored on the module’s hard drive in plaintext and can be zeroized by reformatting the module’s hard drive containing the module’s software. Pre-shared keys are input into the module over an encrypted management session. These keys are used during IKE for authentication. The pre- shared key configuration information is stored on the module’s hard drive and can be zeroized by reformatting the hard drive containing the © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 20 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. module’s software. Additionally, it can be overwritten by changing the pre- shared key. Diffie-Hellman (DH) key pairs are generated during IKE for use for key exchange during IKE. These are ephemeral key pairs. Diffie-Hellman Groups 14 to 18 are used, to provide between 112 and 128 bits of encryption strength. The public parameters are exchanged over a secure TLS session established between the module and the management software. These parameters are deleted from the system after IKE key exchange is complete. Session keys for IPSec are ephemeral keys established for IPSec connections. These keys are negotiated during IKE as part of the DH key agreement. They are generated as needed by an SA and are only stored in volatile memory. These keys can be zeroized by powering down the module. Session keys for management session are established by the TLS handshake protocol. These keys are used to encrypt management session and are generated as needed by the TLS handshake. These keys are stored in volatile memory as well as cached to disk for possible reuse. The keys in volatile memory can be zeroized by powering down the module. The keys cached to disk can be zeroized by reformatting the hard drive containing the module’s software. The AES CMAC integrity check key is generated externally from the module and is hard-coded into the cphash binary. This key is stored on the module’s hard drive in plaintext and is used to perform the firmware integrity check. The keys cached to disk can be zeroized by reformatting the partition (or whole hard drive). The SP 800-90A deterministic random bit generator (DRBG) keys are generated by the module using entropy gathered from various sources. The entropy used to generate these keys is cached to the module’s hard drive and are used by the SHA-256 DRBG. The seed length is 440 bits in accordance with SP800-90A. This entropy can be zeroized by reformatting the hard drive containing the module’s software. Self-Tests The module performs a set of self-tests in order to ensure proper operation in compliance with FIPS 140-2. These self-tests are run during power-up (power-up self-tests) or when certain conditions are met (conditional self-tests). © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 21 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Power-up Self-tests: • Firmware Integrity Tests: The module checks the integrity of its various components using a AES-CMAC. • Cryptographic Algorithm Known Answer Tests (KATs): KATs are run at power-up for the following algorithms: o AES-CBC KAT o Triple-DES-CBC KAT o DRBG KAT o RSA (encrypt/decrypt) and (sign/verify) KAT tests o SHA-1 KAT o SHA-256 KAT o SHA-384 KAT o SHA-512 KAT o SHA-1 HMAC KAT • Policy file integrity test (bypass mode test): the module performs a SHA-1 check value verification to ensure that the policy files are not modified. Conditional Self-tests: • Continuous DRBG Test: This test is constantly run to detect failure of the module’s random bit generator. • Policy file integrity test (bypass mode test): the module performs a SHA-1 check value verification to ensure that the policy files are not modified. If any of the kernel module KATs fail, the system enters the kernel panic state. If any one of the service KATs fails, that service halts and the system enters the error state. If the KATs are passed (by both the kernel modules and the services), the success is logged to the Check Point log. If the power-up firmware integrity check fails, the system enters the integrity check failure state, halts, and has to be restarted. If the firmware integrity check passes, the event is logged to the Check Point log. If the continuous DRBG test fails, the system reboots. All errors are logged to the Check Point logs. © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 22 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. When the module enters the error state, all cryptographic services and data output for the problem service is halted until the error state is cleared. Restarting the module or the failed service can clear the error state. Design Assurance Check Point uses a hybrid configuration management system for its products and documentation management needs. Both CVS and Rational® ClearCase® are used for configuration management of product source code releases. These software applications provide access control, versioning, and logging capabilities for tracking the components included in the various Check Point products. Manual configuration management controls are utilized for the associated product documentation. A formal process has been implemented whereby a log is kept of all product documentation and updates. Product documentation releases are tied to versions of the cryptographic module and source code build releases through this log. Subversion is used to provide configuration management and archival for the module’s FIPS 140-2 documentation. This document database application provides access control, versioning, and logging for documents created in support of FIPS 140-2 validation testing efforts. Mitigation of Other Attacks The module does not provide mitigation against other attacks. It is designed to meet the overall FIPS 140-2 level 1 requirements and provides the standard level of security that comes with meeting those requirements. SECURE DELIVERY AND OPERATION Check Point VSX meets overall Level 1 requirements for FIPS 140-2. The sections below describe how to securely deliver the module to authorized operators, and includes how to place and keep the module in FIPS- approved mode of operation. Secure Delivery The cryptographic module ships from the manufacturer to the customer without any cryptographic keys. The only critical security parameter (CSP) is the default password contauined in the ISO image that is configured during installation. All other cryptographic keys and CSPs are generated after the module is installed and initially powered up. When the module powers up, firmware integrity tests check the integrity of its various components using a 56-bit error detection code (EDC) calculated by the cphash binary when FIPS mode is enabled. © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 23 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Other known answer tests (see Self Tests in this document for a complete description of known answer tests) confirm the correct operation of cryptographic algorithms and security functions. If any of these tests fail, the module will not initialize. FIPS Mode Configuration Local Crypto-Officer Configuration Steps The Local Crypto-Officer must perform the following operations during installation and initialization of the module in order to enable the FIPS mode of operation. Note: These instructions also apply if the Local Crypto-Officer is migrating from previous module versions to the evaluated cryptographic module version. The Local Crypto-Officer must reinstall and reinitialize the module as per these instructions. Module version VSX Version R67.10 with R7x hotfix includes support for Diffie-Hellman Groups up to Group 14 (2048 bit modulus) key sizes. Additional Diffie-Hellman Groups 15-18 (3072 bits to 8192 bits) must be configured during the initialization process by the Local Crypto-Officer before beginning the initialization of the module. Check Point recommends that Diffie-Hellman Groups 14 to 18 be used, The procedure for enabling the additional groups is obtainable from Check Point support SK27054 on the Check Point website. The system time clocks of the module platform, the management station, and any other trusted systems must all be synchronized. 1. Install the Secure Platform operating system. The module automatically reboots the system once this is completed. Note: when installing onto some computing platforms, it will be necessary to load the software from a temporarily-connected USB CD-ROM or via the network interface by using FTP. 2. Login to the console using the default Local Crypto-Officer password. The module will immediately request that this password be changed. 3. At the command prompt, run the following command to begin configuration of the module. sysconfig The following will be performed via the menus displayed when “sysconfig” is run. © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 24 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. a. Perform the network configuration, date and time configuration, and the licensing configuration. b. When prompted to select Check Point software to install on top of the operating system, select only “VPN-1 Power VSX”.. c. Continue through the rest of the configuration until the sysconfig command finishes. 4. Reboot the module. 5. Login to the console. 6. Switch to expert mode. 7. Copy /boot/grub/grub.conf to /boot/grub/grub.conf.bak. 8. Edit /boot/grub/grub.conf and remove all of the lines below and including the “title Start in maintenance mode” line until “title Start in online debug mode” 9. Save /boot/grub/grub.conf. 10. Copy /etc/cpshell/cpshell.cfg to /etc/cpshell/cpshell.cfg.bak. 11. Edit /etc/cpshell/cpshell.cfg and remove the line beginning with “patch”. 12. Save /etc/cpshell/cpshell.cfg. 13. Copy /etc/cpshell/fips.cfg.disabled to /etc/cpshell/fips.cfg 14. Edit /etc/cpshell/fips.cfg and add the following line. expert 0 1 “expert” “Switch to expert mode” 15. Save /etc/cpshell/fips.cfg. 16. Copy $CPDIR/conf/sic_policy.conf to $CPDIR/conf/sic_policy.conf.bak. 17. Copy $CPDIR/conf/fips_sic_policy.conf to $CPDIR/conf/sic_policy.conf 18. This step is optional. If configuring support for additional Diffie- Hellman Groups 15-18, follow the instructions found in SK27054 for defining the moduli for these Diffie-Hellman Groups in the product database. See also note under Step #1. © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 25 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 19. Exit expert mode. 20. Switch the module to FIPS mode by entering the following command: fips on 21. Reboot. Running the “fips on” command disables SSH, disables the Web UI, removes support for SSLv3 from SIC (i.e. only TLS is supported), enables Local Crypto-Officer account lockout of 60 minutes after 3 failed authentication attempts, disables remote installation daemon, and removes access to the fw, fwm, and vpn command line utilities. The Local Crypto-Officer must not switch out of FIPS mode or disable the firmware integrity check. Management Station Configuration Steps In order for the external management station to operate correctly with the module running in FIPS mode, the following commands must be run on the management station. Also, the time clock on the management station should be synchronized with the module platform as well as any other trusted systems. 1. If the Check Point services are running, execute the following command to stop all Check Point services. cpstop 2. Copy $CPDIR/conf/sic_policy.conf to $CPDIR/conf/sic_policy.conf.bak. 3. Copy $CPDIR/conf/fips_sic_policy.conf to $CPDIR/conf/sic_policy.conf 4. Run the following command to enable only TLSv1 for management sessions. ckp_regedit -a "Software\CheckPoint\SIC" FIPS_140 -n 1 5. If the Check Point services were stopped in step 1, restart them by entering the following command. cpstart © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 26 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Remote Crypto-Officer Configuration Guidelines The Remote Crypto-Officer must follow the following guidelines for configuring the modules services. Authentication during IKE and TLS must employ pre-shared keys or digital certificates. Additionally, only the following FIPS-approved algorithms may be used by IPSec, IKE and TLS: Data Encryption • Triple-DES • AES Data Packet Integrity • HMAC with SHA1 Authentication • Certificates • Pre-shared keys The following figures contain screen-shots that illustrate the module’s FIPS mode settings: © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 27 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Figure 4 – In Traditional Mode, Select Only FIPS-Approved Algorithms for use with IKE © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 28 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Figure 5 – In Meshed Communities Select Only FIPS-Approved Algorithms for use with IKE © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 29 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Figure 6 – Only Pre-Shared Keys or Digital Certificates may be used to Authenticate Clients © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 30 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Figure 7 – Only FIPS-Approved Algorithms may be used with IKE Notes: 1. Diffie-Hellman Group 14 (2048-bits) provides 112 bits of encryption strength. Check Point recommends the use of Diffie-Hellman groups 14 or higher, to provide 112 or more bits of encryption strength. © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 31 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Figure 8 – Only FIPS-Approved Algorithms may be used with IPSec © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 32 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Figure 9 – Only FIPS-Approved Algorithms may be used with TLS © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 33 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Figure 10 – Only FIPS-Approved Algorithms may be used with TLS © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 34 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Figure 11 – Configuring the module to enable Distributed Key Management (DKM) globally © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 35 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Figure 12 – Configuring the module to generate RSA keys with DKM on a per-certificate basis Crypto-Officer Guidance The Local Crypto-Officer is responsible for installation and initialization of the module, configuration and management of the module, and removal of the module. More details on how to use the module can be found in the Check Point VSX user manuals. The Local Crypto-Officer receives the module in a shrink wrapped package containing a CD-ROM with the VSX installation media and user documentation. The Crypto-Officer should examine the package and shrink wrap for evidence of tampering. Tamper-evidence includes tears, scratches, and other irregularities in the packaging. Before the installation of the module, there is no access control provided by the module. Therefore, the Local Crypto-Officer must maintain control of the installation media. During installation, the Local Crypto-Officer boots a standard PC from the CD-ROM containing the module’s software. The Crypto-Officer will walk through a series of steps, and must follow the directions above to properly configure the module for FIPS 140-2 compliance. The Local Crypto-Officer password for the module is a default after installation. Before this is changed, the Crypto-Officer must maintain control of the module. This password must be changed immediately upon logging into the module after installation. © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 36 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. The Local Crypto-Officer must establish the SIC configuration after logging into the module for the first time. Once this has been completed, the module has been adequately initialized and can be managed from the management server. To determine if the module is in the alternating bypass state, the Remote Crypto Officer can examine the VPN rule table. If at least one connection is configured without encryption then the module is in the alternating bypass state. If all connections are configured with encryption the module is not in the alternating bypass state. Management Once initialization of the module has been completed, the Remote Crypto- Officer must manage the module using the remote management server. Through this server, the Crypto-Officer is able to configure policies for the module. These policies determine how the VPN services of the module will function. The Remote Crypto-Officer is responsible for maintaining the module. Besides management of the module, this involves monitoring the module’s logs. If unusual or suspicious activity is found, the Crypto-Officer must take the module offline and investigate. If the module consistently malfunctions or otherwise repeatedly enters an error state, the Remote or Local Crypto-Officer must contact the manufacturer. Note Do not apply upgrades, hotfixes or patches as any change to the validated module firmware will invalidate the FIPS module. Termination At the end of the life cycle of the module, the Local Crypto-Officer must reformat the hard drive containing the module’s software. This will zeroize all keys and other CSPs. User Guidance The User accesses the module’s VPN functionality as an IPSec client or as a remote access TLS-based VPN client. Although outside the boundary of the module, the User must be careful not to provide authentication information and session keys to other parties. © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 37 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. ACRONYMS AH Authentication Header ANSI American National Standards Institute CBC Cipher Block Chaining CLI Command Line Interface CRC Cyclic Redundancy Check CSP Critical Security Parameter DRBG Deterministic Random Bit Generator. Also known as a pseudorandom number generator (PRNG). DSA Digital Signature Standard EMC Electromagnetic Compatibility EMI Electromagnetic Interference ESP Encapsulating Security Payload FCC Federal Communication Commission FIPS Federal Information Processing Standard FP Feature Pack HF Hot Fix IKE Internet Key Exchange IPSec IP Security KAT Known Answer Test LED Light Emitting Diode MAC Message Authentication Code NG Next Generation NIST National Institute of Standards and Technology NVLAP National Voluntary Laboratory Accreditation Program PC Personal Computer RAM Random Access Memory RIP Routing Information Protocol RSA Rivest Shamir and Adleman SA Security Association SHA Secure Hash Algorithm SIC Secure Internal Communications SNMP Simple Network Management Protocol SP Secure Platform SSH Secure Shell SVN Secure Virtual Network TLS Transport Layer Security VPN Virtual Private Network © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 38 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. APPENDIX: DEFINING ADVANCED DIFFIE-HELLMAN GROUPS FOR IKE Based on the following Check Point support article: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetail s=&solutionid=sk27054 Solution ID: sk27054 Product: VSX, Security Gateway Version: NGX R61, NGX R67, NGX R65, NGX R62, NGX R60, R70, R71, R75 OS: All Last Modified:22-May-2011 Cause By default, VPN-1 Pro supports Diffie-Hellman groups 1, 2 and 5. RFC 3526 defines new DH groups, numbered 14 to 18. These groups use longer modulus, and are expected to become widely used in the next few years. While VPN-1 Pro is able to use these groups starting with VPN-1 NG with Application Intelligence R55 HFA 10, these new groups are not yet defined in the database. This document describes how to define these objects in the database. Solution The Diffie-Hellman prime numbers are presented as complete strings. The excessive horizontal formatting of this article is due to the length of these strings. Follow the below instructions to define groups 14 through 18. Group 24 is added and supported in R7x Use cut-and-paste to copy the DH prime number. To define Diffie-Hellman group 14: 1. Close SmartDashboard. 2. Open 'GuiDBedit'. 3. In the top left corner, go to 'VPN -> encryption'. 4. Right-click the top right window and choose "New..." 5. Under "Class" choose "IKE_Diffie_Hellman_parameters_object". 6. Under Object, type "Group 14 (2048 bit)". 7. Click 'OK'. 8. Set "DH_group_number" to 14. 9. Set "mod"->"value" to the MODP string below. NOTE: cut and paste into 'GuiDBedit'. 10. Set "modsize" to 2048. 11. Set "private_key_length" to 256. 12. Set "root"->"value" to "02" (zero-two). 13. Set "rootsize" to 2. 14. "type" should be set to "IKE_DH_parameters". 15. Save and exit. Group 14's MODP: © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 39 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. FFFFFFFFFFFFFFFFC90FDAA22168C234C4C6628B80DC1CD129024E088A67CC74020BBEA63B139 B22514A08798E3404DDEF9519B3CD3A431B302B0A6DF25F14374FE1356D6D51C245E485B57662 5E7EC6F44C42E9A637ED6B0BFF5CB6F406B7EDEE386BFB5A899FA5AE9F24117C4B1FE64928665 1ECE45B3DC2007CB8A163BF0598DA48361C55D39A69163FA8FD24CF5F83655D23DCA3AD961C62 F356208552BB9ED529077096966D670C354E4ABC9804F1746C08CA18217C32905E462E36CE3BE 39E772C180E86039B2783A2EC07A28FB5C55DF06F4C52C9DE2BCBF6955817183995497CEA956A E515D2261898FA051015728E5A8AACAA68FFFFFFFFFFFFFFFF To define Diffie-Hellman group 15: 1. Close SmartDashBoard. 2. Open GuiDBEdit. 3. In the top left corner, go to VPN->encryption. 4. Right-click the top right window and choose "New..." 5. Under "Class" choose "IKE_Diffie_Hellman_parameters_object". 6. Under "Object", type "Group 15 (3072 bit)". 7. Click 'OK'. 8. Set "DH_group_number" to 15. 9. Set "mod"->"value" to the MODP string below. NOTE: cut and paste into 'GuiDBEdit'. 10. Set "modsize" to 3072. 11. Set "private_key_length" to 256. 12. Set "root"->"value" to "02" (zero-two). 13. Set "rootsize" to 2. 14. "type" should be set to "IKE_DH_parameters". 15. Save and exit. Group 15's MODP: FFFFFFFFFFFFFFFFC90FDAA22168C234C4C6628B80DC1CD129024E088A67CC74020BBEA63B139 B22514A08798E3404DDEF9519B3CD3A431B302B0A6DF25F14374FE1356D6D51C245E485B57662 5E7EC6F44C42E9A637ED6B0BFF5CB6F406B7EDEE386BFB5A899FA5AE9F24117C4B1FE64928665 1ECE45B3DC2007CB8A163BF0598DA48361C55D39A69163FA8FD24CF5F83655D23DCA3AD961C62 F356208552BB9ED529077096966D670C354E4ABC9804F1746C08CA18217C32905E462E36CE3BE 39E772C180E86039B2783A2EC07A28FB5C55DF06F4C52C9DE2BCBF6955817183995497CEA956A E515D2261898FA051015728E5A8AAAC42DAD33170D04507A33A85521ABDF1CBA64ECFB850458D BEF0A8AEA71575D060C7DB3970F85A6E1E4C7ABF5AE8CDB0933D71E8C94E04A25619DCEE3D226 1AD2EE6BF12FFA06D98A0864D87602733EC86A64521F2B18177B200CBBE117577A615D6C77098 8C0BAD946E208E24FA074E5AB3143DB5BFCE0FD108E4B82D120A93AD2CAFFFFFFFFFFFFFFFF To define Diffie-Hellman group 16: 1. Close SmartDashBoard. 2. Open 'GuiDBEdit'. 3. In the top left corner, go to VPN->encryption. 4. Right-click the top right window and choose "New..." 5. Under "Class" choose "IKE_Diffie_Hellman_parameters_object". 6. Under Object, type "Group 16 (4096 bit)". © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 40 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 7. Click 'OK'. 8. Set "DH_group_number" to 16. 9. Set "mod"->"value" to the MODP string below. NOTE: cut and paste into 'GuiDBEdit'. 10. Set "modsize" to 4096. 11. Set "private_key_length" to 256. 12. Set "root"->"value" to "02" (zero-two). 13. Set "rootsize" to 2. 14. "type" should be set to "IKE_DH_parameters". 15. Save and exit. Group 16's MODP: FFFFFFFFFFFFFFFFC90FDAA22168C234C4C6628B80DC1CD129024E088A67CC74020BBEA63B139 B22514A08798E3404DDEF9519B3CD3A431B302B0A6DF25F14374FE1356D6D51C245E485B57662 5E7EC6F44C42E9A637ED6B0BFF5CB6F406B7EDEE386BFB5A899FA5AE9F24117C4B1FE64928665 1ECE45B3DC2007CB8A163BF0598DA48361C55D39A69163FA8FD24CF5F83655D23DCA3AD961C62 F356208552BB9ED529077096966D670C354E4ABC9804F1746C08CA18217C32905E462E36CE3BE 39E772C180E86039B2783A2EC07A28FB5C55DF06F4C52C9DE2BCBF6955817183995497CEA956A E515D2261898FA051015728E5A8AAAC42DAD33170D04507A33A85521ABDF1CBA64ECFB850458D BEF0A8AEA71575D060C7DB3970F85A6E1E4C7ABF5AE8CDB0933D71E8C94E04A25619DCEE3D226 1AD2EE6BF12FFA06D98A0864D87602733EC86A64521F2B18177B200CBBE117577A615D6C77098 8C0BAD946E208E24FA074E5AB3143DB5BFCE0FD108E4B82D120A92108011A723C12A787E6D788 719A10BDBA5B2699C327186AF4E23C1A946834B6150BDA2583E9CA2AD44CE8DBBBC2DB04DE8EF 92E8EFC141FBECAA6287C59474E6BC05D99B2964FA090C3A2233BA186515BE7ED1F612970CEE2 D7AFB81BDD762170481CD0069127D5B05AA993B4EA988D8FDDC186FFB7DC90A6C08F4DF435C93 4063199FFFFFFFFFFFFFFFF To define Diffie-Hellman group 17: 1. Close SmartDashBoard. 2. Open 'GuiDBEdit'. 3. In the top left corner, go to VPN->encryption. 4. Right-click the top right window and choose "New..." 5. Under "Class" choose "IKE_Diffie_Hellman_parameters_object". 6. Under Object, type "Group 17 (6144 bit)". 7. Click 'OK'. 8. Set "DH_group_number" to 17. 9. Set "mod"->"value" to the MODP string below. NOTE: cut and paste into 'GuiDBEdit'. 10. Set "modsize" to 6144. 11. Set "private_key_length" to 256. 12. Set "root"->"value" to "02" (zero-two). 13. Set "rootsize" to 2. 14. "type" should be set to "IKE_DH_parameters". 15. Save and exit. Group 17's MODP: © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 41 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. FFFFFFFFFFFFFFFFC90FDAA22168C234C4C6628B80DC1CD129024E088A67CC74020BBEA63B139 B22514A08798E3404DDEF9519B3CD3A431B302B0A6DF25F14374FE1356D6D51C245E485B57662 5E7EC6F44C42E9A637ED6B0BFF5CB6F406B7EDEE386BFB5A899FA5AE9F24117C4B1FE64928665 1ECE45B3DC2007CB8A163BF0598DA48361C55D39A69163FA8FD24CF5F83655D23DCA3AD961C62 F356208552BB9ED529077096966D670C354E4ABC9804F1746C08CA18217C32905E462E36CE3BE 39E772C180E86039B2783A2EC07A28FB5C55DF06F4C52C9DE2BCBF6955817183995497CEA956A E515D2261898FA051015728E5A8AAAC42DAD33170D04507A33A85521ABDF1CBA64ECFB850458D BEF0A8AEA71575D060C7DB3970F85A6E1E4C7ABF5AE8CDB0933D71E8C94E04A25619DCEE3D226 1AD2EE6BF12FFA06D98A0864D87602733EC86A64521F2B18177B200CBBE117577A615D6C77098 8C0BAD946E208E24FA074E5AB3143DB5BFCE0FD108E4B82D120A92108011A723C12A787E6D788 719A10BDBA5B2699C327186AF4E23C1A946834B6150BDA2583E9CA2AD44CE8DBBBC2DB04DE8EF 92E8EFC141FBECAA6287C59474E6BC05D99B2964FA090C3A2233BA186515BE7ED1F612970CEE2 D7AFB81BDD762170481CD0069127D5B05AA993B4EA988D8FDDC186FFB7DC90A6C08F4DF435C93 402849236C3FAB4D27C7026C1D4DCB2602646DEC9751E763DBA37BDF8FF9406AD9E530EE5DB38 2F413001AEB06A53ED9027D831179727B0865A8918DA3EDBEBCF9B14ED44CE6CBACED4BB1BDB7 F1447E6CC254B332051512BD7AF426FB8F401378CD2BF5983CA01C64B92ECF032EA15D1721D03 F482D7CE6E74FEF6D55E702F46980C82B5A84031900B1C9E59E7C97FBEC7E8F323A97A7E36CC8 8BE0F1D45B7FF585AC54BD407B22B4154AACC8F6D7EBF48E1D814CC5ED20F8037E0A79715EEF2 9BE32806A1D58BB7C5DA76F550AA3D8A1FBFF0EB19CCB1A313D55CDA56C9EC2EF29632387FE8D 76E3C0468043E8F663F4860EE12BF2D5B0B7474D6E694F91E6DCC4024FFFFFFFFFFFFFFFF To define Diffie-Hellman group 18: 1. Close SmartDashBoard. 2. Open 'GuiDBEdit'. 3. In the top left corner, go to VPN->encryption. 4. Right-click the top right window and choose "New..." 5. Under "Class" choose "IKE_Diffie_Hellman_parameters_object". 6. Under Object, type "Group 18 (8192 bit)". 7. Click 'OK'. 8. Set "DH_group_number" to 18. 9. Set "mod"->"value" to the MODP string below. NOTE: cut and paste into 'GuiDBEdit'. 10. Set "modsize" to 8192. 11. Set "private_key_length" to 256. 12. Set "root"->"value" to "02" (zero-two). 13. Set "rootsize" to 2. 14. "type" should be set to "IKE_DH_parameters". 15. Save and exit. Group 18's MODP: FFFFFFFFFFFFFFFFC90FDAA22168C234C4C6628B80DC1CD129024E088A67CC74020BBEA63B139 B22514A08798E3404DDEF9519B3CD3A431B302B0A6DF25F14374FE1356D6D51C245E485B57662 5E7EC6F44C42E9A637ED6B0BFF5CB6F406B7EDEE386BFB5A899FA5AE9F24117C4B1FE64928665 1ECE45B3DC2007CB8A163BF0598DA48361C55D39A69163FA8FD24CF5F83655D23DCA3AD961C62 F356208552BB9ED529077096966D670C354E4ABC9804F1746C08CA18217C32905E462E36CE3BE 39E772C180E86039B2783A2EC07A28FB5C55DF06F4C52C9DE2BCBF6955817183995497CEA956A E515D2261898FA051015728E5A8AAAC42DAD33170D04507A33A85521ABDF1CBA64ECFB850458D BEF0A8AEA71575D060C7DB3970F85A6E1E4C7ABF5AE8CDB0933D71E8C94E04A25619DCEE3D226 1AD2EE6BF12FFA06D98A0864D87602733EC86A64521F2B18177B200CBBE117577A615D6C77098 © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 42 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 8C0BAD946E208E24FA074E5AB3143DB5BFCE0FD108E4B82D120A92108011A723C12A787E6D788 719A10BDBA5B2699C327186AF4E23C1A946834B6150BDA2583E9CA2AD44CE8DBBBC2DB04DE8EF 92E8EFC141FBECAA6287C59474E6BC05D99B2964FA090C3A2233BA186515BE7ED1F612970CEE2 D7AFB81BDD762170481CD0069127D5B05AA993B4EA988D8FDDC186FFB7DC90A6C08F4DF435C93 402849236C3FAB4D27C7026C1D4DCB2602646DEC9751E763DBA37BDF8FF9406AD9E530EE5DB38 2F413001AEB06A53ED9027D831179727B0865A8918DA3EDBEBCF9B14ED44CE6CBACED4BB1BDB7 F1447E6CC254B332051512BD7AF426FB8F401378CD2BF5983CA01C64B92ECF032EA15D1721D03 F482D7CE6E74FEF6D55E702F46980C82B5A84031900B1C9E59E7C97FBEC7E8F323A97A7E36CC8 8BE0F1D45B7FF585AC54BD407B22B4154AACC8F6D7EBF48E1D814CC5ED20F8037E0A79715EEF2 9BE32806A1D58BB7C5DA76F550AA3D8A1FBFF0EB19CCB1A313D55CDA56C9EC2EF29632387FE8D 76E3C0468043E8F663F4860EE12BF2D5B0B7474D6E694F91E6DBE115974A3926F12FEE5E43877 7CB6A932DF8CD8BEC4D073B931BA3BC832B68D9DD300741FA7BF8AFC47ED2576F6936BA424663 AAB639C5AE4F5683423B4742BF1C978238F16CBE39D652DE3FDB8BEFC848AD922222E04A4037C 0713EB57A81A23F0C73473FC646CEA306B4BCBC8862F8385DDFA9D4B7FA2C087E879683303ED5 BDD3A062B3CF5B3A278A66D2A13F83F44F82DDF310EE074AB6A364597E899A0255DC164F31CC5 0846851DF9AB48195DED7EA1B1D510BD7EE74D73FAF36BC31ECFA268359046F4EB879F9240094 38B481C6CD7889A002ED5EE382BC9190DA6FC026E479558E4475677E9AA9E3050E2765694DFC8 1F56E880B96E7160C980DD98EDD3DFFFFFFFFFFFFFFFFF © Copyright 2012, 2013 Check Point Software Technologies Ltd. Page 43 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice.