collaborative Protection Profile for Full Drive Encryption – Authorization Acquisition

Revision History

Contents

1 Introduction

1.1 PP Overview

The purpose of the first set of Collaborative Protection Profiles (cPPs) for Full Drive Encryption (FDE): Authorization Acquisition (AA) and Encryption Engine (EE) is to provide requirements for Data-at-Rest protection for a lost device that contains storage. These cPPs allow FDE solutions based in software and/or hardware to meet the requirements. The form factor for a storage device may vary, but could include: system hard drives/solid state drives in servers, workstations, laptops, mobile devices, tablets, and external media. A hardware solution could be a Self-Encrypting Drive or other hardware-based solutions; the interface (USB, SATA, etc.) used to connect the storage device to the host machine is outside the scope of this cPP.

Full Drive Encryption encrypts all data (with certain exceptions) on the storage device and permits access to the data only after successful authorization to the FDE solution. The exceptions include the necessity to leave a portion of the storage device (the size may vary based on implementation) unencrypted for such things as the Master Boot Record (MBR) or other AA/EE pre-authentication software. These FDE cPPs interpret the term “full drive encryption” to allow FDE solutions to leave a portion of the storage device unencrypted so long as it does not contain plaintext user or plaintext authorization data.

Since the FDE cPPs support a variety of solutions, two cPPs describe the requirements for the FDE components shown in Figure 1.

Figure 1: FDE Components

The FDE cPP - Authorization Acquisition describes the requirements for the Authorization Acquisition piece and details the security requirements and assurance activities necessary to interact with a user and result in the availability of sending a Border Encryption Value (BEV) to the Encryption Engine.

The FDE cPP - Encryption Engine describes the requirements for the Encryption Engine piece and details the necessary security requirements and assurance activities for the actual encryption/decryption of the data by the DEK. Each cPP will also have a set of core requirements for management functions, proper handling of cryptographic keys, updates performed in a trusted manner, audit and self-tests.

This TOE description defines the scope and functionality of the Authorization Acquisition, and the Security Problem Definition describes the assumptions made about the operating environment and the threats to the AA that the cPP requirements address

1.3 Implementation

Full Drive Encryption solutions vary with implementation and vendor combinations.

Therefore, vendors will evaluate products that provide both components of the Full Disk Encryption Solution (AA and EE) against both cPPs – could be done in a single evaluation with one ST. A vendor that provides a single component of a FDE solution would only evaluate against the applicable cPP. The FDE cPP is divided into two documents to allow labs to independently evaluate solutions tailored to one cPP or the other. When a customer acquires an FDE solution, they will either obtain a single vendor product that meets the AA + EE cPPs or two products, one of which meets the AA and the other of which meets the EE cPPs.

The table below illustrates a few examples for certification.

1.4 TOE Overview

The Target of Evaluation (TOE) for this cPP (Authorization Acquisition) may be either a Host software solution that manages a HW Encryption Engine (e.g. a SED) or as part of a combined evaluation of this cPP and the Encryption Engine cPP for a vendor that is providing a solution that includes both components.

The following sections provide an overview of the functionality of the FDE AA as well as the security capabilities.

1.4.1 Authorization Acquisition Introduction

The Authorization Acquisition sends a Border Encryption Value (BEV), which could be a Key Encryption Key (KEK), a Key Releasing Key (KRK), or some other type of key to the Encryption Engine. The EE does not have to use this value directly as the key to decrypt or release the DEK. It may use it as part of a scheme that uses other intermediate keys to eventually protect the DEK. A KEK wraps other keys, notably the DEK or other intermediary keys which chain to the DEK. Key Releasing Keys (KRKs) authorize the EE to release either the DEK or other intermediary keys which chain to the DEK. Figure 2 illustrates the components within AA and its relationship with EE.

Figure 2: Authorization Acquisition Details

Authorization factors may be unique to individual users or may be used by a group of individuals. In other words, the EE requires authorization factors from the AA to establish that the possessor of the authorization factor belongs to the community of users authorized to access information stored on the storage device (and does not require specific user authorization). Authorization factors are the specific value provided one of the supported authorization methods. Examples of authorization methods include, but are not limited to, passwords, passphrases, or randomly generated values stored on USB tokens or a pin to release a key on hardware storage media such as a Trusted Platform Module (TPM).

