The TSF shall alert the administrators in the event of any of the following: <h:ul> <h:li>Change in enrollment status</h:li> <h:li>Failure to apply policies to a MD</h:li> <h:li><selectables><selectable><assignable>other events</assignable></selectable><selectable>no other events</selectable></selectables>.</h:li> </h:ul>

For distributed TOEs, the administrator ensures that the availability of every TOE component is checked as appropriate to reduce the risk of an undetected attack on (or failure of) one or more TOE components. The administrator also ensures that it is checked as appropriate for every TOE component that the audit functionality is running properly. The enterprise IT infrastructure provides security for a network that is available to the TOE and MDs that prevents unauthorized access. TOE Administrators are trusted to follow and apply all administrator guidance in a trusted manner. Users of the MD are trained to securely use the MD and apply all guidance in a trusted manner. Reliable timestamps are provided by the operational environment for the TOE. A wireless network will be available to the MDs.

For a distributed TOE, the ST author should reference for guidance on how each SFR should be met. The table details whether SFRs should be met by all TOE components, by at least one TOE component or whether they are dependent on the feature being implemented by the TOE component. The ST for a distributed TOE must include a mapping of SFRs to each of the components of the TOE. (Note that this deliverable is examined as part of the ASE_TSS.1 and AVA_VAN.1 Evaluation Activities.) Test Environment for Evaluation Activities As described in the evaluation activities below, the ST for an MDM system is required to list all the supported MDM agents and MD platforms with which an MDM server operates. The identified evaluation activities for testing that includes the use of an agent should be completed for each MDM agent and platform listed in the ST. The evaluation activities for testing that include use of an MDM agent will ensure that the server interacts appropriately with the agent (i.e., sends a policy update to the agent), but will not ensure that the MDM agent handles the received data correctly (i.e., appropriately applies the policy to the device), as that is accounted for in the Evaluation Activities in PP_MDF, PP_GPOS, or . In addition to the above guidance, if the TOE server acts as a primary MDM server and interfaces with one or more subordinate MDM servers, then the ST is required to list all of the supported subordinate MDM servers. All evaluation activity testing that includes the use of a subordinate MDM server should be completed for each of the subordinate MDM servers listed in the ST. MDM agent testing should be done for devices managed directly by the primary MDM Server. MDM agent testing with a subordinate MDM server will be done during the subordinate MDM server evaluation. If the TOE server acts as a subordinate MDM server and interfaces with one or more primary MDM servers, then the ST is required to list all of the supported primary MDM servers, along with all of the supported MDM agents and MD platforms with which it operates. A test primary MDM server may be used for evaluation activity testing that requires the use of a primary MDM server. For clarification purposes "primary MDM server" and "subordinate MDM server" will be specified when the distinction is necessary and relevant to explanations and testing, otherwise "MDM server" may be used when the distinction is not necessary and could reference either a primary MDM server or subordinate MDM server.

This family defines requirements for the TSF to alert administrators when a set of specified events occurs.

This family defines requirements for the TSF to provide an interface for the MDM server to convey information about MDs for other systems.

This family defines requirements for administrators to see network connectivity status.

defines requirements for alerting the administrator to events.

The following actions could be considered for the management functions in FMT. Install policies. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP, PP-Module, functional package or ST: Type of alert. Identity of MD that sent alert No dependencies.

The TSF shall alert the administrators in the event of any of the following: <h:ul> <h:li>Change in enrollment status</h:li> <h:li>Failure to apply policies to a MD</h:li> <h:li><selectables><selectable><assignable>other events</assignable></selectable><selectable>no other events</selectable></selectables>.</h:li> </h:ul> An alert can be defined as anything providing straightaway notice to the administrator. An alert is different from an audit record, however the fact that an alert was sent should be audited per FAU_GEN.1/AUDITGEN. Email, pop-up notifications, or other methods are acceptable forms of alerts. If the TOE is a subordinate MDM server, then sending an alert to the primary MDM server over the trusted channel is sufficient to fulfill this requirement. The MDM agent is required to report to the MDM server on successful application of policies on a MD, and failures can be inferred from the absence of such alerts. This requirement is intended to ensure that the MDM server notifies administrators when policies are not properly installed. Failure to properly install policy updates does not affect the enrollment status of the MD. The evaluator shall examine the TSS and verify that it describes how the alert system is implemented. The evaluator shall also verify that a description of each assigned event is provided in the TSS. The evaluator shall examine the guidance document and verify that it describes how the alerts can be configured, if configurable. For each MDM agent or platform listed as supported in the ST: The evaluator shall enroll a device and ensure that the MDM server alerts the administrator of the change in enrollment status. The evaluator shall unenroll (retire) a device and ensure that the MDM server alerts the administrator of the change in enrollment status. The evaluator shall configure policies, which the MDM agent should not be able to apply. These policies shall include: a setting which is configurable on the MDM server interface but not supported by the platform on which the MDM agent runs, if any such settings exist a valid configuration setting with an invalid parameter, which may require manual modification of the policy prior to transmission to the device The evaluator shall deploy such policies and verify that the MDM server alerts the administrator about the failed application of the policy. Alternate test: The evaluator shall configure a policy that the MDM agent can successfully apply. The evaluator blocks the response from the MDM agent of the successful application of the policy, resulting in the MDM server alerting of a failure of application. The evaluator shall verify that the MDM server alerts the administrator about the failed application of the policy. [conditional) If any additional events are specified in the assignment, the evaluator shall trigger each of the events listed and ensure that the MDM server alerts the administrator.

Type of alert

Identity of MD that sent alert.

defines requirements for providing information to enrolled MDs through a secure channel.

The following actions could be considered for the management functions in FMT. Query the current version of the MD firmware or software. Query the hardware model of the MD. Query the current version of installed applications. There are no auditable events foreseen. FTP_ITC.1 Inter-TSF Trusted Channel

The TSF shall provide <selectables> <selectable>an interface that provides responses to queries about the configuration of enrolled devices</selectable> <selectable>an interface that permits the export of data about the configuration of enrolled devices</selectable> </selectables> to authorized entities over a channel that meets the secure channel requirements in <h:b>FTP_ITC.1/OE_XFER_IT</h:b>. The provided information for each enrolled MD includes: <h:ul> <h:li>The current version of the MD firmware or software</h:li> <h:li>The hardware model of the MD</h:li> <h:li> <selectables linebreak="yes"> <selectable>The current version of installed mobile applications,</selectable> <selectable>List of MD configuration policies that are in place on the device (as defined in <xref to="fel-smf-man-agnt"/>),</selectable> <selectable><assignable>list of other available information about enrolled MDs</assignable>,</selectable> <selectable>no other information</selectable></selectables>. </h:li> </h:ul>

The TSF shall provide <assignable>type of interface</assignable> to authorized entities over a channel that meets the secure channel requirements in FTP_ITC.1(1). The provided information for each enrolled MD includes: <h:ul> <h:li>The current version of the MD firmware or software</h:li> <h:li>The current version of the hardware model of the MD</h:li> <h:li> <selectables linebreak="yes"> <selectable>The current version of installed applications,</selectable> <selectable>List of MD configuration policies that are in place on the device (as defined in <xref to="fel-smf-man-agnt"/>),</selectable> <selectable><assignable>list of other available information about enrolled MDs</assignable>,</selectable> <selectable>no other information</selectable></selectables>. </h:li> </h:ul>

The intent of this requirement is that the MDM server be able to provide compliance information about enrolled MDs for use by other enterprise security infrastructure systems. There are active standards efforts underway by the Internet Engineering Task Force (IETF) Security Automation and Continuous Monitoring (SACM) Working Group and others to define protocols and standards to assess and report on endpoint device posture. It is expected that this requirement will evolve in future versions of this Protection Profile as standards efforts mature. If the TOE acts as a subordinate MDM server, then this SFR also ensures that there is a mechanism for the primary MDM server to query information about the devices managed by the subordinate MDM server. The evaluator shall examine the TSS to verify that it describes the TOE's compliance reporting capability with respect to whether it provides responses to queries about the configuration of enrolled devices or whether it permits the export of data about the configuration of these devices. The evaluator shall also verify that the TSS identifies the trusted channel used to protect data that is transmitted over this interface. Lastly, the evaluator shall verify that the TSS identifies the information that is provided for each enrolled device. The evaluator shall check to ensure that the operational guidance contains instructions on how to access the MDM server's compliance reporting interface. Using the operational guidance, the evaluator shall demonstrate the ability to access the compliance reporting interface from an authorized entity and successfully obtain information about enrolled devices. The evaluator shall attempt to access the compliance reporting interface from an unauthorized entity and demonstrate that the attempt is denied.

The TSF shall <selectables> <selectable>invoke platform-provided functionality</selectable> <selectable>implement functionality</selectable> </selectables> to generate audit data of the following auditable events: <h:li>All auditable events for the [<h:i>not specified</h:i>] level of audit;</h:li> [ <h:ol type="a"><h:i> <h:li>All administrative actions</h:li> <h:li> <selectables> <selectable>Commands issued to the MDM agent</selectable> <selectable>Commands issued to the subordinate MDM server</selectable> <selectable>Status updates provided to the primary MDM server</selectable> <selectable>none</selectable> </selectables> </h:li> <h:li>Specifically defined auditable events listed in <xref g="t-audit-mandatory"/></h:li> <h:li><selectables linebreak="yes"> <selectable>Start up and shut down of the audit functions,</selectable> <selectable id="sel-at2">Auditable events defined in <xref g="t-audit-optional"/> for Strictly Optional SFRs,</selectable> <selectable id="sel-at3">Auditable events defined in <xref g="t-audit-objective"/> for Objective SFRs,</selectable> <selectable id="sel-at4">Auditable events defined in <xref g="t-audit-sel-based"/> for Selection-Based SFRs,</selectable> <selectable id="sel-atssh">Auditable events for <xref to="ssh"/>,</selectable> <selectable id="sel-attls">Auditable events for <xref to="tls"/>,</selectable> <selectable id="sel-atssh">Auditable events for <xref to="X509"/>,</selectable> <selectable>no other events</selectable> </selectables></h:li></h:i>]. </h:ol> This requirement outlines the events for which audit data must be generated by either the MDM system or the MDM server platform. Each audit data event may be written by the MDM system or may be dispatched to the operating system on which it runs. It is acceptable to select both "invoke platform-provided functionality" and "implement functionality." It should be specified which auditable events are completed by the MDM system and which are completed by the MDM platform. For distributed TOEs, each component must generate audit data for each of the SFRs that it implements. If more than one TOE component is involved when an audit event is triggered, the event has to be audited on each component (e.g., rejection of a connection by one component while attempting to establish a secure communication channel between two components should result in an audit event being generated by both components). This is not limited to error cases but also includes events about successful actions like successful build up or tear down of a secure communication channel between TOE components. Item a above requires all administrative actions to be auditable. Administrative actions refer to any management functions specified by FMT_MOF.1/FUNCBE. Thus no additional specification for the auditability of these actions is specified in aside from those that require additional record content. If the TOE is distributed and the given component does not deal with setting the policy applied to the MDM agent, it is acceptable to not have any administrative actions to audit. Item b includes those commands, which may be performed automatically based on triggers or on a schedule. If the TOE server acts as a primary MDM server and interfaces with a subordinate MDM server, then "Commands issued to the subordinate MDM server" must be selected. If the TOE server acts as a subordinate MDM server and interfaces with a primary MDM server, then "Status updates provided to the primary MDM server" must be selected. For distributed TOEs, if the TOE component directly interacts with a primary MDM server, subordinate MDM server, or MDM agent then the corresponding selection should be made for that component. If the TOE component does not directly interact with any of these entities, then it is acceptable to select "none". In item d above, "Start up and shut down of the audit functions" must be selected if the TSF has a start up and shut down phase. If the TSF does not have a distinct start up or shut down phase (e.g., a cloud service), this selection is not required. Additionally, if the TOE is distributed, this applies to all components. Depending on the specific requirements selected by the ST author from SFRs, optional requirements, selection-based requirements, and objective requirements, the ST author should include the appropriate auditable events from , , and in the ST for the requirements selected. Each functional package includes auditable events for the SFRs defined in the package. The ST author is expected to include the auditable events (if any) for each SFR that the ST claims from a functional package. The evaluator shall check the TSS and ensure that it lists all of the auditable events. The evaluator shall check to make sure that every audit event type mandated by the PP is described in the TSS. The evaluator shall verify that for every audit event described in the TSS, the description indicates where the audit event is generated (TSF, TOE platform). If "invoke platform-provided functionality" is selected, the evaluator shall examine the TSS to verify that it describes (for each supported platform) how this functionality is invoked (it should be noted that this may be through a mechanism that is not implemented by the MDM server; nonetheless, that mechanism will be identified in the TSS as part of this evaluation activity). The evaluator shall check the administrative guide and ensure that it lists all of the auditable events. The evaluator shall check to make sure that every audit event type mandated by the PP is described. 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 specified 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. 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 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 (if applicable)</h:li> <h:li>The outcome (success or failure) of the event</h:li> <h:li>Additional information in <xref g="t-audit-mandatory"/></h:li> <h:li><refinement><selectables linebreak="yes"> <selectable id="sel-at2-i">Additional information defined in <xref g="t-audit-optional"/> for Strictly Optional SFRs,</selectable> <selectable id="sel-at3-i">Additional information defined in <xref g="t-audit-objective"/> for Objective SFRs,</selectable> <selectable id="sel-at4-i">Additional information defined in <xref g="t-audit-sel-based"/> for Selection-Based SFRs,</selectable> <selectable id="sel-atssh">Additional information defined in <xref to="ssh"/>,</selectable> <selectable id="sel-attls">Additional information defined in <xref to="tls"/>,</selectable> <selectable id="sel-atssh">Additional information defined in <xref to="X509"/>,</selectable> <selectable>No other additional information</selectable> </selectables></refinement>.</h:li> </h:ul> This requirement outlines the information to be included in audit data. All audits must contain at least the information mentioned in . The ST author must identify in the TSS which information of the audit data is performed by the TSF and that which is performed by the TOE platform. The evaluator shall check the TSS and ensure that it 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 the administrative guide and ensure that it 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 the description of the fields contains the information required in . When verifying the test results from , the evaluator shall ensure the audit data generated during testing matches the format specified in the administrative guide, and that the fields for each audit data have the proper entries. 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 <h:b>MAS server</h:b> shall be able to generate audit data of the following auditable events: [<h:i><h:ol type="a"> <h:li>Failure to push a new application on a MD</h:li> <h:li>Failure to update an existing application on a MD</h:li> </h:ol></h:i>]. The MDM agent is required to report to the MAS server on successful receipt of an application or update on a MD, and failures can be inferred from the absence of such alerts.

The <selectables><selectable><h:b>MAS server</h:b></selectable><selectable><h:b>MAS server platform</h:b></selectable></selectables> shall record within the audit data at least the following information: <h:ul> <h:li>date and time of the auditable event</h:li> <h:li>type of event</h:li> <h:li>MD identity</h:li> <h:li><assignable>other audit relevant information</assignable>.</h:li> </h:ul> All audits must contain at least the information mentioned in , but may contain more information which can be assigned. The ST author must identify in the TSS which information of the audit data is performed by the TSF and that which is performed by the TOE platform. This requirement is claimed if "enable/disable/modify policies listed in FMT_SMF.1/MAS" is selected in FMT_MOF.1.1/FUNCBE. The evaluator shall check the TSS and ensure that it 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 the administrative guide and ensure that it 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 the description of the fields contains the information required in . The evaluator shall verify that when an application or update push fails, that the audit data generated match the format specified in the guidance and that the fields in each audit data have proper entries. When verifying the test results from , the evaluator shall ensure the audit data generated during testing match the format specified in the administrative guide, and that the fields in each audit data have the proper entries. 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.

defines requirements for authorized administrators to read network connectivity status.

The following actions could be considered for the management functions in FMT. Query connectivity status. There are no auditable events foreseen. FAU_ALT_EXT.2 Agent Alerts

The TSF shall provide authorized administrators with the capability to read the network connectivity status of an enrolled agent. The MDM server establishes the network connectivity status of enrolled agents using periodic reachability event alerts from the agents according to FAU_ALT_EXT.2.1 in the . This status may be determined by sending an update request from the MDM server which the agent is required to respond to or by using scheduled periodic notifications of connectivity initiated by the MDM agent. If the TOE server acts as a subordinate MDM server then there should be some mechanism for the primary MDM server to initialize and read results of the network reachability tests performed by the subordinate MDM server on those devices that it manages. The evaluator ensures that the TSS describes how reachability events are implemented, for each supported MD platform. The evaluator verifies that this description clearly indicates who (MDM agent or MDM server) initiates reachability events. The evaluator shall verify that the guidance instructs administrators on the method of determining the network connectivity status of an enrolled agent. For each MDM agent or platform listed as supported in the ST: The evaluator shall configure the MDM agent or platform to perform a network reachability test, both with and without such connectivity and shall ensure that by following the guidance, the evaluator can determine results that reflect both.

