Protection Profile - Common Criteria Evaluation and Validation ...

Security Requirements for Voice Over IP ApplicationInformation Assurance Directorate24 January 2013Version 0.6

Table of Contents1 INTRODUCTION .................................................................................................................................... 11.1 First Generation Protection Profiles ............................................................................................. 11.2 Compliant Targets of Evaluation ................................................................................................... 12 SECURITY PROBLEM DESCRIPTION ....................................................................................................... 22.1 Communications with the TOE ..................................................................................................... 22.2 Malicious “Updates” ..................................................................................................................... 33 SECURITY OBJECTIVES .......................................................................................................................... 33.1 Protected Communications .......................................................................................................... 33.2 Verifiable Updates ........................................................................................................................ 44 SECURITY REQUIREMENTS ................................................................................................................... 54.1 Conventions .................................................................................................................................. 54.2 TOE Security Functional Requirements ........................................................................................ 54.2.1 Cryptographic Support (FCS) ................................................................................................. 54.2.2 Identification and Authentication (FIA) .............................................................................. 134.2.3 Security Management (FMT) ................................................. Error! Bookmark not defined.4.2.4 Protection of the TSF (FPT) ................................................................................................. 154.2.5 Trusted Path/Channel (FTP) ................................................................................................ 164.3 Security Assurance Requirements .............................................................................................. 174.3.1 Class ADV: Development ..................................................................................................... 184.3.2 Class AGD: Guidance Documents ........................................................................................ 194.3.3 Class ATE: Tests ................................................................................................................... 224.3.4 Class AVA: Vulnerability assessment .................................................................................. 234.3.5 Class ALC: Life-cycle support ............................................................................................... 24RATIONALE .................................................................................................................................................. 26ANNEX A: SUPPORTING TABLES .................................................................................................................. 26Assumptions ........................................................................................................................................... 26Threats .................................................................................................................................................... 26Security Objectives for the TOE .............................................................................................................. 27ANNEX B: NIST SP 800-53/CNSS 1253 MAPPING ........................................................................................ 28ANNEX C: ADDITIONAL REQUIREMENTS ..................................................................................................... 29ii

List of TablesTable 1: TOE Security Assurance Requirements ......................................................................................... 17Table 2: TOE Assumptions .......................................................................................................................... 26Table 3: Threats .......................................................................................................................................... 26Table 4: Security Objectives for the TOE .................................................................................................... 27Table 5: Security Objectives for the Operational Environment .................................................................. 27List of FiguresFigure 1: VoIP Communication ..................................................................................................................... 2Revision HistoryVersion Date Description1.0 Initial releaseiii

1 INTRODUCTION1 This Protection Profile (PP), describing security requirements for a Voice over Internet Protocol (VoIP)application, is intended to provide a minimal, baseline set of requirements that are targeted atmitigating well defined and described threats. It represents an evolution of “traditional” ProtectionProfiles and the associated evaluation of the requirements contained within the document. Thisintroduction will describe the features of a compliant Target of Evaluation (TOE), and will also discussthe evolutionary aspects of the PP as a guide to readers of the document.1.1 First Generation Protection Profiles2 What makes security for mobility different than other technologies? Regardless of the actual technicalsecurity features of individual devices, a wired computing or communications device has impliedsecurity if the physical environment where the device resides is protected by guards, dogs and fences.For mobility, these traditional physical protections are irrelevant. Not only are the wirelesscommunication channels more readily available to adversaries, but the devices themselves are alsoexpected to be multipurpose and used for both work and enterprise data. Mobility clearly brings newsecurity challenges.3 Some desired mobility security features might not be reasonably expected to appear within the nexteighteen months. Those features that go beyond where commercial industry is currently heading willprobably not be supported by interim mobility solutions, or by the first generation Mobility PPs. TheInformation Assurance Directorate (IAD) will work with vendors to determine how and when to obtainproducts with these features, and whether/when to create the corresponding PPs.1.2 Compliant Targets of Evaluation4 This is a PP for a VoIP application. The VoIP application in the context of this PP is part of the cell phoneworkspace that the enterprise can install for use by the phone user. The VoIP infrastructure for anenterprise can vary greatly, both in size and complexity. Many kinds of functionality are possible, oftendesirable, and sometimes necessary – including Session Border Controllers (SBC), gateways, trunking,and Network Address Translation (NAT) and firewall traversal. The VoIP Application in the context ofthis PP is considered to be a VoIP client that interacts with a SIP Server which provides registrar andproxy capabilities required for call-session management via SIP requests and responses to establish,process, and terminate VoIP calls. The VoIP Application will interact with a peer Application using theSecurity Real-Time Transport Protocol (SRTP) that has been established using the Session DescriptionProtocol (SDP) and the Security Descriptions for Media Streams (SDES) for SDP.5 While the functionality that the TOE is obligated to implement in response to the described threatenvironment is discussed in detail in later sections, it is useful to give a brief description here. CompliantTOEs will provide security functionality that addresses threats to the TOE. They must also protect thecommunications between itself and another VoIP client (i.e., cell phone) by using a SDES-SRTP-protectedchannel. Likewise, compliant TOEs must also protect communications between itself and the SIP Serverby using a Transport Layer Security (TLS)- and (optionally) a Datagram Transport Layer Security (DTLS)-protected signaling channel. To register the TOE within the domain, the TOE is required to be passwordauthenticated by the SIP Server. The TOE is required by this PP to make use of certificates toauthenticate the both the SIP server end and the TOE itself through the TLS connection. The TOE mustprovide the ability to report its version to the Enterprise so that a determination as to whether it can beupdated can be made. As shown in Figure 1, the TOE communicates with other VoIP clients and SIP1

Servers over protected channels. Components in red are addressed in this PP. Components in blue areaddressed in related PPs.Figure 1: VoIP Communication6 The set of requirements in this PP is purposely limited in scope in order to promote quicker, less costlyevaluations that provide value to the end users. Security Targets (ST)s that include a large amount ofadditional functionality (and requirements) are discouraged.2 SECURITY PROBLEM DESCRIPTION7 As detailed in the previous section, the security problem to be addressed by compliant TOEs is describedby threats and policies that are common to a mobile VoIP application, as opposed to those that might betargeted at the specific functionality of a specific type of VoIP application. Annex A: Supporting Tablespresents the Security Problem Description (SPD) in a more “traditional” form. The following sectionsdetail the problems that compliant TOEs will address; references to the “traditional” statements inAnnex A are included.2.1 Communications with the TOE8 Mobile VoIP applications communicate with the SIP Server as well as other mobile VoIP applicationclients, over internet protocol (IP). The endpoints of the communication can be both geographically andlogically distant from the TOE, and pass through a variety of other systems. These intermediate systemsmay be under the control of an adversary, and offer an opportunity for communications with the TOE tobe compromised. Although a VPN tunnel provides an outer layer of security for the TOE to communicatewith the Enterprise, additional inner layers of security are needed to protect call control traffic (TLStunnel) and Real Time Services media streams (SRTP tunnel).2

