Hypori Virtual Mobile Infrastructure Platform 4.1 Hypori Client (ios) Common Criteria Assurance Activities Report. Version 1.

Transcription

1 Hypori Virtual Mobile Infrastructure Platform 4.1 Hypori Client (ios) Common Criteria Assurance Activities Report Version 1.0, August 17, 2018 Prepared by: Leidos Inc. 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: Intelligent Waves, LLC 1801 Robert Fulton Drive Suite 440 Reston, VA The TOE Evaluation was Sponsored by: Intelligent Waves, LLC 1801 Robert Fulton Drive Suite 440 Reston, VA Evaluation Personnel: Greg Beaver Pascal Patin 1

3 Common Criteria Versions 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.2, 22 April 2016 including DoD Annex for Protection Profile for Application Software v1.2, Version 1 Release 1, 21 February The following NIAP Technical Decisions apply to the Security Target and evaluation assurance activities. o TD0238 User-modifiable files FTP_AEX_EXT.1.4 o TD0217 Compliance to RFC5759 and RFC5280 for using CRLs o TD0192 Update to FCS_STO_EXT.1 Application Note o TD0178 Integrity for installation tests in AppSW PP o TD0174 Optional Ciphersuites for TLS o TD0172 Additional APIs added to FCS_RBG_EXT.1.1 o TD0163 Update to FCS_TLSC_EXT.1.1 Test 5.4 and FCS_TLSS_EXT.1.1 Test o TD0119 FCS_STO_EXT.1.1 in PP_APP_v1.2 o TD0107 FCS_CKM - ANSI X , Section 4.1.for Cryptographic Key Generation o TD0221: FMT_SMF Assignments moved to Selections o TD0244: FCS_TLSC_EXT - TLS Client Curves Allowed o TD0268: FMT_MEC_EXT.1 Clarification o TD0283: Cipher Suites for TLS in SWApp v1.2 o TD0295: Update to FPT_AEX_EXT.1.3 Assurance Activities o TD0300: Sensitive Data in FDP_DAR_EXT.1 o TD0304: Update to FCS_TLSC_EXT.1.2 o TD0305: Handling of TLS connections with and without mutual authentication o TD0327: Default file permissions for FMT_CFG_EXT.1.2 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 TLS Client Protocol FCS_TLSC_EXT.1.2 TLS Client Protocol FCS_TLSC_EXT.1.3 TLS Client Protocol FCS_TLSC_EXT.2.1 TLS Client Protocol FCS_TLSC_EXT.4 TLS Client Protocol User Data Protection (FDP) FDP_DEC_EXT.1 Access to Platform Resources FDP_NET_EXT.1 Network Communications 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 Privacy (FPR) FPR_ANO_EXT.1 User Consent for Transmission of Personally Identifiable Information Protection of the TSF (FPT)

5 2.6.1 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) FTP_DIT_EXT.1 Protection of Data in Transit Security Assurance Requirements Class ADV: Development ADV_FSP.1 Basic Functional Specification Class AGD: Guidance Documents AGD_OPE.1 Operational User Guidance AGD_PRE.1 Preparative Procedures 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 4.1 Hypori Client (ios) 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 4.1 Hypori Client (ios) Security Target, Version 4.1, August 14, 2018 [USER_CC] Hypori User Guide Common Criteria Configuration and Operation - Version 4.1 [USER_GUIDE] Hypori User Guide, Version 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 ST states that the application shall use no DRBG functionality for its cryptographic operations. Therefore the FCS_RBG_EXT.2 elements are not included in the ST. ST Section FCS_RBG_EXT.1 states that: The Hypori Client relies on the platform for cryptographic services. Consequently, the Hypori Client itself uses no DRBG functions. 5