The TSF shall <selectables> <selectable><h:b>invoke platform-provided functionality</h:b></selectable> <selectable><h:b>implement functionality</h:b></selectable> </selectables> <h:b>to</h:b> provide [<h:i>authorized administrators</h:i>] with the capability to read [<h:i>all audit information</h:i>] from the audit data.

The TSF shall <selectables> <selectable><h:b>invoke platform-provided functionality</h:b></selectable> <selectable><h:b>implement functionality</h:b></selectable> </selectables> <h:b>to</h:b> provide the audit data in a manner suitable for the <h:b>authorized administrators</h:b> to interpret the information. The intent of this requirement is to ensure that the administrator can view and interpret the audit data and to prevent unauthorized users from accessing the logs. If "invoke platform-provided functionality" is selected, the evaluator shall examine the TSS to verify that it describes (for each supported platform) how this functionality is invoked (it should be noted that this may be through a mechanism that is not implemented by the MDM server; nonetheless, that mechanism will be identified in the TSS as part of this evaluation activity). The evaluator shall check the operational guidance and ensure that it describes how the administrator accesses the audit data and describes the format of audit data. The evaluator shall attempt to view the audit data as the authorized administrator and verify that the action succeeds. The evaluator shall ensure the audit data generated during testing match the format specified in the administrative guide.

The TSF shall <selectables> <selectable><h:b>invoke platform-provided functionality</h:b></selectable> <selectable><h:b>implement functionality</h:b></selectable></selectables> 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. The ST author must select whether the TSF or the platform maintains the audit data. For the ST author, the assignment is used to list any additional criteria or "none." If "invoke platform-provided functionality" is selected, the evaluator shall examine the TSS to verify that it describes (for each supported platform) how this functionality is invoked (it should be noted that this may be through a mechanism that is not implemented by the MDM server; nonetheless, that mechanism will be identified in the TSS as part of this evaluation activity). 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 is 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 be able to <h:b>transmit the generated audit data to an external IT entity using a trusted channel according to FTP_ITC.1/OE_XFER_IT</h:b> and store generated audit data on the <selectables> <selectable id="locally">TOE itself</selectable> <selectable>no other storage</selectable> </selectables>. Per , audit data may be generated by the TOE, the platform, or both. If audit data is generated by the TOE, the TSF must have the ability to securely transmit this data to a remote entity. It may additionally store this data within the TOE boundary, in which case "the TOE itself" is selected and FAU_STG.2 must be included in the ST. Regardless of whether the TSF stores the audit data it generates within the TOE boundary, the TOE must always be able to securely transmit the audit data it generates to a remote entity. If audit data is generated by the platform, any secure local storage or secure remote transmission of this data is the responsibility of the platform. Although the audit server is outside of the TOE, the TSF should still be able to support mutual authentication. There are no requirements levied on the audit server, but the TOE should be able to support TLS client certificate authentication. This way if the non-TOE audit server does support verifying client certificates, the TSF is able to make use of that. For distributed TOEs, each component must be able to export any audit data it generates across a protected channel. This may involve individual components independently transmitting audit data to the same environmental audit server via FTP_ITC.1/OE_XFER_IT, or it may involve one component of a distributed TOE aggregating audit data generated by other components prior to external transmission. In this case, the internal communication of audit data is protected via the mechanisms specified in FPT_ITT.1/INTRA_XFER or FPT_ITT.1/INTRA_XFER_AGENT as appropriate. The intent of this requirement in the context of a distributed TOE is that all audit data generated by all components of the TSF be transmitted to an environmental entity entirely through trusted channels, regardless of whether it is transmitted directly from the TSF to the operational environment or whether it is first transmitted to another part of the TOE. The evaluator shall examine the TSS to ensure it describes the means by which the audit data are transferred to the external audit server, and how the trusted channel is provided. The evaluator shall also examine the operational guidance to determine that it describes the relationship between the local audit data and the audit data that are sent to the audit log server. For example, when an audit event is generated, is it simultaneously sent to the external server and the local store, or is the local store used as a buffer and "cleared" periodically by sending the data to the audit server. The evaluator shall also examine the operational guidance to ensure it describes how to establish the trusted channel to the audit server, as well as describe any requirements on the audit server (particular audit server protocol, version of the protocol required, etc.), as well as configuration of the TOE needed to communicate with the audit server. Testing of the trusted channel mechanism will be performed as defined in the associated evaluation activities for the particular trusted channel mechanism. The evaluator shall perform the following test for this requirement: The evaluator shall establish a session between the TOE and the audit server according to the configuration guidance provided. The evaluator shall then examine the traffic that passes between the audit server and the TOE during several activities of the evaluator's choice designed to generate audit data to be transferred to the audit server. The evaluator shall observe that these data are not able to be viewed in the clear during this transfer, and that they are successfully received by the audit server. The evaluator shall record the particular software (name, version) used on the audit server during testing.

The TSF shall be able to [<h:i>prevent</h:i>] unauthorizd modifications to the stored audit data in the audit trail. If "store audit data locally" is selected in , this SFR must be included in the ST. The purpose of this requirement is to ensure that audit data are stored securely. The ST author is responsible for selecting whether audit data are maintained when audit storage or failure occurs. The ST author must choose a means by which audit data are saved and select the events during which the data will be saved. The TSF may rely on the underlying operating system for this functionality, and the first selection should be made appropriately. If "invoke platform-provided functionality" is selected, the evaluator shall examine the TSS to verify that it describes (for each supported platform) how the audit data protection functionality is invoked (it should be noted that this may be through a mechanism that is not implemented by the MDM server; nonetheless, that mechanism will be identified in the TSS as part of this evaluation activity). If "implement functionality" is selected, the evaluator shall ensure that the TSS describes how the audit data are protected from unauthorized modification or deletion. The evaluator shall ensure that the TOE uses audit trail specific protection mechanisms. The evaluator shall perform the following tests: The evaluator shall access the audit trail as an unauthorized user and attempt to modify and delete the audit data. The evaluator shall verify that these attempts fail. The evaluator shall access the audit trail as an authorized user and attempt to modify and delete the audit data. The evaluator shall verify that these attempts succeed. The evaluator shall verify that only the records intended for modification and deletion are modified and deleted.

The TSF shall be able to <selectables onlyone="yes"> <selectable>prevent</selectable> <selectable>detect</selectable> </selectables> unauthorized modifications to the stored audit data in the audit trail.

This family describes the registration process, including the capability for the administrator to enable or disable communications between a distributed TOE and other components of the TOE.

defines requirements for the registration process for distributed TOEs.

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: Enabling or disabling communications between a pair of components. Identities of the endpoint's pairs enabled or disabled. FPT_ITT.1 TSF Data Transfer FTP_TRP.1 Trusted Path

The TSF shall <selectables> <selectable>invoke platform-provided functionality</selectable> <selectable>implement functionality</selectable> </selectables> to require an Administrator to enable communications between any pair of TOE components before such communication can take place.

The TSF shall <selectables> <selectable>invoke platform-provided functionality</selectable> <selectable>implement functionality</selectable> </selectables> to implement a registration process in which components establish and use a communications channel that uses <selectables> <selectable>A channel that meets the secure channel requirements in <selectables> <selectable>FTP_ITC.1/OE_XFER_IT</selectable> <selectable>FPT_ITT.1/INTRA_XFER</selectable> <selectable>FPT_ITT.1/INTRA_XFER_AGENT</selectable> </selectables>,</selectable> <selectable>A channel that meets the secure registration channel requirements in <selectables> <selectable>FTP_TRP.1/TRUSTPATH_ENROLL</selectable> <selectable>FTP_TRP.1/TRUSTPATH_JOIN</selectable> </selectables>,</selectable> <selectable>No channel</selectable> </selectables> for at least TSF data.

The TSF shall <selectables> <selectable>invoke platform-provided functionality</selectable> <selectable>implement functionality</selectable> </selectables> to enable an administrator to disable communications between any pair of TOE components. This SFR is only applicable if the TOE is distributed and therefore has multiple components that need to communicate via an internal TSF channel. When creating the TSF from the initial pair of components, either of these components may be identified as the TSF for the purposes of satisfying the meaning of "TSF" in this SFR. The intention of this requirement is to ensure that there is a registration process that includes a positive enablement step by an administrator before components joining a distributed TOE can communicate with the other components of the TOE and before the new component can act as part of the TSF. The registration process may itself involve communication with the joining component: many implementations use a bespoke process for this, and the security requirements for the "registration communication" are then defined in . Use of this "registration communication" channel is not deemed inconsistent with the requirement of (i.e., the registration channel can be used before the enablement step, but only in order to complete the registration process). The channel selection (for the registration channel) in is essentially a choice between the use of a normal secure channel that is equivalent to a channel used to communicate with external IT entities (FTP_ITC.1/OE_XFER_IT) or existing TOE components (FPT_ITT.1/INTRA_XFER and FPT_ITT.1/INTRA_XFER_AGENT), or else a separate type of channel that is specific to registration (FTP_TRP.1/TRUSTPATH_ENROLL or FTP_TRP.1/TRUSTPATH_JOIN). If the TOE does not require a communications channel for registration (e.g., because the registration is achieved entirely by configuration actions by an administrator at each of the components) then the main selection in is completed with the "No channel" option. If the ST author selects the FTP_ITC.1/OE_XFER_IT or FPT_ITT.1/INTRA_XFER and FPT_ITT.1/INTRA_XFER_AGENT channel type in the main selection in then the TSS identifies the relevant SFR iteration that specifies the channel used. If the ST author selects the FTP_TRP.1/TRUSTPATH_ENROLL or FTP_TRP.1/TRUSTPATH_JOIN channel type, then the TSS (possibly with support from the operational guidance) describes details of the channel and the mechanisms that it uses (and describes how the registration process ensures that the channel can only be used by the intended joiner and gatekeeper). Note that the FTP_TRP.1/TRUSTPATH_ENROLL or FTP_TRP.1/TRUSTPATH_JOIN channel type may require support from security measures in the operational environment (see the definition of FTP_TRP.1/TRUSTPATH_ENROLL or FTP_TRP.1/TRUSTPATH_JOIN for details). Note that the channel that is set up and used for registration may be adopted as a continuing internal communication channel (i.e., between different TOE components) provided that the channel meets the requirements of FTP_ITC.1/OE_XFER_IT or FPT_ITT.1/INTRA_XFER / FPT_ITT.1/INTRA_XFER_AGENT. Otherwise the registration channel is closed after use and a separate channel is used for the internal communications. Specific requirements for Preparative Procedures relating to FCO_CPC_EXT.1 are defined in the Evaluation Activities. The evaluator shall examine the TSS to verify that it describes the mechanism for registering distributed TOE components using a secure channel, whether this is a dedicated registration channel or the same channel that is used for protected communications once registered, and whether the functionality is implemented by the TSF or invoked from its platform. The evaluator shall examine the guidance documentation to confirm that it contains instructions for enabling and disabling communications with any individual component of a distributed TOE. The evaluator shall confirm that the method of disabling is such that all other components can be prevented from communicating with the component that is being removed from the TOE (preventing the remaining components from either attempting to initiate communications to the disabled component, or from responding to communications from the disabled component). The evaluator shall confirm that an IT entity that is not currently a member of the distributed TOE cannot communicate with any component of the TOE until the non-member entity is enabled by an administrator for each of the non-equivalent TOE components that it is required to communicate with (non-equivalent TOE components are as defined in the minimum configuration for the distributed TOE) The evaluator shall confirm that after enablement, an IT entity can communicate only with the components that it has been enabled for. This includes testing that the enabled communication is successful for the enabled component pair, and that communication remains unsuccessful with any other component for which communication is possible but has not been explicitly enabled. Some TOEs may set up the registration channel before the enablement step is carried out, but in such a case the channel must not allow communications until after the enablement step has been completed. The evaluator shall separately disable each TOE component in turn and ensure that the other TOE components cannot then communicate with the disabled component, whether by attempting to initiate communications with the disabled component or by responding to communication attempts from the disabled component. In situations where one component acts as the 'Gatekeeper' for all other components, the test would involve disabling the components in turn on the Gatekeeper and ensuring that the TOE no longer communicates with disabled components.

Enabling or disabling communications between a pair of components.

Identities of the endpoint's pairs enabled or disabled.

This family defines requirements for management of cryptographic keys using mechanisms beyond what are specified in CC Part 2.

This family defines requirements for protecting HTTP communications between the TOE and an external IT entity.

This family defines requirements for generating IVs in accordance with NIST-approved cipher modes.

This family defines requirements for ensuring the protection of keys and secrets.

The TSF shall <selectables> <selectable>invoke platform-provided functionality</selectable> <selectable>implement functionality</selectable> </selectables> <h:b>to</h:b> 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-ecdsa-erb-P384">P-384</selectable> <selectable id="sel-exp-ak-ecdsa-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-ecdsa-rs-P384">P-384</selectable> <selectable id="sel-exp-ak-ecdsa-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>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. When generating ECC keys pairs for key agreement and if “ECDH” is claimed in FCS_CKM_EXT.7, 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. 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-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-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-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. 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 distribute cryptographic keys in accordance with a specified cryptographic key distribution method <selectables> <selectable id="sel-ckm-2-encap">key encapsulation as defined in FCS_COP.1/KeyEncap</selectable> <selectable id="sel-ckm-2-wrap">key wrapping as defined in FCS_COP.1/KeyWrap</selectable> </selectables> that meets the following: [<h:i>none</h:i>]. If "key encapsulation..." is selected, FCS_COP.1/KeyEncap is claimed. If "key wrapping..." is selected, FCS_COP.1/KeyWrap must be 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 key or keying material 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 <selectables> <selectable>invoking platform-provided functionality with the following rules: <h:ul> <h:li>For volatile memory, the destruction shall be executed by <selectables> <selectable>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> <selectable>ones</selectable> <selectable>a new value of a key</selectable> <selectable><assignable>some value that does not contain any keying material</assignable></selectable> </selectables>,</selectable> <selectable>removal of power to the memory,</selectable> <selectable>destruction of reference to the key directly followed by a request for garbage collection</selectable> </selectables></h:li> <h:li>For non-volatile memory that consists of the invocation of an interface provided by the underlying platform that <selectables> <selectable>logically addresses the storage location of the key and performs a <selectables> <selectable>single</selectable> <selectable> <assignable>ST author defined multi-pass</assignable></selectable> </selectables> 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> <selectable>ones</selectable> <selectable>a new value of a key</selectable> <selectable><assignable>some value that does not contain any keying material</assignable></selectable> </selectables>,</selectable> <selectable>instructs the underlying platform to destroy the abstraction that represents the key</selectable> </selectables> </h:li> </h:ul></selectable> <selectable>implementing key destruction 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></selectable></selectables> that meets the following: [<h:i>no standard</h:i>]. Even if "invoking platform-provided functionality with the following rules" is selected in , the TSF must determine when the plaintext keys and keying material are no longer needed and thus should be destroyed. 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. 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. Since this is a software-only TOE, the hardware controllers that manage non-volatile storage media are necessarily outside the TOE boundary. Thus, the TOE developer is likely to have little control over—or insight into—the functioning of these storage devices. The TOE must make a “best-effort” to destroy disused cryptographic keys by invoking the appropriate hardware interfaces—recognizing that the specific actions taken by the hardware are out of the TOE’s control. But in cases where the TOE has insight into the non-volatile storage technologies used by the hardware, or where the TOE can specify a preference or method for destroying keys, the destruction should be executed by a single, direct overwrite consisting of pseudorandom data or a new key, by a repeating pattern of any static value, or by a block erase. The interface referenced in the requirement could take different forms, the most likely of which is an API to an OS kernel. There may be various levels of abstraction visible. For instance, in a given implementation that overwrites a key stored in non-volatile memory, the application may have access to the file system details and may be able to logically address specific memory locations. In another implementation where an application instructs the underlying platform to destroy the representation of a key stored in non-volatile memory, the application may simply have a handle to a resource and can only ask the platform to delete the resource, as may be the case with a platforms secure key store. The latter implementation should only be used for the most restricted access. The level of detail to which the TOE has access should be described in the TSS. 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. If platform-provided functionality is invoked for key destruction, the evaluator shall verify that the TSS identifies the platform functions used for this. 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, whether the TSF destroys this key material itself or invokes the platform to do so. 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. In cases where testing reveals that third-party software modules or programming language run-time environments do not properly overwrite keys, this fact must be documented. Likewise, it must be documented if there is no practical way to determine whether such modules or environments destroy keys properly. In cases where it is impossible or impracticable to perform the above tests, the evaluator shall describe how keys are destroyed in such cases, to include: Which keys are affected The reasons why testing is impossible or impracticable Evidence that keys are destroyed appropriately (e.g., citations to component documentation, component developer/vendor attestation, component vendor test results) Aggravating and mitigating factors that may affect the timeliness or execution of key destruction (e.g., caching, garbage collection, operating system memory management)

requires that cryptographic key agreement be performed in accordance with specified standards.

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.2 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 <selectables> <tabularize id="fcs-ckm-ext-7-sels" title="Allowable choices for FCS_CKM_EXT.7"> <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-sels"/> provides the allowable choices for completion of the selection operations of FCS_CKM_EXT.7.</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> </selectables>

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>

