Assurance Activities Report for Samsung Galaxy Devices VPN Client on Android 7 (IVPNCPP14)

Transcription

1 Assurance Activities Report for Samsung Galaxy Devices VPN Client on Android 7 (IVPNCPP14) Version /03/17 Prepared by: Gossamer Security Solutions Accredited Security Testing Laboratory Common Criteria Testing Catonsville, MD Prepared for: National Information Assurance Partnership Common Criteria Evaluation and Validation Scheme 2017 Gossamer Security Solutions, Inc.

2 REVISION HISTORY Revision Date Authors Summary Version /14/17 Compton Initial draft Version /03/17 Compton Addressed ECR Comments The TOE Evaluation was Sponsored by: Samsung Electronics Co., Ltd. 416 Maetan-3dong, Yeongtong-gu, Suwon-si, Gyeonggi-do, Korea Evaluation Personnel: James Arnold Tammy Compton Common Criteria Versions: Common Criteria for Information Technology Security Evaluation Part 1: Introduction, Version 3.1, Revision 4, September 2012 Common Criteria for Information Technology Security Evaluation Part 2: Security functional components, Version 3.1, Revision 4, September 2012 Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components, Version 3.1 Revision 4, September 2012 Common Evaluation Methodology Versions: Common Methodology for Information Technology Security Evaluation, Evaluation Methodology, Version 3.1, Revision 4, July 2012 GSS CCT Assurance Activity Report Page 2 of Gossamer Security Solutions, Inc.

3 TABLE OF CONTENTS 1. Introduction Equivalence Protection Profile SFR Assurance Activities Cryptographic support (FCS) Cryptographic Key Generation (Asymmetric Keys) (FCS_CKM.1(1)) Cryptographic Key Generation (for asymmetric keys - IKE) (FCS_CKM.1(2)) Cryptographic Key Storage (FCS_CKM_EXT.2) Cryptographic Key Zeroization (FCS_CKM_EXT.4) Cryptographic Operation (Data Encryption/Decryption) (FCS_COP.1(1)) Cryptographic Operation (for cryptographic signature) (FCS_COP.1(2)) Cryptographic Operation (Cryptographic Hashing) (FCS_COP.1(3)) Cryptographic Operation (Keyed-Hash Message Authentication) (FCS_COP.1(4)) Extended: Internet Protocol Security (IPsec) Communications (FCS_IPSEC_EXT.1) Extended: Cryptographic operation (Random Bit Generation) (FCS_RBG_EXT.1) User data protection (FDP) Full Residual Information Protection (FDP_RIP.2) Identification and authentication (FIA) Extended: Pre-Shared Key Composition (FIA_PSK_EXT.1) Extended: X.509 Certificate Validation (FIA_X509_EXT.1) Extended: X.509 Certificate Use and Management (FIA_X509_EXT.2) Security management (FMT) Specification of Management Functions (FMT_SMF.1(1)) Specification of Management Functions (FMT_SMF.1(2)) Protection of the TSF (FPT) Extended: TSF Self Test (FPT_TST_EXT.1) Extended: Trusted Update (FPT_TUD_EXT.1) Trusted path/channels (FTP) Inter-TSF trusted channel (FTP_ITC.1) Protection Profile SAR Assurance Activities GSS CCT Assurance Activity Report Page 3 of Gossamer Security Solutions, Inc.

4 3.1 Development (ADV) Basic functional specification (ADV_FSP.1) Guidance documents (AGD) Operational user guidance (AGD_OPE.1) Preparative procedures (AGD_PRE.1) Life-cycle support (ALC) Labelling of the TOE (ALC_CMC.1) TOE CM coverage (ALC_CMS.1) Tests (ATE) Independent testing - conformance (ATE_IND.1) Vulnerability assessment (AVA) Vulnerability survey (AVA_VAN.1) GSS CCT Assurance Activity Report Page 4 of Gossamer Security Solutions, Inc.

5 1. INTRODUCTION This document presents evaluations results of the Samsung Electronics Co., Ltd. Samsung Galaxy Devices VPN Client on Android 7 IVPNCPP evaluation. This document contains a description of the assurance activities and associated results as performed by the evaluators. 1.1 EQUIVALENCE This evaluation tested the following Galaxy devices: Device Name Model Number Chipset Vendor CPU Build Arch/ISA Android Version Kernel Version Build Number Galaxy S8 SM-G955F System LSI Exynos 8895 A NRD90M Galaxy S8+ SM-G955U Qualcomm MSM8998 A NRD90M Galaxy S7 Edge SM-G935F System LSI Exynos 8890 A NRD90M Galaxy S7 Edge SM-G935A Qualcomm MSM8996 A NRD90M Galaxy Tab S3 SM-T825Y Qualcomm MSM8996 A NRD90M Galaxy S6 Edge SM-G925V System LSI Exynos 7420 A NRD90M The following table contains a list of devices that are claimed via equivalency. For each device, there is a mapping to one of the devices that was fully tested as part of this evaluation. Evaluated Chipset Device Vendor CPU Equivalent Devices Differences Galaxy S8+ Qualcomm MSM8998 Galaxy S8 (Qualcomm) S8+ is larger Galaxy S8 Qualcomm MSM8998 Galaxy S8 Active (Qualcomm) Curved screen vs. Flat screen S7 Active has a IP68 & MIL- STD-810G certified body Galaxy S8+ System LSI Exynos 8895 Galaxy S8 (System LSI) S8+ is larger Galaxy S7 Edge Qualcomm MSM8996 Galaxy S7 (Qualcomm) Curved screen vs. Flat screen Galaxy S7 Edge Qualcomm MSM8996 Galaxy S7 Active (Qualcomm) Curved screen vs. Flat screen S7 Active has a IP68 & MIL- STD-810G certified body No fingerprint sensor Galaxy S7 Edge System LSI Exynos 8890 Galaxy S7 (System LSI) Curved screen vs. Flat screen Galaxy S6 Edge System LSI Exynos 7420 Galaxy S6 Flat screen vs. Curved screen Galaxy S6 Edge System LSI Exynos 7420 Galaxy S6 Edge+ Edge+ is larger Galaxy S6 Edge System LSI Exynos 7420 Galaxy Note 5 Curved screen vs. Flat screen Note 5 is larger Note 5 includes stylus & functionality to take advantage of it for input (not security related) Galaxy S6 Edge System LSI Exynos 7420 Galaxy S6 Active Curved screen vs. Flat screen GSS CCT Assurance Activity Report Page 5 of Gossamer Security Solutions, Inc.

6 Evaluated Device Chipset Vendor CPU Equivalent Devices Differences S6 Active has a IP68 & MIL- STD-810G certified body No fingerprint sensor GSS CCT Assurance Activity Report Page 6 of Gossamer Security Solutions, Inc.