7 2.1.2 FCS_CKM_EXT.1 Cryptographic Key Generation Services 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. [ST] Section states that the Hypori Client does not generate cryptographic keys. As part of installation, a user adds a Hypori server TLS client certificate and key to the platform s key store. The Hypori Client relies on the platform for TLS support. The platform generates all ephemeral TLS keys without direct Hypori Client action. 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 ios: The evaluator shall verify that all credentials are stored within a Keychain. [ST] Section FCS_STO_EXT.1 identifies and describes the Hypori Client persistent credentials and how the client stores each credential. The Hypori Client persistent credentials are identified as the following: User TLS client key - Authenticates Hypori client when establishing TLS connection to Hypori Server Server account password - Authenticates user to Hypori Server The TSS states that both the user TLS client key and the server account password are stored in the ios Keychain. 6

8 2.1.4 FCS_TLSC_EXT.1 TLS Client Protocol FCS_TLSC_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, FCS_TLSC_EXT.2, FCS_TLSC_EXT.4 identifies the ciphersuites that the Hypori Client supports. 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. [USER_CC] Section 3 Guidance Documentation states that Intelligent Wave s Hypori Client applies in the evaluated configuration along with this Common Criteria specific guidance. The general guidance covers ios versions 10.0, 10.1, 10.2, and 10.3, and there is no version-specific configuration. Cipher suites are determined by choice of ios version, not the Hypori Client configuration. [USER_CC] Section 8 Reference Identifier for TLS states that as part of setting up a new account on the Hypori Client, a user may receive enrollment instructions from the Hypori administrator. These instructions may come in the form of a web page or and contain a link to the Hypori User Provisioning service. The user is provided with a QR code, a One-Time Password (OTP), or a deep link that is presented to the Hypori Provisioning service to automate several account-creation steps. [USER_CC] Section 7 Provisioning of Hypori Client Credentials states that the 4.1 version of the Hypori Client does not create credentials. When using the Add Account with QR code or OTP options or a provisioning deep-link, the Hypori Client acquires the user s credentials from the Hypori provisioning server and installs it into the ios keychain on the mobile device and directs the Hypori Client s user to name the account to associate it with the installed credential. ios provides the Secure Enclave for secure storage of cryptographic keys using the ios Keychain APIs. Unlike Android, the ios keychain cannot be shared by non-apple applications, thus each application can only access their own keys. The Hypori Client for ios supports the following means to get the user s credentials into the ios keychain for its use: The Hypori Client can contact the Hypori provisioning portal and download the user s credentials and install them into the ios keychain. The Hypori Provisioning Portal is described in the Acquiring a Client Certificate topic in the Hypori User Guide Version 4.1 product documentation. The Hypori Client can also import credentials from a.p12 Document Provider using the ios Document Provider Extension and install them into the ios keychain. An administrator can manually install the user s credentials into the Hypori Client s data storage 7

9 by downloading a.p12 file using a USB cable connected to a provisioning laptop running Apple s itunes. The admin must then configure the Hypori Client to import the credentials into the ios keychain Test Assurance Activities The evaluator shall also perform the following tests: Test 1: The evaluator shall establish a TLS connection using each of the cipher suites 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 cipher suite 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 cipher suite being used (for example, that the cryptographic algorithm is 128-bit AES and not 256-bit AES). The evaluator configured the server to only use TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256. The evaluator ran a Wireshark capture and attempted to connect to the server through the Hypori Client application. The evaluator reviewed the packet capture and verified that the TLS connection was established successfully and TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 was used. The evaluator repeated the process for each remaining ciphersuite. All of the ciphersuites claimed in the ST successfully established a TLS connection. 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. The evaluator ran a Wireshark capture and attempted to connect to the server through the Hypori 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. Test 3: The evaluator shall send a server certificate in the TLS connection that does not match the server-selected cipher suite (for example, send a ECDSA certificate while using the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite or send a RSA certificate while using one of the ECDSA cipher suites.) The evaluator shall verify that the TOE disconnects after receiving the server s 8

