Cisco Jabber for Windows Security Target Page 1 of 41 Cisco Jabber for Windows Security Target Version 1.0 12 November 2015 EDCS - 1502603 Cisco Jabber for Windows Security Target Page 2 of 41 Table of Contents 1 SECURITY TARGET INTRODUCTION .............................................................................8 1.1 ST and TOE Reference .................................................................................................... 8 1.2 TOE Overview ................................................................................................................. 8 1.2.1 TOE Product Type .................................................................................................... 9 1.2.2 Supported non-TOE Hardware/ Software/ Firmware............................................... 9 1.3 TOE DESCRIPTION....................................................................................................... 9 1.4 TOE Evaluated Configuration........................................................................................ 10 1.5 Logical Scope of the TOE Platform............................................................................... 11 1.5.1 Cryptographic Support............................................................................................ 12 1.5.2 User Data Protection............................................................................................... 12 1.5.3 Identification and authentication............................................................................. 12 1.5.4 Security Management ............................................................................................. 12 1.5.5 Protection of the TSF.............................................................................................. 13 1.5.6 Trusted path/Channels ............................................................................................ 13 1.6 Logical Scope of the TOE Client Platform.................................................................... 13 1.6.1 Cryptographic Support............................................................................................ 13 1.6.2 User Data Protection............................................................................................... 14 1.6.3 Identification and authentication............................................................................. 14 1.6.4 Security Management ............................................................................................. 14 1.6.5 Protection of the TSF.............................................................................................. 14 1.6.6 Trusted Path/Channels ............................................................................................ 15 1.7 Excluded Functionality .................................................................................................. 15 2 Conformance Claims.............................................................................................................16 2.1 Common Criteria Conformance Claim .......................................................................... 16 2.2 Protection Profile Conformance..................................................................................... 16 2.3 Protection Profile Conformance Claim Rationale.......................................................... 16 2.3.1 TOE Appropriateness.............................................................................................. 16 2.3.2 TOE Security Problem Definition Consistency...................................................... 16 2.3.3 Statement of Security Requirements Consistency.................................................. 16 3 SECURITY PROBLEM DEFINITION................................................................................17 3.1 Assumptions................................................................................................................... 17 3.2 Threats............................................................................................................................ 17 3.3 Organizational Security Policies.................................................................................... 18 4 SECURITY OBJECTIVES...................................................................................................19 4.1 Security Objectives for the TOE .................................................................................... 19 4.2 Security Objectives for the Environment....................................................................... 19 5 SECURITY REQUIREMENTS ...........................................................................................21 5.1 Conventions.................................................................................................................... 21 5.2 TOE Security Functional Requirements ........................................................................ 21 5.3 SFRs Drawn from VoIP PP for VoIP Applications (TOE)............................................ 22 5.3.1 Cryptographic Support (FCS)................................................................................. 22 5.3.2 User data protection (FDP)..................................................................................... 23 Cisco Jabber for Windows Security Target Page 3 of 41 5.3.3 Identification and authentication (FIA) .................................................................. 23 5.3.4 Security management (FMT).................................................................................. 23 5.3.5 Protection of the TSF (FPT) ................................................................................... 24 5.3.6 Trusted Path/Channels (FTP).................................................................................. 24 5.4 SFRs from the VoIP PP VoIP Client Applications or Client Platforms ........................ 24 5.4.1 Cryptographic Support (FCS)................................................................................. 24 5.4.2 Identification and authentication (FIA) .................................................................. 26 5.4.1 Security management (FMT).................................................................................. 27 5.4.2 Protection of the TSF (FPT) ................................................................................... 27 5.4.1 Trusted Path/Channels (FTP).................................................................................. 28 5.5 TOE SFR Dependencies Rationale for SFRs Found in PP............................................ 28 5.6 Security Assurance Requirements.................................................................................. 28 5.6.1 SAR Requirements.................................................................................................. 28 5.6.2 Security Assurance Requirements Rationale.......................................................... 29 5.7 Assurance Measures....................................................................................................... 29 6 TOE Summary Specification ................................................................................................30 6.1 TOE Security Functional Requirement Measures.......................................................... 30 7 Annex B: References.............................................................................................................41 Cisco Jabber for Windows Security Target Page 4 of 41 List of Tables TABLE 1 ACRONYMS............................................................................................................................................................................................ 5 TABLE 2 TERMINOLOGY ..................................................................................................................................................................................... 6 TABLE 3 ST AND TOE IDENTIFICATION.......................................................................................................................................................... 8 TABLE 4 IT ENVIRONMENT COMPONENTS...................................................................................................................................................... 9 TABLE 5 JABBER FOR WINDOWS REQUIREMENTS........................................................................................................................................11 TABLE 6 FIPS REFERENCES.............................................................................................................................................................................12 TABLE 7 TOE PROVIDED CRYPTOGRAPHY ...................................................................................................................................................12 TABLE 8 FIPS REFERENCES.............................................................................................................................................................................13 TABLE 9 TOE PROVIDED CRYPTOGRAPHY ...................................................................................................................................................14 TABLE 10 EXCLUDED FUNCTIONALITY..........................................................................................................................................................15 TABLE 11 PROTECTION PROFILES ..................................................................................................................................................................16 TABLE 12 TOE ASSUMPTIONS ........................................................................................................................................................................17 TABLE 13 THREATS..........................................................................................................................................................................................17 TABLE 14 SECURITY OBJECTIVES FOR THE TOE..........................................................................................................................................19 TABLE 15 SECURITY OBJECTIVES FOR THE ENVIRONMENT........................................................................................................................19 TABLE 16 SECURITY FUNCTIONAL REQUIREMENTS....................................................................................................................................21 TABLE 17: ASSURANCE MEASURES.................................................................................................................................................................28 TABLE 18 ASSURANCE MEASURES..................................................................................................................................................................29 TABLE 19 HOW TOE SFRS ARE MET ............................................................................................................................................................30 TABLE 20: REFERENCES ...................................................................................................................................................................................41 Cisco Jabber for Windows Security Target Page 5 of 41 Acronyms The following acronyms and abbreviations are common and may be used in this Security Target: Table 1 Acronyms Acronyms / Abbreviations Definition AAA Administration, Authorization, and Accounting ACL Access Control Lists AES Advanced Encryption Standard BRI Basic Rate Interface CC Common Criteria for Information Technology Security Evaluation CEM Common Evaluation Methodology for Information Technology Security CM Configuration Management CSU Channel Service Unit CUCM Cisco Unified Communications Manager DHCP Dynamic Host Configuration Protocol DSU Data Service Unit EAL Evaluation Assurance Level EHWIC Ethernet High-Speed WIC ESP Encapsulating Security Payload GE Gigabit Ethernet port HTTP Hyper-Text Transport Protocol HTTPS Hyper-Text Transport Protocol Secure ICMP Internet Control Message Protocol ISDN Integrated Services Digital Network IT Information Technology NDPP Network Device Protection Profile OS Operating System PBKDF2 Password-Based Key Derivation Function version 2 PoE Power over Ethernet POP3 Post Office Protocol PP Protection Profile SA Security Association SBC Session Border Controllers SDES Security Descriptions for Media Streams SDP Session Description Protocol SFP Small–form-factor pluggable port SHS Secure Hash Standard SIP Session Initiation Protocol SSHv2 Secure Shell (version 2) SRTP Security Real-Time Transport Protocol ST Security Target TCP Transport Control Protocol TLS TransportLayerSecurity TOE Target of Evaluation TSC TSF Scope of Control TSF TOE Security Function TSP TOE Security Policy UCM Unified Communications Manager UDP User datagram protocol VoIP Voice over IP Cisco Jabber for Windows Security Target Page 6 of 41 Acronyms / Abbreviations Definition WAN Wide Area Network WIC WAN Interface Card Terminology Table 2 Terminology Term Definition Authorized Administrator Any user which has been assigned to a privilege level that is permitted to perform all TSF-related functions. Client Device Platform The device (part of the Operational Environment of the TOE) on which the VoIP Application (the TOE) is installed. CUCM Cisco Unified Communications Manager (CUCM) serves as the software-based call-processing component of the Cisco Unified Communications family of products. The CUCM extends enterprise telephony features and functions to packet telephony network devices such as IP phones, media processing devices, voice- over-IP (VoIP) gateways, and multimedia applications. Security Administrator Synonymous with Authorized Administrator for the purposes of this evaluation. SIP Server The SIP Server (in this evaluation it is the Cisco Unified Communications Manager (CUCM)) interacts with a VoIP client (TOE) and provides registrar and proxy capabilities required for call-session management as well as establishing, processing, and terminating VoIP calls. User Any entity (human user or external IT entity) outside the TOE that interacts with the TOE. Cisco Jabber for Windows Security Target Page 7 of 41 DOCUMENT INTRODUCTION Prepared By: Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134 This document provides the basis for an evaluation of a specific Target of Evaluation (TOE), Jabber for Windows. This Security Target (ST) defines a set of assumptions about the aspects of the environment, a list of threats that the product intends to counter, a set of security objectives, a set of security requirements, and the IT security functions provided by the TOE which meet the set of requirements. Administrators of the TOE will be referred to as administrators, Authorized Administrators, TOE administrators, semi-privileged, privileged administrators, and security administrators in this document. Cisco Jabber for Windows Security Target Page 8 of 41 1 SECURITY TARGET INTRODUCTION The Security Target contains the following sections:  Security Target Introduction [Section 1]  Conformance Claims [Section 2]  Security Problem Definition [Section 3]  Security Objectives [Section 4]  IT Security Requirements [Section 5]  TOE Summary Specification [Section 6] The structure and content of this ST comply with the requirements specified in the Common Criteria (CC), Part 1, Annex A, and Part 2. 1.1 ST and TOE Reference This section provides information needed to identify and control this ST and its TOE. Table 3 ST and TOE Identification Name Description ST Title Cisco Jabber for Windows Security Target ST Version 1.0 Publication Date 12 November 2015 Vendor and ST Author Cisco Systems, Inc. TOE Reference Cisco Jabber for Windows, Jabber TOE Hardware Models NA TOE Software Version 11.0 Keywords Authentication, Voice, Telephony 1.2 TOE Overview Cisco Jabber for Windows 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 Windows 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 desk-phone control features. These features mean that high-quality and high-availability voice and video telephony is available on users’ desk phones, soft clients, and mobile devices. Cisco Jabber is a Cisco-developed highly configurable proprietary software that provides for efficient and effective unified communications application. The TOE is software-only comprised of the Cisco Jabber software image Release 11.0. Cisco Jabber for Windows Security Target Page 9 of 41 1.2.1 TOE Product Type Cisco Jabber for Windows is a unified communications client within the Cisco Jabber suite of collaboration software. The Cisco Jabber application is a soft phone with wideband and high- fidelity audio, standards based high-definition video, and desk-phone control features. Integrated with Cisco Unified Communications Manager (CUCM) call-control, it delivers secure, reliable communications. 1.2.2 Supported non-TOE Hardware/ Software/ Firmware The TOE supports the following hardware, software, and firmware components in its operational environment. Each component is identified as being required or not based on the claims made in this Security Target. All of the following environment components are supported by all TOE evaluated configurations. Table 4 IT Environment Components Component Required Usage/Purpose Description for TOE performance Certification Authority No This includes any IT Environment Certification Authority on the TOE network. This can be used to validate certificates. Management Workstation installed with Microsoft Windows 8 Yes This includes any IT Environment Management workstation that supports the requirements defined below in Section 1.4 Remote SIP Endpoint/Peer in this evaluation it is the Cisco Unified Communications Manager (CUCM)) Yes This includes any peer with which the TOE participates in SDES-SRTP communications. SIP peers may be any device or remote VoIP application that supports SDES- SRTP communications. 1.3 TOE DESCRIPTION This section provides an overview of the Cisco Jabber Target of Evaluation (TOE). The TOE is comprised of a single client application that delivers business-quality voice and video to your desktop. The Cisco Jabber primary features include the following:  Communication integration - a single, intuitive interface for instant messaging with individuals and groups, IP telephony, visual voicemail, 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. Cisco Jabber for Windows Security Target Page 10 of 41  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 voicemail 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 voicemail. 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 voicemail. Note in the evaluated configuration, video capabilities are not evaluated or tested. 1.4 TOE Evaluated Configuration The TOE is a software solution that is installed on the following Common Criteria certified Microsoft Window operating systems:  Microsoft Windows 8 Pro and Enterprise Edition, 32 bit and 64 bit—supported in Jabber Desktop mode only Refer to the Microsoft Windows 8 Security Target1 for information regarding the evaluated configuration requirements of Microsoft Windows 8 Pro and Enterprise Edition, 32 bit and 64 bit. The TOE also requires support of Cisco Unified Communications Manager (CUCM), release 11.0 or later as the SIP Server. Cisco CUCM serves as the call-processing component for voice that includes IP telephony, mobility features and calls controls. As such there are configuration settings that are pushed to Jabber for Windows that are required in the evaluated configuration. These settings cannot be changed. Refer to the Cisco Unified Communications Manager (CUCM) Security Target2 for information regarding the evaluated configuration requirements of CUCM 11.0. 1 http://www.commoncriteriaportal.org/products/ 2 http://www.commoncriteriaportal.org/products/ Cisco Jabber for Windows Security Target Page 11 of 41 The following table identifies the minimum requirements for Jabber to run on Microsoft Windows 8: Table 5 Jabber for Windows Requirements Requirement Installed RAM 2 GB RAM Free Physical Memory 128 MB Free Disk Space 256 MB CPU Speed and Type Mobile AMD Sempron Processor 3600+ 2 GHz Intel Core2 CPU T7400 at 2. 16 GHz Intel Atom Jabber can be installed on any support hardware that is also supported by Microsoft Windows 8. The following hardware platforms and components are included in the evaluated configuration of Microsoft Windows 8 Pro and Enterprise Edition, 32 bit and 64 bit.  Microsoft Surface  Dell Optiplex GX620  Dell XPS 8500  ASUS VivoTab (Windows RT NVidia tablet)  Dell XPS10 (Windows RT Qualcomm tablet)  Dell Precision M6300  Trusted Platform Module Refer to the Microsoft Windows 8 Security Target3 for additional information regarding the evaluated configuration and hardware requirements. The network, on which the TOE resides, is considered part of the environment. The TOE guidance documentation that is considered to be part of the TOE can be found listed in the Cisco Jabber Common Criteria Configuration Guide document and are downloadable from the http://cisco.com web site. 1.5 Logical Scope of the TOE Platform The TOE is comprised of several security features. Each of the security features identified above consists of several security functionalities, as identified below.  Cryptographic Support  User Data Protection  Identification and Authentication  Security Management  Protection of the TSF  Trusted Path/Channels 3 http://www.commoncriteriaportal.org/products/ Cisco Jabber for Windows Security Target Page 12 of 41 These features are described in more detail in the subsections below. In addition, the TOE implements all RFCs of the VoIP PPv1.3 as necessary to satisfy testing/assurance measures prescribed therein. 1.5.1 Cryptographic Support The TOE provides cryptography in support of other Cisco Jabber for Windows security functionality. This cryptography has been validated for conformance to the requirements of FIPS 140-2 Level 1 (see Table 6 for certificate references). Table 6 FIPS References Algorithm Cert. # RSA #1133 and #1134 The TOE provides cryptography in support of SIP connections via Security Real-Time Transport Protocol (SRTP) that has been established using the Session Description Protocol (SDP) and the Security Descriptions for Media Streams (SDES) for SDP. The TOE also protects communications between itself and the CUCM SIP Server by using a Transport Layer Security (TLS)-protected signaling channel. The cryptographic services provided by the TOE are described in Table 7 below. Table 7 TOE Provided Cryptography Cryptographic Method Use within the TOE RSA/DSA Signature Services X.509 certificate signing The TOE uses the X.509v3 certificate for securing TLS, and SDES/SRTP connections. 1.5.2 User Data Protection The TOE ensures that voice data is not transmitted when a call is placed on hold, call placed on mute and when not connected. 1.5.3 Identification and authentication The TOE performs authentication using passwords for SIP Register functions. The passwords must be at least eight (8) characters and include the use of upper and lower case characters, numbers and special characters. 1.5.4 Security Management The TOE provides the capability to manage the following functions:  Identify SIP Servers used for communications;  Specify the credentials used for connections;  Define the password requirements for SIP authentications;  Cryptographic functionality; and  Update to the TOE. Cisco Jabber for Windows Security Target Page 13 of 41 The TOE supports the administrative user to perform the above security relevant management functions. 1.5.5 Protection of the TSF The TOE protects against interference and tampering by untrusted subjects by implementing authentication and access controls to limit configuration the administrative user. The TOE is able to verify any software updates prior to the software updates being installed on the TOE to avoid the installation of unauthorized software. 1.5.6 Trusted path/Channels The TOE allows secure communications between itself and a remote VoIP application using SDES-SRTP. 1.6 Logical Scope of the TOE Client Platform The TOE is comprised of several security features. Each of the security features identified above consists of several security functionalities, as identified below.  Cryptographic Support  User Data Protection  Identification and Authentication  Security Management  Protection of the TSF  Trusted Path/Channels These features are described in more detail in the subsections below. In addition, the TOE implements all RFCs of the VoIP PPv1.3 as necessary to satisfy testing/assurance measures prescribed therein. 1.6.1 Cryptographic Support The TOE Client Device Platform provides cryptography in support of other Cisco Jabber for Windows security functionality. This cryptography has been validated for conformance to the requirements of FIPS 140-2 Level 1 (see Table 6 for certificate references). Table 8 FIPS References Algorithm Cert. # Triple-DES #1387 AES #2197 and #2216 SHS #1903 HMAC #1345 DRBG #258 and #259 RSA #1133 and #1134 Cisco Jabber for Windows Security Target Page 14 of 41 Algorithm Cert. # ECDSA #341 The TOE Client Device Platform provides cryptography in support of SIP connections via Security Real-Time Transport Protocol (SRTP) that has been established using the Session Description Protocol (SDP) and the Security Descriptions for Media Streams (SDES) for SDP. The TOE also protects communications between itself and the CUCM SIP Server by using a Transport Layer Security (TLS)-protected signaling channel. The cryptographic services provided by the TOE are described in Table 9 below. Table 9 TOE Provided Cryptography Cryptographic Method Use within the TOE RSA/DSA Signature Services X.509 certificate signing The TOE Client Device Platform uses the X.509v3 certificate for securing TLS and SDES/SRTP connections. 1.6.2 User Data Protection The TOE ensures that voice data is not transmitted when a call is placed on hold, call placed on mute and when not connected. 1.6.3 Identification and authentication The TOE Client Device Platform provides validates certificates using Online Certificate Status Protocol (OCSP). The certificates are used to support authentication for SDES/SRTP and TLS connections. 1.6.4 Security Management The TOE Client Device Platform provides the capability to manage the following functions:  Configure cryptographic algorithms;  Load X5.09v3 certificates;  Configure certificate revocation check; and  Ability to update the TOE, and to verify the updates. The TOE Client Device Platform supports the administrative user to perform the above security relevant management functions. 1.6.5 Protection of the TSF The TOE Client Device Platform protects against interference and tampering by untrusted subjects by implementing authentication and access controls to limit configuration to the administrative user. The TOE is able to verify any software updates prior to the software updates being installed on the TOE to avoid the installation of unauthorized software. Cisco Jabber for Windows Security Target Page 15 of 41 1.6.6 Trusted Path/Channels The TOE allows secure communications between itself and a remote CUCM SIP Server using TLS. 1.7 Excluded Functionality The following functionality is excluded from the evaluation. Table 10 Excluded Functionality Excluded Functionality Exclusion Rationale Non-FIPS 140-2 mode of operation This mode of operation includes non-FIPS allowed operations. These services will be disabled by configuration. The exclusion of this functionality does not affect compliance to the Protection Profile for Voice Over IP (VoIP) Applications, version 1.3. Cisco Jabber for Windows Security Target Page 16 of 41 2 CONFORMANCE CLAIMS 2.1 Common Criteria Conformance Claim The TOE and ST are compliant with the Common Criteria (CC) Version 3.1, Revision 4, dated: September 2012. For a listing of Assurance Requirements claimed see section 5.6. The TOE and ST are CC Part 2 extended and CC Part 3 conformant. 2.2 Protection Profile Conformance The TOE and ST are conformant with the Protection Profiles as listed in Table 11 below: Table 11 Protection Profiles Protection Profile Version Date Protection Profile for Voice Over IP (VoIP) Applications 1.3 3 November 2014 2.3 Protection Profile Conformance Claim Rationale 2.3.1 TOE Appropriateness The TOE provides all of the functionality at a level of security commensurate with that identified in the U.S. Government Protection Profile:  Protection Profile for Voice Over IP (VoIP) Applications, Version 1.3 2.3.2 TOE Security Problem Definition Consistency The Assumptions, Threats, and Organizational Security Policies included in the Security Target represent the Assumptions, Threats, and Organizational Security Policies specified in the Protection Profile for Voice Over IP (VoIP) Applications, Version 1.3 for which conformance is claimed verbatim. All concepts covered in the Protection Profile Security Problem Definition are included in the Security Target Statement of Security Objectives Consistency. The Security Objectives included in the Security Target represent the Security Objectives specified in the VoIP PPv1.3 for which conformance is claimed verbatim. All concepts covered in the Protection Profile’s Statement of Security Objectives are included in the Security Target. 2.3.3 Statement of Security Requirements Consistency The Security Functional Requirements included in the Security Target represent the Security Functional Requirements specified in the VoIP PPv1.3 for which conformance is claimed verbatim. All concepts covered in the Protection Profile’s Statement of Security Requirements are included in this Security Target. Additionally, the Security Assurance Requirements included in this Security Target are identical to the Security Assurance Requirements included in VoIP PPv1.3. Cisco Jabber for Windows Security Target Page 17 of 41 3 SECURITY PROBLEM DEFINITION This chapter identifies the following:  Significant assumptions about the TOE’s operational environment.  IT related threats to the organization countered by the TOE.  Environmental threats requiring controls to provide sufficient protection.  Organizational security policies for the TOE as appropriate. This document identifies assumptions as A.assumption with “assumption” specifying a unique name. Threats are identified as T.threat with “threat” specifying a unique name. Organizational Security Policies (OSPs) are identified as P.osp with “osp” specifying a unique name. 3.1 Assumptions The specific conditions listed in the following subsections are assumed to exist in the TOE’s environment. These assumptions include both practical realities in the development of the TOE security requirements and the essential environmental conditions on the use of the TOE. Table 12 TOE Assumptions Assumption Assumption Definition 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 that are necessary to support the correct operation of the TOE. A.TRUSTED_CONFIG Personnel configuring the TOE and its operational environment will follow the applicable security configuration guidance. 3.2 Threats The following table lists the threats addressed by the TOE and the IT Environment. The assumed level of expertise of the attacker for all the threats identified below is Enhanced-Basic. Table 13 Threats Threat Threat Definition T.TSF_CONFIGURATION Failure to allow configuration of the TSF may prevent its users from being able to adequately implement their particular security policy, leading to a compromise of user information. T.TSF_FAILURE Security mechanisms of the TOE may fail, leading to a compromise of the TSF. T.UNAUTHORIZED_ACCESS A user may gain unauthorized access to the TOE data. 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 Cisco Jabber for Windows Security Target Page 18 of 41 Threat Threat Definition T.UNAUTHORIZED_UPDATE A malicious party attempts to supply the end user with an update to the product that may compromise the security features of the TOE. T.USER_DATA_REUSE Voice data may be inadvertently sent to a destination not intended because it is sent outside the voice call. 3.3 Organizational Security Policies The VoIP PPv1.3 does not define organizational security policies. Cisco Jabber for Windows Security Target Page 19 of 41 4 SECURITY OBJECTIVES This Chapter identifies the security objectives of the TOE and the IT Environment. The security objectives identify the responsibilities of the TOE and the TOE’s IT environment in meeting the security needs.  This document identifies objectives of the TOE as O.objective with objective specifying a unique name. Objectives that apply to the IT environment are designated as OE.objective with objective specifying a unique name. 4.1 Security Objectives for the TOE The following table, Security Objectives for the TOE, identifies the security objectives of the TOE. These security objectives reflect the stated intent to counter identified threats and/or comply with any security policies identified. An explanation of the relationship between the objectives and the threats/policies is provided in the rationale section of this document. Table 14 Security Objectives for the TOE TOE Objective TOE Security Objective Definition O.PROTECTED_COMMUNICATIONS The TOE will provide protected communication channels with authorized IT entities (SIP Server and other VoIP applications). O.TSF_SELF_TEST The TOE will provide the capability to test some subset of its security functionality to ensure it is operating properly. O.VERIFIABLE_UPDATES The TOE will provide the capability to help ensure that any updates to the TOE can be verified by the administrator to be unaltered and (optionally) from a trusted source. 4.2 Security Objectives for the Environment All of the assumptions stated in section 3.1 are considered to be security objectives for the environment. The following are the Protection Profile 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. Table 15 Security Objectives for the Environment Environment Security Objective IT Environment Security Objective Definition OE.AUTHORIZED_USER The user of the TOE is non-hostile and follows all user guidance. 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. Cisco Jabber for Windows Security Target Page 20 of 41 Environment Security Objective IT Environment Security Objective Definition OE.TRUSTED_ADMIN TOE Administrators are trusted to follow and apply all administrator guidance in a trusted manner. Cisco Jabber for Windows Security Target Page 21 of 41 5 SECURITY REQUIREMENTS This section identifies the Security Functional Requirements for the TOE. The Security Functional Requirements included in this section are derived from Part 2 of the Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 4, dated: September 2012 and all international interpretations. 5.1 Conventions The CC defines operations on Security Functional Requirements: assignments, selections, assignments within selections and refinements. This document uses the following font conventions to identify the operations defined by the CC:  Assignment: Indicated with [italicized] text within brackets;  Refinement: Indicated with bold text;  Selection: Indicated with [underlined] text within brackets;  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. Formatting conventions outside of operations and iterations matches the formatting specified within the NDPP. 5.2 TOE Security Functional Requirements This section identifies the Security Functional Requirements for the TOE. The TOE Security Functional Requirements that appear in the following table are described in more detail in the following subsections. Table 16 Security Functional Requirements Class Name Component Identification Component Name Security Functional Requirements for VoIP Applications (TOE) FCS: Cryptographic support FCS_CKM_EXT.2(1) Cryptographic Key Storage FCS_SRTP_EXT.1 Secure Real-Time Transport Protocol (SRTP) FDP: User data protection FDP_VOP_EXT.1 Voice Over IP Data Protection FIA: Identification and authentication FIA_SIPC_EXT.1 Session Initiation Protocol (SIP) Client FMT: Security Management FMT_SMF.1 Specification of Management Functions FPT: Protection of the TSF FPT_TUD_EXT.1 Extended: Trusted Update FTP: Trusted path/channels FTP_ITC.1(1) Inter-TSF Trusted Channel (SDES-SRTP) Security Functional Requirements for VoIP Client Applications or Client Platforms FCS: Cryptographic support FCS_CKM.1(1) Cryptographic Key Generation (Asymmetric Keys) FCS_CKM.1(2) Cryptographic Key Generation FCS_CKM_EXT.4 Cryptographic key material destruction (Key Material) FCS_COP.1(1) Cryptographic Operation (Data Encryption/Decryption) FCS_COP.1(2) Cryptographic Operation (for cryptographic signature) Cisco Jabber for Windows Security Target Page 22 of 41 Class Name Component Identification Component Name FCS_COP.1(3) Cryptographic Operation (for cryptographic hashing) FCS_COP.1(4) Cryptographic Operation (For keyed-hash Message Authentication) FCS_RBG_EXT.1 Extended: Cryptographic operation (Random Bit Generation) FCS_TLS_EXT.1 Transport Level Security FIA: Identification and authentication FIA_X509_EXT.1 Extended: X509 Certificate Validation FIA_X509_EXT.2 Extended: X509 Certificate Use and Management FMT: Security management FMT_SMF.1 Specification of Management Functions FPT: Protection of the TSF FPT_TST_EXT.1 Extended: TSF Self Test FPT_TUD_EXT.1 Extended: Trusted Update FTP: Trusted Path/Channels FTP_ITC.1(2) Inter-TSF Trusted Channel (TLS/SIP) 5.3 SFRs Drawn from VoIP PP for VoIP Applications (TOE) 5.3.1 Cryptographic Support (FCS) 5.3.1.1 FCS_CKM.2(1) Refinement: Cryptographic Key Storage / FCS_CKM_EXT.2(1) Cryptographic Key Storage FCS_CKM_EXT.2.1(1) The VoIP client application shall store persistent secrets and private keys when not in use in platform-provided key storage. 5.3.1.2 FCS_SRTP_EXT.1 Secure Real-Time Transport Protocol (SRTP) FCS_SRTP_EXT.1.1 The VoIP client application 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 VoIP client application 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 VoIP client application shall ensure the SRTP NULL algorithm can be disabled. FCS_SRTP_EXT.1.4 The VoIP client application shall allow the SRTP ports to be used for SRTP communications to be specified by an Authorized Administrator. Cisco Jabber for Windows Security Target Page 23 of 41 5.3.2 User data protection (FDP) 5.3.2.1 FDP_VOP_EXT.1 Voice Over IP Data Protection FDP_VOP_EXT.1.1 The VoIP Client Application shall stop the transmission of voice data when a VoIP call is placed on hold, a VoIP call is placed on mute, a VoIP call is not connected, and [no other actions]. 5.3.3 Identification and authentication (FIA) 5.3.3.1 FIA_SIPC_EXT.1 Session Initiation Protocol (SIP) Client FIA_SIPC_EXT.1.1 The VoIP client application 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 VoIP client application 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 VoIP client application 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: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, and “)”, and [no other supported special characters]}. FIA_SIPC_EXT.1.4 The password entered by the user as per FIA_SIPC_EXT.1.2 shall be cleared by the VoIP client application once the VoIP client application is notified that the REGISTER request was successful. 5.3.4 Security management (FMT) 5.3.4.1 FMT_SMF.1 Specification of Management Functions FMT_SMF.1.1 The VoIP client application shall be capable of performing the following management functions:  Specify the SIP Server to use for connections,  Specify VoIP client credentials to be used for connections,  Specify password requirements for SIP authentication,  Ability to configure all security management functions identified in other sections of this PP,  [no other functions]. Cisco Jabber for Windows Security Target Page 24 of 41 5.3.5 Protection of the TSF (FPT) 5.3.5.1 FPT_TUD_EXT.1 Extended: Trusted Update FPT_TUD_EXT.1.1 The TSF shall provide the client device platform the ability to query the current version of the TOE firmware/software. 5.3.6 Trusted Path/Channels (FTP) 5.3.6.1 FTP_ITC.1(1) Inter-TSF Trusted Channel (SDES-SRTP) FTP_ITC.1.1(1) Refinement: The VoIP Client Application 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 VoIP Client Application shall permit the TSF or the remote VoIP application to initiate communication via the trusted channel. FTP_ITC.1.3(1) The VoIP Client Application shall initiate communication via the trusted channel for [all communications between the two devices]. 5.4 SFRs from the VoIP PP VoIP Client Applications or Client Platforms 5.4.1 Cryptographic Support (FCS) 5.4.1.1 FCS_CKM.1(1) Cryptographic Key Generation (Asymmetric Keys) FCS_CKM.1.1(1) Refinement: The [VoIP client application, client device platform] shall generate asymmetric cryptographic keys used for key establishment in accordance with:  NIST Special Publication 800-56B, “Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography” for RSA-based key establishment schemes and [  NIST Special Publication 800-56A, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography” for elliptic curve-based key establishment schemes and implementing “NIST curves” P-256, P-384 and [no other curves] (as defined in FIPS PUB 186-4, “Digital Signature Standard”)] and specified cryptographic key sizes equivalent to, or greater than, a symmetric key strength of 112 bits. Cisco Jabber for Windows Security Target Page 25 of 41 5.4.1.2 FCS_CKM.1(2) Cryptographic Key Generation FCS_CKM.1.1(2) Refinement: The [client device platform] shall generate asymmetric cryptographic keys used for authentication in accordance with a specified cryptographic key generation algorithm [  FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3 for RSA schemes;  FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4 for ECDSA schemes and implementing “NIST curves” P-256, P-384 and [no other curves]] and specified cryptographic key sizes equivalent to, or greater than, a symmetric key strength of 112 bits. 5.4.1.3 FCS_CKM_EXT.4 Cryptographic key material destruction (Key Material) FCS_CKM_EXT.4.1 Refinement: The [client device platform] shall zeroize all plaintext secret and private cryptographic keys and Critical Security Parameters (CSPs) when no longer required. 5.4.1.4 FCS_COP.1(1) Cryptographic Operation (Data Encryption/Decryption) FCS_COP.1.1 Refinement: The [client device platform] shall perform encryption and decryption in accordance with a specified cryptographic algorithm AES operating in CTR, CBC, and [GCM (as defined in NIST SP800-38D), [no other modes] and cryptographic key sizes 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 SP800-38D 5.4.1.5 FCS_COP.1(2) Cryptographic Operation (for cryptographic signature) FCS_COP.1.1(2) Refinement: The [client device platform] shall perform cryptographic signature services (generation and verification) in accordance with a specified cryptographic algorithm  FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3 for RSA schemes [  FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4 for Elliptic Curve Digital Signature Algorithm (ECDSA) schemes and implementing “NIST curves” P-256, P-384, and [no other curves]  No other algorithms] and cryptographic key sizes [equivalent to, or greater than, a symmetric key strength of 112 bits]. 5.4.1.6 FCS_COP.1(3) Cryptographic Operation (for cryptographic hashing) FCS_COP.1.1(3) Refinement: The [client device platform] shall perform cryptographic hashing in accordance with a specified cryptographic algorithm SHA-1 and [SHA-256, SHA- Cisco Jabber for Windows Security Target Page 26 of 41 384] and [no other algorithms] and message digest sizes 160 bits and [256, 384] and [no other message digest sizes] that meet the following: FIPS PUB 180-3, “Secure Hash Standard.” 5.4.1.7 FCS_COP.1(4) Cryptographic Operation (For keyed-hash Message Authentication) FCS_COP.1.1(4) Refinement: The [client device platform] shall perform keyed-hash message authentication in accordance with a specified cryptographic algorithm HMAC-SHA-1 and [HMAC-SHA-256, HMAC- SHA-384] and cryptographic key sizes [160, 256, 384], and message digest sizes 160 and [256, 384] bits that meet the following: FIPS Pub 198-1, "The Keyed-Hash Message Authentication Code, and FIPS Pub 180-3, “Secure Hash Standard.” 5.4.1.8 FCS_RBG_EXT.1 Extended: Cryptographic operation (Random Bit Generation) FCS_RBG_EXT.1.1 The [client device platform] shall perform all deterministic random bit generation services in accordance with [NIST Special Publication 800-90A using CTR_DRBG (AES)]; FIPS Pub 140-2 Annex C: X9.31 Appendix 2.4 using AES]. FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded by an entropy source that accumulates entropy from [a platform-based RBG] with a minimum of [256 bits] of entropy at least equal to the greatest security strength (according to NIST SP 800-57) of the keys and hashes that it will generate. 5.4.1.9 FCS_TLS_EXT.1 Transport Level Security FCS_TLS_EXT.1.1 The [VoIP client application] shall implement one or more of the following protocols [TLS 1.0 (RFC 2246), TLS 1.2 (RFC 5246)] using mutual authentication with certificates and supporting the following ciphersuites: Mandatory Ciphersuites: TLS_RSA_WITH_AES_128_CBC_SHA Optional Ciphersuites: [ TLS_ECDHE_RSA_WITH _AES_256_GCM_SHA384 as defined in RFC 5289 ]. FCS_TLS_EXT.1.2 The [client device platform] shall not establish a trusted channel if the distinguished name (DN) contained in a certificate does not match the expected DN for the peer. 5.4.2 Identification and authentication (FIA) 5.4.2.1 FIA_X509_EXT.1 Extended: X509 Certificate Validation FIA_X509_EXT.1.1 The [client device platform] shall validate certificates in accordance with the following rules:  RFC 5280 certificate validation and certificate path validation. Cisco Jabber for Windows Security Target Page 27 of 41  Validate the certificate path by ensuring the basicConstraints extension is present and the cA flag is set to TRUE for all CA certificates.  Validate the revocation status of the certificate using [the Online Certificate Status Protocol (OCSP) as specified in RFC 2560, a Certificate Revocation List (CRL) as specified in RFC 5759].  Validate the extendedKeyUsage field according to the following rules: o Certificates used for trusted updates and executable code integrity verification shall have the Code Signing purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3). o Server certificates presented for TLS shall have the Server Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field. FIA_X509_EXT.1.2 The [client device platform] shall only treat a certificate as a CA certificate if the basicConstraints extension is present and the CA flag is set to TRUE. 5.4.2.2 FIA_X509_EXT.2 Extended: X509 Certificate Use and Management FIA_X509_EXT.2.1 The [client device platform] shall use X.509v3 certificates as defined by RFC 5280 to support authentication for SDES/SRTP, TLS, and [no additional uses]. FIA_X509_EXT.2.2 When the [client device platform] cannot establish a connection to determine the validity of a certificate, the [client device platform] shall [allow the administrator to choose whether to establish or not establish the trusted channel in these cases]. FIA_X509_EXT.2.3 The [client device platform] shall not establish a trusted communication channel if the peer certificate is deemed invalid. 5.4.1 Security management (FMT) 5.4.1.1 FMT_SMF.1 Specification of Management Functions FMT_SMF.1.1 The [VoIP client Application, client device platform] shall be capable of performing the following management functions:  Configure cryptographic algorithms associated with protocols mandated in this PP,  Load X5.09v3 certificates used for security functions in this PP,  Configure certificate revocation check,  Ability to update the TOE, and to verify the updates  Ability to configure all security management functions identified in other sections of this PP,  [no other actions]. 5.4.2 Protection of the TSF (FPT) 5.4.2.1 FPT_TST_EXT.1 Extended: TSF Self Test FPT_TST_EXT.1.1 The [VoIP Client Application, client device platform] shall run a suite of self tests during initial start-up (on power on) to demonstrate correct operation of the TSF. Cisco Jabber for Windows Security Target Page 28 of 41 FPT_TST_EXT.1.2 The [VoIP Client Application, client device platform] shall provide the capability to verify the integrity of stored TSF executable code when it is loaded for execution through the use of the TSF-provided cryptographic services. 5.4.2.1 FPT_TUD_EXT.1 Extended: Trusted Update FPT_TUD_EXT.1.2 The [Client device platform] shall provide authorized administrators the ability to initiate updates to the TOE firmware/software. FPT_TUD_EXT.1.3 The [Client device platform] shall provide a means to verify firmware/software updates to the TOE using a digital signature mechanism and [no other functions] prior to installing those updates. 5.4.1 Trusted Path/Channels (FTP) 5.4.1.1 FTP_ITC.1(2) Inter-TSF Trusted Channel (TLS/SIP) FTP_ITC.1.1(2) Refinement: The [VoIP Client Application] 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 disclosure. FTP_ITC.1.2(2) The [VoIP Client Application] shall permit the TSF to initiate communication via the trusted channel. FTP_ITC.1.3(2) The [VoIP Client Application] shall initiate communication via the trusted channel for [all communications with the SIP server]. 5.5 TOE SFR Dependencies Rationale for SFRs Found in PP The Security Functional Requirements (SFRs) in this Security Target represent the SFRs identified in the VoIP PPv1.3. As such, the VoIP PPv1.3 SFR dependency rationale is deemed acceptable since the PP itself has been validated. 5.6 Security Assurance Requirements 5.6.1 SAR Requirements The TOE assurance requirements for this ST are taken directly from the NDPP which are derived from Common Criteria Version 3.1, Revision 4. The assurance requirements are summarized in the table below. Table 17: Assurance Measures Assurance Class Components Components Description Development ADV_FSP.1 Basic Functional Specification Guidance Documents AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative User guidance Life Cycle Support ALC_CMC.1 Labeling of the TOE ALC_CMS.1 TOE CM coverage Cisco Jabber for Windows Security Target Page 29 of 41 Assurance Class Components Components Description Tests ATE_IND.1 Independent testing - conformance Vulnerability Assessment AVA_VAN.1 Vulnerability analysis 5.6.2 Security Assurance Requirements Rationale The Security Assurance Requirements (SARs) in this Security Target represent the SARs identified in the VoIP PPv1.3. As such, the VoIP PPv1.3 SAR rationale is deemed acceptable since the PP itself has been validated. 5.7 Assurance Measures The TOE satisfies the identified assurance requirements. This section identifies the Assurance Measures applied by Cisco to satisfy the assurance requirements. The table below lists the details. Table 18 Assurance Measures Component How requirement will be met ADV_FSP.1 There are no specific assurance activities associated with ADV_FSP.1. The requirements on the content of the functional specification information are implicitly assessed by virtue of the other assurance activities being performed. The functional specification is comprised of the information contained in the AGD_OPE and AGD_PRE documentation, coupled with the information provided in the TSS of the ST. The assurance activities in the functional requirements point to evidence that should exist in the documentation and TSS section; since these are directly associated with the SFRs, the tracing in element ADV_FSP.1.2D is implicitly already done and no additional documentation is necessary. AGD_OPE.1 The Administrative Guide provides the descriptions of the processes and procedures of how the administrative users of the TOE can securely administer the TOE using the interfaces that provide the features and functions detailed in the guidance. AGD_PRE.1 The Installation Guide describes the installation, generation, and start-up procedures so that the users of the TOE can put the components of the TOE in the evaluated configuration. ALC_CMC.1 The AGD and ST implicitly meet this assurance requirement. The evaluator shall check the ST to ensure that it contains an identifier (such as a product name/version number) that specifically identifies the version that meets the requirements of the ST. Further, the evaluator shall check the AGD guidance and TOE samples received for testing to ensure that the version number is consistent with that in the ST. ALC_CMS.1 ATE_IND.1 Cisco provided the TOE for testing and, in coordination with the evaluation team, determined that the TOE was suitable for testing. All information provided met the requirements for content and presentation of evidence and testing was successfully completed based upon the requirements of the PP and extended package. AVA_VAN.1 Cisco provided the TOE for testing and it was determined to be suitable for completion of the requirements. All information provided met the requirements for content and presentation of evidence. The evaluation team conducted a public search of potential vulnerabilities and ensured no issues resulted in a potential risk to the end user(s). Cisco Jabber for Windows Security Target Page 30 of 41 6 TOE SUMMARY SPECIFICATION 6.1 TOE Security Functional Requirement Measures This chapter identifies and describes how the Security Functional Requirements identified above are met by the TOE. Table 19 How TOE SFRs are Met TOE SFRs How the SFR is Met Security Functional Requirements for VoIP Applications (TOE) FCS_CKM_EXT.2(1) During the initial configuration and setup, the Jabber certificate with its private key is generated. The certificate and private key are stored in the Credential Manager’s secure store of the Client platform. The Client Platform includes a key isolation service that is designed specifically to host secret and private keys in a protected process to mitigate tampering or access to sensitive key materials. The TOE user’s credentials (user name and password) are also stored in the Credential Manager’s secure store on the Client Platform. In the evaluated configuration, the Client device platform, Microsoft Windows’s Credential Manager is used to provide the secure store for usernames/passwords. The Credential Manager keeps track of the user's name, password, and related information for the authentication service for the CUCM SIP Server. In the evaluated configuration, the Credential Manager will automatically supply the stored credentials when required by CUCM. There is no interface available for the user to access to this Credential Manager’s secure store file on the Client Platform. The user only presents the credentials during the initial configuration, after which time the Client Platform manages the credentials. The storage and encryption process is also managed and performed by the Client Platform. The Jabber certificate with its private key as described above is also used for client authentication purposes when establishing SIP/TLS connectivity with CUCM SIP Server. FCS_SRTP_EXT.1 Incoming and outgoing calls are handled the same per RFC4568. Following is an overview of the TLS handshake, noting the client in the diagram is the TOE and Server is the CUCM SIP Server. The TLS Handshake protocol layer is designed to operate in a lock-step manner, meaning that messages received in incorrect order will cause the - handshake to fail. Cisco Jabber for Windows Security Target Page 31 of 41 TOE SFRs How the SFR is Met The TOE must be configured to support an encrypted secure connection. This configuration is pushed to the TOE by the CUCM SIP Server. Therefore the TOE, will then establish an encrypted secure signaling connection with CUCM SIP Server using the SRTP protocol. This is provided through the use of encryption and message authentication headers. SRTP Packet Format The following example are the fields that appear within a normal RTP packet:  Version (V)—2-bit field indicating the protocol version.  Padding (P)—1-bit field indicating padding at the end of the RTP packet.  Extension Header (X)—1-bit field indicating the presence of an optional extension header.  Marker (M)—1-bit marker bit, used to identify events such as frame boundaries.  Payload Type (PT)—7-bit field which identifies the format of the RTP payload.  Sequence Number—16-bit field which increments by one for each RTP packet sent. This field can be used by the receiver to identify lost packets.  Timestamp—32-bit field which reflects the sampling instant of the first octet of the RTP packet.  Synchronization Source Identifier (SSRC)—32-bit field which uniquely identifies the source of a stream of RTP packets.  Contributing Source Identifiers (CSRCs)—Variable length field which contains a list of sources of streams of RTP packets that have contributed to a combined stream produced by an RTP mixer.  RTP Extension (Optional)—Variable length field which contains a 16-bit profile specific identifier and a 16-bit length identifier, followed by variable length extension data.  RTP Payload—Variable length field which holds the real-time application data (i.e. voice, video, etc). Cisco Jabber for Windows Security Target Page 32 of 41 TOE SFRs How the SFR is Met SRTP adds the following two additional fields to the packet:  Master Key Identifier (MKI)—Optional field of configurable length, used to indicate the master key, from which the individual session keys were derived for encryption and/or authentication, within a given cryptographic context.  Authentication Tag—Recommended field of configurable length, used to hold the message authentication data for the RTP header and payload for the particular packet. With SRTP, encryption applies only to the payload of the RTP packet. Message authentication, however, is applied to both the RTP header as well as the RTP payload. Since message authentication applies to the RTP sequence number within the header, SRTP indirectly provides protection against replay attacks. In the evaluated configuration, the TOE is configured for a secure connection with CUCM SIP Server, the TOE returns its certificates when client certificate is requested during TLS handshake. When the TOE receives CUCM SIP Server certificates during the TLS handshake, the TOE validates that the received certificate is the same as the CUCM SIP Server certificate in its truststore. In the evaluated configuration the SIP session is established over TLS, during the negotiation, Jabber offers all the SRTP ciphers it supports. The CUCM SIP Server is responsible for the configuration of the policy regarding which ciphers are acceptable, including what to do when no cipher can be negotiated. The CUCM SIP Server has configuration settings per-device to require all calls to be secure. The TOE has no visibility to this configuration as it is pushed from the CUCM SIP Server. Therefore when the administrator of the CUCM SIP Server selects ‘Authenticated’ as the value for the Device Security Mode field on the phone security profile, the SIP connection is over TLS using NULL-SHA encryption. However when the administrator of the CUCM SIP Server selects ‘Encrypted’ as the value for the Device Security Mode field on the phone security profile, the SIP connection is over TLS using AES 128 or AES 256 or SHA encryption. As a result, when the CUCM SIP Server is configured to only allow secure/encrypted calls, then TOE must also be set ‘encrypt’ otherwise the calls would fail if the TOE was set to ‘authenticate’ using NULL-SHA encryption. The evaluated configuration must be set to ‘secure/encrypted calls’. The key is generated randomly by the client platform when building its SDP offer. The TOE supports AES_CM_128_HMAC_SHA1_80. FDP_VOP_EXT.1 The following diagram is an example for the Jabber for Windows. Cisco Jabber for Windows Security Target Page 33 of 41 TOE SFRs How the SFR is Met 1. Status message 6. Recent calls 2. Menu 7. Voice Messages 3. Search or call bar 8. Meetings 4. Contacts 9. Custom Groups 5. Chat Rooms 10. Phone Controls To make a call, Step 1 Access the phone number options for your contact. For example, right-click on a contact in your contact list and choose Call, or from a chat window, click on the phone numbers/address list drop-down list. Step 2 Choose Jabber Call. There are several features that suspend or stop voice media on a call; such as setting the call on hold, transfer, or end call. In addition, entering/leaving a conference can also interrupt voice data briefly. When a call is placed on voice mute (silence), SRTP is not stopped, but voice data from the microphone is no longer being sent. Instead, silence or comfort noise packets are sent depending on the configuration settings by CUCM SIP Server. Using the Jabber call screen, selecting the ‘Mute’ icon will mute the voice audio. Selecting the ‘Mute’ icon again will unmute. When on mute, the TOE audio component is no longer transmitting a signal containing ‘voice data’. However ‘when placed on ‘mute’, ‘silence’ RTP packets (wrapped by the encryption when SRTP is used) are sent to maintain the SRTP connection. Hold always results in the existing SRTP streams being stopped and new SRTP streams (with new keys) being negotiated over SIP/SDP with the Music on Hold service. Using the Jabber call screen, selecting ‘More’ icon, then selecting ‘Hold” will place the call on hold or resume the call. Transfer always results in the existing SRTP streams being stopped and new SRTP streams (with new keys) being negotiated over SIP/SDP with the new remote party. Using the the Jabber call screen, selecting ‘More’ icon, then selecting ‘Transfer’ , then enter the number Cisco Jabber for Windows Security Target Page 34 of 41 TOE SFRs How the SFR is Met you wish to transfer the call too, will transfer the call. End the call by selecting the telephone icon, sends a SIP BYE (or CANCEL if it occurs very early in the call) and always stops the SRTP streams. For all these functions, the implementation is via SIP and SDP messaging, and the SDP messaging includes the necessary crypto options. Any change of participant results in re-keying (unless they are connected to a conference bridge and each endpoint has a unique set of keys applied only to the call leg between it and the bridge). FIA_SIPC_EXT.1 Passwords are enforced by the CUCM SIP Server; password policy is configured and enforced as configured on the CUCM SIP Server. For the user-entered password, a minimum of eight (8) characters is required and all of the following characters are supported (letters a-z (upper and lower case), numbers (0-9) and special characters (“!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, and “)”,). The password is entered by the user when requested by the CUCM SIP Server to register and complete the call. The password is passed to the CUCM as part of the SIP REGISTER request. At this point, the memory space is immediately overwritten. The CUCM SIP Server then issues an authentication token that will be kept in a SecureString to guard the authentication token while it is memory. Once the call is completed (ended), the memory space holding the authentication token is overwritten from the memory space and released for use by other functions. For outgoing calls, ports are reserved for media (as configured by the CUCM SIP Server (5060 for SIP call signalling and 5061 for Secure SIP call signalling))), then the build SDP (SIP Session Description Protocol (SDP) messages (sometimes referred to as Security Descriptions or SDES) to exchange keying material within the call signalling during call establishment) and send an INVITE with the SDP and then sends a 180 Ringing message. When the user answers, then send a 200 Ok with the SDP. For incoming calls, the TOE receives an INVITE, to which it respond immediately with 100 Trying, reserve ports for media, build the SDP and send a 180 Ringing message. When the user answers, we send a 200 Ok with the SDP. FMT_SMF.1 The TOE retrieves its configuration from the CUCM SIP Server. The CUCM SIP Server administrator configures the access to manage the VoIP client (TOE). The VoIP client (TOE) does offer limited configuration settings as most configurations are passed from the client device platform. This is to ensure organizational policies and settings are applied and enforced accordingly. FPT_TUD_EXT.1 When there is an update for Jabber for Windows, the process to update is the same as a new installation. Cisco Jabber for Windows provides an MSI4 installation package that the Authorized Administrator of the Client Platform can use in the following ways: A Group Policy, may be configured the Authorized Administrator of the Client Platform to be used as a deployment mechanism to install the TOE on multiple computers in the same domain. This method allows the Authorized Administrator of the Client Platform to ‘push’ updates to the TOE by downloading the binary to specific configuration location. 4 MSI is an installer package file format used by Windows. Its name comes from the program's original title, Microsoft Installer, which has since changed to Windows Installer. MSI files are used for installation, storage, and removal of programs. Cisco Jabber for Windows Security Target Page 35 of 41 TOE SFRs How the SFR is Met The Authorized Administrator of the Client Platform may also run the MSI file manually on the file system of the TOE and then specify connection properties when the Client Platform is started. This method is normally used for installing a single instance for testing or evaluation purposes. The Authorized Administrator of the Client Platform may also create a Custom Installer. This method is used when the same installation properties are being distributed across the domain. . The Jabber for Windows version is stamped or indicated on the MSI file. When the binary is downloaded it is verified by the Client Platform as being signed by a trusted source. FTP_ITC.1(1) There is no direct admin or user interaction on Jabber to configure or set the SRTP channel. The CUCM SIP Server administrator configures appropriately, and then each time a call is made the clients automatically start SRTP streams as negotiated. There is no user or admin interaction per-SRTP-channel. The CUCM SIP Server administrator can configure the port ranges for the voice and video streams. If network loss on the SRTP sessions occurs, the TOE automatically attempts to recover. If the user remains dissatisfied with the result, they can end the call and redial. The communication is initiated on the TOE by the user dialling a number or the SIP URI. Security Functional Requirements for VoIP Client Applications or Client Platforms FCS_CKM.1(1) Key generation is invoked by the CUCM SIP Server admin setting the device into Cisco Certificate Authority Proxy Function (CAPF) “Install/Upgrade” mode, and will take place when the user proceeds with the initial configuration and setup. During this initial configuration and setup of the TOE, CAPF may create certificates under its own authority or it can be used as a proxy to request certificates from an external Certificate Authority (CA) and these certificates can then be used to establish secure, authenticated connections for protocols such as SIP signalling over TLS. The certificates are stored on the client device platform in the certificate store. During key establishment, the client uses the Platform provided API for diffie-hellman exchanges (per SP 800-56A) and uses the Platforms cryptographic primitives for RSA key wrap (per SP 800-56B). During the CAPF process, the TOE makes a call to the Client platform’s Cryptography API which is the: Next Generation (CNG) API to generate the required keys using its FIPS Approved random number generator, which is the SP 800-56A implementation and the platform crypto primitives for SP 800-56B key establishment (cng.sys). Refer to the Microsoft Windows 8 CNG Reference (https://msdn.microsoft.com/en- us/library/windows/desktop/aa376214(v=vs.85).aspx) information regarding details and specifics of the client platform features that are used for key generation CNG Cryptographic Primitive Functions https://msdn.microsoft.com/en-us/library/windows/desktop/aa833130(v=vs.85).aspx  BCryptGenerateKeyPair  BCryptGenerateSymmetricKey  BCryptGenRandom CNG Cryptographic Configuration Functions https://msdn.microsoft.com/en-us/library/windows/desktop/bb204774(v=vs.85).aspx  BCryptGetFipsAlgorithmMode  BCryptEnumAlgorithms FCS_CKM.1(2) Cisco Jabber for Windows Security Target Page 36 of 41 TOE SFRs How the SFR is Met  BCryptQueryContextFunctionConfiguration FCS_CKM_EXT.4 Keys and secrets  RSA keys  User password (secret)  Hash (object)  TLS Session Keys for initial registration to the SIP server  TLS Session Keys for SIP-TLS connections  sRTP Session Keys are maintained by the Client Platform. The Client Platform includes a key isolation service designed specifically to host secret and private keys in a protected process to mitigate tampering or access to sensitive key materials. The Client Platform destroys non-persistent cryptographic keys (note that all keys which are subject to destruction are stored within the crypto module that was subject to FIPS 140- 2 certification) after a cryptographic administrator-defined period of time of inactivity or when no longer required. The Client Platform overwrites each intermediate storage area for all plaintext key/critical cryptographic security parameter (i.e., any storage, such as memory buffers, that is included in the path of such data). This overwriting is performed as follows: Key Identifier Zeroization Non-Volatile Memory RSA keys Overwrite is executed three or more times using a different alternating data pattern each time upon the transfer of the key/critical cryptographic security parameter to another location. User password (secret) Hash (object) Volatile Memory TLS Session Keys for initial registration to the SIP server Overwrite is a single direct overwrite consisting of a pseudo random pattern, followed by a read-verify upon the transfer of the key/critical cryptographic security parameter to another location TLS Session Keys for SIP-TLS connections sRTP Session Keys User password (secret) Refer to the Microsoft Windows 8 CNG Reference (https://msdn.microsoft.com/en- us/library/windows/desktop/aa376214(v=vs.85).aspx) information regarding details and specifics of the client platform features that are used for key destruction CNG Cryptographic Primitive Functions https://msdn.microsoft.com/en-us/library/windows/desktop/aa833130(v=vs.85).aspx  BCryptDestroyHash (when the hash (object) is selected for deletion, the HASH_HANDLE (hHash) is passed and the hash object is deleted (destroyed) as indicated in the BCryptDestroyHash function).  BCryptDestroyKey (when the key is selected for deletion, the KEY_HANDLE (hKey) is passed and the key is deleted (destroyed) as indicated in the NCryptDeleteKey function).  BCryptDestroySecret (when the user password (secret) is selected for deletion, the SECRET_HANDLE (hSecret) is passed and the secret is deleted (destroyed) as indicated in the BCryptDestroySecret function). FCS_COP.1(1) For the TLS sessions, the TOE supports a FIPS mode with the following cipher list as Cisco Jabber for Windows Security Target Page 37 of 41 TOE SFRs How the SFR is Met defined by the CUCM SIP Server: TLS_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH _AES_256_GCM_SHA384 For SRTP connections, see FCS_SRTP_EXT.1 Secure Real-Time Transport Protocol (SRTP). Noting that both CTR and GCM are supported options for SRTP as follows, for CBC (NIST SP 800-38A) and GCM (NIST SP 800-38D) on TLS connections, and CTR (NIST SP 800-38A) and GCM (NIST SP 800-38D) on SRTP sessions. FCS_COP.1(2) The TOE only performs digital signature verification as required by client TLS sessions, in order to validate the server certificate. The RSA schemes are supported and required in order to meet the requirements. Also, the certificate key is required to be at least 2048 bits in length. All digital signature functionality in the TOE is handled by client device platform on behalf of the TOE as part of TLS session setup by calling the Cryptographic Primitives Library (BCryptPrimitives.dll), Enhanced DSS and Diffie-Hellman Cryptographic Services Provider (DSSENH.dll) and the RSA Enhanced Cryptographic Services Provider (RSAENH.dll) as appropriate. The client device platform provides cryptographic operations such as hashing and digital signatures. Hashing is used by other FIPS Approved algorithms implemented in client device platform (the hashed message authentication code, RSA, DSA, and EC DSA signature services, Diffie-Hellman and elliptic curve Diffie-Hellman key agreement, and the random number generation AES_CTR_DRBG, however CNG can be also be configured to use the Dual EC DRBG). FCS_COP.1(3) Hashing is done by the client device platform to validate server certificates on establishing TLS connections. Hashing is also performed as part of SRTP and as part of SIP digest authentication. All hashing functionality in the TOE is handled by client device platform on behalf of the TOE as part of SRTP and as part of SIP digest authentication by calling the Cryptographic Primitives Library (BCryptPrimitives.dll) and the RSA Enhanced Cryptographic Services Provider (RSAENH.dll) as appropriate. FCS_COP.1(4) Keyed hash functionality is done by the client device platform to validate server certificates on establishing TLS connections. Keyed hash functionality is also performed as part of SRTP and as part of SIP digest authentication. All Keyed hash functionality in the TOE is handled by client device platform on behalf of the TOE as part of SRTP and as part of SIP digest authentication by calling the Cryptographic Primitives Library (BCryptPrimitives.dll) and the RSA Enhanced Cryptographic Services Provider (RSAENH.dll) as appropriate. Also see FCS_SRTP_EXT.1 Secure Real-Time Transport Protocol (SRTP) TLS sessions can use SHA|SHA256|SHA384. SRTP sessions can use HMAC-SHA1-32, HMAC-SHA1-80 or AEAD FCS_RBG_EXT.1 The client device platform’s deterministic random bit generation (DRBG) is implemented in accordance with NIST Special Publication 800-90. Windows generates random bits by taking the output of a cascade of two SP800-90 AES-256 counter mode based DRBGs in kernel-mode and four cascaded SP800-90 AES-256 DRBGs in user-mode; all are seeded from the Windows entropy pool. When required, the TOE makes calls to calling the Cryptographic Primitives Library (BCryptPrimitives.dll) and the RSA Enhanced Cryptographic Services Provider (RSAENH.dll) as appropriate. The client device platform is Common Criteria certified and it is assumed that the source for the seeding provides at least 256 bits of entropy which is needed to meet the FCS_RBG_EXT.1.1 requirement. Cisco Jabber for Windows Security Target Page 38 of 41 TOE SFRs How the SFR is Met FCS_TLS_EXT.1 For TLS sessions, the client device platform supports FIPS mode with cipher list that includes the following ciphers: TLS_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES256_GCM_SHA384 If the client device platform deems that a certificate is invalid it will not establish the session. Certificates are validated automatically when presented for use. The certificate status checking is implemented in the CryptoAPI. The client platform automatically performs a bit-wise comparison of the DN in the presented certificate to the expected DN. This check is performed automatically and does not require any specific guidance. If the presented DN does not match the expected DN, an alert is presented to the user identifying the DN mismatch and the option is presented to decline the certificate. In name matching the subject name of a certificate must match the issuer name in the current certificate in order for the certificate to be chosen as a valid issuer. FIA_X509_EXT.1 The client device platform is responsible for validating the X509 certificate. During the initial configuration and setup of the TOE, CAPF may create certificates under its own authority or it can be used as a proxy to request certificates from an external Certificate Authority (CA) and these certificates can then be used to establish secure, authenticated connections for protocols such as SIP signalling over TLS. The certificates are stored on the client device platform in the certificate store. The Authorized Administrator may also have to import root certificates into the certificate store if the certificates are signed by a CA that does not already exist in the trust store. The following certificates are required for the on premises server configurations to establish secure connection with the TOE: Server Certificate CUCM HTTP (Tomcat) and CallManager certificate (secure SIP call signalling for secure phone) The TOE uses the client device platform to verify the certificate information at the point in time when it receives the server certificate as part of the process of establishing a secure connection to any server. All of the certificates in the certificate chain are also validated in the process. Certificate validity and chain is validated via the client device platform including CRL/OCSP revocation status checks. The client device platform also validates the extendedKeyUsage field according to the following rules:  Certificates used for trusted updates and executable code integrity verification shall have the Code Signing purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3).  Server certificates presented for TLS shall have the Server Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) This validation is done by the client device platform. Both OCSP and CRL’s are supported depending on the information supplied in the certificate. Not being able to connect to the revocation server (OCSP and CRL) will result in the administrator being able to choose to establish the requested connection or to allow the requested connection to not being established. For more information regarding the managing certificates refer to the Microsoft Windows 8 Security Target Section 6.2.4.10 Certificates Used in IPsec and TLS for the Security Management (FMT), Management of TSF Data for X.509 Certificates (FMT_MTD.1(X509)) and associated Microsoft documentation for certificate management, such as technet links Manage Certificates: http://technet.microsoft.com/en- FIA_X509_EXT.2 Cisco Jabber for Windows Security Target Page 39 of 41 TOE SFRs How the SFR is Met us/library/cc771377.aspx. FMT_SMF.1 The client device platforms deployment of CA certificates to the platform trust store. The client device platform can enable or disable FIPS mode (only form of cryptographic algorithm configuration). Note, FIPS mode must be enabled/set in the evaluated configuration. Depending on FIPS mode, changes the behavior of the TOE when establishing connections to the CUCM SIP servers when certificate validation fails. The client device platform and the TOE updates are performed as described in FPT_TUD_EXT.1 Extended FPT_TST_EXT.1 Client device platform/TOE performs power-on/self-test of cryptographic modules. Refer to the FIPS certificate for more information identified in Section 1.6.1 in this document as related to the TOE. For the suite of power-on and cryptographic modules self-test that are run on the client device platform, refer to the Microsoft Windows 8 Security Target5 for information. During initial start-up of the TOE, tests are also run to verify its correct operation. These test may include power on self-tests for critical operational function and software integrity test to ensure correction operation of the software and module features. These tests are sufficient to verify that the correct version of the TOE software is running and the underlying operational environment is sufficient (e.g. memory and space allocations) as well as that the cryptographic operations are all performing as expected. The TOE’s Software Integrity Test is run automatically whenever the system image is loaded and confirms through use of digital signature verification that the image file that’s about to be loaded was properly signed and has maintained its integrity since being signed. The system image is digitally signed by Cisco prior to being made available for download from CCO. If any of the tests fail, the TOE will not boot and the Authorized Administrator is instructed to contact Cisco Technical Assistance Center (TAC). FPT_TUD_EXT.1 Depending on configuration, the client device platform or the TOE can initiate the update; however, the verification is always done by the client device platform. To check the current version, on the TOE click on the menu button and select Help and then select About Cisco Jabber. When software updates are made available by Cisco, an administrator can obtain, verify the integrity of, and install those updates. The updates can be downloaded from Cisco.com. A digital signature is used to verify software/firmware update files (to ensure they have not been modified from the originals distributed by Cisco) before they are used to actually update the TOE. The TOE can then be updated according to the instruction in the Cisco Jabber for Windows Common Criteria Configuration Guide When an invalid image is attempted to be installed, the TOE will display an error and will reject the image as an invalid or corrupt image. If this happens, the Administrator is instructed to contact Cisco Technical Assistance Center (TAC). FTP_ITC.1(2) There is no direct admin or user interaction on Jabber to configure or set the SRTP channel. The CUCM SIP Server administrator configures appropriately, and then each time a call is 5 http://www.commoncriteriaportal.org/products/ Cisco Jabber for Windows Security Target Page 40 of 41 TOE SFRs How the SFR is Met made the clients automatically start SRTP streams as negotiated. There is no user or admin interaction per-SRTP-channel. The CUCM SIP Server administrator can configure the port ranges for the voice and video streams. All communications with the CUCM SIP Server is protected by TLS. If network loss on the SRTP sessions occurs, the TOE automatically attempts to recover. If the user remains dissatisfied with the result, they can end the call and redial. The communication is initiated on the TOE by the user dialling a number or the SIP URI. Cisco Jabber for Windows Security Target Page 41 of 41 7 ANNEX B: REFERENCES The following documentation was used to prepare this ST: Table 20: References Identifier Description [CC_PART1] Common Criteria for Information Technology Security Evaluation – Part 1: Introduction and general model, dated September 2012, version 3.1, Revision 4, CCMB-2012-009-001 [CC_PART2] Common Criteria for Information Technology Security Evaluation – Part 2: Security functional components, dated September 2012, version 3.1, Revision 4, CCMB-2012-009- 002 [CC_PART3] Common Criteria for Information Technology Security Evaluation – Part 3: Security assurance components, dated September 2012, version 3.1, Revision 4, CCMB-2012-009- 003 [CEM] Common Methodology for Information Technology Security Evaluation – Evaluation Methodology, dated September 2012, version 3.1, Revision 4, CCMB-2012-009-004 [VoIP PP] Protection Profile for Voice Over IP (VoIP) Applications, version 1.3, 3 Nov 2014 [800-38A] NIST Special Publication 800-38A Recommendation for Block 2001 Edition Recommendation for Block Cipher Modes of Operation Methods and Techniques December 2001 [800-56A] NIST Special Publication 800-56A, March, 2007 Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised) [800-56B] NIST Special Publication 800-56B Recommendation for Pair-Wise, August 2009 Key Establishment Schemes Using Integer Factorization Cryptography [FIPS 140-2] FIPS PUB 140-2 Federal Information Processing Standards Publication Security Requirements for Cryptographic Modules May 25, 2001 [FIPS PUB 186-2] FIPS PUB 186-2 Federal Information Processing Standards Publication 2000 January 27 [FIPS PUB 186-3] FIPS PUB 186-3 Federal Information Processing Standards Publication Digital Signature Standard (DSS) June, 2009 [FIPS PUB 198-1] Federal Information Processing Standards Publication The Keyed-Hash Message Authentication Code (HMAC) July 2008 [800-90] NIST Special Publication 800-90A Recommendation for Random Number Generation Using Deterministic Random Bit Generators January 2012 [FIPS PUB 180-3] FIPS PUB 180-3 Federal Information Processing Standards Publication Secure Hash Standard (SHS) October 2008 Client Platform CC certification http://www.commoncriteriaportal.org/products/