7 2. PROTECTION PROFILE SFR ASSURANCE ACTIVITIES This section of the AAR identifies each of the assurance activities included in the claimed Protection Profile and describes the findings in each case. The following evidence was used to complete the Assurance Activities: AAR v0.1 Samsung Electronics Co., Ltd. Samsung Galaxy Devices VPN Client on Android 7 (IVPNCPP14) Security Target, Version 1.1, March 29, 2017 [ST] Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 7 (MDFPP30/WLANCEP10 Security Target, Version 0.2, March 24, 2017 [Platform ST] Samsung VPN Client on Galaxy Devices Guidance documentation, version 3.0, February 27, 2017 [Admin- Guide] Samsung VPN Client on Galaxy Devices VPN User Guidance Documentation, version 3.0, March 15, 2017 [User-Guide] 2.1 CRYPTOGRAPHIC SUPPORT (FCS) CRYPTOGRAPHIC KEY GENERATION (ASYMMETRIC KEYS) (FCS_CKM.1(1)) FCS_CKM.1(1).1 Component TSS Assurance Activities: Requirement met by the platform For each platform listed in the ST, the evaluator shall examine the ST of the platform to ensure that the key establishment claimed in that platform's ST contains the key establishment requirement in the VPN Client's ST. The evaluator shall also examine the TSS of the VPN Client's ST to verify that it describes (for each supported platform) how the key establishment functionality is invoked (it should be noted that this may be through a mechanism that is not implemented by the VPN Client; nonetheless, that mechanism will be identified in the TSS as part of this assurance activity). Requirement met by the TOE GSS CCT Assurance Activity Report Page 7 of Gossamer Security Solutions, Inc.

8 Key Establishment Schemes: SP800-56B Key Establishment Schemes: At this time, detailed test procedures for RSA-based key establishment schemes are not available. In order to show that the TSF complies with 80056A and/or 80056B, depending on the selections made, the evaluator shall ensure that the TSS contains the following information: - The TSS shall list all sections of the appropriate standard(s) to which the TOE complies. - For each applicable section listed in the TSS, for all statements that are not 'shall' (that is, 'shall not', 'should', and 'should not'), if the TOE implements such options it shall be described in the TSS. If the included functionality is indicated as 'shall not' or 'should not' in the standard, the TSS shall provide a rationale for why this will not adversely affect the security policy implemented by the TOE. For each applicable section of 80056A and 80056B (as selected), any omission of functionality related to 'shall' or 'should' statements shall be described. This requirement is met by the TOE platform. The evaluator checked the Platform-ST and found each key establishment method required by the TOE listed. The evaluator also verified each curve size and key size required by the TOE was included in the Platform ST. The SFR had the identifier FCS_CKM.2(1) in the Platform-ST. The TOE platform has CVL algorithm certificate #1141 and ECDSA algorithm certificate #1074 for Elliptic Curve key establishment and key generation respectively. The TOE platform has RSA algorithm certificate #2413 for RSA key generation and for RSA key establishment. The TOE utilizes the cryptographic algorithm implementation of the TOE Platform by directly linking against the native BoringSSL cryptographic library through the native C API. In this way, the TOE can invoke the cryptographic operations provided by the TOE Platform (including the key establishment, key generation, encryption/decryption, random bit generation, digital signatures, hashing, and keyed hashing). Component Component Testing Assurance Activities: Requirement met by the TOE Key Generation: FIPS Key Establishment Schemes: SP800-56A Key Establishment Schemes: FIPS This requirement was met by the Platform so no additional testing is required CRYPTOGRAPHIC KEY GENERATION (FOR ASYMMETRIC KEYS - IKE) (FCS_CKM.1(2)) FCS_CKM.1(2).1 GSS CCT Assurance Activity Report Page 8 of Gossamer Security Solutions, Inc.

9 Component TSS Assurance Activities: Requirement met by the platform For each platform listed in the ST, the evaluator shall examine the ST of the platform to ensure that the key generation function claimed in that platform's ST contains the key generation requirement in the VPN Client's ST. The evaluator shall also examine the TSS of the VPN Client's ST to verify that it describes (for each supported platform) how the key generation functionality is invoked (it should be noted that this may be through a mechanism that is not implemented by the VPN Client; nonetheless, that mechanism will be identified in the TSS as part of this assurance activity). Requirement met by the TOE If the TSF implements a FIPS signature scheme, this requirement is verified under FCS_COP.1(2). If the ESF implements the ANSI X scheme, the evaluator shall check to ensure that the TSS describes how the keypairs are generated. In order to show that the TSF implementation complies with ANSI X , the evaluator shall ensure that the TSS contains the following information: - The TSS shall list all sections of the standard to which the TOE complies; - For each applicable section listed in the TSS, for all statements that are not 'shall' (that is, 'shall not', 'should', and 'should not'), if the TOE implements such options it shall be described in the TSS. If the included functionality is indicated as 'shall not' or 'should not' in the standard, the TSS shall provide a rationale for why this will not adversely affect the security policy implemented by the TOE; - For each applicable section of Appendix B, any omission of functionality related to 'shall' or 'should' statements shall be described. This requirement is met by the TOE platform. The evaluator checked the Platform-ST and found each key establishment method required by the TOE listed. The evaluator also verified each curve size and key size required by the TOE was included in the Platform ST. The SFR had the identifier FCS_CKM.1(1) in the platform ST. The TOE utilizes the cryptographic algorithm implementation of the TOE Platform by directly linking against the native BoringSSL cryptographic library through the native C API. In this way, the TOE can invoke the cryptographic operations provided by the TOE Platform (including the key establishment, key generation, encryption/decryption, random bit generation, digital signatures, hashing, and keyed hashing). Component Component GSS CCT Assurance Activity Report Page 9 of Gossamer Security Solutions, Inc.

10 2.1.3 CRYPTOGRAPHIC KEY STORAGE (FCS_CKM_EXT.2) FCS_CKM_EXT.2.1 Component TSS Assurance Activities: Regardless of whether this requirement is met by the TOE or the TOE platform, the evaluator will check the TSS to ensure that it lists each persistent secret (credential, secret key) and private key needed to meet the requirements in the ST. For each of these items, the evaluator will confirm that the TSS lists for what purpose it is used, and how it is stored. The evaluator than performs the following actions. Persistent secrets and private keys manipulated by the platform For each platform listed in the ST, the evaluator shall examine the ST of the platform to ensure that the persistent secrets and private keys listed as being stored by the platform in the VPN client ST are identified as being protected in that platform's ST. Persistent secrets and private keys manipulated by the TOE The evaluator reviews the TSS for to determine that it makes a case that, for each item listed as being manipulated by the TOE, it is not written unencrypted to persistent memory, and that the item is stored by the platform. Table 3 in the ST presents all the keys used by the TOE. The table identifies the key, how it is created, where it is stored, when it is cleared and how it is cleared. All of the keys needed for the requirements are presented in the table. The Platform ST upon which the VPN TOE relies provides a description of the protections afforded to the keystore, Memory, and FLASH in Section 6.1. Component Component CRYPTOGRAPHIC KEY ZEROIZATION (FCS_CKM_EXT.4) FCS_CKM_EXT.4.1 GSS CCT Assurance Activity Report Page 10 of Gossamer Security Solutions, Inc.

11 Component TSS Assurance Activities: The evaluator shall ensure that all plaintext secret and private cryptographic keys and CSPs (whether manipulated by the TOE or exclusively by the platform) are identified in the VPN Client ST's TSS, and that they are accounted for by the assurance activities in this section. Requirement met by the platform The evaluator shall check to ensure the TSS describes each of the secret keys (keys used for symmetric encryption), private keys, and CSPs used to generate key that are not otherwise covered by the FCS_CKM_EXT.4 requirement levied on the TOE. For each platform listed in the ST, the evaluator shall examine the TSS of the ST of the platform to ensure that each of the secret keys, private keys, and CSPs used to generate key listed above are covered. Requirement met by the TOE The evaluator shall check to ensure the TSS describes when each of the plaintext keys are cleared (e.g., system power off, disconnection of an IPsec connection, when no longer needed by the VPN channel per the protocol); and the type of clearing procedure that is performed (cryptographic erase, overwrite with zeros, overwrite three or more times by a different alternating pattern, overwrite with random pattern, or block erase). If different types of memory are used to store the materials to be protected, the evaluator shall check to ensure that the TSS describes the clearing procedure in terms of the memory in which the data are stored (for example, 'secret keys stored on flash are cleared by overwriting once with zeros, while secret keys stored on the internal persistent storage device are cleared by overwriting three times with a random pattern that is changed before each write'). Table 3 in the ST presents all the secret and private keys used by the TOE. The table identifies the key, how it is created, where it is stored, when it is cleared and how it is cleared. All of the keys needed for the requirements are presented in the table. The Platform ST upon which the VPN TOE relies provides a description of the protections afforded to the keystore. Memory, and FLASH in Section 6.1. Component Component Testing Assurance Activities: Requirement met by the TOE For each key clearing situation described in the TSS, the evaluator shall repeat the following test. Test 1: The evaluator shall utilize appropriate combinations of specialized operational environment and development tools (debuggers, simulators, etc.) for the TOE and instrumented TOE builds to test that keys are GSS CCT Assurance Activity Report Page 11 of Gossamer Security Solutions, Inc.

12 cleared correctly, including all intermediate copies of the key that may have been created internally by the TOE during normal cryptographic processing with that key. Cryptographic TOE implementations in software shall be loaded and exercised under a debugger to perform such tests. The evaluator shall perform the following test for each key subject to clearing, including intermediate copies of keys that are persisted encrypted by the TOE: 1. Load the instrumented TOE build in a debugger. 2. Record the value of the key in the TOE subject to clearing. 3. Cause the TOE to perform a normal cryptographic processing with the key from #1. 4. Cause the TOE to clear the key. 5. Cause the TOE to stop the execution but not exit. 6. Cause the TOE to dump the entire memory footprint of the TOE into a binary file. 7. Search the content of the binary file created in #4 for instances of the known key value from #1. The test succeeds if no copies of the key from #1 are found in step #7 above and fails otherwise. The evaluator shall perform this test on all keys, including those persisted in encrypted form, to ensure intermediate copies are cleared. Test 1 The corresponding MDFPPv30 evaluation has been augmented to address the clearing of the VPN secrets. See the Assurance Activity Report (MDFPP30) for Samsung Galaxy Devices on Android CRYPTOGRAPHIC OPERATION (DATA ENCRYPTION/DECRYPTION) (FCS_COP.1(1)) FCS_COP.1(1).1 Component TSS Assurance Activities: Requirement met by the platform For each platform listed in the ST, the evaluator shall examine the ST of the platform to ensure that the encryption/decryption function(s) claimed in that platform's ST contains the encryption/decryption function(s) in GSS CCT Assurance Activity Report Page 12 of Gossamer Security Solutions, Inc.

13 the VPN Client's ST. The evaluator shall also examine the TSS of the VPN Client's ST to verify that it describes (for each supported platform) how the encryption/decryption functionality is invoked for the indicated modes and key sizes in the VPN Client's ST (it should be noted that this may be through a mechanism that is not implemented by the VPN Client; nonetheless, that mechanism will be identified in the TSS as part of this assurance activity). This requirement is met by the TOE platform. The evaluator checked the Platform-ST and found in the FCS_COP.1(1) SFR that the TOE Platform meets claimed AES CBC and GMC modes of encryption and decryptions functions with 128 and 256 bits. The TOE utilizes the cryptographic algorithm implementation of the TOE Platform by directly linking against the native BoringSSL cryptographic library through the native C API. In this way, the TOE can invoke the cryptographic operations provided by the TOE Platform (including the key establishment, key generation, encryption/decryption, random bit generation, digital signatures, hashing, and keyed hashing). Component Component Testing Assurance Activities: Requirement met by the TOE FIPS This requirement was met by the Platform so no additional testing is required CRYPTOGRAPHIC OPERATION (FOR CRYPTOGRAPHIC SIGNATURE) (FCS_COP.1(2)) FCS_COP.1(2).1 Component TSS Assurance Activities: Requirement met by the platform For each platform listed in the ST, the evaluator shall examine the ST of the platform to ensure that the digital signature functions claimed in that platform's ST contains the digital signature functions in the VPN Client's ST. The evaluator shall also examine the TSS of the VPN Client's ST to verify that it describes (for each supported platform) how the digital signature functionality is invoked for each operation they are used for in the VPN client (it should be noted that this may be through a mechanism that is not implemented by the VPN Client; nonetheless, that mechanism will be identified in the TSS as part of this assurance activity). This requirement is met by the TOE platform. The evaluator checked the Platform-ST and found in the FCS_COP.1(3) SFR that the TOE Platform provides RSA and ECDSA signatures with curves of 256, 384, and 521 as GSS CCT Assurance Activity Report Page 13 of Gossamer Security Solutions, Inc.

14 needed by the TOE. The TOE utilizes the cryptographic algorithm implementation of the TOE Platform by directly linking against the native BoringSSL cryptographic library through the native C API. In this way, the TOE can invoke the cryptographic operations provided by the TOE Platform (including the key establishment, key generation, encryption/decryption, random bit generation, digital signatures, hashing, and keyed hashing). Component Component Testing Assurance Activities: Requirement met by the TOE FIPS This requirement was met by the Platform so no additional testing is required CRYPTOGRAPHIC OPERATION (CRYPTOGRAPHIC HASHING) (FCS_COP.1(3)) FCS_COP.1(3).1 Component TSS Assurance Activities: The evaluator shall check that the association of the hash function with other cryptographic functions (for example, the digital signature verification function) specified in the VPN Client ST (whether these are performed by the platform or by the TOE) is documented in the TSS. Requirement met by the platform For each platform listed in the ST, the evaluator shall examine the ST of the platform to ensure that the hash function(s) claimed in that platform's ST contains the hash function(s) in the VPN Client's ST. The evaluator shall also examine the TSS of the VPN Client's ST to verify that it describes (for each supported platform) how the hash functionality is invoked for each digest size selected in the VPN Client's ST (it should be noted that this may be through a mechanism that is not implemented by the VPN Client; nonetheless, that mechanism will be identified in the TSS as part of this assurance activity). This requirement is met by the TOE platform. The evaluator checked Platform-ST and found in the FCS_COP.1(2) SFR that the TOE Platform provides the following hashing algorithms; SHA-1, SHA-256, SHA-384, SHA-512 with message digest sizes 160, 256, 384, 512. This matches the TOE s requirements exactly. The TOE utilizes the cryptographic algorithm implementation of the TOE Platform by directly linking against the native BoringSSL cryptographic library through the native C API. In this way, the TOE can invoke the cryptographic operations GSS CCT Assurance Activity Report Page 14 of Gossamer Security Solutions, Inc.

15 provided by the TOE Platform (including the key establishment, key generation, encryption/decryption, random bit generation, digital signatures, hashing, and keyed hashing). Component Component Testing Assurance Activities: Requirement met by the TOE FIPS This requirement was met by the Platform so no additional testing is required CRYPTOGRAPHIC OPERATION (KEYED-HASH MESSAGE AUTHENTICATION) (FCS_COP.1(4)) FCS_COP.1(4).1 Component TSS Assurance Activities: The evaluator shall check that the association of the keyed-hash function with other cryptographic functions specified in the VPN Client ST (whether these are performed by the platform or by the TOE) is documented in the TSS. Requirement met by the platform For each platform listed in the ST, the evaluator shall examine the ST of the platform to ensure that the keyed hash function(s) claimed in that platform's ST contains the keyed hash function(s) in the VPN Client's ST. The evaluator shall also examine the TSS of the VPN Client's ST to verify that it describes (for each supported platform) how the keyed hash functionality is invoked for each digest size and key size selected in the VPN Client's ST (it should be noted that this may be through a mechanism that is not implemented by the VPN Client; nonetheless, that mechanism will be identified in the TSS as part of this assurance activity). Requirement met by the TOE Additionally, for all cases where the output of the HMAC following the hash calculation is truncated, the evaluator shall ensure that the TSS states for what operation this truncation takes place; the size of the final output; and the standard to which this truncation complies. The evaluator shall examine the TSS to ensure that it specifies the following values used by the HMAC function: keylength, hash function used, block size, and output MAC length used. GSS CCT Assurance Activity Report Page 15 of Gossamer Security Solutions, Inc.

16 This requirement is met by the TOE platform. The evaluator checked the Platform-ST and found in the FCS_COP.1(4 ) SFR that the TOE Platform provides the following keyed hashing algorithms; HMAC-SHA1, HMAC- SHA-256, HMAC-SHA-384, HMAC-SHA-512 with message digest sizes 160, 256, 384, 512. This matches the TOE s requirements exactly. The ST explains that the hash functions HMAC-SHA1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 are used as integrity/authentication algorithms as well as Diffie-Hellman Groups 5, 14, 19, 20 and 24. The TOE utilizes the cryptographic algorithm implementation of the TOE Platform by directly linking against the native BoringSSL cryptographic library through the native C API. In this way, the TOE can invoke the cryptographic operations provided by the TOE Platform (including the key establishment, key generation, encryption/decryption, random bit generation, digital signatures, hashing, and keyed hashing). Component Component Testing Assurance Activities: Requirement met by the TOE FIPS This requirement was met by the Platform so no additional testing is required EXTENDED: INTERNET PROTOCOL SECURITY (IPSEC) COMMUNICATIONS (FCS_IPSEC_EXT.1) FCS_IPSEC_EXT.1.1 TSS Assurance Activities: The evaluator shall examine the TSS and determine that it describes how the IPsec capabilities are implemented and how a packet is processed, e.g., what takes place at the platform and what takes place within the client. The TSS will detail the relationship between the client and the underlying platform, including which aspects are implemented by the client, and those that are provided by the underlying platform. The TSS describes how the client interacts with the platforms network stack (e.g., does the client insert itself within the stack via kernel mods, does the client simply invoke APIs to gain access to network services). If the SPD is implemented by the client, then the TSS describes how the SPD is implemented and the rules for processing both inbound and outbound packets in terms of the IPsec policy. The TSS describes the rules that are available and the resulting actions available after matching a rule. The TSS describes how those rules and actions form the SPD in terms of the BYPASS (e.g., no encryption), DISCARD (e.g., drop the packet), and PROTECT (e.g., encrypt the packet) actions defined in RFC As noted in section of RFC 4301, the processing of entries in the SPD is non-trivial and the evaluator shall determine that the description in the TSS is sufficient to determine which rules will be applied given the rule structure implemented by the TOE. For example, if the TOE allows specification of ranges, conditional rules, etc., the evaluator shall determine that the description of rule processing (for both inbound and outbound packets) is sufficient to determine the action that will be applied, especially in the case where two different rules may apply. This description shall cover both the initial packets (that is, no SA is established on the interface or for that GSS CCT Assurance Activity Report Page 16 of Gossamer Security Solutions, Inc.

17 particular packet) as well as packets that are part of an established SA. If the SPD is implemented by the underlying platform, then the TSS describes how the client interacts with the platform to establish and populate the SPD, including the identification of the platform's interfaces that are used by the client. Section 6.1 of the TSS explains that the TOE presents as few configuration options as possible to the user in order to minimize the possibility of misconfiguration and relies upon the Gateway to enforce organizational policies (for things like the specific cipher suites and selection of traffic to protect). For this reason, the TOE does not support editing of its SPD entries. The TOE will insert a PROTECT rule to IPsec encrypt and send all TOE traffic to the VPN GW (as the TOE ignores the IKEv1/IKEv2 Traffic Selector negotiated between the client and gateway and always sends all traffic). The TOE routes all packets through the kernel s IPsec interface (ipsec0) when the VPN is active. The kernel compares packets routed through this interface to the SPDs configured for the VPN to determine whether to PROTECT, BYPASS, or DISCARD each packet. The vendor designed the TOE s VPN, when operating in CC Mode, to allow no configuration and to always force all traffic through the VPN. The TOE ignores any IKEv1/IKEv2 traffic selector negotiations with the VPN GW and will always create an SPD PROTECT rule that matches all traffic. Thus, the kernel will match all packets, subsequently encrypt those packets, and finally forward them to the VPN Gateway Guidance Assurance Activities: The evaluator shall examine the operational guidance to verify it describes how the SPD is created and configured. If there is an administrative interface to the client, then the guidance describes how the administrator specifies rules for processing a packet. The description includes all three cases - a rule that ensures packets are encrypted/decrypted, dropped, and allowing a packet to flow in plaintext. The evaluator shall determine that the description in the operational guidance is consistent with the description in the TSS, and that the level of detail in the operational guidance is sufficient to allow the administrator to set up the SPD in an unambiguous fashion. This includes a discussion of how ordering of rules impacts the processing of an IP packet. If the client is configured by an application, such as the VPN gateway, then the operational guidance describes the client interface used by the application. The description contains information as to how the SPD is established and set up in an unambiguous fashion. The description includes what is configurable via the interface, how ordering of entries may be expressed, as well as the impacts that ordering of entries may have on the packet processing. In either case, the evaluator ensures the description provided In the TSS is consistent with the capabilities and description provided in the operational guidance. Section of the Admin-Guide explains the security functions implemented in the Gateway. It further explains in Section how to configure a Gateway (with a pointer to the User Guide). Testing Assurance Activities: The evaluator uses the operational guidance to configure the TOE and platform to carry out the following tests: Test 1: The evaluator shall configure the SPD such that there is a rule for dropping a packet, encrypting a packet, and allowing a packet to flow in plaintext. The selectors used in the construction of the rule shall be different such that the evaluator can generate a packet and send packets to the client with the appropriate fields (fields that are used by the rule - e.g., the IP addresses, TCP/UDP ports) in the packet header. The evaluator performs both GSS CCT Assurance Activity Report Page 17 of Gossamer Security Solutions, Inc.

18 positive and negative test cases for each type of rule. The evaluator observes via the audit trail, and packet captures that the TOE exhibited the expected behavior: appropriate packets were dropped, allowed through without modification, was encrypted by the IPsec implementation. Test 2: The evaluator shall devise several tests that cover a variety of scenarios for packet processing. These scenarios must exercise the range of possibilities for SPD entries and processing modes as outlined in the TSS and operational guidance. Potential areas to cover include rules with overlapping ranges and conflicting entries, inbound and outbound packets, and packets that establish SAs as well as packets that belong to established SAs. The evaluator shall verify, via the audit trail and packet captures, for each scenario that the expected behavior is exhibited, and is consistent with both the TSS and the operational guidance.. Test 1 &2 (run together) - Since control over SPDs is limited to connecting and disconnecting the VPN client, the evaluators showed that the platform was implementing BYPASS (allowing all traffic) until the point that the VPN client was connected to a gateway and then the evaluators showed that traffic was encrypted (PROTECT). The evaluators subsequently set up pings to show that when the BYPASS rule (client disconnected) was in effect the pings were successful, but once the VPN client was connected and the pings did not fall within scope of the VPN they were subject to DISCARD (no ping responses from the TOE, showing they were discarded by the TOE) FCS_IPSEC_EXT.1.2 TSS Assurance Activities: The evaluator checks the TSS to ensure it states that the VPN can be established to operate in tunnel mode and/or transport mode (as selected). The second paragraph of Section 6.1 says the TOE supports IPsec in tunnel mode (as selected in the SFR). Guidance Assurance Activities: The evaluator shall confirm that the operational guidance contains instructions on how to configure the connection in each mode selected. Instructions on configuring a connection in tunnel mode are included in the guidance. Section of the Admin-Guide specifies the Administrator settings for setting up a VPN connection (certificate, gateway, pre-shared key). Section 3.4 of the Users-Guide explains to users how to set up a VPN tunnel. Testing Assurance Activities: The evaluator shall perform the following test(s) based on the selections chosen: Test 1 (conditional): If tunnel mode is selected, the evaluator uses the operational guidance to configure the TOE/platform to operate in tunnel mode and also configures a VPN GW to operate in tunnel mode. The evaluator configures the TOE/platform and the VPN GW to use any of the allowable cryptographic algorithms, authentication methods, etc. to ensure an allowable SA can be negotiated. The evaluator shall then initiate a connection from the client to connect to the VPN GW peer. The evaluator observes (for example, in the audit trail and the captured packets) that a successful connection was established using the tunnel mode. Test 2 (conditional): If transport mode is selected, the evaluator uses the operational guidance to configure the TOE/platform to operate in transport mode and also configures a VPN GW to operate in transport mode. The evaluator configures the TOE/platform and the VPN GW to use any of the allowed cryptographic algorithms, GSS CCT Assurance Activity Report Page 18 of Gossamer Security Solutions, Inc.

19 authentication methods, etc. to ensure an allowable SA can be negotiated. The evaluator then initiates a connection from the TOE/platform to connect to the VPN GW. The evaluator observes (for example, in the audit trail and the captured packets) that a successful connection was established using the transport mode. Test 1 The evaluator configured a VPN gateway to require tunnel mode using a PSK. The device successfully connected to the VPN gateway and traffic log supports tunnel mode was used for the device. The evaluator performed this test for both IKEv1 and IKEv2 and it passed in both instances. Test 2 Not applicable as the TOE supports only tunnel mode FCS_IPSEC_EXT.1.3 TSS Assurance Activities: The evaluator shall examine the TSS to verify that the TSS provides a description of how a packet is processed against the SPD and that if no 'rules' are found to match, that a final rule exists, either implicitly or explicitly, that causes the network packet to be discarded. Section 6.1 of the TSS explains that the TOE presents as few configuration options as possible to the user in order to minimize the possibility of misconfiguration and relies upon the Gateway to enforce organizational policies (for things like the specific cipher suites and selection of traffic to protect). For this reason, the TOE does not support editing of its SPD entries. The TOE will insert a PROTECT rule to IPsec encrypt and send all TOE traffic to the VPN GW (as the TOE ignores the IKEv1/IKEv2 Traffic Selector negotiated between the client and gateway and always sends all traffic). The TOE routes all packets through the kernel s IPsec interface (ipsec0) when the VPN is active. The kernel compares packets routed through this interface to the SPDs configured for the VPN to determine whether or PROTECT, BYPASS, or DISCARD each packet. The vendor designed the TOE s VPN, when operating in CC Mode, to allow no configuration and to always force all traffic through the VPN. The TOE ignores any IKEv1/IKEv2 traffic selector negotiations with the VPN GW and will always create an SPD PROTECT rule that matches all traffic. Thus, the kernel will match all packets, subsequently encrypt those packets, and finally forward them to the VPN Gateway. Guidance Assurance Activities: The evaluator checks that the operational guidance provides instructions on how to construct the SPD and uses the guidance to configure the TOE/platform for the following tests. The TOE does not support editing of SPD entries. See the TSS assurance activity for an explanation. Testing Assurance Activities: The evaluator shall perform the following test: Test 1: The evaluator shall configure the SPD such that it has entries that contain operations that DISCARD, BYPASS, and PROTECT network packets. The evaluator may use the SPD that was created for verification of FCS_IPSEC_EXT.1.1. The evaluator shall construct a network packet that matches a BYPASS entry and send that packet. The evaluator should observe that the network packet is passed to the proper destination interface with no modification. The evaluator shall then modify a field in the packet header; such that it no longer matches the evaluator-created entries (there may be a 'TOE/platform created' final entry that discards packets that do not GSS CCT Assurance Activity Report Page 19 of Gossamer Security Solutions, Inc.

20 match any previous entries). The evaluator sends the packet, and observes that the packet was not permitted to flow to any of the TOE's interfaces. Test 1 The evaluator sent traffic to the TOE to ensure it could receive traffic and pass traffic to proper destinations on the network. The evaluator then connected the VPN and attempted to send traffic to the TOE outside the VPN. The traffic was discarded as expected FCS_IPSEC_EXT.1.4 TSS Assurance Activities: The evaluator shall examine the TSS to verify that the algorithms AES-GCM-128 and AES- GCM-256 are implemented. If the ST author has selected either AES-CBC-128 or AES-CBC-256 in the requirement, then the evaluator verifies the TSS describes these as well. In addition, the evaluator ensures that the SHA-based HMAC algorithm conforms to the algorithms specified in FCS_COP.1(4) Cryptographic Operations (for keyed-hash message authentication). Section 6.1 of the ST states TOE implements RFC 4106 conformant AES-GCM-128, and AES-GCM-256, and RFC 3602 conformant AES-CBC-128, and AES-CBC-256 as encryption algorithms. Section 6.1 also states the TOE implements HMAC-SHA1, SHA-256, SHA-384, and SHA-512 as authentication algorithms. Guidance Assurance Activities: The evaluator checks the operational guidance to ensure it provides instructions on how to configure the TOE/platform to use the AES-GCM-128, and AES-GCM-256 algorithms, and if either AES- CBC-128 or AES-CBC-256 have been selected the guidance instructs how to use these as well. Section 3.2 of the User -Guide and Section of the Admin-Guide provide instructions for configuring the device into CC mode. For the VPN configuration, CC Mode only needs to be Enforced as that will set the required FIPS encryption. The TOE does not need to be configured to support specific encryption algorithms. The TOE will respond with the appropriate algorithm to the VPN Gateway. Testing Assurance Activities: Test 1: The evaluator shall configure the TOE/platform as indicated in the operational guidance configuring the TOE/platform to using each of the AES-GCM-128, and AES-GCM-256 algorithms, and attempt to establish a connection using ESP. If the ST Author has selected either AES-CBC-128 or AES-CBC-256, the TOE/platform is configured to use those algorithms and the evaluator attempts to establish a connection using ESP for those algorithms selected. Test 1 - The evaluator made an IPsec connection to a VPN gateway using each of the claimed IPsec ESP ciphersuites (AES-GCM-128, AES-GCM-256, AES-CBC-128 and AES-CBC-256). The evaluator was able to capture each ciphersuite using a packet capture FCS_IPSEC_EXT.1.5 TSS Assurance Activities: The evaluator shall examine the TSS to verify that IKEv1 and/or IKEv2 are implemented. Section 6.1 of the TSS states that the TOE provides IKEv1 and IKEv2 key establishment as part of its IPsec implementation. GSS CCT Assurance Activity Report Page 20 of Gossamer Security Solutions, Inc.

21 Guidance Assurance Activities: The evaluator shall check the operational guidance to ensure it instructs the administrator how to configure the TOE/platform to use IKEv1 and/or IKEv2 (as selected), and uses the guidance to configure the TOE/platform to perform NAT traversal for the following test. Section 3.2 of the User -Guide and Section of the Admin-Guide provide instructions for configuring the device into CC mode. For the VPN configuration, CC Mode only needs to be Enforced as that will set the required FIPS encryption. No configuration is necessary for IKEv1/IKEv2 and NAT traversal. The TOE supports each automatically. Testing Assurance Activities: Test 1: The evaluator shall configure the TOE/platform so that it will perform NAT traversal processing as described in the TSS and RFC 5996, section The evaluator shall initiate an IPsec connection and determine that the NAT is successfully traversed. Test 1 The evaluator put the device behind a NAT router. The evaluator then connected the device to the VPN gateway using PSK. The packet capture of the traffic demonstrates that the connection with the NAT router was working. The evaluator performed this test for both IKEv1 and IKEv2 and it passed in both instances FCS_IPSEC_EXT.1.6 TSS Assurance Activities: The evaluator shall ensure the TSS identifies the algorithms used for encrypting the IKEv1 and/or IKEv2 payload, and that the algorithms AES-CBC-128, AES-CBC-256 are specified, and if others are chosen in the selection of the requirement, those are included in the TSS discussion. Section 6.1 of the TSS states the encrypted payload for IKEv1/IKEv2 uses AES-CBC-128, AES-CBC-256 as specified in RFC 6379 and AES-GCM-128 and AES-GCM-256 as specified in RFC Guidance Assurance Activities: The evaluator ensures that the operational guidance describes the configuration of the mandated algorithms, as well as any additional algorithms selected in the requirement. The guidance is then used to configure the TOE/platform to perform the following test for each ciphersuite selected. Section 3.2 of the User -Guide and Section of the Admin-Guide provide instructions for configuring the device into CC mode. For the VPN configuration, CC Mode only needs to be Enforced as that will set the required FIPS encryption. The TOE does not need to be configured to support specific encryption algorithms. The TOE will respond with the appropriate algorithm to the VPN Gateway. Testing Assurance Activities: Test 1: The evaluator shall configure the TOE/platform to use the ciphersuite under test to encrypt the IKEv1 and/or IKEv2 payload and establish a connection with a peer device, which is configured to only accept the payload encrypted using the indicated ciphersuite. The evaluator will confirm the algorithm was that used in the negotiation. Test 1 - The evaluator made an IPsec connection to a VPN gateway using each of the claimed IKE ciphersuites. The evaluator was able to capture each ciphersuite using a packet capture. This test was performed for IKEv1 and IKEv2 and it passed in both instances FCS_IPSEC_EXT.1.7 GSS CCT Assurance Activity Report Page 21 of Gossamer Security Solutions, Inc.

22 TSS Assurance Activities: The evaluator shall examine the TSS to ensure that, in the description of the IPsec protocol, it states that aggressive mode is not used for IKEv1 Phase 1 exchanges, and that only main mode is used. It may be that this is a configurable option. Section 6.1 states IKEv1 only supports main mode and requires no configuration for this enforcement. Guidance Assurance Activities: If the mode requires configuration of the TOE/platform prior to its operation, the evaluator shall check the operational guidance to ensure that instructions for this configuration are contained within that guidance. No configuration is necessary as IKEv1 only supports main mode. Testing Assurance Activities: Test 1 (conditional): The evaluator shall configure the TOE/platform as indicated in the operational guidance, and attempt to establish a connection using an IKEv1 Phase 1 connection in aggressive mode. This attempt should fail. The evaluator should then show that main mode exchanges are supported. This test is not applicable if IKEv1 is not selected above in the FCS_IPSEC_EXT.1.5 protocol selection. The evaluator configured the VPN Gateway to request IKEv1 main mode. The connection was successful. The evaluator then configured the VPN Gateway to request IKEv1 aggressive mode. The client connected using main mode as aggressive mode is not supported FCS_IPSEC_EXT.1.8 Guidance Assurance Activities: The evaluator verifies that the values for SA lifetimes can be configured and that the instructions for doing so are located in the operational guidance. If time-based limits are supported, the evaluator ensures that either the Administrator or VPN Gateway are able to configurable Phase 1 SAs values for 24 hours and 8 hours for Phase 2 SAs. Currently there are no values mandated for the number of packets or number of bytes, the evaluator just ensures that this can be configured if selected in the requirement. The TOE does not need to be configured to support SA lifetimes. The TOE will support the lifetime values configured on the VPN Gateway. An administrator can configure the VPN Gateway to limit SA lifetimes based on length of time to values that include 24 hours for IKE SAs and 8 hours for IPsec SAs. The TOE includes hardcoded limits of 10 hours for an IKE SA and 3 hours for an IPsec SA. The TOE and VPN Gateway will rekey their IKE and IPsec SAs after the shorter of either 10 hours and 3 hours respectively (the TOE s fixed lifetimes) or the administrator specified lifetime configured on the VPN Gateway. Testing Assurance Activities: When testing this functionality, the evaluator needs to ensure that both sides are configured appropriately. From the RFC 'A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes were negotiated. In IKEv2, each end of the SA is responsible for enforcing its own lifetime policy on the SA and rekeying the SA when necessary. If the two ends have different lifetime policies, the end with the shorter lifetime will end up always being the one to request the rekeying. If the two ends have the same lifetime policies, it is possible that GSS CCT Assurance Activity Report Page 22 of Gossamer Security Solutions, Inc.

23 both will initiate a rekeying at the same time (which will result in redundant SAs). To reduce the probability of this happening, the timing of rekeying requests SHOULD be jittered.' Each of the following tests shall be performed for each version of IKE selected in the FCS_IPSEC_EXT.1.5 protocol selection: Test 1 (Conditional): The evaluator shall configure a maximum lifetime in terms of the # of packets (or bytes) allowed following the operational guidance. The evaluator shall establish an SA and determine that once the allowed # of packets (or bytes) through this SA is exceeded, the connection is closed. Test 2 (Conditional): The evaluator shall construct a test where a Phase 1 SA is established and attempted to be maintained for more than 24 hours before it is renegotiated. The evaluator shall observe that this SA is closed or renegotiated in 24 hours or less. If such an action requires that the TOE be configured in a specific way, the evaluator shall implement tests demonstrating that the configuration capability of the TOE works as documented in the operational guidance. Test 3 (Conditional): The evaluator shall perform a test similar to Test 1 for Phase 2 SAs, except that the lifetime will be 8 hours instead of 24. Test 1 This test is not applicable because that packet quantity option was not selected in the requirement. Test 2 The evaluator configured a Phase 1 SA lifetime timeout of 25 hours on the VPN server. The evaluator then established a connection with the VPN. The IPsec SA timed out after just under 10 hours and the connection reset. The evaluator repeated this test for IKEv1 and IKE v2 and it passed in both instances. Test 3 - The evaluator configured a Phase 2 SA lifetime timeout of 9 hours for on the VPN server. The evaluator then established a connection with the VPN. The IPsec SA timed out after just under 3 hours and the connection reset. The evaluator repeated this test for IKEv1 and IKE v2 and it passed in both instances FCS_IPSEC_EXT.1.9 TSS Assurance Activities: The evaluator shall check to ensure that, for each DH group supported, the TSS describes the process for generating 'x' (as defined in FCS_IPSEC_EXT.1.9) and each nonce. The evaluator shall verify that the TSS indicates that the random number generated that meets the requirements in this PP is used, and that the length of 'x' and the nonces meet the stipulations in the requirement. Section 6.1 states the nonce is generated using a FIPS validated RBG with lengths of 224, 256, and 384 bits. The TSS also has all supported DH groups listed along with their group values (e.g., 14 (2048-bit MODP), 19 (256-bit Random ECP)). GSS CCT Assurance Activity Report Page 23 of Gossamer Security Solutions, Inc.

24 FCS_IPSEC_EXT.1.10 TSS Assurance Activities: The evaluator shall check to ensure that, for each DH group supported, the TSS describes the process for generating 'x' (as defined in FCS_IPSEC_EXT.1.9) and each nonce. The evaluator shall verify that the TSS indicates that the random number generated that meets the requirements in this PP is used, and that the length of 'x' and the nonces meet the stipulations in the requirement. See the analysis for FCS_IPSEC_EXT.1.9. This AA is a repeat of the previous AA FCS_IPSEC_EXT.1.11 TSS Assurance Activities: The evaluator shall check to ensure that the DH groups specified in the requirement are listed as being supported in the TSS. If there is more than one DH group supported, the evaluator checks to ensure the TSS describes how a particular DH group is specified/negotiated with a peer. Section 6.1 of the ST states the TOE supports the following DH groups: 5, 14, 19, 20 and 24. The TOE selects the DH group by selecting the largest group configured by an administrator that is offered by the VPN gateway. Testing Assurance Activities: The evaluator shall also perform the following test: Test 1: For each supported DH group, the evaluator shall test to ensure that all supported IKE protocols can be successfully completed using that particular DH group. Test 1 - The evaluator made an IPsec connection to a VPN gateway using each of the claimed DH groups. The evaluator was able to capture each DH group using a packet capture. The evaluator repeated this test for IKEv1 and IKE v2 and it passed in both instances FCS_IPSEC_EXT.1.12 TSS Assurance Activities: The evaluator ensures that the TSS identifies RSA and/or ECDSA as being used to perform peer authentication. The description must be consistent with the algorithms as specified in FCS_COP.1(2) Cryptographic Operations (for cryptographic signature). GSS CCT Assurance Activity Report Page 24 of Gossamer Security Solutions, Inc.

25 If pre-shared keys are chosen in the selection, the evaluator shall check to ensure that the TSS describes how preshared keys are established and used in authentication of IPsec connections. The evaluator shall check that the operational guidance describes how pre-shared keys are to be generated and established. The description in the TSS and the operational guidance shall also indicate how pre-shared key establishment is accomplished for TOEs/platforms that can generate a pre-shared key as well as TOEs/platforms that simply use a pre-shared key. Section 6.1 of the TSS states that the TOE implements peer authentication using RSA certificates or ECDSA certificates that conform to RFC 4945, or pre-shared keys for IKEv2 and RSA certificates or pre-shared keys for IKEv1. The FCS_COP.1(2) SFR does support both RSA and ECDSA certificates. For pre-shared keys, section 6.1 states the TOE does not perform any processing on pre-shared keys. The TOE simply uses the pre-shared key that was entered by the administrator. Guidance Assurance Activities: The evaluator ensures the operational guidance describes how to set up the TOE/platform to use the cryptographic algorithms RSA and/or ECDSA. In order to construct the environment and configure the TOE/platform for the following tests, the evaluator will ensure that the operational guidance also describes how to configure the TOE/platform to connect to a trusted CA, and ensure a valid certificate for that CA is loaded into the TOE/platform and marked 'trusted'. Section of the Admin-Guide provides the settings for the selecting the cryptographic algorithm in the VPN Type setting. The same section also identifies the settings for selecting certificates. Section 3.5 in the User-Guide addresses certificate management. It explains how to import certificates into the Trust Anchor Database and how to import and remove certificates. Testing Assurance Activities: For efficiency sake, the testing that is performed here has been combined with the testing for FIA_X509_EXT.2.1 (for IPsec connections), FCS_IPSEC_EXT.1.13, and FIA_X509_EXT.2.3. The following tests shall be repeated for each peer authentication protocol selected in the FCS_IPSEC_EXT.1.12 selection above: Test 1: The evaluator shall have the TOE/platform generate a public-private key pair, and submit a CSR (Certificate Signing Request) to a CA (trusted by both the TOE/platform and the peer VPN used to establish a connection) for its signature. The values for the DN (Common Name, Organization, Organizational Unit, and Country) will also be passed in the request. Test 2: The evaluator shall use a certificate signed using the RSA or ECDSA algorithm to authenticate the remote peer during the IKE exchange. This test ensures the remote peer has the certificate for the trusted CA that signed the TOE's certificate and it will do a bit-wise comparison on the DN. This bit-wise comparison of the DN ensures that not only does the peer have a certificate signed by the trusted CA, but the certificate is from the DN that is expected. The evaluator will configure the TOE/platform to associate a certificate (e.g., a certificate map in some implementations) with a VPN connection. This is what the DN is checked against. Test 3: The evaluator shall test that the TOE/platform can properly handle revoked certificates - conditional on whether CRL or OCSP is selected; if both are selected, and then a test is performed for each method. For this draft of the PP, the evaluator has to only test one up in the trust chain (future drafts may require to ensure the GSS CCT Assurance Activity Report Page 25 of Gossamer Security Solutions, Inc.

26 validation is done up the entire chain). The evaluator shall ensure that a valid certificate is used, and that the SA is established. The evaluator then attempts the test with a certificate that will be revoked (for each method chosen in the selection) to ensure when the certificate is no longer valid that the TOE/platform will not establish an SA. Test 4: The evaluator shall test that given a signed certificate from a trusted CA, that when the DN does not match - any of the four fields can be modified such that they do not match the expected value, that an SA does not get established. Test 5: Deleted by TD Test 6 [conditional]: The evaluator shall generate a pre-shared key and use it, as indicated in the operational guidance, to establish an IPsec connection with the VPN GW peer. If the generation of the pre-shared key is supported, the evaluator shall ensure that establishment of the key is carried out for an instance of the TOE/platform generating the key as well as an instance of the TOE/platform merely taking in and using the key. Test 1 - The TOE doesn t generate certificate requests, but rather requires certificates to be loaded through the device UI or via an MDM. The certificates for this set of tests were generated outside the TOE and loaded into the TOE. Test 2 The evaluator configured the server to require RSA certificates for authentication for VPN connections. The evaluator then attempted to make a connection using a RSA client certificate. The connection succeeded. The evaluator re-configured to require ECDSA certificate encryption. The evaluator then attempted to make a connection using an ECDSA client certificate. The connection succeeded. The evaluator performed only the RSA connection for the IKEv1 configuration and both for IKEv2. Test 3 The evaluator revoked the VPN gateway s certificate and then attempted to make a connection to the VPN gateway. The connection failed because the gateway s certificate was not valid. The evaluator repeated this test for IKEv1 and IKEv2 and it passed in both instances. Test 4 - The evaluator imported a trusted CA certificate using a poorly defined DN value with the CN name misspelled. The evaluator configured the server to require RSA certificates for authentication for VPN connections. The evaluator then attempted to make a connection using a RSA client certificate loaded. The connection failed because of the bad server certificate. This part of the test was repeated for IKEv1 and IKEv2 and it passed in both instances. The evaluator re-configured to require ECDSA certificate encryption using a poorly defined DN with a misspelled CN. The evaluator then attempted to make a connection using an ECDSA client certificate loaded. The connection failed because of the bad server certificate. This part of the test was run on IKEv2 only. Test 5 Omitted per TD0053. This test is duplicative with FIA_X509_EXT.2.2. Test 6 - The TOE does not generate pre-shared keys. GSS CCT Assurance Activity Report Page 26 of Gossamer Security Solutions, Inc.