10 Certificate handshake message. The evaluator configured the server to present an ECDSA certificate after selecting TLS_RSA_WITH_AES_128_CBC_SHA. The evaluator ran a Wireshark capture and attempted to connect to the server through the Hypori 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. 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. The evaluator ran a Wireshark capture and attempted to connect to the server through the Hypori 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 TLS connection failed after the server selects the TLS_NULL_WITH_NULL_NULL ciphersuite. 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 Hypori Client application. The evaluator reviewed the packet capture and verified that the TLS connection was dropped after the device received the invalid TLS version. 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 9

11 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. Updated per NIAP TD0163: Update to FCS_TLSC_EXT.1.1 Test 5.4 and FCS_TLSS_EXT.1.1 Test The below tests for FCS_TLSC_EXT.1.1 and FCS_TLSS_EXT.1.1 can only be performed for ciphersuites that utilize Diffie Hellman. These tests should be conditional and only required when a ciphersuite that utilizes Diffie Hellman is claimed by a Security Target. The evaluator shall perform the following modifications to the traffic: Test 5.4: (conditional): If an ECDHE or DHE ciphersuite is selected, 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 the ChangeCipherSpec message. The evaluator ran a Wireshark capture and attempted to connect to the server through the Hypori 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. 10

12 2.1.5 FCS_TLSC_EXT.1.2 TLS Client Protocol 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, FCS_TLSC_EXT.2, FCS_TLSC_EXT.4 states that the Hypori Client relies on the platform for TLS protection of communication with the Hypori server. This includes providing the TLS client certificate to authenticate the client to the server. Hypori Client establishes the reference identifier using the configured server host name. The Hypori Client validates the first CN and the subject alternative names against the configured reference identifier. 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. [USER_CC] Section 8 Reference Identifier for TLS provides the guidance for setting the reference identifier to be used for the purposes of certificate validation in TLS. As part of setting up a new account on the Hypori Client, a user may receive enrollment instructions from the Hypori administrator. These instructions may come in the form of a web page or and contain a link to the Hypori User Provisioning service. The user is provided with a QR code, a One- Time Password (OTP), or a deep link that is presented to the Hypori Provisioning service to automate several account-creation steps. The provisioning service provides the server hostname, port, and the user s client certificate to the Hypori Client and it generates and installs the client certificate for the account as described in section 7. Alternatively, the account information, including the certificate, can be configured manually by the user or administrator. See the Setting Up an Account topic in the Hypori User Guide Version 4.1 for detailed instructions. The hostname of the server and the client certificate association provided by the provisioning server (or manually provided by the user or administrator) is saved as an account. The account represents the linkage between the user of the client and the particular Hypori server. The server certificate returned when connecting to the Hypori server includes the reference identifier associated with its DNS name and is validated against the hostname as required by the protection profile. The reference identifier in the client certificate is chosen by the administrator from one of several fields in the certificate during server configuration. When the client certificate is presented to the Hypori server, it is validated and the reference identifier is extracted and used to authenticate the user Test Assurance Activities 11

13 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. 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. The connection was rejected. A network capture verified that the connection was terminated by the application and that no application data was sent. Updated per NIAP TD0304: Update to FCS_TLSC_EXT.1.2 Test 3: [conditional]: If the TOE does not mandate the presence of the SAN extension, 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. If the TOE does mandate the presence of the SAN extension, this Test shall be omitted. 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 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 12

14 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 verified that the connection failed. 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. A Wireshark packet capture verified that the connection failed. 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 configured the reference identifier with a single leftmost label (e.g. foo.com). A Wireshark capture verified that the connection the connection failed. The evaluator then configured the reference identifier with two leftmost labels (e.g. foo.tlstest.ccmdpp.com) and verified that the connection failed. 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. The test is not applicable. Hypori Client establishes the reference identifier using the configured server host name. Hypori 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 13