9 Plaintext communication with the TOE may allow critical data (such as passwords, keys, configurationsettings, and certificates) to be read and/or manipulated directly by intermediate systems, leading to acompromise of the TOE. Several protocols can be used to provide protection; however, each of theseprotocols has many options that can be implemented and still have the overall protocol implementationremain compliant to the protocol specification listed in the RFC. Some of these options can havenegative impacts on the security of the connection. For instance, using a weak encryption algorithm(even one that is allowed by the RFC, such as DES) can allow an adversary to read and even manipulatethe data on the encrypted channel, thus circumventing countermeasures in place to prevent suchattacks. Further, if the protocol is implemented with little-used or non-standard options, it may becompliant with the protocol specification but will not be able to interact with other, diverse equipmentthat is typically found in large enterprises.10 Even though the communication path is protected, there is a possibility that the external user (be it a SIPserver, or another VoIP application) could be duped into thinking that a malicious third-party user orsystem is the TOE. For instance, a middleman could intercept a connection request to the TOE, andrespond to the external user as if it were the TOE. In a similar manner, the TOE could also be duped intothinking that it is establishing communications with a legitimate remote entity when in fact it is not. Anattacker could also mount a malicious man-in-the-middle-type of attack, in which an intermediatesystem is compromised, and the traffic is proxied, examined, and modified by this system. This attackcan even be mounted via encrypted communication channels if appropriate countermeasures are notapplied. These attacks are, in part, enabled by a malicious attacker capturing VoIP traffic (for instance,an authentication session) and “playing back” that traffic in order to fool an endpoint into thinking itwas communicating with a legitimate remote entity.[T.UNAUTHORIZED_ACCESS]2.2 Malicious “Updates”11 Since a common attack vector used involves attacking unpatched versions of software containing wellknownflaws, updating the VoIP application is necessary to ensure that changes to the threatenvironment are addressed. While the actual update functionality will be implemented in theEnterprise, it is important that the Enterprise be able to accurately determine whether the TOE needs tobe updated so that it can be kept current and any inherent vulnerabilities that are discovered can bequickly addressed.[T.UNAUTHORIZED_UPDATE]3 SECURITY OBJECTIVES12 Compliant TOEs will provide security functionality that address threats to the TOE and implementspolicies that are imposed by law or regulation. The following sections provide a description of thisfunctionality in light of the threats previously discussed that motivate its inclusion in compliant TOEs.The security functionality provided includes protected communications to and between elements of theTOE and the SIP Server and the ability to verify the source of updates to the TOE.3.1 Protected Communications13 To address the issues concerning transmitting sensitive data to and from the TOE described in Section2.1, “Communications with the TOE”, compliant TOEs will provide encryption for these communicationpaths between themselves and the SIP Server. These channels are implemented using TLS for3

communication with the SIP Server and SDES-SRTP for communication between endpoints (another VoIPapplication). TLS and SDES-SRTP are specified by RFCs that offer a variety of implementation choices.Requirements have been imposed on TLS and SDES-SRTP to provide interoperability and resistance tocryptographic attack. Whether such additional mechanisms will be evaluated is Scheme-dependent. Ifsuch additional mechanisms are not evaluated, guidance must be given to the administrator so that theycan be disabled (or shown not to affect the specified security functionality) during TOE operation.14 In addition to providing protection from disclosure (and detection of modification) for thecommunications, the TLS protocol described in this document offers two-way authentication of eachendpoint in a cryptographically secure manner, meaning that even if there was a malicious attackerbetween the two endpoints, any attempt to represent themselves to either endpoint of thecommunications path as the other communicating party would be detected. The requirements on theTLS protocol, in addition to the structure of the protocol itself, provide protection against replay attackssuch as those described in Section 2.1, usually by including a unique value in each communication sothat replay of that communication can be detected.(FCS_CKM_EXT.4, FCS_COP.1(*), FCS_RBG_EXT.1, FIA_SIPC_EXT.1,, FCS_SRTP_EXT.1, FCS_TLS_EXT.1,FIA_X509_EXT.1, FTP_ITC.1(*))3.2 Verifiable Updates15 As outlined in Section 2.2, “Malicious Updates”, failure by the Enterprise to be able to determine thatthe TOE needs to be updated could lead to a compromise of the device. Therefore, the TOE is requiredto be able to provide its current version to the Enterprise through a defined interface.(FPT_TUD_EXT.1)4

4 SECURITY REQUIREMENTS16 The Security Functional Requirements included in this section are derived from Part 2 of the CommonCriteria for Information Technology Security Evaluation, Version 3.1, Revision 3, with additional extendedfunctional components.4.1 Conventions17 The CC defines operations on Security Functional Requirements (SFR): assignments, selections,assignments within selections and refinements. This document uses the following font conventions toidentify 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 theelement 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).18 Explicitly stated SFRs are identified by having a label ‘EXT’ after the requirement name for TOE SFRs.4.2 TOE Security Functional Requirements19 This section identifies the Security Functional Requirements for the TOE. It should be noted that severalprotocols are used during call establishment: DTLS/TLS, SIP, SDP, and SDES-SRTP. While these protocols(and associated TSS and Testing Assurance Activities) are specified separately, it is expected that acomprehensive description and end-to-end test case/cases can be used to describe and demonstratethe capabilities of the TOE.20 As indicated above, there is no notion of an “administrator” of the TOE on the device. Administrativesettings will be performed either as part of provisioning the device with the TOE or through somefunction of an MDM capability. In the following requirements, the term “Enterprise” is used to capturethis notion of an administrative entity for the TOE.4.2.1 Cryptographic Support (FCS)21 In implementing and evaluating the cryptographic functionality of the TOE, it is important to point outthat while the production of random keys and salts is required by the TOE, these requirements arecontained by reference in the specification of the underlying protocols (TLS, DTLS, and SDES) rather thanexplicitly through, for example, FCS_CKM.1.FCS_CKM_EXT.4 Cryptographic key material destruction (Key Material)FCS_CKM_EXT.4.1 The TSF shall zerioize all plaintext secret and private cryptographic keys and CriticalSecurity Parameters (CSPs) when no longer required.Application Note:5

22 “CCritical Security Parameters” are defined in FIPS 140-2 as “security-related information (e.g., secretand private cryptographic keys, and authentication data such as passwords and PINs) whose disclosureor modification can compromise the security of a cryptographic module.”23 The zeroization indicated above applies to each intermediate storage area for plaintextkey/cryptographic critical security parameter (i.e., any storage, such as memory buffers, that is includedin the path of such data) upon the transfer of the key/cryptographic critical security parameter toanother location.Assurance Activity:TSS24 The evaluator shall check to ensure the TSS describes each of the secret keys (keys used for symmetricencryption), private keys, and CSPs used to generate key; when they are zeroized (for example,immediately after use, on system shutdown, etc.); and the type of zeroization procedure that isperformed (overwrite with zeros, overwrite three times with random pattern, etc.). If different types ofmemory are used to store the materials to be protected, the evaluator shall check to ensure that the TSSdescribes the zeroization procedure in terms of the memory in which the data are stored (for example,"secret keys stored on flash are zeroized by overwriting once with zeros, while secret keys stored on theinternal hard drive are zeroized by overwriting three times with a random pattern that is changed beforeeach write").FCS_COP.1(1) Cryptographic Operation (Data Encryption/Decryption)FCS_COP.1.1 The TSF shall perform encryption and decryption in accordance with a specifiedcryptographic algorithm AES operating in [assignment: one or more modes] and cryptographic key sizes128-bits, 256-bits, and [selection: 192 bits, no other key sizes] that meets the following: FIPS PUB 197, “Advanced Encryption Standard (AES)” [selection: NIST SP 800-38A, NIST SP 800-38B, NIST SP 800-38C, NIST SP 800-38D, NIST SP 800-38E]Application Note:25 For the assignment, the ST author should choose the mode or modes in which AES operates. For the firstselection, the ST author should choose the key sizes that are supported by this functionality. For thesecond selection, the ST author should choose the standards that describe the modes specified in theassignment.Assurance Activity:Test26 The evaluator shall use tests appropriate to the modes selected in the above requirement from "TheAdvanced Encryption Standard Algorithm Validation Suite (AESAVS)", "The XTS-AES Validation System(XTSVS)", The CMAC Validation System (CMACVS)", "The Counter with Cipher Block Chaining-MessageAuthentication Code (CCM) Validation System (CCMVS)", and "The Galois/Counter Mode (GCM) andGMAC Validation System (GCMVS)" (these documents are available fromhttp://csrc.nist.gov/groups/STM/cavp/index.html) as a guide in testing the requirement above. This willrequire that the evaluator have a reference implementation of the algorithms known to be good that canproduce test vectors that are verifiable during the test.6

