Assurance Activity Report

Transcription

1 Assurance Activity Report (IVPNCPP14) for Oceus Networks VPN Client Version 0.6 January 19, 2017 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 Document: AAR- Oceus-VID Gossamer Security Solutions, Inc.

2 REVISION HISTORY Revision Date Authors Summary Version 07/13/16 Sykes Initial draft 0.1 Version 07/14/16 Sykes ST Updates 0.2 Version 8/09/16 Sykes Guidance Review 0.3 Version 12/06/16 Sykes Guidance Update 0.4 Version 12/23/2016 Sykes Updated to address Validator Comments 0.5 Version /19/2017 Arnold Updated to address NIAP follow-up comments The TOE Evaluation was Sponsored by: Oceus Networks 5801 Tennyson Parkway Suite 250 Plano, Texas Evaluation Personnel: Tammy Compton Jim Arnold Raymond Smoley Katie Sykes 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) GSS CCT Assurance Activity Report Page 3 of Gossamer Security Solutions, Inc.

4 3. Protection Profile SAR Assurance Activities 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 Oceus Networks Oceus VPN Client IVPNCPP14 evaluation. This document contains a description of the assurance activities and associated results as performed by the evaluators. 1.1 EQUIVALENCE This section presents the test environment and explains why the test subset was adequate to address all product installations. The TOE consists of two distinct products. The following are the final specific applications used for testing. Note that testing started on version , but incrementally changed as bugs were identified and fixed during testing. All of the RSA and ECDSA tests were performed using the final 2211 version. While the PSK IPsec tests were actually performed using version 2208, the changes between 2208 and 2211 were all certificate related (e.g., revocation checks) and the evaluator ensured that version 2211 could continue to connect as expected when using a PSK. Oceus Networks VPN for Samsung Devices, Version o Consists of a single Android application (APK): Oceus VPN Client Oceus Networks VPN for Android Devices, Version o Consists of two Android applications (APKs): Oceus VPN Client and OceusVPNService Testing began in early August 2016 shortly before the evaluation was officially checked in on August 12, Two different Samsung S7 Edge (w/ Android 6.0.1) devices were selected for testing because one is based on a Qualcomm CPU and the other an Exynos CPU. Both of these CPU s are 64-bit ARMv8 processors. The CAVP certificates claimed for the TOE identify the Exynos 7420 Octa (Cortex-A53) w/android 6.0 which is also a 64-bit ARMv8 processor. This decision was made based on NIAP s Policy 5 guidance in force at check in time and throughout the evaluation. 1 Item #4b in the Frequently Asked Questions for NIAP Policy #5 document, dated June 12, 2015, states the following: Q. If an algorithm implementation has been tested on one processor, can a claim be made that the implementation also runs on a different processor? A. If the untested processor supports the same instruction set and operates on the same word size as the tested processor and the algorithm implementation can operate on the untested processor without change, then the algorithm implementation does not have to be re-tested 1 Most testing had been completed by early September 2016, prior to the recent change made to Policy 5 on 17 November, GSS CCT Assurance Activity Report Page 5 of Gossamer Security Solutions, Inc.

6 Based on this guidance, the hardware selected for testing is equivalent to hardware identified on the CAVP certificates claimed for the TOE. While there are different CPUs on the various phones such as the Exynos 7420 and 8890 processors, each of the applicable processors is a 64-bit ARMv8 processor and provide equal support to the Oceus VPN client. Additionally, both the S6 and S7 devices identified in the Security Target run Android and similarly provide equal support for the Oceus VPN client application which runs unchanged (ie. same binary) on all of the identified devices. With the two S7 devices, the evaluator was able to test both the Samsung and Android variants of the TOE in parallel. In addition to these two devices, the evaluator utilized a special build of the mobile device operating system on each of those devices for a small number of tests that required access (e.g., to be able to dump memory) not available in the production mobile devices. These special engineering devices were used for the tests related to key destruction (where memory had to be dumped) and IPsec SPD testing (where iptables rules had to be changed). 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.4 Oceus Networks VPN Client (IVPNCPP14) Security Target, Version v0.8, December 22, 2016 [ST] Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 6 (MDFPP20) Security Target, Version 0.61, December 13, 2016 [Platform ST] Samsung Electronics Co., Ltd. Samsung Galaxy S7 Devices on Android 6 (MDFPP20) Security Target, 0.61, December 13, 2016 [S7 Platform ST] Both-Platform-ST refers to Platform ST and S7 Platform ST Oceus Networks VPN Client User Guide, Version 0.16, 12/8/2016 [User Guide] Oceus Networks VPN Client Product Guidance, Version 0.8, 12/8/2016 [Product Guide] 2.1 CRYPTOGRAPHIC SUPPORT (FCS) CRYPTOGRAPHIC KEY GENERATION (ASYMMETRIC KEYS) (FCS_CKM.1(1)) FCS_CKM.1(1).1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined 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). GSS CCT Assurance Activity Report Page 7 of Gossamer Security Solutions, Inc.

8 Requirement met by the TOE 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. Per NIAP Policy Letter #5, this requirement is satisfied by virtue of the applicable CAVP certificates identified in Table 6-1 of the ST. Validation activities that are performed during a cryptographic algorithm or module validation which results in a NIST CAVP/CMVP certificate may be used to demonstrate compliance to some PP/cPP assurance activities. Component Guidance Assurance Activities: None Defined Component Testing Assurance Activities: Requirement met by the TOE The evaluator shall verify the implementation of the key generation routines of the supported schemes using the applicable tests below. Key Generation for RSA-Based Key Establishment Schemes The evaluator shall verify the implementation of RSA Key Generation by the TOE using the Key Generation test. This test verifies the ability of the TSF to correctly produce values for the key components including the public verification exponent e, the private prime factors p and q, the public modulus n and the calculation of the private signature exponent d. Key Pair generation specifies 5 ways (or methods) to generate the primes p and q. These include: 1. Random Primes: -Provable primes -Probable primes GSS CCT Assurance Activity Report Page 8 of Gossamer Security Solutions, Inc.

9 2. Primes with Conditions: -Primes p1, p2, q1,q2, p and q shall all be provable primes -Primes p1, p2, q1, and q2 shall be provable primes and p and q shall be probable primes -Primes p1, p2, q1,q2, p and q shall all be probable primes To test the key generation method for the Random Provable primes method and for all the Primes with Conditions methods, the evaluator must seed the TSF key generation routine with sufficient data to deterministically generate the RSA key pair. This includes the random seed(s), the public exponent of the RSA key, and the desired key length. For each key length supported, the evaluator shall have the TSF generate 25 key pairs. The evaluator shall verify the correctness of the TSF's implementation by comparing values generated by the TSF with those generated from a known good implementation. Key Generation for Finite-Field Cryptography (FFC) - Based 56A Schemes FFC Domain Parameter and Key Generation Tests The evaluator shall verify the implementation of the Parameters Generation and the Key Generation for FFC by the TOE using the Parameter Generation and Key Generation test. This test verifies the ability of the TSF to correctly produce values for the field prime p, the cryptographic prime q (dividing p-1), the cryptographic group generator g, and the calculation of the private key x and public key y. The Parameter generation specifies 2 ways (or methods) to generate the cryptographic prime q and the field prime p: Cryptographic and Field Primes: -Primes q and p shall both be provable primes -Primes q and field prime p shall both be probable primes and two ways to generate the cryptographic group generator g: Cryptographic Group Generator: -Generator g constructed through a verifiable process -Generator g constructed through an unverifiable process. The Key generation specifies 2 ways to generate the private key x: Private Key: GSS CCT Assurance Activity Report Page 9 of Gossamer Security Solutions, Inc.