15 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 TLS Client Protocol 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 demonstrated that validating a certificate without a valid certification path results in the connection failing. For this test a chain of one root CA, two intermediate CAs and one leaf server certificate were used. The test initially demonstrated than when the TOE had the root CA but no intermediate CAs the connection failed. Providing the TOE with the root CA and both intermediate CAs resulted in the connection being accepted. After that the bottom level intermediate CA was removed and the connection was rejected again FCS_TLSC_EXT.2.1 TLS Client Protocol TSS Assurance Activities The evaluator shall ensure that the TSS description required per FIA_X509_EXT.2.1 includes the use of client-side certificates for TLS mutual authentication. [ST] Section FCS_TLSC_EXT.2 states that The Hypori Client establishes the reference identifier using the configured server host name. The Hypori Client validates the first CN and the subject alternative names against the configured reference identifier. [ST] Section FIA_X509_EXT.2 states that the Hypori Client presents the TLS client certificate and key to the Hypori 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 certificate store. The user can change the selection from Client Certificate under Connection on the Settings page. The TLS client certificate is an X.509 certificate. 14

16 The Hypori Client uses the ios platform certificate path validation services with the CA certificate to validate the certificate presented by the Hypori server. The Hypori Client enables the ios services to use OCSP to determine the revocation status and is configured to fail the connection if the certificate is revoked or the connection to the OCSP responder fails 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. [USER_CC] Section 7 Provisioning of Hypori Client Credentials, provides the instructions to install associated certificates. [USER_GUIDE] Section Acquiring a Certificate, provides the instructions how to acquire a certificate for the Hypori Client Test Assurance Activities Updated per NIAP TD0305: Handling of TLS connections with and without mutual authentication Test 1: The evaluator shall establish a connection to a peer server that is not configured for mutual authentication (i.e. does not send Server s Certificate Request (type 13) message). The evaluator observes negotiation of a TLS channel and confirms that the TOE did not send Client s Certificate message (type 11) during handshake. The evaluator attempted to establish a connection from the TOE to a TLS server that was not configured for mutual authentication. A wire capture of the connection attempt showed that the TOE did not send a client certificate when it did not receive a Certificate Request message from the server. Updated per NIAP TD0305: Handling of TLS connections with and without mutual authentication Test 2: The evaluator shall establish a connection to a peer server with a shared trusted root that is configured for mutual authentication (i.e. it sends Server s Certificate Request (type 13) message). The evaluator observes negotiation of a TLS channel and confirms that the TOE responds with a nonempty Client s Certificate message (type 11) and Certificate Verify (type 15) message. The evaluator attempted to establish a connection from the TOE to a TLS server that was configured for mutual authentication. A wire capture of the connection attempt showed that the TOE did send a client certificate when it received a Certificate Request message from the server FCS_TLSC_EXT.4 TLS Client Protocol 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.4 states that for elliptic curve cipher suites, the Hypori Client relies on the platform for elliptic curves. The ios platforms support NIST curves secp256r1, secp384r1, and secp521r1 and Supported Elliptic Curves Extension for TLS. No configuration is required by a Hypori Client user. 15

17 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 Modified per TD0244: FCS_TLSC_EXT - TLS Client Curves Allowed The evaluator shall also perform the following tests: Test 1: The evaluator shall configure a server to perform ECDHE key exchange using each of the TOE s supported curves and shall verify that the TOE successfully connects to the server. The evaluator established test connections from the TOE to TLS test servers that were each configured to use one of the curves claimed by the TOE. Wire captures of the connection attempts showed that the TOE could connect successfully using each of the claimed curve. 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 perform the platform-specific actions below and inspect user documentation to determine the application's access to hardware resources. The evaluator shall ensure that this is consistent with the selections indicated. The evaluator shall review documentation provided by the application developer and for each resource which it accesses, identify the justification as to why access is required. For ios: The evaluator shall verify that either the application or the documentation provides a list of the hardware resources it accesses. [USER_CC] Section 4.2 ios Permissions, identifies the required permissions for the Hypori ios client to access the mobile device s features and services: The following permissions are requested after the Client app is launched: Camera 16

