CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7 09/19/2017 3e Technologies International 9715 Key West Avenue 5th Floor Rockville, MD 20850 USA www.ultra-3eti.com CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 2 of 35 1. SECURITY TARGET INTRODUCTION........................................................................................................3 1.1 SECURITY TARGET REFERENCE......................................................................................................................3 1.2 TOE REFERENCE............................................................................................................................................3 1.3 TOE OVERVIEW .............................................................................................................................................4 1.3.1 Hardware, Firmware, and Software Required by the TOE ...................................................................4 1.4 TOE DESCRIPTION .........................................................................................................................................4 1.4.1 TOE Architecture...................................................................................................................................5 1.4.2 TOE Documentation ..............................................................................................................................7 2. CONFORMANCE CLAIMS..............................................................................................................................8 2.1 CONFORMANCE RATIONALE...........................................................................................................................8 3. SECURITY OBJECTIVES ................................................................................................................................9 3.1 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT .....................................................................9 4. EXTENDED COMPONENTS DEFINITION ................................................................................................10 5. SECURITY REQUIREMENTS.......................................................................................................................11 5.1 TOE SECURITY FUNCTIONAL REQUIREMENTS .............................................................................................11 5.1.1 Security audit (FAU)............................................................................................................................12 5.1.2 Cryptographic support (FCS)..............................................................................................................14 5.1.3 Identification and authentication (FIA) ...............................................................................................17 5.1.4 Security management (FMT) ...............................................................................................................18 5.1.5 Protection of the TSF (FPT) ................................................................................................................19 5.1.6 TOE access (FTA)................................................................................................................................19 5.1.7 Trusted path/channels (FTP) ...............................................................................................................20 5.2 TOE SECURITY ASSURANCE REQUIREMENTS...............................................................................................20 5.2.1 Development (ADV).............................................................................................................................21 5.2.2 Guidance documents (AGD)................................................................................................................21 5.2.3 Life-cycle support (ALC) .....................................................................................................................22 5.2.4 Security Target (ASE) ..........................................................................................................................23 5.2.5 Tests (ATE) ..........................................................................................................................................23 5.2.6 Vulnerability assessment (AVA)...........................................................................................................23 6. TOE SUMMARY SPECIFICATION..............................................................................................................24 6.1 SECURITY AUDIT ..........................................................................................................................................24 6.2 CRYPTOGRAPHIC SUPPORT ...........................................................................................................................24 6.3 IDENTIFICATION AND AUTHENTICATION.......................................................................................................31 6.4 SECURITY MANAGEMENT .............................................................................................................................32 6.5 PROTECTION OF THE TSF .............................................................................................................................33 6.6 TOE ACCESS.................................................................................................................................................34 6.7 TRUSTED PATH/CHANNELS ...........................................................................................................................34 LIST OF TABLES Table 1 TOE Security Functional Components ......................................................................................................12 Table 2 Assurance Components ...............................................................................................................................21 Table 6-1: TOE FIPS-140 Tested Algorithms.........................................................................................................26 Table 6-2: TOE CSPs Use and Management ..........................................................................................................26 Table 6-5: Management of TSF Data.......................................................................................................................32 CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 3 of 35 1. Security Target Introduction This section identifies the Security Target (ST) and Target of Evaluation (TOE) identification, ST conventions, ST conformance claims, and the ST organization. The TOE is CyberFence 3e-636 Series Network Security Devices provided by 3e Technologies International. The TOE is being evaluated as a Network Device. The Security Target contains the following additional sections:  Conformance Claims (Section 2)  Security Objectives (Section 3)  Extended Components Definition (Section 4)  Security Requirements (Section 5)  TOE Summary Specification (Section 6) Conventions The following conventions have been applied in this document:  Security Functional Requirements – Part 2 of the CC defines the approved set of operations that may be applied to functional requirements: iteration, assignment, selection, and refinement. o Iteration: allows a component to be used more than once with varying operations. In the ST, iteration is indicated by a parenthetical number placed at the end of the component. For example FDP_ACC.1(1) and FDP_ACC.1(2) indicate that the ST includes two iterations of the FDP_ACC.1 requirement. o Assignment: allows the specification of an identified parameter. Assignments are indicated using bold and are surrounded by brackets (e.g., [assignment]). Note that an assignment within a selection would be identified in italics and with embedded bold brackets (e.g., [[selected- assignment]]). o Selection: allows the specification of one or more elements from a list. Selections are indicated using bold italics and are surrounded by brackets (e.g., [selection]). o Refinement: allows the addition of details. Refinements are indicated using bold, for additions, and strike-through, for deletions (e.g., “… all objects …” or “… some big things …”).  Other sections of the ST – Other sections of the ST use bolding to highlight text of special interest, such as captions. 1.1 Security Target Reference ST Title – CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target ST Version – Version 0.7 ST Date – 09/19/2017 1.2 TOE Reference TOE Identification – 3e Technologies International CyberFence 3e-636 Series Network Security Devices TOE Developer – 3e Technologies International TOE Models – 3e-636L3 EtherGuard, 3e-636L2 DarkNode, 3e-636H UltraCrypt, 3e-636A EtherWatch CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 4 of 35 TOE Firmware Versions: 5.1.300 for 3e-636L3 EtherGuard, 5.1.300 for 3e-636L2, 3e-636H, 3e-636A Evaluation Sponsor – 3e Technologies International Keywords – Encryption, VLAN, VPN, IPsec, access control, data packet inspection, traffic filter 1.3 TOE Overview The Target of Evaluation (TOE) is CyberFence 3e-636 Series Network Security Devices. 3eTI’s 636 Series Network Security Devices offer the multiple capabilities necessary for protecting embedded devices and safety- critical industrial control systems (ICS) against internal and external attacks. The core capabilities include: network access control, OSI Layer 2 and Layer 3 packet filtering, industrial control protocols packet inspection and secured application data transportation (via encryption). This Security Target only addresses the functions that provide for the security of the TOE itself as described in Section 1.4.1.2 TOE logical boundaries below. 1.3.1 Hardware, Firmware, and Software Required by the TOE The TOE requires the following Operational Environment support which is not included in the TOE’s physical boundary.  Administrator Workstations: Trusted administrators access the TOE through the TLS/HTTPS protocol.  Audit Servers: The TOE relies upon the audit server for storage of audit records. The TOE itself stores limited amount of the audit records in its internal persistence storage. Those audit records are accessible and exportable through the Web GUI interface.  NTP Servers: The TOE relies upon an NTP server to provide reliable time. If the time is configured locally, the TOE will use its own reliable hardware clock to maintain time as well.  LDAP Server: The TOE relies on the LDAP server for centralized authentication of administrator if the security administrator chooses this configuration. The TOE can also authenticate administrator using local user name and password. 1.4 TOE Description The TOE is composed of both hardware and firmware. All four models of the 3e-636 series devices share identical hardware. The firmware contains modules, that when activated, can provide additional functionality to the device. The 3e-636L3 runs firmware with naming convention: “signed_636N-L3.5.1.300.00.43.bin”. The last 2 digits are associated with the build number for a minor bug fix release that affected non security related functionality associated with this devices capability. 3e-636L2 DarkNode, 3e-636H Ultracrypt and 3e-636A EtherWatch run on firmware with naming convention: “signed_636N.5.1.300.00.50.bin”. The evaluated version of the product was the 3e-636L2 DarkNode. The two sets of firmware are treated as equivalent under the context of this CPPNDV10 validation in that they share a common base consisting of a collection of modules that implement all CPPNDV10 SFRs, those are: o Same vendor’s own OpenSSL library and cryptographic hardware driver o Same HTTPS module o Same IPsec module o Same WebGUI for security functional management o Same audit log module for CPPNDV10 audit logs The differences between the two sets of firmware are the addition of other modules which implement functionality that is outside the scope of this evaluation. The 3e-636L3 is the common base plus a network data routing module, firewall modules and Industrial Protocol DPI modules, while the 3e-636L2 is the common base plus a VLAN encryption module, with firewall and industrial protocol DPI as optional modules. CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 5 of 35 The table below identifies the additional product functional features supported by each model of the TOE. Again, none of the features listed below are included in the evaluated configuration. Device Name VPN Encryption VLAN Encryption Access Control Industrial Protocol Packet Inspection 3e-636L3 EtherGuard X X X 3e-636L2 Darknode X X X 3e-636H Ultracrypt X 3e-636A EtherWatch X X 1.4.1 TOE Architecture The figure below illustrates the typical deployment use case and operational environment setup for TOE devices. 3 eTI 636L 3 EtherGuard Network Security Network Network Peer Time Server Audit Log Server IPsec Tunnels 3e-636L2 DarkNode Ultracrypt Network Peer LDAP Server 3e-636L2 EtherWatch Network Peer TOE TLS Management Station All devices operate in the same operation environment. IPsec tunnels are used to secure the communication between device and external servers such as NTP server, Audit log server and LDAP server. All devices offer the same HTTPS/TLS based GUI interface for device configuration and management. CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 6 of 35 1.4.1.1 Physical Boundaries The TOE physical boundary defines all hardware and firmware that is required to support the TOE’s logical boundary and the TOE’s security functions. The TOE hardware platform uses FreeScale MPC8378E CPU and the TOE’s firmware contains an embedded Linux Kernel customized by 3eTI based on kernel version 4.6. In short, the TOE’s physical boundary is the physical device for all models. The table below describes the ports and interfaces implemented by the TOE Port/Interfaces Management/Control I/O Data Input Data Output Status Output Same on all devices Local Management Ethernet port (1) X Yes Plain text Ethernet port (1) X X X Yes Cipher text Ethernet port (1) X X X Yes Auxiliary Ethernet port (1) N/A N/A X Disabled on 3e- 636L3. Bridged to Plain text port on 3e- 636L2, 3e-636H and 3e-636A Power Yes LED X Yes Reset Pin X Yes The Operational Environment components relied upon by the TOE and not included in the physical boundary are described in Section 1.3.1. 1.4.1.2 Logical Boundaries This section summarizes the security functions provided by CyberFence 3e-636: - Security audit - Cryptographic support - Identification and authentication - Security management - Protection of the TSF - TOE access - Trusted path/channels 1.4.1.2.1 Security audit The TOE generates auditable events for actions on the TOE with the capability of selective audit record generation. The records of these events can be viewed within the TOE Management Interface or they can be exported to audit systems in the Operational Environment. The TOE generates records for its own actions, containing information about the user/process associated with the event, the success or failure of the event, and the time that the event occurred. Additionally, all administrator actions relating to the management of TSF data and configuration data are logged by the TOE’s audit generation functionality. CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 7 of 35 1.4.1.2.2 Cryptographic support The TOE uses NIST SP 800-90 DRBG random bits generator and the following cryptographic algorithms: AES, RSA, ECDSA, SHA, HMAC to secure the trusted channel and trusted path communication. The TOE is designed to zeroize Critical Security Parameters (CSPs) to mitigate the possibility of disclosure or modification. 1.4.1.2.3 Identification and authentication The TOE provides Identification and Authentication security functionality to ensure that all users are properly identified and authenticated before accessing TOE functionality. The TOE enforces a password-based authentication mechanism to perform administrative user authentication. Passwords are obscured when being displayed during any attempted login. Administrative users can be authenticated via either local user database or remote LDAP server. The TOE also authenticates its IPsec peers; the authentication is performed over IKEv2 SA phase of mutual authentication between IPsec peers. 1.4.1.2.4 Security management The Web Management Application of the TOE provides the capabilities for configuration and administration. The Web Management Application can be accessed via the dedicated local Ethernet port configured for “out-of-band” management. There is no local access such as a serial console port. Therefore, the local and remote management is considered the same for this evaluation. An authorized administrator has the ability to modify, edit, and delete security parameters such as audit data, configuration data, and user authentication data. The Web Management Application also offers an authorized administrator the capability to manage how security functions behave. For example an administrator can enable/disable certain audit functions query and set encryption/decryption algorithms used for network packets. 1.4.1.2.5 Protection of the TSF Internal testing of the TOE hardware, software, and software updates against tampering ensures that all security functions are running and available before the TOE accepts any communications. The TSF prevents reading of pre- shared keys, symmetric keys, private keys, and passwords. The TOE uses electronic signature verification before any firmware/software updates are installed. 1.4.1.2.6 TOE access The TOE provides the following TOE Access functionality:  TSF-initiated session termination when a connection (remote or local) is idle for a configurable time period  Administrative termination of own session  TOE Access Banners 1.4.1.2.7 Trusted path/channels The TOE protects interactive communication with administrators using TLS/HTTPS, both integrity and disclosure protection is ensured. The TOE uses IPsec to protect communication with network entities, such as a log server, NTP server and LDAP server. This prevents unintended disclosure or modification of logs and management information. 1.4.2 TOE Documentation  Ultra Electronics 3eTI 636-Series User’s Guide, August 15, 2017, 290000533-002, Revision E (Admin Guide) CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 8 of 35 2. Conformance Claims This TOE is conformant to the following CC specifications:  Common Criteria for Information Technology Security Evaluation Part 2: Security functional components, Version 3.1, Revision 4, September 2012.  Part 2 Extended  Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components, Version 3.1 Revision 4, September 2012.  Part 3 Conformant  Package Claims:  collaborative Protection Profile for Network Devices, Version 1.0, 27 February 2015 (NDcPP10)  Technical Decisions Applied in this ST:  TD0090  TD0116  TD0125  TD0130  TD0154  TD0156  TD0160  TD0224 2.1 Conformance Rationale The ST conforms to the NDcPP10. As explained previously, the security problem definition, security objectives, and security requirements have been drawn from the PP. CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 9 of 35 3. Security Objectives The Security Problem Definition may be found in the NDcPP10 and this section reproduces only the corresponding Security Objectives for operational environment for reader convenience. The NDcPP10 offers additional information about the identified security objectives, but that has not been reproduced here and the NDcPP10 should be consulted if there is interest in that material. In general, the NDcPP10 has defined Security Objectives appropriate for network devices and as such are applicable to the CyberFence 3e-636 Series Network Security Devices TOE. 3.1 Security Objectives for the Operational Environment OE.ADMIN_CREDENTIALS_SECURE The administrator’s credentials (private key) used to access the TOE must be protected on any other platform on which they reside. OE.NO_GENERAL_PURPOSE There are no general-purpose computing capabilities (e.g., compilers or user applications) available on the TOE, other than those services necessary for the operation, administration and support of the TOE. OE.NO_THRU_TRAFFIC_PROTECTION The TOE does not provide any protection of traffic that traverses it. It is assumed that protection of this traffic will be covered by other security and assurance measures in the operational environment. OE.PHYSICAL Physical security, commensurate with the value of the TOE and the data it contains, is provided by the environment. OE.TRUSTED_ADMIN TOE Administrators are trusted to follow and apply all guidance documentation in a trusted manner. OE.UPDATES The TOE firmware and software is updated by an administrator on a regular basis in response to the release of product updates due to known vulnerabilities. CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 10 of 35 4. Extended Components Definition All of the extended requirements in this ST have been drawn from the NDcPP10. The NDcPP10 defines the following extended requirements and since they are not redefined in this ST the NDcPP10 should be consulted for more information in regard to those CC extensions. Extended SFRs: - FAU_STG_EXT.1: Protected Audit Event Storage - FCS_HTTPS_EXT.1: HTTPS Protocol - FCS_IPSEC_EXT.1: IPsec Protocol - FCS_RBG_EXT.1: Random Bit Generation - FCS_TLSS_EXT.1: TLS Server Protocol - FIA_PMG_EXT.1: Password Management - FIA_UAU_EXT.2: Password-based Authentication Mechanism - FIA_UIA_EXT.1: User Identification and Authentication - FIA_X509_EXT.1: X.509 Certificate Validation - FIA_X509_EXT.2: X.509 Certificate Authentication - FIA_X509_EXT.3: X.509 Certificate Requests - FPT_APW_EXT.1: Protection of Administrator Passwords - FPT_SKP_EXT.1: Protection of TSF Data (for reading of all symmetric keys) - FPT_TST_EXT.1: TSF testing - FPT_TUD_EXT.1: Trusted update - FTA_SSL_EXT.1: TSF-initiated Session Locking CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 11 of 35 5. Security Requirements This section defines the Security Functional Requirements (SFRs) and Security Assurance Requirements (SARs) that serve to represent the security functional claims for the Target of Evaluation (TOE) and to scope the evaluation effort. The SFRs have all been drawn from the NDcPP10. The refinements and operations already performed in the NDcPP10 are not identified (e.g., highlighted) here, rather the requirements have been copied from the NDcPP10 and any residual operations have been completed herein. Of particular note, the NDcPP10 made a number of refinements and completed some of the SFR operations defined in the Common Criteria (CC) and that PP should be consulted to identify those changes if necessary. The SARs are also drawn from the NDcPP10 which includes all the SARs for EAL 1. However, the SARs are effectively refined since requirement-specific 'Assurance Activities' are defined in the NDcPP10 that serve to ensure corresponding evaluations will yield more practical and consistent assurance than the EAL 1 assurance requirements alone. The NDcPP10 should be consulted for the assurance activity definitions. 5.1 TOE Security Functional Requirements The following table identifies the SFRs that are satisfied by CyberFence 3e-636 Series Network Security Devices TOE. Requirement Class Requirement Component FAU: Security audit FAU_GEN.1: Audit Data Generation FAU_GEN.2: User identity association FAU_STG_EXT.1: Protected Audit Event Storage FCS: Cryptographic FCS_CKM.1: Cryptographic Key Generation support FCS_CKM.2: Cryptographic Key Establishment FCS_CKM.4: Cryptographic Key Destruction FCS_COP.1(1): Cryptographic Operation (AES Data Encryption/Decryption) FCS_COP.1(2): Cryptographic Operation (Signature Generation and Verification) FCS_COP.1(3): Cryptographic Operation (Hash Algorithm) FCS_COP.1(4): Cryptographic Operation (Keyed Hash Algorithm) FCS_HTTPS_EXT.1: HTTPS Protocol FCS_IPSEC_EXT.1: IPsec Protocol FCS_RBG_EXT.1: Random Bit Generation FCS_TLSS_EXT.1: TLS Server Protocol FIA: Identification and FIA_PMG_EXT.1: Password Management authentication FIA_UAU.7: Protected Authentication Feedback FIA_UAU_EXT.2: Password-based Authentication Mechanism FIA_UIA_EXT.1: User Identification and Authentication FIA_X509_EXT.1: X.509 Certificate Validation FIA_X509_EXT.2: X.509 Certificate Authentication FIA_X509_EXT.3: X.509 Certificate Requests FMT: Security management FMT_MOF.1(1): Management of security functions behavior - Trusted Update FMT_MTD.1(1): Management of TSF Data FMT_SMF.1: Specification of Management Functions FMT_SMR.2: Restrictions on Security Roles FPT: Protection of the FPT_APW_EXT.1: Protection of Administrator Passwords TSF FPT_SKP_EXT.1: Protection of TSF Data (for reading of all symmetric keys) CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 12 of 35 FPT_STM.1: Reliable Time Stamps FPT_TST_EXT.1: TSF testing FPT_TUD_EXT.1: Trusted update FTA: TOE access FTA_SSL.3: TSF-initiated Termination FTA_SSL.4: User-initiated Termination FTA_SSL_EXT.1: TSF-initiated Session Locking FTA_TAB.1: Default TOE Access Banners FTP: Trusted FTP_ITC.1: Inter-TSF trusted channel path/channels FTP_TRP.1: Trusted Path Table 1 TOE Security Functional Components 5.1.1 Security audit (FAU) 5.1.1.1 Audit Data Generation (FAU_GEN.1) FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events: a) Start-up and shut-down of the audit functions; b) All auditable events for the not specified level of audit; and c) All administrative actions comprising: - Administrative login and logout (name of user account shall be logged if individual user accounts are required for administrators). - Security related configuration changes (in addition to the information that a change occurred it shall be logged what has been changed). - Generating/import of, changing, or deleting of cryptographic keys (in addition to the action itself a unique key name or key reference shall be logged). - Resetting passwords (name of related user account shall be logged). - Starting and stopping services (if applicable). - [no other actions]; d) Specifically defined auditable events listed in Table 1. Requirement Auditable Events Additional Content FAU_GEN.1 FAU_GEN.2 FAU_STG_EXT.1 FCS_CKM.1 FCS_CKM.2 FCS_CKM.4 FCS_COP.1(1) FCS_COP.1(2) FCS_COP.1(3) FCS_COP.1(4) FCS_HTTPS_EXT.1 Failure to establish a HTTPS Session. Reason for failure. FCS_IPSEC_EXT.1 Failure to establish an IPsec SA. Reason for failure. FCS_RBG_EXT.1 FCS_TLSS_EXT.1 Failure to establish a TLS Session. Reason for failure. FIA_PMG_EXT.1 FIA_UAU.7 FIA_UAU_EXT.2 All use of identification and authentication mechanism. Origin of the attempt (e.g., IP address). CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 13 of 35 FIA_UIA_EXT.1 All use of identification and authentication mechanism. Provided user identity, origin of the attempt (e.g., IP address). FIA_X509_EXT.1 Unsuccessful attempt to validate a certificate. Reason for failure. FIA_X509_EXT.2 FIA_X509_EXT.3 FMT_MOF.1(1) Any attempt to initiate a manual update. FMT_MTD.1(1) All management activities of TSF data. FMT_SMF.1 FMT_SMR.2 FPT_APW_EXT.1 FPT_SKP_EXT.1 FPT_STM.1 Changes to time. The old and new values for the time. Origin of the attempt to change time for success and failure (e.g., IP address). FPT_TST_EXT.1 FPT_TUD_EXT.1 Initiation of update; result of the update attempt (success or failure). FTA_SSL.3 The termination of a remote session by the session locking mechanism. FTA_SSL.4 The termination of an interactive session. FTA_SSL_EXT.1 Any attempts at unlocking of an interactive session. FTA_TAB.1 FTP_ITC.1 Initiation of the trusted channel. Termination of the trusted channel. Failure of the trusted channel functions. Identification of the initiator and target of failed trusted channels establishment attempt. FTP_TRP.1 Initiation of the trusted path. Termination of the trusted path. Failure of the trusted path functions. Identification of the claimed user identity. FAU_GEN.1.2 The TSF shall record within each audit record at least the following information: a) Date and time of the event, type of event, subject identity, and the outcome (success or failure) of the event; and b) For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST, information specified in column three of Table 1. 5.1.1.2 User identity association (FAU_GEN.2) FAU_GEN.2.1 For audit events resulting from actions of identified users, the TSF shall be able to associate each auditable event with the identity of the user that caused the event. 5.1.1.3 Protected Audit Event Storage (FAU_STG_EXT.1) FAU_STG_EXT.1.1 The TSF shall be able to transmit the generated audit data to an external IT entity using a trusted channel according to FTP_ITC.1. FAU_STG_EXT.1.2 The TSF shall be able to store generated audit data on the TOE itself. FAU_STG_EXT.1.3 The TSF shall [overwrite previous audit records according to the following rule: [when allotted space has reached its threshold]] when the local storage space for audit data is full. CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 14 of 35 5.1.2 Cryptographic support (FCS) 5.1.2.1 Cryptographic Key Generation (FCS_CKM.1) FCS_CKM.1.1 The TSF shall generate asymmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm: [ - RSA schemes using cryptographic key sizes of 2048-bit or greater that meet the following: FIPS PUB 186-4, 'Digital Signature Standard (DSS)', Appendix B.3, - ECC schemes using 'NIST curves' [P-256, P-384, P-521] that meet the following: FIPS PUB 186-4, 'Digital Signature Standard (DSS)', Appendix B.4, - FFC schemes using cryptographic key sizes of 2048-bit or greater that meet the following: FIPS PUB 186-4, 'Digital Signature Standard (DSS)', Appendix B.1]. 5.1.2.2 Cryptographic Key Establishment (FCS_CKM.2) FCS_CKM.2.1 The TSF shall perform cryptographic key establishment in accordance with a specified cryptographic key establishment method: [ - RSA-based key establishment schemes that meets the following: NIST Special Publication 800-56B, 'Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography', - Elliptic curve-based key establishment schemes that meets the following: NIST Special Publication 800-56A, 'Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography', - Finite field-based key establishment schemes that meets the following: NIST Special Publication 800-56A, 'Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography']. 5.1.2.3 Cryptographic Key Destruction (FCS_CKM.4) FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method  For plaintext keys in volatile storage, the destruction shall be executed by a [single overwrite consisting of [zeroes]];  For plaintext keys in non-volatile storage, the destruction shall be executed by the invocation of an interface provided by a part of the TSF that [o logically addresses the storage location of the key and performs a [[single] -pass] overwrite consisting of [a new value of the key]] that meets the following: No Standard. (TD0130 applied) 5.1.2.4 Cryptographic Operation (AES Data Encryption/Decryption) (FCS_COP.1(1)) FCS_COP.1(1).1 The TSF shall perform encryption/decryption in accordance with a specified cryptographic algorithm AES used in [CBC, GCM] mode and cryptographic key sizes [128 bits, 256 bits] that meet the following: AES as specified in ISO 18033-3, [CBC as specified in ISO 10116, GCM as specified in ISO 19772]. 5.1.2.5 Cryptographic Operation (Signature Generation and Verification) (FCS_COP.1(2)) FCS_COP.1(2).1 The TSF shall perform cryptographic signature services (generation and verification) in accordance with a specified cryptographic algorithm [ - RSA Digital Signature Algorithm and cryptographic key sizes (modulus) [2048 bits], - Elliptic Curve Digital Signature Algorithm and cryptographic key sizes [256 bits]] that meet CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 15 of 35 the following: [- For RSA schemes: FIPS PUB 186-4, 'Digital Signature Standard (DSS)', Section 5.5, using PKCS #1 v2.1 Signature Schemes RSASSA-PSS and/or RSASSAPKCS1v1_5, ISO/IEC 9796-2, Digital signature scheme 2 or Digital Signature scheme 3 (TD0116 applied), - For ECDSA schemes: FIPS PUB 186-4, 'Digital Signature Standard (DSS)', Section 6 and Appendix D, Implementing 'NIST curves' P-256, P-384, and [P-521] , ISO/IEC 14888-3, Section 6.4]. 5.1.2.6 Cryptographic Operation (Hash Algorithm) (FCS_COP.1(3)) FCS_COP.1(3).1 The TSF shall perform cryptographic hashing services in accordance with a specified cryptographic algorithm [SHA-1, SHA-256, SHA-384, SHA-512] that meet the following: ISO/IEC 10118-3:2004. 5.1.2.7 Cryptographic Operation (Keyed Hash Algorithm) (FCS_COP.1(4)) FCS_COP.1(4).1 The TSF shall perform keyed-hash message authentication in accordance with a specified cryptographic algorithm [HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA- 512] and cryptographic key sizes [160, 256, 384, 512] and message digest sizes [160, 256, 384, 512] bits that meet the following: ISO/IEC 9797-2:2011, Section 7 'MAC Algorithm 2'. 5.1.2.8 HTTPS Protocol (FCS_HTTPS_EXT.1) FCS_HTTPS_EXT.1.1 The TSF shall implement the HTTPS protocol that complies with RFC 2818. FCS_HTTPS_EXT.1.2 The TSF shall implement HTTPS using TLS. FCS_HTTPS_EXT.1.3 The TSF shall establish the connection only if [the peer initiates handshake]. (TD0125 applied) 5.1.2.9 IPsec Protocol (FCS_IPSEC_EXT.1) FCS_IPSEC_EXT.1.1 The TSF shall implement the IPsec architecture as specified in RFC 4301. FCS_IPSEC_EXT.1.2 The TSF shall have a nominal, final entry in the SPD that matches anything that is otherwise unmatched, and discards it. FCS_IPSEC_EXT.1.3 The TSF shall implement [transport mode, tunnel mode]. (TD0160 applied) FCS_IPSEC_EXT.1.4 The TSF shall implement the IPsec protocol ESP as defined by RFC 4303 using the cryptographic algorithms AES-CBC-128, AES-CBC-256 (both specified by RFC 3602) and [AES-GCM-128 (specified in RFC 4106), AES-GCM-256 (specified in RFC 4106)] together with a Secure Hash Algorithm (SHA)-based HMAC. FCS_IPSEC_EXT.1.5 The TSF shall implement the protocol: [- IKEv2 as defined in RFC 5996 and [with mandatory support for NAT traversal as specified in RFC 5996, section 2.23], and [no other RFCs for hash functions]]. FCS_IPSEC_EXT.1.6 The TSF shall ensure the encrypted payload in the [IKEv2] protocol uses the cryptographic algorithms AES-CBC-128, AES-CBC-256 as specified in RFC 3602 and [AES-GCM-128, AES- GCM-256 as specified in RFC 5282]. FCS_IPSEC_EXT.1.7 The TSF shall ensure that [- IKEv2 SA lifetimes can be configured by an Security Administrator based on [o length of time, where the time values can configured within [24] hours]]. CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 16 of 35 FCS_IPSEC_EXT.1.8 The TSF shall ensure that [- IKEv2 Child SA lifetimes can be configured by a Security Administrator based on [o number of bytes, o length of time, where the time values can be configured within [8] hours]]. FCS_IPSEC_EXT.1.9 The TSF shall generate the secret value x used in the IKE Diffie-Hellman key exchange ('x' in g^x mod p) using the random bit generator specified in FCS_RBG_EXT.1, and having a length of at least [112 (for DH Group 14), 128 (for group 19), 192 (for group 20) ] bits. FCS_IPSEC_EXT.1.10 The TSF shall generate nonces used in [IKEv2] exchanges of length [- [112 (for DH Group 14), 128 (for group 19), 192 (for group 20) ]]. FCS_IPSEC_EXT.1.11 The TSF shall ensure that IKE protocols implement DH Groups(s) [14 (2048-bit MODP), 19 (256-bit Random ECP), 20 (384-bit Random ECP)]. (TD0224 applied) FCS_IPSEC_EXT.1.12 The TSF shall be able to ensure by default that the strength of the symmetric algorithm (in terms of the number of bits in the key) negotiated to protect the [IKEv2 IKE_SA] connection is greater than or equal to the strength of the symmetric algorithm (in terms of the number of bits in the key) negotiated to protect the [IKEv2 CHILD_SA] connection. FCS_IPSEC_EXT.1.13 The TSF shall ensure that all IKE protocols perform peer authentication using [RSA, ECDSA] that use X.509v3 certificates that conform to RFC 4945 and [Pre-shared Keys]. FCS_IPSEC_EXT.1.14 The TSF shall only establish a trusted channel to peers with valid certificates. 5.1.2.10 Random Bit Generation (FCS_RBG_EXT.1) FCS_RBG_EXT.1.1 The TSF shall perform all deterministic random bit generation services in accordance with ISO/IEC 18031:2011 using [CTR_DRBG (AES)]. FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded by at least one entropy source that accumulates entropy from [[a single] hardware-based noise source] with a minimum of [256 bits] of entropy at least equal to the greatest security strength, according to ISO/IEC 18031:2011 Table C.1 'Security Strength Table for Hash Functions', of the keys and hashes that it will generate. 5.1.2.11 TLS Server Protocol (FCS_TLSS_EXT.1) FCS_TLSS_EXT.1.1 The TSF shall implement [TLS 1.2 (RFC 5246), TLS 1.1 (RFC 4346)] supporting the following ciphersuites: Mandatory Ciphersuites: - TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268 Optional Ciphersuites: [- TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268, - TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268, - TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268, - TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246, - TLS_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246, - TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 as defined in RFC 5246, - TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246]. FCS_TLSS_EXT.1.2 The TSF shall deny connections from clients requesting SSL 2.0, SSL 3.0, TLS 1.0, and [none]. (TD0156 applied) CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 17 of 35 FCS_TLSS_EXT.1.3 The TSF shall generate key establishment parameters using RSA with key size 2048 bits and [no other size] and [Diffie-Hellman parameters of size 2048 bits and [no other size]]. 5.1.3 Identification and authentication (FIA) 5.1.3.1 Password Management (FIA_PMG_EXT.1) FIA_PMG_EXT.1.1 The TSF shall provide the following password management capabilities for administrative passwords: a) Passwords shall be able to be composed of any combination of upper and lower case letters, numbers, and the following special characters: ['!', '@', '#', '$', '%', '^', '&', '*', '(', ')', ['+'. '-', '_']] ; b) Minimum password length shall be settable by the Security Administrator, and shall support passwords of 15 characters or greater. 5.1.3.2 Protected Authentication Feedback (FIA_UAU.7) FIA_UAU.7.1 The TSF shall provide only obscured feedback to the administrative user while the authentication is in progress at the local console. 5.1.3.3 Password-based Authentication Mechanism (FIA_UAU_EXT.2) FIA_UAU_EXT.2.1 The TSF shall provide a local password-based authentication mechanism, [[remote password- based authentication mechanism]] to perform administrative user authentication. 5.1.3.4 User Identification and Authentication (FIA_UIA_EXT.1) FIA_UIA_EXT.1.1 The TSF shall allow the following actions prior to requiring the non-TOE entity to initiate the identification and authentication process: - Display the warning banner in accordance with FTA_TAB.1; - [allow network packets configured by the administrator to flow through the TOE] FIA_UIA_EXT.1.2 The TSF shall require each administrative user to be successfully identified and authenticated before allowing any other TSF-mediated actions on behalf of that administrative user. 5.1.3.5 X.509 Certificate Validation (FIA_X509_EXT.1) FIA_X509_EXT.1.1 The TSF shall validate certificates in accordance with the following rules: - RFC 5280 certificate validation and certificate path validation. - The certificate path must terminate with a trusted CA certificate. - The TSF shall validate a certificate path by ensuring the presence of the basicConstraints extension and that the CA flag is set to TRUE for all CA certificates. - The TSF shall validate the revocation status of the certificate using [a Certificate Revocation List (CRL) as specified in RFC 5280 Section 6.3]. - The TSF shall validate the extendedKeyUsage field according to the following rules: o Certificates used for trusted updates and executable code integrity verification shall have the Code Signing purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3) in the extendedKeyUsage field. o Server certificates presented for TLS shall have the Server Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field. CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 18 of 35 o Client certificates presented for TLS shall have the Client Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field. FIA_X509_EXT.1.2 The TSF shall only treat a certificate as a CA certificate if the basicConstraints extension is present and the CA flag is set to TRUE. 5.1.3.6 X.509 Certificate Authentication (FIA_X509_EXT.2) FIA_X509_EXT.2.1 The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for [IPsec, TLS, HTTPS], and [no additional uses]. FIA_X509_EXT.2.2 When the TSF cannot establish a connection to determine the validity of a certificate, the TSF shall [accept the certificate]. 5.1.3.7 X.509 Certificate Requests (FIA_X509_EXT.3) FIA_X509_EXT.3.1 The TSF shall generate a Certificate Request Message as specified by RFC 2986 and be able to provide the following information in the request: public key and [Common Name, Organization, Country]. FIA_X509_EXT.3.2 The TSF shall validate the chain of certificates from the Root CA upon receiving the CA Certificate Response. 5.1.4 Security management (FMT) 5.1.4.1 Management of security functions behavior - Trusted Update (FMT_MOF.1(1)) FMT_MOF.1(1).1 The TSF shall restrict the ability to enable the functions to perform manual update to Security Administrators. 5.1.4.2 Management of TSF Data (FMT_MTD.1(1)) FMT_MTD.1(1).1 The TSF shall restrict the ability to manage the TSF data to Security Administrators. 5.1.4.3 Specification of Management Functions (FMT_SMF.1) FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: - Ability to administer the TOE locally and remotely; - Ability to configure the access banner; - Ability to configure the session inactivity time before session termination or locking; - Ability to update the TOE, and to verify the updates using [digital signature] capability prior to installing those updates (Per TD0090); - [o Ability to configure audit behavior, o Ability to configure the cryptographic functionality]. 5.1.4.4 Restrictions on Security Roles (FMT_SMR.2) FMT_SMR.2.1 The TSF shall maintain the roles: - Security Administrator. FMT_SMR.2.2 The TSF shall be able to associate users with roles. CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 19 of 35 FMT_SMR.2.3 The TSF shall ensure that the conditions - The Security Administrator role shall be able to administer the TOE locally; - The Security Administrator role shall be able to administer the TOE remotely are satisfied. 5.1.5 Protection of the TSF (FPT) 5.1.5.1 Protection of Administrator Passwords (FPT_APW_EXT.1) FPT_APW_EXT.1.1 The TSF shall store passwords in non-plaintext form. FPT_APW_EXT.1.2 The TSF shall prevent the reading of plaintext passwords 5.1.5.2 Protection of TSF Data (for reading of all symmetric keys) (FPT_SKP_EXT.1) FPT_SKP_EXT.1.1 The TSF shall prevent reading of all pre-shared keys, symmetric keys, and private keys. 5.1.5.3 Reliable Time Stamps (FPT_STM.1) FPT_STM.1.1 The TSF shall be able to provide reliable time stamps. 5.1.5.4 TSF testing (FPT_TST_EXT.1) FPT_TST_EXT.1.1 The TSF shall run a suite of the following self-tests [during initial start-up (on power on)] to demonstrate the correct operation of the TSF: [Software integrity test, AES Known Answer Test, SHA Known Answer Test, HMAC Known Answer Test, DRBG Known Answer Test, RSA Known Answer Test, ECDSA Known Answer Test,]. 5.1.5.5 Trusted update (FPT_TUD_EXT.1) FPT_TUD_EXT.1.1 The TSF shall provide Security Administrators the ability to query the currently executing version of the TOE firmware/software and [no other TOE firmware/software version]. (TD0154 applied) FPT_TUD_EXT.1.2 The TSF shall provide Security Administrators the ability to manually initiate updates to TOE firmware/software and [no other update mechanism]. FPT_TUD_EXT.1.3 The TSF shall provide means to authenticate firmware/software updates to the TOE using a [digital signature mechanism] prior to installing those updates. 5.1.6 TOE access (FTA) 5.1.6.1 TSF-initiated Termination (FTA_SSL.3) FTA_SSL.3.1 Refinement: The TSF shall terminate a remote interactive session after a Security Administrator- configurable time interval of session inactivity. CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 20 of 35 5.1.6.2 User-initiated Termination (FTA_SSL.4) FTA_SSL.4.1 Refinement: The TSF shall allow Administrator-initiated termination of the Administrator's own interactive session. 5.1.6.3 TSF-initiated Session Locking (FTA_SSL_EXT.1) FTA_SSL_EXT.1.1 The TSF shall, for local interactive sessions, [- terminate the session] after a Security Administrator-specified time period of inactivity. 5.1.6.4 Default TOE Access Banners (FTA_TAB.1) FTA_TAB.1.1 Refinement: Before establishing an administrative user session the TSF shall display a Security Administrator-specified advisory notice and consent warning message regarding use of the TOE. 5.1.7 Trusted path/channels (FTP) 5.1.7.1 Inter-TSF trusted channel (FTP_ITC.1) FTP_ITC.1.1 The TSF shall be capable of using [IPsec] to provide a trusted communication channel between itself and authorized IT entities supporting the following capabilities: audit server, [[accessing an NTP server]] that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from disclosure and detection of modification of the channel data. FTP_ITC.1.2 The TSF shall permit the TSF, or the authorized IT entities to initiate communication via the trusted channel. FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for [audit logging, and accessing an NTP server]. 5.1.7.2 Trusted Path (FTP_TRP.1) FTP_TRP.1.1 The TSF shall be capable of using [TLS, HTTPS] to provide a communication path between itself and authorized remote administrators that is logically distinct from other communication paths and provides assured identification of its end points and protection of the communicated data from disclosure and provides detection of modification of the channel data. FTP_TRP.1.2 The TSF shall permit remote administrators to initiate communication via the trusted path. FTP_TRP.1.3 The TSF shall require the use of the trusted path for initial administrator authentication and all remote administration actions. 5.2 TOE Security Assurance Requirements The SARs for the TOE are the components as specified in Part 3 of the Common Criteria. Note that the SARs have effectively been refined with the assurance activities explicitly defined in association with both the SFRs and SARs. Requirement Class Requirement Component ADV: Development ADV_FSP.1: Basic functional specification CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 21 of 35 AGD: Guidance documents AGD_OPE.1: Operational user guidance AGD_PRE.1: Preparative procedures ALC: Life-cycle support ALC_CMC.1: Labelling of the TOE ALC_CMS.1: TOE CM coverage ASE: Security Target ASE_TSS.1: Security Target ATE: Tests ATE_IND.1: Independent testing - conformance AVA: Vulnerability assessment AVA_VAN.1: Vulnerability survey Table 2 Assurance Components 5.2.1 Development (ADV) 5.2.1.1 Basic functional specification (ADV_FSP.1) ADV_FSP.1.1d The developer shall provide a functional specification. ADV_FSP.1.2d The developer shall provide a tracing from the functional specification to the SFRs. ADV_FSP.1.1c The functional specification shall describe the purpose and method of use for each SFR-enforcing and SFR-supporting TSFI. ADV_FSP.1.2c The functional specification shall identify all parameters associated with each SFR-enforcing and SFR-supporting TSFI. ADV_FSP.1.3c The functional specification shall provide rationale for the implicit categorisation of interfaces as SFR-non-interfering. ADV_FSP.1.4c The tracing shall demonstrate that the SFRs trace to TSFIs in the functional specification. ADV_FSP.1.1e The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ADV_FSP.1.2e The evaluator shall determine that the functional specification is an accurate and complete instantiation of the SFRs. 5.2.2 Guidance documents (AGD) 5.2.2.1 Operational user guidance (AGD_OPE.1) AGD_OPE.1.1d The developer shall provide operational user guidance. AGD_OPE.1.1c The operational user guidance shall describe, for each user role, the user-accessible functions and privileges that should be controlled in a secure processing environment, including appropriate warnings. AGD_OPE.1.2c The operational user guidance shall describe, for each user role, how to use the available interfaces provided by the TOE in a secure manner. AGD_OPE.1.3c The operational user guidance shall describe, for each user role, the available functions and interfaces, in particular all security parameters under the control of the user, indicating secure values as appropriate. CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 22 of 35 AGD_OPE.1.4c The operational user guidance shall, for each user role, clearly present each type of security- relevant event relative to the user-accessible functions that need to be performed, including changing the security characteristics of entities under the control of the TSF. AGD_OPE.1.5c The operational user guidance shall identify all possible modes of operation of the TOE (including operation following failure or operational error), their consequences and implications for maintaining secure operation. AGD_OPE.1.6c The operational user guidance shall, for each user role, describe the security measures to be followed in order to fulfil the security objectives for the operational environment as described in the ST. AGD_OPE.1.7c The operational user guidance shall be clear and reasonable. AGD_OPE.1.1e The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. 5.2.2.2 Preparative procedures (AGD_PRE.1) AGD_PRE.1.1d The developer shall provide the TOE including its preparative procedures. AGD_PRE.1.1c The preparative procedures shall describe all the steps necessary for secure acceptance of the delivered TOE in accordance with the developer's delivery procedures. AGD_PRE.1.2c The preparative procedures shall describe all the steps necessary for secure installation of the TOE and for the secure preparation of the operational environment in accordance with the security objectives for the operational environment as described in the ST. AGD_PRE.1.1e The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. AGD_PRE.1.2e The evaluator shall apply the preparative procedures to confirm that the TOE can be prepared securely for operation. 5.2.3 Life-cycle support (ALC) 5.2.3.1 Labelling of the TOE (ALC_CMC.1) ALC_CMC.1.1d The developer shall provide the TOE and a reference for the TOE. ALC_CMC.1.1c The TOE shall be labelled with its unique reference. ALC_CMC.1.1e The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. 5.2.3.2 TOE CM coverage (ALC_CMS.1) ALC_CMS.1.1d The developer shall provide a configuration list for the TOE. ALC_CMS.1.1c The configuration list shall include the following: the TOE itself; and the evaluation evidence required by the SARs. CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 23 of 35 ALC_CMS.1.2c The configuration list shall uniquely identify the configuration items. ALC_CMS.1.1e The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. 5.2.4 Security Target (ASE) 5.2.4.1 Security Target (ASE_TSS.1) ASE_TSS.1.1c Refinement: The TOE summary specification shall describe how the TOE meets each SFR. In the case of entropy analysis the TSS is used in conjunction with required supplementary information on Entropy. 5.2.5 Tests (ATE) 5.2.5.1 Independent testing - conformance (ATE_IND.1) ATE_IND.1.1d The developer shall provide the TOE for testing. ATE_IND.1.1c The TOE shall be suitable for testing. ATE_IND.1.1e The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ATE_IND.1.2e The evaluator shall test a subset of the TSF to confirm that the TSF operates as specified. 5.2.6 Vulnerability assessment (AVA) 5.2.6.1 Vulnerability survey (AVA_VAN.1) AVA_VAN.1.1d The developer shall provide the TOE for testing. AVA_VAN.1.1c The TOE shall be suitable for testing. AVA_VAN.1.1e The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. AVA_VAN.1.2e The evaluator shall perform a search of public domain sources to identify potential vulnerabilities in the TOE. AVA_VAN.1.3e The evaluator shall conduct penetration testing, based on the identified potential vulnerabilities, to determine that the TOE is resistant to attacks performed by an attacker possessing Basic attack potential. CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 24 of 35 6. TOE Summary Specification This chapter describes the security functions: - Security audit - Cryptographic support - Identification and authentication - Security management - Protection of the TSF - TOE access - Trusted path/channels 6.1 Security audit The Security audit function is designed to satisfy the following security functional requirements: FAU_GEN.1: The TOE is designed to be able to generate log records for a wide range of security relevant and other events as they occur. The events that can cause an audit record to be logged include starting and stopping the audit function, Security Administrator’s configuration of CSPs and security functions as well as all of the events identified in Error! Reference source not found.. The TOE generates records for several separate classes of events: authentication/access to the system, actions taken directly on the system by network clients, and management of security functions by authorized administrators. All audit records include the date/time of the event, the identity associated with the event (such as the service, computer or user), the success/failure of the event and a definition of the event (by code or explanation). FAU_GEN.2: All actions performed by the TOE are associated with a unique identifier, this information is maintained in the audit record, allowing the events stored there to be traced directly to the user or system for which they were performed. FAU_STG_EXT.1: The TOE stores audit logs locally with up to a fixed size of 256K bytes. The Security Administrator can configure the TOE to send email alert upon the audit logs reaching a configurable percentage of the fixed size. Local password based authentication and authorization limits the access to the local audit log records. Only the Security Administrator can gain access to the local audit log records. When the TOE is configured to export audit logs to an external SYSLOG server, it simultaneously sends the message to the server and local store. The TOE requires the external audit server and itself to be connected via an IPsec session. The User’s Guide provides details about the “Export Audit Logs” configuration. The TOE exports audit data over IPsec using AES128/256 bit encryption. Disconnection to external entities such as syslog server will result in log of communication error and attempt to re-establish secure channel. At no point, will plaintext be transmitted. The TOE does not implement an automatic synchronization mechanism between the local and remote audit storage. When the audit log storage space is full, the TOE also provides the Authorized Administrator the option of overwriting “old” audit records rather than preventing auditable events. 6.2 Cryptographic support There are two cryptographic engines within the TOE models as shown in the figure below. All models share the same hardware MPC8378E cryptographic core and OpenSSL library. CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 25 of 35 Figure 6-1: TOE Cryptographic Cores MPC8378E Crypto Core Kernel Space IPSec ESP Data Encryption/ Decryption Driver 3eTI OpenSSL Library HTTPS/TLS Process IPSec Control Process -SA authentication -IKEv2 key derivation First is the 3eTI’s own OpenSSL library. 3eTI’s OpenSSL Library serves as the sole user application level cryptographic library. It provides the FCS_COP functions listed below. All user level applications, such as HTTPS/TLS Web UI, IPsec SA authentication module use this library. 3eTI’s OpenSSL provides the following cryptographic algorithms in FIPS mode: AES, RSA, HMAC, SHS, ECDSA, DH, DRBG The 3eTI OpenSSL Library represents not the entire OpenSSL Library, but the FIPS Object Module that is compiled into the larger OpenSSL Library. Because 3eTI has already compiled the FIPS Object Module and then links that same, identical Object Module into different versions of the larger OpenSSL library, the version of the larger OpenSSL Library is not relevant. There is a FreeScale MPC8378E cryptographic core within the TOE as well. It provides cryptographic function for the Linux kernel drivers. IPsec ESP data encryption/decryption using AES-CBC with SHS or AES-GCM is provided by this engine. The MPC8378E cryptographic core provides the following cryptographic algorithms in FIPS mode: AES (CBC, GCM). HMAC , SHS. CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 26 of 35 The TOE utilizes version 2.0 of its OpenSSL Algorithm Implementation and version 1.0 of the MPC8378E cryptographic core in version 5.1.300 of the TOE. Table 6-1: TOE FIPS-140 Tested Algorithms Algorithm Cert No. SFR Mapping 3eTI OpenSSL AES (CBC, 128, 256 bits key) 2060 FCS_COP.1(1) CVL KAS FFC/ECC 1357 FCS_CKM.2(1) DSA, KeyPairGen 1255 FCS_CKM.1(1) ECDSA PKG/PKV/SigGen/SigVer P256/384/521 415 303 FCS_COP.1(2) FCS_CKM.1(1) SHS 1801 FCS_COP.1(3) HMAC 1253 FCS_COP.1(4) RSA key generation 2568 FCS_CKM.1(1) RSA sign/verify 1491 FCS_COP.1(2) DRBG NIST SP800-90 with one independent hardware based noise source of 256 bits of non-deterministic 822 FCS_RBG_EXT.1 MPC8378E Cryptographic Core AES (CBC) 2078 FCS_COP.1(1) AES (GCM) 2105 FCS_COP.1(1) HMAC 1259 FCS_COP.1(4) SHS 1807 FCS_COP.1(3) FCS_CKM.1: The TOE support both RSA and ECDSA key generation. The key generation is used by the TOE when it creates a Certificate Signing Request (CSR) to apply for a certificate from the Certificate Authority (CA). The TOE enforces the key size of 2048 or greater for RSA key pairs and supports NIST curves P256, P384 and P512 for ECDSA key pairs. FCS_CKM.2 The TOE acts as both receiver and sender for RSA-based key establishment and ECDSA based key establishment in cryptographic operations. FCS_CKM.4: Table 6- below lists all the keys and CSPs used and managed by the TOE. Table 6-2: TOE CSPs Use and Management Non-Protocol Keys/CSPs Key/CSP Type Generation/ Input Output Storage Zeroization Use Operator passwords ASCII string Input encrypted (using TLS session key) Not output PKCS5 hash in flash Zeroized when reset to factory settings. Used to authenticate Security Admin and Admin role operators Firmware verification key ECDSA public key Embedded in firmware at compile time. Not output Plaintext in flash Zeroized when firmware is Used for firmware digital CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 27 of 35 Firmware upgrade is through encrypted (using TLS session key) upgraded. signature verification RBG Keys/CSPs Key/CSP Type Generation/ Input Output Storage Zeroization Use DRBG CTR V 32-byte value 32 bytes from /dev/random file, /dev/random is populated by hardware noise generator Not output Plaintext in RAM Zeroized every time a new random number is generated using the FIPS DRBG after it is used. Used as CTR V value for FIPS DRBG. DRBG CTR Key 32-byte value 32 bytes from /dev/random file, /dev/random is populated by hardware noise generator Not output Plaintext in RAM Zeroized every time a new random number is generated using the FIPS DRBG after it is used. Used as CTR key for FIPS DRBG. RFC 2818 HTTPS Keys/CSPs Key/CSP Type Generation/ Input Output Storage Zeroization Use RSA private key RSA (2048) (key wrapping; key establishment methodology provides 112- bits of encryption strength) Not input (installed at factory) Not output Plaintext in flash Zeroized when new private key is uploaded Used to support Security Admin and Admin TLS/HTTPS interfaces. TLS session key for encryption AES (128/256) Not input, derived using TLS protocol Not output Plaintext in RAM Zeroized when a page of the web GUI is served after it is used. Used to protect TLS/HTTPS session. Public Security Parameter HTTPS Public certificate RSA (2048) Input encrypted (using TLS session key) D During TLS session setup Used to setup TLS session for TLS/HTTPS HTTPS root certificate RSA (2048) Input encrypted (using TLS session key) Not output Used to setup TLS session for TLS/HTTPS IPsec Keys DH Private Key 2048 bits private key Generated Not output Plaintext in RAM Zeroized when no longer used IKE v2 SA setup CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 28 of 35 ECCDH Private Key 256,384,521 bits Generated Not output Plaintext in RAM and encrypted in FLASH RAM copy zeroized when no longer used IKE v2 SA setup IPSec SA Authenticatio n certificate private key RSA (2048, 4096), ECDSA (256,384,512) Input encrypted using TLS session key Not output Plaintext in RAM and encrypted in FLASH RAM copy zeroized when no longer used IKE v2 SA authentication IPSec SA private key password Text string Input encrypted using TLS session key Not output Plaintext in RAM and encrypted in FLASH Zeroized when no longer used Encrypt the IPSec SA certificate private key IPSec SA session key Derived from DH/ECCDH key exchange Not input Not output Plaintext in RAM Zeroized when no longer used Encrypt and Authenticate SA_Auth messages of IKE v2 IPSec ESP symmetric Data encryption key AES, AES_GCM (128, 256) Not input (derived from SA setup) Not output Plaintext in RAM Zeroized when child SA lifetime expired Encrypt IPSec ESP data The zeroization technique is to write all 0xa5, then 0x5a, 0xff and finally all zeros to the memory location where the key is stored. A read-verify is performed after the zeroization. The same zeroization technique is applied to flash. The TOE does not store keys in EEPROM. FCS_COP.1(1): AES is implemented with key sizes of 128, and 256 bits in Cipher Block Chaining (CBC) mode and Galois Counter Mode (GCM). The 3eTI’s OpenSSL Library provides AES services for application level data encryption and decryption. The management interface uses this library to provide Transport Layer Security (TLS/HTTPS). For TOE’s TLS interface, AES_CBC with 128 or 256 bits key is used. 3eTI’s MPC8378E Cryptographic Core provides AES_GCM and AES_CBC services for IPsec data encryption. 128 and 256 bits keys are supported. Table 6-1 lists the AES mode and key sizes, all AES algorithm implementations are NIST CAVP validated. FCS_COP.1(2): The 3eTI OpenSSL Library provides the RSA Digital Signature Algorithm (rDSA) to the TLS/HTTPS Daemon for the TLS session. The TLS/HTTPS Daemon enforces a 2048 or larger bits RSA key length for use with the RSA. TOE Firmware’s digital signature is using ECDSA with P256. The 3eTI OpenSSL library provides ECDSA sign/verify operation support. IPsec tunnels can be configured to use RSA (2048, 4096) or ECDSA with key size 256, 384, and 521 bits using NIST curve P256, P384 and P521) certificate for IPsec SA authentication. Table 6-1 lists RSA and ECDSA CAVP validation certificate numbers. FCS_COP.1(3): The TSF supports SHA-1, SHA-256, SHA-384, and SHA-512 for secure hashing. See Table 6-1 for details. The security hashing functions are used in IPsec IKEv2 and ESP to provide data packet integrity. FCS_COP.1(4): The TOE’s OpenSSL Library and the MPC8378E cryptographic core both implement HMAC-SHA-1, HMAC- SHA-256, HMAC-SHA-384, and HMAC-SHA-512, keyed-hash message authentication supporting digest sizes: CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 29 of 35 160, 256, 384, and 512 bits and key size of 160 bits, 256 bits, 384 and 512 bits implemented to meet ISO/IEC 9797- 2:2011, Section 7 “MAC Algorithm 2 FCS_IPSEC_EXT.1: The TOE implements IPsec protocol in full compliance with IETF RFCs as specified by NDcPP. Within the TOE, NTP client uses IPsec tunnel with NTP server and audit log service will use IPsec tunnel to the remote log server. The TOE supports IKEv2 only as defined by RFCs 5996 and always attempts NAT traversal, hence an administrator need not configure either. During the Security Association (SA) setup phase, the TOE supports the following DH groups:  ecp384  ecp256  modp2048 If the administrator selects “auto negotiation” from IPsec “Cipher Suites” configuration GUI, then the groups listed above will be send to the IPsec peer during the IKEv2 negotiation. If “Suite B GCM128” is selected, then the TOE will use ecp256 group. If “Suite B GCM256” is selected, then the TOE will use ecp384 group. The TOE choses and enforces the group and AES cipher to make sure that the SA confidentiality strength is equivalent or greater than the configured ESP confidentiality strength. For example, the TOE (when configured for “Auto Negotiation”) will reject any ESP proposal with an AES key length greater than the negotiated IKE AES key length. Similarly, administrator selection of “Suite B GCM128” or similar ciphers ensure the TOE will enforce a single, proscribed set of modes to make sure that the parents IPsec SA confidentiality strength is equal or greater than the child SA’s strength. Mode IKE (openssl library) ESP (Hardware encryption) Encryption Integrity Pseudo Random Function DH Group Encryption Integrity (where applicable) Suite B GCM 128 aes128cbc sha256 sha256 ecp256 aes128gcm128 - The TOE uses ISO/IEC 18031:2011 DRBG to generate the “x” in each DH group and the nonce. After the Diffie Hellman exchanges that setup the session keys, the IKEv2 payload is protected by the following encryption algorithms:  AES-CBC-256  AES-CBC-128 SHA-512, SHA-384, SHA-256 and SHA1 are used to provide payload data integrity. X.509 certificates with rDSA 2048 bits or larger key or ECDSA 256, 384, and 521 bits key with NIST P256, P384 and P521 are used for IPsec tunnel authentication with its peer. The TOE supports IPsec tunnel mode and transport mode which allows on the payload of packet to be encrypted. The TOE requires no administrative configuration and negotiates either depending on the peer. The TOE uses IPsec standard encapsulating Security Payload (ESP) protocol to provide authentication, encryption and anti-replay services. It uses the following ciphers to encrypt the IPsec data payload: 1. GCM mode with Nonce length of 128, 96 and 64 bits  AES-GCM-128  AES-GCM-256 2. CBC mode with HMAC-SHA-512, HMAC-SHA-384, HMAC-SHA-256 and HMAC-SHA1 as integrity  AES-CBC-128  AES-CBC-256 CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 30 of 35 When the administrator chooses AES-GCM-128 for ESP encryption, the TOE will automatically choose SHA-256 for the IKE’s integrity and pseudo random function. If the choice is AES-GCM-256, then SHA-256 will be used in IKE integrity and SHA-384 will be used for the pseudo random function. If the administrator chooses “Auto Negotiation” for IPsec, the TOE will send cipher list ranked with the highest security first to its peer. For example, the IKE integrity list will be sent as: SHA-512, SHA-384, SHA-256 and SHA1. It’s expected that the peer will pick the strongest one it could support. There is no need to explicitly configure security hashing functions in the IPsec configuration. The IPsec daemon module implements implicit policies such that only expected data packages are allowed. Any data packages that violate the policy will be discarded. The TOE allows the Security Administrator to configure the IKEv2 SA and child SA lifetime by minutes (20-1440, default 180) and the TOE additionally allows the Administrator to configure child SA lifetime by number of bytes (90 to 2047Kb, 0 for unlimited) or by number of data packets (192 to 2097151K, 0 for unlimited). The TOE supports X.509 certificate for IPsec mutual authentication. RSA certificate with 2048 or 4098 bits, ECDSA certificates with 256, 384, and 521 bits key is supported implementing NIST curves P256, P384 and P521. When certificates are used for authentication, the distinguished name (DN) is verified to ensure the certificate is valid and is from a valid entity. The DN naming attributes in the certificate is compared with the expected DN naming attributes (as specified by an administrator) and deemed valid if the attribute types are the same and the values are the same and as expected. The TOE can be configured to use pre-shared key for IPsec authentication as well. The security administrator first select “Pre-Shared Key” under the “Authentication” when configure the IPsec tunnel via web GUI, then enter the pre-shared key manually via the GUI. The TOE’s IPsec Security Policy Database (SPD) is dynamically configured based the trusted paths IPsec is used to protect. For example, the TOE uses IPsec to protect a remote syslog trusted path. In this instance, records are written into the SPD to protect packets passing between the TOE and the remote syslog server based on source address, destination address, protocol and port number. When protecting remote syslog trusted path, the SPD will have record matching ingress UDP traffic with source address and port corresponding to the remote syslog server. Additionally, the SPD will have record matching egress traffic with destination address and port corresponding to the remote syslog server. Traffic passing through the security boundary and matching either of these two records will be classified as “PROTECTED” using IPsec transport mode. Traffic that does not match any records in the SPD but does match the local firewall access list will be allows to “BYPASS” the security boundary unperturbed. Traffic that does not match any records in the SPD and doesn’t match the local firewall access list will be “DISCARDED”. Additional records are written into the SPD when additional trusted paths are configured for IPsec protection (i.e. remote audit log and NTP server). FCS_RBG_EXT.1: The TOE implements RBG as defined ISO/IEC 18031:2011 using AES. The entropy source is a hardware based noise generator. Entropy is obtained from a zener diode operated in avalanche mode. The noise from the diode is passed through a cascaded pair of operational amplifiers, then applied to the input of a Microchip MCP3221. MCP3221 is a successive approximation analog to digital converter (ADC) with a 12 bit resolution. The TOE communicates with the MCP3221 hardware over the 2-wire I2C and reads in the raw entropy. The raw entropy is further conditioned by the Linux kernel to produce 8 bits of entropy per byte. Then the random bytes are read by the DRBG implementation of 256 bits of DRBG key and DRBG seed. FCS_HTTPS_EXT.1: FCS_TLSS_EXT.1: The management interface with remote administration station is always TLS/HTTPS. The HTTPS implementation is fully compliant with RFC 2818. The TOE acts as an HTTPS server and waits for client connections on TCP port CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 31 of 35 443. The TOE’s HTTPS server permits an HTTP client to close the connection at any time, and the HTTPS server will recover gracefully. In particular, the HTTPS server is prepared to receive an incomplete close from the client, and is willing to resume TLS sessions closed in this fashion. The TOE’s HTTPS server supports TLS version 1.1/1.2 only and will deny connection requests from TLS clients with lower version. It supports the following ciphers:  TLS_RSA_WITH_AES_128_CBC_SHA  TLS_RSA_WITH_AES_256_CBC_SHA  TLS_DHE_RSA_WITH_AES_128_CBC_SHA  TLS_DHE_RSA_WITH_AES_256_CBC_SHA  TLS_RSA_WITH_AES_128_CBC_SHA256  TLS_RSA_WITH_AES_256_CBC_SHA256  TLS_DHE_RSA_WITH_AES_128_CBC_SHA256  TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 The TOE’s TLS/HTTPS server uses RSA 2048 bits certificate for TLS authentication. After the TLS session’s successful setup, the security administrator logs into the TOE via user name and passwords. If the failure count reaches the configured threshold, the TLS/HTTPS session will be terminated by the TLS/HTTPS server. The Diffie- Hellman group 14 with parameters of size 2048 bits is used for the key agreement. 6.3 Identification and authentication The Identification and authentication function is designed to satisfy the following security functional requirements: FIA_PMG_EXT.1: The TOE supports the local definition of users with corresponding passwords. The passwords can be composed of any combination of upper and lower case letters, numbers, and special characters (that include: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, and “)”. Minimum password length is settable by the Authorized Administrator, and can be configured for minimum password lengths of 15 characters. Additionally, the TOE supports password lengths up to 32 characters long. NOTE: The TOE will truncate passwords that are longer than 32 characters when creating a user or changing passwords for an existing user. FIA_UAU.7: when a user is entering their password information, the password is obscured such that no observer could read the password off the screen. FIA_UAU_EXT.2: FIA_UIA_EXT.1: The TOE requires all users to be successfully identified and authenticated before allowing any TSF mediated actions to be performed except for the login banner that is displayed prior to user authentication and any network packets as configured by the authorized administrator may flow through the TOE. Network packets as configured by the authorized administrator may flow through the TOE. The administrator logs on the TOE through either dedicated local Ethernet port or over WAN Ethernet port to access the Web Management UI. The Web Management UI is accessible over HTTPS only and the TOE supports TLS 1.1/1.2. There is no local access such as a serial console port. Therefore, the local and remote management is considered the same for this evaluation. A successful authentication is determined by a successful username and password combination after the HTTPS connection. An incorrect password will result in a failed authentication attempt. The TOE does not provide a reason for failure in the cases of a login failure. The TOE supports local authentication using A local user database. FIA_X509_EXT.1: CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 32 of 35 FIA_X509_EXT.2: FIA_X509_EXT.3: The TOE uses X.509 certificates for IPsec authentications. The TOE can be configured with the certificates and their corresponding private key by security administrator or by creating CSRs and importing the CA signed CSRs to the TOE. The security administrator can load and delete certificates for usage of IPsec authentication, load and delete CAs, intermediated CAs and CRLs. The TOE checks that the basicConstraints extension and CA flag are set to TRUE for all CA certificates before their acceptance. During the IPsec authentication using X509 certificate, the TOE develops a certificate path from a trust anchor configured by security administrator which is fully compliant with RFC 5280. When a certificate chain is received from a peer, the TOE processes the certificate chain path until the first trusted certificate, or trust point, is reached. The TOE uses CRL that have been preloaded by the administrator to validate the peer certificates, and the TOE will accept as valid, a certificate for which the administrator has not loaded a CRL. Failure by the TOE to establish the certification path to a trust anchor will lead to the failure of establishment of this IPsec trusted channel. The TOE allows the security administrator to view the certificates and CAs. The TOE’s GUI will display the certificates’ name, subject name, issuer name, valid-start date, expiration date. 6.4 Security management The Security management function is designed to satisfy the following security functional requirements: FMT_MOF.1(1): FMT_MTD.1(1): FMT_SMF.1: FMT_SMR.2: The Web Management Application over HTTP/TLS provides capabilities for the authorized administrator to manage cryptographic, audit, and authentication functions and data. The TOE provides three roles: Security Administrator, Non-security Administrator, and user (Peer Device). Security Administrator and Administrator can only access the TOE through Web Application through TLS/HTTPS. Upon successful authentication with the TOE, the Security Administrator can manage TSF data as shown in the table below. Table 6-2: Management of TSF Data Service and Purpose Details Security Administrator (referred to as Crypto officer in guidance) Non-Security Administrator Input of Keys IKE v2 digital certificate private key, 802.1X supplicant private key, device HTTPS private keys, authentication key with RADIUS Server. X Create and manage users Support up to 10 administrator users and 5 crypto officer users. X Change password Administrator changes his own password only. X X Show system status View traffic status and systems log excluding security audit log. X X Manage audit logging Select audit events to be logged. Configure remote audit logging. View audit event records. X Key zeroization via reboot X X CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 33 of 35 Factory default Delete all configurations and set device back to factory default state. X Perform Self-Test Run algorithm KAT through reboot. X X Load New Firmware Upload 3eTI digitally signed firmware. X SNMP Management Manage all SNMP settings including SNMPv3 encryption key. X X HTTPS Management Load HTTPS server certificate and private key. X Key Generation Create asymmetric key pairs and X509v3 Certificate Signing Request. X X No GUI interfaces are accessible to the user prior to authentication. The TOE enforces authentication then enables the TSF data configuration interfaces. The Non-security administrators have no access to those TSF data configuration interfaces. 6.5 Protection of the TSF The Protection of the TSF function is designed to satisfy the following security functional requirements: FPT_APW_EXT.1: FPT_SKP_EXT.1: The authentication passwords are stored in PKCS5 format in the TOE. All other CSPs are stored in encrypted format in the TOE on non-volatile memory. The file system that holds the hashed password and encrypted CSPs are made read-only during runtime to avoid data corruption. None of the files or CSPs is available through any external interfaces to users/administrators. The Web Application Interface allows security administrator to input keys/passwords to the TOE with no output capabilities. FPT_STM.1: The TOE has a running NTP daemon to synchronize the local time with an external NTP server. IPsec tunnel is setup between the TOE and NTP server to protect the integrity and privacy of the time source. In the absence of an NTP server in the Operational Environment, the authorized administrator has the capability to set the time locally. The local time is used for the following security functions identified in this ST:  Time stamping each audit record.  Verifying the validity of the Web Server X509v3 Certificate.  Verifying the validity of the IPsec tunnel peer’s Certificate.  Verifying the validity of the Firmware X509v3 Certificate during the firmware upload process.  Enforcing user lockout periods for “Bad Password” login attempts.  Timing out login sessions due to inactivity. FPT_TST_EXT.1: The TSF performs a firmware integrity check and a configuration file integrity check on system start up. Algorithm Known Answer Tests are run at startup time as shown below: Power-on self-tests: Software Integrity Test  Bootloader Integrity Test  Firmware Integrity Test FreeScale PowerQUICC Crypto Engine Power-on self-tests:  AES_GCM encrypt/decrypt KAT  SHA-1, SHA256, SHA384, SHA512 KAT  HMAC SHA-1, SHA256, SHA384, SHA512 KAT CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 34 of 35 3eTI OpenSSL library Power-on self-tests:  HMAC SHA-1, SHA256, SHA384, SHA512 KAT  SHA-1, SHA256, SHA384, SHA512 KAT  FIPS SP800-90 DRBG KAT  RSA sign/verify KAT  ECDSA sign/verify KAT Vectors for each known answer test (KAT) are compiled into the Firmware. The known inputs are provided to the cryptographic function and the output of that function is compared to the known output. The firmware is halted if any of the known answer tests fail. After device is powered on, the first thing done by bootloader is to check its own integrity. If the integrity is broken, firmware won’t boot. Firmware integrity is performed at firmware boot up. Both firmware and bootloader are digitally signed with ECDSA. The TOE also performs the DRBG Continuous Random Number test consists of a Repetitive Count test and an Adaptive Proportion test. Each random sample is compared to previous samples. The Repetitive Count test ensures the new sample is not repeated sequentially above a threshold. The Adaptive Proportion test ensures the new sample is not repeated beyond a threshold within a window of previous samples. FPT_TUD_EXT.1: When newer version of firmware is released, the customers are notified by 3eTI’s customer service department, normally via e-mail. If a customer desires to get a copy of the new firmware, the customer will be provided with an URL link to the secured download site together with onetime valid user name and password. The Security Administrator can update the TOE’s firmware. The firmware is digitally signed with ECDSA. The TOE uses the public key to verify the digital signature. Upon successful verification, the TOE will load the new update upon reboot. The update will be rejected if the verification fails. 6.6 TOE access The TOE access function is designed to satisfy the following security functional requirements: FTA_SSL.3: FTA_SSL.4: FTA_SSL_EXT.1: The Web Management Application terminates the remote or local session if it detects inactivity longer than the configured time period. The default time period is 10 minutes. The remote session will be closed by the Web Management Application together with the HTTPS session. The Security Administrator is required to re- authenticate with the TOE and setup a new session. The time intervals are configurable by the security administrator. FTA_TAB.1: The Management GUI displays a customizable TOE access banner to the remote administrative user before the user can log into the system. 6.7 Trusted path/channels The Trusted path/channels function is designed to satisfy the following security functional requirements: FTP_ITC.1: CyberFence 3e-636 Series Network Security Devices (NDcPP10) Security Target Version 0.7, 09/19/2017 Page 35 of 35 The TOE provide a trusted communication channel between itself and all authorized IT entities that is logically distinct from other communication channels. IPsec is setup between the TOE and the audit log server, LDAP and NTP server. The trusted channel can be initiated either by the TOE or by the remote IT entities. FTP_TRP.1: All remote administrative communications take place over a secure encrypted TLS session. The HTTPS/TLS implementation allows web browser clients to connect to TOE HTTPS server. The remote users are able to initiate TLS communications with the TOE.