10 -len(q) bit output of RBG where 1 <=x <= q-1 -len(q) + 64 bit output of RBG, followed by a mod q-1 operation where 1<= x<=q-1. The security strength of the RBG must be at least that of the security offered by the FFC parameter set. To test the cryptographic and field prime generation method for the provable primes method and/or the group generator g for a verifiable process, the evaluator must seed the TSF parameter generation routine with sufficient data to deterministically generate the parameter set. For each key length supported, the evaluator shall have the TSF generate 25 parameter sets and key pairs. The evaluator shall verify the correctness of the TSF's implementation by comparing values generated by the TSF with those generated from a known good implementation. Verification must also confirm -g!= 0,1 -q divides p-1 -g^q mod p = 1 -g^x mod p = y for each FFC parameter set and key pair. Key Generation for Elliptic Curve Cryptography (ECC)- Based 56A Schemes ECC Key Generation Test For each supported NIST curve, i.e., P-256, P-284 and P-521, the evaluator shall require the implementation under test (IUT) to generate 10 private/public key pairs. The private key shall be generated using an approved random bit generator (RBG). To d etermine correctness, the evaluator shall submit the generated key pairs to the public key verification (PKV) function of a known good implementation. ECC Public Key Verification (PKV) Test For each supported NIST curve, i.e., P-256, P-284 and P-521, the evaluator shall generate 10 private/public key pairs using the key generation function of a known good implementation and modify five of the public key values so that they are incorrect, leaving five values unchanged (i.e., correct). The evaluator shall obtain in response a set of 10 PASS/FAIL values. Key Establishment Schemes The evaluator shall verify the implementation of the key establishment schemes of the supported by the TOE using the applicable tests below. GSS CCT Assurance Activity Report Page 10 of Gossamer Security Solutions, Inc.

11 SP800-56A Key Establishment Schemes The evaluator shall verify a TOE's implementation of SP800-56A key agreement schemes using the following Function and Validity tests. These validation tests for each key agreement scheme verify that a TOE has implemented the components of the key agreement scheme according to the specifications in the Recommendation. These components include the calculation of the DLC primitives (the shared secret value Z) and the calculation of the derived keying material (DKM) via the Key Derivation Function (KDF). If key confirmation is supported, the evaluator shall also verify that the components of key confirmation have been implemented correctly, using the test procedures described below. This includes the parsing of the DKM, the generation of MACdata and the calculation of MACtag. Function Test The Function test verifies the ability of the TOE to implement the key agreement schemes correctly. To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each supported key agreement scheme-key agreement role combination, KDF type, and, if supported, key confirmation role- key confirmation type combination, the tester shall generate 10 sets of test vectors. The data set consists of one set of domain parameter values (FFC) or the NIST approved curve (ECC) per 10 sets of public keys. These keys are static, ephemeral or both depending on the scheme being tested. The evaluator shall obtain the DKM, the corresponding TOE's public keys (static and/or ephemeral), the MAC tag(s), and any inputs used in the KDF, such as the Other Information field OI and TOE id fields. If the TOE does not use a KDF defined in SP A, the evaluator shall obtain only the public keys and the hashed value of the shared secret. The evaluator shall verify the correctness of the TSF's implementation of a given scheme by using a known good implementation to calculate the shared secret value, derive the keying material DKM, and compare hashes or MAC tags generated from these values. If key confirmation is supported, the TSF shall perform the above for each implemented approved MAC algorithm. Validity Test The Validity test verifies the ability of the TOE to recognize another party's valid and invalid key agreement results with or without key confirmation. To conduct this test, the evaluator shall obtain a list of the supporting cryptographic functions included in the SP800-56A key agreement implementation to determine which errors the TOE should be able to recognize. The evaluator generates a set of 24 (FFC) or 30 (ECC) test vectors consisting of data sets including domain parameter values or NIST approved curves, the evaluator's public keys, the TOE's public/private key pairs, MACTag, and any inputs used in the KDF, such as the other info and TOE id fields. The evaluator shall inject an error in some of the test vectors to test that the TOE recognizes invalid key agreement results caused by the following fields being incorrect: the shared secret value Z, the DKM, the other information GSS CCT Assurance Activity Report Page 11 of Gossamer Security Solutions, Inc.

12 field OI, the data to be MACed, or the generated MACTag. If the TOE contains the full or partial (only ECC) public key validation, the evaluator will also individually inject errors in both parties ' static public keys, both parties' ephemeral public keys and the TOE's static private key to assure the TOE detects errors in the public key validation function and/or the partial key validation function (in ECC only). At least two of the test vectors shall remain unmodified and therefore should result in valid key agreement results (they should pass). The TOE shall use these modified test vectors to emulate the key agreement scheme using the corresponding parameters. The evaluator shall compare the TOE's results with the results using a known good implementation verifying that the TOE detects these errors. The TOE has algorithm certificate #1028 for Mocana Nanosec crypto library for ECDSA, algorithm certificate # 2347 for RSA (Sig (gen)) and certificate # 1049 for CVL FFC and ECC CRYPTOGRAPHIC KEY GENERATION (FOR ASYMMETRIC KEYS - IKE) (FCS_CKM.1(2)) FCS_CKM.1(2).1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined 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 TSF implements the ANSI X scheme, the evaluator shall check to ensure that the TSS describes how the keypairs are generat ed. In order to show that the TSF implementation complies with ANSI X , the evaluator shall ensure that the TSS contains the following information: GSS CCT Assurance Activity Report Page 12 of Gossamer Security Solutions, Inc.

13 - 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. The TOE implements the FIPS 186-4, Digital Signature Standard (DSS) for RSA and ECDSA schemes. requirement is verified under FCS_COP.1(2). This Component Guidance Assurance Activities: None Defined Component Testing Assurance Activities: None Defined CRYPTOGRAPHIC KEY STORAGE (FCS_CKM_EXT.2) FCS_CKM_EXT.2.1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined 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 GSS CCT Assurance Activity Report Page 13 of Gossamer Security Solutions, Inc.

14 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 6-2 in the ST presents all the keys used by the TOE. The table identifies the key, its purpose, where it is stored and when and how it is cleared. The Both-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 Guidance Assurance Activities: None Defined Component Testing Assurance Activities: None Defined CRYPTOGRAPHIC KEY ZEROIZATION (FCS_CKM_EXT.4) FCS_CKM_EXT.4.1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined 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 GSS CCT Assurance Activity Report Page 14 of Gossamer Security Solutions, Inc.

15 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 6-2 in the ST presents all the keys used by the TOE. The table identifies the key, its purpose, where it is stored and when and how it is cleared. Keys are cleared using the Zero overwrite or Crypto erase methods. Crypto erase refers to the deletion of the certificate by clearing the key used to encrypt the CSP. Once the key has been cleared, the data encrypted by it is cryptographically erased. The reference to zero overwrite, indicates that the value being cleared is overwritten, byte-by-byte using a zero value. The Both-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 Guidance Assurance Activities: None Defined 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 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. GSS CCT Assurance Activity Report Page 15 of Gossamer Security Solutions, Inc.

16 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 evaluator received an engineering build from Oceus. The evaluator then used that build to run a series of memory dump tests that dumped the memory on the device. The evaluator took the memory dumps and searched those dumps with a hex search tool to search for known keys. The evaluator was unable to find any of the keys in the dump files. The following keys were tested: Key Name Destroyed upon Power-off/Wipe Destroyed after disconnect Destroyed when no longer needed VPN IKE_SA Keys (Auth initiator and responder, Encryption initiator and responder) VPN CHILD/IPSEC_SA Keys (initiator and responder) X X CRYPTOGRAPHIC OPERATION (DATA ENCRYPTION/DECRYPTION) (FCS_COP.1(1)) FCS_COP.1(1).1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined 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 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. GSS CCT Assurance Activity Report Page 16 of Gossamer Security Solutions, Inc.

17 Component Guidance Assurance Activities: None Defined Component Testing Assurance Activities: Requirement met by the TOE The evaluator shall perform the following activities based on the selections in the ST. AES-CBC Tests AES-CBC Known Answer Tests There are four Known Answer Tests (KATs), described below. In all KATs, the plaintext, ciphertext, and IV values shall be 128-bit blocks. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation. KAT-1. To test the encrypt functionality of AES-CBC, the evaluator shall supply a set of 10 plaintext values and obtain the ciphertext value that results from AES-CBC encryption of the given plaintext using a key value of all zeros and an IV of all zeros. Five plaintext values shall be encrypted with a 128-bit all-zeros key, and the other five shall be encrypted with a 256-bit all-zeros key. To test the decrypt functionality of AES-CBC, the evaluator shall perform the same test as for encrypt, using 10 ciphertext values as input and AES-CBC decryption. KAT-2. To test the encrypt functionality of AES-CBC, the evaluator shall supply a set of 10 key values and obtain the ciphertext value that results from AES-CBC encryption of an all-zeros plaintext using the given key value and an IV of all zeros. Five of the keys shall be 128-bit keys, and the other five shall be 256-bit keys. To test the decrypt functionality of AES-CBC, the evaluator shall perform the same test as for encrypt, using an allzero ciphertext value as input and AES-CBC decryption. KAT-3. To test the encrypt functionality of AES-CBC, the evaluator shall supply the two sets of key values described below and obtain the ciphertext value that results from AES encryption of an all-zeros plaintext using the given key value and an IV of all zeros. The first set of keys shall have bit keys, and the second set shall have bit keys. Key i in each set shall have the leftmost i bits be ones and the rightmost N-i bits be zeros, for i in [1,N]. To test the decrypt functionality of AES-CBC, the evaluator shall supply the two sets of key and ciphertext value pairs described below and obtain the plaintext value that results from AES-CBC decryption of the given ciphertext using the given key and an IV of all zeros. The first set of key/ciphertext pairs shall have bit key/ciphertext pairs, and the second set of key/ciphertext pairs shall have bit key/ciphertext pairs. Key i in each set shall have the leftmost i bits be ones and the rightmost N-i bits be zeros, for i in [1,N]. The ciphertext value in each pair shall be the value that results in an all-zeros plaintext when decrypted with its corresponding key. GSS CCT Assurance Activity Report Page 17 of Gossamer Security Solutions, Inc.