18 Location Microphone Photo Library Notifications A brief summary that describes how these ios permissions are used is provided in [USER_CC] Test Assurance Activity The evaluator shall perform the platform-specific actions below and inspect user documentation to determine the application's access to hardware resources. The evaluator shall ensure that this is consistent with the selections indicated. The evaluator shall review documentation provided by the application developer and for each resource which it accesses, identify the justification as to why access is required. For ios: The evaluator shall verify that either the application or the documentation provides a list of the hardware resources it accesses. The evaluator verified that the application requested permission to access platform resources (both hardware and information repositories) before installing. The hardware resources the TOE wishes to access are listed on the TOE s ios Settings page FDP_DEC_EXT TSS Assurance Activities Guidance Assurance Activities The evaluator shall perform the platform-specific actions below and inspect user documentation to determine the application's access to sensitive information repositories. The evaluator shall ensure that this is consistent with the selections indicated. The evaluator shall review documentation provided by the application developer and for each sensitive information repository which it accesses, identify the justification as to why access is required. For ios: The evaluator shall verify that either the application software or its documentation provides a list of the sensitive information repositories it accesses. [USER_CC] Section 1.1 Hypori VMI System Overview, states that the Hypori system is a Virtual Mobile Infrastructure (VMI) platform. Users running the Hypori Client on their mobile devices access Hypori Virtual Devices, which are virtual Android devices running on a server in the cloud. The Virtual Device contains the operating system, data, and applications, and it uses TLS 1.2 encryption to communicate securely with the Hypori Client. 17

19 Therefore the Hypori ios Client does not store data in any sensitive information repositories Test Assurance Activities The evaluator shall perform the platform-specific actions below and inspect user documentation to determine the application's access to sensitive information repositories. The evaluator shall ensure that this is consistent with the selections indicated. The evaluator shall review documentation provided by the application developer and for each sensitive information repository which it accesses, identify the justification as to why access is required. For ios: The evaluator shall verify that either the application software or its documentation provides a list of the sensitive information repositories it accesses. The evaluator verified that the application requested permission to access platform resources before installing. The information repositories the TOE wishes to access are listed in the TOE s ios Settings page FDP_NET_EXT.1 Network Communications FDP_NET_EXT TSS Assurance Activities None defined Guidance Assurance Activities Test Assurance Activities 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 Hypori Server. Network captures verified that the only network communication seen is the user initiated communication to the Hypori 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. 18

20 2.2.3 FDP_DAR_EXT.1 Encryption of Sensitive Application Data FDP_DAR_EXT TSS Assurance Activities Modified per TD0300: Sensitive Data in FDP_DAR_EXT.1 The evaluator shall examine the TSS to ensure that it describes the sensitive data processed by the application. The evaluator shall then ensure that the following activities cover all of the sensitive data identified in the TSS. Assurance activities (after the identification of the sensitive data) are to be performed on all sensitive data listed that are not covered by FCS_STO_EXT.1. The evaluator shall inventory the filesystem 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 filesystem to note where data was stored (if any), and determine whether it has been encrypted. For ios: The evaluator shall inspect the TSS and ensure that it describes how the application uses the Complete Protection, Protected Unless Open, or Protected Until First User Authentication Data Protection Class for each data file stored locally. [ST] Section FDP_DAR_EXT.1 states that the Hypori Client sensitive data consist of user TLS client key and server account password credentials. FCS_STO_EXT.1 Storage of Secrets specifies the platform s ios keychain for protecting keys and credentials. In accordance with FCS_STO_EXT.1, the Hypori Client stores these credentials in the platform s ios keychain as described in [ST] section The Hypori Client stores application account options and any cached configuration settings (such as the server s hostname, port, notification properties, and settings to control the client application s behavior for disconnecting, keyboard, access to phone features, and jailbreak checking) provided by the Hypori Server using the ios Protected Until First User Authentication protection class Guidance Assurance Activities Test Assurance Activity 2.3 Identification and Authentication (FIA) 19

