The TSF shall be able to generate audit data of the following auditable events:<h:br/> <h:ul> <h:li>Start-up and shutdown of the audit functions</h:li> <h:li>All auditable events for the [<h:i>not specified</h:i>] level of audit</h:li> [<h:li><h:i>All administrative actions</h:i></h:li> <h:li><h:i>Start-up and shutdown of the OS</h:i></h:li> <h:li><h:i>Insertion or removal of removable media</h:i></h:li> <h:li><h:i>Specifically defined auditable events in <xref g="t-audit-mandatory"/></h:i></h:li> <h:li><h:i>Auditable events as defined in the <xref to="tls"/>;</h:i></h:li> <h:li><h:i>Auditable events as defined in the <xref to="X509"/>;</h:i></h:li> <h:li><h:i><selectables linebreak="yes"> <selectable>Audit data reaching <assignable>integer value less than 100</assignable> percent of audit capacity</selectable> <selectable>Auditable events defined in <xref g="t-audit-objective"/> for Objective SFRs</selectable> <selectable>Auditable events defined in <xref g="t-audit-feat-based"/> for Implementation-Dependent SFRs</selectable> <selectable>Auditable events defined in <xref g="t-audit-sel-based"/> for Selection-Based SFRs</selectable> <selectable exclusive="yes">no additional auditable events</selectable> </selectables>]</h:i></h:li> </h:ul>

The TSF shall be able to generate audit data of the following auditable events:<h:br/> <h:ul> <h:li>Start-up and shutdown of the audit functions</h:li> <h:li>All auditable events for the [<h:i>not specified</h:i>] level of audit</h:li> [<h:li><h:i>All administrative actions</h:i></h:li> <h:li><h:i>Start-up and shutdown of the OS</h:i></h:li> <h:li><h:i>Insertion or removal of removable media</h:i></h:li> <h:li><h:i>Specifically defined auditable events in <xref g="t-audit-mandatory"/></h:i></h:li> <h:li><h:i>Auditable events as defined in the <xref to="tls"/>;</h:i></h:li> <h:li><h:i>Auditable events as defined in the <xref to="X509"/>;</h:i></h:li> <h:li><h:i><selectables linebreak="yes"> <selectable>Audit data reaching <assignable>integer value less than 100</assignable> percent of audit capacity</selectable> <selectable>Auditable events defined in <xref g="t-audit-objective"/> for Objective SFRs</selectable> <selectable>Auditable events defined in <xref g="t-audit-feat-based"/> for Implementation-Dependent SFRs</selectable> <selectable>Auditable events defined in <xref g="t-audit-sel-based"/> for Selection-Based SFRs</selectable> <selectable exclusive="yes">no additional auditable events</selectable> </selectables>]</h:i></h:li> </h:ul> Administrator actions are defined as functions labeled as mandatory for FMT_MOF_EXT.1.2 (i.e., ‘M-MM’ in ). If the TSF does not support removable media, number 4 is implicitly met. The TSF must generate audit data for all events contained in . For all other audit tables (i.e., tables for non-mandatory SFRs and references to functional packages), the ST author includes the audit events (if any) for the SFRs that are claimed in the ST. Application Note: FPT_TST_EXT.1 – Audit of self-tests is required only at initial start-up. Since the TOE "transitions to non-operational mode" upon failure of a self-test, per FPT_NOT_EXT.1, this is considered equivalent evidence to audit data for the failure of a self-test. FDP_DAR_EXT.1 - "None" must be selected, if the TOE utilizes whole volume encryption for protected data, since it is not feasible to audit when the encryption/decryption fails. If the TOE utilizes file-based encryption for protected data and audits when this encryption/decryption fails, then that auditable event should be selected. For FMT_SMF_EXT.1, it is acceptable for the initiation of the software update to be audited without indicating the outcome (success or failure) of the update.

The TSF shall record within the audit data at least the following information: <h:ul> <h:li>Date and time of the event</h:li> <h:li>Type of event</h:li> <h:li>Subject identity</h:li> <h:li>The outcome (success or failure) of the event</h:li> <refinement><h:li>Additional information in <xref g="t-audit-mandatory"/></h:li> <h:li>Additional information defined in the <xref to="tls"/>;</h:li> <h:li>Additional information defined in the <xref to="X509"/>;</h:li> <h:li> <selectables linebreak="yes"> <selectable>Additional information defined in <xref g="t-audit-objective"/> for Objective SFRs</selectable> <selectable>Additional information defined in <xref g="t-audit-feat-based"/> for Implementation-Dependent SFRs</selectable> <selectable>Additional information defined in <xref g="t-audit-sel-based"/> for Selection-Based SFRs</selectable> <selectable exclusive="yes">no additional information</selectable> </selectables></h:li></refinement> </h:ul> The subject identity is usually the process name/ID. The event type is often indicated by a severity level, for example, ‘info’, ‘warning’, or ‘error’. For each audit event selected from , , or in FAU_GEN.1.1, if additional information is required to be recorded within the audit data, it should be included in this selection. The evaluator shall check the TSS and ensure that it lists all of the auditable events and provides a format for audit data. Each audit data format type must be covered, along with a brief description of each field. The evaluator shall check to make sure that every audit event type mandated by the PP is described and that the description of the fields contains the information required in FAU_GEN.1.2. The evaluator shall also make a determination of the administrative actions that are relevant in the context of this PP including those listed in the Management section. The evaluator shall examine the administrative guide and make a determination of which administrative commands are related to the configuration (including enabling or disabling) of the mechanisms implemented in the TOE that are necessary to enforce the requirements defined in the PP. The evaluator shall document the methodology or approach taken while determining which actions in the administrative guide are security relevant with respect to this PP. The evaluator may perform this activity as part of the activities associated with ensuring the AGD_OPE guidance satisfies the requirements. The evaluator shall test the TOE’s ability to correctly generate audit data by having the TOE generate audit data for the events listed in the provided table and administrative actions. This should include all instances of an event. The evaluator shall test that audit data are generated for the establishment and termination of a channel for each of the cryptographic protocols contained in the ST. For administrative actions, the evaluator shall test that each action determined by the evaluator above to be security relevant in the context of this PP is auditable. When verifying the test results, the evaluator shall ensure the audit data generated during testing match the format defined in the administrative guide, and that the fields defined in FAU_GEN.1.2 are contained in the audit data. Note that the testing here can be accomplished in conjunction with the testing of the security mechanisms directly. For example, testing performed to ensure that the administrative guidance provided is correct verifies that AGD_OPE.1 is satisfied and should address the invocation of the administrative actions that are needed to verify the audit data are generated as expected.

The TSF shall provide [<h:i>the administrator</h:i>] with the capability to read [<h:i>all audited events and data contents</h:i>] from the audit data. The administrator must have access to read the audit data, perhaps through an API or via an MDM agent that transfers the local records stored on the TOE to the MDM server, where the enterprise administrator may then view them.

The TSF shall provide the audit data in a manner suitable for the user to interpret the information. There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. The evaluation activity for this requirement is performed in conjunction with test for function of FMT_SMF_EXT.1.

The TSF shall be able to select the set of events to be audited from the set of all auditable events based on the following attributes <h:ol type="a"> <h:li>[<h:i>event type</h:i>]</h:li> <h:li>[<h:i>success of auditable security events</h:i></h:li> <h:li><h:i>failure of auditable security events</h:i></h:li> <h:li><h:i><assignable>other attributes</assignable></h:i>]</h:li> </h:ol> The intent of this requirement is to identify all criteria that can be selected to trigger an audit event. This can be configured through an interface on the TSF for a user or administrator to invoke. For the ST author, the assignment is used to list any additional criteria or "none". There are no TSS evaluation activities for this component. The evaluator shall review the administrative guidance to ensure that the guidance itemizes all event types, as well as describes all attributes that are to be selectable in accordance with the requirement, to include those attributes listed in the assignment. The administrative guidance shall also contain instructions on how to set the pre-selection as well as explain the syntax (if present) for multi-value pre-selection. The administrative guidance shall also identify those audit data that are always recorded, regardless of the selection criteria currently being enforced. The evaluator shall also perform the following tests: For each attribute listed in the requirement, the evaluator shall devise a test to show that selecting the attribute causes only audit events with that attribute (or those that are always recorded, as identified in the administrative guidance) to be recorded. [conditional] If the TSF supports specification of more complex audit pre-selection criteria (e.g., multiple attributes, logical expressions using attributes) then the evaluator shall devise tests showing that this capability is correctly implemented. The evaluator shall also, in the test plan, provide a short narrative justifying the set of tests as representative and sufficient to exercise the capability.

All modifications to the audit configuration that occur while the audit collection functions are operating

The TSF shall protect the stored audit data in the audit trail from unauthorized deletion.

The TSF shall be able to [<h:i>prevent</h:i>] unauthorized modifications to the stored audit data in the audit trail. The evaluator shall ensure that the TSS lists the location of all logs and the access controls of those files such that unauthorized modification and deletion are prevented. There are no guidance evaluation activities for this component. The evaluator shall attempt to delete the audit trail in a manner that the access controls should prevent (as an unauthorized user) and shall verify that the attempt fails. The evaluator shall attempt to modify the audit trail in a manner that the access controls should prevent (as an unauthorized application) and shall verify that the attempt fails.

The TSF shall [<h:i>overwrite the oldest stored audit records</h:i>] <h:s>[assignment: other actions to be taken in case of audit storage failure and conditions for the actions]</h:s> if the audit data storage is full. The evaluator shall examine the TSS to ensure that it describes the size limits on the audit records, the detection of a full audit trail, and the actions taken by the TSF when the audit trail is full. The evaluator shall ensure that the actions results in the deletion or overwrite of the oldest stored record. There are no guidance evaluation activities for this component. There are no test evaluation activities for this component.

This section describes how keys are generated, derived, combined, released and destroyed. There are two major types of keys: DEKs and KEKs. (A REK is considered a KEK.) DEKs are used to protect data (as in the DAR protection described in FDP_DAR_EXT.1 and FDP_DAR_EXT.2). KEKs are used to protect other keys – DEKs, other KEKs, and other types of keys stored by the user or applications. The following diagram shows an example key hierarchy to illustrate the concepts of this profile. This example is not meant as an approved design, but ST authors will be expected to provide a diagram illustrating their key hierarchy in order to demonstrate that they meet the requirements of this profile. Please note if is selected in FIA_UAU.5.1, each BAF claimed in FIA_MBV_EXT.1.1 in the shall be illustrated in the key hierarchy diagram, to include a description of when and how the BAF is used to release keys. If is selected in FIA_UAU.5.1, meaning that a PIN or password must be used in conjunction with the BAF, this interaction shall be included.

The TSF shall generate <h:b>asymmetric</h:b> cryptographic keys in accordance with a specified cryptographic key generation algorithm<selectables> <tabularize id="fcs-ckm-1-ak-sels" title="Allowable Choices for FCS_CKM.1/AKG"> <textcol>Identifier</textcol> <selectcol>Cryptographic Key Generation Algorithm</selectcol> <reqtext>and specified cryptographic <h:b>algorithm parameters</h:b> <h:s>key sizes</h:s></reqtext> <selectcol>Cryptographic Algorithm Parameters</selectcol> <reqtext>that meet the following: </reqtext> <selectcol>List of Standards</selectcol> <reqtext>.<h:p/><h:p/><xref to="fcs-ckm-1-ak-sels"/> provides the allowable choices for completion of the selection operations of FCS_CKM.1/AKG.</reqtext> </tabularize>  <selectable id="sel-fcs-ckm-ak-rsa"> <col>RSA</col> <col>RSA</col> <col>Modulus of size <selectables> <selectable id="sel-exp-ak-rsa-3072">3072</selectable> <selectable id="sel-exp-ak-rsa-4096">4096</selectable> <selectable id="sel-exp-ak-rsa-6144">6144</selectable> <selectable id="sel-exp-ak-rsa-8192">8192</selectable> </selectables> bits </col> <col>NIST FIPS PUB 186-5 (Section A.1.1)</col> </selectable>  <selectable id="sel-fcs-ckm-ak-ecdsa-erb"> <col>ECC-ERB</col> <col>ECC-ERB - Extra Random Bits</col> <col>Elliptic Curve <selectables> <selectable id="sel-exp-ak-edcsa-erb-P256">P-256</selectable> <selectable id="sel-exp-ak-edcsa-erb-P384">P-384</selectable> <selectable id="sel-exp-ak-edcsa-erb-P521">P-521</selectable></selectables> </col> <col> FIPS PUB 186-5 (Section A.2.1)<h:p/> NIST SP 800-186 (Section 3) [NIST Curves] </col> </selectable>  <selectable id="sel-fcs-ckm-ak-ecdsa-rs"> <col>ECC-RS</col> <col>ECC-RS - Rejection Sampling</col> <col>Elliptic Curve <selectables> <selectable id="sel-exp-ak-edcsa-rs-P256">P-256</selectable> <selectable id="sel-exp-ak-edcsa-rs-P384">P-384</selectable> <selectable id="sel-exp-ak-edcsa-rs-P521">P-521</selectable></selectables> </col> <col> FIPS PUB 186-5 (Section A.2.2)<h:p/> NIST SP 800-186 (Section 3) [NIST Curves] </col> </selectable>  <selectable id="sel-fcs-ckm-ak-ffc-erb"> <col>FFC-ERB</col> <col>FFC-ERB - Extra Random Bits</col> <col>Static domain parameters approved for <selectables> <selectable>IKE Groups <selectables> <selectable id="sel-dp-ak-ffc-erb-modp3072">MODP-3072</selectable> <selectable id="sel-dp-ak-ffc-erb-modp4096">MODP-4096</selectable> <selectable id="sel-dp-ak-ffc-erb-modp6144">MODP-6144</selectable> <selectable id="sel-dp-ak-ffc-erb-modp8192">MODP-8192</selectable> </selectables></selectable> <selectable>TLS Groups <selectables> <selectable id="sel-dp-ak-ffc-erb-ffdhe3072">ffdhe3072</selectable> <selectable id="sel-dp-ak-ffc-erb-ffdhe4096">ffdhe4096</selectable> <selectable id="sel-dp-ak-ffc-erb-ffdhe6144">ffdhe6144</selectable> <selectable id="sel-dp-ak-ffc-erb-ffdhe8192">ffdhe8192</selectable> </selectables></selectable></selectables> </col> <col> NIST SP 800-56A Revision 3 (Section 5.6.1.1.3) [key pair generation]<h:p/> <selectables> <selectable>RFC 3526 [IKE groups]</selectable> <selectable>RFC 7919 [TLS groups]</selectable></selectables> </col> </selectable>  <selectable id="sel-fcs-ckm-ak-ffc-rs"> <col>FFC-RS</col> <col>FFC-RS - Rejection Sampling</col> <col>Static domain parameters approved for <selectables> <selectable>IKE Groups <selectables> <selectable id="sel-dp-ak-ffc-rs-modp3072">MODP-3072</selectable> <selectable id="sel-dp-ak-ffc-rs-modp4096">MODP-4096</selectable> <selectable id="sel-dp-ak-ffc-rs-modp6144">MODP-6144</selectable> <selectable id="sel-dp-ak-ffc-rs-modp8192">MODP-8192</selectable> </selectables></selectable> <selectable>TLS Groups <selectables> <selectable id="sel-dp-ak-ffc-rs-ffdhe3072">ffdhe3072</selectable> <selectable id="sel-dp-ak-ffc-rs-ffdhe4096">ffdhe4096</selectable> <selectable id="sel-dp-ak-ffc-rs-ffdhe6144">ffdhe6144</selectable> <selectable id="sel-dp-ak-ffc-rs-ffdhe8192">ffdhe8192</selectable> </selectables></selectable></selectables> </col> <col> NIST SP 800-56A Revision 3 (Section 5.6.1.1.3) [key pair generation]<h:p/> <selectables> <selectable>RFC 3526 [IKE groups]</selectable> <selectable>RFC 7919 [TLS groups]</selectable></selectables> </col> </selectable>  <selectable id="sel-fcs-ckm-ak-lms"> <col>EdDSA</col> <col>EdDSA</col> <col>Domain parameters approved for elliptic curves [<h:i>Edwards25519</h:i>] </col> <col>NIST FIPS PUB 186-5 (section 6.2.1)[key-pair generation]<h:p/> NIST SP 800-186 (Section 3.2.3)[Edwards Curves] </col> </selectable>  <selectable id="sel-fcs-ckm-ak-lms"> <col>LMS</col> <col>LMS</col> <col>Private key size = <selectables> <selectable><h:i>192 bits with</h:i> <selectables> <selectable>SHA-256/192</selectable> <selectable>SHAKE256/192</selectable> </selectables></selectable> <selectable>256 bits with <selectables> <selectable>SHA-256</selectable> <selectable>SHAKE256</selectable> </selectables></selectable> </selectables><h:p/> Winternitz parameter = <selectables> <selectable>1</selectable> <selectable>2</selectable> <selectable>4</selectable> <selectable>8</selectable></selectables><h:p/> Tree height = <selectables> <selectable>5</selectable> <selectable>10</selectable> <selectable>15</selectable> <selectable>20</selectable> <selectable>25</selectable></selectables> </col> <col>RFC 8554 [LMS]<h:p/> NIST SP 800-208 [parameters] </col> </selectable>  <selectable id="sel-fcs-ckm-ak-mlkem"> <col>ML-KEM</col> <col>ML-KEM KeyGen</col> <col>Parameter set = ML-KEM-1024</col> <col>NIST FIPS 203 (Section 7.1)</col> </selectable>  <selectable id="sel-fcs-ckm-ak-mldsa"> <col>ML-DSA</col> <col>ML-DSA KeyGen</col> <col>Parameter set = ML-DSA-87</col> <col>NIST FIPS 204 (Section 5.1)</col> </selectable>  <selectable id="sel-fcs-ckm-ak-xmss"> <col>XMSS</col> <col>XMSS</col> <col>Private key size = <selectables> <selectable>192 bits with <selectables> <selectable>SHA-256/192</selectable> <selectable>SHAKE256/192</selectable> </selectables></selectable> <selectable>256 bits with <selectables> <selectable>SHA-256</selectable> <selectable>SHAKE256</selectable> </selectables></selectable> </selectables><h:p/> Tree height = <selectables> <selectable>10</selectable> <selectable>16</selectable> <selectable>20</selectable> </selectables> </col> <col>RFC 8391 [XMSS]<h:p/> NIST SP 800-208 [parameters] </col> </selectable> </selectables> For RSA the choice of the modulus implies the resulting key sizes of the public and private keys generated using the specified standard methods. RSA key generation with modulus size 2048 bits is no longer permitted by CNSA. For Finite Field Cryptography (FFC) DSA, ST authors should consult schemes for guidelines on use. FIPS PUB 186-5 does not approve DSA for digital signature generation but allows DSA for digital signature verification for legacy purposes. “FFC-ERB” or “FFC–RS” may be claimed only for generating private and public keys when “DH” is claimed in FCS_CKM_EXT.7/LOCKED or FCS_CKM_EXT.7/UNLOCKED. For ECC selections, “P-256” may only be selected if the is included in the ST and P-256 may only be used specifically for Bluetooth functions. When generating ECC keys pairs for key agreement and if “ECDH” is claimed in FCS_CKM_EXT.7/LOCKED or FCS_CKM_EXT.7/UNLOCKED, then “ECC–ERB” or “ECC–RS” must be claimed. The sizes of the private key, which is a scalar, and the public key, which is a point on the elliptic curve, are determined by the choice of the curve. When generating ECC key pairs for digital signature generation and if “ECDSA” is claimed in FCS_COP.1/SigGen, then “ECC–ERB” or “ECC–RS” must be claimed. The sizes of the private key, which is a scalar, and the public key, which is a point on the elliptic curve, are determined by the choice of the curve. The evaluator shall examine the TSS to verify that it describes how the TOE generates a key based on output from a random bit generator as defined in FCS_RBG.1. The evaluator shall review the TSS to verify that it describes how the functionality described by FCS_RBG.1 is invoked. If support for P-256 is claimed, the evaluator shall examine the TSS to verify that it is only used for Bluetooth functions. The evaluator shall examine the TSS to verify that it identifies the usage and key lifecycle for keys generated using each selected algorithm. The evaluator shall examine the TSS to verify that any one-time values such as nonces or masks are constructed in accordance with the relevant standards. If the TOE uses the generated key in a key chain or hierarchy then the evaluator shall verify that the TSS describes how the key is used as part of the key chain or hierarchy. The evaluator shall verify that the guidance instructs the administrator how to configure the TOE to generate keys for the selected key generation algorithms for all key types and uses identified in the TSS. The following tests are conditional based on the selections made in the SFR. The evaluator shall perform the following tests or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described. RSA Key Generation RSA RSA Modulus of size [selection: 3072, 4096, 6144, 8192] bits NIST FIPS PUB 186-5 (Section A.1.1) FIPS PUB 186-5 Key Pair generation specifies five methods for generating the primes p and q. These are: Random provable primes Random probable primes Provable primes with conditions based on auxiliary provable primes Probable primes with conditions based on auxiliary provable primes Probable primes with conditions based on auxiliary probable primes In addition to the key generation method, the input parameters are: Modulus [3072, 4096, 6144, 8192] Hash algorithm [SHA-384, SHA-512] (methods 1, 3, 4 only) Rabin-Miller prime test [2100, 2Security String] (methods 2, 4, 5 only) p mod 8 value [0,1,3,5,7] q mod 8 value [0,1,3,5,7] Private key format [standard, Chinese Remainder Theorem] Public exponent [fixed value, random] The evaluator shall verify the ability of the TSF to correctly produce values for the RSA key components, including the public verification exponent e, the private prime factors p and q, the public modulus n, and the calculation of the private signature exponent d. Testing for Random Provable Primes and Conditional Methods To test the key generation method for the random provable primes method and for all the primes with conditions methods (methods 1, 3-5), the evaluator shall seed the TSF key generation routine with sufficient data to deterministically generate the RSA key pair. For each supported combination of the above input parameters, the evaluator shall have the TSF generate 25 key pairs. The evaluator shall verify the correctness of the TSF’s implementation by comparing values generated by the TSF with those generated by a known good implementation using the same input parameters. Testing for Random Probable Primes Method If the TOE generates random probable primes (method 2) then, if possible, the random probable primes method should also be verified against a known good implementation as described above. If verification against a known good implementation is not possible, the evaluator shall have the TSF generate 25 key pairs for each supported key length nlen and verify that all of the following are true. n = p*q p and q are probably prime according to Miller-Rabin tests with error probability <2(-125) 216 < e < 2256 and e is an odd integer GCD(p-1,e) = 1 GCD(q-1,e) = 1 |p-q| > 2(nlen/2 – 100) p ≥ squareroot(2)*( 2(nlen/2 -1) ) q ≥ squareroot(2)*( 2(nlen/2 -1) ) 2(nlen/2) < d < LCM(p-1,q-1) e*d = 1 mod LCM(p-1,q-1) Elliptic Curve Key Generation ECC-ERB ECC – Extra Random Bits Elliptic Curve [selection: P-256, P-384, P-521] NIST FIPS PUB 186-5 (Section A.2.1) NIST SP 800-186 (Section 3) [NIST Curves] ECC-RS ECC – Rejection Sampling Elliptic Curve [selection: P-256, P-384, P-521] NIST FIPS PUB 186-5 (Section A.2.2) NIST SP 800-186 (Section 3) [NIST Curves] To test the TOE’s ability to generate asymmetric cryptographic keys using elliptic curves, the evaluator shall perform the ECC Key Generation Test and the ECC Key Validation Test using the following input parameters. Elliptic curve [P-256, P-384, P-521] Key pair generation method [extra random bits, rejection sampling] ECC Key Generation Test For each supported combination of the above input parameters the evaluator shall require the implementation under test to generate 10 private and public key pairs (d, Q). The private key, d, shall be generated using a random bit generator as defined in FCS_RBG.1. The private key, d, is used to compute the public key, Q'. The evaluator shall confirm that 0<d<n (where n is the order of the group), and the computed value Q' is then compared to the generated public and private key pairs’ public key, Q, to confirm that Q is equal to Q'. ECC Key Validation Test For each supported combination of the above parameters the evaluator shall generate 12 private and public key pairs using the key generation function of a known good implementation. For each set of 12 public keys, the evaluator shall modify four public key values by shifting x or y out of range by adding the order of the field and modify four other public key values by shifting x or y so that they are still in bounds, but not on the curve. The remaining public key values are left unchanged (i.e., correct). To determine correctness, the evaluator shall submit the public keys to the public key validation (PKV) function of the TOE and confirm that the results correspond as expected for the modified and unmodified values. Finite Field Cryptography Key Generation FFC-ERB FFC – Extra Random Bits Static domain parameters approved for [selection: IKE groups [selection: MODP-3072, MODP-4096, MODP-6144, MODP-8192], TLS groups [selection: ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192]]] NIST SP 800-56A Revision 3 (Section 5.6.1.1.3) [key pair generation] [selection: RFC 3526 [IKE groups], RFC 7919 [TLS groups]] FFC-RS FFC – Rejection Sampling Static domain parameters approved for [selection: IKE groups [selection: MODP-3072, MODP-4096, MODP-6144, MODP-8192], TLS groups [selection: ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192]]] NIST SP 800-56A Revision 3 (Section 5.6.1.1.4) [key pair generation] [selection: RFC 3526 [IKE groups], RFC 7919 [TLS groups]] To test the TOE’s ability to generate asymmetric cryptographic keys using finite fields, the evaluator shall perform the Safe Primes Generation Test and the Safe Primes Validation Test using the following input parameter: Fields/Groups [MODP-3072, MODP-4096, MODP-6144, MODP-8192, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192] Safe Primes Generation Test For each supported safe primes group, generate 10 key pairs. The evaluator shall verify the correctness of the TSF’s implementation by comparing values generated by the TSF with those generated by a known good implementation using the same input parameters. Safe Primes Verification Test For each supported safe primes group, use a known good implementation to generate 10 key pairs. For each set of 10, the evaluator shall modify three so they are incorrect. The remaining values are left unmodified (i.e., correct). To determine correctness, the evaluator shall submit the key pairs to the public key validation (PKV) function of the TOE and shall confirm that the results correspond as expected for the modified and unmodified values. EdDSA Key Generation EdDSA EdDSA Edwards25519 NIST FIPS PUB 186-5 [EdDSA]NISTP 800-186 [parameters] The evaluator shall require the implementation under test (IUT) to generate 10 private/public key pairs. The private key shall be generated as defined in RFC 7748 using an approved random bit generator (RBG) and shall be written in little-endian order (least significant byte first). To determine correctness, the evaluator shall submit the generated key pairs to the public key verification (PKV) function of a known good implementation. Note: Assuming the PKV function of the good implementation will (using little-endian order): Confirm the private and public keys are 32-byte values Confirm the three least significant bits of the first byte of the private key are zero Confirm the most significant bit of the last byte is zero Confirm the second most significant bit of the last byte is one Calculate the expected public key from the private key and confirm it matches the supplied public key The evaluator shall generate 10 private/public key pairs using the key generation function of a known good implementation and modify 5 of the public key values so that they are incorrect, leaving five values unchanged (i.e. correct). The evaluator shall obtain in response a set of 10 PASS/FAIL values. LMS Key Generation LMS LMS Key Generation Private key size = [selection: 192 bits with [selection: SHA-256/192, SHAKE256/192], 256 bits with [selection: SHA-256, SHAKE256]]; Winternitz parameter = [selection: 1, 2, 4, 8]; Tree height = [selection: 5, 10, 15, 20, 25] RFC 8554 [LMS]NIST SP 800-208 [parameters] To test the TOE’s ability to generate asymmetric cryptographic keys using LMS, the evaluator shall perform the LMS Key Generation Test using the following input parameters: Hash algorithm [SHA-256/192, SHAKE256/192, SHA-256, SHAKE256] Winternitz [1, 2, 4, 8] Tree height [5, 10, 15, 20, 25] LMS Key Generation Test For each supported combination of the hash algorithm, Winternitz parameter, and tree height, the evaluator shall generate one public key for each of the test cases. The number of test cases depends on the tree height: : Number of LMS Test Cases 5 5 10 4 15 3 20 2 25 1 The evaluator shall verify the correctness of the TSF’s implementation by comparing the public key generated by the TSF with that generated by a known good implementation using the same input parameters. ML-KEM Key Generation ML-KEM ML-KEM Key Generation Parameter set = [ML-KEM-1024] NIST FIPS PUB 203 (Section 7.1) To test the TOE’s ability to generate asymmetric cryptographic keys using ML-KEM, the evaluator shall perform the Algorithm Functional Test using the following input parameters: Parameter set [ML-KEM-1024] Random seed d [32 bytes] Random seed z [32 bytes] Algorithm Functional Test For each supported parameter set the evaluator shall require the implementation under test to generate 25 key pairs using 25 different randomly generated pairs of 32-byte seed values (d, z). To determine correctness, the evaluator shall compare the resulting key pairs (ek, dk) with those generated using a known good implementation using the same inputs. ML-DSA Key Generation ML-DSA ML-DSA Key Generation Parameter set = ML-DSA-87 NIST FIPS PUB 204 (Section 5.1) To test the TOE’s ability to generate asymmetric cryptographic keys using ML-DSA, the evaluator shall perform the Algorithm Functional Test using the following input parameters: Parameter set [ML-DSA-87] Random seed [32 bytes] Algorithm Functional Test For each supported parameter set the evaluator shall require the implementation under test to generate 25 key pairs using 25 different randomly generated 32-byte seed values. To determine correctness, the evaluator shall compare the resulting key pairs with those generated using a known good implementation using the same inputs. XMSS Key Generation XMSS XMSS Private key size = [selection: 192 bits with [selection: SHA-256/192, SHAKE256/192], 256 bits with [selection: SHA-256, SHAKE256]], tree height = [selection: 10, 16, 20] RFC 8391 [XMSS] NIST SP 800-208 [parameters] To test the TOE’s ability to generate asymmetric cryptographic keys using XMSS, the evaluator shall perform the XMSS Key Generation Test using the following input parameters: Hash algorithm [SHA-256/192, SHAKE256/192, SHA-256, SHAKE256] Tree height [10, 16, 20] (XMSS only) : Number of Test Cases for XMSSMT 10 5 16 4 20 3 40 2 60 1 XMSS Key Generation Test For each supported combination of hash algorithm and tree height, the evaluator shall generate one public key for each test case. The number of test cases depends on the tree height as defined in . The evaluator shall verify the correctness of the TSF’s implementation by comparing values generated by the TSF with those generated by a known good implementation using the same input parameters. Note: The number of test cases is limited due to the extreme amount of time it can take to generate XMSS trees.

The TSF shall generate <h:b>symmetric</h:b> cryptographic keys in accordance with a specified cryptographic key generation algorithm<selectables> <tabularize id="fcs-ckm-1-skg-sels" title="Allowable Choices for FCS_CKM.1/SKG"> <textcol>Identifier</textcol> <selectcol>Cryptographic Key Generation Algorithm</selectcol> <reqtext>and specified cryptographic key sizes</reqtext> <selectcol>Cryptographic Key Sizes</selectcol> <reqtext>that meet the following: </reqtext> <selectcol>List of standards</selectcol> <reqtext>.<h:p/><h:p/><xref to="fcs-ckm-1-skg-sels"/> provides the allowable choices for completion of the selection operations of FCS_CKM.1/SKG.</reqtext> </tabularize>  <selectable id="sel-fcs-ckm-sk-rsk"> <col>RSK</col> <col>Direct Generation from a Random Bit Generator as defined in FCS_RBG.1</col> <col><selectables> <selectable id="sel-exp-skg-256">256</selectable> <selectable id="sel-exp-skg-256">384</selectable> <selectable id="sel-exp-skg-512">512</selectable></selectables> bits </col> <col>NIST SP 800-133 Revision 2 (Section 6.1)[Direct generation of symmetric keys]</col> </selectable> </selectables> The evaluator shall examine the TSS to verify that it describes how the TOE obtains a symmetric cryptographic key through direct generation from a random bit generator as defined in FCS_RBG.1. The evaluator shall review the TSS to verify that it describes how the functionality described by FCS_RBG.1 is invoked. The evaluator shall examine the TSS to verify that it identifies the usage, and key lifecycle for keys generated using each selected algorithm. If the TOE uses the generated key in a key chain/hierarchy then the evaluator shall verify that the TSS describes how the key is used as part of the key chain/hierarchy. The evaluator shall verify that the AGD instructs the administrator how to configure the TOE to use the DRBG to generate symmetric keys for all uses identified in the ST. The following tests are conditional based upon the selections made in the SFR. The evaluator shall perform the following test or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described. To test the TOE’s ability to generate symmetric cryptographic keys using a random bit generator, the evaluator shall configure the symmetric cryptographic key generation capability for each claimed key size. The evaluator shall use the description of the DRBG interface to verify that the TOE requests and receives an amount of DRBG output greater than or equal to the requested key size.

The TSF shall distribute cryptographic keys in accordance with the specified cryptographic key distribution method <h:b>key wrapping as defined in FCS_COP.1/KeyWrap</h:b> and <selectables> <selectable id="sel-ckm-2-encap">key encapsulation as defined in FCS_COP.1/KeyEncap</selectable> <selectable id="sel-ckm-2-no-other"><h:b>no other methods</h:b></selectable> </selectables> that meets the following: [<h:i>none</h:i>]. Key encapsulation is used in support of TLS when ML-KEM is used as the method of key establishment. Key wrapping is used in support of wireless LAN communications so it is always required. If "key encapsulation..." is selected, FCS_COP.1/KeyEncap is claimed. The evaluator shall ensure that the TSS documents that the security strength supported by the selected key distribution methods is sufficient for the security strength of the keys distributed through those methods. It is not necessary to identify the services that use each key distribution method here. That information should be documented in the requirements for the individual services and protocols that invoke key distribution. The evaluator shall verify that the AGD guidance instructs the administrator how to configure the TOE to use the selected key distribution methods. Specific testing for this component is covered by testing for the claimed components in FCS_COP.1/KeyEncap or FCS_COP.1/KeyWrap, depending on selections made.

The TSF shall destroy [<h:i>all plaintext keys and keying material</h:i>] when <selectables> <selectable>no longer needed</selectable> <selectable><assignable>other circumstances for destruction</assignable></selectable> </selectables>.

The TSF shall destroy <h:b>plaintext</h:b> cryptographic keys and keying material specified by FCS_CKM.6.1 in accordance with a specified cryptographic key destruction method [<h:i>in accordance with the following rules: <h:ul> <h:li>For volatile memory, the destruction shall be executed by a single direct overwrite consisting of <selectables> <selectable>a pseudo-random pattern using the TSF or platform DRBG (as defined in FCS_RBG.1)</selectable> <selectable>zeroes</selectable> </selectables></h:li> <h:li>For non-volatile EEPROM, the destruction shall be executed by a single direct overwrite consisting of a pseudo-random pattern using the TSF or platform DRBG (as defined in FCS_RBG.1), followed by a read-verify.</h:li> <h:li>For non-volatile flash memory, that is not wear-leveled, the destruction shall be executed by a <selectables> <selectable>single direct overwrite consisting of zeroes followed by a read-verify</selectable> <selectable>block erase that erases the reference to memory that stores data as well as the data itself</selectable> </selectables> </h:li> <h:li>For non-volatile flash memory that is wear-leveled, the destruction shall be executed by a <selectables> <selectable>single direct overwrite consisting of zeroes</selectable> <selectable>block erase</selectable> </selectables></h:li> <h:li>For non-volatile memory other than EEPROM and flash, the destruction shall be executed by a single direct overwrite with a random pattern that is changed before each write</h:li></h:ul></h:i>] that meets the following: [<h:i>no standard</h:i>]. For the purposes of this requirement, keying material refers to authentication data, passwords, secret/private symmetric keys, private asymmetric keys, data used to derive keys, values derived from passwords, etc. “Plaintext keying material” may refer to a KEK that is used to encrypt other keying material. Destruction of encrypted keying material may be accomplished by destroying the KEK used to encrypt it. If different mechanisms are used for destroying different keying material, all relevant claims should be selected and the TSS should identify which keying material is destroyed by which mechanism. There are multiple situations in which plaintext keying material is no longer needed, including when the TOE is powered off, when the wipe when trusted channels are disconnected, when keying material is no longer needed by the trusted channel per the protocol, and when transitioning to the locked state (for those values derived from the Password Authentication Factor or that key material which is protected by the password-derived or biometric-unlocked KEK as defined in FCS_STG_EXT.2 – see Figure 3). For keys (or key material used to derive those keys) protecting sensitive data received in the locked state, "no longer needed" includes "while in the locked state." The assignment for "other circumstances for destruction" is completed for any user or Administrator directed key destruction such as initiating the wipe function or other manual destruction. Key storage areas in non-volatile storage can be overwritten with any value that renders the keys unrecoverable. The value used can be all zeroes, all ones, or any other pattern or combination of values significantly different than the value of the key itself. When ‘a value that does not contain any keying material’ is chosen, it means that the TOE uses some other specified data not drawn from a source that may contain keying material or reveal information about it or any other TSF-protected data. In other words, the data used for overwriting is carefully selected and not taken from a general ‘pool’ that might contain current or residual data that itself requires confidentiality protection. If multiple copies exist, all copies must be destroyed. The evaluator shall verify that the TSS identifies all plaintext keys and keying material stored by the TOE, the type of memory in which it is stored, and when and how the keying material is erased. If the TOE uses one or more KEKs to protect stored keying material, the evaluator shall verify that the TSS describes the destruction of that keying material, either directly or by destruction of the KEK used to encrypt it. If different types of memory are used to store the materials to be protected, the evaluator shall check to ensure that the TSS describes the clearing procedure in terms of the memory in which the data are stored (for example, "secret keys stored on flash are cleared by overwriting once with zeros, while secret keys stored on the internal persistent storage device are cleared by overwriting one time with a random pattern that is changed before each write"). For block erases, the evaluator shall also ensure that the TSS identifies the block erase command that is used and shall verify that the command used also addresses any copies of the plaintext key material that may be created, e.g. in order to optimize the use of Flash memory. Evaluation Activity Note: The following tests likely require the TOE developer to provide access to a test platform that provides the evaluator with tools that are typically not found on the end consumer version of the TOE. The evaluator shall perform the following tests for all keys and key material subject to destruction by the TOE. For these tests, the evaluator shall utilize an appropriate development environment (e.g., a virtual machine) and development tools (debuggers, simulators, etc.) to test that keys are cleared, including all copies of the key that may have been created internally by the TOE during normal cryptographic processing with that key. Applied to each key held as plaintext in volatile memory and subject to destruction by overwrite by the TOE (whether or not the plaintext value is subsequently encrypted for storage in volatile or non-volatile memory). In the case where the only selection made for the destruction method key was removal of power, then this test is unnecessary. The evaluator shall: Record the value of the key in the TOE subject to clearing. Cause the TOE to perform a normal cryptographic processing with the key from Step #1. Cause the TOE to clear the key. Cause the TOE to stop the execution but not exit. Cause the TOE to dump the entire memory of the TOE into a binary file. Search the content of the binary file created in Step #5 for instances of the known key value from Step #1. Break the key value from Step #1 into 3 similar sized pieces and perform a search using each piece. Steps 1-6 ensure that the complete key does not exist anywhere in volatile memory. If a copy is found, then the test fails. Step 7 ensures that partial key fragments do not remain in memory. If a fragment is found, there is a minuscule chance that it is not within the context of a key (e.g., some random bits that happen to match). If this is the case the test should be repeated with a different key in Step #1. If a fragment is found the test fails. Applied to each key held in non-volatile memory and subject to destruction by overwrite by the TOE. The evaluator shall use special tools (as needed), provided by the TOE developer if necessary, to view the key storage location: Record the value of the key in the TOE subject to clearing. Cause the TOE to perform a normal cryptographic processing with the key from Step #1. Cause the TOE to clear the key. Search the non-volatile memory the key was stored in for instances of the known key value from Step #1. If a copy is found, then the test fails. Break the key value from Step #1 into 3 similar sized pieces and perform a search using each piece. If a fragment is found then the test is repeated (as described for test 1 above), and if a fragment is found in the repeated test then the test fails. Applied to each key held as non-volatile memory and subject to destruction by overwrite by the TOE. The evaluator shall use special tools (as needed), provided by the TOE developer if necessary, to view the key storage location: Record the storage location of the key in the TOE subject to clearing. Cause the TOE to perform a normal cryptographic processing with the key from Step #1. Cause the TOE to clear the key. Read the storage location in Step #1 of non-volatile memory to ensure the appropriate pattern is utilized. The test succeeds if correct pattern is used to overwrite the key in the memory location. If the pattern is not found the test fails.

This family defines requirements for management of cryptographic keys that are not addressed by FCS_CKM in CC Part 2.

requires the TSF to implement a Root Encryption Key (REK).

There are no management activities foreseen. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP, PP-Module, functional package or ST: Generation of a REK. FCS_RBG.1 Random Bit Generation

The TSF shall support <selectables> <selectable id="s-immutable-hardware">immutable hardware</selectable> <selectable id="s-mutable-hardware">mutable hardware</selectable></selectables> REKs with a <selectables> <selectable id="s-rek-sym">symmetric</selectable> <selectable id="s-rek-asym">asymmetric</selectable></selectables> key of strength <selectables> <selectable id="s-rek-192">192 bits</selectable> <selectable id="s-rek-256">256 bits</selectable></selectables>.

The TSF shall support <assignable>description of REKs</assignable>

Each REK shall be hardware-isolated from the OS on the TSF in runtime.

Each REK shall be generated by a DRBG in accordance with FCS_RBG.1. Either asymmetric or symmetric keys are allowed; the ST author makes the selection appropriate for the device. Symmetric keys must be of size 256 bits in order to correspond with FCS_COP.1/SKC. Asymmetric keys may be of any strength corresponding to FCS_CKM.1/AKG. The raw key material of "immutable hardware" REKs is computationally processed by hardware and software cannot access the raw key material. If is selected in FCS_CKM_EXT.1.1, FCS_CKM_EXT.9 must be included in the ST. The lack of a public/documented API for importing or exporting the REK, when a private/undocumented API exists, is not sufficient to meet this requirement. The DRBG used to generate a REK may be a DRBG native to the hardware key container or may be an off-device DRBG. If performed by an off-device DRBG, the device manufacturer must not be able to access a REK after the manufacturing process has been completed. The Evaluation Activities for these two cases differ. The evaluator shall review the TSS to determine that a REK is supported by the TOE, that the TSS includes a description of the protection provided by the TOE for a REK, and that the TSS includes a description of the method of generation of a REK. The evaluator shall verify that the description of the protection of a REK describes how any reading, import, and export of that REK is prevented. For example, if the hardware protecting the REK is removable, the description should include how other devices are prevented from reading the REK. The evaluator shall verify that the TSS describes how encryption/decryption/derivation actions are isolated so as to prevent applications and system-level processes from reading the REK while allowing encryption/decryption/derivation by the key. The evaluator shall verify that the description includes how the OS is prevented from accessing the memory containing REK key material, which software is allowed access to the REK, how any other software in the execution environment is prevented from reading that key material, and what other mechanisms prevent the REK key material from being written to shared memory locations between the OS and the separate execution environment. If key derivation is performed using a REK, the evaluator shall ensure that the TSS description includes a description of the key derivation function and shall verify the key derivation uses an approved derivation mode and key expansion algorithm as defined in FCS_CKM_EXT.3.2. The evaluator shall verify that the generation of a REK meets the FCS_RBG.1 requirement: If REKs is/are generated on-device, the TSS shall include a description of the generation mechanism including what triggers a generation, how the functionality described by FCS_RBG.1 is invoked, and whether a separate instance of the DRBG is used for REKs. If REKs is/are generated off-device, the TSS shall include evidence that the DRBG meets FCS_RBG.1. This will likely necessitate a second set of DRBG documentation equivalent to the documentation provided for the DRBG Evaluation Activities. In addition, the TSS shall describe the manufacturing process that prevents the device manufacturer from accessing any REKs. There are no guidance evaluation activities for this component. There are no test evaluation activities for this component.

Generation of a REKNone

requires the TSF to specify the mechanism it uses to generate Data Encryption Keys (DEKs).

There are no management activities foreseen. There are no auditable events foreseen. FCS_RBG.1 Random Bit Generation

All DEKs shall be <selectables> <selectable>randomly generated by a method defined in FCS_RBG.1,</selectable> <selectable> from the combination of a randomly generated DEK with another DEK or salt in a way that preserves the effective entropy of each factor by <selectables linebreak="yes"> <selectable>using an XOR operation,</selectable> <selectable>concatenating the keys and using a KDF (as described in SP 800-108),</selectable> <selectable id="s-dek-800-56">concatenating the keys and using a KDF (as described in SP 800-56C)</selectable> </selectables> </selectable> </selectables> with entropy corresponding to the security strength of AES key sizes of 256 bits.

All DEKs shall be <assignable>generation mechanism</assignable> with entropy corresponding to the security strength of AES key sizes of 256 bits.

The intent of this requirement is to ensure that the DEK cannot be recovered with less work than a full exhaust of the key space for AES. The key generation capability of the TOE uses a DRBG implemented on the TOE device (FCS_RBG.1). A DEK is used in addition to the KEK so that authentication factors can be changed without having to re-encrypt all of the user data on the device. The ST author selects all applicable DEK generation types implemented by the TOE. SP 800-56C specifies a two-step key derivation procedure that employs an extraction-then-expansion technique for deriving keying material from a shared secret generated during a key establishment scheme. The Randomness Extraction step as described in Section 5 of SP 800-56C is followed by Key Expansion using the key derivation functions defined in SP 800-108 (as described in Section 6 of SP 800-56C). The evaluator shall ensure that the documentation of the product's encryption key management is detailed enough that, after reading, the product's key management hierarchy is clear and that it meets the requirements to ensure the keys are adequately protected. The evaluator shall ensure that the documentation includes both an essay and one or more diagrams. Note that this may also be documented as separate proprietary evidence rather than being included in the TSS. The evaluator shall also examine the key hierarchy section of the TSS to ensure that the formation of all DEKs is described and that the key sizes match that described by the ST author. The evaluator shall examine the key hierarchy section of the TSS to ensure that each DEK is generated or combined from keys of equal or greater security strength using one of the selected methods. If the symmetric DEK is generated by a DRBG, the evaluator shall review the TSS to determine that it describes how the functionality described by FCS_RBG.1 is invoked. The evaluator uses the description of the DRBG functionality in FCS_RBG.1 or documentation available for the operational environment to determine that the key size being requested is greater than or equal to the key size and mode to be used for the encryption/decryption of the data. If the DEK is formed from a combination, the evaluator shall verify that the TSS describes the method of combination and that this method is either an XOR or a KDF to justify that the effective entropy of each factor is preserved. The evaluator shall also verify that each combined value was originally generated from an Approved DRBG described in FCS_RBG.1. If is selected, the evaluator shall ensure the TSS includes a description of the randomness extraction step. The description must include how an approved untruncated MAC function is being used for the randomness extraction step and the evaluator shall verify the TSS describes that the output length (in bits) of the MAC function is at least as large as the targeted security strength (in bits) of the parameter set employed by the key establishment scheme (see Tables 1-3 of SP 800-56C). The description must include how the MAC function being used for the randomness extraction step is related to the PRF used in the key expansion and verify the TSS description includes the correct MAC function: If an HMAC-hash is used in the randomness extraction step, then the same HMAC-hash (with the same hash function hash) is used as the PRF in the key expansion step. If an AES-CMAC is used in the randomness extraction step, then AES-CMAC with a 128-bit key is used as the PRF in the key expansion step. The description must include the lengths of the salt values being used in the randomness extraction step and the evaluator shall verify the TSS description includes correct salt lengths: If an HMAC-hash is being used as the MAC, the salt length can be any value up to the maximum bit length permitted for input to the hash function hash. If an AES-CMAC is being used as the MAC, the salt length shall be the same length as the AES key (i.e., 256 bits). (conditional) If a KDF is used, the evaluator shall ensure that the TSS includes a description of the key derivation function and shall verify the key derivation uses an approved derivation mode and key expansion algorithm as defined in SP 800-108 or SP 800-56C. The evaluator uses the description of the DRBG functionality in FCS_RBG.1 or documentation available for the operational environment to determine that the key size being generated or combined is identical to the key size and mode to be used for the encryption/decryption of the data. If a KDF is used, the evaluator shall perform one or more of the following tests to verify the correctness of the key derivation function, depending on the modes that are supported. maps the data fields to the notations used in SP 800-108 and SP 800-56C. : Notations used in SP 800-108 and SP 800-56C Pseudorandom functionPRFPRF Counter lengthrr Length of output of PRFhh Length of derived keying materialLL Length of input valuesl lengthl length Pseudorandom input values IK1 (key derivation key)Z (shared secret) Pseudorandom salt valuesn/as Randomness extraction MACn/aMAC Counter Mode Tests: The evaluator shall determine the following characteristics of the key derivation function: One or more pseudorandom functions that are supported by the implementation (PRF). One or more of the values {8, 16, 24, 32} that equal the length of the binary representation of the counter (r). The length (in bits) of the output of the PRF (h). Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. These must be evenly divisible by h. Up to two values of L that are NOT evenly divisible by h. Location of the counter relative to fixed input data: before, after, or in the middle. Counter before fixed input data: fixed input data string length (in bytes), fixed input data string value. Counter after fixed input data: fixed input data string length (in bytes), fixed input data string value. Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string input before counter, value of string input after counter. The length (I_length) of the input values I. For each supported combination of I_length, MAC, salt, PRF, counter location, value of r, and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I, and pseudorandom salt values. If there is only one value of L that is evenly divisible by h, the evaluator shall generate 20 test vectors for it. For each test vector, the evaluator shall supply this data to the TOE in order to produce the keying material output. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation. Feedback Mode Tests: The evaluator shall determine the following characteristics of the key derivation function: One or more pseudorandom functions that are supported by the implementation (PRF). The length (in bits) of the output of the PRF (h). Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. These must be evenly divisible by h. Up to two values of L that are NOT evenly divisible by h. Whether or not zero-length IVs are supported. Whether or not a counter is used, and if so: One or more of the values {8, 16, 24, 32} that equal the length of the binary representation of the counter (r). Location of the counter relative to fixed input data: before, after, or in the middle. Counter before fixed input data: fixed input data string length (in bytes), fixed input data string value. Counter after fixed input data: fixed input data string length (in bytes), fixed input data string value. Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string input before counter, value of string input after counter. The length (I_length) of the input values I. For each supported combination of I_length, MAC, salt, PRF, counter location (if a counter is used), value of r (if a counter is used), and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I and pseudorandom salt values. If the KDF supports zero-length IVs, five of these test vectors will be accompanied by pseudorandom IVs and the other five will use zero-length IVs. If zero-length IVs are not supported, each test vector will be accompanied by an pseudorandom IV. If there is only one value of L that is evenly divisible by h, the evaluator shall generate 20 test vectors for it. For each test vector, the evaluator shall supply this data to the TOE in order to produce the keying material output. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation. Double Pipeline Iteration Mode Tests: The evaluator shall determine the following characteristics of the key derivation function: One or more pseudorandom functions that are supported by the implementation (PRF). The length (in bits) of the output of the PRF (h). Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. These must be evenly divisible by h. Up to two values of L that are NOT evenly divisible by h. Whether or not a counter is used, and if so: One or more of the values {8, 16, 24, 32} that equal the length of the binary representation of the counter (r). Location of the counter relative to fixed input data: before, after, or in the middle. Counter before fixed input data: fixed input data string length (in bytes), fixed input data string value. Counter after fixed input data: fixed input data string length (in bytes), fixed input data string value. Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string input before counter, value of string input after counter. The length (I_length) of the input values I. For each supported combination of I_length, MAC, salt, PRF, counter location (if a counter is used), value of r (if a counter is used), and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I, and pseudorandom salt values. If there is only one value of L that is evenly divisible by h, the evaluator shall generate 20 test vectors for it. For each test vector, the evaluator shall supply this data to the TOE in order to produce the keying material output. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation.

requires the TSF to generate and manage the strength of Key Encryption Keys (KEKs).

There are no management activities foreseen. There are no auditable events foreseen. FCS_CKM.1 Cryptographic Key Generation FCS_COP.1 Cryptographic Operation FCS_RBG.1 Random Bit Generation

The TSF shall use <selectables> <selectable id="s-kek-asym"><snip>asymmetric KEKs</snip> of <assignable id="a-kek-asym-size">security strength greater than or equal to 192 bits</assignable> security strength</selectable> <selectable id="s-kek-sym"><snip>symmetric KEKs</snip> of 256-bit security strength corresponding to at least the security strength of the keys encrypted by the KEK</selectable> </selectables>.

The TSF shall use <assignable>description of KEKs</assignable>.

The ST author selects all applicable KEK types implemented by the TOE.

The TSF shall generate all KEKs using one of the following methods: <h:ul><h:li>Derive the KEK from a Password Authentication Factor as defined in FCS_CKM_EXT.8 and </h:li></h:ul> <selectables linebreak="yes"> <selectable>Generate the KEK using a DRBG that meets this profile (as defined in FCS_RBG.1)</selectable> <selectable>Generate the KEK using a key generation scheme that meets this profile (as defined in FCS_CKM.1/AKG or FCS_CKM.1/SKG)</selectable> <selectable>Combine the KEK from other KEKs in a way that preserves the effective entropy of each factor by <selectables> <selectable>using an XOR operation</selectable> <selectable>concatenating the keys and using a KDF (as described in SP 800-108)</selectable> <selectable>concatenating the keys and using a KDF (as described in SP 800-56C)</selectable> <selectable>encrypting one key with another</selectable></selectables> </selectable> </selectables>.

The TSF shall generate all KEKs using one of the following methods: <h:ul><h:li>Derive the KEK from a Password Authentication Factor as defined in FCS_COP.1.1 and </h:li></h:ul> <selectables linebreak="yes"> <selectable>Generate the KEK using a DRBG that meets this profile (as defined in FCS_RBG.1)</selectable> <selectable>Generate the KEK using a key generation scheme that meets this profile (as defined in FCS_CKM.1/AKG or FCS_CKM.1/SKG)</selectable> <selectable>Combine the KEK from other KEKs in a way that preserves the effective entropy of each factor by <selectables> <selectable>using an XOR operation</selectable> <selectable>concatenating the keys and using a KDF (as described in SP 800-108)</selectable> <selectable>concatenating the keys and using a KDF (as described in SP 800-56C)</selectable> <selectable>encrypting one key with another</selectable> </selectables> </selectable> </selectables>.

The conditioning of passwords is performed in accordance with FCS_CKM_EXT.8. It is expected that key generation derived from conditioning, using a DRBG or generation scheme, and through combination, will each be necessary to meet the requirements set out in this document. In particular, has KEKs of each type: KEK_3 is generated, KEK_1 is derived from a Password Authentication Factor, and KEK_2 is combined from two KEKs. In , KEK_3 may either be a symmetric key generated from a DRBG or an asymmetric key generated using a key generation scheme as defined in FCS_CKM.1/AKG. If combined, the ST author should describe which method of combination is used in order to justify that the effective entropy of each factor is preserved. SP 800-56C specifies a two-step key derivation procedure that employs an extraction-then-expansion technique for deriving keying material from a shared secret generated during a key establishment scheme. The Randomness Extraction step as described in Section 5 of SP 800-56C is followed by Key Expansion using the key derivation functions defined in SP 800-108 (as described in Section 6 of SP 800-56C). The evaluator shall examine the key hierarchy section of the TSS to ensure that the formation of all KEKs are described and that the key sizes match that described by the ST author. The evaluator shall examine the key hierarchy section of the TSS to ensure that each key (DEKs, software-based key storage, and KEKs) is encrypted by keys of equal or greater security strength using one of the selected methods. The evaluator shall review the TSS to verify that it contains a description of the conditioning used to derive KEKs. This description must include the size and storage location of salts. This activity may be performed in combination with that for FCS_CKM_EXT.8. (conditional) If the symmetric KEK is generated by a DRBG, the evaluator shall review the TSS to determine that it describes how the functionality described by FCS_RBG.1 is invoked. The evaluator uses the description of the DRBG functionality in FCS_RBG.1 or documentation available for the operational environment to determine that the key size being requested is greater than or equal to the key size and mode to be used for the encryption/decryption of the data. (conditional) If the KEK is generated according to an asymmetric key scheme, the evaluator shall review the TSS to determine that it describes how the functionality described by FCS_CKM.1/AKG is invoked. The evaluator uses the description of the key generation functionality in FCS_CKM.1/AKG or documentation available for the operational environment to determine that the key strength being requested is greater than or equal to 112 bits. (conditional) If the KEK is formed from a combination, the evaluator shall verify that the TSS describes the method of combination and that this method is either an XOR, a KDF, or encryption. (conditional) If a KDF is used, the evaluator shall ensure that the TSS includes a description of the key derivation function and shall verify the key derivation uses an approved derivation mode and key expansion algorithm as defined in SP 800-108. (conditional) If is selected, the evaluator shall ensure the TSS includes a description of the randomness extraction step. The description must include How an approved untruncated MAC function is being used for the randomness extraction step and the evaluator shall verify the TSS describes that the output length (in bits) of the MAC function is at least as large as the targeted security strength (in bits) of the parameter set employed by the key establishment scheme (see Tables 1-3 of SP 800-56C). How the MAC function being used for the randomness extraction step is related to the PRF used in the key expansion and verify the TSS description includes the correct MAC function: If an HMAC-hash is used in the randomness extraction step, then the same HMAC-hash (with the same hash function hash) is used as the PRF in the key expansion step. If an AES-CMAC (with key length 128, 192, or 256 bits) is used in the randomness extraction step, then AES-CMAC with a 128-bit key is used as the PRF in the key expansion step. The lengths of the salt values being used in the randomness extraction step and the evaluator shall verify the TSS description includes correct salt lengths: If an HMAC-hash is being used as the MAC, the salt length can be any value up to the maximum bit length permitted for input to the hash function hash. If an AES-CMAC is being used as the MAC, the salt length shall be the same length as the AES key (i.e., 256 bits). The evaluator shall also ensure that the documentation of the product's encryption key management is detailed enough that, after reading, the product's key management hierarchy is clear and that it meets the requirements to ensure the keys are adequately protected. The evaluator shall ensure that the documentation includes both an essay and one or more diagrams. Note that this may also be documented as separate proprietary evidence rather than being included in the TSS. There are no guidance evaluation activities for this component. If a KDF is used, the evaluator shall perform one or more of the following tests to verify the correctness of the key derivation function, depending on the modes that are supported. maps the data fields to the notations used in SP 800-108 and SP 800-56C. : Notations used in SP 800-108 and SP 800-56C Pseudorandom functionPRFPRF Counter lengthrr Length of output of PRFhh Length of derived keying materialLL Length of input valuesI_lengthI_length Pseudorandom input values IK1 (key derivation key)Z (shared secret) Pseudorandom salt valuesn/as Randomness extraction MACn/aMAC Counter Mode Tests: The evaluator shall determine the following characteristics of the key derivation function: One or more pseudorandom functions that are supported by the implementation (PRF). One or more of the values {8, 16, 24, 32} that equal the length of the binary representation of the counter (r). The length (in bits) of the output of the PRF (h). Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. These must be evenly divisible by h. Up to two values of L that are NOT evenly divisible by h. Location of the counter relative to fixed input data: before, after, or in the middle. Counter before fixed input data: fixed input data string length (in bytes), fixed input data string value. Counter after fixed input data: fixed input data string length (in bytes), fixed input data string value. Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string input before counter, value of string input after counter. The length (I_length) of the input values I. For each supported combination of I_length, MAC, salt, PRF, counter location, value of r, and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I, and pseudorandom salt values. If there is only one value of L that is evenly divisible by h, the evaluator shall generate 20 test vectors for it. For each test vector, the evaluator shall supply this data to the TOE in order to produce the keying material output. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation. Feedback Mode Tests: The evaluator shall determine the following characteristics of the key derivation function: One or more pseudorandom functions that are supported by the implementation (PRF). The length (in bits) of the output of the PRF (h). Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. These must be evenly divisible by h. Up to two values of L that are NOT evenly divisible by h. Whether or not zero-length IVs are supported. Whether or not a counter is used, and if so: One or more of the values {8, 16, 24, 32} that equal the length of the binary representation of the counter (r). Location of the counter relative to fixed input data: before, after, or in the middle. Counter before fixed input data: fixed input data string length (in bytes), fixed input data string value. Counter after fixed input data: fixed input data string length (in bytes), fixed input data string value. Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string input before counter, value of string input after counter. The length (I_length) of the input values I. For each supported combination of I_length, MAC, salt, PRF, counter location (if a counter is used), value of r (if a counter is used), and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I and pseudorandom salt values. If the KDF supports zero-length IVs, five of these test vectors will be accompanied by pseudorandom IVs and the other five will use zero-length IVs. If zero-length IVs are not supported, each test vector will be accompanied by an pseudorandom IV. If there is only one value of L that is evenly divisible by h, the evaluator shall generate 20 test vectors for it. For each test vector, the evaluator shall supply this data to the TOE in order to produce the keying material output. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation. Double Pipeline Iteration Mode Tests: The evaluator shall determine the following characteristics of the key derivation function: One or more pseudorandom functions that are supported by the implementation (PRF). The length (in bits) of the output of the PRF (h). Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. These must be evenly divisible by h. Up to two values of L that are NOT evenly divisible by h. Whether or not a counter is used, and if so: One or more of the values {8, 16, 24, 32} that equal the length of the binary representation of the counter (r). Location of the counter relative to fixed input data: before, after, or in the middle. Counter before fixed input data: fixed input data string length (in bytes), fixed input data string value. Counter after fixed input data: fixed input data string length (in bytes), fixed input data string value. Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string input before counter, value of string input after counter. The length (I_length) of the input values I. For each supported combination of I_length, MAC, salt, PRF, counter location (if a counter is used), value of r (if a counter is used), and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I, and pseudorandom salt values. If there is only one value of L that is evenly divisible by h, the evaluator shall generate 20 test vectors for it. For each test vector, the evaluator shall supply this data to the TOE in order to produce the keying material output. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation.

requires the TSF to implement a cryptographic or other mechanism to make TSF data unreadable.

The following actions could be considered for the management functions in FMT: TSF wipe of protected data. TSF wipe of enterprise data. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP, PP-Module, functional package or ST: Failure of the wipe. FCS_CKM.6 Timing and Event of Cryptographic Key Destruction FCS_RBG.1 Random Bit Generation

The TSF shall wipe all protected data by <selectables linebreak="yes"> <selectable>Cryptographically erasing the encrypted DEKs or the KEKs in non-volatile memory by following the requirements in FCS_CKM.6.2,</selectable> <selectable>Overwriting all protected data according to the following rules: <h:ul> <h:li>For EEPROM, the destruction shall be executed by a single direct overwrite consisting of a pseudo random pattern using the TSF’s DRBG (as defined in FCS_RBG.1), followed by a read-verify.</h:li> <h:li>For flash memory, that is not wear-leveled, the destruction shall be executed <selectables> <selectable>by a single direct overwrite consisting of zeros followed by a read-verify</selectable> <selectable>by a block erase that erases the reference to memory that stores data as well as the data itself</selectable></selectables>.</h:li> <h:li>For flash memory, that is wear-leveled, the destruction shall be executed <selectables> <selectable>by a single direct overwrite consisting of zeros</selectable> <selectable>by a block erase</selectable> </selectables>. </h:li> <h:li>For non-volatile memory other than EEPROM and flash, the destruction shall be executed by a single direct overwrite with a random pattern that is changed before each write. </h:li> </h:ul> </selectable> </selectables>. Protected data is all non-TSF data, including all user or enterprise data. Some or all of this data may be considered sensitive data as well.

The TSF shall perform a power cycle on conclusion of the wipe procedure. The evaluator shall check to ensure the TSS describes how the device is wiped, the type of clearing procedure that is performed (cryptographic erase or overwrite) and, if overwrite is performed, the overwrite procedure (overwrite with zeros, overwrite three or more times by a different alternating pattern, overwrite with random pattern, or block erase). If different types of memory are used to store the data to be protected, the evaluator shall check to ensure that the TSS describes the clearing procedure in terms of the memory in which the data are stored (for example, data stored on flash are cleared by overwriting once with zeros, while data stored on the internal persistent storage device are cleared by overwriting three times with a random pattern that is changed before each write). The evaluator shall verify that the AGD guidance describes how to enable encryption, if it is not enabled by default. Additionally the evaluator shall verify that the AGD guidance describes how to initiate the wipe command. Evaluation Activity Note: The following test may require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on consumer Mobile Device products. The evaluator shall perform one of the following tests. The test before and after the wipe command shall be identical. This test shall be repeated for each type of memory used to store the data to be protected. For File-based Methods: The evaluator shall enable encryption according to the AGD guidance. The evaluator shall create a user data (protected data or sensitive data) file, for example, by using an application. The evaluator shall use a tool provided by the developer to examine this data stored in memory (for example, by examining a decrypted files). The evaluator shall initiate the wipe command according to the AGD guidance provided for FMT_SMF_EXT.1. The evaluator shall use a tool provided by the developer to examine the same data location in memory to verify that the data has been wiped according to the method described in the TSS (for example, the files are still encrypted and cannot be accessed). For Volume-based Methods: The evaluator shall enable encryption according to the AGD guidance. The evaluator shall create a unique data string, for example, by using an application. The evaluator shall use a tool provided by the developer to search decrypted data for the unique string. The evaluator shall initiate the wipe command according to the AGD guidance provided for FMT_SMF_EXT.1. The evaluator shall use a tool provided by the developer to search for the same unique string in decrypted memory to verify that the data has been wiped according to the method described in the TSS (for example, the files are still encrypted and cannot be accessed). The evaluator shall cause the device to wipe and verify that the wipe concludes with a power cycle.

Failure of the wipeNone

requires the TSF to generate salts in a specified manner.

There are no management activities foreseen. There are no auditable events foreseen. FCS_RBG.1 Random Bit Generation

The TSF shall generate all salts using a DRBG that meets FCS_RBG.1. This requirement refers only to salt generation. In the examples given, a salt may be used as part of the scheme/algorithm. Requirements on nonces or ephemeral keys are provided elsewhere, if needed. The list below is provided for clarity, in order to give examples of where the TSF may be generating cryptographic salts; it is not exhaustive nor is it intended to mandate implementation of all of these schemes/algorithms. Cryptographic salts are generated for various uses including: RSASSA-PSS signature generation DSA signature generation ECDSA signature generation DH static key agreement scheme PBKDF Key Agreement Scheme in NIST SP 800-56B AES GCM The evaluator shall verify that the TSS contains a description regarding the salt generation, including which algorithms on the TOE require salts. The evaluator shall confirm that the salt is generated using a DRBG described in FCS_RBG.1. For PBKDF derivation of KEKs, this evaluation activity may be performed in conjunction with FCS_CKM_EXT.3.2. There are no guidance evaluation activities for this component. There are no test evaluation activities for this component.

requires the TSF to perform key establishment regardless of whether the device is locked or unlocked.

The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP, PP-Module, functional package or ST: minimal: Success and failure of the activity; basic: The object attribute(s), and object value(s) excluding any sensitive information. [FDP_ITC.1 Import of User Data without Security Attributes, or FDP_ITC.2 Import of User Data with Security Attributes, or FCS_CKM.1 Cryptographic Key Generation, or FCS_CKM.5 Cryptographic Key Derivation, or FCS_CKM_EXT.8 Password-Based Key Derivation], [FCS_CKM_EXT.7 Cryptographic Key Distribution, or FCS_COP.1 Cryptographic Operation] FCS_CKM.6 Timing and Event of Cryptographic Key Destruction FCS_COP.1 Cryptographic Operation

The TSF shall derive shared cryptographic keys with input from multiple parties in accordance with specified cryptographic key agreement algorithms <assignable>cryptographic algorithm</assignable> and specified cryptographic parameters <assignable>cryptographic parameters</assignable> that meet the following: <assignable>list of standards</assignable>.

The TSF shall derive shared cryptographic keys with input from multiple parties in accordance with specified cryptographic key agreement algorithms <h:b>for the purposes of encrypting sensitive data received while the device is locked</h:b>. <selectables> <tabularize id="fcs-ckm-ext-7-locked-sels" title="Allowable choices for FCS_CKM_EXT.7/LOCKED"> <textcol>Identifier</textcol> <selectcol>Cryptographic Algorithm</selectcol> <reqtext>and specified cryptographic parameters</reqtext> <selectcol>Cryptographic Parameters</selectcol> <reqtext>that meet the following:</reqtext> <selectcol>List of Standards</selectcol> <reqtext>.<h:p/><h:p/><xref to="fcs-ckm-ext-7-locked-sels"/> provides the allowable choices for completion of the selection operations of FCS_CKM_EXT.7/LOCKED.</reqtext> </tabularize> <selectable id="sel-fcs-ckm-kat-kas2"> <col>KAS2</col> <col>RSA</col> <col>Modulus size <selectables> <selectable>3072</selectable> <selectable>4096</selectable> <selectable>6144</selectable> <selectable>8192</selectable> </selectables> bits</col> <col>NIST SP 800-56B Revision 2 (Section 8.3) [KAS2]</col> </selectable> <selectable id="sel-fcs-ckm-kat-dh"> <col>DH</col> <col>Finite Field Cryptography Diffie-Hellman</col> <col>Static domain parameters approved for <selectables> <selectable>IKE Groups <selectables> <selectable id="sel-kat-ffc-modp3072">MODP-3072</selectable> <selectable id="sel-kat-ffc-modp4096">MODP-4096</selectable> <selectable id="sel-kat-ffc-modp6144">MODP-6144</selectable> <selectable id="sel-kat-ffc-modp8192">MODP-8192</selectable> </selectables></selectable> <selectable>TLS Groups <selectables> <selectable id="sel-kat-ffc-ffdhe3072">ffdhe3072</selectable> <selectable id="sel-kat-ffc-ffdhe4096">ffdhe4096</selectable> <selectable id="sel-kat-ffc-ffdhe6144">ffdhe6144</selectable> <selectable id="sel-kat-ffc-ffdhe8192">ffdhe8192</selectable> </selectables></selectable></selectables> </col> <col> NIST SP 800-56A Revision 3 (Section 5.7.1.1) [DH]<h:p/> <selectables> <selectable>RFC 3526 [IKE groups]</selectable> <selectable>RFC 7919 [TLS groups]</selectable></selectables> </col> </selectable> <selectable id="sel-fcs-ckm-kat-ecdh"> <col>ECDH</col> <col>Elliptic Curve Diffie-Hellman</col> <col>Elliptic Curve <selectables> <selectable id="sel-exp-kat-ecdh-P384">P-384</selectable> <selectable id="sel-exp-kat-ecdh-P521">P-521</selectable></selectables> </col> <col> NIST SP 800-56A Revision 3 (Section 5.7.1.2) [ECDH]<h:p/> NIST SP 800-186 (Section 3.2.1) [NIST Curves] </col> </selectable> <selectable id="sel-fcs-ckm-kat-ecdhed"> <col>ECDH-Ed</col> <col>ECDH with Montgomery Curves</col> <col>Domain parameters approved for elliptic curves [<h:i>curve25519</h:i>] </col> <col> RFC 7748 (Section 5) [ECDH-Ed]<h:p/> NIST SP 800-186 (Section 3.2.2) [Montgomery Curves] </col> </selectable> </selectables> This SFR defines the asymmetric key scheme used to protect data at rest as defined by FDP_DAR_EXT.2.2. The evaluator shall ensure that the TSS documents that the security strength of the material contributed by the TOE is sufficient for the security strength of the key and the agreement method. There are no additional guidance evaluation activities for this component. The following tests are conditional based upon the selections made in the SFR. The evaluator shall perform the following test or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described. KAS2 KAS2 RSA Modulus Size [selection: 3072, 4096, 6144, 8192] bits NIST SP 800-56B Revision 2 (Section 8.3) [KAS2] To test the TOE’s implementation of the of the KAS2 RSA Key Agreement scheme, the evaluator shall perform the Algorithm Functional Test and Validation Test using the following input parameters: RSA Private key format [Basic, Prime Factor, Chinese Remainder Theorem] Modulo value [3072, 4096, 6144, 8192] Role [initiator, responder] The evaluator shall generate a test group (i.e., set of tests) for each parameter value of the above parameter type with the largest number of supported values. For example, if the TOE supports all five Modulo values, then the evaluator shall generate five test groups. Each of the above supported parameter values must be included in at least one test group. Regardless of how many parameter values are supported, there must be at least two test groups. Half of the test groups are designated as Algorithm Functional Tests (AFT) and the remainder are designated as Validation Tests (VAT). If there is an odd number of groups, then the extra group is designated randomly as either AFT or VAT. Algorithm Functional Test For each test group designated as AFT, the evaluator shall generate 10 test cases using random data (except for a fixed public exponent, if supported). The resulting shared secrets shall be compared with those generated by a known-good implementation using the same inputs. Validation Test For each test group designated as VAT, the evaluator shall generate 25 test cases are using random data (except for a fixed public exponent, if supported). Of the 25 test cases: Two test cases must have a shared secret with a leading nibble of 0s, Two test cases have modified derived key material, Two test cases have modified tags, if key confirmation is supported, Two test cases have modified MACs, if key confirmation is supported, and The remaining test cases are not modified. To determine correctness, the evaluator shall confirm that the resulting 25 shared secrets correspond as expected for both the modified and unmodified values. FFC Diffie-Hellman Key Agreement DH Finite Field Cryptography Diffie-Hellman Static domain parameters approved for [selection: IKE groups [selection: MODP-3072, MODP-4096, MODP-6144, MODP-8192], TLS groups [selection: ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192]] NIST SP 800-56A Revision 3 (Section 5.7.1.1) [DH] [selection: RFC 3526 [IKE Groups], RFC 7919 [TLS Groups]] To test the TOE’s implementation of FFC Diffie-Hellman Key Agreement, the evaluator shall perform the Algorithm Functional Test and Validation Test using the following input parameters: Domain Parameter Group [MODP-3072, MODP-4096, MODP-6144, MODP-8192, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192] Algorithm Functional Test For each supported domain parameter group, the evaluator shall generate 10 test cases by generating the initiator and responder secret keys using random data, calculating the responder public key, and creating the shared secret. The resulting shared secrets shall be compared with those generated by a known-good implementation using the same inputs. Validation Test For each supported combination of the above parameters the evaluator shall generate 15 Diffie Hellman initiator/responder key pairs using the key generation function of a known-good implementation. For each set of key pairs, the evaluator shall modify five initiator private key values. The remaining key values are left unchanged (i.e., correct). To determine correctness, the evaluator shall confirm that the 15 shared secrets correspond as expected for both the modified and unmodified inputs. Elliptic Curve Diffie-Hellman Key Agreement ECDH Elliptic Curve Diffie-Hellman Elliptic Curve [selection: P-384, P-521] NIST SP 800-56A Revision 3 (Section 5.7.1.2) [ECDH] NIST SP 800-186 (Section 3.2.1) [NIST Curves] To test the TOE’s implementation of Elliptic Curve Diffie-Hellman Key Agreement, the evaluator shall perform the Algorithm Functional Test and Validation Test using the following input parameters: Elliptic Curve [P-384, P-521] Algorithm Functional Test For each supported Elliptic Curve the evaluator shall generate 10 test cases by generating the initiator and responder secret keys using random data, calculating the responder public key, and creating the shared secret. The resulting shared secrets shall be compared with those generated by a known-good implementation using the same inputs. Validation Test For each supported Elliptic Curve the evaluator shall generate 15 Diffie Hellman initiator/responder key pairs using the key generation function of a known-good implementation. For each set of key pairs, the evaluator shall modify five initiator private key values. The remaining key values are left unchanged (i.e., correct). To determine correctness, the evaluator shall confirm that the 15 shared secrets correspond as expected for the modified and unmodified values. Curve25519 Key Establishment Schemes ECDH-Ed ECDH with Montgomery Curves Domain parameters approved for elliptic curves [curve25519] RFC 7748 (Section 5) [ECDH-Ed] NIST SP 800-186 (Section 3.2.2) [Montgomery Curves] Curve25519 Key Establishment Schemes The evaluator shall verify a TOE's implementation of the key agreement scheme using the following Function and Validity tests. These validation tests for each key agreement scheme verify that a TOE has implemented the components of the key agreement scheme according to the specification. These components include the calculation of the shared secret K and the hash of K. Function Test The Function test verifies the ability of the TOE to implement the key agreement schemes correctly. To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each supported key agreement role and hash function combination, the tester shall generate 10 sets of public keys. These keys are static, ephemeral or both depending on the scheme being tested. The evaluator shall obtain the shared secret value K, and the hash of K. The evaluator shall verify the correctness of the TSF’s implementation of a given scheme by using a known good implementation to calculate the shared secret value K and compare the hash generated from this value. Validation Test The Validity test verifies the ability of the TOE to recognize another party’s valid and invalid key agreement results. To conduct this test, the evaluator generates a set of 30 test vectors consisting of data sets including the evaluator’s public keys and the TOE’s public/private key pairs. The evaluator shall inject an error in some of the test vectors to test that the TOE recognizes invalid key agreement results caused by the following fields being incorrect: the shared secret value K or the hash of K. At least two of the test vectors shall remain unmodified and therefore should result in valid key agreement results (they should pass). The TOE shall use these modified test vectors to emulate the key agreement scheme using the corresponding parameters. The evaluator shall compare the TOE’s results with the results using a known good implementation verifying that the TOE detects these errors.

The TSF shall derive shared cryptographic keys with input from multiple parties in accordance with specified cryptographic key agreement algorithms <selectables> <tabularize id="fcs-ckm-ext-7-unlocked-sels" title="Allowable choices for FCS_CKM_EXT.7/UNLOCKED"> <textcol>Identifier</textcol> <selectcol>Cryptographic algorithm</selectcol> <reqtext>and specified cryptographic parameters</reqtext> <selectcol>Cryptographic parameters</selectcol> <reqtext>that meet the following:</reqtext> <selectcol>List of standards</selectcol> <reqtext>.<h:p/><h:p/><xref to="fcs-ckm-ext-7-unlocked-sels"/> provides the allowable choices for completion of the selection operations of FCS_CKM_EXT.7/UNLOCKED.</reqtext> </tabularize>  <selectable id="sel-fcs-ckm-kat-dh"> <col>DH</col> <col>Finite Field Cryptography Diffie-Hellman</col> <col>Static domain parameters approved for <selectables> <selectable>IKE Groups <selectables> <selectable id="sel-kat-ffc-modp3072">MODP-3072</selectable> <selectable id="sel-kat-ffc-modp4096">MODP-4096</selectable> <selectable id="sel-kat-ffc-modp6144">MODP-6144</selectable> <selectable id="sel-kat-ffc-modp8192">MODP-8192</selectable> </selectables></selectable> <selectable>TLS Groups <selectables> <selectable id="sel-kat-ffc-ffdhe3072">ffdhe3072</selectable> <selectable id="sel-kat-ffc-ffdhe4096">ffdhe4096</selectable> <selectable id="sel-kat-ffc-ffdhe6144">ffdhe6144</selectable> <selectable id="sel-kat-ffc-ffdhe8192">ffdhe8192</selectable> </selectables></selectable></selectables> </col> <col> NIST SP 800-56A Revision 3 (Section 5.7.1.1) [DH]<h:p/> <selectables> <selectable>RFC 3526 [IKE groups]</selectable> <selectable>RFC 7919 [TLS groups]</selectable></selectables> </col> </selectable> <selectable id="sel-fcs-ckm-kat-ecdh"> <col>ECDH</col> <col>Elliptic Curve Diffie-Hellman</col> <col>Elliptic Curve <selectables> <selectable id="sel-exp-kat-ecdh-P384">P-256</selectable> <selectable id="sel-exp-kat-ecdh-P384">P-384</selectable> <selectable id="sel-exp-kat-ecdh-P521">P-521</selectable></selectables> </col> <col> NIST SP 800-56A Revision 3 (Section 5.7.1.2) [ECDH]<h:p/> NIST SP 800-186 (Section 3.2.1) [NIST Curves] </col> </selectable> </selectables>

This SFR is claimed if the TSF supports key agreement schemes as a method of key establishment for external communications channels. This will generally apply to all conformant TOEs, except in the rare (but possible) case where only key encapsulation is used. This SFR must be included in the ST if agreement is a service provided by the TOE to tenant software, or if it is used by the TOE itself to support or implement PP-specified security functionality. The above algorithms are CNSA compliant with the exception of P-256 ECDH. This may only be selected if the is included in the ST and P-256 may only be used specifically for Bluetooth functions. The evaluator shall ensure that the TSS documents that the security strength of the material contributed by the TOE is sufficient for the security strength of the key and the agreement method. If support for P-256 is claimed, the evaluator shall examine the TSS to verify that it is only used for Bluetooth functions. There are no additional Guidance evaluation activities for this component. The following tests are conditional based upon the selections made in the SFR. The evaluator shall perform the following test or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described. FFC Diffie-Hellman Key Agreement DH Finite Field Cryptography Diffie-Hellman Static domain parameters approved for [selection: IKE groups [selection: MODP-3072, MODP-4096, MODP-6144, MODP-8192], TLS groups [selection: ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192]] NIST SP 800-56A Revision 3 (Section 5.7.1.1) [DH] [selection: RFC 3526 [IKE Groups], RFC 7919 [TLS Groups]] To test the TOE’s implementation of FFC Diffie-Hellman Key Agreement, the evaluator shall perform the Algorithm Functional Test and Validation Test using the following input parameters: Domain Parameter Group [MODP-3072, MODP-4096, MODP-6144, MODP-8192, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192] Algorithm Functional Test For each supported domain parameter group, the evaluator shall generate 10 test cases by generating the initiator and responder secret keys using random data, calculating the responder public key, and creating the shared secret. The resulting shared secrets shall be compared with those generated by a known-good implementation using the same inputs. Validation Test For each supported combination of the above parameters the evaluator shall generate 15 Diffie Hellman initiator/responder key pairs using the key generation function of a known-good implementation. For each set of key pairs, the evaluator shall modify five initiator private key values. The remaining key values are left unchanged (i.e., correct). To determine correctness, the evaluator shall confirm that the 15 shared secrets correspond as expected for both the modified and unmodified inputs. Elliptic Curve Diffie-Hellman Key Agreement ECDH Elliptic Curve Diffie-Hellman Elliptic Curve [selection: P-256, P-384, P-521 NIST SP 800-56A Revision 3 (Section 5.7.1.2) [ECDH] NIST SP 800-186 (Section 3.2.1) [NIST Curves] To test the TOE’s implementation of Elliptic Curve Diffie-Hellman Key Agreement, the evaluator shall perform the Algorithm Functional Test and Validation Test using the following input parameters: Elliptic Curve [P-256, P-384, P-521] Algorithm Functional Test For each supported Elliptic Curve the evaluator shall generate 10 test cases by generating the initiator and responder secret keys using random data, calculating the responder public key, and creating the shared secret. The resulting shared secrets shall be compared with those generated by a known-good implementation using the same inputs. Validation Test For each supported Elliptic Curve the evaluator shall generate 15 Diffie Hellman initiator/responder key pairs using the key generation function of a known-good implementation. For each set of key pairs, the evaluator shall modify five initiator private key values. The remaining key values are left unchanged (i.e., correct). To determine correctness, the evaluator shall confirm that the 15 shared secrets correspond as expected for the modified and unmodified values.

requires that password-based key derivation be performed in accordance with specified standards.

The TSF shall perform password-based key derivation functions in accordance with a specified cryptographic algorithm [HMAC-<selectables> <selectable>SHA-384</selectable> <selectable>SHA-512</selectable> </selectables>, with iteration count of <assignable>number of iterations</assignable> using a randomly generated salt of length <assignable>equal to or greater than 128</assignable> and output cryptographic key sizes <selectables> <selectable>256</selectable> <selectable>384</selectable> <selectable>512</selectable></selectables> bits that meet the following standard: [NIST SP 800-132 (Section 5.3) [PBKDF2]]. NIST recommends a minimum “number of iterations” of 1000 but prefers the largest number feasible given performance constraints. NIST recommends that the randomly generated portion of the salt have length of at least 128 bits and must be derived from Random Bit Generation. If this SFR is claimed, then FCS_COP.1/KeyedHash and FCS_RBG.1 must also be claimed. The evaluator shall verify that the TSS documents that the selection of the keyed hash algorithm, iteration count, length of salt, and other mitigations are sufficient for the security strength of the key derived. The evaluator shall examine the TSS to verify that the salt is generated in accordance with the relevant specification. The evaluator shall examine the TSS to determine whether the TOE implements other mitigations against password-exhaustion attacks. Examples include the use of interface-based mitigations and secret salts. The following tests are conditional based upon the selections made in the SFR. The evaluator shall perform the following test or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described. To test the TOE’s ability to derive cryptographic keys from a password using PBKDF2 the evaluator shall perform the Algorithm Functional Test using the following input parameters: HMAC algorithms [SHA-384, SHA-512] Iteration count [1-10000000] Derived Key size [256, 384, 512] bits Password length [8-128] bytes Salt length [128-4096] bits in multiples of 8. Algorithm Functional Test For each supported HMAC algorithm, the evaluator shall generate 50 test cases using supported values for the above parameters such that All supported derived key sizes are tested at least 10 times, Iteration counts are random values between the supported minimum and maximum values, with the supported minimum and maximum tested at least once each, Passwords are random byte strings representing upper- and lower-case letters of random supported lengths such that the minimum and maximum lengths are tested at least once, and Salts are random values between the supported minimum and maximum lengths such that the supported minimum and maximum lengths are both tested at least once. The evaluator shall compare the resulting keys from each test case with keys derived using a known-good implementation with the same input parameters.

requires the TSF to enforce the confidentiality of key data stored in mutable hardware by ensuring no mechanism exists to read or export it.

FCS_CKM_EXT.1 Cryptographic Key Support

A [<h:i>REK</h:i>] shall not be able to be read from or exported from hardware.

A <assignable>key, type of keys, or list of keys</assignable> shall not be able to be read from or exported from hardware.

This SFR is claimed if "mutable hardware" is selected in FCS_CKM_EXT.1.1. It is not claimed if "immutable hardware" is selected because it is implicitly met in that case. The lack of a public or documented API for performing this function is not sufficient to meet the requirement if a private or undocumented function exists to perform it. The evaluation activity for this component is performed in conjunction with the evaluation activity for FCS_CKM_EXT.1.

The TSF shall perform [<h:i>authenticated encryption with associated data</h:i>] in accordance with a specified cryptographic algorithm <selectables> <tabularize id="fcs-cop-aead-sels" title="Allowable choices for FCS_COP.1/AEAD"> <textcol>Identifier</textcol> <reqtext/> <selectcol>Cryptographic algorithm</selectcol> <reqtext>and cryptographic key sizes</reqtext> <selectcol>Cryptographic key sizes</selectcol> <reqtext>that meet the following:</reqtext> <selectcol>List of standards</selectcol> <reqtext>.<h:p/><h:p/><xref to="fcs-cop-aead-sels"/> provides the allowable choices for completion of the selection operations of FCS_COP.1/AEAD.</reqtext> </tabularize> <selectable id="sel-fcs-cop-aead-aes-ccm"> <col>AES-CCM</col> <col>AES in CCM mode with unpredictable, non-repeating nonce, minimum size of 64 bits</col> <col><selectables> <selectable>128 bits</selectable> <selectable>256 bits</selectable> </selectables></col> <col><selectables> <selectable>ISO/IEC 18033-3:2010 (Subclause 5.2)</selectable> <selectable>FIPS PUB 197</selectable></selectables> [AES]<h:p/> <selectables> <selectable>ISO/IEC 19772:2020 (Clause 7)</selectable> <selectable>NIST SP 800-38C</selectable></selectables> [CCM] </col></selectable> <selectable id="sel-fcs-cop-aead-aes-gcm"> <col>AES-GCM</col> <col>AES in GCM mode with non-repeating IVs using <selectables> <selectable>deterministic</selectable> <selectable>DRBG-based</selectable></selectables>, IV construction; the tag must be of length <selectables> <selectable>96</selectable> <selectable>104</selectable> <selectable>112</selectable> <selectable>120</selectable> <selectable>128</selectable> </selectables> bits. </col> <col>256 bits</col> <col><selectables> <selectable>ISO/IEC 18033-3:2010 (Subclause 5.2)</selectable> <selectable>FIPS PUB 197</selectable></selectables> [AES]<h:p/> <selectables> <selectable>ISO/IEC 19772:2020 (Clause 10)</selectable> <selectable>NIST SP 800-38D</selectable></selectables> [GCM] </col></selectable> </selectables> The use of 256-bit keys for AES encryption is required by CNSA. 128-bit keys may only be used when the is claimed and only for the purpose of Bluetooth communications. The evaluator shall examine the TSS to ensure that it describes the construction of any IVs, nonces, and tags in conformance with the relevant specifications. If a CCM mode algorithm is selected, then the evaluator shall examine the TOE summary specification to confirm that it describes how the nonce is generated and that the same nonce is never reused to encrypt different plaintext pairs under the same key. If the use of 128-bit keys is selected in conjunction with AES-CCM, the evaluator shall verify that the TSS describes the use of 128-bit AES-CCM as being solely for Bluetooth. If a GCM mode algorithm is selected, then the evaluator shall examine the TOE summary specification to confirm that it describes how the IV is generated and that the same IV is never reused to encrypt different plaintext pairs under the same key. The evaluator shall also confirm that for each invocation of GCM, the length of the plaintext is at most (232)-2 blocks. The following tests may require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products. The following tests are conditional based upon the selections made in the SFR. The evaluator shall perform the following test or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described. AES-CCM AES-CCM AES in CCM mode with non-repeating nonce, minimum size of 64 bits [selection:128 bits, 256 bits] [selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: ISO/IEC 19772:2020 (Clause 7), NIST SP 800-38C] [CCM] To test the TOE’s implementation of AES-CCM authenticated encryption functionality the evaluator shall perform the Algorithm Functional Tests described below using the following input parameters: Key Size [128,256] bits Associated data size [0-65536] bits in increments of 8 Payload size [0-256] bits in increments of 8 IV/Nonce size [64-104] bits in increments of 8 Tag size [32-128] bits in increments of 16 Algorithm Functional Tests Unless otherwise specified, the following tests should use random data, a tag size of 128 bits, IV/Nonce size of 104 bits, payload size of 256 bits, and associated data size of 256 bits. If any of these values are not supported, any supported value may be used. The evaluator shall compare the output from each test case against results generated by a known-good implementation with the same input parameters. Variable Associated Data Test For each claimed key size, and for each supported associated data size from 0 through 256 bits in increments of 8 bits, the TOE must be tested by encrypting 10 test cases using all random data. In addition, for each key size, the TOE must be tested by encrypting 10 cases with associated data lengths of 65536 bits, if supported. Variable Payload Test For each claimed key size, and for each supported payload size from 0 through 256 bits in increments of 8 bits, the TOE must be tested by encrypting 10 test cases using all random data. Variable Nonce Test For each claimed key size, and for each supported IV/Nonce size from 64 through 104 bits in increments of 8 bits, the TOE must be tested by encrypting 10 test cases using all random data. Variable Tag Test For each claimed key size, and for each supported tag size from 32 through 128 bits in increments of 16 bits, the TOE must be tested by encrypting 10 test cases using all random data. Decryption Verification Test For each claimed key size, for each supported associated data size from 0 through 256 bits in increments of 8 bits, for each supported payload size from 0 through 256 bits in increments of 8 bits, for each supported IV/Nonce size from 64 through 104 bits in increments of 8 bits, and for each supported tag size from 32 through 128 bits in increments of 16 bits, the TOE must be tested by decrypting 10 test cases using all random data. AES-GCM AES-GCM AES in GCM mode with non-repeating IVs using [selection: deterministic, DRBG-based] IV construction; the tag must be of length [selection: 96, 104, 112, 120, or 128] bits. 256 bits [selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: ISO/IEC 19772:2020 (Clause 10), NIST SP 800-38D] [GCM] To test the TOE’s implementation of AES-GCM authenticated encryption functionality the evaluator shall perform the Encryption Algorithm Functional Tests and Decryption Algorithm Functional Tests as described below using the following input parameters: Key Size [256] bits Associated data size [0-65536] bits Payload size [0-65536] bits IV size [96] bits Tag size [96, 104, 112, 120, 128] bits Encryption Algorithm Functional Tests The evaluator shall generate 15 test cases using random data for each combination of the above parameters as follows: Each claimed key size, Each supported tag size, Four supported non-zero payload sizes, such that two are multiples of 128 bits and two are not multiples of 128 bits, Four supported non-zero associated data sizes, such that two are multiples of 128 bits and two are not multiples of 128 bits, and An associated data size of zero, if supported. Note that the IV size is always 96 bits. The evaluator shall compare the output from each test case against results generated by a known- good implementation with the same input parameters. Decryption Algorithm Functional Tests The evaluator shall test the authenticated decrypt functionality of AES-GCM by supplying 15 test cases for the supported combinations of the parameters as described above. For each parameter combination the evaluator shall introduce an error into either the Ciphertext or the Tag such that approximately half of the cases are correct and half the cases contain errors.

The TSF shall perform [<h:i>cryptographic hashing</h:i>] in accordance with a specified cryptographic algorithm <selectables> <selectable id="sel-cop1-sha256">SHA-256</selectable> <selectable id="sel-cop1-sha384">SHA-384</selectable> <selectable id="sel-cop1-sha512">SHA-512</selectable> <selectable id="sel-cop1-sha3-384">SHA3-384</selectable> <selectable id="sel-cop1-sha3-512">SHA3-512</selectable> </selectables> that meet the following: <selectables> <selectable>ISO/IEC 10118-3:2018 [SHA, SHA3]</selectable> <selectable>FIPS PUB 180-4 [SHA]</selectable> <selectable>FIPS PUB 202 [SHA3]</selectable> </selectables>. In accordance with CNSA: SHA-3 hashes may be used only for internal hardware functionality such as boot integrity checks, and SHA-256 is permitted only for use as a PRF or MAC as part of a key derivation function, or as part of LMS or XMSS. The hash selection should be consistent with the overall strength of the algorithm used for signature generation. For example, the TOE should choose SHA-384 for 3072-bit RSA, 4096-bit RSA, or ECC with P-384; and SHA-512 for ECC with P-521. The evaluator shall examine the TSS to verify that if SHA-256 is selected, that it is being used only as a PRF or MAC step in a key derivation function or as part of LMS, and not as a hash algorithm. The following tests may require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products. The following tests are conditional, based on the selections made in the SFR. The evaluator shall perform the following tests or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described. SHA-256, SHA-384, SHA-512 To test the TOE’s ability to generate hash digests using SHA2, the evaluator shall perform the Algorithm Functional Test, Monte Carlo Test, and Large Data Test for each claimed SHA2 algorithm. Algorithm Functional Test The evaluator shall generate a number of test cases equal to the block size of the hash (512 for SHA2-256; 1024 for the other SHA2 algorithms). Each test case is to consist of random data of a random length between 0 and 65536 bits, or the largest size supported. Monte Carlo Test Monte Carlo tests begin with a single seed and run 100 iterations of the chained computation. For the standard Monte Carlo test the message hashed is always three times the length of the initial seed. For j = 0 to 99 A = B = C = SEED For i = 0 to 999 MSG = A || B || C MD = SHA(MSG) A = B B = C C = MD Output MD SEED = MD For the alternate version of the Monte Carlo Test, the hashed message is always the same length as the seed. INITIAL_SEED_LENGTH = LEN(SEED) For j = 0 to 99 A = B = C = SEED For i = 0 to 999 MSG = A || B || C if LEN(MSG) >= INITIAL_SEED_LENGTH: MSG = leftmost INITIAL_SEED_LENGTH bits of MSG else: MSG = MSG || INITIAL_SEED_LENGTH - LEN(MSG) 0 bits MD = SHA(MSG) A = B B = C C = MD Output MD SEED = MD The evaluator shall compare the output against results generated by a known good implementation with the same input. Large Data Test The implementation must be tested against one test case each on large data messages of 1GB, 2GB, 4GB, and 8GB of data as supported. The data need not be random. It may, for example, consist of a repeated pattern of 64 bits. The evaluator shall compare the output against results generated by a known good implementation with the same input. SHA3-384, SHA3-512 To test the TOE’s ability to generate hash digests using SHA3 the evaluator shall perform the Algorithm Functional Test, Monte Carlo Test, and Large Data Tests for each claimed SHA3 algorithm. Algorithm Functional Test Generate a test case consisting of random data for every message length from 0 bits (or the smallest supported message size) to rate bits, where rate equals 832 for SHA3-384 and 576 for SHA3-512. Additionally, generate tests cases of random data for messages of every multiple of (rate+1) bits starting at length rate, and continuing until 65535 is exceeded. The evaluator shall compare the output against results generated by a known good implementation with the same input. Monte Carlo Test Monte Carlo tests begin with a single seed and run 100 iterations of the chained computation. For this Monte Carlo Test, the hashed message is always the same length as the seed. MD[0] = SEED INITIAL_SEED_LENGTH = LEN(SEED) For 100 iterations For i = 1 to 1000 MSG = MD[i-1]; if LEN(MSG) >= INITIAL_SEED_LENGTH: MSG = leftmost INITIAL_SEED_LENGTH bits of MSG else: MSG = MSG || INITIAL_SEED_LENGTH - LEN(MSG) 0 bits MD[i] = SHA3(MSG) MD[0] = MD[1000] Output MD[0] The evaluator shall compare the output against results generated by a known good implementation with the same input. Large Data Test The implementation must be tested against one test case each on large data messages of 1GB, 2GB, 4GB, and 8GB of data as supported. The data need not be random. It may, for example, consist of a repeated pattern of 64 bits. The evaluator shall compare the output against results generated by a known good implementation with the same input.

The TSF shall perform [<h:i>keyed hash message authentication</h:i>] in accordance with a specified cryptographic algorithm <selectables> <tabularize id="fcs-cop-keyedhash-sels" title="Allowable choices for FCS_COP.1/KeyedHash"> <selectcol>Keyed Hash Algorithm</selectcol> <reqtext>and cryptographic key sizes</reqtext> <selectcol>Cryptographic Key Sizes</selectcol> <reqtext>that meet the following:</reqtext> <selectcol>List of Standards</selectcol> <reqtext>.<h:p/><h:p/><xref to="fcs-cop-keyedhash-sels"/> provides the allowable choices for completion of the selection operations of FCS_COP.1/KeyedHash.</reqtext> </tabularize> <selectable id="sel-fcs-cop-keyedhash-hmac-sha-256"> <col>HMAC-SHA-256</col> <col>256 bits</col> <col><selectables> <selectable><h:i>ISO/IEC 9797-2:2021 (Section 7 “MAC Algorithm 2”)</h:i></selectable> <selectable><h:i>FIPS PUB 198-1</h:i></selectable></selectables> </col> </selectable> <selectable id="sel-fcs-cop-keyedhash-hmac-sha-384"> <col>HMAC-SHA-384</col> <col><selectables> <selectable><h:i>384 (ISO, FIPS)</h:i></selectable> <selectable><h:i>256 (FIPS)</h:i></selectable></selectables> bits </col> <col><selectables> <selectable><h:i>ISO/IEC 9797-2:2021 (Section 7 “MAC Algorithm 2”)</h:i></selectable> <selectable><h:i>FIPS PUB 198-1</h:i></selectable></selectables> </col> </selectable> <selectable id="sel-fcs-cop-keyedhash-hmac-sha-512"> <col>HMAC-SHA-512</col> <col><selectables> <selectable><h:i>512 (ISO, FIPS)</h:i></selectable> <selectable><h:i>384 (FIPS)</h:i></selectable> <selectable><h:i>256 (FIPS)</h:i></selectable></selectables> bits </col> <col><selectables> <selectable><h:i>ISO/IEC 9797-2:2021 (Section 7 “MAC Algorithm 2”)</h:i></selectable> <selectable><h:i>FIPS PUB 198-1</h:i></selectable></selectables> </col> </selectable> </selectables> The intent of this requirement is to specify the keyed-hash message authentication function used for key establishment purposes for the various cryptographic protocols used by the OS (e.g., trusted channel). The hash selection must support the message digest size selection. The hash selection should be consistent with the overall strength of the algorithm used for FCS_COP.1/Hash. In accordance with CNSA, HMAC-SHA-256 may be used only as a PRF or MAC step in a key derivation function. The evaluator shall examine the TSS to ensure that the size of the key is sufficient for the desired security strength of the output. The evaluator shall examine the TSS to verify that if HMAC-SHA-256 is selected, that it is being used only as a PRF or MAC step in a key derivation function. The following tests are conditional based on the selections made in the SFR. The evaluator shall perform the following tests or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described. HMAC HMAC-SHA-256 256 bits [selection: ISO/IEC 9797-2:2021 (Section 7 “MAC Algorithm 2”), FIPS PUB 198-1] HMAC-SHA-384 [selection: (ISO, FIPS) 384, (FIPS) 256] bits [selection: ISO/IEC 9797-2:2021 (Section 7 “MAC Algorithm 2”), FIPS PUB 198-1] HMAC-SHA-512 [selection: (ISO, FIPS) 512, (FIPS) 384, 256] bits [selection: ISO/IEC 9797-2:2021 (Section 7 “MAC Algorithm 2”), FIPS PUB 198-1] To test the TOE’s ability to generate keyed hashes using HMAC the evaluator shall perform the Algorithm Functional Test for each combination of claimed HMAC algorithm the following parameters: Hash function [SHA-256, SHA-384, SHA-512] Key length [8-65536] bits by 8s MAC length [32-[digest size of hash function (256, 384, 512)]] bits Algorithm Functional Test For each supported Hash function the evaluator shall generate 150 test cases using random input messages of 128 bits, random supported key lengths, random keys, and random supported MAC lengths such that across the 150 test cases: The key length includes the minimum, the maximum, a key length equal to the block size, and key lengths that are both larger and smaller than the block size. The MAC size includes the minimum, the maximum, and two other random values. The evaluator shall compare the output against results generated by a known good implementation with the same input.

The TSF shall perform [<h:i>key encapsulation</h:i>] in accordance with a specified cryptographic algorithm <selectables> <tabularize id="fcs-cop-keyencap-sels" title="Allowable choices for FCS_COP.1/KeyEncap"> <textcol>Identifier</textcol> <reqtext/> <selectcol>Cryptographic Algorithm</selectcol> <reqtext>and cryptographic key sizes</reqtext> <selectcol>Cryptographic Key Sizes</selectcol> <reqtext>that meet the following:</reqtext> <selectcol>List of Standards</selectcol> <reqtext>.<h:p/><h:p/><xref to="fcs-cop-keyencap-sels"/> provides the allowable choices for completion of the selection operations of FCS_COP.1/KeyEncap.</reqtext> </tabularize> <selectable id="sel-fcs-cop-keyencap-mlkem"> <col>ML-KEM</col> <col>ML-KEM</col> <col>Parameter set = ML-KEM-1024</col> <col>NIST FIPS 203</col> </selectable> </selectables> This SFR is claimed when "key encapsulation" is selected in FCS_CKM.2.1. For this PP, the only anticipated use of key encapsulation is the use of ML-KEM as part of key establishment for trusted communications. The evaluator shall ensure that the TSS documents that the selection of the key size is sufficient for the security strength of the key encapsulated. The evaluator shall examine the TSS to verify that any one-time values such as nonces or masks are constructed and used in accordance with the relevant standards. The following test may require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products. The following tests are conditional based upon the selections made in the SFR. The evaluator shall perform the following test or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described. ML-KEM Key Encapsulation ML-KEM ML-KEM Parameter set = ML-KEM-1024 NIST FIPS PUB 203 To test the TOE’s implementation of ML-KEM key encapsulation/decapsulation, the evaluator shall perform the Encapsulation Test and the Decapsulation Test using the following input parameters: Encapsulation Parameters: Parameter set [ML-KEM-1024] Previously generated encapsulation key (ek) Random value (m) [32 bytes] Decapsulation Parameters: Parameter set [ML-KEM-1024] Previously generated decapsulation key (dk) Previously generated ciphertext (c) [32 bytes] Encapsulation Test For each supported parameter set the evaluator shall generate 25 test cases consisting of an encapsulation key ek and random value m. For each test case the valuator shall require the implementation under test to generate the corresponding shared secret k and ciphertext c. To determine correctness, the evaluator shall compare the resulting values with those generated using a known-good implementation using the same inputs. Encapsulation Key Check (if supported) The evaluator shall generate 10 encapsulation keys such that: Five of the encapsulation keys are valid, and Five of the encapsulation keys are modified such that a value in the noisy linear system is encoded into the key as a value greater than Q. The evaluator shall invoke the TOE’s Encapsulation Key Check functionality to determine the validity of the 10 keys. The unmodified keys should be determined valid, and the modified keys should be determined invalid. Decapsulation Key Check (if supported) The evaluator shall generate 10 decapsulation keys such that: Five of the decapsulation keys are valid, and Five of the decapsulation keys are modified such that the concatenated values ek||H(ek) will no longer match by modifying H(ek) to be a different value. The evaluator shall invoke the TOE’s Decapsulation Key Check functionality to determine the validity of the 10 keys. The unmodified keys should be determined valid, and the modified keys should be determined invalid. Decapsulation Test For each supported parameter set the evaluator shall use a single previously generated decapsulation key dk and generate 10 test cases consisting of valid and invalid ciphertexts c. For each test case the evaluator shall require the implementation under test to generate the corresponding shared secret k whether or not the ciphertext is valid. To determine correctness, the evaluator shall compare the resulting values with those generated using a known-good implementation using the same inputs.

The TSF shall perform [<h:i>key wrapping</h:i>] in accordance with a specified cryptographic algorithm <selectables> <tabularize id="fcs-cop-kw-sels" title="Allowable choices for FCS_COP.1/KeyWrap"> <textcol>Identifier</textcol> <reqtext/> <selectcol>Cryptographic Algorithm</selectcol> <reqtext>and cryptographic key sizes</reqtext> <selectcol>Cryptographic Key Sizes</selectcol> <reqtext>that meet the following:</reqtext> <selectcol>List of Standards</selectcol> <reqtext>.<h:p/><h:p/><xref to="fcs-cop-kw-sels"/> provides the allowable choices for completion of the selection operations of FCS_COP.1/KeyWrap.</reqtext> </tabularize>  <selectable id="sel-fcs-cop-kw-aes-kw"> <col>AES-KW</col> <col>AES in KW mode</col> <col>256 bits</col> <col><selectables> <selectable>ISO/IEC 18033-3:2010 (Subclause 5.2)</selectable> <selectable>FIPS PUB 197</selectable></selectables> [AES]<h:p/> <selectables> <selectable>ISO/IEC 19772:2020 (clause 6)</selectable> <selectable>NIST SP 800-38F (Section 6.2)</selectable> </selectables> [KW mode]</col> </selectable>  <selectable id="sel-fcs-cop-kw-aes-kwp"> <col>AES-KWP</col> <col>AES in KWP mode</col> <col>256 bits</col> <col><selectables> <selectable>ISO/IEC 18033-3:2010 (Subclause 5.2)</selectable> <selectable>FIPS PUB 197</selectable></selectables> [AES]<h:p/> NIST SP 800-38F (Section 6.3) [KWP mode]</col> </selectable> <selectable id="sel-fcs-cop-kw-aes-ccm"> <col>AES-CCM</col> <col>AES in CCM mode with unpredictable, non-repeating nonce, minimum size of 64 bits</col> <col>256 bits</col> <col><selectables> <selectable>ISO/IEC 18033-3:2010 (Subclause 5.2)</selectable> <selectable>FIPS PUB 197</selectable></selectables> [AES]<h:p/> <selectables> <selectable>ISO/IEC 19772:2020 (Clause 7)</selectable> <selectable>NIST SP 800-38C</selectable></selectables> [CCM] </col></selectable> <selectable id="sel-fcs-cop-kw-aes-gcm"> <col>AES-GCM</col> <col>AES in GCM mode with non-repeating IVs using <selectables> <selectable>deterministic</selectable> <selectable>DRBG-based</selectable></selectables>, IV construction; the tag must be of length <selectables> <selectable>96</selectable> <selectable>104</selectable> <selectable>112</selectable> <selectable>120</selectable> <selectable>128</selectable> </selectables> bits. </col> <col>256 bits</col> <col><selectables> <selectable>ISO/IEC 18033-3:2010 (Subclause 5.2)</selectable> <selectable>FIPS PUB 197</selectable></selectables> [AES]<h:p/> <selectables> <selectable>ISO/IEC 19772:2020 (Clause 10)</selectable> <selectable>NIST SP 800-38D</selectable></selectables> [GCM] </col></selectable> </selectables> NIST 800-57p1rev5 sec. 5.6.2 specifies that the size of key used to protect the key being transported should be at least the security strength of the key it is protecting. The evaluator shall ensure that the TSS documents that the selection of the key size is sufficient for the security strength of the key wrapped. The evaluator shall examine the TSS to ensure that it describes the construction of any IVs, nonces, and MACs in conformance with the relevant specifications. For tests of AES-GCM and AES-CCM, see testing for FCS_COP.1/AEAD. The following tests are conditional based upon the selections made in the SFR. The evaluator shall perform the following test or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described. AES-KW AES-KW AES in KW mode 256 bits [selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: ISO/IEC 19772:2020 (clause 6), NIST SP 800-38F (Section 6.2)] [KW mode] To test the TOE’s ability to wrap keys using AES in Key Wrap mode the evaluator shall perform the Algorithm Functional Tests using the following input parameters: Key size [256] bits Keyword cipher type [cipher, inverse] Payload sizes [128-4096] bits by 64s Algorithm Functional Test The evaluator shall generate 100 encryption test cases using random data for each combination of claimed key size, keyword cipher type, and six supported payload sizes such that the payload sizes include the minimum, the maximum, two that are divisible by 128, and two that are not divisible by 128. The results shall be compared with those generated by a known-good implementation using the same inputs. The evaluator shall generate 100 decryption test cases using the same parameters as above, but with 20 of each 100 test cases having modified ciphertext to produce an incorrect result. To determine correctness, the evaluator shall confirm that the results correspond as expected for both the modified and unmodified values. AES-KWP AES-KWP AES in KWP mode 256 bits [selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] NIST SP 800-38F (Section 6.3) [KWP mode] To test the TOE’s ability to wrap keys using AES in Key Wrap with Padding mode with padding the evaluator shall perform the Algorithm Functional Tests using the following input parameters: Key size [256] bits Keyword cipher type [cipher, inverse] Payload sizes [8-4096] bits by 8s Algorithm Functional Test The evaluator shall generate 100 encryption test cases using random data for each combination of claimed key size, keyword cipher type, and six supported payload sizes such that the payload sizes include the minimum, the maximum, two that are divisible by 128, and two that are not divisible by 128. The results shall be compared with those generated by a known-good implementation using the same inputs. The evaluator shall generate 100 decryption test cases using the same parameters as above, but with 20 of each 100 test cases having modified ciphertext to produce an incorrect result. To determine correctness, the evaluator shall confirm that the results correspond as expected for both the modified and unmodified values.

The TSF shall perform [<h:i>digital signature generation</h:i>] in accordance with a specified cryptographic algorithm <selectables> <tabularize id="fcs-cop-siggen-sels" title="Allowable choices for FCS_COP.1/SigGen"> <textcol>Identifier</textcol> <reqtext/> <selectcol>Cryptographic Algorithm</selectcol> <reqtext>and cryptographic key sizes</reqtext> <selectcol>Cryptographic Key Sizes</selectcol> <reqtext>that meet the following:</reqtext> <selectcol>List of Standards</selectcol> <reqtext>.<h:p/><h:p/><xref to="fcs-cop-siggen-sels"/> provides the allowable choices for completion of the selection operations in FCS_COP.1/SigGen.<h:p/></reqtext> </tabularize> <selectable id="sel-fcs-cop-siggen-rsa-pkcs"> <col>RSA-PKCS</col> <col>RSASSA-PKCS1-v1_5</col> <col>Modulus of size <selectables> <selectable><h:i>3072</h:i></selectable> <selectable><h:i>4096</h:i></selectable> <selectable><h:i>6144</h:i></selectable> <selectable><h:i>8192</h:i></selectable> </selectables> bits, hash <selectables> <selectable><h:i>SHA-384</h:i></selectable> <selectable><h:i>SHA-512</h:i></selectable> </selectables></col> <col> RFC 8017 (Section 8.2) [PKCS #1 v2.2]<h:p/> FIPS PUB 186-5 (Section 5.4) [RSASSA-PKCS1-v1_5] </col> </selectable> <selectable id="sel-fcs-cop-siggen-rsa-pss"> <col>RSA-PSS</col> <col>RSASSA-PSS</col> <col>Modulus of size <selectables> <selectable><h:i>3072</h:i></selectable> <selectable><h:i>4096</h:i></selectable> <selectable><h:i>6144</h:i></selectable> <selectable><h:i>8192</h:i></selectable> </selectables> bits, hash <selectables> <selectable><h:i>SHA-384</h:i></selectable> <selectable><h:i>SHA-512</h:i></selectable> </selectables>, Salt Length (<h:i>sLen</h:i>) such that <assignable><h:i>0 ≤ <h:i>sLen</h:i> ≤ <h:i>hLen</h:i> (Hash Output Length)</h:i></assignable> and Mask Generation Function = MGF1</col> <col> RFC 8017 (Section 8.1) [PKCS#1 v2.2]<h:p/> FIPS PUB 186-5 (Section 5.4) [RSASSA-PSS] </col> </selectable> <selectable id="sel-fcs-cop-siggen-ecdsa"> <col>ECDSA</col> <col>ECDSA</col> <col>Elliptic Curve <selectables> <selectable><h:i>P-384</h:i></selectable> <selectable><h:i>P-521</h:i></selectable> </selectables>, per-message secret number generation <selectables> <selectable><h:i>extra random bits</h:i></selectable> <selectable><h:i>rejection sampling</h:i></selectable> <selectable><h:i>deterministic</h:i></selectable> </selectables> and hash function using <selectables> <selectable><h:i>SHA-384</h:i></selectable> <selectable><h:i>SHA-512</h:i></selectable> </selectables></col> <col><selectables> <selectable><h:i>ISO/IEC 14888-3:2018 (Subclause 6.6)</h:i></selectable> <selectable><h:i>FIPS PUB 186-5 (Sections 6.3.1, 6.4.1</h:i></selectable> </selectables>[ECDSA]<h:p/> NIST SP-800 186 (Section 4) [NIST Curves] </col> </selectable>  <selectable id="sel-fcs-cop-siggen-lms"> <col>LMS</col> <col>LMS</col> <col>Private key size = <selectables> <selectable>192 bits with <selectables> <selectable>SHA-256/192</selectable> <selectable>SHAKE256/192</selectable> </selectables></selectable> <selectable>256 bits with <selectables> <selectable>SHA-256</selectable> <selectable>SHAKE256</selectable> </selectables></selectable> </selectables><h:p/> Winternitz parameter = <selectables> <selectable>1</selectable> <selectable>2</selectable> <selectable>4</selectable> <selectable>8</selectable></selectables><h:p/> Tree height = <selectables> <selectable>5</selectable> <selectable>10</selectable> <selectable>15</selectable> <selectable>20</selectable> <selectable>25</selectable></selectables> </col> <col>RFC 8554 [LMS]<h:p/> NIST SP 800-208 [parameters] </col> </selectable>  <selectable id="sel-fcs-cop-siggen-mldsa"> <col>ML-DSA</col> <col>ML-DSA Signature Generation</col> <col>Parameter set = ML-DSA-87</col> <col>NIST FIPS 204 (Section 5.2)</col> </selectable>  <selectable id="sel-fcs-cop-siggen-xmss"> <col>XMSS</col> <col>XMSS</col> <col>Private key size = <selectables> <selectable>192 bits with <selectables> <selectable>SHA-256/192</selectable> <selectable>SHAKE256/192</selectable> </selectables></selectable> <selectable>256 bits with <selectables> <selectable>SHA-256</selectable> <selectable>SHAKE256</selectable> </selectables></selectable> </selectables><h:p/> Tree height = <selectables> <selectable>10</selectable> <selectable>16</selectable> <selectable>20</selectable> </selectables> </col> <col>RFC 8391 [XMSS]<h:p/> NIST SP 800-208 [parameters] </col> </selectable> </selectables> The evaluator shall examine the TSS and verify that any hash function is the appropriate security strength for the signing algorithm. The evaluator shall examine the TSS to verify that any one-time values such as nonces or masks are constructed and used in accordance with the relevant standards. The evaluator shall examine the TSS to verify that the TOE has appropriate measures in place to ensure that hash-based signature algorithms do not reuse private keys. The following tests are conditional based on the selections made in the SFR. The evaluator shall perform the following tests or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described. RSA-PKCS Signature Generation RSA-PKCS RSASSA-PKCS1-v1_5 Modulus of size [selection: 3072, 4096, 6144, 8192] bits, hash [selection: SHA-384, SHA-512] RFC 8017 (Section 8.2) [PKCS #1 v2.2] NIST FIPS PUB 186-5 (Section 5.4) [RSASSA-PKCS1-v1_5] To test the TOE’s ability to perform RSA Digital Signature Generation using PKCS1-v1_5 signature type, the evaluator shall perform the Generated Data Test using the following input parameters: Modulus size [3072, 4096, 6144, 8192] bits Hash algorithm [SHA-384, SHA-512] Generated Data Test For each supported combination of the above parameters, the evaluator shall cause the TOE to generate three test cases using random data. The evaluator shall compare the results against those from a known good implementation. RSA-PSS Signature Generation RSA-PSS RSASSA-PSS Modulus of size [selection: 3072, 4096, 6144, 8192] bits, hash [selection: SHA-384, SHA-512], Salt Length (sLen) such that [assignment: 0 ≤ sLen ≤ hLen (Hash Output Length)] and Mask Generation Function = MGF1 RFC 8017 (Section 8.2) [PKCS #1 v2.2] NIST FIPS PUB 186-5 (Section 5.4) [RSASSA-PSS] To test the TOE’s ability to perform RSA Digital Signature Generation using PSS signature type, the evaluator shall perform the Generated Data Test using the following input parameters: Modulus size [3072, 4096, 6144, 8192] bits Hash algorithm [SHA-384, SHA-512] Salt length [Fixed based on implementation] Mask function [MGF1] Generated Data Test For each supported combination of the above parameters, the evaluator shall cause the TOE to generate three test cases using random data. The evaluator shall compare the results against those from a known good implementation. ECDSA Signature Generation ECDSA ECDSA Elliptic Curve [selection: P-384, P-521], per-message secret number generation [selection: extra random bits, rejection sampling, deterministic] and hash function using [selection: SHA-384, SHA-512] [selection: ISO/IEC 14888-3:2018 (Subclause 6.6), NIST FIPS PUB 186-5 (Sections 6.3.1, 6.4.1] [ECDSA] NIST SP-800 186 (Section 4) [NIST Curves] To test the TOE’s ability to perform ECDSA Digital Signature Generation using extra random bits or rejection sampling for secret number generation, the evaluator shall perform the Algorithm Functional Test using the following input parameters: Elliptic Curve [P-384, P-521] Hash algorithm [SHA-384, SHA-512] To test the TOE’s ability to perform ECDSA Digital Signature Generation using deterministic secret number generation, the evaluator shall perform the Algorithm Functional Test using the following input parameters: Elliptic Curve [P-384, P-521] Hash algorithm [SHA-384, SHA-512] Algorithm Functional Test For each supported combination of the above parameters, the evaluator shall cause the TOE to generate 10 test cases using random data. The evaluator shall compare the results against those from a known good implementation. LMS Signature Generation LMS LMS Private key size = [selection: 192 bits with [selection: SHA256/192, SHAKE256/192], 256 bits with [selection: SHA-256, SHAKE256]], Winternitz parameter = [selection: 1, 2, 4, 8], and tree height = [selection: 5, 10, 15, 20, 25] RFC 8554 [LMS] NIST SP 800-208 [parameters] To test the TOE’s ability to generate cryptographic digital signature using LMS, the evaluator shall perform the Algorithm Functional Test using the following input parameters: Hash algorithm [SHA-256/192, SHAKE256/192, SHA-256, SHAKE256] Winternitz [1, 2, 4, 8] Tree height [5, 10, 15, 20, 25] Algorithm Functional Test For each supported combination of the above parameters, the evaluator shall generate 10 signatures. The evaluator shall verify the correctness of the implementation by comparing values generated by the TOE with those generated by a known good implementation using the same input parameters. ML-DSA Signature Generation ML-DSA ML-DSA SigGen Parameter set = ML-DSA-87 NIST FIPS PUB 204 (Section 5.2) To test the TOE’s ability to generate digital signatures using ML-DSA, the evaluator shall perform the Algorithm Functional Test using the following input parameters: Parameter set [ML-DSA-87] Seed [32 random bytes] (for non-deterministic signature testing), or Seed [32 zero bytes] (for deterministic signature testing) Message to sign [8-65535] bytes Mu value (if generated externally) Previously generated private key (sk) Context (for external interface testing) Algorithm Functional Test For each combination of supported parameter set and capabilities, the evaluator shall require the implementation under test to generate 15 signatures pairs using 15 different randomly generated 32-byte seed values. To determine correctness, the evaluator shall compare the resulting key pairs with those generated using a known good implementation using the same inputs. Known Answer Test for Rejection Cases For each supported parameter set, the evaluator shall cause the TOE to generate signatures using the data below and a deterministic seed of all 0’s. Correctness is determined by comparing the hash of the resulting signature with the hash in the fourth row for each corresponding test case below. The test values are defined as follows: Seed is the seed to generate the key pair (pk, sk) Hash of keys is computed by SHA-256(pk||sk) Message is the message to be signed Hash of sig is computed by SHA-256(sig) ML-DSA-87 Test Cases for Rejection Cases Test case 87-RC-01 Seed: E4F5AFCF697E0EC3C1BDEB66FAA903221E803902F9C3F716E1056A63D77DC250 Hash of Keys: 61618E8DDA6998072C8EB36974E03880D741CAF0BD523356DFC161E7C9E63934 Message: F4F1C05004D5B946F69EAFE104C4020519086ADDB9582A20FDE887D13DFC36B1 Hash of sig: B584E38FA442FC3C81A147D4BDBF058D73C822CAF5CA4C06B0110867F60A8001 Test case 87-RC-02 Seed: 8B828D871254D6C57384A8E7025AA3F7160CAD1D2C754499DF3844426062C3DD Hash of Keys: BB64481317D6C0DBAD20C0C7EF11078AD54E5D574F4A07652115A95F77C655FA Message: 0F9409C5A4930C25B83FC5B77FDB5BB49C75372DE724D9C1A77DB700CF0CF154 Hash of sig: F86B49BE9DEB2B209BDEB4E922E5939E92D38E562C44BB09AFBD67323C345192 Test case 87-RC-03 Seed: E693D282CACB8CE65FD4D108DA7A373F097F0AA9713550BE242AAD5BD3E2E452 Hash of Keys: B0BEAF56713A69BD4AB2CBEE006FA5001E7B41F3AE541E05F088933AA0CC78DF Message: 24DABB9D57ADEBD560ED65D9451C5106D437061708F849BA53F3543CDF9AAAE0 Hash of sig: DBF65CEFF9F96A74AAF6F3AB27B043231BE6AA04FBA2EEC987A24A00BDD6A08E Test case 87-RC-04 Seed: 4002163EB8EED01A8E0919BA8C07D291341EDCAE25B02B9779A2CFFE50561AF0 Hash of Keys: FED1BE685C20ECB322FC40D41DEE7E0E98D0409FBF989CAE71B8AD2D58AD645E Message: EE316BB5EBED53325B4A55571C60657B53E353B51B831F4A0BBB28107EBA4BA8 Hash of sig: 3BE9B5545FDCED92547B3409C83B3312CCB5792A8EC3A4DA63BA692C79BEF17C Test case 87-RC-05 Seed: 9C7AD524F65854C27E565BCEDF8E86D650F13A40D0448F9AE10C05F10F777120 Hash of Keys: 0EA872CA5A4BEA94F4E8EF7ED31800727899A51059FDEE111E5CB15F0233B534 Message: CE09831294AA96CAF684B9E667947B021C57B24C138EC7D4DA270694C82F2E08 Hash of sig: 3B9526CEE6587F2418BFE603ADB0F7DF0D69EBA31C9F9F005C60C993945EBD33 Test case 87-RC-06 Seed: 2EB7676D4A28700DA7772A7A035EB495CAA6F842352A74824EF5FD891BC38B2A Hash of Keys: D5B73703A1DDC5BCB0D14AE39B193A25D6ADA6535827973181ADB0BE70435A5B Message: C2B3A0AC483A5517682285C205974B2A506946448A8F7D3E1934C155EFDFE922 Hash of sig: 375D598704B722C8A1FEF1626FD7738A532C06329AA4217357460E3B729660F8 Test case 87-RC-07 Seed: E4E80CCE8B26DF1B02B99949851EE2F907FE4F0CC34790352C76D5D91634D073 Hash of Keys: 84B7E61684A12698400B09EA332EA3C4FBCFA47FE37FD6AE725CBC5FA8A99D3F Message: 89E6AB43C9CB1CC59C3986D53217A558357E62102A26F666F2B64CD1DBB7A536 Hash of sig: 7C4AABD163CAEF8F6EBFDA3E3EEBC0A9604675B0E991ABAFD284F1AE8BA07B2A Test case 87-RC-08 Seed: 5787262B803499223D4E5A8C1EE572E89F7A69B359B3F8505355B0BDEAB95E5C Hash of Keys: 85AE1DE605A7B479C02730BF4B7DD6D0FD8FFE5C980893CA6DAD00BD8BD1CE68 Message: D3230C4E061964BBFB17702432D5D36FC1EB3D1068F8CCAA84044776E3B5CC55 Hash of sig: D3ABE460EE2DD9595F413CFE2780A319E4E4DFD6592995298A7AB0B82A5E2815 Test case 87-RC-09 Seed: CE099B99330537DD153052243FC32ACAD509A126AB982410258858567D410D79 Hash of Keys: E04A9F15EDF8F078EB336CE624249EF2A8EDF2CDBF6A8276E9F5E92ED9B0BAE8 Message: 0035931762665F561A1B22176567E3B10FDE2441521F77030733A8E39312EEEE Hash of sig: 3EEF413CB5EB179896ECA172D0DBFB9B251545DC561D61580BD5BBC8B6D734E1 Test case 87-RC-10 Seed: FC8F2929878CBD81E1CCC23913F290380120C043A4A8A251AEEBF09705B8E590 Hash of Keys: 7E2ECCA86F532E8E8092FEBB6E0007F92E7909AD2BCBE2E02AB375DAC9969E5E Message: D3C28875D2671C0EF23BFDC8869E8ECF8868D3F0561C3134D254F7479D0CE0E5 Hash of sig: EB69A908EDCC04320A0B61AD57E21B044465F2037698636B64229CF2DB259789 XMSS Signature Generation XMSS XMSS Private key size = [selection: 192 bits with [selection: SHA256/192, SHAKE256/192], 256 bits with [selection: SHA-256, SHAKE256]], and tree height = [selection: 10, 16, 20] RFC 8391 [XMSS] NIST SP 800-208 [parameters] To test the TOE’s ability to generate digital signatures using XMSS, the evaluator shall perform the XMSS Key Generation Test using the following input parameters: Hash algorithm [SHA-256/192, SHAKE256/192, SHA-256, SHAKE256] Tree height [10, 16, 20] XMSS Key Generation Test For each supported combination of the above parameters, the evaluator shall generate 10 signatures. The evaluator shall verify the correctness of the implementation by comparing values generated by the TOE with those generated by a known-good implementation using the same input parameters. Known Answer Test for Large Number of Rejection Cases (Total Rejection Count) For each supported parameter set, the evaluator shall cause the TOE to generate signatures using the data below and a deterministic seed of all 0’s. Correctness is determined by comparing the hash of the resulting signature with the hash in the fourth row of the corresponding test case below. ML-DSA-87 Test Cases for Total Rejection Count Test case 87-LN-01 Seed: 98B6298051D92BF37293C93C97370747BF527B87B71F6C4264182F45155ADE4C Hash of Keys: 04A135B5C9B7020332C7B16E7108E8FF7FC1EAE1C23C5FA0B5D5CED0FEEE7424 Message: D7B0341269259083ABF3C8DC47559A19D57669B4486E0224F376DC43E577A3D8 Hash of sig: 58D72D76EC0FB65BFB9893C4479366B79DD7B8B7577E4291D13514FCC76C26DD Test case 87-LN-02 Seed: DFB5BDD90F58571DCA962426C623F13D046BBE814D183886AC90D143EAD725A7 Hash of Keys: 2B6AB8CFCCCC41F759CAF01932E9413F5DC6D949BC827F739866929683FB155E Message: 21005DB2B583CC826A9684BFFD0EE00AB97E0479FE4A1D266699337540145778 Hash of sig: C93EA34E00FFFFC3ECEA072D5FB038A83B5539CAF7B831AEDCFA785E50B3CA5E Test case 87-LN-03 Seed: 5AD414E0DD0EF2FE685F342871875FDF06F503717A86C3B3466565ADD2096417 Hash of Keys: BD9C2D52F3FC78DB17E682DA2E78947ECFC0898333838D60C892700B2B0DDA9F Message: 29139C279816B25F2D6BB52C8247D163544F7BA332C3CF63359B9E23FBC56515 Hash of sig: DB4BE2DE19FB40437BDB7E9B6578D665DB05B4E88C16907DF4546EBA9BE03AEA Test case 87-LN-04 Seed: 484DD2F406A4D15F49A91AD5FC3BDC1D0FF253622EB68F83D6E1C870D0E89E29 Hash of Keys: A719DC9A77C91C46295555C2353BA0CBEA513DA9A92A5C34D2E949EFF46A12D8 Message: 6AD6E959F0EA60126364FB7C95FA71133F246A9265A11B4965EE78AB0CB5AF0E Hash of sig: 5050D7A665074EC63D9F3966C1F01A1BFB18F9E83AE0B09F838BC1E2342ED6F4 Test case 87-LN-05 Seed: B25C1816F82D59940D5CB829BAC364AAD013C4C16415CE1CF6DCC2F15199B391 Hash of Keys: ADBB2CD43F222640BD9FF4E61C80E63853E8DC1F759C581B7447C9C166EAA38E Message: 824E47322895BFFE37B6B4AFC41CF6115C07EEC0C24EB81076C87A1B01AE8617 Hash of sig: 667ADA46073BC69D64DC47BB9A76DD0D78302E7415D87D5E816B05FB95F9E84D Test case 87-LN-06 Seed: B2CE72B3560AF07E06465881F56ADA00262BA708D87B73F39E04E310F3B8A3E9 Hash of Keys: FD9C4AC53AE803242A62DF933B8E8BAD6CE5207AC4A73683B6D9383B5E70B17A Message: A1501CC84C917E0D2D7C27C2AC382220BD8FFFE807DB38E37A9E429EC2781911 Hash of sig: 779553B195E11558EE59EF3942F5F6B446A2144600D1F4F50B300C6C56504760 Test case 87-LN-07 Seed: AB01D0E591B7DDCD3C03395AED808FA2763C0A486D44119D621BE0FD0B022B25 Hash of Keys: 93B6ADE34F78A4ADB36B2F6D2C51DB793E659E1243E80488AE1C03B65125D6D7 Message: 8DE8122D89D15FE84A4C34F6B59B2C4B11F33B6A053154D199B634F557FDF5F6 Hash of sig: 0483045999A79B583F403DB96A736F0F0B24E2DFBC4E5CFA9B50E3D910786F07 Test case 87-LN-08 Seed: 15D60D3693762F82C9AC1DCB0576936651AC81D863842EDB91109C8EE83AE705 Hash of Keys: 2DF544E2E939AA717741C2437288FAEB308DEB8FF37A2652FAE34BAE8B84D779 Message: F05946A6113905C34163AEF2246FD69016CE24A7BA40F8E7E42EDAC2D0A44605 Hash of sig: F8383917AF79C8E540D2356AB05F08B465BF32DFEC444B787CE31BF48CC6C3DD Test case 87-LN-09 Seed: 21212285BED53B3411705DAF5F3BDDB6F0618EB571B36EE11A74053407A269F5 Hash of Keys: 737061155A9A03F11F9FEBBB940BED4DD54542C4A6212F89A5EB4EC2BE542782 Message: FFE38246BF3DEFD9CAD15CC17CEA511C067D582E04227B479E32F9197CF91482 Hash of sig: C4C12C58032052FB2D21F0C6A7388A63154FB85B74287D2859DE6C1C6F7F277B Test case 87-LN-10 Seed: A2744470587C71BA43EC26DC390CE3531978F315993C653E5D3EFD2849D5D9F1 Hash of Keys: B1BF37BFFB11531B6ADD697870D7DB2E2462D0A97A63F09C1D0038457C6D795A Message: 9831A830231A160B9847203341A5F30BF3E87A2A482AEEA6886315C92B5C4E4C Hash of sig: 46C669D2FEB643A38E54FF87B790CC33F44043A1B6B31DB9474D301328CA2A7F

The TSF shall perform [<h:i>digital signature verification</h:i>] in accordance with a specified cryptographic algorithm <selectables> <tabularize id="fcs-cop-sigver-sels" title="Allowable choices for FCS_COP.1/SigVer"> <textcol>Identifier</textcol> <reqtext/> <selectcol>Cryptographic Algorithm</selectcol> <reqtext>and cryptographic key sizes</reqtext> <selectcol>Cryptographic Key Sizes</selectcol> <reqtext>that meet the following:</reqtext> <selectcol>List of Standards</selectcol> <reqtext>.<h:p/><h:p/><xref to="fcs-cop-sigver-sels"/> provides the allowable choices for completion of the selection operations in FCS_COP.1/SigVer.<h:p/></reqtext> </tabularize> <selectable id="sel-fcs-cop-sigver-rsa-pkcs"> <col>RSA-PKCS</col> <col>RSASSA-PKCS1-v1_5</col> <col>Modulus of size <selectables> <selectable><h:i>3072</h:i></selectable> <selectable><h:i>4096</h:i></selectable> <selectable><h:i>6144</h:i></selectable> <selectable><h:i>8192</h:i></selectable> </selectables> bits and hash <selectables> <selectable><h:i>SHA-384</h:i></selectable> <selectable><h:i>SHA-512</h:i></selectable> </selectables></col> <col> RFC 8017 (Section 8.2) [PKCS #1 v2.2]<h:p/> FIPS PUB 186-5 (Section 5.4) [RSASSA-PKCS1-v1_5] </col> </selectable> <selectable id="sel-fcs-cop-sigver-rsa-pss"> <col>RSA-PSS</col> <col>RSASSA-PSS</col> <col>Modulus of size <selectables> <selectable><h:i>3072</h:i></selectable> <selectable><h:i>4096</h:i></selectable> <selectable><h:i>6144</h:i></selectable> <selectable><h:i>8192</h:i></selectable> </selectables> bits and hash <selectables> <selectable><h:i>SHA-384</h:i></selectable> <selectable><h:i>SHA-512</h:i></selectable> </selectables></col> <col> RFC 8017 (Section 8.1) [PKCS#1 v2.2]<h:p/> FIPS PUB 186-5 (Section 5.4) [RSASSA-PSS] </col> </selectable> <selectable id="sel-fcs-cop-sigver-ecdsa"> <col>ECDSA</col> <col>ECDSA</col> <col>Elliptic Curve <selectables> <selectable><h:i>P-384</h:i></selectable> <selectable><h:i>P-521</h:i></selectable> </selectables> using hash <selectables> <selectable><h:i>SHA-384</h:i></selectable> <selectable><h:i>SHA-512</h:i></selectable> </selectables></col> <col><selectables> <selectable><h:i>ISO/IEC 14888-3:2018 (Subclause 6.6)</h:i></selectable> <selectable><h:i>FIPS PUB 186-5 (Section 6.4.2)</h:i></selectable> </selectables>[ECDSA]<h:p/> NIST SP-800 186 (Section 4) [NIST Curves] </col> </selectable>  <selectable id="sel-fcs-cop-sigver-lms"> <col>LMS</col> <col>LMS</col> <col>Private key size = <selectables> <selectable><h:i>192 bits with </h:i><selectables> <selectable><h:i>SHA-256/192</h:i></selectable> <selectable><h:i>SHAKE256/192</h:i></selectable> </selectables></selectable> <selectable><h:i>256 bits with </h:i><selectables> <selectable><h:i>SHA-256</h:i></selectable> <selectable><h:i>SHAKE256</h:i></selectable> </selectables></selectable> </selectables><h:p/> Winternitz parameter = <selectables> <selectable><h:i>1</h:i></selectable> <selectable><h:i>2</h:i></selectable> <selectable><h:i>4</h:i></selectable> <selectable><h:i>8</h:i></selectable></selectables><h:p/> Tree height = <selectables> <selectable><h:i>5</h:i></selectable> <selectable><h:i>10</h:i></selectable> <selectable><h:i>15</h:i></selectable> <selectable><h:i>20</h:i></selectable> <selectable><h:i>25</h:i></selectable></selectables> </col> <col>RFC 8554 [LMS]<h:p/> NIST SP 800-208 [parameters] </col> </selectable>  <selectable id="sel-fcs-cop-sigver-xmss"> <col>XMSS</col> <col>XMSS</col> <col>Private key size = <selectables> <selectable><h:i>192 bits with </h:i><selectables> <selectable><h:i>SHA-256/192</h:i></selectable> <selectable><h:i>SHAKE256/192</h:i></selectable> </selectables></selectable> <selectable><h:i>256 bits with </h:i><selectables> <selectable><h:i>SHA-256</h:i></selectable> <selectable><h:i>SHAKE256</h:i></selectable> </selectables></selectable> </selectables><h:p/> Tree height = <selectables> <selectable><h:i>10</h:i></selectable> <selectable><h:i>16</h:i></selectable> <selectable><h:i>20</h:i></selectable> </selectables> </col> <col>RFC 8391 [XMSS]<h:p/> NIST SP 800-208 [parameters] </col> </selectable>  <selectable id="sel-fcs-cop-sigver-mldsa"> <col>ML-DSA</col> <col>ML-DSA Signature Verification</col> <col>Parameter set = ML-DSA-87</col> <col>NIST FIPS 204 (Section 5.3)</col> </selectable> </selectables> The evaluator shall examine the TSS to verify that any one-time values such as nonces or masks are constructed and used in accordance with the relevant standards. The following tests are conditional based on the selections made in the SFR. The evaluator shall perform the following tests or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described. RSA-PKCS Signature Verification RSA-PKCS RSASSA-PKCS1-v1_5 Modulus of size [selection: 3072, 4096, 6144, 8192] bits, hash [selection: SHA-384, SHA-512] RFC 8017 (Section 8.2) [PKCS #1 v2.2] NIST FIPS PUB 186-5 (Section 5.4) [RSASSA-PKCS1-v1_5] To test the TOE’s ability to perform RSA Digital Signature Verification using PKCS1-v1_5 signature type, the evaluator shall perform Generated Data Test using the following input parameters: Modulus size [3072, 4096, 6144, 8192] bits Hash algorithm [SHA-384, SHA-512] Generated Data Test For each supported combination of the above parameters, the evaluator shall cause the TOE to generate six test cases using a random message and its signature such that the test cases are modified as follows: One test case is left unmodified For one test case the Message is modified For one test case the Signature is modified For one test case the exponent (e) is modified For one test case the IR is moved For one test case the Trailer is moved The TOE must correctly verify the unmodified signatures and fail to verify the modified signatures. RSA-PSS Signature Verification RSA-PSS RSASSA-PSS Modulus of size [selection: 3072, 4096, 6144, 8192] bits, hash [selection: SHA-384, SHA-512] RFC 8017 (Section 8.2) [PKCS #1 v2.2] NIST FIPS PUB 186-5 (Section 5.4) [RSASSA-PSS] To test the TOE’s ability to perform RSA Digital Signature Verification using PSS signature type, the evaluator shall perform the Generated Data Test using the following input parameters: Modulus size [3072, 4096, 6144, 8192] bits Hash algorithm [SHA-384, SHA-512] Salt length [0-hash length] Mask function [MGF1] Generated Data Test For each supported combination of the above parameters, the evaluator shall cause the TOE to generate six test cases using random data such that the test cases are modified as follows: One test case is left unmodified For one test case the Message is modified For one test case the Signature is modified For one test case the exponent (e) is modified For one test case the IR is moved For one test case the Trailer is moved The TOE must correctly verify the unmodified signatures and fail to verify the modified signatures. ECDSA Signature Verification ECDSA ECDSA Elliptic Curve [selection: P-384, P-521] and hash function using [selection: SHA-384, SHA-512] [selection: ISO/IEC 14888-3:2018 (Subclause 6.6), NIST FIPS PUB 186-5 (Sections 6.3.1, 6.4.1] [ECDSA] NIST SP-800 186 (Section 4) [NIST Curves] To test the TOE’s ability to perform ECDSA Digital Signature Verification, the evaluator shall perform the Algorithm Functional Test using the following input parameters: Elliptic Curve [P-384, P-521] Hash algorithm [SHA-384, SHA-512] Algorithm Functional Test For each supported combination of the above parameters, the evaluator shall cause the TOE to generate test cases consisting of messages and signatures such that the 21 test cases are modified as follows: Three test cases are left unmodified For three test cases the Message is modified For three test cases the key is modified For three test cases the r value is modified For three test cases the s value is modified For three test cases the value r is zeroed For three test cases the value s is zeroed The TOE must correctly verify the unmodified signatures and fail to verify the modified signatures. LMS Signature Verification LMS LMS Private key size = [selection: 192 bits with [selection: SHA256/192, SHAKE256/192], 256 bits with [selection: SHA-256, SHAKE256]], Winternitz parameter = [selection: 1, 2, 4, 8], and tree height = [selection: 5, 10, 15, 20, 25] RFC 8554 [LMS] NIST SP 800-208 [parameters] To test the TOE’s ability to verify cryptographic digital signature using LMS, the evaluator shall perform the Algorithm Functional Test using the following input parameters: Hash algorithm [SHA-256/192, SHAKE256/192, SHA-256, SHAKE256] Winternitz [1, 2, 4, 8] Tree height [5, 10, 15, 20, 25] Algorithm Functional Test For each supported combination of the above parameters, the evaluator shall generate four test cases consisting of signed messages and keys, such that One test case is unmodified (i.e., correct) For one test case modify the message, i.e., the message is different For one test case modify the signature, i.e., signature is different For one test case modify the signature header so that it is a valid header for a different LMS parameter set. The TOE must correctly verify the unmodified test case and fail to verify the modified test cases. XMSS Signature Verification XMSS XMSS Private key size = [selection: 192 bits with [selection: SHA256/192, SHAKE256/192], 256 bits with [selection: SHA-256, SHAKE256]], and tree height = [selection: 10, 16, 20] RFC 8391 [XMSS] NIST SP 800-208 [parameters] To test the TOE’s ability to verify digital signatures using XMSS or XMSS MT, the evaluator shall perform the XMSS digital signature verification test using the following input parameters: Hash algorithm [SHA-256/192, SHAKE256/192, SHA-256, SHAKE256] Tree height [10, 16, 20] XMSS Digital Signature Verification Test For each supported combination of the above parameters, the evaluator shall generate four test cases consisting of signed messages and keys, such that One test case is unmodified (i.e., correct) For one test case modify the message, i.e., the message is different For one test case modify the signature, i.e., signature is different For one test case modify the signature header so that it is a valid header for a different XMSS parameter set The evaluator shall verify the correctness of the implementation by verifying that the TOE correctly verifies the unmodified test case and fails to verify the modified test cases. ML-DSA Signature Verification ML-DSA ML-DSA SigVer Parameter set = ML-DSA-87 NIST FIPS PUB 204 (Section 5.2) To test the TOE’s ability to validate digital signatures using ML-DSA, the evaluator shall perform the Algorithm Functional Test using the following input parameters: Parameter set [ML-DSA-87] Previously generated signed Message [8-65535] bytes Mu value (if generated externally) Context (for external interface testing) Previously generated public key (pk) Previously generated Signature Algorithm Functional Test For each combination of supported parameter set and capabilities, the evaluator shall require the implementation under test to validate 15 signatures. Each group of 15 test cases is modified as follows: Three test cases are left unmodified For three test cases the Signed message is modified For three test cases the component of the signature that commits the signer to the message is modified For three test cases the component of the signature that allows the verifier to construct the vector z is modified For three test cases the component of the signature that allows the verifier to construct the hint array is modified The TOE must correctly verify the unmodified signatures and fail to verify the modified signatures.

The TSF shall perform [<h:i>symmetric-key encryption/decryption</h:i>] in accordance with a specified cryptographic algorithm <selectables> <tabularize id="fcs-cop-skc-sels" title="Allowable choices for FCS_COP.1/SKC"> <textcol>Identifier</textcol> <reqtext/> <selectcol>Cryptographic Algorithm</selectcol> <reqtext>and cryptographic key sizes</reqtext> <selectcol>Cryptographic Key Sizes</selectcol> <reqtext>that meet the following:</reqtext> <selectcol>List of Standards</selectcol> <reqtext>.<h:p/><h:p/><xref to="fcs-cop-skc-sels"/> provides the allowable choices for completion of the selection operations of FCS_COP.1/SKC.</reqtext> </tabularize>  <selectable id="sel-fcs-cop-skc-aes-cbc"> <col>AES-CBC</col> <col>AES in CBC mode with non-repeating and unpredictable IVs</col> <col>256 bits</col> <col><selectables> <selectable>ISO/IEC 18033-3:2010 (Subclause 5.2)</selectable> <selectable>FIPS PUB 197</selectable></selectables> [AES]<h:p/><selectables> <selectable>ISO/IEC 10116:2017 (Clause 7)</selectable> <selectable>NIST SP 800-38A</selectable></selectables> [CBC] </col> </selectable>  <selectable id="sel-fcs-cop-skc-aes-xts"> <col>XTS-AES</col> <col>AES in XTS mode with unique tweak values that are consecutive non-negative integers starting at an arbitrary non-negative integer</col> <col>512 bits</col> <col><selectables> <selectable>ISO/IEC 18033-3:2010 (Subclause 5.2)</selectable> <selectable>FIPS PUB 197</selectable></selectables> [AES]<h:p/><selectables> <selectable>IEEE Std. 1619-2018</selectable> <selectable>NIST SP 800-38E</selectable></selectables> [XTS] </col> </selectable>  <selectable id="sel-fcs-cop-skc-aes-ctr"> <col>AES-CTR</col> <col>AES in Counter Mode with a non-repeating initial counter and with no repeated use of counter values across multiple messages with the same secret key</col> <col>256 bits</col> <col><selectables> <selectable>ISO/IEC 18033-3:2010 (Subclause 5.2)</selectable> <selectable>FIPS PUB 197</selectable></selectables> [AES]<h:p/><selectables> <selectable>: ISO/IEC 10116:2017 (Clause 10)</selectable> <selectable>NIST SP 800-38A</selectable></selectables> [CBC] </col> </selectable> </selectables> At minimum, the TOE is required to support AES-CBC to provide this algorithm as a cryptographic service to tenant software as defined in FCS_SRV_EXT.1. The evaluator shall examine the TSS to ensure that it describes the construction of any IVs, tweak values, and counters in conformance with the relevant specifications. If XTS-AES is claimed then the evaluator shall examine the TSS to verify that the TOE creates full-length keys by methods that ensure that the two key halves are different and independent. The following tests require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products. The following tests are conditional based upon the selections made in the SFR. The evaluator shall perform the following test or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described. AES-CBC AES-CBC AES in CBC mode with non-repeating and unpredictable IVs 256 bits [selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: ISO/IEC 10116:2017 (Clause 7), NIST SP 800-38A] [CBC] To test the TOE’s ability to encrypt/decrypt data using AES in CBC mode, the evaluator shall perform Algorithm Functional Tests and Monte Carlo Tests using the following input parameters: Key size [256] bits Direction [encryption, decryption] Algorithm Functional Tests Algorithm Functional Tests are designed to verify the correct operation of the logical components of the algorithm implementation under normal operation using different block sizes. For AES-CBC, there are two types of AFTs: Known-Answer Tests For each combination of direction and claimed key size, the TOE must be tested using the GFSBox, KeySbox, VarTxt, and VarKey test cases listed in Appendixes B through E of The Advanced Encryption Standard Algorithm Validation Suite (AESAVS), NIST, 15 November 2002. Multi-Block Message Tests For each combination of direction and claimed key size, the TOE must be tested against 10 test cases consisting of a random IV, random key, and random plaintext/ciphertext. The plaintext/ciphertext starts with a length of 16 bytes and increases by 16 bytes for each test case until reaching 160 bytes. Monte Carlo Tests Monte Carlo tests are intended to test the implementation under strenuous conditions. The TOE must process the test cases according to the following algorithm once for each combination of direction and key size: Key[0] = Key IV[0] = IV PT[0] = PT for i = 0 to 99 { Output Key[i], IV[i], PT[0] for j = 0 to 999 { if (j == 0) { CT[j] = AES-CBC-Encrypt(Key[i], IV[i], PT[j]) PT[j+1] = IV[i] } else { CT[j] = AES-CBC-Encrypt(Key[i], PT[j]) PT[j+1] = CT[j-1] } } Output CT[j] AES_KEY_SHUFFLE(Key, CT) IV[i+1] = CT[j] PT[0] = CT[j-1] } where AES_KEY_SHUFFLE is defined as: If ( keylen = 128 ) Key[i+1] = Key[i] xor MSB(CT[j], 128) If ( keylen = 192 ) Key[i+1] = Key[i] xor (LSB(CT[j-1], 64) || MSB(CT[j], 128)) If ( keylen = 256 ) Key[i+1] = Key[i] xor (MSB(CT[j-1], 128) || MSB(CT[j], 128)) The above pseudocode is for encryption. For decryption, swap all instances of CT and PT. The initial IV, key, and plaintext/ciphertext should be random. The evaluator shall test the decrypt functionality using the same test as above, exchanging CT and PT, and replacing AES-CBC-Encrypt with AES-CBC-Decrypt. XTS-AES XTS-AES AES in XTS mode with unique tweak values that are consecutive non-negative integers starting at an arbitrary non-negative integer 512 bits [selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: IEEE Std. 1619-2018, NIST SP 800-38E] [XTS] To test the TOE’s ability to encrypt/decrypt data using AES in XTS mode, the evaluator shall perform the Single Data Unit Test and the Multiple Data Unit Test using the following input parameters: Direction [encryption, decryption] Key size [512] bits Tweak value format [128-bit hex string, data unit sequence number] Single Data Unit Test For each combination of claimed key size, direction, and supported tweak value format, the evaluator shall generate 50 test cases consisting of random payload data. The payload data size is determined randomly for each test case from supported values within the range [128-65536] bits. The payload size and data unit size must be equal. Multiple Data Unit Test For each combination of claimed key size, direction, and supported tweak value format, the evaluator shall generate 50 test cases consisting of random payload data. The payload data size is determined randomly for each test case from supported values within the range [128-65536] bits. Likewise, the data unit size is determined randomly for each test case from supported values within the range [128-65535] bits. The payload size and data unit size must not be equal. The evaluator shall verify the correctness of the TSF’s implementation by comparing values generated by the TSF with those generated by a known good implementation using the same input parameters. AES-CTR AES-CTR AES in Counter Mode with a non-repeating initial counter and with no repeated use of counter values across multiple messages with the same secret key. 256 bits [selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: ISO/IEC 10116:2017 (Clause 10), NIST SP 800-38A] [CTR] To test the TOE’s ability to encrypt/decrypt data using AES in CTR mode, the evaluator shall perform the Algorithm Functional Test and the Counter Test using the following input parameters: Direction [encryption, decryption] Key size [256] bits Algorithm Functional Tests Algorithm Functional Tests are designed to verify the correct operation of the logical components of the algorithm implementation under normal operation using different block sizes. For AES-CTR, there are three types of AFTs: Known-Answer Tests For each combination of direction and claimed key size, the TOE must be tested using the GFSBox, KeySbox, VarTxt, and VarKey test cases listed in Appendixes B through E of The Advanced Encryption Standard Algorithm Validation Suite (AESAVS), NIST, 15 November 2002. Single Block Message Tests For each combination of direction and claimed key, the evaluator shall generate 10 test cases with a data size of 128 bits. Partial Block Message Tests Monte Carlo tests are intended to test the implementation under strenuous conditions. The TOE must process the test cases according to the following algorithm once for each combination of direction and key size: For each combination of direction and claimed key, the evaluator shall generate five test cases such that the data size is not a multiple of 128 bits. The evaluator shall verify the correctness of the TSF’s implementation by comparing values generated by the TSF with those generated by a known good implementation using the same input parameters. Counter Test The evaluator shall generate a single message of 1000 blocks (128000 bits) and either encrypt or decrypt it. Back-compute the IVs used. Verify that they are unique and increasing (encryption) or decreasing (decryption).

The TSF shall perform [<h:i>extendable-output function</h:i>] in accordance with a specified cryptographic algorithm <selectables> <tabularize id="fcs-cop-xof-sels" title="Allowable choices for FCS_COP.1/XOF"> <selectcol>Cryptographic Algorithm</selectcol> <reqtext>and parameters</reqtext> <selectcol>Parameters</selectcol> <reqtext>that meet the following:</reqtext> <selectcol>List of Standards</selectcol> <reqtext>.<h:p/><h:p/><xref to="fcs-cop-xof-sels"/> provides the allowable choices for completion of the selection operations of FCS_COP.1/XOF.</reqtext> </tabularize>  <selectable id="sel-fcs-cop-xof-shake"> <col>SHAKE</col> <col>Functions = [SHAKE256] </col> <col>NIST FIPS PUB 202 Section 6.2 [SHAKE]</col> </selectable> </selectables> In accordance with CNSA 2.0, SHAKE is permitted to be used only as a component of LMS or XMSS. Therefore this component is claimed only if LMS or XMSS is claimed in FCS_COP.1/SigVer. The following tests are conditional based on the selections made in the SFR. The evaluator shall perform the following tests or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described. SHAKE SHAKE Function = [SHAKE256] NIST FIPS PUB 202 Section 6.2 [SHAKE] To test the TOE’s implementation of the SHAKE Extendable Output Function the evaluator shall perform the Algorithm Functional Test, Monte Carlo Test, and Variable Output Test using the following input parameters: Function [SHAKE256] Output length [16-65536] bits Algorithm Functional Test For each supported function, generate test cases consisting of random data for every message length from 0 bits (if supported) to rate-1 bits, where rate equals 1088. Additionally, generate tests cases of random data for messages of every multiple of (rate+1) bits starting at length rate, and continuing until 65535 is exceeded. Monte Carlo Test The Monte Carlo test takes in a single 128-bit message (SEED) and desired output length in bits, and runs 100 iterations of the chained computation. MaxOutBytes and MinOutBytes are the largest and smallest supported input and output sizes in bytes, respectively. Range = maxOutBytes - minOutBytes + 1 OutputLen = maxOutBytes For j = 0 to 99 MD[0] = SEED For i = 1 to 1000 MSG[i] = 128 leftmost bits of MD[i-1] if (MSG[i] < 128 bits) Append 0 bits on rightmost side of MSG[i] til MSG[i] is 128 bits MD[i] = SHAKE(MSG[i], OutputLen * 8) RightmostOutputBits = 16 rightmost bits of MD[i] as an integer OutputLen = minOutBytes + (RightmostOutputBits % Range) Output MD[1000], OutputLen SEED = MD[1000] Variable Output Test This test measures the ability of the TOE to generate output digests of varying sizes. The evaluator shall generate 512 test cases such that the input for each test case consists of 128- bits of random data, and the output length includes the minimum supported value, the maximum supported value, and 510 random values between the minimum and maximum digest sizes supported by the implementation.

This family defines requirements for implementation of the HTTPS protocol.

requires the TSF to implement the HTTPS protocol in accordance with the specified standard, using TLS, and notifying the application if invalid.

The following actions could be considered for the management functions in FMT: Configuring whether to allow or disallow establishment of a trusted channel if the peer or server certificate is deemed invalid. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP, PP-Module, functional package or ST: Failure of the certificate validity check. FCS_TLS_EXT.1 TLS Protocol FIA_X509_EXT.1 X.509 Validation of Certificates

The TSF shall implement the HTTPS protocol that complies with RFC 2818.

The TSF shall implement HTTPS using TLS as defined in [<h:i>the <xref to="tls"/></h:i>].

The TSF shall implement HTTPS using TLS as defined in <assignable>specification that defines TLS implementation requirements</assignable>.

The must be included in the ST, with the following selections made: FCS_TLS_EXT.1: TLS must be selected Client must be selected

The TSF shall notify the application and <selectables> <selectable id="s-not-estab">not establish the connection</selectable> <selectable id="s-req-app-auth">request application authorization to establish the connection</selectable> <selectable id="s-no-other-action" exclusive="yes">no other action</selectable></selectables> if the peer certificate is deemed invalid.

The TSF shall notify the application and <assignable>a response</assignable> if the peer certificate is deemed invalid.

Validity is determined by the certificate path, the expiration date, and the revocation status in accordance with RFC 5280. The selection made for FCS_HTTPS_EXT.1.3 must be consistent with the claims made in FCS_TLSC_EXT.1.6 of , e.g. if the TLS rejects all invalid certificates with no exceptions, then "not establish the connection" will be selected here. FMT_SMF_EXT.1 Function configures whether to allow or disallow the establishment of a trusted channel if the peer certificate is deemed invalid. There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. The evaluator shall attempt to establish an HTTPS connection with a webserver, observe the traffic with a packet analyzer, and verify that the connection succeeds and that the traffic is identified as TLS or HTTPS. Other tests are performed in conjunction with testing in the . The evaluator shall demonstrate that using a certificate without a valid certification path results in an application notification. Using the administrative guidance, the evaluator shall then load a certificate or certificates to the Trust Anchor Database needed to validate the certificate to be used in the function, and demonstrate that the function succeeds. The evaluator then shall delete one of the certificates, and show that the application is notified of the validation failure. Certificate validity for HTTPS connections shall be tested in accordance with testing performed for FIA_X509_EXT.1 as defined in the .

Failure of the certificate validity check.

Issuer Name and Subject Name of certificate

User’s authorization decisionNo additional information

This family defines requirements for initialization vector generation in support of key generation.

requires the TSF to generate IVs in accordance with a set of approved modes.

There are no management activities foreseen. There are no auditable events foreseen. No dependencies.

The TSF shall generate IVs in accordance with [<h:i><xref to="ivtable"/>: References and IV Requirements for NIST-approved Cipher Modes</h:i>].

The TSF shall generate IVs in accordance with <assignable>standard or specification for IV generation</assignable>.

lists the requirements for composition of IVs according to the NIST Special Publications for each cipher mode. The composition of IVs generated for encryption according to a cryptographic protocol is addressed by the protocol. Thus, this requirement addresses only IVs generated for key storage and data storage encryption. The evaluator shall examine the key hierarchy section of the TSS to ensure that the encryption of all keys is described and the formation of the IVs for each key encrypted by the same KEK meets FCS_IV_EXT.1. There are no guidance evaluation activities for this component. There are no test evaluation activities for this component.

This family defines requirements for the generation of random bits.

The TSF shall perform deterministic random bit generation services using <selectables> <tabularize id="fcs-rbg-1-sels" title="Allowable choices for FCS_RBG.1.1"> <textcol>Identifier</textcol> <reqtext/> <selectcol>DRBG Algorithm</selectcol> <reqtext> in accordance with </reqtext> <selectcol>List of standards</selectcol> <reqtext>after initialization.<h:p/><h:p/><xref to="fcs-rbg-1-sels"/> provides the allowable choices for completion of the selection operations of FCS_RBG.1.</reqtext> </tabularize> <selectable id="sel-fcs-rbg-hash-drbg"> <col>HASH_DRBG</col> <col>Hash_DRBG with <selectables> <selectable>SHA-384</selectable> <selectable>SHA-512</selectable> </selectables></col> <col><selectables> <selectable>ISO/IEC 18031: 2011 (Section C.2.2)</selectable> <selectable>NIST SP 800-90A Revision 1 Section 10.1.1</selectable></selectables> </col> </selectable> <selectable id="sel-fcs-rbg-hmac-drbg"> <col>HMAC_DRBG</col> <col>HMAC_DRBG with <selectables> <selectable>SHA-384</selectable> <selectable>SHA-512</selectable> </selectables></col> <col><selectables> <selectable>ISO/IEC 18031: 2011 (Section C.2.3)</selectable> <selectable>NIST SP 800-90A Revision 1 Section 10.1.2</selectable></selectables> </col> </selectable> <selectable id="sel-fcs-rbg-ctr-drbg"> <col>CTR_DRBG</col> <col>CTR_DRBG with AES-CTR-256</col> <col><selectables> <selectable>ISO/IEC 18031: 2011 (Section C.3.2)</selectable> <selectable>NIST SP800-90A Revision 1 Section 10.2.1</selectable></selectables> </col> </selectable> </selectables> Documentation will be produced and the evaluator shall perform the activities in accordance with and the Clarification to the Entropy Documentation and Assessment Annex. The evaluator shall verify that the TSS identifies the DRBGs used by the TOE. If the DRBG functionality is configurable, the evaluator shall verify that the operational guidance includes instructions on how to configure this behavior. The evaluator shall perform the following tests: The evaluator shall perform 15 trials for the DRBG implementation. If the DRBG is configurable, the evaluator shall perform 15 trials for each configuration. The evaluator shall also confirm that the operational guidance contains appropriate instructions for configuring the DRBG functionality. If the DRBG has prediction resistance enabled, each trial consists of: Instantiate the DRBG. Generate a block of random bits. Generate a second block of random bits. Uninstantiate. The evaluator shall verify that the second block of random bits is the expected value. The evaluator shall generate 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 next two are additional input and entropy input for the first call to generate. The final two are additional input and entropy input for the second call to generate. These values are randomly generated. "generate one block of random bits" means to generate random bits with number of returned bits equal to the Output Block Length (as defined in NIST SP 800-90A). If the DRBG does not have prediction resistance, each trial consists of: Instantiate the DRBG. Generate a block of random bits. Reseed. Generate a second block of random bits. Uninstantiate. The evaluator shall verify that the second block of random bits is the expected value. The evaluator shall generate 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 the first call to generate. The sixth and seventh are additional input and entropy input to the call to reseed. The final value is additional input to the second generate call. The following list contains more information on some of the input values to be generated/selected by the evaluator. Entropy input: The length of the entropy input value must equal the seed length. Nonce: If a nonce is supported (CTR_DRBG with no Derivation Function does not use a nonce), the nonce bit length is one-half the seed length. Personalization string: The length of the personalization string must be less than or equal to seed length. If the implementation only supports one personalization string length, then the same length can be used for both values. If more than one string length is support, the evaluator shall use personalization strings of two different lengths. If the implementation does not use a personalization string, no value needs to be supplied. Additional input: The additional input bit lengths have the same defaults and restrictions as the personalization string lengths.

The TSF shall use a <selectables> <selectable id="internal-seed">TSF entropy source <assignable>name of entropy source</assignable></selectable> <selectable id="internal-seeds"><h:b>multiple independent TSF entropy sources <assignable>names of entropy sources</assignable></h:b></selectable> <selectable id="external-seed">TSF interface for obtaining entropy</selectable> </selectables> for initialization and reseeding. Following the approach in SP800-90B/C, noise sources are required to be independent. Non-independent noise sources that share dependencies are treated as a single raw source requiring a single entropy source validation. If a TOE has multiple dependent noise sources, they should be grouped according to their dependencies for the purposes of these requirements. For the selection in this requirement, the ST author selects "TSF entropy source..." if a single entropy source is used as input to the DRBG. The ST author selects "multiple independent TSF entropy sources..." if a seed is formed from a combination of two or more independent entropy sources within the TOE boundary. If the TSF implements two or more separate DRBGs that are seeded in separate manners, this SFR should be iterated for each DRBG. If multiple distinct entropy sources exist such that each DRBG only uses one of them, then each iteration would select "TSF entropy source..."; "multiple independent TSF entropy sources..." is only selected if a single DRBG uses multiple independent entropy sources for its seed. The ST author selects "TSF interface for obtaining entropy" if entropy source data is generated outside the TOE boundary. If "TSF entropy source..." is selected, FCS_RBG.3 must be claimed. If "multiple independent TSF entropy sources..." is selected, FCS_RBG.4 and FCS_RBG.5 must be claimed. If "TSF interface for obtaining entropy" is selected, FCS_RBG.2 must be claimed.

There are no additional EAs for this element.

The TSF shall update the DRBG state by <selectables> <selectable>reseeding</selectable> <selectable>uninstantiating and reinstantiating</selectable> </selectables> using a <selectables> <selectable>TSF entropy source <assignable>name of entropy source</assignable></selectable> <selectable>TSF interface for obtaining entropy <assignable>name of the interface</assignable></selectable></selectables> in the following situations: <selectables linebreak="yes"> <selectable>never</selectable> <selectable>on demand</selectable> <selectable>on the condition: <assignable>condition</assignable></selectable> <selectable>after <assignable>time</assignable></selectable> </selectables> in accordance with <assignable>list of standards</assignable>. The evaluator shall verify that the TSS identifies how the DRBG state is updated, and the situations under which this may occur. If the ST claims that the DRBG state can be updated on demand, the evaluator shall verify that the operational guidance has instructions for how to perform this operation.

The TSF shall be able to accept a minimum input of [<h:i>384 bits of min-entropy</h:i>] from a TSF interface for obtaining entropy. This SFR is claimed if "TSF interface for obtaining entropy" is selected in , i.e., the TOE's entropy source is outside the TOE boundary. In the case of a mobile device this would likely only occur when the entropy source is a Dedicated Security Component that is integrated with the TOE. If the environmental entropy source produces full entropy, the amount of entropy data collected is equal to the amount specified in the selection. If the entropy source does not assure full entropy (i.e., the ratio of min-entropy to collected data is less than 1:1), then the TSF must collect sufficient additional entropy data and perform a derivation function on it to reduce the collected data to a seed with the claimed min-entropy. In this case, the entropy documentation is expected to identify the min-entropy rate of the source data, how much data the TSF collects, and what derivation function is performed on this collected data to ensure that it has the claimed min-entropy. One should not apply NIST SP 800-90B (or AIS-31) statistical tests against an external entropy source since the TSF is unable to enforce entropy requirements or conditioning requirements against something outside of its logical boundary. However, the TSS may include estimates for min-entropy from external sources that contribute to the overall entropy requirements for the DRBG. The evaluator shall examine the entropy documentation required by FCS_RBG.1 to verify that it identifies, for each DRBG function implemented by the TOE, the TSF external interface that is used to seed the TOE's DRBG. The evaluator shall verify that this includes the amount of sampled data and the min-entropy rate of the sampled data such that it can be determined that the TSF can derive a seed from it that has the claimed amount of min-entropy. If the TSF uses an entropy source that can be assumed to have full entropy, the seed is the output data from the entropy source. If the TSF uses an entropy source where the min-entropy of the data is less than 1:1, the evaluator shall verify that the entropy documentation identifies how large the collected data sample is and how TSF derives this data into a seed that has the claimed min-entropy.

The TSF shall be able to seed the DRBG using a <selectables onlyone="yes"> <selectable>TSF software-based entropy source</selectable> <selectable>TSF hardware-based entropy source</selectable></selectables> <assignable>name of entropy source</assignable> with [<h:i>a minimum of 384</h:i>] bits of min-entropy. This SFR is claimed if "TSF entropy source..." is selected in , i.e., the TOE has a single entropy source that is inside the TOE boundary. If the TOE obtains seed material from an environmental component, this is specified using FCS_RBG.2. If the TSF entropy source produces full entropy, the amount of entropy data collected is equal to the amount specified in the selection. If the entropy source does not assure full entropy (i.e., the ratio of min-entropy to collected data is less than 1:1), then the TSF must collect sufficient additional entropy data and perform a derivation function on it to reduce the collected data to a seed with the claimed min-entropy. In this case, the entropy documentation is expected to identify the min-entropy rate of the source data, how much data the TSF collects, and what derivation function is performed on this collected data to ensure that it has the claimed min-entropy. One can apply NIST SP 800-90B (or AIS-31) statistical tests against internal entropy sources (aka raw entropy) to confirm the min-entropy of the entropy source. The evaluator shall examine the entropy documentation required by FCS_RBG.1 to verify that it identifies, for each DRBG function implemented by the TOE, the TSF entropy source that is used to seed the TOE's DRBG. The evaluator shall verify that this includes the amount of sampled data and the min-entropy rate of the sampled data such that it can be determined that the TSF can derive a seed from it that has the claimed amount of min-entropy. If the TSF uses an entropy source that can be assumed to have full entropy, the seed is the output data from the entropy source. If the TSF uses an entropy source where the min-entropy of the data is less than 1:1, the evaluator shall verify that the entropy documentation identifies how large the collected data sample is and how TSF derives this data into a seed that has the claimed min-entropy.

The TSF shall be able to seed the DRBG using <selectables> <selectable><assignable>number</assignable> independent TSF software-based entropy source(s)</selectable> <selectable><assignable>number</assignable> independent TSF hardware-based entropy source(s)</selectable> </selectables>. This SFR is claimed if "multiple independent TSF entropy sources..." is selected in , i.e., the TSF performs some sort of operation to combine data from multiple distinct sources into a value that is used to derive a seed. If the TOE has only a single entropy source, this is specified using FCS_RBG.3. FCS_RBG.5 defines the mechanism by which these sources are combined to ensure sufficient minimum entropy. The evaluator shall examine the entropy documentation required by FCS_RBG.1 to verify that it identifies, for each DRBG function implemented by the TOE, each TSF entropy source used to seed the TOE's DRBG.

The TSF shall <assignable>combining operation</assignable> <selectables> <selectable>output from TSF entropy source(s)</selectable> <selectable>input from TSF interface(s) for obtaining entropy</selectable></selectables> resulting in a minimum of [<h:i>384</h:i>] bits of min-entropy to create the entropy input into the derivation function as defined in <assignable>list of standards</assignable>. This SFR is claimed if "multiple TSF entropy sources..." is selected in , i.e., the TSF performs some sort of operation to combine data from multiple distinct sources into a value that is used to derive a seed. If the TOE has only a single entropy source, this is specified using FCS_RBG.3. If the environmental entropy source produces full entropy, the amount of entropy data collected is equal to the amount specified in the selection. If the entropy source does not assure full entropy (i.e., the ratio of min-entropy to collected data is less than 1:1), then the TSF must collect sufficient additional entropy data and perform a derivation function on it to reduce the collected data to a seed with the claimed min-entropy. In this case, the entropy documentation is expected to identify the min-entropy rate of the source data, how much data the TSF collects, and what derivation function is performed on this collected data to ensure that it has the claimed min-entropy. One can apply NIST SP 800-90B (or AIS-31) statistical tests against internal entropy sources (aka raw entropy) to confirm the min-entropy of the entropy sources either in aggregate or individually. Using the entropy sources defined in FCS_RBG.4, the evaluator shall examine the entropy documentation required by FCS_RBG.1 to verify that it describes the method by which data from these sources are combined into a single seed. This should include an estimation of the rate at which each entropy source outputs data and whether this is dependent on any system-specific factors so that each source's relative contribution to the overall entropy is understood. The evaluator shall verify that the amount of sampled data, the min-entropy rate of the sampled data, and the method by which the multiple sampled data sources are combined can be used to determine that the TSF can derive a seed from it that has the claimed amount of min-entropy. This includes any description of how the TSF derives data larger than the seed value into a seed that has the claimed min-entropy.

The TSF shall provide a [<h:i>software</h:i>] interface to make the output, as defined in FCS_RBG.1 Random bit generation (RBG), available as a service to entities outside of the TOE. The evaluator shall verify that the TSS identifies the interface that the TSF makes available for calling applications to obtain DRBG output. The evaluator shall verify that the guidance documentation includes an API specification for the random bit generation service such that it is clear how a calling application is able to obtain DRBG output from the TSF. The evaluator shall invoke the API specified by the guidance documentation to determine that the TSF provides DRBG output upon proper invocation of the API.

requires the TSF to save and restore the state of the DRBG when powering off and starting up.

There are no management activities foreseen. There are no auditable events foreseen. FCS_RBG.1 Random Bit Generation

The TSF shall save the state of the DRBG at power-off, and shall use this state as input to the DRBG at startup. The capability to add the state saved at power-off as input to the DRBG prevents a DRBG that is slow to gather entropy from producing the same output regularly and across reboots. Since there is no guarantee of the protections provided when the state is stored (or a requirement for any such protection), it is assumed that the state is 'known', and therefore cannot contribute entropy to the DRBG, but can introduce enough variation that the initial DRBG values are not predictable and exploitable. The evaluation activity for this requirement is captured in the DRBG documentation for . The evaluator shall verify that the documentation describes how the state is generated so as to be available for the next startup, how the state is used as input to the DRBG, and any protection measures used for the state while the TOE is powered off. There are no guidance evaluation activities for this component. There are no test evaluation activities for this component.

requires the TSF to support a personalization string as a DRBG input parameter.

There are no management activities foreseen. There are no auditable events foreseen. FCS_RBG.1 Random Bit Generation

The TSF shall allow applications to add data to the DRBG using the Personalization String as defined in SP 800-90A. as defined in SP 800-90A, the TSF must not count data input from an application towards the entropy required by FCS_RBG.1. Thus, the TSF must not allow the only input to the DRBG seed to be from an application. The evaluator shall verify that this function is included as an interface to the DRBG in the documentation required by and that the behavior of the DRBG following a call to this interface is described. The evaluator shall also verify that the documentation of the DRBG describes the conditions of use and possible values for the Personalization String input to the SP 800-90A specified DRBG. There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. The evaluator shall write, or the developer shall provide, an application that adds data to the DRBG via the Personalization String. The evaluator shall verify that the request succeeds.

This family defines requirements for the ability of the TOE to make its cryptographic operations available to non-TSF components.

requires the TSF to have externally-accessible cryptographic services for making algorithm functions available to applications.

There are no management activities foreseen. There are no auditable events foreseen. FCS_CKM.1 Cryptographic Key Generation FCS_COP.1 Cryptographic Operation

The TSF shall provide a mechanism for applications to request the TSF to perform the following cryptographic operations: [<h:i><h:ul> <h:li>AEAD: <assignable>one or more AEAD algorithms</assignable> as claimed in FCS_COP.1/AEAD</h:li> <h:li>Hash: <assignable>one or more hash algorithms</assignable> as claimed in FCS_COP.1/Hash</h:li> <h:li>HMAC: <assignable>one or more HMAC algorithms</assignable> as claimed in FCS_COP.1/KeyedHash</h:li> <h:li>Digital signature:<assignable>one or more digital signature generation or verification algorithms</assignable> as claimed in FCS_COP.1/SigGen or FCS_COP.1/SigVer</h:li></h:ul> and <selectables linebreak="yes"> <selectable>Asymmetric key generation: <assignable>one or more key generation algorithms</assignable> as claimed in FCS_CKM.1/AKG</selectable> <selectable>Key agreement: <assignable>one or more key agreement algorithms</assignable> as claimed in FCS_CKM_EXT.7/UNLOCKED</selectable> <selectable>Key encapsulation: <assignable>one or more key encapsulation algorithms</assignable> as claimed in FCS_COP.1/KeyEncap</selectable> <selectable>Key wrapping: <assignable>one or more key wrap algorithms</assignable> as claimed in FCS_COP.1/KeyWrap</selectable> <selectable>Symmetric encryption: <assignable>one or more symmetric encryption algorithms</assignable> as claimed in FCS_COP.1/SKC</selectable> <selectable>no other cryptographic operations</selectable> </selectables></h:i>].

The TSF shall provide a mechanism for applications to request the TSF to perform the following cryptographic operations: <assignable>cryptographic functions</assignable>.

A conformant TOE is required to provide to provide an interface for third-party applications to invoke AEAD, hash, HMAC, and digital signature functions. The functions made available by the TSF may be a subset of those functions claimed; for example, if the TOE claims both CCM and GCM modes in FCS_COP.1/AEAD but CCM is only implemented in hardware for the purpose of Bluetooth, it is sufficient to offer only GCM. The TSF is not required to provide algorithm services for the selectable algorithms, but they should be included within the TOE boundary if supported. The TSF must also provide a service for generation of symmetric keys as defined in FCS_CKM.1/SKC. However, since this PP specifies "direct generation from a random bit generator" as the only mechanism for doing this, it is not necessary to list that service here because FCS_RBG.6 already requires the TSF to make the output of its DRBG available to third parties. There is no extra step to generate a symmetric key from random bits; the random bits themselves are the key. The evaluation shall verify that the TSS (or other product documentation) includes the security functions (cryptographic algorithms) described in these requirements. There are no guidance evaluation activities for this component. The evaluator shall write, or the developer shall provide access to, an application that requests cryptographic operations by the TSF. The evaluator shall verify that the results from the operation match the expected results according to the API documentation. This application may be used to assist in verifying the cryptographic operation Evaluation Activities for the other algorithm services requirements.

requires the TSF to support its stored keys being usable by external applications through cryptographic algorithm services.

There are no management activities foreseen. There are no auditable events foreseen. FCS_COP.1 Cryptographic Operation

The TSF shall provide a mechanism for applications to request the TSF to perform the following cryptographic operations: <selectables linebreak="yes"> <selectable>Algorithms in FCS_COP.1/AEAD</selectable> <selectable>Algorithms in FCS_COP.1/KeyWrap</selectable> <selectable>Algorithms in FCS_COP.1/SigGen</selectable> <selectable>Algorithms in FCS_COP.1/SigVer</selectable> <selectable>Algorithms in FCS_COP.1/SKC</selectable> </selectables> by keys stored in the secure key storage.

The TSF shall provide a mechanism for applications to request the TSF to perform the following cryptographic operations: <assignable>cryptographic operations defined by the TSF in FCS_COP.1</assignable> by keys stored in the secure key storage.

The TOE will, therefore, be required to perform cryptographic operations on behalf of applications using the keys stored in the TOE’s secure key storage. The evaluator shall verify that the API documentation for the secure key storage includes the cryptographic operations by the stored keys. There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. The evaluator shall write, or the developer shall provide access to, an application that requests cryptographic operations of stored keys by the TSF. The evaluator shall verify that the results from the operation match the expected results according to the API documentation. The evaluator shall use these APIs to test the functionality of the secure key storage according to the Evaluation Activities in FCS_STG_EXT.1.

This family defines requirements for the implementation of secure key storage with access control, confidentiality, and integrity protections.

requires the TSF to implement a secure key storage and defines the access restrictions to be enforced on this.

The following actions could be considered for the management functions in FMT: Importing keys or secrets into the secure key storage. Destroying imported keys or secrets in the secure key storage. Approving exceptions for shared use of keys or secrets by multiple applications. Approving exceptions for destruction of keys or secrets by applications that did not import the key or secret The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP, PP-Module, functional package or ST: Import or destruction of key. Exceptions to use and destruction rules. [FCS_CKM.1 Cryptographic Key Generation, or FDP_ITC.1 Import of User Data without Security Attributes, or FDP_ITC.2 Import of User Data with Security Attributes] FMT_SMF.1 Specification of Management Functions FMT_SMR.1 Security Roles

The TSF shall provide <selectables> <selectable id="mutable-hardware">mutable hardware</selectable> <selectable id="s-software-store">software-based</selectable> </selectables> secure key storage for asymmetric private keys and <selectables> <selectable>symmetric keys</selectable> <selectable>persistent secrets</selectable> <selectable exclusive="yes">no other keys</selectable> </selectables>.

The TSF shall provide <assignable>storage medium</assignable> secure key storage for asymmetric private keys and <assignable>list of secrets</assignable> .

A hardware keystore can be exposed to the TSF through a variety of interfaces, including embedded on the motherboard, USB, microSD, and Bluetooth. Immutable hardware is considered outside of this requirement and will be covered elsewhere. If the secure key storage is implemented in software that is protected as required by FCS_STG_EXT.2, the ST author must select . If is selected, the ST author must select in FCS_STG_EXT.2.1. Support for secure key storage for all symmetric keys and persistent secrets will be required in future revisions.

The TSF shall be capable of importing keys or secrets into the secure key storage upon request of <selectables> <selectable id="import-user">the user</selectable> <selectable id="s-import-admin">the administrator</selectable> </selectables> and <selectables> <selectable>applications running on the TSF</selectable> <selectable exclusive="yes">no other subjects</selectable> </selectables>.

The TSF shall be capable of importing keys or secrets into the secure key storage upon request of <assignable>list of users</assignable> and <assignable>list of other subjects</assignable>.

If the ST selects only , the ST author must select function in FMT_MOF_EXT.1.1.

The TSF shall be capable of destroying keys or secrets in the secure key storage upon request of <selectables> <selectable>the user</selectable> <selectable>the administrator</selectable> </selectables>. If the ST selects , the ST author must select function in FMT_MOF_EXT.1.1.

The TSF shall have the capability to allow only the application that imported the key or secret the use of the key or secret. Exceptions may only be explicitly authorized by <selectables> <selectable>the user</selectable> <selectable>the administrator</selectable> <selectable>a common application developer</selectable> </selectables>. If the ST selects or , the ST author must also select in FMT_SMF_EXT.1.1. If the ST selects , the ST author must select function in FMT_MOF_EXT.1.1.

The TSF shall allow only the application that imported the key or secret to request that the key or secret be destroyed. Exceptions may only be explicitly authorized by <selectables> <selectable id="s-killkey-user">the user</selectable> <selectable id="s-killkey-admin">the administrator</selectable> <selectable>a common application developer</selectable> </selectables>.

The TSF shall allow only the application that imported the key or secret to request that the key or secret be destroyed. Exceptions may only be explicitly authorized by <assignable>list of subjects</assignable>.

If the ST selects or , the ST author must also select function in FMT_SMF_EXT.1.1. If the ST selects only , the ST author must select function in FMT_MOF_EXT.1.1. The evaluator shall verify that the API documentation provided in the TSS (or other documentation) includes the security functions (import, use, and destruction) described in these requirements. The API documentation shall include the method by which applications restrict access to their keys or secrets in order to meet FCS_STG_EXT.1.4. The evaluator shall review the TSS to determine that the TOE implements the required secure key storage. The evaluator shall ensure that the TSS contains a description of the key storage mechanism that justifies the selection of "mutable hardware" or "software-based". The evaluator shall review the AGD guidance to determine that it describes the steps needed to import or destroy keys or secrets. The evaluator shall test the functionality of each security function: The evaluator shall import keys or secrets of each supported type according to the AGD guidance. The evaluator shall write, or the developer shall provide access to, an application that generates a key or secret of each supported type and calls the import functions. The evaluator shall verify that no errors occur during import. The evaluator shall write, or the developer shall provide access to, an application that uses an imported key or secret: For RSA, the secret shall be used to sign data. For ECDSA, the secret shall be used to sign data. In the future additional types will be required to be tested: For symmetric algorithms, the secret shall be used to encrypt data. For persistent secrets, the secret shall be compared to the imported secret. The evaluator shall repeat this test with the application-imported keys or secrets and a different application’s imported keys or secrets. The evaluator shall verify that the TOE requires approval before allowing the application to use the key or secret imported by the user or by a different application: The evaluator shall deny the approvals to verify that the application is not able to use the key or secret as described. The evaluator shall repeat the test, allowing the approvals to verify that the application is able to use the key or secret as described. If the ST author has selected "common application developer", this test is performed by either using applications from different developers or appropriately (according to API documentation) not authorizing sharing. The evaluator shall destroy keys or secrets of each supported type according to the AGD guidance. The evaluator shall write, or the developer shall provide access to, an application that destroys an imported key or secret. The evaluator shall repeat this test with the application-imported keys or secrets and a different application’s imported keys or secrets. The evaluator shall verify that the TOE requires approval before allowing the application to destroy the key or secret imported by the administrator or by a different application: The evaluator shall deny the approvals and verify that the application is still able to use the key or secret as described. The evaluator shall repeat the test, allowing the approvals and verifying that the application is no longer able to use the key or secret as described. If the ST author has selected "common application developer", this test is performed by either using applications from different developers or appropriately (according to API documentation) not authorizing sharing.

Import or destruction of key

Identity of key Role and identity of requester

Exceptions to use and destruction rulesNone

Identity of key Role and identity of requester

requires the TSF to implement confidentiality measures to protect the key storage.

There are no management activities foreseen. There are no auditable events foreseen. FCS_CKM_EXT.3 Cryptographic Key Generation FCS_COP.1 Cryptographic Operation FCS_STG_EXT.1 Cryptographic Key Storage

The TSF shall encrypt all DEKs, KEKs, <assignable>any long-term trusted channel key material</assignable> and <selectables> <selectable id="s-all-software-key-store">all software-based key storage</selectable> <selectable exclusive="yes">no other keys</selectable> </selectables> by KEKs that are <selectables linebreak="yes"> <selectable>Protected by the REK with <selectables linebreak="yes"> <selectable>encryption by a REK</selectable> <selectable>encryption by a KEK chaining from a REK</selectable> <selectable>encryption by a KEK that is derived from a REK</selectable> </selectables> </selectable> <selectable>Protected by the REK and the password with <selectables linebreak="yes"> <selectable>encryption by a REK and the password-derived KEK</selectable> <selectable>encryption by a KEK chaining to a REK and the password-derived or biometric-unlocked KEK</selectable> <selectable>encryption by a KEK that is derived from a REK and the password-derived or biometric-unlocked KEK</selectable> </selectables> </selectable> </selectables>.

The TSF shall encrypt all DEKs, KEKs, <assignable>any long-term trusted channel key material</assignable> and <assignable>other secrets </assignable> by KEKs that are <assignable>protection mechanism</assignable>.

The ST author must select if is selected in FCS_STG_EXT.1.1. If the ST author selects in FCS_STG_EXT.1.1, the secure key storage is not subject to this requirement. REKs are not subject to this requirement. A REK and the password-derived KEK may be combined to form a combined KEK (as described in FCS_CKM_EXT.3) in order to meet this requirement. Software-based key storage must be protected by the password or biometric and REK. All keys must ultimately be protected by a REK. In particular, has KEKs protected according to these requirements: DEK_1 meets the "encryption by a REK and the password-derived KEK" case and would be appropriate for sensitive data, DEK_2 meets the "encryption by a KEK chaining from a REK" case and would not be appropriate for sensitive data, K_1 meets the "encryption by a REK" case and is not considered a sensitive key, and K_2 meets the "encryption by a KEK chaining to a REK and the password-derived or biometric-unlocked KEK" case and is considered a sensitive key. Long-term trusted channel key material includes Wi-Fi (PSKs), IPsec (PSKs and client certificates) and Bluetooth keys. These keys must not be protected by the password, as they may be necessary in the locked state. For clarity, the ST author must assign any Long-term trusted channel key material supported by the TOE. At a minimum, a TOE must support at least Wi-Fi and Bluetooth keys. The evaluator shall review the TSS to determine that the TSS includes key hierarchy description of the protection of each DEK for data-at-rest, of software-based key storage, of long-term trusted channel keys, and of KEK related to the protection of the DEKs, long-term trusted channel keys, and software-based key storage. This description must include a diagram illustrating the key hierarchy implemented by the TOE in order to demonstrate that the implementation meets FCS_STG_EXT.2. The description shall indicate how the functionality described by FCS_RBG.1 is invoked to generate DEKs (FCS_CKM_EXT.2), the key size (FCS_CKM_EXT.2 and FCS_CKM_EXT.3) for each key, how each KEK is formed (generated, derived, or combined as defined in FCS_CKM_EXT.3), the integrity protection method for each encrypted key (FCS_STG_EXT.3), and the IV generation for each key encrypted by the same KEK (FCS_IV_EXT.1). More detail for each task follows the corresponding requirement. The evaluator shall also ensure that the documentation of the product's encryption key management is detailed enough that, after reading, the product's key management hierarchy is clear and that it meets the requirements to ensure the keys are adequately protected. The evaluator shall ensure that the documentation includes both an essay and one or more diagrams. Note that this may also be documented as separate proprietary evidence rather than being included in the TSS. The evaluator shall examine the key hierarchy description in the TSS section to verify that each DEK and software-stored key is encrypted as defined in FCS_STG_EXT.2. There are no guidance evaluation activities for this component. There are no test evaluation activities for this component.

DEKs, KEKs, <assignable>any long-term trusted channel key material</assignable> and <selectables> <selectable>all software-based key storage</selectable> <selectable exclusive="yes">no other keys</selectable> </selectables> shall be encrypted using one of the following methods: <selectables> <selectable>using a SP800-56B key establishment scheme</selectable> <selectable>using AES in the following modes: <selectables> <selectable>Key Wrap (KW) as defined in FCS_COP.1/KeyWrap</selectable> <selectable>Key Wrap with Padding (KWP) as defined in FCS_COP.1/KeyWrap</selectable> <selectable>GCM as defined in FCS_COP.1/AEAD</selectable> <selectable>CCM as defined in FCS_COP.1/AEAD</selectable> <selectable>CBC as defined in FCS_COP.1/SKC</selectable> </selectables></selectable> </selectables>.

The ST author selects which key encryption schemes are used by the TOE. This requirement refers only to KEKs as defined this PP and does not refer to those KEKs specified in other standards. The ST author must assign the same Long-term trusted channel key material assigned in FCS_STG_EXT.2.1.

requires the TSF to implement integrity measures to protect the key storage.

There are no management activities foreseen. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP, PP-Module, functional package or ST: Failure to verify the integrity of stored key. FCS_COP.1 Cryptographic Operation FCS_STG_EXT.2 Encrypted Cryptographic Key Storage

The TSF shall protect the integrity of any encrypted DEKs and KEKs and <selectables> <selectable>long-term trusted channel key material</selectable> <selectable>all software-based key storage</selectable> <selectable exclusive="yes">no other keys</selectable> </selectables> by <selectables linebreak="yes"> <selectable><selectables> <selectable>GCM as defined in FCS_COP.1/AEAD</selectable> <selectable>CCM as defined in FCS_COP.1/AEAD</selectable> <selectable>Key Wrap as defined in FCS_COP.1/KeyWrap</selectable> <selectable>Key Wrap with Padding as defined in FCS_COP.1/KeyWrap</selectable> </selectables> cipher mode for encryption as defined in FCS_STG_EXT.2</selectable> <selectable>a hash (FCS_COP.1<h:b>/Hash</h:b>) of the stored key that is encrypted by a key protected by FCS_STG_EXT.2</selectable> <selectable>a keyed hash (FCS_COP.1<h:b>/KeyedHash</h:b>) using a key protected by a key protected by FCS_STG_EXT.2</selectable> <selectable>a digital signature of the stored key using an asymmetric key protected as defined in FCS_STG_EXT.2</selectable> <selectable>an immediate application of the key for decrypting the protected data followed by a successful verification of the decrypted data with previously known information</selectable> </selectables>.

The TSF shall protect the integrity of any encrypted DEKs and KEKs and <selectables> <selectable>long-term trusted channel key material</selectable> <selectable>all software-based key storage</selectable> <selectable exclusive="yes">no other keys</selectable> </selectables> by <selectables linebreak="yes"> <selectable><assignable>AES algorithm</assignable> cipher mode for encryption as defined in FCS_STG_EXT.2</selectable> <selectable>a hash (FCS_COP.1) of the stored key that is encrypted by a key protected by FCS_STG_EXT.2</selectable> <selectable>a keyed hash (FCS_COP.1) using a key protected by a key protected by FCS_STG_EXT.2</selectable> <selectable>a digital signature of the stored key using an asymmetric key protected as defined in FCS_STG_EXT.2</selectable> <selectable>an immediate application of the key for decrypting the protected data followed by a successful verification of the decrypted data with previously known information</selectable> </selectables>.

The ST author must assign the same Long-term trusted channel key material assigned in FCS_STG_EXT.2.1.

The TSF shall verify the integrity of the <selectables> <selectable>hash</selectable> <selectable>digital signature</selectable> <selectable>MAC</selectable> </selectables> of the stored key prior to use of the key. This requirement is not applicable to derived keys that are not stored. It is not expected that a single key will be protected from corruption by multiple of these methods; however, a product may use one integrity-protection method for one type of key and a different method for other types of keys. The explicit Evaluation Activities for each of the options will be addressed in each of the requirements (FCS_COP.1.1/Hash, FCS_COP.1.1/KeyedHash). Key Wrapping must be implemented per SP800-38F. The evaluator shall examine the key hierarchy description in the TSS section to verify that each encrypted key is integrity protected according to one of the options in FCS_STG_EXT.3. The evaluator shall also ensure that the documentation of the product's encryption key management is detailed enough that, after reading, the product's key management hierarchy is clear and that it meets the requirements to ensure the keys are adequately protected. The evaluator shall ensure that the documentation includes both an essay and one or more diagrams. Note that this may also be documented as separate proprietary evidence rather than being included in the TSS. There are no guidance evaluation activities for this component. There are no test evaluation activities for this component.

Failure to verify integrity of stored key

Identity of key being verified

A subset of the User Data Protection focuses on protecting Data-At-Rest, namely FDP_DAR_EXT.1 and FDP_DAR_EXT.2. Three levels of data-at-rest protection are addressed: TSF data, protected data (and keys), and sensitive data. addresses the level of protection required for each level of data-at-rest. : Protection of Data Levels TSF DataTSF data does not require confidentiality, but does require integrity protection. (FPT_TST_EXT.2/PREKERNEL) Protected DataProtected data is encrypted while powered off. (FDP_DAR_EXT.1) Sensitive DataSensitive data is encrypted while in the locked state, in addition to while powered off. (FDP_DAR_EXT.2) All keys, protected data, and sensitive data must ultimately be protected by the REK. Sensitive data must be protected by the password in addition to the REK. In particular, has KEKs protected according to these requirements: DEK_1 would be appropriate for sensitive data, DEK_2 would not be appropriate for sensitive data, K_1 is not considered a sensitive key, and K_2 is considered a sensitive key. These requirements include a capability for encrypting sensitive data received while in the locked state, which may be considered a separate sub-category of sensitive data. This capability may be met by a key transport scheme (RSA) by using a public key to encrypt the DEK while protecting the corresponding private key with a password-derived or biometric-unlocked KEK. This capability may also be met by a key agreement scheme. To do so, the device generates a device-wide sensitive data asymmetric pair (the private key of which is protected by a password-derived or biometric-unlocked KEK) and an asymmetric pair for the received sensitive data to be stored. In order to store the sensitive data, the device-wide public key and data private key are used to generate a shared secret, which can be used as a KEK or a DEK. The data private key and shared secret are cleared after the data is encrypted and the data public key stored. Thus, no key material is available in the locked state to decrypt the newly stored data. Upon unlock, the device-wide private key is decrypted and is used with each data public key to regenerate the shared secret and decrypt the stored data. , below, illustrates this scheme.

This family defines the rules for access control functions that are not addressed by the FDP_ACF family in CC Part 2.

requires the TSF to be able to control access to its own services.

The following actions could be considered for the management functions in FMT: Placing applications into application groups based on enterprise configuration settings. Enabling/disabling location services. Enabling/disabling data signaling over externally-accessible hardware ports. There are no auditable events foreseen. FMT_SMR.1 Security Roles

The TSF shall provide a mechanism to restrict the system services that are accessible to an application. Examples of system services to which this requirement applies include: Obtain data from camera and microphone input devices Obtain current device location Retrieve credentials from system-wide credential store Retrieve contacts list / address book Retrieve stored pictures Retrieve text messages Retrieve emails Retrieve device identifier information Obtain network access The evaluator shall ensure the TSS lists all system services available for use by an application. The evaluator shall also ensure that the TSS describes how applications interface with these system services, and means by which these system services are protected by the TSF. The TSS shall describe which of the following categories each system service falls in: No applications are allowed access Privileged applications are allowed access Applications are allowed access by user authorization All applications are allowed access Privileged applications include any applications developed by the TSF developer. The TSS shall describe how privileges are granted to third-party applications. For both types of privileged applications, the TSS shall describe how and when the privileges are verified and how the TSF prevents unprivileged applications from accessing those services. For any services for which the user may grant access, the evaluator shall ensure that the TSS identifies whether the user is prompted for authorization when the application is installed, or during runtime. The evaluator shall ensure that the operational user guidance contains instructions for restricting application access to system services. There are no guidance evaluation activities for this element. Evaluation Activity Note: The following tests require the vendor to provide access to a test platform that provides the evaluator with tools that are typically not found on consumer Mobile Device products. The evaluator shall write, or the developer shall provide, applications for the purposes of the following tests. For each system service to which no applications are allowed access, the evaluator shall attempt to access the system service with a test application and verify that the application is not able to access that system service. For each system service to which only privileged applications are allowed access, the evaluator shall attempt to access the system service with an unprivileged application and verify that the application is not able to access that system service. The evaluator shall attempt to access the system service with a privileged application and verify that the application can access the service. For each system service to which the user may grant access, the evaluator shall attempt to access the system service with a test application. The evaluator shall ensure that either the system blocks such accesses or prompts for user authorization. The prompt for user authorization may occur at runtime or at installation time, and should be consistent with the behavior described in the TSS. For each system service listed in the TSS that is accessible by all applications, the evaluator shall test that an application can access that system service.

The TSF shall provide an access control policy that prevents <selectables> <selectable id="s-fdp-app">application</selectable> <selectable id="fdp_group">groups of applications</selectable> </selectables> from accessing <selectables> <selectable>all</selectable> <selectable id="s-private">private</selectable> </selectables> data stored by other <selectables> <selectable>application</selectable> <selectable>groups of applications</selectable> </selectables>. Exceptions may only be explicitly authorized for such sharing by <selectables> <selectable id="s-acl-user">the user</selectable> <selectable id="s-acl-admin">the administrator</selectable> <selectable id="s-acl-devel">a common application developer</selectable> <selectable>no one</selectable> </selectables>.

The TSF shall provide an access control policy that prevents <assignable>list of subjects</assignable> from accessing <selectables><selectable>all</selectable><selectable>private</selectable> </selectables> data stored by other <assignable>list of subjects</assignable>. Exceptions may only be explicitly authorized for such sharing by <assignable>list of authorized subjects</assignable>.

Application groups may be designated Enterprise or Personal. Applications installed by the user default to being in the Personal application group unless otherwise designated by the administrator in function of FMT_SMF_EXT.1.1. Applications installed by the administrator default to being in the Enterprise application group (this category includes applications that the user requests the administrator install, for instance by selecting the application for installation through an enterprise application catalog) unless otherwise designated by the administrator in function of FMT_SMF_EXT.1.1. It is acceptable for the same application to have multiple instances installed, each in different application groups. Private data is defined as data that is accessible only by the application that wrote it. Private data is distinguished from data that an application may, by design, write to shared storage areas. If is selected, FDP_ACF_EXT.2 must be included in the ST. The evaluator shall examine the TSS to verify that it describes which data sharing is permitted between applications, which data sharing is not permitted, and how disallowed sharing is prevented. It is possible to select both "applications" and "groups of applications", in which case the TSS is expected to describe the data sharing policies that would be applied in each case. There are no guidance evaluation activities for this element. The evaluator shall write, or the developer shall provide, two applications, one that saves data containing a unique string, and a second that attempts to access that data. Based on the selections made, the following steps shall be performed: If is selected, the applications shall be placed into different groups. If is selected, the evaluator shall install the two applications. If is selected, the application shall not write to a designated shared storage area. The evaluator shall verify that the second application is unable to access the stored unique string by default. [conditional: "no one" is not selected in FDP_ACF_EXT.1.2] Using the applications from the previous test, the evaluator shall test the explicit authorizations for sharing data between applications as follows, depending on the selections made in FDP_ACF_EXT.1.2: If is selected, the evaluator shall grant access as the user and verify that the second application is able to access the stored unique string. If is selected, the evaluator shall grant access as the administrator and verify that the second application is able to access the stored unique string. If is selected, the evaluator shall grant access to an application with a common application developer to the first, and verify that the application is able to access the stored unique string.

requires the TSF to be able to provide separate copies of system resources for different application groups.

The following actions could be considered for the management functions in FMT: Approving exceptions for sharing data between applications or groups of applications. There are no auditable events foreseen. FDP_ACF_EXT.1 Access Control for System Services FMT_SMR.1 Security Roles

The TSF shall provide a separate <selectables> <selectable>address book</selectable> <selectable>calendar</selectable> <selectable>keystore</selectable> <selectable>account credential database, <assignable>list of additional resources</assignable></selectable> </selectables> for each application group and only allow applications within that process group to access the resource. Exceptions may only be explicitly authorized for such sharing by <selectables> <selectable>the user</selectable> <selectable>the administrator</selectable> <selectable>no one</selectable> </selectables>. If is selected in FDP_ACF_EXT.1.2, FDP_ACF_EXT.2 must be included in the ST. There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. For each selected resource, the evaluator shall cause data to be placed into the Enterprise group’s instance of that shared resource. The evaluator shall install an application into the Personal group that attempts to access the shared resource information and verify that it cannot access the information.

requires the TSF to enforce policies on applications that prohibit write and execute permissions from being granted simultaneously.

There are no management activities foreseen. There are no auditable events foreseen. No dependencies.

The TSF shall enforce an access control policy that prohibits an application from granting both write and execute permission to a file on the device except for <selectables> <selectable>files stored in the application's private data folder</selectable> <selectable>no exceptions</selectable> </selectables>. There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. Evaluation Activity Note: The following tests require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on consumer Mobile Device products. The evaluator shall write, or the developer shall provide, an application that attempts to store a file with both write and execute permissions. If the selection is "no exceptions", then the evaluator shall verify that this action fails and that the permissions on the file are not simultaneously write and execute. If the selection is "application's private data folder", then the evaluator shall ensure that the attempt to store the file is outside of the application's private data folder. The evaluator shall traverse the file system examining the permission on each TSF file to verify that no file has both write and execute permissions set. If the selection is "application's private data folder", then only files outside of this folder need to be examined by the evaluator for this test.

This family defines requirements for managing device backups.

requires the TSF to be able to determine which data to include in backup operations.

The following actions could be considered for the management functions in FMT: Enable/disable backup of certain applications to a local or remote system. There are no auditable events foreseen. No dependencies.

The TSF shall provide a mechanism for applications to mark <selectables> <selectable id="s-all-app-data">all application data</selectable> <selectable id="s-sel-app-data">selected application data</selectable> </selectables> to be excluded from device backups.

The TSF shall provide a mechanism for applications to mark <assignable>list of data categories </assignable> to be excluded from device backups.

Device backups include any mechanism built into the TOE that allows stored application data to be extracted over a physical port or sent over the network, but does not include any functionality implemented by a specific application itself if the application is not included in the TOE. The lack of a public/documented API for performing backups, when a private/undocumented API exists, is not sufficient to meet this requirement. There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. If is selected, the evaluator shall install an application that has marked all of its application data to be excluded from backups. The evaluator shall cause data to be placed into the application’s storage area. The evaluator shall attempt to back up the application data and verify that the backup fails or that the application’s data was not included in the backup. If is selected, the evaluator shall install an application that has marked selected application data to be excluded from backups. The evaluator shall cause data covered by "selected application data" to be placed into the application’s storage area. The evaluator shall attempt to backup that selected application data and verify that either the backup fails or that the selected data is excluded from the backup.

This family defines requirements for managing Bluetooth devices.

requires the TSF to manage which applications communicate with Bluetooth devices.

There are no management activities foreseen. There are no auditable events foreseen. No dependencies.

The TSF shall limit the applications that may communicate with a particular paired Bluetooth device. Not every application with privileges to use Bluetooth should be permitted to communicate with every paired Bluetooth device. For example, the TSF may choose to require that only the application that initiated the current connection may communicate with the device, or it may strictly tie the paired device to the first application that makes a socket connection to the device following initial pairing. Additionally, for more flexibility, the TSF may choose to provide the user with a way to select which applications on the device may communicate with or observe communications with each paired Bluetooth device. The evaluator shall ensure that the TSS describes the mechanism used to prevent unrestricted access to paired Bluetooth devices (or their communication data) by every application with access to the Bluetooth system service on the TOE. The evaluator shall verify that this method either restricts access to a single application or provides explicit control of the applications that may communicate with the paired Bluetooth device. The evaluator shall verify that the AGD contains the steps to configure which applications are allowed to communicate with a given Bluetooth peripheral. The evaluator shall establish a Bluetooth connection with any peripheral. The evaluator shall verify that an application that is allowed to communicate with the Bluetooth peripheral is able to and that an application that is not allowed to communicate with that Bluetooth peripheral is unable to communicate with the peripheral.

This family defines requirements for implementation of data-at-rest protection.

requires the TSF to be able to protect all data with a chosen method of encryption.

The following actions could be considered for the management functions in FMT: Enabling data-at-rest protection. Enabling removable media’s data-at-rest protection. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP, PP-Module, functional package or ST: Failure to encrypt/decrypt data. FCS_COP.1 Cryptographic Operation

Encryption shall cover all protected data. Protected data is all non-TSF data, including all user or enterprise data. Some or all of this data may be considered sensitive data as well.

Encryption shall be performed using DEKs with AES in the <selectables> <selectable id="fel-dar-how-cbc">CBC</selectable> <selectable id="fel-dar-how-gcm">GCM</selectable> <selectable id="fel-dar-how-xts">XTS</selectable> </selectables> mode with key size [<h:i>256</h:i>] bits.

Encryption shall be performed using DEKs with AES in the <assignable>list of AES modes</assignable> mode with key size <assignable>list of acceptable key sizes</assignable> bits.

IVs must be generated in accordance with FCS_IV_EXT.1.1. The evaluator shall verify that the TSS section of the ST indicates which data is protected by the DAR implementation and what data is considered TSF data. The evaluator shall ensure that this data includes all protected data. The evaluator shall review the AGD guidance to determine that the description of the configuration and use of the DAR protection does not require the user to perform any actions beyond configuration and providing the authentication credential. The evaluator shall also review the AGD guidance to determine that the configuration does not require the user to identify encryption on a per-file basis. Evaluation Activity Note: The following test requires the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on consumer Mobile Device products. The evaluator shall enable encryption according to the AGD guidance. The evaluator shall create user data (non-system) either by creating a file or by using an application. The evaluator shall use a tool provided by the developer to verify that this data is encrypted when the product is powered off, in conjunction with .

Failure to encrypt/decrypt dataNone

requires the TSF to protect the Trust Anchor Database.

The following actions could be considered for the management functions in FMT: Importing X.509v3 certificates into the Trust Anchor Database. Removing imported X.509v3 certificates from the Trust Anchor Database. Approving import and removal by applications of X.509v3 certificates in the Trust Anchor Database. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP, PP-Module, functional package or ST: Addition or removal of certificate from Trust Anchor Database FCS_COP.1 Cryptographic Operation FCS_CKM_EXT.7 Cryptographic Key Establishment FCS_STG_EXT.2 Encrypted Cryptographic Key Storage

The TSF shall provide a mechanism for applications to mark data and keys as sensitive. Data and keys that have been marked as sensitive will be subject to certain restrictions (through other requirements) in both the locked and unlocked states of the Mobile Device. This mechanism allows an application to choose those data and keys under its control to be subject to those requirements. In the future, this PP may require that all data and key created by applications will default to the "sensitive" marking, requiring an explicit "non-sensitive" marking rather than an explicit "sensitive" marking. The evaluator shall verify that the TSS includes a description of which data stored by the TSF (such as by native applications) is treated as sensitive. This data may include all or some user or enterprise data and must be specific regarding the level of protection of email, contacts, calendar appointments, messages, and documents. The evaluator shall examine the TSS to determine that it describes the mechanism that is provided for applications to use to mark data and keys as sensitive. This description shall also contain information reflecting how data and keys marked in this manner are distinguished from data and keys that are not (for instance, tagging, segregation in a "special" area of memory or container, etc.). There are no guidance evaluation activities for this element. The evaluator shall enable encryption of sensitive data and require user authentication according to the AGD guidance. The evaluator shall try to access and create sensitive data (as defined in the ST and either by creating a file or using an application to generate sensitive data) in order to verify that no other user interaction is required.

The TSF shall use an asymmetric key scheme to encrypt and store sensitive data received while the product is locked. Sensitive data is encrypted according to FDP_DAR_EXT.1.2. The asymmetric key scheme must be performed in accordance with FCS_CKM_EXT.7/LOCKED. The intent of this requirement is to allow the device to receive sensitive data while locked and to store the received data in such a way as to prevent unauthorized parties from decrypting it while in the locked state. If only a subset of sensitive data may be received in the locked state, this subset must be described in the TSS. Key material must be cleared when no longer needed as defined in FCS_CKM.6. For keys (or key material used to derive those keys) protecting sensitive data received in the locked state, "no longer needed" includes "while in the locked state." For example, in the first key scheme, this includes the DEK protecting the received data as soon as the data is encrypted. In the second key scheme this includes the private key for the data asymmetric pair, the generated shared secret, and any generated DEKs. Of course, both schemes require that a private key of an asymmetric pair (the RSA private key and the device-wide private key, respectively) be cleared when transitioning to the locked state. The evaluator shall review the TSS section of the ST to determine that the TSS includes a description of the process of receiving sensitive data while the device is in a locked state. The evaluator shall also verify that the description indicates if sensitive data that may be received in the locked state is treated differently than sensitive data that cannot be received in the locked state. The description shall include the key scheme for encrypting and storing the received data, which must involve an asymmetric key and must prevent the sensitive data-at-rest from being decrypted by wiping all key material used to derive or encrypt the data (as described in the application note). The introduction to this section provides two different schemes that meet the requirements, but other solutions may address this requirement. There are no guidance evaluation activities for this element. The evaluator shall perform the tests in FCS_CKM.6 for all key material no longer needed while in the locked state and shall ensure that keys for the asymmetric scheme are addressed in the tests performed when transitioning to the locked state.

The TSF shall encrypt any stored symmetric key and any stored private key of the asymmetric keys used for the protection of sensitive data as defined in [<h:i>FCS_STG_EXT.2.1 selection 2</h:i>].

The TSF shall encrypt any stored symmetric key and any stored private key of the asymmetric keys used for the protection of sensitive data according to <assignable>mechanism for encrypted key storage</assignable>.

Symmetric keys used to encrypt sensitive data while the TSF is in the unlocked state must be encrypted with (or chain to a KEK encrypted with) the REK and password-derived or biometric-unlocked KEK. A stored private key of the asymmetric key scheme for encrypting data in the locked state must be encrypted with (or chain to a KEK encrypted with) the REK and password-derived or biometric-unlocked KEK. The evaluator shall verify that the key hierarchy section of the TSS required for FCS_STG_EXT.2.1 includes the symmetric encryption keys (DEKs) used to encrypt sensitive data. The evaluator shall ensure that these DEKs are encrypted by a key encrypted with (or chain to a KEK encrypted with) the REK and password-derived or biometric-unlocked KEK. The evaluator shall verify that the TSS section of the ST that describes the asymmetric key scheme includes the protection of any private keys of the asymmetric pairs. The evaluator shall ensure that any private keys that are not wiped and are stored by the TSF are stored encrypted by a key encrypted with (or chain to a KEK encrypted with) the REK and password-derived or biometric-unlocked KEK. The evaluator shall also ensure that the documentation of the product's encryption key management is detailed enough that, after reading, the product's key management hierarchy is clear and that it meets the requirements to ensure the keys are adequately protected. The evaluator shall ensure that the documentation includes both an essay and one or more diagrams. Note that this may also be documented as separate proprietary evidence rather than being included in the TSS. There are no guidance evaluation activities for this element. There are no test evaluation activities for this element.

The TSF shall decrypt the sensitive data that was received while in the locked state upon transitioning to the unlocked state using the asymmetric key scheme and shall re-encrypt that sensitive data using the symmetric key scheme. The evaluator shall verify that the TSS section of the ST that describes the asymmetric key scheme includes a description of the actions taken by the TSF for the purposes of DAR upon transitioning to the unlocked state. These actions shall minimally include decrypting all received data using the asymmetric key scheme and re-encrypting with the symmetric key scheme used to store data while the device is unlocked. There are no guidance evaluation activities for this element. There are no test evaluation activities for this element.

Failure to encrypt/decrypt dataNone

This family defines requirements for handling of information flows that are not addressed by FDP_IFC in CC Part 2.

requires the TSF to be able to support the use of an IPsec VPN to protect data in transit.

The following actions could be considered for the management functions in FMT: Enabling/disabling VPN protection. Enabling/disabling Always On VPN protection. There are no auditable events foreseen. FTP_ITC_EXT.1 Trusted Channel Communication

The TSF shall <selectables linebreak="yes"> <selectable>provide an interface which allows a VPN client to protect all IP traffic using IPsec</selectable> <selectable>provide a VPN client which can protect all IP traffic using IPsec <h:b>as defined in the <xref to="mod-vpnclient"/></h:b></selectable> </selectables> with the exception of IP traffic needed to manage the VPN connection, and <selectables> <selectable><assignable>traffic needed for correct functioning of the TOE</assignable></selectable> <selectable>no other traffic</selectable></selectables>, when the VPN is enabled. Typically, the traffic needed to manage the VPN connection is referred to as "Control Plane" traffic; whereas, the IP traffic protected by the IPsec VPN is referred to as "Data Plane" traffic. All "Data Plane" traffic must flow through the VPN connection and the VPN must not split-tunnel. “IP traffic needed for correct functioning of the TOE” comprises traffic that would prevent the TOE from proper operation if it was either blocked by or routed through the VPN. Enabling the VPN means that the VPN client has been activated by the user. If the VPN tunnel gets interrupted, then no “Data Plane” traffic should be sent without the VPN tunnel being re-established or the user disabling the VPN client. If no native IPsec client is validated or third-party VPN clients may also implement the required Information Flow Control, the first option must be selected. In these cases, the TOE provides an API to third-party VPN clients that allow them to configure the TOE’s network stack to perform the required Information Flow Control. The ST author must select the second option if the TSF implements a native VPN client ( is selected in ). Thus the TSF must be validated against the and the ST author must also include FDP_IFC_EXT.1 from the . It is optional for the VPN client to be configured to be always-on per FMT_SMF_EXT.1 Function . Always-on means the establishment of an IPsec trusted channel to allow any communication by the TSF. The evaluator shall verify that the TSS section of the ST describes the routing of IP traffic through processes on the TSF when a VPN client is enabled. The evaluator shall ensure that the description indicates which traffic does not go through the VPN and which traffic does. The evaluator shall verify that a configuration exists for each baseband protocol in which only the traffic identified by the ST author as necessary for establishing the VPN connection (IKE traffic and perhaps HTTPS or DNS traffic) or needed for the correct functioning of the TOE is not encapsulated by the VPN protocol (IPsec). The evaluator shall verify that the TSS section describes any differences in the routing of IP traffic when using any supported baseband protocols (e.g. Wi-Fi or, LTE). The evaluator shall verify that one (or more) of the following options is addressed by the documentation: The description above indicates that if a VPN client is enabled, all configurations route all Data Plane traffic through the tunnel interface established by the VPN client. The AGD guidance describes how the user or administrator can configure the TSF to meet this requirement. The API documentation includes a security function that allows a VPN client to specify this routing. If the ST author identifies any differences in the routing between Wi-Fi and cellular protocols, the evaluator shall repeat this test with a base station implementing one of the identified cellular protocols. Step 1: The evaluator shall enable a Wi-Fi configuration as described in the AGD guidance (as required by FTP_ITC_EXT.1). The evaluator shall use a packet sniffing tool between the wireless access point and an Internet-connected network. The evaluator shall turn on the sniffing tool and perform actions with the device such as navigating to websites, using provided applications, and accessing other Internet resources. The evaluator shall verify that the sniffing tool captures the traffic generated by these actions, turn off the sniffing tool, and save the session data. Step 2: The evaluator shall configure an IPsec VPN client that supports the routing specified in this requirement, and if necessary, configure the device to perform the routing specified as described in the AGD guidance. The evaluator shall ensure the test network is capable of sending any traffic identified as exceptions. The evaluator shall turn on the sniffing tool, establish the VPN connection, and perform the same actions with the device as performed in the first step, as well as ensuring that all exception traffic is generated. The evaluator shall verify that the sniffing tool captures traffic generated by these actions, turn off the sniffing tool, and save the session data. Step 3: The evaluator shall examine the traffic from both step one and step two to verify that all Data Plane traffic is encapsulated by IPsec, except for any exceptions identified in the SFR (if applicable). For each exception listed in the SFR, the evaluator shall verify that traffic is allowed outside of the VPN tunnel. The evaluator shall examine the Security Parameter Index (SPI) value present in the encapsulated packets captured in Step two from the TOE to the Gateway and shall verify this value is the same for all actions used to generate traffic through the VPN. Note that it is expected that the SPI value for packets from the Gateway to the TOE is different than the SPI value for packets from the TOE to the Gateway. The evaluator shall be aware that IP traffic on the cellular baseband outside of the IPsec tunnel may be emanating from the baseband processor and shall verify with the manufacturer that any identified traffic is not emanating from the application processor. Step 4: (Conditional: If ICMP is not listed as part of the IP traffic needed for the correct functioning of the TOE) The evaluator shall perform an ICMP echo from the TOE to the IP address of another device on the local wireless network and shall verify that no packets are sent using the sniffing tool. The evaluator shall attempt to send packets to the TOE outside the VPN tunnel (i.e., not through the VPN gateway), including from the local wireless network, and shall verify that the TOE discards them.

This family defines requirements for managing data storage.

requires the TSF to be able to label, encrypt, store, and decrypt sensitive data and keys.

There are no management activities foreseen. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP, PP-Module, functional package or ST: Failure to encrypt/decrypt data. FCS_COP.1 Cryptographic Operation FCS_STG_EXT.2 Encrypted Cryptographic Key Storage

The TSF shall provide protected storage for the Trust Anchor Database. The evaluator shall ensure the TSS describes the Trust Anchor Database implemented that contain certificates used to meet the requirements of this PP. This description shall contain information pertaining to how certificates are loaded into the store, and how the store is protected from unauthorized access (for example, UNIX permissions) in accordance with the permissions established in FMT_SMF_EXT.1 and FMT_MOF_EXT.1.1. There are no guidance evaluation activities for this component. There are no test evaluation activities for this component.

Addition or removal of certificate from Trust Anchor Database

Subject name of certificate

This family defines requirements for the use of trusted channel protocols to protect user data.

requires the TSF to be able to protect communication channels between products using a chosen secure method.

There are no management activities foreseen. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP, PP-Module, functional package or ST: Application initiation of trusted channel. FTP_ITC_EXT.1 Trusted Channel Communication

The TSF shall provide a means for non-TSF applications executing on the TOE to use <assignable>data transfer protocol</assignable> to provide a protected communication channel between the non-TSF application and another IT product that is logically distinct from other communication channels, provides assured identification of its end points, protects channel data from disclosure, and detects modification of the channel data.

The TSF shall permit the non-TSF applications to initiate communication via the trusted channel.

The TSF shall provide a means for non-TSF applications executing on the TOE to use [<h:i><h:ul> <h:li>Mutually authenticated TLS as defined in the <xref to="tls"/>,</h:li> <h:li>HTTPS,</h:li> </h:ul>and <selectables linebreak="yes"> <selectable id="upc_dtls">mutually authenticated DTLS as defined in the <xref to="tls"/></selectable> <selectable id="s-upc-ipsec">IPsec as defined in the <xref to="mod-vpnclient"/></selectable> <selectable exclusive="yes">no other protocol</selectable> </selectables> </h:i>] to provide a protected communication channel between the non-TSF application and another IT product that is logically distinct from other communication channels, provides assured identification of its end points, protects channel data from disclosure, and detects modification of the channel data. The intent of this requirement is that one of the selected protocols is available for use by user applications running on the device for use in connecting to distant-end services that are not necessarily part of the enterprise infrastructure. It should be noted that the FTP_ITC_EXT.1 requires that all TSF communications be protected using the protocols indicated in that requirement, so the protocols required by this component ride "on top of" those listed in FTP_ITC_EXT.1. It should also be noted that some applications are part of the TSF, and FTP_ITC_EXT.1 requires that TSF applications be protected by at least one of the protocols in first selection in FTP_ITC_EXT.1. It is not required to have two different implementations of a protocol, or two different protocols, to satisfy both this requirement (for non-TSF apps) and FTP_ITC_EXT.1 (for TSF apps), as long as the services specified are provided. The ST author must list which trusted channel protocols are implemented by the Mobile Device for use by non-TSF apps. The TSF must be validated against FCS_TLSC_EXT requirements from the , with the claims from that package made for those requirements as defined in . If is selected, the TSF must be validated against FCS_DTLS_EXT requirements from the , with the claims from that package made for those requirements as defined in . If the ST author selects , the TSF must be validated against the .

The TSF shall permit the non-TSF applications to initiate communication via the trusted channel. The evaluator shall verify that the API documentation provided in the TSS (or other documentation) includes the security functions (protection channel) described in these requirements, and verify that the APIs implemented to support this requirement include the appropriate settings/parameters so that the application can both provide and obtain the information needed to assure mutual identification of the endpoints of the communication as required by this component. The evaluator shall examine the TSS to determine that it describes that all protocols listed in the TSS are specified and included in the requirements in the ST. The evaluator shall confirm that the operational guidance contains instructions necessary for configuring the protocols selected for use by the applications. Evaluation Activity Note: The following test requires the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on consumer Mobile Device products. The evaluator shall perform the following tests: The evaluator shall write, or the developer shall provide access to, an application that requests protected channel services by the TSF. The evaluator shall verify that the results from the protected channel match the expected results according to the API documentation. This application may be used to assist in verifying the protected channel Evaluation Activities for the protocol requirements. The evaluator shall ensure that the application is able to initiate communications with an external IT entity using each protocol specified in the requirement, setting up the connections as described in the operational guidance and ensuring that communication is successful. The evaluator shall ensure, for each communication channel with an authorized IT entity, the channel data are not sent in plaintext.

Application initiation of trusted channel

Name of application Trusted channel protocol Non-TOE endpoint of connection

The TSF shall provide a means for non-TSF applications executing on the TOE to use Bluetooth as defined in [<h:i>the <xref to="mod-bluetooth"/></h:i>] to provide a protected communication channel between the non-TSF application and another IT product that is logically distinct from other communication channels, provides assured identification of its end points, protects channel data from disclosure, and detects modification of the channel data. If the TOE implements Bluetooth, this requirement must be included in the ST. The intent of this requirement is that Bluetooth is available for use by user applications running on the device for use in connecting to distant-end services that are not necessarily part of the enterprise infrastructure. The ST author must list which trusted channel protocols are implemented by the Mobile Device for use by non-TSF apps. The TSF must be validated against requirements from the . It should be noted that the FTP_ITC_EXT.1 requires that all TSF communications be protected using the protocols indicated in that requirement, so the protocols required by this component ride "on top of" those listed in FTP_ITC_EXT.1.

Application initiation of trusted channel

Name of application Trusted channel protocol Non-TOE endpoint of connection

This family defines requirements for authentication failure handling that are not addressed by the FIA_AFL family in CC Part 2.

requires the TSF be able to manage unsuccessful authentication attempts and limit the number of attempts for each method.

The following actions could be considered for the management functions in FMT: Configuration of authentication failure limit. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP, PP-Module, functional package or ST: Exceeding configured authentication failure limit. FCS_CKM_EXT.5 TSF Wipe FIA_UAU.1 Timing of Authentication FIA_UAU.5 Multiple Authentication Mechanisms

The TSF shall consider password and <selectables>  <selectable> biometric in accordance with the <xref to="mod-biometrics"/></selectable> <selectable> hybrid</selectable> <selectable exclusive="yes" id="s-authfail-noother"> no other mechanism</selectable> </selectables> as critical authentication mechanisms.

The TSF shall consider password and <assignable>list of acceptable authentication mechanisms</assignable> as critical authentication mechanisms.

A critical authentication mechanism is one in which countermeasures are triggered (i.e., wipe of the device) when the maximum number of unsuccessful authentication attempts is exceeded, rendering the other factors unavailable. If no additional authentication mechanisms are selected in FIA_UAU.5.1, then must be selected. If an additional authentication mechanism is selected in FIA_UAU.5.1, then it must only be selected in FIA_AFL_EXT.1.1 if surpassing the authentication failure threshold for biometric data causes a countermeasure to be triggered regardless of the failure status of the other authentication mechanisms. If the TOE implements multiple Authentication Factor interfaces (for example, a DAR decryption interface, a lock screen interface, an auxiliary boot mode interface), this component applies to all available interfaces. For example, a password is a critical authentication mechanism regardless of if it is being entered at the DAR decryption interface or at a lock screen interface.

The TSF shall detect when a configurable positive integer within <assignable>range of acceptable values for each authentication mechanism</assignable> of <selectables> <selectable id="s-authfail-num-unique">unique</selectable> <selectable id="s-authfail-num-non-unique">non-unique</selectable> </selectables> unsuccessful authentication attempts occur related to last successful authentication for each authentication mechanism.

The TSF shall detect when a configurable positive integer within <assignable>range of acceptable values for each authentication mechanism</assignable> of <selectables><selectable>unique</selectable><selectable>non-unique</selectable> </selectables> unsuccessful authentication attempts occur related to last successful authentication for each authentication mechanism.

The positive integer is configured as defined in FMT_SMF_EXT.1.1 function . An unique authentication attempt is defined as any attempt to verify a password or biometric sample, in which the input is different from a previous attempt. "" must be selected if the authentication system increments the counter only for unique unsuccessful authentication attempts. For example, if the same incorrect password is attempted twice the authentication system increments the counter once. "" must be selected if the authentication system increments the counter for each unsuccessful authentication attempt, regardless of if the input is unique. For example, if the same incorrect password is attempted twice the authentication system increments the counter twice. If hybrid authentication (i.e., a combination of biometric and pin/password) is supported, a failed authentication attempt can be counted as a single attempt, even if both the biometric and pin/password were incorrect. If the TOE supports multiple authentication mechanisms per FIA_UAU.5.1, this component applies to all authentication mechanisms. It is acceptable for each authentication mechanism to utilize an independent counter or for multiple authentication mechanisms to utilize a shared counter. The interaction between the authentication factors in regards to the authentication counter must be in accordance with FIA_UAU.5.2. If the TOE implements multiple Authentication Factor interfaces (for example, a DAR decryption interface, a lock screen interface, an auxiliary boot mode interface), this component applies to all available interfaces. However, it is acceptable for each Authentication Factor interface to be configurable with a different number of unsuccessful authentication attempts.

The TSF shall maintain the number of unsuccessful authentication attempts that have occurred upon power off. The TOE may implement an Authentication Factor interface that precedes another Authentication Factor interface in the boot sequence (for example, a volume DAR decryption interface which precedes the lock screen interface) before the user can access the device. In this situation, because the user must successfully authenticate to the first interface to access the second, the number of unsuccessful authentication attempts need not be maintained for the second interface.

When the defined number of unsuccessful authentication attempts has exceeded the maximum allowed for a given authentication mechanism, all future authentication attempts will be limited to other available authentication mechanisms, unless the given mechanism is designated as a critical authentication mechanism. In accordance with FIA_AFL_EXT.1.3, this requirement also applies after the TOE is powered off and powered back on.

When the defined number of unsuccessful authentication attempts for the last available authentication mechanism or single critical authentication mechanism has been surpassed, the TSF shall perform a wipe of all protected data. Wipe is performed in accordance with FCS_CKM_EXT.5. Protected data is all non-TSF data, including all user or enterprise data. Some or all of this data may be considered sensitive data as well. If the TOE implements multiple Authentication Factor interfaces (for example, a DAR decryption interface, a lock screen interface, an auxiliary boot mode interface), this component applies to all available interfaces.

The TSF shall increment the number of unsuccessful authentication attempts prior to notifying the user that the authentication was unsuccessful. This requirement is to ensure that if power is cut to the device directly after an authentication attempt, the counter will be incremented to reflect that attempt. The evaluator shall ensure that the TSS describes that a value corresponding to the number of unsuccessful authentication attempts since the last successful authentication is kept for each Authentication Factor interface. The evaluator shall ensure that this description also includes if and how this value is maintained when the TOE loses power, either through a graceful powered off or an ungraceful loss of power. The evaluator shall ensure that if the value is not maintained, the interface is after another interface in the boot sequence for which the value is maintained. If the TOE supports multiple authentication mechanisms, the evaluator shall ensure that this description also includes how the unsuccessful authentication attempts for each mechanism selected in FIA_UAU.5.1 is handled. The evaluator shall verify that the TSS describes if each authentication mechanism utilizes its own counter or if multiple authentication mechanisms utilize a shared counter. If multiple authentication mechanisms utilize a shared counter, the evaluator shall verify that the TSS describes this interaction. The evaluator shall confirm that the TSS describes how the process used to determine if the authentication attempt was successful. The evaluator shall ensure that the counter would be updated even if power to the device is cut immediately following notifying the TOE user if the authentication attempt was successful or not. The evaluator shall verify that the AGD guidance describes how the administrator configures the maximum number of unique unsuccessful authentication attempts. The evaluator shall configure the device with all authentication mechanisms selected in FIA_UAU.5.1. The evaluator shall perform the following tests for each available authentication interface: The evaluator shall configure the TOE, according to the AGD guidance, with a maximum number of unsuccessful authentication attempts. The evaluator shall enter the locked state and enter incorrect passwords until the wipe occurs. The evaluator shall verify that the number of password entries corresponds to the configured maximum and that the wipe is implemented. [conditional] If the TOE supports multiple authentication mechanisms the previous test shall be repeated using a combination of authentication mechanisms confirming that the critical authentication mechanisms will cause the device to wipe and that when the maximum number of unsuccessful authentication attempts for a non-critical authentication mechanism is exceeded, the device limits authentication attempts to other available authentication mechanisms. If multiple authentication mechanisms utilize a shared counter, then the evaluator shall verify that the maximum number of unsuccessful authentication attempts can be reached by using each individual authentication mechanism and a combination of all authentication mechanisms that share the counter. The evaluator shall repeat the previous tests, but shall power off (by removing the battery, if possible) the TOE between unsuccessful authentication attempts. The evaluator shall verify that the total number of unsuccessful authentication attempts for each authentication mechanism corresponds to the configured maximum and that the critical authentication mechanisms cause the device to wipe. Alternatively, if the number of authentication failures is not maintained for the interface under test, the evaluator shall verify that upon booting the TOE between unsuccessful authentication attempts another authentication factor interface is presented before the interface under test.

Excess of authentication failure limit

Authentication factor used

This family defines requirements for the composition of password credentials.

requires the TSF to enforce character length and composition requirements for password credentials.

The following actions could be considered for the management functions in FMT: Configuring password policy. There are no auditable events foreseen. FIA_UAU.5 Multiple Authentication Mechanisms

The TSF shall support the following for the Password Authentication Factor: <h:ol> <h:li>Passwords shall be able to be composed of any combination of <selectables> <selectable>upper and lower case letters</selectable> <selectable><assignable>a character set of at least 52 characters</assignable></selectable> </selectables>, numbers, and special characters: <selectables> <selectable>"!"</selectable> <selectable>"@"</selectable> <selectable>"#"</selectable> <selectable>"$"</selectable> <selectable>"%"</selectable> <selectable>"^"</selectable> <selectable>"&"</selectable> <selectable> "*"</selectable> <selectable>"("</selectable> <selectable>")"</selectable> <selectable><assignable>other characters</assignable></selectable> </selectables>; </h:li> <h:li>Password length up to <assignable>an integer greater than or equal to 14</assignable> characters shall be supported. </h:li> </h:ol> While some corporate policies require passwords of 14 characters or better, the use of a REK for DAR protection and key storage protection and the anti-hammer requirement (FIA_TRT_EXT.1) addresses the threat of attackers with physical access using much smaller and less complex passwords. The ST author selects the character set: either the upper and lower case Basic Latin letters or another assigned character set containing at least 52 characters. The assigned character set must be well defined: either according to an international encoding standard (such as Unicode) or defined in the assignment by the ST author. The ST author also selects the special characters that are supported by the TOE; they may optionally list additional special characters supported using the assignment. There are no TSS evaluation activities for this component. The evaluator shall examine the operational guidance to determine that it provides guidance to security administrators on the composition of strong passwords, and that it provides instructions on setting the minimum password length. The evaluator shall compose passwords that either meet the requirements, or fail to meet the requirements, in some way. For each password, the evaluator shall verify that the TOE supports the password. While the evaluator is not required (nor is it feasible) to test all possible compositions of passwords, the evaluator shall ensure that all characters, rule characteristics, and a minimum length listed in the requirement are supported, and justify the subset of those characters chosen for testing.

This family defines requirements for prevention of brute-force authentication attempts.

requires the TSF to limit authentication attempts by number of attempts in a set amount of time.

There are no management activities foreseen. There are no auditable events foreseen. FIA_UAU.5 Multiple Authentication Mechanisms

The TSF shall limit automated user authentication attempts by <selectables> <selectable>preventing authentication via an external port</selectable> <selectable>enforcing a delay between incorrect authentication attempts</selectable> </selectables> for all authentication mechanisms selected in FIA_UAU.5.1. The minimum delay shall be such that no more than 10 attempts can be attempted per 500 milliseconds. The authentication throttling applies to all authentication mechanisms selected in FIA_UAU.5.1. The user authentication attempts in this requirement are attempts to guess the Authentication Factor. The developer can implement the timing of the delays in the requirements using unequal or equal timing of delays. The minimum delay specified in this requirement provides defense against brute forcing. The evaluator shall verify that the TSS describes the method by which authentication attempts are not able to be automated. The evaluator shall ensure that the TSS describes either how the TSF disables authentication via external interfaces (other than the ordinary user interface) or how authentication attempts are delayed in order to slow automated entry and shall ensure that this delay totals at least 500 milliseconds over 10 attempts for all authentication mechanisms selected in FIA_UAU.5.1. There are no guidance evaluation activities for this component. There are no test evaluation activities for this component.

The TSF shall provide <h:b>password and</h:b> <selectables>  <selectable id="uau_biometric"> biometric in accordance with the <xref to="mod-biometrics"/></selectable> <selectable id="uau_hybr"> hybrid</selectable> <selectable exclusive="yes">no other mechanism</selectable> </selectables> to support user authentication. The TSF must support a Password Authentication Factor and may optionally implement a BAF. A hybrid authentication factor is where a user has to submit a combination of PIN/password and biometric sample where both have to pass and if either fails the user is not made aware of which factor failed. If or is selected, then the TSF must be validated against requirements from the . If is selected, does not need to be selected, but should be selected if the biometric authentication can be used independent of the hybrid authentication, i.e., without having to enter a PIN/password. The Password Authentication Factor is configured as defined in FIA_PMG_EXT.1.

The TSF shall authenticate any user's claimed identity according to the <assignable>rules describing how the multiple authentication mechanisms provide authentication</assignable>. Rules regarding how the authentication factors interact in terms of unsuccessful authentication are covered in FIA_AFL_EXT.1. The evaluator shall ensure that the TSS describes each mechanism provided to support user authentication and the rules describing how the authentication mechanisms provide authentication. Specifically, for all authentication mechanisms defined in FIA_UAU.5.1, the evaluator shall ensure that the TSS describes the rules as to how each authentication mechanism is used. Example rules are how the authentication mechanism authenticates the user (i.e., how does the TSF verify that the correct password or biometric sample was entered), the result of a successful authentication (i.e., is the user input used to derive or unlock a key) and which authentication mechanism can be used at which authentication factor interfaces (i.e., if there are times, for example, after a reboot, that only specific authentication mechanisms can be used). If multiple BAFs are claimed in FIA_MBV_EXT.1.1 in the , the interaction between the BAFs must be described. For example, whether the multiple BAFs can be enabled at the same time. The evaluator shall verify that configuration guidance for each authentication mechanism is addressed in the AGD guidance. For each authentication mechanism selected in FIA_UAU.5.1, the evaluator shall enable that mechanism and verify that it can be used to authenticate the user at the specified authentication factor interfaces. For each authentication mechanism rule, the evaluator shall ensure that the authentication mechanisms behave accordingly.

The TSF shall re-authenticate the user <refinement>via the Password Authentication Factor</refinement> under the conditions [<h:i>attempted change to any supported authentication mechanisms</h:i>]. The password authentication factor must be entered before either the password or biometric authentication factor, if selected in FIA_UAU.5.1, can be changed. There are no TSS evaluation activities for this element. There are no guidance evaluation activities for this element. The evaluator shall configure the TSF to use the Password Authentication Factor according to the AGD guidance. The evaluator shall change Password Authentication Factor according to the AGD guidance and verify that the TSF requires the entry of the Password Authentication Factor before allowing the factor to be changed. [conditional] If is selected in FIA_UAU.5.1, for each BAF claimed in FIA_MBV_EXT.1.1 in the the evaluator shall configure the TSF to use the BAF, which includes configuring the Password Authentication Factor, according to the AGD guidance. The evaluator shall change the BAF according to the AGD guidance and verify that the TSF requires the entry of the Password Authentication Factor before allowing the BAF to be changed. [conditional] If is selected in FIA_UAU.5.1, the evaluator shall configure the TSF to use the BAF and PIN or password, which includes configuring the Password Authentication Factor, according to the AGD guidance. The evaluator shall change the BAF and PIN according to the AGD guidance and verify that the TSF requires the entry of the Password Authentication Factor before allowing the factor to be changed.

The TSF shall re-authenticate the user <refinement>via an authentication factor defined in FIA_UAU.5.1</refinement> under the conditions <refinement>TSF-initiated lock, user-initiated lock, <assignable>other conditions</assignable></refinement>. Depending on the selections made in FIA_UAU.5.1, either the password (at a minimum), biometric authentication or hybrid authentication mechanisms can be used to unlock the device. TSF-initiated and user-initiated locking is described in FTA_SSL_EXT.1. There are no TSS evaluation activities for this element. There are no guidance evaluation activities for this element. The evaluator shall configure the TSF to transition to the locked state after a time of inactivity (FMT_SMF_EXT.1) according to the AGD guidance. The evaluator shall wait until the TSF locks and then verify that the TSF requires the entry of the Password Authentication Factor before transitioning to the unlocked state. [conditional] If is selected in FIA_UAU.5.1, for each BAF claimed in FIA_MBV_EXT.1.1 in the the evaluator shall repeat Test 1 verifying that the TSF requires the entry of the BAF before transitioning to the unlocked state. [conditional] If is selected in FIA_UAU.5.1, the evaluator shall repeat Test 1 verifying that the TSF requires the entry of the BAF and PIN/password before transitioning to the unlocked state. The evaluator shall configure user-initiated locking according to the AGD guidance. The evaluator shall lock the TSF and then verify that the TSF requires the entry of the Password Authentication Factor before transitioning to the unlocked state. [conditional] If is selected in FIA_UAU.5.1, for each BAF claimed in FIA_MBV_EXT.1.1 in the the evaluator shall repeat verifying that the TSF requires the entry of the BAF before transitioning to the unlocked state. [conditional] If is selected in FIA_UAU.5.1, the evaluator shall repeat verifying that the TSF requires the entry of the BAF and PIN/password before transitioning to the unlocked state.

User changes Password Authentication Factor

The TSF shall provide only [<h:i>obscured feedback to the device’s display</h:i>] to the user while the authentication is in progress. This applies to all authentication methods defined in FIA_UAU.5.1. The TSF may briefly (1 second or less) display each character or provide an option to allow the user to unmask the password; however, the password must be obscured by default. If is selected in FIA_UAU.5.1, the TSF must not display sensitive information regarding any BAF that could aid an adversary in identifying or spoofing the respective biometric characteristics of a given human user. While it is true that biometric samples, by themselves, are not secret, the analysis performed by the respective biometric algorithms, as well as output data from these biometric algorithms, is considered sensitive and must be kept secret. Where applicable, the TSF must not reveal or make public the reasons for authentication failure. The evaluator shall ensure that the TSS describes the means of obscuring the authentication entry, for all authentication methods defined in FIA_UAU.5.1. The evaluator shall verify that any configuration of this requirement is addressed in the AGD guidance and that the password is obscured by default. The evaluator shall enter passwords on the device, including at least the Password Authentication Factor at lock screen, and verify that the password is not displayed on the device. [conditional] If is selected in FIA_UAU.5.1, for each BAF claimed in FIA_MBV_EXT.1.1 in the the evaluator shall authenticate by producing a biometric sample at lock screen. As the biometric algorithms are performed, the evaluator shall verify that sensitive images, audio, or other information identifying the user are kept secret and are not revealed to the user. Additionally, the evaluator shall produce a biometric sample that fails to authenticate and verify that the reasons for authentication failure (user mismatch, low sample quality, etc.) are not revealed to the user. It is acceptable for the BAF to state that it was unable to physically read the biometric sample, for example, if the sensor is unclean or the biometric sample was removed too quickly. However, specifics regarding why the presented biometric sample failed authentication shall not be revealed to the user.

This family defines requirements for user authentication that are not addressed by FIA_UAU in CC Part 2.

requires the TSF enforce data-at-rest protection until successful authentication has occurred.

There are no management activities foreseen. There are no auditable events foreseen. FDP_DAR_EXT.1 Protected Data Encryption FDP_DAR_EXT.2 Sensitive Data Encryption

The TSF shall require the user to present the Password Authentication Factor prior to decryption of protected data and encrypted DEKs, KEKs and <selectables> <selectable>long-term trusted channel key material</selectable> <selectable>all software-based key storage</selectable> <selectable exclusive="yes">no other keys</selectable> </selectables> at startup. The intent of this requirement is to prevent decryption of protected data before the user has authorized to the device using the Password Authentication Factor. The Password Authentication Factor is also required in order derive the key used to decrypt sensitive data, which includes software-based secure key storage. The evaluator shall verify that the TSS section of the ST describes the process for decrypting protected data and keys. The evaluator shall ensure that this process requires the user to enter a Password Authentication Factor and, in accordance with FCS_CKM_EXT.3, derives a KEK, which is used to protect the software-based secure key storage and (optionally) DEKs for sensitive data, in accordance with FCS_STG_EXT.2. There are no guidance evaluation activities for this component. The following tests may be performed in conjunction with FDP_DAR_EXT.1 and FDP_DAR_EXT.2. Evaluation Activity Note: The following test require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on consumer Mobile Device products. The evaluator shall enable encryption of protected data and require user authentication according to the AGD guidance. The evaluator shall write, or the developer shall provide access to, an application that includes a unique string treated as protected data. The evaluator shall reboot the device, use a tool provided by developer to search for the unique string within the application data, and verify that the unique string cannot be found. The evaluator shall enter the Password Authentication Factor to access full device functionality, use a tool provided by the developer to access the unique string within the application data, and verify that the unique string can be found. [conditional] The evaluator shall require user authentication according to the AGD guidance. The evaluator shall store a key in the software-based secure key storage. The evaluator shall lock the device, use a tool provided by developer to access the key within the stored data, and verify that the key cannot be retrieved or accessed. The evaluator shall enter the Password Authentication Factor to access full device functionality, use a tool provided by developer to access the key, and verify that the key can be retrieved or accessed. [conditional] The evaluator shall enable encryption of sensitive data and require user authentication according to the AGD guidance. The evaluator shall write, or the developer shall provide access to, an application that includes a unique string treated as sensitive data. The evaluator shall lock the device, use a tool provided by developer to attempt to access the unique string within the application data, and verify that the unique string cannot be found. The evaluator shall enter the Password Authentication Factor to access full device functionality, use a tool provided by developer to access the unique string within the application data, and verify that the unique string can be retrieved.

requires the TSF to prevent a subject’s use of TOE until the user is authenticated.

The following actions could be considered for the management functions in FMT: Enabling/disabling display TSF notifications while in the locked state. Enabling/disabling bypass of local user authentication. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP, PP-Module, functional package or ST: Action performed before authentication. No dependencies.

The TSF shall allow <selectables> <selectable> <assignable>list of actions</assignable></selectable> <selectable> no actions</selectable> </selectables> on behalf of the user to be performed before the user is authenticated.

The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. The security relevant actions allowed by unauthorized users in locked state must be listed. At a minimum the actions that correspond to the functions available to the user in FMT_SMF_EXT.1 and are allowed by unauthorized users in locked state should be listed. For example, if the user can enable/disable the camera per function of FMT_SMF_EXT.1 and unauthorized users can take a picture when the device is in locked state, this action must be listed. The evaluator shall verify that the TSS describes the actions allowed by unauthorized users in the locked state. There are no guidance evaluation activities for this component. The evaluator shall attempt to perform some actions not listed in the selection while the device is in the locked state and verify that those actions do not succeed.

Action performed before authentication

requires the TSF to enforce the use of a secondary authentication factor to access certain user data.

There are no management activities foreseen. There are no auditable events foreseen. FDP_ACF_EXT.2 Access Control for System Resources FIA_UAU.5 Multiple Authentication Mechanisms

The TSF shall provide a secondary authentication mechanism for accessing Enterprise applications and resources. The secondary authentication mechanism shall control access to the Enterprise application and shared resources and shall be incorporated into the encryption of protected and sensitive data belonging to Enterprise applications and shared resources. For the BYOD use case, Enterprise applications and data must be protected using a different password than the user authentication to gain access to the personal applications and data, if configured. This requirement must be included in the ST if the TOE implements a container solution, in which there is a separate authentication, to separate user and Enterprise applications and resources. There are no TSS evaluation activities for this element. There are no guidance evaluation activities for this element. The Evaluation Activities for any selected requirements related to device authentication must be separately performed for the secondary authentication mechanism (in addition to activities performed for the primary authentication mechanism). The requirements are: FIA_UAU.6/CREDENTIAL, FIA_UAU.6/LOCKED, FIA_PMG_EXT.1, FIA_TRT_EXT.1, FIA_UAU.7, FIA_UAU_EXT.2, FTA_SSL_EXT.1, FCS_STG_EXT.2, FMT_SMF_EXT.1/FMT_MOF_EXT.1 #1, #2, #8, #21, and #36. Additionally, FIA_AFL_EXT.1 must be met, except that in FIA_AFL_EXT.1.2 the separate test is performed with the text "wipe of all protected data" changed to "wipe of all Enterprise application data and all Enterprise shared resource data."

The TSF shall require the user to present the secondary authentication factor prior to decryption of Enterprise application data and Enterprise shared resource data. The intent of this requirement is to prevent decryption of protected Enterprise application data and Enterprise shared resource data before the user has authenticated to the device using the secondary authentication factor. Enterprise shared resource data consists of the FDP_ACF_EXT.2.1 selections. The evaluator shall verify that the TSS section of the ST describes the process for decrypting Enterprise application data and shared resource data. The evaluator shall ensure that this process requires the user to enter an Authentication Factor and, in accordance with FCS_CKM_EXT.3, derives a KEK which is used to protect the software-based secure key storage and (optionally) DEKs for sensitive data, in accordance with FCS_STG_EXT.2. There are no guidance evaluation activities for this element. There are no test evaluation activities for this element.

This family defines requirements for the management and use of X.509 certificates.

requires the TSF to make a certificate validation service available to environmental components.

There are no management activities foreseen. There are no auditable events foreseen. FIA_X509_EXT.1 X.509 Validation of Certificates

The TSF shall provide a certificate validation service to applications.

The TSF shall respond to the requesting application with the success or failure of the validation. In order to comply with all of the rules in FIA_X509_EXT.1 as defined in the , multiple API calls may be required; all of these calls should be clearly documented. The evaluator shall verify that the API documentation provided in the TSS (or other documentation) includes the security function (certificate validation) described in this requirement. This documentation shall be clear as to which results indicate success and failure. There are no guidance evaluation activities for this component. The evaluator shall write, or the developer shall provide access to, an application that requests certificate validation by the TSF. The evaluator shall verify that the results from the validation match the expected results according to the API documentation. This application may be used to verify that import, removal, modification, and validation are performed correctly according to the tests required by FDP_STG_EXT.1, FTP_ITC_EXT.1, FMT_SMF_EXT.1, and FIA_X509_EXT.1 as defined in the .

Both the user and the administrator may manage the TOE. This administrator is likely to be acting remotely and could be the Mobile Device Management (MDM) Administrator acting through an MDM agent. The Administrator is responsible for management activities, including setting the policy that is applied by the enterprise on the Mobile Device. These management functions are likely to be a different set than those management functions provided to the user. Management functions that are provided to the user and not the administrator are listed in FMT_MOF_EXT.1.1. Management functions for which the administrator may adopt a policy that restricts the user from performing that function are listed in FMT_MOF_EXT.1.2. identifies the management functions that this PP defines, whether they are mandatory or optional, and specifies any restrictions on the roles that can perform these functions. This table is used with FMT_MOF_EXT.1 and FMT_SMF_EXT.1 to specify the management functions that the TOE supports and the roles that may perform these functions.

This family defines requirements for authorization to manage the behavior of the TSF that are not addressed by FMT_MOF in CC Part 2.

requires the TSF to apply restrictions to access its management functions to the authorized roles.

The following actions could be considered for the management functions in FMT: Managing the group of roles that can interact with the functions in the TSF. There are no auditable events foreseen. FMT_SMF.1 Specification of Management Functions FMT_SMR.1 Security Roles

The TSF shall restrict the ability to perform the functions [<h:i>in the "User Only" column of <xref to="fmt_smf"/></h:i>] to the user.

The TSF shall restrict the ability to perform the functions <assignable>reference to list of management functions</assignable> to the user.

The functions that have an "M" in the "User Only" column of are mandatory for this component, thus are restricted to the user, meaning that the administrator cannot manage those functions. The functions that have an "O" in the "User Only" column are optional and may be selected; and those functions with a "-" are not applicable and may not be selected. The ST author should select those security management functions that only the user may perform (i.e., the ones the administrator may not perform). The ST author may use a table in the ST, indicating with clear demarcations (to be accompanied by an index) those functions that are restricted to the user ("User Only" column). The ST author should iterate a row to indicate any variations in the selectable sub-functions or assigned values with respect to the values in the columns. A function cannot contain an "M" in both the "User Only" and "Admin Only" columns. For functions that are mandatory, any sub-functions not in a selection are also mandatory and any assignments must contain at least one assigned value. For non-selectable sub-functions in an optional function, all sub-functions outside a selection must be implemented in order for the function to be listed. The evaluator shall verify that the TSS describes those management functions that may only be performed by the user and confirm that the TSS does not include an Administrator API for any of these management functions. This activity will be performed in conjunction with FMT_SMF_EXT.1. There are no guidance evaluation activities for this element. There are no test evaluation activities for this element.

The TSF shall restrict the ability to perform the functions [<h:i>in the "Admin Only" column of <xref to="fmt_smf"/></h:i>] to the administrator when the device is enrolled and according to the administrator-configured policy.

The TSF shall restrict the ability to perform the functions <assignable>reference to list of management functions</assignable> to the administrator when the device is enrolled and according to the administrator-configured policy.

As long as the device is enrolled in management, the administrator (of the enterprise) must be guaranteed that minimum security functions of the enterprise policy are enforced. Further restrictive policies can be applied at any time by the user on behalf of the user or other administrators. The functions that have an "M" in the "Admin Only" column of are mandatory for this component; the functions that have an "O" in the "Admin Only" column are optional and may be selected; and those functions with a "-" in the "Admin Only" column are not applicable and may not be selected. The ST author should select those security management functions that the administrator may restrict. The ST author may use a table in the ST, indicating with clear demarcations (to be accompanied by an index) those functions that are and are not implemented with APIs for the administrator (as in the "Admin" column). Additionally, the ST author should demarcate which functions the user is prevented from accessing or performing (as in the "Admin Only" column). The ST author should iterate a row to indicate any variations in the selectable sub-functions or assigned values with respect to the values in the columns. A function cannot contain an "M" in both the "User Only" and "Admin Only" columns. For functions that are mandatory, any sub-functions not in a selection are also mandatory and any assignments must contain at least one assigned value. For non-selectable sub-functions in an optional function, all sub-functions outside the selection must be implemented in order for the function to be listed. The evaluator shall verify that the TSS describes those management functions that may be performed by the Administrator, to include how the user is prevented from accessing, performing, or relaxing the function (if applicable), and how applications/APIs are prevented from modifying the Administrator configuration. The TSS also describes any functionality that is affected by administrator-configured policy and how. This activity will be performed in conjunction with FMT_SMF_EXT.1. There are no guidance evaluation activities for this element. The evaluator shall use the test environment to deploy policies to Mobile Devices. The evaluator shall create policies which collectively include all management functions which are controlled by the (enterprise) administrator and cannot be overridden/relaxed by the user as defined in FMT_MOF_EXT.1.2. The evaluator shall apply these policies to devices, attempt to override/relax each setting both as the user (if a setting is available) and as an application (if an API is available), and ensure that the TSF does not permit it. Note that the user may still apply a more restrictive policy than that of the administrator. Additional testing of functions provided to the administrator are performed in conjunction with the testing activities for FMT_SMF_EXT.1.1.

This family defines requirements for security-relevant management functions that are not addressed by FMT_SMF in CC Part 2.

requires the TSF to define the management functions that it implements.

There are no management activities foreseen. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: Initiation of policy update. Change of settings. Success or failure of function Initiation of software update. Initiation of application installation or update. No dependencies.

The TSF shall be capable of performing the following management functions: <h:br/><h:br/> <h:b><ctr id="fmt_smf" ctr-type="Table">: Management Functions</ctr></h:b><h:br/><h:br/> Status Markers:<h:br/> M - Mandatory<h:br/> O - Optional/Objective<h:br/>  <management-function-set default="O"> <manager cid="I">Impl.</manager> <manager cid="U">User Only</manager> <manager cid="A">Admin</manager> <manager cid="AO">Admin Only</manager> <management-function id="mf-pwd"> <text>  configure password policy: <h:ul> <h:li>Minimum password length</h:li> <h:li>Minimum password complexity</h:li> <h:li>Maximum password lifetime</h:li> </h:ul> </text> <M ref="I"/> <NA ref="U"/><M ref="A"/><M ref="AO"/> <aactivity> <TSS>The evaluator shall verify the TSS defines the allowable policy options: the range of values for both password length and lifetime, and a description of complexity to include character set and complexity policies (e.g., configuration and enforcement of number of uppercase, lowercase, and special characters per password).</TSS> <Tests>Test FMT_SMF_EXT.1:1: The evaluator shall exercise the TSF configuration as the administrator and perform positive and negative tests, with at least two values set for each variable setting, for each of the following: <h:br/> <h:ul> <h:li>Minimum password length</h:li> <h:li>Minimum password complexity</h:li> <h:li>Maximum password lifetime</h:li> </h:ul> </Tests> </aactivity> </management-function> <management-function id="mf-screenlock"> <text>  configure session locking policy: <h:ul> <h:li>Screen-lock enabled/disabled</h:li> <h:li>Screen lock timeout </h:li> <h:li>Number of authentication failures</h:li> </h:ul> </text> <M ref="I"/><NA ref="U"/><M ref="A"/><M ref="AO"/> <aactivity> <TSS>The evaluator shall verify the TSS defines the range of values for both timeout period and number of authentication failures for all supported authentication mechanisms.</TSS> <Tests>Test FMT_SMF_EXT.1:2: The evaluator shall exercise the TSF configuration as the administrator. The evaluator shall perform positive and negative tests, with at least two values set for each variable setting, for each of the following: <h:br/> <h:ul> <h:li>Screen-lock enabled/disabled</h:li> <h:li>Screen lock timeout</h:li> <h:li>Number of authentication failures (may be combined with test for FIA_AFL_EXT.1)</h:li> </h:ul> </Tests> </aactivity> </management-function> <management-function id="mf-vpn"> <text>  enable/disable the VPN protection: <h:ul> <h:li>Across device</h:li></h:ul> <h:div class="indent"> <selectables linebreak="yes"> <selectable id="s-vpn-per-app">on a per-app basis</selectable> <selectable id="s-vpn-per-appgroup">on a per-group of applications processes basis</selectable> <selectable exclusive="yes">no other method</selectable> </selectables></h:div> </text> <M ref="I"/> <app-note><also ref-id="mf-audioVisual"/><also ref-id="mf-location"/> Functions <_/> must be implemented on a device-wide basis but may also be implemented on a per-app basis or on a per-group of applications basis in which the configuration includes the list of applications or groups of applications to which the enable/disable applies.</app-note> <app-note> Function <_/> addresses enabling and disabling the IPsec VPN only. The configuration of the VPN Client itself (with information such as VPN Gateway, certificates, and algorithms) is addressed by the <xref to="mod-vpnclient"/>. The administrator options should only be listed if the administrator can remotely enable/disable the VPN connection. <h:p> Function <xref to="mf-vpn"/> optionally allows the VPN to be configured per-app or per-groups of apps. If this configuration is selected, it does not void FDP_IFC_EXT.1. Instead FDP_IFC_EXT.1 is applied to the application or group of applications the VPN is applied to. In other words, all traffic destined for the VPN-enabled application or group of applications, must travel through the VPN, but traffic not destined for that application or group of applications can travel outside the VPN. When the VPN is configured across the device FDP_IFC_EXT.1 applies to all traffic and the VPN must not split tunnel. </h:p> </app-note> <aactivity> <Tests> The evaluator shall perform the following tests: <h:ul> <h:li>Test FMT_SMF_EXT.1:3a: The evaluator shall exercise the TSF configuration to enable the VPN protection. These configuration actions must be used for the testing of the FDP_IFC_EXT.1.1 requirement. </h:li> <h:li>Test FMT_SMF_EXT.1:3b: [conditional] If "<xref to="s-vpn-per-app"/>" is selected, the evaluator shall create two applications and enable one to use the VPN and the other to not use the VPN. The evaluator shall exercise each application (attempting to access network resources; for example, by browsing different websites) individually while capturing packets from the TOE. The evaluator shall verify from the packet capture that the traffic from the VPN-enabled application is encapsulated in IPsec and that the traffic from the VPN-disabled application is not encapsulated in IPsec. </h:li> <h:li>Test FMT_SMF_EXT.1:3c: [conditional] If "<xref to="s-vpn-per-appgroup"/>" is selected, the evaluator shall create two applications and the applications shall be placed into different groups. Enable one application group to use the VPN and the other to not use the VPN. The evaluator shall exercise each application (attempting to access network resources; for example, by browsing different websites) individually while capturing packets from the TOE. The evaluator shall verify from the packet capture that the traffic from the application in the VPN-enabled group is encapsulated in IPsec and that the traffic from the application in the VPN-disabled group is not encapsulated in IPsec. </h:li> </h:ul> </Tests> </aactivity> </management-function> <management-function id="mf-radios"> <text>  enable/disable <assignable id="a-mf-radios">list of all radios</assignable></text> <M ref="I"/> <app-note> The assignment in function <_/> consists of all radios present on the TSF, such as Wi-Fi, cellular, NFC, Bluetooth BR/EDR, and Bluetooth LE, which can be enabled and disabled. Disablement of the cellular radio does not imply that the radio may not be enabled in order to place emergency phone calls; however, it is not expected that a device in "airplane mode", where all radios are disabled, will automatically (without authorization) turn on the cellular radio to place emergency calls.</app-note> <aactivity> <TSS> The evaluator shall verify that the TSS includes a description of each radio and an indication of if the radio can be enabled/disabled along with what role can do so. In addition the evaluator shall verify that the frequency ranges at which each radio operates is included in the TSS. The evaluator shall verify that the TSS includes at what point in the boot sequence the radios are powered on and indicates if the radios are used as part of the initialization of the device. </TSS> <Guidance> The evaluator shall confirm that the AGD guidance describes how to perform the enable/disable function for each radio. </Guidance> <Tests> <h:p> Test FMT_SMF_EXT.1:4: The evaluator shall ensure that minimal signal leakage enters the RF shielded enclosure (i.e., Faraday bag, Faraday box, RF shielded room) by performing the following steps: </h:p> <h:p> Step 1: Place the antenna of the spectrum analyzer inside the RF shielded enclosure. </h:p> <h:p> Step 2: Enable "Max Hold" on the spectrum analyzer and perform a spectrum sweep of the frequency range between 300 MHz - 6000 MHz, in 1 kHz steps (this range should encompass 802.11, 802.15, GSM, UMTS, and LTE). This range will not address NFC 13.56.MHz, another test should be set up with similar constraints to address NFC. </h:p> <h:p> If power above -75 dBm is observed, the Faraday box has too great of signal leakage and shall not be used to complete the test for Function <xref to="mf-radios"/>. </h:p> <h:p> The evaluator shall exercise the TSF configuration as the administrator and, if not restricted to the administrator, the user, to enable and disable the state of each radio (e.g. Wi-Fi, cellular, NFC, Bluetooth). Additionally, the evaluator shall repeat the steps below, booting into any auxiliary boot mode supported by the device. For each radio, the evaluator shall: </h:p> <h:p> Step 1: Place the antenna of the spectrum analyzer inside the RF shielded enclosure. Configure the spectrum analyzer to sweep desired frequency range for the radio to be tested (based on range provided in the TSS)). The ambient noise floor shall be set to -110 dBm. Place the TOE into the RF shielded enclosure to isolate them from all other RF traffic. </h:p> <h:p> Step 2: The evaluator shall create a baseline of the expected behavior of RF signals. The evaluator shall power on the device, ensure the radio in question is enabled, power off the device, enable "Max Hold" on the spectrum analyzer and power on the device. The evaluator shall wait 2 minutes at each Authentication Factor interface prior to entering the necessary password to complete the boot process, waiting 5 minutes after the device is fully booted. The evaluator shall observe that RF spikes are present at the expected uplink channel frequency. The evaluator shall clear the "Max Hold" on the spectrum analyzer. </h:p> <h:p> Step 3: The evaluator shall verify the absence of RF activity for the uplink channel when the radio in question is disabled. The evaluator shall complete the following test five times. The evaluator shall power on the device, ensure the radio in question is disabled, power off the device, enable "Max Hold" on the spectrum analyzer and power on the device. The evaluator shall wait 2 minutes at each Authentication Factor interface prior to entering the necessary password to complete the boot process, waiting 5 minutes after the device is fully booted. The evaluator shall clear the "Max Hold" on the spectrum analyzer. If the radios are used for device initialization, then a spike of RF activity for the uplink channel can be observed initially at device boot. However, if a spike of RF activity for the uplink channel of the specific radio frequency band is observed after the device is fully booted or at an Authentication Factor interface it is deemed that the radio is enabled. </h:p> </Tests> </aactivity> </management-function> <management-function id="mf-audioVisual"> <text>  enable/disable <assignable id="a-audiovisual-devs">list of audio or visual collection devices</assignable>: <h:ul> <h:li>Across device</h:li></h:ul> <h:div class="indent"><selectables linebreak="yes"> <selectable id="s-audiovisual-per-app">on a per-app basis</selectable> <selectable id="s-audiovisual-per-appgroup">on a per-group of applications processes basis</selectable> <selectable exclusive="yes">no other method</selectable> </selectables></h:div> </text> <M ref="I"/> <app-note>The assignment in function <_/> consists of at least one audio or visual device, such as camera and microphone, which can be enabled and disabled by either the user or administrator. Disablement of the microphone does not imply that the microphone may not be enabled in order to place emergency phone calls. If certain devices are able to be restricted to the enterprise (either device-wide, per-app or per-group of applications) and others are able to be restricted to users, then this function should be iterated in the table with the appropriate table entries. <h:p> Regarding functions <xref to="mf-radios"/> and <xref to="mf-audioVisual"/>, disablement of a particular radio or audio/visual device must be effective as soon as the TOE has power. Disablement must also apply when the TOE is booted into auxiliary boot modes, for example, associated with updates or backup. If the TOE supports states in which security management policy is inaccessible, for example, due to data-at-rest protection, it is acceptable to meet this requirement by ensuring that these devices are disabled by default while in these states. That these devices are disabled during auxiliary boot modes does not imply that the device (particularly the cellular radio) may not be enabled in order to perform emergency phone calls. </h:p> </app-note> <aactivity><TSS> The evaluator shall verify that the TSS includes a description of each collection device and an indication of if it can be enabled/disabled along with what role can do so. The evaluator shall confirm that the AGD guidance describes how to perform the enable/disable function. </TSS> <Tests>The evaluator shall perform the following tests: <h:ul> <h:li>Test FMT_SMF_EXT.1:5a: The evaluator shall exercise the TSF configuration as the administrator and, if not restricted to the administrator, the user, to enable and disable the state of each audio or visual collection devices (e.g. camera, microphone) listed by the ST author. For each collection device, the evaluator shall disable the device and then attempt to use its functionality. The evaluator shall reboot the TOE and verify that disabled collection devices may not be used during or early in the boot process. Additionally, the evaluator shall boot the device into each available auxiliary boot mode and verify that the collection device cannot be used. </h:li> <h:li>Test FMT_SMF_EXT.1:5b: [conditional] If "<xref to="s-audiovisual-per-app"/>" is selected, the evaluator shall create two applications and enable one to use access the A/V device and the other to not access the A/V device. The evaluator shall exercise each application attempting to access the A/V device individually. The evaluator shall verify that the enabled application is able to access the A/V device and the disabled application is not able to access the A/V device. </h:li> <h:li>Test FMT_SMF_EXT.1:5c: [conditional] If "<xref to="s-audiovisual-per-appgroup"/>" is selected, the evaluator shall create two applications and the applications shall be placed into different groups. Enable one group to access the A/V device and the other to not access the A/V device. The evaluator shall exercise each application attempting to access the A/V device individually. The evaluator shall verify that the application in the enabled group is able to access the A/V device and the application in the disabled group is not able to access the A/V device. </h:li> </h:ul> </Tests> </aactivity> </management-function> <management-function id="mf-lockState"> <text>   transition to the locked state </text> <M ref="I"/><NA ref="U"/><M ref="A"/><NA ref="AO"/> <aactivity><Tests>Test FMT_SMF_EXT.1:6: The evaluator shall use the test environment to instruct the TSF, both as a user and as the administrator, to command the device to transition to a locked state, and verify that the device transitions to the locked state upon command. </Tests></aactivity> </management-function> <management-function id="mf-wipe"> <text>   TSF wipe of protected data </text> <M ref="I"/> <NA ref="U"/> <M ref="A"/> <NA ref="AO"/> <app-note> Wipe of the TSF (function <xref to="mf-wipe"/>) is performed as defined in FCS_CKM_EXT.5. Protected data is all non-TSF data, including all user or enterprise data. Some or all of this data may be considered sensitive data as well.</app-note> <aactivity> <Tests>Test FMT_SMF_EXT.1:7: The evaluator shall use the test environment to instruct the TSF, both as a user and as the administrator, to command the device to perform a wipe of protected data. The evaluator shall ensure that this management setup is used when conducting the Evaluation Activities in FCS_CKM_EXT.5.</Tests> </aactivity> </management-function> <management-function id="mf-appInstallRules"> <text>   configure application installation policy by <h:div class="indent"><selectables linebreak="yes"> <selectable id="mf-appInstallRules-restrict">restricting the sources of applications</selectable> <selectable id="mf-appInstallRules-specify">specifying a set of allowed applications based on <assignable>application characteristics</assignable> (an <snip>application allowlist</snip>)</selectable> <selectable id="mf-appInstallRules-deny">denying installation of applications</selectable> </selectables></h:div> </text> <M ref="I"/><NA ref="U"/><M ref="A"/><M ref="AO"/> <app-note> The selection in function <xref to="mf-appInstallRules"/> allows the ST author to select which mechanisms are available to the administrator through the MDM agent to restrict the applications which the user may install. The ST author must state if application allowlist is applied device-wide or if it can be specified to apply to either the Enterprise or Personal applications. <h:ul> <h:li>If the administrator can restrict the sources from which applications can be installed, the ST author selects "<xref to="mf-appInstallRules-restrict"/>". </h:li> <h:li>If the administrator can specify a allowlist of allowed applications, the ST author selects "<xref to="mf-appInstallRules-specify"/>". The ST author should list any application characteristics (e.g. name, version, or developer) based on which the allowlist can be formed.</h:li> <h:li>If the administrator can prevent the user from installing additional applications, the ST author selects "<xref to="mf-appInstallRules-deny"/>". </h:li> </h:ul> </app-note> <aactivity><TSS> The evaluator shall verify the TSS describes the allowable application installation policy options based on the selection included in the ST. If the <xref to="mf-appInstallRules-specify"/> is selected, the evaluator shall verify that the TSS includes a description of each application characteristic upon which the allowlist may be based. </TSS> <Tests> The evaluator shall exercise the TSF configuration as the administrator to restrict particular applications, sources of applications, or application installation according to the AGD guidance. The evaluator shall attempt to install unauthorized applications and ensure that this is not possible. The evaluator shall, in conjunction, perform the following specific tests: <h:ul> <h:li>Test FMT_SMF_EXT.1:8a: [conditional] The evaluator shall attempt to connect to an unauthorized repository in order to install applications. </h:li> <h:li>Test FMT_SMF_EXT.1:8b: [conditional] The evaluator shall attempt to install two applications (one allowlisted, and one not) from a known allowed repository and verify that the application not on the allowlist is rejected. The evaluator shall also attempt to side-load executables or installation packages via USB connections to determine that the white list is still adhered to </h:li> </h:ul> </Tests> </aactivity> </management-function> <management-function id="mf-keyStorage"> <text>   import keys or secrets into the secure key storage </text> <M ref="I"/><NA ref="AO"/> <aactivity><also ref-id="mf-keyWipe"/> <TSS>The evaluator shall verify that the TSS describes each category of keys or secrets that can be imported into the TSF’s secure key storage.</TSS> <Tests> The test of these functions is performed in association with FCS_STG_EXT.1. </Tests> </aactivity> </management-function> <management-function id="mf-keyWipe"> <text>   destroy imported keys or secrets and <selectables> <selectable exclusive="yes">no other keys or secrets</selectable> <selectable><assignable>list of other categories of keys or secrets</assignable></selectable> </selectables> in the secure key storage </text> <M ref="I"/><NA ref="AO"/> </management-function> <management-function id="mf-certImport"> <text>   import X.509v3 certificates into the Trust Anchor Database </text> <M ref="I"/><NA ref="U"/><M ref="A"/> <aactivity> <Guidance>The evaluator shall review the AGD guidance to determine that it describes the steps needed to import, modify, or remove certificates in the Trust Anchor database, and that the users that have authority to import those certificates (e.g., only administrator, or both administrators and users) are identified. </Guidance> <Tests> Test FMT_SMF_EXT.1:11: The evaluator shall import certificates according to the AGD guidance as the user or as the administrator, as determined by the administrative guidance. The evaluator shall verify that no errors occur during import. The evaluator should perform an action requiring use of the X.509v3 certificate to provide assurance that installation was completed properly. </Tests> </aactivity> </management-function> <management-function id="mf-certWipe"> <text>   remove imported X.509v3 certificates and <selectables> <selectable exclusive="yes">no other X.509v3 certificates</selectable> <selectable><assignable>list of other categories of X.509v3 certificates</assignable></selectable> </selectables> in the Trust Anchor Database </text> <M ref="I"/><NA ref="AO"/> <app-note> In the future, function <xref to="mf-certWipe"/> may require destruction or disabling of any default trusted CA certificates, excepting those CA certificates necessary for continued operation of the TSF, such as the developer’s certificate. At this time, the ST author must indicate in the assignment whether pre-installed or any other category of X.509v3 certificates may be removed from the Trust Anchor Database. </app-note> <aactivity> <TSS> The evaluator shall verify that the TSS describes each additional category of X.509 certificates and their use within the TSF. </TSS> <Tests> Test FMT_SMF_EXT.1:12: The evaluator shall remove an administrator-imported certificate and any other categories of certificates included in the assignment of function <xref to="mf-appRemove"/> from the Trust Anchor Database according to the AGD guidance as the user and as the administrator. </Tests> </aactivity> </management-function> <management-function id="mf-enroll"> <text>   enroll the TOE in management </text> <M ref="I"/><O ref="U"/><O ref="A"/><O ref="AO"/> <app-note> For function <xref to="mf-enroll"/>, the enrollment function may be installing an MDM agent and includes the policies to be applied to the device. It is acceptable for the user approval notice to require the user to intentionally opt to view the policies (for example, by "tapping" on a "View" icon) rather than listing the policies in full in the notice. </app-note> <aactivity> <TSS>The evaluator shall examine the TSS to ensure that it contains a description of each management function that will be enforced by the enterprise once the device is enrolled. The evaluator shall examine the AGD guidance to determine that this same information is present. </TSS> <Tests> Test FMT_SMF_EXT.1:13: The evaluator shall verify that user approval is required to enroll the device into management. </Tests> </aactivity> </management-function> <management-function id="mf-appRemove"> <text>   remove applications </text> <M ref="I"/><NA ref="U"/><M ref="A"/> <aactivity><TSS> The evaluator shall verify that the TSS includes an indication of what applications (e.g., user-installed applications, Administrator-installed applications, or Enterprise applications) can be removed along with what role can do so. The evaluator shall examine the AGD guidance to determine that it details, for each type of application that can be removed, the procedures necessary to remove those applications and their associated data. For the purposes of this Evaluation Activity, "associated data" refers to data that are created by the app during its operation that do not exist independent of the app's existence, for instance, configuration data, or e-mail information that’s part of an e-mail client. It does not, on the other hand, refer to data such as word processing documents (for a word processing app) or photos (for a photo or camera app). </TSS><Tests> Test FMT_SMF_EXT.1:14: The evaluator shall attempt to remove applications according to the AGD guidance and verify that the TOE no longer permits users to access those applications or their associated data.</Tests></aactivity> </management-function> <management-function id="mf-update"> <text>   update system software </text> <M ref="I"/><NA ref="U"/><M ref="A"/> <app-note> For function <xref to="mf-update"/>, the administrator capability to update the system software may be limited to causing a prompt to the user to update rather than the ability to initiate the update itself. As the administrator is likely to be acting remotely, he/she would be unaware of inopportune situations, such as low power, which may cause the update to fail and the device to become inoperable. The user can refuse to accept the update in such situations. It is expected that system architects will be cognizant of this limitation and will enforce network access controls in order to enforce enterprise-critical updates. </app-note> <aactivity><Tests>Test FMT_SMF_EXT.1:15: The evaluator shall attempt to update the TSF system software following the procedures in the AGD guidance and verify that updates correctly install and that the version numbers of the system software increase. </Tests></aactivity> </management-function> <management-function id="mf-appInstall"> <text>   install applications </text> <M ref="I"/><NA ref="U"/><M ref="A"/> <app-note> Function <xref to="mf-appInstall"/> addresses both installation and update. This protection profile does not distinguish between installation and update of applications because mobile devices typically completely overwrite the previous installation with a new installation during an application update. </app-note> <aactivity><Tests>Test FMT_SMF_EXT.1:16: The evaluator shall attempt to install an application following the procedures in the AGD guidance and verify that the application is installed and available on the TOE.</Tests></aactivity> </management-function> <management-function id="mf-entAppRemove"> <text>   remove Enterprise applications </text> <M ref="I"/><NA ref="U"/><M ref="A"/><NA ref="AO"/> <app-note> For function <xref to="mf-entAppRemove"/>, "Enterprise applications" are those applications that belong to the Enterprise application group. Applications installed by the enterprise administrator (including automatic installation by the administrator after being requested by the user from a catalog of enterprise applications) are by default placed in the Enterprise application group unless an exception has been made in function <xref to="mf-appGroups"/> of FMT_SMF_EXT.1.1. </app-note> <aactivity><Tests> Test FMT_SMF_EXT.1:17: The evaluator shall attempt to remove any Enterprise applications from the device by following the administrator guidance. The evaluator shall verify that the TOE no longer permits users to access those applications or their associated data.</Tests></aactivity> </management-function> <management-function id="mf-notifications"> <text>   enable/disable display notification in the locked state of: <selectables linebreak="yes"> <selectable>email notifications</selectable> <selectable>calendar appointments</selectable> <selectable>contact associated with phone call notification</selectable> <selectable>text message notification</selectable> <selectable><assignable>other application-based notifications</assignable></selectable> <selectable>all notifications</selectable> </selectables> </text> <M ref="I"/> <app-note> If the display of notifications in the locked state is supported, the configuration of these notifications (function <xref to="mf-notifications"/>) must be included in the selection. </app-note> <aactivity><Guidance>The evaluator shall examine the AGD Guidance to determine that it specifies, for at least each category of information selected for Function <xref to="mf-notifications"/>, how to enable and disable display information for that type of information in the locked state. </Guidance> <Tests>Test FMT_SMF_EXT.1:18: For each category of information listed in the AGD guidance, the evaluator shall verify that when that TSF is configured to limit the information according to the AGD, the information is no longer displayed in the locked state.</Tests> </aactivity> </management-function> <management-function id="mf-dar"> <text>   enable data-at rest protection </text> <M ref="I"/> <app-note> Function <xref to="mf-dar"/> must be included in the selection if data-at-rest protection is not natively enabled. </app-note> <aactivity><Tests> Test FMT_SMF_EXT.1:19: The evaluator shall exercise the TSF configuration as the administrator and, if not restricted to the administrator, the user, to enable system-wide data-at-rest protection according to the AGD guidance. The evaluator shall ensure that all Evaluation Activities for DAR protection (FDP_DAR_EXT) are conducted with the device in this configuration. </Tests></aactivity> </management-function> <management-function id="mf-rmediaDar"> <text>   enable removable media’s data-at-rest protection </text> <M ref="I"/> <app-note> Function <xref to="mf-rmediaDar"/> is implicitly met if the TSF does not support removable media. </app-note> <aactivity><Tests> Test FMT_SMF_EXT.1:20: The evaluator shall exercise the TSF configuration as the administrator and, if not restricted to the administrator, the user, to enable removable media’s data-at-rest protection according to the AGD guidance. The evaluator shall ensure that all Evaluation Activities for DAR protection (FDP_DAR_EXT) are conducted with the device in this configuration. </Tests></aactivity> </management-function> <management-function id="mf-location"> <text>   enable/disable location services: <h:ul> <h:li>Across device</h:li></h:ul> <h:div class="indent"><selectables linebreak="yes"> <selectable id="mf-location-per_app">on a per-app basis</selectable> <selectable>on a per-group of applications processes basis</selectable> <selectable exclusive="yes">no other method</selectable> </selectables></h:div> </text> <M ref="I"/> <app-note> For function <xref to="mf-location"/>, location services include location information gathered from GPS, cellular, and Wi-Fi. </app-note> <aactivity><Tests> The evaluator shall perform the following tests. <h:ul> <h:li>Test FMT_SMF_EXT.1:21a: The evaluator shall enable location services device-wide and shall verify that an application (such as a mapping application) is able to access the TOE’s location information. The evaluator shall disable location services device-wide and shall verify that an application (such as a mapping application) is unable to access the TOE’s location information. </h:li> <h:li>Test FMT_SMF_EXT.1:21b: [conditional] If <xref to="mf-location-per_app"/> is selected, the evaluator shall create two applications and enable one to use access the location services and the other to not access the location services. The evaluator shall exercise each application attempting to access location services individually. The evaluator shall verify that the enabled application is able to access the location services and the disabled application is not able to access the location services. </h:li> </h:ul></Tests></aactivity> </management-function> <management-function id="mf-authFactors"> <text>  enable/disable the use of <selectables> <selectable>Biometric Authentication Factor</selectable> <selectable>Hybrid Authentication Factor</selectable> </selectables> </text> <app-note> Function <xref to="mf-authFactors"/> must be included in the ST if the TOE contains a BAF. This selection must correspond with the selection made in FIA_UAU.5.1. If <xref to="uau_biometric"/> is selected in FIA_UAU.5.1, "Biometric Authentication Factor" must be selected and the user or admin must have the option to disable the use of it. If multiple BAFs are claimed in FIA_MBV_EXT.1.1 in the <xref to="mod-biometrics"/>, this applies to all different modalities. If <xref to="uau_hybr"/> is selected in FIA_UAU.5.1 it must be selected and the user or admin must have the option to disable the use of it. </app-note> <aactivity><Tests> The evaluator shall verify that the TSS states if the TOE supports a BAF or hybrid authentication. If the TOE does not include a BAF or hybrid authentication this test is implicitly met.<h:ul> <h:li>Test FMT_SMF_EXT.1:22a: [conditional] If <xref to="uau_biometric"/> is selected in FIA_UAU.5.1, for each BAF claimed in FIA_MBV_EXT.1.1 in the <xref to="mod-biometrics"/> the evaluator shall verify that the TSS describes the procedure to enable/disable the BAF. The evaluator shall configure the TOE to allow each supported BAF to authenticate and verify that successful authentication can be achieved using the BAF. The evaluator shall configure the TOE to disable the use of each supported BAF for authentication and confirm that the BAF cannot be used to authenticate. </h:li> <h:li>Test FMT_SMF_EXT.1:22b: [conditional] If <xref to="uau_hybr"/> is selected the evaluator shall verify that the TSS describes the procedure to enable/disable the hybrid (biometric credential and PIN/password) authentication. The evaluator shall configure the TOE to allow hybrid authentication to authenticate and confirm that successful authentication can be achieved using the hybrid authentication. The evaluator shall configure the TOE to disable the use of hybrid authentication and confirm that the hybrid authentication cannot be used to authenticate. </h:li> </h:ul> </Tests></aactivity> </management-function> <management-function id="mf-certInvalid"> <text>  configure whether to allow or disallow establishment of <assignable>configurable trusted channel in FTP_ITC_EXT.1.1 or FDP_UPC_EXT.1.1/APPS</assignable> if the peer or server certificate is deemed invalid.</text> <app-note>  Function <xref to="mf-certInvalid"/> must be included in the ST if the function is configurable on the TOE for any of the trusted channels either mandated or selected in <xref to="fel-wlan"/> or <xref to="fel-tls-app"/>. The configuration can be different depending on the specific trusted channel(s) and they must be filled in for the assignment. </app-note> <aactivity><Tests>The test of this function is performed in conjunction with FIA_X509_EXT.2.2 in <xref to="X509"/> and FCS_TLSC_EXT.1.6 in the <xref to="tls"/>. </Tests></aactivity> </management-function>  <management-function id="mf-externalPorts"> <text>  enable/disable all data signaling over <assignable>list of externally accessible hardware ports</assignable> </text> <app-note>  The assignment in function <xref to="mf-externalPorts"/> consists of all externally accessible hardware ports, such as USB, the SD card, and HDMI, whose data transfer capabilities can be enabled and disabled by either the user or administrator. Disablement of data transfer over an external port must be effective during and after boot into the normal operative mode of the device. If the TOE supports states in which configured security management policy is inaccessible, for example, due to data-at-rest protection, it is acceptable to meet this requirement by ensuring that data transfer is disabled by default while in these states. Each of the ports may be enabled or disabled separately. The configuration policy need not disable all ports together. In the case of USB, charging is still allowed if data transfer capabilities have been disabled. </app-note> <aactivity><TSS> The evaluator shall verify that the TSS includes a list of each externally accessible hardware port and an indication of if data transfer over that port can be enabled/disabled. AGD guidance will describe how to perform the enable/disable function.</TSS> <Tests>Test FMT_SMF_EXT.1:24: The evaluator shall exercise the TSF configuration to enable and disable data transfer capabilities over each externally accessible hardware ports (e.g. USB, SD card, HDMI) listed by the ST author. The evaluator shall use test equipment for the particular interface to ensure that while the TOE may continue to receive data on the RX pins, it is not responding on TX pins used for data transfer when they are disabled. For each disabled data transfer capability, the evaluator shall repeat this test by rebooting the device into the normal operational mode and verifying that the capability is disabled throughout the boot and early execution stage of the device.</Tests> </aactivity> </management-function> <management-function id="mf-serverProtocols"> <text>  enable/disable <assignable id="a-server">list of protocols where the device acts as a server</assignable> </text> <app-note> The assignment in function <xref to="mf-serverProtocols"/> consists of all protocols where the TSF acts as a server, which can be enabled and disabled by either the user or administrator. Hotspot tethering is not a 'protocol' as defined by this function. This is defined in management function WL-3 of <xref to="mod-wlanclient"/>. </app-note> <aactivity><TSS> The evaluator shall verify that the TSS describes how the TSF acts as a server in each of the protocols listed in the ST, and the reason for acting as a server.</TSS> <Tests> Test FMT_SMF_EXT.1:25: The evaluator shall attempt to disable each listed protocol in the assignment. The evaluator shall verify that remote devices can no longer access the TOE or TOE resources using any disabled protocols. </Tests> </aactivity> </management-function> <management-function id="mf-devModes"> <text>  enable/disable developer modes </text> <app-note> Function <xref to="mf-devModes"/> must be included in the selection if developer modes are supported by the TSF. </app-note> <aactivity><Tests> Test FMT_SMF_EXT.1:26: The evaluator shall exercise the TSF configuration as the administrator and, if not restricted to the administrator, the user, to enable and disable any developer mode. The evaluator shall test that developer mode access is not available when its configuration is disabled. The evaluator shall verify the developer mode remains disabled during device reboot.</Tests></aactivity> </management-function> <management-function id="mf-authBypass"> <text>  enable/disable bypass of local user authentication </text> <app-note> Function <xref to="mf-authBypass"/> must be included in the selection if bypass of local user authentication, such as a "Forgot Password", password hint, or remote authentication feature, is supported. </app-note> <aactivity><Guidance>The evaluator shall examine the AGD guidance to determine that it describes how to enable and disable any "Forgot Password", password hint, or remote authentication (to bypass local authentication mechanisms) capability. </Guidance> <Tests>Test FMT_SMF_EXT.1:27: For each mechanism listed in the AGD guidance that provides a "Forgot Password" feature or other means where the local authentication process can be bypassed, the evaluator shall disable the feature and ensure that they are not able to bypass the local authentication process.</Tests></aactivity> </management-function> <management-function id="mf-wipeEntData"> <text>  wipe Enterprise data </text> <NA ref="AO"/> <aactivity><Tests> Test FMT_SMF_EXT.1:28: The evaluator shall attempt to wipe Enterprise data resident on the device according to the administrator guidance. The evaluator shall verify that the data is no longer accessible by the user.</Tests></aactivity> </management-function> <management-function id="mf-appCert"> <text>  approve <selectables> <selectable>import</selectable> <selectable>removal</selectable> </selectables> by applications of X.509v3 certificates in the Trust Anchor Database </text> <app-note> Function <xref to="mf-appCert"/> must be included in the selection if the TSF allows applications, other than MDM agents, to import or remove X.509v3 certificates from the Trust Anchor Database. The MDM agent is considered to be acting as the administrator. This function does not apply to applications trusting a certificate for its own validations. The function only applies to situations where the application modifies the device-wide Trust Anchor Database, affecting the validations performed by the TSF for other applications. The user or administrator may be provided the ability to globally allow or deny any application requests in order to meet this requirement. </app-note> <aactivity><TSS> The evaluator shall verify that the TSS describes how approval for an application to perform the selected action (import, removal) with respect to certificates in the Trust Anchor Database is accomplished (e.g., a pop-up, policy setting, etc.). <h:br/><h:br/> The evaluator shall also verify that the API documentation provided in the TSS (or other documentation) includes any security functions (import, modification, or destruction of the Trust Anchor Database) allowed by applications. </TSS> <Tests>The evaluator shall perform one of the following tests: <h:ul> <h:li>Test FMT_SMF_EXT.1:29a: [conditional] If applications may import certificates to the Trust Anchor Database, the evaluator shall write, or the developer shall provide access to, an application that imports a certificate into the Trust Anchor Database. The evaluator shall verify that the TOE requires approval before allowing the application to import the certificate: <h:ul> <h:li>The evaluator shall deny the approvals to verify that the application is not able to import the certificate. Failure of import shall be tested by attempting to validate a certificate that chains to the certificate whose import was attempted (as described in the evaluation activity for FIA_X509_EXT.1 as defined in the <xref to="X509"/>). </h:li> <h:li>The evaluator shall repeat the test, allowing the approval to verify that the application is able to import the certificate and that validation occurs. </h:li> </h:ul> </h:li> <h:li>Test FMT_SMF_EXT.1:29b: [conditional] If applications may remove certificates in the Trust Anchor Database, the evaluator shall write, or the developer shall provide access to, an application that removes certificates from the Trust Anchor Database. The evaluator shall verify that the TOE requires approval before allowing the application to remove the certificate: <h:ul> <h:li>The evaluator shall deny the approvals to verify that the application is not able to remove the certificate. Failure of removal shall be tested by attempting to validate a certificate that chains to the certificate whose removal was attempted (as described in the evaluation activity for FIA_X509_EXT.1 as defined in the <xref to="X509"/>). <h:p/> The evaluator shall repeat the test, allowing the approval to verify that the application is able to remove/modify the certificate and that validation no longer occurs. </h:li> </h:ul> </h:li> </h:ul> </Tests> </aactivity> </management-function> <management-function id="mf-certValidity"> <text>  configure whether to allow or disallow establishment of a trusted channel if the TSF cannot establish a connection to determine the validity of a certificate</text> <app-note> Function <xref to="mf-certValidity"/> must be included in the ST if "administrator is allowed to configure certificate acceptance" is selected in FIA_X509_EXT.2.2 in <xref to="X509"/> </app-note> <aactivity><Tests>The test of this function is performed in conjunction with FIA_X509_EXT.2.2 in <xref to="X509"/>.</Tests></aactivity> </management-function> <management-function id="mf-cellular"> <text>  enable/disable the cellular protocols used to connect to cellular network base stations </text> <aactivity><TSS>The evaluator shall ensure that the TSS describes which cellular protocols can be disabled.</TSS> <Guidance>The evaluator shall confirm that the AGD guidance describes the procedure for disabling each cellular protocol identified in the TSS. </Guidance> <Tests>Test FMT_SMF_EXT.1:31: The evaluator shall attempt to disable each cellular protocol according to the administrator guidance. The evaluator shall attempt to connect the device to a cellular network and, using network analysis tools, verify that the device does not allow negotiation of the disabled protocols.</Tests></aactivity> </management-function> <management-function id="mf-auditLogs"> <text>  read audit logs kept by the TSF </text> <M ref="I"/> <NA ref="U"/><M ref="A"/><NA ref="AO"/> <aactivity><Tests>Test FMT_SMF_EXT.1:32: The evaluator shall attempt to read any device audit logs according to the administrator guidance and verify that the logs may be read. This test may be performed in conjunction with the evaluation activity of FAU_GEN.1.</Tests></aactivity> </management-function> <management-function id="mf-digSign"> <text>  configure <selectables> <selectable>certificate</selectable> <selectable>public-key</selectable> </selectables> used to validate digital signature on applications </text> <app-note> Function <xref to="mf-digSign"/> should be included in the selection if FPT_TUD_EXT.5.1 is included in the ST and the configurable option is selected. </app-note> <aactivity><Tests> The test of this function is performed in conjunction with FPT_TUD_EXT.5.1. </Tests></aactivity> </management-function> <management-function id="mf-sharedKeys"> <text>  approve exceptions for shared use of keys or secrets by multiple applications </text> <app-note> Function <xref to="mf-sharedKeys"/> should be included in the selection if user or administrator is selected in FCS_STG_EXT.1.4. </app-note> <aactivity><TSS>The evaluator shall verify that the TSS describes how the approval for exceptions for shared use of keys or secrets by multiple applications is accomplished (e.g., a pop-up, policy setting, etc.).</TSS><Tests> The test of this function is performed in conjunction with FCS_STG_EXT.1. </Tests></aactivity> </management-function> <management-function id="mf-keyWipeRules"> <text>  approve exceptions for destruction of keys or secrets by applications that did not import the key or secret </text> <app-note> Function <xref to="mf-keyWipeRules"/> should be included in the selection if <xref to="s-killkey-user"/> or <xref to="s-killkey-admin"/> is selected in FCS_STG_EXT.1.5.  </app-note> <aactivity><TSS>The evaluator shall verify that the TSS describes how the approval for exceptions for destruction of keys or secrets by applications that did not import the key or secret is accomplished (e.g., a pop-up, policy setting, etc.). </TSS><Tests> The test of this function is performed in conjunction with FCS_STG_EXT.1. </Tests> </aactivity> </management-function> <management-function id="mf-unlockBanner"> <text>  configure the unlock banner </text> <M ref="I"/> <NA ref="U"/> <app-note>  </app-note> <aactivity><TSS> The evaluator shall verify that the TSS describes any restrictions in banner settings (e.g., character limitations). </TSS><Tests> The test of this function is performed in conjunction with FTA_TAB.1. </Tests></aactivity> </management-function> <management-function id="mf-auditItems"> <text>  configure the auditable items </text> <NA ref="U"/> <app-note> Function <xref to="mf-auditItems"/> must be included in the selection if FAU_SEL.1 is included in the ST. </app-note> <aactivity><Tests>The test of this function is performed in conjunction with FAU_SEL.1.</Tests></aactivity> </management-function> <management-function id="mf-integ"> <text>  retrieve TSF-software integrity verification values </text> <aactivity><Tests>The test of this function is performed in conjunction with FPT_NOT_EXT.2.1.</Tests></aactivity> </management-function> <management-function id="mf-USB"> <text>  enable/disable <selectables linebreak="yes"> <selectable id="s-usbstore">USB mass storage mode</selectable> <selectable>USB data transfer without user authentication</selectable> <selectable>USB data transfer without authentication of the connecting system</selectable> </selectables> </text> <aactivity><TSS>The evaluator shall verify that the TSS includes a description of how data transfers can be managed over USB.</TSS> <Tests>The evaluator shall perform the following tests based on the selections made: <h:ul> <h:li>Test FMT_SMF_EXT.1:39a: [conditional] The evaluator shall disable USB mass storage mode, attach the device to a computer, and verify that the computer cannot mount the TOE as a drive. The evaluator shall reboot the TOE and repeat this test with other supported auxiliary boot modes. </h:li> <h:li>Test FMT_SMF_EXT.1:39b: [conditional] The evaluator shall disable USB data transfer without user authentication, attach the device to a computer, and verify that the TOE requires user authentication before the computer can access TOE data. The evaluator shall reboot the TOE and repeat this test with other supported auxiliary boot modes. </h:li> <h:li>Test FMT_SMF_EXT.1:39c: [conditional] The evaluator shall disable USB data transfer without connecting system authentication, attach the device to a computer, and verify that the TOE requires connecting system authentication before the computer can access TOE data. The evaluator shall then connect the TOE to another computer and verify that the computer cannot access TOE data. The evaluator shall then connect the TOE to the original computer and verify that the computer can access TOE data. </h:li> </h:ul></Tests> </aactivity> </management-function> <management-function id="mf-backup"> <text>  enable/disable backup of <selectables> <selectable id="s-backup-all-apps">all applications</selectable> <selectable id="s-backup-sel-apps">selected applications</selectable> <selectable id="s-backup-sel-grps">selected groups of applications</selectable> <selectable id="s-backup-cfg">configuration data</selectable> </selectables> to <selectables> <selectable>locally connected system</selectable> <selectable>remote system</selectable> </selectables> </text> <aactivity><TSS>The evaluator shall verify that the TSS includes a description of available backup methods that can be enabled/disabled. If "selected applications" or "selected groups of applications" are selected the TSS shall include which applications of groups of applications backup can be enabled/disabled.</TSS> <Tests> <h:ul> <h:li>Test FMT_SMF_EXT.1:40a: [conditional] If <xref to="s-backup-all-apps"/> is selected, the evaluator shall disable each selected backup location in turn and verify that the TOE cannot complete a backup. The evaluator shall then enable each selected backup location in turn and verify that the TOE can perform a backup.</h:li> <h:li>Test FMT_SMF_EXT.1:40b: [conditional] If <xref to="s-backup-sel-apps"/> is selected, the evaluator shall disable each selected backup location in turn and verify that for the selected application the TOE prevents backup from occurring. The evaluator shall then enable each selected backup location in turn and verify that for the selected application the TOE can perform a backup.</h:li> <h:li>Test FMT_SMF_EXT.1:40c: [conditional] If <xref to="s-backup-sel-grps"/> is selected, the evaluator shall disable each selected backup location in turn and verify that for a group of applications the TOE prevents the backup from occurring. The evaluator shall then enable each selected backup location in turn and verify for the group of application the TOE can perform a backup. </h:li> <h:li>Test FMT_SMF_EXT.1:40d: [conditional] If <xref to="s-backup-cfg"/> is selected, the evaluator shall disable each selected backup location in turn and verify that the TOE prevents the backup of configuration data from occurring. The evaluator shall then enable each selected backup location in turn and verify that the TOE can perform a backup of configuration data.</h:li> </h:ul> </Tests></aactivity> </management-function> <management-function id="mf-tethering"> <text>  enable/disable <selectables linebreak="yes"> <selectable>Bluetooth tethering</selectable> <selectable id="s-tether"><snip>USB tethering</snip> authenticated by <selectables> <selectable>device authentication</selectable> <selectable>USB device identifier</selectable> <selectable exclusive="yes">no authentication</selectable> </selectables> </selectable> </selectables> </text> <app-note> Function <xref to="mf-tethering"/>, device authentication for USB tethering refers to the user needing to authenticate themselves to the mobile device and unlock it in order to initiate a tethered connection. USB device authentication references the use of device filtration to permit or reject tethering for certain connected devices or types of devices. </app-note> <aactivity><TSS> The evaluator shall verify that the TSS includes a description of Bluetooth or USB tethering functionality as claimed in the function. If USB tethering is supported, the evaluator shall verify that it includes the method used for authentication USB connections.</TSS> <Tests>The evaluator shall perform the following tests based on the selections in Function <xref to="mf-tethering"/>. <h:ul> <h:li>Test FMT_SMF_EXT.1:41a: [conditional] The evaluator shall enable Bluetooth tethering functionality. The evaluator shall use a Bluetooth device to connect to the TOE and verify that tethering functionality is implemented. The evaluator shall disable Bluetooth tethering functionality and verify that the function has been disabled.</h:li> <h:li>Test FMT_SMF_EXT.1:41b: [conditional] The evaluator shall enable USB tethering functionality with each of supported authentication methods. The evaluator shall connect to the TOE over USB with another device and verify that the tethering functionality requires the configured authentication method. </h:li> </h:ul></Tests></aactivity> </management-function> <management-function id="mf-dataSharing"> <text>  approve exceptions for sharing data between <selectables> <selectable>applications</selectable> <selectable>groups of applications</selectable> </selectables></text> <app-note> Functions <xref to="mf-dataSharing"/> and <xref to="mf-appGroups"/> correspond to FDP_ACF_EXT.1.2. </app-note> <aactivity><Tests>The test of this function is performed in conjunction with FDP_ACF_EXT.1.2.</Tests></aactivity> </management-function> <management-function id="mf-appGroups"> <text>  place applications into application groups based on <assignable>enterprise configuration settings</assignable></text> <aactivity><Tests> Test FMT_SMF_EXT.1:43: The evaluator shall set a policy to cause a designated application to be placed into a particular application group. The evaluator shall then install the designated application and verify that it was placed into the correct group. </Tests></aactivity> </management-function> <management-function id="mf-unenroll"> <text>  unenroll the TOE from management </text> <app-note> For function <xref to="mf-unenroll"/>, FMT_SMF_EXT.2.1 specifies actions to be performed when the TOE is unenrolled from management. </app-note> <aactivity><Tests> Test FMT_SMF_EXT.1:44: The evaluator shall attempt to unenroll the device from management and verify that the steps described in FMT_SMF_EXT.2.1 are performed. This test should be performed in conjunction with the FMT_SMF_EXT.2.1 evaluation activity. </Tests></aactivity> </management-function> <management-function id="mf-alwaysOnVPN"> <text>  enable/disable the Always On VPN protection: <h:ul> <h:li>Across device</h:li></h:ul> <h:div class="indent"><selectables linebreak="yes"> <selectable>on a per-app basis</selectable> <selectable>on a per-group of applications processes basis</selectable> <selectable exclusive="yes">no other method</selectable> </selectables></h:div> </text> <app-note> Function <_/> must be included in the ST if IPsec is selected in FTP_ITC_EXT.1 and the native IPsec VPN client can be configured to be Always-On. Always-On is defined as when the TOE has a network connection the VPN attempts to connect, all data leaving the device uses the VPN when the VPN is connected and no data leaves that device when the VPN is disconnected. The configuration of the VPN Client itself (with information such as VPN Gateway, certificates, and algorithms) is addressed by the <xref to="mod-vpnclient"/>. </app-note> <aactivity><TSS>The evaluator shall verify that the TSS contains guidance to configure the VPN as Always-On. </TSS><Tests>The evaluator shall configure the VPN as Always-On and perform the following tests: <h:ul> <h:li>Test FMT_SMF_EXT.1:45a: The evaluator shall verify that when the VPN is connected all traffic is routed through the VPN. This test is performed in conjunction with FDP_IFC_EXT.1.1. </h:li> <h:li>Test FMT_SMF_EXT.1:45b: The evaluator shall verify that when the VPN is not established, that no traffic leaves the device. The evaluator shall ensure that the TOE has network connectivity and that the VPN is established. The evaluator shall use a packet sniffing tool to capture the traffic leaving the TOE. The evaluator shall disable the VPN connection on the server side. The evaluator shall perform actions with the device such as navigating to websites, using provided applications, and accessing other Internet resources and verify that no traffic leaves the device. </h:li> <h:li>Test FMT_SMF_EXT.1:45c: The evaluator shall verify that the TOE has network connectivity and that the VPN is established. The evaluator shall disable network connectivity (i.e., Airplane Mode) and verify that the VPN disconnects. The evaluator shall re-establish network connectivity and verify that the VPN automatically reconnects. </h:li> </h:ul> </Tests></aactivity> </management-function> <management-function id="mf-bioRevoke"> <text>  revoke Biometric template</text> <aactivity><TSS>The evaluator shall verify that the TSS describes the procedure to revoke a biometric credential stored on the TOE. </TSS><Tests>Test FMT_SMF_EXT.1:46: The evaluator shall configure the TOE to use BAF and confirm that the biometric can be used to authenticate to the device. The evaluator shall revoke the biometric credential’s ability to authenticate to the TOE and confirm that the same BAF cannot be used to authenticate to the device. </Tests></aactivity> </management-function> <management-function id="mf-other"> <text>  <assignable>list of other management functions to be provided by the TSF</assignable></text> <aactivity><TSS> The evaluator shall verify that the TSS describes all assigned security management functions and their intended behavior. </TSS> <Tests>Test FMT_SMF_EXT.1:47: The evaluator shall design and perform tests to demonstrate that the function may be configured and that the intended behavior of the function is enacted by the TOE. </Tests></aactivity> </management-function> </management-function-set>

The TSF shall be capable of performing <assignable>list of management functions</assignable>.

identifies the management functions defined by this PP, whether they are mandatory or optional, and whether it is mandatory, optional, or forbidden for a particular role to perform each function. The first column ("#") is a sequential numeric identifier while the second column ("Management Function") lists the management functions identified in the PP. In the following columns: ‘M’ means Mandatory ‘O’ means Optional/Objective '-' means that no value (M or O) can be assigned The third column ("Impl.") indicates whether the function is to be implemented. The ST author should select which of the non-mandatory functions are implemented. The fourth column ("User Only") indicates functions that are to be restricted to the user (i.e., not available to the administrator). The fifth column ("Admin") indicates functions that are available to the administrator. The functions restricted to the user ("User Only" column) cannot also be available to the administrator. Functions available to the administrator can still be available to the user, as long as the function is not restricted to the administrator ("Admin Only" column). Thus, if the TOE must offer these functions to both the user and the administrator to perform, the "Admin" column entry must be selected. The "Admin Only" column (FMT_MOF_EXT.1.2) indicates whether the function is to be restricted to the administrator when the device is enrolled and the administrator applies the indicated policy. If the function is restricted to the administrator the function is not available to the user. This does not prevent the user from modifying a setting to make the function stricter, but the user cannot undo the configuration enforced by the administrator. The ST author may use a table in the ST, listing only those functions that are implemented. For functions that are mandatory, any sub-functions not in a selection are also mandatory and any assignments must contain at least one assigned value. For functions that are optional and contain an assignment or selection, at least one value must be assigned/selected to be included in the ST. For non-selectable sub-functions in an optional function, all sub-functions must be implemented in order for the function to be included. For functions with a "per-app basis" sub function and an assignment, the ST author must indicate which assigned features are manageable on a per-app basis and which are not by iterating the row. The evaluator shall verify that the TSS describes all management functions, what roles can perform each function, and how these functions are (or can be) restricted to the roles identified by FMT_MOF_EXT.1. The following activities are organized according to the function number in the table. These activities include TSS Evaluation Activities, AGD Evaluation Activities, and test activities. Test activities specified below shall take place in the test environment described in the evaluation activity for FPT_TUD_EXT.1. The evaluator shall consult the AGD guidance to perform each of the specified tests, iterating each test as necessary if both the user and administrator may perform the function. The evaluator shall verify that the AGD guidance describes how to perform each management function, including any configuration details. For each specified management function tested, the evaluator shall confirm that the underlying mechanism exhibits the configured setting.

Initiation of policy update

Policy name

Change of settings

Role of user that changed setting Value of new setting

Success or failure of function

Role of user that performed function Function performed Reason for failure

Initiation of software update

Version of update

Initiation of application installation or update

Name and version of application

requires the TSF to automatically perform specific management functions in response to a specific event.

The following actions could be considered for the management functions in FMT: Configuration of the functions that are performed in response to unenrollment event. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP, PP-Module, functional package or ST: Initiation of unenrollment. Completion of unenrollment. No dependencies.

The TSF shall offer <selectables> <selectable id="s-smf-wipe-pro">wipe of protected data</selectable> <selectable id="s-smf-wipe-sen">wipe of sensitive data</selectable> <selectable id="s-smf-ext-2-rem-ent-app">remove Enterprise applications</selectable> <selectable>remove all device-stored Enterprise resource data</selectable> <selectable>remove Enterprise secondary authentication data</selectable> <selectable><assignable>list other available remediation actions</assignable></selectable> </selectables> upon unenrollment and <selectables> <selectable><assignable>other administrator-configured triggers</assignable></selectable> <selectable exclusive="yes"> no other triggers</selectable> </selectables>.

The TSF shall offer <assignable>list of remediation actions</assignable> upon unenrollment and <assignable>list of triggers</assignable>.

Unenrollment may consist of removing the MDM agent or removing the administrator’s policies. The functions in the selection are remediation actions that TOE may provide (perhaps via APIs) to the administrator (perhaps via an MDM agent) that may be performed upon unenrollment. "Enterprise applications" refers to applications that are in the Enterprise application group. "Enterprise resource data" refers to all stored Enterprise data and the separate resources that are available to the Enterprise application group, per FDP_ACF_EXT.2.1. If FDP_ACF_EXT.2.1 is included in the ST, then "remove all device-stored Enterprise resource data" must be selected, and is defined to be all resources selected in FDP_ACF_EXT.2.1. If FIA_UAU_EXT.4.1 is included in the ST, then "remove Enterprise secondary authentication data" must be selected. If FIA_UAU_EXT.4.1 is not included in the ST, then "remove Enterprise secondary authentication data" cannot be selected. Enterprise secondary authentication data only refers to any data stored on the TOE that is specifically used as part of a secondary authentication mechanism to authenticate access to Enterprise applications and shared resources. Material that is used for the TOE’s primary authentication mechanism or other purposes not related to authentication to or protection of Enterprise applications or shared resources should not be removed. Protected data is all non-TSF data, including all user or enterprise data. Some or all of this data may be considered sensitive data as well. If is selected it is assumed that the sensitive data is wiped as well. However, if is selected, it does not imply that all non-TSF data (protected data) is wiped. If or is selected the wipe must be in accordance with FCS_CKM_EXT.5.1. Thus cryptographically wiping the device is an acceptable remediation action. The evaluator shall verify that the TSS describes all available remediation actions, when they are available for use, and any other administrator-configured triggers. The evaluator shall verify that the TSS describes how the remediation actions are provided to the administrator. There are no guidance evaluation activities for this component. The evaluator shall use the test environment to iteratively configure the device to perform each remediation action in the selection. The evaluator shall configure the remediation action per how the TSS states it is provided to the administrator. The test environment could be an MDM agent application, but can also be an application with administrator access.

Initiation of unenrollment

Identity of administrator Failure of accepting command to unenroll

Unenrollment

Remediation action performed

requires the TSF to provide users with a list of administrators and their specified functions.

There are no management activities foreseen. There are no auditable events foreseen. FMT_SMR.1 Security Roles

The TSF shall provide a mechanism that allows users to view a list of currently authorized administrators and the management functions that each administrator is authorized to perform. There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. The evaluator shall cause the TOE to be enrolled into management. The evaluator shall then invoke this mechanism and verify the ability to view that the device has been enrolled, and view the management functions that the administrator is authorized to perform.

This family defines requirements for protecting against common types of software exploitation techniques.

requires the TSF to support address space layout randomization (ASLR).

There are no management activities foreseen. There are no auditable events foreseen. FCS_RBG.1 Random Bit Generation

The TSF shall provide address space layout randomization ASLR to applications.

The base address of any user-space memory mapping will consist of at least 8 unpredictable bits. The 8 unpredictable bits may be provided by the TSF DRBG (as defined in FCS_RBG.1) but is not required. The evaluator shall ensure that the TSS section of the ST describes how the 8 bits are generated and provides a justification as to why those bits are unpredictable. There are no guidance evaluation activities for this component. Evaluation Activity Note: The following test require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on consumer Mobile Device products. The evaluator shall select 3 apps included with the TSF. These must include any web browser or mail client included with the TSF. For each of these apps, the evaluator shall launch the same app on two separate Mobile Devices of the same type and compare all memory mapping locations. The evaluator shall ensure that no memory mappings are placed in the same location on both devices. This test can also be completed on the same Mobile Device if the evaluator reboots the Mobile Device between application launches. If the rare (at most 1/256) chance occurs that two mappings are the same for a single app and not the same for the other two apps, the evaluator shall repeat the test with that app to verify that in the second test the mappings are different.

requires the TSF to enforce access permissions on physical memory.

There are no management activities foreseen. There are no auditable events foreseen. No dependencies.

The TSF shall be able to enforce read, write, and execute permissions on every page of physical memory. The evaluator shall ensure that the TSS describes of the memory management unit (MMU), and ensures that this description documents the ability of the MMU to enforce read, write, and execute permissions on all pages of virtual memory. There are no guidance evaluation activities for this component. There are no test evaluation activities for this component.

requires the TSF to implement stack overflow protection.

There are no management activities foreseen. There are no auditable events foreseen. No dependencies.

TSF processes that execute in a non-privileged execution domain on the application processor shall implement stack-based buffer overflow protection. A "non-privileged execution domain" refers to the user mode (as opposed to kernel mode, for instance) of the processor. While not all TSF processes must implement such protection, it is expected that most of the processes (to include libraries used by TSF processes) do implement buffer overflow protections. The evaluator shall determine that the TSS contains a description of stack-based buffer overflow protections implemented in the TSF software which runs in the non-privileged execution mode of the application processor. The exact implementation of stack-based buffer overflow protection will vary by platform. Example implementations may be activated through compiler options such as "-fstack-protector-all", "-fstack-protector", and "/GS" flags. The evaluator shall ensure that the TSS contains an inventory of TSF binaries and libraries, indicating those that implement stack-based buffer overflow protections as well as those that do not. The TSS must provide a rationale for those binaries and libraries that are not protected in this manner. There are no guidance evaluation activities for this component. There are no test evaluation activities for this component.

requires the TSF to protect itself from untrusted subjects and enforce address space isolation.

There are no management activities foreseen. There are no auditable events foreseen. No dependencies.

The TSF shall protect itself from modification by untrusted subjects.

The TSF shall enforce isolation of address space between applications. In addition to the TSF software (e.g., kernel image, device drivers, trusted applications) that resides in storage, the execution context (e.g., address space, processor registers, per-process environment variables) of the software operating in a privileged mode of the processor (e.g., kernel), as well as the context of the trusted applications is to be protected. In addition to the software, any configuration information that controls or influences the behavior of the TSF is also to be protected from modification by untrusted subjects. Configuration information includes, but is not limited to, user and administrative management function settings, WLAN profiles, and Bluetooth data such as the service-level security requirements database. Untrusted subjects include untrusted applications; unauthorized users who have access to the device while powered off, in a screen-locked state, or when booted into auxiliary boot modes; and, unauthorized users or untrusted software or hardware which may have access to the device over a wired interface, either when the device is in a screen-locked state or booted into auxiliary boot modes. The evaluator shall ensure that the TSS describes the mechanisms that are in place that prevents non-TSF software from modifying the TSF software or TSF data that governs the behavior of the TSF. These mechanisms could range from hardware-based means (e.g. "execution rings" and memory management functionality); to software-based means (e.g. boundary checking of inputs to APIs). The evaluator determines that the described mechanisms appear reasonable to protect the TSF from modification. The evaluator shall ensure the TSS describes how the TSF ensures that the address spaces of applications are kept separate from one another. The evaluator shall ensure the TSS details the USSD and MMI codes available from the dialer at the locked state or during auxiliary boot modes that may alter the behavior of the TSF. The evaluator shall ensure that this description includes the code, the action performed by the TSF, and a justification that the actions performed do not modify user or TSF data. If no USSD or MMI codes are available, the evaluator shall ensure that the TSS provides a description of the method by which actions prescribed by these codes are prevented. The evaluator shall ensure the TSS documents any TSF data (including software, execution context, configuration information, and audit logs) which may be accessed and modified over a wired interface in auxiliary boot modes. The evaluator shall ensure that the description includes data, which is modified in support of update or restore of the device. The evaluator shall ensure that this documentation includes the auxiliary boot modes in which the data may be modified, the methods for entering the auxiliary boot modes, the location of the data, the manner in which data may be modified, the data format and packaging necessary to support modification, and software or hardware tools, if any, which are necessary for modifying the data. The evaluator shall ensure that the TSS provides a description of the means by which unauthorized and undetected modification (that is, excluding cryptographically verified updates per FPT_TUD_EXT.2) of the TSF data over the wired interface in auxiliary boots modes is prevented. The lack of publicly available tools is not sufficient justification. Examples of sufficient justification include auditing of changes, cryptographic verification in the form of a digital signature or hash, disabling the auxiliary boot modes, and access control mechanisms that prevent writing to files or flashing partitions. There are no guidance evaluation activities for this component. Evaluation Activity Note: The following tests require the vendor to provide access to a test platform that provides the evaluator with tools that are typically not found on consumer Mobile Device products. In addition, the vendor provides a list of files (e.g., system files, libraries, configuration files, audit logs) that make up the TSF data. This list could be organized by folders/directories (e.g., /usr/sbin, /etc), as well as individual files that may exist outside of the identified directories. The evaluator shall create and load an app onto the Mobile Device. This app shall attempt to traverse over all file systems and report any locations to which data can be written or overwritten. The evaluator shall ensure that none of these locations are part of the OS software, device drivers, system and security configuration files, key material, or another untrusted application’s image/data. For example, it is acceptable for a trusted photo editor app to have access to the data created by the camera app, but a calculator application shall not have access to the pictures. For each available auxiliary boot mode, the evaluator shall attempt to modify a TSF file of their choosing using the software or hardware tools described in the TSS. The evaluator shall verify that the modification fails.

requires the TSF to provide ASLR to the kernel.

There are no management activities foreseen. There are no auditable events foreseen. FCS_RBG.1 Random Bit Generation (RBG)

The TSF shall provide address space layout randomization (ASLR) to the kernel.

The base address of any kernel-space memory mapping will consist of <assignable>number greater than or equal to 4</assignable> unpredictable bits. The unpredictable bits may be provided by the TSF DRBG (as defined in FCS_RBG.1). The evaluator shall ensure that the TSS section of the ST describes how the bits are generated and provides a justification as to why those bits are unpredictable. There are no guidance evaluation activities for this component. Evaluation Activity Note: The following test require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on consumer Mobile Device products. The evaluator shall reboot the TOE six times. For each of these reboots, the evaluator shall examine memory mapping locations of the kernel. The evaluator shall ensure that for at least five reboots the memory mappings are not placed in the same location on both devices.

requires the TSF to prevent physical memory from being both writable and executable.

There are no management activities foreseen. There are no auditable events foreseen. No dependencies.

The TSF shall prevent write and execute permissions from being simultaneously granted to any page of physical memory <selectables> <selectable>with no exceptions</selectable> <selectable> <assignable>specific exceptions</assignable></selectable> </selectables>. Memory used for just-in-time (JIT) compilation is anticipated as an exception in this requirement; if so, the ST author must address how this exception is permitted. It is expected that the memory management unit will transition the system to a non-operational state if any violation is detected in kernel memory space. The evaluator shall ensure that the TSS describes how the operating system of the application processor prevents all processes executing in a non-privileged execution domain from achieving write and execute permissions on any page of memory (with only specified exceptions). The evaluator shall ensure that the TSS describes how such processes are unable to request pages of memory with such permissions, and how they are unable to change permissions to both write and execute on any pages already allocated to them. There are no guidance evaluation activities for this component. There are no test evaluation activities for this component.

This family defines requirements for separation of baseband and application processor execution.

requires the TSF to enforce separation between baseband and application processor execution except through application processor mechanisms.

There are no management activities foreseen. There are no auditable events foreseen. No dependencies.

The TSF shall prevent code executing on any baseband processor (BP) from accessing application processor (AP) resources except when mediated by the AP. These resources include: Volatile and non-volatile memory Control of and data from integrated and non-integrated peripherals (e.g. USB controllers, touch screen controllers, LCD controller, codecs) Control of and data from integrated and non-integrated I/O sensors (e.g. camera, light, microphone, GPS, accelerometers, geomagnetic field sensors) Mobile devices are becoming increasingly complex having an application processor that runs an operating system and user applications and separate baseband processors that handle cellular and other wireless network connectivity. The application processor within most modern Mobile Devices is a system on a chip (SoC) that integrates, for example, CPU/GPU cores and memory interface electronics into a single, power-efficient package. Baseband processors are becoming increasingly complex themselves delivering voice encoding alongside multiple independent radios (LTE, Wi-Fi, Bluetooth, FM, GPS) in a single package containing multiple CPUs and DSPs. Thus, the baseband processors in these requirements include such integrated SoCs and include any radio processors (integrated or not) on the Mobile Device. All other requirements mostly, except where noted, apply to firmware/software on the application processor, but future requirements (notably, all Integrity, Access Control, and Anti-Exploitation requirements) will apply to application processors and baseband processors. The evaluator shall ensure that the TSS section of the ST describes at a high level how the processors on the Mobile Device interact, including which bus protocols they use to communicate, any other devices operating on that bus (peripherals and sensors), and identification of any shared resources. The evaluator shall verify that the design described in the TSS does not permit any BPs from accessing any of the peripherals and sensors or from accessing main memory (volatile and non-volatile) used by the AP. In particular, the evaluator shall ensure that the design prevents modification of executable memory of the AP by the BP. There are no guidance evaluation activities for this component. There are no test evaluation activities for this component.

This family defines requirements for limiting Bluetooth capabilities without user action.

requires the TSF to maintain a disabled by default posture for Bluetooth profiles.

There are no management activities foreseen. There are no auditable events foreseen. No dependencies.

The TSF shall disable support for <assignable>list of Bluetooth profiles</assignable> Bluetooth profiles when they are not currently being used by an application on the Mobile Device, and shall require explicit user action to enable them. Some Bluetooth services incur more serious consequences if unauthorized remote devices gain access to them. Such services should be protected by measures like disabling support for the associated Bluetooth profile unless it is actively being used by an application on the Mobile Device (in order to prevent discovery by a Service Discovery Protocol search), and then requiring explicit user action to enable those profiles in order to use the services. It may be further appropriate to require additional user action before granting a remote device access to that service. For example, it may be appropriate to disable the OBEX Push Profile until a user on the Mobile Device pushes a button in an application indicating readiness to transfer an object. After completion of the object transfer, support for the OBEX profile should be suspended until the next time the user requests its use. The evaluator shall ensure that the TSS lists all Bluetooth profiles that are disabled while not in use by an application and which need explicit user action in order to become enabled. There are no guidance evaluation activities for this component.The evaluator shall perform the following tests: While the service is not in active use by an application on the TOE, the evaluator shall attempt to discover a service associated with a "protected" Bluetooth profile (as specified by the requirement) on the TOE via a Service Discovery Protocol search. The evaluator shall verify that the service does not appear in the Service Discovery Protocol search results. Next, the evaluator shall attempt to gain remote access to the service from a device that does not currently have a trusted device relationship with the TOE. The evaluator shall verify that this attempt fails due to the unavailability of the service and profile. The evaluator shall repeat Test 1 with a device that currently has a trusted device relationship with the TOE and verify that the same behavior is exhibited.

The TSF shall preserve a secure state when the following types of failures occur: [<h:i>DRBG self-test failure</h:i>]. The intent of this requirement is to ensure that cryptographic services requiring random bit generation cannot be performed if a failure of a self-test defined in FPT_TST.1 occurs. The evaluator shall verify that the TSF describes how the TOE enters an error state in the event of a DRBG self-test failure. The evaluator shall verify that the guidance documentation describes the error state that results from a DRBG self-test failure and the actions that a user or administrator should take in response to attempt to resolve the error state.

This family defines requirements for JTAG interface access limitations.

requires the TSF to specify the mechanism used to restrict access to its JTAG interface.

There are no management activities foreseen. There are no auditable events foreseen. No dependencies.

The TSF shall <selectables> <selectable id="s-jtag-kill-hw">disable access through hardware</selectable> <selectable id="s-jtag-control-key">control access by a signing key</selectable> </selectables> to JTAG.

The TSF shall <assignable>list access control mechanisms</assignable> to JTAG.

This requirement means that access to JTAG must be disabled either through hardware or restricted through the use of a signing key. If is selected: The evaluator shall examine the TSS to determine the location of the JTAG ports on the TSF, to include the order of the ports (i.e., Data In, Data Out, Clock, etc.). If is selected: The evaluator shall examine the TSS to determine how access to the JTAG is controlled by a signing key. The evaluator shall examine the TSS to determine when the JTAG can be accessed, i.e. what has the access to the signing key. There are no guidance evaluation activities for this component. Evaluation Activity Note: The following test requires the developer to provide access to a test platform that provides the evaluator with chip level access. If is selected: The evaluator shall connect to the available JTAG port(s) on the device. The evaluator shall query the JTAG port(s) to determine if the functionality of the JTAG access is available. This could be through the retrieval of information that may only be accessible through the JTAG interface(s) or by other means that can show the status of the interface to accept commands.

This family defines requirements for protecting plaintext keys.

requires the TSF to avoid storage of plaintext keys in readable memory.

There are no management activities foreseen. There are no auditable events foreseen. No dependencies.

The TSF shall not store any plaintext key material in readable non-volatile memory. The intention of this requirement is that the TOE will not write plaintext keying material to persistent storage. For the purposes of this requirement, keying material refers to authentication data, passwords, secret/private symmetric keys, private asymmetric keys, data used to derive keys, etc. These values must be stored encrypted. This requirement also applies to any value derived from passwords. Thus, the TOE cannot store plaintext password hashes for comparison purposes before protected data is decrypted, and the TOE should use key derivation and decryption to verify the Password Authentication Factor. If is selected in FIA_UAU.5.1 keying material also refers to the PIN/password used as part of the hybrid authentication. The evaluator shall consult the TSS section of the ST in performing the Evaluation Activities for this requirement. In performing their review, the evaluator shall determine that the TSS contains a description of the activities that happen on power-up and password authentication relating to the decryption of DEKs, stored keys, and data. The evaluator shall ensure that the description also covers how the cryptographic functions in the FCS requirements are being used to perform the encryption functions, including how the KEKs, DEKs, and stored keys are unwrapped, saved, and used by the TOE so as to prevent plaintext from being written to non-volatile storage. The evaluator shall ensure that the TSS describes, for each power-down scenario how the TOE ensures that all keys in non-volatile storage are not stored in plaintext. The evaluator shall ensure that the TSS describes how other functions available in the system (e.g., regeneration of the keys) ensure that no unencrypted key material is present in persistent storage. The evaluator shall review the TSS to determine that it makes a case that key material is not written unencrypted to the persistent storage. There are no guidance evaluation activities for this component. There are no test evaluation activities for this component.

requires the TSF to prevent transmitting plaintext key material to the operational environment.

There are no management activities foreseen. There are no auditable events foreseen. No dependencies.

The TSF shall not transmit any plaintext key material outside the security boundary of the TOE. The intention of this requirement is to prevent the logging of plaintext key information to a service that transmits the information off-device. For the purposes of this requirement, key material refers to keys, passwords, and other material that is used to derive keys. If is selected in FIA_UAU.5.1 keying material also refers to the PIN/password used as part of the hybrid authentication. In the future, this requirement will apply to symmetric and asymmetric private keys stored in the TOE secure key storage where applications are outside the boundary of the TOE. Thus, the TSF will be required to provide cryptographic key operations (signature, encryption, and decryption) on behalf of applications (FCS_SRV_EXT.2.1) that have access to those keys. The evaluator shall consult the TSS section of the ST in performing the Evaluation Activities for this requirement. The evaluator shall ensure that the TSS describes the TOE security boundary. The cryptographic module may very well be a particular kernel module, the Operating System, the Application Processor, or up to the entire Mobile Device. In performing their review, the evaluator shall determine that the TSS contains a description of the activities that happen on power-up and password authentication relating to the decryption of DEKs, stored keys, and data. The evaluator shall ensure that the TSS describes how other functions available in the system (e.g., regeneration of the keys) ensure that no unencrypted key material is transmitted outside the security boundary of the TOE. The evaluator shall review the TSS to determine that it makes a case that key material is not transmitted outside the security boundary of the TOE. There are no guidance evaluation activities for this component. There are no test evaluation activities for this component.

requires the TSF to prevent the export of plaintext keys.

There are no management activities foreseen. There are no auditable events foreseen. No dependencies.

The TSF shall ensure it is not possible for the TOE users to export plaintext keys. Plaintext keys include DEKs, KEKs, and all keys stored in the secure key storage (FCS_STG_EXT.1). The intent of this requirement is to prevent the plaintext keys from being exported during a backup authorized by the TOE user or administrator. The ST author will provide a statement of their policy for handling and protecting keys. The evaluator shall check to ensure the TSS describes a policy in line with not exporting either plaintext DEKs, KEKs, or keys stored in the secure key storage. There are no guidance evaluation activities for this component. There are no test evaluation activities for this component.

This family defines requirements for generation of notifications in response to completed self-tests.

requires the TSF to become non-operational when certain failures occur.

There are no management activities foreseen. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP, PP-Module, functional package or ST: Measurement of TSF software. FPT_TST_EXT.1 TSF Cryptographic Functionality Testing FPT_TST_EXT.2 TSF Integrity Checking

The TSF shall transition to non-operational mode and <selectables> <selectable>log failures in the audit record</selectable> <selectable>notify the administrator</selectable> <selectable> <assignable>other actions</assignable></selectable> <selectable exclusive="yes">no other actions</selectable> </selectables> when the following types of failures occur: <h:ul> <h:li>failures of the self-tests</h:li> <h:li>TSF software integrity verification failures</h:li> <h:li><selectables> <selectable exclusive="yes">no other failures</selectable> <selectable> <assignable>other failures</assignable></selectable> </selectables></h:li> </h:ul> The evaluator shall verify that the TSS describes critical failures that may occur and the actions to be taken upon these critical failures. There are no guidance evaluation activities for this component. Evaluation Activity Note: The following test require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on consumer Mobile Device products. The evaluator shall use a tool provided by the developer to modify files and processes in the system that correspond to critical failures specified in the second list. The evaluator shall verify that creating these critical failures causes the device to take the remediation actions specified in the first list.

Measurement of TSF softwareNone

Integrity verification valueNo additional information

requires the TSF to generate and sign software integrity verification values.

The following actions could be considered for the management functions in FMT: Retrieval of TSF software integrity verification values. There are no auditable events foreseen. FCS_COP.1 Cryptographic Operation

The TSF shall <selectables> <selectable>audit</selectable> <selectable>provide the administrator with</selectable> </selectables> TSF-software integrity verification values. These notifications are typically called remote attestation and these integrity values are typically called measurements. The integrity values are calculated from hashes of critical memory and values, including executable code. The ST author must select whether these values are logged as a part of FAU_GEN.1.1 or are provided to the administrator. The evaluator shall verify that the TSS describes which critical memory is measured for these integrity values and how the measurement is performed (including which TOE software generates these values, how that software accesses the critical memory, and which algorithms are used). If the integrity values are provided to the administrator, the evaluator shall verify that the AGD guidance contains instructions for retrieving these values and information for interpreting them. For example, if multiple measurements are taken, what those measurements are and how changes to those values relate to changes in the device state. Evaluation Activity Note: The following test may require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on consumer Mobile Device products. The evaluator shall repeat the following test for each measurement: The evaluator shall boot the device in an approved state and record the measurement taken (either from the log or by using the administrative guidance to retrieve the value via an MDM agent). The evaluator shall modify the critical memory or value that is measured. The evaluator shall boot the device and verify that the measurement changed.

The TSF shall cryptographically sign all integrity verification values. The intent of this requirement is to provide assurance to the administrator that the responses provided are from the TOE and have not been modified or spoofed by a man-in-the-middle such as a network-based adversary or a malicious MDM Agent. The evaluator shall verify that the TSS describes which key the TSF uses to sign the responses to queries and the certificate used to prove ownership of the key, and the method of associating the certificate with a particular device manufacturer and model. There are no guidance evaluation activities for this component. The evaluator shall perform the following test: The evaluator shall write, or the developer shall provide, a management application that queries either the audit logs or the measurements. The evaluator shall verify that the responses to these queries are signed and verify the signatures against the TOE’s certificate.

The TSF shall be able to provide reliable time stamps <refinement>for its own use</refinement>. The evaluator shall examine the TSS to ensure that it lists each security function that makes use of time. The TSS provides a description of how the time is maintained and considered reliable in the context of each of the time related functions. This documentation must identify whether the TSF uses a NTP server or the carrier’s network time as the primary time sources. The evaluator examines the operational guidance to ensure it describes how to set the time. The evaluator uses the operational guide to set the time. The evaluator shall then use an available interface to observe that the time was set correctly.

The TSF shall run a suite of the following self-tests [<h:i>during initial start-up, <selectables> <selectable>periodically during normal operation</selectable> <selectable>at the request of the authorized user</selectable> <selectable>at the conditions <assignable>conditions under which self-test should occur</assignable></selectable> <selectable>at no other time</selectable> </selectables></h:i>] to demonstrate the correct operation of [<h:i>TSF DRBG defined in FCS_RBG.1</h:i>]: <assignable>DRBG health tests</assignable>.

The TSF shall provide authorized users with the capability to verify the integrity of [<h:i>[DRBG seed/output data]</h:i>].

The TSF shall provide authorized users with the capability to verify the integrity of [<h:i>[TSF DRBG defined in FCS_RBG.1]</h:i>]. This SFR is a required dependency of FCS_RBG.1. It is intended to require that any DRBG implemented by the TOE undergo health testing at startup (and optionally in other circumstances) to ensure that the random bit generation functionality has not been degraded. If the TSF supports multiple DRBGs, this SFR should be iterated to describe the self-test behavior for each. The TSF's response to a DRBG health test failure is addressed by FPT_FLS.1. The evaluator shall examine the TSS to ensure that it details the self-tests that are run by the TSF along with how they are run. This description should include an outline of what the tests are actually doing. The evaluator shall ensure that the TSS makes an argument that the tests are sufficient to demonstrate that the DRBG is operating correctly. Note that this information may also be placed in the entropy documentation specified by . If a self-test can be executed at the request of an authorized user, the evaluator shall verify that the operational guidance provides instructions on how to execute that self-test. For each self-test, the evaluator shall verify that evidence is produced that the self-test is executed when specified by FPT_TST.1.1. If a self-test can be executed at the request of an authorized user, the evaluator shall verify that following the steps documented in the operational guidance to perform the self-test will result in execution of the self-test.

Execution of self-tests

None.

This family defines requirements for execution of self-tests that are not addressed by FPT_TST in CC Part 2.

requires the TSF to run self-test at start-up to verify correct operation.

There are no management activities foreseen. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: Initiation of self-test. Failure of self-test. FCS_COP.1 Cryptographic Operation

The TSF shall run a suite of self-tests during initial start-up (on power on) to demonstrate the correct operation of all cryptographic functionality. This requirement may be met by performing known answer tests or pair-wise consistency tests. The self-tests must be performed before the cryptographic functionality is exercised (for example, during the initialization of a process that utilizes the functionality). The cryptographic functionality includes the cryptographic operations in FCS_COP and the key generation functions in FCS_CKM. DRBG self-test functionality is specifically addressed by FPT_TST.1. The TSF's response to a self-test failure is addressed by FPT_NOT_EXT.1. The evaluator shall examine the TSS to ensure that it specifies the self-tests that are performed at start-up. This description must include an outline of the test procedures conducted by the TSF (e.g., rather than saying "memory is tested", a description similar to "memory is tested by writing a value to each memory location and reading it back to ensure it is identical to what was written" shall be used). The TSS must include any error states that the TSF may enter when self-tests fail, and the conditions and actions necessary to exit the error states and resume normal operation. The evaluator shall verify that the TSS indicates these self-tests are run at start-up automatically, and do not involve any inputs from or actions by the user or operator. The evaluator shall inspect the list of self-tests in the TSS and verify that it includes algorithm self-tests. The algorithm self-tests will typically be conducted using known answer tests. There are no guidance evaluation activities for this component. There are no test evaluation activities for this component.

Initiation of self-test

Failure of self-test

Algorithm that caused the failureNo additional information

requires the TSF to verify code and bootchain integrity is stored prior to execution by a designated key or hash.

There are no management activities foreseen. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: Start-up of TOE. Detected integrity violation None FCS_COP.1 Cryptographic Operation

The TSF shall verify the integrity of <assignable>TSF data</assignable> stored in mutable media prior to its execution through the use of <assignable>cryptographic or immutable hardware mechanism</assignable>.

The TSF shall verify the integrity of [<h:i>the bootchain up through the Application Processor OS kernel</h:i>] stored in mutable media prior to its execution through the use of <selectables> <selectable>a digital signature using an immutable hardware asymmetric key</selectable> <selectable>an immutable hardware hash of an asymmetric key</selectable> <selectable>an immutable hardware hash</selectable> <selectable>a digital signature using a hardware-protected asymmetric key</selectable> </selectables>. The bootchain of the TSF is the sequence of firmware and software, including ROM, bootloaders, and kernel, which ultimately result in loading the kernel on the Application Processor, regardless of which processor executes that code. Executable code that would be loaded after the kernel is covered in FPT_TST_EXT.2/POSTKERNEL. In order to meet this requirement, the hardware protection may be transitive in nature: a hardware-protected public key, hash of an asymmetric key, or hash may be used to verify the mutable bootloader code which contains a key or hash used by the bootloader to verify the mutable OS kernel code, which contains a key or hash to verify the next layer of executable code, and so on. The cryptographic mechanism used to verify the (initial) mutable executable code must be protected, such as being implemented in hardware or in read-only memory (ROM). The evaluator shall verify that the TSS section of the ST includes a description of the boot procedures, including a description of the entire bootchain, of the software for the TSF’s Application Processor. The evaluator shall ensure that before loading the bootloaders for the operating system and the kernel, all bootloaders and the kernel software itself is cryptographically verified. For each additional category of executable code verified before execution, the evaluator shall verify that the description in the TSS describes how that software is cryptographically verified. The evaluator shall verify that the TSS contains a justification for the protection of the cryptographic key or hash, preventing it from being modified by unverified or unauthenticated software. The evaluator shall verify that the TSS contains a description of the protection afforded to the mechanism performing the cryptographic verification. The evaluator shall verify that the TSS describes each auxiliary boot mode available on the TOE during the boot procedures. The evaluator shall verify that, for each auxiliary boot mode, a description of the cryptographic integrity of the executed code through the kernel is verified before each execution. There are no guidance evaluation activities for this component. Evaluation Activity Note: The following tests require the vendor to provide access to a test platform that provides the evaluator with tools that are typically not found on consumer Mobile Device products. The evaluator shall perform the following tests: The evaluator shall perform actions to cause TSF software to load and observe that the integrity mechanism does not flag any executables as containing integrity errors and that the TOE properly boots. The evaluator shall modify a TSF executable that is integrity protected and cause that executable to be successfully loaded by the TSF. The evaluator observes that an integrity violation is triggered and the TOE does not boot. (Care must be taken so that the integrity violation is determined to be the cause of the failure to load the module, and not the fact that the module was modified so that it was rendered unable to run because its format was corrupt). [conditional] If the ST author indicates that the integrity verification is performed using a public key, the evaluator shall verify that the update mechanism includes a certificate validation as defined in FIA_X509_EXT.1 as defined in the . The evaluator shall digitally sign the TSF executable with a certificate that does not have the Code Signing purpose in the extendedKeyUsage field and verify that an integrity violation is triggered. The evaluator shall repeat the test using a certificate that contains the Code Signing purpose and verify that the integrity verification succeeds. Ideally, the two certificates should be identical except for the extendedKeyUsage field.

Start-up of TOE

Detected integrity violationNone

The TSF code file that caused the integrity violationNo additional information

The TSF shall verify the integrity of <selectables> <selectable id="s-all-exe">all executable code</selectable> <selectable><assignable>subset of executable code</assignable></selectable> </selectables> stored in mutable media prior to its execution through the use of <selectables> <selectable>a digital signature using an immutable hardware asymmetric key</selectable> <selectable>an immutable hardware hash of an asymmetric key</selectable> <selectable>an immutable hardware hash</selectable> <selectable>a digital signature using a hardware-protected asymmetric key</selectable> <selectable>hardware-protected hash</selectable> </selectables>. All executable code covered in this requirement is executed after the kernel is loaded. If "all executable code in mutable media" is verified, implementation in hardware or in read-only memory is a natural logical consequence. At this time, the verification of software executed on other processors stored in mutable media is not required; however, it may be added in the first assignment. If all executable code (including bootloaders, kernel, device drivers, pre-loaded applications, user-loaded applications, and libraries) is verified, "all executable code stored in mutable media" should be selected. There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. The evaluation activity shall be completed in conjunction with FPT_TST_EXT.2/PREKERNEL for all executable code specified.

Detected integrity violationNone

The TSF code file that cause the integrity violationNo additional information

requires the TSF to validate a code signing certificate before the associated code is executed.

There are no management activities foreseen. There are no auditable events foreseen. FPT_TST_EXT.2 TSF Integrity Checking FIA_X509_EXT.1 X.509 Validation of Certificates FIA_X509_EXT.2 X.509 Certificate Authentication

The TSF shall not execute code if the code signing certificate is deemed invalid. Certificates may optionally be used for code signing for integrity verification (FPT_TST_EXT.2.1/PREKERNEL). If "code signing for software integrity testing" is selected in FIA_X509_EXT.2.1 in , FPT_TST_EXT.3.1 must be included in the ST. Validity is determined by the certificate path, the expiration date, and the revocation status in accordance with RFC 5280. There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. Testing for this component is performed in conjunction with the Evaluation Activities for FPT_TST_EXT.2.1/PREKERNEL.

This family defines requirements for trusted updates.

requires the TSF to provide authorized users the ability to query the version of the TOE hardware, TOE software, and installed applications.

There are no management activities foreseen. There are no auditable events foreseen. FMT_SMR.1 Security Roles

The TSF shall provide authorized users the ability to query the current version of the TOE firmware/software.

The TSF shall provide authorized users the ability to query the current version of the hardware model of the device. The current version of the hardware model of the device is an identifier that is sufficient to indicate (in tandem with manufacturer documentation) the hardware which comprises the device.

The TSF shall provide authorized users the ability to query the current version of installed mobile applications. The current version of mobile applications is the name and published version number of each installed mobile application. The evaluator shall establish a test environment consisting of the Mobile Device and any supporting software that demonstrates usage of the management functions. This can be test software from the developer, a reference implementation of management software from the developer, or other commercially available software. The evaluator shall set up the Mobile Device and the other software to exercise the management functions according to the provided guidance documentation. There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. Using the AGD guidance provided, the evaluator shall test that the administrator and user can query: The current version of the TSF operating system and any firmware that can be updated separately The hardware model of the TSF The current version of all installed mobile applications The evaluator shall review manufacturer documentation to ensure that the hardware model identifier is sufficient to identify the hardware which comprises the device.

requires the TSF to ensure that system software updates are digitally signed prior to installation.

The following actions could be considered for the management functions in FMT: Updating of system software. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP, PP-Module, functional package or ST: Success or failure of signature verification for applications. FCS_COP.1 Cryptographic Operation

The TSF shall verify software updates to the Application Processor system software and <selectables> <selectable><assignable>other processor system software</assignable></selectable> <selectable>no other processor system software</selectable> </selectables> using a digital signature verified by the manufacturer trusted key prior to installing those updates. The digital signature mechanism is implemented in accordance with FCS_COP.1.1/SigVer. At this time, this requirement does not require verification of software updates to the software operating outside the Application Processor. Any change, via a supported mechanism, to software residing in non-volatile storage is deemed a software update. Thus, this requirement applies to TSF software updates regardless of how the software arrives or is delivered to the device. This includes over-the-air (OTA) updates as well as partition images containing software which may be delivered to the device over a wired interface.

The TSF shall <selectables> <selectable>never update</selectable> <selectable>update only by verified software</selectable> </selectables> the TSF boot integrity <selectables> <selectable>key</selectable> <selectable>hash</selectable> </selectables>. The key or hash updated via this requirement is used for verifying software before execution in FPT_TST_EXT.2/PREKERNEL. The key or hash is verified as a part of the digital signature on an update, and the software which performs the update of the key or hash is verified by FPT_TST_EXT.2/PREKERNEL.

The TSF shall verify that the digital signature verification key used for TSF updates <selectables> <selectable>is validated to a public key in the Trust Anchor Database</selectable> <selectable>matches an immutable hardware public key</selectable> </selectables>. The ST author must indicate the method by which the signing key for system software updates is limited and, if selected in FPT_TUD_EXT.2.3, must indicate how this signing key is protected by the hardware. If certificates are used, certificates are validated for the purpose of software updates in accordance with FIA_X509_EXT.1 as defined in the and should be selected in FIA_X509_EXT.2.1 as defined in the . Additionally, FPT_TUD_EXT.4 must be included in the ST. The evaluator shall verify that the TSS section of the ST describes all TSF software update mechanisms for updating the system software. The evaluator shall verify that the description includes a digital signature verification of the software before installation and that installation fails if the verification fails. The evaluator shall verify that all software and firmware involved in updating the TSF is described and, if multiple stages and software are indicated, that the software/firmware responsible for each stage is indicated and that the stages which perform signature verification of the update are identified. The evaluator shall verify that the TSS describes the method by which the digital signature is verified and that the public key used to verify the signature is either hardware-protected or is validated to chain to a public key in the Trust Anchor Database. If hardware-protection is selected, the evaluator shall verify that the method of hardware-protection is described and that the ST author has justified why the public key may not be modified by unauthorized parties. [conditional] If the ST author indicates that software updates to system software running on other processors is verified, the evaluator shall verify that these other processors are listed in the TSS and that the description includes the software update mechanism for these processors, if different than the update mechanism for the software executing on the Application Processor. [conditional] If the ST author indicates that the public key is used for software update digital signature verification, the evaluator shall verify that the update mechanism includes a certificate validation as defined in FIA_X509_EXT.1 as defined in the and a check for the Code Signing purpose in the extendedKeyUsage. There are no guidance evaluation activities for this component. The evaluator shall verify that the developer has provided evidence that the following tests were performed for each available update mechanism: The tester shall try to install an update without the digital signature and shall verify that installation fails. The tester shall attempt to install an update with digital signature, and verify that installation succeeds. The tester shall digitally sign the update with a key disallowed by the device and verify that installation fails. The tester shall attempt to install an update signed with the allowed key and verify that installation succeeds. [conditional] The tester shall digitally sign the update with an invalid certificate and verify that update installation fails. The tester attempt to install an update that was digitally signed using a valid certificate and a certificate that contains the purpose and verify that the update installation succeeds. [conditional] The tester shall repeat these test for the software executing on each processor listed in the first selection. The tester shall attempt to install an update without the digital signature and shall verify that installation fails. The tester shall attempt to install an update with digital signature, and verify that installation succeeds.

Success or failure of signature verification for software updates

requires the TSF to ensure that application software updates are digitally signed prior to installation.

There are no management activities foreseen. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP, PP-Module, functional package or ST: Success or failure of signature verification for applications. FCS_COP.1 Cryptographic Operation

The TSF shall verify mobile application software using a digital signature mechanism prior to installation. This requirement does not necessitate an X.509v3 certificate or certificate validation. X.509v3 certificates and certificate validation are addressed in . The evaluator shall verify that the TSS describes how mobile application software is verified at installation. The evaluator shall ensure that this method uses a digital signature. There are no guidance evaluation activities for this component. Evaluation Activity Note: The following test does not have to be tested using the commercial application store. The evaluator shall write, or the developer shall provide access to, an application. The evaluator shall try to install this application without a digitally signature and shall verify that installation fails. The evaluator shall attempt to install a digitally signed application, and verify that installation succeeds.

Success or failure of signature verification for applications

requires the TSF to enforce validity of system software’s code signing certificate prior to installation.

There are no management activities foreseen. There are no auditable events foreseen. FIA_X509_EXT.1 X.509 Validation of Certificates FIA_X509_EXT.2 X.509 Certificate Authentication

The TSF shall not install code if the code signing certificate is deemed invalid. Certificates may optionally be used for code signing of system software updates (FPT_TUD_EXT.2.3) and of mobile applications (). This element must be included in the ST if certificates are used for either update element. If "code signing for system software updates" is selected or the assignment is selected and specifies the use of X.509 in code signing for mobile applications in FIA_X509_EXT.2.1 in , FPT_TUD_EXT.4 must be included in the ST. Validity is determined by the certificate path, the expiration date, and the revocation status in accordance with RFC 5280. There are no TSS evaluation activities for this component. There are no guidance evaluation activities for this component. Testing for this component is performed in conjunction with the Evaluation Activities for FPT_TUD_EXT.2 and FPT_TUD_EXT.5.

requires the TSF to enforce validity of application software’s code signing certificate prior to installation.

The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: Configure certificate or public key used to validate digital signature on applications. There are no auditable events foreseen. FIA_X509_EXT.1 X.509 Validation of Certificates FIA_X509_EXT.2 X.509 Certificate Authentication

The TSF shall by default only install mobile applications cryptographically verified by <selectables> <selectable>a built-in X.509v3 certificate</selectable> <selectable>a configured X.509v3 certificate</selectable> </selectables>. The built-in certificate is installed by the manufacturer either at time of manufacture or as a part of system updates. The configured certificate used to verify the signature is set as defined in FMT_SMF_EXT.1 function . The evaluator shall verify that the TSS describes how mobile application software is verified at installation. The evaluator shall ensure that this method uses a digital signature by a code signing certificate. There are no guidance evaluation activities for this component. The evaluator shall write, or the developer shall provide access to, an application. The evaluator shall try to install this application without a digitally signature and shall verify that installation fails. The evaluator shall attempt to install an application digitally signed with an appropriate certificate, and verify that installation succeeds. The evaluator shall digitally sign the application with an invalid certificate and verify that application installation fails. The evaluator shall digitally sign the application with a certificate that does not have the Code Signing purpose and verify that application installation fails. This test may be performed in conjunction with the Evaluation Activities for FIA_X509_EXT.1 as defined in the . If necessary, the evaluator shall configure the device to limit the public keys that can sign application software according to the AGD guidance. The evaluator shall digitally sign the application with a certificate disallowed by the device or configuration and verify that application installation fails. The evaluator shall attempt to install an application digitally signed with an authorized certificate and verify that application installation succeeds.

requires the TSF to prevent the intentional rollback of software updates.

There are no management activities foreseen. There are no auditable events foreseen. No dependencies.

The TSF shall verify that software updates to the TSF are a current or later version than the current version of the TSF. A later version has a larger version number. The method for distinguishing newer software versions from older versions is determined by the manufacturer. The evaluator shall verify that the TSS describes the mechanism that prevents the TSF from installing software updates that are an older version that the currently installed version. There are no guidance evaluation activities for this component. The evaluator shall repeat the following tests to cover all allowed software update mechanisms as described in the TSS. For example, if the update mechanism replaces an entire partition containing many separate code files, the evaluator does not need to repeat the test for each individual file. The evaluator shall attempt to install an earlier version of software (as determined by the manufacturer). The evaluator shall verify that this attempt fails by checking the version identifiers or cryptographic hashes of the privileged software against those previously recorded and checking that the values have not changed. The evaluator shall attempt to install a current or later version and shall verify that the update succeeds.

This family defines requirements for session locking capabilities that are not addressed by FTA_SSL in CC Part 2.

requires the TSF to manage the transition to a locked state and what operations can be performed.

The following actions could be considered for the management functions in FMT: Configuring session locking policy. Transitioning to the locked state. There are no auditable events foreseen. FMT_SMR.1 Security Roles FPT_STM.1 Reliable Time Stamps

The TSF shall transition to a locked state after a time interval of inactivity.

The TSF shall transition to a locked state after initiation by either the user or the administrator.

The TSF shall, upon transitioning to the locked state, perform the following operations: <h:ul> <h:li>Clearing or overwriting display devices, obscuring the previous contents; </h:li> <h:li><assignable>Other actions performed upon transitioning to the locked state</assignable>.</h:li> </h:ul> The time interval of inactivity is configured using FMT_SMF_EXT.1 function . The user/administrator-initiated lock is defined in FMT_SMF_EXT.1 function . The evaluator shall verify the TSS describes the actions performed upon transitioning to the locked state. The evaluation shall verify that the AGD guidance describes the method of setting the inactivity interval and of commanding a lock. The evaluator shall verify that the TSS describes the information allowed to be displayed to unauthorized users. The evaluator shall configure the TSF to transition to the locked state after a time of inactivity (FMT_SMF_EXT.1) according to the AGD guidance. The evaluator shall wait until the TSF locks and verify that the display is cleared or overwritten and that the only actions allowed in the locked state are unlocking the session and those actions defined in FIA_UAU_EXT.2. The evaluator shall command the TSF to transition to the locked state according to the AGD guidance as both the user and the administrator. The evaluator shall wait until the TSF locks and verify that the display is cleared or overwritten and that the only actions allowed in the locked state are unlocking the session and those actions defined in FIA_UAU_EXT.2.

Before establishing a user session, the [<h:i>TSF</h:i>] shall display an [<h:i>advisory warning</h:i>] message <h:b>regarding unauthorized use of the TOE</h:b>. This requirement may be met with the configuration of either text or an image containing the text of the desired message. The TSF must minimally display this information at startup, but may also display the information at every unlock. The banner is configured as defined in FMT_SMF_EXT.1 function . The TSS shall describe when the banner is displayed. There are no guidance evaluation activities for this component. The evaluator shall also perform the following test: The evaluator follows the operational guidance to configure a notice and consent warning message. The evaluator shall then start up or unlock the TSF. The evaluator shall verify that the notice and consent warning message is displayed in each instance described in the TSS.

This family defines requirements for trusted channels that are not addressed by FTP_ITC in CC Part 2 because they apply specifically to channels required by a mobile device.

requires the TSF to manage the communication channel between itself and other trusted products.

The following actions could be considered for the management functions in FMT: Configuring the actions that require trusted channel, if applicable. Enabling/disabling communications protocols where the TSF acts as a server. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP, PP-Module, functional package or ST: Initiation and termination of trusted channel. No dependencies.

The TSF shall use <h:ul> <h:li>802.11-2012 in accordance with the [<h:i><xref to="mod-wlanclient"/></h:i>],</h:li> <h:li>802.1X in accordance with the [<h:i><xref to="mod-wlanclient"/></h:i>],</h:li> <h:li>EAP-TLS in accordance with the [<h:i><xref to="mod-wlanclient"/></h:i>],</h:li> <h:li>Mutually authenticated TLS in accordance with the [<h:i><xref to="tls"/></h:i>]</h:li> </h:ul> and <selectables linebreak="yes"> <selectable id="s-itc-ipsec"><snip>IPsec</snip> in accordance with the <xref to="mod-vpnclient"/></selectable> <selectable id="itc_dtls"><snip>mutually authenticated DTLS</snip> as defined in the <xref to="tls"/></selectable> <selectable>HTTPS</selectable> </selectables> protocols to provide a communication channel between itself and another trusted IT product using certificates as defined in [<h:i><xref to="X509"/></h:i>] that is logically distinct from other communication channels, provides assured identification of its end points, protects channel data from disclosure, and detects modification of the channel data.

The TSF shall use <h:ul> <h:li>802.11-2012 in accordance with <assignable>requirements or standards defining implementation of this protocol</assignable>,</h:li> <h:li>802.1X in accordance with <assignable>requirements or standards defining implementation of this protocol</assignable>,</h:li> <h:li>EAP-TLS in accordance with <assignable>requirements or standards defining implementation of this protocol</assignable>,</h:li> <h:li>Mutually authenticated TLS in accordance with <assignable>requirements or standards defining implementation of this protocol</assignable></h:li> </h:ul> and <assignable>other protocols</assignable> protocols to provide a communication channel between itself and another trusted IT product using certificates as defined in <assignable>requirement or standard defining the use of certificates</assignable> that is logically distinct from other communication channels, provides assured identification of its end points, protects channel data from disclosure, and detects modification of the channel data.

The intent of the mandatory portion of the above requirement is to use the cryptographic protocols identified in the requirement to establish and maintain a trusted channel between the TOE and an access point, VPN Gateway, or other trusted IT product. contains the requirements for implementing each of the other optional trusted channel protocols. The ST author must include the security functional requirements for the trusted channel protocol selected in FTP_ITC_EXT.1 in the main body of the ST. Assured identification of endpoints is performed according to the authentication mechanisms used by the listed trusted channel protocols. Claims from the are only required to the extent that they are needed to support the functionality required by the trusted protocols that are claimed. The TSF is mandated to support mutually authenticated TLS, which means that it implements a protocol that requires the validation of a certificate presented by an external entity. Therefore, FIA_X509_EXT.1 and FIA_X509_EXT.2 as defined in will be claimed, as will FIA_TSM_EXT.1 for management of the trust store. The requirement to implement mutually authenticated TLS also means that it implements a protocol that requires the presentation of any certificates to an external entity. Therefore, FIA_XCU_EXT.2 will be claimed. FIA_X509_EXT.6 will also be claimed, along with any applicable dependencies, depending on how the certificates presented by the TOE are obtained.

The TSF shall permit the TSF to initiate communication via the trusted channel.

The TSF shall initiate communication via the trusted channel for wireless access point connections, administrative communication, configured enterprise connections, and <selectables> <selectable>OTA updates</selectable> <selectable exclusive="yes">no other connections</selectable> </selectables>. The evaluator shall examine the TSS to determine that it describes the details of the TOE connecting to access points, VPN Gateways, and other trusted IT products in terms of the cryptographic protocols specified in the requirement, along with TOE-specific options or procedures that might not be reflected in the specifications. The evaluator shall also confirm that all protocols listed in the TSS are specified and included in the requirements in the ST. If OTA updates are selected, the TSS shall describe which trusted channel protocol is initiated by the TOE and is used for updates. The evaluator shall confirm that the operational guidance contains instructions for establishing the connection to access points, VPN Gateways, and other trusted IT products. The evaluator shall also perform the following tests for each protocol listed: The evaluator shall ensure, for each communication channel with an authorized IT entity, the channel data are not sent in plaintext and that a protocol analyzer identifies the traffic as the protocol under testing. [conditional] If is selected, the evaluator shall ensure that the TOE is able to initiate communications with a VPN Gateway, setting up the connections as described in the operational guidance and ensuring that communication is successful. [conditional] If OTA updates are selected, the evaluator shall trigger an update request according to the operational guidance and shall ensure that the communication is successful. For any other selected protocol (not tested in Test 1, 2, or 3), the evaluator shall ensure that the TOE is able to initiate communications with a trusted IT product using the protocol, setting up the connection as described in the operational guidance and ensuring that the communication is successful.

Initiation and termination of trusted channel

Trusted channel protocol Non-TOE endpoint of connection

The Security Objectives in were constructed to address threats identified in . The Security Functional Requirements (SFRs) in are a formal instantiation of the Security Objectives. The PP identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the documentation applicable for the evaluation and performs independent testing. This section lists the set of SARs from CC part 3 that are required in evaluations against this PP. Individual Evaluation Activities to be performed are specified both in as well as in this section. The general model for evaluation of TOEs against STs written to conform to this PP is as follows: After the ST has been approved for evaluation, the ITSEF will obtain the TOE, supporting environmental IT, and the administrative/user guides for the TOE. The ITSEF is expected to perform actions mandated by the Common Evaluation Methodology (CEM) for the ASE and ALC SARs. The ITSEF also performs the Evaluation Activities contained within , which are intended to be an interpretation of the other CEM evaluation requirements as they apply to the specific technology instantiated in the TOE. The Evaluation Activities that are captured in also provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the PP. The TOE Security Assurance Requirements are identified in . : Security Assurance Requirements Security Target (ASE) Conformance Claims (ASE_CCL.1) Extended Components Definition (ASE_ECD.1) ST Introduction (ASE_INT.1) Security Objectives for the Operational Environment (ASE_OBJ.1) Direct Rationale Security Requirements (ASE_REQ.1) Security Problem Definition (ASE_SPD.1) TOE Summary Specification (ASE_TSS.1) Development (ADV) Basic Functional Specification (ADV_FSP.1) Guidance Documents (AGD) Operational User Guidance (AGD_OPE.1) Preparative Procedures (AGD_PRE.1) Life Cycle Support (ALC) Labeling of the TOE (ALC_CMC.1) TOE CM Coverage (ALC_CMS.1) Timely Security Updates (ALC_TSU_EXT.1) Tests (ATE) Independent Testing – Conformance (ATE_IND.1) Vulnerability Assessment (AVA) Vulnerability Survey (AVA_VAN.1) The ST is evaluated as per ASE activities defined in the CEM for ASE_CCL.1, ASE_ECD.1, ASE_INT.1, ASE_OBJ.1, ASE_REQ.1, ASE_SPD.1, and ASE_TSS.1. In addition, there may be Evaluation Activities specified within that call for necessary descriptions to be included in the TSS that are specific to the TOE technology type. The design information about the TOE is contained in the guidance documentation available to the end user as well as the TSS portion of the ST, and any additional information required by this PP that is not to be made public.

The functional specification describes the TOE Security Functions Interface (TSFIs). It is not necessary to have a formal or complete specification of these interfaces. Additionally, because TOEs conforming to this PP will necessarily have interfaces to the Operational Environment that are not directly invokable by TOE users, there is little point specifying that such interfaces be described in and of themselves since only indirect testing of such interfaces may be possible. For this PP, the activities for this family should focus on understanding the interfaces presented in the TSS in response to the functional requirements and the interfaces presented in the AGD documentation. No additional "functional specification" documentation is necessary to satisfy the evaluation activities specified. Several TSS evaluation activities reference the need for the TOE to have API documentation to demonstrate that certain functions exist and can be performed in the manner required by this PP. These evaluation activities reference "other documentation" as it may not be practical to include this in the TSS itself. Vendor API documentation may exist outside the ST and be referenced separately. The interfaces that need to be evaluated are characterized through the information needed to perform the evaluation activities listed, rather than as an independent, abstract list.

The developer shall provide a functional specification.

The developer shall provide a tracing from the functional specification to the SFRs. As indicated in the introduction to this section, the functional specification is comprised of the information contained in the AGD_OPE, AGD_PRE, and the API information that is provided to application developers, including the APIs that require privilege to invoke. The developer may reference a website accessible to application developers and the evaluator. The API documentation must include those interfaces required in this profile. The API documentation must clearly indicate to which products and versions each available function applies. The evaluation 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.

The functional specification shall describe the purpose and method of use for each SFR-enforcing and SFR-supporting TSFI.

The functional specification shall identify all parameters associated with each SFR-enforcing and SFR-supporting TSFI.

The functional specification shall provide rationale for the implicit categorization of interfaces as SFR-non-interfering.

The tracing shall demonstrate that the SFRs trace to TSFIs in the functional specification.

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

The evaluator shall determine that the functional specification is an accurate and complete instantiation of the SFRs. There are no specific evaluation activities associated with these SARs, except ensuring the information is provided. The functional specification documentation is provided to support the evaluation activities described in , and other activities described for AGD, ATE, and AVA SARs. The requirements on the content of the functional specification information is implicitly assessed by virtue of the other evaluation activities being performed; if the evaluator is unable to perform an activity because there is insufficient interface information, then an adequate functional specification has not been provided.

The guidance documents will be provided with the ST. Guidance must include a description of how the IT personnel verifies that the Operational Environment can fulfill its role for the security functionality. The documentation should be in an informal style and readable by the IT personnel. Guidance must be provided for every operational environment that the product supports as claimed in the ST. This guidance includes: Instructions to successfully install the TSF in that environment Instructions to manage the security of the TSF as a product and as a component of the larger operational environment Instructions to provide a protected administrative capability Guidance pertaining to particular security functionality is also provided; requirements on such guidance are contained in the evaluation activities specified with each requirement.

The developer shall provide operational user guidance. The operational user guidance does not have to be contained in a single document. Guidance to users, administrators and application developers can be spread among documents or web pages. Where appropriate, the guidance documentation is expressed in the eXtensible Configuration Checklist Description Format (XCCDF) to support security automation. Rather than repeat information here, the developer should review the evaluation activities for this component to ascertain the specifics of the guidance that the evaluator will be checking for. This will provide the necessary information for the preparation of acceptable guidance.

The operational user guidance shall describe, for each user role, the user-accessible functions and privileges that should be controlled in a secure processing environment, including appropriate warnings. User and administrator (e.g., MDM agent), and application developer are to be considered in the definition of user role.

The operational user guidance shall describe, for each user role, how to use the available interfaces provided by the TOE in a secure manner.

The operational user guidance shall describe, for each user role, the available functions and interfaces, in particular all security parameters under the control of the user, indicating secure values as appropriate.

The operational user guidance shall, for each user role, clearly present each type of security-relevant event relative to the user-accessible functions that need to be performed, including changing the security characteristics of entities under the control of the TSF.

The operational user guidance shall identify all possible modes of operation of the OS (including operation following failure or operational error), their consequences, and implications for maintaining secure operation.

The operational user guidance shall, for each user role, describe the security measures to be followed in order to fulfill the security objectives for the operational environment as described in the ST.

The operational user guidance shall be clear and reasonable.

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. Some of the contents of the operational guidance are verified by the evaluation activities in and evaluation of the TOE as defined in [CEM]. The following additional information is also required. The operational guidance shall contain a list of natively installed applications and any relevant version numbers. If any third party vendors are permitted to install applications before purchase by the end user or enterprise, these applications shall also be listed. The operational guidance shall contain instructions for configuring the cryptographic engine associated with the evaluated configuration of the TOE. It shall provide a warning to the administrator that use of other cryptographic engines was not evaluated nor tested during the CC evaluation of the TOE. The documentation must describe the process for verifying updates to the TOE by verifying a digital signature. The evaluator shall verify that this process includes the following steps: Instructions for obtaining the update itself. This should include instructions for making the update accessible to the TOE (e.g., placement in a specific directory). Instructions for initiating the update process, as well as discerning whether the process was successful or unsuccessful. This includes generation of the hash/digital signature. The TOE will likely contain security functionality that does not fall in the scope of evaluation under this PP. The operational guidance shall make it clear to an administrator which security functionality is covered by the evaluation activities.

The developer shall provide the TOE, including its preparative procedures. As with the operational guidance, the developer should look to the evaluation activities to determine the required content with respect to preparative procedures.

The preparative procedures shall describe all the steps necessary for secure acceptance of the delivered TOE in accordance with the developer's delivery procedures.

The preparative procedures shall describe all the steps necessary for secure installation of the TOE and for the secure preparation of the operational environment in accordance with the security objectives for the operational environment as described in the ST.

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

The evaluator shall apply the preparative procedures to confirm that the OS can be prepared securely for operation. As indicated in the introduction above, there are significant expectations with respect to the documentation—especially when configuring the operational environment to support TOE functional requirements. The evaluator shall check to ensure that the guidance provided for the TOE adequately addresses all platforms claimed for the TOE in the ST.

At the assurance level provided for TOEs conformant to this PP, life-cycle support is limited to end-user-visible aspects of the life-cycle, rather than an examination of the TOE vendor’s development and configuration management process. This is not meant to diminish the critical role that a developer’s practices play in contributing to the overall trustworthiness of a product; rather, it is a reflection on the information to be made available for evaluation at this assurance level.

This component is targeted at identifying the TOE such that it can be distinguished from other products or versions from the same vendor and can be easily specified when being procured by an end user.

The developer shall provide the TOE and a reference for the TOE.

The TOE shall be labeled with a unique reference.

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. 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. If the vendor maintains a web site advertising the TOE, the evaluator shall examine the information on the web site to ensure that the information in the ST is sufficient to distinguish the product.

Given the scope of the TOE and its associated evaluation evidence requirements, this component’s evaluation activities are covered by the evaluation activities listed for ALC_CMC.1.

The developer shall provide a configuration list for the TOE.

The configuration list shall include the following: the TOE itself; and the evaluation evidence required by the SARs.

The configuration list shall uniquely identify the configuration items.

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The "evaluation evidence required by the SARs" in this PP is limited to the information in the ST coupled with the guidance provided to administrators and users under the AGD requirements. By ensuring that the TOE is specifically identified and that this identification is consistent in the ST and in the AGD guidance (as done in the evaluation activity for ALC_CMC.1), the evaluator implicitly confirms the information required by this component. Life-cycle support is targeted aspects of the developer’s life-cycle and instructions to providers of applications for the developer’s devices, rather than an in-depth examination of the TSF manufacturer’s development and configuration management process. This is not meant to diminish the critical role that a developer’s practices play in contributing to the overall trustworthiness of a product; rather, it’s a reflection on the information to be made available for evaluation. The evaluator shall ensure that the developer has identified (in public-facing development guidance for their platform) one or more development environments appropriate for use in developing applications for the developer’s platform. For each of these development environments, the developer shall provide information on how to configure the environment to ensure that buffer overflow protection mechanisms in the environments are invoked (e.g., compiler and linker flags). The evaluator shall ensure that this documentation also includes an indication of whether such protections are on by default, or have to be specifically enabled. The evaluator shall ensure that the TSF is uniquely identified (with respect to other products from the TSF vendor), and that documentation provided by the developer in association with the requirements in the ST is associated with the TSF using this unique identification.

The developer shall document and provide flaw remediation procedures addressed to TOE developers.

The flaw remediation procedures documentation shall describe the procedures used to track all reported security flaws in each release of the TOE.

The flaw remediation procedures shall require that a description of the nature and effect of each security flaw be provided, as well as the status of finding a correction to that flaw.

The flaw remediation procedures shall require that corrective actions be identified for each of the security flaws.

The flaw remediation procedures documentation shall describe the methods used to provide flaw information, corrections and guidance on corrective actions to TOE users.

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. Evaluated as specified by [CEM].

The developer shall document and provide flaw remediation procedures addressed to TOE developers.

The developer shall establish a procedure for accepting and acting upon all reports of security flaws and requests for corrections to those flaws.

The developer shall provide flaw remediation guidance addressed to TOE users.

The flaw remediation procedures documentation shall describe the procedures used to track all reported security flaws in each release of the TOE.

The flaw remediation procedures shall require that a description of the nature and effect of each security flaw be provided, as well as the status of finding a correction to that flaw.

The flaw remediation procedures shall require that corrective actions be identified for each of the security flaws.

The flaw remediation procedures documentation shall describe the methods used to provide flaw information, corrections and guidance on corrective actions to TOE users.

The flaw remediation procedures shall describe a means by which the developer receives from TOE users reports and enquiries of suspected security flaws in the TOE.

The procedures for processing reported security flaws shall ensure that any reported flaws are remediated and the remediation procedures issued to TOE users.

The procedures for processing reported security flaws shall provide safeguards that any corrections to these security flaws do not introduce any new flaws.

The flaw remediation guidance shall describe a means by which TOE users report to the developer any suspected security flaws in the TOE.