18 KAT-4. To test the encrypt functionality of AES-CBC, the evaluator shall supply the set of 128 plaintext values described below and obtain the two ciphertext values that result from AES-CBC encryption of the given plaintext using a 128-bit key value of all zeros with an IV of all zeros and using a 256-bit key value of all zeros with an IV of all zeros, respectively. Plaintext value i in each set shall have the leftmost i bits be ones and the rightmost 128-i bits be zeros, for i in [1,128]. To test the decrypt functionality of AES-CBC, the evaluator shall perform the same test as for encrypt, using ciphertext values of the same form as the plaintext in the encrypt test as input and AES-CBC decryption. AES-CBC Multi-Block Message Test The evaluator shall test the encrypt functionality by encrypting an i-block message where 1< i <=10. The evaluator shall choose a key, an IV and plaintext message of length i blocks and encrypt the message, using the mode to be tested, with the chosen key and IV. The ciphertext shall be compared to the result of encrypting the same plaintext message with the same key and IV using a known good implementation. The evaluator shall also te st the decrypt functionality for each mode by decrypting an i-block message where 1 < i <=10. The evaluator shall choose a key, an IV and a ciphertext message of length i blocks and decrypt the message, using the mode to be tested, with the chosen key and IV. The plaintext shall be compared to the result of decrypting the same ciphertext message with the same key and IV using a known good implementation. AES-CBC Monte Carlo Tests The evaluator shall test the encrypt functionality using a set of 200 plaintext, IV, and key 3-tuples. 100 of these shall use 128 bit keys, and 100 shall use 256 bit keys. The plaintext and IV values shall be 128-bit blocks. For each 3- tuple, 1000 iterations shall be run as follows: # Input: PT, IV, Key for i = 1 to 1000: if i == 1: CT[1] = AES-CBC-Encrypt(Key, IV, PT) PT = IV else: CT[i] = AES-CBC-Encrypt(Key, PT) PT = CT[i-1] GSS CCT Assurance Activity Report Page 18 of Gossamer Security Solutions, Inc.

19 The ciphertext computed in the 1000th iteration (i.e., CT[1000]) is the result for that trial. This result shall be compared to the result of running 1000 iterations with the same values using a known good implementation. The evaluator shall test the decrypt functionality using the same test as for encrypt, exchanging CT and PT and replacing AES-CBC-Encrypt with AES-CBC-Decrypt. AES-GCM Monte Carlo Test The evaluator shall test the authenticated encrypt functionality of AES-GCM for each combination of the following input parameter lengths: 128 bit and 256 bit keys Two plaintext lengths. One of the plaintext lengths shall be a non-zero integer multiple of 128 bits, if supported. The other plaintext length shall not be an integer multiple of 128 bits, if supported. Three AAD lengths. One AAD length shall be 0, if supported. One AAD length shall be a non-zero integer multiple of 128 bits, if supported. One AAD length shall not be an integer multiple of 128 bits, if supported. Two IV lengths. If 96 bit IV is supported, 96 bits shall be one of the two IV lengths tested. The evaluator shall test the encrypt functionality using a set of 10 key, plaintext, AAD, and IV tuples for each combination of parameter lengths above and obtain the ciphertext value and tag that results from AES-GCM authenticated encrypt. Each supported tag length shall be tested at least once per set of 10. The IV value may be supplied by the evaluator or the implementation being tested, as long as it is known. The evaluator shall test the decrypt functionality using a set of 10 key, ciphertext, tag, AAD, and IV 5-tuples for each combination of parameter lengths above and obtain a Pass/Fail result on authentication and the decrypted plaintext if Pass. The set shall include five tuples that Pass and five that Fail. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation. The TOE has algorithm certificate #2741 for Mocana Nanosec crypto library for AES in CBC and GCM mode. GSS CCT Assurance Activity Report Page 19 of Gossamer Security Solutions, Inc.

20 2.1.6 CRYPTOGRAPHIC OPERATION (FOR CRYPTOGRAPHIC SIGNATURE) (FCS_COP.1(2)) FCS_COP.1(2).1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined 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. Component Guidance Assurance Activities: None Defined Component Testing Assurance Activities: Requirement met by the TOE The evaluator shall perform the following activities based on the selections in the ST. Key Generation: Key Generation for RSA Signature Schemes The evaluator shall verify the implementation of RSA Key Generation by the TOE using the Key Generation test. This test verifies the ability of the TSF to correctly produce values for the key components including the public verification exponent e, the private prime factors p and q, the public modulus n and the calculation of the private signature exponent d. Key Pair generation specifies 5 ways (or methods) to generate the primes p and q. These include: 1. Random Primes: -Provable primes -Probable primes GSS CCT Assurance Activity Report Page 20 of Gossamer Security Solutions, Inc.

21 2. Primes with Conditions: -Primes p1, p2, q1,q2, p and q shall all be provable primes -Primes p1, p2, q1, and q2 shall be provable primes and p and q shall be probable primes -Primes p1, p2, q1,q2, p and q shall all be probable primes To test the key generation method for the Random Provable primes method and for all the Primes with Conditions methods, the evaluator must seed the TSF key generation routine with sufficient data to deterministically generate the RSA key pair. This includes the random seed(s), the public exponent of the RSA key, and the desired key length. For each key length supported, the evaluator shall have the TSF generate 25 key pairs. The evaluator shall verify the correctness of the TSF's implementation by comparing values generated by the TSF with those generated from a known good implementation. ECDSA Key Generation Tests FIPS ECDSA Key Generation Test For each supported NIST curve, i.e., P-256, P-284 and P-521, the evaluator shall require the implementation under test (IUT) to generate 10 private/public key pairs. The private key shall be generated using an approved random bit generator (RBG). To determine correctness, the evaluator shall submit the generated key pairs to the public key verification (PKV) function of a known good implementation. FIPS Public Key Verification (PKV) Test For each supported NIST curve, i.e., P-256, P-284 and P-521, the evaluator shall generate 10 private/public key pairs using the key generation function of a known good implementation and modify five of the public key values so that they are incorrect, leaving five values unchanged (i.e., correct). The evaluator shall obtain in response a set of 10 PASS/FAIL values. ECDSA Algorithm Tests ECDSA FIPS Signature Generation Test For each supported NIST curve (i.e., P-256, P-284 and P-521) and SHA function pair, the evaluator shall generate bit long messages and obtain for each message a public key and the resulting signature values R and S. To determine correctness, the evaluator shall use the signature verification function of a known good implementation. ECDSA FIPS Signature Verification Test GSS CCT Assurance Activity Report Page 21 of Gossamer Security Solutions, Inc.

22 For each supported NIST curve (i.e., P-256, P-284 and P-521) and SHA function pair, the evaluator shall generate a set of bit message, public key and signature tuples and modify one of the values (message, public key or signature) in five of the 10 tuples. The evaluator shall obtain in response a set of 10 PASS/FAIL values. RSA Signature Algorithm Tests Signature Generation Test The evaluator shall verify the implementation of RSA Signature Generation by the TOE using the Signature Generation Test. To conduct this test the evaluator must generate or obtain 10 messages from a trusted reference implementation for each modulus size/sha combination supported by the TSF. The evaluator shall have the TOE use their private key and modulus value to sign these messages. The evaluator shall verify the correctness of the TSF's signature using a known good implementation and the associated public keys to verify the signatures. Signature Verification Test The evaluator shall perform the Signature Verification test to verify the ability of the TOE to recognize another party's valid and invalid signatures. The evaluator shall inject errors into the test vectors produced during the Signature Verification Test by introducing errors in some of the public keys e, messages, IR format, and/or signatures. The TOE attempts to verify the signatures and returns success or failure. The TOE has algorithm certificate #479 for Mocana Nanosec crypto library for ECDSA and algorithm certificate # 2347 for RSA (Sig (gen)) CRYPTOGRAPHIC OPERATION (CRYPTOGRAPHIC HASHING) (FCS_COP.1(3)) FCS_COP.1(3).1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined 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 GSS CCT Assurance Activity Report Page 22 of Gossamer Security Solutions, Inc.

