Hypori Virtual Mobile Infrastructure Platform Android Cloud Environment Client Common Criteria Assurance Activities Report

Transcription

1 Hypori Virtual Mobile Infrastructure Platform Android Cloud Environment Client Common Criteria Assurance Activities Report Version 1.0, February 17, 2016 Prepared by: Leidos Inc. (formerly Science Applications International Corporation) Common Criteria Testing Laboratory 6841 Benjamin Franklin Drive Columbia, MD 21046

2 Prepared for: National Information Assurance Partnership Common Criteria Evaluation and Validation Scheme The Developer of the TOE: Hypori, Inc Waterford Centre Blvd, Suite 100 Austin, TX The TOE Evaluation was Sponsored by: Hypori, Inc Waterford Centre Blvd, Suite 100 Austin, TX Evaluation Personnel: Greg Beaver Cody Cummins Zalman Kuperman Common Criteria Versions 1

3 Common Criteria for Information Technology Security Evaluation Part 1: Introduction, Version 3.1, Revision 4, dated: September Common Criteria for Information Technology Security Evaluation Part 2 (Extended): Security Functional Components, Revision 4, dated: September Common Criteria for Information Technology Security Evaluation Part 3 (Extended): Security Assurance Components, Revision 4, dated: September Common Evaluation Methodology Versions Common Methodology for Information Technology Security Evaluation, Evaluation Methodology, Version 3.1, Revision 4, dated: September Protection Profiles [PP_APP_SW] Protection Profile for Application Software, Version 1.1, 5 November 2014 (PP APP SW) including DoD Annex for Protection Profile for Application Software v1.0, Version 1, Release 1 (DoD Annex), 22 October NIAP Technical Decision TD0051 Android Implementation of TLS in App PP v1.1 applies and is addressed in the ST. The following NIAP Technical Decisions apply to evaluation assurance activities. o TD0054: Clarification of FPT_API_EXT.1.1 Requirement in APP PP v1.1 o TD0050: FMT_CFG_EXT.1.2 Change in APP SW PPv1.1. 2

4 Table of Contents 1 Introduction Evidence Security Functional Requirement Assurance Activities Cryptographic Support (FCS) FCS_RBG_EXT.1 Random Bit Generation Services FCS_CKM_EXT.1 Cryptographic Key Generation Services FCS_STO_EXT.1 Storage of Secrets FCS_TLSC_EXT.1(1) TLS Client Protocol Android FCS_TLSC_EXT.1.2(1) Android FCS_TLSC_EXT.1.3(1) Android FCS_TLSC_EXT.1.4(1) Android FCS_TLSC_EXT.1.5(1) Android FCS_TLSC_EXT.1(2) TLS Client Protocol Android FCS_TLSC_EXT.1.2(2) Android FCS_TLSC_EXT.1.3(2) Android FCS_TLSC_EXT.1.4(2) Android FCS_TLSC_EXT.1.5(2) Android FCS_TLSC_EXT.1 TLS(3) Client Protocol Android 5.0, FCS_TLSC_EXT.1.2 Android(3) 5.0, FCS_TLSC_EXT.1.3(3) Android 5.0, FCS_TLSC_EXT.1.4(3) Android 5.0, FCS_TLSC_EXT.1.5(3) Android 5.0, User Data Protection (FDP) FDP_DEC_EXT.1 Access to Platform Resources FDP_DAR_EXT.1 Encryption Of Sensitive Application Data Identification and Authentication (FIA) FIA_X509_EXT.1 X.509 Certificate Validation FIA_X509_EXT.2 X.509 Certificate Authentication Security Management (FMT) FMT_MEC_EXT.1 Supported Configuration Mechanism FMT_CFG_EXT.1 Secure by Default Configuration FMT_SMF.1 Specification of Management Functions Protection of the TSF (FPT) FPT_API_EXT.1 Use of Supported Services and APIs FPT_AEX_EXT.1 Anti-Exploitation Capabilities FPT_TUD_EXT.1 Integrity for Installation and Update FPT_LIB_EXT.1 Use of Third Party Libraries Trusted Path/Channel (FTP) FPT_DIT_EXT.1 Protection of Data in Transit Security Assurance Requirements

5 3.1 Class ADV: Development ADV_FSP.1 Basic Functional Specification Class AGD: Guidance Documents AGD_OPE.1 Operational User Guidance AGD_PRE.1 Preparative Procedures ATE_IND.1 Independent Testing Conformance ATE_IND.1 Assurance Activity Class AVA: Vulnerability Assessment AVA_VAN.1 Assurance Activity Class ALC: Life-Cycle Support ALC_CMC.1 Labeling of the TOE Assurance Activity ALC_CMS.1 TOE CM Coverage Assurance Activity ALC_TSU_EXT.1 Timely Security Updates

6 1 INTRODUCTION This document presents assurance activity evaluation results of the Hypori Virtual Mobile Infrastructure Platform Android Cloud Environment Client 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 3. Test a summary of the test procedure and result 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 [ST] Hypori Virtual Mobile Infrastructure Platform Android Cloud Environment Client Security Target, Version 1.0, February 17, 2016 [ACE_CC] Hypori ACE User Guide Common Criteria Configuration and Operation - Version [ACE_CLIENT_INSTALL] Hypori ACE Client Install Guide for Android Devices, version 3.1 Enterprise Distribution [UG_ANDROID] Hypori ACE User Guide for Android Devices, Version 3.1- ACE Device 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 are derived from [PP_APP_SW]. 2.1 Cryptographic Support (FCS) FCS_RBG_EXT.1 Random Bit Generation Services FCS_RBG_EXT TSS Assurance Activities If use no DRBG functionality is selected, the evaluator shall inspect the application and its developer documentation and verify that the application needs no random bit generation services. The SFR states that the application shall use no DRBG functionality for its cryptographic operations. The TSS states that the ACE Client relies on the Android platform for cryptographic services. Consequently, the ACE Client itself uses no DRBG functions. The evaluator inspected the guidance documentation and the security target and verified that the application needs no random bit generation services. The evaluator inspected the application through the actions of the functional tests and verified that the TOE did not rely upon DRBG functionality. 5

7 2.1.2 FCS_CKM_EXT.1 Cryptographic Key Generation Services This requirement depends upon selection in FCS_TLSC_EXT FCS_CKM_EXT Assurance Activities The evaluator shall inspect the application and its developer documentation to determine if the application needs asymmetric key generation services. If not, the evaluator shall verify the generate no asymmetric cryptographic keys selection is present in the ST. Otherwise, the evaluation activities shall be performed as stated in the selection-based requirements. The evaluator inspected the developer documentation and determined that the application relies upon the asymmetric key generation services provided by the Android platform. The evaluator verified that the selection generate no asymmetric cryptographic keys is present in the ST FCS_STO_EXT.1 Storage of Secrets FCS_STO_EXT TSS Assurance Activities The evaluator shall check the TSS to ensure that it lists all persistent credentials (secret keys, PKI private keys, or passwords) needed to meet the requirements in the ST. For each of these items, the evaluator shall confirm that the TSS lists for what purpose it is used, and how it is stored. For all credentials for which the application invokes platform-provided functionality, the evaluator shall perform the following actions which vary per platform. For Android: The evaluator shall verify that the application uses the Android KeyStore to store certificates. [ST] Section FCS_STO_EXT.1 identifies and describes the ACE Client persistent credentials and how the client stores each credential. The ACE Client persistent credentials are identified as the following: User TLS client key - Authenticates ACE client when establishing TLS connection to ACE Server Server account password - Authenticates user to ACE Server The TSS states that both the user TLS client key and the server account password are stored in the Android KeyStore. [ST] Appendix: Android APIs identifies that the ACE Client uses the java.security.keystore API. 6

