# Mobile Device Fundamentals

Version: 3.1

2017-06-16

National Information Assurance Partnership

## Revision History

VersionDateComment
1.02013-10-21Initial Release
1.12014-01-12Typographical changes and additional clarifications in application notes. Removed assignment from FCS_TLS_EXT.1 and limited testing to those ciphersuites in both FCS_TLS_EXT.1 and FCS_TLS_EXT.2.
2.02015-09-14 Included changes based on Technical Rapid Response Team Decisions. Clarified many requirements and assurance activities. Mandated objective requirements:
• Application Access Control (FDP_ACF_EXT.1.2)
• VPN Information Flow Control (FDP_IFC_EXT.1)
• Suite B cryptography for IEEE 802.11
• Certificate enrollment
• Protection of additional key material types
• Heap overflow protection
• Bluetooth requirements
• Cryptographic operation services for applications
• Remote Attestation (FPT_NOT_EXT.1)
Added transition dates for some objective requirements.
Included hardware-isolated REK and key storage selections.
Allowed key derivation by REK.
Mandated HTTPS and TLS for application use. (FDP_UPC_EXT.1)
Removed Dual_EC_DRBG as an approved DRBG.
Mandated TSF Wipe upon authentication failure limit and required number of authentication failures be maintained across reboot.
Clarified Management Class.
Included more domain isolation discussion and tests.
Updated Audit requirements and added Auditable Events table.
Updated Use Case Templates.
Moved Glossary to Introduction.
3.02015-09-17Included changes based on Technical Rapid Response Team Decisions.
Clarified many requirements and assurance activities.
Mandated objective requirements:
• Generation of Audit Records (FAU_GEN.1)
• Audit Storage Protection (FAU_STG.1)
• Audit Storage Overwrite (FAU_STG.4)
• Lock Screen DAR (FDP_DAR_EXT.2)
• Discard Bluetooth Connection Attempts from Bluetooth Addresses with Existing Connection (FIA_BLT_EXT.3)
• JTAG Disablement (FPT_JTA)
• Application Backup
• Biometric Authentication Factor
• Access Control
• User Authentication
• Bluetooth Encryption
WLAN client requirements moved to Extended Package for WLAN Client.
Added SFRs to support BYOD Use Case
BYOD Use Case
Updated key destruction SFR
3.12017-04-05 Included changes based on Technical Rapid Response Team Decisions and incorporated Technical Decisions.
Modified biometric requirements:
• FIA_UAU.5 - Added iris, face, voice and vein as supported modalities, in addition to fingerprint (allowed in version 3)
• FIA_BMG_EXT.1.1 - Clarified AA to specify that vendor evidence is acceptable and expectations of evidence provided.
• FIA_BMG_EXT.1.2 - SAFAR was changed to an assignment of a SAFAR no greater than 1:500.
• FIA_AFL_EXT.1 - Updated to allow each biometric modality to utilize an individual or shared counter.
FCS_TLSC_EXT.1.1 - Removed TLS ciphersuites that utilized SHA1 and updated optional ciphersuites to be uniformed across PPs.
FCS_STG_EXT.2.2 - Modified to require long term trusted channel key material be encrypted by an approved method.
FIA_UAU_EXT.1.1 - Modified to allow the long term trusted channel key material to be available prior to password being entered at start-up.
3.22019-03-01Removed TLS SFRs and utilized TLS Functional Package
Removed Bluetooth SFRs and utilized Bluetooth Module

# 1 Introduction

## 1.1 Objectives of Document

This document presents the Common Criteria (CC) Protection Profile (PP) to express the fundamental security and evaluation requirements for a Mobile Device.

## 1.2 Scope of Document

The scope of the Protection Profile within the development and evaluation process is described in the Common Criteria for Information Technology Security Evaluation [CC]. In particular, a PP defines the IT security requirements of a generic type of TOE and specifies the functional and assurance security measures to be offered by that TOE to meet stated requirements [CC].

The target audiences of this PP are Mobile Device developers, CC consumers, evaluators and schemes.

## 1.4 Terms

The following sections list Common Criteria and technology terms used in this document.

### 1.4.1 Common Criteria Terms

 Common Criteria (CC) Common Criteria for Information Technology Security Evaluation (International Standard ISO/IEC 15408). Common Criteria Testing Laboratory Within the context of the Common Criteria Evaluation and Validation Scheme (CCEVS), an IT security evaluation facility, accredited by the National Voluntary Laboratory Accreditation Program (NVLAP) and approved by the NIAP Validation Body to conduct Common Criteria-based evaluations. Common Evaluation Methodology (CEM) Common Evaluation Methodology for Information Technology Security Evaluation. Module (Module) An implementation-independent set of security requirements for a specific subset of products described by a PP. Protection Profile (PP) An implementation-independent set of security requirements for a category of products. Security Assurance Requirement (SAR) A requirement for how the TOE's proper implementation of the SFR's is verified by an evaluator. Security Functional Requirement (SFR) A requirement for security enforcement by the TOE. Security Target (ST) A set of implementation-dependent security requirements for a specific product. Target of Evaluation (TOE) The product under evaluation. TOE Security Functionality (TSF) The security functionality of the product under evaluation. TOE Summary Specification (TSS) A description of how a TOE satisfies the SFRs in an ST. TSF Data Data for the operation of the TSF that is used to enforce its security requirements.

## 1.5 TOE Overview

This assurance standard specifies information security requirements for Mobile Devices for use in an enterprise. A Mobile Device in the context of this assurance standard is a device, which is composed of a hardware platform and its system software. The device typically provides wireless connectivity and may include software for functions like secure messaging, email, web, VPN connection, and VoIP (Voice over IP), for access to the protected enterprise network, enterprise data and applications, and for communicating to other Mobile Devices.

Figure 1 illustrates the network operating environment of the Mobile Device.

Examples of a "Mobile Device" that should claim conformance to this Protection Profile include smartphones, tablet computers, and other Mobile Devices with similar capabilities.

The Mobile Device provides essential services, such as cryptographic services, data-at-rest protection, and key storage services to support the secure operation of applications on the device. Additional security features such as security policy enforcement, application mandatory access control, anti-exploitation features, user authentication, and software integrity protection are implemented in order to address threats.

This assurance standard describes these essential security services provided by the Mobile Device and serves as a foundation for a secure mobile architecture. The wireless connectivity shall be validated against the Extended Package for WLAN Client. As illustrated in Figure 2, it is expected that a typical deployment would also include either third-party or bundled components. Whether these components are bundled as part of the Mobile Device by the manufacturer or developed by a third-party, they must be separately validated against the related assurance standards such as the Extended Package for Mobile Device Management Agents, Extended Package for IPsec VPN Client, and VoIP Application Extended Package. It is the responsibility of the architect of the overall secure mobile architecture to ensure validation of these components. Additional applications that may come pre-installed on the Mobile Device that are not validated are considered to be potentially flawed, but not malicious. Examples include email client and web browser.

## 1.6 TOE Usage

The Mobile Device may be operated in a number of use cases. Appendix F - Use Case Templates provides use case templates that list those selections, assignments, and objective requirements that best support the use cases identified by this Protection Profile. In addition to providing essential security services, the Mobile Device includes the necessary security functionality to support configurations for these various use cases. Each use case may require additional configuration and applications to achieve the desired security. A selection of these use cases is elaborated below.

Several of the use case templates include objective requirements that are strongly desired for the indicated use cases. Readers can expect those requirements to be made mandatory in the next revision of this protection profile, and industry should aim to include that security functionality in products in the near-term.

As of publication of this version of the Protection Profile, meeting the requirements in Section 5 Security Requirements is necessary for all use cases.

[USE CASE 1] Enterprise-owned device for general-purpose enterprise use and limited personal use

An enterprise-owned device for general-purpose business use is commonly called Corporately Owned, Personally Enabled (COPE). This use case entails a significant degree of enterprise control over configuration and, possibly, software inventory. The enterprise elects to provide users with Mobile Devices and additional applications (such as VPN or email clients) in order to maintain control of their Enterprise data and security of their networks. Users may use Internet connectivity to browse the web or access corporate mail or run enterprise applications, but this connectivity may be under significant control of the enterprise.

[USE CASE 2] Enterprise-owned device for specialized, high-security use

An enterprise-owned device with intentionally limited network connectivity, tightly controlled configuration, and limited software inventory is appropriate for specialized, high-security use cases. For example, the device may not be permitted connectivity to any external peripherals. It may only be able to communicate via its Wi-Fi or cellular radios with the enterprise-run network, which may not even permit connectivity to the Internet. Use of the device may entail compliance with policies that are more restrictive than those in any general-purpose use case, yet may mitigate risks to highly sensitive information. As in the previous case, the enterprise will look for additional applications providing enterprise connectivity and services to have a similar level of assurance as the platform.

[USE CASE 3] Personally-owned device for personal and enterprise use

A personally-owned device, which is used, for both personal activities and enterprise data is commonly called Bring Your Own Device (BYOD). The device may be provisioned for access to enterprise resources after significant personal usage has occurred. Unlike in the enterprise-owned cases, the enterprise is limited in what security policies it can enforce because the user purchased the device primarily for personal use and is unlikely to accept policies that limit the functionality of the device. However, because the enterprise allows the user full (or nearly full) access to the enterprise network, the enterprise will require their own security controls to ensure that enterprise resources are protected from potential threats posed by the personal activities on the device. These controls could potentially be enforced by a separation mechanism built-in to the device itself to distinguish between enterprise and personal activities, or by a third-party application that provides access to enterprise resources and leverages security capabilities provided by the mobile device. Based upon the operational environment and the acceptable risk level of the enterprise, those security functional requirements outlined in Section 5 Security Requirements of this PP along with the selections in the Use Case 3 template defined in Appendix F - Use Case Templates are sufficient for the secure implementation of this BYOD use case.

[USE CASE 4] Personally-owned device for personal and limited enterprise use

A personally-owned device, which is used, for both personal activities and enterprise data is commonly called Bring Your Own Device (BYOD). This device may be provisioned for limited access to enterprise resources such as enterprise email. Because the user does not have full access to the enterprise or enterprise data, the enterprise may not need to enforce any security policies on the device. However, the enterprise may want secure email and web browsing with assurance that the services being provided to those clients by the Mobile Device are not compromised. Based upon the operational environment and the acceptable risk level of the enterprise, those security functional requirements outlined in Section 5 Security Requirements of this PP are sufficient for the secure implementation of this BYOD use case.

# 2 Conformance Claims

An ST must claim exact conformance to this PP, as defined in the CC and CEM addenda for Exact Conformance, Selection-Based SFRs, and Optional SFRs (dated May 2017).
This PP is conformant to Parts 2 (extended) and 3 (conformant) of Common Criteria Version 3.1, Revision 5.
This PP does not claim conformance to any Protection Profile.
This PP is TLS Package Conformant.

# 3 Security Problem Definition

## 3.1 Threats

Mobile devices are subject to the threats of traditional computer systems along with those entailed by their mobile nature. The threats considered in this Protection Profile are those of network eavesdropping, network attacks, physical access, malicious or flawed applications, persistent presence, backup, biometric impersonation, revocation of biometric credentials, and revocation of biometric template as detailed in the following sections.
T.EAVESDROP
Network Eavesdropping

An attacker is positioned on a wireless communications channel or elsewhere on the network infrastructure. Attackers may monitor and gain access to data exchanged between the Mobile Device and other endpoints.
T.NETWORK
Network Attack

An attacker is positioned on a wireless communications channel or elsewhere on the network infrastructure. Attackers may initiate communications with the Mobile Device or alter communications between the Mobile Device and other endpoints in order to compromise the Mobile Device. These attacks include malicious software update of any applications or system software on the device. These attacks also include malicious web pages or email attachments, which are usually delivered to devices over the network.
T.PHYSICAL
Physical Access

An attacker, with physical access, may attempt to access user data on the Mobile Device including credentials. These physical access threats may involve attacks, which attempt to access the device through external hardware ports, impersonate the user authentication mechanisms, through its user interface, and also through direct and possibly destructive access to its storage media. Note: Defending against device re-use after physical compromise is out of scope for this protection profile.
T.FLAWAPP
Malicious or Flawed Application

Applications loaded onto the Mobile Device may include malicious or exploitable code. This code could be included intentionally or unknowingly by the developer, perhaps as part of a software library. Malicious apps may attempt to exfiltrate data to which they have access. They may also conduct attacks against the platform’s system software, which will provide them with additional privileges and the ability to conduct further malicious activities. Malicious applications may be able to control the device's sensors (GPS, camera, microphone) to gather intelligence about the user's surroundings even when those activities do not involve data resident or transmitted from the device. Flawed applications may give an attacker access to perform network-based or physical attacks that otherwise would have been prevented
T.PERSISTENT
Persistent Presence

Persistent presence on a device by an attacker implies that the device has lost integrity and cannot regain it. The device has likely lost this integrity due to some other threat vector, yet the continued access by an attacker constitutes an on-going threat in itself. In this case, the device and its data may be controlled by an adversary as well as by its legitimate owner.

## 3.2 Assumptions

The specific conditions listed below are assumed to exist in the TOE’s Operational Environment. These include both practical realities in the development of the TOE security requirements and the essential environmental conditions on the use of the TOE.
A.CONFIG
It is assumed that the TOE’s security functions are configured correctly in a manner to ensure that the TOE security policies will be enforced on all applicable network traffic flowing among the attached networks.
A.NOTIFY
It is assumed that the mobile user will immediately notify the administrator if the Mobile Device is lost or stolen.
A.PRECAUTION
It is assumed that the mobile user exercises precautions to reduce the risk of loss or theft of the Mobile Device.
A.PROPER_USER
Mobile device users are not willfully negligent or hostile, and use the device within compliance of a reasonable Enterprise security policy.

## 3.3 Organizational Security Policy

There are no OSPs for the Mobile Device.

# 4 Security Objectives

## 4.1 Security Objectives for the TOE

The security objectives for the Mobile Device are defined as follows.
O.COMMS
Protected Communications

To address the network eavesdropping (T.EAVESDROP) and network attack (T.NETWORK) threats described in Section 3.1 Threats, concerning wireless transmission of Enterprise and user data and configuration data between the TOE and remote network entities, conformant TOEs will use a trusted communication path. The TOE will be capable of communicating using one (or more) of these standard protocols: IPsec, DTLS, TLS, HTTPS, or Bluetooth. The protocols are specified by RFCs that offer a variety of implementation choices. Requirements have been imposed on some of these choices (particularly those for cryptographic primitives) to provide interoperability and resistance to cryptographic attack.

While conformant TOEs must support all of the choices specified in the ST including any optional SFRs defined in this PP, they may support additional algorithms and protocols. If such additional mechanisms are not evaluated, guidance must be given to the administrator to make clear the fact that they were not evaluated.

Addressed by: , , , FCS_CKM_EXT.8, , , , , , FCS_DTLS_EXT.1, , , , , , , FCS_TLSC_EXT.1, FCS_TLSC_EXT.2, FCS_TLSC_EXT.3, FDP_BLT_EXT.1, , , , FIA_BLT_EXT.1, FIA_BLT_EXT.2, FIA_BLT_EXT.3, FIA_BLT_EXT.4, FIA_BLT_EXT.5, FIA_BLT_EXT.6, , , , , , , FTP_BLT_EXT.1, FTP_BLT_EXT.2,
O.STORAGE
Protected Storage

To address the issue of loss of confidentiality of user data in the event of loss of a Mobile Device (T.PHYSICAL), conformant TOEs will use data-at-rest protection. The TOE will be capable of encrypting data and keys stored on the device and will prevent unauthorized access to encrypted data.

O.CONFIG
Mobile Device Configuration

To ensure a Mobile Device protects user and enterprise data that it may store or process, conformant TOEs will provide the capability to configure and apply security policies defined by the user and the Enterprise Administrator. If Enterprise security policies are configured these must be applied in precedence of user specified security policies.

O.AUTH
Authorization and Authentication

To address the issue of loss of confidentiality of user data in the event of loss of a Mobile Device (T.PHYSICAL), users are required to enter an authentication factor to the device prior to accessing protected functionality and data. Some non-sensitive functionality (e.g., emergency calling, text notification) can be accessed prior to entering the authentication factor. The device will automatically lock following a configured period of inactivity in an attempt to ensure authorization will be required in the event of the device being lost or stolen.

Authentication of the endpoints of a trusted communication path is required for network access to ensure attacks are unable to establish unauthorized network connections to undermine the integrity of the device.

Repeated attempts by a user to authorize to the TSF will be limited or throttled to enforce a delay between unsuccessful attempts.

O.INTEGRITY
Mobile Device Integrity

To ensure the integrity of the Mobile Device is maintained conformant TOEs will perform self-tests to ensure the integrity of critical functionality, software/firmware and data has been maintained. The user shall be notified of any failure of these self-tests. This will protect against the threat T.PERSISTENT.

To address the issue of an application containing malicious or flawed code (T.FLAWAPP), the integrity of downloaded updates to software/firmware will be verified prior to installation/execution of the object on the Mobile Device. In addition, the TOE will restrict applications to only have access to the system services and data they are permitted to interact with. The TOE will further protect against malicious applications from gaining access to data they are not authorized to access by randomizing the memory layout.

O.PRIVACY
End User Privacy and Device Functionality

In a BYOD environment (use cases 3 and 4), a personally-owned mobile device is used for both personal activities and enterprise data. Enterprise management solutions may have the technical capability to monitor and enforce security policies on the device. However, the privacy of the personal activities and data must be ensured. In addition, since there are limited controls that the enterprise can enforce on the personal side, separation of personal and enterprise data is needed. This will protect against the T.FLAWAPP and T.PERSISTENT threats.

## 4.2 Security Objectives for the Operational Environment

The following security objectives for the operational environment assist the OS in correctly providing its security functionality. These track with the assumptions about the environment.
OE.CONFIG
administrators will configure the Mobile Device security functions correctly to create the intended security policy
OE.NOTIFY
The Mobile User will immediately notify the administrator if the Mobile Device is lost or stolen.
OE.PRECAUTION
The Mobile User exercises precautions to reduce the risk of loss or theft of the Mobile Device.