23 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. Section 6.1 of the ST states that the Mocana Nanosec crypto library provides an implementation of the SHA-1, SHA-256, and SHA-384 hashing algorithms. These hash functions can be defined for use in an IPsec connection. Table 6 1 provides the corresponding CAVP certificate demonstrating compliance with these algorithms. Component Guidance Assurance Activities: None Defined Component Testing Assurance Activities: Requirement met by the TOE The TSF hashing functions can be implemented in one of two modes. The first mode is the byteoriented mode. In this mode the TSF only hashes messages that are an integral number of bytes in length; i.e., the length (in bits) of the message to be hashed is divisible by 8. The second mode is the bitoriented mode. In this mode the TSF hashes messages of arbitrary length. As there are different tests for each mode, an indication is given in the following sections for the bitoriented vs. the byteoriented testmacs. The evaluator shall perform all of the following tests for each hash algorithm implemented by the TSF and used to satisfy the requirements of this PP. Short Messages Test Bitoriented Mode The evaluators devise an input set consisting of m+1 messages, where m is the block length of the hash algorithm. The length of the messages range sequentially from 0 to m bits. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF. Short Messages Test Byteoriented Mode The evaluators devise an input set consisting of m/8+1 messages, where m is the block length of the hash algorithm. The length of the messages range sequentially from 0 to m/8 bytes, with each message being an integral number of bytes. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF. Selected Long Messages Test Bitoriented Mode GSS CCT Assurance Activity Report Page 23 of Gossamer Security Solutions, Inc.

24 The evaluators devise an input set consisting of m messages, where m is the block length of the hash algorithm. The length of the ith message is *i, where 1. i. m. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF. Selected Long Messages Test Byteoriented Mode The evaluators devise an input set consisting of m/8 messages, where m is the block length of the hash algorithm. The length of the ith message is *99*i, where 1. i. m/8. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF. Pseudorandomly Generated Messages Test This test is for byteoriented implementations only. The evaluators randomly generate a seed that is n bits long, where n is the length of the message digest produced by the hash function to be tested. The evaluators then formulate a set of 100 messages and associated digests by following the algorithm provided in Figure 1 of [SHAVS]. The evaluators then ensure that the correct result is produced when the messages are provided to the TSF. The TOE has algorithm certificate #2313 for Mocana Nanosec crypto library for SHS (SHA-1, SHA-256, SHA-384) CRYPTOGRAPHIC OPERATION (KEYED-HASH MESSAGE AUTHENTICATION) (FCS_COP.1(4)) FCS_COP.1(4).1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined 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 GSS CCT Assurance Activity Report Page 24 of Gossamer Security Solutions, Inc.

25 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. Section 6.1 of the ST states that the Mocana Nanosec crypto library provides an implementation of a keyed-hash message authentication code (HMAC). The library provides the HMAC-SHA-1, HMAC-SHA-256 and HMAC-SHA-384 algorithms. These algorithms are used with key sizes and block sizes of 160, 256 and 384 respectively, producing output MAC lengths equal to the block size. These keyed-hash functions can be defined for use in an IPsec connection. Table 6-1 provides the corresponding CAVP certificate demonstrating compliance with these algorithms. Component Guidance Assurance Activities: None Defined Component Testing Assurance Activities: Requirement met by the TOE For each of the supported parameter sets, the evaluator shall compose 15 sets of test data. Each set shall consist of a key and message data. The evaluator shall have the TSF generate HMAC tags for these sets of test data. The resulting MAC tags shall be compared to the result of generating HMAC tags with the same key and IV using a known good implementation. Extended: Internet Protocol Security (FCS_IPSEC_EXT) In order to show that the TSF implements the RFCs in accordance with the requirements of this PP, the evaluator shall perform the assurance activities listed below. In future versions of this PP, assurance activities may be augmented, or new ones introduced that cover more aspects of RFC compliance than are currently described in this publication. The TOE is required to use the IPsec protocol to establish connections used to communicate with a VPN Gateway. The evaluators shall minimally create a test environment equivalent to the test environment illustrated above. It is expected that the traffic generator is used to construct network packets and will provide the evaluator with the ability manipulate fields in the ICMP, IPv4, IPv6, UDP, and TCP packet headers. The evaluators must provide justification for any differences in the test environment. GSS CCT Assurance Activity Report Page 25 of Gossamer Security Solutions, Inc.

26 In the following elements of the FCS_IPSEC_EXT.1 component, it is allowable for some or all of the individual elements to be implemented by the platform on which the VPN client operates. The TSS of the VPN client will identify all of the information listed in the assurance activities of the elements; this may be repeated from the underlying platform's (if implemented by the platform) ST and should be indicated as such in the VPN client ST. If the configuration is to be performed on the platform, the evaluators shall ensure that the 'operational guidance' for each platform in the VPN Client ST contains the appropriate information (either through reference in the platform's ST, or by information contained in the VPN client ST). All tests must be performed by the evaluators using the VPN client and a representative sample of platforms listed in the VPN Client ST. The TOE has algorithm certificate #1718 for Mocana Nanosec crypto library for HMAC-SHA-1, HMAC-SHA-256 and HMAC-SHA EXTENDED: INTERNET PROTOCOL SECURITY (IPSEC) COMMUNICATIONS (FCS_IPSEC_EXT.1) FCS_IPSEC_EXT.1.1 TSS Assurance Activities: None Defined Guidance Assurance Activities: The evaluator shall examine the operational guidance to verify it instructs the Administrator how to construct entries into the SPD that specify a rule for DISCARD, BYPASS and PROTECT. The TOE does not support direct editing of SPD entries. See the Testing assurance activity for an explanation. Subsequently, the evaluators issued a question to NIAP about SPD activities and received the following guidance. See also NIAP TD0138. TSS 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 GSS CCT Assurance Activity Report Page 26 of Gossamer Security Solutions, Inc.

27 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 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. GUIDANCE 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. The ST has been revised to drop the mention of internal iptables processing since those functions are not visible to users in the evaluated configuration. Rather, the ST explains that the VPN client implement the PROTECT rule when it is connected with the mobile dice platform implementing BYPASS when the VPN client is not connected and DISCARD when the VPN client is connected, but traffic doesn t match the VPN. The Guidance is deemed acceptable since it explains how to configure and connect and disconnect a VPN client and all of its attributed. This is the full extent of control the user has over the actual SPDs. Testing Assurance Activities: The evaluator uses the operational guidance to configure the TOE and platform to carry out the following tests: GSS CCT Assurance Activity Report Page 27 of Gossamer Security Solutions, Inc.

28 Test 1: The evaluator shall configure the SPD such that there is a rule for DISCARD, BYPASS, PROTECT. The selectors used in the construction of the rule shall be different such that the evaluator can send in three network packets with the appropriate fields in the packet header that each packet will match one of the three rules. The evaluator observes via the audit trail, and packet captures that the TOE exhibited the expected behavior: appropriate packet was dropped, allowed through without modification, was encrypted by the IPsec implementation. Test 2: The evaluator shall devise two equal SPD entries with alternate operations - BYPASS and PROTECT. The entries should then be deployed in two distinct orders and in each case the evaluator shall ensure that the first entry is enforced in both cases by generating applicable packets and using packet capture and logs for confirmation. Test 3: The evaluator shall repeat the procedure above, except that the two entries should be devised where one is a subset of the other (e.g., a specific address vs. a network segment). Again, the evaluator should test both orders to ensure that the first is enforced regardless of the specificity of the rule. Test 1 The evaluator created a PROTECT SPD by establishing a VPN connection. For DISCARD, a rule was configured to discard packets and the packet capture showed those packets were lost. For BYPASS, a rule was configured to allow packets (with VPN disabled) and the packet capture showed those packets were accepted. Test 2 The DISCARD case above showed the device was blocking traffic from the VPN. Next the evaluator inserted a rule to allow in the bypass case showing an ordering affect and then added another blocking rule at the end showing that it had no effect. Test 3 The evaluator inserted a subset discard rule in front of an allow all rule and showed that the subset had the expected effect of causing the packets to be discarded. Subsequently, the evaluators issued a question to NIAP about SPD activities and received the following guidance. See also NIAP TD0138. TEST Given the degree of coupling between a VPN client and its underlying platform, it is expected that the client will be tested on each platform claimed in the ST. In cases where the platforms are simply different versions of the same operating system (provided by the same platform vendor), an equivalency argument may be made in lieu of testing on each version. The argument would have to demonstrate that the client interacts in exactly the same way with the versions of the OS - e.g., same APIs are used with the same parameters, the network stack is modified with the exactly the same kernel modules. The evaluator uses the operational guidance to configure the TOE and underlying platform. Depending on the implementation, the evaluator may be required to use a VPN gateway or some form of application to configure the client and platform. For Test 2, the evaluator is required to choose an application that allows for the configuration of the full set of capabilities of the VPN client (in conjunction with the platform). For example, if the client provides a robust interface that allows for specification of wildcards, subnets, etc., it is GSS CCT Assurance Activity Report Page 28 of Gossamer Security Solutions, Inc.