8 2.1.4 FCS_TLSC_EXT.1(1) TLS Client Protocol Android FCS_TLSC_EXT.1.1(1) Android 4.3 This requirement depends upon selection in FTP_DIT_EXT TSS Assurance Activities The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that the ciphersuites supported are specified. The evaluator shall check the TSS to ensure that the ciphersuites specified include those listed for this component. [ST] Section FCS_TLSC_EXT.1 identifies the ciphersuites that the ACE Client supports. Ciphersuites are unique to each of the Android operating system versions and the SFR is iterated for each Android version. The ciphersuites listed in in the TSS are those that are listed in the SFR component Guidance Assurance Activities The evaluator shall also check the operational guidance to ensure that it contains instructions on configuring the TOE so that TLS conforms to the description in the TSS. [ACE_CC] Section 3 Guidance Documentation states that Hypori s general ACE Client applies in the evaluated configuration along with this Common Criteria specific guidance. The general guidance covers Android 4.3, 4.4, 5.0, and 5.1, and there is no version-specific configuration. Cipher suites are determined by choice of Android version not ACE Client configuration. [ACE_CC] Section 6 Provisioning of ACE Client Credentials states that to configure an ACE client account, the user must provide a hostname and port for the ACE server, a name for the account, an optional password (to access the server), and a client certificate/credential. The 3.1 version of the ACE client does not create nor install credentials into the Android KeyChain. It is expected that some other out-of-band process is used to create and install the keys into the KeyChain. Once installed, the ACE Client s account can be created using the Add Account option to associate the account with a credential. Guidance is provided in the different ways used create and install credentials into the Android KeyChain. One of the methods directs the user to a self-provisioning portal using Microsoft certificate services or equivalent, and downloads the credentials to the device and loads them into the Android KeyChain (an example of this is described in the Creating the Client Certificate online help topic in the ACE User Guide for Android Devices Version 3.1 product documentation. The instructions on configuring the TOE conform to the TLS description in the TSS Test Assurance Activities The evaluator shall also perform the following tests: Test 1: The evaluator shall establish a TLS connection using each of the ciphersuites specified by the requirement. This connection may be established as part of the establishment of a higherlevel protocol, e.g., as part of an EAP session. It is sufficient to observe the successful negotiation of a ciphersuite to satisfy the intent of the test; it is not necessary to examine the characteristics of the 7

9 encrypted traffic in an attempt to discern the ciphersuite being used (for example, that the cryptographic algorithm is 128bit AES and not 256bit AES). See the test results in AAR Section Test 2: The evaluator shall attempt to establish the connection using a server with a server certificate that contains the Server Authentication purpose in the extendedkeyusage field and verify that a connection is established. The evaluator will then verify that the client rejects an otherwise valid server certificate that lacks the Server Authentication purpose in the extendedkeyusage field and a connection is not established. Ideally, the two certificates should be identical except for the extendedkeyusage field. See the test results in AAR Section Test 3: The evaluator shall send a server certificate in the TLS connection that does not match the serverselected ciphersuite (for example, send a ECDSA certificate while using the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite or send a RSA certificate while using one of the ECDSA ciphersuites.) The evaluator shall verify that the TOE disconnects after receiving the server s Certificate handshake message. See the test results in AAR Section Test 4: The evaluator shall configure the server to select the TLS_NULL_WITH_NULL_NULL ciphersuite and verify that the client denies the connection. See the test results in AAR Section The evaluator shall perform the following modifications to the traffic: Test 5.1: Change the TLS version selected by the server in the Server Hello to a non-supported TLS version (for example 1.3 represented by the two bytes 03 04) and verify that the client rejects the connection. See the test results in AAR Section The evaluator shall perform the following modifications to the traffic: Test 5.2: Modify at least one byte in the server s nonce in the Server Hello handshake message, and verify that the client rejects the Server Key Exchange handshake message (if using a DHE or ECDHE ciphersuite) or that the server denies the client s Finished handshake message. See the test results in AAR Section

10 The evaluator shall perform the following modifications to the traffic: Test 5.3: Modify the server s selected ciphersuite in the Server Hello handshake message to be a ciphersuite not presented in the Client Hello handshake message. The evaluator shall verify that the client rejects the connection after receiving the Server Hello. See the test results in AAR Section The evaluator shall perform the following modifications to the traffic: Test 5.4: Modify the signature block in the Server s Key Exchange handshake message, and verify that the client rejects the connection after receiving the Server Key Exchange message. See the test results in AAR Section The evaluator shall perform the following modifications to the traffic: Test 5.5: Modify a byte in the Server Finished handshake message, and verify that the client sends a fatal alert upon receipt and does not send any application data. See the test results in AAR Section The evaluator shall perform the following modifications to the traffic: Test 5.6: Send an garbled message from the Server after the Server has issued the ChangeCipherSpec message and verify that the client denies the connection. See the test results in AAR Section FCS_TLSC_EXT.1.2(1) Android 4.3 This requirement depends upon selection in FTP_DIT_EXT TSS Assurance Activities The evaluator shall ensure that the TSS describes the client s method of establishing all reference identifiers from the application-configured reference identifier, including which types of reference identifiers are supported (e.g. Common Name, DNS Name, URI Name, Service Name, or other application-specific Subject Alternative Names) and whether IP addresses and wildcards are supported. The evaluator shall ensure that this description identifies whether and the manner in which certificate pinning is supported or used by the TOE. [ST] Section FCS_TLSC_EXT.1 states that the ACE Client uses the Android platform verifier to establish reference identifiers. The platform verifier validates the first CN and the subject alternative 9

11 names against the host name. It supports wildcards and IP addresses. Pinning is not supported in the client Guidance Assurance Activities The evaluator shall verify that the AGD guidance includes instructions for setting the reference identifier to be used for the purposes of certificate validation in TLS. [ACE_CC] Section 7 Reference Identifier for TLS, states that as part of setting up a new account on the ACE Client, the user enters the hostname of the authentication server. The hostname is communicated to the user or administrator when setting up the user s account on the mobile device. See the Creating a Client Account section in the Hypori ACE Client Install Guide for Android Devices, version 3.1 Enterprise Distribution for detailed instructions Test Assurance Activities The evaluator shall configure the reference identifier according to the AGD guidance and perform the following tests during a TLS connection: Test 1: The evaluator shall present a server certificate that does not contain an identifier in either the Subject Alternative Name (SAN) or Common Name (CN) that matches the reference identifier. The evaluator shall verify that the connection fails. See the test results in AAR Section Test 2: The evaluator shall present a server certificate that contains a CN that matches the reference identifier, contains the SAN extension, but does not contain an identifier in the SAN that matches the reference identifier. The evaluator shall verify that the connection fails. The evaluator shall repeat this test for each supported SAN type. See the test results in AAR Section Test 3: The evaluator shall present a server certificate that contains a CN that matches the reference identifier and does not contain the SAN extension. The evaluator shall verify that the connection succeeds. See the test results in AAR Section Test 4: The evaluator shall present a server certificate that contains a CN that does not match the reference identifier but does contain an identifier in the SAN that matches. The evaluator shall verify that the connection succeeds. See the test results in AAR Section The evaluator shall perform the following wildcard tests with each supported type of reference 10

12 identifier: Test 5.1: The evaluator shall present a server certificate containing a wildcard that is not in the leftmost label of the presented identifier (e.g. foo.*.example.com) and verify that the connection fails. See the test results in AAR Section The evaluator shall perform the following wildcard tests with each supported type of reference identifier: Test 5.2: The evaluator shall present a server certificate containing a wildcard in the leftmost label but not preceding the public suffix (e.g. *.example.com). The evaluator shall configure the reference identifier with a single leftmost label (e.g. foo.example.com) and verify that the connection succeeds. The evaluator shall configure the reference identifier without a leftmost label as in the certificate (e.g. example.com) and verify that the connection fails. The evaluator shall configure the reference identifier with two leftmost labels (e.g. bar.foo.example.com) and verify that the connection fails. See the test results in AAR Section The evaluator shall perform the following wildcard tests with each supported type of reference identifier: Test 5.3: The evaluator shall present a server certificate containing a wildcard in the leftmost label immediately preceding the public suffix (e.g. *.com). The evaluator shall configure the reference identifier with a single leftmost label (e.g. foo.com) and verify that the connection fails. The evaluator shall configure the reference identifier with two leftmost labels (e.g. bar.foo.com) and verify that the connection fails. See the test results in AAR Section Test 6: [conditional] If URI or Service name reference identifiers are supported, the evaluator shall configure the DNS name and the service identifier. The evaluator shall present a server certificate containing the correct DNS name and service identifier in the URIName or SRVName fields of the SAN and verify that the connection succeeds. The evaluator shall repeat this test with the wrong service identifier (but correct DNS name) and verify that the connection fails. See the test results in AAR Section Test 7: [conditional] If pinned certificates are supported the evaluator shall present a certificate that does not match the pinned certificate and verify that the connection fails. The test is not applicable. The TOE does not support pinned certificates FCS_TLSC_EXT.1.3(1) Android 4.3 This requirement depends upon selection in FTP_DIT_EXT

13 TSS Assurance Activities Guidance Assurance Activities Test Assurance Activities The evaluator shall use TLS as a function to verify that the validation rules in FIA_X509_EXT.1.1 are adhered to and shall perform the following additional test: Test 1: The evaluator shall demonstrate that a peer using a certificate without a valid certification path results in an authenticate failure. Using the administrative guidance, the evaluator shall then load the trusted CA certificate(s) needed to validate the peer's certificate, and demonstrate that the connection succeeds. The evaluator then shall delete one of the CA certificates, and show that the connection fails. See the test results in AAR Section FCS_TLSC_EXT.1.4(1) Android TSS Assurance Activities The evaluator shall ensure that the TSS description required per FIA_X509_EXT.2.1 includes the use of clientside certificates for TLS mutual authentication. [ST] Section FIA_X509_EXT.2 ACE Client presents TLS client certificate and key to the ACE Server to authenticate a TLS connection. During account setup, the user identifies which certificate to present for each account. The user selects a certificate from the Android certificate store. The user can change the selection from Client Certificate under Connection on the Settings page. The TLS client certificate is an X509 certificate Guidance Assurance Activities The evaluator shall verify that the AGD guidance required per FIA_X509_EXT.2.1 includes instructions for configuring the client side certificates for TLS mutual authentication. [ACE_CC] Section 6 Provisioning of ACE Client Credentials, provides the instructions to install associated certificate. [UG_ANDROID] Chapter 3: ACE Client Installation Overview, Section: Installing Certificates on Android Devices includes the guidance to install the client side certificates for TLS mutual authentication Test Assurance Activities The evaluator shall also perform the following test: Test 1: The evaluator shall perform the following modification to the traffic: 12

14 Configure the server to require mutual authentication and then modify a byte in a CA field in the Server s Certificate Request handshake message. The modified CA field must not be the CA used to sign the client s certificate. The evaluator shall verify the connection is unsuccessful. See the test results in AAR Section FCS_TLSC_EXT.1.5(1) Android 4.3 This requirement depends upon selection in FCS_TLSC_EXT TSS Assurance Activities The evaluator shall verify that TSS describes the supported Elliptic Curves Extension and whether the required behavior is performed by default or may be configured. [ST] Section FCS_TLSC_EXT.1 states that the Android platform supports NIST curves secp256r1 and secp384r1 and supported Elliptic Curves Extension for TLS. No configuration is required by an ACE Client user Guidance Assurance Activities If the TSS indicates that the supported Elliptic Curves Extension must be configured to meet the requirement, the evaluator shall verify that AGD guidance includes configuration of the supported Elliptic Curves Extension. No configuration is required for Supported Elliptic Curves Extension Test Assurance Activities The evaluator shall also perform the following tests: Test 1: The evaluator shall configure the server to perform an ECDHE key exchange message in the TLS connection using a nonsupported ECDHE curve (for example, P192) and shall verify that the TOE disconnects after receiving the server's Key Exchange handshake message. See the test results in AAR Section FCS_TLSC_EXT.1(2) TLS Client Protocol Android FCS_TLSC_EXT.1.1(2) Android 4.4 This requirement depends upon selection in FTP_DIT_EXT TSS Assurance Activities The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that the ciphersuites supported are specified. The evaluator shall check the TSS to ensure that the ciphersuites specified include those listed for this component. [ST] Section FCS_TLSC_EXT.1 identifies the ciphersuites that the ACE Client supports. Ciphersuites are unique to each of the Android operating system versions and the SFR is iterated for 13

15 each Android version. The ciphersuites listed in in the TSS are those that are listed in the SFR component Guidance Assurance Activities The evaluator shall also check the operational guidance to ensure that it contains instructions on configuring the TOE so that TLS conforms to the description in the TSS. [ACE_CC] Section 3 Guidance Documentation states that Hypori s general ACE Client applies in the evaluated configuration along with this Common Criteria specific guidance. The general guidance covers Android 4.3, 4.4, 5.0, and 5.1, and there is no version-specific configuration. Cipher suites are determined by choice of Android version not ACE Client configuration. [ACE_CC] Section 6 Provisioning of ACE Client Credentials states that to configure an ACE client account, the user must provide a hostname and port for the ACE server, a name for the account, an optional password (to access the server), and a client certificate/credential. The 3.1 version of the ACE client does not create nor install credentials into the Android KeyChain. It is expected that some other out-of-band process is used to create and install the keys into the KeyChain. Once installed, the ACE Client s account can be created using the Add Account option to associate the account with a credential. Guidance is provided in the different ways used create and install credentials into the Android KeyChain. One of the methods directs the user to a self-provisioning portal using Microsoft certificate services or equivalent, and downloads the credentials to the device and loads them into the Android KeyChain (an example of this is described in the Creating the Client Certificate online help topic in the ACE User Guide for Android Devices Version 3.1 product documentation. The instructions on configuring the TOE conform to the TLS description in the TSS Test Assurance Activities The evaluator shall also perform the following tests: Test 1: The evaluator shall establish a TLS connection using each of the ciphersuites specified by the requirement. This connection may be established as part of the establishment of a higherlevel protocol, e.g., as part of an EAP session. It is sufficient to observe the successful negotiation of a ciphersuite to satisfy the intent of the test; it is not necessary to examine the characteristics of the encrypted traffic in an attempt to discern the ciphersuite being used (for example, that the cryptographic algorithm is 128bit AES and not 256bit AES). The evaluator established a TLS connection with each of the following ciphersuites: TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA A packet capture using Wireshark verified that each TLS connection was successfully established. 14

16 Test 2: The evaluator shall attempt to establish the connection using a server with a server certificate that contains the Server Authentication purpose in the extendedkeyusage field and verify that a connection is established. The evaluator will then verify that the client rejects an otherwise valid server certificate that lacks the Server Authentication purpose in the extendedkeyusage field and a connection is not established. Ideally, the two certificates should be identical except for the extendedkeyusage field. The evaluator configured the server to present a server certificate without the Server Authentication purpose in the extendedkeyusage field. A Wireshark capture was started and attempted to connect to the server through the ACE Client application. The evaluator reviewed the packet capture and verified that the TLS connection was dropped after the device received the server certificate. Test 3: The evaluator shall send a server certificate in the TLS connection that does not match the serverselected ciphersuite (for example, send a ECDSA certificate while using the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite or send a RSA certificate while using one of the ECDSA ciphersuites.) The evaluator shall verify that the TOE disconnects after receiving the server s Certificate handshake message. The evaluator configured the server to present an ECDSA certificate after selecting TLS_RSA_WITH_AES_128_CBC_SHA. A Wireshark capture was started and attempted to connect to the server through the ACE Client application. The evaluator reviewed the packet capture and verified that the TLS connection was dropped after the device received the mismatched server certificate. Test 4: The evaluator shall configure the server to select the TLS_NULL_WITH_NULL_NULL ciphersuite and verify that the client denies the connection. The evaluator configured the server to modify the server hello to select the TLS_NULL_WITH_NULL_NULL ciphersuite. A Wireshark capture was started and attempted to connect to the server through the ACE Client application. The evaluator reviewed the packet capture and verified that the TLS connection was dropped after the device received the invalid ciphersuite attempt. The evaluator shall perform the following modifications to the traffic: Test 5.1: Change the TLS version selected by the server in the Server Hello to a non-supported TLS version (for example 1.3 represented by the two bytes 03 04) and verify that the client rejects the connection. The evaluator configured the server and modified the server hello to non-supported TLS version to (TLS 1.3). The evaluator ran a Wireshark capture and attempted to connect to the server through the ACE Client application. The evaluator reviewed the packet capture and verified that the TLS connection was dropped after the device received the invalid TLS version attempt for each of the Android versions. 15

17 The evaluator shall perform the following modifications to the traffic: Test 5.2: Modify at least one byte in the server s nonce in the Server Hello handshake message, and verify that the client rejects the Server Key Exchange handshake message (if using a DHE or ECDHE ciphersuite) or that the server denies the client s Finished handshake message. The evaluator modified the server nonce in the Server Hello Handhsake message and verified the client rejected the Server Key Exchange handshake message and dropped the TLS connection. The evaluator performed a network capture and verified that the TLS connection was dropped after the device received the modified Server Hello. The evaluator shall perform the following modifications to the traffic: Test 5.3: Modify the server s selected ciphersuite in the Server Hello handshake message to be a ciphersuite not presented in the Client Hello handshake message. The evaluator shall verify that the client rejects the connection after receiving the Server Hello. The TLS connection failed when the server selected a ciphersuite not provided in the client hello. The evaluator captured the network packets and verified that the TLS connection was dropped after the device received the invalid ciphersuite. The evaluator shall perform the following modifications to the traffic: Test 5.4: Modify the signature block in the Server s Key Exchange handshake message, and verify that the client rejects the connection after receiving the Server Key Exchange message. The Client TLS connection failed when receiving a modified signature block in the Server s Key Exchange handshake message. The evaluator conducted a packet capture and verified that the TLS connection was dropped after the device received the modified Server s Key Exchange handshake message. The evaluator shall perform the following modifications to the traffic: Test 5.5: Modify a byte in the Server Finished handshake message, and verify that the client sends a fatal alert upon receipt and does not send any application data. The TLS connection failed after receiving a modified Server Finished handshake message. A network capture was performed and the evaluator verified that an alert was sent and the TLS connection attempt ended after the device received the modified Server Finished handshake message. The evaluator shall perform the following modifications to the traffic: Test 5.6: Send an garbled message from the Server after the Server has issued the ChangeCipherSpec message and verify that the client denies the connection. The TLS connection failed after receiving a garbled message from the Server after the Server has issued 16

18 the ChangeCipherSpec message. The evaluator ran a Wireshark capture and attempted to connect to the server through the ACE Client application. The packet capture was reviewed and it verified that an alert was sent and the TLS connection attempt was denied after the device received the garbled message FCS_TLSC_EXT.1.2(2) Android 4.4 This requirement depends upon selection in FTP_DIT_EXT TSS Assurance Activities The evaluator shall ensure that the TSS describes the client s method of establishing all reference identifiers from the application-configured reference identifier, including which types of reference identifiers are supported (e.g. Common Name, DNS Name, URI Name, Service Name, or other application-specific Subject Alternative Names) and whether IP addresses and wildcards are supported. The evaluator shall ensure that this description identifies whether and the manner in which certificate pinning is supported or used by the TOE. [ST] Section FCS_TLSC_EXT.1 states that the ACE Client uses the Android platform verifier to establish reference identifiers. The platform verifier validates the first CN and the subject alternative names against the host name. It supports wildcards and IP addresses. Pinning is not supported in the client Guidance Assurance Activities The evaluator shall verify that the AGD guidance includes instructions for setting the reference identifier to be used for the purposes of certificate validation in TLS. [ACE_CC] Section 7 Reference Identifier for TLS, states that as part of setting up a new account on the ACE Client, the user enters the hostname of the authentication server. The hostname is communicated to the user or administrator when setting up the user s account on the mobile device. See the Creating a Client Account section in the Hypori ACE Client Install Guide for Android Devices, version 3.1 Enterprise Distribution for detailed instructions Test Assurance Activities The evaluator shall configure the reference identifier according to the AGD guidance and perform the following tests during a TLS connection: Test 1: The evaluator shall present a server certificate that does not contain an identifier in either the Subject Alternative Name (SAN) or Common Name (CN) that matches the reference identifier. The evaluator shall verify that the connection fails. The server was configured to use a server certificate that did not contain the configured hostname in either the Subject Alternative Name (SAN) or Common Name (CN). A TLS connection was attempted and rejected. The evaluator verified the connection was terminated by the application by examining a packet capture and the displayed error message on the device. 17

19 Test 2: The evaluator shall present a server certificate that contains a CN that matches the reference identifier, contains the SAN extension, but does not contain an identifier in the SAN that matches the reference identifier. The evaluator shall verify that the connection fails. The evaluator shall repeat this test for each supported SAN type. The evaluator configured the server to use a server certificate that contained a CN that matches the reference identifier, contained the SAN extension, but did not contain an identifier in the SAN that matches the reference identifier. A Wireshark capture was started and attempted to connect to the server through the ACE Client application using the configured host name. In this test the configured hostname is tlstest.ccmdpp.com. The connection was rejected. A network capture verified that the connection was terminated by the application by examining the packet capture and seeing that a FIN message was sent to kill the connection. Test 3: The evaluator shall present a server certificate that contains a CN that matches the reference identifier and does not contain the SAN extension. The evaluator shall verify that the connection succeeds. The TLS connection succeeded after presenting a server certificate that contained a CN that matches the reference identifier and did not contain the SAN extension. A network capture verified that the TLS connection was successful. Test 4: The evaluator shall present a server certificate that contains a CN that does not match the reference identifier but does contain an identifier in the SAN that matches. The evaluator shall verify that the connection succeeds. The TLS connection succeeded after receiving a server certificate that contained a CN that does not match the reference identifier but does contain an identifier in the SAN that matches. A Wireshark capture and attempted to connect to the server through the ACE Client application using the configured host name. In this test the configured hostname is tlstest.ccmdpp.com. A network capture verified that the TLS connection was successful. The evaluator shall perform the following wildcard tests with each supported type of reference identifier: Test 5.1: The evaluator shall present a server certificate containing a wildcard that is not in the leftmost label of the presented identifier (e.g. foo.*.example.com) and verify that the connection fails. The evaluator configured the server to use a server certificate that contains a wildcard that is not in the leftmost label of the CN. A Wireshark capture and attempted to connect to the server through the ACE Client application using the configured host name. In this test the configured hostname is tlstest.ccmdpp.com. The Wireshark capture verified that the connection failed. An authentication error was displayed on the device. 18

20 The evaluator shall perform the following wildcard tests with each supported type of reference identifier: Test 5.2: The evaluator shall present a server certificate containing a wildcard in the leftmost label but not preceding the public suffix (e.g. *.example.com). The evaluator shall configure the reference identifier with a single leftmost label (e.g. foo.example.com) and verify that the connection succeeds. The evaluator shall configure the reference identifier without a leftmost label as in the certificate (e.g. example.com) and verify that the connection fails. The evaluator shall configure the reference identifier with two leftmost labels (e.g. bar.foo.example.com) and verify that the connection fails. The server was configured to use a server certificate that contains a wildcard in the leftmost label of the CN. The evaluator ran a Wireshark capture and attempted to connect to the server through the ACE Client application using the configured host name of tlstest.ccmdpp.com. The evaluator reviewed the packet capture and verified that the connection was successful. The evaluator then ran a Wireshark capture and attempted to connect to the server through the ACE Client application using the configured host name of ccmdpp.com. The connection failed and the device displayed an Authentication Error message. The evaluator ran a Wireshark capture and attempted to connect to the server through the ACE Client application using the configured host name of foo.tlstest.ccmdpp.com. The evaluator viewed that the error message was displayed after the CN could not be matched and verified by the packet capture that the connection was terminated. The evaluator shall perform the following wildcard tests with each supported type of reference identifier: Test 5.3: The evaluator shall present a server certificate containing a wildcard in the leftmost label immediately preceding the public suffix (e.g. *.com). The evaluator shall configure the reference identifier with a single leftmost label (e.g. foo.com) and verify that the connection fails. The evaluator shall configure the reference identifier with two leftmost labels (e.g. bar.foo.com) and verify that the connection fails. The server was configured to use a server certificate that contains a wildcard in the leftmost label of the CN, immediately preceding the public suffix. The evaluator ran a Wireshark capture and attempted to connect to the server through the ACE Client application using the configured host name of ccmdpp.com. The evaluator viewed that the error message was displayed after the CN could not be matched and verified by the packet capture that the connection was terminated. The evaluator ran a Wireshark capture and attempted to connect to the server through the ACE Client application using the configured host name of foo.tlstest.ccmdpp.com. The evaluator viewed that the error message was displayed after the use of the invalid wildcard and verified by the packet capture that the connection was terminated. Test 6: [conditional] If URI or Service name reference identifiers are supported, the evaluator shall configure the DNS name and the service identifier. The evaluator shall present a server certificate containing the correct DNS name and service identifier in the URIName or SRVName fields of the SAN and verify that the connection succeeds. The evaluator shall repeat this test with the wrong 19

21 service identifier (but correct DNS name) and verify that the connection fails. The test is not applicable. ACE Client establishes the reference identifier using the configured server host name. ACE Client validates the first CN and the subject alternative names against the configured reference identifier. It supports wildcards and IP addresses. Test 7: [conditional] If pinned certificates are supported the evaluator shall present a certificate that does not match the pinned certificate and verify that the connection fails. The test is not applicable. The TOE does not support pinned certificates FCS_TLSC_EXT.1.3(2) Android 4.4 This requirement depends upon selection in FTP_DIT_EXT TSS Assurance Activities Guidance Assurance Activities Test Assurance Activities The evaluator shall use TLS as a function to verify that the validation rules in FIA_X509_EXT.1.1 are adhered to and shall perform the following additional test: Test 1: The evaluator shall demonstrate that a peer using a certificate without a valid certification path results in an authenticate failure. Using the administrative guidance, the evaluator shall then load the trusted CA certificate(s) needed to validate the peer's certificate, and demonstrate that the connection succeeds. The evaluator then shall delete one of the CA certificates, and show that the connection fails. The evaluator ran a Wireshark capture and attempted to connect to the server through the ACE Client application while the CA was not installed on the device. The evaluator further verified the connection was terminated by the application by examining the packet capture and seeing that handshake attempt ended after receiving the server certificate. The device displayed an error message stating that the cert path could not be validated. The evaluator installed the CA certificate on the Android device and ran a Wireshark capture and attempted to connect to the server through the ACE Client application. The evaluator reviewed the packet capture and verified that the TLS connection was successful FCS_TLSC_EXT.1.4(2) Android TSS Assurance Activities 20

22 The evaluator shall ensure that the TSS description required per FIA_X509_EXT.2.1 includes the use of clientside certificates for TLS mutual authentication. [ST] Section FIA_X509_EXT.2 ACE Client presents TLS client certificate and key to the ACE Server to authenticate a TLS connection. During account setup, the user identifies which certificate to present for each account. The user selects a certificate from the Android certificate store. The user can change the selection from Client Certificate under Connection on the Settings page. The TLS client certificate is an X509 certificate Guidance Assurance Activities The evaluator shall verify that the AGD guidance required per FIA_X509_EXT.2.1 includes instructions for configuring the client side certificates for TLS mutual authentication. [ACE_CC] Section 6 Provisioning of ACE Client Credentials, provides the instructions to install associated certificate. [UG_ANDROID] Chapter 3: ACE Client Installation Overview, Section: Installing Certificates on Android Devices includes the guidance to install the client side certificates for TLS mutual authentication Test Assurance Activities The evaluator shall also perform the following test: Test 1: The evaluator shall perform the following modification to the traffic: Configure the server to require mutual authentication and then modify a byte in a CA field in the Server s Certificate Request handshake message. The modified CA field must not be the CA used to sign the client s certificate. The evaluator shall verify the connection is unsuccessful. The evaluator configured the server to require mutual authentication and then modified a byte in a CA field in the Server s Certificate Request handshake message. A Wireshark capture was started and attempted to connect to the server through the ACE Client application. The evaluator reviewed the packet capture and verified that the connection was not successful. The client terminated the TLS handshake after receiving the modified Certificate Request message FCS_TLSC_EXT.1.5(2) Android 4.4 This requirement depends upon selection in FCS_TLSC_EXT TSS Assurance Activities The evaluator shall verify that TSS describes the supported Elliptic Curves Extension and whether the required behavior is performed by default or may be configured. [ST] Section FCS_TLSC_EXT.1 states that the Android platform supports NIST curves secp256r1 and secp384r1 and supported Elliptic Curves Extension for TLS. No configuration is required by an ACE Client user Guidance Assurance Activities 21

23 If the TSS indicates that the supported Elliptic Curves Extension must be configured to meet the requirement, the evaluator shall verify that AGD guidance includes configuration of the supported Elliptic Curves Extension. No configuration is required for Supported Elliptic Curves Extension Test Assurance Activities The evaluator shall also perform the following tests: Test 1: The evaluator shall configure the server to perform an ECDHE key exchange message in the TLS connection using a nonsupported ECDHE curve (for example, P192) and shall verify that the TOE disconnects after receiving the server's Key Exchange handshake message. The evaluator configured the server to use a server certificate with the P192 ECDHE curve. A Wireshark capture was started and attempted to connect to the server through the ACE Client application. The evaluator reviewed the packet capture and viewed that the server terminated the connection because the P192 ECDHE curve was not supported by the client FCS_TLSC_EXT.1 TLS(3) Client Protocol Android 5.0, FCS_TLSC_EXT.1.1(3) Android 5.0, 5.1 This requirement depends upon selection in FTP_DIT_EXT TSS Assurance Activities The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that the ciphersuites supported are specified. The evaluator shall check the TSS to ensure that the ciphersuites specified include those listed for this component. [ST] Section FCS_TLSC_EXT.1 identifies the ciphersuites that the ACE Client supports. Ciphersuites are unique to each of the Android operating system versions and the SFR is iterated for each Android version. The ciphersuites listed in in the TSS are those that are listed in the SFR component Guidance Assurance Activities The evaluator shall also check the operational guidance to ensure that it contains instructions on configuring the TOE so that TLS conforms to the description in the TSS. [ACE_CC] Section 3 Guidance Documentation states that Hypori s general ACE Client applies in the evaluated configuration along with this Common Criteria specific guidance. The general guidance covers Android 4.3, 4.4, 5.0, and 5.1, and there is no version-specific configuration. Cipher suites are determined by choice of Android version not ACE Client configuration. [ACE_CC] Section 6 Provisioning of ACE Client Credentials states that to configure an ACE client account, the user must provide a hostname and port for the ACE server, a name for the account, an optional password (to access the server), and a client certificate/credential. 22

24 The 3.1 version of the ACE client does not create nor install credentials into the Android KeyChain. It is expected that some other out-of-band process is used to create and install the keys into the KeyChain. Once installed, the ACE Client s account can be created using the Add Account option to associate the account with a credential. Guidance is provided in the different ways used create and install credentials into the Android KeyChain. One of the methods directs the user to a self-provisioning portal using Microsoft certificate services or equivalent, and downloads the credentials to the device and loads them into the Android KeyChain (an example of this is described in the Creating the Client Certificate online help topic in the ACE User Guide for Android Devices Version 3.1 product documentation. The instructions on configuring the TOE conform to the TLS description in the TSS Test Assurance Activities The evaluator shall also perform the following tests: Test 1: The evaluator shall establish a TLS connection using each of the ciphersuites specified by the requirement. This connection may be established as part of the establishment of a higherlevel protocol, e.g., as part of an EAP session. It is sufficient to observe the successful negotiation of a ciphersuite to satisfy the intent of the test; it is not necessary to examine the characteristics of the encrypted traffic in an attempt to discern the ciphersuite being used (for example, that the cryptographic algorithm is 128bit AES and not 256bit AES). The evaluator established a TLS connection with each of the following ciphersuites: TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA256 A packet capture using Wireshark verified that each TLS connection was successfully established. Test 2: The evaluator shall attempt to establish the connection using a server with a server certificate 23

25 that contains the Server Authentication purpose in the extendedkeyusage field and verify that a connection is established. The evaluator will then verify that the client rejects an otherwise valid server certificate that lacks the Server Authentication purpose in the extendedkeyusage field and a connection is not established. Ideally, the two certificates should be identical except for the extendedkeyusage field. The evaluator configured the server to present a server certificate without the Server Authentication purpose in the extendedkeyusage field. A Wireshark capture was started and attempted to connect to the server through the ACE Client application. The evaluator reviewed the packet capture and verified that the TLS connection was dropped after the device received the server certificate. The TLS connection is denied by the device when presented a server certificate without the Server Authentication purpose in the extendedkeyusage field for each of the tested Android versions. Test 3: The evaluator shall send a server certificate in the TLS connection that does not match the serverselected ciphersuite (for example, send a ECDSA certificate while using the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite or send a RSA certificate while using one of the ECDSA ciphersuites.) The evaluator shall verify that the TOE disconnects after receiving the server s Certificate handshake message. The evaluator configured the server to present an ECDSA certificate after selecting TLS_RSA_WITH_AES_128_CBC_SHA. A Wireshark capture was started and attempted to connect to the server through the ACE Client application. The evaluator reviewed the packet capture and verified that the TLS connection was dropped after the device received the mismatched server certificate. The TLS connection failed when the server certificate does not match the ciphersuite selected by the server for each of the Android versions. Test 4: The evaluator shall configure the server to select the TLS_NULL_WITH_NULL_NULL ciphersuite and verify that the client denies the connection. The evaluator configured the server to modify the server hello to select the TLS_NULL_WITH_NULL_NULL ciphersuite. A Wireshark capture was started and attempted to connect to the server through the ACE Client application. The evaluator reviewed the packet capture and verified that the TLS connection was dropped after the device received the invalid ciphersuite attempt. The evaluator shall perform the following modifications to the traffic: Test 5.1: Change the TLS version selected by the server in the Server Hello to a non-supported TLS version (for example 1.3 represented by the two bytes 03 04) and verify that the client rejects the connection. The evaluator configured the server and modified the server hello to non-supported TLS version to (TLS 1.3). The evaluator ran a Wireshark capture and attempted to connect to the server through the ACE Client application. The evaluator reviewed the packet capture and verified that the TLS 24

26 connection was dropped after the device received the invalid TLS version attempt for each of the Android versions. The evaluator shall perform the following modifications to the traffic: Test 5.2: Modify at least one byte in the server s nonce in the Server Hello handshake message, and verify that the client rejects the Server Key Exchange handshake message (if using a DHE or ECDHE ciphersuite) or that the server denies the client s Finished handshake message. The evaluator modified the server nonce in the Server Hello Handshake message and verified the client rejected the Server Key Exchange handshake message and dropped the TLS connection. The evaluator performed a network capture and verified that the TLS connection was dropped after the device received the modified Server Hello. The evaluator shall perform the following modifications to the traffic: Test 5.3: Modify the server s selected ciphersuite in the Server Hello handshake message to be a ciphersuite not presented in the Client Hello handshake message. The evaluator shall verify that the client rejects the connection after receiving the Server Hello. The TLS connection failed when the server selected a ciphersuite not provided in the client hello. The evaluator captured the network packets and verified that the TLS connection was dropped after the device received the invalid ciphersuite. The evaluator shall perform the following modifications to the traffic: Test 5.4: Modify the signature block in the Server s Key Exchange handshake message, and verify that the client rejects the connection after receiving the Server Key Exchange message. The Client TLS connection failed when receiving a modified signature block in the Server s Key Exchange handshake message. The evaluator conducted a packet capture and verified that the TLS connection was dropped after the device received the modified Server s Key Exchange handshake message. The evaluator shall perform the following modifications to the traffic: Test 5.5: Modify a byte in the Server Finished handshake message, and verify that the client sends a fatal alert upon receipt and does not send any application data. The TLS connection failed after receiving a modified Server Finished handshake message. A network capture was performed and the evaluator verified that an alert was sent and the TLS connection attempt ended after the device received the modified Server Finished handshake message. The evaluator shall perform the following modifications to the traffic: Test 5.6: Send an garbled message from the Server after the Server has issued the ChangeCipherSpec message and verify that the client denies the connection. 25

27 The TLS connection failed after receiving a garbled message from the Server after the Server has issued the ChangeCipherSpec message. The evaluator ran a Wireshark capture and attempted to connect to the server through the ACE Client application. The packet capture was reviewed and it verified that an alert was sent and the TLS connection attempt was denied after the device received the garbled message FCS_TLSC_EXT.1.2 Android(3) 5.0, 5.1 This requirement depends upon selection in FTP_DIT_EXT TSS Assurance Activities The evaluator shall ensure that the TSS describes the client s method of establishing all reference identifiers from the application-configured reference identifier, including which types of reference identifiers are supported (e.g. Common Name, DNS Name, URI Name, Service Name, or other application-specific Subject Alternative Names) and whether IP addresses and wildcards are supported. The evaluator shall ensure that this description identifies whether and the manner in which certificate pinning is supported or used by the TOE. [ST] Section FCS_TLSC_EXT.1 states that the ACE Client uses the Android platform verifier to establish reference identifiers. The platform verifier validates the first CN and the subject alternative names against the host name. It supports wildcards and IP addresses. Pinning is not supported in the client Guidance Assurance Activities The evaluator shall verify that the AGD guidance includes instructions for setting the reference identifier to be used for the purposes of certificate validation in TLS. [ACE_CC] Section 7 Reference Identifier for TLS, states that as part of setting up a new account on the ACE Client, the user enters the hostname of the authentication server. The hostname is communicated to the user or administrator when setting up the user s account on the mobile device. See the Creating a Client Account section in the Hypori ACE Client Install Guide for Android Devices, version 3.1 Enterprise Distribution for detailed instructions Test Assurance Activities The evaluator shall configure the reference identifier according to the AGD guidance and perform the following tests during a TLS connection: Test 1: The evaluator shall present a server certificate that does not contain an identifier in either the Subject Alternative Name (SAN) or Common Name (CN) that matches the reference identifier. The evaluator shall verify that the connection fails. The server was configured to use a server certificate that did not contain the configured hostname in either the Subject Alternative Name (SAN) or Common Name (CN). A TLS connection was attempted and rejected. The evaluator verified the connection was terminated by the application by examining a packet capture and the displayed error message on the device. 26

28 Test 2: The evaluator shall present a server certificate that contains a CN that matches the reference identifier, contains the SAN extension, but does not contain an identifier in the SAN that matches the reference identifier. The evaluator shall verify that the connection fails. The evaluator shall repeat this test for each supported SAN type. The evaluator configured the server to use a server certificate that contained a CN that matches the reference identifier, contained the SAN extension, but did not contain an identifier in the SAN that matches the reference identifier. A Wireshark capture was started and attempted to connect to the server through the ACE Client application using the configured host name. In this test the configured hostname is tlstest.ccmdpp.com. The connection was rejected. A network capture verified that the connection was terminated by the application by examining the packet capture and seeing that a FIN message was sent to kill the connection. Test 3: The evaluator shall present a server certificate that contains a CN that matches the reference identifier and does not contain the SAN extension. The evaluator shall verify that the connection succeeds. The TLS connection succeeded after presenting a server certificate that contained a CN that matches the reference identifier and did not contain the SAN extension. A network capture verified that the TLS connection was successful. Test 4: The evaluator shall present a server certificate that contains a CN that does not match the reference identifier but does contain an identifier in the SAN that matches. The evaluator shall verify that the connection succeeds. The TLS connection succeeded after receiving a server certificate that contained a CN that does not match the reference identifier but does contain an identifier in the SAN that matches. A Wireshark capture and attempted to connect to the server through the ACE Client application using the configured host name. In this test the configured hostname is tlstest.ccmdpp.com. A network capture verified that the TLS connection was successful. The evaluator shall perform the following wildcard tests with each supported type of reference identifier: Test 5.1: The evaluator shall present a server certificate containing a wildcard that is not in the leftmost label of the presented identifier (e.g. foo.*.example.com) and verify that the connection fails. The evaluator configured the server to use a server certificate that contains a wildcard that is not in the leftmost label of the CN. A Wireshark capture and attempted to connect to the server through the ACE Client application using the configured host name. In this test the configured hostname is tlstest.ccmdpp.com. The Wireshark capture verified that the connection failed. An authentication error was displayed on the device. 27

29 The evaluator shall perform the following wildcard tests with each supported type of reference identifier: Test 5.2: The evaluator shall present a server certificate containing a wildcard in the leftmost label but not preceding the public suffix (e.g. *.example.com). The evaluator shall configure the reference identifier with a single leftmost label (e.g. foo.example.com) and verify that the connection succeeds. The evaluator shall configure the reference identifier without a leftmost label as in the certificate (e.g. example.com) and verify that the connection fails. The evaluator shall configure the reference identifier with two leftmost labels (e.g. bar.foo.example.com) and verify that the connection fails. The server was configured to use a server certificate that contains a wildcard in the leftmost label of the CN. The evaluator ran a Wireshark capture and attempted to connect to the server through the ACE Client application using the configured host name of tlstest.ccmdpp.com. The evaluator reviewed the packet capture and verified that the connection was successful. The evaluator then ran a Wireshark capture and attempted to connect to the server through the ACE Client application using the configured host name of ccmdpp.com. The connection failed and the device displayed an Authentication Error message. The evaluator ran a Wireshark capture and attempted to connect to the server through the ACE Client application using the configured host name of foo.tlstest.ccmdpp.com. The evaluator viewed that the error message was displayed after the CN could not be matched and verified by the packet capture that the connection was terminated. The evaluator shall perform the following wildcard tests with each supported type of reference identifier: Test 5.3: The evaluator shall present a server certificate containing a wildcard in the leftmost label immediately preceding the public suffix (e.g. *.com). The evaluator shall configure the reference identifier with a single leftmost label (e.g. foo.com) and verify that the connection fails. The evaluator shall configure the reference identifier with two leftmost labels (e.g. bar.foo.com) and verify that the connection fails. The server was configured to use a server certificate that contains a wildcard in the leftmost label of the CN, immediately preceding the public suffix. The evaluator ran a Wireshark capture and attempted to connect to the server through the ACE Client application using the configured host name of ccmdpp.com. The evaluator viewed that the error message was displayed after the CN could not be matched and verified by the packet capture that the connection was terminated. The evaluator ran a Wireshark capture and attempted to connect to the server through the ACE Client application using the configured host name of foo.tlstest.ccmdpp.com. The evaluator viewed that the error message was displayed after the use of the invalid wildcard and verified by the packet capture that the connection was terminated. Test 6: [conditional] If URI or Service name reference identifiers are supported, the evaluator shall configure the DNS name and the service identifier. The evaluator shall present a server certificate containing the correct DNS name and service identifier in the URIName or SRVName fields of the SAN and verify that the connection succeeds. The evaluator shall repeat this test with the wrong service identifier (but correct DNS name) and verify that the connection fails. 28

30 The test is not applicable. ACE Client establishes the reference identifier using the configured server host name. ACE Client validates the first CN and the subject alternative names against the configured reference identifier. It supports wildcards and IP addresses. Test 7: [conditional] If pinned certificates are supported the evaluator shall present a certificate that does not match the pinned certificate and verify that the connection fails. The test is not applicable. The TOE does not support pinned certificates FCS_TLSC_EXT.1.3(3) Android 5.0, 5.1 This requirement depends upon selection in FTP_DIT_EXT TSS Assurance Activities Guidance Assurance Activities Test Assurance Activities The evaluator shall use TLS as a function to verify that the validation rules in FIA_X509_EXT.1.1 are adhered to and shall perform the following additional test: Test 1: The evaluator shall demonstrate that a peer using a certificate without a valid certification path results in an authenticate failure. Using the administrative guidance, the evaluator shall then load the trusted CA certificate(s) needed to validate the peer's certificate, and demonstrate that the connection succeeds. The evaluator then shall delete one of the CA certificates, and show that the connection fails. The evaluator ran a Wireshark capture and attempted to connect to the server through the ACE Client application while the CA was not installed on the device. The evaluator further verified the connection was terminated by the application by examining the packet capture and seeing that handshake attempt ended after receiving the server certificate. The device displayed an error message stating that the cert path could not be validated. The evaluator installed the CA certificate on the Android device and ran a Wireshark capture and attempted to connect to the server through the ACE Client application. The evaluator reviewed the packet capture and verified that the TLS connection was successful FCS_TLSC_EXT.1.4(3) Android 5.0, TSS Assurance Activities The evaluator shall ensure that the TSS description required per FIA_X509_EXT.2.1 includes the use of clientside certificates for TLS mutual authentication. 29

31 [ST] Section FIA_X509_EXT.2 ACE Client presents TLS client certificate and key to the ACE Server to authenticate a TLS connection. During account setup, the user identifies which certificate to present for each account. The user selects a certificate from the Android certificate store. The user can change the selection from Client Certificate under Connection on the Settings page. The TLS client certificate is an X509 certificate Guidance Assurance Activities The evaluator shall verify that the AGD guidance required per FIA_X509_EXT.2.1 includes instructions for configuring the client side certificates for TLS mutual authentication. [ACE_CC] Section 6 Provisioning of ACE Client Credentials, provides the instructions to install associated certificate. [UG_ANDROID] Chapter 3: ACE Client Installation Overview, Section: Installing Certificates on Android Devices includes the guidance to install the client side certificates for TLS mutual authentication Test Assurance Activities The evaluator shall also perform the following test: Test 1: The evaluator shall perform the following modification to the traffic: Configure the server to require mutual authentication and then modify a byte in a CA field in the Server s Certificate Request handshake message. The modified CA field must not be the CA used to sign the client s certificate. The evaluator shall verify the connection is unsuccessful. The evaluator configured the server to require mutual authentication and then modified a byte in a CA field in the Server s Certificate Request handshake message. A Wireshark capture was started and attempted to connect to the server through the ACE Client application. The evaluator reviewed the packet capture and verified that the connection was not successful. The client terminated the TLS handshake after receiving the modified Certificate Request message FCS_TLSC_EXT.1.5(3) Android 5.0, 5.1 This requirement depends upon selection in FCS_TLSC_EXT TSS Assurance Activities The evaluator shall verify that TSS describes the supported Elliptic Curves Extension and whether the required behavior is performed by default or may be configured. [ST] Section FCS_TLSC_EXT.1 states that the Android platform supports NIST curves secp256r1 and secp384r1 and supported Elliptic Curves Extension for TLS. No configuration is required by an ACE Client user Guidance Assurance Activities If the TSS indicates that the supported Elliptic Curves Extension must be configured to meet the requirement, the evaluator shall verify that AGD guidance includes configuration of the supported Elliptic Curves Extension. No configuration is required for Supported Elliptic Curves Extension. 30

32 Test Assurance Activities The evaluator shall also perform the following tests: Test 1: The evaluator shall configure the server to perform an ECDHE key exchange message in the TLS connection using a nonsupported ECDHE curve (for example, P192) and shall verify that the TOE disconnects after receiving the server's Key Exchange handshake message. The evaluator configured the server to use a server certificate with the P192 ECDHE curve. A Wireshark capture was started and attempted to connect to the server through the ACE Client application. The evaluator reviewed the packet capture and viewed that the server terminated the connection because the P192 ECDHE curve was not supported by the client. 2.2 User Data Protection (FDP) FDP_DEC_EXT.1 Access to Platform Resources FDP_DEC_EXT TSS Assurance Activities Guidance Assurance Activities The evaluator shall install and run the application and inspect its user documentation to verify that the user is informed of any need to access hardware resources. The method of doing so varies per platform. [ACE_CC] Section 4 Permissions, identifies the permissions and the access to the hardware resources needed to install the application. The following permissions are requested during the ACE Client installation: Read phone status and identity Take pictures and videos (Camera) Record audio (Microphone) GPS and network-based location Find, use, add, and remove accounts and set passwords Access and change network state Access Wi-Fi connection state information Retrieve running apps Change audio settings Read and enable/disable sync settings Install/uninstall shortcuts Prevent phone from sleeping Display a system alert Receive boot completed Full network access View network connections Read external storage 31

33 Test Assurance Activity The evaluator shall install and run the application and inspect its user documentation to verify that the user is informed of any need to access hardware resources. The method of doing so varies per platform. For Android: The evaluator shall install the application and verify that the application displays the platform resources it would like to access. This includes permissions such as ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION, BLUETOOTH, CAMERA, INTERNET, NFC, READ_EXTERNAL_STORAGE, RECORD_AUDIO. A complete list of Android permissions can be found at: The evaluator attempted to install the ACE Client application through the Google Play Store and verified that the application requested permission to access platform resources before installing FDP_DEC_EXT TSS Assurance Activities Guidance Assurance Activities The evaluator shall ensure that the selection captures all sensitive information repositories which the application is intended to access. The evaluator shall install and run the application software and inspect its user documentation to verify that the user is informed of any need to access these repositories. The method of doing so varies per platform. The SFR states that the application shall provide user awareness of its intent to access accounts on device. [ACE_CC] Section 4 Permissions, identifies the permissions and the access to the hardware resources needed to install and run the application. Sub-Section 4.5 Add, remove accounts and set passwords, states that the ACE Client uses the Android Account Manager APIs to manage ACE accounts on the client device Test Assurance Activities The evaluator shall ensure that the selection captures all sensitive information repositories which the application is intended to access. The evaluator shall install and run the application software and inspect its user documentation to verify that the user is informed of any need to access these repositories. The method of doing so varies 32

34 per platform. For Android: The evaluator shall install the application and verify that the application displays the permissions used to access system-wide repositories. This includes permissions such as READ_CALENDAR, READ_CALL_LOG, READ_CONTACTS, READ_EXTERNAL_STORAGE, READ_LOGS. A complete list of Android permissions can be found at: The evaluator attempted to install the application and verified that the application displays the repositories it would like to access before installing FDP_DEC_EXT TSS Assurance Activities Guidance Assurance Activities The evaluator shall review documentation provided by the application developer and for each resource which it requests access to, identify the justification as to why access is required. [ACE_CC] Section 4 Permissions, identifies the permissions and the access to the hardware resources needed to install the application. The following permissions are requested during the ACE Client installation: Read phone status and identity Take pictures and videos (Camera) Record audio (Microphone) GPS and network-based location Find, use, add, and remove accounts and set passwords Access and change network state Access Wi-Fi connection state information Retrieve running apps Change audio settings Read and enable/disable sync settings Install/uninstall shortcuts Prevent phone from sleeping Display a system alert Receive boot completed Full network access View network connections Read external storage Justification is provided as to why access is required. 33

35 Test Assurance Activities FDP_DEC_EXT TSS Assurance Activities None defined Guidance Assurance Activities Test Assurance Activity The evaluator shall perform the following tests: Test 1: The evaluator shall run the application. While the application is running, the evaluator shall sniff network traffic ignoring all non-application associated traffic and verify that any network communications witnessed are documented in the TSS or are user-initiated. The evaluator verified that only application associated traffic is the user initiated communication to the ACE Server. Network captures verified that the only network communication seen is the user initiated communication to the ACE Server. Test 2: The evaluator shall run the application. After the application initializes, the evaluator shall run network port scans to verify that any ports opened by the application have been captured in the ST for the third selection and its assignment. This includes connection-based protocols (e.g. TCP, DCCP) as well as connectionless protocols (e.g. UDP). The evaluator ran the application and connected to the server. The evaluator ran an Nmap port scan on the device and verified no ports were opened by the TOE that shouldn t have been FDP_DEC_EXT TSS Assurance Activity The evaluator shall inspect the TSS documentation to identify functionality in the application where PII can be transmitted, and perform the following tests. [ST] Section FDP_DEC_EXT.1 states that the ACE Client does not maintain PII. Hence, it does not transmit PII over any network. ACE Client does maintain user credentials. In particular, ACE Client transmits a user s account name and TLS client certificate when connecting to an ACE Server. However, PP APP SW distinguishes credentials from PII Guidance Assurance Activities 34

36 None defined Test Assurance Activity Test 1: The evaluator shall run the application and exercise the functionality responsibly for transmitting PII and verify that user approval is required before transmission of the PII. Note: The security target states that the TOE does not transmit Personally Identifiable Information (PII) over a network. Test 1 is not applicable FDP_DAR_EXT.1 Encryption Of Sensitive Application Data FDP_DAR_EXT TSS Assurance Activities For Android: The evaluator shall inspect the TSS and verify that it describes how files containing sensitive data are stored with the MODE_PRIVATE flag set. [ST] Section states that the application leverages platform-provided functionality to encrypt sensitive data in nonvolatile memory. Sections FCS_STO_EXT.1 and FDP_DAR_EXT.1 states that the ACE Client sensitive data consists of user TLS client key and server account password credentials. FCS_STO_EXT.1 Storage of Secrets specifies the Android KeyStore for protecting keys and credentials. ACE Client stores application account options using Android s SharedPreferences. The SharedPreferences files are accessed using the MODE_PRIVATE flag, even though the application account options do not contain sensitive data Guidance Assurance Activities Test Assurance Activity The evaluator shall inventory the file system locations where the application may write data. The evaluator shall run the application and attempt to store sensitive data. The evaluator shall then inspect those areas of the file system to note where data was stored (if any), and determine whether it has been encrypted. If leverage platform-provided functionality is selected, the evaluation activities will be performed as stated in the following requirements, which vary on a per-platform basis: For Android: The evaluator shall inspect the TSS and verify that it describes how files containing sensitive data are stored with the MODE_PRIVATE flag set. [ST] Section states that the ACE Client stores the user TLS client key and the server account password in the Android KeyStore. The ACE Client does not store any sensitive data in the file system. 35

37 2.3 Identification and Authentication (FIA) FIA_X509_EXT.1 X.509 Certificate Validation FIA_X509_EXT.1 X.509 NIAP TD Bullet 4 of FIA_X509_EXT.1.1 should be rewritten as follows: The application shall validate the revocation status of the certificate using [selection: the Online Certificate Status Protocol (OCSP) as specified in RFC 2560, a Certificate Revocation List (CRL) as specified in RFC 5759, none]. The application note should be rewritten as follows: Application Note: FIA_X509_EXT.1.1 lists the rules for validating certificates. The ST author shall select whether revocation status is verified using OCSP, CRLs, or not at all. The ST author can select none only when a mobile application provides countermeasures to the threat of a compromised server certificate that are at least as effective as certificate revocation checking. In particular, the developer will ask NIAP to re-examine the developer s countermeasures for a compromised server certificate and the developer will respond to any concerns with the countermeasures. FIA_X509_EXT.2 requires that certificates are used for HTTPS, TLS and DTLS; this use requires that the extendedkeyusage rules are verified TSS Assurance Activity The evaluator shall ensure the TSS describes where the check of validity of the certificates takes place. The evaluator ensures the TSS also provides a description of the certificate path validation algorithm. [ST] Section FIA_X509_EXT.1 states that the Android platform performs certification path validation as part of the TLS service. The platform certificate path algorithm is described by its Android platform source code: _r7/src/platform/java/org/conscrypt/TrustManagerImpl.java See the checktrusted() method at line 249 for the algorithm. Android does not provide revocation checking as part of certificate path validation. Hypori provides countermeasures to the threat of a compromised server certificate that are at least as effective as certificate revocation checking. In the evaluated configuration, it is best to use an enterprise CA signing certificate for ACE Server certificates and use a service such as GlobalSign's trusted root certificate service to anchor its trust chain. 36

38 An administrator schedules the provisioning server to generate server certificates that corresponds to a typical CRL update schedule. These server certificates would be set to expire after a fixed number of hours based upon the same schedule along with some margin for delivering the updates. Employing this practice will result in the servers certificate valid for only a short period of time; typically the time it takes to roll out a CRL update throughout the enterprise. If a server certificate is compromised, it will only be usable for a very short time if at all. That time period is likely less than it takes for an enterprise to detect that a server's key/certificate is compromised and to revoke the certificate and update the CRLs and OCSP responders Guidance Assurance Activities Test Assurance Activity The tests described must be performed in conjunction with the other certificate services assurance activities, including the functions in FIA_X509_EXT.2.1. The tests for the extendedkeyusage rules are performed in conjunction with the uses that require those rules. The evaluator shall create a chain of at least four certificates: the node certificate to be tested, two Intermediate CAs, and the selfsigned Root CA. Test 1: The evaluator shall demonstrate that validating a certificate without a valid certification path results in the function failing. The evaluator shall then load a certificate or certificates as trusted CAs needed to validate the certificate to be used in the function, and demonstrate that the function succeeds. The evaluator shall then delete one of the certificates, and show that the function fails. A trusted CA path was installed on the device. A Wireshark capture verified that a connection attempt to the server was successful. The trusted CA was deleted from the device. A Wireshark capture verified that a connection attempt to the server was unsuccessful and the connection was denied by the client. The tests described must be performed in conjunction with the other certificate services assurance activities, including the functions in FIA_X509_EXT.2.1. The tests for the extendedkeyusage rules are performed in conjunction with the uses that require those rules. The evaluator shall create a chain of at least four certificates: the node certificate to be tested, two Intermediate CAs, and the selfsigned Root CA. Test 2: The evaluator shall demonstrate that validating an expired certificate results in the function failing. The evaluator configured the server to use an expired certificate and started a Wireshark capture and then attempted to connect to the server through the ACE client application. The evaluator reviewed the packet capture and verified that the connection failed after receiving the expired server certificate. The TOE also displayed an error message warning of the expired certificate. The tests described must be performed in conjunction with the other certificate services assurance 37

39 activities, including the functions in FIA_X509_EXT.2.1. The tests for the extendedkeyusage rules are performed in conjunction with the uses that require those rules. The evaluator shall create a chain of at least four certificates: the node certificate to be tested, two Intermediate CAs, and the selfsigned Root CA. Test 3: The evaluator shall test that the TOE can properly handle revoked certificates conditional on whether CRL or OCSP is selected; if both are selected, then a test shall be performed for each method. The evaluator shall test revocation of the node certificate and revocation of the intermediate CA certificate (i.e. the intermediate CA certificate should be revoked by the root CA). The evaluator shall ensure that a valid certificate is used, and that the validation function succeeds. The evaluator then attempts the test with a certificate that has been revoked (for each method chosen in the selection) to ensure when the certificate is no longer valid that the validation function fails. Test 3 is not applicable. Per TD0051, Android does not check for revoked certificates. The tests described must be performed in conjunction with the other certificate services assurance activities, including the functions in FIA_X509_EXT.2.1. The tests for the extendedkeyusage rules are performed in conjunction with the uses that require those rules. The evaluator shall create a chain of at least four certificates: the node certificate to be tested, two Intermediate CAs, and the selfsigned Root CA. Test 4: If OCSP is selected, the evaluator shall configure the OCSP server or use a man-in-the-middle tool to present a certificate that does not have the OCSP signing purpose and verify that validation of the OCSP response fails. If CRL is selected, the evaluator shall configure the CA to sign a CRL with a certificate that does not have the crlsign key usage bit set, and verify that validation of the CRL fails. Test 4 is not applicable. Per TD0051, ACE Client does not check extended key usage for OCSP Signing, since ACE Client does not use OCSP to check certificate revocation status. The tests described must be performed in conjunction with the other certificate services assurance activities, including the functions in FIA_X509_EXT.2.1. The tests for the extendedkeyusage rules are performed in conjunction with the uses that require those rules. The evaluator shall create a chain of at least four certificates: the node certificate to be tested, two Intermediate CAs, and the selfsigned Root CA. Test 5: The evaluator shall modify any byte in the first eight bytes of the certificate and demonstrate that the certificate fails to validate. (The certificate will fail to parse correctly.) The evaluator configured the server to modify a byte in the first eight bytes of its certificate. The evaluator started a Wireshark and attempted to connect to the server through the ACE client application. The packet capture verified that the connection failed after receiving the modified server certificate. The tests described must be performed in conjunction with the other certificate services assurance activities, including the functions in FIA_X509_EXT.2.1. The tests for the extendedkeyusage rules are performed in conjunction with the uses that require those rules. The evaluator shall create a chain 38

40 of at least four certificates: the node certificate to be tested, two Intermediate CAs, and the selfsigned Root CA. Test 6: The evaluator shall modify any byte in the last byte of the certificate and demonstrate that the certificate fails to validate. (The signature on the certificate will not validate.) The evaluator configured the server and modified the last byte of its certificate. The evaluator started a Wireshark and attempted to connect to the server through the ACE client application. The packet capture verified that the connection failed after receiving the modified. An error message was displayed by the TOE to notify that the certificate could be validated. The tests described must be performed in conjunction with the other certificate services assurance activities, including the functions in FIA_X509_EXT.2.1. The tests for the extendedkeyusage rules are performed in conjunction with the uses that require those rules. The evaluator shall create a chain of at least four certificates: the node certificate to be tested, two Intermediate CAs, and the selfsigned Root CA. Test 7: The evaluator shall modify any byte in the public key of the certificate and demonstrate that the certificate fails to validate. (The signature on the certificate will not validate.) The evaluator configured the server to modify a byte in the public key of its certificate. A Wireshark was started and an attempt to connect to the server through the ACE client application. The packet capture verified that the connection failed after receiving the modified server certificate. An error message was displayed by the TOE to notify that the certificate could be validated FIA_X509_EXT.1.2 This requirement depends upon selection in FTP_DIT_EXT TSS Assurance Activity Guidance Assurance Activities Test Assurance Activity The tests described must be performed in conjunction with the other certificate services assurance activities, including the functions in FIA_X509_EXT.2.1. The evaluator shall create a chain of at least four certificates: the node certificate to be tested, two Intermediate CAs, and the selfsigned Root CA. Test 1: The evaluator shall construct a certificate path, such that the certificate of the CA issuing the TOE's certificate does not contain the basicconstraints extension. The validation of the certificate 39

41 path fails. The evaluator issued certificates using a CA that does not contain the basicconstraints extension and attempted to connect to the server through the ACE Client application. A network packet capture verified that the connection failed after receiving the server certificate. Additionally the TOE displayed a notification that the certificate could not be validated. The tests described must be performed in conjunction with the other certificate services assurance activities, including the functions in FIA_X509_EXT.2.1. The evaluator shall create a chain of at least four certificates: the node certificate to be tested, two Intermediate CAs, and the selfsigned Root CA. Test 2: The evaluator shall construct a certificate path, such that the certificate of the CA issuing the TOE's certificate has the CA flag in the basicconstraints extension not set. The validation of the certificate path fails. The evaluator issued certificates using a CA that has the CA flag in the basicconstraints extension not set and attempted to connect to the server through the ACE Client application. A packet capture verified that the connection failed after receiving the server certificate. Additionally, the TOE displayed an error message stating that the certificate could be validated. The tests described must be performed in conjunction with the other certificate services assurance activities, including the functions in FIA_X509_EXT.2.1. The evaluator shall create a chain of at least four certificates: the node certificate to be tested, two Intermediate CAs, and the selfsigned Root CA. Test 3: The evaluator shall construct a certificate path, such that the certificate of the CA issuing the TOE's certificate has the CA flag in the basicconstraints extension set to TRUE. The validation of the certificate path succeeds. The evaluator configured the issuing CA to have the CA flag in the basicconstraints extension set to TRUE and attempted to connect to the server through the ACE client application. A packet capture verified that the connection succeeded FIA_X509_EXT.2 X.509 Certificate Authentication FIA_X509_EXT.2.1 This requirement depends upon selection in FTP_DIT_EXT Assurance Activity None Identified FIA_X509_EXT.2.2 This requirement depends upon selection in FTP_DIT_EXT

42 TSS Assurance Activity The evaluator shall check the TSS to ensure that it describes how the TOE chooses which certificates to use, and any necessary instructions in the administrative guidance for configuring the operating environment so that the TOE can use the certificates. [ST] Section FIA_X509_EXT.2 states that the ACE Client presents the TLS client certificate and key to the ACE Server to authenticate a TLS connection. During account setup, the user identifies which certificate to present for each account. The user selects a certificate from the Android certificate store. The user can change the selection from Client Certificate under Connection on the Settings page. The TLS client certificate is an X509 certificate. The user stores a CA certificate for the server certificates in the Android key store during installation. (The user need not install a CA certificate when the CA is a platform trusted CA.) ACE Client uses Android platform certificate path validation services with the CA certificate to validate the certificate presented by the ACE Server. Android does not provide revocation checking as part of certificate validation. Hence, there is no communication with a revocation service and no certificate is rejected for lack of revocation check. The evaluator shall examine the TSS to confirm that it describes the behavior of the TOE when a connection cannot be established during the validity check of a certificate used in establishing a trusted channel. The evaluator shall verify that any distinctions between trusted channels are described. Android does not provide revocation checking as part of certificate validation. Hence, there is no communication with a revocation service and no certificate is rejected for lack of revocation check Guidance Assurance Activity The evaluator shall examine the TSS to confirm that it describes the behavior of the TOE when a connection cannot be established during the validity check of a certificate used in establishing a trusted channel. The evaluator shall verify that any distinctions between trusted channels are described. 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. The operational guidance does not identify any default action which the administrator must take when a connection cannot be established during the validity check of a certificate used Test Assurance Activity The evaluator shall perform the following test for each trusted channel: 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. 41

43 Per TD0051 this test is not applicable. Android does not provide revocation checking as part of certificate validation. Hence, there is no communication with a revocation service and no certificate is rejected for lack of revocation check. 2.4 Security Management (FMT) FMT_MEC_EXT.1 Supported Configuration Mechanism TD0024: Application Settings Clarification for FMT_MEC_EXT References PP_APP_V1.1, requirement FMT_MEC_EXT.1 Issue Description In FMT_MEC_EXT.1, the stated assurance activity on Linux indicate /etc must be used for systemspecific changes and the user's home directory for user-specific configuration. The Windows assurance-activity specifies the use of the Windows registry. The focus is on security-related settings, but more clarification is needed on what are the security-related settings. Resolution The Assurance Activity for this requirement should be revised to state The evaluator shall review the TSS to identify the application's configuration options (e.g. settings) and determine whether these are stored and set using the mechanisms supported by the platform. At a minimum the TSS shall list settings related to any SFRs and any settings that are mandated in the operational guidance in response to an SFR. The next update of the App PP will reflect the TD. Justification The Assurance Activity needed to be rewritten to clarify the intent, which is that the TSS should define the security-related settings based on the platform and that these settings must include settings related to any of the SFRs and the operational guidance FMT_MEC_EXT TSS Assurance Activity The evaluator shall review the TSS to identify the application's configuration options (e.g. settings) and determine whether these are stored and set using the mechanisms supported by the platform. At a minimum the TSS shall list settings related to any SFRs and any settings that are mandated in the operational guidance in response to an SFR. ST Section 6.4 states that the TOE uses Android mechanisms for storing the configuration settings. 42

44 The ACE Client provides the capability to set the following configuration options: ACE Server IP address, ACE Server port, and TLS client certificate (key). ACE Client invokes the recommended Android mechanisms for storing configuration data. The client uses SharedPreferences and extends PreferenceActivity Guidance Assurance Activities The evaluator shall review the TSS to identify the application's configuration options (e.g. settings) and determine whether these are stored and set using the mechanisms supported by the platform. At a minimum the TSS shall list settings related to any SFRs and any settings that are mandated in the operational guidance in response to an SFR. The TOE uses Android mechanisms for storing the configuration settings. The ACE Client provides the capability to set the following configuration options: ACE Server IP address, ACE Server port, and TLS client certificate (key). ACE Client invokes the recommended Android mechanisms for storing configuration data. The client uses SharedPreferences and extends PreferenceActivity Test Assurance Activity The evaluator shall review the TSS to identify the application's configuration options (e.g. settings) and determine whether these are stored and set using the mechanisms supported by the platform. At a minimum the TSS shall list settings related to any SFRs and any settings that are mandated in the operational guidance in response to an SFR. The method of doing so varies per platform. For Android: The evaluator shall run the application and make Security-related changes to its configuration. The evaluator shall check that at least one XML file at location /data/data/package/shared_prefs/ reflects the changes made to the configuration to verify that the application used SharedPreferences and/or PreferenceActivity classes for storing configuration data, where package is the Java package of the application. The evaluator ran the application and made Security-related changes to its configuration. The evaluator viewed an xml file was located in shared_prefs of /data/data/com.hypori.ace.client.demo/ for the configured user and verified that it reflected the configuration made FMT_CFG_EXT.1 Secure by Default Configuration FMT_CFG_EXT TSS Assurance Activity The evaluator shall check the TSS to determine if the application requires any type of credentials and if the applications installs with default credentials. [ST] Section FMT_CFG_EXT.1 states that the ACE Client credentials consist of the user TLS client key and server account password. ACE Client installer does not include a default client key or server account password. A user installs a TLS client certificate and private key from a certificate file using Android s certificate services. A user s IT group provides the user with server account password. 43

45 Guidance Assurance Activity Test Assurance Activity If the application uses any default credentials the evaluator shall run the following tests. Test 1: The evaluator shall install and run the application without generating or loading new credentials and verify that only the minimal application functionality required to set new credentials is available. The application does not use any default credentials. As identified in [ACE_CLIENT_INSTALL], the server account name and password are provided by the system administrator. Therefore, this test is not applicable. If the application uses any default credentials the evaluator shall run the following tests. Test 2: The evaluator shall attempt to clear all credentials and verify that only the minimal application functionality required to set new credentials is available. The application does not use any default credentials. As identified in [ACE_CLIENT_INSTALL], the server account name and password are provided by the system administrator. Therefore, this test is not applicable. If the application uses any default credentials the evaluator shall run the following tests. Test 3: The evaluator shall run the application, establish new credentials and verify that the original default credentials no longer provide access to the application. The application does not use any default credentials. As identified in [ACE_CLIENT_INSTALL], the server account name and password are provided by the system administrator. Therefore, this test is not applicable FMT_CFG_EXT TSS Assurance Activity Guidance Assurance Activities Test Assurance Activity TD0050: FMT_CFG_EXT.1.2 Change in APP SW PPv1.1 44

46 Publication Date References PP_APP_v1.1 Issue Description There is a typographical error in the Application Software PP v1.1 that needs to be correct. In control "FMT_CFG_EXT.1.2" there is a command listed under the Blackberry and Android Assurance Activities that reads: ls -alr grep -E '$...(r -w --x)'. Resolution The command is being corrected to read: ls -alr grep -E '^...(r -w --x)'. In a regex, the dollar sign indicates end-of-line. The carrot indicates beginning-of-line. Justification Command correction needed for FMT_CFG_EXT.1.2 The evaluator shall install and run the application. The evaluator shall inspect the filesystem of the platform (to the extent possible) for any files created by the application and ensure that their permissions are adequate to protect them. The method of doing so varies per platform. For Android: The evaluator shall run ls -alr grep -E '^...(r -w --x)' inside the application's data directories to ensure that all files are not world-accessible (either read, write, or execute). The command should not print any files. The evaluator shall also verify that no sensitive data is written to external storage as this data can be read/modified by any application containing the READ_EXTERNAL_STORAGE and/or WRITE_EXTERNAL_STORAGE permissions. The evaluator ran ls -alr grep -E '^...(r -w --x)' command inside the application's data directory and verified that no files were listed as world accessible. The evaluator verified no sensitive data was written to external storage FMT_SMF.1 Specification of Management Functions FMT_SMF TSS Assurance Activity Guidance Assurance Activity 45

47 The evaluator shall verify 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. The TSF is capable of performing the following management functions: Setting configuration options Applying configuration policies from the ACE Sever [ACE_CC] Section 6 Provisioning of ACE Client Credentials provides the guidance to create and install the ACE Client credentials. [UG_ANDROID] Section: Connecting to the Server pages provides the guidance to set the following: The ACE server name or address The ACE server port number The Account name The TLS client identity certificate Test Assurance Activity The evaluator shall test the application's ability to provide the management functions by configuring the application and testing each option selected from above. The evaluator is expected to test these functions in all the ways in which the ST and guidance documentation state the configuration can be managed. The evaluator confirmed the application's ability to provide the management functions. The following functions were performed: The application was configured. The evaluator verified that the remember password policy was enabled on the ACE Client. The evaluator configured the client policy on the ACE server by setting the remember-password flag to false in the clientpolicies.json file. The evaluator connected to the ACE Server through the Ace Client application to apply the policy and verified that the remember-password setting was now disabled on the ACE Client. 2.5 Protection of the TSF (FPT) FPT_API_EXT.1 Use of Supported Services and APIs FPT_API_EXT.1.1 TD0054: Clarification of FPT_API_EXT.1.1 Requirement in APP PP v References PP_APP_v1.1 46

48 Issue Description Additional detail of the FPT_API_EXT.1.1 requirement is needed in order for an Application Software vendor to know where they are using capabilities or products that are inherently unreliable. These items should be identified and documented in the TSS to successfully meet the requirement. Resolution Revised wording for the Application Note: The definition of supported may vary depending upon whether the application is provided by a third party (who relies upon documented platform APIs) or by a platform vendor who may be able to guarantee support for platform APIs which are not externally documented. The use of undocumented API's by a 3rd party application, like a virus scanner for example, is acceptable when well thought-out and documented by the application developer. Revised wording for the Assurance Activity: The evaluator shall verify that the TSS lists the platform APIs used in the application. The evaluator shall then compare the list with the supported APIs (available through e.g. developer accounts, platform developer groups) and ensure that all APIs listed in the TSS are supported. If any unsupported API's should be discovered the evaluator should review the TSS and verify that unsupported API calls are clearly documented along with a developer justification for why they must be used TSS Assurance Activity The evaluator shall verify that the TSS lists the platform APIs used in the application. The evaluator shall then compare the list with the supported APIs (available through e.g. developer accounts, platform developer groups) and ensure that all APIs listed in the TSS are supported. If any unsupported API's should be discovered the evaluator should review the TSS and verify that unsupported API calls are clearly documented along with a developer justification for why they must be used. [ST] Section 9 Appendix: Android APIs identifies the Android platform APIs used by the ACE Client. The TOE runs on Android versions 4.3, 4.4, 5.0 and 5.1. Android version 4.3 API Level 18 Android version 4.4 API Level 19 Android version 5.0 API Level 21 Android version 5.1 API Level 22 The evaluator compared the platform APIs identified in the security target with the platform developer web page at and insured that all of the platform APIs identified in the ST are supported for each version of Android Guidance Assurance Activity 47

49 Test Assurance Activities FPT_AEX_EXT.1 Anti-Exploitation Capabilities FPT_AEX_EXT TSS Assurance Activity The evaluator shall ensure that the TSS describes the compiler flags used to enable ASLR when the application is compiled. [ST] Section describes the compiler flags used to enable ASLR when the application is compiled. The Client uses -fpic when building the application with Android Native Development Kit (NDK r9d) using gcc. ACE Client is a Java application that includes Java Native Interface (JNI) libraries. Hypori enables stack-based buffer overflow protection using -fstack-protector Guidance Assurance Activity Test Assurance Activities The evaluator shall perform either a static or dynamic analysis to determine that no memory mappings are placed at an explicit and consistent address. The method of doing so varies per platform. For Android: The evaluator shall run the same application on two different Android systems. Connect via ADB and inspect /proc/pid/maps. Ensure the two different instances share no mapping locations. The evaluator ran the same application on two different Android systems. One system was Android version 4.4 and the other version was Android 5.1. The evaluator connected to the devices using the Android Debug Bridge (ADB) ran executed the top command. The evaluator collected the /proc/pid/maps file for comparing and verified that no files shared the same memory mapping location FPT_AEX_EXT TSS Assurance Activity Guidance Assurance Activity 48

50 Test Assurance Activity The evaluator shall verify that no memory mapping requests are made with write and execute permissions. The method of doing so varies per platform. For Android: The evaluator shall perform static analysis on the application to verify that mmap is never invoked with both the PROT_WRITE and PROT_EXEC permissions, and mprotect is never invoked. The evaluator decompiled the ACE Client apk file. After decompilation, the evaluator performed a search for mmap and mprotect on the entire application. Both searches did not return any matching results. The evaluator was able to conclude that mmap and mprotect is not invoked by the TOE FPT_AEX_EXT TSS Assurance Activity Guidance Assurance Activity Test Assurance Activity The evaluator shall configure the platform in the ascribed manner and carry out one of the prescribed tests: For Android: The evaluator shall ensure that the application can run with SE for Android enabled and enforcing. The application successfully ran with SE enabled and enforcing on both Android 4.4 and Android FPT_AEX_EXT TSS Assurance Activity Guidance Assurance Activity Test Assurance Activity The evaluator shall run the application and determine where it writes its files. For files where the user 49

51 does not choose the destination, the evaluator shall check whether the destination directory contains executable files. This varies per platform: For Android: The evaluator shall run the program, mimicking normal usage, and note where all files are written. The evaluator shall ensure that there are no executable files stored under /data/data/package/ where package is the Java package of the application. The evaluator ran the ACE client application and mimicked normal usage by connecting to the ACE Server. The evaluator listed the files under /data/data/ com.hypori.ace.client.demo and verified that no executable files were found FPT_AEX_EXT TSS Assurance Activity The evaluator shall ensure that the TSS section of the ST describes the compiler flag used to enable stack-based buffer overflow protection in the application. [ST] Section FPT_AEX_EXT.1 states that the ACE Client is a Java application that includes Java Native Interface (JNI) libraries. Hypori enables stack-based buffer overflow protection using - fstack-protector Guidance Assurance Activity Test Assurance Activity The evaluator shall perform a static analysis to verify that stack-based buffer overflow protection is present. The method of doing so varies per platform: For Android: Applications that are entirely Java run in the Java machine and do not need traditional stack protection. For applications using Java Native Interface (JNI), the evaluator shall ensure that the -fstack-protector-strong or fstack-protector all flags are used. The - fstack-protector-all flag is preferred but -fstack-protector-strong is acceptable. [ST] Section FPT_AEX_EXT.1 states that the ACE Client is a Java application that includes Java Native Interface (JNI) libraries. Hypori enables stack-based buffer overflow protection using - fstack-protector FPT_TUD_EXT.1 Integrity for Installation and Update FPT_TUD_EXT TSS Assurance Activity 50

52 Guidance Assurance Activity Test Assurance Activity The evaluator shall check for an update using procedures described in the documentation and verify that the application does not issue an error. If it is updated or if it reports that no update is available this requirement is considered to be met. The evaluator checked for an update through the Google Play store and saw that no update was available and no error was issued FPT_TUD_EXT TSS Assurance Activity Guidance Assurance Activity Test Assurance Activity The evaluator shall verify that application updates are distributed in the format supported by the platform. This varies per platform: For Android: The evaluator shall ensure that the application is packaged in the Android application package (APK) format. [ST] Section FPT_TUD_EXT.1 states that Hypori distributes the ACE Client as an.apk file. The evaluator verified the application was packaged as an APK by installing the ACE Client application on the Android devices from the Google Play Store FPT_TUD_EXT TSS Assurance Activity Guidance Assurance Activity Test Assurance Activity The evaluator shall record the path of every file on the entire filesystem prior to installation of the application, and then install and run the application. Afterwards, the evaluator shall then uninstall the application, and compare the resulting filesystem to the initial record to verify that no files, other than 51

53 configuration, output, and audit/log files, have been added to the filesystem. The ACE Client application only writes to the /data/ partition. Using the df command in a shell, the evaluator viewed that /data/ is its own separate filesystem. The evaluator captured the files in the /data/ filesystem. The evaluator installed and ran the ACE Client application. The evaluator then uninstalled the application through the Google Play Store. The evaluator captured the files in the /data/ filesystem. The evaluator compared the list of files to see that no unaccounted files have been added to the /data/ filesystem. The only files that added were log files FPT_TUD_EXT TSS Assurance Activity Guidance Assurance Activity Test Assurance Activity The evaluator shall verify that the application's executable files are not changed by the application. The evaluator shall complete the following test: Test 1: The evaluator shall install the application and then locate all of its executable files. The evaluator shall then, for each file, save off either a hash of the file or a copy of the file itself. The evaluator shall then run the application and exercise all features of the application as described in the TSS. The evaluator shall then compare each executable file with the either the saved hash or the saved copy of the files. The evaluator shall verify that these are identical. The evaluator captured a SHA1 hash value of the executable file before and after the ACE Client Application was run. The evaluator verified that the executable file was not modified by making sure the hashes were the same. The SHA1 hash value of the executable (2d do 54 9a 2e b ee cb 8f d9 90 b0 ec ab) was the same before and after the application was ran FPT_TUD_EXT TSS Assurance Activity Guidance Assurance Activity The evaluator shall query the application for the current version of the software according to the operational user guidance (AGD_OPE.1) and shall verify that the current version matches that of the documented and installed version [ACE_CC] Section 8 Verify Version of ACE Client, provides the guidance to query the application for the current version of the software. 52

54 Test Assurance Activity The evaluator shall query the application for the current version of the software according to the operational user guidance (AGD_OPE.1) and shall verify that the current version matches that of the documented and installed version. The evaluator queried the application for the current version of the software according to the operational user guidance (AGD_OPE.1) and verified that the current version matches that of the documented and installed version FPT_TUD_EXT TSS Assurance Activity The evaluator shall verify that the TSS identifies how the application installation package and updates to it are signed by an authorized source. The definition of an authorized source must be contained in the TSS. The evaluator shall also ensure that the TSS (or the operational guidance) describes how candidate updates are obtained. [ST] Section FPT_TUD_EXT.1 states that a user obtains ACE Client updates using the Android update mechanism or from the user s IT group. Hypori digitally signs the installation package as well as updates and includes the corresponding public key certificate in the package. Android will install an update only when the certificate in the update matches the certificate in the installed client. The client is signed with a unique certificate. It can be delivered via the Google Play store, MDM, or other enterprise app stores. The certificate information: X.509, CN=Brian Vetter, OU=DroidCloud, O=DroidCloud, L=Austin, ST=Tx, C=US PM] [certificate is valid from 3/20/13 1:03 PM to 8/5/401:03 [CertPath not validated: Path does not chain with any of the trust anchors] Hypori provides customers with timely updates. A customer chooses their preferred communication. Hypori Support Department will notify customers of updates using each customer s preferred communication mechanism. Application changes may be pushed to end users via the Google Play store like any other Android application or via an enterprise application store internal to a customer. Typical delivery times for security updates are 5 to 10 business days. Hypori maintains a Security Portal online. Every customer is registered with the Support Portal. Hypori notifies each customer of a new security report on the Support portal using the customers preferred communication mechanism. Hypori secures the Support Portal via SSL and user authentication. Each customer contact must log in with their specific credentials in order to see the security reports Guidance Assurance Activity The evaluator shall verify that the TSS identifies how the application installation package and updates to it are signed by an authorized source. The definition of an authorized source must be contained in the TSS. The evaluator shall also ensure that the TSS (or the operational guidance) describes how candidate updates are obtained. [ACE_CC] Section 5 Update Verification; describes how candidate updates are obtained. installation package is obtained through Google Play or your enterprise IT group. The 53

55 [UG_ANDROID] Section: ACE Client Settings page 25 describes how the TOE candidate updates are obtained. Updating Your ACE Client If you already have an ACE Client installed on your mobile device, you can update the client, request a new certificate, and change your account password using the Hypori User Setup app. To update your ACE Client files and password: 1) On your mobile device, open your web browser and type the URL to the Hypori User Setup web app given to you by your system administrator. 2) On the login screen, type your ACE account username and password. 3) On the Welcome screen, choose one of the following actions: Download ACE Client: Opens the ACE Client download page in the Google Play Store (see Installing the ACE Client from the Google Play Store on page 15). Request a Certificate: Generates and installs a new authentication certificate on your mobile device (see Creating the Client Certificate on page 21). Change Password: Opens the Change Password screen. Your new password must be a minimum of seven characters, and it must contain at least one uppercase letter, one lowercase letter, and one numeric character. View Quick Install Guide: Opens the Hypori ACE Quick Install Guide. 4) After selecting an action, follow the on-screen instructions to complete the task Test Assurance Activity FPT_LIB_EXT.1 Use of Third Party Libraries FPT_LIB_EXT TSS Assurance Activity Guidance Assurance Activity Test Assurance Activity The evaluator shall install the application and survey its installation directory for dynamic libraries. The evaluator shall verify that libraries found to be packaged with or employed by the application are limited to those in the assignment. The evaluator listed the dynamic libraries found in the ACE Client application s installation directory. The evaluator then verified that only the claimed libraries were used. 54