1.4.2 Authorization Acquisition Security Capabilities

The AA collects authorization factors which the EE uses to access data on the storage device and perform a variety of management functions. Depending on the type of authorization method, the AA may condition them further. For example, it may apply an approved password-based key derivation function (e.g. PBKDF2) on passwords. In this cPP passwords also encompass passphrases. An external token containing a randomly generated value of sufficient strength may require no further conditioning on the authorization factor. The AA may then combine one or more authorization factors in such a way that maintains the strength of both factors.

The AA serves as the main management interface to the EE. However, the EE may also offer management functionality. The requirements in the EE cPP address how the EE should handle these features. The management functionality may include the ability to send commands to the EE such as changing a DEK, setting up new users, managing KEKs and other intermediate keys, and performing a key sanitization (e.g. overwrite of the DEK). It may also forward commands that partition the drive for use by multiple users. However, this document defers the management of partitions and assumes that administrators will only provision and manage the data on whole drives.

1.4.3 Interface/Boundary

1.5 Compliant Targets of Evaluation

1.5.1 TOE Boundary

The environment in which the AA functions may differ depending on the boot stage of the platform in which it operates, see Figure 3. Depending on the solution’s architecture, aspects of provisioning, initialization, and authorization may be performed in the Pre-Boot environment, while encryption, decryption and management functionality are likely performed in the Operating System environment. In non-software solutions, encryption/decryption starts in Pre-OS environment and continues into OS present environment.

In the Operating System environment, the Authorization Acquisition has the full range of services available from the operating system (OS), including hardware drivers, cryptographic libraries, and perhaps other services external to the TOE.

The Pre-Boot environment is much more constrained with limited capabilities. This environment turns on the minimum number of peripherals and loads only those drivers necessary to bring the platform from a cold start to executing a fully functional operating system with running applications.

The AA TOE may include or leverage features and functions within the operational environment.

Figure 3: Operational Environment

1.6 Use Cases

2 Conformance Claims

Conformance Statement

An ST must claim exact conformance to this PP.

The evaluation methods used for evaluating the TOE are a combination of the workunits defined in [CEM] as well as the Evaluation Activities for ensuring that individual SFRs and SARs have a sufficient level of supporting evidence in the Security Target and guidance documentation and have been sufficiently tested by the laboratory as part of completing ATE_IND.1. Any functional packages this PP claims similarly contain their own Evaluation Activities that are used in this same manner.

CC Conformance Claims

This PP is conformant to Part 2 (extended) and Part 3 (conformant) of Common Criteria CC:2022, Revision 1.

PP Claim

This PP does not claim conformance to any Protection Profile.

There are no PPs or PP-Modules that are allowed in a PP-Configuration with this PP.

Package Claim

This PP is not conformant to any Functional or Assurance Packages.

3 Security Problem Definition

3.1 Threats

This section provides a narrative that describes how the requirements mitigate the mapped threats. A requirement may mitigate aspects of multiple threats. A requirement may only mitigate a threat in a limited way. Some requirements are optional, either because the TSF fully mitigates the threat without the additional requirements being claimed or because the TSF relies on its Operational Environment to provide the functionality that is described by the optional requirements.

A threat consists of a threat agent, an asset and an adverse action of that threat agent on that asset. The threat agents are the entities that put the assets at risk if an adversary obtains a lost or stolen storage device. Threats drive the functional requirements for the target of evaluation (TOE). For instance, one threat below is T.UNAUTHORIZED_DATA_ACCESS. The threat agent is the possessor (unauthorized user) of a lost or stolen storage device. The asset is the data on the storage device, while the adverse action is to attempt to obtain those data from the storage device. This threat drives the functional requirements for the storage device encryption (TOE) to authorize who can use the TOE to access the hard disk and encrypt/decrypt the data. Since possession of the KEK, DEK, intermediate keys, authorization factors, submasks, and random numbers or any other values that contribute to the creation of keys or authorization factors could allow an unauthorized user to defeat the encryption, this SPD considers key material equivalent to the data in importance and they appear among the other assets addressed below.