27 FCS_IPSEC_EXT.1.13 TSS Assurance Activities: (Per TD0037) The assurance activities for this element are performed in conjunction with the assurance activities for the next element. Per TD0037, refer to the assurance activities in FCS_IPSEC_EXT FCS_IPSEC_EXT.1.14 TSS Assurance Activities: (Per TD0037) The evaluator shall ensure that the TSS describes how the TOE compares the peer's presented identifier to the reference identifier. This description shall include whether the certificate presented identifier is compared to the ID payload presented identifier, which field(s) of the certificate are used as the presented identifier (DN, Common Name, or SAN), and, if multiple fields are supported, the logical order comparison. If the ST author assigned an additional identifier type, the TSS description shall also include a description of that type and the method by which that type is compared to the peer's presented certificate. Section 6.1 of the ST states that If certificates are used, the TOE ensures that the IP address 1 or Fully Qualified Distinguished Name (FQDN) contained in a certificate matches the expected IP Address or FQDN for the entity attempting to establish a connection and ensures that the certificate has not been revoked (using the Online Certificate Status Protocol [OCSP] in accordance with RFC 2560). Guidance Assurance Activities: (Per TD0037) The evaluator shall ensure that the operational guidance includes the configuration of the reference identifier(s) for the peer. Section 3.4 of the User Guide describes creating a VPN tunnel and includes configuring the server address which consists of a FQDN or an IP address. Testing Assurance Activities: (Per TD0037) For each supported identifier type (excluding DNs), the evaluator shall repeat the following tests: Test 1: For each field of the certificate supported for comparison, the evaluator shall configure the peer's reference identifier on the TOE (per the administrative guidance) to match the field in the peer's presented certificate and shall verify that the IKE authentication succeeds. 1 The TOE only accepts IPv4 addresses when matching a certificate IP address. GSS CCT Assurance Activity Report Page 27 of Gossamer Security Solutions, Inc.

