Assurance Activity Report for BlackBerry Smartphones with OS VPN Client

Transcription

1 Assurance Activity Report for BlackBerry Smartphones with OS VPN Client Version January 2017 Prepared by: Electronic Warfare Associates-Canada, Ltd Michael Street Ottawa, Ontario, Canada K1J 7T2 Prepared for: Communications Security Establishment (CSE) and National Information Assurance Partnership (NIAP)

2 The Developer of the TOE: BlackBerry Limited 2200 University Avenue East Waterloo, Ontario N2K OA7 Canada Evaluator(s): Conan Hoye Common Criteria Versions Common Criteria for Information Technology Security Evaluation Part 1: Introduction, Version 3.1, Revision 4, September Common Criteria for Information Technology Security Evaluation Part 2: Security Functional Components, Version 3.1, Revision 4, September Common Criteria for Information Technology Security Evaluation Part 3: Security Assurance Components, Version 3.1, Revision 4, September Common Evaluation Methodology Versions Common Methodology for Information Technology Security Evaluation, Evaluation Methodology, Version 3.1, Revision 4, September Protection Profiles NIAP Protection Profile for IPsec Virtual Private Network (VPN) Clients, Version 1.4, 21 October 2013 Technical Decisions TD0037, TD0042, TD0053 and TD ii

3 1 Table of Contents 1 Introduction Evidence Equivalency Argument Security Functional Requirement Assurance Activities Class: Cryptographic Support (FCS) FCS_CKM.1(1) Cryptographic Key Generation (Asymmetric Keys) FCS_CKM.1 (2) Cryptographic Key Generation (for asymmetric keys - IKE) FCS_CKM_EXT.2 Cryptographic Key Storage FCS_CKM_EXT.4 Cryptographic Key Zeroization FCS_COP.1(1) Cryptographic Operation (Data Encryption/Decryption) FCS_COP.1(2) Cryptographic Operation (for cryptographic signature) FCS_COP.1(3) Cryptographic Operation (Cryptographic Hashing) FCS_COP.1(4) Cryptographic Operation (Keyed-Hash Message Authentication) FCS_IPSEC_EXT.1 Extended: Internet Protocol Security (IPsec) Communications FCS_RBG_EXT.1 Extended: Cryptographic operation (Random Bit Generation) Class: User Data Protection (FDP) FDP_IFC_EXT.1 Subset Information Flow Control FDP_RIP.2 Full Residual Information Protection Class: Identification and Authentication (FIA) FIA_X509_EXT.1 Extended: X.509 Certificate Validation FIA_X509_EXT.2 Extended: X.509 Certificate Use and Management Class: Security Management (FMT) FMT_SMF.1(1) Specification of Management Functions FMT_SMF.1(2) Specification of Management Functions Class: Protection of TOE (FPT) FPT_TST_EXT.1 Extended: TSF Self Test FPT_TUD_EXT.1 Extended: Trusted Update Class: Trusted Path/Trusted Channel (FTP) iii

4 2.6.1 FTP_ITC.1 Inter-TSF trusted channel Security Assurance Requirements Class ADV: Development ADV_FSP.1 Basic functional specification Class AGD: Guidance Documents AGD_OPE.1 Operational User Guidance AGD_PRE.1 Preparative Procedures Class ATE: Tests ATE_IND.1 Independent Testing - Conformance Class AVA: Vulnerability Assessment AVA_VAN.1 Vulnerability Survey Class ALC: Life-cycle Support ALC_CMC.1 Labeling of the TOE ALC_CMS.1 TOE CM coverage iv