29 unacceptable for the evaluator to choose a VPN Gateway that only allows for specifying a single fully qualified IP addresses in the rule. The evaluator performs 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 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. Since control over SPDs is limited to connecting and disconnecting the VPN client, the evaluators showed that the mobile device 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). Additional tests were not performed given the limited possibility of rules and the fact that the TOE is not designed to act as a server and as such has limited ability to respond (hence, the use of pings) 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). Section 6.1 of the ST states that the TOE implements IPsec and can operate in tunnel mode while being conformant with RFC Guidance Assurance Activities: The evaluator shall confirm that the operational guidance contains instructions on how to configure the connection in each mode selected. The TOE supports tunnel mode only and is automatically in tunnel mode when the instructions in the User Guide for configuring basic and advanced VPN client options and connecting to the VPN gateway are followed. GSS CCT Assurance Activity Report Page 29 of Gossamer Security Solutions, Inc.

30 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, 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 ST indicates that the TOE supports IPsec capabilities as specified in RFC The TOE Platform supports the TOE implementation of IPSec by providing iptables filtering functionality that supports the TOE IPsec functions (i.e., iptables provide SDP rules). It further states that the TOE does not support editing of SPD rules. The TOE implicitly implements SPD rules through the configuration and connection of a VPN session. A VPN connection causes the TOE to implicitly define a PROTECT rule to IPsec encrypt and send all TOE traffic to the VPN gateway, along with a DISCARD rule to reject any traffic not part of the established VPN connection. A BYPASS rule is automatically configured when the TOE disconnects from 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 above for an explanation. Testing Assurance Activities: The evaluator shall perform the following test: GSS CCT Assurance Activity Report Page 30 of Gossamer Security Solutions, Inc.

31 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 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 that the TOE supports AES-GCM-128 and AES-GCM-256, AES-CBC-128, and AES-CBC- 256 modes for use with ESP. The AES-GCM ciphers are used in compliance with RFC These same 4 ciphers can be used with either IKEv1 or IKEv2. Section 6.1 also states that the TOE implements HMAC-SHA-1, HMAC-SHA-256 and HMAC-SHA-384 to support the IPsec connection which is consistent with the algorithms specified in FCS_COP.1(4). 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 1.2 of the User Guide describes Common Criteria (CC) Mode. It states that this feature restricts the use of cryptographic algorithms and enforces policies that are in accordance with the Protection Profile for IPsec Virtual Private Network (VPN) Clients, Version 1.4. Section 1.3 states that before connecting to a VPN gateway, a VPN connection profile must be created that will match the configuration expected by the VPN gateway. Section 2 and 3 describe how to create a profile and how to configure basic and advanced VPN client options. The VPN client options include setting the user authentication, IKEY key type (authentication method), IKE version, the PFS exchange, Phase 1 algorithms and DH groups. GSS CCT Assurance Activity Report Page 31 of Gossamer Security Solutions, Inc.

32 Section 4.7 describes how to configure the TOE in Common Criteria Mode. It states that when enabled, the available DH groups, Suite B and default cryptographic and hash algorithms are reduced to a subset that meets the requirements defined in the Protection Profile. Section 4.3 of the User Guide provides instructions for configuring Suite B algorithms. By default, the TOE will use AES-256-CBC or AES-128-CBC and SHA-1. Configuring Suite B provides the option of selecting AES-GCM-128 or AES-GCM-256. Section 4.5 states that when Suite B is selected, the DH group option is ignored. DH group 19 is only used when GCM-128 is selected. DH Group 20 is only used when GCM-256 is selected. CC mode and Suite B forces the use of the crypto, hash and DH group usage to only those that are Suite B approved and supported by CC mode. Section 9 of the User Guide indicates that there are many configuration options for a VPN tunnel which cannot be configured from the client and must be configured from the gateway. The VPN client will utilize these settings from the gateway configuration to construct the secure tunnel. The following settings must be configured through the gateway: Encryption settings the VPN client will use FIPS validated encryption, the gateway will specify which algorithms should be used. IKE Protocols & Authentication the gateway specifies which IKE protocols are allowed and which authentication techniques are required for establishing the connection. IPsec Session Key crypto period the gateway specifies the session key crypto periods and can be used to configure periods under 1 hour in duration. Certificate Validation The VPN gateway should be configured to check the validity of certificates it receives from the clients. For OCSP, the Responder(s) specified in the AIA URL field of the issued Certificates should be reachable by both the VPN Gateway and the Oceus VPN Client. The Oceus VPN Client will also perform certificate validation during the VPN tunnel negotiations. If the Responder(s) of the VPN gateway certificate chain are not reachable by the OVPN client, the VPN connection attempt will be terminated by the client. 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. GSS CCT Assurance Activity Report Page 32 of Gossamer Security Solutions, Inc.

33 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 ST indicates that the TOE supports the AES-GCM-128, AES-GCM-256, AES-CBC-128, and AES-CBC- 256 ciphers and that these ciphers can be used with either IKEv1 or IKEv2 payloads. The TOE supports IKEv2 as defined in RFCs 5996 (with mandatory support for NAT traversal as specified in section 2.23). 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.6 of the User Guide describes how to select the IKE version. IKE version 1 is the default. Section 1.2 of the User Guide states that NAT Traversal provides connectivity to users that are in networks that use Network Address Translation. NAT-T is automatically negotiated during IKE Phase 1 and redirects traffic to port 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 ST states that the TOE supports AES-GCM-128 and AES-GCM-256, AES-CBC-128, and AES-CBC- 256 modes for use with ESP and that the AES-CBC-128 and AES-CBC-256 ciphers can be used with either IKEv1 or IKEv2 payloads. 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 1.2 of the User Guide describes Common Criteria (CC) Mode. It states that this feature restricts the use of cryptographic algorithms and enforces policies that are in accordance with the Protection Profile for IPsec Virtual Private Network (VPN) Clients, Version 1.4. GSS CCT Assurance Activity Report Page 33 of Gossamer Security Solutions, Inc.

34 Section 1.3 states that before connecting to a VPN gateway, a VPN connection profile must be created that will match the configuration expected by the VPN gateway. Section 2 and 3 describe how to create a profile and how to configure basic and advanced VPN client options. The VPN client options include setting the user authentication, IKEY key type (authentication method), IKE version, the PFS exchange, Phase 1 algorithms and DH groups. Section 4.7 describes how to configure the TOE in Common Criteria Mode. It states that when enabled, the available DH groups, Suite B and default cryptographic and hash algorithms are reduced to a subset that meets the requirements defined in the Protection Profile. Section 4.3 of the User Guide provides instructions for configuring Suite B algorithms. By default, the TOE will use AES-256-CBC or AES-128-CBC and SHA-1. Configuring Suite B provides the option of selecting AES-GCM-128 or AES-GCM-256. Section 4.5 states that when Suite B is selected, the DH group option is ignored. DH group 19 is only used when GCM-128 is selected. DH Group 20 is only used when GCM-256 is selected. CC mode and Suite B forces the use of the crypto, hash and DH group usage to only those that are Suite B approved and supported by CC mode. Section 9 of the User Guide indicates that there are many configuration options for a VPN tunnel which cannot be configured from the client and must be configured from the gateway. The VPN client will utilize these settings from the gateway configuration to construct the secure tunnel. The following settings must be configured through the gateway: Encryption settings the VPN client will use FIPS validated encryption, the gateway will specify which algorithms should be used. IKE Protocols & Authentication the gateway specifies which IKE protocols are allowed and which authentication techniques are required for establishing the connection. IPsec Session Key crypto period the gateway specifies the session key crypto periods and can be used to configure periods under 1 hour in duration. Certificate Validation The VPN gateway should be configured to check the validity of certificates it receives from the clients. For OCSP, the Responder(s) specified in the AIA URL field of the issued Certificates should be reachable by both the VPN Gateway and the Oceus VPN Client. The Oceus VPN Client will also perform certificate validation during the VPN tunnel negotiations. If the Responder(s) of the VPN gateway certificate chain are not reachable by the OVPN client, the VPN connection attempt will be terminated by the client. 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. GSS CCT Assurance Activity Report Page 34 of Gossamer Security Solutions, Inc.