## 4.3 Security Objectives Rationale

This section describes how the assumptions, threats, and organization security policies map to the security objectives.
 Threat, Assumption, or OSP Security Objectives Rationale T.EAVESDROP O.COMMS, O.CONFIG, O.AUTH The threat T.EAVESDROP is countered by O.COMMS as this provides the capability to communicate using one (or more) standard protocols as a means to maintain the confidentiality of data that are transmitted outside of the TOE.The threat T.EAVESDROP is countered by O.CONFIG as this provides a secure configuration of the mobile device to protect data that it processes.The threat T.EAVESDROP is countered by O.AUTH as this provides authentication of the endpoints of a trusted communication path. T.NETWORK O.COMMS, O.CONFIG, O.AUTH The threat T.NETWORK is countered by O.COMMS as this provides the capability to communicate using one (or more) standard protocols as a means to maintain the confidentiality of data that are transmitted outside of the TOE.The threat T.NETWORK is countered by O.CONFIG as this provides a secure configuration of the mobile device to protect data that it processes.The threat T.NETWORK is countered by O.AUTH as this provides authentication of the endpoints of a trusted communication path. T.PHYSICAL O.STORAGE, O.AUTH The threat T.PHYSICAL is countered by O.STORAGE as this provides the capability to encrypt all user and enterprise data and authentication keys to ensure the confidentiality of data that it stores.The threat T.PHYSICAL is countered by O.AUTH as this provides the capability to authenticate the user prior to accessing protected functionality and data. T.FLAWAPP O.COMMS, O.CONFIG, O.AUTH, O.INTEGRITY, O.PRIVACY The threat T.FLAWAPP is countered by O.COMMS as this provides the capability to communicate using one (or more) standard protocols as a means to maintain the confidentiality of data that are transmitted outside of the TOE.The threat T.FLAWAPP is countered by O.CONFIG as this provides the capability to configure and apply security policies to ensure the Mobile Device can protect user and enterprise data that it may store or process.The threat T.FLAWAPP is countered by O.AUTH as this provides the capability to authenticate the user and endpoints of a trusted path to ensure they are communicating with an authorized entity with appropriate privileges.The threat T.FLAWAPP is countered by O.INTEGRITY as this provides the capability to perform self-tests to ensure the integrity of critical functionality, software/firmware and data has been maintained.The threat T.FLAWAPP is countered by O.PRIVACY as this provides separation and privacy between user activities. T.PERSISTENT O.INTEGRITY, O.PRIVACY The threat T.PERSISTENT is countered by O.INTEGRITY as this provides the capability to perform self-tests to ensure the integrity of critical functionality, software/firmware and data has been maintained.The threat T.PERSISTENT is countered by O.PRIVACY as this provides separation and privacy between user activities. A.CONFIG OE.CONFIG The operational environment objective OE.CONFIG is realized through A.CONFIG. A.NOTIFY OE.NOTIFY The operational environment objective OE.NOTIFY is realized through A.NOTIFY. A.PRECAUTION OE.PRECAUTION The operational environment objective OE.PRECAUTION is realized through A.PRECAUTION. A.PROPER_USER OE.DATA_PROPER_USER The operational environment objective OE.DATA_PROPER_USER is realized through A.PROPER_USER.

# 5 Security Requirements

## 5.1 Security Fundamental Requirements

The individual security functional requirements are specified in the sections below.

The following conventions are used for the completion of operations:
• [Italicized text within square brackets] indicates an operation to be completed by the ST author
• Underlined text indicates additional text provided as a refinement.
• [Bold and italicized text within square brackets] indicates the completion of an assignment.
• [Italicized text within square brackets] indicates the completion of a selection.
• Number in parentheses after SFR name, e.g. (1), indicates the completion of a iteration.

### 5.1.1 Class: Security Audit (FAU)

#### FAU_GEN.1 Audit Data Generation

The TSF shall be able to generate an audit record of the following auditable events:
1. Start-up and shutdown of the audit functions
2. All auditable events for the [not selected] level of audit
4. Start-up and shutdown of the Rich OS
5. Insertion or removal of removable media
6. Specifically defined auditable events in Table 1
7. [selection: Audit records reaching [assignment: integer value less than 100] percentage of audit capacity, [assignment: other auditable events derived from this profile]]
8. [selection: Specifically defined auditable event in Table 2, no additional auditable events]
Application Note: Administrator actions are defined as functions labeled as mandatory for FMT_MOF_EXT.1.2 (i.e. ‘M-MM’ in Table 6). If the TSF does not support removable media, number 4 is implicitly met.

The TSF shall generate an audit record for all events contained in Table 1. Generating audit records for events in Table 2 is currently objective. It is acceptable to include individual SFRs from Table 2 in the ST, without including the entirety of Table 2.

Table 1 Application Note: FPT_TST_EXT.1 – Audit of self-tests is required only at initial start-up. Since the TOE "transitions to non-operational mode" upon failure of a self-test, per FPT_NOT_EXT.1, this is considered equivalent evidence to an audit record for the failure of a self-test. FDP_DAR_EXT.1 - "None" shall be selected, if the TOE utilizes whole volume encryption for protected memory, since it is not feasible to audit when the encryption/decryption fails. If the TOE utilizes file-based encryption for protected data and audits when this encryption/decryption fails, then that auditable event shall be selected.

Table 2 Application Note: If the audit event for FMT_SMF_EXT.1 is included in the ST, it is acceptable for the initiation of the software update to be audited without indicating the outcome (success or failure) of the update.
The TSF shall record within each audit record at least the following information:
1. Date and time of the event
2. Type of event
3. Subject identity
4. The outcome (success or failure) of the event
5. Additional information in Table 1
Application Note: The subject identity is usually the process name/ID. The event type is often indicated by a severity level, for example, ‘info’, ‘warning’, or ‘error’.

If "no additional auditable events" is selected in the second selection of FAU_GEN.1.1, then "no additional information" shall be selected.

For each audit event selected from Table 2 in FAU_GEN.1.1 if additional information is required to be recorded within the audit record, it should be included in this selection.
TSS
The evaluator shall check the TSS and ensure that it lists all of the auditable events and provides a format for audit records. Each audit record format type must be covered, along with a brief description of each field. The evaluator shall check to make sure that every audit event type mandated by the PP is described and that the description of the fields contains the information required in FAU_GEN.1.2.

The evaluator shall also make a determination of the administrative actions that are relevant in the context of this PP including those listed in the Management section. The evaluator shall examine the administrative guide and make a determination of which administrative commands are related to the configuration (including enabling or disabling) of the mechanisms implemented in the TOE that are necessary to enforce the requirements 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.

Tests
The evaluator shall test the TOE’s ability to correctly generate audit records by having the TOE generate audit records 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 records are generated for the establishment and termination of a channel for each of the cryptographic protocols contained in the ST. For administrative actions, the evaluator shall test that each action determined by the evaluator above to be security relevant in the context of this PP is auditable. When verifying the test results, the evaluator shall ensure the audit records generated during testing match the format specified in the administrative guide, and that the fields specified in FAU_GEN.1.2 are contained in each audit record.

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 records are generated as expected.

Table 1: Mandatory Auditable Events
 Requirement Auditable Events Additional Audit Record Contents FAU_GEN.1 None. FAU_STG.1 None. FAU_STG.4 None. FCS_CKM_EXT.1 [selection: generation of a REK, None]. No additional information. FCS_CKM_EXT.2 None. FCS_CKM_EXT.3 None. FCS_CKM_EXT.4 None. FCS_CKM_EXT.5 [selection: Failure of the wipe, None]. No additional information. FCS_CKM_EXT.6 None. FCS_CKM.1 [selection: Failure of key generation activity for authentication keys, None]. No additional information. FCS_CKM.2(*) None. FCS_COP.1(*) None. FCS_IV_EXT.1 None. FCS_SRV_EXT.1 None. FCS_STG_EXT.1 Import or destruction of key. Identity of key. Role and identity of requestor. [selection: Exceptions to use and destruction rules, No other events] FCS_STG_EXT.2 None. FCS_STG_EXT.3 Failure to verify integrity of stored key. Identity of key being verified. FDP_DAR_EXT.1 [selection: Failure to encrypt/decrypt data, None]. No additional information. FDP_DAR_EXT.2 Failure to encrypt/decrypt data. No additional information. FDP_IFC_EXT.1 None. FDP_STG_EXT.1 Addition or removal of certificate from Trust Anchor Database. Subject name of certificate. FIA_PMG_EXT.1 None. FIA_TRT_EXT.1 None. FIA_UAU_EXT.1 None. FIA_UAU.5 None. FIA_UAU.7 None. FIA_X509_EXT.1 Failure to validate X.509v3 certificate. Reason for failure of validation. FMT_MOF_EXT.1 None. FPT_AEX_EXT.1 None. FPT_AEX_EXT.2 None. FPT_AEX_EXT.3 None. FPT_JTA_EXT.1 None. FPT_KST_EXT.1 None. FPT_KST_EXT.2 None. FPT_KST_EXT.3 None. FPT_NOT_EXT.1 [selection: Measurement of TSF software, None]. [selection: Integrity verification value, No additional information]. FPT_STM.1 None. FPT_TST_EXT.1 Initiation of self-test. [selection: Algorithm that caused the failure, none] Failure of self-test. FPT_TST_EXT.2(1) Start-up of TOE. No additional information. [selection: Detected integrity violation, none] [selection: The TSF code file that caused the integrity violation, No additional information] FPT_TUD_EXT.1 None. FTA_SSL_EXT.1 None.

#### FAU_STG.1 Audit Storage Protection

The TSF shall protect the stored audit records in the audit trail from unauthorized deletion.
The TSF shall be able to prevent unauthorized modifications to the stored audit records in the audit trail.
TSS
The evaluator shall ensure that the TSS lists the location of all logs and the access controls of those files such that unauthorized modification and deletion are prevented.
Tests
• Test 1: The evaluator shall attempt to delete the audit trail in a manner that the access controls should prevent (as an unauthorized user) and shall verify that the attempt fails.
• Test 2: The evaluator shall attempt to modify the audit trail in a manner that the access controls should prevent (as an unauthorized application) and shall verify that the attempt fails.

#### FAU_STG.4 Prevention of Audit Data Loss

The TSF shall overwrite the oldest stored audit records if the audit trail is full.
TSS
The evaluator shall examine the TSS to ensure that it describes the size limits on the audit records, the detection of a full audit trail, and the action(s) taken by the TSF when the audit trail is full. The evaluator shall ensure that the action(s) results in the deletion or overwrite of the oldest stored record.

### 5.1.2 Class: Cryptographic Support (FCS)

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

#### FCS_CKM.1 Cryptographic key generation

The TSF shall generate asymmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm [selection:
• RSA schemes using cryptographic key sizes of 2048-bit or greater that meet FIPS PUB 186-4, "Digital Signature Standard (DSS)", Appendix B.3,
• ECC schemes using [selection:
• "NIST curves" P-384 and [selection: P-256, P-521, no other curves] that meet the following: FIPS PUB 186-4, "Digital Signature Standard (DSS)", Appendix B.4,
• Curve25519 schemes that meet the following: RFC 7748
]
,
• FFC schemes using [selection:
• cryptographic key sizes of 2048-bit or greater that meet the following: FIPS PUB 186-4, "Digital Signature Standard (DSS)", Appendix B.1,
• Diffie-Hellman group 14 that meet the following: RFC3526, Section 3,
• "safe-prime" groups that meet the following: 'NIST Special Publication 800-56A Revision 3, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography"', and [selection: RFC 3526, RFC 7919]
]
].
Application Note: The ST author shall select all key generation schemes used for key establishment and entity authentication. When key generation is used for key establishment, the schemes in FCS_CKM.2.1(1) and selected cryptographic protocols must match the selection. When key generation is used for entity authentication, the public key may be associated with an X.509v3 certificate.

If the TOE acts as a receiver in the RSA key establishment scheme, the TOE does not need to implement RSA key generation.

Curve25519 can only be used for ECDH and in conjunction with FDP_DAR_EXT.2.2.
TSS
The evaluator shall ensure that the TSS identifies the key sizes supported by the TOE. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify that it identifies the usage for each scheme.

Guidance
The evaluator shall verify that the AGD guidance instructs the administrator how to configure the TOE to use the selected key generation scheme(s) and key size(s) for all uses defined in this PP.

Assurance Activity Note: The following tests require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products.

Tests
Key Generation for FIPS PUB 186-4 RSA Schemes

The evaluator shall verify the implementation of RSA Key Generation by the TOE using the Key Generation test. This test verifies the ability of the TSF to correctly produce values for the 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.

Key Pair generation specifies 5 ways (or methods) to generate the primes p and q. These include:
1. Random Primes:
• Provable primes
• Probable primes
2. Primes with Conditions:
• Primes p1, p2, q1,q2, p and q shall all be provable primes
• Primes p1, p2, q1, and q2 shall be provable primes and p and q shall be probable primes
• Primes p1, p2, q1,q2, p and q shall all be probable primes
To test the key generation method for the Random Provable primes method and for all the Primes with Conditions methods, the evaluator must seed the TSF key generation routine with sufficient data to deterministically generate the RSA key pair. This includes the random seed(s), the public exponent of the RSA key, and the desired key length. For each key length supported, 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 from a known good implementation.

If possible, the Random Probable primes method should also be verified against a known good implementation as described above. Otherwise, the evaluator shall have the TSF generate 10 keys pairs for each supported key length nlen and verify:
• n = p*q
• p and q are probably prime according to Miller-Rabin tests
• GCD(p-1,e) = 1
• GCD(q-1,e) = 1
• 2^16 < e < 2^256 and e is an odd integer
• |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)

Key Generation for FIPS 186-4 Elliptic Curve Cryptography (ECC)
FIPS 186-4 ECC Key Generation Test

For each supported NIST curve, i.e. P-256, P-384 and P-521, the evaluator shall require the implementation under test (IUT) to generate 10 private/public key pairs. The private key shall be generated using an approved random bit generator (RBG). To determine correctness, the evaluator shall submit the generated key pairs to the public key verification (PKV) function of a known good implementation.

FIPS 186-4 Public Key Verification (PKV) Test

For each supported NIST curve, i.e. P-256, P-384 and P-521, the evaluator shall generate 10 private/public key pairs using the key generation function of a known good implementation and modify five of the public key values so that they are incorrect, leaving five values unchanged (i.e. correct). The evaluator shall obtain in response a set of 10 PASS/FAIL values.

Key Generation for Curve25519

The evaluator shall require the implementation under test (IUT) to generate 10 private/public key pairs. The private key shall be generated as specified in RFC 7748 using an approved random bit generator (RBG). To determine correctness, the evaluator shall submit the generated key pairs to the public key verification (PKV) function of a known good implementation.

Note: Assuming the PKV function of the good implementation will:
1. confirm the private and public keys are 32-byte values
2. confirm the three least significant bits of the most significant byte of the private key are zero
3. confirm the most significant bit of the least significant byte is zero
4. confirm the second most significant bit of the most significant byte is one
5. calculate the expected public key from the private key and confirm it matches the supplied public key

The evaluator shall generate 10 private/public key pairs using the key generation function of a known good implementation and modify 5 of the public key values so that they are incorrect, leaving five values unchanged (i.e. correct). The evaluator shall obtain in response a set of 10 PASS/FAIL values.

Key Generation for Finite-Field Cryptography (FFC)
The evaluator shall verify the implementation of the Parameters Generation and the Key Generation for FFC by the TOE using the Parameter Generation and Key Generation test. This test verifies the ability of the TSF to correctly produce values for the field prime p, the cryptographic prime q (dividing p-1), the cryptographic group generator g, and the calculation of the private key x and public key y.
The Parameter generation specifies 2 ways (or methods) to generate the cryptographic prime q and the field prime p:

Cryptographic and Field Primes:

• Primes q and p shall both be provable primes
• Primes q and field prime p shall both be probable primes
and two ways to generate the cryptographic group generator g:

Cryptographic Group Generator:

• Generator g constructed through a verifiable process
• Generator g constructed through an unverifiable process
The Key generation specifies 2 ways to generate the private key x:

Private Key:

• len(q) bit output of RBG where 1 <= x <= q-1
• len(q) + 64 bit output of RBG, followed by a mod q-1 operation where 1<= x<=q-1
The security strength of the RBG must be at least that of the security offered by the FFC parameter set.

To test the cryptographic and field prime generation method for the provable primes method and/or the group generator g for a verifiable process, the evaluator must seed the TSF parameter generation routine with sufficient data to deterministically generate the parameter set.

For each key length supported, the evaluator shall have the TSF generate 25 parameter sets and key pairs. The evaluator shall verify the correctness of the TSF’s implementation by comparing values generated by the TSF with those generated from a known good implementation. Verification must also confirm
• g != 0,1
• q divides p-1
• g^q mod p = 1
• g^x mod p = y

for each FFC parameter set and key pair.

#### Diffie-Hellman Group 14 and FFC Schemes using "safe-prime" groups

Testing for FFC Schemes using Diffie-Hellman group 14 and/or "safe-prime" groups is done as part of testing in FCS_CKM.2.1.

#### FCS_CKM.2(1) Cryptographic key establishment

The TSF shall perform cryptographic key establishment in accordance with a specified cryptographic key establishment method:[selection:
• RSA-based key establishment schemes that meets the following: NIST Special Publication 800-56B, "Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography",
• Elliptic curve-based key establishment schemes that meets the following: NIST Special Publication 800-56A, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography",
• Finite field-based key establishment schemes that meets the following: NIST Special Publication 800-56A, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography",
• No other schemes
].
Application Note: The ST author shall select all key establishment schemes used for the selected cryptographic protocols.

The RSA-based key establishment schemes are described in Section 9 of NIST SP 800-56B; however, Section 9 relies on implementation of other sections in SP 800-56B. If the TOE acts as a receiver in the RSA key establishment scheme, the TOE does not need to implement RSA key generation.

The elliptic curves used for the key establishment scheme shall correlate with the curves specified in FCS_CKM.1.1.