5 1 Introduction This document presents assurance activity evaluation results of the TOE evaluation. There are three types of assurance activities and the following is provided for each: 1. TOE Summary Specification (TSS) - An indication that the required information is in the TSS section of the Security Target; 2. Guidance - A specific reference to the location in the guidance is provided for the required information; and 3. Test A summary of the test procedure used and the results obtained is provided for each required test activity. This Assurance Activities Report contains sections for each functional class and family and sub-sections addressing each of the SFRs specified in the Security Target. 1.1 Evidence The following is a list of the documents consulted: [ST] Security Target, Version 1.5, 24 January 2017 [VPN_PP] Protection Profile for IPsec Virtual Private Network (VPN) Clients, Version 1.4, 21 October 2013 [BB10_ST] BlackBerry Smartphones with OS Security Target, Version 1.10, 9 January 2016 [BB10_AGD_SUP] BlackBerry Smartphones with OS Common Criteria Guidance Supplement, Version: 1.0, 12 October 2016 [AGD_AG_BES] [AGD_INS_BES] Administration Guide BES12 Version 12.5, SWD , 24 August 2016 Installation and Upgrade Guide BES12 Version 12.5, SWD , 30 June 2016 [AGD_POL] Policy Reference Spreadsheet BES12.4, 24 March 2016 [AGD_SUP] [AGD_UG_CLASSIC] [AGD_UG_LEAP] [AGD_UG_P9982] Common Criteria Guidance Supplement, Version 1.0, 4 August 2016 BlackBerry Classic Smartphone Version: User Guide, SWD , 26 April 2016 BlackBerry Leap Smartphone Version: User Guide, SWD , 27 April 2016 BlackBerry P'9982 Smartphone Version: User Guide, SWD- 1

6 , 27 April 2016 [AGD_UG_P9983] [AGD_UG_PASSPRT] [AGD_UG_Q10] [AGD_UG_Z10] [AGD_UG_Z30] BlackBerry P'9983 Smartphone Version: User Guide, SWD , 27 April 2016 BlackBerry Passport Smartphone Version: User Guide, SWD , 27 April 2016 BlackBerry Q10 Smartphone Version: User Guide, SWD , 27 April 2016 BlackBerry Z10 Smartphone Version: User Guide, SWD , 27 April 2016 BlackBerry Z30 Smartphone Version: User Guide, SWD , 27 April Equivalency Argument The TOE is the VPN Client software of the BlackBerry OS that loads the VPN Profile which provides protection between itself and another VPN endpoint, such as a VPN Gateway. The TOE platform is the BlackBerry 10 smartphone running the BlackBerry OS. The list of TOE platforms claimed in the ST is longer than the list of platforms tested. The testing was performed on the following devices: Classic (SQC100-1); Passport (SQW100-1); Q10 (SQN100-3); Z30 (STA100-1). Equivalency will be claimed for all other models listed in the ST. The set of tested devices was selected to ensure that each CPU type is tested. These CPUs are used in other devices which are claimed in the ST such as the Leap, Z10, P 9982, and P9983. The smartphones have the following CPU: Passport: Qualcomm Snapdragon 801 MSM8974-AA Classic: Qualcomm MSM8960 Leap: Qualcomm MSM8960 Z30: Qualcomm MSM8960T Z10: Qualcomm MSM8960 Q10: Qualcomm MSM8960 2

7 P 9982: Qualcomm MSM8960T P 9983: Qualcomm MSM8960T The Z30 is equivalent to the P 9882, and P The Classic is equivalent to the Leap and Z10. There are no additional devices equivalent to the Q10 and Passport models. The hardware differences between models, such as the presence of a CDMA modem, support for different GSM, or LTE bands do not affect the TSF. The TSF are implemented in BB10 OS software which uses the process isolation and memory separation capabilities offered by the CPU. All devices run the same version of BlackBerry OS 10 (BBOS build 1668). 3

8 2 Security Functional Requirement Assurance Activities This section describes the assurance activities associated with the SFRs defined in the ST and the results of those activities as performed by the evaluation team. The assurance activities have been extracted from [VPN_PP]. 2.1 Class: Cryptographic Support (FCS) FCS_CKM.1(1) Cryptographic Key Generation (Asymmetric Keys) TSS Assurance Activity: 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). Section of the TSS of the [ST] specifies that the key establishment functionality is invoked through the IPsec client negotiation. Section of the TSS of the [ST] additionally specifies that all of the cryptographic functionality is invoked via the Security Builder API. This is confirmed for all claimed platforms in the [BB10_ST] section covering key establishment. Section of the [BB10_ST] specifies Key Agreement Scheme Certificate #13, which includes finite field Diffie Hellman schemes and elliptical curve Diffie Hellman schemes Guidance Assurance Activity: Test Assurance Activity: FCS_CKM.1 (2) Cryptographic Key Generation (for asymmetric keys - IKE) TSS Assurance Activity: 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). 4