56 2.6 Trusted Path/Channel (FTP) FPT_DIT_EXT.1 Protection of Data in Transit FPT_DIT_EXT TSS Assurance Activity Guidance Assurance Activity Test Assurance Activity The evaluator shall perform the following tests. Test 1: The evaluator shall exercise the application (attempting to transmit data; for example by connecting to remote systems or websites) while capturing packets from the application. The evaluator shall verify from the packet capture that the traffic is encrypted with HTTPS, TLS or DTLS in accordance with the selection in the ST. The application connected to the remote server and network packets were captured using Wireshark. The packet captures verified that TLSv1.2 was used for transmitting the data, including the sending of user credentials. Test 2: The evaluator shall exercise the application (attempting to transmit data; for example by connecting to remote systems or websites) while capturing packets from the application. The evaluator shall review the packet capture and verify that no sensitive data is transmitted in the clear. The application connected to the remote server and network packets were captured using Wireshark. The packet captures verified that TLSv1.2 was used for transmitting the data. No sensitive data was transmitted in the clear. Test 3: The evaluator shall inspect the TSS to determine if user credentials are transmitted. If credentials are transmitted the evaluator shall set the credential to a known value. The evaluator shall capture packets from the application while causing credentials to be transmitted as described in the TSS. The evaluator shall perform a string search of the captured network packets and verify that the plaintext credential previously set by the evaluator is not found. The application connected to the remote server and network packets were captured using Wireshark. The packet captures verified that TLSv1.2 was used for transmitting the data. No sensitive data was transmitted in the clear and examination of the packets revealed that no plaintext credentials were found. 55

