Assurance Activity Report (AAR) for a Target of Evaluation

Transcription

1 Assurance Activity Report (AAR) for a Target of Evaluation Cisco Jabber for Android and iphone/ipad Version 11.7 Security Target Version.9, March 2017 Protection Profile for Voice Over IP (VoIP) Applications version 1.3 AAR Version 1.5, March 2017 Evaluated by: Office Park Dr. Montgomery Village, MD Prepared for: National Information Assurance Partnership Common Criteria Evaluation and Validation Scheme 1

2 The Developer of the TOE: Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA The Author of the Security Target: Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA The TOE Evaluation was Sponsored by: Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA Evaluation Personnel: W. Dean Freeman, CISSP, GCIH Pascal Patin, CISSP Common Criteria Version Common Criteria Version 3.1 Revision 4 Common Evaluation Methodology Version CEM Version 3.1 Revision 4 2

3 Contents 1 TOE Overview Assurance Activities Identification Test Equivalency Justification Chosen Testing Subset Architectural Description of the TOE Differences Between Models of the TOE Test Subset Justification/Rationale Test Diagram Test Diagram (iphone Testbed #1) Configuration Information (iphone Testbed #1) Test Diagram (iphone Testbed #2) Configuration Information (iphone Testbed #2) Test Diagram (iphone Testbed #3) Configuration Information (iphone Testbed #3) Test Diagram (Android Testbed #1) Configuration Information (Android Testbed #1) Test Diagram (Android Testbed #2) Configuration Information (Android Testbed #2) Test Diagram (Android Testbed #3) Configuration Information (Android Testbed #3) Detailed Test Cases Cryptographic Support (FCS) FCS_CKM_EXT.2.1(1) TSS FCS_SRTP_EXT.1 TSS FCS_SRTP_EXT.1 Test FCS_CKM.1.1(1) Met By TOE, Test #1, RSA Key Generation FCS_CKM.1.1(1) Met By TOE, B Key Establishment Schemes, TSS FCS_CKM.1.1(2) Met By TOE, TSS FCS_CKM_EXT.4.1 Met By Platform, TSS FCS_CKM_EXT.4.1 Met By Platform, TSS FCS_CKM_EXT.4.1 Met By TOE, TSS

4 FCS_CKM_EXT.4.1 Met By TOE, Test FCS_COP.1.1(1) Met By TOE, Test #1, AES-CBC KAT FCS_COP.1.1(1) Met By TOE, Test #2, AES-CBC KAT FCS_COP.1.1(1) Met By TOE, Test #3, AES-CBC KAT FCS_COP.1.1(1) Met By TOE, Test #4, AES-CBC KAT FCS_COP.1.1(1) Met By TOE, Test #5, AES-CBC Multi- Block Message Test FCS_COP.1.1(1) Met By TOE, Test #6, AES-CBC Monte Carlo Test FCS_COP.1.1(1) Met By TOE, Test #7, AES-GCM Monte Carlo Test FCS_COP.1.1(1) Met By Platform, TSS FCS_COP.1.1(2) Met By Platform, TSS FCS_COP.1.1(3) Met By TOE, Test #1, Short Message Test Bit Oriented Mode FCS_COP.1.1(3) Met By TOE, Test #2, Short Message Test Byte Oriented Mode FCS_COP.1.1(3) Met By TOE, Test #3, Selected Long FCS_COP.1.1(3) Met By TOE, Test #4, Selected Long Messages Test Byte Oriented Mode FCS_COP.1.1(3) Met By TOE, Test #5, Pseudorandomly Generated Messages Test FCS_COP.1.1(3) Met By Platform, TSS FCS_COP.1.1(4) Met By TOE, TSS FCS_COP.1.1(4) Met By TOE, TSS FCS_COP.1.1(4) Met By TOE, Test FCS_RBG_EXT.1 Met By Platform, TSS User Data Protection (FDP) FDP_VOP_EXT.1 TSS FDP_VOP_EXT.1 Test FDP_VOP_EXT.1 Test Identification and Authentication (FIA) FIA_SIPC_EXT.1 TSS FIA_SIPC_EXT.1 Test FIA_SIPC_EXT.1 Test FIA_SIPC_EXT.1 Test FIA_X509_EXT.1 TSS FIA_X509_EXT.1 Guidance

5 5.3.7 FIA_X509_EXT.1 Test FIA_X509_EXT.1 Test FIA_X509_EXT.1 Test FIA_X509_EXT.1 Test FIA_X509_EXT.1 Test FIA_X509_EXT.1 Test FIA_X509_EXT.2.2 TSS FIA_X509_EXT.2.2 TSS FIA_X509_EXT2.2 Test # FIA_X509_EXT.2.3 TSS FIA_X509_EXT.2.3 TSS FIA_X509_EXT.2.3 Test FIA_X509_EXT.2.3 Test FIA_X509_EXT.2.3 Test FIA_X509_EXT.2.3 Test FIA_X509_EXT.2.3 Test Security Management (FMT) FMT_SMF.1 Guidance Protection of the TSF (FPT) FPT_TUD_EXT.1.1 TSS FPT_TUD_EXT.1.1 Guidance FPT_TUD_EXT.1.1 Test FPT_TUD_EXT.1.3 TSS FPT_TUD_EXT.1.3 Test FPT_TUD_EXT.1.3 Test FPT_TST_EXT.1 TSS FPT_TST_EXT.1 TSS FPT_TST_EXT.1 Test FPT_TST_EXT.1 Test Trusted Path/Channels (FTP) FTP_ITC.1(1) TSS FTP_ITC.1(1) Guidance

6 5.6.3 FTP_ITC.1(1) Test FTP_ITC.1(1) Test FTP_ITC.1(1) Test FTP_ITC.1(1) Test FTP_ITC.1(2) TSS FTP_ITC.1(2) Test FTP_ITC.1(2) Test TLS (FCS_TLS) FCS_TLS_EXT.1 TSS FCS_TLS_EXT.1 TSS FCS_TLS_EXT.1 Guidance FCS_TLS_EXT.1 Test FCS_TLS_EXT.1 Test FCS_TLS_EXT.1 Test FCS_TLS_EXT.1 Test FCS_TLS_EXT.1 Test Security Assurance Requirements AGD: Guidance Documents AGD_OPE.1 Guidance AGD_OPE.1 Guidance AGD_OPE.1 Guidance AGD_PRE.1 Guidance AGD_PRE.1 Guidance AGD_PRE.1 Test ATE: Tests AVA: Vulnerability Assessment Scope Examination of Publicly Available Information ALC: Life-Cycle Support ALC_CMC Conclusion

7 7

8 Revision History: Version Date Changes Version 0.1 6/30/2016 Initial Draft Version /21/2016 Update to reflect ST changes Version /2/2016 Updated after QA review Version 1.1 1/5/2017 Updated in response to validator comments Version 1.2 2/16/2017 Updated based on validator comments Version 1.3 3/6/2017 Updated based on new algorithm certificates and comments Version 1.4 3/14/17 Updated based on comments Version 1.5 3/16/17 Updated based on final comments 8

9 1 TOE Overview Cisco Jabber for Android and iphone/ipad streamlines communications and enhances productivity by unifying presence, instant messaging, video, voice, voice messaging, screen sharing, and conferencing capabilities securely into one client on your desktop. Cisco Jabber for Android and iphone/ipad delivers highly secure, clear, and reliable communications. It offers flexible deployment models, is built on open standards, and integrates with commonly used desktop applications. The Cisco Jabber application is a soft phone with wideband and high-fidelity audio, standards based high-definition video (720p), and phone control features. These features mean that highquality and high-availability voice and video telephony is available on users mobile devices. The TOE is software-only comprised of the Jabber mobile application release

10 2 Assurance Activities Identification The following table identifies each of the Assurance Activities executed for this evaluation. Test Case ID Activity Type Verdict FCS_CKM_EXT.(2)1 TSS 1 TSS FCS_SRTP_EXT.1 TSS 1 TSS FCS_SRTP_EXT.1 Test 1 Testing FDP_VOP_EXT.1 TSS 1 TSS FDP_VOP_EXT.1 Test 1 Testing FDP_VOP_EXT.1 Test 2 Testing FIA_SIPC_EXT.1 TSS 1 TSS FIA_SIPC_EXT.1 Test 1 Testing FIA_SIPC_EXT.1 Test 2 Testing FIA_SIPC_EXT.1 Test 3 Testing FMT_SMF.1 Guidance 1 Guidance FPT_TUD_EXT.1 TSS 1 TSS FPT_TUD_EXT.1 Test 1 Testing FTP_ITC.1(1) TSS 1 TSS FTP_ITC.1(1) Guidance 1 Guidance FTP_ITC.1(1) Test 1 Testing FTP_ITC.1(1) Test 2 Testing FTP_ITC.1(1) Test 3 Testing FTP_ITC.1(1) Test 4 Testing FCS_CKM.1(1) (Met by TOE) RSA Test Testing FCS_CKM.1(1) (Met by TOE) B TSS 1 TSS FCS_CKM.1(2) (Met by TOE) TSS 1 TSS FCS_CKM_EXT.4 (Met by platform) TSS 1 TSS FCS_CKM_EXT.4 (Met by TOE) TSS 1 TSS FCS_CKM_EXT.4 (Met by TOE) Test 1 Testing FCS_COP.1(1) (Met by TOE) AES-CBC KAT-1 Testing FCS_COP.1(1) (Met by TOE) AES-CBC KAT-2 Testing FCS_COP.1(1) (Met by TOE) AES-CBC KAT-3 Testing FCS_COP.1(1) (Met by TOE) AES-CBC KAT-4 Testing FCS_COP.1(1) (Met by TOE) AES-CBC Multi- Testing Block Message Test FCS_COP.1(1) (Met by TOE) AES-CBC Monte Testing Carlo Test FCS_COP.1(1) (Met by TOE) AES-GCM Monte Testing Carlo Test FCS_COP.1(2) (Met by TOE) RSA Key Testing Generation Test FCS_COP.1(2) (Met by TOE) FIPS Key Testing Generation Test FCS_COP.1(2) (Met by TOE) PKV Test Testing FCS_COP.1(2) (Met by TOE) CDSA FIPS Testing Signature Generation Test FCS_COP.1(2) (Met by TOE) ECDSA FIPS Testing Signature Verification Test FCS_COP.1(2) (Met by TOE) RSA Signature Generation Test Testing 10

11 Test Case ID Activity Type Verdict FCS_COP.1(2) (Met by TOE) RSA Signature Testing Verification Test FCS_COP.1(3) (Met by TOE) Short Message Testing Test Bit Oriented Mode FCS_COP.1(3) (Met by TOE) Short Message Testing Test Byte Oriented Mode FCS_COP.1(3) (Met by TOE) Selected Long Testing Messages Test Bit Oriented Mode FCS_COP.1(3) (Met by TOE) Selected Long Testing Messages Test Byte Oriented Mode FCS_COP.1(3) (Met by TOE) Pseudorandomly Testing Generated Messages Test FCS_COP.1(4) (Met by TOE) TSS 1 TSS FCS_COP.1(4) (Met by TOE) TSS 2 TSS FCS_COP.1(4) (Met by TOE) Test 1 Testing FCS_RBG_EXT.1 (Met by platform) TSS 1 TSS FCS_TLS_EXT.1 TSS 1 TSS FCS_TLS_EXT.1 TSS 2 TSS FCS_TLS_EXT.1 Test 1 Testing FCS_TLS_EXT.1 Test 2 Testing FCS_TLS_EXT.1 Test 3 Testing FCS_TLS_EXT.1 Test 4 Testing FCS_TLS_EXT.1 Test 5 Testing FIA_X509_EXT.1 TSS 1 TSS FIA_X509_EXT.1 Guidance 1 Guidance FIA_X509_EXT.1 Test 1 Testing FIA_X509_EXT.1 Test 2 Testing FIA_X509_EXT.1 Test 3 Testing FIA_X509_EXT.1 Test 4 Testing FIA_X509_EXT.1 Test 5 Testing FIA_X509_EXT.1 Test 6 Testing FIA_X509_EXT.2.2 TSS 1 TSS FIA_X509_EXT.2.2 TSS 2 TSS FIA_X509_EXT.2.2 Test 1 Testing FIA_X509_EXT.2.3 TSS 1 TSS FIA_X509_EXT.2.3 TSS 2 TSS FIA_X509_EXT.2.3 Test 1 Testing FIA_X509_EXT.2.3 Test 2 Testing FIA_X509_EXT.2.3 Test 3 Testing FIA_X509_EXT.2.3 Test 4 Testing FIA_X509_EXT.2.3 Test 5 Testing FMT_SMF.1 Guidance 1 Guidance FPT_TST_EXT.1 TSS 1 TSS FPT_TST_EXT.1 TSS 2 TSS FPT_TST_EXT.1 Test 1 Testing FPT_TST_EXT.1 Test 2 Testing FPT_TUD_EXT.1 TSS 1 TSS FPT_TUD_EXT.1 Test 1 Testing FPT_TUD_EXT.1 Test 2 Testing 11

12 Test Case ID Activity Type Verdict FTP_ITC.1(2) TSS 1 TSS FTP_ITC.1(2) Test 1 Testing FTP_ITC.1(2) Test 2 Testing 12

13 3 Test Equivalency Justification 3.1 Chosen Testing Subset The TOE is a software only TOE without any different hardware models. The TOE was tested on the following OSs. Apple ios 9, Android Architectural Description of the TOE The TOE is comprised of a single client application that delivers business-quality voice and video to your mobile device. The Cisco Jabber primary features include the following: Communication integration - a single, intuitive interface for instant messaging with individuals and groups, IP telephony, visual voic , voice and web conferencing, desktop sharing, chat history, and integrated directories. Integrated voice and video telephony - Make, receive, and control phone calls with a variety of call-control options are available, including mute, call transfer, call forwarding, and impromptu conferencing. Presence - View real-time availability of co-workers and colleagues within the enterprise network. Enterprise instant messaging - Chat in real time using instant messaging to save time and reduce phone tag. Encryption - Encrypt instant messaging communications using up to 256-bit Advanced Encryption Standard (AES) encryption and Transport Layer Security/Secure Sockets Layer (TLS/SSL) connections. Enterprise policy management - Set granular policies to determine which features and capabilities your Cisco Jabber end users can or cannot access. The deployment scenario is on in which you set up, manage, and maintain all services on your corporate network. The Cisco Jabber can be deployed in the following modes: Full UC - deploy full UC mode, enable instant messaging and presence capabilities, provision voic and conferencing capabilities, and provision users with devices for audio and video. IM-Only - deploy IM-only mode, enable instant messaging and presence capabilities. Do not provision users with devices. Phone Mode - In Phone mode, the user's primary authentication is to Cisco Unified Communications Manager. To deploy phone mode, provision users with devices for audio and video capabilities. You can also provision users with additional services such as voic . 13

14 In the evaluated configuration, the TOE will use the on-premises deployment scenario that is one in which the Administrator set ups, manages, and maintains all services on the corporate network. In addition, the TOE will be deployed in Phone Mode. In Phone mode, the end-user's primary authentication is to the SIP Server, Cisco Unified Communications Manager (CUCM). In this deployment, the Administrator provision users with devices for audio and video capabilities. The Administrator can also provision users with additional services such as voic . Note in the evaluated configuration, video capabilities are not evaluated or tested. 3.3 Differences Between Models of the TOE This has been addressed by a separate equivalency document, Cisco Jabber for Android and iphone/ipad v11.7 Software Equivalency Rationale. 3.4 Test Subset Justification/Rationale This has been addressed by a separate equivalency document, Cisco Jabber for Android and iphone/ipad v11.7 Software Equivalency Rationale. 14

15 4 Test Diagram 4.1 Test Diagram (iphone Testbed #1) 4.2 Configuration Information (iphone Testbed #1) TOE #1: SW version: Cisco Jabber 11.7 TOE Platform #1 HW version: iphone 6 SW version: ios IP address: Infrastructure Platform: OS version: Windows 10 Professional x64 Hypervisor version: VMWare Workstation Professional 12 TLS Server/CUCM simulator: OS version: Kali Linux IP address: Configuration Details: OpenSSL for certificate creation, and to act as a server for cert tests AcumenTLS fork of NIAP s TLS test tool for other TLS/cert tests 15

16 DNS Server: OS version: FreeBSD 10.3 IP Address: Configuration Details: BIND for providing DNS services to the TOE platform OCSP/CRL Server: OS version: Fedora 22 IP Address: Configuration Details: OpenCA s OCSPD for OCSP responder Apache HTTPD for providing CRL distribution point 4.3 Test Diagram (iphone Testbed #2) 4.4 Configuration Information (iphone Testbed #2) TOE #1: SW version: Cisco Jabber 11.7 TOE Platform #1 HW version: iphone 6 SW version: ios IP address: Infrastructure Platform: HW version: Cisco UCS 16

17 Hypervisor: VMWare ESXi CUCM1: IP Address: Software Version: CUCM2: IP Address: Software Version: DNS Server: OS Version: Windows Server 2012R2 IP Address: Test Diagram (iphone Testbed #3) 4.6 Configuration Information (iphone Testbed #3) TOE #1: HW version: SW version: Cisco Jabber

18 TOE Platform #1 HW version: iphone 6 SW version: ios IP address: Test Diagram (Android Testbed #1) 4.8 Configuration Information (Android Testbed #1) TOE #1: SW version: Cisco Jabber 11.7 TOE Platform #1 HW version: Samsung Galaxy S7 SW version: Android 6 IP address (a): IP Address (b): Configuration Information: The Common Criteria mode package was installed to facilitate CRL fetching Infrastructure Platform: OS version: Windows 10 Professional x64 18

19 Hypervisor version: VMWare Workstation Professional 12 TLS Server/CUCM simulator: OS version: Kali Linux IP address (a): IP Address (b): Configuration Details: OpenSSL for certificate creation, and to act as a server for cert tests AcumenTLS fork of NIAP s TLS test tool for other TLS/cert tests DNS Server: OS version: FreeBSD 10.3 IP Address (a): IP Address (b): Configuration Details: BIND for providing DNS services to the TOE platform OCSP/CRL Server: OS version: Fedora 22 IP Address (b): Configuration Details: OpenCA s OCSPD for OCSP responder Apache HTTPD for providing CRL distribution point 4.9 Test Diagram (Android Testbed #2) 19

20 4.10 Configuration Information (Android Testbed #2) TOE #1: SW version: Cisco Jabber 11.7 TOE Platform #1 HW version: Samsung Galaxy S7 SW version: Android 6 IP address: Infrastructure Platform: CUCM1: CUCM2: DNS Server: HW version: Cisco UCS Hypervisor: VMWare ESXi IP Address: Software Version: IP Address: Software Version: OS Version: Windows Server 2012R2 IP Address: Laptop (VoIP peer): OS Version: Windows 10 Professional x64 SW Version: Jabber 11.7 IP Address:

21 4.11 Test Diagram (Android Testbed #3) 4.12 Configuration Information (Android Testbed #3) TOE #1: SW version: Cisco Jabber 11.7 TOE Platform #1 HW version: Samsung Galaxy S7 SW version: Android 6 IP address:

22 5 Detailed Test Cases 5.1 Cryptographic Support (FCS) FCS_CKM_EXT.2.1(1) TSS 1 The evaluator shall examine the TSS to ensure it describes in detail how user credentials, certificates, persistent secret and private keys are stored. The evaluator reviews the TSS to determine that it makes a case that key material is not written unencrypted to persistent memory, and that key material is stored by the platform Evaluator Findings The evaluator examined the TSS to ensure that it describes in detail how user credentials, persistent secrets, certificates and private keys are stored. According to the TSS entry for this SFR the TOE uses either the Android KeyStore or the ios Keychain to store credentials and private keys. The TSS claims that both platforms have a key isolation service that is designed to protect credentials from disclosure and modification and there is no danger of unencrypted keys being written to persistent memory. There are also no interfaces that would allow users to access the key storage. Based on this the assurance activity is considered satisfied Verdict FCS_SRTP_EXT.1 TSS 1 The evaluator shall examine the TSS to verify that it describes how the SRTP session is negotiated for both incoming and outgoing calls. This includes how the keying material is established, as well has how requests to use the NULL algorithm or other unallowed ciphersuites are rejected by the TSF Evaluator Findings The evaluator examined the TSS to verify that it describes how SRTP sessions are negotiated for both incoming and outgoing calls. According to the TSS entry for this SFR all calls are handled as required by RFC The TOE begins by establishing a TLS-protected connection with a CUCM SIP server. Configurations for encrypted RTP calls are pushed out by the SIP server. The key is generated randomly by the TOE platform during the building of the SDP offer. During the establishment of a connection with the SIP server the TOE offers all of the ciphersuites that it supports. The handling of unsupported ciphers is the responsibility of the CUCM server. Requests to use the NULL algorithm when the TOE is configured for encrypted calling will result in the call failing. Based on this the assurance activity is considered satisfied Verdict 22

23 5.1.3 FCS_SRTP_EXT.1 Test 1 Test ID FCS_SRTP_EXT.1 Test 1 The evaluator shall follow the procedure for initializing their device so that they are ready to receive and place calls. The evaluator shall then both place and receive a call and determine that the traffic sent and received by the TOE is encrypted. To ensure that the call is being encrypted and to view the ciphersuites being used a packet capture tool should be used. In order to decrypt the TLS-SIP traffic and view the SDES negotiation the SIP server s private key needs to be loaded into the packet capture tool. Configure the device according to guidance documentation to place and receive encrypted calls from another client. Place a call to another client. Using a packet capture tool capture the traffic going to and from the device and determine if it is encrypted. Place a call from another client to the TOE. Configure the CUCM server to output an unencrypted version of the negotiation. Verify the SDES communication /Fail Criteria The SIP exchange shows the negotiated srtp parameters FCS_CKM.1.1(1) Met By TOE, Test #1, RSA Key Generation The evaluator shall verify the implementation of RSA Key Generation by the TOE using the Key Generation test. This test verifies the ability of the TSF to correctly produce values for the key components including the public verification exponent e, the private prime factors p and q, the public modulus n and the calculation of the private signature exponent d Evaluator Findings The cryptography employed by the TOE has been through CAVP validation. The relevant CAVP algorithm certificate for this test is 2403 (ios) and 2404 (Android) Verdict FCS_CKM.1.1(1) Met By TOE, B Key Establishment Schemes, TSS 1 In order to show that the TSF complies with A and/or B, depending on the selections made, the evaluator shall ensure that the TSS contains the following information: The TSS shall list all sections of the appropriate standard(s) to which the TOE complies. For each applicable section listed in the TSS, for all statements that are not "shall" (that is, "shall not", "should", and "should not"), if the TOE implements such options it shall be described in the TSS. If the included functionality is indicated as "shall not" or "should not" in the standard, the TSS shall provide a rationale for why this will not adversely affect the security policy implemented by the TOE. 23

24 For each applicable section of A and B (as selected), any omission of functionality related to "shall" or should statements shall be described Evaluator Findings The evaluator examined the TSS to verify that it contained the information to show that the TSF complies with B. Table 19 in section 6.1 of the ST was used to determine the verdict of this assurance activity. The TSS states that the TOE complies with B. The TOE performs asymmetric cryptographic key generation for the purpose of RSA-based key establishment. This is done using the Cisco FIPS Object Module (FOM) v6.0 library. Only RSA is supported. Based on this the assurance activity is considered satisfied Verdict FCS_CKM.1.1(2) Met By TOE, TSS 1 If the ESF implements the ANSI X scheme, the evaluator shall check to ensure that the TSS describes how the key-pairs are generated. In order to show that the TSF implementation complies with ANSI X , the evaluator shall ensure that the TSS contains the following information: The TSS shall list all sections of the standard to which the TOE complies; For each applicable section listed in the TSS, for all statements that are not "shall" (that is, "shall not", "should", and "should not"), if the TOE implements such options it shall be described in the TSS. If the included functionality is indicated as "shall not" or "should not" in the standard, the TSS shall provide a rationale for why this will not adversely affect the security policy implemented by the TOE; For each applicable section of Appendix B, any omission of functionality related to "shall" or should statements shall be described Evaluator Findings The evaluator examined the TSS to ensure that it describes how key pairs are generated. Table 19 in section 6.1 of the ST was used to determine the verdict of this assurance activity. The TOE complies with Appendix B.3 for RSA of FIPS PUB Certificates are not generated by the TOE itself, but are generated on a CUCM server and transported to the TOE after authentication. Based on this the assurance activity is considered satisfied Verdict FCS_CKM_EXT.4.1 Met By Platform, TSS 1 The evaluator shall check to ensure the TSS describes each of the secret keys (keys used for symmetric encryption), private keys, and CSPs used to generate key that are not otherwise covered by the FCS_CKM_EXT.4 requirement levied on the TOE. 24

25 Evaluator Findings The evaluator examined the TSS to ensure that each of the secret keys, private keys and CSPs are described. The TSS states that private keys used for certificate generation via CAPF, TLS session keys, srtp session keys and user passwords are maintained by the TOE. These secrets are maintained by the TOE, but the TOE uses platform memory management functions to control their zeroization. Based on this the assurance activity is considered satisfied Verdict FCS_CKM_EXT.4.1 Met By Platform, TSS 2 For each platform listed in the ST, the evaluator shall examine the TSS of the ST of the platform to ensure that each of the secret keys, private keys, and CSPs used to generate key listed above are covered Evaluator Findings The evaluator examined the TSS to determine that all of the keys listed above are covered. Table 19 in section 6.1 of the ST was used to determine the verdict of this assurance activity. As stated in the above assurance activity the platform does not maintain any keys or CSPs and merely supports their zeroization. Based on this the assurance activity is considered satisfied Verdict FCS_CKM_EXT.4.1 Met By TOE, TSS 1 The evaluator shall check to ensure the TSS describes each of the secret keys (keys used for symmetric encryption), private keys, and CSPs used to generate key; when they are zeroized (for example, immediately after use, on system shutdown, etc.); and the type of zeroization procedure that is performed (overwrite with zeros, overwrite three times with random pattern, etc.). If different types of memory are used to store the materials to be protected, the evaluator shall check to ensure that the TSS describes the zeroization procedure in terms of the memory in which the data are stored (for example, "secret keys stored on flash are zeroized by overwriting once with zeros, while secret keys stored on the internal hard drive are zeroized by overwriting three times with a random pattern that is changed before each write"). If a read-back is done to verify the zeroization, this shall be described as well Evaluator Findings The evaluator examined the TSS to ensure that each of the secret keys, private keys and CSPs are described. Table 19 in section 6.1 of the ST was used to determine the verdict of this assurance activity. The TSS states that TLS session keys, srtp session keys and user passwords are maintained by the TOE. 25

26 When keys or CSPs are no longer needed they are overwritten with zeroes. Platform memory management functions are used to control this. Based on this the assurance activity is considered satisfied Verdict FCS_CKM_EXT.4.1 Met By TOE, Test 1 Test ID FCS_CKM_EXT.4 Test #1 For each key clearing situation described in the TSS the evaluator shall repeat the following test. The evaluator shall utilize appropriate combinations of specialized operational environment and development tools (debuggers, simulators, etc.) for the TOE and instrumented TOE builds to test that keys are cleared correctly, including all intermediate copies of the key that may have been created internally by the TOE during normal cryptographic processing with that key. Cryptographic TOE implementations in software shall be loaded and exercised under a debugger to perform such tests. The evaluator shall perform the following test for each key subject to clearing, including intermediate copies of keys that are persisted encrypted by the TOE: Load the instrumented TOE build in a debugger. Record the value of the key in the TOE subject to clearing. Cause the TOE to perform a normal cryptographic processing with the key from #1. Cause the TOE to clear the key. Cause the TOE to stop the execution but not exit. Cause the TOE to dump the entire memory footprint of the TOE into a binary file. Search the content of the binary file created in #4 for instances of the known key value from #1. The test succeeds if no copies of the key from #1 are found in step #7 above and fails otherwise. The evaluator shall perform this test on all keys, including those persisted in encrypted form, to ensure intermediate copies are cleared. In cases where the TOE is implemented in firmware and operates in a limited operating environment that does not allow the use of debuggers, the evaluator shall utilize a simulator for the TOE on a general purpose operating system. The evaluator shall provide a rationale explaining the instrumentation of the simulated test environment and justifying the obtained test results. /Fail Criteria FCS_COP.1.1(1) Met By TOE, Test #1, AES-CBC KAT Evaluator Findings The cryptography employed by the TOE has been through CAVP validation. The relevant CAVP algorithm certificate for this test is 4223 (ios) and 4240 (Android). 26

27 Verdict FCS_COP.1.1(1) Met By TOE, Test #2, AES-CBC KAT Evaluator Findings The cryptography employed by the TOE has been through CAVP validation. The relevant CAVP algorithm certificate for this test is 4223 (ios) and 4240 (Android) Verdict FCS_COP.1.1(1) Met By TOE, Test #3, AES-CBC KAT Evaluator Findings The cryptography employed by the TOE has been through CAVP validation. The relevant CAVP algorithm certificate for this test is 4223 (ios) and 4240 (Android) Verdict FCS_COP.1.1(1) Met By TOE, Test #4, AES-CBC KAT Evaluator Findings The cryptography employed by the TOE has been through CAVP validation. The relevant CAVP algorithm certificate for this test is 4223 (ios) and 4240 (Android) Verdict FCS_COP.1.1(1) Met By TOE, Test #5, AES-CBC Multi- Block Message Test Evaluator Findings The cryptography employed by the TOE has been through CAVP validation. The relevant CAVP algorithm certificate for this test is 4223 (ios) and 4240 (Android) Verdict FCS_COP.1.1(1) Met By TOE, Test #6, AES-CBC Monte Carlo Test Evaluator Findings The cryptography employed by the TOE has been through CAVP validation. The relevant CAVP algorithm certificate for this test is 4223 (ios) and 4240 (Android) Verdict 27

28 FCS_COP.1.1(1) Met By TOE, Test #7, AES-GCM Monte Carlo Test Evaluator Findings The cryptography employed by the TOE has been through CAVP validation. The relevant CAVP algorithm certificate for this test is 4223 (ios) and 4240 (Android) Verdict FCS_COP.1.1(1) Met By Platform, TSS 1 For each platform listed in the ST, the evaluator shall examine the ST of the platform to ensure that the encryption/decryption function(s) claimed in that platform's ST contains the encryption/decryption function(s) in the VoIP Client Application's ST. The evaluator shall also examine the TSS of the VoIP Client Application's ST to verify that it describes (for each supported platform) how the encryption/decryption functionality is invoked for each mode and key size selected in the VoIP Client Application's ST Evaluator Findings According to the TOE ST the TOE platform should be capable of performing AES-CBC in the context of generating random numbers (via the platform provided SP A DRBG). The evaluator examined the STs of the claimed platforms to determine if they contain the functions in the TOE ST. The following STs were examined: Apple ios 9.2 MDFPPv2 ST (VID 10725) Samsung Galaxy S7 on Android 6 MDFPPv2 ST (VID 10739) In the Mobile Device Fundamentals PP cryptographic encryption/decryption services are addressed by FCS_COP.1(1). Each of the examined STs claimed that they support AES for encryption/decryption. According to the TSS the TOE only uses uses platform provided AES in support of random number generation and is never directly invoked otherwise. An examination of the TOE s AES CAVP certificates showed that CTR was covered by both of them. Based on these findings the assurance activity is considered satisfied Verdict FCS_COP.1.1(2) Met By Platform, TSS 1 For each platform listed in the ST, the evaluator shall examine the ST of the platform to ensure that the digital signature functions claimed in that platform's ST contains the digital signature functions in the VoIP Client Application's ST. The evaluator shall also examine the TSS of the VoIP Client Application's ST to verify that it describes (for each supported platform) how the digital signature functionality is invoked for each operation they are used for in the VoIP client application (it should be noted that this may 28

29 be through a mechanism that is not implemented by the VoIP Client Application; nonetheless, that mechanism will be identified in the TSS as part of this assurance activity) Evaluator Findings According to the TOE ST the TOE platform should be capable of performing RSA and ECDSA cryptographic signature services an accordance with FIPS The evaluator examined the STs of the claimed platforms to determine if they contain the functions in the TOE ST. The following STs were examined: Apple ios 9.2 MDFPPv2 ST (VID 10725) Samsung Galaxy S7 on Android 6 MDFPPv2 ST (VID 10739) In the Mobile Device Fundamentals PP cryptographic signature services are addressed by FCS_COP.1(3). All four of the examined STs claimed that they support FIPS RSA and ECDSA cryptographic signature services. According to the TSS the TOE only uses digital signature verification to validate server certificates for client TLS sessions. On ios the TOE calls the SecTrustEvaluate API while on Android it calls the X509TrustManger::checkServerTrusted API. Based on these findings the assurance activity is considered satisfied Verdict FCS_COP.1.1(3) Met By TOE, Test #1, Short Message Test Bit Oriented Mode Evaluator Findings The cryptography employed by the TOE has been through CAVP validation. The relevant CAVP algorithm certificate for this test is 3470 (ios) and 3478 (Android) Verdict FCS_COP.1.1(3) Met By TOE, Test #2, Short Message Test Byte Oriented Mode Evaluator Findings The cryptography employed by the TOE has been through CAVP validation. The relevant CAVP algorithm certificate for this test is 3470 (ios) and 3478 (Android) Verdict FCS_COP.1.1(3) Met By TOE, Test #3, Selected Long Evaluator Findings The cryptography employed by the TOE has been through CAVP validation. The relevant CAVP algorithm certificate for this test is 3470 (ios) and 3478 (Android). 29

30 Verdict FCS_COP.1.1(3) Met By TOE, Test #4, Selected Long Messages Test Byte Oriented Mode Evaluator Findings The cryptography employed by the TOE has been through CAVP validation. The relevant CAVP algorithm certificate for this test is 3470 (ios) and 3478 (Android) Verdict FCS_COP.1.1(3) Met By TOE, Test #5, Pseudorandomly Generated Messages Test Evaluator Findings The cryptography employed by the TOE has been through CAVP validation. The relevant CAVP algorithm certificate for this test is 3470 (ios) and 3478 (Android) Verdict FCS_COP.1.1(3) Met By Platform, TSS 1 For each platform listed in the ST, the evaluator shall examine the ST of the platform to ensure that the hash function(s) claimed in that platform's ST contains the hash function(s) in the VoIP Client Application's ST. The evaluator shall also examine the TSS of the VoIP Client Application's ST to verify that it describes (for each supported platform) how the hash functionality is invoked for each digest size selected in the VoIP Client Application's ST Evaluator Findings According to the TOE ST the TOE platform should be capable of performing SHS in support of RSA and ECDSA cryptographic signature services. The evaluator examined the STs of the claimed platforms to determine if they contain the functions in the TOE ST. The following STs were examined: Apple ios 9.2 MDFPPv2 ST (VID 10725) Samsung Galaxy S7 on Android 6 MDFPPv2 ST (VID 10739) In the Mobile Device Fundamentals PP cryptographic hashing services are addressed by FCS_COP.1(2). Each of the examined STs claimed that they support SHS hashing. According to the TSS the TOE only uses uses platform provided SHS in support of signature services and is never directly invoked otherwise. Additionally, the TOE only uses digital signature verification to validate server certificates for client TLS sessions. On ios the TOE calls the SecTrustEvaluate API while on Android it calls the X509TrustManger::checkServerTrusted API. Based on these findings the assurance activity is considered satisfied. 30

31 Verdict FCS_COP.1.1(4) Met By TOE, TSS 1 For all cases where the output of the HMAC following the hash calculation is truncated, the evaluator shall ensure that the TSS states for what operation this truncation takes place; the size of the final output; and the standard to which this truncation complies Evaluator Findings The evaluator examined the TSS to determine for what operations the output of the HMAC following the hash calculation is truncated. Table 19 in section 6.1 of the ST was used to determine the verdict of this work unit. The evaluator found that there were no such cases. Based on this the assurance activity is considered satisfied Verdict FCS_COP.1.1(4) Met By TOE, TSS 2 The evaluator shall examine the TSS to ensure that it specifies the following values used by the HMAC function: key length, hash function used, block size, and output MAC length used Evaluator Findings The evaluator examined the TSS to ensure that it specifies the HMAC function used by the TOE. Table 19 in section 6.1 was used to determine the verdict of this assurance activity. The evaluator found that the TOE uses HMAC-SHA-1, HMAC-SHA-256 and HMAC-SHA-384. Based on this the assurance activity is considered satisfied Verdict FCS_COP.1.1(4) Met By TOE, Test 1 For each of the supported parameter sets, the evaluator shall compose 15 sets of test data. Each set shall consist of a key and message data. The evaluator shall have the TSF generate HMAC tags for these sets of test data. The resulting MAC tags shall be compared to the result of generating HMAC tags with the same key and IV using a known good implementation Evaluator Findings The cryptography employed by the TOE has been through CAVP validation. The relevant CAVP algorithm certificate for this test is 2771 (ios) and 2779 (Android) Verdict 31

32 FCS_RBG_EXT.1 Met By Platform, TSS 1 For each platform listed in the ST, the evaluator shall examine the ST of the platform to ensure that the RBG functions claimed in that platform s ST contains the RBG functions in the VoIP Client Application s ST. The evaluator shall also examine the TSS of the VoIP Client Application s ST to verify that it describes (for each supported platform) how the RBG functionality is invoked for each operation they are used for in the VoIP application (it should be noted that this may be through a mechanism that is not implemented by the VoIP application; nonetheless, that mechanism will be identified in the TSS as part of this assurance activity Evaluator Findings The ST of the TOE requires the platform to be able to perform deterministic random bit generation in accordance with NIST SP A using CTR_DRBG(AES). The deterministic RBG accumulates entropy from a platform-based RBG with a minimum of 256 bits of entropy. The evaluator examined the STs that were previously listed in the assurance activity for FCS_COP.1(2). All of them were capable of performing deterministic random bit generation to the standard and with the amount of entropy required by the TOE. An examination of the TOE s AES CAVP certificates showed that CTR was covered by both of them. The TOE invokes RBG functionality by calling /dev/random on all platforms. Based on this the assurance activity is considered satisfied Verdict 5.2 User Data Protection (FDP) FDP_VOP_EXT.1 TSS 1 The evaluator shall examine the TSS to verify that it describes how each of the functions in the requirement is implemented Evaluator Findings The evaluator examined the TSS to verify that it describes how each of the functions in the requirement is implemented. In the SFR the ST makes the claim that the transmission of voice data is stopped when a call is placed on mute, when it is not connected and when it is placed on hold. These are the only two functions described in this requirement. The TSS states that when a call is placed on mute, SRTP is not stopped. The TOE stops sending voice data, however silence or comfort noise packets continue to be sent in order to maintain the connection. Placing a call on hold does result in SRTP streams being stopped. The TOE plays music until the call is resumed, at which point a new connection is negotiated over SIP/SDP. The termination of a call is done with a SIP BYE message which terminates SRTP streams. 32

33 Verdict FDP_VOP_EXT.1 Test 1 Test ID FDP_VOP_EXT.1 Test 1 The evaluator shall follow the procedure for initializing the device so that it is ready to receive and place calls. Using a packet capture tool, the evaluator shall verify that no voice traffic is transmitted until a call is placed/received. The evaluator shall place a call and verify that the voice traffic is being sent through the secure channel. The evaluator shall then implement each of the functions listed (mute, hold, disconnect, and any other specified actions) and verify that voice traffic is no longer being transmitted. Start up the TOE so that it is in a state where it can place a call to another VoIP client. Start a packet capture tool to monitor data going into and out of the TOE. Place a call from the TOE to the other VoIP client. Once the call is accepted turn the mute feature on the TOE on and then off. Place the TOE on hold and then take it off of hold. Disconnect the TOE from the call. /Fail Criteria Voice data is not passed when a call is on mute FDP_VOP_EXT.1 Test 2 Test ID FDP_VOP_EXT.1 Test 2 The evaluator shall follow the procedure for initializing the device so that it is ready to receive and place calls. Using a packet capture tool, the evaluator shall verify that no voice traffic is transmitted until a call is placed/received. The evaluator shall receive a call and verify that the voice traffic is being sent through the secure channel. The evaluator shall then implement each of the functions listed (mute, hold, disconnect, and any other specified actions) and verify that voice traffic is no longer being transmitted. Start up the TOE so that it is in a state where it can receive a call from another VoIP client. Start a packet capture tool to monitor data going into and out of the TOE. Place a call from another VoIP client to the TOE. Once the call is accepted turn the mute feature on the TOE on and then off. Place the TOE on hold and then take it off of hold. Disconnect the TOE from the call. /Fail Criteria Voice data is not passed when a call is on hold. 33

34 5.3 Identification and Authentication (FIA) FIA_SIPC_EXT.1 TSS 1 The evaluator shall examine the TSS to verify that it describes how the SIP session is established. This shall include the initiation of the SIP session, registration of the user, and how both outgoing and incoming calls are handled (initiated, described, and terminated). This description shall also include a description of the handling of the password from the time it is entered by the user until the time it is cleared by the TSF Evaluator Findings The evaluator examined the TSS to verify that it describes how the SIP session is established. The entries for FCS_SRTP_EXT.1 and FIA_SIPC_EXT.1 were used to determine the verdict of this assurance activity. During an attempt to connect to the SIP server the TOE passes a request for a password to the user in order to complete the SIP REGISTER request. This password is sent to CUCM to complete the connection attempt. The password is kept in a SecureString, and once it is no longer required its memory space is zeroized and released for use by other applications. Outgoing calls go through ports configured by CUCM. By default SIP uses port 5060 while Secure SIP uses An SDP/SDES message is sent to exchange keying material along with a SIP INVITE message. After that a SIP 180 RINGING message is sent, followed by a 200 OK message when the other user answers. Incoming calls are initiated when the TOE receives a INVITE message. It response with a SIP 100 TRYING message along with a SDP message. An answer by the VoIP peer then results in a SIP 200 OK message Verdict FIA_SIPC_EXT.1 Test 1 Test ID FIA_SIPC_EXT.1 Test 1 The evaluator shall follow the procedure for initializing their device to include establishing a connection to the SIP Server. The evaluator shall confirm that they are prompted for a password prior to successfully completing the SIP REGISTER request. Attempt to connect the TOE to a SIP server. Start a packet capture of all traffic between the TOE and the SIP server. Verify that the SIP REGISTER request is not completed until after a password is entered into the TOE. /Fail Criteria The SIP REGISTER packet is only sent after authentication FIA_SIPC_EXT.1 Test 2 34

35 Test ID FIA_SIPC_EXT.1 Test 2 The evaluator shall follow the procedure for initializing their device to include establishing a connection to the SIP Server. The evaluator shall confirm that entering an incorrect password results in the device not being registered by the SIP Server (e.g., they are unable to successful place or receive calls). The evaluator shall also confirm that entering the correct password allows the successful registration of the device (e.g., by being able to place and receive calls). Start a wireshark capture Begin to establish a connection between the TOE and a SIP server Enter a bad password o Jabber1 o Verify that no SIP traffic is passed /Fail Criteria No SIP traffic is sent between the client and the SIP server until the user has successfully authenticated FIA_SIPC_EXT.1 Test 3 Test ID FIA_SIPC_EXT.1 Test 3 The evaluator shall set up the test environment such that a variety of passwords are shown to be accepted by the TOE, such that the length and character set identified in FIA_SIPC_EXT.1.3 is represented. The test report shall contain a rationale by the evaluator that the test set used is representative of the allowed lengths and characters. Set the minimum password length for 15 characters Attempt a set of good passwords o TestwordOne! o TestwordNum@2 o testingpassword#3 o TestPa$$wordFour o Te%tP^$$wordFive o testp*()wordsix o ThisIsAVeryLongTestword1! o 123&TestPa55w0rd% Verify that the good passwords were accepted Attempt a set of bad passwords o Test o TestPa55w*rd o Testpassword o ThisIsAVeryLongTestword Verify the bad passwords were not accepted /Fail Criteria Only good passwords are accepted. Bad passwords are rejected FIA_X509_EXT.1 TSS 1 The evaluator shall ensure the TSS describes where the check of validity of the certificates takes place the TOE or the TOE platform. It may be that the TOE requests the platform to perform the check and provide a result, or the TOE may do the check itself. The evaluator ensures the 35

36 TSS also provides a description of the certificate path validation algorithm, ensuring that it describes how the validation chain will terminate in a trusted root certificate Evaluator Findings The evaluator examined the TSS to determine if describes where the check of certificate validity takes place. The TSS entry for this SFR states that validity checking takes place on the platform. During initial TOE configuration it receives a certificate from CUCM. This certificate can be either created by CUCM s Certificate Authority Proxy Function (CAPF) or CUCM can request a certificate from an external CA. Once a certificate is received it is stored on the TOE platform s certificate store. Verification of certificates is performed by the platform. Certificate verification includes CRL/OCSP checks along with extendedkeyusage field validation Verdict FIA_X509_EXT.1 Guidance 1 The evaluator ensures the guidance documentation provides the user with the necessary information to setup the validation check whether it is done by the TOE or TOE platform. The guidance documentation provides instructions how to select the method used for checking, as well as how to setup a protected communication path with the entity providing the information pertaining to certificate validity Evaluator Findings The evaluator examined the guidance documentation to determine whether it provides the necessary information to setup the validation check. Section of the AGD was used to determine the verdict of this assurance activity. The only actions necessary for users to take are to enter the authentication string required by the Certficate Authority Proxy Function (CAPF). Instructions on how to perform this are in section Based on this the assurance activity is considered satisfied Verdict FIA_X509_EXT.1 Test 1 Test ID FIA_X509_EXT.1.1 Test #1 The evaluator shall demonstrate that validating a certificate without a valid certification path results in the function (trusted channel setup, trusted software update, integrity check) failing. The evaluator shall then load a certificate or certificates needed to validate the certificate to be used in the function, and demonstrate that the function succeeds. The evaluator then shall delete one of the certificates, and show that the function fails. 36