This SFR is claimed if the TSF supports key agreement schemes as a method of key establishment for trusted channels. This will generally apply to all conformant TOEs, except in the rare (but possible) case where only key encapsulation is used. All of the above algorithms with the selectable parameters are CNSA compliant. 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.

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>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-aead-aes-gcm"> <col>AES-GCM</col> <col>AES in GCM mode with non-repeating IVs using <selectables> <selectable>deterministic</selectable> <selectable>RBG-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. 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 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 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 [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 <selectables> <selectable>invoke platform-provided functionality</selectable> <selectable>implement functionality</selectable> </selectables> <h:b>to</h:b> perform <h:b>cryptographic hashing</h:b> in accordance with 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-1 hash is no longer permitted to be used as a hash function, SHA3 hashes may be used only for internal hardware functionality such as boot integrity checks, and SHA-256 is permitted only for use 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. If "invoke platform-provided functionality" is selected: The evaluator shall examine the TSS to verify that it describes (for each supported platform) how the hash functionality is invoked for each digest size selected in the MDM server's ST (it should be noted that this may be through a mechanism that is not implemented by the MDM server; nonetheless, that mechanism will be identified in the TSS as part of this evaluation activity). If "implement functionality" is selected: The evaluator shall check that the association of the hash function with other TSF cryptographic functions (for example, the digital signature verification function) is documented in the TSS. The evaluator shall check the AGD documents to determine that any configuration that is required to be done to configure the functionality for the required hash sizes is present. The TSF hashing functions can be implemented in one of two modes. The first mode is the byte-oriented mode. In this mode the TSF only hashes messages that are an integral number of bytes in length (i.e., the length (in bits) of the message to be hashed is divisible by 8). The second mode is the bit-oriented mode. In this mode the TSF hashes messages of arbitrary length. As there are different tests for each mode, an indication is given in the following sections for the bit-oriented vs. byte-oriented TestMAC. 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. 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. 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. There are two versions of the Monte Carlo test for SHA-1 and SHA-2. Either one is acceptable. 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>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>RBG-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> This SFR is claimed when "key wrapping" is selected in FCS_CKM.2.1. 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 <selectables> <selectable>invoke platform-provided functionality</selectable> <selectable>implement functionality</selectable> </selectables> <h:b>to</h:b> 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-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> </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. 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 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>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> [CTR] </col> </selectable> </selectables> 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, 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.

defines requirements for the implementation of the HTTPS protocol.

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 of the certificate validity check. Issuer Name and Subject Name of certificate. User's authorization decision No additional information FCS_TLS_EXT.1 TLS Protocol