57 3 SECURITY ASSURANCE REQUIREMENTS 3.1 Class ADV: Development ADV_FSP.1 Basic Functional Specification FSP_FSP.1 Assurance Activity The information about the TOE is contained in the guidance documentation available to the end user as well as the TSS portion of the ST. The TOE developer must concur with the description of the product that is contained in the TSS as it relates to the functional requirements. The Assurance Activities contained in Section 5.1 should provide the ST authors with sufficient information to determine the appropriate content for the TSS section. Application Note: As indicated in the introduction to this section, the functional specification is comprised of the information contained in the AGD_OPE and AGD_PRE documentation. The developer may reference a website accessible to application developers and the evaluator. The assurance activities in the functional requirements point to evidence that should exist in the documentation and TSS section; since these are directly associated with the SFRs, the tracing in element ADV_FSP.1.2D is implicitly already done and no additional documentation is necessary. The Assurance Activities identified above provided sufficient information to determine the appropriate content for the TSS section. Since these are directly associated with the SFRs, and are implicitly already done, no additional documentation or analysis is necessary. 3.2 Class AGD: Guidance Documents AGD_OPE.1 Operational User Guidance AGD_OPE.1 Assurance Activity Some of the contents of the operational guidance will be verified by the assurance activities in Section 5.1 and evaluation of the TOE according to the [CEM]. The following additional information is also required. If cryptographic functions are provided by the TOE, the operational guidance shall contain instructions for configuring the cryptographic engine associated with the evaluated configuration of the TOE. It shall provide a warning to the administrator that use of other cryptographic engines was not evaluated nor tested during the CC evaluation of the TOE. Cryptographic functions are provided by the Android platform and not the TOE. management of cryptographic functions are not identified in the operational guidance. As a result, the The documentation must describe the process for verifying updates to the TOE by verifying a digital signature this may be done by the TOE or the underlying platform. [ACE-CC] Section 5 Update Verification states that Hypori digitally signs the installation package as well as updates and includes the corresponding public key certificate in the package. Android will install 56

