collaborative Protection Profile for Full Drive Encryption – Encryption Engine

Revision History

Contents

1 Introduction

1.1 PP Overview

Figure 1: FDE Components

1.3 Implementation

1.4 TOE Overview

1.4.1 Encryption Engine Introduction

Figure 2: Encryption Engine Details

1.4.2 Encryption Engine Security Capabilities

1.4.3 Interface/Boundary

1.5 Compliant Targets of Evaluation

1.5.1 TOE Boundary

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

T.AUTHORIZATION_GUESSING

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

T.CHOSEN_PLAINTEXT

Threat agents may trick authorized users into storing chosen plaintext on the encrypted storage device in the form of an image, document, or some other file. A poor choice of encryption algorithms, encryption modes, and initialization vectors along with the chosen plaintext could allow attackers to recover the effective DEK, thus providing unauthorized access to the previously unknown plaintext on the storage device.

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 keying material in unencrypted sectors of the storage device and on other peripherals in the operating environment (OE), (e.g., BIOS configuration, SPI flash, or TPMs).

T.KEYSPACE_EXHAUST

Threat agents may perform a cryptographic exhaustive search 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.KNOWN_PLAINTEXT

Threat agents know plaintext in regions of storage devices, especially in uninitialized regions (all zeroes) as well as regions that contain well known software such as operating systems. A poor choice of encryption algorithms, encryption modes, and initialization vectors along with known plaintext could allow an attacker to recover the effective DEK, thus providing unauthorized access to the previously unknown plaintext on the storage device.

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_FIRMWARE_MODIFY

An attacker attempts to modify the firmware of the storage device via a command from the AA or from the host platform that may compromise the security features of the TOE.

T.UNAUTHORIZED_FIRMWARE_UPDATE

An attacker attempts to replace the firmware on the storage device via a command from the AA or from the host platform with a malicious firmware update that may compromise the security features of the TOE.

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 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 storage device free of protected data in areas not targeted for encryption. It is also assumed that data intended for protection should not be on the targeted storage media until after provisioning. 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.PHYSICAL

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

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.STRONG_CRYPTO

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

A.TRAINED_USER

Users follow the provided guidance for securing the TOE and authorization factors. This includes conformance with authorization factor strength, using external token authentication factors for no other purpose and ensuring external token authorization factors are securely stored separately from the storage device or platform. The user should also be trained on how to power off their system.

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 (i.e., 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 be 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, AA, or 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 organization that uses or owns 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 than 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_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 entering a compliant power-saving state or turned off so memory remnant attacks are infeasible.

Rationale: Users are properly trained [A.TRAINED_USER] to not leave the storage device unattended until it is in a compliant power-saving state or fully turned off.

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 Operating 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).

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 should 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]
						

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))
						

5.1.2 User Data Protection

5.1.3 Security Management (FMT)

5.1.4 Protection of the TSF (FPT)

5.1.5 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 5: SFR Rationale

Threat	Addressed by	Rationale
T.AUTHORIZATION_​GUESSING	FCS_SNI_EXT.1	Mitigates this threat by requiring proper salts, which will prevent pre-computed attacks.
	FCS_VAL_EXT.1	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 against authorization factors such as passwords and PINs.
T.CHOSEN_​PLAINTEXT	FCS_COP.1/SKC	Mitigates this threat by ensuring the proper choice of encryption algorithm and mode.
	FCS_SNI_EXT.1	Mitigates this threat by ensuring proper handling of salts, nonces, and initialization vectors.