9 Section of the TSS of the [ST] specifies that the key establishment functionality is invoked through the IPsec client negotiation. Section of the TSS of the [ST] additionally specifies that all of the cryptographic functionality is invoked via the Security Builder API. This is confirmed for all claimed platforms in the [BB10_ST] section covering key establishment. Section of the [BB10_ST] specifies elliptical curve CAVP certificate #199, which includes key generation Guidance Assurance Activity: Test Assurance Activity: FCS_CKM_EXT.2 Cryptographic Key Storage TSS Assurance Activity: 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. For each platform listed in the ST, the evaluator shall examine the ST of the platform to ensure that the persistent secrets and private keys listed as being stored by the platform in the VPN client ST are identified as being protected in that platform's ST. Persistent secrets and private keys manipulated by the TOE The evaluator reviews the TSS for to determine that it makes a case that, for each item listed as being manipulated by the TOE, it is not written unencrypted to persistent memory, and that the item is stored by the platform. Table 12 in the [ST] lists all persistent secrets and private keys. The table specifies use and storage for each key. The table specifies that all persistent keys are written to the flash using the secure key store. The [BB10_ST] in Sections , , and specifies that private keys can be stored in the secure key store Guidance Assurance Activity: 5

10 Test Assurance Activity: FCS_CKM_EXT.4 Cryptographic Key Zeroization TSS Assurance Activity: 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. 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. The [ST] lists in section all the keys used within the TOE and the means used to generate the keys. The keys used in the TOE are not generated with platform keys Guidance Assurance Activity: Test Assurance Activity: FCS_COP.1(1) Cryptographic Operation (Data Encryption/Decryption) TSS Assurance Activity: 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). Section of the [ST] specifies that all of the cryptographic functionality is invoked via the Security Builder API, and that AES-CBC and AES-GCM modes are supported. Section of the [ST] specifies that the following encryption sizes and modes are supported AES128, AES256, AES128_ICV16_GCM, and AES256_ICV16_GCM. The [BB10_ST] specifies in section , and that the BBOS platform supports 6

11 AES CBC and AES GCM with 128 and 256 bit keys. This is consistent with the selections made in the [ST] Guidance Assurance Activity: Test Assurance Activity: FCS_COP.1(2) Cryptographic Operation (for cryptographic signature) TSS Assurance Activity: 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). Section of the [ST] specifies that all of the cryptographic functionality is invoked via the Security Builder API. The [BB10_ST] specifies in section , and that the BBOS platform supports RSA and ECDSA digital signatures. This is consistent with the selections made in the [ST] Guidance Assurance Activity: Test Assurance Activity: FCS_COP.1(3) Cryptographic Operation (Cryptographic Hashing) TSS Assurance Activity: 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. 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). 7

12 Section of the [ST] specifies that all of the cryptographic functionality is invoked via the Security Builder API. The [BB10_ST] specifies in section , and that the BBOS platform supports SHA-1, SHA-256, SHA-385, and SHA-512. This is consistent with the selections made in the [ST]. The association of the hash function to IPSec Processing is described in section and for Trusted Update in section of [ST] Guidance Assurance Activity: Test Assurance Activity: FCS_COP.1(4) Cryptographic Operation (Keyed-Hash Message Authentication) TSS Assurance Activity: 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. For each platform listed in the ST, the evaluator shall examine the ST of the platform to ensure that the keyed hash function(s) claimed in that platform's ST contains the keyed hash function(s) in the VPN Client's ST. The evaluator shall also examine the TSS of the VPN Client's ST to verify that it describes (for each supported platform) how the keyed hash functionality is invoked for each digest size and key size selected in the VPN Client's ST (it should be noted that this may be through a mechanism that is not implemented by the VPN Client; nonetheless, that mechanism will be identified in the TSS as part of this assurance activity). Section of the [ST] specifies that all of the cryptographic functionality is invoked via the Security Builder API. The [BB10_ST] specifies in section , and that the BBOS platform supports HMAC-SHA-1, HMAC-SHA-256, and HMAC-SHA-385. This is consistent with the selections made in the [ST]. The association of the hash function to IPSec Processing is described in section and for Trusted Update in section of [ST] Guidance Assurance Activity: Test Assurance Activity: 8