FCS_COP.1(2) Cryptographic Operation (for cryptographic signature)FCS_COP.1.1(2) Refinement: The TSF shall perform cryptographic signature services in accordancewith a [selection:(1) Digital Signature Algorithm (DSA) with a key size (modulus) of 2048 bits or greater,(2) RSA Digital Signature Algorithm (rDSA) with a key size (modulus) of 2048 bits orgreater, or(3) Elliptic Curve Digital Signature Algorithm (ECDSA) with a key size of 256 bits or greater]Application Note: As the preferred approach for cryptographic signature, elliptic curves willbe required in future publications of this PP.that meets the following:Case: Digital Signature AlgorithmFIPS PUB 186-3, “Digital Signature Standard”Case: RSA Digital Signature Algorithm FIPS PUB 186-2 or FIPS PUB 186-3, “Digital Signature Standard”Case: Elliptic Curve Digital Signature AlgorithmApplication Note:FIPS PUB 186-3, “Digital Signature Standard”The TSF shall implement “NIST curves” P-256, P-384 and [selection:P-521, no other curves] (as defined in FIPS PUB 186-3, “DigitalSignature Standard”).27 The ST Author should choose the algorithm implemented to perform digital signatures; if more than onealgorithm is available, this requirement (and the corresponding FCS_CKM.1 requirement) should beiterated to specify the functionality. For the algorithm chosen, the ST author should make theappropriate assignments/selections to specify the parameters that are implemented for that algorithm.28 While FIPS PUB 186-2 has been revised by FIPS PUB 186-3, it is still allowable to claim conformance tothe older standard while products are transitioning to the newer standard. At a future date, products willnot be allowed to claim conformance to FIPS PUB 186-2. The ST author makes the selection of theconformance standard as appropriate for the TOE.29 For elliptic curve-based schemes, the key size refers to the log2 of the order of the base point. As thepreferred approach for digital signatures, ECDSA will be required in future publications of this PP.Assurance Activity:Test30 The evaluator shall use the signature generation and signature verification portions of "The DigitalSignature Algorithm Validation System” (DSAVS or DSA2VS), "The Elliptic Curve Digital Signature7

Algorithm Validation System” (ECDSAVS or ECDSA2VS), and "The RSA Validation System” (RSAVS) as aguide in testing the requirement above. The Validation System used shall comply with the conformancestandard identified in the ST (i.e. FIPS PUB 186-2 or FIPS PUB 186-3). This will require that the evaluatorhave a reference implementation of the algorithms known to be good that can produce test vectors thatare verifiable during the test.FCS_COP.1(3) Cryptographic Operation (Cryptographic Hashing)FCS_COP.1.1(3) Refinement: The TSF shall perform cryptographic hashing services in accordance with aspecified cryptographic algorithm [selection: SHA-1, SHA-256, SHA-384, SHA-512] and cryptographic keymessage digest sizes [selection: 160, 256, 384, 512] bits that meet the following: FIPS Pub 180-3, “SecureHash Standard.”Application Note:31 The selection of the hashing algorithm must correspond to the selection of the message digest size; forexample, if SHA-1 is chosen, then the only valid message digest size selection would be 160 bits.Assurance Activity:Test32 The evaluator shall use "The Secure Hash Algorithm Validation System (SHAVS)" as a guide in testing therequirement above. This will require that the evaluator have a reference implementation of thealgorithms known to be good that can produce test vectors that are verifiable during the test.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 accordancewith a specified cryptographic algorithm HMAC-[selection: SHA-1, SHA-256, SHA-384, SHA-512], key sizes[assignment: key size (in bits) used in HMAC], and message digest sizes [selection: 160, 256, 384, 512]bits that meet the following: FIPS Pub 198-1, "The Keyed-Hash Message Authentication Code, and FIPSPub 180-3, “Secure Hash Standard.”Application note:33 In future versions of this PP, SHA-1 may be removed as a valid hash algorithm. Developers areencouraged to transition to the other listed hash alogorithms.Assurance Activity:Test34 The evaluator shall use "The Keyed-Hash Message Authentication Code (HMAC) Validation System(HMACVS) " as a guide in testing the requirement above. This will require that the evaluator have areference implementation of the algorithms known to be good that can produce test vectors that areverifiable during the test.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[selection, choose one of: NIST Special Publication 800-90 using [selection: Hash_DRBG (any),8

HMAC_DRBG (any), CTR_DRBG (AES) , Dual_EC_DRBG (any)]; FIPS Pub 140-2 Annex C: X9.31 Appendix2.4 using AES] seeded by an entropy source that accumulates entropy from [selection: a software-basednoise source; a TSF-hardware-based noise source].FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded with a minimum number of bits of entropy atleast equal to the greatest bit length required by the protocols and functions supported by the TOE.Application Note:35 It is important to note that FCS_RBG_EXT.1 requires that all RBG operations done by the TSF are done bythe portion of the TSF that implements this requirement. This means that the creation of all random keymaterial for the TLS and SDES-SRTP connections must be performed by the TSF.36 NIST Special Pub 800-90, Appendix C describes the minimum entropy measurement that will probably berequired in future versions of FIPS-140. If possible this should be used immediately and be required infuture versions of this PP.37 For the first selection in FCS_RBG_EXT.1.1, the ST author should select the standard to which the RBGservices comply (either 800-90 or 140-2 Annex C).38 SP 800-90 contains four different methods of generating random numbers; each of these, in turn,depends on underlying cryptographic primitives (hash functions/ciphers). The ST author will select thefunction used (if 800-90 is selected), and include the specific underlying cryptographic primitives used inthe requirement or in the TSS. While any of the identified hash functions (SHA-1, SHA-256, SHA-384,SHA-512) are allowed for Hash_DRBG or HMAC_DRBG, only AES-based implementations for CTR_DRBGare allowed. While any of the curves defined in 800-90 are allowed for Dual_EC_DRBG, the ST author notonly must include the curve chosen, but also the hash algorithm used.39 For the second selection in FCS_RBG_EXT.1.1, the ST author indicates whether the sources of entropy aresoftware-based, hardware-based, or both. If there are multiple sources of entropy, the ST will elaborateeach entropy sources and whether it is hardware- or software-based. Hardware-based noise sources arepreferred.40 Note that for FIPS Pub 140-2 Annex C, currently only the method described in NIST-RecommendedRandom Number Generator Based on ANSI X9.31 Appendix A.2.4 Using the 3-Key Triple DES and AESAlgorithm, Section 3 is valid. If the key length for the AES implementation used here is different thanthat used to encrypt the user data, then FCS_COP.1 may have to be adjusted or iterated to reflect thedifferent key length. For the selection in FCS_RBG_EXT.1.2, the ST author selects the minimum numberof bits of entropy that is used to seed the RBG.41 The ST author also ensures that any underlying functions are included in the baseline requirements forthe TOE.Assurance Activity:TSS42 Documentation shall be produced – and the evaluator shall perform the activities – in accordance withAnnex D, Entropy and Documentation and Assessment.Test43 The evaluator shall also perform the following tests, depending on the standard to which the RBGconforms.9