58 an update only when the certificate in the update matches the certificate in the installed client. The Android operating system will report success or failure of the update process. The evaluator shall verify that this process includes the following steps: Instructions for obtaining the update itself. This should include instructions for making the update accessible to the TOE (e.g., placement in a specific directory). Instructions for initiating the update process, as well as discerning whether the process was successful or unsuccessful. This includes generation of the hash/digital signature. [ACE_CC] Section 5 Update Verification; describes how candidate updates are obtained. installation package is obtained through Google Play or your enterprise IT group. [UG_ANDROID] Section: ACE Client Settings page 25 describes how the TOE candidate updates are obtained. Updating Your ACE Client If you already have an ACE Client installed on your mobile device, you can update the client, request a new certificate, and change your account password using the Hypori User Setup app. To update your ACE Client files and password: 1) On your mobile device, open your web browser and type the URL to the Hypori User Setup web app given to you by your system administrator. 2) On the login screen, type your ACE account username and password. 3) On the Welcome screen, choose one of the following actions: Download ACE Client: Opens the ACE Client download page in the Google Play Store (see Installing the ACE Client from the Google Play Store on page 15). Request a Certificate: Generates and installs a new authentication certificate on your mobile device (see Creating the Client Certificate on page 21). Change Password: Opens the Change Password screen. Your new password must be a minimum of seven characters, and it must contain at least one uppercase letter, one lowercase letter, and one numeric character. View Quick Install Guide: Opens the Hypori ACE Quick Install Guide. 4) After selecting an action, follow the on-screen instructions to complete the task. The TOE will likely contain security functionality that does not fall in the scope of evaluation under this PP. The operational guidance shall make it clear to an administrator which security functionality is covered by the evaluation activities. [ACE_CC] Section 2 Common Criteria Evaluation identifies the security functionality covered by the evaluation activities. [ST] Section 2.3 identifies the physical boundaries of the TOE as the ACE Client application and configuration settings as defined in the ACE Client installation package for Android. ACE Client is a 57