13 2.1.9 FCS_IPSEC_EXT.1 Extended: Internet Protocol Security (IPsec) Communications FCS_IPSEC_EXT TSS Assurance Activity: Guidance Assurance Activity: 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. Section 2.2 of the [AGD_SUP] specifies that the following: The TOE implements a Security Policy Database (SPD) in accordance with RFC 4301 that provides the rules for how a packet is processed through the use of the VPN profile. If a packet does not meet the required conditions for passing the packet, the packet will be discarded. The SPD is configured through the IT Policy. The evaluator verified that this guidance is accurate in testing. The SPD entry is configured through IT policy Test Assurance Activity: The evaluator uses the operational guidance to configure the TOE and platform to carry out the following tests: Test 1: The evaluator shall configure the SPD such that there is a rule for 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. The evaluator first created a PROTECT SPD entry by establishing a VPN connection to a VPN gateway. The TOE implements a DISCARD rule when no other rule is met. The evaluator configured the TOE to discard packets in this manner. The evaluator created a BYPASS rule to allow packets to travel outside the VPN. In each case the evaluator performed a packet capture that showed those packets were protected, discarded and bypassed as per the rules created. In this manner the evaluator tested the TOE to meet the Test 1 requirements. The evaluator created a PROTECT entry in the SPD by establishing a VPN connection to a VPN gateway. 9

14 The evaluator then created a BYPASS rule on the TOE for the same subnet associated with the PROTECT SPD entry. The evaluator then verified that the packets sent were still protected. In this manner the evaluator tested the TOE to meet the Test 2 requirements. The evaluator created a PROTECT entry in the SPD by establishing a VPN connection to a VPN gateway. The evaluator then created a BYPASS rule on the TOE for half of the subnet associated with the PROTECT SPD entry. The evaluator then verified that the packets sent to the half of the subnet associated with the BYPASS rule were still protected. In this manner the evaluator tested the TOE to meet the Test 3 requirements FCS_IPSEC_EXT TSS Assurance Activity: 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 of the [ST] specifies that VPNs can be established in tunnel mode. This is consistent with the selection in the associated SFR Guidance Assurance Activity: The evaluator shall confirm that the operational guidance contains instructions on how to configure the connection in each mode selected. The evaluator verified during functional testing that the TOE only supports tunnel mode. This is consistent with the selection in the [ST] Test Assurance Activity: 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. 10

15 The evaluator configured the TOE and VPN gateway to use tunnel mode and the claimed cryptographic algorithms. The evaluator then initiated the VPN connection from the TOE. Once connected the evaluator verified that the VPN connection was established in tunnel mode using a packet capture and verified the audit logs on the VPN gateway FCS_IPSEC_EXT TSS Assurance Activity: 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 of the TSS specifies that the TOE platform implements a Security Policy Database (SPD) in accordance with RFC 4301 that provides the rules for how a packet is processed through the use of the VPN profile. If a packet does not meet the required conditions for passing the packet, the packet will be discarded Guidance Assurance Activity: 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. Section 2.2 of the [AGD_SUP] specifies that the following: The TOE implements a Security Policy Database (SPD) in accordance with RFC 4301 that provides the rules for how a packet is processed through the use of the VPN profile. If a packet does not meet the required conditions for passing the packet, the packet will be discarded. The SPD is configured through the IT Policy. The evaluator verified that this guidance is accurate in testing. The SPD entry is configured through IT policy Test Assurance Activity: The evaluator shall perform the following test: Test 1: The evaluator shall configure the SPD such that it has entries that contain operations that DISCARD, BYPASS, and PROTECT network packets. The evaluator may use the SPD that was created for verification of FCS_IPSEC_EXT.1.1. The evaluator shall construct a network packet that matches a BYPASS entry and send that packet. The evaluator should observe that the network packet is passed to the proper destination interface with no modification. The evaluator shall then modify a field in the packet header; such that it no longer matches the evaluatorcreated 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. 11