35 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 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 of the ST states that the TOE provides both main mode and aggressive mode. However, if the configuration profile indicates only main mode, then no aggressive mode connections are accepted by the device. Guidance indicates that aggressive mode should not be allowed in the profiles. 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. Section 4.4 of the User Guide provides instructions for configuring Main and Aggressive mode. There is a note in this section indicating that Main mode must be used in the CC evaluated configuration. 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. Test 1: 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. Note: A TRRT decision, for this evaluation only, was allowed for this test approach as representation of a failed attempt to connect using aggressive mode FCS_IPSEC_EXT.1.8 TSS Assurance Activities: None Defined 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 GSS CCT Assurance Activity Report Page 35 of Gossamer Security Solutions, Inc.

36 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. Section 9 of the User Guide indicates that there are many configuration options for a VPN tunnel which cannot be configured from the client and must be configured from the Gateway. The VPN client will utilize these settings from the gateway configuration to construct the secure tunnel. One of the settings that must be configured via the gateway is the IPsec session key crypto period. The gateway specifies the session key crypto periods and can be used to configure periods under one hour in duration. This section provides a table of settings that need to be 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 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 Not applicable. 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. GSS CCT Assurance Activity Report Page 36 of Gossamer Security Solutions, Inc.

37 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 of the ST states that the x value (256 bits) that is used in the IKE DH key exchange and the nonce (128 bits) are both obtained from the DRBG specified in FCS_RBG_EXT.1. This ensures that the probability they are repeated will be less than 2^256. Table 6-5 lists each DH group that the TOE supports including its modulus and strength. This list is consistent with those DH groups identified in FCS_IPSEC_EXT.1.11 as being supported by the TOE. Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined 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 TSS AA identified for FCS_IPSEC_EXT.1.9. Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined 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. GSS CCT Assurance Activity Report Page 37 of Gossamer Security Solutions, Inc.

38 Section 6.1 of the ST states that the TOE supports Diffie-Hellman groups 5, 14, 15, 16, 17, 18, 19, 20 and 24. The TOE configures one DH group per profile. Connections can be made only using the configured DH group. Guidance Assurance Activities: None Defined 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). 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 ST states that the TOE performs peer authentication using an RSA x509v3 certificate, or an ECDSA x509v3 certificate. The x509v3 certificates must be conformant with RFC This description is consistent with the algorithms specified in FCS_COP.1(2). Section 6.3 of the ST states that the TOE can authenticate IPsec peers using pre-shared keys. Section of the User Guide describes how pre-shared keys are to be generated and established. A pre-shared key can be between 1 and 64 characters, composed of any combination of upper and lower case letters, numbers, and special characters (that #, $, %, ^, &, *, (, and ) ). The TOE can also accept bit-based preshared keys, when specified in hex format. 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'. GSS CCT Assurance Activity Report Page 38 of Gossamer Security Solutions, Inc.

39 Section of the User Guide provides the settings for configuring the TOE to use certificates for peer authentication. The TOE does not generate certificate requests, but rather requires certificates to be loaded through the platform. Section 3.2 of the Product Guide provides instructions for generating, exporting and loading a certificate to a device. 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 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: Test Deleted by TD0053. 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. See the corresponding MDFPP evaluations (VID and VID 10739) for those operations. GSS CCT Assurance Activity Report Page 39 of Gossamer Security Solutions, Inc.

40 Subsequently, the evaluators issued a question to NIAP about SPD testing and received the following guidance. See also NIAP TD0140. The TRRT has determined that it is acceptable to expect different behavior from this type of VPN client implementation. Given the current lack of support for CSRs in the mobile space, operational guidance for installing a certificate for use by the TOE and verification that the TOE is able to use the configured certificate meets the intent of the requirement and assurance activity. Given that, since not all TOE platforms will be able to generate certificate requests, the VPN Client PP "FCS_IPSEC_EXT.1.12, Test 1" should be updated to allow the option of importing a private key and certificate. 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. Alternatively, the evaluator may import to the TOE/platform a previously generated private key and corresponding certificate. The evaluators imported all of the certificates used during testing. 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. This test was performed using RSA, ECDSA, IKEv1 and IKEv2. The test passed in all 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. 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 40 of Gossamer Security Solutions, Inc.

41 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 Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined 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 when certificates are used for authentication, the TOE establishes an SA only if the IP address or FQDN contained in a certificate matches the expected IP address or FQDN configured for the profile. Additional checks on a certificate enforce proper key usage, the validity period and revocation status. Section 6.3 of the ST indicates that the TOE processes a VPN connection to a server by first comparing the Identification (ID) Payload received from the server against the certificate sent by the server, and if the IP address or FQDN of the certificate does not match the ID, then the TOE does not establish the connection. Assuming the server s certificate matches the ID, the TOE then validates that it can construct a certificate path from the server s certificate through any intermediary CAs to the CA certificate specified by the user in the VPN configuration. 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 10 and 11 of the User Guide describes how to configure the validation options for certificate validations. The first option is Subject Name which if checked, the end-entity server certificate must contain a CommonName or SubjectAltName that matches the FQDN or the IP address of the VPN server. Testing Assurance Activities: (Per TD0037) For each supported identifier type (excluding DNs), the evaluator shall repeat the following tests: GSS CCT Assurance Activity Report Page 41 of Gossamer Security Solutions, Inc.

42 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. 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: Not Applicable GSS CCT Assurance Activity Report Page 42 of Gossamer Security Solutions, Inc.

43 Test 5: Not Applicable. Test 6: Not Applicable 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 ST states that the TOE supports AES-GCM-128 and AES-GCM-256, AES-CBC-128, and AES-CBC- 256 modes for use with ESP and that AES-CBC-128 and AES-CBC-256 can be used with either IKEv1 or IKEv2. Section 6.1 further states that the VPN Gateway (per TD 0097) provides the ability to ensure the strength of the symmetric algorithm negotiated to protect IKEv1 Phase 1 or IKEv2 IKE_SA connections is greater than or equal to the strength of the algorithm negotiated to protect the IKEv1 Phase 2 or IKEv2 CHILD_SA connections Guidance Assurance Activities: None Defined 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. 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. GSS CCT Assurance Activity Report Page 43 of Gossamer Security Solutions, Inc.

44 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. Note: A TRRT decision, for this evaluation only, was allowed for this test approach as representation of a failed attempt to connect using an unallowed cipher. Component TSS Assurance Activities: None Defined Component Guidance Assurance Activities: None Defined Component Testing Assurance Activities: None Defined EXTENDED: CRYPTOGRAPHIC OPERATION (RANDOM BIT GENERATION) (FCS_RBG_EXT.1) FCS_RBG_EXT.1.1 TSS Assurance Activities: Guidance Assurance Activities: None Defined Testing Assurance Activities: FCS_RBG_EXT.1.2 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined Component TSS Assurance Activities: (Per TD0079) Requirement met by the platform: GSS CCT Assurance Activity Report Page 44 of Gossamer Security Solutions, Inc.

45 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; nevertheless, 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 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. The Entropy description is provided in a separate (non-st) document that has been delivered to CCEVS for approval. Note that the entropy analysis has been accepted by CCEVS/NSA. The evaluator checked the Both-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. Component Guidance Assurance Activities: None Defined Component Testing Assurance Activities: (Per TD0079) The evaluator shall perform the following tests. 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 A). 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 GSS CCT Assurance Activity Report Page 45 of Gossamer Security Solutions, Inc.