28 Test 2: For each field of the certificate support for comparison, the evaluator shall configure the peer's reference identifier on the TOE (per the administrative guidance) to not match the field in the peer's presented certificate and shall verify that the IKE authentication fails. The following tests are conditional: Test 3: (conditional) If, according to the TSS, the TOE supports both Common Name and SAN certificate fields and uses the preferred logic outlined in the Application Note, the tests above with the Common Name field shall be performed using peer certificates with no SAN extension. Additionally, the evaluator shall configure the peer's reference identifier on the TOE to not match the SAN in the peer's presented certificate but to match the Common Name in the peer's presented certificate, and verify that the IKE authentication fails. Test 4: (conditional) If the TOE supports DN identifier types, the evaluator shall configure the peer's reference identifier on the TOE (per the administrative guidance) to match the subject DN in the peer's presented certificate and shall verify that the IKE authentication succeeds. To demonstrate a bit-wise comparison of the DN, the evaluator shall change a single bit in the DN (preferably, in an Object Identifier (OID) in the DN) and verify that the IKE authentication fails. Test 5: (conditional) If the TOE supports both IPv4 and IPv6 and supports IP address identifier types, the evaluator must repeat test 1 and 2 with both IPv4 address identifiers and IPv6 identifiers. Additionally, the evaluator shall verify that the TOE verifies that the IP header matches the identifiers by setting the presented identifiers and the reference identifier with the same IP address that differs from the actual IP address of the peer in the IP headers and verifying that the IKE authentication fails. Test 6: (conditional) If, according to the TSS, the TOE performs comparisons between the peer's ID payload and the peer's certificate, the evaluator shall repeat the following test for each combination of supported identifier types and supported certificate fields (as above). The evaluator shall configure the peer to present a different ID payload than the field in the peer's presented certificate and verify that the TOE fails to authenticate the IKE peer. Test 1: The evaluator configures the peer s reference identifier on the TOE (the configuration supports FQDN or IP address for the VPN Gateway) to match the field in the peer s presented certificate. IKE authentication succeeds. Test 2: The evaluator configures the peer s reference identifier on the TOE (the configuration supports FQDN or IP address for the VPN Gateway) to mismatch the field in the peer s presented certificate. IKE authentication fails. Test 3: Not Applicable. Test 4: The evaluator configures the TOE and the peer with mismatched DNS address. The IKE authentication fails. Test 5: Not Applicable. Test 6: Not Applicable. Component GSS CCT Assurance Activity Report Page 28 of Gossamer Security Solutions, Inc.