Implementations Conforming to FIPS 140-2, Annex C44 The reference for the tests contained in this section is The Random Number Generator Validation System(RNGVS) [RNGVS]. The evaluator shall conduct the following two tests. Note that the "expected values"are produced by a reference implementation of the algorithm that is known to be correct. Proof ofcorrectness is left to each Scheme.45 The evaluator shall perform a Variable Seed Test. The evaluator shall provide a set of 128 (Seed, DT)pairs to the TSF RBG function, each 128 bits. The evaluator shall also provide a key (of the lengthappropriate to the AES algorithm) that is constant for all 128 (Seed, DT) pairs. The DT value isincremented by 1 for each set. The seed values shall have no repeats within the set. The evaluatorensure that the values returned by the TSF match the expected values.46 The evaluator shall perform a Monte Carlo Test. For this test, they supply an initial Seed and DT value tothe TSF RBG function; each of these is 128 bits. The evaluator shall also provide a key (of the lengthappropriate to the AES algorithm) that is constant throughout the test. The evaluator then invoke theTSF RBG 10,000 times, with the DT value being incremented by 1 on each iteration, and the new seed forthe subsequent iteration produced as specified in NIST-Recommended Random Number Generator Basedon ANSI X9.31 Appendix A.2.4 Using the 3-Key Triple DES and AES Algorithms, Section 3. The evaluatorensure that the 10,000 th value produced matches the expected value.Implementations Conforming to NIST Special Publication 800-9047 The evaluator shall perform 15 trials for the RBG implementation. If the RBG is configurable, theevaluator shall perform 15 trials for each configuration. The evaluator shall also confirm that theoperational guidance contains appropriate instructions for configuring the RBG functionality.48 If the RBG has prediction resistance enabled, each trial consists of (1) instantiate the deterministic RBG(DRBG), (2) generate the first block of random bits (3) generate a second block of random bits (4)uninstantiate. The evaluator verifies that the second block of random bits is the expected value. Theevaluator shall generate eight input values for each trial. The first is a count (0 – 14). The next three areentropy input, nonce, and personalization string for the instantiate operation. The next two areadditional input and entropy input for the first call to generate. The final two are additional input andentropy input for the second call to generate. These values are randomly generated. “Generate one blockof random bits” means to generate random bits with the number of returned bits equal to the OutputBlock Length (as defined in NIST SP 800-90).49 If the RBG does not have prediction resistance, each trial consists of (1) instantiate DRBG, (2) generatethe first block of random bits (3) reseed, (4) generate a second block of random bits (5) uninstantiate.The evaluator verifies that the second block of random bits is the expected value. The evaluator shallgenerate eight input values for each trial. The first is a count (0 – 14). The next three are entropy input,nonce, and personalization string for the instantiate operation. The fifth value is additional input to thefirst call to generate. The sixth and seventh are additional input and entropy input to the call to re-seed.The final value is additional input to the second generate call.50 The following paragraphs contain more information on some of the input values to begenerated/selected by the evaluator.51 Entropy input: the length of the entropy input value must equal the seed length.52 Nonce: If a nonce is supported (CTR_DRBG with no derivation function (df) does not use a nonce), thenonce bit length is one-half the seed length.10

53 Personalization string: The length of the personalization string must be

FCS_TLS_EXT.1 Transport Level SecurityFCS_TLS_EXT.1.1 The TSF shall implement the TLS 1.2 protocol (RFC 5246) compliant with Suite B Profilefor TLS (RFC 6460) using mutual authentication with certificates and ciphersuites:Mandatory Ciphersuites:TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 using the 256-bit prime modulus elliptic curvespecified in FIPS-186-2;TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 using the 384-bit prime modulus elliptic curvespecified in FIPS-186-2;Optional Ciphersuites:[selection:None;TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA using the 256-bit prime modulus elliptic curvespecified in FIPS-186-2;TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA using the 384-bit prime modulus elliptic curvespecified in FIPS-186-2;Application Note:58 The ciphersuites to be used in the evaluated configuration are limited by this requirement. The ST authorshould select the optional ciphersuites that are supported; if there are no ciphersuites supported otherthan the mandatory suites, then “None” should be selected. If administrative steps need to be taken sothat the suites negotiated by the implementation are limited to those in this requirement, theappropriate instructions need to be contained in the guidance called for by AGD_OPE.59 The Mandatory Suite B algorithms (RFC 6460) listed above are the preferred algorithms forimplementation. In addition, future publications of this PP will require that the TOE offer a means todeny all connection attempts using specified older versions of the SSL/TLS protocol.Assurance Activity:TSS60 The evaluator shall check the description of the implementation of this protocol in the TSS to ensure thatoptional characteristics (e.g., extensions supported, client authentication supported) are specified, andthe ciphersuites supported are specified as well. The evaluator shall check the TSS to ensure that theciphersuites specified are identical to those listed for this component.Test61 The evaluator shall also perform the following test:Test 1: The evaluator shall establish a TLS connection using each of the ciphersuites specified by therequirement. This connection may be established as part of the establishment of a higher-levelprotocol, e.g., as part of a SIP session. It is sufficient to observe (on the wire) the successfulnegotiation of a ciphersuite to satisfy the intent of the test; it is not necessary to examine thecharacteristics of the encrypted traffic in an attempt to discern the ciphersuite being used (forexample, that the cryptographic algorithm is 128-bit AES and not 256-bit AES).12

4.2.2 Identification and Authentication (FIA)FIA_SIPC_EXT.1 Session Initiation Protocol (SIP) ClientFIA_SIPC_EXT.1.1 The TSF shall implement the Session Initiation Protocol (SIP) that complies with RFC3261 using the Session Description Protocol (SDP) complying with RFC 4566 to describe the multimediasession 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 passwordauthentication 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 [assignment:positive integer of 8 or more] characters in the set of {upper case characters, lower case characters,numbers, and the following special characters: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, and “)”, and[assignment: other supported special characters]}.FIA_SIPC_EXT.1.4 Password entered by the user as per FIA_SIPC_EXT.1.2 shall be cleared by the TSFonce the TSF is notified that the REGISTER request was successful.Application Note:62 The only SIP request that is required to be authenticated (by the SIP Server) is the REGISTER request; theTOE supports this by providing a user-entered password. While the SIP Server will perform theenforcement and only register the user upon the presentation of the correct password, the client isrequired by the elements above to support passwords that are at least 8 characters long (the maximumlength is defined in the first assignment) and can contain the characters identified in FIA_SIPC_EXT.1.3(characters allowed by the TOE but not listed explicitly in the element should be identified in the secondassignment; otherwise “no other characters” is an acceptable assignment), and to prompt the user forthe password when it sends the REGISTER request.63 The intent of the FIA_SIPC_EXT.1.4 element is that the password used for SIP registration are notmaintained on the device, and must be re-entered by the user if an additional REGISTER function needsto be sent.Assurance Activity:TSS64 The evaluator shall examine the TSS to verify that it describes how the SIP session is established. Thisshall include the initiation of the SIP session, registration of the user, and how both outgoing andincoming calls are handled (initiated, described, and terminated). This description shall also include adescription of the handling of the password from the time it is entered by the user until the time it iscleared by the TSF.Test65 The evaluator shall also perform the following test:13