16 The evaluator created a BYPASS rule for the TOE and sent ICMP packets from the bypassed subnet to the TOE. Using a packet capture, the evaluator verified that responses were provided to the ICMP packets. The evaluator then used a spoofed IP address, which was not part of the bypassed subnet, and verified that the TOE did not send replies. The evaluator reviewed the TOE audit log and packet captures to verify the modified packet was discarded by the TOE FCS_IPSEC_EXT TSS Assurance Activity: 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). The evaluator has verified that AES with CBC and GCM modes are supported for 128 and 256 bit keys. The [ST] Section(s) & also specify that SHA and HMAC algorithms conforming to FCS_COP.1(3) and FCS_COP.1(4) are supported by the TOE Guidance Assurance Activity: 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. Instructions to configure AES with CBC and GCM modes for 128 and 256 bit keys are described in: a. [AGD_SUP], Version 1.0, 4 August 2016, section 2.2, VPN Policy Settings; and b. [AGD_AG_BES], SWD , 23 March 2016, section 14, Profile settings. The evaluator verified that the guidance describes the configuration of the algorithms selected in the [ST] Test Assurance Activity: 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/platofrm is configured to use those algorithms and the evaluator attempts to establish a connection using ESP for those algorithms selected. The evaluator configured the TOE and VPN gateway to use each of the claimed IPsec AES key sizes and modes sequentially. Once configured, the evaluator initiated the VPN connection from the TOE. The evaluator then verified that the connection was established with the specified IPsec AES key size and mode by examining the packet capture and the audit logs on the VPN gateway. 12

17 FCS_IPSEC_EXT TSS Assurance Activity: The evaluator shall examine the TSS to verify that IKEv1 and/or IKEv2 are implemented. Section of the [ST] specifies that only IKEv2 is supported in the evaluated configuration Guidance Assurance Activity: 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. Instructions to configure IKEv2 are described in: a. [AGD_SUP], Version 1.0, 4 August 2016, section 2.2, VPN Policy Settings; and b. [AGD_AG_BES], SWD , 23 March 2016, section 14, BlackBerry 10: VPN profile settings. The TOE does not support IKEv1. The evaluator verified IKEv2 is supported by default through testing of the TOE Test Assurance Activity: 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. The evaluator configured the TOE and VPN gateway to use Network Address Translation (NAT) to access a remote subnet. The evaluator then initiated the VPN connection from the TOE and verified that the connection was established. The evaluator then browsed to a website and sent ICMP messages through the VPN and verified that the NAT traversal was successful FCS_IPSEC_EXT TSS Assurance Activity: 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. 13

18 Section of the [ST] specifies AES-CBC-128, AES-CBC-256, AES-ICV16-GCM-128 and AES-ICV16-GCM- 256 as the algorithms for encrypting the IKEv2 payload Guidance Assurance Activity: 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. The configuration of algorithms is described in: a. [AGD_SUP], Version 1.0, 4 August 2016, section 2.2, VPN Policy Settings; and b. [AGD_AG_BES], SWD , 23 March 2016, section 14, Profile settings. The evaluator verified that the guidance describes the configuration of the algorithms selected in the [ST] Test Assurance Activity: 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. The evaluator configured the TOE and VPN gateway to use each of the claimed IKE AES key sizes and modes sequentially. Once configured, the evaluator initiated the VPN connection from the TOE. The evaluator then verified that the VPN connection was established, with the specified IKE AES key size and mode, by examining a packet capture and the audit logs on the VPN gateway FCS_IPSEC_EXT TSS Assurance Activity: 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 of the [ST] specifies that IKEv1 is not used Guidance Assurance Activity: 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. 14