The domain parameters used for the finite field-based key establishment scheme are specified by the key generation according to FCS_CKM.1.1.
TSS
The evaluator shall ensure that the supported key establishment schemes correspond to the key generation schemes identified in FCS_CKM.1.1. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify that it identifies the usage for each scheme.

Guidance
The evaluator shall verify that the AGD guidance instructs the administrator how to configure the TOE to use the selected key establishment scheme(s).

Assurance Activity Note: The following tests require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products.

Tests
Key Establishment Schemes

The evaluator shall verify the implementation of the key establishment schemes supported by the TOE using the applicable tests below.

SP800-56A Key Establishment Schemes

The evaluator shall verify a TOE's implementation of SP800-56A key agreement schemes using the following Function and Validity tests. These validation tests for each key agreement scheme verify that a TOE has implemented the components of the key agreement scheme according to the specifications in the Recommendation. These components include the calculation of the DLC primitives (the shared secret value Z) and the calculation of the derived keying material (DKM) via the Key Derivation Function (KDF). If key confirmation is supported, the evaluator shall also verify that the components of key confirmation have been implemented correctly, using the test procedures described below. This includes the parsing of the DKM, the generation of MACdata and the calculation of MACtag.

Function Test

The Function test verifies the ability of the TOE to implement the key agreement schemes correctly. To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each supported key agreement scheme-key agreement role combination, KDF type, and, if supported, key confirmation role- key confirmation type combination, the tester shall generate 10 sets of test vectors. The data set consists of one set of domain parameter values (FFC) or the NIST approved curve (ECC) per 10 sets of public keys. These keys are static, ephemeral or both depending on the scheme being tested.

The evaluator shall obtain the DKM, the corresponding TOE’s public keys (static and/or ephemeral), the MAC tag(s), and any inputs used in the KDF, such as the Other Information field OI and TOE id fields.

If the TOE does not use a KDF defined in SP 800-56A, the evaluator shall obtain only the public keys and the hashed value of the shared secret.

The evaluator shall verify the correctness of the TSF’s implementation of a given scheme by using a known good implementation to calculate the shared secret value, derive the keying material DKM, and compare hashes or MAC tags generated from these values.

If key confirmation is supported, the TSF shall perform the above for each implemented approved MAC algorithm.

Validity Test

The Validity test verifies the ability of the TOE to recognize another party’s valid and invalid key agreement results with or without key confirmation. To conduct this test, the evaluator shall obtain a list of the supporting cryptographic functions included in the SP800-56A key agreement implementation to determine which errors the TOE should be able to recognize. The evaluator generates a set of 24 (FFC) or 30 (ECC) test vectors consisting of data sets including domain parameter values or NIST approved curves, the evaluator’s public keys, the TOE’s public/private key pairs, MACTag, and any inputs used in the KDF, such as the other info and TOE id fields.

The evaluator shall inject an error in some of the test vectors to test that the TOE recognizes invalid key agreement results caused by the following fields being incorrect: the shared secret value Z, the DKM, the other information field OI, the data to be MACed, or the generated MACTag. If the TOE contains the full or partial (only ECC) public key validation, the evaluator will also individually inject errors in both parties’ static public keys, both parties’ ephemeral public keys and the TOE’s static private key to assure the TOE detects errors in the public key validation function and/or the partial key validation function (in ECC only). At least two of the test vectors shall remain unmodified and therefore should result in valid key agreement results (they should pass).

The TOE shall use these modified test vectors to emulate the key agreement scheme using the corresponding parameters. The evaluator shall compare the TOE’s results with the results using a known good implementation verifying that the TOE detects these errors.

SP800-56B Key Establishment Schemes

The evaluator shall verify that the TSS describes whether the TOE acts as a sender, a recipient, or both for RSA-based key establishment schemes.

If the TOE acts as a sender, the following assurance activity shall be performed to ensure the proper operation of every TOE supported combination of RSA-based key establishment scheme:

To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each combination of supported key establishment scheme and its options (with or without key confirmation if supported, for each supported key confirmation MAC function if key confirmation is supported, and for each supported mask generation function if KTS-OAEP is supported), the tester shall generate 10 sets of test vectors. Each test vector shall include the RSA public key, the plaintext keying material, any additional input parameters if applicable, the MacKey and MacTag if key confirmation is incorporated, and the outputted ciphertext. For each test vector, the evaluator shall perform a key establishment encryption operation on the TOE with the same inputs (in cases where key confirmation is incorporated, the test shall use the MacKey from the test vector instead of the randomly generated MacKey used in normal operation) and ensure that the outputted ciphertext is equivalent to the ciphertext in the test vector.

If the TOE acts as a receiver, the following assurance activities shall be performed to ensure the proper operation of every TOE supported combination of RSA-based key establishment scheme:

To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each combination of supported key establishment scheme and its options (with our without key confirmation if supported, for each supported key confirmation MAC function if key confirmation is supported, and for each supported mask generation function if KTS-OAEP is supported), the tester shall generate 10 sets of test vectors. Each test vector shall include the RSA private key, the plaintext keying material (KeyData), any additional input parameters if applicable, the MacTag in cases where key confirmation is incorporated, and the outputted ciphertext. For each test vector, the evaluator shall perform the key establishment decryption operation on the TOE and ensure that the outputted plaintext keying material (KeyData) is equivalent to the plaintext keying material in the test vector. In cases where key confirmation is incorporated, the evaluator shall perform the key confirmation steps and ensure that the outputted MacTag is equivalent to the MacTag in the test vector.

The evaluator shall ensure that the TSS describes how the TOE handles decryption errors. In accordance with NIST Special Publication 800-56B, the TOE must not reveal the particular error that occurred, either through the contents of any outputted or logged error message or through timing variations. If KTS-OAEP is supported, the evaluator shall create separate contrived ciphertext values that trigger each of the three decryption error checks described in NIST Special Publication 800-56B section 7.2.2.3, ensure that each decryption attempt results in an error, and ensure that any outputted or logged error message is identical for each. If KTS-KEM-KWS is supported, the evaluator shall create separate contrived ciphertext values that trigger each of the three decryption error checks described in NIST Special Publication 800-56B section 7.2.3.3, ensure that each decryption attempt results in an error, and ensure that any outputted or logged error message is identical for each.

#### FCS_CKM.2(2) Cryptographic key establishment (While device is locked)

The TSF shall perform cryptographic key establishment in accordance with a specified cryptographic key establishment method: [selection:
• RSA-based key establishment schemes that meets the following: NIST Special Publication 800-56B, "Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography",
• Elliptic curve-based key establishment schemes that meets the following: [selection:
• NIST Special Publication 800-56A, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography",
• RFC 7748, "Elliptic Curves for Security"
]
,
• Finite field-based key establishment schemes that meets the following: NIST Special Publication 800-56A, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography"
] for the purposes of encrypting sensitive data received while the device is locked.
Application Note: The RSA-based key establishment schemes are described in Section 9 of NIST SP 800-56B; however, Section 9 relies on implementation of other sections in SP 800-56B. If the TOE acts as a receiver in the RSA key establishment scheme, the TOE does not need to implement RSA key generation.

The elliptic curves used for the key establishment scheme shall correlate with the curves specified in FCS_CKM.1.1.

The domain parameters used for the finite field-based key establishment scheme are specified by the key generation according to FCS_CKM.1.1.
Tests
The test for SP800-56A and SP800-56B key establishment schemes is performed in association with FCS_CKM.2.1(1).

Curve25519 Key Establishment Schemes

The evaluator shall verify a TOE's implementation of the key agreement scheme using the following Function and Validity tests. These validation tests for each key agreement scheme verify that a TOE has implemented the components of the key agreement scheme according to the specification. These components include the calculation of the shared secret K and the hash of K.

Function Test

The Function test verifies the ability of the TOE to implement the key agreement schemes correctly. To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each supported key agreement role and hash function combination, the tester shall generate 10 sets of public keys. These keys are static, ephemeral or both depending on the scheme being tested.

The evaluator shall obtain the shared secret value K, and the hash of K.

The evaluator shall verify the correctness of the TSF’s implementation of a given scheme by using a known good implementation to calculate the shared secret value K and compare the hash generated from this value.

Validity Test

The Validity test verifies the ability of the TOE to recognize another party’s valid and invalid key agreement results. To conduct this test, the evaluator generates a set of 30 test vectors consisting of data sets including the evaluator’s public keys and the TOE’s public/private key pairs.

The evaluator shall inject an error in some of the test vectors to test that the TOE recognizes invalid key agreement results caused by the following fields being incorrect: the shared secret value K or the hash of K. At least two of the test vectors shall remain unmodified and therefore should result in valid key agreement results (they should pass).

The TOE shall use these modified test vectors to emulate the key agreement scheme using the corresponding parameters. The evaluator shall compare the TOE’s results with the results using a known good implementation verifying that the TOE detects these errors.

#### FCS_CKM_EXT.1 Extended: Cryptographic Key Support

The TSF shall support [selection: immutable hardware, mutable hardware] REK(s) with a [selection: symmetric, asymmetric] key of strength [selection: 112 bits, 128 bits, 192 bits, 256 bits].
Each REK shall be hardware-isolated from Rich OS on the TSF in runtime.
Each REK shall be generated by a RBG in accordance with FCS_RBG_EXT.1.
Application Note: Either asymmetric or symmetric keys are allowed; the ST author makes the selection appropriate for the device. Symmetric keys must be of size 128 or 256 bits in order to correspond with FCS_COP.1(1). Asymmetric keys may be of any strength corresponding to FCS_CKM.1.

The raw key material of "immutable hardware" REK(s) is computationally processed by hardware and software cannot access the raw key material. Thus if "immutable-hardware" is selected in FCS_CKM_EXT.1.1 it implicitly meets FCS_CKM_EXT.7. If "mutable-hardware" is selected in FCS_CKM_EXT.1.1, FCS_CKM_EXT.7 must be included in the ST.

The lack of a public/documented API for importing or exporting the REK, when a private/undocumented API exists, is not sufficient to meet this requirement.

The RBG used to generate a REK may be a RBG native to the hardware key container or may be an off-device RBG. If performed by an off-device RBG, the device manufacturer shall not be able to access a REK after the manufacturing process has been completed. The assurance activities for these two cases differ.
TSS
The evaluator shall review the TSS to determine that a REK is supported by the TOE, that the TSS includes a description of the protection provided by the TOE for a REK, and that the TSS includes a description of the method of generation of a REK.

The evaluator shall verify that the description of the protection of a REK describes how any reading, import, and export of that REK is prevented. (For example, if the hardware protecting the REK is removable, the description should include how other devices are prevented from reading the REK.) The evaluator shall verify that the TSS describes how encryption/decryption/derivation actions are isolated so as to prevent applications and system-level processes from reading the REK while allowing encryption/decryption/derivation by the key.

The evaluator shall verify that the description includes how the Rich OS is prevented from accessing the memory containing REK key material, which software is allowed access to the REK, how any other software in the execution environment is prevented from reading that key material, and what other mechanisms prevent the REK key material from being written to shared memory locations between the Rich OS and the separate execution environment.

If key derivation is performed using a REK, the evaluator shall ensure that the TSS description includes a description of the key derivation function and shall verify the key derivation uses an approved derivation mode and key expansion algorithm according to FCS_CKM_EXT.3.2.

The evaluator shall verify that the generation of a REK meets the FCS_RBG_EXT.1.1 and FCS_RBG_EXT.1.2 requirements:

• If REK(s) is/are generated on-device, the TSS shall include a description of the generation mechanism including what triggers a generation, how the functionality described by FCS_RBG_EXT.1 is invoked, and whether a separate instance of the RBG is used for REK(s).
• If REK(s) is/are generated off-device, the TSS shall include evidence that the RBG meets FCS_RBG_EXT.1. This will likely necessitate a second set of RBG documentation equivalent to the documentation provided for the RBG assurance activities. In addition, the TSS shall describe the manufacturing process that prevents the device manufacturer from accessing any REK(s).

#### FCS_CKM_EXT.2 Extended: Cryptographic Key Random Generation

All DEKs shall be [selection:
• randomly generated,
• from the combination of a randomly generated DEK with another DEK or salt in a way that preserves the effective entropy of each factor by [selection: using an XOR operation, concatenating the keys and using a KDF (as described in SP 800-108), concatenating the keys and using a KDF (as described in SP 800-56C)]
] with entropy corresponding to the security strength of AES key sizes of [selection: 128, 256] bits.
Application Note: The intent of this requirement is to ensure that the DEK cannot be recovered with less work than a full exhaust of the key space for AES. The key generation capability of the TOE uses a RBG implemented on the TOE device (FCS_RBG_EXT.1). Either 128-bit or 256-bit (or both) are allowed; the ST author makes the selection appropriate for the device. A DEK is used in addition to the KEK so that authentication factors can be changed without having to re-encrypt all of the user data on the device.

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

If combined, the ST author shall describe which method of combination is used in order to justify that the effective entropy of each factor is preserved, and the ST author shall describe that each combined value was originally generated from an Approved DRBG described in FCS_RBG_EXT.1

The documentation of the product's encryption key management should be detailed enough that, after reading, the evaluator will thoroughly understand the product's key management and how it meets the requirements to ensure the keys are adequately protected. This documentation should include an essay and diagram(s). This documentation is not required to be part of the TSS - it can be submitted as a separate document and marked as developer proprietary.

SP 800-56C specifies a two-step key derivation procedure that employs an extraction-then-expansion technique for deriving keying material from a shared secret generated during a key establishment scheme. The Randomness Extraction step as described in Section 5 of SP 800-56C is followed by Key Expansion using the key derivation functions defined in SP 800-108 (as described in Section 6 of SP 800-56C).

