Supporting Document
Mandatory Technical Document
Collaborative Protection Profile for Application Software
Version: 2.0
2026-07-21
Application Software International Technical Community (AppSW-iTC)
This is a Supporting Document (SD), intended to complement the Common Criteria version 3 and the associated Common Evaluation Methodology for Information Technology Security Evaluation.
SDs may be “Guidance Documents”, that highlight specific approaches and application of the standard to areas where no mutual recognition of its application is required, and as such, are not of normative nature, or “Mandatory Technical Documents”, whose application is mandatory for evaluations whose scope is covered by that of the SD. The usage of the latter class is not only mandatory, but certificates issued as a result of their application are recognized under the CCRA.
Technical Editor:
Application Software International Technical Community (AppSW-iTC)
Document history:
| Version | Date | Comment |
|---|---|---|
| v 1.0 | 2014-10-20 | Initial release |
| v 1.1 | 2014-11-05 | Addition to TLS cipher suite selections |
| v 1.2 | 2016-04-22 | Added server-side TLS requirements (selection-based) Multiple clarification based on NIAP TRRT inquiries Refactored FDP_DEC_EXT.1 into separate components |
| v 1.3 | 2019-03-01 | Incorporated available Technical Decisions Refactored FPT_TUD Added a selection to FTP_DIT Moved SWID Tags requirement Leveraged TLS Package Added equivalency section |
| v 1.4 | 2021-10-07 | Incorporated applicable Technical Decisions Updated to TLS FP 2.1 Incorporated SSH FP 2.0 |
| v 2.0 | 2025-06-16 | Rebaselined from the NIAP Protection Profile for Application Software, Version 2.0, as the source baseline rather than revising the prior collaborative Protection Profile for Application Software Version 1.4 Converted to collaborative Protection Profile maintained by the Application Software International Technical Community (AppSW-iTC) CC:2022 conversion Updating for TLS FP, SSH FP, and X.509 FP TDs and GitHub Issues CNSA 2.0 updates ALC FLR Updates |
| v 2.0 Draft | 2026-07-21 | Draft-review updates. |
General Purpose:
The purpose of this SD is to define evaluation methods for the functional behavior of
products.
Acknowledgments:
This SD was developed by the Application Software International Technical Community (AppSW-iTC), with representatives from industry, government agencies, Common Criteria Test Laboratories, and academia.
The scope of the Collaborative Protection Profile for Application Software is to describe the security functionality of products in terms of [CC] and to define functional and assurance requirements for them.
Although Evaluation Activities are defined mainly for the evaluators to follow, in general they also help developers to prepare for evaluation by identifying specific requirements for their TOE. The specific requirements in Evaluation Activities may in some cases clarify the meaning of Security Functional Requirements (SFR), and may identify particular requirements for the content of Security Targets (ST) (especially the TOE Summary Specification), user guidance documentation, and possibly supplementary information (e.g. for entropy analysis or cryptographic key management architecture).
Evaluation Activities can be defined for both SFRs and Security Assurance Requirements (SAR), which are themselves defined in separate sections of the SD.
If any Evaluation Activity cannot be successfully completed in an evaluation, then the overall verdict for the evaluation is a 'fail'. In rare cases there may be acceptable reasons why an Evaluation Activity may be modified or deemed not applicable for a particular TOE, but this must be approved by the Certification Body for the evaluation.
In general, if all Evaluation Activities (for both SFRs and SARs) are successfully completed in an evaluation then it would be expected that the overall verdict for the evaluation is a ‘pass’. To reach a ‘fail’ verdict when the Evaluation Activities have been successfully completed would require a specific justification from the evaluator as to why the Evaluation Activities were not sufficient for that TOE.
Similarly, at the more granular level of assurance components, if the Evaluation Activities for an assurance component and all of its related SFR Evaluation Activities are successfully completed in an evaluation then it would be expected that the verdict for the assurance component is a ‘pass’. To reach a ‘fail’ verdict for the assurance component when these Evaluation Activities have been successfully completed would require a specific justification from the evaluator as to why the Evaluation Activities were not sufficient for that TOE.
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. |
Distributed TOE | A TOE composed of multiple components operating as a logical whole. |
Extended Package (EP) | A deprecated document form for collecting SFRs that implement a particular protocol, technology, or functionality. See Functional Packages. |
Functional Package (FP) | A document that collects SFRs for a particular protocol, technology, or functionality. |
Operational Environment (OE) | Hardware and software that are outside the TOE boundary that support the TOE functionality and security policy. |
Protection Profile (PP) | An implementation-independent set of security requirements for a category of products. |
Protection Profile Configuration (PP-Configuration) | A comprehensive set of security requirements for a product type that consists of at least one Base-PP and at least one PP-Module. |
Protection Profile Module (PP-Module) | An implementation-independent statement of security needs for a TOE type complementary to one or more Base-PPs. |
Security Assurance Requirement (SAR) | A requirement to assure the security of the TOE. |
Security Functional Requirement (SFR) | A requirement for security enforcement by the TOE. |
Security Target (ST) | A set of implementation-dependent security requirements for a specific product. |
Target of Evaluation (TOE) | The product under evaluation. |
TOE Security Functionality (TSF) | The security functionality of the product under evaluation. |
TOE Summary Specification (TSS) | A description of how a TOE satisfies the SFRs in an ST. |
Address Space Layout Randomization (ASLR) | An anti-exploitation feature which loads memory mappings into unpredictable locations. ASLR makes it more difficult for an attacker to redirect control to code that they have introduced into the address space of an application process. |
Application (app) | Software that runs on a platform and performs tasks on behalf of the user or owner of the platform, as well as its supporting documentation. For a single-component TOE, the terms TOE and application are interchangeable in this document. For a distributed TOE, the TOE is the collective boundary and an application component is an identified TOE Component within that boundary. |
Application Framework | A software framework used by an application to provide application structure or security-relevant services such as request routing, authentication, authorization, session management, object binding, serialization or deserialization, configuration management, cryptographic provider selection, management endpoint exposure, or other application behavior. Examples include web, enterprise, dependency injection, remote procedure call, and service frameworks. |
Application Programming Interface (API) | A specification of routines, data structures, object classes, and variables that allows an application to make use of services provided by another software component, such as a library. APIs are often provided for a set of libraries included with the platform. |
Communication Relationship Type | A class of communications between an identified initiating TOE Component and an identified receiving TOE Component, which may be the same TOE Component, where the communications have the same security purpose, interfaces, protocol roles, protection mechanism, identity and trust model, and security-relevant configuration. Relationships are separate types when a difference can affect an applicable SFR or Evaluation Activity. |
Component Implementation-Equivalence Class | For one or more explicitly identified SFR iterations and implementation-specific portions of Evaluation Activities, a set of named SFR Implementation Instances, used by one or more TOE Components in identified security-relevant configurations where applicable, that have the same security-relevant implementation and version, wrapper or integration behavior, security-relevant build options and implementation configuration relevant to the reused activities, role and exercised code path, cryptographic provider where applicable, and immediate platform services and interfaces relevant to the reused activities. Peripheral differences may exist only when they are identified and demonstrated not to affect the scoped Evaluation Activity results. Channel-specific deployed values that are covered by retained interface or channel checks do not, by themselves, prevent class membership. Interfaces and communication relationships are coverage targets rather than class members. |
Credential | Data that establishes the identity of a user, e.g. a cryptographic key or password. |
Data Execution Prevention (DEP) | An anti-exploitation feature of modern operating systems executing on modern computer hardware, which enforces a non-execute permission on pages of memory. DEP prevents pages of memory from containing both data and instructions, which makes it more difficult for an attacker to introduce and execute code. |
Developer | An entity that writes application software. For the purposes of this document, vendors and developers are the same. |
Managed Runtime | A software execution environment, other than the operating system, that interprets, compiles, loads, hosts, or otherwise mediates execution of application code. Examples include virtual machines, language runtimes, managed execution environments, embedded application servers, and scripting runtimes. |
Mobile Code | Software transmitted from a remote system for execution within a limited execution environment on the local system. Typically, there is no persistent installation and execution begins without the user's consent or even notification. Examples of mobile code technologies include JavaScript, Java applets, Adobe Flash, and Microsoft Silverlight. |
Operating System (OS) | Software that manages hardware resources and provides services for applications. |
Personally Identifiable Information (PII) | Any information about an individual maintained by an agency, including, but not limited to, education, financial transactions, medical history, and criminal or employment history and information which can be used to distinguish or trace an individual's identity, such as their name, social security number, date and place of birth, mother’s maiden name, biometric records, etc., including any other personal information which is linked or linkable to an individual.[OMB] |
Platform | The environment in which application software runs. The platform can be an operating system, hardware environment, a software based execution environment, or some combination of these. These types of platforms may also run atop other platforms. |
Protected Channel Instance | A materially distinct realization of a Communication Relationship Type. A channel instance is distinguished by an interface, protocol role, credential or trust configuration, endpoint-identity processing, protection configuration, or interruption and recovery behavior that can affect an applicable Evaluation Activity. Otherwise equivalent channels that differ only because additional Runtime Replicas create them are not separate instances unless an Evaluation Activity expressly requires every deployed instance to be examined or tested. |
Running-Payload Activity | The portion of an Evaluation Activity whose evaluation object is a TOE application payload executing in a Linux container and whose procedure examines or observes its Linux userspace process, executable, effective filesystem, or effective application configuration. The term does not include activity portions whose evaluation object is an image or update artifact, installation or update workflow, container runtime or orchestrator configuration, or external interface or channel. |
Runtime Replica | A TOE Component Instance that has the same application artifact, security-relevant configuration, role, claimed SFR behavior, and relevant platform interface as another deployed instance of that TOE Component. Instance-specific identities, addresses, credentials, or similar deployed values may differ when the difference does not alter the claimed SFR behavior or an Evaluation Activity result and remains covered by the required instance-, interface-, or channel-specific checks. Horizontal scaling through Runtime Replicas does not create an additional TOE Component. An instance with a different application artifact is not a Runtime Replica and shall be represented as a separately identified TOE Component or explicitly identified configuration. An instance with another difference that can affect an SFR or Evaluation Activity is also not a Runtime Replica and shall be represented separately in the same manner. |
SFR Implementation Instance | A unique use of a security-relevant implementation by a TOE Component, in an identified security-relevant configuration where applicable, to satisfy one or more SFRs. Additional Runtime Replicas that deploy that use do not create additional SFR Implementation Instances. |
Sensitive Data | Sensitive data may include all user or enterprise data or may be specific application data such as emails, messaging, documents, calendar items, and contacts. Sensitive data must minimally include PII, credentials, and keys. Sensitive data shall be identified in the application’s TSS by the ST author. |
Stack Cookie | An anti-exploitation feature that places a value on the stack at the start of a function call, and checks that the value is the same at the end of the function call. This is also referred to as Stack Guard, or Stack Canaries. |
TOE Component | A named, logical, separately deployable portion of the TOE that is identified in the ST and mapped to the base cPP, applicable PP-Modules, and relevant SFRs. A TOE Component may have one or more deployed TOE Component Instances. A different application artifact, or a difference in security-relevant configuration, role, claimed SFR behavior, or relevant platform interface that can affect an SFR or Evaluation Activity, requires a separately identified TOE Component or explicitly identified configuration. |
TOE Component Instance | A deployed occurrence of a TOE Component. |
Vendor | An entity that sells application software. For purposes of this document, vendors and developers are the same. Vendors are responsible for maintaining and updating application software. |
The EAs presented in this section capture the actions the evaluator performs to address technology specific aspects covering specific SARs (e.g. ASE_TSS.1, ADV_FSP.1, AGD_OPE.1, and ATE_IND.1) – this is in addition to the CEM workunits that are performed in Section 3 Evaluation Activities for SARs.
Regarding design descriptions (designated by the subsections labeled TSS, as well as any required supplementary material that may be treated as proprietary), the evaluator must ensure there is specific information that satisfies the EA. For findings regarding the TSS section, the evaluator’s verdicts will be associated with the CEM workunit ASE_TSS.1-1. Evaluator verdicts associated with the supplementary evidence will also be associated with ASE_TSS.1-1, since the requirement to provide such evidence is specified in ASE in the PP.
For ensuring the guidance documentation provides sufficient information for the administrators/users as it pertains to SFRs, the evaluator’s verdicts will be associated with CEM workunits ADV_FSP.1-7, AGD_OPE.1-4, and AGD_OPE.1-5.
Finally, the subsection labeled Tests is where the authors have determined that testing of the product in the context of the associated SFR is necessary. While the evaluator is expected to develop tests, there may be instances where it is more practical for the developer to construct tests, or where the developer may have existing tests. Therefore, it is acceptable for the evaluator to witness developer-generated tests in lieu of executing the tests. In this case, the evaluator must ensure the developer’s tests are executing both in the manner declared by the developer and as mandated by the EA. The CEM workunits that are associated with the EAs specified in this section are: ATE_IND.1-3, ATE_IND.1-4, ATE_IND.1-5, ATE_IND.1-6, and ATE_IND.1-7.
The evaluator shall examine the TSS to verify that it describes whether the TSF has functions that require the use of asymmetric key generation services, and whether these services are implemented within the TOE boundary or invoked by the TSF from its operational environment.
Conditional: If the ST claims "generate no asymmetric keys," the evaluator shall ensure that the TOE does not have any functions that would require asymmetric key generation (for example, because it does not use asymmetric keys for any purpose or because the keys that it does use are generated elsewhere and imported into it as part of initial setup).None.
None.
If "use no DRBG functionality" is selected, the evaluator shall inspect the application and its developer documentation and verify that the application needs no random bit generation services.
If "implement DRBG functionality" is selected, the evaluator shall ensure that FCS_RBG.1 is claimed.If "invoke platform-provided DRBG functionality" is selected, the evaluator performs the following activities. The evaluator shall examine the TSS to confirm that it identifies all functions (as described by the SFRs included in the ST) that obtain random numbers from the platform RBG. The evaluator shall determine that for each of these functions, the TSS states which platform interface (API) is used to obtain the random numbers. The evaluator shall confirm that each of these interfaces corresponds to the acceptable interfaces listed for each platform below.It should be noted that there is no expectation that the evaluators attempt to confirm that the APIs are being used correctly for the functions identified in the TSS; the activity is to list the used APIs and then do an existence check via decompilation.The evaluator shall verify the guidance documentation contains any information required for configuring the DRBG.
If "invoke platform-provided DRBG functionality" is selected, the following tests shall be performed:
The evaluator shall decompile the application binary using a decompiler suitable for the application (TOE). The evaluator shall search the output of the decompiler to determine that, for each API listed in the TSS, that API appears in the output. If the representation of the API does not correspond directly to the strings in the following list, the evaluator shall provide a mapping from the decompiled text to its corresponding API, with a description of why the API text does not directly correspond to the decompiled text and justification that the decompiled text corresponds to the associated API.
The following are the per-platform list of acceptable APIs:
javax.crypto.KeyGenerator class or the java.security.SecureRandom class or /dev/random or /dev/urandom.
rand_s, RtlGenRandom, BCryptGenRandom, or CryptGenRandom API is used for classic desktop applications. The evaluator shall verify the application uses the RNGCryptoServiceProvider class or derives a class from System.Security.Cryptography.RandomNumberGenerator API for Windows Universal Applications. It is only required that the API is called/invoked, there is no requirement that the API be used directly. In future versions of this document, CryptGenRandom may be removed as an option as it is no longer the preferred API per vendor documentation.
SecRandomCopyBytes, CCRandomGenerateBytes, or CCRandomCopyBytes, or uses /dev/random directly to acquire random.
/dev/random or /dev/urandom.
/dev/random.
CCRandomGenerateBytes or CCRandomCopyBytes, or collects random from /dev/random.
If invocation of platform-provided functionality is achieved in another way, the evaluator shall ensure the TSS describes how this is carried out, and how it is equivalent to the methods listed here (e.g. higher-level API invokes identical low-level API).
The evaluator shall check the TSS to ensure that it lists all persistent credentials (secret keys, PKI private keys, or passwords) needed to meet the requirements in the ST. For each of these items, the evaluator shall confirm that the TSS lists for what purpose it is used, and how it is stored.
If not store any credentials is selected, the evaluator shall verify the TSS describes the behavior of the TOE in sufficient detail to verify that the TSF does not have any behavior that would require any credentials to be stored (e.g., because the TOE does not have any functionality requiring authentication).If securely store is selected, the evaluator shall verify the TSS contains the platform functions utilized and verify those functions are documented by the platform to be non-deprecated functions meeting the specifications in the requirement.If invoke the functionality provided by the platform to securely store is selected, the evaluator shall confirm the TSS describes how the platform storage is invoked for each supported platform. The evaluator shall confirm the invocation of the platform is using non-deprecated functions provided by the platform(s).None.
KeyStore or the Android KeyChain to store certificates.
Keychain.
Key Management Framework (KMF).
Keychain.
If any selection other than not store any sensitive data is selected the evaluator shall examine the TSS to ensure that it describes the sensitive data processed by the application. The evaluator shall then ensure that the following activities cover all of the sensitive data identified in the TSS.
If not store any sensitive data is selected, the evaluator shall inspect the TSS to ensure that it describes how sensitive data cannot be written to non-volatile memory. The evaluator shall also ensure that this is consistent with the file system test below.If implement functionality to encrypt sensitive data is selected the evaluator shall confirm the TSS describes how the application ensures all sensitive data is protected by the file encryption functions. If protect sensitive data in accordance with FCS_STO_EXT.1 is selected the evaluator shall confirm the TSS describes which data is protected via this mechanism and the selections within FCS_STO_EXT.1 that are leveraged. If multiple selections are included the evaluator shall ensure the TSS describes which sensitive data is captured by which selection.If "leverage platform-provided functionality..." is selected, the evaluation activities will be performed as stated in the following requirements, which vary on a per-platform basis.MODE_PRIVATE flag set. The evaluator shall confirm the operational guidance contains any instructions necessary for configuring the storage and protection of any sensitive data.
If leverage platform-provided functionality to encrypt sensitive data is selected the evaluator shall confirm the operational guidance contains the list of supported operational environments and any steps necessary to ensure the platform captures any sensitive data that is stored.If "implement functionality to encrypt sensitive data as defined in the PP-Module for File Encryption" or "protect sensitive data in accordance with FCS_STO_EXT.1" is selected, the evaluator shall inventory the file system locations where the application may write data. The evaluator shall run the application and attempt to store sensitive data. The evaluator shall then inspect those areas of the file system to note where data was stored (if any), and verify it has been encrypted.
If "leverage platform-provided functionality..." is selected no additional testing is required.
None.
The evaluator shall perform the platform-specific actions below and inspect user documentation to determine the application's access to hardware resources. The evaluator shall ensure that this is consistent with the selections indicated. The evaluator shall review documentation provided by the application developer and for each resource which it accesses, identify the justification as to why access is required.
uses-permission entry in the AndroidManifest.xml file for access to a hardware resource is reflected in the selection.
None.
The evaluator shall perform the platform-specific actions below and inspect user documentation to determine the application's access to sensitive information repositories. The evaluator shall ensure that this is consistent with the selections indicated. The evaluator shall review documentation provided by the application developer and for each sensitive information repository which it accesses, identify the justification as to why access is required.
uses-permission entry in the AndroidManifest.xml file for access to a sensitive information repository is reflected in the selection.
None.
The evaluator shall verify the guidance documents contain any instructions necessary to configure the restriction of network communications.
The evaluator shall check that the TSS describes whether the application requires any type of application provided credentials and whether the application is pre-configured with default values for these credentials. If credentials are required, the evaluator shall verify that the TSS details how use of the TOE is restricted until new credentials are set (which includes the replacement of default credentials if any are present).
The evaluator shall verify the guidance documentation details regarding any default or null application provided credentials being used and how they would be updated. For managed runtime or application framework based TOEs that can expose default credentials, development profiles, management interfaces, or default administrative endpoints, the evaluator shall verify that the guidance identifies the required production configuration and any actions needed to disable or replace insecure defaults.
None.
None.
find -L. -perm /002 inside the application's data directories to ensure that all files are not world-writable. The command should not print any files (for this test, directories are not considered to be files).
find -L. -perm /002 inside the application's data directories to ensure that all files are not world-writable. The command should not print any files.
find. \( -perm -002 \) inside the application's data directories to ensure that all files are not world-writable. The command should not print any files.
find. -perm +002 inside the application's data directories to ensure that all files are not world-writable. The command should not print any files.
The evaluator shall review the TSS to identify the application's configuration options (e.g., settings) and determine whether these are stored and set using the mechanisms supported by the platform or implemented by the application in accordance with the PP-Module for File Encryption. At a minimum the TSS shall list settings related to any SFRs and any settings that are mandated in the operational guidance in response to an SFR.
For managed runtime or application framework based TOEs, the evaluator shall verify that the TSS identifies the applicable runtime or framework configuration options and describes how production configuration disables or constrains debug features, remote management interfaces, management endpoints, unsafe object binding, unsafe serialization or deserialization behavior, unauthorized plug-in loading, insecure cryptographic provider selection, insecure trust store configuration, and development or sample configurations.Conditional: If "implement functionality to encrypt and store configuration options as defined by FDP_PRT_EXT.1 in the PP-Module for File Encryption" is selected, the evaluator shall ensure that the TSS identifies those options, as well as indicates where the encrypted representation of these options is stored.The evaluator shall verify the guidance documentation contains any information necessary to configure the protection of configuration settings. For managed runtime or application framework based TOEs, the evaluator shall verify that the guidance identifies the required runtime or framework configuration and any prohibited development, debug, management, deserialization, plug-in, or external configuration settings.
The evaluator shall inspect the TSS and verify that it describes what Android API is used (and provides a link to the documentation of the API) when storing configuration data. The evaluator shall run the application and verify that the behavior of the TOE is consistent with where and how the API documentation says the configuration data will be stored.
For SharedPreferences, the evaluator shall examine the XML file to make sure it reflects the changes made to the configuration to verify that the application used SharedPreferences or PreferenceActivity to store the configuration data. For DataStore, the evaluator shall use a protocol buffer analyzer to examine the file to make sure it reflects the changes made to the configuration to verify that the application used DataStore to store the configuration data.The evaluator shall determine and verify that Windows Universal Applications use either the Windows.Storage namespace, Windows.UI.ApplicationSettings namespace, or the IsolatedStorageSettings namespace for storing application specific settings. If a .NET application is implemented as a UWP application, it shall be evaluated using these UWP requirements. For .NET applications that do not use the UWP application model and do not operate as Classic Desktop applications, the evaluator shall determine and verify that the application uses one of the locations listed in https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/ or https://learn.microsoft.com/en-us/previous-versions/dotnet/netframework-4.0/zzdt0e7f(v=vs.100) or https://learn.microsoft.com/en-us/aspnet/core/fundamentals/configuration/ or https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/web-config for storing application specific (whether application-wide or user-specific) settings.
For Classic Desktop applications, the evaluator shall run the application while monitoring it with the SysInternals tool Process Monitor and make changes to its configuration. The evaluator shall verify that Process Monitor logs show corresponding changes to the Windows Registry or C:\ProgramData\ directory.user defaults system or key-value store for storing all settings.
NSUserDefaults class.
The evaluator shall verify the TSS details how the application's management functions align with the selected management functions.
The evaluator shall verify that every management function mandated by the PP is described in the operational guidance and that the description contains the information required to perform the management duties associated with the management function.
If "not use PII" is claimed, the evaluator shall verify the TSS states the application does not utilize any PII.
If "not transmit PII over a network" is claimed, the evaluator shall verify that the TSS makes this assertion (e.g., because it does not use network connectivity at all or if the functions for which it uses network connectivity do not involve transmission of PII). If "require user approval before executing..." is selected, the evaluator shall inspect the TSS documentation to verify that it identifies the functions where PII may be transmitted over a network.
The evaluator shall verify the guidance documentation contains any instructions to configure the transmission of PII and details any prompts that would approve or deny transmission of PII.
The evaluator shall ensure that the TSS describes the compiler flags used to enable ASLR when the application is compiled. If any explicitly-mapped exceptions are claimed, the evaluator shall check that the TSS identifies these exceptions, describes the static memory mapping that is used, and provides justification for why static memory mapping is appropriate in this case.
None.
pmap -x PID to ensure the two different instances share no mapping locations.
pmap -x PID to ensure the two different instances share no mapping locations.
vmmap PID to ensure the two different instances share no mapping locations.
For managed runtime or application framework based TOEs that perform just-in-time compilation, load native code, or expose native interfaces such as JNI, JNA, FFI, native plug-ins, or equivalent mechanisms within the TOE boundary, the evaluator shall verify that the TSS identifies those mechanisms.
None.
/NXCOMPAT flag was used during compilation to verify that DEP protections are enabled for the application.
None.
None.
If the OS platform supports Windows Defender Exploit Guard Exploit Protection, the evaluator shall configure the platform-supported process mitigations that are applicable to the application's execution model and supported by the evaluated Windows version, using a platform-vendor-documented method. The evaluator shall verify that the configured mitigations are applied to the application process and demonstrate that application startup and representative security-relevant operations complete successfully without disabling or placing any applicable mitigation in an audit-only or otherwise non-enforcing mode. The following link describes how to enable Exploit Protection, https://learn.microsoft.com/en-us/defender-endpoint/exploit-protection.
None.
None.
(Conditional: The PE or ELF automated tests fail) The evaluator shall ensure that the TSS describes the stack-based buffer overflow compiler flags.
None.
For PE, the evaluator will disassemble each and ensure the following sequence appears:
mov rcx, QWORD PTR [rsp+(...)]xor rcx, (...)call (...)For ELF executables, the evaluator will ensure that each contains references to the symbol __stack_chk_fail.
If these automated tests fail, the evaluator shall perform the above, conditional TSS activity.Tools such as Canary Detector may help automate these activities.
The evaluator shall verify that the TSS lists the platform APIs used in the application. The evaluator shall then compare the list with the supported APIs (available through e.g. developer accounts, platform developer groups) and ensure that all APIs listed in the TSS are supported.
For managed runtime or application framework based TOEs, the evaluator shall verify that the TSS identifies the runtime or framework APIs used for security-relevant behavior and indicates whether any unsupported, deprecated, internal, reflective, dynamically loaded, or native interface APIs are used.None.
For managed runtime or application framework based TOEs, the evaluator shall verify that the TSS identifies each runtime or framework included in the TOE boundary. The TSS shall identify the runtime or framework version, the security-relevant services used by the TOE, and whether the runtime or framework provides services such as authentication, authorization, session management, object binding, serialization or deserialization, management endpoints, cryptographic provider selection, trust store handling, configuration loading, or code loading.
None.
The evaluator shall verify that the TSS identifies how the application is distributed. If "as an additional package..." is selected, the evaluator shall perform the tests in FPT_TUD_EXT.2.
None.
The evaluator shall confirm the TSS describes the data transmitted, and verify it matches the selections of all data or sensitive data.
The evaluator shall confirm the TSS describes the method by which the data is protected and that is matches the chosen selections, if multiple selections are included the evaluator shall verify the TSS describes which data is sent over which trusted channels and the totality of the data type selection is covered by all chosen selections.For platform-provided functionality, the evaluator shall verify the TSS contains the calls to the platform that the TOE is leveraging to invoke the functionality. The evaluator shall verify calls are documented by the platform vendor and non-deprecated.For platform-provided HTTPS, IPsec, TLS, or DTLS as a client the evaluator shall verify that the TSS lists any specific calls the product uses that specifies or allows the end users to specify cipher suites, support for mutual authentication, support for session renegotiation, hash algorithms for the signature_algorithms extension in the Client Hello with the supported_signature_algorithms value, and the supported groups in the Supported Groups Extension in Client Hello. The evaluator shall verify any calls the product specifies align with the options provided in this PP and the Functional Package for Transport Layer Security (TLS), version 2.1.For platform-provided HTTPS, IPsec, TLS, or DTLS as a server the evaluator shall verify that the TSS lists any specific calls the product uses that specifies or allows the end users to specify cipher suites, which protocols are denied connection requests, key establishment algorithms, support for mutual authentication, response to an invalid client certificate, and support for session renegotiation. The evaluator shall verify any calls the product specifies align with the options provided in this PP and the Functional Package for Transport Layer Security (TLS), version 2.1.For platform-provided HTTPS the evaluator shall verify that the TSS lists any specific calls the product uses that specifies or allows the end users to specify the response to an invalid certificate.For platform-provided HTTPS as a server the evaluator shall verify that the TSS lists any specific calls the product uses that specifies or allows the end users to specify cipher suites, which protocols are denied connection requests, key establishment algorithms, support for mutual authentication, response to an invalid client certificate, and support for session renegotiation. The evaluator shall verify any calls the product specifies align with the options provided in this PP and the Functional Package for Transport Layer Security (TLS), version 2.1.For platform-provided SSH the evaluator shall verify that the TSS lists any specific calls the product uses that specifies or allows the end users to specify the applicable RFCs, the authentication methods, the limit for dropping large packets in an SSH transport connection, the SSH transport accepted algorithms, the SSH public key for public-key based authentication, The diffie-hellman-group used for key exchange, and the parameters of session rekey or termination. The evaluator shall verify any calls the product specifies align with the options provided in this PP and the Functional Package for Secure Shell (SSH), version 2.0.The evaluator shall confirm the guidance documentation contains any information necessary for enabling and configuring the trusted channels that have been selected.
The evaluator shall ensure that the TSS identifies the key sizes supported by the TOE. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify that it identifies the usage for each scheme
If the ST selects "invoke platform-provided functionality," then the evaluator shall examine the TSS to verify that it describes how the key generation functionality is invoked and that the invocation matches the algorithm and size selections for each supported platform. The evaluator shall confirm the invocation of the platform is using non-deprecated functions provided by the platform(s).The evaluator shall verify that the operational guidance instructs the administrator how to configure the TOE to use the selected key generation scheme(s) and key size(s) for all uses defined in this PP if any configuration is required.
If the ST selects "implement functionality," then the following test activities shall be carried out.
Evaluation Activity Note: The following tests may require the developer to provide access to a developer environment that provides the evaluator with tools that are not typically available to end-users of the application
Key Generation for FIPS PUB 186-5 RSA Schemes
The evaluator shall verify the implementation of RSA Key Generation by the TOE using the Key Generation test. This test verifies the ability of the TSF to correctly produce values for the key components including the public verification exponent e, the private prime factors p and q, the public modulus n and the calculation of the private signature exponent d. Key Pair generation specifies 5 ways (or methods) to generate the primes p and q. These include:
If possible, the Random Probable primes method should also be verified against a known good implementation as described above. Otherwise, the evaluator shall have the TSF generate 10 keys pairs for each supported key length nlen and verify:
Key Generation for Elliptic Curve Cryptography (ECC)
FIPS 186-5 ECC Key Generation Test- For each supported NIST curve, i.e., P-384 and P-521, the evaluator shall require the implementation under test (IUT) to generate 10 private/public key pairs. The private key shall be generated using an approved random bit generator (RBG). To determine correctness, the evaluator shall submit the generated key pairs to the public key verification (PKV) function of a known good implementation.
FIPS 186-5 Public Key Verification (PKV) Test- For each supported NIST curve, i.e., P-384 and P-521, the evaluator shall generate 10 private/public key pairs using the key generation function of a known good implementation and modify five of the public key values so that they are incorrect, leaving five values unchanged (i.e., correct). The evaluator shall obtain in response a set of 10 PASS/FAIL values.
Key Generation for Finite-Field Cryptography (FFC)
The evaluator shall verify the implementation of the Parameters Generation and the Key Generation for FFC by the TOE using the Parameter Generation and Key Generation test. This test verifies the ability of the TSF to correctly produce values for the field prime p, the cryptographic prime q (dividing p-1), the cryptographic group generator g, and the calculation of the private key x and public key y. The Parameter generation specifies two ways (or methods) to generate the cryptographic prime q and the field prime p:
Cryptographic and Field Primes:
Cryptographic Group Generator:
Private Key:
Testing for FFC Schemes using safe-prime groups is done as part of testing in FCS_CKM.2.1
Key Generation for LMS/XMSS
For each supported LMS/LMSOTS pair, the evaluator will provide 1, 2, 3, 4, 5 seeds for H = 25, 20, 15, 10, 5 respectively where H = the height of the LMS tree. For each seed, the TOE will generate the corresponding public key which is to be verified by the evaluator using a known good implementation.
Key Generation for ML-DSA
The evaluator shall 10x input to the internal KeyGen function a 32-byte random seed. Verify the returned public-private key pair is correct using a known good implementation. Here internal KeyGen refers to the TOE’s implementation of the function ML-DSA.KeyGen_internal(-) as described in FIPS.204.
Key Generation for ML-KEM
The evaluator shall 10x input to the internal KeyGen function a pair of 32-byte random string. Verify the returned encapsulation and decapsulation key pair is correct using a known good implementation. Here internal KeyGen refers to the TOE’s implementation of the function ML-KEM.KeyGen_internal(-,-) as described in FIPS.203.
The evaluator shall review the TSS to determine that it describes how the functionality described by FCS_RBG_EXT.1 is invoked.
If the application is relying on random bit generation from the host platform, the evaluator shall verify the TSS includes the name/manufacturer of the external RBG and describes the function call and parameters used when calling the external DRBG function. If different external RBGs are used for different platforms, the evaluator shall verify the TSS identifies each RBG for each platform. Also, the evaluator shall verify the TSS includes a short description of the vendor's assumption for the amount of entropy seeding the external DRBG. The evaluator uses the description of the RBG functionality in FCS_RBG_EXT or documentation available for the operational environment to determine that the key size being requested is identical to the key size and mode to be used for the encryption/decryption of the user data.The evaluator shall verify the guidance documentation contains any information necessary to configure key sizes.
The evaluator shall ensure that the supported key establishment schemes claimed in the TSS correspond to the key generation schemes identified in FCS_CKM.1.1/AK. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify that it identifies the usage for each scheme.
If the ST selects "invoke platform-provided functionality," then the evaluator shall examine the TSS to verify that it describes how the key establishment functionality is invoked and that the invocation matches the algorithm selection for each supported platform. The evaluator shall confirm the invocation of the platform is using non-deprecated functions provided by the platform(s).The evaluator shall verify that the operational guidance instructs the administrator how to configure the TOE to use the selected key establishment scheme(s) if configuration is required.
Evaluation Activity Note: The following tests require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products.
Key Establishment Schemes The evaluator shall verify the implementation of the key establishment schemes supported by the TOE using the applicable tests below.
SP800-56A Key Establishment Schemes
The evaluator shall verify a TOE's implementation of SP800-56A key agreement schemes using the following Function and Validity tests. These validation tests for each key agreement scheme verify that a TOE has implemented the components of the key agreement scheme according to the specifications in the Recommendation. These components include the calculation of the DLC primitives (the shared secret value Z) and the calculation of the derived keying material (DKM) via the Key Derivation Function (KDF). If key confirmation is supported, the evaluator shall also verify that the components of key confirmation have been implemented correctly, using the test procedures described below. This includes the parsing of the DKM, the generation of MACdata and the calculation of MACtag.
Function Test
The Function test verifies the ability of the TOE to implement the key agreement schemes correctly. To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each supported key agreement scheme-key agreement role combination, KDF type, and if supported, key confirmation role and type combination, the tester shall generate 10 sets of test vectors. The data set consists of one set of domain parameter values (FFC) or the NIST approved curve (ECC) per 10 sets of public keys. These keys are static, ephemeral or both depending on the scheme being tested.
The evaluator shall obtain the DKM, the corresponding TOE’s public keys (static and/or ephemeral), the MAC tag(s), and any inputs used in the KDF, such as the Other Information (OtherInfo) and TOE ID fields.
If the TOE does not use a KDF defined in SP 800-56A, the evaluator shall obtain only the public keys and the hashed value of the shared secret.
The evaluator shall verify the correctness of the TSF’s implementation of a given scheme by using a known good implementation to calculate the shared secret value, derive the keying material DKM, and compare hashes or MAC tags generated from these values.
If key confirmation is supported, the TSF shall perform the above for each implemented approved MAC algorithm.
Validity Test
The Validity test verifies the ability of the TOE to recognize another party’s valid and invalid key agreement results with or without key confirmation. To conduct this test, the evaluator shall obtain a list of the supporting cryptographic functions included in the SP800-56A key agreement implementation to determine which errors the TOE should be able to recognize. The evaluator generates a set of 24 (FFC) or 30 (ECC) test vectors consisting of data sets including domain parameter values or NIST approved curves, the evaluator’s public keys, the TOE’s public/private key pairs, MACTag, and any inputs used in the KDF, such as the OtherInfo and TOE ID fields.
The evaluator shall inject an error in some of the test vectors to test that the TOE recognizes invalid key agreement results caused by the following fields being incorrect: the shared secret value Z, the DKM, the OtherInfo field, the data to be MACed, or the generated MACTag. If the TOE contains the full or partial (only ECC) public key validation, the evaluator will also individually inject errors in both parties’ static public keys, both parties’ ephemeral public keys and the TOE’s static private key to ensure that the TOE detects errors in the public key validation function and/or the partial key validation function (in ECC only). At least two of the test vectors shall remain unmodified and therefore should result in valid key agreement results (they should pass).
The TOE shall use these modified test vectors to emulate the key agreement scheme using the corresponding parameters. The evaluator shall compare the TOE’s results with the results obtained by using a known good implementation verifying that the TOE detects these errors.
SP800-56B Key Establishment Schemes
The evaluator shall verify that the TSS describes whether the TOE acts as a sender, a recipient, or both for RSA-based key establishment schemes.
If the TOE acts as a sender, the following evaluation activity shall be performed to ensure the proper operation of every TOE supported combination of RSA-based key establishment scheme:
If the TOE acts as a receiver, the following evaluation activities shall be performed to ensure the proper operation of every TOE supported combination of RSA-based key establishment scheme:
The evaluator shall ensure that the TSS describes how the TOE handles decryption errors. In accordance with NIST Special Publication 800-56B, the TOE must not reveal the particular error that occurred, either through the contents of any outputted or logged error message or through timing variations. If KTS-OAEP is supported, the evaluator shall create separate contrived ciphertext values that trigger each of the three decryption error checks described in NIST Special Publication 800-56B section 7.2.2.3, ensure that each decryption attempt results in an error, and ensure that any outputted or logged error message is identical for each. If KTS-KEM-KWS is supported, the evaluator shall create separate contrived ciphertext values that trigger each of the three decryption error checks described in NIST Special Publication 800-56B section 7.2.3.3, ensure that each decryption attempt results in an error, and ensure that any outputted or logged error message is identical for each.
FFC Schemes using “safe-prime” groups
The evaluator shall verify the correctness of the TSF’s implementation of safe-prime groups by using a known good implementation for each protocol selected in FTP_DIT_EXT.1 that uses safe-prime groups. This test must be performed for each safe-prime group that each protocol uses.
ML-KEM Key Establishment Schemes
To test encapsulation the evaluator shall 10x input to the internal Encaps function a random 32-byte string and an encapsulation key. Verify the returned cipher text and shared secret is correct using a known good implementation. Here internal refers to the TOE’s implementation of the function ML-KEM.Encaps_internal(-,-) as described in FIPS.203.
To test decapsulation the evaluator shall 10x input to the internal Decaps function a cipher text and decapsulation key. Verify the returned shared secret is correct using a known good implementation. The tests should include a mix of valid and invalid/garbled cipher texts. Here internal refers to the TOE’s implementation of the function ML-KEM.Decaps_internal(-,-) as described in FIPS.203.The evaluator shall check that the association of the hash function with other application cryptographic functions (for example, the digital signature verification function) is documented in the TSS.
The evaluator shall verify the guidance documentation contains any information required for configuring the algorithm or size.
The TSF hashing functions can be implemented in one of two modes. The first mode is the byte-oriented mode. In this mode the TSF hashes only messages that are an integral number of bytes in length; i.e., the length (in bits) of the message to be hashed is divisible by 8. The second mode is the bit-oriented mode. In this mode the TSF hashes messages of arbitrary length. As there are different tests for each mode, an indication is given in the following sections for the bit-oriented vs. the byte-oriented test MACs. The evaluator shall perform all of the following tests for each hash algorithm implemented by the TSF and used to satisfy the requirements of this PP.
The following tests require the developer to provide access to a test application that provides the evaluator with tools that are typically not found in the production application.
None.
The evaluator shall verify the guidance documentation contains any information required for configuring the algorithm or size.
The following tests require the developer to provide access to a test application that provides the evaluator with tools that are typically not found in the production application.
None.
The evaluator shall verify the guidance documentation contains any information required for configuring the algorithm or size.
The following tests require the developer to provide access to a test application that provides the evaluator with tools that are typically not found in the production application.
ECDSA Algorithm Test
RSA Signature Algorithm Test
LMS/XMSS Signature Algorithm Test
ML-DSA Test
There are no additional TSS evaluation activities for this component.
There are no additional Guidance evaluation activities for this component.
The following tests are conditional based on the selections made in the SFR. The evaluator shall perform the following tests or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described.
To test the TOE's implementation of the SHAKE Extendable Output Function, the evaluator shall perform the Algorithm Functional Test, Monte Carlo Test, and Variable Output Test using the following input parameters:
Algorithm Functional Test
Monte Carlo Test
Range = maxOutBytes - minOutBytes + 1
OutputLen = maxOutBytes
For j = 0 to 99
MD[0] = SEED
For i = 1 to 1000
MSG[i] = 128 leftmost bits of MD[i-1]
if (MSG[i] < 128 bits)
Append 0 bits on rightmost side of MSG[i] until MSG[i] is 128 bits
MD[i] = SHAKE(MSG[i], OutputLen * 8)
RightmostOutputBits = 16 rightmost bits of MD[i] as an integer
OutputLen = minOutBytes + (RightmostOutputBits % Range)
Output MD[1000], OutputLen
SEED = MD[1000]Variable Output Test
Conditional: If AES-GCM is selected, the evaluator shall verify the tag length is described in the TSS and that a tag length of at least 128 is used unless the following "Appendix C: Requirements and Guidelines for Using Short Tags" is being followed from NIST SP 800-38D.
The evaluator checks the guidance documents to determine that any configuration that is required to be done to configure the functionality for the required modes and key size is present.
The evaluator shall perform all of the following tests for each algorithm implemented by the TSF and used to satisfy the requirements of this PP:
AES-CBC Known Answer Tests
There are four Known Answer Tests (KATs), described below. In all KATs, the plaintext, ciphertext, and IV values shall be 128-bit blocks. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation.
KAT-1. To test the encrypt functionality of AES-CBC, the evaluator shall supply a set of 5 plaintext values and obtain the ciphertext value that results from AES-CBC encryption of the given plaintext using a key value of all zeros and an IV of all zeros. Five plaintext values shall be encrypted with a 256-bit all- zeros key. To test the decrypt functionality of AES-CBC, the evaluator shall perform the same test as for encrypt, using 10 ciphertext values as input and AES-CBC decryption.
KAT-2. To test the encrypt functionality of AES-CBC, the evaluator shall supply a set of 5 key values and obtain the ciphertext value that results from AES-CBC encryption of an all-zeros plaintext using the given key value and an IV of all zeros. The keys shall be 256-bit keys. To test the decrypt functionality of AES-CBC, the evaluator shall perform the same test as for encrypt, using an all-zero ciphertext value as input and AES-CBC decryption.
KAT-3. To test the encrypt functionality of AES-CBC, the evaluator shall supply the set of key values described below and obtain the ciphertext value that results from AES encryption of an all-zeros plaintext using the given key value and an IV of all zeros. The set of keys shall have 256-bit keys. Key i in each set shall have the leftmost i bits be ones and the rightmost N-i bits be zeros, for i in [1,N]. To test the decrypt functionality of AES-CBC, the evaluator shall supply the sets of key and ciphertext value pairs described below and obtain the plaintext value that results from AES-CBC decryption of the given ciphertext using the given key and an IV of all zeros. The set of key/ciphertext pairs shall have 256-bit key/ciphertext pairs. Key i in each set shall have the leftmost i bits be ones and the rightmost N-i bits be zeros, for i in [1,N]. The ciphertext value in each pair shall be the value that results in an all-zeros plaintext when decrypted with its corresponding key.
KAT-4. To test the encrypt functionality of AES-CBC, the evaluator shall supply the set of 128 plaintext values described below and obtain the ciphertext values that result from AES-CBC encryption of the given plaintext using a 256-bit key value of all zeros with an IV of all zeros. Plaintext value i in each set shall have the leftmost i bits be ones and the rightmost 128-i bits be zeros, for i in [1,128].
To test the decrypt functionality of AES-CBC, the evaluator shall perform the same test as for encrypt, using ciphertext values of the same form as the plaintext in the encrypt test as input and AES-CBC decryption.
AES-CBC Multi-Block Message Test
The evaluator shall test the encrypt functionality by encrypting an i-block message where 1 < i <= 10. The evaluator shall choose a key, an IV and plaintext message of length i blocks and encrypt the message, using the mode to be tested, with the chosen key and IV. The ciphertext shall be compared to the result of encrypting the same plaintext message with the same key and IV using a known good implementation. The evaluator shall also test the decrypt functionality for each mode by decrypting an i-block message where 1 < i <=10. The evaluator shall choose a key, an IV and a ciphertext message of length i blocks and decrypt the message, using the mode to be tested, with the chosen key and IV. The plaintext shall be compared to the result of decrypting the same ciphertext message with the same key and IV using a known good implementation.
AES-CBC Monte Carlo Tests
The evaluator shall test the encrypt functionality using a set of 100 plaintext, IV, and key 3-tuples. 100 of these shall use shall use 256-bit keys. The plaintext and IV values shall be 128-bit blocks. For each 3-tuple, 1000 iterations shall be run as follows:
# Input: PT, IV, Key
for i = 1 to 1000:
if i == 1:
CT[1] = AES-CBC-Encrypt(Key, IV, PT)
PT = IV
else:
CT[i] = AES-CBC-Encrypt(Key, PT)
PT = CT[i-1]The ciphertext computed in the 1000th iteration (i.e., CT[1000]) is the result for that trial. This result shall be compared to the result of running 1000 iterations with the same values using a known good implementation.
The evaluator shall test the decrypt functionality using the same test as for encrypt, exchanging CT and PT and replacing AES-CBC-Encrypt with AES-CBC-Decrypt.
AES-GCM Monte Carlo Tests
The evaluator shall test the authenticated encrypt functionality of AES-GCM for each combination of the following input parameter lengths:
256-bit keys
Two plaintext lengths. One of the plaintext lengths shall be a non-zero integer multiple of 128 bits, if supported. The other plaintext length shall not be an integer multiple of 128 bits, if supported.
Three AAD lengths. One AAD length shall be 0, if supported. One AAD length shall be a non-zero integer multiple of 128 bits, if supported. One AAD length shall not be an integer multiple of 128 bits, if supported.
Two IV lengths. If 96 bit IV is supported, 96 bits shall be one of the two IV lengths tested.
The evaluator shall test the encrypt functionality using a set of 10 key, plaintext, AAD, and IV tuples for each combination of parameter lengths above and obtain the ciphertext value and tag that results from AES-GCM authenticated encrypt. Each supported tag length shall be tested at least once per set of 10. The IV value may be supplied by the evaluator or the implementation being tested, as long as it is known.
The evaluator shall test the decrypt functionality using a set of 10 key, ciphertext, tag, AAD, and IV 5-tuples for each combination of parameter lengths above and obtain a Pass/Fail result on authentication and the decrypted plaintext if Pass. The set shall include five tuples that Pass and five that Fail.
The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation.
AES-XTS Tests
The evaluator shall test the encrypt functionality of XTS-AES for each combination of the following input parameter lengths:
512 bit (for AES-256) keys
Three data unit (i.e., plaintext) lengths. One of the data unit lengths shall be a non-zero integer multiple of 128 bits, if supported. One of the data unit lengths shall not be an integer multiple of 128 bits, if supported. The third data unit length shall be either the longest supported data unit length or 216 bits, whichever is smaller.
Using a set of 100 (key, plaintext and 128-bit random tweak value) 3-tuples, the evaluator shall obtain the ciphertext that results from XTS-AES encrypt.
The evaluator may supply a data unit sequence number instead of the tweak value if the implementation supports it. The data unit sequence number is a base-10 number ranging between 0 and 255 that implementations convert to a tweak value internally.
The evaluator shall test the decrypt functionality of XTS-AES using the same test as for encrypt, replacing plaintext values with ciphertext values and XTS-AES encrypt with XTS-AES decrypt.
AES-CCM Tests
It is not recommended that evaluators use values obtained from static sources such as http://csrc.nist.gov/groups/STM/cavp/documents/mac/ccmtestvectors.zip or use values not generated expressly to exercise the AES-CCM implementation.
The evaluator shall test the generation-encryption and decryption-verification functionality of AES-CCM for the following input parameter and tag lengths:
Keys: All supported and selected key sizes (e.g., 256 bits).
Associated Data: Two or three values for associated data length: The minimum (≥ 0 bytes) and maximum (≤ 32 bytes) supported associated data lengths, and 2^16 (65536) bytes, if supported.
Payload: Two values for payload length: The minimum (≥ 0 bytes) and maximum (≤ 32 bytes) supported payload lengths.
Nonces: All supported nonce lengths (7, 8, 9, 10, 11, 12, 13) in bytes.
Tag: All supported tag lengths (4, 6, 8, 10, 12, 14, 16) in bytes.
The testing for CCM consists of five tests. To determine correctness in each of the below tests, the evaluator shall compare the ciphertext with the result of encryption of the same inputs with a known good implementation.
Variable Associated Data Test
For each supported key size and associated data length, and any supported payload length, nonce length, and tag length, the evaluator shall supply one key value, one nonce value, and 10 pairs of associated data and payload values, and obtain the resulting ciphertext.
Variable Payload Test
For each supported key size and payload length, and any supported associated data length, nonce length, and tag length, the evaluator shall supply one key value, one nonce value, and 10 pairs of associated data and payload values, and obtain the resulting ciphertext.
Variable Nonce Test
For each supported key size and nonce length, and any supported associated data length, payload length, and tag length, the evaluator shall supply one key value, one nonce value, and 10 pairs of associated data and payload values, and obtain the resulting ciphertext.
Variable Tag Test
For each supported key size and tag length, and any supported associated data length, payload length, and nonce length, the evaluator shall supply one key value, one nonce value, and 10 pairs of associated data and payload values, and obtain the resulting ciphertext.
Decryption-Verification Process Test
To test the decryption-verification functionality of AES-CCM, for each combination of supported associated data length, payload length, nonce length, and tag length, the evaluator shall supply a key value and 15 sets of input plus ciphertext, and obtain the decrypted payload. Ten of the 15 input sets supplied should fail verification and five should pass.
AES-CTR Tests
Test 1: Known Answer Tests (KATs)
There are four Known Answer Tests (KATs) described below. For all KATs, the plaintext, IV, and ciphertext values shall be 128-bit blocks. The results from each test may either be obtained by the validator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation.
KAT-1. To test the encrypt functionality, the evaluator shall supply a set of 5 plaintext values and obtain the ciphertext value that results from encryption of the given plaintext using a key value of all zeros and an IV of all zeros. Five plaintext values shall be encrypted with a 256-bit all zeros key. To test the decrypt functionality, the evaluator shall perform the same test as for encrypt, using 5 ciphertext values as input.
KAT-2. To test the encrypt functionality, the evaluator shall supply a set of 5 key values and obtain the ciphertext value that results from encryption of an all zeros plaintext using the given key value and an IV of all zeros. Five of the key values shall be 256-bit keys. To test the decrypt functionality, the evaluator shall perform the same test as for encrypt, using an all zero ciphertext value as input.
KAT-3. To test the encrypt functionality, the evaluator shall supply the key values described below and obtain the ciphertext values that result from AES encryption of an all zeros plaintext using the given key values an an IV of all zeros. The set of keys shall have 256 256-bit keys. Key_i shall have the leftmost i bits be ones and the rightmost N-i bits be zeros, for i in [1, N]. To test the decrypt functionality, the evaluator shall supply the key and ciphertext value pairs described below and obtain the plaintext value that results from decryption of the given ciphertext using the given key values and an IV of all zeros. The first set of key/ciphertext pairs shall have 256 256-bit pairs. Key_i shall have the leftmost i bits be ones and the rightmost N-i bits be zeros for i in [1, N]. The ciphertext value in each pair shall be the value that results in an all zeros plaintext when decrypted with its corresponding key.
KAT-4. To test the encrypt functionality, the evaluator shall supply the set of 128 plaintext values described below and obtain the ciphertext values that result from encryption of the given plaintext using a 256-bit key value of all zeros, and an IV of all zeros. Plaintext value i in each set shall have the leftmost bits be ones and the rightmost 128-i bits be zeros, for i in [1, 128]. To test the decrypt functionality, the evaluator shall perform the same test as for encrypt, using ciphertext values of the same form as the plaintext in the encrypt test as input.
Test 2: Multi-Block Message Test
The evaluator shall test the encrypt functionality by encrypting an i-block message where 1 less-than i less-than-or-equal to 10. For each i the evaluator shall choose a key, IV, and plaintext message of length i blocks and encrypt the message, using the mode to be tested, with the chosen key. The ciphertext shall be compared to the result of encrypting the same plaintext message with the same key and IV using a known good implementation. The evaluator shall also test the decrypt functionality by decrypting an i-block message where 1 less-than i less-than-or-equal to 10. For each i the evaluator shall choose a key and a ciphertext message of length i blocks and decrypt the message, using the mode to be tested, with the chosen key. The plaintext shall be compared to the result of decrypting the same ciphertext message with the same key using a known good implementation.
Test 3: Monte-Carlo Test
For AES-CTR mode, perform the Monte Carlo Test for ECB Mode on the encryption engine of the counter mode implementation. There is no need to test the decryption engine.
The evaluator shall test the encrypt functionality using 100 plaintext/key pairs. 100 of these shall use 256-bit keys. The plaintext values shall be 128-bit blocks. For each pair, 1000 iterations shall be run as follows:
For AES-ECB mode # Input: PT, Key for i = 1 to 1000: CT[i] = AES-ECB-Encrypt(Key, PT) PT = CT[i]
The ciphertext computed in the 1000th iteration is the result for that trial. This result shall be compared to the result of running 1000 iterations with the same values using a known good implementation.
The evaluator shall examine the TSS to verify that it describes the TSF's HTTPS implementation as a client, server, or both, and that if the TSF implements an HTTPS server, whether this supports mutual authentication. Additionally, the evaluator shall examine the TSS to verify that it includes enough detail is provided to explain how the implementation complies with RFC 2818.
The evaluator shall review the operational guidance to ensure that it includes any information necessary for configuring HTTPS in alignment with RFC 2818, or whether this is the default behavior of the TOE.
The evaluator shall attempt to establish an HTTPS connection using the TOE, present an invalid peer certificate, and verify that the TSF behaves in the manner specified in the TSF in response. If this behavior is configurable, the evaluator shall iterate this test as necessary to exercise each configuration option and verify that the TSF behaves in the configured manner.
Other tests are performed in conjunction with the Functional Package for Transport Layer Security (TLS), version 2.1 and the Functional Package for X.509.
Support for PBKDF: The evaluator shall examine the password hierarchy described in the TSS to ensure that the formation of all password based derived keys is described and that the key sizes match that described by the ST author. The evaluator shall check that the TSS describes the method by which the password/passphrase is first encoded and then fed to the SHA algorithm. The settings for the algorithm (padding, blocking, etc.) shall be described, and the evaluator shall verify that these are supported by the selections in this component as well as the selections concerning the hash function itself. The evaluator shall verify that the TSS contains a description of how the output of the hash function is used to form the submask that will be input into the function. For the NIST SP 800-132-based conditioning of the password/passphrase, the required evaluation activities will be performed when doing the evaluation activities for the appropriate requirements (FCS_COP.1.1/KeyedHash). No explicit testing of the formation of the submask from the input password is required. FCS_PBKDF_EXT.1: The evaluator shall verify the TSS describes the salt size and verify that the salt size aligns with NIST SP 800-132 with a minimum random length of 128 bits.
The evaluator shall confirm the guidance documentation contains any information necessary for configuring the password conditioning if any configuration is supported.
The evaluator shall perform the following tests:
The evaluator shall perform 15 trials for the DRBG implementation. If the DRBG is configurable, the evaluator shall perform 15 trials for each configuration. The evaluator shall also confirm that the operational guidance contains appropriate instructions for configuring the DRBG functionality.
If the DRBG has prediction resistance enabled, each trial consists of (1) instantiate DRBG, (2) generate the first block of random bits (3) generate a second block of random bits (4) uninstantiate. The evaluator verifies that the second block of random bits is the expected value. The evaluator shall generate eight input values for each trial. The first is a count (0 – 14). The next three are entropy input, nonce, and personalization string for the instantiate operation. The next two are additional input and entropy input for the first call to generate. The final two are additional input and entropy input for the second call to generate. These values are randomly generated. "generate one block of random bits" means to generate random bits with number of returned bits equal to the Output Block Length (as defined in NIST SP 800-90A).
If the DRBG does not have prediction resistance, each trial consists of (1) instantiate DRBG, (2) generate the first block of random bits (3) reseed, (4) generate a second block of random bits (5) uninstantiate. The evaluator verifies that the second block of random bits is the expected value. The evaluator shall generate eight input values for each trial. The first is a count (0 – 14). The next three are entropy input, nonce, and personalization string for the instantiate operation. The fifth value is additional input to the first call to generate. The sixth and seventh are additional input and entropy input to the call to reseed. The final value is additional input to the second generate call.
The following list contains more information on some of the input values to be generated/selected by the evaluator.
If salts are used, the evaluator shall ensure the TSS describes how salts are generated. The evaluator shall confirm that the salt is generating using an RBG described in FCS_RBG_EXT.1.
If nonces are used the evaluator shall ensure the TSS describes how nonces are created verify they are a minimum of 64 bits in size.If initialization vectors (IV) are used the evaluator shall ensure the TSS describes how IVs and tweaks are handled based on the AES mode. The evaluator shall confirm that the IVs and tweaks meet the stated requirements for each AES mode.If using a GCM IV, the evaluator shall confirm the TSS describes the GCM IV construction and that it matches one of two allowed construction methods given in Section 8.2 of SP800-38D.None.
The evaluator shall examine the TSS to ensure that it details the self-tests that are run by the TSF along with how they are run. This description should include an outline of what the tests are actually doing. The evaluator shall ensure that the TSS makes an argument that the tests are sufficient to demonstrate that the DRBG is operating correctly.
Note that this information may also be placed in the entropy documentation specified by Appendix D - Entropy Documentation and Assessment.If a self-test can be executed at the request of an authorized user, the evaluator shall verify that the operational guidance provides instructions on how to execute that self-test.
For each self-test, the evaluator shall verify that evidence is produced that the self-test is executed when specified by FPT_TST.1.1.
If a self-test can be executed at the request of an authorized user, the evaluator shall verify that following the steps documented in the operational guidance to perform the self-test will result in execution of the self-test.
The evaluator shall verify that the TSS describes how the application is distributed and verify that description aligns with the selections in the ST.
None.
RPM format. Applications running on Debian and Debian derivatives shall be packaged in DEB format.
None.
The evaluator shall verify the guidance documentation details how uninstallation of the application is performed.
For all other platforms, the evaluator shall record the path of every file on the entire file system prior to installation of the application, and then install and run the application. Afterward, the evaluator shall uninstall the application, and compare the resulting file system to the initial record to verify that no files, other than configuration, output, and audit or log files, have been added to the file system.
The evaluator shall verify that the TSS identifies how the application installation package is signed by an authorized source. The definition of an authorized source must be contained in the TSS.
None.
The evaluator shall verify that the TSS lists any IANA MIME media types (as described by http://www.iana.org/assignments/media-types) for all formats the application processes and that it maps those formats to parsing services provided by the platform.
The API shall be verified in FPT_API_EXT.1.None.
None.
The evaluator shall examine the TSS to verify that it identifies each non-network local inter-process communication mechanism covered by this objective, the Communication Relationship Type and TOE Component Instances it serves, and the assigned protection. The TSS shall describe how the applicable base cPP requirements, platform access controls, object permissions, isolation mechanisms, configuration controls, or operational guidance protect the communication path and restrict access to authorized TOE Component Instances.
Where operational guidance is relied upon as the assigned protection, the evaluator shall verify that it contains all instructions needed to configure that protection.
None.
None.
None.
Some of the contents of the operational guidance will be verified by the evaluation activities in Section 5.1 Security Functional Requirements and evaluation of the TOE according to the [CEM]. The following additional information is also required.
If cryptographic functions are provided by the TOE, the operational guidance shall contain instructions for configuring the cryptographic engine associated with the evaluated configuration of the TOE. It shall provide a warning to the administrator that use of other cryptographic engines was not evaluated nor tested during the CC evaluation of the TOE.The documentation must describe the process for verifying updates to the TOE by verifying a digital signature – this may be done by the TOE or the underlying platform.The evaluator shall verify that this process includes the following steps:The evaluator shall ensure that the developer has identified (in guidance documentation for application developers concerning the targeted platform) one or more development environments appropriate for use in developing applications for the developer’s platform. For each of these development environments, the developer shall provide information on how to configure the environment to ensure that buffer overflow protection mechanisms in the environment(s) are invoked (e.g., compiler flags). The evaluator shall ensure that this documentation also includes an indication of whether such protections are on by default, or have to be specifically enabled. The evaluator shall ensure that the TSF is uniquely identified (with respect to other products from the TSF vendor), and that documentation provided by the developer in association with the requirements in the ST is associated with the TSF using this unique identification.
The evaluator shall inspect the guidance document and verify it describes how to access the flaw remediation guidance.
The evaluator shall inspect the guidance document and verify it describes how to access the flaw remediation guidance.
The evaluator shall verify that the TSS contains a description of the timely security update process used by the developer to create and deploy security updates. The evaluator shall verify that this description addresses the entire application. The evaluator shall also verify that, in addition to the TOE developer’s process, any third-party processes are also addressed in the description. The evaluator shall also verify that each mechanism for deployment of security updates is described.
The evaluator shall verify that, for each deployment mechanism described for the update process, the TSS lists a time between public disclosure of a vulnerability and public availability of the security update to the TOE patching this vulnerability, to include any third-party or carrier delays in deployment. The evaluator shall verify that this time is expressed in a number or range of days.The evaluator shall verify that this description includes the publicly available mechanisms (including either an email address or website) for reporting security issues related to the TOE. The evaluator shall verify that the description of this mechanism includes a method for protecting the report either using a public key for encrypting email or a trusted channel for a website.Component implementation-equivalence classes for distributed TOEs. For a distributed TOE, the evaluator shall verify that the ST identifies each TOE Component and security-relevant configuration, where applicable; maps each TOE Component and configuration to the applicable SFR iteration or iterations; and identifies each Component Implementation-Equivalence Class for which evidence reuse is claimed. The evaluator shall verify that the ST separately identifies the interfaces and Communication Relationship Types required by the applicable SFRs. The ST need not contain a component-to-Evaluation-Activity mapping.
The evaluator shall examine an implementation-equivalence rationale, which may be provided separately from the ST. The rationale shall identify the class members; the SFR iterations and exact implementation-specific Evaluation Activity paragraphs or test identifiers for which reuse is proposed; the common security-relevant implementation and version, wrapper or integration behavior, build options, implementation configuration and values relevant to the reused activities, role and exercised code path, cryptographic provider where applicable, and immediate platform services and interfaces relevant to the reused activities; and any peripheral differences reasonably capable of affecting the scoped results. The evaluator shall verify that the rationale explains why each identified peripheral difference cannot affect those results. Different security-relevant implementations, versions, providers, wrapper or integration behavior, build options, implementation configurations or values that affect the reused activities, roles, exercised code paths, or relevant platform services and interfaces shall not be placed in the same class for the affected scope. Channel-specific certificates, keys, trust-anchor values, endpoint identities, addresses, and similar deployed values may differ when they do not alter the reused implementation behavior and are covered by the retained interface- or channel-specific activities.
The evaluator shall examine objective evidence for every claimed class member, such as artifact identifiers or hashes, dependency manifests, software bills of materials, build records, configuration records, or observed invocation paths, and shall determine whether the claimed membership is substantiated. A shared base image, runtime, library name, source repository, or build pipeline alone is not sufficient to establish class membership.
Class membership shall be re-established when a member's security-relevant implementation version, provider, wrapper or integration behavior, relevant build options, relevant configuration, platform service or interface, or exercised code path changes. Image, runtime, or orchestrator differences that are outside the scope of a Running-Payload Activity shall be evaluated at their own stated layer; when such a difference can affect the scoped running-payload result, it is also a class-relevant difference.
The evaluator shall prepare a test plan and report documenting the testing aspects of the system, including any application crashes during testing. The evaluator shall determine the root cause of any application crashes and include that information in the report. The test plan covers all of the testing actions contained in the [CEM] and the body of this PP’s evaluation activities.
While it is not necessary to have one test case per test listed in an evaluation activity, the evaluator must document in the test plan that each applicable testing requirement in the ST is covered. The test plan identifies the platforms to be tested, and for those platforms not included in the test plan but included in the ST, the test plan provides a justification for not testing the platforms. This justification must address the differences between the tested platforms and the untested platforms, and make an argument that the differences do not affect the testing to be performed. It is not sufficient to merely assert that the differences have no effect; rationale must be provided. If all platforms claimed in the ST are tested, then no rationale is necessary. The test plan describes the composition of each platform to be tested, and any setup that is necessary beyond what is contained in the AGD documentation. It should be noted that the evaluator is expected to follow the AGD documentation for installation and setup of each platform either as part of a test or as a standard pre-test condition. This may include special test drivers or tools. For each driver or tool, an argument (not just an assertion) should be provided that the driver or tool will not adversely affect the performance of the functionality by the TOE and its platform.
This also includes the configuration of the cryptographic engine to be used. The cryptographic algorithms implemented by this engine are those specified by this PP and used by the cryptographic protocols being evaluated (e.g., SSH). The test plan identifies high-level test objectives as well as the test procedures to be followed to achieve those objectives. These procedures include expected results.
General guidance for Linux-container application payloads. For a Running-Payload Activity, the evaluator may perform the specified Linux procedure by invoking a command in a container shell when one is present, by using a runtime-supported execution facility in the payload's namespaces, by applying namespace-aware external instrumentation, or by using an equivalent non-invasive method. The method shall examine the exact evaluated component artifact and deployed configuration. When the activity concerns process behavior or effective permissions, the evaluator shall examine the actual TOE process. An auxiliary or reproduced process may be used for a particular observation only when the evaluator demonstrates that it is equivalent to the TOE process for the exact property being measured, including the relevant user and group identifiers, Linux capabilities, security profile, mounts, environment, and namespaces.
The evaluator shall not modify the evaluated image or grant a privilege, capability, mount, or access path that is absent from the evaluated deployment merely to make a test convenient. A diagnostic or ephemeral container, host-side namespace entry, or other external tool may be used for a distroless or minimal image when the evaluator documents why the tool does not alter the TOE artifact, deployed TOE configuration, or behavior being measured. Such tooling is not part of the TOE. Offline inspection of the exact evaluated image may be used for a static property, but it does not replace observation of running behavior when the activity requires execution.
This method allowance applies only to the Running-Payload Activity portion of an Evaluation Activity. It does not satisfy or make inapplicable examination or testing whose subject is image or package identity and authorized-source signature, image composition or software inventory, installation, update or removal lifecycle, runtime or orchestrator configuration or dependency, mounted or injected data at its source, network policy, or an externally exposed interface or protected channel. Each such portion shall be performed at the artifact, platform, lifecycle, configuration, interface, or channel layer stated by the activity. For FPT_TUD_EXT.1 and FPT_TUD_EXT.2, a running-payload version query or observation of executable-change behavior may use this method when called for by the activity; authorized-source, signature or integrity verification, delivery, installation or replacement, and removal checks remain applicable for every distinct update artifact and path at their stated scope. Any supported rollback behavior shall be documented and evaluated only to the extent required by a completed SFR or applicable Evaluation Activity.
The evaluator shall preserve all repetitions and coverage required by the originating activity. One interactive shell session does not satisfy a requirement to exercise multiple systems, configurations, TOE Components, TOE Component Instances, artifacts, interfaces, or channels. The Running-Payload Activity shall be performed using at least one exact TOE Component Instance representing every applicable TOE Component and each of its identified security-relevant configurations, where applicable. It need not be repeated solely for additional Runtime Replicas unless the originating activity expressly requires every deployed instance to be examined or tested. The same execution may be cited for mapped SFR Implementation Instances in a substantiated Component Implementation-Equivalence Class as permitted below.
Representative execution for distributed TOEs. When a Component Implementation-Equivalence Class has been substantiated, the test plan shall identify the exact implementation-specific Evaluation Activity paragraphs or test identifiers proposed for representative execution and shall map the class to those activities. The evaluator shall select one or more representative class-member SFR Implementation Instances and, for each, an exact deployed TOE Component Instance through which it will be exercised. The selected SFR Implementation Instances and deployed TOE Component Instances shall collectively expose all behavior relevant to the identified activities. If they do not, the evaluator shall require additional execution or determine that the proposed class is not substantiated for that scope.
The evaluator may cite an implementation-specific execution performed on a selected TOE Component Instance for every mapped class member covered by the representative SFR Implementation Instance. Representative execution eliminates only duplicate execution of the same implementation-specific activity across class members. It does not reduce any test count, parameter combination, supported algorithm, protocol role, configuration, certificate case, negative test, interface, channel, communication relationship, or end-to-end coverage required by the originating Evaluation Activity, including an activity incorporated from a PP-Module or Functional Package. Any interface-specific, channel-specific, artifact-specific, or deployment-specific portion shall be performed at its stated scope.
For example, the complete protocol-implementation test suite for multiple TOE Components or identified security-relevant configurations that use the same substantiated TLS implementation may be executed on one or more selected TOE Component Instances that exercise representative mapped SFR Implementation Instances. Connection establishment, deployed credentials, trust configuration, endpoint identity, traffic protection, interruption and recovery, and other interface- or channel-specific behavior shall still be checked for each distinct interface or channel as required by the applicable activity. All protocol versions, algorithms, certificate cases, negative cases, and other internal repetitions required by the TLS activity shall be exercised on the selected TOE Component Instance or instances.
The test report shall identify each class, its members, the membership evidence examined, the representative SFR Implementation Instance or instances selected, the exact deployed TOE Component Instances used for execution, the activities performed, the repetitions not performed, and the interface-, channel-, artifact-, configuration-, and end-to-end checks performed separately. The report shall preserve a coverage mapping and separate verdict for every applicable SFR and Evaluation Activity.
The test report (which could just be an annotated version of the test plan) details the activities that took place when the test procedures were executed, and includes the actual results of the tests. This shall be a cumulative account, so if there was a test run that resulted in a failure; a fix installed; and then a successful re-run of the test, the report would show a “fail” and “pass” result (and the supporting details), and not just the “pass” result.
The evaluator shall generate a report to document their findings with respect to this requirement. This report could physically be part of the overall test report mentioned in ATE_IND, or a separate document. The evaluator performs a search of public information to find vulnerabilities that have been found in similar applications with a particular focus on network protocols the application uses and document formats it parses.
The evaluator documents the sources consulted and the vulnerabilities found in the report.For each vulnerability found, the evaluator either provides a rationale with respect to its non-applicability, or the evaluator formulates a test (using the guidelines provided in ATE_IND) to confirm the vulnerability, if suitable. Suitability is determined by assessing the attack vector needed to take advantage of the vulnerability. If exploiting the vulnerability requires expert skills and an electron microscope, for instance, then a test would not be suitable and an appropriate justification would be formulated.This Supporting Document has no required supplementary information beyond the ST, operational guidance, and testing.
| Identifier | Title |
|---|---|
| [CC] | Common Criteria for Information Technology Security Evaluation -
|
| [OMB] | Reporting Incidents Involving Personally Identifiable Information and Incorporating the Cost for Security in Agency Information Technology Investments, OMB M-06-19, July 12, 2006. |
| [SHAKE] | SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions, NIST FIPS PUB 202, August 2015. |
| [TD0994] | NIAP Technical Decision TD0994: Addition of FCS_COP.1/XOF to PP_APP_V2.0, May 13, 2026. |