PP-Module for File Encryption Enterprise
Management
Version: 2.0
2025-09-29
National Information Assurance Partnership
Revision History
Version Date Comment
1.0 2019-07-30 Initial Release
2.0 2025-09-29 Update to CC:2022
Contents
1 Introduction
1.1 Overview
1.2 Terms
1.2.1 Common Criteria Terms
1.2.2 Technical Terms
1.3 Compliant Targets of Evaluation
1.3.1 TOE Boundary
1.4 Use Cases
2 Conformance Claims
3 Security Problem Definition
3.1 Threats
3.2 Assumptions
3.3 Organizational Security Policies
4 Security Objectives
4.1 Security Objectives for the Operational Environment
4.2 Security Objectives Rationale
5 Security Requirements
5.1 Protection Profile for Application Software Security Functional Requirements Direction
5.1.1 Modified SFRs
5.1.1.1 Trusted Path/Channel (FTP)
5.2 TOE Security Functional Requirements
5.2.1 Cryptographic Support (FCS)
5.2.2 Identification and Authentication (FIA)
5.2.3 Security Management (FMT)
5.2.4 Protection of the TSF (FPT)
5.3 TOE Security Functional Requirements Rationale
6 Consistency Rationale
6.1 Protection Profile for Application Software
6.1.1 Consistency of TOE Type
6.1.2 Consistency of Security Problem Definition
6.1.3 Consistency of OE Objectives
6.1.4 Consistency of Requirements
Appendix A - Optional SFRs
A.1 Strictly Optional Requirements
A.2 Objective Requirements
A.3 Implementation-dependent Requirements
Appendix B - Selection-based Requirements
B.1 Cryptographic Support (FCS)
B.2 Identification and Authentication (FIA)
B.3 Trusted Path/Channels (FTP)
Appendix C - Extended Component Definitions
C.1 Extended Components Table
C.2 Extended Component Definitions
C.2.1 Cryptographic Support (FCS)
C.2.1.1 FCS_CKM_EXT Cryptographic Key Management
C.2.1.2 FCS_KYC_EXT Key Chaining and Key Storage
C.2.1.3 FCS_VAL_EXT Validation
C.2.1.4 FCS_KDF_EXT Cryptographic Key Derivation Function
C.2.1.5 FCS_SMC_EXT Submask Combining
C.2.2 Identification and Authentication (FIA)
C.2.2.1 FIA_AUT_EXT Authorization
C.2.2.2 FIA_REC_EXT Recovery Support
C.2.2.3 FIA_CHR_EXT Challenge/Response Recovery Credential
C.2.3 Protection of the TSF (FPT)
C.2.3.1 FPT_KYP_EXT Protection of Key and Key Material
Appendix D - Key Management Description
Appendix E - Acronyms
Appendix F - Bibliography
1 Introduction
1.1 Overview
The scope of the File Encryption Enterprise Management PP-Module is to describe the security functionality of a
file encryption enterprise management product in terms of [CC] and to define functional and assurance
requirements for such products. This PP-Module is intended for use with the following Base-PP
Application Software Protection Profile, Version 2.0
This Base-PP is valid because a file encryption enterprise management product is a 3rd party application. The use
case for a product conforming to the FE module is to protect data at rest on a device that is lost or stolen while
powered off without any prior access by an adversary. The use case where an adversary obtains a device that is in a
powered state and is able to make modifications to the environment or the TOE itself (e.g., evil maid attacks) is not
addressed by that module. The module does contain protections to mitigate the potential for attack with a powered
on device, but they are not sufficient to protect data from a skilled adversary with physical access.
While that use case is still true for the Enterprise Management PP-Module, this PP-module also expands the use
case to include protecting the communications between the Enterprise Management Server and the client device
through the use of a trusted channel. It also expands the use case to include the optional abilities of the EM to
interact with clients (with proper authorization), to direct it to perform sanitation of keys and material on the
device, to manage and store parts of the key chain required for decryption on the client, or to issue a recovery
credential to reset the authentication factor if it has been lost.
The TOE and Its Supporting Environment:
The environment in which the EM functions is expected to exist is on a back end server, not on the endpoint
system. It is expected to have secure access to a management system (e.g. Active Directory) and access to a means
of storing key material when not in use. The EM shall not have the ability to access the secured stored key material
without verification of access authority by the LDAP.
The Operating System environment may make a full range of services available to the Enterprise Management PP-
Module, including hardware drivers, cryptographic libraries, and perhaps other services external to the TOE. The
EM TOE may include or leverage features and functions within the operational environment.
1.2 Terms
The following sections list Common Criteria and technology terms used in this document.
1.2.1 Common Criteria Terms
Assurance Grounds for confidence that a TOE meets the SFRs [CC].
Base Protection Profile
(Base-PP)
Protection Profile used as a basis to build a PP-Configuration.
Collaborative
Protection Profile (cPP)
A Protection Profile developed by international technical communities and approved
by multiple schemes.
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.
Distributed TOE A TOE composed of multiple components operating as a logical whole.
Extended Package (EP) A deprecated document form for collecting SFRs that implement a particular protocol,
technology, or functionality. See Functional Packages.
Functional Package
(FP)
A document that collects SFRs for a particular protocol, technology, or functionality.
Operational
Environment (OE)
Hardware and software that are outside the TOE boundary that support the TOE
functionality and security policy.
Protection Profile (PP) An implementation-independent set of security requirements for a category of
products.
Protection Profile
Configuration (PP-
Configuration)
A comprehensive set of security requirements for a product type that consists of at
least one Base-PP and at least one PP-Module.
Protection Profile
Module (PP-Module)
An implementation-independent statement of security needs for a TOE type
complementary to one or more Base-PPs.
Security Assurance
Requirement (SAR)
A requirement to assure the security of the TOE.
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.
1.2.2 Technical Terms
Authorization
factor (AF)
A value that a user knows, has, or is (e.g. password, token, etc.) submitted to the TOE to
establish that the user is in the community authorized to access the requested material.
Entropy Source This cryptographic function provides a seed for a random bit generator by accumulating the
outputs from one or more noise sources. The functionality includes a measure of the
minimum work required to guess a given output and tests to ensure that the noise sources
are operating properly.
File Encryption
Key (FEK)
The key that is used by the encryption algorithm to encrypt the selected user data on the
host machine.
File/Set of files The user data that is selected to be encrypted, which can include individual file encryption
(with a FEK per file) or a set of files encrypted with a single FEK.
Key Chaining The method of using multiple layers of encryption keys to protect data. A top layer key
encrypts a lower layer key which encrypts the data; this method can have any number of
layers.
Key Encryption
Key (KEK)
The key that is used to encrypt another key.
Key Release Key A key used to release another key from storage, it is not used for the direct derivation or
decryption of another key.
Key Sanitization A method of sanitizing encrypted data by securely overwriting the key, as described in the
key destruction requirement, that was encrypting the data.
Keying Escrow The process of exporting a key to an alternate location.
Keying Material Key material is commonly known as critical security parameter (CSP) data, and also
includes authorization data, nonces, and metadata.
Noise Source The component of an RBG that contains the non-deterministic, entropy-producing activity.
Non-Volatile
Memory
A type of computer memory that will retain information without power.
Powered-Off
State
The device has been shut down.
Protected Data This refers to all files designated by the user for encryption.
Random Bit
Generator (RBG)
A cryptographic function composed of an entropy source and DRBG that is invoked for
random bits needed to produce keying material.
Recovery Value A secondary credential that can be used to validate a user in the event the primary one is
lost.
Registration The initial process of associating and endpoint and/or user with the server.
Submask A submask is a bit string that can be generated and stored in a number of ways
System Identity A composition of a series of identifiers that may vary, but aim to identity and associate with
a specific system
1.3 Compliant Targets of Evaluation
The target of evaluation for this PP-Module is the Enterprise Management (EM) function of a FE solution. The
following section provides an overview of the security functionality of this PP-module.
1.3.1 TOE Boundary
The application, which consists of the software provided by its vendor, is installed onto the platform(s) it operates
on. It executes on the platform, which may be an operating system, hardware environment, a software based
execution environment, or some combination of these. Those platforms may themselves run within other
environments, such as virtual machines or operating systems, that completely abstract away the underlying
hardware from the application. The TOE is not accountable for security functionality that is implemented by
platform layers that are abstracted away. Some evaluation activities are specific to the particular platform on which
the application runs, in order to provide precision and repeatability. The only platforms currently recognized by
[AppPP] and this module are those specified in SFR Evaluation Activities. To test on a platform for which there are
no EAs, a Vendor should contact NIAP with recommended EAs. NIAP will determine if the proposed platform is
appropriate for the PP and accept, reject, or develop EAs as necessary in coordination with the technical
community.
The TOE includes any software in the application installation package, even those pieces that may extend or
modify the functionality of the underlying platform, such as kernel drivers. BIOS and other firmware, the operating
system kernel, and other systems software (and drivers) provided as part of the platform are outside the scope of
this document.
1.4 Use Cases
[USE CASE 1] Enterprise Management
The use case for this PP-Module is protecting the communications between the Enterprise Management
Server and the client device through the use of a trusted channel. Including the optional abilities of the EM to
interact with clients (with proper authorization), to direct it to perform sanitation of keys and material on the
device, to manage and store parts of the key chain required for decryption on the client, or to issue a recovery
credential to reset the authentication factor if it has been lost.
2 Conformance Claims
Conformance Statement
An ST must claim exact conformance to this PP-Module.
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-Module is conformant to Part 2 (extended) and Part 3 (extended) of Common Criteria CC:2022,
Revision 1.
PP Claim
This PP-Module does not claim conformance to any Protection Profile.
The following PPs and PP-Modules are allowed to be specified in a PP-Configuration with this PP-Module:
PP-Module for VPN Clients, Version 3.0
PP-Module for File Encryption, Version 2.0
Package Claim
This PP-Module is Functional Package for SSH Version 2.0 conformant.
This PP-Module is Functional Package for TLS Version 2.1 conformant.
This PP-Module is Functional Package for X.509 Version 1.0 conformant.
This PP-Module does not conform to any assurance packages.
The functional packages to which the PP conforms may include SFRs that are not mandatory to claim for the
sake of conformance. An ST that claims one or more of these functional packages may include any non-
mandatory SFRs that are appropriate to claim based on the capabilities of the TSF and on any triggers for
their inclusion based inherently on the SFR selections made.
3 Security Problem Definition
The primary asset that is being protected is the sensitive user data stored on a system. The threat model thus
focuses on a host machine that has been compromised by an unauthorized user. This section addresses threats to the
TOE only.
3.1 Threats
T.KEYING_MATERIAL_COMPROMISE_SERVER
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. This PP-Module considers possession of key material of equal importance to the data itself.
Threat agents may look for key material in unencrypted storage on the Management Server and in external
databases in the operating environment (OE), e.g. SQL database.
T.MAN_IN_THE_MIDDLE
An attacker listening on the communication between the Management Server and the Client(s) to obtain the
user’s credential, keys, or recovery material.
T.UNAUTHORIZED_ADMINISTRATOR_ACCESS
An attacker masquerading as an administrator to the Management Server to gain access to TOE management
functionality to gain unauthorized access to protected data or prevent legitimate users from gaining
authorized access.
T.UNAUTHORIZED_DATA_ACCESS_ENDPOINT
An attacker accessing the data on the encrypted file(s) by getting access to a protected file(s), attaching it to a
host system controlled by the attacker and using the key material, or optionally a recovery credential to
access the data. The PP-Module for File Encryption addresses the primary threat of unauthorized disclosure
of recovery material.
T.UNAUTHORIZED_DATA_ACCESS_SERVER
An attacker accessing the Management Server and generating a recovery key chain for an endpoint. The File
Encryption PP-Module addresses the primary threat of unauthorized disclosure of data protected on the
endpoint; this adds the Management Server to the scope of the threat.
T.UNTRUSTED_COMMUNICATION_CHANNELS
An attacker targeting the Management Server using insecure tunneling protocols or the presence of an
unencrypted path to disclose keys, key material, or recovery material transferred between the endpoint and
the Management Server.
3.2 Assumptions
These assumptions are made on the Operational Environment (OE) in order to be able to ensure that the security
functionality specified in the PP-Module can be provided by the TOE. If the TOE is placed in an OE that does not
meet these assumptions, the TOE may no longer be able to provide all of its security functionality.
A.ENVIRONMENTAL_STORAGE
Any key storage mechanism provided by the Operational Environment is able to provide the same level of
security as a TOE-internal storage mechanism that is conformant to this PP-Configuration.
A.PHYSICAL_SERVER
The platform on which the Management Server resides is 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.SECURED_CONFIGURATION
The Management Server and the remote endpoints are installed and configured in accordance with their
evaluated configuration.
A.SECURED_ENVIRONMENT
Any environmental components required to support the functionality of the Management Server (e.g.
underlying operating system, firewall, database) are installed and configured in accordance with its proper
configuration.
3.3 Organizational Security Policies
An organization deploying the TOE is expected to satisfy the organizational security policy listed below in addition
to all organizational security policies defined by the claimed Base-PP.
This document does not define any additional OSPs.
4 Security Objectives
The Security Problem described in Section 3 will be addressed by a combination of cryptographic capabilities.
Compliant TOEs will provide security functionality that addresses threats to the TOE and enforces policies that are
imposed by law and regulation. The following subsections provide a description of the security objectives required
to meet the threats/policies previously discussed. The description of these security objectives are in addition to that
described in the [AppPP].
Note: in each subsection below particular security objectives are identified (highlighted by O.) and they are
matched with the associated security functional requirements (SFRs) that provide the mechanisms to satisfy the
objectives.
The Security Objectives are the requirements for the Target of Evaluation (TOE) and for the Operational
Environment derived from the threats in Section 3.
4.1 Security Objectives for the Operational Environment
OE.ENVIRONMENTAL_STORAGE
If the TOE relies on the Operational Environment for key storage, the storage mechanism will provide at
least the same level of security as a TOE-internal storage mechanism as defined by FPT_KYP_EXT.1.
OE.PHYSICAL_SERVER
The Operating environment will provide a cryptographic function capability that is commensurate with the
requirements and capabilities of the TOE as defined in FCS_KYC_EXT.1.
OE.SECURED_CONFIGURATION
The Management Server and remote endpoints are configured in accordance with its associated operational
guidance so that the level of security that is provided by the TOE is consistent with its evaluated
configuration.
OE.SECURED_ENVIRONMENT
The components of the Management Server’s underlying platform are configured in accordance with their
associated operational guidance so that the TOE is deployed in an environment that is consistent with its
evaluated configuration.
4.2 Security Objectives Rationale
This section describes how the assumptions and organizational security policies map to operational environment
security objectives.
Table 1: Security Objectives Rationale
Assumption or OSP Security Objectives Rationale
A.ENVIRONMENTAL_​
STORAGE
OE.ENVIRONMENTAL_​
STORAGE
The operational environment objective
OE.ENVIRONMENTAL_STORAGE is realized
through A.ENVIRONMENTAL_STORAGE.
A.PHYSICAL_​
SERVER OE.PHYSICAL_​
SERVER The operational environment objective
OE.PHYSICAL_SERVER is realized through
A.PHYSICAL_SERVER.
A.SECURED_​
CONFIGURATION
OE.SECURED_​
CONFIGURATION
The operational environment objective
OE.SECURED_CONFIGURATION is realized
through A.SECURED_CONFIGURATION.
A.SECURED_​
ENVIRONMENT
OE.SECURED_​
ENVIRONMENT
The operational environment objective
OE.SECURED_ENVIRONMENT is realized
through A.SECURED_ENVIRONMENT.
5 Security Requirements
This chapter describes the security requirements which have to be fulfilled by the product under evaluation. Those
requirements comprise functional components from Part 2 and assurance components from Part 3 of [CC]. The
following conventions are used for the completion of operations:
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 Protection Profile for Application Software Security Functional
Requirements Direction
The TOE is expected to rely on some of the security functions implemented by the application as a whole and
evaluated against [AppPP]. The following section describe any modifications that the ST author must make to the
SFRs defined in the Base-PP in addition to what is mandated by section 5.2.
5.1.1 Modified SFRs
The SFRs listed in this section are defined in the App PP and relevant to the secure operation of the TOE.
5.1.1.1 Trusted Path/Channel (FTP)
FTP_DIT_EXT.1: Protection of Data in Transit
This SFR is modified from its definition in the Base-PP by removing the first selection (where the
application does not transmit any data or sensitive data). By definition, a TOE that conforms to this PP-
Module must have the ability to transmit sensitive data to another trusted IT product.
The text of the requirement is replaced with:
The application shall [selection:
encrypt all transmitted [selection, choose one of: sensitive data, data] with [selection:
HTTPS as a client in accordance with FCS_HTTPS_EXT.1
HTTPS as a server in accordance with FCS_HTTPS_EXT.1
TLS as a server as defined in Functional Package for TLS and also supports functionality for
[selection: mutual authentication, none]
TLS as a client as defined in Functional Package for TLS
DTLS as a server as defined in Functional Package for TLS and also supports functionality for
[selection: mutual authentication,none]
DTLS as a client as defined in Functional Package for TLS
SSH as defined in the Functional Package for Secure Shell
IPsec as defined in the VPN Client PP-Module, version 3.0
] for [assignment: function(s)] using certificates as defined in the Functional Package for X.509
invoke platform-provided functionality to encrypt all transmitted sensitive data with [selection: HTTPS,
TLS, DTLS, SSH, IPsec] for [assignment: function(s)] using certificates as defined in the Functional
Package for X.509
invoke platform-provided functionality to encrypt all transmitted data with [selection: HTTPS, TLS,
DTLS, SSH, IPsec] for [assignment: function(s)] using certificates as defined in the Functional Package
for X.509
] between itself and another trusted IT product.
5.2 TOE Security Functional Requirements
The following section describes the SFRs that must be satisfied by any TOE that claims conformance to this PP-
Module. These SFRs must be claimed regardless of which PP-Configuration is used to define the TOE.
5.2.1 Cryptographic Support (FCS)
FCS_CKM.6 Cryptographic Key Destruction
FCS_CKM.6.1
The TSF shall destroy [all keys and key material] when no longer needed.
Application Note: Keys, including intermediate keys and key material that are no
longer needed are destroyed by using an approved method, FCS_CKM.6.2.
Examples of keys are intermediate keys, submasks. There may be instances where
keys or key material that are contained in persistent storage are no longer needed and
require destruction. Base on their implementation, vendors will explain when certain
keys are no longer needed. There are multiple situations in which key material is no
longer necessary, for example, a wrapped key may need to be destroyed when a
password is changed. However, there are instances when keys are allowed to remain
in memory, for example, a device identification key. If a PIN was used for a smart
card and managed by the TOE, ensuring that the PIN was properly destroyed must
be addressed.
FCS_CKM.6.2
The TSF shall destroy cryptographic keys and keying material specified by
FCS_CKM.6.1 in accordance with a specified cryptographic key destruction method
[[selection:
For volatile memory, the destruction shall be executed by a [selection:
single overwrite consisting of [selection: a pseudo-random pattern
using the TSF's RBG, zeroes, ones, new value of a key, [assignment: any
value that does not contain any CSP]]
removal of power to the memory
destruction of reference to the key directly followed by a request for
garbage collection
]
For non-volatile memory, the destruction shall be executed by [selection:
destruction of all KEKs protecting the target key, where none of the
KEKs protecting the target key are derived
the invocation of an interface provided by the underlying platform that
[selection:
logically addresses the storage location of the key and performs a
[selection: single, [assignment: ST author defined multi-pass]]
overwrite consisting of [selection: a pseudo-random pattern using
the TSF's RBG, zeroes, ones, new value of a key, [assignment:
any value that does not contain any CSP]]
instructs the underlying platform to destroy the abstraction that
represents the key
]
]
]] that meets the following: [no standard].
Application Note: The interface referenced in the requirement could take different
forms, the most likely of which is an application programming interface to an OS
kernel. There may be various levels of abstraction visible. For instance, in a given
implementation that overwrites a key stored in non-volatile memory, the application
may have access to the file system details and may be able to logically address
specific memory locations. In another implementation that instructs the underlying
platform to destroy the representation of a key stored in non-volatile memory, the
application may simply have a handle to a resource and can only ask the platform to
delete the resource, as may be the case with a platforms secure key store. The latter
implementation should only be used for the most restricted access. The level of
detail to which the TOE has access will be reflected in the TSS section of the ST.
Several selections allow assignment of a 'value that does not contain any CSP'. This
means that the TOE uses some other specified data not drawn from a source that may
contain key material or reveal information about key material, and not being any of
the particular values listed as other selection options. The point of the phrase 'does
not contain any CSP' is to ensure that the overwritten data is carefully selected, and
not taken from a general 'pool' that might contain current or residual data that itself
requires confidentiality protection.
For the selection "destruction of all KEKs protecting target key, where none of the
KEKs protecting the target key are derived", a key can be considered destroyed by
destroying the key that protects the key. If a key is wrapped or encrypted it is not
necessary to "overwrite" that key, overwriting the key that is used to wrap or encrypt
the key used to encrypt/decrypt data, using the appropriate method for the memory
type involved, will suffice. For example, if a product uses a Key Encryption Key
(KEK) to encrypt a File Encryption Key (FEK), destroying the KEK using one of the
methods in FCS_CKM.6 is sufficient, since the FEK would no longer be usable (of
course, presumes the FEK is still encrypted and the KEK cannot be recovered or re-
derived).
Evaluation Activities
FCS_CKM.6
TSS
The evaluator shall verify the TSS provides a high level description of what it means for keys and
key material to be no longer needed and when they should be expected to be destroyed. The
evaluator shall verify the TSS provides a high level description of what it means for keys and key
material to be no longer needed and when then should be expected to be destroyed.
KMD
The evaluator examines the KMD to ensure it describes how the keys are managed in volatile
memory. This description includes details of how each identified key is introduced into volatile
memory (e.g. by derivation from user input, or by unwrapping a wrapped key stored in non-volatile
memory) and how they are overwritten.
The evaluator shall check to ensure the KMD lists each type of key that is stored in in non-volatile
memory, and identifies how the TOE interacts with the underlying platform to manage keys (e.g.,
store, retrieve, destroy). The description includes details on the method of how the TOE interacts
with the platform, including an identification and description of the interfaces it uses to manage keys
(e.g., file system APIs, platform key store APIs).
The evaluator examines the interface description for each different media type to ensure that the
interface supports the selection(s) and description in the KMD.
If the ST makes use of the open assignment and fills in the type of pattern that is used, the evaluator
examines the KMD to ensure it describes how that pattern is obtained and used. The evaluator shall
verify that the pattern does not contain any CSPs.
The evaluator shall check that the KMD identifies any configurations or circumstances that may not
strictly conform to the key destruction requirement.
If the selection "destruction of all KEKs protecting target key, where none of the KEKs protecting the
target key are derived" is included the evaluator shall examine the TOE's keychain in the KMD and
identify each instance when a key is destroyed by this method. In each instance the evaluator shall
verify all keys capable of decrypting the target key are destroyed in accordance with a specified key
destruction method in FCS_CKM.6.2. The evaluator shall verify that all of the keys capable of
decrypting the target key are not able to be derived to reestablish the keychain after their
destruction.
The evaluator shall verify the KMD includes a description of the areas where keys and key material
reside and when the keys and key material are no longer needed.
The evaluator shall verify the KMD includes a key lifecycle, that includes a description where key
material reside, how the key material is used, how it is determined that keys and key material are no
longer needed, and how the material is destroyed once it is not needed and that the documentation
in the KMD follows FCS_CKM.6.2 for the destruction.
Guidance
There are a variety of concerns that may prevent or delay key destruction in some cases.
The evaluator shall check that the guidance documentation identifies configurations or
circumstances that may not strictly conform to the key destruction requirement, and that this
description is consistent with the relevant parts of the TSS and any other relevant Required
Supplementary Information.
The evaluator shall check that the guidance documentation provides guidance on situations where
key destruction may be delayed at the physical layer and how such situations can be avoided or
mitigated if possible.
Some examples of what is expected to be in the documentation are provided here.
When the TOE does not have full access to the physical memory, it is possible that the storage may
be implementing wear-leveling and garbage collection. This may create additional copies of the key
that are logically inaccessible but persist physically. In this case, to mitigate this the drive should
support the TRIM command and implements garbage collection to destroy these persistent copies
when not actively engaged in other tasks.
Drive vendors implement garbage collection in a variety of different ways, as such there is a
variable amount of time until data is truly removed from these solutions. There is a risk that data
may persist for a longer amount of time if it is contained in a block with other data not ready for
erasure. To reduce this risk, the operating system and file system of the OE should support TRIM,
instructing the non-volatile memory to erase copies via garbage collection upon their deletion. If a
RAID array is being used, only set-ups that support TRIM are utilized. If the drive is connected via
PCI-Express, the operating system supports TRIM over that channel.
The drive should be healthy and contain minimal corrupted data and should be at end-of-life before
a significant amount of damage to drive health occurs, this minimizes the risk that small amounts of
potentially recoverable data may remain in damaged areas of the drive.
Tests
These tests are only for key destruction provided by the application, test 2 does not apply to any keys
using the selection "new value of a key":
Test FCS_CKM.6:1: Applied to each key held in volatile memory and subject to destruction by
overwrite by the TOE (whether or not the value is subsequently encrypted for storage in
volatile or non-volatile memory). In the case where the only selection made for the key
destruction method 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 cause the TOE or the underlying platform to dump 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.
Steps #1-6 ensure that the complete key does not exist anywhere in volatile memory. If a copy
is found, then the test fails.
Test FCS_CKM.6:2: [Conditional] If new value of a key is selected this test does not apply.
Applied to each key held in non-volatile memory and subject to destruction by the TOE.
The evaluator shall use special tools (as needed), provided by the TOE developer if necessary,
to ensure the tests function as intended.
1. Identify the purpose of the key and what access should fail when it is deleted. (e.g. the
file encryption key being deleted would cause data decryption to fail.)
2. Cause the TOE to clear the key.
3. Have the TOE attempt the functionality that the cleared key would be necessary for.
4. The test succeeds if Step #3 fails.
Tests 3 and 4 do not apply for the selection instructing the underlying platform to destroy the
representation of the key, as the TOE has no visibility into the inner workings and completely
relies on the underlying platform.
Test FCS_CKM.6:3: Applied to each key held in non-volatile memory and subject to
destruction by overwrite by the TOE. The evaluator shall use a tool that provides a logical
view of the media (e.g., MBR file system):
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 logical view that the key was stored in for instances of the known key value
from Step #1. If a copy is found, then the test fails.
Test FCS_CKM.6:4: Applied to each key held in non-volatile memory and subject to
destruction by overwrite by the TOE. The evaluator shall use a tool that provides a logical
view of the media:
1. Record the logical 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 logical 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_KYC_EXT.1 Key Chaining and Key Storage
FCS_KYC_EXT.1.1
The TSF shall maintain a key chain of [intermediate keys] originating from [one or
more initial [selection: submask(s), recovery value(s)]] to [the final value returned
to the endpoint] using the following method(s): [selection:
utilization of the platform key storage
utilization of platform key storage that performs key wrap with a TSF provided
key
implementation of key establishment as specified in FCS_CKM.2 (from the
Base-PP)
implementation of key derivation as specified in FCS_KDF_EXT.1
implementation of key wrapping as specified in FCS_COP.1/KW
implementation of key encryption as specified in FCS_COP.1/KE
implementation of key combining as specified in FCS_SMC_EXT.1
implementation of key transport as specified in FCS_COP.1/KT
] while maintaining an effective strength of commensurate with the strength of the
FEK and [selection:
no supplemental key chains
other supplemental key chains that protect a key or keys in the primary key
chain using the following method(s): [selection:
utilization of the platform key storage
utilization of platform key storage that performs key wrap with a TSF
provided key
implementation of key establishment as specified in FCS_CKM.2 (from
the Base-PP)
implementation of key encryption as specified in FCS_COP.1/KE
implementation of key transport as specified in FCS_COP.1/KT
implementation of key wrapping as specified in FCS_COP.1/KW
implementation of key derivation as specified in FCS_KDF_EXT.1
implementation of key combining as specified in FCS_SMC_EXT.1
]
].
Application Note: Key Chaining is the method of using multiple layers of
encryption keys to ultimately secure the a final key. The number of intermediate keys
will vary. The ST Author should clearly indicate which portions of the key chain are
created and maintained by the enterprise server and which are created and
maintained by the endpoint. This requirement is in addition to the same requirement
in the PP-Module for File Encryption, it covers a different section of the keychain, if
both modules are included both requirements must be included.
Evaluation Activities
FCS_KYC_EXT.1
TSS
The evaluator shall verify the TSS contains a high-level description of the key sizes that it supports
key outputs of no fewer 128 bits for products that support only AES128, and no fewer than 256 bits
for products that support AES-256. The evaluator shall verify the TSS contains a description of the
controls preventing a key from being provided to the endpoint before validation has occurred.
The evaluator shall verify the TSS includes a description of the key chain used to protect encryption
keys associated with endpoints. The description of the key chains shall be reviewed to ensure it
maintains a chain of keys using the methods listed in the SFR.
The evaluator shall ensure the chain of keys is maintained from the authorization factor or recovery
value to the value returned to the endpoint. The evaluator shall examine the TSS to ensure that it
describes how the key chain process functions, such that it does not expose any material that might
compromise any key in the chain. This description must include a diagram illustrating the key chain
implemented and detail where all keys and keying material is stored or what it is derived from. The
evaluator shall examine the key chain to ensure that at no point the chain could be broken without a
cryptographic exhaust, the initial authorization value, recovery value or a compromise of the TOE
server and the effective strength of the keys are maintained throughout the key chain.
KMD
None.
Guidance
If there are configurations to enable or disable use of enterprise server, which modify the key chain,
they shall be described. If there are configurations on to enable recovery mechanisms, they shall be
described.
Tests
None.
FCS_VAL_EXT.1/Admin Validation (Server Administrator)
FCS_VAL_EXT.1.1/Admin
The TSF shall perform validation of the [admin] by [selection:
receiving assertion of the subject's validity from [assignment: Operational
Environment component responsible for authentication]
validating the [selection: submask, intermediate key] using the following
methods: [selection:
key wrap as specified in FCS_COP.1/KW
hash the [selection: submask, intermediate key, FEK] as specified in
FCS_COP.1/Hash (from [AppPP]) and compare it to a stored hash
decrypt a known value using the [selection: submask, intermediate key,
FEK] as specified in FCS_COP.1/SKC (from [AppPP]) and compare it
against a stored known value
]
].
FCS_VAL_EXT.1.2/Admin
The TSF shall require validation of the [admin] prior to [permitting the actions
described in FMT_MTD.1.1 and FMT_SMF.1.1/FEEM].
Application Note: This PP-Module performs validation of any administrator
credential on the management server, as described in FIA_AUT_EXT.1.1, used to
log in to the EM in accordance with this SFR.
Evaluation Activities
FCS_VAL_EXT.1/Admin
TSS
Conditional:
If 'validating' is selected, the evaluator shall examine the TSS to determine that it states which
authorization factors support validation.
The evaluator shall also examine the TSS to ensure that it includes a high-level description of how
how the submasks are validated. If multiple submasks are used within the TOE, the evaluator shall
confirm that the TSS describes how each is validated (e.g., each submask validated before
combining, once combined validation takes place).
Conditional:
If 'receiving assertion of the subject's validity' is selected, the evaluator shall examine the TSS to
verify that it describes the environments that can be leveraged with the TOE and how each claims to
perform validation. The evaluator shall also ensure that none of the stated platform validation
mechanisms weaken the key chain of the product.
KMD
None.
Guidance
If the validation functionality is configurable, the evaluator shall examine the operational guidance
to ensure it describes how to configure the TOE to ensure the limits regarding validation attempts
can be established.
Tests
There are no test activities for this requirement.
FCS_VAL_EXT.1/User Validation (User)
FCS_VAL_EXT.1.1/User
The TSF shall perform validation of the [user] by [selection:
receiving assertion of the subject's validity from [assignment: Operational
Environment component responsible for authentication]
validating the [selection: submask, intermediate key] using the following
methods: [selection:
key wrap as specified in FCS_COP.1/KW
hash the [selection: submask, intermediate key, FEK] as specified in
FCS_COP.1/Hash (from [AppPP]) and compare it to a stored hash
decrypt a known value using the [selection: submask, intermediate key,
FEK] as specified in FCS_COP.1/SKC (from [AppPP]) and compare it
against a stored known value
]
].
FCS_VAL_EXT.1.2/User
The TSF shall require validation of the [user] prior to [transmitting submasks, FEKs,
or keys to decrypt FEKs to the endpoint].
Application Note: This references the validation of an endpoint user to the server.
These activities are performed by the server.
Evaluation Activities
FCS_VAL_EXT.1/User
TSS
The evaluator shall examine the TSS to determine which component of the Operational Environment
is used to assert the User’s identity.
The evaluator shall examine the TSS to determine how the TOE responds to an assertion by the
Operational Environment. The evaluator shall examine the TSS to verify that it describes how
validation is performed. The evaluator shall verify the TSS ensures that the validation process does
not expose any material that might compromise key material or expose protected data.
KMD
None.
Guidance
The evaluator shall examine the operational guidance to ensure it describes how to configure the
TOE and Operational Environment to enable the OE to provide User identity assertions to the TOE.
(conditional) If the number of User authentication attempts is configurable in the TOE, the examiner
shall examine the operational guidance to ensure it describes how to configure the TOE.
Tests
The evaluator shall perform the following tests:
Test FCS_VAL_EXT.1/User:1: The evaluator shall determine the limit on the average rate of
the number of consecutive failed authorization attempts. The evaluator will test the TOE by
entering that number of incorrect authorization factors in consecutive attempts to access the
protected data. If the limit mechanism includes any “lockout” period, the time period tested
should include at least one such period. Then the evaluator will verify that the TOE behaves
as described in the TSS.
Test FCS_VAL_EXT.1/User:2: For each validated authorization factor, ensure that when the
user provides an incorrect authorization factor, the TOE prevents FEKs or keys that decrypt
FEKs from being forwarded to the endpoint.
FCS_VAL_EXT.2/User Validation Remediation (User)
FCS_VAL_EXT.2.1/User
The TSF shall [selection:
institute a delay such that only [assignment: ST author specified number or
configurable range of] validation attempts can be made within a 24 hour
period
block validation after [assignment: ST author specified number or
configurable range of] consecutive failed validation attempts
[terminate the session] upon [assignment: ST author specified number or
configurable range of] consecutive failed validation attempts
[[selection: direct the endpoint to perform key sanitization, perform key
sanitization] of FEK(s) or an intermediate key] upon [assignment: ST
specified number or configurable range of] consecutive failed validation
attempts
].
Evaluation Activities
FCS_VAL_EXT.2/User
TSS
This SFR is evaluated through the activities defined for FCS_VAL_EXT.1/User.
KMD
None.
Guidance
This SFR is evaluated through the activities defined for FCS_VAL_EXT.1/User.
Tests
This SFR is evaluated through the activities defined for FCS_VAL_EXT.1/User.
5.2.2 Identification and Authentication (FIA)
FIA_AUT_EXT.1 Subject Authorization
FIA_AUT_EXT.1.1
The TSF shall [selection: receive assertion of the user’s validity from: [assignment:
Operational Environment component responsible for user authentication], provide
authorization] based on [selection:
a password authorization factor conditioned as defined in FCS_CKM_EXT.6
an external smart card factor that is at least the same bit-length as the FEK(s),
and is protecting a submask that is [selection: generated by the TOE (using
the RBG as specified in FCS_RBG_EXT.1 (from [AppPP])), generated by the
platform] protected using asymmetric keys as defined in FCS_CKM.1.1/AK
(from [AppPP]) with user presence proved by presentation of the smart card
and [selection: no PIN, an OE defined PIN, a configurable PIN]
an external USB token factor that is at least the same security strength as the
FEK(s), and is providing a submask generated by the [selection: TOE, using
the RBG as specified in FCS_RBG_EXT.1 (from [AppPP]), platform]
].
Application Note: This applies to the authorization of administrators on the
enterprise server.
FCS_RBG_EXT.1 is in the Application Software Protection Profile.
This requirement specifies what authorization factors the TOE accepts from the user.
A password entered by the user is one authorization factor that the TOE must be able
to condition, as specified in FCS_CKM_EXT.6. Another option is a smart card
authorization factor, with the differentiating feature being how the value is generated
– either by the TOE’s RBG or by the platform. An external USB token may also be
used, with the submask value generated either by the TOE’s RBG or by the platform.
The TOE may accept any number of authorization factors, and these are categorized
as “submasks”. The ST author selects the authorization factors they support, and
there may be multiple methods for a selection.
Use of multiple authorization factors is preferable; if more than one authorization
factor is used, the submasks produced must be combined using FCS_SMC_EXT.1.
Evaluation Activities
FIA_AUT_EXT.1
The evaluation activities for this component will be driven by the selections made by the ST author.
This section describes evaluation activities for all possible selections in an ST; it should be
understood that if a capability is not selected in the ST, the noted assurance activity does not need to
be performed.
TSS
The evaluator shall examine the TSS to ensure that it describes how user authentication is
performed. The evaluator shall verify that the authorization methods listed in the TSS are specified
and included in the requirements in the ST.
Requirement met by the TOE:
The evaluator shall first examine the TSS to ensure that the authorization factors specified in the ST
are described. For password-based factors the examination of the TSS section is performed as part
of FCS_CKM_EXT.6 Evaluation Activities. Additionally in this case, the evaluator shall verify that
the operational guidance discusses the characteristics of external authorization factors (e.g., how
the authorization factor must be generated; format(s) or standards that the authorization factor must
meet) that are able to be used by the TOE.
If other authorization factors are specified, then for each factor, the TSS specifies how the factors
are input into the TOE.
Requirement met by the OE:
The evaluator shall examine the TSS to ensure a description is included for how the TOE is invoking
the OE functionality and how it is getting an authorization value that has appropriate entropy.
KMD
None.
Guidance
The evaluator shall verify that the AGD guidance includes instructions for all of the authorization
factors. The AGD will discuss the characteristics of external authorization factors (e.g., how the
authorization factor is generated; format(s) or standards that the authorization factor must meet,
configuration of the TPM device used) that are able to be used by the TOE.
Tests
The evaluator shall ensure that authorization using each selected method is tested during the course
of the evaluation, setting up the method as described in the operational guidance and ensuring that
authorization is successful and that failure to provide an authorization factor results in denial to
access to plaintext data.
[conditional]: If there is more than one authorization factor, ensure that failure to supply a required
authorization factor does not result in access to the decrypted plaintext data.
FIA_REC_EXT.1 Recovery Support
FIA_REC_EXT.1.1
The TSF shall [selection: provide the ability to enable and disable the use of
recovery credentials, not support recovery].
FIA_REC_EXT.1.2
The TSF shall support the following recovery mechanisms [selection: Challenge
Response Recovery as defined in FIA_CHR_EXT.1, None].
Application Note: This requirement defines the recovery options supported between
the endpoint(s) and the enterprise server. This does not prevent the OE from
providing recovery if the OE is managing the authentication of the users.
Evaluation Activities
FIA_REC_EXT.1
TSS
The evaluator shall examine the TSS to determine that types of supported recovery credential are
specified.
KMD
None.
Guidance
The evaluator shall confirm that the guidance documentation contains instructions for turning off
the ability of the server to return a recovery credential.
Tests
The evaluator shall disable the ability of a server to return a recovery credential. The evaluator
should then attempt to obtain the recovery credential and this should fail.
FIA_UAU.1 Timing of Authentication
FIA_UAU.1.1
The TSF shall allow [assignment: list of TSF-mediated actions] on behalf of the
administrator to be performed before the administrator is authenticated.
FIA_UAU.1.2
The TSF shall require each administrator to be successfully authenticated before
allowing any other TSF-mediated actions on behalf of that administrator.
Application Note: This requirement defines the timing of administrator capabilities
on the enterprise server.
Evaluation Activities
FIA_UAU.1
TSS
The evaluator shall examine the TSS to determine that it describes the list of actions that are
performed on behalf of the administrator prior to login of the administrator. The evaluator shall
examine the TSS to determine that it describes the list of actions that require administrator
authentication.
KMD
None.
Guidance
The evaluator shall examine the guidance documentation to determine that any necessary
preparatory steps (e.g., establishing credential material such as pre- shared keys, tunnels,
certificates, etc.) to logging in are described. For each supported login method, the evaluator shall
ensure the guidance documentation provides clear instructions for successfully logging on. If
configuration is necessary to ensure the services provided before login are limited, the evaluator
shall determine that the guidance documentation provides sufficient instruction on limiting the
allowed services.
Tests
The evaluator shall perform the following tests:
Test FIA_UAU.1:1: The evaluator shall verify that the list of actions allowed without
administrator login completes successfully without requiring administrator login and make
sure this list is consistent with the TSS.
Test FIA_UAU.1:2: The evaluator shall verify that attempting any other action requires
successful entry of an administrator credential.
Test FIA_UAU.1:3: The evaluator shall use the guidance documentation to configure the
appropriate credential supported for the login method. For that credential/login method, the
evaluator shall show that providing correct I&A information results in the ability to access the
system, while providing incorrect information results in denial of access.
Test FIA_UAU.1:4: The evaluator shall configure the services allowed (if any) according to
the guidance documentation, and then determine the services available to an external remote
entity. The evaluator shall determine that the list of services available is limited to those
specified in the requirement.
FIA_UID.1 Timing of Identification
FIA_UID.1.1
The TSF shall allow [assignment: list of TSF-mediated actions] on behalf of the
administrator to be performed before the administrator is identified.
FIA_UID.1.2
The TSF shall require each administrator to be successfully identified before
allowing any other TSF-mediated actions on behalf of that administrator.
Application Note: This requirement defines the timing of administrator capabilities
on the enterprise server.
Evaluation Activities
FIA_UID.1
TSS
The evaluator shall examine the TSS to determine that it describes the list of actions that are
performed on behalf of the administrator prior to identification of the administrator.
KMD
None.
Guidance
The evaluator shall examine the guidance documentation to determine that any necessary
preparatory steps for creating and configuring administrator accounts are described.
Tests
The evaluator shall perform the following tests:
Test FIA_UID.1:1: The evaluator shall verify that the list of actions allowed without
administrator identification completes successfully without requiring the administrator to be
identified and make sure this list is consistent with the TSS.
Test FIA_UID.1:2: The evaluator shall verify that attempting any other action requires
successful entry of an administrator account name and successful entry of the administrator
account credential.
5.2.3 Security Management (FMT)
FMT_MOF.1 Management of Security Functions Behaviour
FMT_MOF.1.1
The TSF shall restrict the ability to [selection: determine the behavior of, disable,
enable, modify the behavior of] the functions [selection: encryption algorithms
used, key sizes used] to [selection: no users, [administrators]].
Application Note: The intent of this SFR is to define a mechanism to distinguish
administrators (who have the ability to configure the TSF and its data) from users
(individuals in the enterprise who have FEs on their systems).
The TSF does not need to provide roles that are explicitly called ‘administrator’ or
‘user’; the ST must logically define the administrator as a combination of one or
more roles that are provided by the TOE. A user as defined by this PP-Module may
be either a user that is specifically assigned an unprivileged role by the TSF or it
may be characterized by an individual that lacks an administrator account on the
TOE
The TSF may optionally provide the ability to rely on an external authentication
mechanism to identify users in the case of a user requesting distribution of a
recovery credential. In this situation, the TOE’s reliance on the Operational
Environment is functionally equivalent to the TSF maintaining the user role as
defined by FMT_SMR.2.1.
Evaluation Activities
FMT_MOF.1
TSS
The evaluator shall examine that the TSS details how Administrators are authenticated and
identified by all TOE components. The evaluator shall examine that authentication and
identification of Administrators cannot be compromised for any TOE component in this case.
KMD
None.
Guidance
The evaluator shall review the guidance documentation to ensure that it contains instructions for
administering the TOE both locally and remotely, including any configuration that needs to be
performed on the client for remote administration.
Tests
The evaluator shall perform the following tests:
In the course of performing the testing activities for the evaluation, the evaluator shall use all
supported interfaces, although it is not necessary to repeat each test involving an administrative
action with each interface. The evaluator shall ensure, however, that each supported method of
administering the TOE that conforms to the requirements of this PP-Module be tested; for instance,
if the TOE can be administered through a local hardware interface, SSH, and TLS/HTTPS, then all
three methods of administration must be exercised during the evaluation team’s test activities.
FMT_MTD.1 Management of TSF Data
FMT_MTD.1.1
The TSF shall restrict the ability to [selection: change default, query, modify, delete,
clear, [assignment: other operations]] the [encryption keys and intermediate values]
to [administrators] at the following times: [selection: never, during initial
provisioning, during recovery] .
Application Note: These restrictions apply to modifications on the enterprise server.
Evaluation Activities
FMT_MTD.1
TSS
The evaluator shall examine the TSS to determine that, for each administrative function identified in
the guidance documentation; those that are available to the administrator are identified. For each of
these functions, the evaluator shall also confirm that the TSS details when changes may be made to
the encryption keys and/or intermediate values.
KMD
None.
Guidance
The evaluator shall verify that the guidance document describes what operations on the encryption
keys and intermediate values are allowed to the administrator at what times.
Tests
The evaluator shall perform the following tests:
Test FMT_MTD.1:1: The evaluator shall try to perform at least one of the related actions
without prior authentication as administrator (either by authentication as a user with no
administrator privileges or without user authentication at all – depending on the
configuration of the TOE). This test should fail.
Test FMT_MTD.1:2: The evaluator shall try to perform at least one of the related actions with
prior authentication as administrator. This test should pass.
Test FMT_MTD.1:3: The evaluator shall try to perform at least one of the actions at the times
that are not permitted. This test should fail.
Test FMT_MTD.1:4: The evaluator shall try to perform at least one of the actions at the times
are permitted. This test should pass.
FMT_SMF.1/FEEM Specification of Management Functions (Management Server)
FMT_SMF.1.1/FEEM
The TSF shall be capable of performing the following management functions:
[selection:
register new user
revoke registration of user
initiate key generation
initiate keying escrow
initiate key zeroization
initiate key recovery
set encryption policy (supported algorithms and key sizes)
change administrator passwords
change user passwords
change recovery credentials
define administrators of the TOE
enable/disable use of recovery credential
configure number of failed authentication attempts before issuing a key
destruction of the FEK(s)
configure the number of authentication attempts that can be made within a
24 hour period
configure the number of failed authentication attempts required to begin
blocking subsequent attempts
ability to enable or disable one or more of the following functions:
[selection: configure cryptographic functionality, change authentication
factors, perform a cryptographic erase of the data by the destruction of
FEKs or KEKs protecting the FEKs, configure the number of failed
validation attempts required to trigger corrective behavior, configure the
corrective behavior to issue in the event of an excessive number of failed
validation attempts, [assignment: other management functions provided by
the TSF]]
] .
Application Note: This SFR refers specifically to the management functions that
can be performed by the Management Server. Functions that are performed by the
rest of the TOE are addressed by the FMT_SMF.1/FEEM SFR in the File Encryption
PP-Module. The final two assignments provide the ST author the ability to indicate
when the PP-Module for File Encryption functionality (such as configuration of
power saving states) can be configured by the Management Server.
The TSF’s ability to initiate key generation, escrow, zeroization, and/or recovery
may be accomplished either by the TOE performing those functions or by the TOE
issuing a request to a remote client to perform the functions. The ST author must
indicate which case is provided by the TSF. If the TOE performs any of the
cryptographic functions that are selected as being initiated in this SFR, the ST author
must include the equivalent FCS SFRs from the File Encryption PP-Module as part
of the TOE, specifically indicating that these functions are provided by the
Management Server component of the TOE.
If the TSF supports the use of a recovery credential, the ST author must include the
‘enable/disable use of recovery credential’ selection.
Evaluation Activities
FMT_SMF.1/FEEM
TSS
The evaluator shall examine the TSS to ensure that it describes which of the selections are provided
by the TOE. Additionally, the TSS shall describe which of the configurable selections can be
disabled on the Enterprise Management Server. The evaluator shall examine the TSS to ensure that
it describes whether the TOE provides the ability to initiate key generation, escrow, zeroization
and/or recovery or whether it requests the client to perform those functions.
KMD
None.
Guidance
The evaluator shall examine the Guidance Documents to ensure that, if supported, configuration of
the following options is described, including any reliance on the Operational Environment if
applicable:
Register new user
Revoke registration of an user
Initiate key generation
Initiate keying escrow
Initiate key recovery
Initiate key zeroization
Set encryption policy (supported algorithms and key sizes)
Change Administrator passwords
Change user passwords
Change Recovery Credentials
Define Administrators of the TOE
Enable/Disable the use of recovery credentials (end users)
Configure the number of failed authentication attempts before issuing a key destruction of the
FEK(s)
Configure the number of authentication attempts that can be made in a 24 hour period
Configure the number of failed authentication attempts required to begin blocking subsequent
attempts
The ability to enable/disable one or more functions defined in the PP-Module for File Encryption
The ability to authorize whether or not users can perform one or more of the functions in the File
Encryption PP-Module.
ability to enable or disable one or more of the following functions (configure cryptographic
functionality, change authentication factors, perform a cryptograph erase of the data by the
destruction of FEKs or KEKs protecting the FEKs, configure the number of failed validation
attempts required to trigger corrective behavior, configure the corrective behavior to issue in the
event of an excessive number of failed validation attempts, [other management functions provided by
the TSF]
ability to perform one or more of the following functions (configure cryptographic functionality,
change authentication factors, perform a cryptograph erase of the data by the destruction of FEKs
or KEKs protecting the FEKs, configure the number of failed validation attempts required to trigger
corrective behavior, configure the corrective behavior to issue in the event of an excessive number of
failed validation attempts, [other management functions provided by the TSF]
ability to authorize whether or not users can perform one or more of the following functions
(configure cryptographic functionality, change authentication factors, perform a cryptograph erase
of the data by the destruction of FEKs or KEKs protecting the FEKs, configure the number of failed
validation attempts required to trigger corrective behavior, configure the corrective behavior to
issue in the event of an excessive number of failed validation attempts, [other management functions
provided by the TSF]
Tests
The evaluator shall perform the following tests for each claimed management function:
Test FMT_SMF.1/FEEM:1: The evaluator shall configure the management server and two
users according to the guidance documents. The evaluator shall register the users with the
management server. The evaluator shall verify that the users are identified by the management
server as defined in the guidance documents. This test shall pass.
Test FMT_SMF.1/FEEM:2: The evaluator shall disconnect the second user from the network.
The evaluator shall revoke the registration of the second user in the management server. The
evaluator shall attempt to connect the second user to the network and verify the endpoint fails
to connect or is displayed as revoked in the console.
Test FMT_SMF.1/FEEM:3: The evaluator shall verify that the TOE performs the actions (e.g.
generate key) and sends the result to the user's client. The user's client shall perform the
actions necessary to accept the updated configuration (e.g. encrypt the data with the new key,
update the encryption algorithm key size or mode and re-encrypt).
Test FMT_SMF.1/FEEM:4: For each item that is initiated by the TOE but performed on the
endpoint, the evaluator shall verify that the TOE requests the user's client to perform the
action (generate a key and encrypt the data, zeroize a key).
Test FMT_SMF.1/FEEM:5: For each method of changing a credential, the evaluator shall
first provision the initial authorization factor(s) in the Enterprise Server, and then verify all
authorization values supported allow the user access to the encrypted data on the user's
client. Then the evaluator shall exercise the management functions to change the
authorization factor values to a new one on the Enterprise Server. Then he or she will verify
that the user's client denies access to the user’s encrypted data when he or she uses the old or
original authorization factor values to gain access.
Test FMT_SMF.1/FEEM:6: The evaluator shall add two administrators to the administrator
group in the Enterprise Server and provision authorization factor(s) for each administrator.
The evaluator shall verify that both administrators can log into the Enterprise Server using
the provided authorization factors. The evaluator shall then exercise the management
functions to change the authorization factor values for the first administrator to a new one on
the Enterprise Server. Then he or she will verify that the Enterprise Server denies the first
administrator access to the Management Console when the first administrator logs in with the
old or original authorization factor to gain access. The evaluator shall also verify that the
second administrator is still able to log in to the Enterprise Server with their original
authorization factor.
Test FMT_SMF.1/FEEM:7: The evaluator shall verify that the an administrator can configure
each of the supported authorization factors attempts limits and shall verify that the user is
denied access after surpassing that limit.
Test FMT_SMF.1/FEEM:8: If the TOE provides the capability to disable management of any
capability allowed in the EM PP-Module, the evaluator shall devise a test that ensures that
each capability which can be disabled has been or can be disabled following guidance
provided by the vendor.
Test FMT_SMF.1/FEEM:9: If the TOE provides the capability to manage capabilities in place
of the File Encryption Clients, where those administrative capabilities are then disabled in the
File Encryption Clients, the evaluator shall devise a test that ensures that each capability
which can be disabled in the File Encryption Clients and can be subsequently managed by the
EM is tested as follows: Disable the administrative capability in a File Encryption Client and
enable it in the EM. Verify that the administration of the capability in the EM is successful.
Test FMT_SMF.1/FEEM:10: The evaluator shall verify the encryption policy enforcement by
changing the permitted algorithms and verifying the changes take place.
FMT_SMR.2 Restrictions on Security Roles
FMT_SMR.2.1
The TSF shall maintain the roles [administrator, user].
FMT_SMR.2.2
The TSF shall be able to associate users with roles.
FMT_SMR.2.3
The TSF shall ensure that the conditions[selection: the administrator role shall be
able to administer the Management Server locally, the administrator role shall be
able to administer the Management Server remotely as specified in FTP_TRP.1,
the administrator role shall be able to administer the endpoint(s) locally, the
administrator role shall be able to administer the endpoint(s) remotely] are
satisfied.
Application Note: The intent of this SFR is to define a mechanism to distinguish
administrators (who have the ability to configure the TSF and its data) from users
(individuals in the enterprise who have FEs on their systems).
The TSF does not need to provide roles that are explicitly called ‘administrator’ or
‘user’; the ST must logically define the administrator as a combination of one or
more roles that are provided by the TOE. A user as defined by this PP-Module may
be either a user that is specifically assigned an unprivileged role by the TSF or it
may be characterized by an individual that lacks an administrator account on the
TOE.
The TSF may optionally provide the ability to rely on an external authentication
mechanism to identify users in the case of a user requesting distribution of a
recovery credential. In this situation, the TOE’s reliance on the Operational
Environment is functionally equivalent to the TSF maintaining the user role as
defined by FMT_SMR.2.1.
Evaluation Activities
FMT_SMR.2
TSS
Refer to the evaluation activities for FMT_MOF.1.
Guidance
Refer to the evaluation activities for FMT_MOF.1.
Tests
Refer to the evaluation activities for FMT_MOF.1.
5.2.4 Protection of the TSF (FPT)
FPT_ITT.1 Basic Internal TSF Data Transfer Protection
FPT_ITT.1.1
The TSF shall protect TSF data from [disclosure, modification] when it is
transmitted between separate parts of the TOE through the use of [selection: IPsec
as defined in the PP-Module for VPN Client, HTTPS in accordance with
FCS_HTTPS_EXT.1 (from [AppPP]), TLS as defined in the Functional Package
for Transport Layer Security (TLS), version 2.1, SSH as defined in the Functional
Package for Secure Shell (SSH), version 2.0] .
Application Note: This SFR is intended to define protected communications
between the Management Server and the endpoints.
Evaluation Activities
FPT_ITT.1
TSS
The evaluator shall examine the TSS to determine that, for all communications between components
of a distributed TOE, each communications mechanism is identified in terms of the allowed
protocols and intra-TOE configurations for that IT entity. The evaluator shall also confirm that all
protocols listed in the TSS for these inter-component communications are specified and included in
the requirements in the ST.
KMD
None.
Guidance
The evaluator shall confirm that the guidance documentation contains instructions for establishing
the relevant allowed communication channels and protocols between each pair of authorized TOE
components, and that it contains instructions to reestablish a connection should a connection be
unintentionally broken.
Tests
The evaluator shall perform the following tests:
Test FPT_ITT.1:1: The evaluator shall ensure that communications using each supported
protocol between each pair of authorized TOE components is tested during the course of the
evaluation, setting up the connections as described in the guidance documentation and
ensuring that communication is successful.
Test FPT_ITT.1:2: The evaluator shall ensure, for each communication channel with an
endpoint or server, the channel data is not sent in plaintext.
Test FPT_ITT.1:3: The evaluator shall, for each protocol associated with each authorized IT
entity tested during Test 1, physically interrupt the connection. The evaluator shall ensure that
when physical connectivity is restored, communications are appropriately protected.
Further evaluation activities are associated with the specific protocols.
FPT_KYP_EXT.1 Protection of Keys and Key Material
FPT_KYP_EXT.1.1
The TSF shall store keys in non-volatile memory only when [selection:
wrapped, as specified in FCS_COP.1/KW
encrypted, as specified in FCS_COP.1/SKC (from [AppPP])
the plaintext key is stored in the underlying platform's keystore as specified by
FCS_STO_EXT.1 (from [AppPP])
the plaintext key is stored in a SQL database in the Operational Environment
the plaintext key is not part of the key chain as specified in FCS_KYC_EXT.1.
the plaintext key will no longer provide access to the encrypted data after
initial provisioning
the plaintext key is a key split that is combined as specified in
FCS_SMC_EXT.1 and another contribution to the split is [selection: wrapped
as specified in FCS_COP.1/KW, derived and not stored in non-volatile
memory]
the plaintext key is stored on an external storage device for use as an
authorization factor.
the plaintext key is used to wrap a key as specified in FCS_COP.1/KW that is
already wrapped as specified in FCS_COP.1/KW
].
Application Note: This details the key storage requirements for the enterprise
server. The plaintext key storage in non-volatile memory is allowed for several
reasons. If the keys exist within protected memory that is not user accessible on the
TOE or OE, the only methods that allow it to play a security relevant role for
protecting the FEK is if it is a key split or providing additional layers of wrapping or
encryption on keys that have already been protected.
Evaluation Activities
FPT_KYP_EXT.1
TSS
The evaluator shall verify the TSS for a high level description of the method(s) used to protect keys
stored in non-volatile memory.
KMD
The evaluator shall verify the KMD to ensure it describes the storage location of all keys and the
protection of all keys stored in non-volatile memory. The description of the key chain shall be
reviewed to ensure FCS_COP.1/KW is followed for the storage of wrapped or encrypted keys in non-
volatile memory and plaintext keys in non-volatile memory meet one of the criteria for storage.
Guidance
None.
Tests
None.
FPT_KYP_EXT.2 Attribution of Key and Key Material
FPT_KYP_EXT.2.1
The TSF shall maintain an association between stored endpoint keys and user
identity, [selection: remote endpoints, recovery credential, system identity, no other
subjects].
Application Note: The intent of this SFR is that at minimum, keys are associated
with the users for which it was explicitly created by the TSF. If the TOE has the
ability to maintain an association to keys for a user, this SFR is intended to require
an association between the key chain and a user through the user account name(s)
that are authorized to use it.
Likewise, if the TOE supports the use of a recovery credential, this SFR is intended
to require an association between user and the recovery credential used to recover
that data.
FPT_KYP_EXT.2.2
The TSF shall provide the ability to register users by exchange of [assignment:
mutually identifying information that allows for an association to be made].
Application Note: The ST author will complete the assignment with information on
the method used by the Management Server portion of the TOE to establish the
association with the endpoint portion of the TOE described in FPT_KYP_EXT.2.1.
FPT_KYP_EXT.2.3
The TSF shall provide the ability to revoke the registration of users by [assignment:
method of removing and/or exchanging information that prevents further
communications between the TOE and the endpoint].
FPT_KYP_EXT.2.4
The TSF shall transmit any secure or private cryptographic information that is
transferred between the TOE and a user's endpoint in order to establish or
disestablish an association using a communications channel with a security strength
at least as great as the strength of the information being transmitted.
Application Note: The channel used to transmit this data is defined in FPT_ITT.1.
Evaluation Activities
FPT_KYP_EXT.2
TSS
The evaluator shall examine the TSS to verify that it describes the method by which an association is
maintained and verify it matches the selections.
KMD
None.
Guidance
The evaluator shall verify the guidance documentation provides instructions on how to configure the
association, if any configuration is necessary.
Tests
For each method of association, the evaluator shall change the configuration so that the associate is
broken and verify that enterprise functions do not work.
5.3 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 2: SFR Rationale
Threat Addressed by Rationale
T.KEYING_​
MATERIAL_​
COMPROMISE_​
SERVER
FCS_CKM_EXT.1 (from
Base-PP)
Mitigates the threat by ensuring that a key
generation mechanism exists for the TOE to
use.
FCS_CKM.1/SK (from Base-
PP)
Mitigates the threat by securely generating
symmetric encryption keys.
FCS_CKM.2 (from Base-PP) Mitigates the threat by securely establishing
cryptographic keys between entities.
FCS_CKM.6 Mitigates the threat by securely destroying
keys and key material when no longer needed.
FCS_COP.1/KT (selection-
based)
Mitigates the threat by securely transmitting
keys using a cryptographic algorithm.
FCS_COP.1/KW (selection-
based)
Mitigates the threat by securely wrapping
cryptographic keys using a cryptographic
algorithm.
FCS_KDF_EXT.1 (selection-
based)
Mitigates the threat by securely deriving
cryptographic keys.
FCS_KYC_EXT.1 Mitigates the threat by securely storing keys &
key chain material.
FCS_SMC_EXT.1 (selection-
based)
Mitigates the threat by securely generating
intermediate keys by combining submasks.
FIA_AUT_EXT.1 Mitigates the threat by authorizing a user
based on a secure credential.
FMT_MOF.1 Mitigates the threat by restricting the ability to
manage encryption parameters to
administrators.
FMT_SMF.1/FEEM Mitigates the threat by restricting the ability to
manage the Management Server to
administrators.
FPT_ITT.1 Mitigates the threat by protecting data
transmitted within different parts of the TOE.
FPT_KYP_EXT.1 Mitigates the threat by limiting the situations
in which plaintext keys may be stored, and
storing the keys protected in all other
situations.
FTP_DIT_EXT.1 (modified
from Base-PP)
Mitigates the threat by encrypting data
transmitted to an external entity.
T.MAN_​
IN_​
THE_​
MIDDLE FCS_CKM_EXT.1 (from
Base-PP)
Mitigates the threat by ensuring that a key
generation mechanism exists for the TOE to
use.
FCS_CKM_EXT.6
(selection-based)
Mitigates the threat by conditioning passwords
or other credentials to an unreadable form.
FCS_COP.1/SigGen (from
Base-PP)
Mitigates the threat by cryptographically
signing communications between servers and
clients.
FCS_COP.1/SKC (from
Base-PP)
Mitigates the threat by utilizing symmetric
encryption in communications between
servers and clients.
FCS_RBG_EXT.1 (from
Base-PP)
Mitigates the threat by using a secure RBG to
support secure communication.
FPT_ITT.1 Mitigates the threat by encrypting data
transmitted between different parts of the
TOE.
FTP_DIT_EXT.1 (modified
from Base-PP)
Mitigates the threat by encrypting sensitive or
all data transmitted to an external entity.
FTP_TRP.1 (selection-based) Mitigates the threat by protecting
communication with an appropriate secure
protocol.
T.UNAUTHORIZED_​
ADMINISTRATOR_​
ACCESS
FCS_VAL_EXT.1/Admin Mitigates the threat by validating the
administrator before allowing any
administrative actions.
FCS_VAL_EXT.2/Admin
(selection-based)
Mitigates the threat by preventing excessive
unsuccessful validation attempts.
FIA_UAU.1 Mitigates the threat by limiting the
administrative actions that can be taken before
the authentication process must succeed.
FIA_UID.1 Mitigates the threat by limiting the
administrative actions that can be taken before
the identification process must succeed.
T.UNAUTHORIZED_​
DATA_​
ACCESS_​
ENDPOINT
FPT_KYP_EXT.2 Mitigates the threat by associating keys to user
identities and providing a method for
revocation of the association.
T.UNAUTHORIZED_​
DATA_​
ACCESS_​
SERVER
FCS_COP.1/SKC (from
Base-PP)
Mitigates the threat by identifying users with a
securely-encrypted value.
FCS_VAL_EXT.1/User Mitigates the threat by validating the user
before decryption of any data or key.
FCS_VAL_EXT.2/User Mitigates the threat by preventing excessive
unsuccessful validation attempts.
FIA_CHR_EXT.1 (selection-
based)
Mitigates the threat by providing a limited-
time and limited-scope challenge-response
recovery credential.
FIA_REC_EXT.1 Mitigates the threat by providing a secure
recovery mechanism.
FIA_UAU.1 Mitigates the threat by limiting the
administrative actions that can be taken before
the authentication process must succeed.
FIA_UID.1 Mitigates the threat by limiting the
administrative actions that can be taken before
the identification process must succeed.
FMT_MTD.1 Mitigates the threat by restricting the times at
which certain cryptographic parameters can be
modified on the server.
FMT_SMR.2 Mitigates the threat by maintaining separate
security roles for administrators and users.
6 Consistency Rationale
6.1 Protection Profile for Application Software
6.1.1 Consistency of TOE Type
When this PP-Module is used to extend the App PP, the TOE type for the overall TOE is still a software
application. The TOE boundary is simply extended to include the enterprise management functionality for software
file encryption that the application performs.
6.1.2 Consistency of Security Problem Definition
Table 3: Consistency of Security Problem Definition (App PP base)
PP-Module Threat, Assumption, OSP Consistency Rationale
T.KEYING_MATERIAL_COMPROMISE_SERVER This threat is a specific example of
T.PHYSICAL_ACCESS defined in the Base-PP.
Specifically, this PP-Module defines a method of
maliciously gaining access to sensitive data at rest that
is particular to the technology type of this PP-Module.
T.MAN_IN_THE_MIDDLE This threat is a specific example of
T.NETWORK_EAVESDROP defined in the Base-PP.
Specifically, the attacker performs network
eavesdropping to gain access to key data in transit
between TOE components.
T.UNAUTHORIZED_ADMINISTRATOR_ACCESS This threat is a variation on T.LOCAL_ATTACK
defined in the Base-PP. The Base-PP does not define
access-controlled management functions so this PP-
Module goes beyond it by specifying misuse of the
management interface as a threat to the TSF.
T.UNAUTHORIZED_DATA_ACCESS_ENDPOINT This threat is a variation on T.PHYSICAL_ACCESS
defined in the Base-PP. In this case, the "sensitive data
at rest" is the data that the TOE is intended to protect.
T.UNAUTHORIZED_DATA_ACCESS_SERVER This threat is a variation on T.PHYSICAL_ACCESS
defined in the Base-PP. In this case, the "sensitive data
at rest" is the data that the TOE is intended to protect.
T.UNTRUSTED_COMMUNICATION_CHANNELS This threat is a variation on T.NETWORK_ATTACK
and T.NETWORK_EAVESDROP defined in the Base-
PP. The threat of untrusted communication channels
allows for exploitation of the TSF in different ways,
depending on how the lack of trust is manifested.
A.ENVIRONMENTAL_STORAGE
A.PHYSICAL_SERVER
A.SECURED_CONFIGURATION
A.SECURED_ENVIRONMENT
6.1.3 Consistency of OE Objectives
Table 4: Consistency of OE Objectives (App PP base)
PP-Module OE Objective Consistency Rationale
OE.ENVIRONMENTAL_STORAGE This objective is consistent with the Base-PP because the Base-PP
allows for the TOE to use platform-provided key storage.
OE.PHYSICAL_SERVER This objective is consistent with the Base-PP because it is an extension
of the Base-PP's OE.PLATFORM objective that is specific to this
technology type. It is also consistent because the Base-PP permits the
TSF to use platform-provided cryptography.
OE.SECURED_CONFIGURATION This objective is consistent with the Base-PP because it expects the
TOE's operational guidance to be responsibly followed in the same
manner as OE.PROPER_ADMIN in the Base-PP.
OE.SECURED_ENVIRONMENT This objective is consistent with the Base-PP because it is an extension
of the Base-PP's OE.PLATFORM objective that is specific to this
technology type.
6.1.4 Consistency of Requirements
This PP-Module identifies several SFRs from the App PP that are needed to support File Encryption Enterprise
Management functionality. This is considered to be consistent because the functionality provided by the App PP is
being used for its intended purpose. The PP-Module also identifies a number of modified SFRs from the App PP
that are used entirely to provide functionality for File Encryption Enterprise Management. The rationale for why
this does not conflict with the claims defined by the App PP are as follows:
Table 5: Consistency of Requirements (App PP base)
PP-Module
Requirement
Consistency Rationale
Modified SFRs
FTP_DIT_EXT.1 This SFR is defined in the Base-PP. This PP-Module modifies it by removing the
option not to transmit sensitive data because this particular TOE type will always
have that capability. It is still consistent with the Base-PP because all selections that
the ST author is permitted to make are available options in the Base-PP version of
the SFR.
Additional SFRs
This PP-Module does not add any requirements when the App PP is the base.
Mandatory SFRs
FCS_CKM.6 This SFR requires destruction of cryptographic keys when they are no longer
needed. The Base-PP does not mandate key destruction but it also does not prohibit
it.
FCS_KYC_EXT.1 The Base-PP defines how stored keys are protected. This SFR extends that
functionality by defining the logical hierarchy of how keys are logically protected
by other keys or other secret data.
FCS_VAL_EXT.1/Admin This SFR goes beyond the functionality defined by the Base-PP by defining a
method by which the TSF can validate the correctness of data input to it.
FCS_VAL_EXT.1/User This SFR goes beyond the functionality defined by the Base-PP by defining a
method by which the TSF can validate the correctness of data input to it.
FCS_VAL_EXT.2/User This SFR goes beyond the functionality defined by the Base-PP by defining a
method by which the TSF can take security-relevant action if some data input to it is
invalid.
FIA_AUT_EXT.1 This SFR defines how administrator requests to access protected data are authorized.
It uses FCS_RBG_EXT.1 from the Base-PP in a manner consistent with its
definition, but otherwise does not relate to functionality defined by the Base-PP.
FIA_REC_EXT.1 This SFR defines the TOE's potential support for recovery credentials. This
functionality does not relate to any behavior defined in the Base-PP.
FIA_UAU.1 This SFR requires administrators to be authenticated prior to accessing management
functionality. The Base-PP does not mandate identification and authentication
measures for a management interface but it also does not prohibit them.
FIA_UID.1 This SFR requires administrators to be identified prior to accessing management
functionality. The Base-PP does not mandate identification and authentication
measures for a management interface but it also does not prohibit them.
FMT_MOF.1 This SFR defines access restrictions for TOE management functions. This is not
defined in the Base-PP but there is nothing in the Base-PP that prohibits it.
FMT_MTD.1 This SFR defines access restrictions for management of TSF data. This is not
defined in the Base-PP but there is nothing in the Base-PP that prohibits it.
FMT_SMF.1/FEEM This SFR defines management functions for the TOE for functionality specific to
this PP-Module. These functions are defined in addition to what the Base-PP defines
for its own operation.
FMT_SMR.2 This SFR defines administrative roles, which are used by other SFRs to derive
privileges to interact with the TOE's management functionality. This is not defined
in the Base-PP but there is nothing in the Base-PP that prohibits it.
FPT_ITT.1 This SFR uses a subset of the protocols defined in the Base-PP for secure
communications. This PP-Module extends the functionality by explicitly defining a
communications channel where both endpoints are TOE components.
FPT_KYP_EXT.1 The Base-PP defines an SFR for secure storage of sensitive data. This SFR expands
on that definition by describing the supported logical methods for storage of key
data.
FPT_KYP_EXT.2 This SFR relates to key attribution such that stored keys can be associated with the
users that 'own' them. This does not relate to functionality that is defined in the
Base-PP so it does not interfere with the implementation of any Base-PP SFRs.
Optional SFRs
This PP-Module does not define any Optional requirements.
Objective SFRs
This PP-Module does not define any Objective requirements.
Implementation-dependent SFRs
This PP-Module does not define any Implementation-dependent requirements.
Selection-based SFRs
FCS_CKM_EXT.6 This SFR defines a key derivation method based on passphrase conditioning. It uses
the FCS_RBG_EXT.1 SFR from the Base-PP in its intended manner but otherwise
does not relate to the Base-PP's functionality.
FCS_COP.1/KT This SFR defines key transport functionality that is outside the scope of the original
cryptographic operations defined in the Base-PP.
FCS_COP.1/KW This SFR defines usage of AES functionality not defined by the Base-PP. However,
this functionality is only used in certain situations that are specific to this PP-
Module and do not affect the ability of any Base-PP SFRs to be enforced.
FCS_KDF_EXT.1 This SFR defines key transport functionality. It uses random bit generation and
keyed-hash message authentication functionality from the Base-PP as they are
intended but is otherwise outside the scope of the original cryptographic operations
defined in the Base-PP.
FCS_SMC_EXT.1 This SFR relates to submask combining as a method of generating intermediate
keys. Key hierarchy functionality is outside the scope of the Base-PP.
FCS_VAL_EXT.2/Admin This SFR goes beyond the functionality defined by the Base-PP by defining a
method by which the TSF can take security-relevant action if some data input to it is
invalid.
FIA_CHR_EXT.1 This SFR defines the TOE's implementation of recovery credentials. This
functionality does not relate to any behavior defined in the Base-PP.
FTP_TRP.1 This SFR uses a subset of the protocols defined in the Base-PP for secure
communications. This PP-Module extends the functionality by explicitly defining a
communications path between a remote administrator and the TOE.
Appendix A - Optional SFRs
A.1 Strictly Optional Requirements
This PP-Module does not define any Strictly Optional SFRs or SARs.
A.2 Objective Requirements
This PP-Module does not define any Objective SFRs.
A.3 Implementation-dependent Requirements
This PP-Module does not define any Implementation-dependent SFRs.
Appendix B - Selection-based Requirements
B.1 Cryptographic Support (FCS)
FCS_CKM_EXT.6 Cryptographic Password/Passphrase Conditioning
The inclusion of this selection-based component depends upon selection in FIA_AUT_EXT.1.1.
FCS_CKM_EXT.6.1
The TSF shall support a password/passphrase of up to [assignment: maximum
password size, positive integer of 64 or more] characters used to generate a password
authorization factor.
FCS_CKM_EXT.6.2
The TSF shall allow passwords to be composed of any combination of upper case
characters, lower case characters, numbers, and the following special characters: “!”,
“@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, and “)”, and [selection: [assignment: other
supported special characters], no other characters].
FCS_CKM_EXT.6.3
The TSF shall perform Password-based Key Derivation Functions in accordance
with a specified cryptographic algorithm HMAC- [selection: SHA-384, SHA-512],
with [assignment: positive integer of 4096 or more] iterations, and output
cryptographic key sizes [256] bits that meet the following: [NIST SP 800-132].
FCS_CKM_EXT.6.4
The TSF shall not accept passwords less than [selection: a value settable by the
administrator, [assignment: minimum password length accepted by the TOE, must
be >= 1]] and greater than the maximum password length defined in
FCS_CKM_EXT.6.1.
FCS_CKM_EXT.6.5
The TSF shall generate all salts using an RBG that meets FCS_RBG_EXT.1 (from
[AppPP]) and with entropy corresponding to the security strength selected for
PBKDF in FCS_CKM_EXT.6.3.
Application Note: This applies to passwords on the enterprise server.
The password/passphrase is represented on the host machine as a sequence of
characters whose encoding depends on the TOE and the underlying OS. This
sequence must be conditioned into a string of bits that is to be used as a KEK that is
the same size as the FEK.
For FCS_CKM_EXT.6.1, the ST author assigns the maximum size of the
password/passphrase it supports; it must support at least 64 characters.
For FCS_CKM_EXT.6.2, the ST author assigns any other supported characters; if
there are no other supported characters, they should select “no other characters”.
For FCS_CKM_EXT.6.3, the ST author selects the parameters based on the PBKDF
used by the TSF. The key cryptographic key sizes in FCS_CKM_EXT.6.3 are made
to correspond to the KEK key sizes selected in FCS_KYC_EXT.1.
The password/passphrase must be conditioned into a string of bits that forms the
submask to be used as input into the KEK. Conditioning is performed using one of
the identified hash functions in accordance with the process described in NIST SP
800-132. SP 800-132 requires the use of a pseudo-random function (PRF) consisting
of HMAC with an approved hash function.
Appendix A of 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 password recovery attack. However, for this
PP-Module, a minimum iteration count of 4096 is required in order to ensure that
twelve bits of security is added to the password/passphrase value. A significantly
higher value is recommended to ensure optimal security.
For FCS_CKM_EXT.6.4 If the minimum password length is settable, then ST author
chooses “a value settable by the administrator for this component for
FMT_SMF.1.1/FEEM. If the minimum length is not settable, the ST author fills in
the assignment with the minimum length the password must be (zero-length
passwords are not allowed for compliant TOEs).
This requirement is selection dependent on FIA_AUT_EXT.1.1.
Evaluation Activities
FCS_CKM_EXT.6
TSS
There are two aspects of this component that require evaluation: passwords/passphrases of the
length specified in the requirement (at least 64 characters) are supported, and that the characters
that are input are subject to the selected conditioning function. These activities are separately
addressed in the text below.
Support for minimum length: The evaluator shall check to ensure that the TSS describes the
allowable ranges for password/passphrase lengths, and that at least 64 characters may be specified
by the user.
Support for character set: The evaluator shall check to ensure that the TSS describes the allowable
character set and that it contains the characters listed in the SFR.
Support for PBKDF: The evaluator shall examine the TSS to ensure that the formation of all KEKs
or FEKs (as decided in the FCS_CKM_EXT.3 selection) is described and that the key sizes match
that described by the ST author.
The evaluator shall check that the TSS describes the method by which the password/passphrase is
first encoded and then fed to the SHA algorithm. The settings for the algorithm (padding, blocking,
etc.) shall be described, and the evaluator shall verify that these are supported by the selections in
this component as well as the selections concerning the hash function itself. The evaluator shall
verify that the TSS contains a description of how the output of the hash function is used to form the
submask that will be input into the function and is the same length of the KEK selected in
FCS_KYC_EXT.1.
For the NIST SP 800-132-based conditioning of the password/passphrase, the required evaluation
activities will be performed when doing the evaluation activities for the appropriate requirements
(FCS_COP.1.1/KeyedHash). If any manipulation of the key is performed in forming the submask
that will be used to form the FEK or KEK, that process shall be described in the TSS.
h:br/>No explicit testing of the formation of the submask from the input password is required.
FCS_CKM_EXT.6.2: The ST author shall provide a description in the TSS regarding the salt
generation. The evaluator shall confirm that the salt is generated using an RBG described in
FCS_RBG_EXT.1 (from the [AppPP]).
KMD
None.
Guidance
Support for minimum length: The evaluators shall check the Operational Guidance to determine that
there are instructions on how to generate large passwords/passphrases, and instructions on how to
configure the password/passphrase length to provide entropy commensurate with the keys that the
authorization factor is protecting.
Tests
Support for Password/Passphrase characteristics: In addition to the analysis above, the evaluator
shall also perform the following tests on a TOE configured according to the Operational Guidance:
Test FCS_CKM_EXT.6:1: Ensure that the TOE supports passwords/passphrases of a minimum
length of 64 characters.
Test FCS_CKM_EXT.6:2: Ensure that the TOE does not accept more than the maximum
number of characters specified in FCS_CKM_EXT.6.1.
Test FCS_CKM_EXT.6:3: Ensure that the TOE does not accept less than the minimum number
of characters specified in FCS_CKM_EXT.6.4. If the minimum length is settable by the
administrator, the evaluator determines the minimum length or lengths to test.
Test FCS_CKM_EXT.6:4: Ensure that the TOE supports passwords consisting of all
characters listed in FCS_CKM_EXT.6.2.
Conditioning: No explicit testing of the formation of the authorization factor from the input
password/passphrase is required.
FCS_COP.1/KT Cryptographic operation (Key Transport)
The inclusion of this selection-based component depends upon selection in FCS_KYC_EXT.1.1.
FCS_COP.1.1/KT
The TSF shall perform [key transport] in accordance with a specified cryptographic
algorithm [selection:
CNSA 2.0 Compliant Algorithms:
[Hybrid Key-Transport Method] that meets the following: [Section 9.3
of NIST SP 800-56B, Revision 2] using a key establishment algorithm
[ML-KEM] as specified in FCS_CKM.2 (from the Base-PP) and a key
wrapping algorithm as specified in FCS_COP.1/KW
CNSA 1.0 Compliant Algorithms:
[KTS-OAEP] using cryptographic algorithm [RSA] with cryptographic
key sizes [selection: 3072, 4096] bits that meet the following: [NIST SP
800-56B, Revision 2]
].
Application Note: This requirement is used in the body of the ST if the ST author
chooses to use key transport in the key chaining approach that is specified in
FCS_KYC_EXT.1.
When describing the hybrid key-transport methods, Section 9.3 of NIST SP 800-56B
only mentions using the key establishment schemes contained in SP800-56B to
establish a shared symmetric key encryption key (KEK) for the transport; however
any approved symmetric key establishment method could easily be substituted. This
PP-Module allows the use of ML-KEM key establishment schemes with the hybrid
key-transport methods described in SP800-56B to provide a CNSA2-compliant key-
transport method.
Future versions of this PP-Module may support the use of a key-encapsulation
mechanism (KEM) for key transport as defined in NIST SP 800-227 (in draft as of
the publication of this PP-Module), sections 5.1 and 6.2.1.
Evaluation Activities
FCS_COP.1/KT
TSS
There are no additional TSS evaluation activities for this component.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
For each supported key transport schema, the evaluator shall initiate at least 25 sessions that
require key transport with an independently developed remote instance of a key transport entity,
using known RSA key-pairs. The evaluator shall observe traffic passed from the sender-side and to
the receiver-side of the TOE, and shall perform the following tests, specific to which key transport
scheme was employed.
Test FCS_COP.1/KT:1: The evaluator shall inspect each cipher text, C, produced by the RSA-
OAEP encryption operation of the TOE and make sure it is the correct length, either 256 or
384 bytes depending on RSA key size. The evaluator shall also feed into the TOE's RSA-OEAP
decryption operation some cipher texts that are the wrong length and verify that the erroneous
input is detected and that the decryption operation exits with an error code.
Test FCS_COP.1/KT:2: The evaluator shall convert each cipher text, C, produced by the RSA-
OAEP encryption operation of the TOE to the correct cipher text integer, c, and use the
decryption primitive to compute em = RSADP((n,d),c) and convert em to the encoded message
EM. The evaluator shall then check that the first byte of EM is 0x00. The evaluator shall also
feed into the TOE's RSA-OEAP decryption operation some cipher texts where the first byte of
EM was set to a value other than 0x00, and verify that the erroneous input is detected and that
the decryption operation exits with an error code.
Test FCS_COP.1/KT:3: The evaluator shall decrypt each cipher text, C, produced by the RSA-
OAEP encryption operation of the TOE using RSADP, and perform the OAEP decoding
operation (described in NIST SP 800-56B section 7.2.2.4) to recover HA' || X. For each HA',
the evaluator shall take the corresponding A and the specified hash algorithm and verify that
HA' = Hash(A). The evaluator shall also force the TOE to perform some RSA-OAEP
decryption where the A value is passed incorrectly, and the evaluator shall verify that an error
is detected.
Test FCS_COP.1/KT:4: The evaluator shall check the format of the 'X' string recovered in
OAEP.Test.3 to ensure that the format is of the form PS || 01 || K, where PS consists of zero or
more consecutive 0x00 bytes and K is the transported keying material. The evaluator shall
also feed into the TOE's RSA-OEAP decryption operation some cipher texts for which the
resulting 'X' strings do not have the correct format (i.e., the leftmost non-zero byte is not
0x01). These incorrectly formatted 'X' variables shall be detected by the RSA-OEAP decrypt
function.
Test FCS_COP.1/KT:5: The evaluator shall trigger all detectable decryption errors and
validate that the returned error codes are the same and that no information is given back to
the sender on which type of error occurred. The evaluator shall also validate that no
intermediate results from the TOE's receiver-side operations are revealed to the sender.
FCS_COP.1/KW Cryptographic operation (Key Wrapping)
The inclusion of this selection-based component depends upon selection in FCS_KYC_EXT.1.1,
FCS_VAL_EXT.1.1/Admin, FCS_VAL_EXT.1.1/User.
FCS_COP.1.1/KW
The TSF shall perform [[selection: use platform-provided functionality to perform
Key Wrapping, implement functionality to perform Key Wrapping]] in accordance
with a specified cryptographic algorithm [ AES] in the following mode [selection:
Key Wrap
Key Wrap with Padding
GCM mode
CCM mode
]] and cryptographic key sizes [256 bits (AES)] that meet the following: [[selection:
“NIST SP 800-38C”
“NIST SP 800-38D”
“NIST SP 800-38F”
“NIST SP 800-38A”
]].
Application Note: This applies to any key wrapping occurring on the enterprise
server. This requirement is used in the body of the ST if the ST author chooses to use
key wrapping in the key chaining approach that is specified in FCS_KYC_EXT.1,
key wrap in the admin validation approach that is specified in
FCS_VAL_EXT.1.1/Admin, or key wrap in the user validation approach that is
specified in FCS_VAL_EXT.1.1/User.
Evaluation Activities
FCS_COP.1/KW
TSS
Conditional: If use platform provided functionality was selected, then the evaluator shall examine
the TSS to verify that it describes how the FEK encryption/decryption is invoked.
Conditional: If implement functionality was selected, the evaluator shall check that the TSS includes
a description of encryption function(s) used for key wrapping. The evaluator should check that this
description of the selected encryption function includes the key sizes and modes of operations as
specified in the selections above. The evaluator shall check that the TSS describes the means by
which the TOE satisfies constraints on algorithm parameters included in the selections made for
‘cryptographic algorithm’and ‘list of standards’.
The evaluator shall verify the TSS includes a description of the key wrap function(s) and shall verify
the key wrap uses an approved key wrap algorithm according to the appropriate specification.
KMD
The evaluator shall review the KMD to ensure that all keys are wrapped using the approved method
and a description of when the key wrapping occurs.
Guidance
If multiple encryption modes are supported, the evaluator examines the guidance documentation to
determine that the method of choosing a specific mode/key size is described.
Tests
The assurance activity tests specified for AES in GCM mode in the underlying [AppPP] shall be
performed in the case that "GCM" is selected in the requirement.
The assurance activity tests specified for AES in CBC mode in the underlying [AppPP] shall be
performed in the case that "CBC" is selected in the requirement.
AES Key Wrap (AES-KW) and Key Wrap with Padding (AES-KWP) Test
The evaluator will 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 will use the AES-KW
authenticated-encryption function of a known good implementation.
The evaluator will 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.
The evaluator will 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).
The evaluator will 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.
AES-CCM Tests
It is not recommended that evaluators use values obtained from static sources such as
http://csrc.nist.gov/groups/STM/cavp/documents/mac/ccmtestvectors.zip or use values not generated
expressly to exercise the AES-CCM implementation.
The evaluator shall test the generation-encryption and decryption-verification functionality of AES-
CCM for the following input parameter and tag lengths:
Keys: All supported and selected key sizes (e.g., 128, 256 bits).
Associated Data: Two or three values for associated data length: The minimum (≥ 0 bytes) and
maximum (≤ 32 bytes) supported associated data lengths, and 2^16 (65536) bytes, if supported.
Payload: Two values for payload length: The minimum (≥ 0 bytes) and maximum (≤ 32 bytes)
supported payload lengths.
Nonces: All supported nonce lengths (7, 8, 9, 10, 11, 12, 13) in bytes.
Tag: All supported tag lengths (4, 6, 8, 10, 12, 14, 16) in bytes.
The testing for CCM consists of five tests. To determine correctness in each of the below tests, the
evaluator shall compare the ciphertext with the result of encryption of the same inputs with a known
good implementation.
Variable Associated Data Test
For each supported key size and associated data length, and any supported payload length, nonce
length, 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.
Variable Payload Test
For each supported key size and payload length, and any supported associated data length, nonce
length, 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.
Variable Nonce Test
For each supported key size and nonce length, and any supported associated data length, payload
length, 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.
Variable Tag Test
For each supported key size and tag length, and any supported associated data length, payload
length, 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.
Decryption-Verification Process Test
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 sets of input plus ciphertext, and obtain the decrypted payload. Ten of the 15 input
sets supplied should fail verification and five should pass.
FCS_KDF_EXT.1 Cryptographic Key Derivation Function
The inclusion of this selection-based component depends upon selection in FCS_KYC_EXT.1.1.
FCS_KDF_EXT.1.1
The TSF shall accept [selection: a submask generated by an RBG as specified in
FCS_RBG_EXT.1 (from [AppPP]), a conditioned password, an imported submask]
to derive an intermediate key, as defined in [selection:
NIST SP 800-108 [selection: KDF in Counter Mode, KDF in Feedback Mode,
KDF in Double-Pipeline Iteration Mode]
NIST SP 800-132
] using the keyed-hash functions specified in FCS_COP.1/KeyedHash (from
[AppPP]), such that the output is at least of equivalent security strength (in number
of bits) to the [FEK(s)] .
Application Note: This requirement is used in the body of the ST if the ST author
chooses to use key derivation in the key chaining approach that is specified in
FCS_KYC_EXT.1. This applies to any key derivation occurring on the enterprise
server. This requirement establishes acceptable methods for generating a new
random key or an existing submask to create a new key along the key chain.
Evaluation Activities
FCS_KDF_EXT.1
TSS
Conditional: If 'not derive keys' was selected, then the evaluator shall only examine the TSS to verify
no key derivation is performed.
The evaluator shall verify 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 and SP 800-132.
KMD
The evaluator shall examine the vendor’s KMD to ensure that all keys used are derived using an
approved method and a description of how and when the keys are derived, including the input
values. The evaluator shall confirm the input values are from the sources listed in the requirement.
The evaluator will confirm the output is of equivalent strength to the FEK(s) it is protecting.
Guidance
None.
Tests
None.
FCS_SMC_EXT.1 Submask Combining
The inclusion of this selection-based component depends upon selection in FCS_KYC_EXT.1.1.
FCS_SMC_EXT.1.1
The TSF shall combine submasks using the following method: [[selection: exclusive
OR (XOR), SHA-384, SHA-512, HMAC-SHA-384, HMAC-SHA-512]] to generate an
intermediate key .
Application Note: This requirement is used in the body of the ST if the ST author
chooses to use key combining in the key chaining approach that is specified in
FCS_KYC_EXT.1. This applies to any submask combining occurring on the
enterprise server. This requirement specifies the way that a product may combine the
various submasks by using either an XOR or an approved SHA-hash.
Evaluation Activities
FCS_SMC_EXT.1
TSS
If keys are XORed together to form an intermediate key, the TSS section shall identify how this is
performed (e.g., if there are ordering requirements, checks performed, etc.). The evaluator shall also
confirm that the TSS describes how the length of the output produced is at least the same as that of
the FEK.
KMD
None.
Guidance
None.
Tests
None.
FCS_VAL_EXT.2/Admin Validation Remediation (Server Administrator)
The inclusion of this selection-based component depends upon selection in FIA_AUT_EXT.1.1.
FCS_VAL_EXT.2.1/Admin
The TSF shall [selection:
institute a delay such that only [assignment: ST author specified number or
configurable range of attempts] validation attempts can be made within a 24
hour period
block validation after [assignment: ST author specified number or
configurable range of attempts] of consecutive failed validation attempts
].
Application Note: This requirement must be claimed by the TOE if the ST author
chooses "provide user authorization" in FIA_AUT_EXT.1.1.
Evaluation Activities
FCS_VAL_EXT.2/Admin
TSS
The evaluator shall examine the TSS to determine which remediation options are supported for
which authentication options.
KMD
None.
Guidance
If the remediation functionality is configurable, the evaluator shall examine the operational
guidance to ensure it describes how to configure the TOE to ensure the limits regarding validation
attempts can be established.
Tests
The evaluator shall perform the following tests:
Test FCS_VAL_EXT.2/Admin:1: The evaluator shall determine the limit on the average rate of
the number of consecutive failed authorization attempts. For each authentication factor
supported, the evaluator will test the TOE by entering that number of incorrect authorization
factors in consecutive attempts to access the protected data. If the limit mechanism includes
any "lockout" period, the time period tested should include at least one such period. Then the
evaluator will verify that the TOE behaves as described in the TSS.
B.2 Identification and Authentication (FIA)
FIA_CHR_EXT.1 Challenge/Response Recovery Credential
The inclusion of this selection-based component depends upon selection in FIA_REC_EXT.1.2.
FIA_CHR_EXT.1.1
The TSF shall generate a response only if it is able to access recovery information
for [selection: the user requesting the recovery, the user requesting recovery and the
device for which the recovery was requested].
Application Note: This requires that the TSF has the ability to attribute key chain
information to the appropriate user(s).
FIA_CHR_EXT.1.2
The response shall work only for the user to whom it was generated.
Application Note: This mechanism is intended to provide a recovery method for a
user who has forgotten their authentication factor and is unable to access their
encrypted data on a system that is fully functional.
FIA_CHR_EXT.1.3
The response shall be used only during the same session in which the request was
generated.
Application Note: The intent of this requirement is to limit the attack surface of the
recovery credential mechanism by preventing the use of the credential following a
reboot of the device.
FIA_CHR_EXT.1.4
The TSF shall generate an ephemeral response that has at least as many potential
values as a corresponding password or PIN.
FIA_CHR_EXT.1.5
The TSF shall allow a maximum of [assignment: integer value] response entry
attempts per boot cycle.
FIA_CHR_EXT.1.6
The TSF shall perform remediation as defined in FCS_VAL_EXT.2/User for failed
challenge recovery attempts.
Evaluation Activities
FIA_CHR_EXT.1
TSS
The evaluator shall examine the TSS to determine that the methods for requesting a Recovery
credential are specified. The TSS shall also describe the methods used to verify user requesting the
Recovery credential. The evaluator shall also verify that the TSS contains the estimation of the
strength of the ephemeral response and that it has at least as many potential values as a
corresponding password or PIN.
KMD
None.
Guidance
The evaluator shall confirm that the guidance documentation contains instructions for enforcing
verification of the user for which the Recovery credential is requested. The guidance shall also
describe configuring of the limit for consecutive failed validation attempts if this value is
configurable.
Tests
The evaluator shall ensure that a response is only generated if the user for which recovery is
requested are verified as specified in TSS. The evaluator shall also ensure that the response is
applicable only on behalf of the requesting user with the constraints specified for consecutive failed
authentication attempts.
The term “managed” below is used to refer a user or device which is registered on the server, i.e.
their identity can be successfully verified by either administrator or TSF. The “unmanaged”
presumes that the user/device cannot be successfully verified.
The evaluator shall perform the following tests:
Test FIA_CHR_EXT.1:1: The evaluator shall configure the Challenge/Response recovery to
validate the user. The evaluator shall then issue a challenge on behalf of a managed user and
ensure that TSF successfully generates the response.
Test FIA_CHR_EXT.1:2: The evaluator shall configure Challenge/Response recovery to
validate the user. The evaluator shall then issue a challenge on behalf of managed User A and
attempt to use it as an unmanaged User B to obtain a response. This should fail.
Test FIA_CHR_EXT.1:3: The evaluator shall issue a challenge on behalf of a managed user
and ensure that the response received successfully will log the user in on that device.
Test FIA_CHR_EXT.1:4: The evaluator shall attempt to reuse the response of User A with
User B on the same system and it should fail.
Test FIA_CHR_EXT.1:5: The evaluator shall issue a challenge on behalf of a managed user
from a managed system, reboot the system [system terminates the session] and enter the
response. This should fail.
Test FIA_CHR_EXT.1:6: The evaluator shall issue a challenge on behalf of a managed user
and attempt to enter an incorrect response on the system the number of times described in the
Guidance Documents. The observed behavior shall conform to the assignments/selections in
FIA_CHR_EXT.1.5 and FIA_CHR_EXT.1.6.
B.3 Trusted Path/Channels (FTP)
FTP_TRP.1 Trusted Path
The inclusion of this selection-based component depends upon selection in FMT_SMR.2.3.
FTP_TRP.1.1
The TSF shall be capable of using [selection: IPsec as defined in the PP-Module
for VPN Client, HTTPS in accordance with FCS_HTTPS_EXT.1 (from [AppPP]),
TLS as defined in the Functional Package for Transport Layer Security (TLS),
version 2.1, SSH as defined in the Functional Package for Secure Shell (SSH),
version 2.0] to provide a communication path between itself and authorized remote
administrators that is logically distinct from other communication paths and
provides assured identification of its end points and protection of the communicated
data from [modification, disclosure].
FTP_TRP.1.2
The TSF shall permit remote administrators to initiate communication via the
trusted path.
FTP_TRP.1.3
The TSF shall require the use of the trusted path for [initial administrator
authentication, [all remote administration actions]].
Application Note: This SFR is intended to define protected communications
between the Management Server and remote administrators.
Evaluation Activities
FTP_TRP.1
TSS
The evaluator shall examine the TSS to determine that the methods of remote TOE administration
are indicated, along with how those communications are protected. The evaluator shall also confirm
that all protocols listed in the TSS in support of TOE administration are consistent with those
specified in the requirement, and are included in the requirements in the ST.
KMD
None.
Guidance
The evaluator shall confirm that the guidance documentation contains instructions for establishing
the remote administrative sessions for each supported method.
Tests
The evaluator shall perform the following tests:
Test FTP_TRP.1:1: The evaluators shall ensure that communications using each specified (in
the guidance documentation) remote administration method are tested during the course of
the evaluation, setting up the connections as described in the guidance documentation and
ensuring that communication is successful.
Test FTP_TRP.1:2: For each protocol that the TOE can initiate as defined in the requirement,
the evaluator shall follow the guidance documentation to ensure that in fact the
communication channel can be initiated from the TOE.
Test FTP_TRP.1:3: The evaluator shall ensure, for each communication channel with an
authorized IT entity, the channel data is not sent in plaintext.
Test FTP_TRP.1:4: The evaluator shall ensure that, for each protocol associated with each
authorized IT entity tested during test 1, the connection is physically interrupted. The
evaluator shall ensure that when physical connectivity is restored, communications are
appropriately protected.
Further evaluation activities are associated with the specific protocols.
Appendix C - Extended Component Definitions
This appendix contains the definitions for all extended requirements specified in the PP-Module.
C.1 Extended Components Table
All extended components specified in the PP-Module are listed in this table:
Table 6: Extended Component Definitions
Functional Class Functional Components
Cryptographic Support (FCS) FCS_CKM_EXT Cryptographic Key Management
FCS_KDF_EXT Cryptographic Key Derivation Function
FCS_KYC_EXT Key Chaining and Key Storage
FCS_SMC_EXT Submask Combining
FCS_VAL_EXT Validation
Identification and Authentication (FIA) FIA_AUT_EXT Authorization
FIA_CHR_EXT Challenge/Response Recovery Credential
FIA_REC_EXT Recovery Support
Protection of the TSF (FPT) FPT_KYP_EXT Protection of Key and Key Material
C.2 Extended Component Definitions
C.2.1 Cryptographic Support (FCS)
This PP-Module defines the following extended components as part of the FCS class originally defined by CC Part
2:
C.2.1.1 FCS_CKM_EXT Cryptographic Key Management
Family Behavior
Components in this family define requirements for key management activities that are beyond the scope of what
is defined in the FCS_CKM family in CC Part 2.
Component Leveling
FCS_CKM_EXT 6
FCS_CKM_EXT.6, Cryptographic Password/Passphrase Conditioning, requires the TSF to implement
password/passphrase conditioning using a specified algorithm and with specific constraints on the
password/passphrase composition.
Management: FCS_CKM_EXT.6
There are no specific management functions identified.
Audit: FCS_CKM_EXT.6
There are no auditable events foreseen.
FCS_CKM_EXT.6 Cryptographic Password/Passphrase Conditioning
Hierarchical to: No other components.
Dependencies to: FCS_COP.1 Cryptographic Operation
FCS_RBG_EXT.1 Random Bit Generation
FCS_CKM_EXT.6.1
The TSF shall support a password/passphrase of up to [assignment: maximum password size, positive integer
of 64 or more] characters used to generate a password authorization factor.
FCS_CKM_EXT.6.2
The TSF shall allow passwords to be composed of any combination of upper case characters, lower case
characters, numbers, and the following special characters: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, and “)”,
and [selection: [assignment: other supported special characters], no other characters].
FCS_CKM_EXT.6.3
The TSF shall perform Password-based Key Derivation Functions in accordance with a specified
cryptographic algorithm HMAC-[selection: SHA-384, SHA-512], with [selection: [assignment: positive
integer of 4096 or more] iterations, value supported by the platform, greater than 1000], and output
cryptographic key sizes [assignment: output key size] that meet the following: [assignment: applicable
standard].
FCS_CKM_EXT.6.4
The TSF shall not accept passwords less than [selection: a value settable by the administrator, [assignment:
minimum password length accepted by the TOE, must be >= 1]] and greater than the maximum password
length defined in FCS_CKM_EXT.6.1.
FCS_CKM_EXT.6.5
The TSF shall generate all salts using an RBG that meets FCS_RBG_EXT.1 and with entropy corresponding
to the security strength selected for PBKDF in FCS_CKM_EXT.6.3.
C.2.1.2 FCS_KYC_EXT Key Chaining and Key Storage
Family Behavior
Components in this family define requirements for the secure storage of keys through the use of a logical key
chain.
Component Leveling
FCS_KYC_EXT 1
FCS_KYC_EXT.1, Key Chaining and Key Storage, requires the TSF to specify how it implements key chaining.
Management: FCS_KYC_EXT.1
The following actions could be considered for the management functions in FMT:
Configuration of the cryptographic functionality.
Audit: FCS_KYC_EXT.1
There are no auditable events foreseen.
FCS_KYC_EXT.1 Key Chaining and Key Storage
Hierarchical to: No other components.
Dependencies to: FCS_COP.1 Cryptographic Operation
FCS_KDF_EXT.1 Cryptographic Key Derivation Function
FCS_SMC_EXT.1 Submask Combining
FCS_KYC_EXT.1.1
The TSF shall maintain a key chain of: [selection:
a conditioned password as the [assignment: key type]
[assignment: key type] originating from [assignment: origin of key] to [assignment: end point of key
chain] using the following method(s): [assignment: list of supported key protection methods] while
maintaining an effective strength of commensurate with the strength of the FEK
] and [selection: no supplemental key chains, other supplemental key chains that protect a key or keys in the
primary key chain using the following method(s): [assignment: list of supported key protection methods]].
C.2.1.3 FCS_VAL_EXT Validation
Family Behavior
Components in this family define requirements for validation of data supplied to the TOE and any consequences
resulting from failed validation attempts.
Component Leveling
FCS_VAL_EXT
1
2
FCS_VAL_EXT.1, Validation, requires the TSF to specify what data is being validated and how the validation is
performed.
FCS_VAL_EXT.2, Validation Remediation, requires the TSF to specify what the TOE’s response is in the event
of a data validation failure.
Management: FCS_VAL_EXT.1
There are no specific management functions identified.
Audit: FCS_VAL_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
Minimal: Change to configuration of validation function behavior.
FCS_VAL_EXT.1 Validation
Hierarchical to: No other components.
Dependencies to: FCS_COP.1 Cryptographic Operation
FCS_VAL_EXT.1.1
The TSF shall perform validation of the [assignment: subject requiring validation] by [selection:
receiving assertion of the subject's validity from [assignment: Operational Environment component
responsible for authentication]
validating the [selection: submask, intermediate key] using the following methods: [selection:
key wrap as specified in FCS_COP.1
hash the [selection: submask, intermediate key, FEK] as specified in FCS_COP.1 and compare it
to a stored hash
decrypt a known value using the [selection: submask, intermediate key, FEK] as specified in
FCS_COP.1 and compare it against a stored known value
]
].
FCS_VAL_EXT.1.2
The TSF shall require validation of the [assignment: subject requiring validation] prior to [assignment:
action requiring validation].
Management: FCS_VAL_EXT.2
The following actions could be considered for the management functions in FMT:
Configuration of the number of failed validation attempts required to trigger corrective behavior.
Configuration of the corrective behavior to issue in the event of an excessive number of failed validation
attempts.
Audit: FCS_VAL_EXT.2
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
Minimal: Triggering of excessive validation failure response behavior.
FCS_VAL_EXT.2 Validation Remediation
Hierarchical to: No other components.
Dependencies to: FCS_VAL_EXT.1 Validation
FCS_VAL_EXT.2.1
The TSF shall [selection:
institute a delay such that only [assignment: specified number of] validation attempts can be made
within a 24 hour period
block validation after [assignment: specified number of] consecutive failed validation attempts
[assignment: remediation action] upon [assignment: specified number of] consecutive failed validation
attempts
].
C.2.1.4 FCS_KDF_EXT Cryptographic Key Derivation Function
Family Behavior
Components in this family define requirements for the implementation of cryptographic key derivation functions
Component Leveling
FCS_KDF_EXT 1
FCS_KDF_EXT.1, Cryptographic Key Derivation Function, requires the TSF to specify how it performs key
derivation.
Management: FCS_KDF_EXT.1
The following actions could be considered for the management functions in FMT:
Configuration of the cryptographic functionality.
Audit: FCS_KDF_EXT.1
There are no auditable events foreseen.
FCS_KDF_EXT.1 Cryptographic Key Derivation Function
Hierarchical to: No other components.
Dependencies to: FCS_COP.1 Cryptographic Operation
FCS_RBG_EXT.1 Random Bit Generation
FCS_KDF_EXT.1.1
The TSF shall accept [selection: a submask generated by an RBG as specified in FCS_RBG_EXT.1, a
conditioned password, an imported submask] to derive an intermediate key, as defined in [selection:
NIST SP 800-108 [selection: KDF in Counter Mode, KDF in Feedback Mode, KDF in Double-Pipeline
Iteration Mode]
NIST SP 800-132
] using the keyed-hash functions specified in FCS_COP.1, such that the output is at least of equivalent security
strength (in number of bits) to the [assignment: key that is being derived].
C.2.1.5 FCS_SMC_EXT Submask Combining
Family Behavior
Components in this family define requirements for generation of intermediate keys via submask combining.
Component Leveling
FCS_SMC_EXT 1
FCS_SMC_EXT.1, Submask Combining, requires the TSF to implement submask combining in a specific
manner to support the generation of intermediate keys.
Management: FCS_SMC_EXT.1
The following actions could be considered for the management functions in FMT:
Configuration of the cryptographic functionality.
Audit: FCS_SMC_EXT.1
There are no auditable events foreseen.
FCS_SMC_EXT.1 Submask Combining
Hierarchical to: No other components.
Dependencies to: FCS_COP.1 Cryptographic Operation
FCS_SMC_EXT.1.1
The TSF shall combine submasks using the following method: [assignment: submask combination method] to
generate an intermediate key.
C.2.2 Identification and Authentication (FIA)
This PP-Module defines the following extended components as part of the FIA class originally defined by CC Part
2:
C.2.2.1 FIA_AUT_EXT Authorization
Family Behavior
Components in this family define requirements for how subject authorization is performed. Where FIA_UAU in
CC Part 2 defines circumstances where authentication is required, this family describes the specific
computational methods used to determine whether a subject’s presented authentication data is valid.
Component Leveling
FIA_AUT_EXT 1
FIA_AUT_EXT.1, Subject Authorization, specifies the manner in which the TSF performs user authorization.
Management: FIA_AUT_EXT.1
The following actions could be considered for the management functions in FMT:
Configuration of authentication factors.
Audit: FIA_AUT_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
Minimal: Failure of authorization function.
Basic: All use of authorization function.
FIA_AUT_EXT.1 Subject Authorization
Hierarchical to: No other components.
Dependencies to: FCS_CKM_EXT.6 Cryptographic Password/Passphrase Conditioning
FCS_RBG_EXT.1 Random Bit Generation
FIA_AUT_EXT.1.1
The TSF shall [selection: receive assertion of the user’s validity from: [assignment: Operational Environment
component responsible for user authentication], provide authorization] based on [selection:
a password authorization factor conditioned as defined in FCS_CKM_EXT.6
an external smart card factor that is at least the same bit-length as the FEK(s), and is protecting a
submask that is [selection: generated by the TOE (using the RBG as specified in FCS_RBG_EXT.1),
generated by the platform] protected using asymmetric keys as defined in FCS_CKM.1.1/AK (from
[AppPP]) with user presence proved by presentation of the smart card and [selection: no PIN, an OE
defined PIN, a configurable PIN]
an external USB token factor that is at least the same security strength as the FEK(s), and is providing a
submask generated by the [selection: TOE, using the RBG as specified in FCS_RBG_EXT.1, platform]
].
C.2.2.2 FIA_REC_EXT Recovery Support
Family Behavior
Components in this family define the TOE’s support for recovery credentials as an alternate method for user
authorization.
Component Leveling
FIA_REC_EXT 1
FIA_REC_EXT.1, Recovery Support, requires the TSF to specify the supported recovery method and to include
a means to enable/disable any supported recovery method.
Management: FIA_REC_EXT.1
The following actions could be considered for the management functions in FMT:
Ability to enable/disable the user of recovery credentials.
Ability to change recovery credential values.
Audit: FIA_REC_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
Minimal: Configuration of recovery methods.
FIA_REC_EXT.1 Recovery Support
Hierarchical to: No other components.
Dependencies to: No dependencies.
FIA_REC_EXT.1.1
The TSF shall [selection: provide the ability to enable and disable the use of recovery credentials, not support
recovery].
FIA_REC_EXT.1.2
The TSF shall support the following recovery mechanisms [selection: Challenge Response Recovery as
defined in FIA_CHR_EXT.1, None].
C.2.2.3 FIA_CHR_EXT Challenge/Response Recovery Credential
Family Behavior
Components in this family define requirements for the use of challenge/response as a recovery method.
Component Leveling
FIA_CHR_EXT 1
FIA_CHR_EXT.1, Challenge/Response Recovery Credential, requires the TSF to implement a
challenge/response method to generate recovery credentials for an authorized user.
Management: FIA_CHR_EXT.1
The following actions could be considered for the management functions in FMT:
Ability to enable/disable the user of recovery credentials.
Ability to change recovery credential values.
Audit: FIA_CHR_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
Minimal: Failure of recovery attempt.
Basic: All recovery attempts.
FIA_CHR_EXT.1 Challenge/Response Recovery Credential
Hierarchical to: No other components.
Dependencies to: FCS_VAL_EXT.1 Validation
FIA_REC_EXT.1 Recovery Support
FIA_CHR_EXT.1.1
The TSF shall generate a response only if it is able to access recovery information for [selection: the user
requesting the recovery, the user requesting recovery and the device for which the recovery was requested].
FIA_CHR_EXT.1.2
The response shall work only for the user to whom it was generated.
FIA_CHR_EXT.1.3
The response shall be used only during the same session in which the request was generated.
FIA_CHR_EXT.1.4
The TSF shall generate an ephemeral response that has at least as many potential values as a corresponding
password or PIN.
FIA_CHR_EXT.1.5
The TSF shall allow a maximum of [assignment: integer value] response entry attempts per boot cycle.
FIA_CHR_EXT.1.6
The TSF shall perform remediation as defined in FCS_VAL_EXT.2 for failed challenge recovery attempts.
C.2.3 Protection of the TSF (FPT)
This PP-Module defines the following extended components as part of the FPT class originally defined by CC Part
2:
C.2.3.1 FPT_KYP_EXT Protection of Key and Key Material
Family Behavior
Components in this family define requirements for secure storage of keys.
Component Leveling
FPT_KYP_EXT
1
2
FPT_KYP_EXT.1, Protection of Keys and Key Material , requires the TSF to protect stored key data in a
specified manner.
FPT_KYP_EXT.2, Attribution of Key and Key Material, requires the TSF to protect stored key data in a
specified manner.
Management: FPT_KYP_EXT.1
The following actions could be considered for the management functions in FMT:
Configuration of the cryptographic functionality.
Audit: FPT_KYP_EXT.1
There are no auditable events foreseen.
FPT_KYP_EXT.1 Protection of Keys and Key Material
Hierarchical to: No other components.
Dependencies to: FCS_COP.1 Cryptographic Operation
FCS_KDF_EXT.1 Cryptographic Key Derivation Function
FCS_KYC_EXT.1 Key Chaining and Key Storage
FCS_SMC_EXT.1 Submask Combining
FCS_STO_EXT.1 Storage of Credentials
FPT_KYP_EXT.1.1
The TSF shall store keys in non-volatile memory only when [selection:
wrapped, as specified in FCS_COP.1
encrypted, as specified in FCS_COP.1
the plaintext key is stored in the underlying platform's keystore as specified by FCS_STO_EXT.1
the plaintext key is stored in a SQL database in the Operational Environment
the plaintext key is not part of the key chain as specified in FCS_KYC_EXT.1.
the plaintext key will no longer provide access to the encrypted data after initial provisioning
the plaintext key is a key split that is combined as specified in FCS_SMC_EXT.1 and another
contribution to the split is [selection: wrapped as specified in FCS_COP.1, derived and not stored in
non-volatile memory]
the plaintext key is stored on an external storage device for use as an authorization factor.
the plaintext key is used to wrap a key as specified in FCS_COP.1 that is already wrapped as specified
in FCS_COP.1
].
Management: FPT_KYP_EXT.2
The following actions could be considered for the management functions in FMT:
Registration of users.
Revocation of user registration.
Audit: FPT_KYP_EXT.2
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
Basic: Creation and revocation of user registration.
FPT_KYP_EXT.2 Attribution of Key and Key Material
Hierarchical to: No other components.
Dependencies to: FPT_ITT.1 Basic Internal TSF Data Transfer Protection
FPT_KYP_EXT.2.1
The TSF shall maintain an association between stored endpoint keys and user identity, [selection: remote
endpoints, recovery credential, system identity, no other subjects].
FPT_KYP_EXT.2.2
The TSF shall provide the ability to register users by exchange of [assignment: mutually identifying
information that allows for an association to be made].
FPT_KYP_EXT.2.3
The TSF shall provide the ability to revoke the registration of users by [assignment: method of removing
and/or exchanging information that prevents further communications between the TOE and the endpoint].
FPT_KYP_EXT.2.4
The TSF shall transmit any secure or private cryptographic information that is transferred between the TOE
and a user's endpoint in order to establish or disestablish an association using a communications channel with
a security strength at least as great as the strength of the information being transmitted.
Appendix D - Key Management Description
This appendix should be combined with the appendix in the PP-Module for File Encryption if it is also being
evaluated. 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.
Essay:
The essay will provide the following information for all keys in the key chain:
The purpose of the key
If the key is stored in non-volatile memory
How and when the key is protected
How and when the key is derived
The strength of the key
When or if the key would be no longer needed, along with a justification
How and when a key may be transmitted
The essay will also describe the following topics:
A description of all authorization factors that are supported by the product and how each factor is handled,
including any conditioning and combining performed.
If validation is implemented, the process for validation shall be described, noting what value is used for validation
and the process used to perform the validation. It shall describe how this process ensures no keys in the key chain
are weakened or exposed by this process.
The authorization process that leads to the recovery or access by an end user or administrator. This section shall
detail the key chain used by the product. It shall describe which keys are used in the protection of the FEK(s) or
KEK(s) and how they meet the encryption or derivation requirements, including the direct chain from the initial
authorization to the FEK(s) or KEK(s). It shall also include any values that add into that key chain or interact with
the key chain and the protections that ensure those values do not weaken or expose the overall strength of the key
chain.
The diagram and essay will clearly illustrate the key hierarchy to ensure that at no point the chain could be broken
without a cryptographic exhaust or all of the initial authorization values and the effective strength of the FEK(s) is
maintained throughout the key chain.
A description of the data encryption engine, its components, and details about its implementation (e.g. initialization
of the product, drivers, libraries (if applicable), logical interfaces for encryption/decryption, and how resources to
be encrypted are identified. The description should also include the data flow from the device’s host interface to the
device’s persistent media storing the data or transmission to and endpoint, information on those conditions in which
the data bypasses the data encryption engine. The description should be detailed enough to verify all platforms
ensure that when the user enables encryption, the product encrypts all selected resources.
The process for destroying keys when they are no longer needed by describing the storage location of all keys and
the protection of all keys stored in non-volatile memory.
Diagram:
The diagram will include all keys from the initial authorization factor(s) to the FEK(s) and any keys or values that
contribute into the chain. It must list the cryptographic strength of each key and indicate how each key along the
chain is protected with either options from key chaining requirement. The diagram should indicate the input used to
derive or decrypt each key in the chain.
A functional (block) diagram showing the main components (such as memories and processors) the initial steps
needed for the activities the TOE performs to ensure it encrypts the targeted resources when a user or administrator
first provisions the product.
Appendix E - Acronyms
Table 7: Acronyms
Acronym Meaning
AF Authorization factor
Base-PP Base Protection Profile
CC Common Criteria
CEM Common Evaluation Methodology
cPP Collaborative Protection Profile
EP Extended Package
FEK File Encryption Key
FP Functional Package
KEK Key Encryption Key
OE Operational Environment
PP Protection Profile
PP-Configuration Protection Profile Configuration
PP-Module Protection Profile Module
RBG Random Bit Generator
SAR Security Assurance Requirement
SFR Security Functional Requirement
ST Security Target
TOE Target of Evaluation
TSF TOE Security Functionality
TSFI TSF Interface
TSS TOE Summary Specification
Appendix F - Bibliography
Table 8: Bibliography
Identifier Title
[CC] Common Criteria for Information Technology Security Evaluation -
Part 1: Introduction and general model, CCMB-2022-11-001, CC:2022, Revision 1,
November 2022.
Part 2: Security functional requirements, CCMB-2022-11-002, CC:2022, Revision 1,
November 2022.
Part 3: Security assurance requirements, CCMB-2022-11-003, CC:2022, Revision 1,
November 2022.
Part 4: Framework for the specification of evaluation methods and activities, CCMB-2022-
11-004, CC:2022, Revision 1, November 2022.
Part 5: Pre-defined packages of security requirements, CCMB-2022-11-005, CC:2022,
Revision 1, November 2022.
[CEM] Common Methodology for Information Technology Security Evaluation -
Evaluation methodology, CCMB-2022-11-006, CC:2022, Revision 1, November 2022.
[AppPP] Protection Profile for Application Software, Version 2.0, June 16, 2025
[FIPS140-2] Federal Information Processing Standard Publication (FIPS-PUB) 140-2, Security Requirements
for Cryptographic Modules, National Institute of Standards and Technology, March 19, 2007
[FIPS180-4] Federal Information Processing Standards Publication (FIPS-PUB) 180-4, Secure Hash Standard,
March, 2012
[FIPS186-5] Federal Information Processing Standard Publication (FIPS-PUB) 186-5, Digital Signature
Standard (DSS), National Institute of Standards and Technology, February 2023
[FIPS197] Federal Information Processing Standards Publication (FIPS-PUB) 197, Specification for the
Advanced Encryption Standard (AES), November 26, 2001
[FIPS198-1] Federal Information Processing Standards Publication (FIPS-PUB) 198-1, The Keyed-Hash
Message Authentication Code (HMAC), July 2008
[NIST800-
132]
NIST Special Publication 800-132, Recommendation for Password-Based Key Derivation,
December 2010
[NIST800-
38A]
NIST Special Publication 800-38A, Recommendation for Block Cipher Modes of Operation:
Methods and Techniques, 2001 Edition
[NIST800-
38F]
NIST Special Publication 800-38F,Recommendation for Block Cipher Modes of Operation:
Methods for Key Wrapping, December 2012
[NIST800-
56A]
NIST Special Publication 800-56A, Recommendation for Pair-Wise Key Establishment Schemes
Using Discrete Logarithm Cryptography (Revised), March 2007
[NIST800-
56B]
NIST Special Publication 800-56B, Recommendation for Pair-Wise Key Establishment Schemes
Using Integer Factorization Cryptography, August 2009
[NIST800-
90]
NIST Special Publication 800-90, Recommendation for Random Number Generation Using
Deterministic Random Bit Generators (Revised), March 2007