© Cellcrypt IA DOCUMENTATION Security Target ellcrypt Mobile for Secret client version 1.0 PP Ref: Protection Profile for Mobility — Voice Over IP Application, PP_MOBILITY_VOIP_V0.6, 2013- 01 -28. Ref: ST001 Version: 3.2 Date: 14 April 2014 Copyright © 2014 Cellerypt Limited. All rights reserved. The information contained in this document, including all ideas and technologies described herein, is proprietary to Cellcrypt. Nei- ther the whole nor any part of the information contained in this document may be adapted or reproduced in any material or electron- ic form without the prior written consent of the copyright holder. ST v3.2.docx Page 1 of 37 Ref: STO01 A Security Target Ver: 3.2 04_14 2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 DOCUMENT CONTROL Version History Author(s) Date Update RC 3.2 14 Apr 2014 Updates following validator review. Update to specify processor explicitly, and update build number to account for updating OpenSSL to v1.0.1g to fix heartbleed bug. RC 3.1 31 Mar 2014 Updates following validator review. RC 3.0 10 Mar 2014 Updates following validator review. RC 2.0 10 Jan 2014 Update all versions numbers to final. PG 1.9 1* Oct 2013 Update Table 8 Certificate numbers for version 2.0.5 of OpenSSL FIPS Object Module PG 1.8 22 Aug 2013 |Align TOE version with F8002a. Removed reference to FCS_CKM.1 in Table 6 PG 1.7 20* Aug 2013 |Update version of PJSIP PG 1.6 14% Aug 2013 | Update after drafting FS PG 1.5 1 Aug 2013 Updated after lab review PG 14 30" Jul 2013 Updated after lab review PS 1.3 30" May 2013 | Updated after lab review PS 1.2 22" Mar 2013 Updated after lab review PS 1.1 27" Feb 2013 Re-issued after reformatting PS 1.0 22" Feb 2013 | First Issue ST v3.2.docx Page 2 of 37 Ref: STO01 A Security Target Ver: 3.2 04_14 2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 CONTENTS 1 SECURITY TARGET INTRODUCTION 1.1 Security Target Referencı 1.2 TOE Reference. 1.3. TOE Overview 1.3.1 TOE Architecture. 1.4 TOE Description . 2 CONFORMANCE CLAIMS . 2.1 CC Conformance Claim. 2.2 Protection Profile Claim 2.3 Package Claim .... 2.4 Conformance Rationale 3 SECURITY PROBLEM DEFINITION... 3.1 Threats addressed by the TOE. 3.2. Organisational Security Policies 3.3. Assumptions. 4 SECURITY OBJECTIVES . 4.1 Security objectives for the TOE.. 4.2 Security objectives for the operating environment 4.3 Security Objectives Rationale 4.3.1. Summary Mapping of Security Objectives. 4.3.2 Security Objectives of the TOE Rationale 5 EXTENDED COMPONENTS DEFINITION . 6 SECURITY REQUIREMENTS... 6.1 Security functional requirements 6.1.1 Cryptographic Support (FCS) 6.1.2 Identification and Authentication (FIA) 6.1.3 Protection of the TOE Security Functions (FPT) 6.1.4 Trusted Path/Channel (FTP). 6.2 Security Assurance Requirements. 6.2.1 Class ADV: Development 6.2.2 Class AGD: Guidance Document: 6.2.3 Class AVA: Vulnerability Assessment 6.2.4 Class ALC: Life-Cycle Support 6.2.5 Class ATE: Test... 6.3 Security Requirements Rationale 7 _TOE SUMMARY SPECIFICATION.... 7.1 Secure Services: . 7.2 TOE Security functions. 7.2.1 Cryptographic Support... 7.2.2 Protected communication: 7.2.3 Identification and authenticatio! 7.2.4 TSF protection 7.2.5 TOE Documentation 8 APPENDIX A - TERMINOLOGY AND ACRONYMS 9 APPENDIX B — REFERENCED DOCUMENTS... 10 APPENDIX C—NIST SP 800-53/CNSS 1253 MAPPING ST v3.2.docx Page 3 of 37 Ref: ST001 A Security Target Ver: 3.2 04_14 2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 List of Figures Figure 1 Figure 2 Figure 3 : Sample Deployment Architecture. : Cellcrypt Mobile for Secret Android Architecture . : Two tunnels of the enterprise mobility solution encapsulated by a VPN... List of Tables Table 1: Table 2: Table 3: Table 4: Table 5: Table 6: Table 7: Table 8: Table 9: Conv: Security objectives for the TOE...... Security objectives for the operating environment... Mapping of Assumptions and Threats to Security Objectives Mapping of Assumptions and Threats to Objectives . Extended Components implemented by the TOE... Security Functional Requirements. Assurance Requirements Implementation of Cryptographic Support. Zeroization ... entions The following conventions have been applied in this document: The CC defines operations on Security Functional Requirements (SFR): assignments, selections, assignm identify ents within selections and refinements. This document uses the following font conventions to the operations defined by the CC: Assignment: Indicated with italicized text; Refinement made by PP author: Indicated by the word "Refinement" in bold text after the element number with additional bold text and deletions with strikethroughs, if necessary; Selection: Indicated with underlined text; Assignment within a Selection: Indicated with italicized and underlined text; Iteration: Indicated by appending the iteration number in parenthesis, e.g., (1), (2), (3). Explicitly stated SFRs are identified by having a label 'EXT' after the requirement name for TOE SFRs. ST v3.2.docx Page 4 of 37 Ref: ST001 A Security Target Ver: 3.2 04_14 2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 1 SECURITY TARGET INTRODUCTION This section identifies the Security Target (ST) and Target of Evaluation (TOE) identification, ST conventions, ST conformance claims, and the ST organization. The TOE is comprised of Cellcrypt Mobile for Secret client version 1.0, a Secure Voice over Internet Protocol (SVoIP) application for smartphones, which enables users to have secure voice calls on an end- to-end encrypted session. The Security Target contains the following additional sections: * Conformance Claims (Section 2)—provides details of conformance of the security target against Common Criteria and provides rationale that the TOE conforms to the PP(s) for which conformance has been claimed. * Security Problem Definition (Section 3)—specifies the assumptions and threats that define the security problem to be addressed by the TOE and its operational environment. * Security Objectives (Section 4)—specifies the security objectives for the TOE and its operational environment necessary to counter the threats and satisfy the assumptions defining the security problem. * Extended Components Definition (Section 5)—specifies any new components that define extended functional and extended assurance requirements. * TOE Summary Specification (Section 6)—describes the security functions of the TOE and how they satisfy the security functional requirements. 1.1 Security Target Reference ST Title — Cellcrypt Mobile for Secret client version 1.0 Security Target ST Version — Version 3.2 ST Date - April 14, 2014 1.2 TOE Reference TOE Identification — Cellcrypt Mobile for Secret client version 1.0 TOE Developer - Cellcrypt Inc. Evaluation Sponsor - Cellcrypt Inc. CC Identification - Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 4, September 2012 Build Number - v1.0.0-final-rc2 1.3 TOE Overview Cellcrypt Mobile for Secret client version 1.0 is a VOIP application for secure encrypted voice calls designed to run on standard mobile phones. It comprises a handset software application and a back-end support infrastructure (SIP server). Only the handset software application ‘Cellcrypt Mobile for Secret client version 1.0’ is regarded as the TOE. ST v3.2.docx Page 5 of 37 Ref: ST001 A Security Target Ver: 3.2 04_14 2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 Cellcrypt Mobile for Secret client version 1.0 uses standard wireless packet-based connectivity over Global System for Mobile Communications (GSM)/Enhanced Data rates for GSM Evolution (EDGE) or Wideband Code Division Multiple Access (WCDMA) encrypted voice communication. Authenticated connection set-up ensures that only Cellcrypt Mobile for Secret client version 1.0 enabled mobile phones can participate in secure sessions. End-to-end encryption is achieved through the creation and use of session unique encryption keys. These are used by the handset software application when encrypting/decrypting secure voice traffic. The following assumptions have been made: + The mobile platform will be ARMv7 hardware with Android Jellybean 4.2 (API 17) OS. * Cellcrypt Mobile for Secret client version 1.0 will only handle single session, unicast, secure voice calls. Non-TOE Requirements * Mobile OS (including VPN access), as defined by the Protection Profile for Mobile Device Fundamentals [2], is outside of the scope of this evaluation. * — SIP Server, as defined by the Protection Profile for SIP Server [3], is outside of the scope of this evaluation. * — Cellcrypt Mobile for Secret client version 1.0 will operate exclusively within the mobility ecosystem specified by the associated mobility Protection Profiles, and will assume that all associated resources (IPSEC VPN tunnel, PKI, SIP network) are in place. ST v3.2.docx Page 6 of 37 Ref: ST001 A Security Target Ver: 3.2 04_14 2014 N Cellerypt Cellcrypt Mobile for Secret client version 1.0 GSM Phone Ss CDMA Phone © 3G / 4G / LTE Carrier Network 3G/4G/LTE Carrier Network Internet Firewall / Router LAN Figure 1: Sample Deployment Architecture 1.3.1 TOE Architecture The following block diagram outlines the Cellcrypt Mobile for Secret client version 1.0 application architecture on the Android platform. ST v3.2.docx Page 7 of 37 G Ref: STOO1 Security Target Ver: 3.2 04_14_2014 Cellerypt Cellcrypt Mobile for Secret client version 1.0 UI Layer Settings Telephony State Notification CENTS Connection (Signaling) Manager SIP Client SIP User Agent Client Codecs SIP RTP CESR Media Connection Manager Figure 2: Cellcrypt Mobile for Secret Android Architecture 1.3.1.1 Physical Boundaries The physical boundary of the TOE is the installation package from which the Cellcrypt Mobile for Secret client version 1.0 application is installed. The TOE is described as Cellcrypt Mobile for Secret client version 1.0. In order to comply with the evaluated configuration, the following components should be used. 1.3.1.2 Mobile Platform The TOE requires the following additional mobile platform components to operate: * Android Jellybean 4.2 (API 17) operating system * Smartphone handset compatible with the operating system*. The handsets tested at this time are: o Samsung Galaxy $4 running the Qualcomm Snapdragon 600 processor. +The TOE is designed to be compatible with any Android 4.2 smartphone running on ARMv7 architecture CPU with or without NEON optimization. ST v3.2.docx Page 8 of 37 Ref: ST001 A Security Target Ver: 3.2 04_14 2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 The operating system and handset are considered non-TOE components. 1.3.1.3 Logical Boundaries The Cellcrypt Mobile for Secret client version 1.0 application implements the following components within its logical boundary (application boundary shown by blue line): * Cellcrypt Service Engine * Token Manager * Connection * Voice + Media Manager + SIP Stack (Third party library) * OpenSSL Crypto Library (Third party library) + Codecs (Third party library) The following sections describe each of the components within the application boundary. 1.3.1.3.1. SIP Stack Cellcrypt Mobile for Secret client version 1.0 licenses the 3 party commercial PJSIP stack to provide SIP protocol functionality and compliance with certain open standards including, SIP (RFC 3261), SDP (RFC 4566), SRTP (RFC 3711), and SDES (RFC 4568). The SIP stack is used to implement: + FCS_SRTP_EXT.1: Secure Real-Time Transport Protocol (SRTP) + FIA_SIPC_EXT.1: Session Initiation Protocol (SIP) Client + FTPITC.1(1): Inter-TSF Trusted Channel (SDES-SRTP) and iterations ® _FTP_ITC.1(2): Inter-TSF Trusted Channel (TLS/SIP) and iterations 1.3.1.3.2. Crypto Library Cellcrypt Mobile for Secret client version 1.0 uses the FIPS validated (cert. no. 1747) OpenSSL FIPS Object Model v.2.0.5 module for all its cryptographic operations. Cert. no. 1747 covers Android 4.2 running on ARMv7 CPU with or without NEON optimizations. The module is run in FIPS 140-2 Approved mode of operation. OpenSSL is sourced built and initialised as per FIPS guidelines without any modifications to source. The OpenSSL libraries (libcrypto and libssl) are dynamically linked to the application. The TLS stack uses the OpenSSL module and is built into the application binary. OpenSSL provides the following cryptographic functionality. * —FCS_CKM_EXT.4: Cryptographic key material destruction (Key Material) * —FCS_COP.1(1): Cryptographic Operation (Encryption/Decryption) * FCS_COP.1(2): Cryptographic Operation (Signature Verification) * FCS_COP.1(3): Cryptographic Operation (Cryptographic Hashing) * FCS_COP.1(4): Cryptographic Operation (for keyed-hash Message Authentication) * FCS_RBG_EXT.1: Cryptographic operation (Random Bit Generation) + FCS_TLS_EXT.1: Transport Level Security ST v3.2.docx Page 9 of 37 A Ref: ST001 Security Target Ver: 3.2 04_14_2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 OpenSSL also provides functionality to manage X.509 certificates as per FIA_X509_EXT.1 and iterations. 1.3.1.3.3. Codecs Cellcrypt Mobile for Secret client version 1.0 implements the following codecs: G.711, iLBC, and Speex. 1.3.1.3.4. Cellcrypt Service Engine Main application service, which contains the overall logic for maintaining call state, initiating calls, and interfacing with Ul and audio. The Cellcrypt Service Engine provides the functionality to enable an Enterprise to query the current version of the TOE as per FPT_TUD_EXT.1.1. 1.3.1.3.5. Token Manager Interface logic to a generalized token to request tap, store and retrieve data to/from atoken. Currently the only token interface we use is NFC, which is out of the scope of the ST. 1.3.1.3.6. Connection Generalized logic for call management (setup/teardown). Interfaces SIP specific events to more general call state events. 1.3.1.3.7. Voice A "voice session" type which represents an individual established voice call. In-call events (eventually DTMF handling) would be handled here. Other session types (i.e. Messaging, Video) could be possibly added in future releases. 1.3.1.3.8. Media Manager Manages starting and stopping of ringtones (for incoming calls), and ringing tones (on outgoing calls for far-end ringing, busy tone, fast-busy on network error, etc). 1.3.1.3.9. SRTP Part of the SIP Stack which manages the Secure RTP (encrypted RTP) voice stream. 1.3.1.3.10. RTP Part of the SIP Stack which manages the non-encrypted RTP voice stream. 1.3.1.3.11. SIP user agent client A high level API for constructing SIP multimedia user agent applications. It wraps together the signaling and media functionalities into a call API, interfacing with the lower level SIP and RTP. ST v3.2.docx Page 10 of 37 Ref: ST001 A Security Target Ver: 3.2 04_14 2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 1.3.1.4 External Infrastructure Components 1.3.1.4.1. SIP Server All secure mobile call requests are handled by (SIP) Server (Please see Figure 1). The SIP Server actsas a SIP Registrar/Proxy to provide device registration and coordination of calls between User Equipment. 1.4 TOE Description The Target of Evaluation (TOE) is the Cellcrypt Mobile for Secret client version 1.0 smartphone application, which will run on an Android 4.2 (API 17) based platform. The Cellcrypt Mobile for Secret client version 1.0 application is a software cryptographic application for smartphones, which enables users to have secure voice calls on an end-to-end encrypted session. The logical scope of the TOE comprises: * Authenticated connection set-up with a SIP server * End-to-end encryption used by the TOE when encrypting/decrypting secure voice traffic The TOE achieves authenticated connection using the Identification and authentication (FIA) security functions (SF). X.509 Certificates are used to identify and authenticate each user (FIA_X509_EXT.1) to establish a Trusted Path/Channel (FTP) between the TOE and the SIP Server with TLS (SF FTP_ITC.1(2)). A user password is used to identify and authenticate each user to the SIP Server as part of the Session Initiation Protocol (SIP) Client (FIA_SIPC_EXT.1). Cellcrypt Mobile for Secret client version 1.0 requests that the user inputs her password whenever the TOE requires it. The TOE achieves end-to-end encryption using the Trusted Path/Channel (FTP) SFs. The TOE establishes a trusted channel with the SIP Server using Inter-TSF Trusted Channel TLS/SIP (FTP_ITC.1(2)). The TOE establishes a trusted channel with another TOE on a secure voice call using Inter-TSF Trusted Channel SDES-SRTP (FTP_ITC.1(1)). These SFs depend on Cryptographic Support (FCS): FCS-CKM_EXT.4, FCS_COP1(1-4), FCS_RBG_EXT.1, FCS_SRTP_EXT.1, FCS_TLS_EXT.1, and Trusted Update of the TOE (FPT_TUD_EXT.1). ST v3.2.docx Page 11 of 37 Ref: ST001 A Security Target Ver: 3.2 04_14 2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 2 CONFORMANCE CLAIMS 2.1 CC Conformance Claim This ST and the TOE it describes are conformant to the following CC specifications: * Common Criteria for Information Technology Security Evaluation Part 2: Security Functional Components, September 2012, Version 3.1, Revision 4, CCMB-2012-09-002 o Part 2 Conformant with additional extended functional components. * Common Criteria for Information Technology Security Evaluation Part 3: Security Assurance Components, September 2012, Version 3.1, Revision 4, CCMB-2012-09-003 2.2 Protection Profile Claim The TOE claims to be strictly compliant with all the requirements as specified in the Protection Profile for Mobility — Voice Over IP Application, PP_MOBILITY_VOIP_V0.6, 2013- 01 -28. [1]. 2.3 Package Claim The ST does not claim to be conformant with any pre-defined packages. 2.4 Conformance Rationale This security target claims strict conformance to only one PP [PP_MOBILITY_VOIP_VO0.6] [1]. The security problem definition of this security target is consistent with the statement of the security problem definition in the PP, as the security target claims strict conformance to the PP and no other threats, organizational security policies and assumptions are added. The security objectives of this security target are consistent with the statement of the security objectives in the PP as the security target claims strict conformance to the PP and no other security objectives are added. The security requirements of this security target are consistent with the statement of the security requirements in the PP as the security target claims strict conformance to the PP. ST v3.2.docx Page 12 of 37 Ref: STO01 A Security Target Ver: 3.2 04_14 2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 3 SECURITY PROBLEM DEFINITION This section describes the assumptions and threats that are relevant to both the TOE and its environment. The first section describes the secure usage assumptions, which are those items that the TOE itself cannot implement or enforce. The next two sections cover the threats that are expected to exist in a basic robustness environment and are grouped into threats to be addressed by the TOE and threats to be addressed by the TOE environment. Both the assumptions and the threats are reproduced from the US Government Protection Profile for Security Requirements for Voice Over IP Application, Version 0.6, January 24, 2013. 3.1 Threats addressed by the TOE T.UNAUTHORIZED_ACCESS A user may gain unauthorized access to the TOE data and TOE executable code. A malicious user, process, or external IT entity may masquerade as an authorized entity in order to gain unauthorized access to data or TOE resources. A malicious user, process, or external IT entity may misrepresent itself as the TOE to obtain identification and authentication data. T.UNAUTHORIZED_UPDATE An update may be needed to a specific version of the TOE, but that specific version may not be known to the Enterprise (that is performing the update). 3.2 Organisational Security Policies The PP does not specify any organisational security policies relevant to the operation of the TOE. 3.3 Assumptions The following conditions are assumed to exist in the operational environment. Assumption Name Assumption Description A.AUTHORIZED_USER The cell phone user will follow all provided user guidance. An authorized user is not considered hostile or malicious. A.AVAILABILITY Network resources shall be available to allow VoIP clients to satisfy mission requirements and to transmit information. A.OPER_ENV The operational environment of the TOE appropriately addresses those requirements, threats, and policies not applicable to the TOE itself, but are necessary to support the correct operation of the TOE. A.TRUSTED_ADMIN TOE Administrators are trusted to follow and apply all administrator guidance in a trusted manner. ST v3.2.docx Page 13 of 37 A Ref: ST001 Security Target Ver: 3.2 04_14_2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 4 SECURITY OBJECTIVES This section defines the security objectives for the TOE and its supporting environment. The security objectives are intended to counter identified threats, comply with defined organizational security policies, and address applicable assumptions. The security objectives are reproduced from the US Government Protection Profile for Security Requirements for Voice Over IP Application, Version 0.6, 24% January, 2013. 4.1 Security objectives for the TOE Objective Objective Description O.PROTECTED_COMMUNICATIONS The TOE will provide protected communication channels with authorized IT entities (SIP server and other VOIP applications) O.TRUSTED_UPDATES The TOE will provide the capability to report its current version. Table 1: Security objectives for the TOE 4.2 Security objectives for the operating environment All of the assumptions stated in section 3.1 are considered to be security objectives for the environment. The following are the non-IT security objectives, which, in addition to those assumptions, are to be satisfied without imposing technical requirements on the TOE. That is, they will not require the implementation of functions in the TOE hardware and/or software. Thus, they will be satisfied largely through application of procedural or administrative measures. Objective Objective Description OE.AUTHORIZED_USER The cell phone user of the TOE is non-hostile and follows all user guidance. OE.AVAILABILITY Network resources will be available to allow VoIP clients to satisfy mission requirements and to transmit information. OE.OPER_ENV The operational environment will provide a SIP infrastructure to establish a VoIP connection; a PKI to provide certificates; and an execution domain to support correct operation of the TOE. OE.TRUSTED_ADMIN TOE Administrators are trusted to follow and apply all administrator guidance in a trusted manner. OE.VERIFIABLE_UPDATES The Enterprise will provide the capability to update the TOE after it has determined such an update is necessary. Table 2: Security objectives for the operating environment ST v3.2.docx Page 14 of 37 Ocelicrypt Security Target Ref: ST001 Ver: 3.2 04_14_2014 Cellcrypt Mobile for Secret client version 1.0 4.3 4.3.1 Security Objectives Rationale Summary Mapping of Security Objectives This section provides the summary that all security objectives are traced back to aspects ofthe addressed assumptions, threats, and Organizational Security Policies. Objectives Threats/Assumptions T.UNAUTHORIZED_UPDATE A.AUTHORIZED_USER A.TRUSTED_ADMIN A.AVAILABILITY A.OPER_ENV O.PROTECTED_COMMUNICATIONS X | T.UNAUTHORIZED_ACCESS O.TRUSTED_UPDATES x OE.AUTHORISED_| USER x OE_AVAILABILITY OE.OPER_ENV OE.TRUSTED_ADMIN OE.VERIFIABLE_U PDATES x Table 3: Mapping of Assumptions and Threats to Security Objectives 4.3.2 Security Objectives of the TOE Rationale THREAT / POLICY / AS- SUMPTION ADDRESSED BY RATIONALE T.UNAUTHORIZED_ACCESS A user may gain unauthorized access to the TOE data and TOE executable code. A malicious user, process, or external IT entity may masquerade as an authorized entity in order to gain unauthorized access to data or TOE resources. A mali- cious user, process, or external IT entity may misrepresent itself as the TOE to obtain identifica- tion and authentication data. 0.PROTECTED_COMMUNICATIONS The TOE will provide protected commu- nication channels with authorized IT entities (SIP server and other VOIP ap- plications) O.PROTECTED_COMMUNICATIONS Contributes to mitigating this threat by requiring authorized users access to the SIP server and other VOIP applica- tions. The data and voice paths are protected by a VPN connection. A mu- tually authenticated TLS tunnel further protects the data path. ST v3.2.docx Page 15 of 37 Ocelicrypt Security Target Ref: ST001 Ver: 3.2 04_14_2014 Cellcrypt Mobile for Secret client version 1.0 T.UNAUTHORIZED_UPDATE An update may be needed to a specific version of the TOE, but that specific version may not be known to the Enterprise (that is performing the update). O.VERIFIABLE_UPDATES The TOE will provide the capability to help ensure that the version of the TOE can be verified by the Enterprise. O.TRUSTED_UPDATES Contributes to mitigating this threat by providing a facility to query the ver- sion of software installed. The integrity of origin is also verified when the software is installed. A.AUTHORIZED_USER The cell phone user will follow all provided user guidance. An authorized user is not consid- ered hostile or malicious. OE.AUTHORIZED_USER The cell phone user of the TOE is non- hostile and follows all user guidance. OE.AUTHORIZED_USER Restates the assumption. A.AVAILABILITY Network resources shall be available to allow VoIP clients to satisfy mission requirements and to transmit information. OE.AVAILABILITY Network resources will be available to allow VoIP clients to satisfy mission re- quirements and to transmit information. OE.AVAILABILITY Addresses this assumption by requir- ing that the Enterprise has correctly configured the application to work with the SIP infrastructure and that the SIP infrastructure is operating correctly. A.OPER_ENV The operational environment of the TOE appropriately addresses those requirements, threats, and policies not applicable to the TOE itself, but are necessary to support the correct operation of the TOE. OE.OPER_ENV The operational environment will pro- vide a SIP infrastructure to establish a VoIP connection; a PKI to provide certif- icates; and an execution domain to sup- port correct operation of the TOE. OE.OPER_ENV Addresses this assumption by requir- ing that the SVOIP application is oper- ating within an environment that is compatible with the Protection Profiles for Mobile Device Fundamentals [2] and SIP Server [3] A.TRUSTED_ADMIN TOE Administrators are trusted to follow and apply all adminis- trator guidance in a trusted manner. OE.TRUSTED_ADMIN TOE Administrators are trusted to follow and apply all administrator guidance in a trusted manner. OE.TRUSTED_ADMIN Restates the assumption. Table 4: Mapping of Assumptions and Threats to Objectives ST v3.2.docx Page 16 of 37 Ref: STO01 A Security Target Ver: 3.2 04_14 2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 5 EXTENDED COMPONENTS DEFINITION The TOE implements the following extended components as defined in the PP [1]. Further details including iterations are provided in section 6. Requirement Class Requirement Component FCS: Cryptographic FCS_CKM_EXT.4: Cryptographic key material destruction (Key Material) support FCS_RBG_EXT.1: Cryptographic operation (Random Bit Generation) FCS_SRTP_EXT.1: Secure Real-Time Transport Protocol (SRTP) FCS_TLS_EXT.1: Transport Level Security FIA: Identification and | FIA_SIPC_EXT.1: Session Initiation Protocol (SIP) Client authentication FIA_X5S09_EXT.1 X.509 Certificates FPT: Protection of the FPT_TUD_EXT.1 Extended: Trusted Update TOE security functions Table 5: Extended Components implemented by the TOE [FCS_CKM.1] Cryptographic Key Generation [FCS_CKM.1] is not formally part of the PP — denoted by enclosing in square brackets - so is not formally be included in these Security Requirements. As noted in the PP, the requirements of [FCS_CKM.1] are contained in the PP by reference in the specifications of the underlying protocols (TLS, DTLS and SDES). The TOE is required by the PP to produce random keys and salts as specified in underlying protocols for TLS, DTLS and SDES. [FCS_CKM.1] is satisfied by implementation of FCS_RBG_EXT.1 and iterations as described above. TSF performs all RBG services required by the TOE and these are compliant with the NIST SP 800-90 standard. ST v3.2.docx Page 17 of 37 Ref: STO01 A Security Target Ver: 3.2 04_14 2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 6 SECURITY REQUIREMENTS This section specifies the security requirements for the TOE. The statement of security functional requirements reproduces the security functional requirements (SFRs) specified in the US Government Protection Profile for Security Requirements for Voice Over IP Application with operations completed as appropriate. The requirements are all drawn from the CC Part 2. 6.1 Security functional requirements The following table identifies the security functional requirements that are satisfied by the TOE. Requirement Class Requirement Component FCS: Cryptographic FCS_COP.1(1): Cryptographic Operation (Encryption/Decryption) support FCS_COP.1(2): Cryptographic Operation (Signature Verification) FCS_COP.1(3): Cryptographic Operation (Cryptographic Hashing) FCS_COP.1(4): Cryptographic Operation (for keyed-hash Message Authentication) FCS_RBG_EXT.1: Cryptographic operation (Random Bit Generation) FCS_SRTP_EXT.1: Secure Real-Time Transport Protocol (SRTP) FCS_TLS_EXT.1: Transport Level Security FIA: Identification and | FIA_SIPC_EXT.1: Session Initiation Protocol (SIP) Client authentication FIA_X509_EXT.1 X.509 Certificates FPT: Protection of the FPT_TUD_EXT.1 Extended: Trusted Update TOE security functions FTP: Trusted FTP_ITC.1(1) Inter-TSF Trusted Channel (SDES-SRTP) Path/Channel FTP_ITC.1(2) Inter-TSF Trusted Channel (TLS/SIP) Table 6: Security Functional Requirements 6.1.1 Cryptographic Support (FCS) FCS_CKM_EXT.4 Cryptographic key material destruction (Key Material) FCS_CKM_EXT.4.1 The TSF shall zeroize all plaintext secret and private cryptographic keys and Critical Security Parameters (CSPs) when no longer required. Note that FCS_CKM_EXT.4 depends on [FCS_CKM.1], as justified in the rationale section (6.3). FCS_COP. 1(1) Cryptographic Operation (Encryption/Decryption) FCS_COP.1.1 The TSF shall perform encryption and decryption in accordance with a specified cryptographic algorithm AES operating in CTR and GCM modes and cryptographic key size 128-bits, 256- bits and no other key sizes that meets the following: * FIPS PUB 197 “Advanced Encryption Standard (AES)" * NIST SP 800-38A * NIST SP 800-38D ST v3.2.docx Page 18 of 37 Ref: STO01 A Security Target Ver: 3.2 04_14 2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 FCS_COP.1(2) Cryptographic Operation (Signature Verification) FCS_COP.1.1(2) Refinement: The TSF shall perform cryptographic signature services in accordance with a Elliptic Curve Digital Signature Algorithm (ECDSA) with a key size of 256 bits or greater that meets the following: Case: Elliptic Curve Digital Signature Algorithm *° FIPS PUB 186-3, ‘Digital Signature Standard” * The TSF shall implement “NIST curves” P-256, P-384, and no other curves, (as defined in FIPS PUB 186-3, ‘Digital Signature Standard”) FCS_COP.1(3) Cryptographic Operation (Cryptographic Hashing) FCS_COP.1.1(3) Refinement: The TSF shall perform cryptographic hashing services in accordance with a specified cryptographic algorithm SHA-1, SHA-256, SHA-384, and message digest sizes 160, 256, 384 bits that meet the following: “FIPS Pub 180-3, 'Secure Hash Standard.” FCS_COP. 1(4) Cryptographic Operation (For keyed-hash Message Authentication) FCS_COP.1.1(4) Refinement: The TSF shall perform keyed-hash message authentication in accordance with a specified cryptographic algorithm HMAC-SHA-1 and key size 128 bits, and message digest size 160 bits that meet the following: FIPS Pub 198-1, "The Keyed-Hash Message Authentication Code, and FIPS Pub 180-3, “Secure Hash Standard.” FCS_RBG_EXT.1 Extended: Cryptographic operation (Random Bit Generation) FCS_RBG_EXT.1.1 The TSF shall perform all random bit generation (RBG) services in accordance with NIST Special Publication 800-90 using CTR_DRBG(AES) seeded by an entropy source that accumulates entropy from software-based and operational environment hardware-based noise source. FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded with a minimum number of bits of entropy at least equal to the greatest bit length required by the protocols and functions supported by the TOE. FCS_SRTP_EXT.1 Secure Real-Time Transport Protocol (SRTP) FCS_SRTP_EXT.1.1 The TSF shall implement the Secure Real-Time Transport Protocol (SRTP) that complies with RFC 3711, and use Security Descriptions for Media Streams (SDES) in compliance with RFC 4568 to provide key information for the SRTP connection. FCS_SRTP_EXT.1.2 The TSF shall implement SDES-SRTP supporting the following ciphersuites in accordance with RFC 4568: AES_CM_128_HMAC_SHA1_80. FCS_SRTP_EXT.1.3 The TSF shall ensure the SRTP NULL algorithm shall be disabled. FCS_SRTP_EXT.1.4 The TSF shall allow the SRTP ports to be used for SRTP communications to be specified by the Enterprise. FCS_TLS_EXT .1 Transport Level Security FCS_TLS_EXT.1.1 The TSF shall implement the TLS 1.2 protocol (RFC 5246) compliant with Suite B Profile for TLS (RFC 6460) using mutual authentication with certificates and ciphersuites: ST v3.2.docx Page 19 of 37 Ref: ST001 A Security Target Ver: 3.2 04_14 2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 Mandatory ciphersuites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 using the 256-bit prime modulus elliptic curve specified in FIPS-186-2; TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 using the 384-bit prime modulus elliptic curve specified in FIPS-186-2; Optional Ciphersuites: TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 TLS_DHE_DSS_WITH_AES_256_GCM_SHA38 TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_RSA_WITH_AES_128_CBC_SHA TLS_ECDH_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 ST v3.2.docx Page 20 of 37 Ref: ST001 A Security Target Ver: 3.2 04_14 2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 6.1.2 Identification and Authentication (FIA) FIA_SIPC_EXT.1 Session Initiation Protocol (SIP) Client FIA_SIPC_EXT.1.1 The TSF shall implement the Session Initiation Protocol (SIP) that complies with RFC 3261 using the Session Description Protocol (SDP) complying with RFC 4566 to describe the multimedia session that will be used to carry the VOIP traffic. FIA_SIPC_EXT.1.2 The TSF shall require the user to enter a password to support the use of password authentication for SIP REGISTER function requests as specified in section 22 of RFC 3261. FIA_SIPC_EXT.1.3 The TSF shall support SIP authentication passwords that contain at least 8 characters in the set of {upper case characters, lower case characters, numbers, and the following special characters ,“@”,"#","S", “96" ",“&”,"*”,"(", and ")" and no other characters}. FIA_SIPC_EXT.1.4 Password entered by the user as per FIA_SIPC_EXT.1.2 shall be cleared by the TSF once the TSF is notified that the REGISTER request was successful. X509 Certificates (FIA_X509_EXT) The certificates used by the TSF are those for the distant end TLS connection and the user’s certificate (and associated private key). While it is acceptable for the TSF itself to store and protect these certificates, it is also allowable for the Mobile OS to provide these storage and protection functions. If the TSF provides these functions, then the FIA_X509_EXT.1.Y element shall be included in the body of the ST in this component. FIA_X509EXT.1 Extended: X509 certificates FIA_X509_EXT.1.Y elements have been included as the TSF relies on itself to provide the storage and protection functions. FIA_X509_EXT.1.Y The TSF shall store and protect the certificate(s) from unauthorized deletion and modification. FIA_X509_EXT.1.1 The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for TLS connections. FIA_X509_EXT.1.2 The TSF shall provide the capability for the Enterprise to load the X.509v3 certificates into the TOE for use by the security functions specified in the PP. ST v3.2.docx Page 21 of 37 Ref: STO01 A Security Target Ver: 3.2 04_14 2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 FIA_X509_EXT.1.3 The TSF shall validate the certificate using the Online Certificate Status Protocol (OCSP) as specified in RFC2560 , a Certificate Revocation List (CRL) as specified in RFC 5759. FIA_X509_EXT.1.4. The TSF shall not establish a TLS connection if a certificate is deemed invalid. FIA_X509_EXT.1.5 When the TSF cannot establish a connection to determine the validity of a certificate, the TSF shall, as configured by the Enterprise, establish the TLS connection or disallow the establishment of the TLS connection. 6.1.3 Protection of the TOE Security Functions (FPT) FPT_TUD_EXT .1 Extended: Trusted Update FPT_TUD_EXT.1.1 The TSF shall provide the Enterprise the ability to query the current version of the TOE software. 6.1.4 Trusted Path/Channel (FTP) FTP_ITC.1(1) Inter-TSF Trusted Channel (SDES-SRTP) FTP_ITC.1.1(1) Refinement: The TSF shall provide a communication channel between itself and a remote VoIP application using SDES-SRTP as specified in FCS_SRTP_EXT.1 that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification and disclosure. FTP_ITC.1.2(1) The TSF shall permit the TOE or the remote VoIP application to initiate communication via the trusted channel. FTP_ITC.1.3(1) The TSF shall initiate communication via the trusted channel for all communications between the two devices. FTP_ITC.1(2) Inter-TSF Trusted Channel (TLS/SIP) FTP_ITC.1.1(2) Refinement: The TSF shall provide a communication channel between itself and a SIP Server using TLS “and no other protocol”, as specified in FCS_TLS_EXT.1 “only”, that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification and er disclosure. FTP_ITC.1.2(2) The TSF shall permit the TSF to initiate communication via the trusted channel. FTP_ITC.1.3(2) The TSF shall initiate communication via the trusted channel for all communications with the SIP server. ST v3.2.docx Page 22 of 37 Ref: STO01 A Security Target Ver: 3.2 04_14 2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 6.2 Security Assurance Requirements All assurance requirements are summarized in the table below. Requirement Class Requirement Component ADV: Development ADV_FSP.1: Basic Functional Specification AGD: Guidance Documents AGD_OPE.1: Operational User Guidance AGD_PRE.1: Preparative User Guidance AVA: Vulnerability assessment AVA_VAN.1: Vulnerability Analysis ALC: Lifecycle support ALC_CMC.1: Labelling of the TOE ALC_CMS.1: TOE CM Coverage ATE: Tests ATE_IND.1: Independent Testing - Conformance Table 7: Assurance Requirements 6.2.1 Class ADV: Development 6.2.1.1 ADV_FSP.1 Basic Functional Specification Developer action elements: ADV_FSP.1.1D The developer shall provide a functional specification. ADV_FSP.1.2D The developer shall provide a tracing from the functional specification to the SFRs. Content and presentation elements: ADV_FSP1.1C The functional specification shall describe the purpose and method of use for each SFR-enforcing and SFR-supporting TSFI. ADV_FSP.1.2C The functional specification shall identify all parameters associated with each SFR- enforcing and SFR-supporting TSFI. ADV_FSP.1.3C The functional specification shall provide rationale for the implicit categorization of interfaces as SFR-non-interfering. ADV_FSP.1.4C The tracing shall demonstrate that the SFRs trace to the TSFls in the functional specification. Evaluator action elements: ADV_FSP.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ADV_FSP.1.2E The evaluator shall determine that the functional specification is an accurate and ST v3.2.docx Page 23 of 37 Ref: STO01 A Security Target Ver: 3.2 04_14 2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 complete instantiation of the SFRs. 6.2.2 Class AGD: Guidance Documents 6.2.2.1 AGD_OPE.1 Operational User Guidance Developer action elements: AGD_OPE.1.1D The developer shall provide operational user guidance. Content and prese ntation elements: AGD_OPE.1.1C The operational user guidance shall describe what the authorized user-accessible functions and privileges that should be controlled in a secure processing environment, including appropriate warnings. AGD_OPE.1.2C The operational user guidance shall describe, for the authorized user, how to use the available interfaces provided by the TOE in a secure manner. AGD_OPE.1.3C The operational user guidance shall describe, for the authorized user, the available functions and interfaces, in particular all security parameters under the control of the user, indicating secure values as appropriate. AGD_OPE.1.4C The operational user guidance shall, for the authorized user, clearly present each type of security-relevant event relative to the user-accessible functions that need to be performed, including changing the security characteristics of entities under the control of the TSF. AGD_OPE.1.5C The operational user guidance shall identify all possible modes of operation of the TOE (including operation following failure or operational error), their consequences and implications for maintaining secure operation. AGD_OPE.1.6C The operational user guidance shall, for the authorized user, describe the security measures to be followed in order to fulfil the security objectives for the operational environment as described in the ST. AGD_OPE.1.7C The operational user guidance shall be clear and reasonable. Evaluator action elements: AGD OPE.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ST v3.2.docx Page 24 of 37 Ref: STO01 A Security Target Ver: 3.2 04_14 2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 6.2.2.2 AGD_PRE.1 Preparative procedures Developer action elements: AGD_PRE.1.1D The developer shall provide the TOE including its preparative procedures. Content and presentation elements: AGD_PRE.1.1C The preparative procedures shall describe all the steps necessary for secure acceptance of the delivered TOE in accordance with the developer's delivery procedures. AGD_PRE.1.2C The preparative procedures shall describe all the steps necessary for secure installation of the TOE and for the secure preparation of the operational environment in accordance with the security objectives for the operational environment as described in the ST. Evaluator action elements: AGD_PRE.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation evidence. 6.2.3 Class AVA: Vulnerability Assessment 6.2.3.1 AVA_VAN.1 Vulnerability survey Developer action elements: AVA_VAN.1.D The developer shall provide the TOE for testing. Content and presentation elements: AVA_VAN.1.1C The TOE shall be suitable for testing. Evaluator action elements: AVA_VAN.1.1E The evaluator shall confirm that the information provided meets all the requirements for content and presentation of evidence. AVA_VAN.1.2E The evaluator shall perform a search of public domain sources to identify potential ST v3.2.docx Page 25 of 37 Ref: STO01 A Security Target Ver: 3.2 04_14 2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 vulnerabilities in the TOE. AVA_VAN.1.3E The evaluator shall conduct penetration testing, based in the identified potential vulnerabilities, to determine that the TOE is resistant to attacks performed by an attacker possessing Basic attack potential. 6.2.4 Class ALC: Life-Cycle Support 6.2.4.1 ALC_CMC.1 Labelling of the TOE Developer action elements: ALC_CMC.1.1D The developer shall provide the TOE and a reference for the TOE. Content and presentation elements: ALC_CMS.2.1D The developer shall provide a configuration list for the TOE. Evaluator action elements: ALC_CMC.2.1E The evaluator shall conform that the information provided meets all the requirements for content and presentation of evidence. 6.2.4.2 ALC_CMS.1 TOE CM coverage Developer action elements: ALC_CMS.2.1D The developer shall provide a configuration list for the TOE. Content and presentation elements: ALC_CMS.2.1C The configuration list shall include the following: the TOE itself, and the evaluation evidence required by the SARs. ALC_CMS.2.2C The configuration list shall uniquely identify the configuration items. Evaluator action elements: ALC_CMS.2.1E The evaluator shall confirm that the information provided meets all requirements ST v3.2.docx Page 26 of 37 A Ref: ST001 Security Target Ver: 3.2 04_14_2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 for content and presentation of evidence. 6.2.5 Class ATE: Test 6.2.5.1 ATE_IND.1 Independent testing — Conformance Developer action elements: ATE_IND.1.1D The developer shall provide the TOE for testing. Content and presentation elements: ATE_IND.1.1C The TOE shall be suitable for testing. Evaluator action elements: ATE_IND.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ATE_IND.1.2E The evaluator shall test a subset of the TSF to confirm that the TSF operates as specified. 6.3 Security Requirements Rationale The RATIONALE Section of the Security Requirements for Voice Over IP Application PP provides ra- tionale for the security requirements, demonstrating that the security requirements are suitable to ad- dress the IT security objectives. This rationale is valid for the PP requirements reproduced in the ST and is not further discussed. FCS_CKM_EXT.4 dependency on FCS_CKM.1 is satisfied by reference in the specification of the underly- ing protocols. This approach is dictated by the PP. ST v3.2.docx Page 27 of 37 Ref: ST001 A Security Target Ver: 3.2 04_14 2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 7 TOE SUMMARY SPECIFICATION Cellcrypt Mobile for Secret client version 1.0 is a Secure Voice over Internet Protocol (SVoIP) application for smartphones, which enables users to have secure voice calls on an end-to-end encrypted session. Cellcrypt Mobile for Secret client version 1.0 meets the requirements of the Protection Profile for secure VoIP Application [1], and is intended to operate in an environment specified by the Protection Profile for Mobile Device Fundamentals [2], and the Protection Profile for SIP Server [3]. The scope of evaluation is primarily applicable to Cellcrypt Mobile for Secret client version 1.0 running on a smartphone. The functionalities performed by other system components (Mobile OS, SIP Server, Certificate Authority, Mobile Device Manager) are beyond the scope of the evaluation. 7.1 Secure Services: The Cellcrypt Mobile for Secret client version 1.0 application enables encrypted peer-to-peer voice (secure Voice over Internet Protocol (VoIP)) calls between mobile handsets. The application implements the following secure services: * Secure Client Registration and Call Signalling (data tunnel) * Secure Session Key negotiation between the clients (voice tunnel) * Encryption of the media stream (voice tunnel) The application relies on authenticated connection setup over a VPN tunnel to be provided by the infrastructure. Mobile handset device with Cellcrypt Mobile for Secret application Mobile handset device with Cellerypt Mobile for Secret application IPSec tunnel IPSec tunnel ——— Voice Tunnel — Data Tunnel Figure 3: Two tunnels of the enterprise mobility solution encapsulated by a VPN ST v3.2.docx Page 28 of 37 Ref: ST001 A Security Target Ver: 3.2 04_14 2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 7.2 TOE Security functions 7.2.1 Cryptographic Support All cryptographic functions used by the TOE, viz., implementation of SIP TLS tunnel and media encryption/decryption are performed by a FIPS 140-2 approved crypto library running in FIPS Approved mode. The Cellcrypt Mobile for Secret client version 1.0 application uses the OpenSSL FIPS Object module v2.0.5, (FIPS Certificate No. 1747), which supports all crypto functions required in the Protection Profile. The software (TOE) will be run without modification on Android Jellybean 4.2 (API 17) running on an ARMV7 CPU with or without NEON optimization. The table below gives the corresponding FIPS/CAVP algorithm certificate numbers where applicable. The deterministic RBG used by OpenSSL is seeded using a hardware entropy source with a minimum number of bits of entropy at least equal to the greatest bit length required by the protocols and functions supported by the TOE. Cellcrypt Mobile for Secret accumulates this hardware entropy from the phone’s microphone. On initial start up of the application, the microphone is sampled for 30 seconds. The raw audio samples are combined with device entropy, and cryptographically hashed to generate the initial seed. The OpenSSL FIPS Object Modules v2.0.5 was sourced, compiled, installed, and used in accordance to the guidance provided by the “User Guide for the OpenSSL FIPS Object Module v2.0 (including v2.0.1, v2.0.2, v2.0.3, v2.0.4, v2.0.5)”, and the “OpenSSL FIPS 140-2 Security Policy”. Specifically, + The source code was obtained via “trusted path” by the vendor of record (OpenSSL Software Foundation) on physical media (CD). * The source file openssl-fips-2.0.5.tar.gz has been verified to have the correct SHA-1 digest of 8b44f2a43d098f6858eb1ebe77b73f8f027a9c29. * The OpenSSL FIPS Object Module has been compiled using the Android NDK, which includes gcc 4.6, using the specified build procedure. * The FIPS_mode_set() function at runtime validates the embedded HMAC-SHA-1 digest with a digest generated from the FIPS Object Module object code. The Cryptographic support security function is designed to satisfy the following security functional re- quirements as summarised in the table below: Requirement | Requirement Cellcrypt Mobile for Secret Implementation Certificate # Class Component FCS: FCS_CKM_EXT.4: Zeroization of all CSPs is performed by the OpenSSL v2.0.5 | FIPS #1747 Cryptographic | Cryptographic key FIPS object module. (covers Android support material destruction (Key 4.2 running on an ARMV7 CPU architecture with or without NEON optimizations) Material) The following CSPs are used by Cellcrypt Mobile for Secret: * ECDSA SGK: ECDSA (All NIST defined B, K, and P curves) signature generation key * AES EDK: AES encrypt / decrypt key * HMAC Key: Keyed hash key + CTR_DRBG CSPs: V and Key (AES), entropy input (length dependent on security strength) ST v3.2.docx Page 29 of 37 Ocelicrypt Ref: ST001 Security Target Ver: 3.2 04_14_2014 Cellcrypt Mobile for Secret client version 1.0 FCS_COP.1(1): Cryptographic Operation (Encryption/Decryption) AES implemented via OpenSSL v2.0.5 FIPS object module (FIPS #1747). CAVP #1884, #2116, #2234, #2342, #2394, #2484 FCS_COP.1(2): ECDSA implemented via OpenSSL v2.0.5 FIPS object module _| CAVP #264, Cryptographic Operation | (FIPS #1747). #270, #315, (Signature Verification) #347, 4378, #383, #394, #413 FCS_COP.1(3): SHA implemented via OpenSSL v2.0.5 FIPS object module CAVP #1655, Cryptographic Operation (Cryptographic Hashing) (FIPS #1747). #1840, #1923, #2019, #2056, #2102 FCS_COP.1(4): Cryptographic Operation (for keyed-hash Message Authentication) HMAC implemented via OpenSSL v2.0.5 FIPS object module (FIPS #1747). CAVP #1126, #1288, #1363, #1451, #1485, #1526 FCS_RBG_EXT.1: Cryptographic operation (Random Bit Generation) CTR_DRBG(AES) implemented via OpenSSL v2.0.5 FIPS object module (FIPS #1747). CAVP #157, #229, #264, #292, #316, #342 FCS_SRTP_EXT.1: Secure Real-Time Transport Protocol (SRTP) Implemented via PJSIP v2.1 library that relies on the OpenSSL v2.0.5 FIPS object module (FIPS #1747). Cellcrypt Mobile for Secret client version 1.0 implements Secure Real Time Transport Protocol (SRTP) using the PJSIP v 2.1 library. PISIP is compatible with SRTP ( RFC 3711) and SRTP SDES ( RFC 4568). PJSIP uses the OpenSSL FIPS Object module to provide cryptographic functionality as required in the standards. The following mandatory ciphersuite is implemented: AES_CM_128_HMAC_SHA1_80 N/A FCS_TLS_EXT.1: Transport Level Security Implemented via OpenSSL v2.0.5 FIPS object module running in FIPS Approved mode (FIPS #1747). Cellcrypt Mobile for Secret client version 1.0 supports TLS 1.2 protocol (RFC 5246) compliant with Suite B Profile for TLS implements the TLS 1.2 protocol (RFC 5246) compliant with Suite B Profile for TLS (RFC 6460) using mutual authentication with certificates and all the mandatory ciphersuites as listed below. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 using the 256-bit prime modulus elliptic curve specified in FIPS-186-2; TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 using the 384-bit prime modulus elliptic curve specified in FIPS-186-2; N/A FCS_CKM_.1: Cryptographic Key Generation Implemented via OpenSSL v2.0.5 FIPS object module running in FIPS Approved mode (FIPS #1747). Celicrypt Mobile for Secret client version 1.0 generates all random keys and salts as per NIST SP 800-90 CTR_DRBG(AES) using a hardware based entropy source. N/A ST v3.2.docx Page 30 of 37 Ref: ST001 A Security Target Ver: 3.2 04_14 2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 Table 8: Implementation of Cryptographic Support The TOE is designed to zeroize secret and private keys when they are no longer required by the TOE. The following table summarizes how the values are zeroized. CSP CSP use Where stored When Zeroized How Zeroized Symmetric key HMAC authentication | RAM After call Overwrite with for SRTP stream terminates. ‘0’ 2 times Symmetric key AES Encrypt/decrypt |RAM After call Overwrite with SRTP stream terminates. ‘0’ 2 times Symmetric key Encrypt/decrypt TLS |RAM After TLS Overwrite with data stream to SIP session ‘0’ 2 times Server terminates. Private key TLS connection to SIP |RAM and RAM: after TLS |RAM: Overwrite Server encrypted Flash on | session with ‘0’ 2 times filesystem terminates. Flash: Mobile Flash: on Device OS application dependent uninstallation. Seed file Seed data for PRNG |RAM and On application |Mobile Device encrypted Flash on |uninstallation. |OS dependent filesystem Table 9: Zeroization 7.2.2 Protected communications 7.2.2.1 VPN tunnel The Cellcrypt Mobile for Secret client version 1.0 application connects to the enterprise (SIP Server and other clients) with layered encryption and authentication. All data between Cellcrypt Mobile for Secret client version 1.0 clients and the Enterprise Infrastructure is protected in an IPSec Virtual Private Network (VPN) tunnel. The IPSec VPN connection must be established before connections to enterprise services are permitted. Within the VPN tunnel, application traffic is encrypted to provide an additional layer of protection. 7.2.2.2 Inter-TSF Trusted Channel (SDES -SRTP) Cellcrypt Mobile for Secret client version 1.0 is a standards-based secure VolP client, which supports SDES and SRTP. The Inter-TSF Trusted Channel (SDES-SRTP) security function is designed to satisfy the following security functional requirements: FTP_ITC.1.1(1), FTP_ITC.1.2(1), FTP_ITC.1.3(1). The SRTP ciphers and keys are negotiated using SDES (RFC 4568), as part of the Session Description Protocol (SDP) attachment of the SIP messages. The keying information is protected by the TLS session ST v3.2.docx Page 31 of 37 Ref: ST001 A Security Target Ver: 3.2 04_14 2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 encrypting the SIP link, and is being exchanged between two strongly authenticated endpoints through the SIP server. The calling client will append the SDES “crypto” header to the outgoing INVITE message, specifying its ciphersuite and encryption key. The SIP Server will process and route this message to the called client. Upon receiving an INVITE with an SDES “crypto” header, the TOE will validate that it supports the offered ciphersuite, and use the key as appropriate. On the call being answered, the called client will append the SDES “crypto” header to the outgoing 200 OK message, specifying its ciphersuite and encryption key. The calling client will validate that it supports the offered ciphersuite, and use the key as appropriate. Cellcrypt Mobile for Secret requires the use of SRTP (an RTP only stream is not allowable), and the NULL ciphersuite has been disabled. The only allowable ciphersuite supported by the TOE is: AES_CM_128_HMAC_SHA1_80. If an unsupported (or NULL) ciphersuite is offered, the TOE will reject the call. The SRTP UDP port is configurable by the enterprise. The default configuration is to use an ephemeral port (i.e. the port number used may vary per call). If an explicit port is specified in the settings, the TOE will only use the configured port value. 7.2.2.3 Inter-TSF Trusted Channel (TLS/SIP) Cellcrypt Mobile for Secret is a standards-based secure VoIP client, which supports SIP over TLS 1.2. The Inter-TSF Trusted Channel (TLS/SIP) security function is designed to satisfy the following security functional requirements: FTP_ITC.1.1(2), FTP_ITC.1.2(2), FTP_ITC.1.3(2). 7.2.3 Identification and authentication 7.2.3.1 SIP Client Cellcrypt Mobile for Secret client version 1.0 requires a SIP client authentication password to be entered in order to connect to the SIP server. The user is prompted to manually enter their SIP client authentication password, which is used for authentication in REGISTER requests, whenever registration is required. The SIP client authentication password needs to be sent regularly (in REGISTER and other SIP messages as per the SIP protocol) to the SIP proxy in order to maintain the connection with the SIP server and for the VoIP service to operate. In this regard these messages behave as ‘keep alive’ messages. In the evaluated default configuration, the password will need to be re-entered by the user for each REGISTER request. The Identification and Authentication security function is designed to satisfy the following security functional requirements: FIA_SIPC_EXT.1.1, FIA_SIPC_EXT.1.2, FIA_SIPC_EXT.1.3, FIA_SIPC_EXT.1.4. Once registered to the SIP server, the TOE is available to make or receive calls. ST v3.2.docx Page 32 of 37 Ref: ST001 A Security Target Ver: 3.2 04_14 2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 To initiate a call, the user dials another user’s SIP address. The TOE generates a SIP INVITE request and sends it to the SIP server. The SIP server processes and routes the INVITE message (including SDP) to the called party. On receiving an incoming INVITE request, the receiving TOE processes the message. If acceptable, and the client is available to take incoming calls, the user will be alerted by ringing the phone. The user has the choice of rejecting the call, or accepting the call. If the user rejects the call, a 603 “Call Declined” message is returned, and the call is torn down. If the call is accepted, the called TOE will send back a 200 OK with SDP, and encrypted media streams are established peer-to-peer. Once a call has been established, either side may terminate the call, which initiates a SIP BYE/200 exchange, tearing down the media streams, and the call. 7.2.3.2 X.509v3 Certificates The TSF uses X.509v3 uses certificates to authenticate the user to the SIP server via a mutually authenticated TLS connection. Both the Users Private Key file and the certificate for the TLS connection are stored and protected by the TSF itself. The TOE allows setting of the path for X.509v3 certificate and users Private key file for the TLS connection used by the TSF. The long-lived TLS certificates and private key are stored encrypted in the TOE private area of the filesystem on the phone’s flash-memory. The private key is removed by uninstalling the application, which is the responsibility of the Mobile Device Platform, outside of the scope of the TOE. The certificates and private keys are decrypted and loaded from Flash into RAM by the TOE to use it in order to establish a TLS connection. The TSF performs validity checks on the CA path and that either the SubjectAltName or SubjectDN match what was provided on the distant connection certificate. The TSF also performs OCSP or CRL (whichever is available) validity checks on the certificate. Connection attempts are made only if the certificate is deemed valid. In the case where it is not possible to check the validity of the Certificate via an online check the TSF will either attempt to establish a TLS connection or not dependent on whether this is configured by the Enterprise. The Identification and Authentication security function is designed to satisfy the following security functional requirements: FIA_X509_EXT.1.Y, FIA_X509_EXT.1.1, FIA_X509_EXT.1.2, FIA_X509_EXT.1.3, FIA_X509_EXT.1.4, FIA_X509_EXT.1.5. 7.2.4 TSF protection 7.2.4.1 Integrity of origin Cellcrypt digitally signs the Cellcrypt Mobile for Secret application to provide integrity of origin. The operating system on the device verifies the signature whenever it installs the Cellcrypt Mobile for Secret application. Installation can complete only if this verification succeeds. ST v3.2.docx Page 33 of 37 Ref: ST001 A Security Target Ver: 3.2 04_14 2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 7.2.4.2 TOE software version information The user can verify the version of Cellcrypt Mobile for Secret that is running on their device. Version and device ID information can be obtained by displaying the details in the application settings menu. This process ensures that an administrator can verify that all updates are unaltered and from a trusted source, and it prevents: ® An adversary from making unauthorized updates to the Cellcrypt Mobile for Secret application. * A malicious user, process, or external IT entity misrepresenting itself as the application to obtain identification and authentication data. The TOE version information is also provided to the Android Operating System using the standard An- droid application APIs. The enterprise can use an MDM to obtain the version information of the TOE from the OS. The TSF protection security function is designed to satisfy the following security functional requirement: FPT_TU D_EXT.1.1. 7.2.5 TOE Documentation Cellcrypt offers a User and Administrator guide for the Cellcrypt Mobile for Secret client version 1.0 product. This describes how the Enterprise may Provision, Install, Configure and Operate the product ST v3.2.docx Page 34 of 37 Ref: STO01 A Security Target Ver: 3.2 04_14 2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 8 APPENDIX A - TERMINOLOGY AND ACRONYMS Term Description AES Advanced Encryption Standard CA Certificate Authority CAVP Cryptographic Algorithm Validation Program cc Common Criteria for Information Technology Security Evaluation CIK Crypto Ignition Key CM Cellcrypt Mobile CRADA Cooperative Research And Development Agreement DTLS-SRTP |Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP), (RFC 5764) FIPS Federal Information Processing Standard KEK Key Encryption Key NAT Network Address Translation NIAP National Information Assurance Partnership NIST National Institute of Standards and Technology PKI Public Key Infrastructure PP NIAP Protection Profiles PRNG Pseudo-Random Number Generator RNG Random Number Generator RTP Real Time Protocol (RFC 3550) SDES SDP Security Descriptions for Media Streams (RFC 4568) SDP Session Description Protocol (RFC 4566) SIP Session Initiation Protocol (RFC 3261) SRTP Secure Real Time Protocol (RFC 3711) STUN Session Traversal Utilities for NAT SVoIP Secure Voice over Internet Protocol TEE ARM Trusted Execution Environment TOE Target Of Evaluation TSF TOE Security Functions VPN Virtual Private Network VoIP Voice over Internet Protocol ST v3.2.docx Page 35 of 37 Ref: ST001 A Security Target Ver: 3.2 04_14 2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 9 APPENDIX B — REFERENCED DOCUMENTS [1] Protection Profile for Mobility — Voice Over IP Application, PP_MOBILITY_VOIP_V0.6, 2013- 01 - 28. [2] Protection Profile for Mobile Device Fundamentals, PP_MD_V1.1, 2014-02-24. [3] Protection Profile - Network Device Protection Profile (NDPP) Extended Package SIP Server Version 1.0, 2013-02-06. NIST Special Publication 800-53 - Security and Privacy Controls for Federal Information Systems and Organizations, Revision 4, April 2013. [4 ST v3.2.docx Page 36 of 37 A Ref: ST001 Security Target Ver: 3.2 04_14_2014 \ Cellerypt Cellcrypt Mobile for Secret client version 1.0 10 APPENDIX C — NIST SP 800-53/CNSS 1253 MAPPING Several of the NIST SP 800-53/CNSS 1253 controls [4] are either fully or partially addressed by the TOE. This section outlines the requirements that are addressed when the TOE is incorporated into its operational configuration. The following table is taken from the Protection Profile, [1]. r Name Applicable SFRs Information Flow FTP_ITC.1(*) Enforcement SC-8 Transmission Integrity |FCS_COP.1(2), FCS_COP.1(3), FCS_COP.1(4), FCS_TLS_EXT.1.1, FTP_ITC.1(*), FCS_COMM_PROT_EXT.1,FCS_SIP_EXT.1, FCS_SRPT_EXT.1.1, FCS_DTLS_EXT.1 sc-9 Transmission FCS_COP.1(1), FCS_SRTP_EXT.1, FCS_SIP_EXT.1, FTP_ITC.1(*), Confidentiality FCS_TLS_EXT.1, FCS_COMM_PROT_EXT.1, FCS_DTLS_EXT.1 Sc-12 Cryptographic Key FCS_TLS_EXT.1, FCS_CKM.1, FCS_CKM_EXT.4, Establishment and FCS_COMM_PROT_EXT.1, FCS_RBG_EXT.1, FCS_DTLS_EXT.1 Management SC-13 Use of Cryptography FCS_COP.1(*), FIA_UAU.5, FPT_TUD_EXT.1 END OF DOCUMENT ST v3.2.docx Page 37 of 37