T.KEYING_​MATERIAL_​COMPROMISE	FCS_CKM.1/DEK	Mitigates this threat by ensuring that a sufficiently strong DEK is used to prevent its value from being determined.
	FCS_COP.1/SKC	Mitigates this threat by performing data encryption and decryption.
	FCS_CKM_EXT.6	Mitigates this threat by ensuring proper key material destruction.
	FCS_CKM.6/Power	Mitigates this threat by ensuring proper key material destruction for system power states.
	FCS_COP.1/Hash	Mitigates this threat by performing cryptographic hashing services.
	FCS_KYC_EXT.2	Mitigates this threat by requiring chaining of keys to accept a BEV.
	FCS_SNI_EXT.1	Mitigates this threat by requiring additional obfuscation to the protected key material by introducing IV's and salting.
	FCS_VAL_EXT.1	Mitigates this threat by defining methods for validation of keying material and number of validation attempts.
	FMT_SMF.1	Mitigates this threat by ensuring the TSF provides the functions necessary to manage important aspects of the TOE including generating new keys.
	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 material.
	FPT_PWR_EXT.2	Mitigates this threat by requiring the TOE to enter into a safe power saving state based on each condition.
	FCS_CKM.1/AKG (selection-based)	Mitigates this threat by requiring asymmetric key generation.
	FCS_CKM.6/KEK (optional)	Mitigates this threat by ensuring proper key cryptographic erase.
	FCS_CKM.1/SKG (selection-based)	Mitigates this threat by requiring symmetric cryptographic key generation.
	FCS_CKM.6/GENHW (selection-based)	Mitigates this threat by ensuring proper key material destruction in general hardware.
	FCS_CKM.6/SW (selection-based)	Mitigates this threat by ensuring proper key material destruction within the software TOE and 3rd party storage.
	FCS_CKM.6/TOEHW (selection-based)	Mitigates this threat by ensuring proper key material destruction.
	FCS_COP.1/KeyedHash (selection-based)	Mitigates this threat by performing cryptographic keyed-hash message authentication.
	FCS_COP.1/KeyEnc (selection-based)	Mitigates this threat by performing key encryption and decryption.
	FCS_COP.1/KeyWrap (selection-based)	Mitigates this threat by performing key wrapping.
	FCS_CKM.5 (selection-based)	Mitigates this threat by ensuring strong key derivation methods.
	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.
	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_CKM.1/DEK	Mitigates this threat by defining a sufficiently large keyspace such that keyspace exhaust to determine the value of the DEK is computationally infeasible.
	FCS_KYC_EXT.2	Mitigates this threat by ensuring all keys accepting 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 data encryption 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.KNOWN_​PLAINTEXT	FCS_COP.1/SKC	Mitigates this threat by ensuring the proper choice of encryption algorithm and mode.
	FCS_SNI_EXT.1	Mitigates this threat by ensuring proper handling of salts, nonces, and initialization vectors.
T.UNAUTHORIZED_​DATA_​ACCESS	FCS_COP.1/SKC	Mitigates this threat by defining proper AES encryption.
	FCS_SNI_EXT.1	Mitigates this threat by ensuring proper nonces and IVs are used in the encryption of data.
	FCS_VAL_EXT.1	Mitigates this threat by verifying the correct authentication and limits attempts to decrypt the data.
	FDP_DSK_EXT.1	Mitigates this threat by ensuring the TOE performs full drive encryption, which includes all protected data.
	FMT_SMF.1	Mitigates this threat by ensuring the TSF provides the functions necessary to manage important aspects of the TOE including requests to change and erase the DEK.
	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.
T.UNAUTHORIZED_​FIRMWARE_​MODIFY	FPT_TUD_EXT.1	Mitigates this threat by providing a mechanism used to initiate updates where the authenticity and integrity of the update can be verified as part of the update process.
	FPT_FUA_EXT.1 (selection-based)	Mitigates this threat by ensuring existing firmware cannot be modified unless replaced with a valid update initiated as part of FPT_TUD_EXT.1
T.UNAUTHORIZED_​FIRMWARE_​UPDATE	FCS_COP.1/Hash	Mitigates this threat by defining the cryptographic functions that can be used to validate the authenticity and integrity of firmware updates as defined by FPT_FUA_EXT.1.
	FCS_COP.1/SigVer	Mitigates this threat by defining the cryptographic functions that can be used to validate the authenticity and integrity of firmware updates as defined by FPT_FUA_EXT.1.
	FMT_SMF.1	Mitigates this threat by ensuring the TSF provides the functions necessary to manage important aspects of the TOE including requests to change and erase the DEK.
	FPT_TUD_EXT.1	Mitigates this threat by defining a secure mechanism for updating the TOE firmware.
	FPT_FAC_EXT.1 (optional)	Mitigates this threat by providing additional security by only allowing an update to be initiated by an authorized user.
	FPT_RBP_EXT.1 (optional)	Mitigates this threat by protecting against a malicious or inadvertent downgrade of the firmware to an earlier version that may have security flaws not present in the more recent version.
	FPT_FUA_EXT.1 (selection-based)	Mitigates this threat by forcing the use of authenticated firmware so that no arbitrary replacement of the firmware is feasible.
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 6: 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.1.2 Protection of the TSF (FPT)

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)