It is important to reemphasize at this point that this collaborative Protection Profile does not expect the product (TOE) to defend against the possessor of the lost or stolen hard disk who can introduce malicious code or exploitable hardware components into the Target of Evaluation (TOE) or the Operational Environment. It assumes that the user physically protects the TOE and that the Operational Environment provides sufficient protection against logical attacks. One specific area where a conformant TOE offers some protection is in providing updates to the TOE; other than this area, though, this cPP mandates no other countermeasures. Similarly, these requirements do not address the “lost and found” hard disk problem, where an adversary may have taken the hard disk, compromised the unencrypted portions of the boot device (e.g., MBR, boot partition), and then made it available to be recovered by the original user so that they would execute the compromised code.

T.AUTHORIZATION_GUESSING

Threat agents may exercise host software to repeatedly guess authorization factors, such as passwords and PINs. Successful guessing of an authorization factor may cause the TOE to release BEV or otherwise put it in a state in which it discloses protected data to unauthorized users.

T.KEYING_MATERIAL_COMPROMISE

Possession of any of the keys, authorization factors, submasks, and random numbers or any other values that contribute to the creation of keys or authorization factors could allow an unauthorized user to defeat the encryption. The cPP considers possession of key material of equal importance to the data itself. Threat agents may look for key material in unencrypted sectors of the storage device and on other peripherals in the operational environment (OE), (e.g., BIOS configuration, SPI flash).

T.KEYSPACE_EXHAUST

Threat agents may perform a cryptographic exhaust against the key space. Poorly chosen encryption algorithms and parameters allow attackers to exhaust the key space through brute force and give them unauthorized access to the data.

T.UNAUTHORIZED_DATA_ACCESS

The cPP addresses the primary threat of unauthorized disclosure of protected data stored on a storage device. If an adversary obtains a lost or stolen storage device (e.g., a storage device contained in a laptop or a portable external storage device), they may attempt to connect a targeted storage device to a host of which they have complete control and have raw access to the storage device (e.g., to specified disk sectors, to specified blocks).

T.UNAUTHORIZED_UPDATE

Threat agents may attempt to perform an update of the product which compromises the security features of the TOE. Poorly chosen update protocols, signature generation and verification algorithms, and parameters may allow attackers to install software or firmware that bypasses the intended security features and provides them unauthorized access to data.

3.2 Assumptions

A.INITIAL_DRIVE_STATE

Users enable Full Drive Encryption on a newly provisioned or initialized storage device free of protected data in areas not targeted for encryption. The cPP does not intend to include requirements to find all the areas on storage devices that potentially contain protected data. In some cases, it may not be possible - for example, data contained in “bad” sectors.

While inadvertent exposure to data contained in bad sectors or un-partitioned space is unlikely, one may use forensics tools to recover data from such areas of the storage device. Consequently, the cPP assumes bad sectors, un-partitioned space, and areas that must contain unencrypted code (e.g., MBR and AA/EE pre-authentication software) contain no protected data.

A.PASSWORD_STRENGTH

Authorized users ensure passwords authorization factors have sufficient strength and entropy to reflect the sensitivity of the data being protected.

A.PHYSICAL

The platform is assumed to be physically protected in its Operational Environment and not subject to physical attacks that compromise the security and/or interfere with the platform’s correct operation.

A.PLATFORM_IA

The product does not interfere with or change the normal platform identification and authentication functionality such as the operating system login. It may provide authorization factors to the operating system's login interface, but it will not change or degrade the functionality of the actual interface.

A.PLATFORM_STATE

The platform in which the storage device resides (or an external storage device is connected) is free of malware that could interfere with the correct operation of the product.

A.POWER_DOWN

The user does not leave the platform and/or storage device unattended until all volatile memory is erased after a power-off, so memory remnant attacks are infeasible.

Authorized users do not leave the platform and/or storage device in a mode where sensitive information persists in non-volatile storage (e.g., lock screen). Users power the platform and/or storage device down or place it into a power managed state, such as a “hibernation mode”.