[FCS_TLSC_EXT.1 TLS Client Protocol or FCS_TLSS_EXT.1 TLS Server Protocol

The TSF shall <selectables> <selectable>invoke platform-provided functionality to implement</selectable> <selectable>implement</selectable> </selectables> the HTTPS protocol that complies with RFC 2818.

The TSF shall <selectables> <selectable>invoke platform-provided functionality to implement</selectable> <selectable>implement</selectable> </selectables> HTTPS using TLS in accordance with <xref to="tls"/>. The requirement is claimed if the TSF selects HTTPS in any iteration of FPT_ITT.1, FTP_ITC.1, or FTP_TRP.1. It is expected that if the TOE invokes platform-provided functionality to perform HTTPS, that the platform implementation of HTTPS is conformant to the functional package. The evaluator shall verify that the TSS describes whether the TOE's HTTPS functionality is implemented by the TOE or invoked from the TOE platform. If the TOE implements HTTPS, the evaluator shall verify that the corresponding claims from the TLS Functional Package (client, server, or both) are present. The evaluator shall attempt to establish an HTTPS connection with a web server, web a client, or both (depending on whether the TOE acts as a web client, a web server, or both), 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 the TLS evaluation activities.

Failure of the certificate validity check

Issuer Name and Subject Name of certificate

User's authorization decision

defines requirements for generating IVs.

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

The TSF shall <selectables> <selectable>invoke platform-provided functionality</selectable> <selectable>implement functionality</selectable> </selectables> to generate IVs in accordance with <xref to="iv"/>. This requirement must be included in the ST if the selection in FCS_STG_EXT.1 indicates that the TSF is protecting private keys and persistent secrets with encryption rather than the platform-provided key storage. lists the requirements for composition of IVs according to the corresponding 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 encryption. : References and IV Requirements for NIST-approved Cipher Modes Cipher Mode Reference IV Requirement Electronic Codebook (ECB) SP800-38A No IV Counter (CTR) SP800-38A "Initial Counter" shall be non-repeating. No counter value shall be repeated across multiple messages with the same secret key. Cipher Block Chaining (CBC) SP800-38A IVs shall be unpredictable. Repeating IVs leak information about whether the first one or more blocks are shared between two messages, so IVs should be non-repeating in such situations. Output Feedback (OFB) SP800-38A IVs shall be non-repeating and shall not be generated by invoking the cipher on another IV. Cipher Feedback (CFB) SP800-38A IVs should be non-repeating as repeating IVs leak information about the first plaintext block and about common shared prefixes in messages. XOR Encrypt XOR (XEX) Tweakable Block Cipher with Ciphertext Stealing (XTS) SP800-38E No IV. Tweak values shall be non-negative integers, assigned consecutively, and starting at an arbitrary non-negative integer. Cipher-based Message Authentication Code (CMAC) SP800-38B No IV Key Wrap and Key Wrap with Padding SP800-38F No IV Counter with CBC-Message Authentication Code (CCM) SP800-38C No IV. Nonces shall be non-repeating. Galois Counter Mode (GCM) SP800-38D IV shall be non-repeating. The number of invocations of GCM shall not exceed 2^32 for a given secret key unless an implementation only uses 96-bit IVs (default length). If "invoke platform-provided functionality" is selected: The evaluator shall examine the TSS to verify that it describes (for each supported platform) how the IV generation is invoked for each mode selected in the MDM server's ST (it should be noted that this may be through a mechanism that is not implemented by the MDM server; nonetheless, that mechanism will be identified in the TSS as part of this evaluation activity). If "implement functionality" is selected: The evaluator shall examine the TSS to ensure that it details the encryption of user credentials, persistent secrets, and private keys and the generation of the IVs used for that encryption. The evaluator shall ensure that the generation of IVs for each key encrypted by the same KEK meets .

The TSF shall <h:b><selectables> <selectable>invoke platform-provided functionality</selectable> <selectable id="tsf-drbg">implement functionality</selectable> </selectables></h:b> <h:b>to</h:b> perform <h:b>all</h:b> 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> If "implement functionality" is selected, FPT_FLS.1 and FPT_TST.1 are claimed. 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 and whether they are implemented by the TSF or invoked from the underlying platform. If the DRBG functionality is configurable, the evaluator shall verify that the operational guidance includes instructions on how to configure this behavior. [conditional: "implement functionality" is selected in FCS_RBG.1.1] 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. 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 specified 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.

defines requirements for the security of persistent secrets and private keys.

The following actions could be considered for the management functions in FMT. Import keys or secrets into the secure key storage There are no auditable events foreseen. No dependencies.

The TSF shall use <selectables> <selectable> platform-provided key storage</selectable> <selectable id="fcs_stg_enc"> encryption as defined in FCS_STG_EXT.2</selectable> </selectables> for all persistent secrets and private keys. This requirement ensures that persistent secrets (credentials, secret keys) and private keys are stored securely when not in use. If some secrets or keys are manipulated by the TOE and others are manipulated by the platform, then both of the selections can be specified by the ST author and the ST author must identify in the TSS those keys which are manipulated by the TOE and those by the platform. If "encryption as defined in FCS_STG_EXT.2" is selected then FCS_STG_EXT.2 and FCS_IV_EXT.1 must be included in the ST. If the TSF is an application, and not a dedicated server, then it should store its private keys in the platform-provided key storage. The ST author is responsible for selecting the manner in which the keys are stored and where they are stored in the selections above. Regardless of whether this requirement is met by the TSF or the TOE platform, the evaluator shall check the TSS to ensure that it lists each persistent secret (credential, secret key) and private key needed to meet the requirements in the ST. For each of these items, the evaluator shall confirm that the TSS lists for what purpose it is used, and how it is stored. The evaluator then performs the following actions. Persistent secrets and private keys manipulated by the TOE platform: The evaluator shall examine the TSS to verify that it describes (for each supported platform) how the key storage functionality is invoked for each persistent secret and private key described in the TSS (it should be noted that this may be through a mechanism that is not implemented by the MDM Server; nonetheless, that mechanism will be identified in the TSS as part of this evaluation activity). Persistent secrets and private keys manipulated by the TSF: The evaluator reviews the TSS to determine that it makes a case that, for each item listed as being manipulated by the TOE, it is not written unencrypted to persistent memory, and that the item is stored by the platform.

defines requirements for preventing access to private keys and persistent secrets.

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

The TSF shall <selectables> <selectable>invoke platform-provided functionality</selectable> <selectable>implement functionality</selectable> </selectables> to encrypt all keys using AES in the <selectables> <selectable>Key Wrap (KW) mode</selectable> <selectable>Key Wrap with Padding (KWP) mode</selectable> <selectable>GCM</selectable> <selectable>CCM</selectable> <selectable>CBC mode</selectable> </selectables>. This requirement states that keys used by the TSF shall not be kept in plaintext. The intent of this requirement is to ensure that the private keys, credentials, and persistent secrets cannot be accessed in the TOE in an unencrypted state, allowing an attacker to access keys without having to exhaust the AES key space. This requirement must be included in the ST if the selection in FCS_STG_EXT.1 indicates that the TSF is protecting private keys and persistent secrets with encryption rather than the platform-provided key storage. The evaluator shall examine the TSS to ensure it describes in detail how user credentials, persistent secret and private keys are stored and encrypted. The evaluator shall review the TSS to determine that it makes a case that key material is not written unencrypted to persistent memory and that it identifies the mode of encryption. If "invoke platform-provided functionality" is selected, the evaluator shall examine the TSS to verify that it describes (for each supported platform) how the key encryption functionality is invoked (it should be noted that this may be through a mechanism that is not implemented by the MDM server; nonetheless, that mechanism will be identified in the TSS as part of this evaluation activity).

This family defines requirements for unique certificate or token use.

This family defines requirements for authenticating remote users and limiting user enrollment.

This family defines requirements for using a unique device to generate unique tokens for client devices.

defines requirements for a unique certificate or token for each client device.

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

The TSF shall require a unique <selectables> <selectable>certificate</selectable> <selectable id="fia_cli_token">token as defined in FIA_TOK_EXT.1</selectable> </selectables> for each client device. Token is used here in a generic way to be some form of unique identifier that is not certificate-based as defined in FIA_TOK_EXT.1. If """ is selected, FIA_TOK_EXT.1 must be included in the ST. The evaluator shall ensure that the TSS describes how the client is uniquely identified. None. None.

defines requirements for authenticating and limiting user actions.

The following actions could be considered for the management functions in FMT. Configure the specific device models. Configure the specific time period. 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 MD user authentication. Presented username. FIA_UAU.4 Single-Use Authentication Mechanisms FMT_SMF.1 Specification of Management Functions

The TSF shall authenticate the remote users over a trusted channel during the enrollment of a MD. The MDM server may use its own directory or a directory server to perform the authentication decision for users performing the remote enrollment of a MD. The evaluator shall examine the TSS and verify that it describes the process of enrollment for each MDM agent or platform listed as supported in the ST. This description shall include the trusted path used for enrollment (FTP_TRP.1/TRUSTPATH_ENROLL), the method of user authentication (username or password, token, etc.), the method of authentication decision (local or remote authentication services), and the actions performed on the MDM server upon successful authentication. The evaluator shall examine the operational guidance to verify that it describes the process by which the TOE enrolls mobile devices into management. The evaluator shall attempt to enroll a device without providing correct credentials. The evaluator shall verify that the device is not enrolled and that the described enrollment actions are not taken. The evaluator shall attempt to enroll the device providing correct credentials. The evaluator shall verify that the device is enrolled and that the described enrollment actions are taken.

The TSF shall limit the user's enrollment of devices to devices specified by <selectables> <selectable>IMEI</selectable><selectable> <assignable>a unique device ID</assignable></selectable></selectables> and <selectables> <selectable>specific device models</selectable> <selectable>a number of devices</selectable> <selectable>specific time period</selectable> <selectable><assignable>other features</assignable></selectable> <selectable>no other features</selectable> </selectables>. This requirement is designed to permit the enterprise to restrict users' enrollment of devices. A unique device ID is required to limit the user's enrollment. The unique device ID can be the IMEI or an ID specific to a particular platform. The evaluator shall examine the TSS and verify that it implements a policy to limit the user's enrollment of devices. The evaluator shall ensure that the administrative guidance describes the methods of restricting user enrollment and that it instructs the administrator how to configure the restrictions. For each type of policy selected, the evaluator shall perform the following: The evaluator shall attempt to configure the MDM server according to the administrative guidance in order to prevent enrollment. The evaluator shall verify that the user cannot enroll a device outside of the configured limitation. (For example, the evaluator may try to enroll a disallowed device, or may try to enroll additional devices beyond the number allowed.)

Failure of MD user authentication

Presented username

defines requirements for generating unique tokens.

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

The TSF shall <selectables> <selectable>invoke platform-provided functionality</selectable> <selectable>implement functionality</selectable> </selectables> to use <selectables> <selectable>IMEI</selectable> <selectable><assignable>other unique device ID</assignable></selectable> </selectables> to generate a unique token for each client device. This SFR is included in the ST if "" is selected in FIA_CLI_EXT.1. The evaluator shall review the TSS and verify that the TSF uses either unique identifiers from the client device or a server-specific mechanism to generate a unique token that will be used for verifying the identity of the client device. If the server generates the token using cryptographic functions, it must use algorithms in FCS_COP.1(ANY) (specific algorithms as needed by the vendor). If "invoke platform-provided functionality" is selected, the evaluator shall examine the TSS to verify that it describes (for each supported platform) how this functionality is invoked (it should be noted that this may be through a mechanism that is not implemented by the MDM server; nonetheless, that mechanism will be identified in the TSS as part of this evaluation activity). If "implement functionality" is selected, the evaluator shall examine the TSS to verify that it describes the methods to generate the token. None. For each MDM agent or platform listed as supported in the ST, the evaluator shall use appropriate combinations of specialized operational environment and development tools (debuggers, simulators, etc.) for the TOE and instrumented TOE builds as needed to perform this test. The evaluator shall concurrently enroll ten devices and ensure that the token for each is unique, per the methods described in the TSS.

The TSF shall <selectables> <selectable><h:b>invoke platform-provided functionality</h:b></selectable> <selectable><h:b>implement functionality</h:b></selectable> </selectables> <h:b>to</h:b> allow <assignable>list of TSF mediated actions</assignable> on behalf of the user to be performed before the user is authenticated <h:b>with the server</h:b>.

The TSF shall <selectables> <selectable><h:b>invoke platform-provided functionality</h:b></selectable> <selectable><h:b>implement functionality</h:b></selectable> </selectables> <h:b>that</h:b> requires each user to be successfully authenticated <h:b>with the server</h:b> before allowing any other TSF-mediated actions on behalf of that user. This requirement ensures that any user attempting to access the TSF must be authenticated. These users may be administrators attempting to administer the TOE or ordinary users attempting to enroll for management by the MDM system. The ST author is responsible for assigning the list of actions that can take place before this authentication. The TSF or TOE platform may use enterprise authentication to meet this requirement. For distributed TOEs, at least one TOE component has to support the authentication of administrators but not necessarily all TOE components. In case not all TOE components support authentication for administrators the TSS must describe how administrators are authenticated and identified. If "invoke platform-provided functionality" is selected, the evaluator shall examine the TSS to verify that it describes (for each supported platform) how this functionality is invoked (it should be noted that this may be through a mechanism that is not implemented by the MDM server; nonetheless, that mechanism will be identified in the TSS as part of this evaluation activity). The evaluator shall examine the operational guidance to verify that it describes the process by which users authenticate to the TOE. The evaluator shall perform the following tests: The evaluator shall attempt to perform the prohibited actions before authentication. The evaluator shall verify the actions cannot be performed. The evaluator shall attempt to perform the prohibited actions after authentication. The evaluator shall verify the actions can be performed.

The TSF shall prevent reuse of authentication data related to <assignable>identified authentication mechanisms</assignable>. This requirement references the authentication mechanisms used to authenticate the user for enrollment in . If a username and password is used to authenticate the user for enrollment, the password must not be reused. Thus if the user has two devices enrolled in management or needs to re-enroll the same device (i.e., after a device wipe), the password must be different for each enrollment. Additionally, if two different users are enrolling the password must be different for each user. The evaluator shall verify that the TSS contains a description of the process of enrollment for each MDM agent or platform listed as supported in the ST. This description shall include the method of user authentication (username or password, token, etc.) and how reuse of the authentication data is prevented. The evaluator shall ensure that the administrative guidance describes the methods of restricting user enrollment and that it instructs the administrator on how to configure the restrictions. The evaluator shall enroll a device providing correct credentials. The evaluator shall attempt to enroll a second device using the same credentials used to enroll the first device. The evaluator shall verify that the second device could not enroll.

Attempt to reuse enrollment data

Enrollment data

This family describes how to use digitally signed policies and updates by using private keys, and validating the policy is appropriate.

This family defines the requirements for using expiration time for enrollment and denying enrollment if that time has passed.

The TSF shall restrict the ability to <h:b>perform</h:b> the functions <h:ul> <h:li>enable/disable/modify/and monitor policies listed in FMT_SMF.1/SERVER_CONF_AGENT</h:li> <h:li>listed in FMT_SMF.1/SERVER_CONF_SERVER</h:li> <h:li><selectables> <selectable id="mas">enable/disable/modify policies listed in FMT_SMF.1/MAS</selectable>  <selectable>no other functions</selectable> </selectables></h:li> </h:ul> to [<h:i>authorized administrators</h:i>]. This requirement outlines the functions that administrators will have the power to enable, disable, modify, and monitor functions and policies listed in FMT_SMF.1/SERVER_CONF_AGENT. It also includes functions necessary to maintain and configure the MDM server itself, as described in FMT_SMF.1/SERVER_CONF_SERVER. You must select "enable/disable/modify policies listed in FMT_SMF.1/MAS" if the TOE includes MAS functionality and FMT_SMF.1/MAS, FAU_GEN.1/MAS_SERVER, FMT_MOF.1/MANAGEMENT_MAS, FMT_SMR.1/SECMAN_ROLES_MAS must be included in the ST. The evaluator shall examine the TSS to ensure that it describes what security management functions are restricted to the administrator and what actions can be taken for each management function. The evaluator shall verify that the security management functions are restricted to authorized administrators. The evaluator shall examine the operational guidance to verify that it describes the management functions that are available to authorized administrators and how administrators are authorized to perform those particular functions (e.g., default for the account, role membership, group membership). The evaluator shall attempt to access the functions and policies in FMT_SMF.1/SERVER_CONF_AGENT as an unauthorized user and verify that the attempt fails. [conditional] If "enable/disable/and modify policies listed in FMT_SMF.1/MAS" is selected, the evaluator shall attempt to access the functions and policies in FMT_SMF.1/MAS as an unauthorized user and verify that the attempt fails.

Issuance of command to perform function

Command sent and identity of MDM agent recipients

Change of policy settings

Policy changed and value or full policy

The <h:b>MDM server</h:b> shall restrict the ability to [<h:b><h:i>initiate the enrollment process</h:i></h:b>] to [<h:i>authorized administrators and MD users</h:i>]. This requirement outlines the enrollment functions that both administrators and MD users may perform. The enrollment actions are identified in the TSS as a part of FIA_ENR_EXT.1. The authorized administrator does not remotely initiate enrollment of the MDs that are in the possession of users but may enroll MDs when they are in the possession of the administrator, for example, before distributing the MDs to the users. The evaluator shall examine the TSS and verify that it describes how unauthorized users are prevented from enrolling in the MDM services. The evaluator shall examine the operational guidance to verify that it describes the enrollment process and any restrictions that may prevent unauthorized enrollment. The test of this function is performed in conjunction with FIA_ENR_EXT.1.

Enrollment by a user

Identity of user

The <h:b>MAS server</h:b> shall restrict the ability to [<h:i>enable, modify the behavior of</h:i>] the functions [<h:i>downloading applications</h:i>] to [<h:i>enrolled MDs that are compliant with MDM policies and assigned to a user in the application access group</h:i>]. This requirement is claimed if "enable/disable/modify policies listed in FMT_SMF.1/MAS" is selected in FMT_MOF.1.1/FUNCBE. The evaluator shall examine the TSS to determine that all methods of initiating an application download or update push are specified. The evaluator shall confirm that the operational guidance contains how to initiate an application download or update push. The evaluator shall ensure that the MAS server verifies that the MD is enrolled in the MDM server and is in a compliant state. The evaluator shall verify that either none, or only those applications needed for enrollment, can be downloaded from the MAS server prior to enrolling the MD with the MDM. The evaluator shall ensure that the MAS server verifies that the MD is enrolled in the MDM server and is in a compliant state. The evaluator shall make policy changes to make the enrolled MD non-compliant. The evaluator shall verify that either none, or only those applications needed to bring the MD back into compliance, are able to be downloaded. The evaluator shall ensure that the MAS server verifies that the MD is enrolled in the MDM server and is in a compliant state. The evaluator shall unenroll the MD and verify that an application can not be downloaded from the MAS server after unenrollment.

defines requirements for using digitally signed policies and policy updates.

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: Attempt to reuse enrollment data. Enrollment data. No dependencies.

The TSF shall provide digitally signed policies and policy updates to the <selectables> <selectable>MDM agent</selectable> <selectable>subordinate MDM server</selectable> </selectables>. The intent of this requirement is to cryptographically tie the policies to the enterprise that mandated the policy, not to protect the policies in transit (as they are already protected by FPT_ITT.1/INTRA_XFER / FPT_ITT.1/INTRA_XFER_AGENT or FTP_ITC.1/OE_XFER_AGENT). This is especially critical for users who connect to multiple enterprises.

The TSF shall sign policies and policy updates using a private key associated with <selectables> <selectable>an X.509 certificate</selectable> <selectable>a public key provisioned to the MDM agent</selectable> <selectable>a public key provisioned to the subordinate MDM server</selectable> </selectables> trusted by the MDM agent or subordinate MDM server for policy verification. If "an X.509 certificate" is selected, the ST author includes "policy signing" in the assignment in FIA_X509_EXT.2.1 in .

For each unique policy managed by the TSF, the TSF shall validate that the policy is appropriate for an MDM agent or subordinate MDM server using <selectables linebreak="yes"> <selectable id="fmt_pol_3_x509_agent">client authentication via an X.509 certificate representing the MDM agent</selectable> <selectable id="fmt_pol_3_x509_sub">client authentication via an X.509 certificate representing the subordinate MDM server</selectable> <selectable id="fmt_pol_3_token_agent">a token issued to the MDM agent and associated with a policy signing key uniquely associated to the policy</selectable> <selectable id="fmt_pol_3_token_sub">a token issued to the subordinate MDM server and associated with a policy signing key uniquely associated to the policy</selectable> </selectables>. If "" or "" is claimed, any corresponding protocols that use this are also claimed in FIA_X509_EXT.2.1 in . If "" or "" is claimed, "" is claimed in FIA_CLI_EXT.1.1 and the TSF maintains the association of the key pairs and the agent or subordinate MDM server tokens. When multiple policies are supported, a unique policy signing key for each policy is used. The evaluator shall verify that the ST describes how policies are signed, to include whether the private key used for signing is associated with an X.509 certificate or public key, the method for distributing the policy verification material (a certificate or provisioned public key) to the agent or subordinate MDM server, and the method for distinguishing whether a policy is appropriate for an agent or subordinate MDM server. If tokens are claimed in FMT_POL_EXT.1.3, the evaluator shall verify the ST describes how tokens are established and distributed to the agent or subordinate MDM server. If applicable, the evaluator shall verify that the operational guidance instructs administrators on configuring the enterprise certificate to be used for signing policies or signing the policies before applying them. The evaluator shall perform a policy update in accordance with FMT_SMF.1/SERVER_CONF_AGENT. The evaluator shall examine the policy update, either at the TOE, in transmission, or at the MDM agent or subordinate MDM server. The evaluator shall verify that the TSF signed the policy update and delivered it to the MDM agent or subordinate MDM server.

defines requirements for using digitally signed policies and policy updates by the subordinate MDM server.

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: Attempt to reuse enrollment data. Enrollment data. No dependencies.

The TSF shall only accept policies and policy updates that are digitally signed by a private key that has been authorized for policy updates by the primary MDM server. The intent of this requirement is to cryptographically tie the policies to the enterprise that mandated the policy, not to protect the policies in transit (as they are already protected by FTP_ITC.1/OE_XFER_IT). This is especially critical for users who connect to multiple enterprises.

The TSF shall not process policies for the MDM agent if the signature check fails. The evaluator ensures that the TSS describes how the candidate policies are obtained by the subordinate MDM server, the processing associated with verifying the digital signature of the policy updates, and the actions that take place for successful (signature was verified) and unsuccessful (signature could not be verified) cases. The software components that are performing the processing must also be identified in the TSS and verified by the evaluators. This evaluation activity is performed in conjunction with the evaluation activity for FIA_X509_EXT.1 and FIA_X509_EXT.2 in . The evaluator shall perform a policy update from an available configuration interface (such as through a test primary MDM server). The evaluator shall verify the update is signed and is provided to the subordinate MDM server. The evaluator shall verify the subordinate MDM server accepts the digitally signed policy. The evaluator shall perform a policy update from an available configuration interface (such as through a test primary MDM server). The evaluator shall provide an unsigned and an incorrectly signed policy to the subordinate MDM server. The evaluator shall verify the subordinate MDM server does not accept the digitally signed policy.

defines requirements for the expiration time for enrollment authentication.

The following action could be considered for the management functions in FMT. Configure the length of time the enrollment authenticator is valid. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP, PP-Module, functional package or ST: Enrollment attempted after expiration of authentication data. Identity of user. FIA_ENR_EXT.1 Enrollment FIA_UAU.4 Single-Use Authentication Mechanisms

The TSF shall be able to specify a configurable expiration time for enrollment authentication data.

The TSF shall be able to deny enrollment after the expiration time for the enrollment authentication data has passed. This requirement references the user authenticator used for device enrollment in management in . The user authenticator must only be valid for a configurable time limit. If the authenticator is expired, even if entered correctly, enrollment must not occur. The length of the time the authenticator is valid for is configured per function b.6 in FMT_SMF.1/SERVER_CONF_SERVER. If FMT_SAE_EXT.1 is included in the ST, then function b.6 must be selected in FMT_SMF.1/SERVER_CONF_SERVER. The evaluator shall verify that the TSS contains a description of the process of enrollment for each MDM agent or platform listed as supported in the ST. This description shall be the method of user authentication (username or password, token, etc.). The evaluator shall check to ensure that the operational guidance contains instructions to configure the expiration time for each method of user authentication listed in the TSS. The evaluator shall configure the MDM server according to the administrative guidance to set an expiration time for the enrollment authentication data. For each method of user authentication listed in the TSS, the evaluator shall attempt to enroll using authentication data that has expired. The evaluator shall verify that enrollment was unsuccessful.

Enrollment attempted after expiration of authentication data

Identity of user

The <h:b>MDM server</h:b> shall be capable of <h:b>communicating the following commands to the MDM agent: </h:b> <h:ul style="list-style-type:none"> <h:li><ctr id="smf1" ctr-type="mgmt" pre=""/>. Transition to the locked state (PP_MDF/PP_GPOS Function 6)</h:li> <h:li><ctr id="smf2" ctr-type="mgmt" pre=""/>. Full wipe of protected data (PP_MDF/PP_GPOS Function 7)</h:li> <h:li><ctr id="smf3" ctr-type="mgmt" pre=""/>. Unenroll from management (PP_MDF/PP_GPOS Function 44)</h:li> <h:li><ctr id="smf4" ctr-type="mgmt" pre=""/>. Install policies</h:li> <h:li><ctr id="smf5" ctr-type="mgmt" pre=""/>. Query connectivity status</h:li> <h:li><ctr id="smf6" ctr-type="mgmt" pre=""/>. Query the current version of the MD firmware or software</h:li> <h:li><ctr id="smf7" ctr-type="mgmt" pre=""/>. Query the current version of the hardware model of the device</h:li> <h:li><ctr id="smf8" ctr-type="mgmt" pre=""/>. Query the current version of installed applications</h:li> <h:li><ctr id="smf9" ctr-type="mgmt" pre=""/>. Import X.509v3 certificates into the Trust Anchor Database (PP_MDF/PP_GPOS Function 11)</h:li> <h:li><ctr id="smf10" ctr-type="mgmt" pre=""/>. Install applications (PP_MDF/PP_GPOS Function 16)</h:li> <h:li><ctr id="smf11" ctr-type="mgmt" pre=""/>. Update system software (PP_MDF/PP_GPOS Function 15)</h:li> <h:li><ctr id="smf12" ctr-type="mgmt" pre=""/>. Remove applications (PP_MDF/PP_GPOS Function 14)</h:li> <h:li><ctr id="smf19" ctr-type="mgmt" pre=""/>. Read audit logs kept by the MD (PP_MDF/PP_GPOS Function 32)</h:li> </h:ul> <selectables> <selectable><ctr id="smf13" ctr-type="mgmt" pre=""/>. Remove enterprise applications (PP_MDF/PP_GPOS Function 17),</selectable> <selectable><ctr id="smf14" ctr-type="mgmt" pre=""/>. Wipe enterprise data (PP_MDF/PP_GPOS Function 28),</selectable> <selectable><ctr id="smf15" ctr-type="mgmt" pre=""/>. Remove imported X.509v3 certificates and <selectables linebreak="yes"> <selectable>no other X.509v3 certificates,</selectable> <selectable><assignable>list of other categories of X.509v3 certificates</assignable></selectable> </selectables> in the Trust Anchor Database (PP_MDF/PP_GPOS Function 12),</selectable> <selectable> <ctr id="smf16" ctr-type="mgmt" pre=""/>. Alert the user,</selectable> <selectable> <ctr id="smf17" ctr-type="mgmt" pre=""/>. Import keys or secrets into the secure key storage (PP_MDF/PP_GPOS Function 9),</selectable> <selectable> <ctr id="smf18" ctr-type="mgmt" pre=""/>. Destroy imported keys or secrets and <selectables linebreak="yes"> <selectable>no other keys or secrets,</selectable> <selectable><assignable>list of other categories of keys or secrets</assignable></selectable> </selectables> in the secure key storage (PP_MDF/PP_GPOS Function 10),</selectable> <selectable> <ctr id="smf20" ctr-type="mgmt" pre=""/>. Retrieve MD-software integrity verification values (PP_MDF/PP_GPOS Function 38),</selectable> <selectable> <ctr id="smf21" ctr-type="mgmt" pre=""/>. Approve exceptions for sharing data between <selectables linebreak="yes"> <selectable>application processes,</selectable> <selectable>groups of application processes</selectable> </selectables> (PP_MDF/PP_GPOS Function 42),</selectable> <selectable> <ctr id="smf22" ctr-type="mgmt" pre=""/>. Place applications into application process groups based on <assignable>application characteristics</assignable> (PP_MDF/PP_GPOS Function 43),</selectable> <selectable> <ctr id="smf23" ctr-type="mgmt" pre=""/>. Revoke Biometric template (PP_MDF/PP_GPOS Function 46),</selectable> <selectable> <ctr id="smf24" ctr-type="mgmt" pre=""/>. <assignable>list of other management functions to be provided by the MD</assignable>, </selectable> <selectable>no other management functions</selectable> </selectables> <h:b>and the following MD configuration policies</h:b>: <h:br/><h:br/> <h:ul style="list-style-type:none"> <h:li> <ctr id="smf25" ctr-type="mgmt" pre=""/>. Password policy: <h:ol type="a"> <h:li>minimum password length</h:li> <h:li>minimum password complexity</h:li> <h:li>maximum password lifetime (PP_MDF/PP_GPOS Function 1)</h:li> </h:ol> </h:li> <h:li> <ctr id="smf26" ctr-type="mgmt" pre=""/>. Session locking policy: <h:ol type="a"> <h:li>screen-lock enabled and disabled</h:li> <h:li>screen lock timeout</h:li> <h:li>number of authentication failures (PP_MDF/PP_GPOS Function 2)</h:li> </h:ol> </h:li> <h:li> <ctr id="smf27" ctr-type="mgmt" pre=""/>. Wireless networks (SSIDs) to which the MD may connect (WLAN Client PP-Module Function WL-2)</h:li> <h:li> <ctr id="smf28" ctr-type="mgmt" pre=""/>. Security policy for each wireless network: <h:ol type="a"> <h:li><selectables linebreak="yes"> <selectable>specify the CAs from which the MD will accept WLAN authentication server certificates,</selectable> <selectable>specify the FQDNs of acceptable WLAN authentication server certificates</selectable> </selectables></h:li> <h:li>ability to specify security type</h:li> <h:li>ability to specify authentication protocol</h:li> <h:li>specify the client credentials to be used for authentication</h:li> <h:li><assignable>any additional WLAN management functions</assignable> (WLAN Client PP-Module Function WL-1)</h:li> </h:ol> </h:li> <h:li> <ctr id="smf29" ctr-type="mgmt" pre=""/>. Application installation policy by <selectables linebreak="yes"> <selectable>specifying authorized application repositories,</selectable> <selectable>specifying a set of allowed applications and versions (an application allowlist),</selectable> <selectable>denying application installation</selectable> </selectables>(PP_MDF/PP_GPOS Function 8)</h:li> <h:li> <ctr id="smf30" ctr-type="mgmt" pre=""/>. Enable and disable policy for <assignable>list of audio or visual collection devices</assignable> across device, <selectables linebreak="yes"> <selectable>on a per-app basis</selectable> <selectable>on a per-group of applications processes basis</selectable> <selectable>no other method</selectable> </selectables> (PP_MDF/PP_GPOS Function 5)</h:li> <h:li> <ctr id="smf47" ctr-type="mgmt" pre=""/>. The unlock banner policy (PP_MDF/PP_GPOS Function 36)</h:li> </h:ul> <h:ul style="list-style-type:none"><selectables linebreak="yes"> <selectable> <ctr id="smf31" ctr-type="mgmt" pre=""/>. Enable and disable policy for the VPN protection across MD, <selectables linebreak="yes"> <selectable>on a per-app basis,</selectable> <selectable>on a per-group of application processes basis,</selectable> <selectable>no other method</selectable> </selectables> (PP_MDF/PP_GPOS Function 3),</selectable> <selectable> <ctr id="smf32" ctr-type="mgmt" pre=""/>. Enable and disable policy for <assignable>list of radios</assignable> (PP_MDF/PP_GPOS Function 4),</selectable> <selectable> <ctr id="smf33" ctr-type="mgmt" pre=""/>. Enable and disable policy for data signaling over <assignable>list of externally accessible hardware ports</assignable> (PP_MDF/PP_GPOS Function 24),</selectable> <selectable> <ctr id="smf34" ctr-type="mgmt" pre=""/>. Enable and disable policy for <assignable>list of protocols where the device acts as a server</assignable> (PP_MDF/PP_GPOS Function 25),</selectable> <selectable> <ctr id="smf35" ctr-type="mgmt" pre=""/>. Enable and disable policy for developer modes (PP_MDF/PP_GPOS Function 26),</selectable> <selectable> <ctr id="smf36" ctr-type="mgmt" pre=""/>. Enable policy for data-at-rest protection (PP_MDF/PP_GPOS Function 19),</selectable> <selectable> <ctr id="smf37" ctr-type="mgmt" pre=""/>. Enable policy for removable media's data-at-rest protection (PP_MDF/PP_GPOS Function 20),</selectable> <selectable> <ctr id="smf38" ctr-type="mgmt" pre=""/>. Enable and disable policy for local authentication bypass (PP_MDF/PP_GPOS Function 27),</selectable> <selectable> <ctr id="smf39" ctr-type="mgmt" pre=""/>. The Bluetooth trusted channel policy:<h:br/> <h:ol type="a"> <h:li>Disable/enable the Discoverable (for BR/EDR) and Advertising (for LE) modes (Bluetooth PP-Module Function BT-1)</h:li> <h:li>change the Bluetooth device name (Bluetooth PP-Module Function BT-2)</h:li> <h:li><selectables linebreak="yes"> <selectable>Provide separate controls for turning the BR/EDR and LE radios on and off (Bluetooth PP-Module Function BT-3),</selectable> <selectable>allow and disallow additional wireless technologies to be used with Bluetooth (Bluetooth PP-Module Function BT-4),</selectable> <selectable>configure allowable methods of Out of Band pairing (Bluetooth PP-Module Function BT-5),</selectable> <selectable>disable and enable Discoverable (for BR/EDR) and Advertising (for LE) modes separately (Bluetooth PP-Module Function BT-6),</selectable> <selectable>disable and enable the Connection mode (Bluetooth PP-Module Function BT-7),</selectable> <selectable>disable and enable the Bluetooth services or profiles available on the device (Bluetooth PP-Module Function BT-8),</selectable> <selectable>specify minimum level of security for each pairing (Bluetooth PP-Module Function BT-9),</selectable> <selectable>no other Bluetooth configuration</selectable> </selectables> </h:li> </h:ol> </selectable> <selectable> <ctr id="smf40" ctr-type="mgmt" pre=""/>. Enable and disable policy for 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>other application-based notifications</selectable> </selectables> (PP_MDF/PP_GPOS Function 18), </selectable> <selectable> <ctr id="smf41" ctr-type="mgmt" pre=""/>. Policy for establishing a trusted channel or disallowing establishment if the MD cannot establish a connection to determine the validity of a certificate (PP_MDF/PP_GPOS Function 30),</selectable> <selectable> <ctr id="smf42" ctr-type="mgmt" pre=""/>. Enable and disable policy for the cellular protocols used to connect to cellular network base stations (PP_MDF/PP_GPOS Function 31),</selectable> <selectable> <ctr id="smf43" ctr-type="mgmt" pre=""/>. Policy for import and removal by applications of X.509v3 certificates in the Trust Anchor Database (PP_MDF/PP_GPOS Function 29),</selectable> <selectable> <ctr id="smf44" ctr-type="mgmt" pre=""/>. The: <selectables linebreak="yes"> <selectable>certificate,</selectable> <selectable>public key</selectable> </selectables> used to validate digital signature on applications (PP_MDF/PP_GPOS Function 33),</selectable> <selectable> <ctr id="smf45" ctr-type="mgmt" pre=""/>. Policy for exceptions for shared use of keys or secrets by multiple applications (PP_MDF/PP_GPOS Function 34),</selectable> <selectable> <ctr id="smf46" ctr-type="mgmt" pre=""/>. Policy for exceptions for destruction of keys or secrets by applications that did not import the key or secret (PP_MDF/PP_GPOS Function 35),</selectable> <selectable> <ctr id="smf48" ctr-type="mgmt" pre=""/>. Configure the auditable items (PP_MDF/PP_GPOS Function 37),</selectable> <selectable> <ctr id="smf49" ctr-type="mgmt" pre=""/>. Enable and disable <selectables linebreak="yes"> <selectable>USB mass storage mode,</selectable> <selectable>USB data transfer without user authentication,</selectable> <selectable>USB data transfer without authentication of the connection system</selectable> </selectables> (PP_MDF/PP_GPOS Function 39),</selectable> <selectable> <ctr id="smf50" ctr-type="mgmt" pre=""/>. Enable and disable backup of <selectables linebreak="yes"> <selectable>all applications,</selectable> <selectable>selected applications,</selectable> <selectable>selected groups of applications,</selectable> <selectable>configuration data</selectable> </selectables> to <selectables> <selectable>locally connected system</selectable> <selectable>remote system</selectable> </selectables> (PP_MDF/PP_GPOS Function 40),</selectable> <selectable> <ctr id="smf51" ctr-type="mgmt" pre=""/>. Enable and disable <selectables linebreak="yes"> <selectable>Bluetooth tethering,</selectable> <selectable>USB tethering authenticated by <selectables> <selectable>pre-shared key</selectable> <selectable>passcode</selectable> <selectable>no authentication</selectable> </selectables> </selectable> </selectables> (PP_MDF/PP_GPOS Function 41),</selectable> <selectable> <ctr id="smf52" ctr-type="mgmt" pre=""/>. Enable and disable location services: <selectables linebreak="yes"> <selectable>across device,</selectable> <selectable>on a per-app basis,</selectable> <selectable>on a per-group of application processes basis</selectable> </selectables> (PP_MDF/PP_GPOS Function 21),</selectable> <selectable> <ctr id="smf53" ctr-type="mgmt" pre=""/>. Enable and disable policy for user unenrollment,</selectable> <selectable> <ctr id="smf54" ctr-type="mgmt" pre=""/>. Enable and disable policy for the Always-On VPN protection across device (PP_MDF/PP_GPOS Function 45),</selectable> <selectable> <ctr id="smf55" ctr-type="mgmt" pre=""/>. Enable and disable policy for use of Biometric Authentication Factor (PP_MDF/PP_GPOS Function 22),</selectable> <selectable> <ctr id="smf56" ctr-type="mgmt" pre=""/>. Connectivity timeout policy: <selectables linebreak="yes"> <selectable>allowed <selectables> <selectable>number of missed reachability events</selectable> <selectable>length of time without server connectivity</selectable> </selectables>, </selectable> <selectable>when server connectivity timeout is exceeded agent shall <selectables> <selectable>disable user password</selectable> <selectable>wipe device</selectable> </selectables> and <selectables> <selectable><assignable>other action</assignable></selectable> <selectable>none</selectable> </selectables> </selectable> </selectables>, </selectable> <selectable><ctr id="smf57" ctr-type="mgmt" pre=""/>. Enable and disable multi-user modes,</selectable> <selectable><ctr id="smf58" ctr-type="mgmt" pre=""/>. Enable and disable automatic updates of system software,</selectable> <selectable><ctr id="smf59" ctr-type="mgmt" pre=""/>. Enable and disable removable media,</selectable> <selectable><ctr id="smf60" ctr-type="mgmt" pre=""/>. Enable/disable wireless network bridging capability (e.g. hotspot) authenticated by: <selectables linebreak="yes"> <selectable>pre-shared key</selectable> <selectable>passcode</selectable> <selectable>no authentication</selectable> </selectables> (WLAN Client PP-Module Function WL-3) </selectable> <selectable> <ctr id="smf61" ctr-type="mgmt" pre=""/>. <assignable>list of other policies to be provided by the MD</assignable>, no other policies</selectable> </selectables>.</h:ul> This requirement captures all the configuration functionality the TSF provides the administrator to configure the MDM agent. This requirement is broken into two configurable areas: MDM agent commands and MDM agent policies. The ST author can add more commands and configuration policies by completing the appropriate assignment statements. Function-specific application notes: Function may be satisfied for the BYOD use case by application denylisting or disabling. In the case of BYOD, an enterprise may not want to remove "personal" applications, thus for that use case disabling the application rather than removing it would allow the user to not lose any information they might have in the application. Function provides the MDM server to display an alert to the user of the MD. The audit data read according to Function are to be transmitted to an external audit server according to FAU_STG.1. The MDM server is not expected to retain those logs. Function provides the ability to enable and disable policy for the list of protocols where the device acts as a server, such as a mobile hotspot. Function corresponds to FPT_NET_EXT.1.1 in agent. If the MDM agent has not had a successful reachability event with the MDM server in the amount of time specified in the first selection, then the agent must perform the action selected in the second selection. It is feasible, but not required, that if multiple actions are specified in the second selection, each action could be associated with a different condition in the first selection. If function is included in the ST, then FPT_NET_EXT.1.1 in must be claimed for any MDM agent that the TOE manages. The evaluator shall examine the TSS to ensure that it describes each management function claimed. The evaluator shall examine the TSS to ensure that it identifies the management functions implemented for each supported MDM agent or platform, which are likely to be subsets of all of the management functions available to the administrator on the MDM server. The evaluator shall examine the TSS to verify that any differences between management functions and policies for each supported MDM agent or platform are clearly indicated. The evaluator shall determine if the MD has been evaluated. If so, the evaluator shall examine the TSS to verify that it clearly identifies which management functions match the selections and assignments of the evaluated MD and which management functions were not evaluated. For each command that the TSF can issue to an MDM agent and for each MD configuration policies that can be applied, the evaluator shall examine the operational guidance to verify that it includes instructions on how to perform these actions, and what particular parameters or options can be specified for them. For each MDM agent or platform listed as supported in the ST: The evaluator shall verify the ability to command each MDM agent functional capability and configure each MDM agent policy listed above.

The TSF shall be capable of performing the following management functions. <h:ol type="a"> <h:li>Configure the <selectables> <selectable>devices specified by <selectables> <selectable>IMEI</selectable> <selectable><assignable>a unique device ID</assignable></selectable> </selectables>,</selectable> <selectable>specific device models,</selectable> <selectable>number of devices,</selectable> <selectable>specific time period</selectable> </selectables> and <selectables> <selectable><assignable>other features</assignable></selectable> <selectable>no other features</selectable> </selectables> allowed for enrollment</h:li> <h:li><selectables> <selectable><h:br/>1. Choose X.509v3 certificates for MDM server use</selectable> <selectable><h:br/>2. Allow the administrator to choose whether to accept the certificate when connection cannot be made to establish validity</selectable> <selectable><h:br/>3. Configure the TOE unlock banner</selectable> <selectable><h:br/>4. Configure periodicity of the following commands to the agent: <assignable>list of commands</assignable></selectable> <selectable><h:br/>5. Configure the privacy-sensitive information that will and will not be collected from particular MDs</selectable> <selectable><h:br/>6. Configure the length of time the enrollment authenticator is valid</selectable> <selectable><h:br/>7. Configure the interaction between TOE components</selectable> <selectable><h:br/>8. Configure the cryptographic functionality</selectable> <selectable><h:br/>9. Configure the interaction with the primary MDM server</selectable> <selectable><h:br/>10. Configure the interaction with the subordinate MDM server</selectable> <selectable><h:br/>11. <assignable>other management functions</assignable></selectable> <selectable><h:br/>12. No other management functions</selectable> </selectables>.</h:li> </h:ol> This requirement captures all the configuration functionality in the MDM server to configure the underlying MDM server. The ST author can add more commands and configuration policies by completing the assignment statement. The selection in function 'a' corresponds to the selection in . Function 'b.1' is selection-based under the very limited circumstances when certificate management is both performed solely by platform-provided functionality and the platform uses cloud services; for all other instances it is mandatory. This requirement will be made fully mandatory again in a future version of the PP. Function 'b.1' can be met by relying on the platform to configure the certificates used by the MDM server, however, the MDM server must allow the administrator to choose which certificate is used for a specific functionality. The selection in function 'b.2' includes a function that corresponds to the selection in FIA_X509_EXT.2.2 in . Function 'b.4' allows the administrator to configure periodicity of assigned commands, for example "read audit logs kept by the MD." In this way the administrator can configure the MDM system to retrieve audit logs from the MD on a periodic, such as daily, basis in order to ensure freshness of log data and to minimize loss of audit logs. Function 'b.5' allows the administrator to configure the privacy-sensitive information that will and will not be collected from particular MDs to handle BYOD environments where some information may not be appropriate to collect. Privacy sensitive information may include items such as device physical location and lists of installed personal applications, and would vary depending on the particular capabilities of the TOE and MDM agent. The TOE should provide the capability to group enrolled devices into categories such as enterprise-owned and personal-owned and define the information that will be collected from devices in each category. Function 'b.6' corresponds to configuring the length of time the user authenticator for enrollment is valid in FMT_SAE_EXT.1. This function must be included in the ST if and only if FMT_SAE_EXT.1 is included in the ST. For distributed TOEs, the interaction between TOE components will be configurable (see FCO_CPC_EXT.1). Therefore, the ST author includes the selection "Ability to configure the interaction between TOE components" for distributed TOEs. A simple example would be the change of communication protocol according to FPT_ITT.1/INTRA_XFER. Another example would be changing the management of a TOE component from direct remote administration to remote administration through another TOE component. A more complex use case would be if the realization of an SFR is achieved through two or more TOE components and the responsibilities between the two or more components could be modified. For distributed TOEs, that implement a registration channel (as described in ), the ST author uses the selection "configure the cryptographic functionality" in this SFR, and its corresponding mapping in the TSS, to describe the configuration of any cryptographic aspects of the registration channel that can be modified by the operational environment in order to improve the channel security. Functions b.9 and b.10 allow the administrator to configure the use of a subordinate MDM server to pass MDM policy files to an MDM agent on a managed device. This includes configuring the authentication and communication mechanisms necessary to establish secure channels between the primary MDM server and subordinate MDM server. If the TOE acts as the primary MDM server, then "Configure the interaction with the subordinate MDM server" should be selected. If the TOE acts as a subordinate MDM server then "Configure the interaction with the primary MDM server" should be selected. The evaluator shall examine the TSS to ensure that it describes each management function listed. For function 'b.5', the evaluator shall examine the TSS to ensure that it describes the privacy-sensitive information that the TOE has the capability to collect from enrolled MDs. The evaluator shall verify the operational guidance includes detailed instructions of what options are available and how to configure each management functional capability listed. The evaluator shall perform the following tests based on the supported functions: Testing for function 'a' (configuration of features allowed for enrollment) is performed in conjunction with the use of the function (FIA_ENR_EXT.1). [conditional] If function 'b.1' is claimed, the evaluator shall configure the TSF authentication certificates and verify that the correct certificate is used to established trusted connections for all claimed SFRs that require the TOE to present an X.509 certificate to an external entity (i.e., FPT_ITT.1/INTRA_XFER, FPT_ITT.1/INTRA_XFER_AGENT, FTP_ITC.1/OE_XFER_IT, and FTP_TRP.1/TRUSTPATH_ENROLL as necessary). [conditional] If function 'b.2' is claimed, the evaluator shall [conditional] If function 'b.3' is claimed, testing for configuration of the warning banner is performed in conjunction with the use of the function (FTA_TAB.1). [conditional] If function 'b.4' is claimed, the evaluator shall configure the TOE to transmit a representative set of commands to an enrolled agent. The evaluator shall then configure several different time intervals in series, demonstrating with each time interval that the TSF issues the configured commands over that interval. [conditional] If function 'b.5' is claimed, the evaluator shall configure the TOE to collect different sets of privacy-sensitive information from mobile devices based on whether they are enterprise-owned or personally-owned, enroll devices as those categories, and verify that only the configured attributes are collected from each. [conditional] If function 'b.6' is claimed, testing for configuration of how long the enrollment authenticator is valid is performed in conjunction with the use of the function (FMT_SAE_EXT.1). [conditional] If function 'b.7' is claimed, the evaluator shall configure the TOE to interact with its distributed components. This is performed in conjunction with the use of the function (FCO_CPC_EXT.1). [conditional] If function 'b.8' is claimed, the evaluator shall configure the TOE's cryptographic functionality with different settings and observe that the configured settings are applied each time (e.g., by configuring connection parameters for secure communications and observing that those communications use the configured settings). [conditional] If function 'b.9' is claimed, the evaluator shall configure the TOE as a subordinate MDM server and demonstrate that it can receive policies from a primary server. [conditional] If function 'b.10' is claimed, the evaluator shall configure the TOE as a primary MDM server and demonstrate that it can transmit policies to a subordinate server. [conditional] If any other functions are claimed in b.11, the evaluator shall verify that the functions can be performed in the manner described in the operational guidance.

Success or failure of function

The <h:b>MAS server</h:b> shall be capable of performing the following management functions: [<h:i><h:ul> <h:li>Configure application access groups</h:li> <h:li>Download applications</h:li> <h:li> <selectables> <selectable><assignable>other MAS management functions</assignable></selectable> <selectable>no other functions</selectable> </selectables></h:li> </h:ul></h:i>] This requirement captures all the configuration functionality in the MAS server to configure the underlying MAS server. The ST author can add more commands and configuration policies by completing the assignment statement. The MAS server must be able to create groups to configure which applications a user can access based on which group they are in. If the MAS server uses the groups defined by the MDM, then it must communicate with the MDM server (if separate server) to determine which applications the user can access. This requirement is claimed if "enable/disable/modify policies listed in FMT_SMF.1/MAS" is selected in FMT_MOF.1.1/FUNCBE. The evaluator shall examine the TSS to ensure that it describes each management function listed.The evaluator shall examine the TSS to determine if the MAS server creates its own groups or relies on the groups specified by the MDM server. The evaluator shall confirm that the operational guidance contains how to create and define user groups and how to specify which applications are accessible by which group. The evaluator shall verify the operational guidance includes instructions on how to associate users with roles. The evaluator shall perform the following tests: The evaluator shall ensure that the MAS client can only access the applications specified for the group they are enrolled in. The evaluator shall create a user group, making sure that the MAS client user is excluded from the group. The evaluator shall then verify that an application accessible to that group cannot be accessed. The evaluator shall take the previous test scenario, but this time include the MAS client user in the group and verify that the application can now be accessed.

The TSF shall maintain the roles <h:b>administrator, MD user, and</h:b> <selectables> <selectable><h:b><assignable>additional authorized identified roles</assignable></h:b></selectable> <selectable><h:b>no additional roles</h:b></selectable> </selectables>.

The TSF shall be able to associate users with roles. It is envisioned that the MDM server will be configured and maintained by different user roles. The assignment is used by the ST author to list the roles that are supported. At a minimum, one administrative role must be supported. If no additional roles are supported, then "no additional roles" is selected. The MD user role is used for enrollment of MDs to the MDM according to FIA_ENR_EXT.1. For distributed TOEs, not every TOE component is required to implement its own user management to fulfill this SFR. At least one component has to support authentication and identification of users according to FIA_UAU.1. For the other TOE components authentication can be realized through the use of a trusted channel (either according to FTP_ITC.1/OE_XFER_IT or FPT_ITT.1/INTRA_XFER / FPT_ITT.1/INTRA_XFER_AGENT) from a component that supports the authentication of users according to FIA_UAU.1. The identification of users according to and the association of users with roles according to is done through the components that support the authentication of users according to FIA_UAU.1. The evaluator shall examine the TSS to verify that it describes the administrator role and the powers granted to and limitations of the role. The evaluator shall review the operational guidance to ensure that it contains instructions for administering the TOE and which interfaces are supported. In the course of performing the testing activities for the evaluation, the evaluator shall use all supported interfaces, although it is not necessary to repeat each test involving an administrative action with each interface. The evaluator shall ensure, however, that each supported method of administering the TOE that conforms to the requirements of this PP be tested; for instance, if the TOE can be administered through a local hardware interface or HTTPS then both methods of administration must be exercised during the evaluation team's test activities.

The TSF shall <h:b>additionally</h:b> maintain the roles of [<h:i>enrolled managed devices, application access groups, and <assignable>additional authorized identified roles</assignable></h:i>].

The <h:b>MAS server</h:b> shall be able to associate users with roles. It is envisioned that the MAS server will be configured and maintained by different user roles. The assignment is used by the ST author to list the roles that are supported. At a minimum, one administrative role must be supported. If no additional roles are supported, then "no additional roles" is stated. The MD user role is used for enrollment of MDs to the MAS according to FIA_ENR_EXT.1. This requirement is claimed if "enable/disable/modify policies listed in FMT_SMF.1/MAS" is selected in FMT_MOF.1.1/FUNCBE. The evaluator shall examine the TSS to verify that it describes the administrator role and the powers granted to and limitations of the role. The evaluator shall review the operational guidance to ensure that it contains instructions for administering the TOE and which interfaces are supported. In the course of performing the testing activities for the evaluation, the evaluator shall use all supported interfaces, although it is not necessary to repeat each test involving an administrative action with each interface. The evaluator shall ensure, however, that each supported method of administering the TOE that conforms to the requirements of this PP be tested; for instance, if the TOE can be administered through a local hardware interface or HTTPS then both methods of administration must be exercised during the evaluation team's test activities.

This family describes document platform APIs when selecting "invoke platform-provided functionality."

This family describes packaging third-party libraries when selecting "implement functionality."

This family defines requirements for running self-tests and verifying integrity or executable code.

This family defines requirements for allowing authorized administrators to query software versions, initiate updates, and verify software updates prior to installation.

defines requirements for API usage.

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

The TSF shall use only documented platform APIs. This requirement applies to the APIs used when "invoke platform-provided functionality" is selected in an SFR. The definition of documented may vary depending on whether the MDM software is provided by a third-party (who relies on documented platform APIs) or by a platform vendor who may be able to guarantee support for platform APIs. For cloud services, this can be completed with a reference to a non-public API document as an annex for those API's that are not or cannot be made public. The evaluator shall verify that the TSS lists the platform APIs used by the MDM software. The evaluator shall then compare the list with the supported APIs (available through e.g., developer accounts, platform developer groups) and ensure that all APIs listed in the TSS are supported. Library Document (conditional: The TOE is a cloud MDM service) The evaluator shall verify that the non-public API document lists the API's used by the MDM service.

The TSF shall preserve a secure state when the following types of failures occur: [<h:i>DRBG self-test failure</h:i>]. This SFR is claimed when "implement functionality" is selected in FCS_RBG.1.1. 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.

Failure of the TSF.

None.

The TSF shall <selectables linebreak="yes"> <selectable><h:b>invoke platform-provided functionality to use <selectables linebreak="yes"> <selectable id="ITT1_IPSEC_INVOKE">IPsec,</selectable> <selectable id="ITT1_TLS_INVOKE">mutually authenticated TLS,</selectable> <selectable id="ITT1_DTLS_INVOKE">mutually authenticated DTLS,</selectable> <selectable id="ITT1_HTTPS_INVOKE">HTTPS,</selectable> <selectable id="ITT1_SSH_INVOKE">SSH</selectable> </selectables></h:b></selectable> <selectable><h:b>implement functionality using <selectables linebreak="yes"> <selectable id="ITT1_IPSEC_IMPLEMENT">IPsec as defined in <xref to="mod-vpnclient"/>,</selectable> <selectable id="ITT1_TLS_IMPLEMENT">mutually authenticated TLS as defined in <xref to="tls"/>,</selectable> <selectable id="ITT1_DTLS_IMPLEMENT">mutually authenticated DTLS as defined in <xref to="tls"/>,</selectable> <selectable id="ITT1_HTTPS_IMPLEMENT">HTTPS in accordance with FCS_HTTPS_EXT.1,</selectable> <selectable id="ITT1_SSH_IMPLEMENT">SSH as defined in <xref to="ssh"/></selectable> </selectables></h:b></selectable></selectables> <h:b>to</h:b> protect <h:b>all</h:b> data from [<h:i>disclosure and modification</h:i>] when it is <h:b>transferred</h:b> between separate parts of the TOE. This requirement ensures that all communications between MDM server components of a distributed TOE are protected through the use of an encrypted communications channel. If the TOE boundary includes MDM agents, that is covered by FPT_ITT.1/INTRA_XFER_AGENT. The trusted channel uses secure protocols that preserve the confidentiality and integrity of MDM communications. For this particular use, any of IPsec, TLS, DTLS, HTTPS, or SSH can be used. If TLS or DTLS is used, mutual authentication must be supported regardless of whether the TOE acts as the client or the server in this connection. Where X.509 validation is needed (e.g., if the TOE acts as a TLS server that supports mutual authentication), must be claimed. To distinguish X.509 validation for internal communications from validation for external communications (e.g., communication between TOE components versus communication to a remote IT entity in the operational environment), FIA_X509_EXT.1 from must be iterated for this use as "FIA_X509_EXT.1/Internal" per the guidance in . This channel may also be used as the registration channel for the registration process, as described in section 3.1 and . If the ST author selects that the TSF implements "IPsec as defined in ," the TSF must claim conformance to a PP-Configuration that includes the VPN Client PP-Module. If the ST author selects that the TSF implements "SSH as defined in ," the TSF must be validated against . If the ST author selects that the TSF implements "mutually authenticated TLS as defined in " or "mutually authenticated DTLS as defined in ," the TSF must be validated against requirements from , with the following selections made: FCS_TLS_EXT.1: either TLS or DTLS is selected depending on the selection made in either client or server is selected as appropriate FCS_TLSC_EXT.1.1 or FCS_TLSS_EXT.1.1 (as appropriate): The ciphersuites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1. mutual authentication must be selected FCS_DTLSC_EXT.1.1 or FCS_DTLSS_EXT.1.1 (as appropriate): The ciphersuites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1. mutual authentication must be selected Protocol, DRBG, Certificate validation, algorithm, and similar services may be met with platform-provided services. This requirement is claimed if "FPT_ITT.1/INTRA_XFER" is selected in FTP_ITC_EXT.1. If HTTPS is selected, FCS_HTTPS_EXT.1 must be included in the ST. FCS_HTTPS_EXT.1 includes selections for both TSF and platform-provided HTTPS functionality, so this must be claimed if either of the HTTPS selections above are made. The evaluator shall examine the TSS to determine that the methods and protocols used to protect distributed TOE components are described. The evaluator shall also confirm that all protocols listed in the TSS in support of TOE administration are consistent with those specified in the requirement, and are included in the requirements in the ST. If "invoke platform-provided functionality" is selected, the evaluator shall examine the TSS to verify that it describes (for each supported platform) how this functionality is invoked (it should be noted that this may be through a mechanism that is not implemented by the MDM server; nonetheless, that mechanism will be identified in the TSS as part of this evaluation activity). The evaluator shall confirm that the operational guidance contains instructions for establishing the communication paths for each supported method. The evaluator shall ensure that communications using each specified (in the operational guidance) communication method is tested during the course of the evaluation, setting up the connections as described in the operational guidance and ensuring that communication is successful. The evaluator shall ensure, for each method of communication, the channel data is not sent in plaintext. Further evaluation activities are associated with the specific protocols.

Initiation and termination of the trusted channel

Trusted channel protocol

Identity of initiator and recipient

The TSF shall <selectables> <selectable><h:b>invoke platform-provided functionality to use <selectables linebreak="yes"> <selectable id="ITT2_TLS_INVOKE">mutually authenticated TLS,</selectable> <selectable id="ITT2_DTLS_INVOKE">mutually authenticated DTLS,</selectable> <selectable id="ITT2_HTTPS_INVOKE">HTTPS</selectable> </selectables></h:b></selectable> <selectable><h:b>implement functionality using <selectables linebreak="yes"> <selectable id="ITT2_TLS_IMPLEMENT">mutually authenticated TLS as defined in <xref to="tls"/>,</selectable> <selectable id="ITT2_DTLS_IMPLEMENT">mutually authenticated DTLS as defined in <xref to="tls"/>,</selectable> <selectable id="ITT2_HTTPS_IMPLEMENT">HTTPS in accordance with FCS_HTTPS_EXT.1</selectable> </selectables></h:b></selectable></selectables> <h:b>to</h:b> protect all data from [<h:i>disclosure and modification</h:i>] when it is <h:b>transferred</h:b> between <h:b>the TSF and MDM agent.</h:b> This requirement ensures all communications between the TSF and MDM agent are protected through the use of an encrypted communications channel when MDM agents are included in the TOE boundary. If the TOE boundary includes distributed MDM server components, that is covered by FPT_ITT.1/INTRA_XFER. The trusted channel uses secure protocols that preserve the confidentiality and integrity of MDM agent communications. This requirement is to ensure that the transmission of any audit logs, MD information data (software version, hardware model, and application versions), and configuration data collected by the MDM agent and sent from the MDM agent to the MDM Server, when commanded, or at configurable intervals, is properly protected. This trusted channel also protects any commands and policies sent by the MDM server to the MDM agent. Either the MDM agent or the MDM server is able to initiate the connection. For this particular use, only TLS, DTLS, or HTTPS is permitted. If TLS or DTLS is used, mutual authentication must be supported regardless of whether the TOE acts as the client or the server in this connection. Where X.509 validation is needed (e.g., if the TOE acts as a TLS server supporting mutual authentication), must be claimed. To distinguish X.509 validation for internal communications from validation for external communications (e.g., communication between TOE components versus communication to a remote IT entity in the operational environment), FIA_X509_EXT.1 from must be iterated for this use as "FIA_X509_EXT.1/Internal" per the guidance in . If the ST author selects that the TSF implements "mutually authenticated TLS as defined in " or "mutually authenticated DTLS as defined in ," the TSF must be validated against requirements from , with the following selections made: FCS_TLS_EXT.1: either TLS or DTLS is selected depending on the selection made in server is selected FCS_TLSS_EXT.1.1 (as appropriate): The ciphersuites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1. mutual authentication must be selected FCS_DTLSS_EXT.1.1 (as appropriate): The ciphersuites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1. mutual authentication must be selected Protocol, DRBG, Certificate validation, algorithm, and similar services may be met with platform-provided services. This requirement is claimed if "FPT_ITT.1/INTRA_XFER_AGENT" is selected in FTP_ITC_EXT.1. If HTTPS is selected, FCS_HTTPS_EXT.1 must be included in the ST. FCS_HTTPS_EXT.1 includes selections for both TSF and platform-provided HTTPS functionality, so this must be claimed if either of the HTTPS selections above are made. The evaluator shall examine the TSS to determine that the methods and protocols used to protect distributed TOE components are described. The evaluator shall also confirm that all protocols listed in the TSS in support of TOE administration are consistent with those specified in the requirement, and are included in the requirements in the ST. If "invoke platform-provided functionality" is selected, the evaluator shall examine the TSS to verify that it describes (for each supported platform) how this functionality is invoked (it should be noted that this may be through a mechanism that is not implemented by the MDM server; nonetheless, that mechanism will be identified in the TSS as part of this evaluation activity). The evaluator shall confirm that the operational guidance contains instructions for establishing the communication paths for each supported method. The evaluator shall ensure that communications using each specified (in the operational guidance) communication method is tested during the course of the evaluation, setting up the connections as described in the operational guidance and ensuring that communication is successful. The evaluator shall ensure, for each method of communication, the channel data is not sent in plaintext. Further evaluation activities are associated with the specific protocols.

Initiation and termination of the trusted channel

Trusted channel protocol

Identity of initiator and recipient

defines requirements for third-party libraries.

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

The MDM software shall be packaged with only <assignable>list of third-party libraries</assignable>. The intention of this requirement is for the ST author to document which software libraries (including version numbers) the MDM software is including in case vulnerabilities are later discovered with those libraries. For cloud services, the assignment can be completed with a reference to a non-public library document as an annex for those libraries that are not or cannot be made public. The evaluator shall verify that the TSS lists the libraries used by the MDM software or the public libraries used by the cloud MDM services. The evaluator shall verify that libraries found to be packaged with or employed by the MDM software are limited to those in the assignment. Library Document (conditional: The TOE is a cloud MDM service) The evaluator shall verify that the non-public library document lists the libraries used by the MDM service.

The TSF shall provide the capability to consistently interpret <assignable>MDM policy</assignable> when shared between the primary MDM server and the MDM agent.

The TSF shall use <assignable>list of interpretation rules to be applied by the TSF</assignable> when interpreting MDM policy from the primary MDM server. The intent of this requirement is to verify that there are well-defined rules that the subordinate MDM server follows if it modifies/interprets the MDM policy sent from the primary MDM server that is then delivered to the MDM agent on the managed device. For example: a mapping between the command received from the primary MDM server and the matching command delivered to the MDM agent. If the subordinate MDM does not modify the policy for delivery to the MDM agent, then this requirement is implicitly satisfied. The evaluator ensures that the TSS describes how the policies are translated between the policy that is accepted by the subordinate MDM server and the policy that is generated for delivery to the MDM agent on the managed device. This should include a description or mapping for each MDM agent configuration and policy function claimed in FMT_SMF.1/SERVER_CONF_AGENT. The evaluator shall perform a policy update from an available configuration interface (such as through a test primary MDM server) and retain a copy of the resulting policy. The evaluator then obtains a version of the policy modified by the subordinate MDM for delivery to the MDM agent. The evaluator shall compare the original policy to the modified policy and ensure that the translation rules are valid for each configuration and policy function claimed.

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 specified 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 and output data]</h:i>].

The TSF shall provide authorized users with the capability to verify the integrity of [<h:i>[TSF DRBG specified in FCS_RBG.1]</h:i>]. This SFR is claimed when "implement functionality" is selected in FCS_RBG.1.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 in 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.

defines requirements for the integrity of self-testing.

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: Initiation of self-test. Failure of self-test. Detected integrity violation FPT_TST.1 TSF Self-Testing

The TSF shall run a suite of self tests during initial start-up (power on) to demonstrate correct operation of the TSF.

The TSF shall <selectables> <selectable>invoke platform-provided functionality</selectable> <selectable>implement functionality</selectable> </selectables> to provide the capability to verify the integrity of stored TSF executable code when it is loaded for execution through the use of the <selectables> <selectable>TSF</selectable> <selectable>TOE platform</selectable> </selectables>-provided cryptographic services. While the TOE is typically a software package running in the IT Environment, it is still capable of performing the self-test activities required above. It should be understood, however, that there is a significant dependency on the host environment in assessing the assurance provided by the tests mentioned above (meaning that if the host environment is compromised, the self-tests will not be meaningful). For distributed TOEs, all TOE components (except the Agent components) have to perform self-tests. This does not necessarily mean that each TOE component has to carry out the same self-tests: the ST describes the applicability of the selection (i.e., when self-tests are run) and the final assignment (i.e., which self-tests are carried out) to each TOE component. If "invoke platform-provided functionality" is selected, the evaluator shall examine the TSS to verify that it describes (for each supported platform) how this functionality is invoked (it should be noted that this may be through a mechanism that is not implemented by the MDM server; nonetheless, that mechanism will be identified in the TSS as part of this evaluation activity). If "implement functionality" is selected, the evaluator shall examine the TSS to ensure that it details the self-tests that are run by the TSF on start-up; this description should include an outline of what the tests are actually doing (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 evaluator shall ensure that the TSS makes an argument that the tests are sufficient to demonstrate that the TSF is operating correctly. The evaluator shall examine the TSS to ensure that it describes how to verify the integrity of stored TSF executable code when it is loaded for execution. The evaluator shall ensure that the TSS makes an argument that the tests are sufficient to demonstrate that the integrity of stored TSF executable code has not been compromised. The evaluator also ensures that the TSS (or the operational guidance) describes the actions that take place for successful (e.g., hash verified) and unsuccessful e.g., hash not verified) cases. The evaluator shall verify that the operational guidance includes a description of how the administrator can verify that a self-test has failed and any potential corrective actions that can be used to resolve the failure state. The evaluator shall perform the following tests: The evaluator performs the integrity check on a known good TSF executable and verifies that the check is successful. The evaluator modifies the TSF executable, performs the integrity check on the modified TSF executable and verifies that the check fails.

Initiation of self-test

Failure of self-test

Algorithm that caused failure

Detected integrity violation

The TSF code file that caused the integrity violation

defines requirements for authorized administrators to manage software versions and updates.

The following actions could be considered for the management functions in FMT. Query the current version of the MD firmware or software. Update system software (PP_MDF/PP_GPOS Function 15). 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 No dependencies.

The TSF shall provide authorized administrators the ability to query the current version of the software. For a distributed TOE, the method of determining the installed versions on each component of the TOE is described in the operational guidance. In the requirement, "software" refers to the component of the distributed TOE to which the requirement is being applied. The evaluator shall verify that the TSS identifies the mechanism by which the current version of the TOE can be identified. The evaluator shall ensure that the administrator guidance includes instructions for determining the current version of the TOE. The evaluator shall query the TSF for the current version of the software according to the operational guidance and shall verify that the current version matches that of the documented and installed version.

The TSF shall <selectables> <selectable>invoke platform-provided functionality</selectable> <selectable>implement functionality</selectable> </selectables> to provide authorized administrators the ability to initiate updates to the TOE. If "invoke platform-provided functionality" is selected, the evaluator shall examine the TSS to verify that it describes (for each supported platform) how this functionality is invoked (it should be noted that this may be through a mechanism that is not implemented by the MDM server; nonetheless, that mechanism will be identified in the TSS as part of this evaluation activity). The evaluator shall verify that the operational guidance provides instructions for how to initiate an update to the TOE and any restrictions on this function such that only an authorized administrator can perform it.

The TSF shall <selectables> <selectable>invoke platform-provided functionality</selectable> <selectable>implement functionality</selectable> </selectables> to provide a means to verify software updates to the TSF using a digital signature mechanism prior to installing those updates. The software on the TSF will occasionally need to be updated. This requirement is intended to ensure that the TSF only installs updates provided by the vendor, as updates provided by another source may contain malicious code. For distributed TOEs, all TOE components must support Trusted Update. The verification of the signature or hash on the update must either be done by each TOE component itself (signature verification) or for each TOE component (hash verification). Updating a distributed TOE might lead to the situation where different TOE components are running different software versions. Depending on the differences between the different software versions the impact of a mixture of different software versions might be no problem at all or critical to the proper functioning of the TOE. The TSS must detail the mechanisms that support the continuous proper functioning of the TOE during trusted update of distributed TOEs. If "invoke platform-provided functionality" is selected, the evaluator shall examine the TSS to verify that it describes (for each supported platform) how this functionality is invoked (it should be noted that this may be through a mechanism that is not implemented by the MDM server; nonetheless, that mechanism will be identified in the TSS as part of this evaluation activity). If "implement functionality" is selected, the evaluator shall examine the TSS and verify that it describes the standards by which the updates are digitally signed and how the signature verification process is implemented. The evaluator shall examine the operational guidance to verify that it identifies how the TOE will verify the integrity of an update and how the administrator is made aware of a failure to verify the integrity of the update. The evaluator shall perform the following tests: The evaluator shall attempt to initiate an update digitally signed by the vendor and verify that the update is successfully installed. The evaluator shall attempt to install an update not digitally signed by the vendor and verify that either the signature can be checked (allowing the update to be aborted) or the update is not installed.

Success or failure of signature verification

Before establishing a user session, the [<h:i>TSF</h:i>] shall <selectables> <selectable><h:b>invoke platform-provided functionality</h:b></selectable> <selectable><h:b>implement functionality</h:b></selectable> </selectables> <h:b>to</h:b> display an [<h:i>administrator-specified advisory notice and consent warning</h:i>] message <h:b>regarding use of the TOE.</h:b> This requirement is to ensure that an advisory notice or consent banner is presented to the user on start-up or unlock of the TSF. If "invoke platform-provided functionality" is selected, the evaluator shall examine the TSS to verify that it describes (for each supported platform) how this functionality is invoked (it should be noted that this may be through a mechanism that is not implemented by the MDM server; nonetheless, that mechanism will be identified in the TSS as part of this evaluation activity). If "implement functionality" is selected, the TSS shall describe when the banner is displayed. The evaluator follows the operational guidance to configure a notice and consent warning message. The evaluator shall also perform the following test: The evaluator shall 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.

Change in banner setting

The family defines requirements for communication channels between itself and other communication channels.

The TSF shall <selectables> <selectable><h:b>invoke platform-provided functionality to use <selectables linebreak="yes"> <selectable id="ITC1_IPSEC_INVOKE">IPsec,</selectable> <selectable id="ITC1_SSH_INVOKE">SSH,</selectable> <selectable id="ITC1_TLS_INVOKE">mutually authenticated TLS,</selectable> <selectable id="ITC1_DTLS_INVOKE">mutually authenticated DTLS,</selectable> <selectable id="ITC1_HTTPS_INVOKE">HTTPS</selectable> </selectables></h:b></selectable> <selectable><h:b>implement functionality using <selectables linebreak="yes"> <selectable id="ITC1_IPSEC_IMPLEMENT">IPsec as defined in <xref to="mod-vpnclient"/>,</selectable> <selectable id="ITC1_SSH_IMPLEMENT">SSH as defined in <xref to="ssh"/>,</selectable> <selectable id="ITC1_TLS_IMPLEMENT">mutually authenticated TLS as defined in <xref to="tls"/>,</selectable> <selectable id="ITC1_DTLS_IMPLEMENT">mutually authenticated DTLS as defined in <xref to="tls"/>,</selectable> <selectable id="ITC1_HTTPS_IMPLEMENT">HTTPS in accordance with FCS_HTTPS_EXT.1</selectable> </selectables></h:b></selectable></selectables> <h:b>to</h:b> provide a <h:b>trusted</h:b> communication channel between itself and <h:b>authorized</h:b> IT <h:b>entities supporting the following capabilities: audit server, compliance server, <selectables linebreak="yes"> <selectable>authentication server,</selectable> <selectable>primary MDM server,</selectable> <selectable>subordinate MDM server,</selectable> <selectable><assignable>other capabilities</assignable></selectable> </selectables></h:b> that is logically distinct from other communication channels and provides assured identification of its endpoints and protection of the channel data from modification or disclosure. This requirement ensures that all communications between the TOE and external IT entities other than MDM agents are protected through the use of an encrypted communications channel. If the TOE's operational environment includes MDM agents (i.e., they are not part of the TOE), that is covered by FTP_ITC.1/OE_XFER_AGENT. Protected communications for remote administration is covered by FTP_TRP.1/TRUSTPATH_REM_ADMIN. The trusted channel uses secure protocols that preserve the confidentiality and integrity of MDM communications. For this particular use, any of IPsec, TLS, DTLS, HTTPS, or SSH can be used. If TLS or DTLS is used, mutual authentication must be supported regardless of whether the TOE acts as the client or the server in this connection. The operational environment may or may not use mutual authentication, but the TOE is expected to make use of it if it does. Where X.509 validation is needed (e.g., if the TOE acts as a TLS client), must be claimed. To distinguish X.509 validation for external communications from validation for internal communications (e.g., communication with a remote IT entity in the operational environment versus communication between TOE components), FIA_X509_EXT.1 from must be included in the ST and iterated as "FIA_X509_EXT.1/External" per the guidance in . Protection (by one of the listed protocols) is required at least for communications with the server(s) that collect the audit information (FAU_STG.1.1) and/or compliance information (FAU_CRP_EXT.1.1). If it communicates with an authentication server (e.g., RADIUS), then the ST author chooses "authentication server" in FTP_ITC.1.1/OE_XFER_IT and this connection must be protected by one of the listed protocols. Likewise if the TOE acts as either a primary or subordinate MDM server, then "primary MDM server" or "subordinate MDM server" is selected for the device it communicates with and those communications are protected by one of the listed protocols. If other authorized IT entities (e.g., NTP server) are protected, the ST author makes the appropriate assignments (for those entities) and selections (for the protocols that are used to protect those connections). If the ST author selects that the TSF implements "IPsec as defined in ," the TSF must claim conformance to a PP-Configuration that includes the VPN Client PP-Module. If the ST author selects that the TSF implements "SSH as defined in ," the TSF must be validated against . If the ST author selects that the TSF implements "mutually authenticated TLS as defined in " or "mutually authenticated DTLS as defined in ," the TSF must be validated against requirements from , with the following selections made: FCS_TLS_EXT.1: either TLS or DTLS is selected depending on the selection made in FTP_ITC.1.1/OE_XFER_IT either client or server is selected as appropriate FCS_TLSC_EXT.1.1 or FCS_TLSS_EXT.1.1 (as appropriate): The ciphersuites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1. mutual authentication must be selected FCS_DTLSC_EXT.1.1 or FCS_DTLSS_EXT.1.1 (as appropriate): The ciphersuites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1. mutual authentication must be selected Protocol, DRBG, Certificate validation, algorithm, and similar services may be met with platform-provided services. The requirement implies that not only are communications protected when they are initially established, but also on resumption after an outage. It may be the case that some part of the TOE setup involves manually setting up tunnels to protect other communication, and if after an outage the TOE attempts to re-establish the communication automatically with (the necessary) manual intervention, there may be a window created where an attacker might be able to gain critical information or compromise a connection.

The TSF shall <selectables> <selectable><h:b>invoke platform-provided functionality</h:b></selectable> <selectable><h:b>implement functionality</h:b></selectable> </selectables> <h:b>to</h:b> permit <h:b>the MDM server or other authorized IT entities</h:b> to initiate communication via the trusted channel.

The TSF shall <selectables> <selectable><h:b>invoke platform-provided functionality</h:b></selectable> <selectable><h:b>implement functionality</h:b></selectable> </selectables> <h:b>to</h:b> initiate communication via the trusted channel for <assignable>list of functions for which a trusted channel is required</assignable>. While there are no requirements on the party initiating the communication, the ST author lists in the assignment for the services for which the TOE can initiate the communication with the authorized IT entity. The evaluator shall examine the TSS to determine that the methods of communication with authorized IT entities are indicated, along with how those communications are protected. If "invoke platform-provided functionality" is selected, the evaluator shall examine the TSS to verify that it describes (for each supported platform) how this functionality is invoked (it should be noted that this may be through a mechanism that is not implemented by the MDM server; nonetheless, that mechanism will be identified in the TSS as part of this evaluation activity). The evaluator shall confirm that the operational guidance contains instructions for configuring the communication channel between the MDM server and authorized IT entities for each supported method. The evaluator shall ensure that communications using each specified (in the operational guidance) communication method is tested during the course of the evaluation, setting up the connections as described in the operational guidance and ensuring that communication is successful. The evaluator shall ensure, for each method of communication, the channel data is not sent in plaintext. The evaluator shall ensure, for each communication channel with the MDM server, that a protocol analyzer identifies the traffic as the protocol under testing. Further evaluation activities are associated with the specific protocols.

Initiation and termination of the trusted channel

Trusted channel protocol

Non-TOE endpoint of connection

The TSF shall <selectables> <selectable><h:b>invoke platform-provided functionality to use <selectables linebreak="yes"> <selectable id="ITC2_TLS_INVOKE">mutually authenticated TLS,</selectable> <selectable id="ITC2_DTLS_INVOKE">mutually authenticated DTLS,</selectable> <selectable id="ITC2_HTTPS_INVOKE">HTTPS</selectable> </selectables></h:b></selectable> <selectable><h:b>implement functionality using <selectables linebreak="yes"> <selectable id="ITC2_TLS_IMPLEMENT">mutually authenticated TLS as defined in <xref to="tls"/>,</selectable> <selectable id="ITC2_DTLS_IMPLEMENT">mutually authenticated DTLS as defined in <xref to="tls"/>,</selectable> <selectable id="ITC2_HTTPS_IMPLEMENT">HTTPS in accordance with FCS_HTTPS_EXT.1</selectable> </selectables></h:b></selectable></selectables> <h:b>to</h:b> provide a <h:b>trusted</h:b> communication channel between itself <h:b>(as a server) and the MDM agent</h:b> that is logically distinct from other communication channels, provides assured identification of its endpoints, <h:b>protects channel data from disclosure, and detects modification of the channel data.</h:b> This requirement ensures that all communications between the MDM server and environmental MDM agents are protected through the use of an encrypted communications channel. If the TOE boundary includes MDM agents, that is covered by FPT_ITT.1/INTRA_XFER_AGENT. Protected communications for MDM agent enrollment is covered by FTP_TRP.1/TRUSTPATH_ENROLL. The trusted channel uses secure protocols that preserve the confidentiality and integrity of MDM agent communications. This requirement is to ensure that the transmission of any audit logs, MD information data (software version, hardware model, and application versions), and configuration data collected by the MDM agent and sent from the MDM agent to the MDM Server, when commanded, or at configurable intervals, is properly protected. This trusted channel also protects any commands and policies sent by the MDM server to the MDM agent. Either the MDM agent or the MDM server is able to initiate the connection. If the TOE includes a separate MAS server, this requirement also addresses the communication between the MAS server and the MDM agent. For this particular use, only TLS, DTLS, or HTTPS is permitted. If TLS or DTLS is used, mutual authentication must be supported regardless of whether the TOE acts as the client or the server in this connection. The environmental MDM agents are expected to support mutual authentication, so the TOE is expected to make use of it. Where X.509 validation is needed (e.g., if the TOE acts as a TLS server supporting mutual authentication), must be claimed. To distinguish X.509 validation from validation for external communications (e.g., communication with an MDM agent in the operational environment versus communication between TOE components), FIA_X509_EXT.1 from must be iterated for this use as "FIA_X509_EXT.1/Internal" per the guidance in . If the ST author selects that the TSF implements "mutually authenticated TLS as defined in " or "mutually authenticated DTLS as defined in ," the TSF must be validated against requirements from , with the following selections made: FCS_TLS_EXT.1: either TLS or DTLS is selected depending on the selection made in FTP_ITC.1.1/OE_XFER_AGENT server must be selected FCS_TLSS_EXT.1.1 (as appropriate): The ciphersuites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1. mutual authentication must be selected FCS_DTLSS_EXT.1.1 (as appropriate): The ciphersuites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1. mutual authentication must be selected Protocol, DRBG, Certificate validation, algorithm, and similar services may be met with platform-provided services. The requirement implies that not only are communications protected when they are initially established, but also on resumption after an outage. It may be the case that some part of the TOE setup involves manually setting up tunnels to protect other communication, and if after an outage the TOE attempts to re-establish the communication automatically with (the necessary) manual intervention, there may be a window created where an attacker might be able to gain critical information or compromise a connection. This requirement is claimed if "FTP_ITC.1/OE_XFER_AGENT" is selected in FTP_ITC_EXT.1. If HTTPS is selected, FCS_HTTPS_EXT.1 must be included in the ST. FCS_HTTPS_EXT.1 includes selections for both TSF and platform-provided HTTPS functionality, so this must be claimed if either of the HTTPS selections above are made.

The TSF shall <h:b><selectables> <selectable>invoke platform-provided functionality</selectable> <selectable>implement functionality</selectable> </selectables> to</h:b> initiate communication via the trusted channel for [<h:i>all communication between the TSF and the MDM agent</h:i>] The evaluator shall examine the TSS to determine that the methods of agent-server communication are indicated, along with how those communications are protected. The evaluator shall also confirm that all protocols listed in the TSS in support of remote TOE administration are consistent with those specified in the requirement, and are included in the requirements in the ST. If "invoke platform-provided functionality" is selected, the evaluator shall examine the TSS to verify that it describes (for each supported platform) how this functionality is invoked (it should be noted that this may be through a mechanism that is not implemented by the MDM server; nonetheless, that mechanism will be identified in the TSS as part of this evaluation activity). The evaluator shall confirm that the operational guidance contains instructions for configuring the communication channel between the MDM agent and the MDM server for each supported method. The evaluator shall ensure that communications using each specified (in the operational guidance) agent-server communication method is tested during the course of the evaluation, setting up the connections as described in the operational guidance and ensuring that communication is successful. The evaluator shall ensure, for each method of agent-server communication, the channel data is not sent in plaintext. The evaluator shall ensure, for each communication channel with the MDM server, that a protocol analyzer identifies the traffic as the protocol under testing. Further evaluation activities are associated with the specific protocols.

Initiation and termination of the trusted channel

Trusted channel protocol

Non-TOE endpoint of connection

defines requirements for providing logically distinct communication channels.

There are no management activities foreseen. There are no auditable events foreseen. FTP_ITC.1 Inter-TSF Trusted Channel FTP_TRP.1 Trusted Path

The TSF shall provide a communication channel between itself and <selectables linebreak="yes"> <selectable id="ITC_AgentInTOE">an MDM agent that is internal to the TOE <h:b>as defined in FPT_ITT.1/INTRA_XFER</h:b>,</selectable> <selectable id="ITC_AgentOutTOE">an MDM agent that is external to the TOE <h:b>as defined in FPT_ITT.1/INTRA_XFER_AGENT</h:b>,</selectable> <selectable id="ITC_IS_PRIMARY_MDM">a subordinate MDM server <h:b>as defined in FTP_ITC.1/OE_XFER_IT</h:b>,</selectable> <selectable id="ITC_IS_SUBORDINATE_MDM">a primary MDM server <h:b>as defined in FTP_ITC.1/OE_XFER_IT</h:b>,</selectable> <selectable id="ITC_DISTRIBUTED_TOE">other components comprising the distributed TOE <h:b>as defined in FPT_ITT.1/INTRA_XFER</h:b></selectable> </selectables> that is logically distinct from other communication channels, as defined in <selectables> <selectable id="ITC_DISTRIBUTED_TOE_ITT1">FPT_ITT.1/INTRA_XFER,</selectable> <selectable id="ITC_AgentInTOE_ITT2">FPT_ITT.1/INTRA_XFER_AGENT,</selectable> <selectable id="ITC_AgentOutTOE_ITC">FTP_ITC.1/OE_XFER_AGENT,</selectable> <selectable id="ITC_OE_XFER_IT">FTP_ITC.1/OE_XFER_IT</selectable> </selectables>.

The TSF shall provide a communication channel between itself and <selectables linebreak="yes"> <selectable>an MDM agent that is internal to the TOE,</selectable> <selectable>an MDM agent that is external to the TOE,</selectable> <selectable>a subordinate MDM server,</selectable> <selectable>a primary MDM server,</selectable> <selectable>other components comprising the distributed TOE</selectable> </selectables> that is logically distinct from other communication channels.

This SFR describes the communication channels between the MDM server and an agent that may or may not be inside the TOE boundary, and optionally separate components comprising a distributed TOE, to determine which selection-based SFRs will need to be included in the ST. If is selected, then the MDM is a subordinate MDM and communicates with a Primary MDM. If the MDM is a subordinate MDM then FMT_POL_EXT.3 and FPT_TDC.1/POLICY must be included in the ST. "" should be selected when the MDM is a primary MDM and communicates with a subordinate MDM. If the MDM is neither a primary nor a subordinate MDM, it only communicates with the MDM agents directly, then neither should be selected. The evaluator shall ensure that the TSS contains whether the MDM server communication channel is internal or external to the TOE. This testing can be completed in conjunction with the testing for FPT_ITT.1/INTRA_XFER / FPT_ITT.1/INTRA_XFER_AGENT, FTP_ITC.1/OE_XFER_AGENT, or FTP_ITC.1/OE_XFER_IT.

The TSF shall <selectables> <selectable><h:b>invoke platform-provided functionality to use <selectables linebreak="yes"> <selectable id="TRP2_TLS_INVOKE">TLS,</selectable> <selectable id="TRP2_HTTPS_INVOKE">HTTPS</selectable> </selectables></h:b></selectable> <selectable><h:b>implement functionality using <selectables linebreak="yes"> <selectable id="TRP2_TLS_IMPLEMENT">TLS as defined in <xref to="tls"/>,</selectable> <selectable id="TRP2_HTTPS_IMPLEMENT">HTTPS in accordance with FCS_HTTPS_EXT.1</selectable> </selectables></h:b></selectable> </selectables> <h:b>to</h:b> provide a <h:b>trusted</h:b> communication path between itself and [<h:i>remote</h:i>] users that is logically distinct from other communication paths and provides assured identification of its endpoints and protection of the communicated data from [<h:i>modification, disclosure</h:i>].

Initiation and termination of the trusted channel

Trusted channel protocol

The TSF shall <selectables> <selectable><h:b>invoke platform-provided functionality</h:b></selectable> <selectable><h:b>implement functionality</h:b></selectable> </selectables> <h:b>to</h:b> provide a communication path between itself and <h:b>a joining component</h:b> that is logically distinct from other communication paths and provides assured identification of <selectables> <selectable><h:b>the TSF endpoint</h:b></selectable> <selectable><h:b>both joining component and TSF endpoint</h:b></selectable> </selectables> and protection of the communicated data from [<h:i>modification</h:i>] <h:b>and</h:b> <selectables> <selectable>disclosure</selectable> <selectable><h:b>none</h:b></selectable> </selectables>.

The TSF shall <selectables> <selectable><h:b>invoke platform-provided functionality</h:b></selectable> <selectable><h:b>implement functionality</h:b></selectable> </selectables> <h:b>to</h:b> permit <selectables> <selectable>the TSF</selectable> <selectable><h:b>the joining component</h:b></selectable> </selectables> to initiate communication via the trusted path.

The TSF shall <selectables> <selectable><h:b>invoke platform-provided functionality</h:b></selectable> <selectable><h:b>implement functionality</h:b></selectable> </selectables> <h:b>to</h:b> require the use of the trusted path for [<h:i>joining components to the TSF under environmental constraints identified in <assignable>reference to operational guidance</assignable>]</h:i>. This requirement ensures that communications are protected between MDM server components when a distinct path is used to join components into a distributed TOE. If a separate channel is not used for joining, that is covered by FPT_ITT.1/INTRA_XFER. This requirement does not address an MDM agent joining a distributed TOE. That is covered by FTP_TRP.1/TRUSTPATH_ENROLL. When creating the distributed TOE from the initial components, any of these components may be identified as the TSF for the purposes of satisfying the meaning of "TSF" in this SFR. The selection at the end of FTP_TRP.1/TRUSTPATH_JOIN recognizes that in some cases confidentiality (i.e., protection of the data from disclosure) may not be provided by the channel. The ST author distinguishes in the TSS whether in this case the TOE relies on the environment to provide confidentiality (as part of the constraints referenced in ) or whether the registration data exchanged does not require confidentiality (in which case this assertion must be justified). If "none" is selected, then this word may be omitted in the ST to improve readability. The assignment in ensures that the ST highlights any specific details needed to protect the registration environment. As this does not follow the same rules as the other trusted communications requirements, specific requirements for how the operational guidance discusses the configuration of this path are included in the EA. The evaluator shall examine the TSS to determine that the methods of joining TOE components are indicated, along with how those communications are protected. The evaluator shall also confirm that all protocols listed in the TSS in support of joining are consistent with those specified in the requirement, and are included in the requirements in the ST. If "invoke platform-provided functionality" is selected, the evaluator shall examine the TSS to verify that it describes (for each supported platform) how this functionality is invoked (it should be noted that this may be through a mechanism that is not implemented by the MDM server; nonetheless, that mechanism will be identified in the TSS as part of this evaluation activity). The evaluator shall confirm that the operational guidance contains instructions for joining TOE components for each supported method. The evaluator shall also perform the following tests: The evaluator shall ensure that the communications path for joining components to the TSF is tested for each distinct (nonequivalent) component type, setting up the connections as described in the guidance documentation and ensuring that communication is successful. In particular the evaluator shall confirm that requirements on environment protection for the registration process are consistent with observations made on the test configuration (for example, a requirement to isolate the components from the Internet during registration might be inconsistent with the need for a component to contact a license server). If no requirements on the registration environment are identified as necessary to protect confidentiality, then the evaluator shall confirm that the key used for registration can be configured (following the instructions in the guidance documentation) to be at least the same length as the key used for the internal TSF channel that is being enabled. The evaluator shall confirm that the key used for the channel is unique to the pair of components (this is done by identifying the relevant key during the registration test: it is not necessary to examine the key value). The evaluator shall follow the guidance documentation to ensure that in fact the communication channel can be enabled by an administrator for all the TOE components identified in the guidance documentation as capable of initiation. The evaluator shall ensure that if the guidance documentation states that the channel data is encrypted then the data observed on the channel is not plaintext. The evaluator shall ensure that, for each different pair of nonequivalent component types that can use the registration channel, the connection is physically interrupted during a joining attempt. The evaluator shall ensure that when physical connectivity is restored, communications are appropriately protected. Further evaluation activities are associated with the specific protocols.

Initiation and termination of the trusted channel

Trusted channel protocol

The TSF shall <selectables linebreak="yes"> <selectable><h:b>invoke platform-provided functionality to use <selectables linebreak="yes"> <selectable id="TRP1_IPSEC_INVOKE">IPsec,</selectable> <selectable id="TRP1_TLS_INVOKE">TLS,</selectable> <selectable id="TRP1_HTTPS_INVOKE">HTTPS,</selectable> <selectable id="TRP1_SSH_INVOKE">SSH</selectable> </selectables></h:b></selectable> <selectable><h:b>implement functionality using <selectables linebreak="yes"> <selectable id="TRP1_IPSEC_IMPLEMENT">IPsec as defined in <xref to="mod-vpnclient"/>,</selectable> <selectable id="TRP1_TLS_IMPLEMENT">TLS as defined in <xref to="tls"/>,</selectable> <selectable id="TRP1_HTTPS_IMPLEMENT">HTTPS in accordance with FCS_HTTPS_EXT.1,</selectable> <selectable id="TRP1_SSH_IMPLEMENT">SSH as defined in <xref to="ssh"/></selectable> </selectables></h:b></selectable></selectables> <h:b>to</h:b> provide a communication path between itself <h:b>as a <selectables> <selectable>server</selectable> <selectable>peer</selectable> </selectables></h:b> and [<h:i>remote</h:i>] <h:b>administrators</h:b> that is logically distinct from other communication paths and provides assured identification of its endpoints and protection of the communicated data from [<h:i>modification, disclosure</h:i>].

The TSF shall <selectables> <selectable><h:b>invoke platform-provided functionality</h:b></selectable> <selectable><h:b>implement functionality</h:b></selectable> </selectables> <h:b>to</h:b> permit [<h:i>remote <h:b>administrators</h:b></h:i>] to initiate communication via the trusted path.

The TSF shall require the use of the trusted path for [<h:i>initial <h:b>administrator</h:b> authentication, [remote administration]</h:i>]. For this particular use, only IPsec, TLS, DTLS, or HTTPS is permitted. Where X.509 validation is needed (e.g., if the TOE acts as a TLS server supporting mutual authentication), must be claimed. To distinguish X.509 validation for external communications from validation for internal communications (e.g., communication with a remote administrator versus communication between TOE components), FIA_X509_EXT.1 from must be included in the ST and iterated as "FIA_X509_EXT.1/External" per the guidance in . If the ST author selects that the TSF implements "IPsec as defined in ," the TSF must claim conformance to a PP-Configuration that includes the VPN Client PP-Module. If the ST author selects that the TSF implements "SSH as defined in ," the TSF must be validated against . If the ST author selects that the TSF implements "mutually authenticated TLS as defined in ," the TSF must be validated against requirements from , with the following selections made: FCS_TLS_EXT.1: TLS must be selected Server must be selected FCS_TLSS_EXT.1.1: The ciphersuites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1. Protocol, DRBG, Certificate validation, algorithm, and similar services may be met with platform-provided services. If HTTPS is selected, FCS_HTTPS_EXT.1 must be included in the ST. FCS_HTTPS_EXT.1 includes selections for both TSF and platform-provided HTTPS functionality, so this must be claimed if either of the HTTPS selections above are made. FCS_HTTPS_EXT.1 includes selections for both TSF and platform-provided HTTPS functionality, so this must be claimed if either of the HTTPS selections above are made. The evaluator shall examine the TSS to determine that the methods of remote TOE administration are indicated, along with how those communications are protected. The evaluator shall also confirm that all protocols listed in the TSS in support of TOE administration are consistent with those specified in the requirement, and are included in the requirements in the ST. If "invoke platform-provided functionality" is selected, the evaluator shall examine the TSS to verify that it describes (for each supported platform) how this functionality is invoked (it should be noted that this may be through a mechanism that is not implemented by the MDM server; nonetheless, that mechanism will be identified in the TSS as part of this evaluation activity). The evaluator shall confirm that the operational guidance contains instructions for establishing the remote administrative sessions for each supported method. The evaluator shall also perform the following tests: The evaluator shall ensure that communications using each specified (in the operational guidance) remote administration method is tested during the course of the evaluation, setting up the connections as described in the operational guidance and ensuring that communication is successful. For each method of remote administration supported, the evaluator shall follow the operational guidance to ensure that there is no available interface that can be used by a remote user to establish remote administrative sessions without invoking the trusted path. The evaluator shall ensure, for each method of remote administration, the channel data is not sent in plaintext. Further evaluation activities are associated with the specific protocols.

Initiation and termination of the trusted channel

Trusted channel protocol

Identity of administrator

The Security Objectives for the TOE 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 (AAs) 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 and 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 assurance 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) 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. In addition, there may be Evaluation Activities specified within and relevant appendices that call for necessary descriptions to be included in the TSS that are specific to the TOE technology type.

The TOE summary specification shall describe how the TOE meets each SFR.

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 (e.g., Entropy Essay). The functional specification describes the Target Security Functions Interfaces (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. 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 and AGD_PRE documentation. The developer may reference a website accessible to application developers and the evaluator. 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 Section 5 and the relevant appendices, 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 must also be 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 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 TOE (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 will be verified by the evaluation activities in Sections 4.2, 4.3, and 4.4, and evaluation of the TOE according to the CEM. The following additional information is also required. If cryptographic functions are provided by the TOE, 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 - this may be done by the TOE or the underlying platform. 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 or 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. It is recognized that the application of these requirements will vary depending on aspects such as whether the TOE is delivered in an operational state, or whether it has to be installed at the TOE owner's site, etc. It might also be the case that no installation is necessary, for example as a Software as a Service implementation in a Cloud environment. In this case it may be inappropriate to require and analyze installation procedures and thus this requirement is implicitly satisfied.

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 TOE 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's 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 its 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 and version number) that specifically identifies the version that meets the requirements of the ST. Further, the evaluator shall check the operational 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 website advertising the TOE, the evaluator shall examine the information on the website 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. In cases where the MDM software is Software as a Service, running in a cloud environment where they have little to no control of the operating system and underlying hardware, the evaluated configuration is considered a snapshot of the MDM software with the OS or VM versions used at the time of testing. 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 operational 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 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 inquiries 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.