TSS
The evaluator shall examine the key hierarchy section of the TSS to ensure that the formation of all DEKs is described and that the key sizes match that described by the ST author. The evaluator shall examine the key hierarchy section of the TSS to ensure that each DEK is generated or combined from keys of equal or greater security strength using one of the selected methods.
• If the symmetric DEK is generated by an RBG, the evaluator shall review the TSS to determine that it describes how the functionality described by FCS_RBG_EXT.1 is invoked. The evaluator uses the description of the RBG functionality in FCS_RBG_EXT.1 or documentation available for the operational environment to determine that the key size being requested is greater than or equal to the key size and mode to be used for the encryption/decryption of the data.
• If the DEK is formed from a combination, the evaluator shall verify that the TSS describes the method of combination and that this method is either an XOR, or a KDF.
• If “concatenating the keys and using a KDF (as described in (SP 800-56C)” is selected, the evaluator shall ensure the TSS includes a description of the randomness extraction step.
The description must include how an approved untruncated MAC function is being used for the randomness extraction step and the evaluator must verify the TSS describes that the output length (in bits) of the MAC function is at least as large as the targeted security strength (in bits) of the parameter set employed by the key establishment scheme (see Tables 1-3 of SP 800-56C).

The description must include how the MAC function being used for the randomness extraction step is related to the PRF used in the key expansion and verify the TSS description includes the correct MAC function:
• If an HMAC-hash is used in the randomness extraction step, then the same HMAC-hash (with the same hash function hash) is used as the PRF in the key expansion step.
• If an AES-CMAC (with key length 128, 192, or 256 bits) is used in the randomness extraction step, then AES-CMAC with a 128-bit key is used as the PRF in the key expansion step.
• The description must include the lengths of the salt values being used in the randomness extraction step and the evaluator shall verify the TSS description includes correct salt lengths:
• If an HMAC-hash is being used as the MAC, the salt length can be any value up to the maximum bit length permitted for input to the hash function hash.
• If an AES-CMAC is being used as the MAC, the salt length shall be the same length as the AES key (i.e. 128, 192, or 256 bits).
(conditional) If a KDF is used, the evaluator shall ensure that the TSS includes a description of the key derivation function and shall verify the key derivation uses an approved derivation mode and key expansion algorithm according to SP 800-108 or SP 800-56C.

Guidance
The evaluator uses the description of the RBG functionality in FCS_RBG_EXT.1 or documentation available for the operational environment to determine that the key size being generated or combined is identical to the key size and mode to be used for the encryption/decryption of the data.

Tests
If a KDF is used, the evaluator shall perform one or more of the following tests to verify the correctness of the key derivation function, depending on the mode(s) that are supported. Table 3 maps the data fields to the notations used in SP 800-108 and SP 800-56C.

Table 3: Notations used in SP 800-108 and SP 800-56C
 Data Fields Notations SP 800-108 SP 800-56C Pseudorandom function PRF PRF Counter length r r Length of output of PRF h h Length of derived keying material L L Length of input values l length l length Pseudorandom input values I K1 (key derivation key) Z (shared secret) Pseudorandom salt values n/a s Randomness extraction MAC n/a MAC

Counter Mode Tests:

The evaluator shall determine the following characteristics of the key derivation function:
• One or more pseudorandom functions that are supported by the implementation (PRF).
• One or more of the values {8, 16, 24, 32} that equal the length of the binary representation of the counter (r).
• The length (in bits) of the output of the PRF (h).
• Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. These must be evenly divisible by h.
• Up to two values of L that are NOT evenly divisible by h.
• Location of the counter relative to fixed input data: before, after, or in the middle.
• Counter before fixed input data: fixed input data string length (in bytes), fixed input data string value.
• Counter after fixed input data: fixed input data string length (in bytes), fixed input data string value.
• Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string input before counter, value of string input after counter.
• The length (I_length) of the input values I.
For each supported combination of I_length, MAC, salt, PRF, counter location, value of r, and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I, and pseudorandom salt values. If there is only one value of L that is evenly divisible by h, the evaluator shall generate 20 test vectors for it. For each test vector, the evaluator shall supply this data to the in order to produce the keying material output.

The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation.

Feedback Mode Tests:

The evaluator shall determine the following characteristics of the key derivation function:
• One or more pseudorandom functions that are supported by the implementation (PRF).
• The length (in bits) of the output of the PRF (h).
• Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. These must be evenly divisible by h.
• Up to two values of L that are NOT evenly divisible by h.
• Whether or not zero-length IVs are supported.
• Whether or not a counter is used, and if so:
• One or more of the values {8, 16, 24, 32} that equal the length of the binary representation of the counter (r).
• Location of the counter relative to fixed input data: before, after, or in the middle.
• Counter before fixed input data: fixed input data string length (in bytes), fixed input data string value.
• Counter after fixed input data: fixed input data string length (in bytes), fixed input data string value.
• Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string input before counter, value of string input after counter.
• The length (I_length) of the input values I.
For each supported combination of I_length, MAC, salt, PRF, counter location (if a counter is used), value of r (if a counter is used), and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I and pseudorandom salt values. If the KDF supports zero-length IVs, five of these test vectors will be accompanied by pseudorandom IVs and the other five will use zero-length IVs. If zero-length IVs are not supported, each test vector will be accompanied by an pseudorandom IV. If there is only one value of L that is evenly divisible by h, the evaluator shall generate 20 test vectors for it.

For each test vector, the evaluator shall supply this data to the in order to produce the keying material output. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation.

Double Pipeline Iteration Mode Tests:

The evaluator shall determine the following characteristics of the key derivation function:
• One or more pseudorandom functions that are supported by the implementation (PRF).
• The length (in bits) of the output of the PRF (h).
• Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. These must be evenly divisible by h.
• Up to two values of L that are NOT evenly divisible by h.
• Whether or not a counter is used, and if so:
• One or more of the values {8, 16, 24, 32} that equal the length of the binary representation of the counter (r).
• Location of the counter relative to fixed input data: before, after, or in the middle.
• Counter before fixed input data: fixed input data string length (in bytes), fixed input data string value.
• Counter after fixed input data: fixed input data string length (in bytes), fixed input data string value.
• Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string input before counter, value of string input after counter.
• The length (I_length) of the input values I.
For each supported combination of I_length, MAC, salt, PRF, counter location (if a counter is used), value of r (if a counter is used), and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I, and pseudorandom salt values. If there is only one value of L that is evenly divisible by h, the evaluator shall generate 20 test vectors for it.

For each test vector, the evaluator shall supply this data to the in order to produce the keying material output. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation.

#### FCS_CKM_EXT.3 Extended: Cryptographic Key Generation

The TSF shall use [selection:
• asymmetric KEKs of [assignment: security strength greater than or equal to 112 bits] security strength,
• symmetric KEKs of [selection: 128-bit, 256-bit] security strength corresponding to at least the security strength of the keys encrypted by the KEK
].
Application Note: The ST author selects all applicable KEK types implemented by the TOE.
The TSF shall generate all KEKs using one of the following methods:
• Derive the KEK from a Password Authentication Factor according to FCS_COP.1.1(5) and
[selection:
• Generate the KEK using an RBG that meets this profile (as specified in FCS_RBG_EXT.1),
• Generate the KEK using a key generation scheme that meets this profile (as specified in FCS_CKM.1),
• Combine the KEK from other KEKs in a way that preserves the effective entropy of each factor by [selection: using an XOR operation, concatenating the keys and using a KDF (as described in SP 800-108), concatenating the keys and using a KDF (as described in SP 800-56C), encrypting one key with another]
].
Application Note: The conditioning of passwords is performed in accordance with FCS_COP.1(5).

It is expected that key generation derived from conditioning, using an RBG or generation scheme, and through combination, will each be necessary to meet the requirements set out in this document. In particular, Figure 3 has KEKs of each type: KEK_3 is generated, KEK_1 is derived from a Password Authentication Factor, and KEK_2 is combined from two KEKs. In Figure 3, KEK_3 may either be a symmetric key generated from an RBG or an asymmetric key generated using a key generation scheme according to FCS_CKM.1.

If combined, the ST author shall describe which method of combination is used in order to justify that the effective entropy of each factor is preserved.

The documentation of the product's encryption key management should be detailed enough that, after reading, the evaluator will thoroughly understand the product's key management and how it meets the requirements to ensure the keys are adequately protected. This documentation should include an essay and diagram(s). This documentation is not required to be part of the TSS - it can be submitted as a separate document and marked as developer proprietary.

SP 800-56C specifies a two-step key derivation procedure that employs an extraction-then-expansion technique for deriving keying material from a shared secret generated during a key establishment scheme. The Randomness Extraction step as described in Section 5 of SP 800-56C is followed by Key Expansion using the key derivation functions defined in SP 800-108 (as described in Section 6 of SP 800-56C).
TSS
The evaluator shall examine the key hierarchy section of the TSS to ensure that the formation of all KEKs is described and that the key sizes match that described by the ST author. The evaluator shall examine the key hierarchy section of the TSS to ensure that each key (DEKs, software-based key storage, and KEKs) is encrypted by keys of equal or greater security strength using one of the selected methods.
• The evaluator shall review the TSS to verify that it contains a description of the conditioning use to derive KEKs. This description must include the size and storage location of salts. This activity may be performed in combination with that for FCS_COP.1(5).
• If the symmetric KEK is generated by an RBG, the evaluator shall review the TSS to determine that it describes how the functionality described by FCS_RBG_EXT.1 is invoked. The evaluator uses the description of the RBG functionality in FCS_RBG_EXT.1 or documentation available for the operational environment to determine that the key size being requested is greater than or equal to the key size and mode to be used for the encryption/decryption of the data.
• If the KEK is generated according to an asymmetric key scheme, the evaluator shall review the TSS to determine that it describes how the functionality described by FCS_CKM.1 is invoked. The evaluator uses the description of the key generation functionality in FCS_CKM.1 or documentation available for the operational environment to determine that the key strength being requested is greater than or equal to 112 bits.
• If the KEK is formed from a combination, the evaluator shall verify that the TSS describes the method of combination and that this method is either an XOR, a KDF, or encryption.

(conditional) If a KDF is used, the evaluator shall ensure that the TSS includes a description of the key derivation function and shall verify the key derivation uses an approved derivation mode and key expansion algorithm according to SP 800-108.

If "concatenating the keys and using a KDF (as described in (SP 800-56C)" is selected, the evaluator shall ensure the TSS includes a description of the randomness extraction step.
• The description must include how an approved untruncated MAC function is being used for the randomness extraction step and the evaluator must verify the TSS describes that the output length (in bits) of the MAC function is at least as large as the targeted security strength (in bits) of the parameter set employed by the key establishment scheme (see Tables 1-3 of SP 800-56C).
• The description must include how the MAC function being used for the randomness extraction step is related to the PRF used in the key expansion and verify the TSS description includes the correct MAC function:
• If an HMAC-hash is used in the randomness extraction step, then the same HMAC-hash (with the same hash function hash) is used as the PRF in the key expansion step.
• If an AES-CMAC (with key length 128, 192, or 256 bits) is used in the randomness extraction step, then AES-CMAC with a 128-bit key is used as the PRF in the key expansion step.
• The description must include the lengths of the salt values being used in the randomness extraction step and the evaluator shall verify the TSS description includes correct salt lengths:
• If an HMAC-hash is being used as the MAC, the salt length can be any value up to the maximum bit length permitted for input to the hash function hash.
• If an AES-CMAC is being used as the MAC, the salt length shall be the same length as the AES key (i.e. 128, 192, or 256 bits).
If a KDF is used, the evaluator shall perform one or more of the following tests to verify the correctness of the key derivation function, depending on the mode(s) that are supported. Table 4 maps the data fields to the notations used in SP 800-108 and SP 800-56C.

Table 4: Notations used in SP 800-108 and SP 800-56C
 Data Fields Notations SP 800-108 SP 800-56C Pseudorandom function PRF PRF Counter length r r Length of output of PRF h h Length of derived keying material L L Length of input values I_length I_length Pseudorandom input values I K1 (key derivation key) Z (shared secret) Pseudorandom salt values n/a s Randomness extraction MAC n/a MAC

Counter Mode Tests:

The evaluator shall determine the following characteristics of the key derivation function:
• One or more pseudorandom functions that are supported by the implementation (PRF).
• One or more of the values {8, 16, 24, 32} that equal the length of the binary representation of the counter (r).
• The length (in bits) of the output of the PRF (h).
• Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. These must be evenly divisible by h.
• Up to two values of L that are NOT evenly divisible by h.
• Location of the counter relative to fixed input data: before, after, or in the middle.
• Counter before fixed input data: fixed input data string length (in bytes), fixed input data string value.
• Counter after fixed input data: fixed input data string length (in bytes), fixed input data string value.
• Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string input before counter, value of string input after counter.
• The length (I_length) of the input values I.

For each supported combination of I_length, MAC, salt, PRF, counter location, value of r, and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I, and pseudorandom salt values. If there is only one value of L that is evenly divisible by h, the evaluator shall generate 20 test vectors for it. For each test vector, the evaluator shall supply this data to the TOE in order to produce the keying material output.

The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation.

Feedback Mode Tests:
The evaluator shall determine the following characteristics of the key derivation function:
• One or more pseudorandom functions that are supported by the implementation (PRF).
• The length (in bits) of the output of the PRF (h).
• Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. These must be evenly divisible by h.
• Up to two values of L that are NOT evenly divisible by h.
• Whether or not zero-length IVs are supported.
• Whether or not a counter is used, and if so:
• One or more of the values {8, 16, 24, 32} that equal the length of the binary representation of the counter (r).
• Location of the counter relative to fixed input data: before, after, or in the middle.
• Counter before fixed input data: fixed input data string length (in bytes), fixed input data string value.
• Counter after fixed input data: fixed input data string length (in bytes), fixed input data string value.
• Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string input before counter, value of string input after counter.
• The length (I_length) of the input values I.

For each supported combination of I_length, MAC, salt, PRF, counter location (if a counter is used), value of r (if a counter is used), and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I and pseudorandom salt values. If the KDF supports zero-length IVs, five of these test vectors will be accompanied by pseudorandom IVs and the other five will use zero-length IVs. If zero-length IVs are not supported, each test vector will be accompanied by an pseudorandom IV. If there is only one value of L that is evenly divisible by h, the evaluator shall generate 20 test vectors for it.

For each test vector, the evaluator shall supply this data to the TOE in order to produce the keying material output. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation.

Double Pipeline Iteration Mode Tests:

The evaluator shall determine the following characteristics of the key derivation function:

• One or more pseudorandom functions that are supported by the implementation (PRF).
• The length (in bits) of the output of the PRF (h).
• Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. These must be evenly divisible by h.
• Up to two values of L that are NOT evenly divisible by h.
• Whether or not a counter is used, and if so:
• One or more of the values {8, 16, 24, 32} that equal the length of the binary representation of the counter (r).
• Location of the counter relative to fixed input data: before, after, or in the middle.
• Counter before fixed input data: fixed input data string length (in bytes), fixed input data string value.
• Counter after fixed input data: fixed input data string length (in bytes), fixed input data string value.
• Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string input before counter, value of string input after counter.
• The length (I_length) of the input values I.

For each supported combination of I_length, MAC, salt, PRF, counter location (if a counter is used), value of r (if a counter is used), and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I, and pseudorandom salt values. If there is only one value of L that is evenly divisible by h, the evaluator shall generate 20 test vectors for it.

For each test vector, the evaluator shall supply this data to the TOE in order to produce the keying material output. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation.

#### FCS_CKM_EXT.4 Extended: Key Destruction

The TSF shall destroy cryptographic keys in accordance with the specified cryptographic key destruction methods:
• by clearing the KEK encrypting the target key
• in accordance with the following rules
• For volatile memory, the destruction shall be executed by a single direct overwrite [selection: consisting of a pseudo-random pattern using the TSF’s RBG, consisting of zeroes].
• For non-volatile EEPROM, the destruction shall be executed by a single direct overwrite consisting of a pseudo random pattern using the TSF’s RBG (as specified in FCS_RBG_EXT.1), followed by a read-verify.
• For non-volatile flash memory, that is not wear-leveled, the destruction shall be executed [selection: by a single direct overwrite consisting of zeros followed by a read-verify, by a block erase that erases the reference to memory that stores data as well as the data itself ].
• For non-volatile flash memory, that is wear-leveled, the destruction shall be executed [selection: by a single direct overwrite consisting of zeros, by a block erase].
• 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.
Application Note: The clearing indicated above applies to each intermediate storage area for plaintext key/cryptographic critical security parameter (i.e. any storage, such as memory buffers, that is included in the path of such data) upon the transfer of the key/cryptographic critical security parameter to another location.

Because plaintext key material is not allowed to be written to non-volatile memory (FPT_KST_EXT.1), the second selection only applies to key material written to volatile memory.
The TSF shall destroy all plaintext keying material and critical security parameters when no longer needed.
Application Note: For the purposes of this requirement, plaintext keying material refers to authentication data, passwords, secret/private symmetric keys, private asymmetric keys, data used to derive keys, values derived from passwords, etc. If a BAF is selected in FIA_UAU.5.1 the enrollment or authentication templates are not subject to this requirement, since templates are not suitable for deriving keying material. However, source biometric data (i.e. fingerprint image or friction ridge pattern), the features an algorithm uses to perform biometric authentication for enrollment or verification (e.g. location of minutia), threshold values used in making the match adjudication, intermediate values calculated while building an enrollment or authentication template (i.e. direction maps, minutia counts, binarized and skeletonized representations of friction ridge patterns, etc.), and final match scores are examples of critical security parameters that must be destroyed when no longer needed.

Key destruction procedures are performed in accordance with FCS_CKM_EXT.4.1.

There are multiple situations in which plaintext keying material is no longer necessary, including when the TOE is powered off, when the wipe function is performed, when trusted channels are disconnected, when keying material is no longer needed by the trusted channel per the protocol, and when transitioning to the locked state (for those values derived from the Password Authentication Factor or that key material which is protected by the password-derived or biometric-unlocked KEK according to FCS_STG_EXT.2 – see Figure 3). For keys (or key material used to derive those keys) protecting sensitive data received in the locked state, "no longer needed" includes "while in the locked state."

Trusted channels may include TLS, HTTPS, DTLS, IPsec VPNs, Bluetooth BR/EDR, and Bluetooth LE. The plaintext keying material for these channels includes (but is not limited to) master secrets, and Security Associations (SAs).

If REK(s) are processed in a separate execution environment on the same Application Processor as the Rich OS, REK key material must be cleared from RAM immediately after use, and at least, must be wiped when the device is locked, as the REK is part of the key hierarchy protecting sensitive data.
TSS
The evaluator shall check to ensure the TSS lists each type of plaintext key material (DEKs, software-based key storage, KEKs, trusted channel keys, passwords, etc.) and its generation and storage location.

The evaluator shall verify that the TSS describes when each type of key material is cleared (for example, on system power off, on wipe function, on disconnection of trusted channels, when no longer needed by the trusted channel per the protocol, when transitioning to the locked state, and possibly including immediately after use, while in the locked state, etc.).

The evaluator shall also verify that, for each type of key, the type of clearing procedure that is performed (cryptographic erase, overwrite with zeros, overwrite with random pattern, or block erase) is listed. 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.

Assurance Activity Note 1: 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.

For each software and firmware key clearing situation (including on system power off, on wipe function, on disconnection of trusted channels, when no longer needed by the trusted channel per the protocol, when transitioning to the locked state, and possibly including immediately after use, while in the locked state) the evaluator shall repeat the following tests.

For these tests the evaluator shall utilize 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.

Tests
• Test 1: 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:
1. Record the value of the key in the TOE subject to clearing.
2. Cause the TOE to perform a normal cryptographic processing with the key from Step #1.
3. Cause the TOE to clear the key.
4. Cause the TOE to stop the execution but not exit.
5. Cause the TOE to dump the entire memory of the TOE into a binary file.
6. Search the content of the binary file created in Step #5 for instances of the known key value from Step #1.
7. 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.

• Test 2: 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:
1. Record the value of the key in the TOE subject to clearing.
2. Cause the TOE to perform a normal cryptographic processing with the key from Step #1.
3. Cause the TOE to clear the key.
4. 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.
5. 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.

• Test 3: 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:
1. Record the storage location of the key in the TOE subject to clearing.
2. Cause the TOE to perform a normal cryptographic processing with the key from Step #1.
3. Cause the TOE to clear the key.
4. 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.

#### FCS_CKM_EXT.5 Extended: TSF Wipe

The TSF shall wipe all protected data by [selection:
• Cryptographically erasing the encrypted DEKs and/or the KEKs in non-volatile memory by following the requirements in FCS_CKM_EXT.4.1,
• Overwriting all Protected Data according to the following rules:
• For EEPROM, the destruction shall be executed by a single direct overwrite consisting of a pseudo random pattern using the TSF’s RBG (as specified in FCS_RBG_EXT.1, followed by a read-verify.
• For flash memory, that is not wear-leveled, the destruction shall be executed [selection: by a single direct overwrite consisting of zeros followed by a read-verify, by a block erase that erases the reference to memory that stores data as well as the data itself].
• For flash memory, that is wear-leveled, the destruction shall be executed [selection: by a single direct overwrite consisting of zeros, by a block erase].
• 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.
].
Application Note: Protected data is all non-TSF data, including all user or enterprise data. Some or all of this data may be considered sensitive data as well.
The TSF shall perform a power cycle on conclusion of the wipe procedure.
Application Note: The ST author shall select which method of wipe the TSF performs.
TSS
The evaluator shall check to ensure the TSS describes how the device is wiped; and the type of clearing procedure that is performed (cryptographic erase or overwrite) and, if overwrite is performed, the overwrite procedure (overwrite with zeros, overwrite three or more times by a different alternating pattern, overwrite with random pattern, or block erase). If different types of memory are used to store the data to be protected, the evaluator shall check to ensure that the TSS describes the clearing procedure in terms of the memory in which the data are stored (for example, data stored on flash are cleared by overwriting once with zeros, while data stored on the internal persistent storage device are cleared by overwriting three times with a random pattern that is changed before each write).

Assurance Activity Note: The following test may require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on consumer Mobile Device products.

Tests
The evaluator shall perform one of the following tests. The test before and after the wipe command shall be identical. This test shall be repeated for each type of memory used to store the data to be protected.

Method 1 for File-based Methods:
• Test 1: The evaluator shall enable encryption according to the AGD guidance. The evaluator shall create a user data (protected data or sensitive data) file, for example, by using an application. The evaluator shall use a tool provided by the developer to examine this data stored in memory (for example, by examining a decrypted files). The evaluator shall initiate the wipe command according to the AGD guidance provided for FMT_SMF_EXT.1. The evaluator shall use a tool provided by the developer to examine the same data location in memory to verify that the data has been wiped according to the method described in the TSS (for example, the files are still encrypted and cannot be accessed).
Method 2 for Volume-based Methods:
• Test 1: The evaluator shall enable encryption according to the AGD guidance. The evaluator shall create a unique data string, for example, by using an application. The evaluator shall use a tool provided by the developer to search decrypted data for the unique string. The evaluator shall initiate the wipe command according to the AGD guidance provided for FMT_SMF_EXT.1. The evaluator shall use a tool provided by the developer to search for the same unique string in decrypted memory to verify that the data has been wiped according to the method described in the TSS (for example, the files are still encrypted and cannot be accessed).

#### FCS_CKM_EXT.6 Extended: Salt Generation

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

#### FCS_COP.1(1) Cryptographic operation

The TSF shall perform encryption/decryption in accordance with a specified cryptographic algorithm:
• AES-CBC (as defined in FIPS PUB 197, and NIST SP 800-38A) mode
• AES-CCMP (as defined in FIPS PUB 197, NIST SP 800-38C and IEEE 802.11-2012), and
• [selection:
• AES Key Wrap (KW) (as defined in NIST SP 800-38F),
• AES Key Wrap with Padding (KWP) (as defined in NIST SP 800-38F),
• AES-GCM (as defined in NIST SP 800-38D),
• AES-CCM (as defined in NIST SP 800-38C),
• AES-XTS (as defined in NIST SP 800-38E) mode,
• AES-CCMP-256 (as defined in NIST SP800-38C and IEEE 802.11ac-2013),
• AES-GCMP-256 (as defined in NIST SP800-38D and IEEE 802.11ac-2013),
• no other modes
]
and cryptographic key sizes 128-bit key sizes and [selection: 256-bit key sizes, no other key sizes].
Application Note: For the first selection, the ST author should choose the mode or modes in which AES operates. For the second selection, the ST author should choose the key sizes that are supported by this functionality. 128-bit CBC and CCMP are required in order to comply with WLAN Client Extended Package.

Note that to comply with the WLAN Client EP, AES CCMP (which uses AES in CCM as specified in SP 800-38C) with cryptographic key size of 128 bits must be implemented. Optionally, AES-CCMP-256 or AES-GCMP-256 with cryptographic key size of 256 bits may be implemented.
Assurance Activity Note: The following tests require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products.

Tests
AES-CBC Tests
• Test 1: AES-CBC Known Answer Tests

There are four Known Answer Tests (KATs), described below. In all KATs, the plaintext, ciphertext, and IV values shall be 128-bit blocks. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation.

• Test 1.1: KAT-1. To test the encrypt functionality of AES-CBC, the evaluator shall supply a set of 10 plaintext values and obtain the ciphertext value that results from AES-CBC encryption of the given plaintext using a key value of all zeros and an IV of all zeros. Five plaintext values shall be encrypted with a 128-bit all-zeros key, and the other five shall be encrypted with a 256-bit all-zeros key.

To test the decrypt functionality of AES-CBC, the evaluator shall perform the same test as for encrypt, using 10 ciphertext values as input and AES-CBC decryption.

• Test 1.2: KAT-2. To test the encrypt functionality of AES-CBC, the evaluator shall supply a set of 10 key values and obtain the ciphertext value that results from AES-CBC encryption of an all-zeros plaintext using the given key value and an IV of all zeros. Five of the keys shall be 128-bit keys, and the other five shall be 256-bit keys.

To test the decrypt functionality of AES-CBC, the evaluator shall perform the same test as for encrypt, using an all-zero ciphertext value as input and AES-CBC decryption.

• Test 1.3: KAT-3. To test the encrypt functionality of AES-CBC, the evaluator shall supply the two sets of key values described below and obtain the ciphertext value that results from AES encryption of an all-zeros plaintext using the given key value and an IV of all zeros. The first set of keys shall have 128 128-bit keys, and the second set shall have 256 256-bit keys. Key i in each set shall have the leftmost i bits be ones and the rightmost N-i bits be zeros, for i in [1,N].

To test the decrypt functionality of AES-CBC, the evaluator shall supply the two sets of key and ciphertext value pairs described below and obtain the plaintext value that results from AES-CBC decryption of the given ciphertext using the given key and an IV of all zeros. The first set of key/ciphertext pairs shall have 128 128-bit key/ciphertext pairs, and the second set of key/ciphertext pairs shall have 256 256-bit key/ciphertext pairs. Key i in each set shall have the leftmost i bits be ones and the rightmost N-i bits be zeros, for i in [1,N]. The ciphertext value in each pair shall be the value that results in an all-zeros plaintext when decrypted with its corresponding key.

• Test 1.4: KAT-4. To test the encrypt functionality of AES-CBC, the evaluator shall supply the set of 128 plaintext values described below and obtain the two ciphertext values that result from AES-CBC encryption of the given plaintext using a 128-bit key value of all zeros with an IV of all zeros and using a 256-bit key value of all zeros with an IV of all zeros, respectively. Plaintext value i in each set shall have the leftmost i bits be ones and the rightmost 128-i bits be zeros, for i in [1,128].

To test the decrypt functionality of AES-CBC, the evaluator shall perform the same test as for encrypt, using ciphertext values of the same form as the plaintext in the encrypt test as input and AES-CBC decryption.

• Test 2: AES-CBC Multi-Block Message Test

The evaluator shall test the encrypt functionality by encrypting an i-block message where 1 < i <= 10. The evaluator shall choose a key, an IV and plaintext message of length i blocks and encrypt the message, using the mode to be tested, with the chosen key and IV. The ciphertext shall be compared to the result of encrypting the same plaintext message with the same key and IV using a known good implementation.

The evaluator shall also test the decrypt functionality for each mode by decrypting an i-block message where 1 < i <= 10. The evaluator shall choose a key, an IV and a ciphertext message of length i blocks and decrypt the message, using the mode to be tested, with the chosen key and IV. The plaintext shall be compared to the result of decrypting the same ciphertext message with the same key and IV using a known good implementation.

• Test 3: AES-CBC Monte Carlo Tests

The evaluator shall test the encrypt functionality using a set of 200 plaintext, IV, and key 3-tuples. 100 of these shall use 128 bit keys, and 100 shall use 256 bit keys. The plaintext and IV values shall be 128-bit blocks. For each 3-tuple, 1000 iterations shall be run as follows:

                    # Input: PT, IV, Key
for i = 1 to 1000:
if i == 1:
CT[1] = AES-CBC-Encrypt(Key, IV, PT)
PT = IV
else:
CT[i] = AES-CBC-Encrypt(Key, PT)
PT = CT[i-1]


The ciphertext computed in the 1000th iteration (i.e. CT[1000]) is the result for that trial. This result shall be compared to the result of running 1000 iterations with the same values using a known good implementation.

The evaluator shall test the decrypt functionality using the same test as for encrypt, exchanging CT and PT and replacing AES-CBC-Encrypt with AES-CBC-Decrypt.

AES-CCM Tests
• Test 1: The evaluator shall test the generation-encryption and decryption-verification functionality of AES-CCM for the following input parameter and tag lengths:

• 128 bit and 256 bit keys

• Two payload lengths. One payload length shall be the shortest supported payload length, greater than or equal to zero bytes. The other payload length shall be the longest supported payload length, less than or equal to 32 bytes (256 bits).

• Two or three associated data lengths. One associated data length shall be 0, if supported. One associated data length shall be the shortest supported payload length, greater than or equal to zero bytes. One associated data length shall be the longest supported payload length, less than or equal to 32 bytes (256 bits). If the implementation supports an associated data length of 216 bytes, an associated data length of 216 bytes shall be tested.

• Nonce lengths. All supported nonce lengths between 7 and 13 bytes, inclusive, shall be tested.

• Tag lengths. All supported tag lengths of 4, 6, 8, 10, 12, 14 and 16 bytes shall be tested.
To test the generation-encryption functionality of AES-CCM, the evaluator shall perform the following four tests:
• Test 1.1: For EACH supported key and associated data length and ANY supported payload, nonce and tag length, the evaluator shall supply one key value, one nonce value and 10 pairs of associated data and payload values and obtain the resulting ciphertext.

• Test 1.2: For EACH supported key and payload length and ANY supported associated data, nonce and tag length, the evaluator shall supply one key value, one nonce value and 10 pairs of associated data and payload values and obtain the resulting ciphertext.

• Test 1.3: For EACH supported key and nonce length and ANY supported associated data, payload and tag length, the evaluator shall supply one key value and 10 associated data, payload and nonce value 3-tuples and obtain the resulting ciphertext.

• Test 1.4: For EACH supported key and tag length and ANY supported associated data, payload and nonce length, the evaluator shall supply one key value, one nonce value and 10 pairs of associated data and payload values and obtain the resulting ciphertext.
To determine correctness in each of the above tests, the evaluator shall compare the ciphertext with the result of generation-encryption of the same inputs with a known good implementation.

To test the decryption-verification functionality of AES-CCM, for EACH combination of supported associated data length, payload length, nonce length and tag length, the evaluator shall supply a key value and 15 nonce, associated data and ciphertext 3-tuples and obtain either a FAIL result or a PASS result with the decrypted payload. The evaluator shall supply 10 tuples that should FAIL and 5 that should PASS per set of 15.

AES-GCM Test
The evaluator shall test the authenticated encrypt functionality of AES-GCM for each combination of the following input parameter lengths:

• 128 bit and 256 bit keys

• Two plaintext lengths. One of the plaintext lengths shall be a non-zero integer multiple of 128 bits, if supported. The other plaintext length shall not be an integer multiple of 128 bits, if supported.

• Three AAD lengths. One AAD length shall be 0, if supported. One AAD length shall be a non-zero integer multiple of 128 bits, if supported. One AAD length shall not be an integer multiple of 128 bits, if supported.

• Two IV lengths. If 96 bit IV is supported, 96 bits shall be one of the two IV lengths tested.
• Test 1: The evaluator shall test the encrypt functionality using a set of 10 key, plaintext, AAD, and IV tuples for each combination of parameter lengths above and obtain the ciphertext value and tag that results from AES-GCM authenticated encrypt. Each supported tag length shall be tested at least once per set of 10. The IV value may be supplied by the evaluator or the implementation being tested, as long as it is known.

• Test 2: The evaluator shall test the decrypt functionality using a set of 10 key, ciphertext, tag, AAD, and IV 5-tuples for each combination of parameter lengths above and obtain a Pass/Fail result on authentication and the decrypted plaintext if Pass. The set shall include five tuples that Pass and five that Fail.

• The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation.

XTS-AES Test
• Test 1: The evaluator shall test the encrypt functionality of XTS-AES for each combination of the following input parameter lengths:

• 256 bit (for AES-128) and 512 bit (for AES-256) keys

• Three data unit (i.e. plaintext) lengths. One of the data unit lengths shall be a non-zero integer multiple of 128 bits, if supported. One of the data unit lengths shall be an integer multiple of 128 bits, if supported. The third data unit length shall be either the longest supported data unit length or 216 bits, whichever is smaller.

using a set of 100 (key, plaintext and 128-bit random tweak value) 3-tuples and obtain the ciphertext that results from XTS-AES encrypt.

The evaluator may supply a data unit sequence number instead of the tweak value if the implementation supports it. The data unit sequence number is a base-10 number ranging between 0 and 255 that implementations convert to a tweak value internally.

• Test 2: The evaluator shall test the decrypt functionality of XTS-AES using the same test as for encrypt, replacing plaintext values with ciphertext values and XTS-AES encrypt with XTS-AES decrypt.

AES Key Wrap (AES-KW) and Key Wrap with Padding (AES-KWP) Test
• Test 1: The evaluator shall test the authenticated encryption functionality of AES-KW for EACH combination of the following input parameter lengths:

• 128 and 256 bit key encryption keys (KEKs)

• Three plaintext lengths. One of the plaintext lengths shall be two semi-blocks (128 bits). One of the plaintext lengths shall be three semi-blocks (192 bits). The third data unit length shall be the longest supported plaintext length less than or equal to 64 semi-blocks (4096 bits).
using a set of 100 key and plaintext pairs and obtain the ciphertext that results from AES-KW authenticated encryption. To determine correctness, the evaluator shall use the AES-KW authenticated-encryption function of a known good implementation.

• Test 2: The evaluator shall test the authenticated-decryption functionality of AES-KW using the same test as for authenticated-encryption, replacing plaintext values with ciphertext values and AES-KW authenticated-encryption with AES-KW authenticated-decryption.

• Test 3: The evaluator shall test the authenticated-encryption functionality of AES-KWP using the same test as for AES-KW authenticated-encryption with the following change in the three plaintext lengths:
• One plaintext length shall be one octet. One plaintext length shall be 20 octets (160 bits).

• One plaintext length shall be the longest supported plaintext length less than or equal to 512 octets (4096 bits).
• Test 4: The evaluator shall test the authenticated-decryption functionality of AES-KWP using the same test as for AES-KWP authenticated-encryption, replacing plaintext values with ciphertext values and AES-KWP authenticated-encryption with AES-KWP authenticated-decryption.

#### FCS_COP.1(2) Cryptographic operation

The TSF shall perform cryptographic hashing in accordance with a specified cryptographic algorithm SHA-1 and [selection: SHA-256, SHA-384, SHA-512, no other algorithms] and message digest sizes 160 and [selection: 256, 384, 512 bits, no other message digest sizes] that meet the following: FIPS Pub 180-4.
Application Note: Per NIST SP 800-131A, SHA-1 for generating digital signatures is no longer allowed, and SHA-1 for verification of digital signatures is strongly discouraged as there may be risk in accepting these signatures. It is expected that vendors will implement SHA-2 algorithms in accordance with SP 800-131A.

SHA-1 is currently required in order to comply with the WLAN Client Extended Package. Vendors are strongly encouraged to implement updated protocols that support the SHA-2 family; until updated protocols are supported, this PP allows support for SHA-1 implementations in compliance with SP 800-131A.

The intent of this requirement is to specify the hashing function. The hash selection must support the message digest size selection. The hash selection should be consistent with the overall strength of the algorithm used (for example, SHA 256 for 128-bit keys).
Guidance
The evaluator checks 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 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 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. the byte­oriented testmacs.

The TSF may implement either bit-oriented or byte-oriented; both implementations are not required. The evaluator shall perform all of the following tests for each hash algorithm implemented by the TSF and used to satisfy the requirements of this PP.

Assurance Activity Note: The following tests require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products.

Tests
• Test 1: Short Messages Test: Bit-­oriented Mode
The evaluators devise an input set consisting of m+1 messages, where m is the block length of the hash algorithm. The length of the messages ranges sequentially from 0 to m bits. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF.

• Test 2: Short Messages Test: Byte-­oriented Mode
The evaluators devise an input set consisting of m/8+1 messages, where m is the block length of the hash algorithm. The length of the messages range sequentially from 0 to m/8 bytes, with each message being an integral number of bytes. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF.

• Test 3: Selected Long Messages Test: Bit-­oriented Mode
The evaluators devise an input set consisting of m messages, where m is the block length of the hash algorithm. The length of the ith message is 512 + 99*i, where 1 ≤ i ≤ m. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF.

• Test 4: Selected Long Messages Test: Byte-­oriented Mode
The evaluators devise an input set consisting of m/8 messages, where m is the block length of the hash algorithm. The length of the ith message is 512 + 8*99*i, where 1 ≤ i ≤ m/8. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF.

• Test 5: Pseudorandomly Generated Messages Test
This test is for byte­oriented implementations only. The evaluators randomly generate a seed that is n bits long, where n is the length of the message digest produced by the hash function to be tested. The evaluators then formulate a set of 100 messages and associated digests by following the algorithm provided in Figure 1 of SHAVS. The evaluators then ensure that the correct result is produced when the messages are provided to the TSF.

#### FCS_COP.1(3) Cryptographic operation

The TSF shall perform cryptographic signature services (generation and verification) in accordance with a specified cryptographic algorithm[selection:
• RSA schemes using cryptographic key sizes of 2048-bit or greater that meet the following: FIPS PUB 186-4, "Digital Signature Standard (DSS)", Section 4,
• ECDSA schemes using "NIST curves" P-384 and [selection: P-256, P-521, no other curves] that meet the following: FIPS PUB 186-4, "Digital Signature Standard (DSS)", Section 5,
• No other algorithms
].
Application Note: The ST Author should choose the algorithm implemented to perform digital signatures; if more than one algorithm is available, this requirement should be iterated to specify the functionality. For the algorithm chosen, the ST author should make the appropriate assignments/selections to specify the parameters that are implemented for that algorithm.
Assurance Activity Note: The following tests require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products.
Tests
• Test 1: ECDSA Algorithm Tests
• Test 1.1: ECDSA FIPS 186-4 Signature Generation Test
For each supported NIST curve (i.e. P-256, P-384 and P-521) and SHA function pair, the evaluator shall generate 10 1024-bit long messages and obtain for each message a public key and the resulting signature values R and S. To determine correctness, the evaluator shall use the signature verification function of a known good implementation.

• Test 1.2: ECDSA FIPS 186-4 Signature Verification Test
For each supported NIST curve (i.e. P-256, P-384 and P-521) and SHA function pair, the evaluator shall generate a set of 10 1024-bit message, public key and signature tuples and modify one of the values (message, public key or signature) in five of the 10 tuples. The evaluator shall obtain in response a set of 10 PASS/FAIL values.
• Test 2: RSA Signature Algorithm Tests
• Test 2.1: Signature Generation Test
The evaluator shall verify the implementation of RSA Signature Generation by the TOE using the Signature Generation Test. To conduct this test the evaluator must generate or obtain 10 messages from a trusted reference implementation for each modulus size/SHA combination supported by the TSF. The evaluator shall have the TOE use their private key and modulus value to sign these messages.

The evaluator shall verify the correctness of the TSF’s signature using a known good implementation and the associated public keys to verify the signatures.

• Test 2.2: Signature Verification Test
The evaluator shall perform the Signature Verification test to verify the ability of the TOE to recognize another party’s valid and invalid signatures. The evaluator shall inject errors into the test vectors produced during the Signature Verification Test by introducing errors in some of the public keys e, messages, IR format, and/or signatures. The TOE attempts to verify the signatures and returns success or failure.
The evaluator shall use these test vectors to emulate the signature verification test using the corresponding parameters and verify that the TOE detects these errors.

#### FCS_COP.1(4) Cryptographic operation

The TSF shall perform keyed-hash message authentication in accordance with a specified cryptographic algorithm HMAC-SHA-1 and [selection: HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512, no other algorithms] and cryptographic key sizes [assignment: key size (in bits) used in HMAC] and message digest sizes 160 and [selection: 256, 384, 512, no other] bits that meet the following: FIPS Pub 198-1, "The Keyed-Hash Message Authentication Code", and FIPS Pub 180-4, "Secure Hash Standard".
Application Note: The selection in this requirement must be consistent with the key size specified for the size of the keys used in conjunction with the keyed-hash message authentication. HMAC-SHA-1 is currently required in order to comply with the WLAN Client EP.
TSS
The evaluator shall examine the TSS to ensure that it specifies the following values used by the HMAC function: key length, hash function used, block size, and output MAC length used.

Assurance Activity Note: The following tests require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products.

Tests
For each of the supported parameter sets, the evaluator shall compose 15 sets of test data. Each set shall consist of a key and message data. The evaluator shall have the TSF generate HMAC tags for these sets of test data. The resulting MAC tags shall be compared to the result of generating HMAC tags with the same key and IV using a known good implementation.

#### FCS_COP.1(5) Cryptographic operation

The TSF shall perform conditioning in accordance with a specified cryptographic algorithm HMAC-[selection: SHA-256, SHA-384, SHA-512] using a salt, and [selection: PBKDF2 with [assignment: number of iterations] iterations, [assignment: key stretching funtion], no other function] and output cryptographic key sizes [selection: 128, 256] that meet the following: [selection: NIST SP 800-132, no standard].
Application Note: The key cryptographic key sizes in the third selection should be made to correspond to the KEK key sizes selected in FCS_CKM_EXT.3.

This password must be conditioned into a string of bits that forms the submask to be used as input into the KEK. Conditioning can be performed using one of the identified hash functions and may include a key stretching function; the method used is selected by the ST Author. If selected, NIST SP 800-132 requires the use of a pseudo-random function (PRF) consisting of HMAC with an approved hash function. The ST author selects the hash function used, also includes the appropriate requirements for HMAC and the hash function.

Appendix A of NIST SP 800-132 recommends setting the iteration count in order to increase the computation needed to derive a key from a password and, therefore, increase the workload of performing a dictionary attack.
TSS
The evaluator shall check that the TSS describes the method by which the password is first encoded and then fed to the SHA algorithm and verify the SHA algorithm matches the first selection.

If a key stretching function, such as PBKDF2, is selected the settings for the algorithm (padding, blocking, etc.) shall be described. The evaluator shall verify that the TSS contains a description of how the output of the hash function or key stretching function is used to form the submask that will be input into the function and is the same length as the KEK as specified in FCS_CKM_EXT.3.

If any manipulation of the key is performed in forming the submask that will be used to form the KEK, that process shall be described in the TSS.

No explicit testing of the formation of the submask from the input password is required.

#### FCS_HTTPS_EXT.1 Extended: HTTPS Protocol

The TSF shall implement the HTTPS protocol that complies with RFC 2818.
The TSF shall implement HTTPS using TLS in accordance with the Package for Transport Layer Security.
The TSF shall notify the application and [selection: not establish the connection, request application authorization to establish the connection, no other action] if the peer certificate is deemed invalid.
Application Note: Validity is determined by the certificate path, the expiration date, and the revocation status in accordance with RFC 5280.
Tests
• Test 1: The evaluator shall attempt to establish an HTTPS connection with a webserver, observe the traffic with a packet analyzer, and verify that the connection succeeds and that the traffic is identified as TLS or HTTPS.

Other tests are performed in conjunction with FCS_TLSC_EXT.1.

Certificate validity shall be tested in accordance with testing performed for FIA_X509_EXT.1, and the evaluator shall perform the following test:

• Test 2: The evaluator shall demonstrate that using a certificate without a valid certification path results in an application notification. Using the administrative guidance, the evaluator shall then load a certificate or certificates to the Trust Anchor Database needed to validate the certificate to be used in the function, and demonstrate that the function succeeds. The evaluator then shall delete one of the certificates, and show that the application is notified of the validation failure.

#### FCS_IV_EXT.1 Extended: Initialization Vector Generation

The TSF shall generate IVs in accordance with Table 12: References and IV Requirements for NIST-approved Cipher Modes.
Application Note: Table 12 lists the requirements for composition of IVs according to the NIST Special Publications for each cipher mode. The composition of IVs generated for encryption according to a cryptographic protocol is addressed by the protocol. Thus, this requirement addresses only IVs generated for key storage and data storage encryption.
TSS
The evaluator shall examine the key hierarchy section of the TSS to ensure that the encryption of all keys is described and the formation of the IVs for each key encrypted by the same KEK meets FCS_IV_EXT.1.

#### FCS_RBG_EXT.1 Extended: Cryptographic Operation (Random Bit Generation)

The TSF shall perform all deterministic random bit generation services in accordance with NIST Special Publication 800-90A using [selection: Hash_DRBG (any), HMAC_DRBG (any), CTR_DRBG (AES)].
The deterministic RBG shall be seeded by an entropy source that accumulates entropy from [selection: a software-based noise source, TSF-hardware-based noise source] with a minimum of [selection: 128 bits, 256 bits] of entropy at least equal to the greatest security strength (according to NIST SP 800-57) of the keys and hashes that it will generate.
The TSF shall be capable of providing output of the RBG to applications running on the TSF that request random bits.
Application Note: SP 800-90A contains three different methods of generating random numbers; each of these, in turn, depends on underlying cryptographic primitives (hash functions/ciphers). The ST author will select the function used, and include the specific underlying cryptographic primitives used in the requirement or in the TSS. While any of the identified hash functions (SHA-224, SHA-256, SHA-384, SHA-512) are allowed for Hash_DRBG or HMAC_DRBG, only AES-based implementations for CTR_DRBG are allowed.

The ST author must also ensure that any underlying functions are included in the baseline requirements for the TOE.

Health testing of the DRBGs is performed in conjunction with the self-tests required in FPT_TST_EXT.1.1.

For the selection in FCS_RBG_EXT.1.2, the ST author selects the appropriate number of bits of entropy that corresponds to the greatest security strength of the algorithms included in the ST. Security strength is defined in Tables 2 and 3 of NIST SP 800-57A. For example, if the implementation includes 2048-bit RSA (security strength of 112 bits), AES 128 (security strength 128 bits), and HMAC-SHA-256 (security strength 256 bits), then the ST author would select 256 bits.

The ST author may select either software or hardware noise sources. A hardware noise source is a component that produces data that cannot be explained by a deterministic rule, due to its physical nature. In other words, a hardware based noise source generates sequences of random numbers from a physical process that cannot be predicted. For example, a sampled ring oscillator consists of an odd number of inverter gates chained into a loop, with an electrical pulse traveling from inverter to inverter around the loop. The inverters are not clocked, so the precise time required for a complete circuit around the loop varies slightly as various physical effects modify the small delay time at each inverter on the line to the next inverter. This variance results in an approximate natural frequency that contains drift and jitter over time. The output of the ring oscillator consists of the oscillating binary value sampled at a constant rate from one of the inverters – a rate that is significantly slower than the oscillator’s natural frequency.
Documentation shall be produced and the evaluator shall perform the activities in accordance with Appendix D - Entropy Documentation And Assessment, the "Clarification to the Entropy Documentation and Assessment".

The evaluator shall verify that the API documentation provided according to Section 5.2.2 Class ADV: Development, includes the security functions described in FCS_RBG_EXT.1.3.

Assurance Activity Note: The following tests require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products.

Tests
The evaluator shall perform the following tests.

The evaluator shall perform 15 trials for the RNG implementation. If the RNG 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 RNG functionality.

If the RNG has prediction resistance enabled, each trial consists of (1) instantiate DRBG, (2) generate the first block of random bits (3) generate a second block of random bits (4) uninstantiate. The evaluator verifies that the second block of random bits is the expected value. 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 SP800-90A).

If the RNG does not have prediction resistance, each trial consists of (1) instantiate DRBG, (2) generate the first block of random bits (3) reseed, (4) generate a second block of random bits (5) uninstantiate. The evaluator verifies that the second block of random bits is the expected value. The evaluator 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 paragraphs contain 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 ࣘ 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.

#### FCS_SRV_EXT.1 Extended: Cryptographic Algorithm Services

The TSF shall provide a mechanism for applications to request the TSF to perform the following cryptographic operations:
• All mandatory and [selection: selected algorithms, selected algorithms with the exception of ECC over curve 25519-based algorithms] in FCS_CKM.2(2)
• The following algorithms in FCS_COP.1(1): AES-CBC, [selection: AES Key Wrap, AES Key Wrap with Padding, AES-GCM, AES-CCM, no other modes]
• All mandatory and selected algorithms in FCS_COP.1(3)
• All mandatory and selected algorithms in FCS_COP.1(2)
• All mandatory and selected algorithms in FCS_COP.1(4)
• [selection:
• All mandatory and [selection: selected algorithms, selected algorithms with the exception of ECC over curve 25519-based algorithms] in FCS_CKM.1,
• The selected algorithms in FCS_COP.1(5),
• No other cryptographic operations
]
Application Note: For each of the listed FCS components in the bulleted list, the intent is that the TOE will make available all algorithms specified for that component in the ST. For example, if for FCS_COP.1(2) the ST author selects SHA-256, then the TOE would have to make available an interface to perform SHA-1 (the "mandatory" portion of FCS_COP.1.1(2)) and SHA-256 (the "selected" portion of FCS_COP.1.1(2)). The exception is for FCS_COP.1(1), which does not require the TOE to make available AES_CCMP, AES_XTS, AES_GCMP-256, or AES_CCMP_256 even though they may be implemented to perform TSF-related functions. However, the ST author is expected to select (for FCS_COP.1(1) selection in this component) algorithms that match those selected in the ST for the FCS_COP.1(1) component.
The evaluator shall verify that the API documentation provided according to Section 5.2.2 Class ADV: Development includes the security functions (cryptographic algorithms) described in these requirements.

Tests
The evaluator shall write, or the developer shall provide access to, an application that requests cryptographic operations by the TSF. The evaluator shall verify that the results from the operation match the expected results according to the API documentation. This application may be used to assist in verifying the cryptographic operation assurance activities for the other algorithm services requirements.

### FCS_STG Cryptographic Storage

The following requirements describe how keys are protected. All keys must ultimately be protected by a REK, and may optionally be protected by the user’s authentication factor. Each key’s confidentiality and integrity must be protected. This section also describes the secure key storage services to be provided by the Mobile Device for use by applications and users, applying the same level of protection for these keys as keys internal to the OS.

#### FCS_STG_EXT.1 Extended: Cryptographic Key Storage

The TSF shall provide [selection: mutable hardware, software-based] secure key storage for asymmetric private keys and [selection: symmetric keys, persistent secrets, no other keys].
Application Note: A hardware keystore can be exposed to the TSF through a variety of interfaces, including embedded on the motherboard, USB, microSD, and Bluetooth.

Immutable hardware is considered outside of this requirement and will be covered elsewhere.

If the secure key storage is implemented in software that is protected as required by FCS_STG_EXT.2, the ST author shall select "software-based." If "software-based" is selected, the ST author shall select "all software-based key storage" in FCS_STG_EXT.2.

Support for secure key storage for all symmetric keys and persistent secrets will be required in future revisions.
The TSF shall be capable of importing keys/secrets into the secure key storage upon request of [selection: the user, the administrator] and [selection: applications running on the TSF, no other subjects].
Application Note: If the ST Author selects only user, the ST Author shall select function 9 in FMT_MOF_EXT.1.1.
The TSF shall be capable of destroying keys/secrets in the secure key storage upon request of [selection: the user, the administrator].
Application Note: If the ST Author selects only user, the ST Author shall select function 10 in FMT_MOF_EXT.1.1.
The TSF shall have the capability to allow only the application that imported the key/secret the use of the key/secret. Exceptions may only be explicitly authorized by [selection: the user, the administrator, a common application developer].
Application Note: If the ST Author selects user or administrator, the ST Author must also select function 34 in FMT_SMF_EXT.1.1. If the ST Author selects only user, the ST Author shall select function 34 in FMT_MOF_EXT.1.1.
The TSF shall allow only the application that imported the key/secret to request that the key/secret be destroyed. Exceptions may only be explicitly authorized by [selection: the user, the administrator, a common application developer].
Application Note: If the ST Author selects user or administrator, the ST Author must also select function 35 in FMT_SMF_EXT.1.1. If the ST Author selects only user, the ST Author shall select function 35 in FMT_MOF_EXT.1.1.
TSS
The evaluator shall review the TSS to determine that the TOE’s implements the required secure key storage. The evaluator shall ensure that the TSS contains a description of the key storage mechanism that justifies the selection of "mutable hardware" or "software-based".

Guidance
The evaluator shall review the AGD guidance to determine that it describes the steps needed to import or destroy keys/secrets. The evaluator shall also verify that the API documentation provided according to Section 5.2.2 Class ADV: Development includes the security functions (import, use, and destruction) described in these requirements. The API documentation shall include the method by which applications restrict access to their keys/secrets in order to meet FCS_STG_EXT.1.4.

Tests
The evaluator shall test the functionality of each security function:
• Test 1: The evaluator shall import keys/secrets of each supported type according to the AGD guidance. The evaluator shall write, or the developer shall provide access to, an application that generates a key/secret of each supported type and calls the import functions. The evaluator shall verify that no errors occur during import.

• Test 2: The evaluator shall write, or the developer shall provide access to, an application that uses an imported key/secret:
• For RSA, the secret shall be used to sign data.
• For ECDSA, the secret shall be used to sign data

In the future additional types will be required to be tested:
• For symmetric algorithms, the secret shall be used to encrypt data.
• For persistent secrets, the secret shall be compared to the imported secret.

The evaluator shall repeat this test with the application-imported keys/secrets and a different application’s imported keys/secrets. The evaluator shall verify that the TOE requires approval before allowing the application to use the key/secret imported by the user or by a different application:
• The evaluator shall deny the approvals to verify that the application is not able to use the key/secret as described.
• The evaluator shall repeat the test, allowing the approvals to verify that the application is able to use the key/secret as described.

If the ST Author has selected "common application developer", this test is performed by either using applications from different developers or appropriately (according to API documentation) not authorizing sharing.

• Test 3: The evaluator shall destroy keys/secrets of each supported type according to the AGD guidance. The evaluator shall write, or the developer shall provide access to, an application that destroys an imported key/secret.

The evaluator shall repeat this test with the application-imported keys/secrets and a different application’s imported keys/secrets. The evaluator shall verify that the TOE requires approval before allowing the application to destroy the key/secret imported by the administrator or by a different application:

• The evaluator shall deny the approvals and verify that the application is still able to use the key/secret as described.
• The evaluator shall repeat the test, allowing the approvals and verifying that the application is no longer able to use the key/secret as described.

If the ST Author has selected "common application developer", this test is performed by either using applications from different developers or appropriately (according to API documentation) not authorizing sharing.

#### FCS_STG_EXT.2 Extended: Encrypted Cryptographic Key Storage

The TSF shall encrypt all DEKs, KEKs, [assignment: any long-term trusted channel key material] and [selection: all software-based key storage, no other keys] by KEKs that are [selection:
• Protected by the REK with [selection:
• encryption by a REK,
• encryption by a KEK chaining from a REK,
• encryption by a KEK that is derived from a REK
]
,
• Protected by the REK and the password with [selection:
• encryption by a REK and the password-derived KEK,
• encryption by a KEK chaining to a REK and the password-derived or biometric-unlocked KEK,
• encryption by a KEK that is derived from a REK and the password-derived or biometric-unlocked KEK
]
].
Application Note: The ST author must select "all software-based key storage" if "software-based" is selected in FCS_STG_EXT.1.1. If the ST author selects "mutable hardware" in FCS_STG_EXT.1.1, the secure key storage is not subject to this requirement. REKs are not subject to this requirement.

A REK and the password-derived KEK may be combined to form a combined KEK (as described in FCS_CKM_EXT.3) in order to meet this requirement.

Sensitive data is protected by the REK and the password or biometric. Sensitive data includes some or all user or enterprise data. Software-based key storage itself shall be considered sensitive data and be protected accordingly, i.e. by the password or biometric and REK.

All keys must ultimately be protected by a REK. Sensitive data must be protected by the password or biometric (selection 2). In particular, Figure 3 has KEKs protected according to these requirements: DEK_1 meets 2a and would be appropriate for sensitive data, DEK_2 meets 1b and would not be appropriate for sensitive data, K_1 meets 1a and is not considered a sensitive key, and K_2 meets 2b and is considered a sensitive key.

Long-term trusted channel key material includes WPA2 (PSKs), IPsec (PSKs and client certificates) and Bluetooth keys. These keys shall not be protected by the password, as they may be necessary in the locked state. For clarity, the ST author must assign any Long-term trusted channel key material supported by the . At a minimum, a must support at least WPA2 and Bluetooth keys.

The documentation of the product's encryption key management should be detailed enough that, after reading, the evaluator will thoroughly understand the product's key management and how it meets the requirements to ensure the keys are adequately protected. This documentation should include an essay and diagram(s). This documentation is not required to be part of the TSS - it can be submitted as a separate document and marked as developer proprietary.
TSS
The evaluator shall review the TSS to determine that the TSS includes key hierarchy description of the protection of each DEK for data-at-rest, of software-based key storage, of long-term trusted channel keys, and of KEK related to the protection of the DEKs, long-term trusted channel keys, and software-based key storage. This description must include a diagram illustrating the key hierarchy implemented by the TOE in order to demonstrate that the implementation meets FCS_STG_EXT.2. The description shall indicate how the functionality described by FCS_RBG_EXT.1 is invoked to generate DEKs (FCS_CKM_EXT.2), the key size (FCS_CKM_EXT.2 and FCS_CKM_EXT.3) for each key, how each KEK is formed (generated, derived, or combined according to FCS_CKM_EXT.3), the integrity protection method for each encrypted key (FCS_STG_EXT.3), and the IV generation for each key encrypted by the same KEK (FCS_IV_EXT.1). More detail for each task follows the corresponding requirement.
DEKs, KEKs, [assignment: any long-term trusted channel key material] and [selection: all software-based key storage, no other keys] shall be encrypted using one of the following methods: [selection:
• using a SP800-56B key establishment scheme,
• using AES in the [selection: Key Wrap (KW) mode, Key Wrap with Padding (KWP) mode, GCM, CCM, CBC mode]
] .
Application Note: The ST author selects which key encryption schemes are used by the TOE. This requirement refers only to KEKs as defined this PP and does not refer to those KEKs specified in other standards. The ST author must assign the same Long-term trusted channel key material assigned in FCS_STG_EXT.2.1.
TSS
The evaluator shall examine the key hierarchy description in the TSS section to verify that each DEK and software-stored key is encrypted according to FCS_STG_EXT.2.

#### FCS_STG_EXT.3 Extended: Integrity of encrypted key storage

The TSF shall protect the integrity of any encrypted DEKs and KEKs and [selection: long-term trusted channel key material, all software-based key storage, no other keys] by [selection:
• [selection: GCM, CCM, Key Wrap, Key Wrap with Padding] cipher mode for encryption according to FCS_STG_EXT.2,
• a hash (FCS_COP.1(2)) of the stored key that is encrypted by a key protected by FCS_STG_EXT.2,
• a keyed hash (FCS_COP.1(4)) using a key protected by a key protected by FCS_STG_EXT.2,
• a digital signature of the stored key using an asymmetric key protected according to FCS_STG_EXT.2,
• an immediate application of the key for decrypting the protected data followed by a successful verification of the decrypted data with previously known information
].
Application Note: The ST author must assign the same Long-term trusted channel key material assigned in FCS_STG_EXT.2.1.
The TSF shall verify the integrity of the [selection: hash, digital signature, MAC] of the stored key prior to use of the key.
Application Note: This requirement is not applicable to derived keys that are not stored. It is not expected that a single key will be protected from corruption by multiple of these methods; however, a product may use one integrity-protection method for one type of key and a different method for other types of keys. The explicit Assurance Activities for each of the options will be addressed in each of the requirements (FCS_COP.1.1(2), FCS_COP.1.1(4)).

Key Wrapping shall be implemented per SP800-38F.

The documentation of the product's encryption key management should be detailed enough that, after reading, the evaluator will thoroughly understand the product's key management and how it meets the requirements to ensure the keys are adequately protected. This documentation should include an essay and diagram(s). This documentation is not required to be part of the TSS - it can be submitted as a separate document and marked as developer proprietary.
TSS
The evaluator shall examine the key hierarchy description in the TSS section to verify that each encrypted key is integrity protected according to one of the options in FCS_STG_EXT.3.

### 5.1.3 Class: User Data Protection (FDP)

#### FDP_ACF_EXT.1 Extended: Security access control

The TSF shall provide a mechanism to restrict the system services that are accessible to an application.
Application Note: Examples of system services to which this requirement applies include:

• obtain data from camera and microphone input devices
• get current GPS location
• retrieve credentials from system-wide credential store
• retrieve contacts list / address book
• retrieve stored pictures
• retrieve text messages
• retrieve emails
• retrieve device identifier information
• obtain network access
TSS
The evaluator shall ensure the TSS lists all system services available for use by an application. The evaluator shall also ensure that the TSS describes how applications interface with these system services, and means by which these system services are protected by the TSF.

The TSS shall describe which of the following categories each system service falls in:
1. No applications are allowed access
2. Privileged applications are allowed access
3. Applications are allowed access by user authorization
4. All applications are allowed access
Privileged applications include any applications developed by the TSF developer. The TSS shall describe how privileges are granted to third-party applications. For both types of privileged applications, the TSS shall describe how and when the privileges are verified and how the TSF prevents unprivileged applications from accessing those services.

For any services for which the user may grant access, the evaluator shall ensure that the TSS identifies whether the user is prompted for authorization when the application is installed, or during runtime. The evaluator shall ensure that the operational user guidance contains instructions for restricting application access to system services.

Assurance Activity Note: The following tests require the vendor to provide access to a test platform that provides the evaluator with tools that are typically not found on consumer Mobile Device products.

Tests
The evaluator shall write, or the developer shall provide, applications for the purposes of the following tests.

• Test 1: For each system service to which no applications are allowed access, the evaluator shall attempt to access the system service with a test application and verify that the application is not able to access that system service.
• Test 2: For each system service to which only privileged applications are allowed access, the evaluator shall attempt to access the system service with an unprivileged application and verify that the application is not able to access that system service. The evaluator shall attempt to access the system service with a privileged application and verify that the application can access the service.
• Test 3: For each system service to which the user may grant access, the evaluator shall attempt to access the system service with a test application. The evaluator shall ensure that either the system blocks such accesses or prompts for user authorization. The prompt for user authorization may occur at runtime or at installation time, and should be consistent with the behavior described in the TSS.
• Test 4: For each system service listed in the TSS that is accessible by all applications, the evaluator shall test that an application can access that system service.
The TSF shall provide an access control policy that prevents [selection: application, groups of applications] from accessing [selection: all, private] data stored by other [selection: application, groups of applications]. Exceptions may only be explicitly authorized for such sharing by [selection: the user, the administrator, a common application developer, no one].
Application Note: Application groups may be designated Enterprise or Personal. Applications installed by the user default to being in the Personal application group unless otherwise designated by the administrator in function 43 of FMT_SMF_EXT.1.1. Applications installed by the administrator default to being in the Enterprise application group (this category includes applications that the user requests the administrator install, for instance by selecting the application for installation through an enterprise application catalog) unless otherwise designated by the administrator in function 43 of FMT_SMF_EXT.1.1. It is acceptable for the same application to have multiple instances installed, each in different application groups. Private data is defined as data that is accessible only by the application that wrote it. Private data is distinguished from data that an application may, by design, write to shared storage areas.

If "groups of applications" is selected, FDP_ACF_EXT.2 must be included in the ST.
TSS
The evaluator shall examine the TSS to verify that it describes which data sharing is permitted between applications, which data sharing is not permitted, and how disallowed sharing is prevented. It is possible to select both "application" and "groups of application", in which case the TSS is expected to describe the data sharing policies that would be applied in each case.
Tests
• Test 1: The evaluator shall write, or the developer shall provide, two applications, one that saves data containing a unique string and the other, which attempts to access that data. If "groups of applications" is selected, the applications shall be placed into different groups. If "application" is selected, the evaluator shall install the two applications. If "private data" is selected, the application shall not write to a designated shared storage area. The evaluator shall verify that the second application is unable to access the stored unique string.

If "the user" is selected, the evaluator shall grant access as the user and verify that the second application is able to access the stored unique string.

If "the administrator" is selected, the evaluator shall grant access as the administrator and verify that the second application is able to access the stored unique string.

If "a common application developer" is selected, the evaluator shall grant access to an, application with a common application developer to the first, and verify that the application is able to access the stored unique string.

#### FDP_DAR Data-At-Rest Protection

Three levels of data-at-rest protection are addressed: TSF data, Protected Data (and keys), and sensitive data. Table 5 addresses the level of protection required for each level of data-at-rest.

Table 5: Protection of Data Levels

 Data Level Protection Required TSF Data TSF data does not require confidentiality, but does require integrity protection (FPT_TST_EXT.2(1)). Protected Data Protected data is encrypted while powered off. (FDP_DAR_EXT.1) Sensitive Data Sensitive data is encrypted while in the locked state, in addition to while powered off. (FDP_DAR_EXT.2)

All keys, protected data, and sensitive data must ultimately be protected by the REK. Sensitive data must be protected by the password in addition to the REK. In particular, Figure 3 has KEKs protected according to these requirements: DEK_1 would be appropriate for sensitive data, DEK_2 would not be appropriate for sensitive data, K_1 is not considered a sensitive key, and K_2 is considered a sensitive key.

These requirements include a capability for encrypting sensitive data received while in the locked state, which may be considered a separate sub-category of sensitive data. This capability may be met by a key transport scheme (RSA) by using a public key to encrypt the DEK while protecting the corresponding private key with a password-derived or biometric-unlocked KEK.

This capability may also be met by a key agreement scheme. To do so, the device generates a device-wide sensitive data asymmetric pair (the private key of which is protected by a password-derived or biometric-unlocked KEK) and an asymmetric pair for the received sensitive data to be stored. In order to store the sensitive data, the device-wide public key and data private key are used to generate a shared secret, which can be used as a KEK or a DEK. The data private key and shared secret are cleared after the data is encrypted and the data public key stored. Thus, no key material is available in the locked state to decrypt the newly stored data. Upon unlock, the device-wide private key is decrypted and is used with each data public key to regenerate the shared secret and decrypt the stored data. Figure 4, below, illustrates this scheme.

#### FDP_DAR_EXT.1 Extended: Protected Data Encryption

Encryption shall cover all protected data.
Application Note: Protected data is all non-TSF data, including all user or enterprise data. Some or all of this data may be considered sensitive data as well.
Encryption shall be performed using DEKs with AES in the [selection: XTS, CBC, GCM] mode with key size [selection: 128, 256] bits.
Application Note: IVs shall be generated in accordance with FCS_IV_EXT.1.1.
TSS
The evaluator shall verify that the TSS section of the ST indicates which data is protected by the DAR implementation and what data is considered TSF data. The evaluator shall ensure that this data includes all protected data.

Guidance
The evaluator shall review the AGD guidance to determine that the description of the configuration and use of the DAR protection does not require the user to perform any actions beyond configuration and providing the authentication credential. The evaluator shall also review the AGD guidance to determine that the configuration does not require the user to identify encryption on a per-file basis.

Assurance Activity Note: The following test requires the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on consumer Mobile Device products.

Tests
• Test 1: The evaluator shall enable encryption according to the AGD guidance. The evaluator shall create user data (non-system) either by creating a file or by using an application. The evaluator shall use a tool provided by the developer to verify that this data is encrypted when the product is powered off, in conjunction with Test 1 for FIA_UAU_EXT.1.

#### FDP_DAR_EXT.2 Extended: Sensitive Data Encryption

The TSF shall provide a mechanism for applications to mark data and keys as sensitive.
Application Note: Data and keys that have been marked as sensitive will be subject to certain restrictions (through other requirements) in both the locked and unlocked states of the Mobile Device. This mechanism allows an application to choose those data and keys under its control to be subject to those requirements.

In the future, this PP may require that all data and key created by applications will default to the "sensitive" marking, requiring an explicit "non-sensitive" marking rather than an explicit "sensitive" marking.
TSS
The evaluator shall verify that the TSS includes a description of which data stored by the TSF (such as by native applications) is treated as sensitive. This data may include all or some user or enterprise data and must be specific regarding the level of protection of email, contacts, calendar appointments, messages, and documents.

The evaluator shall examine the TSS to determine that it describes the mechanism that is provided for applications to use to mark data and keys as sensitive. This description shall also contain information reflecting how data and keys marked in this manner are distinguished from data and keys that are not (for instance, tagging, segregation in a "special" area of memory or container, etc.).

Tests
• Test 1: The evaluator shall enable encryption of sensitive data and require user authentication according to the AGD guidance. The evaluator shall try to access and create sensitive data (as defined in the ST and either by creating a file or using an application to generate sensitive data) in order to verify that no other user interaction is required.
The TSF shall use an asymmetric key scheme to encrypt and store sensitive data received while the product is locked.
Application Note: Sensitive data is encrypted according to FDP_DAR_EXT.1.2. The asymmetric key scheme must be performed in accordance with FCS_CKM.2(2).

The intent of this requirement is to allow the device to receive sensitive data while locked and to store the received data in such a way as to prevent unauthorized parties from decrypting it while in the locked state. If only a subset of sensitive data may be received in the locked state, this subset must be described in the TSS.

Key material must be cleared when no longer needed according to FCS_CKM_EXT.4. For keys (or key material used to derive those keys) protecting sensitive data received in the locked state, "no longer needed" includes "while in the locked state." For example, in the first key scheme, this includes the DEK protecting the received data as soon as the data is encrypted. In the second key scheme this includes the private key for the data asymmetric pair, the generated shared secret, and any generated DEKs. Of course, both schemes require that a private key of an asymmetric pair (the RSA private key and the device-wide private key, respectively) be cleared when transitioning to the locked state.
TSS
The evaluator shall review the TSS section of the ST to determine that the TSS includes a description of the process of receiving sensitive data while the device is in a locked state. The evaluator shall also verify that the description indicates if sensitive data that may be received in the locked state is treated differently than sensitive data that cannot be received in the locked state. The description shall include the key scheme for encrypting and storing the received data, which must involve an asymmetric key and must prevent the sensitive data-at-rest from being decrypted by wiping all key material used to derive or encrypt the data (as described in the application note). The introduction to this section provides two different schemes that meet the requirements, but other solutions may address this requirement.

Tests
The evaluator shall perform the tests in FCS_CKM_EXT.4 for all key material no longer needed while in the locked state and shall ensure that keys for the asymmetric scheme are addressed in the tests performed when transitioning to the locked state.
The TSF shall encrypt any stored symmetric key and any stored private key of the asymmetric key(s) used for the protection of sensitive data according to FCS_STG_EXT.2.1 selection 2.
Application Note: Symmetric keys used to encrypt sensitive data while the TSF is in the unlocked state must be encrypted with (or chain to a KEK encrypted with) the REK and password-derived or biometric-unlocked KEK. A stored private key of the asymmetric key scheme for encrypting data in the locked state must be encrypted with (or chain to a KEK encrypted with) the REK and password-derived or biometric-unlocked KEK.

The documentation of the product's encryption key management should be detailed enough that, after reading, the evaluator will thoroughly understand the product's key management and how it meets the requirements to ensure the keys are adequately protected. This documentation should include an essay and diagram(s). This documentation is not required to be part of the TSS - it can be submitted as a separate document and marked as developer proprietary.
TSS
The evaluator shall verify that the key hierarchy section of the TSS required for FCS_STG_EXT.2.1 includes the symmetric encryption keys (DEKs) used to encrypt sensitive data. The evaluator shall ensure that these DEKs are encrypted by a key encrypted with (or chain to a KEK encrypted with) the REK and password-derived or biometric-unlocked KEK.

The evaluator shall verify that the TSS section of the ST that describes the asymmetric key scheme includes the protection of any private keys of the asymmetric pairs. The evaluator shall ensure that any private keys that are not wiped and are stored by the TSF are stored encrypted by a key encrypted with (or chain to a KEK encrypted with) the REK and password-derived or biometric-unlocked KEK.
The TSF shall decrypt the sensitive data that was received while in the locked state upon transitioning to the unlocked state using the asymmetric key scheme and shall re-encrypt that sensitive data using the symmetric key scheme.
TSS
The evaluator shall verify that the TSS section of the ST that describes the asymmetric key scheme includes a description of the actions taken by the TSF for the purposes of DAR upon transitioning to the unlocked state. These actions shall minimally include decrypting all received data using the asymmetric key scheme and re-encrypting with the symmetric key scheme used to store data while the device is unlocked.

#### FDP_IFC_EXT.1 Extended: Subset information flow control

The TSF shall [selection:
• provide an interface which allows a VPN client to protect all IP traffic using IPsec,
• provide a VPN client which can protect all IP traffic using IPsec
] with the exception of IP traffic required to establish the VPN connection.
Application Note: Typically, the traffic required to establish the VPN connection is referred to as "Control Plane" traffic; whereas, the IP traffic protected by the IPsec VPN is referred to as "Data Plane" traffic. All "Data Plane" traffic must flow through the VPN connection and the VPN must not split-tunnel.

If no native IPsec client is validated or third-party VPN clients may also implement the required Information Flow Control, the first option shall be selected. In these cases, the TOE provides an API to third-party VPN clients that allow them to configure the TOE’s network stack to perform the required Information Flow Control.

The ST author shall select the second option if the TSF implements a native VPN client (IPsec is selected in FTP_ITC_EXT.1). Thus the TSF shall be validated against the IPsec Virtual Private Network (VPN) Client Extended Package and the ST author shall also include FDP_IFC_EXT from the VPN Client Extended Profile.

It is optional for the VPN client to be configured to be always-on per FMT_SMF_EXT.1 Function 45. Always-on means the establishment of an IPsec trusted channel to allow any communication by the TSF.
TSS
The evaluator shall verify that the TSS section of the ST describes the routing of IP traffic through processes on the TSF when a VPN client is enabled. The evaluator shall ensure that the description indicates which traffic does not go through the VPN and which traffic does and that a configuration exists for each baseband protocol in which only the traffic identified by the ST author as necessary for establishing the VPN connection (IKE traffic and perhaps HTTPS or DNS traffic) is not encapsulated by the VPN protocol (IPsec). The evaluator shall verify that the TSS section describes any differences in the routing of IP traffic when using any supported baseband protocols (e.g. Wi-Fi or, LTE).

Guidance
The evaluator shall verify that one (or more) of the following options is addressed by the documentation:
• The description above indicates that if a VPN client is enabled, all configurations route all Data Plane traffic through the tunnel interface established by the VPN client.
• The AGD guidance describes how the user and/or administrator can configure the TSF to meet this requirement.
• The API documentation includes a security function that allows a VPN client to specify this routing.

Tests
• Test 1: If the ST author identifies any differences in the routing between Wi-Fi and cellular protocols, the evaluator shall repeat this test with a base station implementing one of the identified cellular protocols.

Step 1: The evaluator shall enable a Wi-Fi configuration as described in the AGD guidance (as required by FTP_ITC_EXT.1). The evaluator shall use a packet sniffing tool between the wireless access point and an Internet-connected network. The evaluator shall turn on the sniffing tool and perform actions with the device such as navigating to websites, using provided applications, and accessing other Internet resources. The evaluator shall verify that the sniffing tool captures the traffic generated by these actions, turn off the sniffing tool, and save the session data.

Step 2: The evaluator shall configure an IPsec VPN client that supports the routing specified in this requirement, and if necessary, configure the device to perform the routing specified as described in the AGD guidance. The evaluator shall turn on the sniffing tool, establish the VPN connection, and perform the same actions with the device as performed in the first step. The evaluator shall verify that the sniffing tool captures traffic generated by these actions, turn off the sniffing tool, and save the session data.

Step 3: The evaluator shall examine the traffic from both step one and step two to verify that all Data Plane traffic is encapsulated by IPsec. The evaluator shall examine the Security Parameter Index (SPI) value present in the encapsulated packets captured in Step two from the TOE to the Gateway and shall verify this value is the same for all actions used to generate traffic through the VPN. Note that it is expected that the SPI value for packets from the Gateway to the TOE is different than the SPI value for packets from the TOE to the Gateway. The evaluator shall be aware that IP traffic on the cellular baseband outside of the IPsec tunnel may be emanating from the baseband processor and shall verify with the manufacturer that any identified traffic is not emanating from the application processor.

Step 4: The evaluator shall perform an ICMP echo from the TOE to the IP address of another device on the local wireless network and shall verify that no packets are sent using the sniffing tool. The evaluator shall attempt to send packets to the TOE outside the VPN tunnel (i.e. not through the VPN gateway), including from the local wireless network, and shall verify that the TOE discards them.

#### FDP_STG_EXT.1 Extended: User Data Storage

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

#### FDP_UPC_EXT.1 Extended: Inter-TSF user data transfer protection

The TSF shall provide a means for non-TSF applications executing on the TOE to use
• TLS in accordance with the Package for Transport Layer Security,
• HTTPS,
• Bluetooth BR/EDR in accordance with the PP-Module for Bluetooth,
and [selection:
• DTLS in accordance with the Package for Transport Layer Security,
• Bluetooth LE in accordance with the PP-Module for Bluetooth,
• IPsec in accordance with the PP-Module for VPN Client,
• no other protocol
] to provide a protected communication channel between the non-TSF application and another IT product that is logically distinct from other communication channels, provides assured identification of its end points, protects channel data from disclosure, and detects modification of the channel data.
Application Note: The intent of this requirement is that one of the selected protocols is available for use by user applications running on the device for use in connecting to distant-end services that are not necessarily part of the enterprise infrastructure. It should be noted that the FTP_ITC_EXT requires that all TSF communications (meaning communications from the device to a gateway) be protected using the protocols indicated in that requirement, so the protocols required by this component ride "on top of" those listed in FTP_ITC_EXT.

It should also be noted that some applications are part of the TSF, and FTP_ITC_EXT requires that TSF applications be protected by at least one of the protocols in first selection in FTP_ITC_EXT.1. It is not required to have two different implementations of a protocol, or two different protocols, to satisfy both this requirement (for non-TSF apps) and FTP_ITC_EXT (for TSF apps), as long as the services specified are provided.

The ST author shall list which trusted channel protocols are implemented by the Mobile Device for use by non-TSF apps. If the ST author selects IPsec, the TSF shall be validated against the "IPsec Virtual Private Network (VPN) Client Extended Package." Appendix B - Selection-Based Requirements contains the requirements for implementing each of the other optional trusted channel protocols. The ST author must include the security functional requirements for the trusted channel protocol selected in FDP_UPC_EXT.1 in the main body of the ST.
The TSF shall permit the non-TSF applications to initiate communication via the trusted channel.
The evaluator shall verify that the API documentation provided according to Section 5.2.2 Class ADV: Development includes the security functions (protection channel) described in these requirements, and verify that the APIs implemented to support this requirement include the appropriate settings/parameters so that the application can both provide and obtain the information needed to assure mutual identification of the endpoints of the communication as required by this component. The evaluator shall write, or the developer shall provide access to, an application that requests protected channel services by the TSF. The evaluator shall verify that the results from the protected channel match the expected results according to the API documentation. This application may be used to assist in verifying the protected channel assurance activities for the protocol requirements.

TSS
The evaluator shall examine the TSS to determine that it describes that all protocols listed in the TSS are specified and included in the requirements in the ST. The evaluator shall confirm that the operational guidance contains instructions necessary for configuring the protocol(s) selected for use by the applications.
Tests
The evaluator shall also perform the following tests:
• Test 1: The evaluators shall ensure that the application is able to initiate communications with an external IT entity using each protocol specified in the requirement, setting up the connections as described in the operational guidance and ensuring that communication is successful.
• Test 2: The evaluator shall ensure, for each communication channel with an authorized IT entity, the channel data are not sent in plaintext.

### 5.1.4 Class: Identification and Authentication (FIA)

#### FIA_AFL_EXT.1 Extended: Authentication failure handling

The TSF shall consider password and [selection: fingerprint, iris, face, voice, vein, hybrid, no other] as critical authentication mechanisms.
Application Note: A critical authentication mechanism is one in which countermeasures are triggered (i.e. wipe of the device) when the maximum number of unsuccessful authentication attempts is exceeded, rendering the other factors unavailable.

If no additional authentication mechanisms are selected in FIA_UAU.5.1, then ‘no other’ shall be selected. If an additional authentication mechanism is selected in FIA_UAU.5.1, then it shall only be selected in FIA_AFL_EXT.1.1 if surpassing the authentication failure threshold for biometric data causes a countermeasure to be triggered regardless of the failure status of the other authentication mechanisms.

If the TOE implements multiple Authentication Factor interfaces (for example, a DAR decryption interface, a lockscreen interface, an auxiliary boot mode interface), this component applies to all available interfaces. For example, a password is a critical authentication mechanism regardless of if it is being entered at the DAR decryption interface or at a lockscreen interface.
The TSF shall detect when a configurable positive integer within [assignment: range of acceptable values for each authentication mechanism] of [selection: unique, non-unique] unsuccessful authentication attempts occur related to last successful authentication for each authentication mechanism.
Application Note: The positive integer(s) is configured according to FMT_SMF_EXT.1.1 function 2.c.

An unique authentication attempt is defined as any attempt to verify a password or biometric sample, in which the input is different from a previous attempt. ‘Unique’ shall be selected if the authentication system increments the counter only for unique unsuccessful authentication attempts. For example, if the same incorrect password is attempted twice the authentication system increments the counter once. ‘Non-unique’ shall be selected if the authentication system increments the counter for each unsuccessful authentication attempt, regardless of if the input is unique. For example, if the same incorrect password is attempted twice the authentication system increments the counter twice.

If hybrid authentication (i.e. a combination of biometric and pin/password) is supported, a failed authentication attempt can be counted as a single attempt, even if both the biometric and pin/password were incorrect.

If the TOE supports multiple authentication mechanisms per FIA_UAU.5.1, this component applies to all authentication mechanisms. It is acceptable for each authentication mechanism to utilize an independent counter or for multiple authentication mechanisms to utilize a shared counter. The interaction between the authentication factors in regards to the authentication counter shall be in accordance with FIA_UAU.5.2.

If the TOE implements multiple Authentication Factor interfaces (for example, a DAR decryption interface, a lockscreen interface, an auxiliary boot mode interface), this component applies to all available interfaces. However, it is acceptable for each Authentication Factor interface to be configurable with a different number of unsuccessful authentication attempts.
The TSF shall maintain the number of unsuccessful authentication attempts that have occurred upon power off.
Application Note: The TOE may implement an Authentication Factor interface that precedes another Authentication Factor interface in the boot sequence (for example, a volume DAR decryption interface which precedes the lockscreen interface) before the user can access the device. In this situation, because the user must successfully authenticate to the first interface to access the second, the number of unsuccessful authentication attempts need not be maintained for the second interface.
When the defined number of unsuccessful authentication attempts has exceeded the maximum allowed for a given authentication mechanism, all future authentication attempts will be limited to other available authentication mechanisms, unless the given mechanism is designated as a critical authentication mechanism.
Application Note: In accordance with FIA_AFL_EXT.1.3, this requirement also applies after the TOE is powered off and powered back on.
When the defined number of unsuccessful authentication attempts for the last available authentication mechanism or single critical authentication mechanism has been surpassed, the TSF shall perform a wipe of all protected data.
Application Note: Wipe is performed in accordance with FCS_CKM_EXT.5. Protected data is all non-TSF data, including all user or enterprise data. Some or all of this data may be considered sensitive data as well.

If the TOE implements multiple Authentication Factor interfaces (for example, a DAR decryption interface, a lockscreen interface, an auxiliary boot mode interface), this component applies to all available interfaces.
The TSF shall increment the number of unsuccessful authentication attempts prior to notifying the user that the authentication was unsuccessful.
Application Note: This requirement is to ensure that if power is cut to the device directly after an authentication attempt, the counter will be incremented to reflect that attempt.
TSS
The evaluator shall ensure that the TSS describes that a value corresponding to the number of unsuccessful authentication attempts since the last successful authentication is kept for each Authentication Factor interface. The evaluator shall ensure that this description also includes if and how this value is maintained when the TOE loses power, either through a graceful powered off or an ungraceful loss of power. The evaluator shall ensure that if the value is not maintained, the interface is after another interface in the boot sequence for which the value is maintained.

If the TOE supports multiple authentication mechanisms, the evaluator shall ensure that this description also includes how the unsuccessful authentication attempts for each mechanism selected in FIA_UAU.5.1 is handled. The evaluator shall verify that the TSS describes if each authentication mechanism utilizes its own counter or if multiple authentication mechanisms utilize a shared counter. If multiple authentication mechanisms utilize a shared counter, the evaluator shall verify that the TSS describes this interaction.

The evaluator shall confirm that the TSS describes how the process used to determine if the authentication attempt was successful. The evaluator shall ensure that the counter would be updated even if power to the device is cut immediately following notifying the TOE user if the authentication attempt was successful or not.

Guidance
The evaluator shall verify that the AGD guidance describes how the administrator configures the maximum number of unique unsuccessful authentication attempts.

Tests
• Test 1: The evaluator shall configure the device with all authentication mechanisms selected in FIA_UAU.5.1. The evaluator shall perform the following tests for each available authentication interface:

Test 1a: The evaluator shall configure the TOE, according to the AGD guidance, with a maximum number of unsuccessful authentication attempts. The evaluator shall enter the locked state and enter incorrect passwords until the wipe occurs. The evaluator shall verify that the number of password entries corresponds to the configured maximum and that the wipe is implemented.

Test 1b: [conditional] If the TOE supports multiple authentication mechanisms the previous test shall be repeated using a combination of authentication mechanisms confirming that the critical authentication mechanisms will cause the device to wipe and that when the maximum number of unsuccessful authentication attempts for a non-critical authentication mechanism is exceeded, the device limits authentication attempts to other available authentication mechanisms. If multiple authentication mechanisms utilize a shared counter, then the evaluator shall verify that the maximum number of unsuccessful authentication attempts can be reached by using each individual authentication mechanism and a combination of all authentication mechanisms that share the counter.

• Test 2: The evaluator shall repeat test one, but shall power off (by removing the battery, if possible) the TOE between unsuccessful authentication attempts. The evaluator shall verify that the total number of unsuccessful authentication attempts for each authentication mechanism corresponds to the configured maximum and that the critical authentication mechanisms cause the device to wipe. Alternatively, if the number of authentication failures is not maintained for the interface under test, the evaluator shall verify that upon booting the TOE between unsuccessful authentication attempts another authentication factor interface is presented before the interface under test.

The TSF shall support the following for the Password Authentication Factor:

## H.4 SAFAR Calculation Example

Suppose the overall authentication system consists of two authentication factors: a four character password factor allowing for ten attempts and a fingerprint biometric factor with an FAR of 1:1000 allowing for five attempts.

Passwords utilize the minimum character set of 63 characters, plus one additional accepted character, making it 64. Assume each attempt is independent.

1. What is the SAFAR of each individual authentication factor, treated separately?
2. If the user can only authenticate using a single authentication factor, assuming all authentication factors available are critical and there is no possibility for the user to switch between authentication factors, what is the overall SAFAR?
3. If the user can authenticate using any authentication factor in an authentication session, and none are considered critical factors, what is the overall SAFAR?
4. If the conditions are the same as in c) but password is now a critical authentication factor that will cause a device wipe, what is the overall SAFAR?
5. If the password factor and fingerprint biometric factor are both required with the number of attempts for fingerprint increased to ten, what is the overall SAFAR? What is the risk if authentication feedback is provided for each modality (i.e. fingerprint failed or password failed)?
6. f) If the password/PIN factor and fingerprint biometric factor are both combined into a hybrid factor (both must be used and the only authentication feedback allowed is valid login or invalid login) for entry with ten attempts allowed for the hybrid factor, what is the overall SAFAR? Why is this scenario more secure than e)?