A.SECURE_STATE

Upon the completion of proper provisioning, the TOE is only assumed secure when in a powered off state up until it is powered on and receives initial authorization.

A.SINGLE_USE_ET

External tokens that contain authorization factors are used for no other purpose than to store the external token authorization factors.

A.STRONG_CRYPTO

All cryptography implemented in the Operational Environment and used by the product meets the requirements listed in the cPP. This includes generation of external token authorization factors by a RBG.

A.TRAINED_USER

Authorized users follow all provided user guidance, including keeping passwords and external tokens securely stored separately from the storage device and/or platform.

A.TRUSTED_CHANNEL

Communication among and between product components (e.g., AA and EE) is sufficiently protected to prevent information disclosure. In cases in which a single product fulfils both cPPs, the communication between the components does not extend beyond the boundary of the TOE (e.g., communication path is within the TOE boundary) so this assumption is inherently met. In cases in which independent products satisfy the requirements of the AA and EE, the physically close proximity of the two products during their operation means that the threat agent has very little opportunity to interpose itself in the channel between the two without the user noticing and taking appropriate actions.

3.3 Organizational Security Policies

This PP defines no Organizational Security Policies.

4 Security Objectives

4.1 Security Objectives for the Operational Environment

OE.INITIAL_DRIVE_STATE

The OE provides a newly provisioned or initialized storage device free of protected data in areas not targeted for encryption.

Rationale: Since the cPP requires all protected data to encrypted, A.INITIAL_DRIVE_STATE assumes that the initial state of the device targeted FDE is free of protected data in those areas of the drive where encryption will not be invoked (e.g., MBR and AA and EE pre-authentication software). Given this known start state, the product (once installed and operational) ensures partitions of logical blocks of user accessible data is protected.

OE.PASSWORD_STRENGTH

An authorized user will be responsible for ensuring that the password authorization factor conforms to guidance from the Enterprise using the TOE.

Rationale: Users are properly trained [A.TRAINED_USER] to create authorization factors that conform to administrative guidance.

OE.PHYSICAL

The Operational Environment will provide a secure physical computing space such that an adversary is not able to make modifications to the environment or to the TOE itself.

Rationale: As stated in section 1.6, the use case for this cPP is to protect data at rest on a device where the adversary receives it in a powered off state and has no prior access.

OE.PLATFORM_IA

The Operational Environment will provide individual user identification and authentication mechanisms that operate independently of the authorization factors used by the TOE.

Rationale: While the product may provide authorization factors to the Operating system's login interface, it must not change or degrade the functionality of the actual interface. [A.PLATFORM_IA] requires that the product not interfere or change the normal platform I&A functionality.

OE.PLATFORM_STATE

The platform in which the storage device resides (or an external storage device is connected) is free of malware that could interfere with the correct operation of the product.

Rationale: A platform free of malware [A.PLATFORM_STATE] prevents an attack vector that could potentially interfere with the correct operation of the product.

OE.POWER_DOWN

Volatile memory is erased after power-off so memory remnant attacks are infeasible.

Rationale: Users are properly trained [A.TRAINED_USER] to not leave the storage device unattended until powered down or placed in a managed power state such as “hibernation mode”. [A.POWER_DOWN] stipulates that such memory remnant attacks are infeasible given the device is in a powered-down or “hibernation mode” state.

OE.SINGLE_USE_ET

External tokens that contain authorization factors will be used for no other purpose than to store the external token authorization factor.

Rationale: Users are properly trained [A.TRAINED_USER] to use external token authorization factors as intended and for no other purpose.

OE.STRONG_ENVIRONMENT_CRYPTO

The Operational Environment will provide a cryptographic function capability that is commensurate with the requirements and capabilities of the TOE and Appendix A.

Rationale: All cryptography implemented in the Operational Environment and used by the product meets the requirements listed in this cPP [A.STRONG_CRYPTO].

OE.TRAINED_USERS

Authorized users will be properly trained and follow all guidance for securing the TOE and authorization factors.