29 Component Component FCS_IPSEC_EXT.1.15 TSS Assurance Activities: The evaluator shall check that the TSS describes the potential strengths (in terms of the number of bits in the symmetric key) of the algorithms that are allowed for the IKE and ESP exchanges. The TSS shall also describe the checks that are done when negotiating IKEv1 Phase 2 and/or IKEv2 CHILD_SA suites to ensure that the strength (in terms of the number of bits of key in the symmetric algorithm) of the negotiated algorithm is less than or equal to that of the IKE SA this is protecting the negotiation. Section 6.1 of the TSS states the TOE implements RFC 4106 conformant AES-GCM-128, and AES-GCM-256, and RFC 3602 conformant AES-CBC-128, and AES-CBC-256 as encryption algorithms. The TOE implements HMAC-SHA1, SHA-256, SHA-384, and SHA-512 as authentication algorithms as well as Diffie-Hellman Groups 5, 14, 19, 20 and 24. The encrypted payload for IKEv1/IKEv2 uses AES-CBC-128, AES-CBC-256 as specified in RFC The TOE relies upon the VPN Gateway to ensure that by default the strength of the symmetric algorithm (in terms of the number of bits in the key) negotiated to protect the IKEv1 Phase 1/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 IKEv1 Phase 2/IKEv2 CHILD_SA connection. Testing Assurance Activities: The evaluator simply follows the guidance to configure the TOE/platform to perform the following tests. Test 1: This test shall be performed for each version of IKE supported. The evaluator shall successfully negotiate an IPsec connection using each of the supported algorithms and hash functions identified in the requirements. Test 2: This test shall be performed for each version of IKE supported. The evaluator shall attempt to establish an SA for ESP that selects an encryption algorithm with more strength than that being used for the IKE SA (i.e., symmetric algorithm with a key size larger than that being used for the IKE SA). Such attempts should fail. Test 3: This test shall be performed for each version of IKE supported. The evaluator shall attempt to establish an IKE SA using an algorithm that is not one of the supported algorithms and hash functions identified in the requirements. Such an attempt should fail. Test 4: This test shall be performed for each version of IKE supported. The evaluator shall attempt to establish an SA for ESP (assumes the proper parameters where used to establish the IKE SA) that selects an encryption algorithm that is not identified in FCS_IPSEC_EXT.1.4. Such an attempt should fail. GSS CCT Assurance Activity Report Page 29 of Gossamer Security Solutions, Inc.

30 Test 1 All of the algorithms were already tested in The evaluator focused on the hashes for this test and configured the VPN gateway to request each hash (one at a time). The evaluator then connected the device using each claimed hash successfully. This test was repeated for IKEv1 and IKEv2 and it passed in both instances. Test 2 This property is not enforced by the TOE but rather must be enforced by the VPN gateway since it determines the applicable cipher strengths. As such there is no applicable test. Test 3 - The evaluator configured the VPN gateway to use an unallowed cipher. The evaluator then attempted to connect the device with the VPN gateway. The connection was refused because the unallowed cipher is not supported. This test was repeated for IKEv1 and IKEv2 and it passed in both instances. Test 4 The evaluator configured the VPN gateway to use the unallowed cipher to establish an SA for ESP. The evaluator then attempted to connect the device with the VPN gateway. The connection was refused because the unallowed cipher is not supported to establish an SA for ESP. This test was repeated for IKEv1 and IKEv2 and it passed in both instances. For all of these tests, the TRRT agreed it is acceptable to initiate communications from the VPN Gateway. Component Component Component EXTENDED: CRYPTOGRAPHIC OPERATION (RANDOM BIT GENERATION) (FCS_RBG_EXT.1) FCS_RBG_EXT FCS_RBG_EXT.1.2 GSS CCT Assurance Activity Report Page 30 of Gossamer Security Solutions, Inc.

31 Component TSS Assurance Activities: Requirement met by the platform For each platform listed in the ST, the evaluator shall examine the ST of the platform to ensure that the RBG functions claimed in that platform's ST contains the RBG functions in the VPN Client's ST. The evaluator shall also examine the TSS of the VPN Client's ST to verify that it describes (for each supported platform) how the RBG functionality is invoked for each operation they are used for in the VPN client (it should be noted that this may be through a mechanism that is not implemented by the VPN Client; nonetheless, that mechanism will be identified in the TSS as part of this assurance activity). Requirement met by the TOE Documentation shall be produced-and the evaluator shall perform the activities-in accordance with Appendix E. If the ST author has selected a platform-based noise source, the evaluator shall verify that the platform's RBG has been validated by examining the platform's ST. The evaluator shall verify that the platform's RBG is seeded with at least the amount of entropy selected by the ST author for this profile. In this case, the ST author is not responsible for Annex E documentation of the platform's RBG. This requirement is met by the TOE platform. The evaluator checked the Platform-ST and found in the FCS_RBG.1 SFR that the TOE Platform provides the CTR_DRBG (AES) with a minimum of 256 bits of entropy as required by the TOE s SFR. The TOE uses the platform DRBG by linking against the native BoringSSL cryptographic library via either a Java API or through the native C API. Component Component Testing Assurance Activities: Requirement met by the TOE The evaluator shall also perform the following tests, depending on the standard to which the RBG conforms. Implementations Conforming to FIPS 140-2, Annex C The reference for the tests contained in this section is The Random Number Generator Validation System (RNGVS). The evaluators shall conduct the following two tests. Note that the 'expected values' are produced by a reference implementation of the algorithm that is known to be correct. Proof of correctness is left to each Scheme. The evaluators shall perform a Variable Seed Test. The evaluators shall provide a set of 128 (Seed, DT) pairs to the TSF RBG function, each 128 bits. The evaluators shall also provide a key (of the length appropriate to the AES algorithm) that is constant for all 128 (Seed, DT) pairs. The DT value is incremented by 1 for each set. The seed values shall have no repeats within the set. The evaluators ensure that the values returned by the TSF match the expected values. The evaluators shall perform a Monte Carlo Test. For this test, they supply an initial Seed and DT value to the TSF RBG function; each of these is 128 bits. The evaluators shall also provide a key (of the length appropriate to the GSS CCT Assurance Activity Report Page 31 of Gossamer Security Solutions, Inc.

32 AES algorithm) that is constant throughout the test. The evaluators then invoke the TSF RBG 10,000 times, with the DT value being incremented by 1 on each iteration, and the new seed for the subsequent iteration produced as specified in NIST-Recommended Random Number Generator Based on ANSI X9.31 Appendix A.2.4 Using the 3-Key Triple DES and AES Algorithms, Section 3. The evaluators ensure that the 10,000th value produced matches the expected value. Implementations Conforming to NIST Special Publication The evaluator shall perform 15 trials for the RNG implementation. If the RNG is configurable, the evaluator shall perform 15 trials for each configuration. The evaluator shall also confirm that the operational guidance contains appropriate instructions for configuring the RNG functionality. If the RNG has prediction resistance enabled, each trial consists of (1) instantiate drbg, (2) generate the first block of random bits (3) generate a second block of random bits (4) uninstantiate. The evaluator verifies that the second block of random bits is the expected value. The evaluator shall generate eight input values for each trial. The first is a count (0-14). The next three are entropy input, nonce, and personalization string for the instantiate operation. The next two are additional input and entropy input for the first call to generate. The final two are additional input and entropy input for the second call to generate. These values are randomly generated. 'Generate one block of random bits' means to generate random bits with number of returned bits equal to the Output Block Length (as defined in NIST SP ). If the RNG does not have prediction resistance, each trial consists of (1) instantiate drbg, (2) generate the first block of random bits (3) reseed, (4) generate a second block of random bits (5) uninstantiate. The evaluator verifies that the second block of random bits is the expected value. The evaluator shall generate eight input values for each trial. The first is a count (0-14). The next three are entropy input, nonce, and personalization string for the instantiate operation. The fifth value is additional input to the first call to generate. The sixth and seventh are additional input and entropy input to the call to reseed. The final value is additional input to the second generate call. The following paragraphs contain more information on some of the input values to be generated/selected by the evaluator. Entropy input: the length of the entropy input value must equal the seed length. Nonce: If a nonce is supported (CTR_DRBG with no df does not use a nonce), the nonce bit length is one-half the seed length. Personalization string: The length of the personalization string must be <= seed length. If the implementation only supports one personalization string length, then the same length can be used for both values. If more than one string length is support, the evaluator shall use personalization strings of two different lengths. If the implementation does not use a personalization string, no value needs to be supplied. GSS CCT Assurance Activity Report Page 32 of Gossamer Security Solutions, Inc.