Solution:

1. The SAFAR for a four-character password allowing for ten attempts, utilizing a 64 character set, is:

$$SAFAR_{\left(password|10 attempts\right)} = 1 - \left(1 - Character set ^{length}\right)^{attempts allowed}$$ $$SAFAR_{\left(password|10 attempts\right)} = 1 - \left(1 - 64 ^{4}\right)^{10}=5.960 * 10^{-7} \left(rounded\right)$$
The SAFAR for a fingerprint biometric factor with an FAR of 1:1000, allowing for five attempts, is:

$$SAFAR_{\left(fingerprint|5 attempts\right)} = 1 - \left(1 - FAR \right)^{attempts}$$ $$SAFAR_{\left(fingerprint|5 attempts\right)} = 1 - \left(1 - 10 ^{-3}\right)^{5}=4.990 * 10^{-3} \left(rounded\right)$$
2. If the user is only allowed to pick one factor, the overall SAFAR is that of the weakest one, which is

$$SAFAR_{\left(fingerprint|5 attempts\right)} = 4.990 * 10^{-3}$$
3. If the user can authenticate using any authentication factor in an authentication session, the overall SAFAR is:

$$SAFAR_{any} = 1 - \left(1 - \left(5.96 * 10^{-7}\right)\right) * \left(1-\left(4.99 * 10 ^{-3}\right)\right)$$ $$= 4.991 * 10{-3} (rounded)$$
4. If the conditions are the same as in c) but with password as a critical factor, the worst-case scenario is the same as in c) in that the password factor is picked last, thus

