The purpose of the first set of Collaborative Protection Profiles (cPPs) for Full Drive Encryption (FDE): Authorization Acquisition (AA) and Encryption Engine (EE) is to provide requirements for Data-at-Rest protection for a lost device that contains storage. These cPPs allow FDE solutions based in software and/or hardware to meet the requirements. The form factor for a storage device may vary, but could include: system hard drives/solid state drives in servers, workstations, laptops, mobile devices, tablets, and external media. A hardware solution could be a Self-Encrypting Drive or other hardware-based solutions; the interface (USB, SATA, etc.) used to connect the storage device to the host machine is outside the scope of this cPP.
Full Drive Encryption encrypts all data (with certain exceptions) on the storage device and permits access to the data only after successful authorization to the FDE solution. The exceptions include the necessity to leave a portion of the storage device (the size may vary based on implementation) unencrypted for such things as the Master Boot Record (MBR) or other AA/EE pre-authentication software. These FDEcPPs interpret the term “full drive encryption” to allow FDE solutions to leave a portion of the storage device unencrypted so long as it does not contain plaintext user or plaintext authorization data.
Since the FDEcPPs support a variety of solutions, two cPPs describe the requirements for the FDE components shown in Figure 1.
The FDEcPP - Authorization Acquisition describes the requirements for the Authorization Acquisition piece and details the security requirements and assurance activities necessary to interact with a user and result in the availability of sending a Border Encryption Value (BEV) to the Encryption Engine.
The FDEcPP - Encryption Engine describes the requirements for the Encryption Engine piece and details the necessary security requirements and assurance activities for the actual encryption/decryption of the data by the DEK. Each cPP will also have a set of core requirements for management functions, proper handling of cryptographic keys, updates performed in a trusted manner, audit and self-tests.
This TOE description defines the scope and functionality of the Authorization Acquisition, and
the Security Problem Definition describes the assumptions made about the operating
environment and the threats to the AA that the cPP requirements address
1.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.
Direct Rationale
A type of Protection Profile, PP-Module, or Security Target in which the security
problem definition (SPD) elements are mapped directly to the SFRs and possibly to the
security objectives for the operational environment. There are no security objectives
for the TOE.
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.
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 submitted by the user, present on the host, or present on a separate protected hardware physical
device used to establish that the user is in the community authorized to use the TOE. The authorization factors are used
to generate the KEK. Note that these AFs are not used to establish the particular identity of the user.
Border Encryption Value (BEV)
A value passed from the FDE Authorization
Acquisition (AA) to the FDE Encryption Engine (EE) intended to link the key chains
of the two components.
Data Encryption Key (DEK)
A key used to encrypt data-at-rest.
Full Drive Encryption (FDE)
Refers to partitions of logical blocks of user accessible data as
managed by the host system that indexes and partitions and an
operating system that maps authorization to read or write data to blocks
in these partitions. For the sake of this Security Program Definition
(SPD) and cPP, FDE performs encryption and authorization on one
partition, so defined and supported by the OS and file system jointly,
under consideration. FDE products encrypt all data (with certain
exceptions) on the partition of the storage device and permits access to
the data only after successful authorization to the FDE solution. The
exceptions include the necessity to leave a portion of the storage device
(the size may vary based on implementation) unencrypted for such
things as the Master Boot Record (MBR) or other AA/EE pre-authentication software. These FDE cPPs interpret the term “full drive
encryption” to allow FDE solutions to leave a portion of the storage
device unencrypted so long as it contains no protected data.
Host Platform
The local hardware and software the TOE is running on, and does not
include any peripheral devices (e.g. USB devices) that may be
connected to the local hardware and software.
Intermediate Key
A key used in a point between the initial user authorization and the
DEK.
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)
A key used to encrypt other keys, such as DEKs or storage that
contains keys.
Key Material
Key material is commonly known as critical security parameter (CSP)
data, and also includes authorization data, nonces, and metadata.
Key Release Key (KRK)
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
that was encrypting the data.
Non-Volatile Memory
A type of computer memory that will retain information without
power.
Operating System (OS)
Software which runs at the highest privilege level and can directly
control hardware resources.
Powered-Off State
The device has been shut down.
Protected Data
This refers to all data on the storage device with the exception of a
small portion required for the TOE to function correctly. It is all space
on the disk a user could write data to and includes the operating
system, applications, and user data. Protected data does not include the
Master Boot Record or Pre-authentication area of the drive – areas of
the drive that are necessarily unencrypted.
Submask
A submask is a bit string that can be generated and stored in a number
of ways.
1.3 Implementation
Full Drive Encryption solutions vary with implementation and vendor combinations.
Therefore, vendors will evaluate products that provide both components of the Full Disk
Encryption Solution (AA and EE) against both cPPs – could be done in a single evaluation
with one ST. A vendor that provides a single component of a FDE solution would only evaluate
against the applicable cPP. The FDEcPP is divided into two documents to allow labs to
independently evaluate solutions tailored to one cPP or the other. When a customer acquires
an FDE solution, they will either obtain a single vendor product that meets the AA + EEcPPs
or two products, one of which meets the AA and the other of which meets the EEcPPs.
The table below illustrates a few examples for certification.
A single vendor’s combination of hardware (e.g. hardware encryption engine,
cryptographic co-processor) and software / firmware
1.4 TOE Overview
The Target of Evaluation (TOE) for this cPP (Authorization Acquisition) may be either a Host software solution that manages a HW Encryption Engine (e.g. a SED) or as part of a combined evaluation of this cPP and the Encryption Engine cPP for a vendor that is providing a solution that includes both components.
The following sections provide an overview of the functionality of the FDEAA as well as the security capabilities.
1.4.1 Authorization Acquisition Introduction
The Authorization Acquisition sends a Border Encryption Value (BEV), which could be a Key Encryption Key (KEK), a Key Releasing Key (KRK), or some other type of key to the Encryption Engine. The EE does not have to use this value directly as the key to decrypt or release the DEK. It may use it as part of a scheme that uses other intermediate keys to eventually protect the DEK. A KEK wraps other keys, notably the DEK or other intermediary keys which chain to the DEK. Key Releasing Keys (KRKs) authorize the EE to release either the DEK or other intermediary keys which chain to the DEK. Figure 2 illustrates the components within AA and its relationship with EE.
Figure 2:
Authorization Acquisition Details
Authorization factors may be unique to individual users or may be used by a group of individuals. In other words, the EE requires authorization factors from the AA to establish that the possessor of the authorization factor belongs to the community of users authorized to access information stored on the storage device (and does not require specific user authorization). Authorization factors are the specific value provided one of the supported authorization methods. Examples of authorization methods include, but are not limited to, passwords, passphrases, or randomly generated values stored on USB tokens or a pin to release a key on hardware storage media such as a Trusted Platform Module (TPM).
The AA collects authorization factors which the EE uses to access data on the storage device and perform a variety of management functions. Depending on the type of authorization method, the AA may condition them further. For example, it may apply an approved password-based key derivation function (e.g. PBKDF2) on passwords. In this cPP passwords also encompass passphrases. An external token containing a randomly generated value of sufficient strength may require no further conditioning on the authorization factor. The AA may then combine one or more authorization factors in such a way that maintains the strength of both factors.
The AA serves as the main management interface to the EE. However, the EE may also offer management functionality. The requirements in the EEcPP address how the EE should handle these features. The management functionality may include the ability to send commands to the EE such as changing a DEK, setting up new users, managing KEKs and other intermediate keys, and performing a key sanitization (e.g. overwrite of the DEK). It may also forward commands that partition the drive for use by multiple users. However, this document defers the management of partitions and assumes that administrators will only provision and manage the data on whole drives.
1.4.3 Interface/Boundary
The interface and boundary between the AA and the EE will vary based on the implementation. If one vendor provides the entire FDE solution, then it may choose to not implement an interface between the AA and EE components. If a vendor provides a solution for one of the components, then the assumptions below state that the channel between the two components is sufficiently secure. Although standards and specifications exist for the interface between AA and EE components, the cPP does not require vendors to follow the standards in this version.
1.5 Compliant Targets of Evaluation
1.5.1 TOE Boundary
The environment in which the AA functions may differ depending on the boot stage of the platform in which it operates, see Figure 3. Depending on the solution’s architecture, aspects of provisioning, initialization, and authorization may be performed in the Pre-Boot environment, while encryption, decryption and management functionality are likely performed in the Operating System environment. In non-software solutions, encryption/decryption starts in Pre-OS environment and continues into OS present environment.
In the Operating System environment, the Authorization Acquisition has the full range of services available from the operating system (OS), including hardware drivers, cryptographic libraries, and perhaps other services external to the TOE.
The Pre-Boot environment is much more constrained with limited capabilities. This environment turns on the minimum number of peripherals and loads only those drivers necessary to bring the platform from a cold start to executing a fully functional operating system with running applications.
The AATOE may include or leverage features and functions within the operational environment.
Figure 3:
Operational Environment
1.6 Use Cases
The use case for a product conforming to the FDEcPPs 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 these cPPs (i.e., FDE-AA and FDE- EE).
The evaluation methods used for evaluating the TOE are a combination of the workunits
defined in [CEM] as well as the Evaluation Activities for ensuring that individual SFRs
and SARs have a sufficient level of supporting evidence in the Security Target and guidance
documentation and have been sufficiently tested by the laboratory as part of completing
ATE_IND.1. Any functional packages this PP claims similarly contain their own Evaluation
Activities that are used in this same manner.
CC Conformance Claims
This PP is conformant to
Part 2 (extended)
and Part 3 (conformant)
of Common Criteria CC:2022, Revision 1.
PP Claim
This PP does not claim conformance to
any Protection Profile.
The following PPs and PP-Modules are allowed to be specified in a
PP-Configuration with this PP:
Package Claim
This PP is not conformant to any
Functional or Assurance Packages.
3 Security Problem Definition
3.1 Threats
This section provides a narrative that describes how the requirements mitigate the mapped
threats. A requirement may mitigate aspects of multiple threats. A requirement may only mitigate a threat in a limited way. Some requirements are optional, either because the TSF fully mitigates the threat without the additional requirements being claimed or because the TSF relies on its Operational Environment to provide the functionality that is described by the optional requirements.
A threat consists of a threat agent, an asset and an adverse action of that threat agent on that asset. The threat agents are the entities that put the assets at risk if an adversary obtains a lost or stolen storage device. Threats drive the functional requirements for the target of evaluation (TOE). For instance, one threat below is T.UNAUTHORIZED_DATA_ACCESS. The threat agent is the possessor (unauthorized user) of a lost or stolen storage device. The asset is the data on the storage device, while the adverse action is to attempt to obtain those data from the storage device. This threat drives the functional requirements for the storage device encryption (TOE) to authorize who can use the TOE to access the hard disk and encrypt/decrypt the data. Since possession of the KEK, DEK, intermediate keys, authorization factors, submasks, and random numbers or any other values that contribute to the creation of keys or authorization factors could allow an unauthorized user to defeat the encryption, this SPD considers key material equivalent to the data in importance and they appear among the other assets addressed below.
It is important to reemphasize at this point that this collaborative Protection Profile does not expect the product (TOE) to defend against the possessor of the lost or stolen hard disk who can introduce malicious code or exploitable hardware components into the Target of Evaluation (TOE) or the Operational Environment. It assumes that the user physically protects the TOE and that the Operational Environment provides sufficient protection against logical attacks. One specific area where a conformant TOE offers some protection is in providing updates to the TOE; other than this area, though, this cPP mandates no other countermeasures. Similarly, these requirements do not address the “lost and found” hard disk problem, where an adversary may have taken the hard disk, compromised the unencrypted portions of the boot device (e.g., MBR, boot partition), and then made it available to be recovered by the original user so that they would execute the compromised code.
T.AUTHORIZATION_GUESSING
Threat agents may exercise host software to repeatedly guess authorization factors, such as passwords and PINs. Successful guessing of an authorization factor may cause the TOE to release BEV or otherwise put it in a state in which it discloses protected data to unauthorized users.
T.KEYING_MATERIAL_COMPROMISE
Possession of any of the keys, authorization factors, submasks, and random
numbers or any other values that contribute to the creation of keys or authorization factors
could allow an unauthorized user to defeat the encryption. The cPP considers possession of
key material of equal importance to the data itself. Threat agents may look for key material
in unencrypted sectors of the storage device and on other peripherals in the operating environment
(OE), (e.g., BIOS configuration, SPI flash).
T.KEYSPACE_EXHAUST
Threat agents may perform a cryptographic exhaust against the key space. Poorly chosen encryption algorithms and parameters allow attackers to exhaust the key space through brute force and give them unauthorized access to the data.
T.UNAUTHORIZED_DATA_ACCESS
The cPP addresses the primary threat of unauthorized disclosure of protected data stored on a storage device. If an adversary obtains a lost or stolen storage device (e.g., a storage device contained in a laptop or a portable external storage device), they may attempt to connect a targeted storage device to a host of which they have complete control and have raw access to the storage device (e.g., to specified disk sectors, to specified blocks).
T.UNAUTHORIZED_UPDATE
Threat agents may attempt to perform an update of the product which compromises the security features of the TOE. Poorly chosen update protocols, signature generation and verification algorithms, and parameters may allow attackers to install software or firmware that bypasses the intended security features and provides them unauthorized access to data.
3.2 Assumptions
A.INITIAL_DRIVE_STATE
Users enable Full Drive Encryption on a newly provisioned or initialized storage device free of protected data in areas not targeted for encryption. The cPP does not intend to include requirements to find all the areas on storage devices that potentially contain protected data. In some cases, it may not be possible - for example, data contained in “bad” sectors.
While inadvertent exposure to data contained in bad sectors or un-partitioned space is unlikely, one may use forensics tools to recover data from such areas of the storage device. Consequently, the cPP assumes bad sectors, un-partitioned space, and areas that must contain unencrypted code (e.g., MBR and AA/EE pre-authentication software) contain no protected data.
A.PASSWORD_STRENGTH
Authorized users ensure passwords authorization factors have sufficient strength and entropy to reflect the sensitivity of the data being protected.
A.PHYSICAL
The platform is assumed to be physically protected in its Operational Environment and not subject to physical attacks that compromise the security and/or interfere with the platform’s correct operation.
A.PLATFORM_IA
The product does not interfere with or change the normal platform identification and authentication functionality such as the operating system login. It may provide authorization factors to the operating system's login interface, but it will not change or degrade the functionality of the actual interface.
A.PLATFORM_STATE
The platform in which the storage device resides (or an external storage device is connected) is free of malware that could interfere with the correct operation of the product.
A.POWER_DOWN
The user does not leave the platform and/or storage device unattended until all volatile memory is erased after a power-off, so memory remnant attacks are infeasible.
Authorized users do not leave the platform and/or storage device in a mode where sensitive information persists in non-volatile storage (e.g., lock screen). Users power the platform and/or storage device down or place it into a power managed state, such as a “hibernation mode”.
A.SECURE_STATE
Upon the completion of proper provisioning, the TOE is only assumed secure when in a powered off state up until it is powered on and receives initial authorization.
A.SINGLE_USE_ET
External tokens that contain authorization factors are used for no other purpose than to store the external token authorization factors.
A.STRONG_CRYPTO
All cryptography implemented in the Operational Environment and used by the product meets the requirements listed in the cPP. This includes generation of external token authorization factors by a RBG.
A.TRAINED_USER
Authorized users follow all provided user guidance, including keeping passwords and external tokens securely stored separately from the storage device and/or platform.
A.TRUSTED_CHANNEL
Communication among and between product components (e.g., AA and EE) is
sufficiently protected to prevent information disclosure. In cases in which a single
product fulfils both cPPs, the communication between the components does not
extend beyond the boundary of the TOE (e.g., communication path is within the TOE
boundary) so this assumption is inherently met. In cases in which independent products satisfy the requirements of the
AA and EE, the physically close proximity of the two products during their operation
means that the threat agent has very little opportunity to interpose itself in the
channel between the two without the user noticing and taking appropriate actions.
3.3 Organizational Security Policies
This document does not define any additional OSPs.
4 Security Objectives
4.1 Security Objectives for the Operational Environment
The Operational Environment of the TOE implements technical and procedural measures to assist the TOE in correctly providing its security functionality. This part wise solution forms the security objectives for the Operational Environment and consists of a set of statements describing the goals that the Operational Environment should achieve.
OE.INITIAL_DRIVE_STATE
The OE provides a newly provisioned or initialized storage device free of protected data in
areas not targeted for encryption.
Rationale: Since the cPP requires all protected data to encrypted, A.INITIAL_DRIVE_STATE assumes
that the initial state of the device targeted FDE is free of protected data in those areas of
the drive where encryption will not be invoked (e.g., MBR and AA and EE pre-authentication software).
Given this known start state, the product (once installed and operational) ensures partitions of
logical blocks of user accessible data is protected.
OE.PASSWORD_STRENGTH
An authorized user will be responsible for ensuring that the password authorization factor conforms to guidance from the Enterprise using the TOE.
Rationale: Users are properly trained [A.TRAINED_USER] to create authorization factors that conform to administrative guidance.
OE.PHYSICAL
The Operational Environment will provide a secure physical computing space such that an adversary is not able to make modifications to the environment or to the TOE itself.
Rationale: As stated in section 1.6, the use case for this cPP is to protect data at rest on a device where the adversary receives it in a powered off state and has no prior access.
OE.PLATFORM_IA
The Operational Environment will provide individual user identification and authentication mechanisms that operate independently of the authorization factors used by the TOE.
Rationale: While the product may provide authorization factors to the Operating system's login interface, it must not change or degrade the functionality of the actual interface. [A.PLATFORM_IA] requires that the product not interfere or change the normal platform I&A functionality.
OE.PLATFORM_STATE
The platform in which the storage device resides (or an external
storage device is connected) is free of malware that could interfere with the correct operation
of the product.
Rationale: A platform free of malware [A.PLATFORM_STATE] prevents an attack vector that could potentially interfere with the correct operation of the product.
OE.POWER_DOWN
Volatile memory is erased after power-off so memory remnant attacks are infeasible.
Rationale: Users are properly trained [A.TRAINED_USER] to not leave the storage device unattended until powered down or placed in a managed power state such as “hibernation mode”. [A.POWER_DOWN] stipulates that such memory remnant attacks are infeasible given the device is in a powered-down or “hibernation mode” state.
OE.SINGLE_USE_ET
External tokens that contain authorization factors will be used for no
other purpose than to store the external token authorization factor.
Rationale: Users are properly trained [A.TRAINED_USER] to use external token authorization factors as intended and for no other purpose.
OE.STRONG_ENVIRONMENT_CRYPTO
The Operating Environment will provide a cryptographic function capability that is commensurate with the requirements and capabilities of the TOE and Appendix A.
Rationale: All cryptography implemented in the Operational Environment and used by
the product meets the requirements listed in this cPP [A.STRONG_CRYPTO].
OE.TRAINED_USERS
Authorized users will be properly trained and follow all guidance for securing the TOE and authorization factors.
Rationale: Users are properly trained [A.TRAINED_USER] to create authorization factors that conform to guidance, not store external token authorization factors with the device, and power down the TOE when required [OE.PLATFORM_STATE] The platform in which the storage device resides (or an external storage device is connected) is free of malware that could interfere with the correct operation of the product.
A platform free of malware [A.PLATFORM_STATE] prevents an attack vector that could potentially interfere with the correct operation of the product.
OE.TRUSTED_CHANNEL
Communication among and between product components (i.e., AA and EE) is sufficiently protected to prevent information disclosure.
Rationale: In situations where there is an opportunity for an adversary to interpose
themselves in the channel between the AA and the EE a trusted channel must be established to prevent exploitation. [A.TRUSTED_CHANNEL] assumes the existence of a trusted channel between the AA and EE, except for when the boundary is within and does not breach the TOE or is in such close proximity that a breach is not possible without detection.
4.2 Security Objectives Rationale
This section describes how the assumptions and organizational
security policies map to operational environment security objectives.
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 Security Functional Requirements
The individual security functional requirements are specified in the sections below.
The TSF shall accept authorization factors from the following methods: [selection:
a submask derived from a password conditioned as defined in FCS_PCC_EXT.1,
an external smart card that is protecting a submask that is
[selection: generated by the TOE (using the RBG as specified in FCS_RBG.1), generated by the Host Platform]
protected as defined in FCS_CKM.1/AKG with user presence proved by presentation of the smart card and
[selection: none, an OE defined PIN, a configurable PIN],
an external USB token that is at least the same security strength as the BEV, and is protecting a submask generated by the TOE, using the RBG as specified in FCS_RBG.1,
an external USB token that is at least the same security strength as the BEV, and is protecting a submask generated by the Host Platform
]
Application
Note:
The TOE may accept any number of authorization methods. The TOE may support any number of specific authorization factors for those methods and these are categorized as “submasks”. The ST author selects the authorization methods they support.
Use of multi-factor authorization is preferable; if more than one authorization factor is used, the submasks produced must be combined using FCS_SMC_EXT.1 specified in Appendix A.
FCS_AFA_EXT.2 Timing of Authorization Factor Acquisition
The TSF shall reacquire the authorization factors specified in FCS_AFA_EXT.1
upon transition from any compliant power saving state specified in FPT_PWR_EXT.1 prior to permitting access to plaintext data.
Application
Note:
This should be accomplished by erasing keys that are no longer needed so that keys must be derived or decrypted again.
FCS_CKM.6 Cryptographic Key and Key Material Destruction (Destruction Timing/Method)
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, and BEV. There may be instances where keys or key material that are
contained in persistent storage are no longer needed and require destruction. Based 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, the TSF should ensure that the PIN was properly destroyed.
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:
[assignment:
some 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 storage that consists of 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:
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 the application may have access to the file system details and may be able to logically address specific memory locations. In another implementation the application may simply have a handle to a resource and can only ask the platform to delete the resource. 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 an RBG meeting FCS_RBG.1 requirements, 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.
FCS_CKM.6/Power Cryptographic Key and Key Material Destruction (Power Management)
The TSF shall destroy [all key material, BEV, and authentication factors
stored in plaintext] when [transitioning to a compliant power saving
state as defined by FPT_PWR_EXT.1].
Application
Note:
The TOE may end up in a non-compliant power saving
state indistinguishable from a compliant power state (e.g. as result of sudden or
unexpected power loss). For those scenarios, the TOE or the operational
environment guidance documentation must provide procedures to support destruction of key material (e.g., automated reboot with memory erasure in early stages of the system’s power-on sequence).
The TSF shall destroy cryptographic keys and keying material specified by FCS_CKM.6.1/Power in
accordance with a specified cryptographic key destruction method [selection: instruct the operational environment to erase, erase] that meets the following: [a key
destruction method specified in FCS_CKM.6].
Application
Note:
In some cases, erasure of keys from volatile memory is
only supported by the operational environment, in which case the operational
environment must expose a well-documented mechanism or interface to invoke the memory erase operation.
The TSF shall perform [cryptographic hashing] in accordance with a specified
cryptographic algorithm
[selection: SHA-256, SHA-384, SHA-512, SHA3-384, SHA3-512] that meet the following:
[selection: ISO/IEC 10118-3:2018 [SHA, SHA3], FIPS PUB 180-4 [SHA], FIPS PUB 202 [SHA3]].
Application
Note:
In accordance with CNSA 1.0 and 2.0:
SHA3 hashes may be used only for internal hardware functionality such as
boot integrity checks, and
SHA-256 is permitted only for use as a PRF or MAC as part of a key derivation function,
or as part of LMS or XMSS.
The hash selection should be consistent with the overall strength of the
algorithm used for signature generation. For example, the TOE should choose SHA-384 for 3072-bit RSA,
4096-bit RSA, or ECC with P-384; and SHA-512 for ECC with P-521.
The TSF shall perform [cryptographic signature services (verification)]
in accordance with a specified cryptographic algorithm
[selection:
CNSA 2.0 Compliant Algorithms:
[selection:
Leighton-Micali Signature Algorithm for verification using cryptographic key sizes of
[selection: 192, 256] bits
eXtended Merkle Signature Scheme Algorithm for verification using cryptographic key sizes of
[selection: 192, 256] bits
Module-Lattice-Based Digital Signature Algorithm using the parameter
set ML-DSA-87
]
CNSA 1.0 Compliant Algorithms:
[selection:
RSA schemes using cryptographic key sizes of
[selection: 3072-bits, 4096-bits]
ECDSA schemes using [“NIST curves”
[selection: P-384, P-521]
]
]
]
that meet the following:
[selection: NIST SP 800-208 [LMS, XMSS], FIPS PUB 204 [ML-DSA], FIPS PUB 186-5 Section 5 [RSA], FIPS PUB 186-5 Section 6 [ECDSA]].
Application
Note:
The selection should be consistent with the overall strength of the algorithm used for FCS_COP.1/SigVer and quantum resistant recommendations. For example,
SHA-256 should be chosen for 2048-bit RSA or ECC with P-256, SHA-384 should be chosen for 3072-bit RSA, 4096-bit RSA, or ECC with P-384, and SHA-512 should
be chosen for ECC with P-521. The selection of the standard is made based on the algorithms selected.
This SFR is mandatory for its use in verification of digital signatures for TOE updates. As support is expanded for CNSA 2.0, CNSA 1.0 will be removed as an selection in a future update.
]
while maintaining an effective strength of [256 bits] for symmetric keys and an effective strength of
[selection: not applicable, 128 bits, 192 bits, 256 bits] for asymmetric keys.
The TSF shall provide at least a [256 bit] BEV to [assignment:
one or more external entities]
[selection:
after the TSF has successfully performed the validation process as specified in FCS_VAL_EXT.1.
without validation taking place.
]
Application
Note:
Key Chaining is the method of using multiple layers of encryption keys to ultimately secure the BEV. The number of intermediate keys will vary – from one
(e.g., taking the conditioned password authorization factor and directly using it as the BEV) to many. This applies to all keys that contribute to the
ultimate wrapping or derivation of the BEV; including those in areas of protected storage (e.g. TPM stored keys, comparison values).
Multiple key chains to the BEV are allowed, as long as all chains meet the key chain requirement.
The BEV is considered to be equivalent to keying material and therefore additional checksums or similar values are not the BEV, even if they are sent with
the BEV.
Once the ST author has selected a method to create the chain (either by deriving keys or unwrapping them or encrypting keys or using RSA Key Transport), they
pull the appropriate requirement out of Appendix B. It is allowable for an implementation to use any or all methods.
For FCS_KYC_EXT.1.2, the validation process is defined in FCS_VAL_EXT.1, Appendix B. If that selection is made by the ST author, then FCS_VAL_EXT.1 is included
in the body of the ST.
The method the TOE uses to chain keys and manage/protect them is described in the Key Management Description; see Appendix E for more information.
CCM: Nonce shall be non-repeating and unpredictable
XTS: No IV. Tweak values shall be non-negative integers, assigned consecutively, and starting at an arbitrary non-negative integer;
GCM: IV shall be non-repeating. The number of invocations of GCM shall not exceed 2^32 for a given secret key
]
].
Application
Note:
This requirement covers several important factors – the salt must be random, but the nonces only have to be unique. FCS_SNI_EXT.1.3 specifies how the IV should
be handled for each encryption mode. CBC, XTS, and GCM are allowed for AES encryption of the data. AES-CCM is an allowed mode for Key Wrapping.
If the TSF uses salts in support of cryptographic operations, and these salts are generated by the TSF, then FCS_RBG.1 must be claimed.
The TSF shall restrict the ability to [modify the behaviour of] the functions [use of compliant power saving state] to [authorized users].
Application
Note:
“Modify the behaviour of” refers to any change in how or when a compliant power state may occur. Only privileged users are allowed to enable or disable compliant power saving states via modification of “use of compliant power saving state” function.
[selection: no other functions, specify the power saving state properties, define the allowable power saving states, generate authorization factors using the TSFRBG, configure authorization method, configure cryptographic functionality, disable key recovery functionality, securely update the public key needed for trusted update, 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:
The intent of this requirement is to express the management capabilities that the TOE possesses. This means that the TOE must be able to perform the listed functions. “Configure cryptographic functionality” could include key management functions; for example, the BEV will be wrapped or encrypted, and the EE will need to unwrap or decrypt the BEV. In item e, if no other management functions are provided (or claimed), then “no other functions” should be selected
Changing the DEK would require the data to be re-encrypted with the new DEK, but allows the user the ability to generate new DEKs.
For the purposes of this document, key sanitization means to destroy the DEK, using one of the approved destruction methods. In some implementations, changing the DEK could be the same functionality as cryptographically erasing the DEK.
If multiple independent authorization methods are supported then configure authorization methods must be selected.
the non-volatile memory the key is stored on is located in an external storage device for use as an authorization factor
the plaintext key is only used to provide additional cryptographic protection to other keys, such that disclosure of the plaintext key would not compromise the security of the keys being protected
]
].
Application
Note:
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 BEV or the DEK are if it is a key split or providing additional layers
of wrapping or encryption on keys that have already been protected.
If the TSF implements key wrapping, key encryption, or key encapsulation to maintain protected cryptographic key storage, then FCS_COP.1/KeyWrap, FCS_COP.1/KeyEnc,
or FCS_COP.1/KeyEncap must be claimed. Additionally, if key wrapping or key encryption is used, then FCS_CKM.1/SKG, FCS_RBG.1, and FCS_COP.1/SKC must be claimed to
support generation, encryption, and decryption of symmetric keys used in support of these operations. If the TSF implements submask combining to maintain protected
cryptographic key storage, then FCS_SMC_EXT.1 must be claimed. These selection must align with FCS_KYC_EXT.1.
For each compliant power saving state defined in FPT_PWR_EXT.1.1, the TSF shall enter
the compliant power saving state when the following conditions occur: user-initiated request, [selection: shutdown, user inactivity, request initiated by remote management system, [assignment:
other conditions], no other conditions].
Application
Note:
If volatile memory is not erased as part of an unexpected power shutdown sequence then guidance documentation must define mitigation activities (e.g. how long users should wait after an unexpected power-down before volatile memory can be considered erased).
The TSF shall verify updates to the TOE software using a [digital signature as specified in FCS_COP.1/SigVer] by the manufacturer prior to installing those updates.
Application
Note:
While this component requires the TOE to implement the update functionality itself, it is acceptable to perform the cryptographic checks using functionality available in the Operational Environment.
5.1.4 TOE Security Functional Requirements Rationale
The following rationale provides justification for each SFR for the TOE,
showing that the SFRs are suitable to address the specified threats:
Mitigates this threat by requiring several options for enforcing validation, such as key sanitization of the DEK or when a configurable number of failed validation attempts is reached within a 24 hour period. This mitigates brute force attacks against authorization methods such as passwords and pins.
Mitigates this threat by ensuring the TSF provides the functions necessary to manage important aspects of the TOE including requests to change and erase the DEK.
Mitigates this threat by assigning users with the proper account permissions and privileges. This can be used with FMT_MOF.1 to restrict users to be able to modify certain power states covered in FMT_MOF.1.
Mitigates this threat by defining conditions in which the TOE will enter a compliant power state. These requirements ensure the device is secure if lost in a compliant power state.
Mitigates this threat by ensuring the TSF provides the functions necessary to manage important behavior of the TOE which includes the initiation of system firmware/software updates.
Mitigates this threat by providing authorized users the ability to query the current version of the TOE software/firmware, initiate updates, and verify updates prior to installation using a manufacturer digital signature.
5.2 Security Assurance Requirements
This cPP identifies the Security Assurance Requirements (SARs) to frame the extent to which
the evaluator assesses the documentation applicable for the evaluation and performs
independent testing. Individual evaluation activities to be performed are specified within
each SFR.
Note to ST authors: There is a selection in the ASE_TSS that must be completed. One cannot simply reference the SARs in this cPP.
The general model for evaluation of TOEs against STs written to conform to this cPP is as follows: after the ST has been approved for evaluation, the ITSEF will obtain the TOE, supporting environmental IT (if required), and the administrative/user guides for the TOE. The ITSEF is expected to perform actions mandated by the Common Evaluation Methodology (CEM) for the ASE and ALC SARs. The ITSEF also performs the Evaluation Activities contained within the SD, which are intended to be an interpretation of the other CEM assurance requirements as they apply to the specific technology instantiated in the TOE. The Evaluation Activities that are captured in the SD also provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the cPP.
The ST is evaluated as per ASE activities defined in the CEM. In addition, there may be Evaluation Activities specified within the SD that call for necessary descriptions to be included in the TSS that are specific to the TOE technology type.
The SFRs in this cPP allow for conformant implementations to incorporate a wide range of acceptable key management approaches as long as basic principles are satisfied. Given the criticality of the key management scheme, this cPP requires the developer to provide a detailed description of their key management implementation. This information can be submitted as an appendix to the ST and marked proprietary, as this level of detailed information is not expected to be made publicly available. See Appendix E for details on the expectation of the developer’s Key Management Description
In addition, if the TOE includes a random bit generator Appendix D provides a description of the information expected to be provided regarding the quality of the entropy.
ASE_TSS.1.1C The TOE summary specification shall describe how the TOE meets each SFR, including a Key Management Description (Appendix E), and [selection: Entropy Essay, list of all of 3rd party software libraries (including version numbers), 3rd party hardware components (including model/version numbers), no other cPP specified proprietary documentation].
5.2.2 ADV: Development
The design information about the TOE is contained in the guidance documentation available to the end user as well as the TSS portion of the ST, and any additional information required by this cPP that is not to be made public (e.g., Entropy Essay).
The functional specification describes the TOE Security Functions Interfaces (TSFIs). It is not necessary to have a formal or complete specification of these interfaces.
Additionally, because TOEs conforming to this cPP may have interfaces to the Operational Environment that are not directly invoked by TOE users, there is little point
specifying that such interfaces be described in and of themselves since only indirect testing of such interfaces may be possible. For this cPP, the evaluation activities
for this family focus on understanding the interfaces presented in the TSS in response to the functional requirements and the interfaces presented in the AGD documentation.
No additional “functional specification” documentation is necessary to satisfy the evaluation activities specified.
The evaluation activities are associated with the applicable SFRs. Since these are directly associated with the SFRs, the tracing in element ADV_FSP.1.2D is implicitly
already done and no additional documentation is necessary.
The developer shall provide a tracing from the functional specification to the
SFRs.
Application
Note:
As indicated in the introduction to this section, the
functional specification is comprised of the information contained in the AGD_OPE and
AGD_PRE documentation. The developer may reference a website accessible to application
developers and the evaluator. The evaluation activities in the functional requirements
point to evidence that should exist in the documentation and TSS
section; since these are directly associated with the SFRs, the tracing in element
ADV_FSP.1.2D is implicitly already done and no additional documentation is
necessary.
The evaluator shall determine that the functional specification is an accurate
and complete instantiation of the SFRs.
5.2.3 AGD: Guidance Documentation
The guidance documents will be provided with the ST. Guidance must include a description of how the IT personnel verifies that
the Operational Environment can fulfill its role for the security functionality. The documentation should be in an informal style
and readable by the IT personnel.
Guidance must be provided for every operational environment that the product supports as claimed in the ST. This guidance
includes:
Instructions to successfully install the TSF in that environment; and
Instructions to manage the security of the TSF as a product and as a component of the larger operational environment
Instructions to provide a protected administrative capability.
Guidance pertaining to particular security functionality must also be provided; requirements on such guidance are contained in
the evaluation activities
AGD_OPE.1 Operational User Guidance (AGD_OPE.1)
The operational user guidance does not have to be contained in a single document. Guidance to users, administrators, and
integrators can be spread among documents or web pages.
The developer should review the evaluation activities to ascertain the specifics of the guidance that the evaluator will be
checking for. This will provide the necessary information for the preparation of acceptable guidance.
The developer shall provide operational user guidance.
Application
Note:
The operational user guidance does not have to be contained in a
single document. Guidance to users, administrators and application developers can be
spread among documents or web pages. Where appropriate, the guidance documentation is
expressed in the eXtensible Configuration Checklist Description Format (XCCDF) to
support security automation. Rather than repeat information here, the developer should
review the evaluation activities for this component to ascertain the specifics of the
guidance that the evaluator will be checking for. This will provide the necessary
information for the preparation of acceptable guidance.
The operational user guidance shall describe, for each user role, the
user-accessible functions and privileges that should be controlled in a secure
processing environment, including appropriate warnings.
Application
Note:
User and administrator are to be considered in the definition
of user role.
The operational user guidance shall describe, for each user role, the available
functions and interfaces, in particular all security parameters under the control of
the user, indicating secure values as appropriate.
The operational user guidance shall, for each user role, clearly present each
type of security-relevant event relative to the user-accessible functions that need to
be performed, including changing the security characteristics of entities under the
control of the TSF.
The operational user guidance shall identify all possible modes of operation of
the TOE (including operation following failure or operational
error), their consequences, and implications for maintaining secure operation.
The operational user guidance shall, for each user role, describe the security
measures to be followed in order to fulfill the security objectives for the
operational environment as described in the ST.
The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.
AGD_PRE.1 Preparative Procedures (AGD_PRE.1)
As with the operational guidance, the developer should look to the Evaluation Activities to determine the required content with respect to preparative procedures.
The developer shall provide the TOE, including its preparative procedures.
Application
Note:
As with the operational guidance, the developer should look to
the evaluation activities to determine the required content with respect to preparative
procedures.
The preparative procedures shall describe all the steps necessary for secure
acceptance of the delivered TOE in accordance with the developer's
delivery procedures.
The preparative procedures shall describe all the steps necessary for secure
installation of the TOE and for the secure preparation of the
operational environment in accordance with the security objectives for the operational
environment as described in the ST.
The evaluator shall apply the preparative procedures to confirm that the TOE
can be prepared securely for operation.
5.2.4 Class ALC: Life-cycle Support
At the assurance level provided for TOEs conformant to this cPP, life-cycle support is limited to end-user-visible aspects of the life-cycle, rather than an examination of the TOE vendor’s development and configuration management process. This is not meant to diminish the critical role that a developer’s practices play in contributing to the overall trustworthiness of a product; rather, it is a reflection on the information to be made available for evaluation at this assurance level.
ALC_CMC.1 Labelling of the TOE (ALC_CMC.1)
This component is targeted at identifying the TOE such that it can be distinguished from other products or versions from the same vendor and can be easily specified when being procured by an end user. The evaluator performs the CEM work units associated with ALC_CMC.1.
The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.
5.2.5 Class ATE: Tests
Testing is specified for functional aspects of the system as well as aspects that take advantage of design or implementation weaknesses. The former is done through the ATE_IND family, while the latter is through the AVA_VAN family. For this cPP, testing is based on advertised functionality and interfaces with dependency on the availability of design information. One of the primary outputs of the evaluation process is the test report as specified in the following requirements.
Testing is performed to confirm the functionality described in the TSS as well as the operational guidance (includes “evaluated configuration” instructions). The focus of the testing is to confirm that the requirements specified in Section 5 are being met. The Evaluation Activities in the SD identify the specific testing activities necessary to verify compliance with the SFRs. The evaluator produces a test report documenting the plan for and results of testing, as well as coverage arguments focused on the platform/TOE combinations that are claiming conformance to this cPP.
Application
Note:
The developer must provide at least one product instance of the TOE for complete testing on at least one
platform regardless of equivalency. See the Equivalency Appendix for more details.
The evaluator shall test a subset of the TSF to confirm
that the TSF operates as specified.
Application
Note:
The evaluator should test the application on the most current
fully patched version of the platform.
5.2.6 Class AVA: Vulnerability Assessment
For the current generation of this cPP, the iTC is expected to survey open sources to discover what vulnerabilities have been
discovered in these types of products and provide that content into the AVA_VAN discussion. In most cases, these vulnerabilities
will require sophistication beyond that of a basic attacker. This information will be used in the development of future Protection
Profiles.
If the TOE is a Network Attached Storage (NAS) device, the evaluator shall verify as part of the vulnerability assessment that
remote management services are either not present or can be fully disabled.
AVA_VAN.1 Vulnerability Survey (AVA_VAN.1)
Vulnerability Analysis
Sources of Vulnerability Information
CEM Work Unit AVA_VAN.1-3 is supplemented here to provide a better-defined set of flaws to
investigate and procedures to follow based on this particular technology. Terminology used is based on the flaw hypothesis
methodology, where the evaluation team hypothesizes flaws and then either proves or disproves those flaws (a flaw is equivalent
to a “potential vulnerability” as used in the CEM). Flaws are categorized into four “types” depending on how they are
formulated:
A list of flaw hypotheses applicable to the technology described by the cPP derived from public sources as documented in
the Type 1 Hypotheses section—this fixed set has been agreed to by the iTC. Additionally, this will be supplemented with entries for a set
of public sources (as indicated below) that are directly applicable to the TOE or its identified components (as defined by
the process in the Type 1 Hypotheses section below); this is to ensure that the evaluators include in their assessment applicable entries
that have been discovered since the cPP was published;
A list of flaw hypotheses contained in this document that are derived from lessons learned specific to that technology and
other iTC input (that might be derived from other open sources and vulnerability databases, for example) as documented in
the Type 2 Hypotheses section;
A list of flaw hypotheses derived from information available to the evaluators; this includes the baseline evidence
provided by the vendor described in this document (documentation associated with EAs, documentation described in
the Vulnerability Survey section), as well as other information (public and/or based on evaluator experience) as documented in the Type 3 Hypotheses
section; and
A list of flaw hypotheses that are generated through the use of iTC-defined tools (e.g., nmap, protocol testers) and their
application is specified in the Type 4 Hypotheses section.
Type 1 Hypotheses-Public-Vulnerability-Based
The following list of public sources of vulnerability information was selected by the iTC:
Search Common Vulnerabilities and Exposures: http://cve.mitre.org/cve/
Search the National Vulnerability Database: https://nvd.nist.gov/
In order to successfully complete this activity, the evaluator will use the developer provided list of all of third party library
information that is used as part of their product, along with the version and any other identifying information (this is required
in the cPP as part of the ASE_TSS.1.1C requirement). This applies to hardware (including chipsets, etc.) that a vendor utilizes
as part of their TOE. This TOE-unique information will be used in the search terms the evaluator uses in addition to those listed
above.
The evaluator will also consider the requirements that are chosen and the appropriate guidance that is tied to each requirement.
In order to supplement this list, the evaluators shall also perform a search on the sources listed above to determine a list of
potential flaw hypotheses that are more recent that the publication date of the cPP, and those that are specific to the TOE and
its components as specified by the additional documentation mentioned above. Any duplicates – either in a specific entry, or in
the flaw hypothesis that is generated from an entry from the same or a different source – can be noted and removed from
consideration by the evaluation team.
As part of type 1 flaw hypothesis generation for the specific components of the TOE, the evaluator shall also search the
component manufacturer’s websites to determine if flaw hypotheses can be generated on this basis (for instance, if security
patches have been released for the version of the component being evaluated, the subject of those patches may form the basis
for a flaw hypothesis).
The iTC has leveraged the expertise of the developers and the evaluation labs to diligently develop the appropriate search
terms and vulnerability databases. They have also thoughtfully considered the iTC-sourced hypotheses the evaluators should
use based upon the applicable use case and the threats to be mitigated by the SFRs. Therefore, it is the intent of the iTC,
for the evaluation to focus all effort on the Type 1 and Type 2 Hypotheses and has decided that Type 3 Hypotheses are not
necessary.
However, if the evaluators discover a Type 3 potential flaw that they believe should be considered, they should work with
their Certification Body to determine the feasibility of pursuing the hypothesis. The Certification Body may determine
whether the potential flaw hypotheses is worth submitting to the iTC for consideration as Type 2 hypotheses in future drafts
of the cPP/SD.
Type 4 Hypotheses-Evaluation-Team-Generated
The iTC has called out several tools that should be used during the Type 2 hypotheses process. Therefore, the use of any tools
is covered within the Type 2 construct and the iTC does not see any additional tools that are necessary. The use case for
Version 2 of this cPP is rather straightforward – the device is found in a powered down state and has not been subjected to
revisit/evil maid attacks. Since that is the use case, the iTC has also assumed there is a trusted channel between the AA and
EE. Since the use case is so narrow, and is not a typical model for penetration or fuzzing testing, the normal types of
testing do not apply. Therefore, the relevant types of tools are referenced in Type 2.
Process for Evaluator Vulnerability Analysis
As flaw hypotheses are generated from the activities described above, the evaluation team will disposition them; that is,
attempt to prove, disprove, or determine the non-applicability of the hypotheses. This process is as follows.
The evaluator will refine each flaw hypothesis for the TOE and attempt to disprove it using the information provided by the
developer or through penetration testing. During this process, the evaluator is free to interact directly with the developer
to determine if the flaw exists, including requests to the developer for additional evidence (e.g., detailed design
information, consultation with engineering staff); however, the CB should be included in these discussions. Should the
developer object to the information being requested as being not compatible with the overall level of the evaluation
activity/cPP and cannot provide evidence otherwise that the flaw is disproved, the evaluator prepares an appropriate set of
materials as follows:
The source documents used in formulating the hypothesis, and why it represents a potential compromise against a
specific TOE function;
An argument why the flaw hypothesis could not be proven or disproved by the evidence provided so far; and
The type of information required to investigate the flaw hypothesis further.
The Certification Body (CB) will then either approve or disapprove the request for additional information. If approved, the
developer provides the requested evidence to disprove the flaw hypothesis (or, of course, acknowledge the flaw).
For each hypothesis, the evaluator will note whether the flaw hypothesis has been successfully disproved, successfully proven
to have identified a flaw, or requires further investigation. It is important to have the results documented as outlined in
the Reporting section below.
If the evaluator finds a flaw, the evaluator must report these flaws to the developer. All reported flaws must be addressed
as follows:
If the developer confirms that the flaw exists and that it is exploitable at Basic Attack Potential, then a change is made by
the developer, and the resulting resolution is agreed by the evaluator and noted as part of the evaluation report.
If the developer, the evaluator, and the CB agree that the flaw is exploitable only above Basic Attack Potential and does not
require resolution for any other reason, then no change is made and the flaw is noted as a residual vulnerability in the
CB-internal report (ETR).
If the developer and evaluator agree that the flaw is exploitable only above Basic Attack Potential, but it is deemed critical
to fix because of technology-specific or cPP-specific aspects such as typical use cases or operational environments, then a
change is made by the developer, and the resulting resolution is agreed by the evaluator and noted as part of the evaluation
report.
Disagreements between evaluator and vendor regarding questions of the existence of a flaw, its attack potential, or whether
it should be deemed critical to fix are resolved by the CB.
Any testing performed by the evaluator shall be documented in the test report as outlined
in the Reporting section below.
As indicated in the Reporting section, the public statement with respect to vulnerability analysis that is performed on TOEs
conformant to the cPP is constrained to coverage of flaws associated with Types 1 and 2 (defined in the Sources of
Vulnerability Information section) flaw hypotheses only. The fact that the iTC generates these candidate hypotheses indicates
these must be addressed.
Reporting
The evaluators shall produce two reports on the testing effort; one that is public-facing (that is, included in the
non-proprietary evaluation report, which is a subset of the Evaluation Technical Report (ETR)), and the complete ETR that is
delivered to the overseeing CB.
The public-facing report contains:
The flaw identifiers returned when the procedures for searching public sources were followed according to instructions in
the Type 1 Hypotheses section;
A statement that the evaluators have examined the Type 1 flaw hypotheses specified
in this document in the
Type 1 Hypotheses section (i.e. the flaws listed in the previous bullet) and the Type 2 flaw hypotheses specified in the
the Type 2 Hypotheses section
No other information is provided in the public-facing report.
The internal CB report contains, in addition to the information in the public-facing report:
a list of all of the flaw hypotheses generated (cf. AVA_VAN.1-4);
the evaluator penetration testing effort, outlining the testing approach, configuration, depth and results (cf.
AVA_VAN.1-9);
all documentation used to generate the flaw hypotheses (in identifying the documentation used in coming up with the
flaw hypotheses, the evaluation team must characterize the documentation so that a reader can determine whether it is
strictly required in this document, and the nature of the documentation (design information, developer
engineering notebooks, etc.));
the evaluator shall report all exploitable vulnerabilities and residual vulnerabilities, detailing for each:
its source (e.g. CEM activity being undertaken when it was conceived, known to the evaluator, read in a publication)
whether it is exploitable in its operational environment or not (i.e. exploitable or residual).
the amount of time, level of expertise, level of knowledge of the TOE, level of opportunity and the equipment
required to perform the identified vulnerabilities (cf. AVA_VAN.1-11);
how each flaw hypothesis was resolved (this includes whether the original flaw hypothesis was confirmed or
disproved, and any analysis relating to whether a residual vulnerability is exploitable by an attacker with Basic
Attack Potential) (cf. AVA_VAN1-10); and
in the case that actual testing was performed in the investigation (either as part of flaw hypothesis generation
using tools specified by the iTC in the Type 4 Hypotheses section, or in proving or disproving a particular flaw) the steps followed in
setting up the TOE (and any required test equipment); executing the test; post-test procedures; and the actual results
(to a level of detail that allow repetition of the test, including the following:
identification of the potential vulnerability the TOE is being tested for;
instructions to connect and setup all required test equipment as required to conduct the penetration test;
instructions to establish all penetration test prerequisite initial conditions;
Application
Note:
Suitability for testing means not being obfuscated or
packaged in such a way as to disrupt either static or dynamic analysis by the
evaluator.
The evaluator shall perform a search of public domain sources to identify
potential vulnerabilities in the TOE.
Application
Note:
Public domain sources include the Common Vulnerabilities
and Exposures (CVE) dictionary for publicly known vulnerabilities. Public domain
sources also include sites which provide free checking of files for viruses.
The evaluator shall conduct penetration testing, based on the identified
potential vulnerabilities, to determine that the TOE is resistant to
attacks performed by an attacker possessing Basic attack potential.
Appendix A - Optional Requirements
As indicated in the introduction to this PP, the baseline requirements (those that must be
performed by the TOE) are contained in the body of this PP.
This appendix contains three other types of optional requirements:
The first type, defined in Appendix A.1 Strictly Optional Requirements, are strictly optional requirements.
If the TOE meets any of these requirements the vendor is encouraged to claim the associated SFRs
in the ST, but doing so is not required in order to conform to this PP.
The second type, defined in Appendix A.2 Objective Requirements, are objective requirements. These describe security functionality that is not yet
widely available in commercial technology.
Objective requirements are not currently mandated by this PP, but will be mandated in
the future. Adoption by vendors is encouraged, but claiming these SFRs is not required in order to conform to this
PP.
The third type, defined in Appendix A.3 Implementation-dependent Requirements, are Implementation-dependent requirements.
If the TOE implements the product features associated with the listed SFRs, either the SFRs must be claimed
or the product features must be disabled in the evaluated configuration.
A.1 Strictly Optional Requirements
A.1.1 Class ALC: Life-cycle Support
ALC_FLR.1 Basic Flaw Remediation (ALC_FLR.1)
This SAR is optional and may be claimed at the ST-Author's discretion.
The flaw remediation procedures shall require that a description of the nature and effect
of each security flaw be provided, as well as the status of finding a correction to that flaw.
The flaw remediation procedures documentation shall describe the methods used to
provide flaw information, corrections and guidance on corrective actions to TOE users.
The flaw remediation procedures shall require that a description of the nature and effect of each
security flaw be provided, as well as the status of finding a correction to that flaw.
The flaw remediation procedures documentation shall describe the methods used to provide flaw
information, corrections and guidance on corrective actions to TOE users.
The flaw remediation procedures shall describe a means by which the developer receives
from TOE users reports and enquiries of suspected security flaws in the TOE.
The procedures for processing reported security flaws shall ensure that any reported
flaws are remediated and the remediation procedures issued to TOE users.
The procedures for processing reported security flaws shall provide safeguards that any
corrections to these security flaws do not introduce any new flaws.
The flaw remediation procedures shall require that a description of the nature and effect of each
security flaw be provided, as well as the status of finding a correction to that flaw.
The flaw remediation procedures documentation shall describe the methods used to provide flaw
information, corrections and guidance on corrective actions to TOE users.
The flaw remediation procedures shall describe a means by which the developer receives from
TOE users reports and enquiries of suspected security flaws in the TOE.
The flaw remediation procedures shall include a procedure requiring timely response and
the automatic distribution of security flaw reports and the associated corrections to
registered users who might be affected by the security flaw.
The procedures for processing reported security flaws shall ensure that any reported flaws are
remediated and the remediation procedures issued to TOE users.
The procedures for processing reported security flaws shall provide safeguards that any
corrections to these security flaws do not introduce any new flaws.
The flaw remediation guidance shall describe a means by which TOE users may register
with the developer, to be eligible to receive security flaw reports and corrections.
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
A.2 Objective Requirements
This PP does not define any
Objective requirements.
A.3 Implementation-dependent Requirements
This PP does not define any
Implementation-dependent requirements.
Appendix B - Selection-based Requirements
As indicated in the introduction to this PP,
the baseline requirements
(those that must be performed by the TOE or its underlying platform)
are contained in the body of this PP.
There are additional requirements based on selections in the body of
the PP:
if certain selections are made, then additional requirements below must be included.
Module-Lattice-Based Key-Encapsulation Mechanism using the parameter set ML-KEM-1024
Module-Lattice-Based Digital Signature Algorithm using the parameter set ML-DSA-87
]
CNSA 1.0 Compliant Algorithms:
[selection:
[RSA schemes] using cryptographic key sizes of [selection: 3072, 4096]
[ECC schemes] using [“NIST curves” P-384 and [selection: P-521, no other curves] ]
]
]
that meet the following:
[selection: NIST SP 800-208 [LMS, XMSS], FIPS PUB 203 [ML-KEM], FIPS PUB 204 [ML-DSA], FIPS PUB 186-5 Appendix A.1 [RSA], FIPS PUB 186-5 Appendix A.2 [ECC]].
Application
Note:
Asymmetric keys may be used to “wrap” a key or submask. This SFR should be included by the ST author when making the appropriate selection in FCS_KYC_EXT.1 or FCS_AFA_EXT.1.
As support is expanded for CNSA 2.0, CNSA 1.0 will be removed as an selection in a future update.
The TSF shall generate symmetric cryptographic keys using a Random Bit Generator as specified in FCS_RBG.1 and specified cryptographic key
sizes 256 bit that meet the following: [no standard].
Application
Note:
Symmetric keys may be used to generate keys along the key chain. This applies to any instance in where the TSFDRBG is referenced for key generation where the TSF generates or re-generates key encryption or key wrapping keys as part of deriving a key (as in FCS_KYC_EXT.1)
FCS_COP.1/CMAC Cryptographic Operation - CMAC
The inclusion of this selection-based component depends upon selection in
FCS_CKM.5.1.
The TSF shall perform [CMAC] in accordance with a specified cryptographic algorithm
[selection:
Cryptographic algorithm]
and cryptographic key sizes
[selection:
Cryptographic key sizes]
that meet the following:
[selection:
List of standards]
The following table provides the allowed choices for
completion of the selection operations of FCS_COP.1/CMAC.
The TSF shall perform [keyed hash message authentication] in accordance
with a specified cryptographic algorithm
[selection:
Keyed Hash Algorithm]
and cryptographic key sizes
[selection:
Cryptographic key sizes]
that meet the following:
[selection:
List of standards]
The following table provides the allowed choices for
completion of the selection operations of FCS_COP.1/KeyedHash.
Application
Note:
The HMAC minimum key sizes in the table are specified in ISO/IEC 9797-2:2021, which requires that the
minimum key size be equal to the digest size. The FIPS standard specifies no minimum or maximum
key sizes, so if FIPS PUB 198-1 is selected, larger or smaller key sizes may be used. This is
indicated by the parenthesized annotations in the Cryptographic Key Sizes column.
In accordance with CNSA 1.0 and 2.0, HMAC-SHA-256 may be used only as a PRF or MAC step in a
key derivation function.
The TSF shall perform [symmetric-key encryption/decryption] in accordance with a
specified cryptographic algorithm
[selection:
Cryptographic algorithm]
and cryptographic key sizes
[selection:
Cryptographic key sizes]
that meet the following:
[selection:
List of standards]
The following table provides the allowed choices for
completion of the selection operations of FCS_COP.1/SKC.
AES in GCM mode with non-repeating IVs using [selection: deterministic, RBG-based],
IV construction; the tag must be of length
[selection: 96, 104, 112, 120, 128] bits.
Application
Note:
This SFR is required when the TSF performs key encryption as part of maintaining and deriving a key chain (FCS_KYC_EXT.1) or when the TSF
uses key encryption as part of password conditioning (FCS_PCC_EXT.1).
The TSF shall perform [key encapsulation] in accordance with a specified cryptographic algorithm
[selection:
Cryptographic algorithm]
and cryptographic key sizes
[selection:
Cryptographic key sizes]
that meet the following:
[selection:
List of standards]
The following table provides the allowed choices for
completion of the selection operations of FCS_COP.1/KeyEncap.
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.
NIST SP 800-57 Part 1 Revision 5 Section 5.6.2 specifies that the size of key used to protect the
key being transported should be at least the security strength of the key it is protecting.
If this SFR is claimed, then FCS_CKM.1/AKG must also be claimed.
KAS1 and KTS-OAEP with the selectable parameters are CNSA 1.0 compliant. ML-KEM-1024 is CNSA 2.0 compliant.
The TSF shall perform [key wrapping] in accordance with a specified cryptographic algorithm
[selection:
Cryptographic algorithm]
and cryptographic key sizes
[selection:
Cryptographic key sizes]
that meet the following:
[selection:
List of standards]
The following table provides the allowed choices for
completion of the selection operations of FCS_COP.1/KeyWrap.
AES in GCM mode with non-repeating IVs using [selection: deterministic, RBG-based],
IV construction; the tag must be of length
[selection: 96, 104, 112, 120, 128] bits.
Application
Note:
This SFR is required when the TSF performs key wrapping as part of maintaining and deriving a key chain (FCS_KYC_EXT.1) or
when the TSF performs validation of a submask, intermediate key, or BEV using a key wrap operation (FCS_VAL_EXT.1).
NIST 800-57p1rev5 sec. 5.6.2 specifies that the size of key used to protect the key being
transported should be at least the security strength of the key it is protecting.
The TSF shall perform [symmetric-key encryption/decryption] in accordance with a
specified cryptographic algorithm
[selection:
Cryptographic algorithm]
and cryptographic key sizes
[selection:
Cryptographic key sizes]
that meet the following:
[selection:
List of standards]
The following table provides the allowed choices for
completion of the selection operations of FCS_COP.1/SKC.
AES in GCM mode with non-repeating IVs using [selection: deterministic, RBG-based],
IV construction; the tag must be of length
[selection: 96, 104, 112, 120, 128] bits.
Application
Note:
The intent of this requirement in the context of this cPP is to provide an SFR that expresses the appropriate symmetric encryption/decryption algorithms
suitable for use in the TOE. If the ST author incorporates the validation requirement (FCS_VAL_EXT.1) and chooses to select the option to decrypt a known
value and perform a comparison, this is the requirement used to specify the algorithm, modes, and key sizes the ST author can choose from.
When the XTS mode is selected, a cryptographic key of 512-bit is allowed as specified in IEEE 1619. XTS-AES key is divided into two AES keys
of equal size - AES-256 is used when a 512-bit key and XTS mode are selected.
This SFR is required when the TSF performs any key wrapping, key encryption, or key derivation operation as part of maintaining a key chain
(FCS_KYC_EXT.1), or when the TSF performs validation of a submask, intermediate key, or BEV using a symmetric encryption operation
(FCS_VAL_EXT.1).
FCS_CKM.5 Cryptographic Key Derivation
The inclusion of this selection-based component depends upon selection in
FCS_KYC_EXT.1.1.
The TSF shall derive cryptographic keys
[selection:
Key type]
from
[selection:
Input parameters]
in accordance with a specified key derivation algorithm
[selection:
Key derivation algorithm]
and specified cryptographic key sizes
[selection:
Key sizes]
that meet the following:
[selection:
List of standards]
The following table provides the allowed choices for
completion of the selection operations of FCS_CKM.5.
Application
Note:
If KDF-CTR, KDF-FB, or KDF-DPI is claimed, then either FCS_COP.1/CMAC or FCS_COP.1/KeyedHash
must also be claimed, depending on the selection made for PRF.
If KDF-Hash is claimed, then FCS_COP.1/Hash must also be claimed.
If KDF-MAC-1S is claimed, then FCS_COP.1/KeyedHash must also be claimed.
If KDF-MAC-2S is claimed, then both FCS_COP.1/KeyedHash and FCS_COP.1/CMAC must also be claimed.
In KDF-MAC-2S, CMAC has been removed as a selection for the MAC step because it requires
selection of 128 bits for the output key size, which is not supported in CNSA 1.0. If HMAC is
selected in the MAC step, then the same HMAC is used as the KDF.
The security strengths of the Pseudo-Random functions for the key derivation methods must be
sufficient for the security strength of the keys derived through those methods. Since CNSA 1.0
permits keys no smaller than 256 bits, no 128- or 192-bit PRFs are permitted.
FCS_PCC_EXT.1 Cryptographic Password Construction and Conditioning
The inclusion of this selection-based component depends upon selection in
FCS_AFA_EXT.1.1.
The TSF shall be capable of accepting a password of at least
[assignment:
64 or more] characters in the set of {upper case characters, lower case characters, numbers, and [assignment:
other supported special characters]} and shall perform Password-based Key Derivation Functions in accordance with a specified cryptographic algorithm HMAC-[selection: SHA-256, SHA-384, SHA-512], with
[selection: [assignment:
10000 or more] iterations, [assignment:
1 or more] iterations and
[assignment:
10000 or more] subsequent rounds
of AES operations with a device key and PBKDF2 output per FCS_COP.1/KeyEnc] and output cryptographic key sizes
[selection: 128 bits, 256 bits] that meet the following: [NIST SP 800-132].
Application
Note:
The password 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 forms the submask to be used as input into
the key chain. Conditioning can be performed using one of the identified hash functions or the process described in
NIST SP 800-132; the method used is selected by the ST author. If 800-132 conditioning is specified, then the ST
author fills in the number of iterations that are performed. 800-132 also requires the use of a pseudo-random
function (PRF) consisting of HMAC with an approved hash function. The ST author selects the hash function used which
also includes the appropriate requirements for HMAC.
This SFR is claimed when password conditioning is used to derive a submask from a password authentication factor,
as defined in FCS_AFA_EXT.1.1.
FCS_RBG.1 Cryptographic Operation (Random Bit Generation)
The TSF shall perform deterministic random bit generation services using
[selection: Hash_DRBG (SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512), HMAC_DRBG (SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512), CTR_DRBG (AES-128, AES-192, AES-256)] in accordance with [selection: ISO/IEC 18031:2011, NIST SP 800-90A] after initialization with a seed.
Application
Note:
For Hash_DRBG and HMAC_DRBG, all allowed choices support a 256-bit security strength. For CTR_DRBG, the supported security strength is equal to the AES size. The TOE is expected to use a DRBG function that can support the security strength of the keys and random values to be generated. For example, an AES-192 CTR_DRBG can be used to generate 128-bit and 192-bit symmetric keys, but can not be used to generate 256-bit symmetric keys. More information is provided in Section 8.4 of NIST SP 800-90A.
The TSF shall use a [selection: TSF noise source [assignment:
name of noise source], multiple TSF noise sources [assignment:
names of noise sources], TSF interface for seeding]
for initialized seeding.
Application
Note:
For the
selection in this requirement, the ST author selects "TSF noise source" if
a single noise source is used as input to the DRBG. The ST author selects "multiple TSF noise sources" if a seed is formed from a combination of two or more noise sources within the TOE boundary. If the TSF implements two or more separate DRBGs that are seeded in separate manners, this SFR should be iterated for each DRBG. It multiple distinct noise sources exist such that each DRBG only uses one of them, then each iteration would select "TSF noise source"; "multiple TSF noise sources" is only selected if a single DRBG uses multiple noise sources for its seed. The ST author selects "TSF interface for seeding" if noise source data is generated outside the TOE boundary.
If "TSF noise source" is selected, FCS_RBG.3 must be claimed.
If "multiple TSF noise sources" is selected, FCS_RBG.4 and FCS_RBG.5 must be claimed.
If "TSF interface for seeding" is selected, FCS_RBG.2 must be claimed.
The TSF shall update the RBG state by [selection: reseeding, uninstantiating and reinstantiating] using a [selection: TSF noise source [assignment:
name of noise source], TSF interface for seeding]
in the following situations: [selection:
never
on demand
on the condition: [assignment:
condition]
after [assignment:
time]
]
in accordance with [assignment:
list of standards].
Application
Note:
This SFR is claimed when the TSF requires the use of random bit generation for submask generation (FCS_AFA_EXT.1,
FCS_CKM.5.1) or salt generation (FCS_SNI_EXT.1).
FCS_RBG.2 Random Bit Generation (External Seeding)
The inclusion of this selection-based component depends upon selection in
FCS_RBG.1.2.
The TSF shall be able to accept a minimum input of [assignment:
minimum input length greater than zero] from a TSF interface for the purpose of seeding.
Application
Note:
This requirement is claimed when a DRBG is seeded with entropy from one or more noise source that is outside the TOE
boundary. Typically the entropy produced by an environmental noise source is conditioned such that the input length has
full entropy and is therefore usable as the seed. However, if this is not the case, it should be noted what the minimum
entropy rate of the noise source is so that the TSF can collect a sufficiently large sample of noise data to be
conditioned into a seed value.
FCS_RBG.3 Random Bit Generation (Internal Seeding - Single Source)
The inclusion of this selection-based component depends upon selection in
FCS_RBG.1.2.
The TSF shall be able to seed the RBG using a [selection, choose one of: TSF software-based noise source, TSF hardware-based noise source] [assignment:
name of noise source] with a minimum of [assignment:
number of bits] bits of min-entropy.
Application
Note:
This requirement is claimed when a DRBG is seeded with entropy from a single noise source that is within the TOE boundary. Min-entropy should be expressed as a ratio of entropy bits to sampled bits so that the total amount of data needed to ensure full entropy is known, as well as the conditioning function by which that data is reduced in size to the seed.
FCS_RBG.4 Random Bit Generation (Internal Seeding - Multiple Sources)
The inclusion of this selection-based component depends upon selection in
FCS_RBG.1.2.
The TSF shall be able to seed the RBG using [selection: [assignment:
number] TSF software-based noise sources, [assignment:
number] TSF hardware-based noise sources].
Application
Note:
This requirement is claimed when a DRBG is seeded with entropy from multiple noise sources that are within the TOE boundary.
FCS_RBG.5 defines the mechanism by which these sources are combined to ensure sufficient minimum entropy.
FCS_RBG.5 Random Bit Generation (Combining Noise Sources)
The inclusion of this selection-based component depends upon selection in
FCS_RBG.1.2.
The TSF shall [assignment:
combining operation] [selection: output from TSF noise sources, input from TSF interfaces for seeding)] to create the entropy input into the derivation function as defined in [assignment:
list of standards], resulting in a minimum of [assignment:
number of bits] bits of min-entropy.
Application
Note:
Examples of typical combining operations include, but are not limited to, XORing or hashing.
FCS_SMC_EXT.1 Submask Combining
The inclusion of this selection-based component depends upon selection in
FCS_KYC_EXT.1.1.
The TSF shall combine submasks using the following method [selection: exclusive OR (XOR), SHA-256, SHA-384, SHA-512] to generate an [intermediary key or BEV].
Application
Note:
This requirement specifies the way that a product may combine the various submasks by using either an XOR or an
approved SHA-hash. The approved hash functions are captured in
FCS_COP.1/Hash.
This SFR is claimed when the TSF requires the use of submask combining as part of maintaining or deriving a key chain.
FCS_VAL_EXT.1 Validation
The inclusion of this selection-based component depends upon selection in
FCS_KYC_EXT.1.2.
hash the [selection: submask, intermediate key, BEV]
as specified in [selection: FCS_COP.1/Hash, FCS_COP.1/KeyedHash] and compare it to a stored hashed [selection: submask, intermediate key, BEV];
decrypt a known value using the [selection: submask, intermediate key, BEV] specified in FCS_COP.1/SKC and compare it against a stored known value
The TSF shall require validation of the [BEV] prior to [forwarding the BEV to the EE].
Application
Note:
This SFR is claimed when the TSF validates an authentication factor as a prerequisite to unlocking the key chain as
defined in FCS_KYC_EXT.1.
perform a key sanitization of the DEK upon a
[selection: configurable number, [assignment:
ST author specified number]]
of consecutive failed validation attempts
institute a delay such that only [assignment:
ST author specified number of attempts] can be made within a 24 hour period
block validation after [assignment:
ST author specified number of attempts] of consecutive failed validation attempts
require power cycle or reset the TOE after [assignment:
ST author specified number of attempts] of consecutive failed validation attempts
].
Application
Note:
The purpose of performing secure validation is to not expose any material that might compromise the submasks. For the selections in FCS_VAL_EXT.1.1, the ST author must clarify in the KMD which specific entities are referred to in this SFR if multiple entities of a type exist.
The TOE validates the submasks (e.g., authorization factors) prior to presenting the BEV to the EE. When a password is used as an authorization factor, it is conditioned before any attempts to validate. In cases where validation of the authorization factors fails, the product will not forward a BEV to EE.
When the key wrap in FCS_COP.1/KeyWrap is used, the validation is performed inherently.
The delay must be enforced by the TOE, but this requirement is not intended to address attacks that bypass the product (e.g. attacker obtains hash value or “known” crypto value and mounts attacks outside of the TOE, such as a third party password crackers). The cryptographic functions (i.e., hash, decryption) performed are those specified in FCS_COP.1/Hash, FCS_COP.1/KeyedHash, and FCS_COP.1/SKC.
The ST author may need to iterate this requirement if multiple authentication factors are used, and either different methods are used to validate, or in some cases one or more authentication factors may be validated, and one or more are not validated.
B.2 Protection of the TSF (FPT)
FPT_FLS.1 Failure with Preservation of Secure State
The inclusion of this selection-based component depends upon selection in
FCS_RBG.1.2.
The TSF shall preserve a secure state when the following types of failures occur: [DRBG self-test failure].
Application
Note:
The intent of this requirement is to ensure that cryptographic services requiring random bit generation cannot be performed if a failure of a self-test defined in FPT_TST.1 occurs.
The TSF shall run a suite of the following self-tests [selection: during initial start-up, at the conditions [before the function is first invoked]]
to demonstrate the correct operation of [selection: [assignment:
parts of TSF], TSF data].
The TSF shall provide authorized users with the capability to verify the integrity of [selection: [assignment:
parts of TSF], TSF].
Application
Note:
This SFR is a required dependency of FCS_RBG.1 and the cryptographic requirements that are selectable in FCS_KYC_EXT.1. It is intended to require that any DRBG implemented by the TOE undergo health testing to ensure that the random bit generation functionality has not been degraded. If the TSF supports multiple DRBGs, this SFR should be iterated to describe the self-test behavior for each.
The tests regarding cryptographic functions implemented in the TOE can be deferred, as long as the tests are performed before the function is invoked.
If any FCS_COP functions are implemented by the TOE, the TSS should describe the known answer self-tests for those functions.
Appendix C - Extended Component Definitions
This appendix contains the definitions for all extended requirements specified in the PP.
C.1 Extended Components Table
All extended components specified in the PP are listed in this table:
Table 12: Extended Component Definitions
Functional Class
Functional Components
Cryptographic Support (FCS)
FCS_AFA_EXT Authorization Factor Acquisition FCS_KYC_EXT Key Chaining FCS_PCC_EXT Cryptographic Password Construction and Conditioning FCS_SMC_EXT Submask Combining FCS_SNI_EXT Cryptographic Operation (Salt, Nonce, and Initialization Vector Generation) FCS_VAL_EXT Validation of Cryptographic Elements
Components in this family address the ability for the TOE to accept a variety of authorization factors.
Component Leveling
FCS_AFA_EXT.1,
Authorization Factor Acquisition,
requires authorization factors to be accepted by the TOE.
FCS_AFA_EXT.2,
Timing of Authorization Factor Acquisition,
defines situations in which the TOE is to accept authorization factors.
Management: FCS_AFA_EXT.1
The following actions could be considered for the management functions in FMT:
Change the authorization factors and methods to be used.
Generate external authorization factors using the TSFDRBG.
Audit: FCS_AFA_EXT.1
There are no audit events foreseen.
FCS_AFA_EXT.1 Authorization Factor Acquisition
Hierarchical to:
No other components.
Dependencies to:
No dependencies.
FCS_AFA_EXT.1.1
The TSF shall accept authorization factors from the following methods: [selection:
a submask derived from a password conditioned as defined in FCS_PCC_EXT.1,
an external smart card that is protecting a submask that is
[selection: generated by the TOE (using the RBG as specified in FCS_RBG.1), generated by the Host Platform]
protected as defined in FCS_CKM.1/AKG with user presence proved by presentation of the smart card and
[selection: none, an OE defined PIN, a configurable PIN],
an external USB token that is at least the same security strength as the BEV, and is protecting a submask generated by the TOE, using the RBG as specified in FCS_RBG.1,
an external USB token that is at least the same security strength as the BEV, and is protecting a submask generated by the Host Platform
]
Management: FCS_AFA_EXT.2
There are no management functions foreseen.
Audit: FCS_AFA_EXT.2
There are no audit events foreseen.
FCS_AFA_EXT.2 Timing of Authorization Factor Acquisition
The TSF shall reacquire the authorization factors specified in FCS_AFA_EXT.1
upon transition from any compliant power saving state specified in FPT_PWR_EXT.1 prior to permitting access to plaintext data.
C.2.1.2 FCS_KYC_EXT Key Chaining
Family Behavior
This family provides the specification to be used for using multiple layers of encryption keys to ultimately secure the protected data encrypted on the drive.
Component Leveling
FCS_KYC_EXT.1,
Key Chaining (Initiator),
requires the TSF to maintain a key chain for a BEV that is provided to a component external to the TOE.
FCS_KYC_EXT.2,
Key Chaining (Recipient) ,
requires the TSF to be able to accept a BEV that is then chained to a DEK used
by the TSF through some method.
Note that this cPP does not include FCS_KYC_EXT.2; it is only included here to provide a complete definition of the FCS_KYC_EXT family.
Management: FCS_KYC_EXT.1
There are no management functions foreseen.
Audit: FCS_KYC_EXT.1
There are no audit events foreseen.
FCS_KYC_EXT.1 Key Chaining (Initiator)
Hierarchical to:
No other components.
Dependencies to:
FCS_CKM.1 Cryptographic Key Generation
FCS_KYC_EXT.1.1
The TSF shall maintain a key chain of:
[selection:
]
while maintaining an effective strength of [256 bits] for symmetric keys and an effective strength of
[selection: not applicable, 128 bits, 192 bits, 256 bits] for asymmetric keys.
FCS_KYC_EXT.1.2
The TSF shall provide at least a [256 bit] BEV to [assignment:
one or more external entities]
[selection:
after the TSF has successfully performed the validation process as specified in FCS_VAL_EXT.1.
] while maintaining an effective strength of [selection: 128 bits, 256 bits]
while maintaining an effective strength of [256 bits] for symmetric keys and an effective strength of [selection: not applicable, 128 bits, 192 bits, 256 bits] for asymmetric keys.
C.2.1.3 FCS_PCC_EXT Cryptographic Password Construction and Conditioning
Family Behavior
This family ensures that passwords used to produce the BEV are robust (in terms of their composition) and are conditioned to provide an appropriate-length bit string.
Component Leveling
FCS_PCC_EXT.1,
Cryptographic Password Construction and Conditioning,
requires the TSF to accept passwords of a certain composition and condition them appropriately.
Management: FCS_PCC_EXT.1
There are no management functions foreseen.
Audit: FCS_PCC_EXT.1
There are no audit events foreseen.
FCS_PCC_EXT.1 Cryptographic Password Construction and Conditioning
Hierarchical to:
No other components.
Dependencies to:
FCS_COP.1 Cryptographic Operation
FCS_PCC_EXT.1.1
The TSF shall be capable of accepting a password of at least [assignment:
64 or more] characters in the set of {upper case characters, lower case characters, numbers, and [assignment:
other supported special characters]} and shall perform Password-based Key Derivation Functions in accordance with a specified cryptographic algorithm HMAC-[selection: SHA-256, SHA-384, SHA-512], with
[selection: [assignment:
10000 or more] iterations, [assignment:
1 or more] iterations and [assignment:
10000 or more] subsequent rounds of AES operations with a device key and PBKDF2 output per FCS_COP.1] and output cryptographic key sizes
[selection: 128 bits, 256 bits] that meet the following: [assignment:
PBKDF recommendation or
specification].
C.2.1.4 FCS_SMC_EXT Submask Combining
Family Behavior
This family specifies the means by which submasks are combined, if the TOE supports more than one submask being used to derive or protect the BEV.
Component Leveling
FCS_SMC_EXT.1,
Submask Combining ,
requires the TSF to combine the submasks in a predictable fashion.
Management: FCS_SMC_EXT.1
There are no management functions foreseen.
Audit: FCS_SMC_EXT.1
There are no audit 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 [selection: exclusive OR (XOR), SHA-256, SHA-384, SHA-512] to generate an [assignment:
types of keys].
C.2.1.5 FCS_SNI_EXT Cryptographic Operation (Salt, Nonce, and Initialization Vector Generation)
Family Behavior
This family ensures that salts, nonces, and IVs are well formed.
Component Leveling
FCS_SNI_EXT.1,
Cryptographic Operation (Salt, Nonce, and Initialization Vector Generation),
requires the generation of salts, nonces, and IVs to be used by the cryptographic components of the TOE to be performed in the specified manner.
Management: FCS_SNI_EXT.1
There are no management functions foreseen.
Audit: FCS_SNI_EXT.1
There are no audit events foreseen.
FCS_SNI_EXT.1 Cryptographic Operation (Salt, Nonce, and Initialization Vector Generation)
Hierarchical to:
No other components.
Dependencies to:
FCS_RBG.1 Cryptographic Operation (Random Bit Generation)
hash the [selection: submask, intermediate key, BEV]
as specified in [assignment:
cryptographic operation requirement] and compare it to a stored hashed [selection: submask, intermediate key, BEV];
decrypt a known value using the [selection: submask, intermediate key, BEV] specified in FCS_COP.1/SKC and compare it against a stored known value
].
FCS_VAL_EXT.1.2
The TSF shall require validation of the [selection: submask, intermediate key, BEV] prior to [assignment:
activity requiring validation].
perform a key sanitization of the DEK upon a
[selection: configurable number, [assignment:
ST author specified number]]
of consecutive failed validation attempts
institute a delay such that only [assignment:
ST author specified number of attempts] can be made within a 24 hour period
block validation after [assignment:
ST author specified number of attempts] of consecutive failed validation attempts
require power cycle or reset the TOE after [assignment:
ST author specified number of attempts] of consecutive failed validation attempts
].
C.2.2 Protection of the TSF (FPT)
This PP defines the following extended components as part of the
FPT class originally defined by CC Part 2:
C.2.2.1 FPT_KYP_EXT Key and Key Material Protection
Family Behavior
This family requires that key and key material be protected if and when written to non-volatile storage.
Component Leveling
FPT_KYP_EXT.1,
Protection of Key and Key Material ,
requires the TSF to ensure that no plaintext key or key material are written to non-volatile storage.
only store keys in non-volatile memory when wrapped, as specified in FCS_COP.1, or encrypted, as specified in FCS_COP.1
only store plaintext keys that meet any one of the following criteria [selection:
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 the other half of the key split is [selection:
wrapped as specified in FCS_COP.1
encrypted as specified in FCS_COP.1
derived and not stored in non-volatile memory
]
the non-volatile memory the key is stored on is located in an external storage device for use as an authorization factor
the plaintext key is only used to provide additional cryptographic protection to other keys, such that disclosure of the plaintext key would not compromise the security of the keys being protected
]
].
C.2.2.2 FPT_PWR_EXT Power Management
Family Behavior
This family defines secure behavior of the TSF when the TOE supports multiple power saving states. The use of compliant power saving states (i.e. power saving states that purge security relevant data upon entry) is essential for ensuring that state transitions cannot be used as attack vectors to bypass TOE self-protection mechanisms.
Component Leveling
FPT_PWR_EXT.1,
Power Saving States,
defines the compliant power saving states that are implemented by the TSF.
FPT_PWR_EXT.2,
Timing of Power Saving States,
describes the situations that cause compliant power saving states to be entered.
Management: FPT_PWR_EXT.1
The following actions could be considered for the management functions in FMT:
Enable or disable the use of individual power saving states
Specify one or more power saving state configurations
Audit: FPT_PWR_EXT.1
There are no auditable events foreseen.
FPT_PWR_EXT.1 Power Saving States
Hierarchical to:
No other components.
Dependencies to:
No dependencies
FPT_PWR_EXT.1.1
The TSF shall define the following compliant power saving states: [selection: S3, S4, G2(S5), G3, [assignment:
other power saving states]].
Management: FPT_PWR_EXT.2
There are no management functions foreseen.
Audit: FPT_PWR_EXT.2
The following actions should be auditable if FAU_GEN Security audit data generation is included in the cPP/ST:
Transition of the TSF into different power saving states
For each compliant power saving state defined in FPT_PWR_EXT.1.1, the TSF shall enter
the compliant power saving state when the following conditions occur: user-initiated request, [selection: shutdown, user inactivity, request initiated by remote management system, [assignment:
other conditions], no other conditions].
C.2.2.3 FPT_TUD_EXT Trusted Update
Family Behavior
Components in this family address the requirements for updating the TOE firmware and/or software.
Component Leveling
FPT_TUD_EXT.1,
Trusted Update,
requires the capability to be provided to update the TOE firmware and software, including the ability to verify the updates prior to installation.
Management: FPT_TUD_EXT.1
The following actions could be considered for the management functions in FMT:
Ability to update the TOE and to verify the updates
Audit: FPT_TUD_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the cPP/ST:
Initiation of the update process
Any failure to verify the integrity of the update
FPT_TUD_EXT.1 Trusted Update
Hierarchical to:
No other components.
Dependencies to:
FCS_COP.1 Cryptographic Operation
FPT_TUD_EXT.1.1
The TSF shall provide [assignment:
list of subjects] the ability to
query the current version of the TOE
[selection: software, firmware].
FPT_TUD_EXT.1.2
The TSF shall provide [assignment:
list of subjects] the ability to initiate updates to TOE
[selection: software, firmware].
FPT_TUD_EXT.1.3
The TSF shall verify updates to the TOE software using a [selection: digital signature, published hash] by the manufacturer prior to installing those updates.
Appendix D - Implicitly Satisfied Requirements
This appendix lists requirements that should be considered satisfied by products
successfully evaluated against this PP. These requirements are not featured
explicitly as SFRs and should not be included in the ST. They are not included as
standalone SFRs because it would increase the time, cost, and complexity of evaluation.
This approach is permitted by [CC] Part 1, 8.3 Dependencies between components.
This information benefits systems engineering activities which call for inclusion of particular
security controls. Evaluation against the PP provides evidence that these controls are present
and have been evaluated.
Table 13: Implicitly Satisfied Requirements
Requirement
Rationale for Satisfaction
FIA_UAU.1 – Timing of Authentication
FMT_SMR.1 has a dependency on FIA_UAU.1. It is satisfied as functions outside of restrictions of FMT_SMR.1 are not security relevant in this cPP.
Appendix E - Entropy Documentation and Assessment
This is an optional appendix in the cPP, and only applies if the TOE is providing deterministic random bit generation services, e.g. the ST claims FCS_RBG.1.
This appendix describes the required supplementary information for each entropy source used by the TOE.
The documentation of the entropy sources should be detailed enough that, after reading, the evaluator will thoroughly understand the entropy source and why it can be relied upon to provide sufficient entropy. This documentation should include multiple detailed sections: design description, entropy justification, operating conditions, and health testing. This documentation is not required to be part of the TSS in the public facing ST.
E.1 Design Description
Documentation shall include the design of each entropy source as a whole, including the interaction of all entropy source components. Any information that can be shared regarding the design should also be included for any third-party entropy sources that are included in the product.
The documentation will describe the operation of the entropy source to include how entropy is produced, and how unprocessed (raw) data can be obtained from within the entropy source for testing purposes. The documentation should walk through the entropy source design indicating where the entropy comes from, where the entropy output is passed next, any post-processing of the raw outputs (hash, XOR, etc.), if/where it is stored, and finally, how it is output from the entropy source. Any conditions placed on the process (e.g., blocking) should also be described in the entropy source design. Diagrams and examples are encouraged.
This design must also include a description of the content of the security boundary of the entropy source and a description of how the security boundary ensures that an adversary outside the boundary cannot affect the entropy rate.
If implemented, the design description shall include a description of how third-party applications can add entropy to the RBG. A description of any RBG state saving between power-off and power-on shall be included.
E.2 Entropy Justification
There should be a technical argument for where the unpredictability in the source comes from and why there is confidence in the entropy source delivering sufficient entropy for the uses made of the RBG output (by this particular TOE). This argument will include a description of the expected min-entropy rate (i.e. the minimum entropy (in bits) per bit or byte of source data) and explain that sufficient entropy is going into the TOE randomizer seeding process. This discussion will be part of a justification for why the entropy source can be relied upon to produce bits with entropy.
The amount of information necessary to justify the expected min-entropy rate depends on the type of entropy source included in the product.
For developer provided entropy sources, in order to justify the min-entropy rate, it is expected that a large number of raw source bits will be collected, statistical tests will be performed, and the min-entropy rate determined from the statistical tests. While no particular statistical tests are required at this time, it is expected that some testing is necessary in order to determine the amount of min-entropy in each output.
For third party provided entropy sources, in which the TOE vendor has limited access to the design and raw entropy data of the source, the documentation will indicate an estimate of the amount of min-entropy obtained from this third-party source. It is acceptable for the vendor to “assume” an amount of min-entropy, however, this assumption must be clearly stated in the documentation provided. In particular, the min-entropy estimate must be specified and the assumption included in the ST.
Regardless of type of entropy source, the justification will also include how the DRBG is initialized with the entropy stated in the ST, for example by verifying that the min-entropy rate is multiplied by the amount of source data used to seed the DRBG or that the rate of entropy expected based on the amount of source data is explicitly stated and compared to the statistical rate. If the amount of source data used to seed the DRBG is not clear or the calculated rate is not explicitly related to the seed, the documentation will not be considered complete.
The entropy justification shall not include any data added from any third-party application or from any state saving between restarts.
E.3 Operating Conditions
The entropy rate may be affected by conditions outside the control of the entropy source itself. For example, voltage, frequency, temperature, and elapsed time after power-on are just a few of the factors that may affect the operation of the entropy source. As such, documentation will also include the range of operating conditions under which the entropy source is expected to generate random data. Similarly, documentation shall describe the conditions under which the entropy source is no longer guaranteed to provide sufficient entropy. Methods used to detect failure or degradation of the source shall be included.
E.4 Health Testing
More specifically, all entropy source health tests and their rationale will be documented. This will include a description of the health tests, the rate and conditions under which each health test is performed (e.g., at startup, continuously, or on-demand), the expected results for each health test, TOE behavior upon entropy source failure, and rationale indicating why each test is believed to be appropriate for detecting one or more failures in the entropy source.
Appendix F - Key Management Description
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 diagrams. 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.
The essay will also describe the following topics:
A description of all authorization methods that are supported by the product and how each factor is handled, including any conditioning and combining performed.
If validation is supported, 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 ultimate release of the BEV. This section shall detail the key chain used by the product. It shall describe which keys are used in the protection of the BEV and how they meet the derivation, key wrap, or a combination of the two requirements, including the direct chain from the initial authorization to the BEV. 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 factors and the effective strength of the BEV is maintained throughout the Key Chain.
A description of the data encryption engine, its components, and details about its implementation (e.g. for hardware: integrated within the device’s main SOC or separate co-processor, for software: initialization of the product, drivers, libraries (if applicable), logical interfaces for encryption/decryption, and areas which are not encrypted (e.g. boot loaders, portions associated with the Master Boot Record (MBRs), partition tables, etc.)). The description should also include the data flow from the device’s host interface to the device’s persistent media storing the data, information on those conditions in which the data bypasses the data encryption engine (e.g. read-write operations to an unencrypted Master Boot Record area). The description should be detailed enough to verify all platforms to ensure that when the user enables encryption, the product encrypts all hard storage devices. It should also describe the platform’s boot initialization, the encryption initialization process, and at what moment the product enables the encryption.
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 factors to the BEV 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 Key Derivation or Key Wrapping (from the allowed options). The diagram should indicate the input used to derive or unwrap each key in the chain.
A functional (block) diagram showing the main components (such as memories and processors) and the data path between, for hardware, the device’s host interface and the device’s persistent media storing the data, or for software, the initial steps needed for the activities the TOE performs to ensure it encrypts the storage device entirely when a user or administrator first provisions the product. The hardware encryption diagram shall show the location of the data encryption engine within the data path.
The hardware encryption diagram shall show the location of the data encryption engine within the data path. The evaluator shall validate that the hardware encryption diagram contains enough detail showing the main components within the data path and that it clearly identifies the data encryption engine.