33 Additional input: the additional input bit lengths have the same defaults and restrictions as the personalization string lengths. This requirement was met by the Platform so no additional testing is required. 2.2 USER DATA PROTECTION (FDP) FULL RESIDUAL INFORMATION PROTECTION (FDP_RIP.2) FDP_RIP.2.1 Component TSS Assurance Activities: Requirement met by the platform For each platform listed in the ST, the evaluator shall examine the ST of the platform to ensure that residual information protection measures with respect to network packets passing through the platform are claimed in that platform's ST. The evaluator shall also examine the TSS of the VPN Client's ST to verify that it describes (for each supported platform) the extent to which the client processes network packets and addresses the FDP_RIP.2 requirement. Requirement met by the TOE 'Resources' in the context of this requirement are network packets being sent through (as opposed to 'to', as is the case when a security administrator connects to the TOE) the TOE. The concern is that once a network packet is sent, the buffer or memory area used by the packet still contains data from that packet, and that if that buffer is re-used, those data might remain and make their way into a new packet. The evaluator shall check to ensure that the TSS describes packet processing to the extent that they can determine that no data will be reused when processing network packets. The evaluator shall ensure that this description at a minimum describes how the previous data are zeroized/overwritten, and at what point in the buffer processing this occurs. Section 6.2 of the TSS states the TOE has been designed to ensure that no residual information exists in network packets. When the TOE allocates a new buffer for a network packet, the new packet data will be used to overwrite any previous data in the buffer. If an allocated buffer exceeds the size of the packet, any additional space will be overwritten (padded) with zeroes before the packet is forwarded (to the external network or delivered to the appropriate, internal application. GSS CCT Assurance Activity Report Page 33 of Gossamer Security Solutions, Inc.

34 Component Component 2.3 IDENTIFICATION AND AUTHENTICATION (FIA) EXTENDED: PRE-SHARED KEY COMPOSITION (FIA_PSK_EXT.1) FIA_PSK_EXT FIA_PSK_EXT FIA_PSK_EXT.1.3 Component TSS Assurance Activities: Requirement met by the platform For each platform listed in the ST, the evaluator shall examine the ST of the platform to ensure that the functions associated with pre-shared keys claimed in that platform's ST contains the same functions specified in the VPN Client's ST. If the TOE does not perform any management or input of the pre-shared keys then no further activity is required; however, any management functions related to pre-shared keys that is performed by the TOE must be specified in the TOE's operational guidance and verified by the evaluator. GSS CCT Assurance Activity Report Page 34 of Gossamer Security Solutions, Inc.

35 Regardless of whether this capability is implemented by the TOE or by the platform, the tests listed in the 'Requirement met by the TOE' section must still be performed for each platform claimed in the ST. Requirement met by the TOE The evaluator shall examine the TSS to ensure that it states that text-based pre-shared keys of 22 characters are supported. If 'text-based pre-shared keys' is selected, the evaluator shall confirm that the TSS states the conditioning that takes place to transform the text-based pre-shared key from the key sequence entered by the user (e.g., ASCII representation) to the bit string used by IPsec, and that this conditioning is consistent with the last selection in the FIA_PSK_EXT.1.3 requirement. Section 6.1 of the TSS states that pre-shared keys can include any letter from a-z, A-Z, the numbers 0 9, and any special character located above the numbers on the keyboard. The specific length of 22 characters required by the VPNCPP14 is supported by the TOE. The TOE does not perform any processing on pre-shared keys. The TOE simply uses the pre-shared key that was entered by the administrator. This description is consistent with the FIA_PSK_EXT.1.3 requirement. Component Guidance Assurance Activities: Requirement met by the TOE The evaluator shall examine the operational guidance to determine that it provides guidance on the composition of strong text-based pre-shared keys, and (if the selection indicates keys of various lengths can be entered) that it provides information on the merits of shorter or longer pre-shared keys. The guidance must specify the allowable characters for pre-shared keys, and that list must be a super-set of the list contained in FIA_PSK_EXT.1.2. If 'bit-based pre-shared keys' is selected, the evaluator shall confirm the operational guidance contains instructions for either entering bit-based pre-shared keys for each protocol identified in the requirement, or generating a bitbased pre-shared key (or both). The evaluator shall also examine the TSS to ensure it describes the process by which the bit-based pre-shared keys are generated (if the TOE supports this functionality), and confirm that this process uses the RBG specified in FCS_RBG_EXT.1. Section of the Admin-Guide provides guidance for selecting a strong pre-shared key. The guidance identifies the entire character set claimed in the SFR and offers suggestions such as do not use names or easily guessed words. The guidance recommends using at least 20 characters to ensure a strong pre-shared key. The guidance also explains how to enter HEX-based keys. HEX keys must start with 0x as the first two characters entered. If those are the first two characters, the remaining entry will be read as a HEX key. Component Testing Assurance Activities: Requirement met by the TOE The evaluator shall also perform the following tests: Test 1: The evaluator shall compose a pre-shared key of 22 characters that contains a combination of the allowed characters in accordance with the operational guidance, and demonstrates that a successful protocol negotiation can be performed with the key. GSS CCT Assurance Activity Report Page 35 of Gossamer Security Solutions, Inc.

36 Test 2 [conditional]: If the TOE supports pre-shared keys of multiple lengths, the evaluator shall repeat Test 1 using the minimum length; the maximum length; and an invalid length. The minimum and maximum length tests should be successful, and the invalid length must be rejected by the TOE. Test 3 [conditional]: If the TOE does not generate bit-based pre-shared keys, the evaluator shall obtain a bit-based pre-shared key of the appropriate length and enter it according to the instructions in the operational guidance. The evaluator shall then demonstrate that a successful protocol negotiation can be performed with the key. Test 4 [conditional]: If the TOE does generate bit-based pre-shared keys, the evaluator shall generate a bit-based pre-shared key of the appropriate length and use it according to the instructions in the operational guidance. The evaluator shall then demonstrate that a successful protocol negotiation can be performed with the key. Test 1 - The evaluator created a pre-shared key of 22 characters that contained a combination of the allowed characters. The evaluator then successfully connected the device to the VPN gateway demonstrating a successful connection. Test 2 - The evaluator created a pre-shared key of maximum length of 64 characters. The evaluator then successfully connected the device to the VPN gateway demonstrating a successful connection. The evaluator created a pre-shared key of minimum length of 1 character. The evaluator then successfully connected the device to the VPN gateway demonstrating a successful connection. The evaluator then attempted to create a pre-shared key of 0 length, an invalid option. The evaluator found that the configurations cannot be saved with a 0-length pre-shared key. Test 3 The evaluator used a bit-based PSK 0xaaa to ensure binary keys could be used and the evaluator successfully connected the device to the VPN gateway demonstrating a successful connection. Test 4 This test is not applicable as the TOE does not generate bit-based pre-shared keys EXTENDED: X.509 CERTIFICATE VALIDATION (FIA_X509_EXT.1) FIA_X509_EXT FIA_X509_EXT.1.2 GSS CCT Assurance Activity Report Page 36 of Gossamer Security Solutions, Inc.

37 Component TSS Assurance Activities: The evaluator shall ensure the TSS describes where the check of validity of the certificates takes place - the TOE or the TOE platform. It may be that the TOE requests the platform to perform the check and provide a result, or the TOE may do the check itself. The evaluator ensures the TSS also provides a description of the certificate path validation algorithm, ensuring that it describes how the validation chain will terminate in a trusted root certificate. Section 6.1 of the TSS states the TOE will verify the authenticity of the VPN gateway s X.509v3 certificate by validating the certificate, validating the certificate path, validating the certificates revocation status using OCSP, validating that the certificate path terminates in a trusted CA certificate, and validating that the CA certificate has the basicconstraints extension present and the CA flag set to true. Component Guidance Assurance Activities: The evaluator ensures the guidance documentation provides the user with the necessary information to setup the validation check whether it is done by the TOE or TOE platform. The guidance documentation provides instructions how to select the method used for checking, as well as how to setup a protected communication path with the entity providing the information pertaining to certificate validity. Section of the User-Guide explains how to specify an OCSP server to be used for certificate validation. The OCSP server itself has a certificate that chains to the root CA, and the OCSP server signs all revocation responses so that they can be validated. This chain ensures a trusted communications path with the OCSP server. Component Testing Assurance Activities: Regardless of the selection of 'TOE' or 'TOE Platform in the FIA_X509_EXT.1 elements, the evaluator shall perform the following tests. This testing may be combined with the testing performed in the other assurance activities (e.g., for FCS_IPSEC_EXT.1.12). Test 1: The evaluator shall demonstrate that validating a certificate without a valid certification path results in the function (trusted channel setup, trusted software update, integrity check) failing. The evaluator shall then load a certificate or certificates needed to validate the certificate to be used in the function, and demonstrate that the function succeeds. The evaluator then shall delete one of the certificates, and show that the function fails. Test 2: The evaluator shall demonstrate that validating an expired certificate results in the function failing. Test 3: The evaluator shall test that revoked certificates are properly handled - conditional on whether CRL or OCSP is selected; if both are selected, and then a test is performed for each method. For this draft of the PP, the evaluator has to only test one up in the trust chain (future drafts may require to ensure the validation is done up the entire chain). The evaluator shall ensure that a valid certificate is used, and that the SA is established. The evaluator then attempts the test with a certificate that will be revoked (for each method chosen in the selection) to ensure when the certificate is no longer valid that an SA will not be established. GSS CCT Assurance Activity Report Page 37 of Gossamer Security Solutions, Inc.

38 Test 4: The evaluator shall construct a certificate path, such that the certificate of the CA issuing the certificate does not contain the basicconstraints extension. The validation of the certificate path fails. Test 5: The evaluator shall construct a certificate path, such that the certificate of the CA issuing the certificate has the ca flag in the basicconstraints extension not set. The validation of the certificate path fails. Test 6: The evaluator shall construct a certificate path, such that the certificate of the CA issuing the certificate has the ca flag in the basicconstraints extension set to TRUE. The validation of the certificate path succeeds. Test 1 The evaluator connected to VPN Gateway using IPsec. A successful connection was made. The evaluator then configured a server certificate with an invalid certification path so that the certificate chain was invalid because of a missing (or deleted) certificate. The connection was refused. This test was repeated for IKEv1 and IKEv2 and it passed in both instances. Test 2 The evaluator configured a VPN Gateway to use IPSec. The VPN Gateway and TOE device were configured with expired certificates. When the TOE attempted to connect, the connection was refused. This test was repeated for IKEv1 and IKEv2 and it passed in both instances. Test 3 The evaluator configured a VPN Gateway to use IPSec. The VPN Gateway and TOE device were configured with valid certificates allowing the TOE devices to connect to the VPN Gateway. A successful connection was made. The VPN Gateway and TOE device were then configured with an OCSP revoked certificate. A revoked certificate error message was received. This test was repeated for IKEv1 and IKEv2 and it passed in both instances. Test 4 The evaluator configured a VPN Gateway to use IPSec. VPN Gateway and TOE device were configured with certificates that did not contain the basicconstraints extension. An unknown CA error message was received. This test was repeated for IKEv1 and IKEv2 and it passed in both instances. Test 5- The evaluator configured a VPN Gateway to use IPSec. VPN Gateway and TOE device were configured with certificates that did not contain the ca flag in the basicconstraints extension. An unknown CA error message was received. This test was repeated for IKEv1 and IKEv2 and it passed in both instances. Test 6 The evaluator configured a VPN Gateway to use IPSec. The VPN Gateway and TOE device were configured with certificates that did contain ca flag in the basicconstraints extension. A successful connection was made. This test was repeated for IKEv1 and IKEv2 and it passed in both instances EXTENDED: X.509 CERTIFICATE USE AND MANAGEMENT (FIA_X509_EXT.2) FIA_X509_EXT.2.1 GSS CCT Assurance Activity Report Page 38 of Gossamer Security Solutions, Inc.

39 FIA_X509_EXT.2.2 TSS Assurance Activities: The evaluator shall check the TSS to ensure that it describes how the TOE/platform chooses which certificates to use, and any necessary instructions in the administrative guidance for configuring the operating environment so that the TOE/platform can use the certificates. If this functionality is implemented entirely by the platform, the operational guidance for the TOE shall reference the applicable guidance for each platform. The evaluator shall examine the TSS to confirm that it describes the behavior of the TOE/platform when a connection cannot be established during the validity check of a certificate used in establishing a trusted channel. If the requirement that the administrator is able to specify the default action, then the evaluator shall ensure that the operational guidance contains instructions on how this configuration action is performed. If this behavior is implemented entirely by the platform, the evaluator shall examine the ST of each platform to confirm that the selections for this element are contained in each platform's ST. Section 6.3 of the ST states that the TOE validates authentication certificates (including the full path) and checks their revocation status using OCSP. The TOE will reject any certificate for which it cannot determine the validity and reject the connection attempts. Section 6.3 of the TSS states that the TOE always uses the certificates configured for the given VPN connection (both client certificate and ensuring that the server s certificate chains to the configured CA certificate). Section of the Admin-Guide specifies the Administrator settings for setting up a certificate for a VPN connection. Section 3.5 of the User-Guide explains how to manage certificates for VPN connections. Testing Assurance Activities: If this requirement is fully or partially implemented by the TOE, the evaluator shall perform Test 1 for each function in the system that requires the use of certificates: Test 1: The evaluator shall demonstrate that using a valid certificate that requires certificate validation checking to be performed in at least some part by communicating with a non-toe IT entity. The evaluator shall then manipulate the environment so that the TOE is unable to verify the validity of the certificate, and observe that the action selected in FIA_X509_EXT.2.2 is performed. If the selected action is administrator-configurable, then the evaluator shall follow the operational guidance to determine that all supported administrator-configurable options behave in their documented manner. Test 1 - See test case where it is demonstrated a connection cannot be made when the certificate validation server cannot be reached. GSS CCT Assurance Activity Report Page 39 of Gossamer Security Solutions, Inc.

40 FIA_X509_EXT.2.3 Component Component Component 2.4 SECURITY MANAGEMENT (FMT) SPECIFICATION OF MANAGEMENT FUNCTIONS (FMT_SMF.1(1)) FMT_SMF.1(1).1 Component TSS Assurance Activities: The evaluator shall check to ensure the TSS describes the client credentials and how they are used by the TOE. Section 6.4 of the TSS states the TOE provides users the ability to specify an X.509v3 certificate (previously loaded into the TOE Platform s key store) for the TOE to use to authenticate to the VPN gateway during IPsec peer authentication. The TOE alternatively provides users the ability to enter a Pre-Shared Key (either through the UI or through an MDM application) to be used in lieu of an X.509v3 certificate during IPsec peer authentication. Component Guidance Assurance Activities: The evaluator shall check to make sure that every management function mandated in the ST for this requirement are described in the operational guidance and that the description contains the information required to perform the management duties associated with each management function. Section of the Admin-Guide specifies the Administrator settings for setting up a VPN connection (name, certificate, gateway, pre-shared key). Section 3.4 of the Users-Guide explains to users how to set up a VPN tunnel. GSS CCT Assurance Activity Report Page 40 of Gossamer Security Solutions, Inc.

41 Section of the User-Guide explains how to setup an OSCP Server. Section 3.5 of the User-Guide explains how to manage certificates for VPN connections. Section of the User-Guide explains how to update the TOE and verify the updates. Component Testing Assurance Activities: The evaluator shall test the TOE's ability to provide the management functions by configuring the TOE according to the operational guidance and testing each management activity listed in the Security Target. Note that the testing here may be accomplished in conjunction with the testing of FCS_IPSEC_EXT.1. Test 1 - Management is testing by using the operational guidance to configure the TOE for testing. See the introduction of the FCS_IPSEC_EXT.1 SFR where the VPN gateways and authentication credentials are specified. The FCS_IPSEC_EXT.1 tests address all aspects of the management requirements including installing certificates, configuring VPN gateways, configuring pre-shared keys, configuring OCSP servers, and setting up VPN tunnels SPECIFICATION OF MANAGEMENT FUNCTIONS (FMT_SMF.1(2)) FMT_SMF.1(2).1 Component TSS Assurance Activities: As stated in the application note, a TOE may be configured either locally (through functions included in the VPN client itself or on its platform), or remotely by a VPN Gateway. The ST will clearly state which functions can be performed locally and remotely. The operational guidance documentation will describe how this is performed as well. The evaluator is expected to test this functions in all the ways in which the ST and guidance documentation state the configuration can be managed (with the exception noted in the previous paragraph). Section 6.4 maps each security management function to the TOE, TOE Platform, or VPN Gateway. Component Guidance Assurance Activities: The evaluator shall check to make sure that every management function mandated by the PP is described in the operational guidance and that the description contains the information required to perform the management duties associated with the management function. Section of the Admin-Guide contains information about the management functions supported by the VPN gateway including encryption settings, IKE Protocols & Authentication, IPsec Session Key cryptoperiod. Section 4.7 of the Admin-Guide explains how to update the TOE securely. GSS CCT Assurance Activity Report Page 41 of Gossamer Security Solutions, Inc.

42 Component Testing Assurance Activities: The evaluator shall test the TOE's ability to provide the management functions by configuring the TOE and testing each option listed in the requirement above. In cases where the management function is provided entirely by the platform (meaning that it is not able to be invoked by or through the TOE), the evaluator may simply ensure that the function is included in each underlying platform's ST. Note that the testing here may be accomplished in conjunction with the testing of other requirements, such as FCS_IPSEC_EXT.1. Management is testing by using the operational guidance to configure the TOE for testing. VPN gateways and authentication credentials are specified when setting up connections many time through the test effort.. The rest of the settings come from the platform or VPN gateway as empirically demonstrated throughout the IPsec and other tests. 2.5 PROTECTION OF THE TSF (FPT) EXTENDED: TSF SELF TEST (FPT_TST_EXT.1) FPT_TST_EXT FPT_TST_EXT.1.2 Component TSS Assurance Activities: Except for where it is explicitly noted, the evaluator is expected to check the following information regardless of whether the functionality is implemented by the TOE or by the TOE platform. The evaluator shall examine the TSS to ensure that it details the self tests that are run by the TSF on start-up; this description should include an outline of what the tests are actually doing (e.g., rather than saying 'memory is tested', a description similar to 'memory is tested by writing a value to each memory location and reading it back to ensure it is identical to what was written' shall be used). The evaluator shall ensure that the TSS makes an argument that the tests are sufficient to demonstrate that the TSF is operating correctly. If some of the tests are GSS CCT Assurance Activity Report Page 42 of Gossamer Security Solutions, Inc.

43 performed by the TOE platform, the evaluator shall check the TSS to ensure that those tests are identified, and that the ST for each platform contains a description of those tests. Note that the tests that are required by this component are those that support security functionality in this PP, which may not correspond to the set of all selftests contained in the platform STs. The evaluator shall examine the TSS to ensure that it describes how the integrity of stored TSF executable code is cryptographically verified when it is loaded for execution. The evaluator shall ensure that the TSS makes an argument that the tests are sufficient to demonstrate that the integrity of stored TSF executable code has not been compromised. The evaluator shall check to ensure that the cryptographic requirements listed are consistent with the description of the integrity verification process. The evaluator also ensures that the TSS (or the operational guidance) describes the actions that take place for successful (e.g. hash verified) and unsuccessful (e.g., hash not verified) cases. Section 6.5 describes how the TOE is cryptographically verified. It states that the TOE verifies its own executable code integrity. The TOE is checked through a combination of the TOE and the TOE Platform. The TOE must request/initiate the integrity checking (and does so as part of loading); however, the TOE makes a call to the TOE Platform s Security Manager, and it is the Security Manager that performs the cryptographic signature verification. Should the integrity check fail, the TOE will not boot. The TOE platform performs known answer power on self-tests (POST) on its cryptographic algorithms to ensure that they are functioning correctly. The kernel itself performs known answer tests on its cryptographic algorithms to ensure they are working correctly and the Samsung security manager service invokes self-test of the BoringSSL module at start to ensure that those cryptographic algorithms are working correctly. The Chipset hardware performs a power-up self-test to ensure that its AES implementation is working as does the TEE SCrypto cryptographic library. Should any of the tests fail, the TOE will reboot to see if that will clear the error. Should the TOE platform fail its power-up tests fails, the TOE platform will lock itself, preventing login. Component Guidance Assurance Activities: The evaluator also ensures that the TSS (or the operational guidance) describes the actions that take place for successful (e.g. hash verified) and unsuccessful (e.g., hash not verified) cases. For checks implemented entirely by the platform, the evaluator ensures that the operational guidance for the TOE references or includes the platform-specific guidance for each platform listed in the ST. The TOE Platform implements the self-tests. Should the TOE platform fail its power-up tests fails, the TOE platform will lock itself, preventing login. Section 4.4 of the User-Guide explains error conditions and instructs the user to contact technical support. Since login is prevented and the TOE Platform guidance offers no further insight, the evaluation concludes the information provided is acceptable. Component Testing Assurance Activities: The evaluator shall perform the following tests: Test 1: The evaluator performs the integrity check on a known good TSF executable and verifies that the check is successful. GSS CCT Assurance Activity Report Page 43 of Gossamer Security Solutions, Inc.

44 Test 2: The evaluator modifies the TSF executable, performs the integrity check on the modified TSF executable and verifies that the check fails. Test 1 This test was run in conjunction with the MDFPP evaluation. After the failing integrity test in test 2, the good/correct binary is restored to show that the TOE is working properly (after having passed the integrity test). Test 2 This test was run in conjunction with the MDFPP evaluation. The developer provided a test script that pulls a VPN binary from the TOE, modifies it, pushes it back and reboots. After the evaluator attempts to unlock the device at the cryptlock screen (and fails), the script continues and restores the binary so the TOE can successfully boot up (thus demonstrating a successful integrity check) EXTENDED: TRUSTED UPDATE (FPT_TUD_EXT.1) FPT_TUD_EXT FPT_TUD_EXT FPT_TUD_EXT.1.3 Component TSS Assurance Activities: Updates to the TOE are signed by an authorized source and may also have a hash associated with them, or are signed by an authorized source. If digital signatures are used, the definition of an authorized source is contained in the TSS, along with a description of how the certificates used by the update verification mechanism are contained on the device. The evaluator ensures this information is contained in the TSS. The evaluator also ensures that the TSS (or the operational guidance) describes how the candidate updates GSS CCT Assurance Activity Report Page 44 of Gossamer Security Solutions, Inc.

45 are obtained; the processing associated with verifying the digital signature or calculating the hash of the updates; and the actions that take place for successful (hash or signature was verified) and unsuccessful (hash or signature could not be verified) cases. If these activities are performed entirely by the underlying platform, a reference to the ST of each platform indicating that the required functionality is included for each platform shall be verified by the evaluator. The ST references the Platform-ST for a description of how updates are verified in section 6.5. Section 4.7 of the Admin-Guide explains how to obtain an update. The Admin-Guide also explains how to verify an update and the result of a successful or unsuccessful verification. The Platform-ST provides a discussion of the update process in the platform which is responsible for this function. Component Guidance Assurance Activities: The evaluator also ensures that the TSS (or the operational guidance) describes how the candidate updates are obtained; the processing associated with verifying the digital signature or calculating the hash of the updates; and the actions that take place for successful (hash or signature was verified) and unsuccessful (hash or signature could not be verified) cases. Section 4.7 of the Admin-Guide explains how to obtain updates. It explains that when updates are made available, they are signed by Samsung with a private key that is unique to the device/carrier combination (i.e. Galaxy S4 on Verizon will not have an update signed with the same key as a Galaxy S4 on AT&T). The public key is embedded in the bootloader image, and is used to verify the integrity and validity of the update package. The update package is checked automatically for integrity and validity by the software on the device. If the check fails the user is informed that there were errors in the update and the update will not be installed. Section of the User- Guide provides the interface for checking for software updates, Settings/About phone/software update. Component Testing Assurance Activities: The evaluator shall perform the following tests (regardless of whether the functionality is implemented by the TOE or by the platform): Test 1: The evaluator performs the version verification activity to determine the current version of the product. The evaluator obtains a legitimate update using procedures described in the operational guidance and verifies that it is successfully installed on the TOE. Then, the evaluator performs a subset of other assurance activity tests to demonstrate that the update functions as expected. After the update, the evaluator performs the version verification activity again to verify the version correctly corresponds to that of the update. Test 2: The evaluator performs the version verification activity to determine the current version of the product. The evaluator obtains or produces an illegitimate update, and attempts to install it on the TOE. The evaluator verifies that the TOE rejects the update. Test 1 & 2- See the FPT_TUD_EXT.2 tests for the applicable MDFPP platforms (Assurance Activity Report (MDFPP30) for Samsung Galaxy Devices on Android 7). Those tests were performed on the same product and software versions and as such should remain valid for this evaluation. 2.6 TRUSTED PATH/CHANNELS (FTP) GSS CCT Assurance Activity Report Page 45 of Gossamer Security Solutions, Inc.

46 2.6.1 INTER-TSF TRUSTED CHANNEL (FTP_ITC.1) FTP_ITC FTP_ITC FTP_ITC.1.3 Component TSS Assurance Activities: The evaluator shall examine the TSS to determine that it describes the details of the TOE connecting to a VPN Gateway in terms of the cryptographic protocols specified in the requirement, along with TOE-specific options or procedures that might not be reflected in the specification. The evaluator shall also confirm that all protocols listed in the TSS are specified and included in the requirements in the ST. Section 6.6 of the TSS states the TOE uses IPsec to provide a protected communication channel between itself and an IPsec VPN gateway. There are no TOE-specific options that are specified. The only protocol described is IPsec and it is included in the TSS (by reference to Section 6.1). Component Guidance Assurance Activities: The evaluator shall confirm that the operational guidance contains instructions for establishing the connection to the access point, and that it contains recovery instructions should a connection be unintentionally broken. GSS CCT Assurance Activity Report Page 46 of Gossamer Security Solutions, Inc.

47 Section 3.4 of the User-Guide explains how to set-up a VPN tunnel. The description talks about different means of authentication and how to configure each (Pre-shared key or certificate). The VPN can be configured to be Always on, if that is the case the connection will be re-established if broken. If not, section of the User-Guide explains how to manually connect. Component Testing Assurance Activities: The evaluator shall also perform the following tests: Test 1: The evaluators shall ensure that the TOE is able to initiate communications with a VPN Gateway using the protocols specified in the requirement, setting up the connections as described in the operational guidance and ensuring that communication is successful. Test 2: The evaluator shall ensure, for each communication channel with a VPN Gateway, the channel data is not sent in plaintext. Test 3: The evaluator shall ensure, for each communication channel with a VPN Gateway, modification of the channel data is detected by the TOE. Test 4: The evaluators shall physically interrupt the connection from the TOE to the a VPN Gateway. The evaluators shall ensure that subsequent communications are appropriately protected, at a minimum in the case of any attempts to automatically resume the connection or connect to a new access point. Test 1- The evaluator configured the VPN gateway to use RSA certificate authentication. The evaluator then attempted to connect to the VPN gateway. The connection succeeded. This was repeated for IKEv1 and IKEv2 and it passed in both instances. Test 2 - The evaluator connected to the VPN gateway using pre-shared key authentication. The connection succeeded. The evaluator captured the traffic and found it to be encrypted and the connection was established. This was repeated for IKEv1 and IKEv2 and it passed in both instances. Test 3 - The evaluator connected to the VPN gateway using pre-shared key authentication. The connection succeeded. The evaluator then repeatedly hit a web server to generate traffic and simultaneously modified some of the ESP packets. The evaluator observed correct operation (ie no corruption) when using a browser to browse web pages in the VPN. The packet captures demonstrate the ESP modifications were detected and dropped. This was repeated for IKEv1 and IKEv2 and it passed in both instances. Test 4 - The evaluator connected to the VPN gateway using pre-shared key authentication. The connection succeeded. The evaluator then disconnected the VPN gateway connection. When the evaluator reconnected, the traffic was encrypted upon resumption. The packet capture demonstrates the traffic is encrypted. This was repeated for IKEv1 and IKEv2 and it passed in both instances. GSS CCT Assurance Activity Report Page 47 of Gossamer Security Solutions, Inc.

48 3. PROTECTION PROFILE SAR ASSURANCE ACTIVITIES The following sections address assurance activities specifically defined in the claimed Protection Profile that correspond with Security Assurance Requirements. 3.1 DEVELOPMENT (ADV) BASIC FUNCTIONAL SPECIFICATION (ADV_FSP.1) Assurance Activities: There are no specific assurance activities associated with these SARs. The functional specification documentation is provided to support the evaluation activities described in Sections 4.1 and 4.2, and other activities described for AGD, ATE, and AVA SARs. The requirements on the content of the functional specification information is implicitly assessed by virtue of the other assurance activities being performed; if the evaluator is unable to perform an activity because the there is insufficient interface information, then an adequate functional specification has not been provided. 3.2 GUIDANCE DOCUMENTS (AGD) OPERATIONAL USER GUIDANCE (AGD_OPE.1) Assurance Activities: With respect to the management functions, while several have also been described in Sections 4.1 and 4.2, additional information is required as follows. For TOE that implement a cryptographic engine, the operational guidance shall contain instructions for configuring the cryptographic engine associated with the evaluated configuration of the TOE. It shall provide a warning that use of other cryptographic engines was not evaluated nor tested during the CC evaluation of the TOE. The documentation must describe the process for verifying updates to the TOE, either by checking the hash or by verifying a digital signature. The evaluator shall verify that this process includes the following steps: - For hashes, a description of where the hash for a given update can be obtained. For digital signatures, instructions for obtaining the certificate that will be used by the FCS_COP.1(2) mechanism to ensure that a signed update has been received from the certificate owner. This may be supplied with the product initially, or may be obtained by some other means. - Instructions for obtaining the update itself. This should include instructions for making the update accessible to the TOE (e.g., placement in a specific directory). - Instructions for initiating the update process, as well as discerning whether the process was successful or unsuccessful. This includes generation of the hash/digital signature. Section of the Admin-Guide explains that Samsung provides three cryptographic modules on the evaluated devices: GSS CCT Assurance Activity Report Page 48 of Gossamer Security Solutions, Inc.

49 Samsung Kernel Cryptographic Module BoringSSL FIPS Object Module SCrypto Module All modules always run in a FIPS-validated mode. BoringSSL, for compatibility reasons, provides access to non-fips algorithms, which developers should not utilize in a validated configuration (but which are necessary to ensure functionality with many commercial services). The APIs which provide access to FIPS-validated algorithms are detailed in the User Guidance documentation. Section 4.7 of the Admin-Guide discusses how to update the device. It explains how to get an update and how updates are signed PREPARATIVE PROCEDURES (AGD_PRE.1) Assurance Activities: As indicated in the introduction above, there are significant expectations with respect to the documentation-especially when configuring the operational environment to support TOE functional requirements. The evaluator shall check to ensure that the guidance provided for the TOE adequately addresses all platforms and components (that is, combination of hardware and operating system) claimed for the TOE in the ST. The evaluator shall check to ensure that the following guidance is provided: - As indicated in the introductory material, administration of the TOE is performed by one or more administrators that are a subset of the group of all users of the TOE. While it must be the case that the overall system (TOE plus Operational Environment) provide this capability, the responsibility for the implementation of the functionality can vary from totally the Operational Environment's responsibility to totally the TOE's responsibility. At a high level, the guidance must contain the appropriate instructions so that the Operational Environment is configured so that it provides the portion of the capability for which it is responsible. If the TOE provides no mechanism to allow separation of administrative users from the population of users, then the instructions, for instance, would cover the OS configuration of the OS I&A mechanisms to provide a unique (OS-based) identity for users, and further guidance would instruct the installer on the configuration of the DAC mechanisms of the OS using the TOE administrative identity (or identities) so that only TOE administrators would have access to the administrative executables. If the TOE provides some or all of this functionality, then the appropriate requirements are included in the ST from Appendix C, and the assurance activities associated with those requirements provide details on the guidance necessary for both the TOE and Operational Environment. The evaluators shall also perform the following tests: Test 1 [Conditional]: If the separation of administrative users from all TOE users is performed exclusively through the configuration of the Operational Environment, the evaluators will, for each configuration claimed in the ST, ensure that after configuring the system according to the administrative guidance, non-administrative users are unable to access TOE administrative functions. GSS CCT Assurance Activity Report Page 49 of Gossamer Security Solutions, Inc.

50 There is no role separation. Section 3.2 of the User-Guide explains how to put the device into CC mode (this includes the TOE and the TOE platform). Section of the Admin-Guide explains how to put the device into CC mode (this includes the TOE and the TOE platform). Tests of the TOE platform have demonstrated the capabilities that users and administrators have when the TOE Platform is in CC mode. The VPN is simply an application in the TOE Platform and has no effect on the overall management of the TOE Platform. The VPN configuration was tested in FMT_SMF.1(1). 3.3 LIFE-CYCLE SUPPORT (ALC) LABELLING OF THE TOE (ALC_CMC.1) Assurance Activities: The evaluator shall check the ST to ensure that it contains an identifier (such as a product name/version number) that specifically identifies the version that meets the requirements of the ST. Further, the evaluator shall check the AGD guidance and TOE samples received for testing to ensure that the version number is consistent with that in the ST. If the vendor maintains a web site advertising the TOE, the evaluator shall examine the information on the web site to ensure that the information in the ST is sufficient to distinguish the product. The evaluator verified that the ST, TOE and Guidance are all labeled with the same versions. The evaluator checked the TOE version during testing by examining the actual devices used for testing TOE CM COVERAGE (ALC_CMS.1) Assurance Activities: The 'evaluation evidence required by the SARs' in this PP is limited to the information in the ST coupled with the guidance provided to administrators and users under the AGD requirements. By ensuring that the TOE is specifically identified and that this identification is consistent in the ST and in the AGD guidance (as done in the assurance activity for ALC_CMC.1), the evaluator implicitly confirms the information required by this component. The evaluator verified that the ST, TOE and Guidance are all labeled with the same versions. The evaluator checked the TOE version during testing by examining the actual devices used for testing. 3.4 TESTS (ATE) INDEPENDENT TESTING - CONFORMANCE (ATE_IND.1) Assurance Activities: The evaluator shall prepare a test plan and report documenting the testing aspects of the system. The test plan covers all of the testing actions contained in the body of this PP's Assurance Activities. While it is not necessary to have one test case per test listed in an Assurance Activity, the evaluators must document in the test plan that each applicable testing requirement in the ST is covered. The Test Plan identifies the platforms to be tested, and for those platforms not included in the test plan but included in the ST, the test plan provides a justification for not testing the platforms. This justification must address the differences between the tested platform and the untested platforms, and make an argument that the GSS CCT Assurance Activity Report Page 50 of Gossamer Security Solutions, Inc.

51 differences do not affect the testing to be performed. It is not sufficient to merely assert that the differences have no affect; rationale must be provided. If all platforms claimed in the ST are tested, then no rationale is necessary. The test plan describes the composition of each platform to be tested, and any setup that is necessary beyond what is contained in the AGD documentation. It should be noted that the evaluators are expected to follow the AGD documentation for installation and setup of each platform either as part of a test or as a standard pre-test condition. This may include special test drivers or tools. For each driver or tool, an argument (not just an assertion) is provided that the driver or tool will not adversely affect the performance of the functionality by the TOE and its platform. The test plan identifies high-level test objectives as well as the test procedures to be followed to achieve those objectives. These procedures include expected results. The test report (which could just be an annotated version of the test plan) details the activities that took place when the test procedures were executed, and includes the actual results of the tests. This shall be a cumulative account, so if there was a test run that resulted in a failure; a fix installed; and then a successful re-run of the test, the report would show a 'fail' and 'pass' result (and the supporting details), and not just the 'pass' result. The evaluator created a Detailed Test Report (DTR) to address all aspects of this requirement. The DTR discusses the test configuration, test cases, expected results, and test results. The following diagrams depict the evaluator s test environment: The following diagram indicates the test environment. Ubuntu Linux Windows Network Putty Connection (16.04) or (14.10) USB Connection TOE Device Figure 1 Evaluator Test Setup 1 GSS CCT Assurance Activity Report Page 51 of Gossamer Security Solutions, Inc.

52 TOE Device Evaluator Sniffing Configuration Linux RADIUS Access Point Linux Backtrack Wireshark Network Putty Connection USB Connection Windows USB Connection Evaluator Direct Connect Configuration TOE Device Figure 2 Evaluator Test Setup VULNERABILITY ASSESSMENT (AVA) VULNERABILITY SURVEY (AVA_VAN.1) Assurance Activities: As with ATE_IND, the evaluator shall generate a report to document their findings with respect to this requirement. This report could physically be part of the overall test report mentioned in ATE_IND, or a separate document. The evaluator performs a search of public information to determine the vulnerabilities that have been found in VPN Client products in general, as well as those that pertain to the particular TOE. The evaluator documents the sources consulted and the vulnerabilities found in the report. For each vulnerability found, the evaluator either provides a rationale with respect to its non-applicability, or the evaluator formulates a test (using the guidelines provided in ATE_IND) to confirm the vulnerability, if suitable. Suitability is determined by assessing the attack vector needed to take advantage of the vulnerability. For example, if the vulnerability can be detected by pressing a key combination on boot-up, for example, a test would be suitable at the assurance level of this PP. If exploiting the vulnerability requires an electron microscope and a tank of liquid nitrogen, for instance, then a test would not be suitable and an appropriate justification would be formulated. The vulnerability analysis is in the Detailed Test Report (DTR) prepared by the evaluator. The vulnerability analysis includes a public search for vulnerabilities. The public search for vulnerabilities did not uncover any residual vulnerability. GSS CCT Assurance Activity Report Page 52 of Gossamer Security Solutions, Inc.