Rationale: Users are properly trained [A.TRAINED_USER] to create authorization factors that conform to guidance, not store external token authorization factors with the device, and power down the TOE when required [OE.PLATFORM_STATE] The platform in which the storage device resides (or an external storage device is connected) is free of malware that could interfere with the correct operation of the product.

A platform free of malware [A.PLATFORM_STATE] prevents an attack vector that could potentially interfere with the correct operation of the product.

OE.TRUSTED_CHANNEL

Communication among and between product components (i.e., AA and EE) is sufficiently protected to prevent information disclosure.

Rationale: In situations where there is an opportunity for an adversary to interpose themselves in the channel between the AA and the EE a trusted channel must be established to prevent exploitation. [A.TRUSTED_CHANNEL] assumes the existence of a trusted channel between the AA and EE, except for when the boundary is within and does not breach the TOE or is in such close proximity that a breach is not possible without detection.

4.2 Security Objectives Rationale

5 Security Requirements

• Refinement operation (denoted by bold text or strikethrough text): Is used to add details to a requirement or to remove part of the requirement that is made irrelevant through the completion of another operation, and thus further restricts a requirement.
• Selection (denoted by italicized text): Is used to select one or more options provided by the [CC] in stating a requirement.
• Assignment operation (denoted by italicized text): Is used to assign a specific value to an unspecified parameter, such as the length of a password. Showing the value in square brackets indicates assignment.
• Iteration operation: Is indicated by appending the SFR name with a slash and unique identifier suggesting the purpose of the operation, e.g. "/EXAMPLE1."

5.1 Security Functional Requirements

5.1.1 Cryptographic Support (FCS)

For j = 0 to 99
	A = B = C = SEED
	For i = 0 to 999
		MSG = A || B || C
		MD = SHA(MSG)
		A = B
		B = C
		C = MD
	Output MD
	SEED = MD
						

INITIAL_SEED_LENGTH = LEN(SEED)
For j = 0 to 99
	A = B = C = SEED
	For i = 0 to 999
		MSG = A || B || C
		if LEN(MSG) >= INITIAL_SEED_LENGTH:
			MSG = leftmost INITIAL_SEED_LENGTH bits of MSG
		else:
			MSG = MSG || INITIAL_SEED_LENGTH - LEN(MSG) 0 bits
		MD = SHA(MSG)
		A = B
		B = C
		C = MD
	Output MD
	SEED = MD
						

MD[0] = SEED
INITIAL_SEED_LENGTH = LEN(SEED)
For 100 iterations
	For i = 1 to 1000
		MSG = MD[i-1];
		if LEN(MSG) >= INITIAL_SEED_LENGTH:
			MSG = leftmost INITIAL_SEED_LENGTH bits of MSG
		else:
			MSG = MSG || INITIAL_SEED_LENGTH - LEN(MSG) 0 bits
		MD[i] = SHA3(MSG)
	MD[0] = MD[1000]
	Output MD[0]
						

5.1.2 Security Management (FMT)

5.1.3 Protection of the TSF (FPT)

5.1.4 TOE Security Functional Requirements Rationale

The following rationale provides justification for each SFR for the TOE, showing that the SFRs are suitable to address the specified threats:

Table 4: SFR Rationale

Threat	Addressed by	Rationale
T.AUTHORIZATION_​GUESSING	FCS_AFA_EXT.1	Mitigates this threat by requiring a set of authorization methods that will be difficult to guess.
	FCS_SNI_EXT.1	Mitigates this threat by requiring proper salts, which will prevent pre-computed attacks.
	FCS_PCC_EXT.1 (selection-based)	Mitigates this threat by requiring user-provided-factors are conditioned to increase the cost of repeatedly guessing a user provided value.
	FCS_SMC_EXT.1 (selection-based)	Mitigates this threat by requiring multi-factor authentication options, further increasing the difficulty of guessing a authentication factor.
	FCS_VAL_EXT.1 (selection-based)	Mitigates this threat by requiring several options for enforcing validation, such as key sanitization of the DEK or when a configurable number of failed validation attempts is reached within a 24 hour period. This mitigates brute force attacks.