59 thin client that only communicates with the ACE server. The ACE Server, applications running on the ACE server, and any functions not specified in this security target are outside the scope of the TOE. Hypori has evaluated the security features of ACE Client version under the Common Criteria Evaluation and Validation Scheme (CCEVS). The evaluation demonstrates Hypori ACE Client conforms to the security requirements specified in Protection Profile for Application Software when installed and operated in accordance with Hypori Virtual Mobile Infrastructure Platform Android Cloud Environment Client Security Target AGD_PRE.1 Preparative Procedures AGD_PRE.1 Assurance Activity 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 (that is, combination of hardware and operating system) claimed for the TOE in the ST. [ACE_CC] identifies all the platforms (that is, combination of hardware and operating system) claimed for the TOE in the ST. Hypori s general ACE Client applies in the evaluated configuration along with this Common Criteria specific guidance. The general guidance covers Android 4.3, 4.4, 5.0, and 5.1, and there is no versionspecific configuration. Cipher suites are determined by choice of Android version not ACE Client configuration. 3.3 ATE_IND.1 Independent Testing Conformance ATE_IND.1 Assurance Activity The evaluator shall prepare a test plan and report documenting the testing aspects of the system, including any application crashes during testing. The evaluator shall determine the root cause of any application crashes and include that information in the report. The test plan covers all of the testing actions contained in the [CEM] and the body of this PP s Assurance Activities. The evaluator prepared a test plan and report documenting the testing aspects of the system of the testing actions contained in the [CEM] and the body of this PP s Assurance Activities. The testing and test results are located in the proprietary Hypori Virtual Mobile Infrastructure Platform Android Cloud Environment Client Common Criteria Test Report and Procedures, Version 1.0, Feb While it is not necessary to have one test case per test listed in an Assurance Activity, the evaluator 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 platforms 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 58