19 This is not applicable as IKEv1 is not supported by the TOE Test Assurance Activity: 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. This is not applicable as IKEv1 is not supported by the TOE FCS_IPSEC_EXT TSS Assurance Activity: Guidance Assurance Activity: The evaluator verifies that the values for SA lifetimes can be configured and that the instructions for doing so are located in the operational guidance. If time-based limits are supported, the evaluator ensures that either the Administrator or VPN Gateway are able to configurable Phase 1 SAs values for 24 hours and 8 hours for Phase 2 SAs. Currently there are no values mandated for the number of packets or number of bytes, the evaluator just ensures that this can be configured if selected in the requirement. Instructions to configure IKE Security Association (SA) lifetimes are described in: a. [AGD_SUP], Version 1.0, 4 August 2016, section 2.2, VPN Policy Settings; and b. [AGD_AG_BES], SWD , 24 August 2016, section 15, BlackBerry 10: VPN profile settings. The evaluation required IKEv2 SA lifetime recommended value to set is 86,400 seconds. The evaluator verified that the guidance documentation specifies the means to configure the SA lifetimes is time based and the unit used in configuring the time is seconds Test Assurance Activity: 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. 15

20 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. The TOE does not support SA lifetimes based upon data throughput. Therefore Test 1 does not apply. The [ST] selection for FCS_IPSEC_EXT.1.8 is consistent with the implementation. The evaluator configured the TOE to use a SA lifetime for Phase 1 of seconds (24 hrs.) and connected the VPN. The evaluator then waited 24hrs and confirmed that the SA was renegotiated in less time than the allotted SA lifetime. The packet capture showed a CREATE_CHILD_SA IKE exchange. The evaluator then configured the TOE to use a SA lifetime for Phase 2 of seconds (8 hrs.) and connected the VPN. The evaluator then waited 8hrs and confirmed that the SA was renegotiated in less time than the allotted SA lifetime. The audit log showed a CREATE_CHILD_SA IPsec exchange FCS_IPSEC_EXT TSS Assurance Activity: 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 of the [ST] specifies each DH group supported and the process for generating x and each nonce. The process for generation of x and the nonce uses the TOE platform DRBG. Section of the [ST] also specifies that the DRBG meets the probability requirement by using the platform provided DRBG Guidance Assurance Activity: Test Assurance Activity: 16

21 FCS_IPSEC_EXT TSS Assurance Activity: 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 of the [ST] specifies each DH group supported and the process for generating x and each nonce. The process for generation of x and the nonce uses the TOE platform DRBG. Section of the [ST] also specifies that the DRBG meets the probability requirement by using the platform provided DRBG Guidance Assurance Activity: Test Assurance Activity: FCS_IPSEC_EXT TSS Assurance Activity: The evaluator shall check to ensure that the DH groups specified in the requirement are listed as being supported in the TSS. If there is more than one DH group supported, the evaluator checks to ensure the TSS describes how a particular DH group is specified/negotiated with a peer. Section of the [ST] specifies that Diffie-Hellman Groups 5, 14, 19, 20 and 24 are supported. The evaluator has verified that this is consistent with the selection in the Section of the [ST]. Section of the [ST] further specifies that the negotiation of the group size is performed as per RFC Guidance Assurance Activity: Test Assurance Activity: 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 17