T.KEYING_​MATERIAL_​COMPROMISE	FCS_AFA_EXT.1	Mitigates this threat by requiring the authorization methods to be accepted by the TOE.
	FCS_AFA_EXT.2	Mitigates this threat by requiring a valid authorization to decrypt the protected material.
	FCS_CKM.6	Mitigates this threat by ensuring proper key material destruction.
	FCS_CKM.6/Power	Mitigates this threat by ensuring proper key material destruction.
	FCS_COP.1/Hash	Mitigates this threat by performing cryptographic hashing services.
	FCS_KYC_EXT.1	Mitigates this threat by requiring chaining of keys to protect the BEV.
	FCS_SNI_EXT.1	Mitigates this threat by requiring additional obfuscation to the protected key material by introducing IV's and salting.
	FMT_MOF.1	Mitigates this threat by restricting the ability to modified compliant power states to authorized users.
	FMT_SMF.1	Mitigates this threat by ensuring the TSF provides the functions necessary to manage important aspects of the TOE.
	FMT_SMR.1	Mitigates this threat by assigning users with the proper account permissions and privileges.
	FPT_KYP_EXT.1	Mitigates this threat by requiring unwrapped key material is not stored in non-volatile memory.
	FPT_PWR_EXT.1	Mitigates this threat by requiring the TOE to meet a compliant power saving state that protects and/or destroys key materials.
	FPT_PWR_EXT.2	Mitigates this threat by requiring the TOE to enter into a safe state based on each condition.
	FCS_CKM.1/AKG (selection-based)	Mitigates this threat by requiring asymmetric key generation.
	FCS_CKM.5.1 (selection-based)	Mitigates this threat by requiring ensuring strong key derivation.
	FCS_PCC_EXT.1 (selection-based)	Mitigates this threat by requiring user-provided-factors are conditioned to increase the cost of repeatedly guessing a user provided value.
	FCS_CKM.1/SKG (selection-based)	Mitigates this threat by requiring symmetric cryptographic key generation.
	FCS_COP.1/KeyedHash (selection-based)	Mitigates this threat by performing keyed-hash message authentication.
	FCS_COP.1/KeyEnc (selection-based)	Mitigates this threat by performing key encryption and decryption.
	FCS_COP.1/KeyEncap (selection-based)	Mitigates this threat by performing key transport.
	FCS_COP.1/KeyWrap (selection-based)	Mitigates this threat by performing key wrapping.
	FCS_COP.1/SKC (selection-based)	Mitigates this threat by performing data encryption and encryption.
	FCS_RBG.1 (selection-based)	Mitigates this threat by randomizing the generated keys in order to reduce the likelihood of guessing the future keys.
	FCS_RBG.2 (selection-based)	Mitigates this threat by ensuring that the TOE's DRBG is seeded with sufficient entropy to ensure the generation of strong cryptographic keys.
	FCS_RBG.3 (selection-based)	Mitigates this threat by ensuring that the TOE's DRBG is seeded with sufficient entropy to ensure the generation of strong cryptographic keys.
	FCS_RBG.4 (selection-based)	Mitigates this threat by ensuring that the TOE's DRBG is seeded with sufficient entropy to ensure the generation of strong cryptographic keys.
	FCS_RBG.5 (selection-based)	Mitigates this threat by ensuring that the TOE's DRBG is seeded with sufficient entropy to ensure the generation of strong cryptographic keys.
	FCS_SMC_EXT.1 (selection-based)	Mitigates this threat by obscuring the submasks via a XOR or hashing operation.
	FCS_VAL_EXT.1 (selection-based	Mitigates this threat by defining methods for validation of a submask, intermediate key, or BEV and number of validation attempts.
	FPT_FLS.1 (selection-based)	Mitigates this threat by ensuring that a malfunctioning DRBG function cannot be used to generate potentially insecure keys.
	FPT_TST.1 (selection-based)	Mitigates this threat by verifying the cryptographic functionality through the self testing functionality.
T.KEYSPACE_​EXHAUST	FCS_KYC_EXT.1	Mitigates this threat by ensuring ensures all keys protecting the BEV are of the same strength.
	FCS_CKM.1/AKG (selection-based)	Mitigates this threat by requiring asymmetric key generation.
	FCS_CKM.1/SKG (selection-based)	Mitigates this threat by requiring symmetric cryptographic key generation.
	FCS_RBG.1 (selection-based)	Mitigates this threat by ensuring that keys used for trusted communications are generated using a secure DRBG.
	FCS_RBG.2 (selection-based)	Mitigates this threat by ensuring that the TOE's DRBG is seeded with sufficient entropy to ensure the generation of strong cryptographic keys.
	FCS_RBG.3 (selection-based)	Mitigates this threat by ensuring that the TOE's DRBG is seeded with sufficient entropy to ensure the generation of strong cryptographic keys.
	FCS_RBG.4 (selection-based)	Mitigates this threat by ensuring that the TOE's DRBG is seeded with sufficient entropy to ensure the generation of strong cryptographic keys.
	FCS_RBG.5 (selection-based)	Mitigates this threat by ensuring that the TOE's DRBG is seeded with sufficient entropy to ensure the generation of strong cryptographic keys.
	FPT_FLS.1 (selection-based)	Mitigates this threat by ensuring that a malfunctioning DRBG function cannot be used to generate potentially insecure keys.
	FPT_TST.1 (selection-based)	Mitigates this threat by verifying the cryptographic functionality through the self testing functionality.
T.UNAUTHORIZED_​DATA_​ACCESS	FCS_AFA_EXT.2	Mitigates this threat by requiring authentication to be re-entered upon return from a compliant power state.
	FMT_MOF.1	Mitigates this threat by restricting the authorized user's ability to modify compliant power states.
	FMT_SMF.1	Mitigates this threat by ensuring the TSF provides the functions necessary to manage important aspects of the TOE.
	FMT_SMR.1	Mitigates this threat by assigning users with the proper account permissions and privileges. This can be used with FMT_MOF.1 to restrict users to be able to modify certain power states covered in FMT_MOF.1.
	FPT_PWR_EXT.1	Mitigates this threat by defining what power states are compliant for the TOE.
	FPT_PWR_EXT.2	Mitigates this threat by defining conditions in which the TOE will enter a compliant power state. These requirements ensure the device is secure if lost in a compliant power state.
	FCS_VAL_EXT.1 (selection-based)	Mitigates this threat by verifying the correct authentication and limits attempts to decrypt the data.
	FPT_TST.1 (selection-based)	Mitigates by testing the behavior of the cryptographic functions through the use of the self-tests.
T.UNAUTHORIZED_​UPDATE	FCS_COP.1/SigVer	Mitigates this threat by defining the signature function that is used to verify updates.
	FMT_SMF.1	Mitigates this threat by ensuring the TSF provides the functions necessary to manage important behavior of the TOE which includes the initiation of system firmware/software updates.
	FPT_TUD_EXT.1	Mitigates this threat by providing authorized users the ability to query the current version of the TOE software/firmware, initiate updates, and verify updates prior to installation using a manufacturer digital signature.

5.2 Security Assurance Requirements

This cPP identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the documentation applicable for the evaluation and performs independent testing. Individual evaluation activities to be performed are specified within each SFR.

Note to ST authors: There is a selection in the ASE_TSS that must be completed. One cannot simply reference the SARs in this cPP.

The general model for evaluation of TOEs against STs written to conform to this cPP is as follows: after the ST has been approved for evaluation, the ITSEF will obtain the TOE, supporting environmental IT (if required), and the administrative/user guides for the TOE. The ITSEF is expected to perform actions mandated by the Common Evaluation Methodology (CEM) for the ASE and ALC SARs. The ITSEF also performs the Evaluation Activities contained within the SD, which are intended to be an interpretation of the other CEM assurance requirements as they apply to the specific technology instantiated in the TOE. The Evaluation Activities that are captured in the SD also provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the cPP.

Table 5: TOE Security Assurance Requirements

Functional Class	Functional Components
Security Target (ASE)	Conformance Claims (ASE_CCL.1)
	Extended Components Definition (ASE_ECD.1)
	ST Introduction (ASE_INT.1)
	Security Objectives for the Operational Environment (ASE_OBJ.1)
	Stated Security Requirements (ASE_REQ.1)
	Security Problem Definition (ASE_SPD.1)
	TOE Summary Specification (ASE_TSS.1)
Development (ADV)	Basic Functional Specification (ADV_FSP.1)
Guidance Documents (AGD)	Operational User Guidance (AGD_OPE.1)
	Preparative Procedures (AGD_PRE.1)
Life Cycle Support (ALC)	Labeling of the TOE (ALC_CMC.1)
	TOE CM Coverage (ALC_CMS.1)
Tests (ATE)	Independent Testing – Sample (ATE_IND.1)
Vulnerability Assessment (AVA)	Vulnerability Survey (AVA_VAN.1)

5.2.1 ASE: Security Target

The ST is evaluated as per ASE activities defined in the CEM. In addition, there may be Evaluation Activities specified within the SD that call for necessary descriptions to be included in the TSS that are specific to the TOE technology type.

The SFRs in this cPP allow for conformant implementations to incorporate a wide range of acceptable key management approaches as long as basic principles are satisfied. Given the criticality of the key management scheme, this cPP requires the developer to provide a detailed description of their key management implementation. This information can be submitted as an appendix to the ST and marked proprietary, as this level of detailed information is not expected to be made publicly available. See Appendix E for details on the expectation of the developer’s Key Management Description

In addition, if the TOE includes a random bit generator Appendix D provides a description of the information expected to be provided regarding the quality of the entropy.

ASE_TSS.1.1C The TOE summary specification shall describe how the TOE meets each SFR, including a Key Management Description (Appendix E), and [selection: Entropy Essay, list of all of 3rd party software libraries (including version numbers), 3rd party hardware components (including model/version numbers), no other cPP specified proprietary documentation].

5.2.2 ADV: Development

The design information about the TOE is contained in the guidance documentation available to the end user as well as the TSS portion of the ST, and any additional information required by this cPP that is not to be made public (e.g., Entropy Essay).

5.2.3 AGD: Guidance Documentation

The guidance documents will be provided with the ST. Guidance must include a description of how the IT personnel verifies that the Operational Environment can fulfill its role for the security functionality. The documentation should be in an informal style and readable by the IT personnel.

Guidance must be provided for every operational environment that the product supports as claimed in the ST. This guidance includes:

• Instructions to successfully install the TSF in that environment; and
• Instructions to manage the security of the TSF as a product and as a component of the larger operational environment
• Instructions to provide a protected administrative capability.

Guidance pertaining to particular security functionality must also be provided; requirements on such guidance are contained in the evaluation activities

5.2.4 Class ALC: Life-cycle Support

5.2.5 Class ATE: Tests

5.2.6 Class AVA: Vulnerability Assessment

Appendix A - Optional Requirements

A.1 Strictly Optional Requirements

A.1.1 Class ALC: Life-cycle Support

A.2 Objective Requirements

This PP does not define any Objective requirements.

A.3 Implementation-dependent Requirements

This PP does not define any Implementation-dependent requirements.

Appendix B - Selection-based Requirements

B.1 Cryptographic Support (FCS)

Key[0] = Key
IV[0] = IV
PT[0] = PT
for i = 0 to 99 {
	Output Key[i], IV[i], PT[0]
	for j = 0 to 999 {
		if (j == 0) {
			CT[j] = AES-CBC-Encrypt(Key[i], IV[i], PT[j])
			PT[j+1] = IV[i]
		} else {
			CT[j] = AES-CBC-Encrypt(Key[i], PT[j])
			PT[j+1] = CT[j-1]
		}
	}
		Output CT[j]
		AES_KEY_SHUFFLE(Key, CT)
		IV[i+1] = CT[j]
		PT[0] = CT[j-1]
}
						

AES_KEY_SHUFFLE

If ( keylen = 128 )
	Key[i+1] = Key[i] xor MSB(CT[j], 128)
If ( keylen = 192 )
	Key[i+1] = Key[i] xor (LSB(CT[j-1], 64) || MSB(CT[j], 128))
If ( keylen = 256 )
	Key[i+1] = Key[i] xor (MSB(CT[j-1], 128) || MSB(CT[j], 128))