46 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 Derivation Function 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 less then or equal to 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. Additional input: the additional input bit lengths have the same defaults and restrictions as the personalization string lengths. The TOE has algorithm certificate #460 for Mocana Nanosec crypto library for DRBG (AES-256 CTR-DRBG). 2.2 USER DATA PROTECTION (FDP) FULL RESIDUAL INFORMATION PROTECTION (FDP_RIP.2) FDP_RIP.2.1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined 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 GSS CCT Assurance Activity Report Page 46 of Gossamer Security Solutions, Inc.

47 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 ST states that the TOE has been designed to ensure that no residual information exists in network packets. When the TOE allocates a new buffer for either an incoming or outgoing 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, additional space will be overwritten (padded) with zeros before the packet is forwarded (to the external network or delivered to the appropriate, internal application). Component Guidance Assurance Activities: None Defined Component Testing Assurance Activities: None Defined 2.3 IDENTIFICATION AND AUTHENTICATION (FIA) EXTENDED: PRE-SHARED KEY COMPOSITION (FIA_PSK_EXT.1) FIA_PSK_EXT.1.1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined FIA_PSK_EXT.1.2 TSS Assurance Activities: None Defined GSS CCT Assurance Activity Report Page 47 of Gossamer Security Solutions, Inc.

48 Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined FIA_PSK_EXT.1.3 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined 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. 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. This requirement is met by the TOE. Section 6.3 of the ST states that the TOE can authenticate IPsec peers using pre-shared keys. A pre-shared key can be between 1 and 64 characters, composed of any combination of upper and lower case letters, numbers, and special characters (that #, $, %, ^, &, *, (, and ) ). The TOE can also accept bit-based pre-shared keys, when specified in hex format. 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. GSS CCT Assurance Activity Report Page 48 of Gossamer Security Solutions, Inc.

49 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 3.4 in the User Guide describes setting the IKE Key Type (ie. authentication method) including Pre-Shared Key. Guidance is provided to the user regarding the composition of strong text based keys including the minimum length. 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. 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 for all PSK-related IPsec tests. GSS CCT Assurance Activity Report Page 49 of Gossamer Security Solutions, Inc.

50 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.1.1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined FIA_X509_EXT.1.2 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined 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.3 of the ST indicates that the TOE validates authentication certificates (including the full path) and checks their revocation status using OCSP (compliant with RFC 2560). The TOE processes a VPN connection to a server by first comparing the Identification (ID) Payload received from the server against the certificate sent by the server, and if the IP address or FQDN of the certificate does not match the ID, then the TOE does not establish the connection. Assuming the server s certificate matches the ID, the TOE then validates that it can construct a certificate path from the server s certificate through any intermediary CAs to the CA certificate specified by the user in the VPN configuration. If the TOE can successfully build the certificate path, then the TOE will next check the validity of the certificates (e.g., checking its validity dates and that the CA flag is present in the basic constraints section for all CA certs). Assuming the certificates are valid, the TOE finally checks the revocation status of all certificates (starting the server s certificate and working up the chain). The TOE will reject any certificate for which it cannot determine the validity and reject the connection attempt. GSS CCT Assurance Activity Report Page 50 of Gossamer Security Solutions, Inc.

51 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. Sections 3 and 4 of the Product Guide describe how to configure basic and advanced VPN client options including the authentication and encryption algorithms and settings to be used for IPsec communications with a VPN gateway. Section 11 of the User Guide describes how to set up the Certificate Validation requirements including the reference identifier, key usage and known revocation status. 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. 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 GSS CCT Assurance Activity Report Page 51 of Gossamer Security Solutions, Inc.

52 because of a missing (or deleted) certificate. The connection was refused. This test was performed using RSA, ECDSA, IKEv1 and IKEv2. The test passed in all 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 performed using RSA, ECDSA, IKEv1 and IKEv2. The test passed in all instances. Test 3 See FCS_IPSEC_EXT.1.12, Test 3 where certificate revocation was tested. 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 performed using RSA, ECDSA, IKEv1 and IKEv2. The test passed in all 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 performed using RSA, ECDSA, IKEv1 and IKEv2. The test passed in all instances EXTENDED: X.509 CERTIFICATE USE AND MANAGEMENT (FIA_X509_EXT.2) FIA_X509_EXT.2.1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined 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 GSS CCT Assurance Activity Report Page 52 of Gossamer Security Solutions, Inc.

53 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 requires that for each VPN connection, the user specify the client certificate the TOE will use (the user must have previously loaded such a certificate into the keystore) and specify the CA certificate to which the server s certificate must chain. The TOE thus uses the specified certificate when attempting to establish that VPN connection. Section 6.3 of the ST further indicates that the TOE validates authentication certificates (including the full path) and checks their revocation station using either OCSP or CRL, based upon the certificate. The TOE will reject any certificate for which it cannot determine the validity and reject the connection attempt. Section 3.2 in the Product Guide describes how to use a certificate authority to configure, generate and export a certificate and then load the client certificate to the TOE device. Section 11 of the User Guide describes how to set up the Certificate Validation requirements including the reference identifier, key usage and known revocation status. Guidance Assurance Activities: None Defined 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. This test must be performed for each certificate revocation method selected in FIA_X509_EXT.1.1 (e.g. OCSP and/or CRL). (TD0053 applied) Test 1 - See Test 2 under FCS_IPSEC_EXT.1.12 where the first part of this test is performed to demonstrate that successful connections can be made when the revocation server is accessible. For the second part of this test, the revocation server was disabled so that it would not respond to requests (the service was disabled on the test server). The evaluator demonstrated that a connection cannot be made when the certificate validation server cannot be reached and that all supported administrator-configurable options behaved as documented FIA_X509_EXT.2.3 GSS CCT Assurance Activity Report Page 53 of Gossamer Security Solutions, Inc.

54 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined Component TSS Assurance Activities: None Defined Component Guidance Assurance Activities: None Defined Component Testing Assurance Activities: None Defined 2.4 SECURITY MANAGEMENT (FMT) SPECIFICATION OF MANAGEMENT FUNCTIONS (FMT_SMF.1(1)) FMT_SMF.1(1).1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined 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.3 of the ST states that the TOE uses X.509 certificates for authentication and that for each VPN connection, the TOE requires that the user specify the client certificate the TOE will use (the user must have previously loaded such a certificate into the keystore) and specify the CA certificate to which the server s certificate must chain. Section 6.3 further describes how the TOE validates the authentication certificates in order to determine whether or not the connection should be established. 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 6.4 of the ST identifies the following security management functions provided by the TOE, the VPN Gateway or the TOE Platform. GSS CCT Assurance Activity Report Page 54 of Gossamer Security Solutions, Inc.

55 The TOE provides functions allowing the user to select VPN gateway and credentials used to connect to those gateways (i.e., ability to configure the reference identifier for the peer). User Guide: Section 3.1 (VPN name), Section 3.2 (VPN server), Section 3.3 (user authentication with VPN gateway) & Section 4 (advanced settings) The TOE platform provides the ability to load X.509v3 certificates used for VPN connections using IPsec. Product Guide: Section (step 3) The TOE provides the ability to configure the version of IKE protocol that is to be used for communication with a given VPN gateway. User Guide: Section 3.6 The TOE provides the ability to configure the IKE authentication techniques to be used for communication with a given VPN gateway. User Guide: Section (pre-shared key), Section (certificate) & Section 4 (advanced settings) The VPN Gateway provides the ability to configure the cryptoperiod for the established session keys. The unit of measure for configuring the cryptoperiod shall be no greater than an hour. User Guide: Section 9 The TOE on a non-knox platform always rejects a certificate when the certificate revocation check cannot be performed. The TOE when running on a KNOX platform prompts the user for a decision on whether to accept the certificate when the certificate revocation check cannot be performed. Security Target (ST): Section The TOE and VPN Gateway provide the ability to specify the algorithm suites that may be proposed and accepted during the IPsec exchanges. User Guide: Section 4.3 (suite B), Section 4.5 (dh groups), Section 4.7 (CC mode) & Section 9 The TOE provides the ability to configure all security management functions identified in other sections of this ST. User Guide & Product Guide references as indicated throughout this AAR The TOE Platform provides the ability to update the TOE, and to verify the updates. Product Guide: Section 5 Section 9 of the User Guide indicates that there are many configuration options for a VPN tunnel which cannot be configured from the client and must be configured from the Gateway. The VPN client will utilize these settings from the gateway configuration to construct the secure tunnel. One of the settings that must be configured via the gateway is the Certificate Revocation Check. For OCSP, the Responder(s) specified in the AIA URL field of the issued Certificates should be reachable by both the VPN Gateway and the Oceus VPN Client. The Oceus VPN Client will also perform certificate validation during the VPN tunnel negotiations. If the Responder(s) of the VPN gateway certificate chain are not reachable by the OVPN client, the VPN connection attempt will be terminated by the client. 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. GSS CCT Assurance Activity Report Page 55 of Gossamer Security Solutions, Inc.

56 2.4.2 SPECIFICATION OF MANAGEMENT FUNCTIONS (FMT_SMF.1(2)) FMT_SMF.1(2).1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined 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. The User Guide and Product Guide describe how each of these functions are performed as documented in this AAR. 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. (Per TD0037) The evaluator shall ensure that the operational guidance instructs the administrator on configuring the reference identifier of the peer. The evaluator follows this guidance in the performance of the assurance activities for the FCS_IPSEC_EXT.1.14 and FCS_IPSEC_EXT.1.15 requirements. See FMT_SMF.1. 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 functions are tested 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 GSS CCT Assurance Activity Report Page 56 of Gossamer Security Solutions, Inc.

57 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.1.1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined FPT_TST_EXT.1.2 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined 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 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 GSS CCT Assurance Activity Report Page 57 of Gossamer Security Solutions, Inc.

58 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 of the ST states that the TOE performs known answer power on self-tests (POST) on its cryptographic algorithms to ensure that they are functioning correctly. The TOE executes the Mocana Cryptographic Library known-answer tests on the Mocana cryptographic functions to ensure they are working correctly. These tests cover the following Cryptographic Algorithm Tests: - AES-CBC, AES-GCM Known Answer Test - HMAC-SHA-1 Known Answer Test - HMAC-SHA-256 Known Answer Test - HMAC-SHA-384 Known Answer Test - HMAC-SHA-512 Known Answer Test - SHA-1 Known Answer Test - SHA-256 Known Answer Test - SHA-384 Known Answer Test - SHA-512 Known Answer Test - AES-CTR DRBG Known Answer Test - RSA Known Answer Test - ECDSA Known Answer Test In the event of a self-test failure, the Mocana library will enter an error state and a specific error code will be returned indicating which self-test or conditional test has failed. The Mocana library will not provide any cryptographic services while in this state. The TOE invokes these self-tests of the Mocana library at start-up to ensure that those cryptographic algorithms are working correctly. The TOE also verifies the integrity of its executable APK each time the VPN is executed using a 2048-bit RSA X509v3 certificate from Oceus Networks used only for signing the product. If the TOE is not signed with the Oceus Networks private signing key, the TOE terminates. 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. Section 6.5 of the ST states that the TOE executes the Mocana Cryptographic Library known-answer tests on the Mocana cryptographic functions to ensure they are working correctly. In the event of a self-test failure, the Mocana library will enter an error state and a specific error code will be returned indicating which self-test or conditional test has failed. The Mocana library will not provide any cryptographic services while in this state. The TOE invokes these self-tests of the Mocana library at start-up to ensure that those cryptographic algorithms are working correctly. The TOE also verifies the integrity of its executable APK each time the VPN is executed using GSS CCT Assurance Activity Report Page 58 of Gossamer Security Solutions, Inc.

59 a 2048-bit RSA X509v3 certificate from Oceus Networks used only for signing the product. If the TOE is not signed with the Oceus Networks private signing key, the TOE terminates. 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. 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 Since the integrity check is automatic and invoked when VPN functionality is used the results of the test setup server to demonstrate successful integrity checks. Test 2 The TOE executable was modified and the evaluator attempted to install it. This caused an integrity check on the modified executable to occur and the integrity check failed EXTENDED: TRUSTED UPDATE (FPT_TUD_EXT.1) FPT_TUD_EXT.1.1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined FPT_TUD_EXT.1.2 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined FPT_TUD_EXT.1.3 TSS Assurance Activities: None Defined GSS CCT Assurance Activity Report Page 59 of Gossamer Security Solutions, Inc.

60 Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined 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 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. Section 6.5 of the ST states that the TOE platform provides the ability to update and verify TOE updates (per Security Targets for VID and VID-10739). The OVPN TOE is provided as an APK. The APK is only distributed though Oceus Networks Sales and is either manually installed on the device or is distributed through an MDM suite using the underlying Android Platform for installation and validation. The Android platform enforces strict requirements when an application is updated. The android platform will only allow an APK/Application to be updated if the update is also signed with the same private key as the application being updated. During Installation, the Android platform performs validation to verify the key of the applications are identical. If the verification fails, the original installed application/apk remains intact without modification. The TOE version is available to a user on the 'About' screen presented by the TOE user interface. 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 16 of the User Guide states that once a device has been deployed, updates may be released to fix issues and provide new features of Oceus VPN Client. These updates are provided for Oceus as determined by Oceus Networks. When updates are made available, they are signed by Oceus Networks with a private key. The update package is checked automatically for integrity and validity by the Android Operating System. If the check fails, an error will be displayed and the update will not be installed. When updates are made, they are made available by Oceus Networks and distributed through the Oceus Networks sales channel. Each product release includes a set of Release Notes that provides details on new features and any issues that were addressed in the release. The Both-Platform-ST provides a discussion of the update process in the platform which is responsible for the function. GSS CCT Assurance Activity Report Page 60 of Gossamer Security Solutions, Inc.

61 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: The evaluator performed the version verification activity upon the initial installation of the TOE. The evaluator installs a legitimate TOE update using the procedures in the User Guide. Upon launching the client, the evaluator verifies the updated TOE version. Test 2: The evaluator attempts to install an illegitimate TOE update with a corrupted FIPS library. The installation fails and the TOE rejects the update. 2.6 TRUSTED PATH/CHANNELS (FTP) INTER-TSF TRUSTED CHANNEL (FTP_ITC.1) FTP_ITC.1.1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined FTP_ITC.1.2 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined GSS CCT Assurance Activity Report Page 61 of Gossamer Security Solutions, Inc.

62 Testing Assurance Activities: None Defined FTP_ITC.1.3 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined 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 ST states that the TOE initiates all communication with a VPN Gateway using an IPsec VPN. The TOE key exchange uses either IKEv1 or IKEv2 depending upon TOE configuration. The TOE uses IPsec to provide assurance in the identification of endpoints and to protect transmitted data from disclosure and modification. The only protocol described is IPsec which is included in the requirements and in the TSS. Section 6.1 contains a description of how the TOE can establish IPsec VPN connections with configured VPN Gateways. 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. Section 3 and 4 of the User Guide describe how to set up the VPN Client Profile and Section 5 describes how to connect to a VPN Gateway. Section 6 describes how to check the connection status with the VPN Gateway and Section 7 describes how to disconnect from the VPN gateway. Section 18 provides troubleshooting information consisting of a list of error messages and information on how to resolve the problem. 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. GSS CCT Assurance Activity Report Page 62 of Gossamer Security Solutions, Inc.

63 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 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 63 of Gossamer Security Solutions, Inc.

64 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). GSS CCT Assurance Activity Report Page 64 of Gossamer Security Solutions, Inc.