22 successfully completed using that particular DH group. The evaluator configured the TOE and VPN gateway to use each claimed Diffie Hellman group. The evaluator then initiated the VPN connection from the TOE, and verified that it was established using the specified Diffie Hellman Group. The evaluator verified this using packet captures and by viewing the audit logs on the VPN gateway FCS_IPSEC_EXT TSS Assurance Activity: 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 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 preshared key. Section of the [ST] specifies that peer authentication is performed using either RSA or ECDSA. This is consistent with the selections in FCS_COP.1(2). As pre-shared keys are not an indicated selection in FCS_IPSEC_EXT.1, the TSS does not describe this option Guidance Assurance Activity: The evaluator shall check that the operational guidance describes how pre-shared keys are to be generated and established. The evaluator ensures the operational guidance describes how to set up the TOE/platform to use the cryptographic algorithms RSA and/or ECDSA. The TOE does not use pre-shared keys. [AGD_SUP], Version 1.0, 4 August 2016, section 2.2, VPN Policy Settings indicates that peer authentication can be performed using either RSA or ECDSA, and the choice is made by selecting the certificate with which to authenticate Test Assurance Activity: 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 18

23 a valid certificate for that CA is loaded into the TOE/platform and marked trusted. 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: The evaluator shall ensure that the TOE is configurable to either establish an SA, or not establish an SA if a connection to the certificate validation entity cannot be reached. For each method selected for certificate validation, the evaluator attempts to validate the certificate - for the purposes of this test, it does not matter if the certificate is revoked or not. For the mode where an SA is allowed to be established, the connection is made. Where the SA is not to be established, the connection is refused. 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. TD0053 removes Test 5. The TOE platform generates keys and submits a CSR with simple certificate enrollment protocol (SCEP) as configured by the administrator. During enrollment of the TOE platform into management, the (SCEP) certificate signing occurs. The evaluator verified this by enrolling the TOE and viewing the signed certificates. The evaluator verified that the fully qualified domain name of the VPN gateway is specified in the VPN policy configuration. The evaluator verified that the VPN gateway was configured with a server certificate which chained to a root certificate installed on the TOE platform. The evaluator then successfully connected the to the VPN gateway. In this way the evaluator verified that the TOE performs certificate verification during an IKE exchange. 19

24 The evaluator configured the TOE to use OCSP and connected successfully to the VPN gateway. The evaluator then revoked the certificate on the OCSP responder. The evaluator then verified that the TOE no longer allowed connections to the VPN gateway, and reported that the certificate was not valid. The evaluator installed a server certificate which did not match the expected reference identifier onto the VPN gateway. The evaluator then attempted to connect to the VPN gateway from the TOE. The TOE denied the connection to the VPN gateway indicating that the certificate was not valid. The evaluator repeated this test case with an invalid SAN in the certificate. The TOE does not support the use of pre-shared keys in the evaluated configuration FCS_IPSEC_EXT TSS Assurance Activity: 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 of the TSS specifies that the fully qualified domain name specified in the configuration of the VPN tunnel is compared to the one presented in the peer certificate as follows: During authentication, the Gateway Authentication ID is compared against one identifier in a certificate based on the Gateway Authentication ID Type. Table 14 in Section specifies that the authentication ID type must be specified in the configuration of the VPN tunnel. This is how the TOE selects which certificate field to compare to the configured authentication ID as follows: Gateway authentication ID type: Guidance Assurance Activity: Fully Qualified Domain Name, address, Identity certificate distinguished name One of these selections must be made in the evaluated configuration The evaluator shall ensure that the operational guidance includes the configuration of the reference identifier(s) for the peer. The evaluator verified that [AGD_AG_BES], SWD , 23 March 2016, section 14, Profile settings, includes the configuration of the reference identifier for the peer under. The value to specify in the VPN profile is the Gateway Authentication ID Test Assurance Activity: For each supported identifier type (excluding DNs), the evaluator shall repeat the following tests: 20

25 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. The evaluator created test certificates with a fully qualified domain name and address in both the CN and SAN. The evaluator the provided the correct reference identifier to the TOE, and verified that IKE authentication was successful. The evaluator then created test certificates with an incorrect fully qualified domain name and address in both the CN and SAN. The evaluator the provided the correct reference identifier to the TOE, and verified that IKE authentication was unsuccessful. The evaluator then repeated the steps above configuring the DN of the certificate and verified the results were the same. The evaluator then created test certificates with and without the SAN field, and with a mismatch between the SAN and Common Name fields. The TOE correctly provided support for the CN and SAN fields with preference for the SAN as per the application note. 21