$$SAFAR_{any password critical} = 4.991* 10^{-3} \left(rounded\right)$$
5. If password and fingerprint are now required factors, the SAFAR for fingerprint has to be recalculated for ten attempts:

$$SAFAR_{fingerprint|10 attempts} = 1 - \left(1-10^{-3}\right)^{10} = 9.955 * 10 ^{-3} \left(rounded\right)$$

Since the SAFAR for password with ten attempts allowed is known, it then follows that:

$$SAFAR_{fingerprint+password} = \left(5.960*10^{-7}\right) * \left(9.955*10^{-3}\right) = 5.933 * 10^{-9} \left(rounded\right)$$
The risk of providing authentication feedback is that if either authentication factor is compromised, the same sample can then be used by the adversary for every authentication after, thus reducing the SAFAR for the system to that of the other authentication factor.

6. If password/PIN and fingerprint are now combined into a single hybrid factor, the SAFAR is as follows:

$$SAFAR_{fingerprint+password|10 attempts} = 1 - \left(1-2^{-6*4}*10^{-3}\right)^{10}$$ $$=5.960 * 10 ^{-10} \left(rounded\right)$$
This is more secure than e) because not only are there less attempts overall before the maximum count is exceeded (10 instead of 20), the adversary would not know if a sample submitted for either factor results in authentication unless the presentation of both factors results in successful authentication.