65 - 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. As described in Section 1.2 of the User Guide, the TOE includes the Common Criteria (CC) mode. This feature restricts the use of cryptographic algorithms and enforces policies that are in accordance to the National Information Assurance Partnership s Protection Profile for IPsec Virtual Private Network (VPN) Clients Version 1.4. Section 14 of the User Guide indicates that when updates are made available, they are signed by Oceus Networks with a private key. The update package is checked automatically for integrity and validity by the Android Operating System. If the check fails, an error will be displayed and the update will not be installed. When updates are made, they are made available by Oceus Networks and distributed through the Oceus Networks sales channel. Each product release includes a set of Release Notes that provides details on new features and any issues that were addressed in the release 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, GSS CCT Assurance Activity Report Page 65 of Gossamer Security Solutions, Inc.

66 ensure that after configuring the system according to the administrative guidance, non-administrative users are unable to access TOE administrative functions. There is no role separation. Section 4.7 of the User Guide explains how to put the device into CC mode. 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. GSS CCT Assurance Activity Report Page 66 of Gossamer Security Solutions, Inc.

67 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 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: GSS CCT Assurance Activity Report Page 67 of Gossamer Security Solutions, Inc.

68 Ubuntu Linux Windows Network Putty Connection (16.04) or (14.10) USB Connection TOE Device Figure 1 Evaluator Test Setup 1 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 2 GSS CCT Assurance Activity Report Page 68 of Gossamer Security Solutions, Inc.