60 ST are tested, then no rationale is necessary. [PP_APP_SW] specifies testing of the TOE with ATE_IND.1 Independent Testing Conformance. The assurance activity for ATE_IND.1 allows for testing a subset of the TOE platforms identified in the security target. The activity requires the evaluation team to provide justification for not testing all platforms. The justification must address the differences between the test platforms and the untested platforms and make an argument that the differences do not affect the testing to be performed. This section identifies a set of TOE platforms for testing and provides justification that results of testing the set are sufficient for all platforms identified in the security target. The section examines the TOE platforms specified in the security target. It considers the [PP ND 1.1] security functional requirements, software on each TOE platform, and hardware that comprise each TOE platform. The TOE is the Hypori Android Cloud Environment Client software application. The TOE runs on Android versions 4.3, 4.4, 5.0 and 5.1 and imposes no hardware requirements beyond Android operating system requirements. The CCTL tested Hypori Android Cloud Environment Client software application on the following platforms: ACE Client App deployed on Samsung Galaxy S6 running Android 5.1 ACE Client App deployed on Samsung Galaxy S5 running Android 4.4 Equivalency Rationale Android 4.3 and Android 4.4 The TOE does not impose hardware requirements beyond Android operating system requirements. Therefore, the equivalency rationale will be based upon the differences in the Android operating systems. With respect to security functionality claimed in the security target, Android 4.3 and Android 4.4 can be considered equivalent. The ACE Client relies on the Android platform for TLS protection of communication with the ACE Server. All of the ciphersuites identified in the security target for Android 4.3 are included in the Android 4.4 version. As a result the ciphersuites can be considered equivalent. For Android 4.3, ACE Client explicitly seeds the OpenSSL PRNG from /dev/urandom to address a Java Cryptography Architecture defect as described on Android has developed patches that ensure that Android s OpenSSL PRNG is initialized correctly. Those patches have been provided to Open Handset Alliance (OHA) partners. ACE Client applies the fix to SecureRandom exactly as posted. Therefore, the random number generation between Android 4.3 and Android 4.4 is working properly and can be considered equivalent. The fix does not affect Android 4.4, 5.0, and 5.1, since the defect is not present in those releases. Below are the point-wise differences Between Android 4.3 and Android 4.4. added to Android 4.4. Added support for five more languages Bi-directional text and other language support Enhanced accessibility These features were 59