# Appendix I - References

IdentifierTitle
[CC] Common Criteria for Information Technology Security Evaluation -
[CC] Common Criteria for Information Technology Security Evaluation -
[CEM] Common Evaluation Methodology for Information Technology Security - Evaluation Methodology, CCMB-2012-09-004, Version 3.1, Revision 4, September 2012.
[NFIQ 1.0] NIST Fingerprint Image Quality and relation to PIV, Tabassi, Elham. NIST Information Technology Laboratory, 2005. Retrieved June 13, 2015.
[NFIQ 2.0] Biometric Quality: The push towards zero error biometrics., Tabassi, Elham et al. International Biometrics Performance Conference (IBPC), 2016. Retrieved May 30, 2016.
[IBPC] On security evaluation of fingerprint recognition systems-- IBPC Presentation., Henniger, Scheuermann, and Kniess.International Biometric Performance Testing Conference (IBPC), 2010. Retrieved June 12, 2015.
[ISO 19989] , ISO/IEC NP 19989: Evaluation of presentation attack detection for biometrics International Organization for Standardization (ISO), 2014.
[ANSI 409.1] ANSI/CITS 409.1-2005. Biometrics Performance Testing and Reporting—Part 1: Principles and Findings." Annex B. ANSI/CITS, 2005.
[NIST] The NIST speaker recognition evaluation—Overview, methodology, systems, results, perspective, Doddington, Przybocki, Martin, and Reynolds. Speech Communication 31: Elsevier, 2000, Retrieved June 10, 2015.
[BROWN] Interval Estimation for a Binomial Proportion.Brown, Cai, and DasGupta.

# Appendix J - Acknowledgements

This protection profile was developed by the Mobility Technical Community with representatives from industry, U.S. Government agencies, Common Criteria Test Laboratories, and international Common Criteria schemes. The National Information Assurance Partnership wishes to acknowledge and thank the members of this group whose dedicated efforts contributed significantly to the publication. These organizations include:

U.S. Government
Defense Information Systems Agency (DISA)
National Information Assurance Partnership (NIAP)
National Institute of Standards and Technology (NIST)

International Common Criteria Schemes
Australasian Information Security Evaluation Program (AISEP)
Canadian Common Criteria Evaluation and Certification Scheme (CSEC)
Information-technology Promotion Agency, Japan (IPA)
UK IT Security Evaluation and Certificate Scheme (NCSC)

Industry
Apple, Inc.
BlackBerry
LG Electronics, Inc.
Microsoft Corporation
Motorola Solutions
Samsung Electronics Co., Ltd.
Other Members of the Mobility Technical Community

Common Criteria Test Laboratories