Test 1: The evaluator shall follow the procedure for initializing their device to include establishing aconnection to the SIP Server. The evaluator shall confirm that they are prompted for a passwordprior to successfully completing the SIP REGISTER request.Test 2: The evaluator shall follow the procedure for initializing their device to include establishing aconnection to the SIP Server. The evaluator shall confirm that entering an incorrect password resultsin the device not being registered by the SIP Server (e.g., they are unable to successful place orreceive calls). The evaluator shall also confirm that entering the correct password allows thesuccessful registration of the device (e.g., by being able to place and receive calls).Test 3: The evaluator shall set up the test environment such that a variety of passwords are shown tobe accepted by the TOE, such that the length and character set identified in FIA_SIPC_EXT.1.3 isrepresented. The test report shall contain a rationale by the evaluator that the test set used isrepresentative of the allowed lengths and characters.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 assocaited private key). While it is acceptable for the TSF itself to store and protect thesecertificates, it is also allowable for the Mobile OS to provide these storage and protection functions. Ifthe TSF provides these functions, then the FIA_X509_EXT.1.Y element shall be included in the body ofthe ST in this component.FIA_X509_EXT.1 Extended: X.509 CertificatesFIA_X509_EXT.1.1 The TSF shall use X.509v3 certificates as defined by RFC 5280 to supportauthentication for TLS connections.Application Note:It should be noted that RFC 5280 defines certificate validation and certification path validationrequirements that must be implemented by the TOE as per this requirement..FIA_X509_EXT.1.2 The TSF shall provide the capability for the Enterprise to load X.509v3 certificates intothe TOE for use by the security functions specified in this PP.FIA_X509_EXT.1.3 The TSF shall validate the certificate using [selection: the Online Certificate StatusProtocol (OCSP) as specified in RFC 2560, 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 establishmentof the TLS connection.Application Note:14

The intent of FIA_X509_EXT.1.5 is that the TOE is configurable to allow or disallow session establishmentif the TOE cannot connect to an entity responsible for providing certificate validation information. Forinstance, if a CRL cannot be obtained because a machine is down, or the network path is broken, theadministrator may elect to configure the TOE to allow sessions to continued to be established, ratherthan terminate the TOE’s ability to establish any new connections because it cannot reach the CA.Assurance Activity:Test66 The evaluator shall perform the following tests for each function in the system that requires the use ofcertificates:Test 1: The evaluator shall demonstrate that using a certificate without a valid certification path resultsin the function failing. The evaluator shall then load a certificate or certificates needed to validate thecertificate to be used in the function, and demonstrate that the function succeeds. The evaluator thenshall delete one of the certificates, and show that the function fails.Additional testing to ensure the requirements are satisfied is performed in conjunction with the TLSrequirements in FTP_ITC.1(2).4.2.3 Protection of the TSF (FPT)FPT_TUD_EXT.1 Extended: Trusted UpdateFPT_TUD_EXT.1.1 The TSF shall provide the Enterpise the ability to query the current version of the TOEsoftware.Application Note:67 Any update of the TOE will be handled by a function of the Mobile OS and is not a function of the TOEitself. However, the TOE must have the ability to correctly report its version to the Mobile OS in order tofacilitate decisions on whether to perform the update.Assurance Activity:TSS68 The evaluator shall check the TSS to determine that it describes the method by which the TOE reports itscurrent version.Guidance69 The TOE guidance shall contain the invocation sequence necessary to obtain the current version of theTOE.Test70 The evaluator shall perform the following test:Test 1: The evaluator shall invoke Enterprise functionality to query the current version of the TOE.The evaluator shall confirm that the current version of the TOE is returned.15

4.2.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 remoteVoIP application using SDES-SRTP as specified in FCS_SRTP_EXT.1 that is logically distinct from otherommunication channels and provides assured identification of its end points and protection of thechannel data from modification and disclosure.FTP_ITC.1.2(1) The TSF shall permit the TOE or the remote VoIP application to initiate communicationvia the trusted channelFTP_ITC.1.3(1) The TSF shall initiate communication via the trusted channel for [all communicationsbetween the two devices].Application Note:71 This requirement addresses the case where the communications is established between a VoIPApplication on another device and the TOE.Assurance Activity:TSS72 The evaluator shall check the TSS section to confirm that it describes how this requirement isimplemented in the TOE.Test73 The evaluator shall verify that communication can be initiated from both the TSF and the remote VoIPApplication.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 SIPServer using TLS [selection: “and no other protocol”, “and DTLS”] as specified in FCS_TLS_EXT.1[selection: “only”, “and in FCS_DTLS_EXT.1”] that is logically distinct from other communicationchannels and provides assured identification of its end points and protection of the channel data frommodification and or disclosure.FTP_ITC.1.2(2) The TSF shall permit the TSF to initiate communication via the trusted channelFTP_ITC.1.3(2) The TSF shall initiate communication via the trusted channel for [all communications withthe SIP server].Application Note:74 The TOE will establish a connection with the SIP server on start-up, and this will persist as long as thedevice is powered on and able to send/receive calls. While the TOE is required to be able to use TLS toestablish this connection, DTLS is also allowed. If DTLS is also implemented, then the ST author shouldmake the second of each selection in FTP_ITC.1.1(2); otherwise the first selection will be made. If DTLS isimplemented, the DTLS requirement in Annex C will also be moved to the body of the ST.16

Assurance Activity:TSF75 The evaluator shall check the TSS section to confirm that it describes how this requirement isimplemented in the TOE.76 Test77 Testing for this requirement is performed by activities in FTP_ITC.1(1) and FCS_TLS_EXT.1 (andFCS_DTLS_EXT.1 where that component is implemented by the TSF).4.3 Security Assurance Requirements78 The Security Objectives for the TOE in Section 3 were constructed to address threats identified inSection 2. The Security Functional Requirements (SFRs) in Section 4.2 are a formal instantiation of theSecurity Objectives. The PP draws the Security Assurance Requirements (SARs) from EAL1 to frame theextent to which the evaluator assesses the documentation applicable for the evaluation and performsindependent testing.79 While this section contains the complete set of SARs from the CC, the Assurance Activities to beperformed by an evaluator are detailed both in Section 4.2 as well as in this section.80 The general model for evaluation of TOEs against STs written to conform to this PP is as follows:81 After the ST has been approved for evaluation, the Common Criteria Testing Laboratory (CCTL) willobtain the TOE, supporting environmental IT, and the administrative guides for the TOE. The AssuranceActivities listed in the ST (which will be refined by the CCTL to be TOE-specific, either within the ST or ina separate document) will then be performed by the CCTL. The CCTL is also expected to perform all ofthe actions mandated by the Common Evaluation Methodology (CEM) for EAL1. The results of theseactivities will be documented and presented (along with the administrative guidance used) forvalidation.82 For each family, “Developer Notes” are provided on the developer action elements to clarify what, ifany, additional documentation/activity needs to be provided by the developer. For thecontent/presentation and evaluator activity elements, additional assurance activities (to those alreadycontained in Section 4.2 and the CEM for EAL1) are described as a whole for the family, rather than foreach element. Additionally, the assurance activities described in this section are complementary tothose specified in Section 4.2.83 The TOE security assurance requirements, summarized in Table 1, identify the management andevaluative activities required to address the threats identified in Section 2 of this PP.Table 1: TOE Security Assurance RequirementsAssurance ClassDevelopmentGuidance DocumentsAssuranceComponentsADV_FSP.1AGD_OPE.1AGD_PRE.1Assurance Components DescriptionBasic Functional SpecificationOperational User GuidancePreparative User Guidance17

Assurance ClassTestsVulnerability AssessmentLife Cycle SupportAssuranceComponentsATE_IND.1AVA_VAN.1ALC_CMC.1ALC_CMS.1Assurance Components DescriptionIndependent Testing - ConformanceVulnerability AnalysisLabeling of the TOETOE CM Coverage4.3.1 Class ADV: Development84 At EAL1, the TOE information is contained in the TOE Summary Specification (TSS) portion of the STguidance as well as documentation available to the end user. While it is not required that the TOEdeveloper write the TSS, the TOE developer must concur with the description of the product that iscontained in the TSS as it relates to the functional requirements. The Assurance Activities contained inSection 4.2 should provide the ST authors with sufficient information to determine the appropriatecontent for the TSS section.4.3.1.1 ADV_FSP.1 Basic functional specification85 The functional specification describes the TOE Security Functionality Interfaces (TSFIs). At EAL1, it is notnecessary to have a formal or complete specification of these interfaces. Additionally, because TOEsconforming to this PP will necessarily have interfaces to the Operational Environment that are notdirectly invokable by TOE users, there is little point specifying that such interfaces be described sinceonly indirect testing of such interfaces may be possible. For this PP, the activities for this family shouldfocus on understanding the interfaces presented in the TSS in response to the functional requirementsand the interfaces presented in the AGD documentation. No additional “functional specification”documentation is necessary to satisfy the assurance activities specified.86 The interfaces that need to be evaluated are characterized through the information needed to performthe assurance activities listed, rather than as an independent, abstract list.Developer action elements:ADV_FSP.1.1DADV_FSP.1.2DDeveloper Note:The developer shall provide a functional specification.The developer shall provide a tracing from the functionalspecification to the SFRs.As indicated in the introduction to this section, the functionalspecification is comprised of the information contained in theAGD_OPR and AGD_PRE documentation, coupled with theinformation provided in the TSS of the ST. The assurance activities inthe functional requirements point to evidence that should exist inthe documentation and TSS section. Since these are directlyassociated with the SFRs, the tracing in element ADV_FSP.1.2D is18

implicitly already done and no additional documentation isnecessary.Content and presentation elements:ADV_FSP.1.1CADV_FSP.1.2CADV_FSP.1.3CADV_FSP.1.4CThe functional specification shall describe the purpose and methodof use for each SFR-enforcing and SFR-supporting TSFI.The functional specification shall identify all parameters associatedwith each SFR-enforcing and SFR-supporting TSFI.The functional specification shall provide rationale for the implicitcategorization of interfaces as SFR-non-interfering.The tracing shall demonstrate that the SFRs trace to TSFIs in thefunctional specification.Evaluator action elements:ADV_ FSP.1.1EADV_ FSP.1.2EThe evaluator shall confirm that the information provided meets allrequirements for content and presentation of evidence.The evaluator shall determine that the functional specification is anaccurate and complete instantiation of the SFRs.Assurance Activity:87 There are no specific assurance activities associated with these SARs. The functional specificationdocumentation is provided to support the evaluation activities described in Section 4.2, and otheractivities described for AGD, ATE, and AVA SARs. The requirements on the content of the functionalspecification information is implicitly assessed by virtue of the other assurance activities beingperformed; if the evaluator is unable to perform an activity because the there is insufficient interfaceinformation, then an adequate functional specification has not been provided.4.3.2 Class AGD: Guidance Documents88 The guidance documents will be provided with the developer’s security target. Guidance must include adescription of how the authorized user verifies that the Operational Environment can fulfill its role forthe security functionality. The documentation should be in an informal style and readable by anauthorized user.89 Guidance must be provided for every operational environment that the product supports as claimed inthe ST. This guidance includesinstructions to successfully install the TOE in that environment; andinstructions to manage the security of the TOE as a product and as a component of the largeroperational environment.19

90 Guidance pertaining to particular security functionality is also provided; specific requirements on suchguidance are contained in the assurance activities specified in Section 4.2.4.3.2.1 AGD_OPE.1 Operational User GuidanceDeveloper action elements:AGD_OPE.1.1DDeveloper Note:The developer shall provide operational user guidance.Rather than repeat information here, the developer should review theassurance activities for this component to ascertain the specifics of theguidance that the evaluators will be checking for. This will provide thenecessary information for the preparation of acceptable guidance.Content and presentation elements:AGD_OPE.1.1CAGD_OPE.1.2CAGD_OPE.1.3CAGD_OPE.1.4CAGD_OPE.1.5CAGD_OPE.1.6CAGD_OPE.1.7CThe operational user guidance shall describe what the authorized useraccessiblefunctions and privileges that should be controlled in a secureprocessing environment, including appropriate warnings.The operational user guidance shall describe, for the authorized user, how touse the available interfaces provided by the TOE in a secure manner.The operational user guidance shall describe, for the authorized user, theavailable functions and interfaces, in particular all security parameters underthe control of the user, indicating secure values as appropriate.The operational user guidance shall, for the authorized user, clearly presenteach type of security-relevant event relative to the user-accessible functionsthat need to be performed, including changing the security characteristics ofentities under the control of the TSF.The operational user guidance shall identify all possible modes of operation ofthe TOE (including operation following failure or operational error), theirconsequences and implications for maintaining secure operation.The operational user guidance shall, for the authorized user, describe thesecurity measures to be followed in order to fulfill the security objectives forthe operational environment as described in the ST.The operational user guidance shall be clear and reasonable.Evaluator action elements:AGD_OPE.1.1EThe evaluator shall confirm that the information provided meets allrequirements for content and presentation of evidence.20

Assurance Activity:91 Some of the contents of the operational guidance will be verified by the assurance activities in Section4.2 and evaluation of the TOE according to the CEM. The following additional information is alsorequired.92 The operational guidance shall contain instructions for configuring the cryptographic engine associatedwith the evaluated configuration of the TOE. It shall provide a warning to the administrator that use ofother cryptographic engines was not evaluated nor tested during the CC evaluation of the TOE.93 The operational guidance shall contain instructions for specifying the ports used for SRTP.4.3.2.2 AGD_PRE.1 Preparative proceduresDeveloper action elements:AGD_PRE.1.1DDeveloper Note:The developer shall provide the TOE including its preparative procedures.As with the operational guidance, the developer should look to the assuranceactivities to determine the required content with respect to preparativeprocedures.Content and presentation elements:AGD_PRE.1.1CAGD_PRE.1.2CThe preparative procedures shall describe all the steps necessary for secureacceptance of the delivered TOE in accordance with the developer's deliveryprocedures.The preparative procedures shall describe all the steps necessary for secureinstallation of the TOE and for the secure preparation of the operationalenvironment in accordance with the security objectives for the operationalenvironment as described in the ST.Evaluator action elements:AGD_PRE.1.1EAGD_PRE.1.2EThe evaluator shall confirm that the information provided meets allrequirements for content and presentation of evidence.The evaluator shall apply the preparative procedures to confirm that the TOEcan be prepared securely for operation.Assurance Activity:21

94 As indicated in the introduction above, there are significant expectations with respect to thedocumentation—especially when configuring the operational environment to support TOE functionalrequirements.4.3.3 Class ATE: Tests95 Testing is specified for functional aspects of the system as well as aspects that take advantage of designor implementation weaknesses. The former is done through ATE_IND family, while the latter is throughthe AVA_VAN family. At the assurance level specified in this PP, testing is based on advertisedfunctionality and interfaces with dependency on the availability of design information. One of theprimary outputs of the evaluation process is the test report as specified in the following requirements.4.3.3.1 ATE_IND.1 Independent testing - Conformance96 Testing is performed to confirm the functionality described in the TSS as well as the administrative(including configuration and operation) documentation provided. The focus of the testing is to confirmthat the requirements specified in Section 4.2 are being met, although some additional testing isspecified for SARs in Section 4.3. The Assurance Activities identify the additional testing activitiesassociated with these components. The evaluator produces a test report documenting the plan for andresults of testing, as well as coverage arguments focused on the platform/TOE combinations that areclaiming conformance to this PP.Developer action elements:ATE_IND.1.1DThe developer shall provide the TOE for testing.Content and presentation elements:ATE_IND.1.1CThe TOE shall be suitable for testing.Evaluator action elements:ATE_IND.1.1EATE_IND.1.2EThe evaluator shall confirm that the information provided meets allrequirements for content and presentation of evidence.The evaluator shall test a subset of the TSF to confirm that the TSF operates asspecified.Assurance Activity:97 The evaluator shall prepare a test plan and report documenting the testing aspects of the system. Thetest plan covers all of the testing actions contained in the CEM and the body of this PP’s AssuranceActivities. While it is not necessary to have one test case per test listed in an Assurance Activity, theevaluators must document in the test plan that each applicable testing requirement in the ST is covered.98 The Test Plan identifies the platforms to be tested, and for those platforms not included in the test planbut included in the ST, the test plan provides a justification for not testing the platforms. Thisjustification must address the differences between the tested platforms and the untested platforms, andmake an argument that the differences do not affect the testing to be performed. It is not sufficient to22

merely assert that the differences have no affect; rationale must be provided. If all platforms claimed inthe ST are tested, then no rationale is necessary.99 The test plan describes the composition of each platform to be tested, and any setup that is necessarybeyond what is contained in the AGD documentation. It should be noted that the evaluators areexpected to follow the AGD documentation for installation and setup of each platform either as part of atest or as a standard pre-test condition. This may include special test drivers or tools. For each driver ortool, an argument (not just an assertion) is provided that the driver or tool will not adversely affect theperformance of the functionality by the TOE and its platform. This also includes the configuration of thecryptographic engine to be used. The cryptographic algorithms implemented by this engine arethose specified by this PP and used by the cryptographic protocols being evaluated (SDES, TLS,DTLS).100 The test plan identifies high-level test objectives as well as the test procedures to be followed to achievethose objectives. These procedures include expected results. The test report (which could just be anannotated version of the test plan) details the activities that took place when the test procedures wereexecuted, and includes the actual results of the tests. This shall be a cumulative account, so if there wasa test run that resulted in a failure; a fix installed; and then a successful re-run of the test, the reportwould show a “fail” and “pass” result (and the supporting details), and not just the “pass” result.4.3.4 Class AVA: Vulnerability assessment101 For the first generation of this protection profile, the evaluation lab is expected to survey open sourcesto learn what vulnerabilities have been discovered in these types of products. In most cases, thesevulnerabilities will require sophistication beyond that of a basic attacker. Until penetration tools arecreated and uniformly distributed to the evaluation labs, evaluators will not be expected to test forthese vulnerabilities in the TOE. The labs will be expected to comment on the likelihood of thesevulnerabilities given the documentation provided by the vendor. This information will be used in thedevelopment of penetration testing tools and for the development of future protection profiles.4.3.4.1 AVA_VAN.1 Vulnerability surveyDeveloper action elements:AVA_VAN.1.1DThe developer shall provide the TOE for testing.Content and presentation elements:AVA_VAN.1.1CThe TOE shall be suitable for testing.Evaluator action elements:AVA_VAN.1.1EAVA_VAN.1.2EAVA_VAN.1.3EThe evaluator shall confirm that the information provided meets allrequirements for content and presentation of evidence.The evaluator shall perform a search of public domain sources toidentify potential vulnerabilities in the TOE.The evaluator shall conduct penetration testing, based on the23

Assurance Activity:identified potential vulnerabilities, to determine that the TOE isresistant to attacks performed by an attacker possessing Basic attackpotential.102 As with ATE_IND the evaluator shall generate a report to document their findings with respect to thisrequirement. This report could physically be part of the overall test report mentioned in ATE_IND, or aseparate document. The evaluator performs a search of public information to determine thevulnerabilities that have been found in Mobility {mobility component} in general, as well as those thatpertain to the particular TOE. The evaluator documents the sources consulted and the vulnerabilitiesfound in the report. For each vulnerability found, the evaluator either provides a rationale with respectto its non-applicability or the evaluator formulates a test (using the guidelines provided in ATE_IND) toconfirm the vulnerability, if suitable. Suitability is determined by assessing the attack vector needed totake advantage of the vulnerability. For example, if the vulnerability can be detected by pressing a keycombination on boot-up, a test would be suitable at the assurance level of this PP. If exploiting thevulnerability requires expert skills and an electron microscope, for instance, then a test would not besuitable and an appropriate justification would be formulated.4.3.5 Class ALC: Life-cycle support103 At the assurance level provided for TOEs conformant to this PP, life-cycle support is limited to end-uservisibleaspects of the life-cycle, rather than an examination of the TOE vendor’s development andconfiguration management process. This is not meant to diminish the critical role that a developer’spractices play in contributing to the overall trustworthiness of a product; rather, it’s a reflection on theinformation to be made available for evaluation at this assurance level.4.3.5.1 ALC_CMC.1 Labeling of the TOE104 This component is targeted at identifying the TOE such that it can be distinguished from other productsor version from the same vendor and can be easily specified when being procured by an end user.Developer action elements:ALC_CMC.1.1DThe developer shall provide the TOE and a reference for the TOE.Content and presentation elements:ALC_CMC.1.1CThe TOE shall be labeled with its unique reference.Evaluator action elements:ALC_CMC.2.1EThe evaluator shall confirm that the information provided meets allrequirements for content and presentation of evidence.Assurance Activity:24

105 The evaluator shall check the ST to ensure that it contains an identifier (such as a product name/versionnumber) that specifically identifies the version that meets the requirements of the ST. Further, theevaluator shall check the AGD guidance and TOE samples received for testing to ensure that the versionnumber is consistent with that in the ST. If the vendor maintains a web site advertising the TOE, theevaluator shall examine the information on the web site to ensure that the information in the ST issufficient to distinguish the product.4.3.5.2 ALC_CMS.1 TOE CM coverage106 Given the scope of the TOE and its associated evaluation evidence requirements, this component’sassurance activities are covered by the assurance activities listed for ALC_CMC.1.Developer action elements:ALC_CMS.2.1DThe developer shall provide a configuration list for the TOE.Content and presentation elements:ALC_CMS.2.1CALC_CMS.2.2CThe configuration list shall include the following: the TOE itself; and theevaluation evidence required by the SARs.The configuration list shall uniquely identify the configuration items.Evaluator action elements:ALC_CMS.2.1EThe evaluator shall confirm that the information provided meets allrequirements for content and presentation of evidence.Assurance Activity:107 The “evaluation evidence required by the SARs” in this PP is limited to the information in the ST coupledwith the guidance provided to administrators and users under the AGD requirements. By ensuring thatthe TOE is specifically identified and that this identification is consistent in the ST and in the AGDguidance (as done in the assurance activity for ALC_CMC.1), the evaluator implicitly confirms theinformation required by this component.25

RATIONALE108 The rationale tracing the threats to the objectives and the objectives to the requirements is contained inthe prose in Sections 2.0 and 3.0. The only outstanding mappings are those for the Assumptions andOrganizational Security Policies; those are contained in Annex A below.ANNEX A: SUPPORTING TABLES109 In this Protection Profile, the focus in the initial sections of the document is to use a narrativepresentation in an attempt to increase the overall understandability of the threats to network devices,the methods used to mitigate those threats, and the extent of the mitigation achieved by compliantTOEs. This presentation style does not readily lend itself to a formalized evaluation activity, so thisAnnex contains the tabular artifacts that can be used for the evaluation activities associated with thisdocument.Assumptions110 The specific conditions listed in the following subsections are assumed to exist in the TOE’s OperationalEnvironment. These assumptions include both practical realities in the development of the TOE securityrequirements and the essential environmental conditions on the use of the TOE.111 ST authors should ensure that the assumptions still hold for their particular technology; the table shouldbe modified as appropriate.Assumption NameA.AUTHORIZED_USERA.AVAILABILITYA.OPER_ENVA.TRUSTED_ADMINTable 2: TOE AssumptionsAssumption NameThe cell phone user will follow all provided user guidance. Anauthorized user is not considered hostile or malicious.Network resources shall be available to allow VoIP clients to satisfymission requirements and to transmit information.The operational environment of the TOE appropriately addressesthose requirements, threats, and policies not applicable to the TOEitself, but that are necessary to support the correct operation of theTOE.TOE Administrators are trusted to follow and apply all administratorguidance in a trusted manner.ThreatsThe following threats should be integrated into the threats that are specific to the technology by the STauthors when including the requirements described in this document. Modifications, omissions, andadditions to the requirements may impact this list, so the ST author should modify or delete thesethreats as appropriate.ThreatT.UNAUTHORIZED_ACCESSTable 3: ThreatsDescription of ThreatA user may gain unauthorized access to the TOEdata and TOE executable code. A malicious user,26

T.UNAUTHORIZED_UPDATEprocess, or external IT entity may masquerade asan authorized entity in order to gain unauthorizedaccess to data or TOE resources. A malicious user,process, or external IT entity may misrepresentitself as the TOE to obtain identification andauthentication data.An update may be needed to a specific version ofthe TOE, but that specific version may not beknown to the Enterprise (that is performing in theupdate).Security Objectives for the TOETable 4: Security Objectives for the TOEObjectiveO.PROTECTED_COMMUNICATIONSO.TRUSTED_UPDATESObjective DescriptionThe TOE will provide protected communicationchannels with authorized IT entities (SIP Server andother VoIP applications).The TOE will provide the capability to report its currentversion.112 The following table contains objectives for the Operational Environment. As assumptions are added tothe PP, these objectives should be augmented to reflect such additions.Table 5: Security Objectives for the Operational EnvironmentObjectiveOE.AUTHORIZED_USEROE.AVAILABILITYOE.OPER_ENVOE.TRUSTED_ADMINOE.VERIFIABLE_UPDATESObjective DescriptionThe cell phone user of the TOE is non-hostile andfollows all user guidance.Network resources will be available to allow VoIPclients to satisfy mission requirements and totransmit informationThe operational environment will provide a SIPinfrastructure to establish a VoIP connection; a PKIto provide certificates; and an execution domain tosupport correct operation of the TOE.TOE Administrators are trusted to follow and applyall administrator guidance in a trusted manner.The Enterprise will provide the capability to updatethe TOE after that it has determine such an update isnecessary.27

ANNEX B: NIST SP 800-53/CNSS 1253 MAPPING113 Several of the NIST SP 800-53/CNSS 1253 controls are either fully or partially addressed by compliantTOEs. This section outlines the requirements that are addressed, and can be used by certificationpersonnel to determine what, if any, additional testing is required when the TOE is incorporated into itsoperational configuration.Application Note:114 In this version, only a simple mapping is provided. In future versions, additional narrative will be includedthat will provide further information for the certification team. This additional information will includedetails regarding the SFR to control mapping discussing what degree of compliance is provided by theTOE (e.g., fully satisfies the control, partially satisfies the control). In addition, a comprehensive review ofthe specified assurance activities, and those evaluation activities that occur as part of satisfying the SARswill be summarized to provide the certification team information regarding how compliance wasdetermined (e.g., document review, vendor assertion, degree of testing/verification). This informationwill indicate to the certification team what, if any, additional activities they need to perform todetermine the degree of compliance to specified controls.115 Since the ST will make choices as far as selections, and will be filling in assignments, a final story cannotnecessarily be made until the ST is complete and evaluated. Therefore, this information should beincluded in the ST in addition to the PP. Additionally, there may be some necessary interpretation(e.g.,“modification”) to the activities performed by the evaluator based on a specific implementation.The scheme could have the oversight personnel (e.g., Validators) fill in this type of information, or couldhave this done by the evaluator as part of the assurance activities. The verification activities are a criticalpiece of information that must be provided so the certification team can determine what, if anything,they need to do in addition to the work of the evaluation team.Identifier Name Applicable SFRsAC-4 Information Flow Enforcement FTP_ITC.1(*)SC-8Transmission IntegrityFCS_COP.1(2), FCS_COP.1(3), FCS_COP.1(4),FCS_TLS_EXT.1.1, FTP_ITC.1(*),FIA_SIPC_EXT.1, FMT_SRTP_EXT.1.1,FCS_DTLS_EXT.1SC-9Transmission ConfidentialityFCS_COP.1(1), FCS_SRTP_EXT.1,FIA_SIPC_EXT.1, FTP_ITC.1(*), FCS_TLS_EXT.1,FCS_DTLS_EXT.1SC-12Cryptographic Key Establishmentand ManagementFCS_TLS_EXT.1, FCS_CKM_EXT.4,FCS_RBG_EXT.1, FCS_DTLS_EXT.1SC-13 Use of Cryptography FCS_COP.1(*), FIA_X509_EXT.128

ANNEX C: ADDITIONAL REQUIREMENTS116 As indicated in the body of this PP, there are several methods by which conformant TOEs can performcertain security functions required to address the objectives. The requirements in the body of the PPindicate those functions that must be implemented by the TSF. There are other functions, however,that are allowed to be implemented by either the TSF or the Mobile OS, or to not be implemented at all.The following sections contain a list of those requirements; if these are implemented by the TSF, thenthe requirements will be moved by the ST author to the body of the ST.117 Note that minor adjustments to the narrative information in the beginning of the ST may be requireddepending on the selections performed.C.1.1 Datagram Transport Level Security118 SIP through TLS must be implemented by the TOE; however, it is also allowable for DTLS to beimplemented in addition to TLS. If DTLS is supported, the following requirement will be included by theST author.FCS_DTLS_EXT.1 Extended: Datagram Transport Level SecurityFCS_DTLS_EXT.1.1 The TSF shall implement the DTLS protocol in accordance with RFC 6347.FCS_DTLS_EXT.1.2 The TSF shall implement the requirements in FCS_TLS_EXT.1 for the DTLSimplementation, except where variations are allowed according to RFC 6347.Application Note:119 Differences between DTLS and TLS are outlined in RFC 6347; otherwise the protocols are the same. Inparticular, for the applicable security characteristics defined for the TOE, the two protocols do not differ.Therefore, all application notes and assurance activities that are listed for FCS_TLS_EXT.1 apply to theDTLS implementation.Assurance Activity:The evaluator shall perform the assurance activities listed for FCS_TLS_EXT.1 to verify this component.C.1.2 X.509120 The certificates used by the TSF are those for the distant end TLS connection and the user’s certificate(and assocaited private key). While it is acceptable for the TSF itself to store and protect thesecertificates, it is also allowable for the Mobile OS to provide these storage and protection functions. Ifthe TSF provides these functions, then the the following element shall be included in the body of the STin the FIA_X509_EXT.1 component.FIA_X509_EXT.1.Y The TSF shall store and protect certificate(s) from unauthorized deletion andmodification.29

TSS121 The evaluator shall ensure the TSS describes all certificate stores implemented that contain certificatesused to meet the requirements of this PP. This description shall contain information pertaining to howcertificates are loaded into storage, and how the storage is protected from unauthorized access.GuidanceThe evaluator shall examine the guidance documentation to ensure it describes how to configure eitherthe TOE or the environment to prevent unauthorized modification or deletion of the certificates.30

Annex D: Entropy Documentation and AssessmentThe documentation of the entropy source should be detailed enough that, after reading, theevaluator will thoroughly understand the entropy source and why it can be relied upon to provideentropy. This documentation should include multiple detailed sections: design description, entropyjustification, operating conditions, and health testing. This documentation is not required to bepart of the TSS.Design DescriptionDocumentation shall include the design of the entropy source as a whole, including the interactionof all entropy source components. It will describe the operation of the entropy source to includehow it works, how entropy is produced, and how unprocessed (raw) data can be obtained fromwithin the entropy source for testing purposes. The documentation should walk through theentropy source design indicating where the random comes from, where it is passed next, any postprocessingof the raw outputs (hash, XOR, etc.), if/where it is stored, and finally, how it is outputfrom the entropy source. Any conditions placed on the process (e.g., blocking) should also bedescribed in the entropy source design. Diagrams and examples are encouraged.This design must also include a description of the content of the security boundary of the entropysource and a description of how the security boundary ensures that an adversary outside theboundary cannot affect the entropy rate.Entropy JustificationThere should be a technical argument for where the unpredictability in the source comes from andwhy there is confidence in the entropy source exhibiting probabilistic behavior (an explanation ofthe probability distribution and justification for that distribution given the particular source is oneway to describe this). This argument will include a description of the expected entropy rate andexplain how you ensure that sufficient entropy is going into the TOE randomizer seeding process.This discussion will be part of a justification for why the entropy source can be relied upon toproduce bits with entropy.Operating ConditionsDocumentation will also include the range of operating conditions under which the entropy sourceis expected to generate random data. It will clearly describe the measures that have been taken inthe system design to ensure the entropy source continues to operate under those conditions.Similarly, documentation shall describe the conditions under which the entropy source is known tomalfunction or become inconsistent. Methods used to detect failure or degradation of the sourceshall be included.Health TestingMore specifically, all entropy source health tests and their rationale will be documented. This willinclude a description of the health tests, the rate and conditions under which each health test isperformed (e.g., at startup, continuously, or on-demand), the expected results for each health test,31

and rationale indicating why each test is believed to be appropriate for detecting one or morefailures in the entropy source.32