61 Expandable notifications Filesystem write performance improvement by running fstrim command while device is idle Improved digital rights management (DRM) APIs Improvements to Photo Sphere Smoother user interface System-level support for geofencing and Wi-Fi scanning APIs User-installable keyboard maps Bluetooth Message Access Profile (MAP) support Chromecast support Closed captioning Chrome web view Device management built-in. If you ever lose your device, you can find or wipe it with the google.com Android Device Manager Downloads app redesign Easy home screen switching Full-screen wallpapers with preview HDR+ photography Music and movie-seeking from lock screen Tap to pay Touchscreen improvements Ability for applications to trigger translucency in the navigation and status bars Applications can now use immersive mode to keep the navigation and status bars hidden while maintaining user interaction Audio tunneling, audio monitoring, loudness enhancer Expanded functionality for notification listener services Native infrared blaster API New framework for UI transitions Optimizations for performance on devices with lower specifications, including zram support and low RAM device API Public API for developing and managing text messaging clients. Settings application no longer uses a multi-pane layout on devices with larger screens Settings application now makes it possible to select default text messaging and home (launcher) application Storage access framework for retrieving content and documents from other sources The Camera application now loads Google+ Photos instead of Gallery when swiping away from the camera view WebViews now based on Chromium engine (feature parity with Chrome for Android 30) Wireless printing capability The Hypori ACE Client is a thin client that installs on the end user s mobile device and communicates only with an ACE Device on an ACE Server and not with other servers or applications. Users access a virtual Android mobile device running on a secure server in the cloud. The operating system, the data, and the applications that users run all reside on the server not on the local device. As a result, these changes and updates from Android 4.3 to Android 4.4 do not affect the security functionality of the TOE and these two Android versions can be considered equivalent. 60

62 Equivalency Rationale Android 5.0 and Android 5.1 The TOE does not impose hardware requirements beyond Android operating system requirements. Therefore, the equivalency rationale will be based upon the differences in the Android operating systems. With respect to security functionality claimed in the security target, Android 5.0 and Android 5.1 can be considered equivalent. The ACE Client relies on the Android platform for TLS protection of communication with the ACE Server. All of the ciphersuites identified in the security target for Android 5.0 are included in the Android 5.1 version. As a result the ciphersuites can be considered equivalent. Below are the point-wise differences Between Android 5.0 and Android 5.1. added to Android 5.1. These features were Ability to join Wi-Fi networks and control paired Bluetooth devices from quick settings Support for multiple SIM cards Device protection: if a device is lost or stolen it will remain locked until the owner signs into their Google account, even if the device is reset to factory settings. Priority Mode alarm - in Priority Mode, users shut down audible notifications for a certain time period High-definition voice calls, available between compatible devices running Android 5.1 Improvements to the notification priority system, to more closely replicate the silent mode that was removed in Android5.0. Changes to the volume and interruptions sliders. New animations in Clock app Sticky soft keys fix NuPlayer is set as the default streaming player Memory leak fixed. Lock screen changes One swipe to unlock from lock screen Quick Settings The Hypori ACE Client is a thin client that installs on the end user s mobile device and communicates only with an ACE Device on an ACE Server and not with other servers or applications. Users access a virtual Android mobile device running on a secure server in the cloud. The operating system, the data, and the applications that users run all reside on the server not on the local device. As a result, these changes and updates from Android 5.0 to Android 5.1 do not affect the security functionality of the TOE and these two Android versions can be considered equivalent. Hypori Software Version Equivalency Rationale The CCTL tested the Hypori ACE Version demo. The demo version and the enterprise version are equivalent. The demo and enterprise versions of the Hypori ACE Client are built from the exact same source code base. There are absolutely no functional differences between the two versions. The package name and associated labels/icons that are required to be different by the Google Play Store have changed. 61

63 The reason for the demo version is to provide a way for Hypori s commercial customers to brand the Hypori ACE Client and then publish their branded enterprise client to the Google Play Store. Most of those same customers initially performed an evaluation of the Hypori ACE Client using the demo version from the Play Store before purchasing the product. The administrative guidance provides instructions for the customers to remove the demo version so there is not any end user confusion caused by having multiple Hypori ACE Clients installed on the same mobile device. Hypori customers want to control when their Hypori ACE Clients are upgraded to a new version. The requirements of the Google Play Store are that an app is uniquely identified by its package name and a monotonically increasing number - in this case the "62" part of " demo". If the Hypori ACE Client demo version and the enterprise version were not differentiated, then all customers' clients could be upgraded whenever Hypori publishes a new version of the client to the Play Store. For example, if Hypori publishes a " demo" version of the Hypori ACE Client to the Play Store, then all customers' clients could be updated to the 3.2 version of the client, eliminating the level of control desired by most customers. Updates and modifications to the Protection Profile for Application Software, Version 1.1, 5 November 2014 (PP APP SW) including DoD Annex for Protection Profile for Application Software v1.0, Version 1, Release 1 (DoD Annex), 22 October 2014are implemented through the NIAP Technical Decisions. The evaluation team reviewed the following Technical Decisions and implemented those that were applicable to the TOE. TD0024: Application Settings Clarification for FMT_MEC_EXT.1. This TD is not applicable to the TOE. The TD impacts the assurance activity on a Linux system. The TOE is installed on an Android platform. TD0025: Update to FCS_COP.1(2). This TD is not applicable to the TOE. FCS_COP.1(2) is not identified in the security target. TD0050: FMT_CFG_EXT.1.2 Change in APP SW PPv1.1. The TD corrects an Android command. The TD is applicable to the TOE. The test was executed with the updated command. TD0051: Android Implementation of TLS in App PP v1.1. The TD is applicable to the TOE. The TOE is installed on an Android platform. The Android implementation of TLS does not support certificate revocation checking. Rationale was identified and placed in the security target. TD0054: Clarification of FPT_API_EXT.1.1 Requirement in APP PP v1.1. The TD is applicable to the TOE. The evaluator shall verify that the TSS lists the platform APIs used in the application. The evaluator shall then compare the list with the supported APIs (available through e.g. developer accounts, platform developer groups) and ensure that all APIs listed in the TSS are supported. If any unsupported API's should be discovered the evaluator should review the TSS and verify that unsupported API calls are clearly documented along with a developer justification for why they must be used. The security target identifies the Android APIs used by the TOE in the Security Target Appendix 9. 62

64 TD0070: Assurance Activity Clarification for FCS_RGB_EXT.1 in Software Application PP. This TD is not applicable to the TOE. FCS_RGB_EXT.1.1 states that the application shall [use no DRBG functionality] for its cryptographic operations. TD0072: FIA_X509_EXT.1.1 Certificate Depth in App PP v1.1. This TD is not applicable to the TOE. The test involves the proper handling of revoked certificates. The TOE is installed on an Android platform in which TD0051 applies which identifies that Android does not support certificate revocation checking. TD0073: Additional Option to meet FPT_TUD_EXT.1.2 in App PP v1.1. This TD is not applicable to the TOE. The TD addresses an update distribution via the Windows Application Software. The TOE is installed on an Android platform. 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 evaluator is 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) should be provided that the driver or tool will not adversely affect the performance of the functionality by the TOE and its platform. This also includes the configuration of the cryptographic engine to be used. The cryptographic algorithms implemented by this engine are those specified by this PP and used by the cryptographic protocols being evaluated (IPsec, TLS/HTTPS, SSH). The test plan describes the test platforms as the Hypori ACE Client installed on the following platforms: ACE Client App deployed on Samsung Galaxy S6 running Android 5.1 ACE Client App deployed on Samsung Galaxy S5 running Android 4.4 The AGD documentation was followed to install and setup the TOE on each platform. cryptographic configuration was required on the Hypori ACE Client to execute the tests. No A special test tool was implemented during testing to simulate the server and provide method to exercise the TOE Client and Android TLS functionality. The Common Criteria/ TLS-CC-Tool was provided by NIAP to test a TLS client for conformance to the TLS requirements as laid out by NIAP's Application Software Protection Profile. The Common Criteria/ TLS-CC-Tool is suitable for manipulating individual fields within TLS packets, as specified in the Test Assurance Activities. The Test Tool can be downloaded at 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, 63

65 the report would show a fail and pass result (and the supporting details), and not just the pass result. The testing and test results are located in the proprietary Hypori Virtual Mobile Infrastructure Platform Android Cloud Environment Client Common Criteria Test Report and Procedures, Version 1.0, Feb The test plan includes high level test objectives, procedures, and actual test results. 3.4 Class AVA: Vulnerability Assessment AVA_VAN.1 Assurance Activity The evaluator shall generate a report to document their findings with respect to this requirement. This report could physically be part of the overall test report mentioned in ATE_IND, or a separate document. The vulnerability assessment analysis is identified in the CCTL proprietary Hypori Virtual Mobile Infrastructure Platform Android Cloud Environment Client Common Criteria Assurance Test Report. The evaluator performs a search of public information to find vulnerabilities that have been found in similar applications with a particular focus on network protocols the application uses and document formats it parses. The evaluator shall also run a virus scanner with the most current virus definitions against the application files and verify that no files are flagged as malicious. The evaluator documents the sources consulted and the vulnerabilities found in the report. Test Objective: Examine the open source information to ensure the vulnerability analysis did not miss any well-known vulnerability. Test Procedure: Use the web site to ensure that all vulnerabilities pertaining to the TOE have been addressed. The search was conducted using the following terms: Hypori ACE Client ACE Cloud Android Cloud Environment Thin Client Actual Results: A public search for vulnerabilities that might affect the TOE was performed. The search results and analysis are presented below. Search Term: Hypori Identifier Description Analysis Conclusion 0 matching records. No CVE entry is applicable to the TOE. 64

66 Search Term: ACE Client Identifier Description Analysis Conclusion 3 matching records. No CVE entry is applicable to the TOE. Search Term: ACE Identifier Description Analysis Conclusion 106 matching records. No CVE entry is applicable to the TOE. Search Term: Cloud Identifier Description Analysis Conclusion 74 matching records. No CVE entry is applicable to the TOE. Search Term: Android Cloud Environment Identifier Description Analysis Conclusion 0 matching records. No CVE entry is applicable to the TOE. Search Term: Thin Client Identifier Description Analysis Conclusion 9 matching records. No CVE entry is applicable to the TOE. A virus scan was executed against the TOE application files. VirusScan Enterprise + AntiSpyware Enterprise 8.8. The virus scanner used was the McAfee 65

67 No virus or malware was detected. 66

68 2/16/2016 5:04:28 PM Engine version = /16/2016 5:04:28 PM AntiVirus DAT version = /16/2016 5:04:28 PM Number of detection signatures in EXTRA.DAT = None 2/16/2016 5:04:28 PM Names of detection signatures in EXTRA.DAT = None 2/16/2016 5:04:29 PM Scan Started LEIDOS-CORP\cumminsc On-Demand Scan 2/16/2016 5:04:31 PM Scan Summary LEIDOS-CORP\cumminsc Scan Summary 2/16/2016 5:04:31 PM Scan Summary LEIDOS-CORP\cumminsc Processes scanned : 0 2/16/2016 5:04:31 PM Scan Summary LEIDOS-CORP\cumminsc Processes detected : 0 2/16/2016 5:04:31 PM Scan Summary LEIDOS-CORP\cumminsc Processes cleaned : 0 2/16/2016 5:04:31 PM Scan Summary LEIDOS-CORP\cumminsc Boot sectors scanned : 0 2/16/2016 5:04:31 PM Scan Summary LEIDOS-CORP\cumminsc Boot sectors detected: 0 2/16/2016 5:04:31 PM Scan Summary LEIDOS-CORP\cumminsc Boot sectors cleaned : 0 2/16/2016 5:04:31 PM Scan Summary LEIDOS-CORP\cumminsc Files scanned : 1 2/16/2016 5:04:31 PM Scan Summary LEIDOS-CORP\cumminsc Files with detections: 0 67