21 2.3.1 FIA_X509_EXT.1 X.509 Certificate Validation FIA_X509_EXT 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 ios platform performs certification path validation as part of the TLS service. The Hypori Client relies on the platform for TLS services and package updates. Hence, the platform checks extended key usage for Server Authentication, Client Authentication, and Code Signing purposes. The ios platform performs certification path validation as part of the TLS service. The platform certificate path methodology to manage X.509 certificate trust evaluation is described in the following document: TS CH1-SECTRUSTEVALUATIONFUNDAMENTALS 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. If the application supports chains of length four or greater, the evaluator shall create a chain of at least four certificates: the node certificate to be tested, two Intermediate CAs, and the self-signed Root CA. If the application supports a maximum trust depth of two, then a chain with no Intermediate CA should instead be created. 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. This test was performed in conjunction with testing for FCS_TLSC_EXT.1.3. The evaluator demonstrated that validating a certificate without a valid certification path results in the connection failing. For this test a chain of one root CA, two intermediate CAs and one leaf server certificate were used. The test initially demonstrated than when the TOE had the root CA but no intermediate CAs the connection failed. Providing the TOE with the root CA and both intermediate CAs 20

22 resulted in the connection being accepted. After that the bottom level intermediate CA was removed and the connection was rejected again. 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. If the application supports chains of length four or greater, the evaluator shall create a chain of at least four certificates: the node certificate to be tested, two Intermediate CAs, and the self-signed Root CA. If the application supports a maximum trust depth of two, then a chain with no Intermediate CA should instead be created. Test 2: The evaluator shall demonstrate that validating an expired certificate results in the function failing. The TLS connection fails after receiving the expired server certificate. Network captures verified the failed connection and error message was displayed by the TOE to notify of an expired 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. If the application supports chains of length four or greater, the evaluator shall create a chain of at least four certificates: the node certificate to be tested, two Intermediate CAs, and the self-signed Root CA. If the application supports a maximum trust depth of two, then a chain with no Intermediate CA should instead be created. Test 3: The evaluator shall test that the TOE can properly handle revoked certificates- conditional on whether CRL, OCSP, or OCSP Stapling is selected; if multiple methods are selected, then the following tests shall be performed for each method: The evaluator shall test revocation of the node certificate. The evaluator shall also test revocation of an intermediate CA certificate (i.e. the intermediate CA certificate should be revoked by the root CA), if intermediate CA certificates are supported. 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. The evaluator demonstrated that the TOE could successfully connect to a server whose certificate had not been revoked by OCSP, and would not connect to a server whose certificate had been revoked. 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. If the application supports chains of length four or greater, the evaluator shall create a chain of at least four certificates: the node certificate to be tested, two Intermediate CAs, and the self-signed Root CA. If the application supports a maximum trust depth of two, then a chain with no Intermediate CA should instead be 21

23 created. 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. The evaluator configured an OCSP responder to present a certificate that did not have the OCSP signing purpose. The TOE rejected the OCSP responder s response due to the invalid 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. If the application supports chains of length four or greater, the evaluator shall create a chain of at least four certificates: the node certificate to be tested, two Intermediate CAs, and the self-signed Root CA. If the application supports a maximum trust depth of two, then a chain with no Intermediate CA should instead be created. 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 modified a byte in the first eight bytes of the certificate and demonstrated that the certificate fails to validate. A network 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. If the application supports chains of length four or greater, the evaluator shall create a chain of at least four certificates: the node certificate to be tested, two Intermediate CAs, and the self-signed Root CA. If the application supports a maximum trust depth of two, then a chain with no Intermediate CA should instead be created. 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 TLS connection failed when the last byte of the server s certificate was modified. A review of the packet capture verified that the connection failed after receiving the modified server certificate. An authentication error message was displayed by the TOE. 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. If the application supports chains of length four or greater, the evaluator shall create a chain of at least four certificates: the node certificate to be tested, two Intermediate CAs, and the self-signed Root CA. If the application 22