Version: 2.0
2026-07-21
Application Software International Technical Community (AppSW-iTC)
| 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. |
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 requirements in this document apply to application software which runs on any type of platform. Some application types are covered by more specific PPs, which may be expressed as PP-Modules of this PP. Such applications are subject to the requirements of both this PP and the PP-Module that addresses their special functionality. PPs for some particularly specialized applications may not be expressed as PP-Modules at this time, though the requirements in this document should be seen as objectives for those highly specialized applications.
Although the requirements in this document apply to a wide range of application software, consult guidance from the relevant national schemes to determine when formal Common Criteria evaluation is expected for a particular type of application. This may vary depending upon the nature of the security functionality of the application.The TOE consists of the vendor-provided application component or components identified in the ST. It may be installed or deployed on one or more platforms and may execute as a single application or as multiple cooperating components. A platform may be an operating system (Figure 1), hardware environment, software-based execution environment, or some combination of these (Figure 2). A platform may itself operate within a virtualized or layered environment that abstracts underlying hardware or platform services from the TOE. Functionality provided by an abstracted layer is part of the operational environment unless the ST explicitly includes that layer in the TOE. The ST shall identify any operational environment service upon which the TOE relies to satisfy a security requirement and the configuration required of that service.
Some evaluation activities are specific to the platform on which an application component runs in order to provide precision and repeatability. The platforms currently recognized by this cPP are those specified in the SFR Evaluation Activities. To test on a platform for which there are no applicable evaluation activities, an interested party may contact the AppSW-iTC with proposed activities. The AppSW-iTC will determine whether the proposed platform is appropriate for the cPP and accept, reject, or develop evaluation activities as necessary in coordination with the technical community.
This cPP applies to application software regardless of its function, delivery mechanism, or deployment topology. Application software may provide an interactive client, a background or server-side service, or a set of containerized or otherwise distributed application payloads. It may be delivered as a native or mobile package, container image, deployment bundle, or other application artifact. Delivery, packaging, and deployment topology do not by themselves determine the TOE boundary.
The TOE boundary shall include every vendor-provided software component that implements or supports a claimed SFR, as well as any additional vendor-provided components explicitly included in the ST. Such components may include user-space processes, libraries, services, sidecars, drivers, and other platform extensions. Platform-provided firmware, operating-system kernels and drivers, runtimes, orchestrators, and other system services are part of the operational environment unless explicitly included in the TOE. Co-packaging or co-deployment with the application does not by itself change that classification. Additional requirements for TOEs comprising separately deployed components are defined in Section 1.5 Distributed and Microservices TOE Architectures.
Some applications rely on managed runtimes or application frameworks to execute application code or to provide security-relevant services. A managed runtime or application framework is not automatically considered a platform equivalent to an operating system. The ST shall identify whether each security-relevant managed runtime or application framework is included in the TOE, bundled with the TOE, provided by the operational environment, or relied upon as a platform or operational environment dependency.
If a managed runtime or application framework is included in the TOE boundary, the ST shall identify it and address its security-relevant configuration, update mechanism, invoked APIs, included libraries, and any security-relevant services it provides to the application. If a runtime or framework is delivered or deployed with the TOE but remains outside the TOE boundary, or is otherwise provided by the operational environment, the ST shall identify the dependency and the guidance shall describe the environmental configuration required for the TOE's claimed security functionality.
Security-relevant managed runtime or application framework behavior includes, but is not limited to, code loading, classpath or module path processing, just-in-time compilation, native interface exposure, reflection, object serialization or deserialization, object binding, routing, authentication, authorization, session management, management or debug interfaces, management endpoints, cryptographic provider selection, trust store behavior, configuration loading, and interpretation of environment variables or external configuration sources. The evaluator shall assess these behaviors through the applicable SFR assurance activities rather than treating the runtime or framework as opaque implementation detail.
A TOE may consist of multiple TOE Components that collectively provide the TOE security functionality. A TOE Component is 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 Instance is a deployed occurrence of a TOE Component. Examples include server-agent products, clustered application deployments, and microservices-based applications composed of multiple application payloads. If a TOE is deployed across multiple TOE Component Instances, the ST shall identify each TOE Component and its permitted instance or scaling topology, including any Runtime Replicas; describe the role of each TOE Component; identify which TOE Components implement each claimed SFR or SFR element; describe every Communication Relationship Type and Protected Channel Instance required by the applicable Evaluation Activities; and distinguish TOE Components and their instances from operational environment components.
For containerized or microservices TOEs, the TOE consists of the application payloads and TOE-provided application components identified in the ST. Packaging does not determine the TOE boundary. A vendor-provided sidecar, init container, operator, library, userland utility, or other executable content that implements or supports a claimed SFR shall not be classified as operational environment merely because it is delivered or deployed using a container pattern. The container orchestration platform, container runtime, operating system kernel, platform service mesh infrastructure, ingress infrastructure, cluster networking, and platform-provided secret or configuration stores are part of the operational environment unless explicitly included in the TOE boundary. The PP does not require these operational environment components to be included in the TOE boundary solely because the TOE depends on them for execution, scheduling, networking, isolation, credential storage, configuration storage, or time services.
When the TOE relies on operational environment components to provide services used by the TOE, the ST shall identify the dependency and the guidance shall describe the required environmental configuration, expected service and failure behavior, and trust assumptions. An operational environment dependency may satisfy a claimed SFR only where that SFR expressly permits use of platform-provided functionality; otherwise the evaluator assesses the TOE's use of and dependency on the service, but the service does not satisfy a TOE-implemented requirement. A Communication Relationship Type is defined between TOE Components, which may be the same TOE Component, and realized by their TOE Component Instances. Communication between TOE Component Instances shall be identified in the ST. Where the TOE claims conformance to a PP-Configuration that includes Server and Agent application modules, the ST shall use the module requirements to address enablement, registration, and disablement of permitted communication pairings among TOE Component Instances and FTP_DIT_EXT.1 to address protection of data transmitted between those instances. For each claimed requirement or element, the ST shall provide an SFR allocation rationale that separately identifies the claim condition, where relevant; the component allocation; and any operational-environment contribution expressly allowed by the requirement. Component allocation shall be All Components, At Least One Component, or Feature Dependent. A Feature Dependent SFR or element is fulfilled only where the relevant feature is implemented by a distributed TOE Component. If it is included in the ST, at least one TOE Component shall implement that feature, and the ST shall map every implementing TOE Component to the SFR element or elements it implements. Where different TOE Components implement different elements of a multi-element SFR, each TOE Component shall satisfy only its mapped elements; the mapped elements collectively satisfy the TOE-level SFR. A feature, selection, or objective condition may control inclusion, but shall not omit an implementing TOE Component from the mapping or required coverage. The TOE as a whole shall satisfy every claimed SFR. Every TOE Component Instance shall exhibit the claimed SFR behavior allocated to its TOE Component in its identified configuration.
The ST need not iterate an SFR solely because the same completed requirement applies to more than one TOE Component. A single completion of the SFR, including one iteration when needed, and a common TSS description may be mapped to multiple TOE Components when the operations and claimed security-relevant behavior are the same. The ST shall identify every mapped TOE Component and shall use separate iterations when different operations are needed to express the claims. Multiple deployed instances of the same TOE Component are Runtime Replicas when they meet the Runtime Replica definition and may be represented by that TOE Component together with its permitted instance or scaling topology. Interfaces and Communication Relationship Types shall be identified separately as required by the applicable SFRs and Evaluation Activities.
Where evidence reuse is claimed, the ST shall provide a concise mapping from each TOE Component and identified security-relevant configuration, where applicable, to its SFR iteration or iterations and implementation-equivalence class identifier. A single Component Implementation-Equivalence Class definition may list multiple SFR iterations when its member SFR Implementation Instances and equivalence basis are identical for those SFRs. The detailed rationale and the mapping from a class to the exact implementation-specific portions of Evaluation Activities for which representative execution is proposed may be provided in separate evaluation evidence and the evaluator's test plan. Class membership does not change SFR applicability, transfer compliance from one TOE Component or identified configuration to another, remove a TOE Component from the TOE boundary, or reduce interface, channel, configuration, or end-to-end coverage required by an Evaluation Activity. Component implementation equivalence and the associated evidence-reuse rules are described in Appendix F - Component Implementation Equivalence Within a Distributed TOE.
This PP includes platform-specific EAs for the below-listed operating system platforms. For "bare-metal" applications, applications that run on other OS platforms, and any aspect of a software-based execution environment not covered by the limited Linux-container Running-Payload mapping below, contact the Technical Community for guidance.
For Evaluation Activity applicability, a TOE application payload executing in a Linux container shall be treated as the Linux platform case for each platform-specific Evaluation Activity whose subject is the running Linux userspace behavior of that payload, and the evaluator shall apply the Linux method to that Running-Payload Activity. This limited mapping does not establish Product Equivalence or Platform Equivalence and does not make any other activity inapplicable. Activity portions whose subject is image or package identity and authorized-source signature, image composition, installation, update or removal workflow, runtime or orchestrator configuration, mounts, networking, or an external interface or channel remain applicable at the artifact, platform, lifecycle, interface, or channel layer stated by the activity. The Supporting Document provides permitted methods and coverage rules for Running-Payload Activities.
This PP defines no Organizational Security Policies.
| Assumption or OSP | Security Objectives | Rationale |
| A.PLATFORM | OE.PLATFORM | The operational environment objective OE.PLATFORM is realized through A.PLATFORM. |
| A.PROPER_ADMIN | OE.PROPER_ADMIN | The operational environment objective OE.PROPER_ADMIN is realized through A.PROPER_ADMIN. |
| A.PROPER_USER | OE.PROPER_USER | The operational environment objective OE.PROPER_USER is realized through A.PROPER_USER. |
The selection "invoke platform-provided DRBG functionality" should only be chosen for direct invocations of the platform DRBG by the TSF.
The selection "use no DRBG functionality" is chosen when the TSF calls a platform implementation of a function that subsequently calls a platform-provided DRBG itself, because this is not a direct invocation of the platform DRBG by the TSF.If "implement DRBG functionality" is selected, FCS_RBG.1 must be claimed for the DRBG mechanism, and FPT_TST.1 and FPT_FLS.1 must be claimed for the self-testing and error handling of this mechanism.In this requirement, cryptographic operations include all cryptographic key generation/derivation/agreement, IVs (for certain modes), as well as protocol-specific random values. Cryptographic operations in this requirement refer to the other cryptographic requirements in this PP, not additional functionality that is not in scope.If "implement functionality to encrypt sensitive data as defined in the PP-Module for File Encryption" is selected, the TSF must claim conformance to a PP-Configuration that includes the PP-Module for File Encryption.
Any file that may potentially contain sensitive data (to include temporary files) shall be protected. The only exception is if the user intentionally exports the sensitive data to non-protected files. ST authors should select "protect sensitive data in accordance with FCS_STO_EXT.1" for the sensitive data that is covered by the FCS_STO_EXT.1 SFR.Configuration options that are stored remotely are not subject to this requirement. Sensitive Data is generally not considered part of configuration options and should be stored according to FDP_DAR_EXT.1 or FCS_STO_EXT.1.
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 TSF must claim conformance to a PP-Configuration that includes the PP-Module for File Encryption.For managed runtime or application framework based TOEs, configuration options include security-relevant runtime or framework settings such as production or development profile selection, debug interfaces, remote management interfaces, management endpoints, routing, authentication and authorization settings, session management settings, object binding, serialization or deserialization settings, cryptographic provider selection, trust store configuration, plug-in loading, and external configuration source precedence.PII is considered to be sensitive data. If "require user approval before executing..." is claimed, the ST must not claim "not transmit any..." in FTP_DIT_EXT.1.
This requirement applies only to PII that is specifically requested by the application; it does not apply if the user volunteers PII without prompting from the application into a general (or inappropriate) data field. A dialog box that declares intent to send PII presented to the user at the time the application is started is sufficient to meet this requirement.
The purpose of this requirement is to help ensure the integrity of application binaries by supporting file protection mechanisms such as directory-level file permissions and application allowlisting.
A user-modifiable file for purposes of this requirement is a file that is writable by an unprivileged user of the application -- either directly through application execution or independently of the application. If the application runs in the context of the application user, then the application should not be able to write to the directory containing the application binaries -- regardless of whether the files are configuration data, audit data, or temporary files.Executables and user-modifiable files may not share the same parent directory, but may share directories above the parent.This requirement applies to the code of the application; it does not apply to mobile code technologies that are designed for download and execution by the application.
If "perform trusted updates" is selected then FPT_TUD_EXT.2 must be included in the ST.Encryption is not required for applications transmitting data that is not sensitive.
Where TOE Component Instance is selected as the peer, the ST shall identify each in-scope network-mediated intra-TOE Communication Relationship Type, the communication path, the TOE Components involved, any TOE Component Instances needed to describe the realized path, the protocol or mechanism used, the data or sensitive data transmitted, and whether the protection is implemented by the TOE, invoked from the platform, or provided through another allowed PP-Configuration dependency. A connection limited to the platform loopback interface is not subject to this requirement in this version of the cPP and does not require a trusted-channel claim or a separate FTP_DIT_EXT.1 test. This scope boundary does not assert that local users or processes are trusted.If "not transmit any..." is selected, no other option can be selected.If "not transmit any..." is NOT selected, it is possible to select more than one of the other options to encrypt data for a specific cryptographic function (e.g., application encrypts management data using SSH AND application invokes platform-provided functionality to encrypt syslog data using TLS OR application encrypts syslog data using TLS. Protocol selections and function assignments should be made to cover all data/sensitive data.If "encrypt all transmitted..." is selected and "TLS" or "DTLS" as a client or server is selected, then corresponding components from Functional Package for Transport Layer Security (TLS), version 2.1 must be selected.If "encrypt all transmitted..." is selected and any claim involving HTTPS is selected, then FCS_HTTPS_EXT.1 and potentially FCS_HTTPS_EXT.2 is required, as indicated by the chosen selections.If "encrypt all transmitted..." is selected and "SSH" is selected, then the TSF shall be validated against the Functional Package for Secure Shell.If "encrypt all transmitted..." is selected and "IPsec" is selected, then the TSF must claim conformance to a PP-Configuration that includes the VPN Client PP-Module, version 3.0.If "encrypt all transmitted..." is selected, FCS_CKM.2 and all iterations of FCS_COP.1 must be claimed.Claims from the Functional Package for X.509 are only required to the extent that they are needed to support the functionality required by the trusted protocols that are claimed. For example, if the TOE supports HTTPS as a server but does not support mutual authentication, then for this interface the TSF would only present certificates in accordance with the requirements of the package and not validate presented certificates.If the TSF implements a protocol that requires the validation of a certificate presented by an external entity, FIA_X509_EXT.1 and FIA_X509_EXT.2 will be claimed. FIA_TSM_EXT.1 may also be claimed if the TSF implements its own trust store. Note that FIA_X509_EXT.1 and FIA_X509_EXT.2 have selections for invocation of platform-provided functionality, so it is expected that these claims are made and tested even when the trusted protocol is implemented by the TOE platform.If the TSF implements a protocol that requires the presentation of any certificates to an external entity, FIA_XCU_EXT.2 from Functional Package for X.509 will be claimed. FIA_X509_EXT.3 from Functional Package for X.509 will also be claimed, along with any applicable dependencies, depending on how the certificates presented by the TOE are obtained.If the TSF implements a protocol that does not require presenting or validating X.509 certificates, no claims from the Functional Package for X.509 are required.The following rationale provides justification for each SFR for the TOE,
showing that the SFRs are suitable to address the specified threats:
| Threat | Addressed by | Rationale |
|---|---|---|
| T.LOCAL_ATTACK | FCS_CKM_EXT.1 | The PP includes FCS_CKM_EXT.1 to specify that the TSF may rely on platform-provided key generation services. |
| FCS_RBG_EXT.1 | The PP includes FCS_RBG_EXT.1 to specify that the TSF may rely on platform-provided random bit generation services. | |
| FCS_STO_EXT.1 | The PP includes FCS_STO_EXT.1 to specify that the TSF may rely on platform-provided credential storage services. | |
| FDP_DAR_EXT.1 | The PP includes FDP_DAR_EXT.1 to specify that the TSF may rely on platform-provided data-at-rest protection services. | |
| FDP_DEC_EXT.1 | The PP includes FDP_DEC_EXT.1 to limit access to platform hardware resources, which limits the methods by which an attacker can attempt to locally compromise the integrity of the TOE. | |
| FMT_CFG_EXT.1 | The PP includes FMT_CFG_EXT.1 for the TSP to limit unauthorized access to itself by preventing the use of default authentication credentials and by ensuring that the TOE uses appropriately restrictive platform permissions on its binaries and data | |
| FMT_MEC_EXT.1 | The PP includes FMT_MEC_EXT.1 to ensure that the TOE can use platform services to store and set configuration options. | |
| FPT_AEX_EXT.1 | The PP includes FPT_AEX_EXT.1 to add complexity to the task of compromising systems by ensuring that the TOE implements various platform security features and can operate on a platform that is configured securely. | |
| FPT_API_EXT.1 | The PP includes FPT_API_EXT.1 to require the TOE to leverage platform functionality by using only documented and supported APIs. | |
| FPT_LIB_EXT.1 | The PP includes FPT_LIB_EXT.1 to ensure that the TOE does not include any unnecessary or unexpected third-party libraries which could present a privacy threat or vulnerability. | |
| FPT_TUD_EXT.1 | The PP includes FPT_TUD_EXT.1 to ensure that the TOE can be patched and that any updates to the TOE have appropriate integrity protection. | |
| FPT_IPC_EXT.1 (Objective) | The PP includes FPT_IPC_EXT.1 to provide an objective for protection of non-network local inter-process communication between TOE Component Instances. | |
| FPT_API_EXT.2 (Objective) | The PP includes FPT_API_EXT.2 to permit the TOE to use platform-provided libraries for parsing IANA MIME media formats. | |
| FCS_CKM.1/AK (Selection-based) | The PP includes FCS_CKM.1/AK to specify that the TSF may rely on platform-provided asymmetric key generation services. | |
| FCS_CKM.2 (Selection-based) | The PP includes FCS_CKM.2 to specify that the TSF may rely on platform-provided key establishment services. | |
| FPT_TUD_EXT.2 (Selection-based) | The PP includes FPT_TUD_EXT.2 to ensure that TOE updates are packaged in a certain format, provide certain integrity protections, and remove residual data. | |
| T.NETWORK_ATTACK | FCS_CKM_EXT.1 | The PP includes FCS_CKM_EXT.1 to specify whether the TOE or the platform is responsible for generation of any asymmetric keys that may be used for establishing trusted communications. |
| FCS_RBG_EXT.1 | The PP includes FCS_RBG_EXT.1 to define whether the random bit generation services used in establishing trusted communications are implemented by the TSF or by the platform. | |
| FDP_DEC_EXT.1 | The PP includes FDP_DEC_EXT.1 to limit access to platform hardware resources, which limits the methods by which an attacker can attempt to remotely compromise the integrity of the TOE. | |
| FDP_NET_EXT.1 | The PP includes FDP_NET_EXT.1 to define the TOE’s usage of network communications, which may include the transmission or receipt of data over a trusted channel. | |
| FMT_CFG_EXT.1 | The PP includes FMT_CFG_EXT.1 for the TSP to limit unauthorized access to itself by preventing the use of default authentication credentials and by ensuring that the TOE uses appropriately restrictive platform permissions on its binaries and data | |
| FMT_SMF.1 | The PP includes FMT_SMF.1 to define the security-relevant management functions that are supported by the TOE, which may include configuration of network behavior. | |
| FPR_ANO_EXT.1 | The PP includes FPR_ANO_EXT.1 to define how the TSF provides control to the user regarding the disclosure of any PII. | |
| FPT_AEX_EXT.1 | The PP includes FPT_AEX_EXT.1 to add complexity to the task of compromising systems by ensuring that the TOE implements various platform security features and can operate on a platform that is configured securely. | |
| FPT_TUD_EXT.1 | The PP includes FPT_TUD_EXT.1 to ensure that updates to the TOE have integrity protection and cannot be altered via network attack. | |
| FTP_DIT_EXT.1 | The PP includes FTP_DIT_EXT.1 to define the trusted channels used to protect data in transit, the data that is protected, and whether the trusted channels are implemented by the TSF or the platform. | |
| FPT_IDV_EXT.1 (Objective) | The PP includes FPT_IDV_EXT.1 to provide a mechanism to identify the TOE version so that it can be determined whether a vulnerability is present on the system based on the installed version. | |
| FCS_CKM.1/AK (Selection-based) | The PP includes FCS_CKM.1/AK to define whether the TSF or the platform generates asymmetric keys that are used in support of trusted communications. | |
| FCS_CKM.1/SK (Selection-based) | The PP includes FCS_CKM.1/SK to define the mechanism used to generate symmetric keys when the TOE performs this function. | |
| FCS_CKM.2 (Selection-based) | The PP includes FCS_CKM.2 to define whether the TSF or the platform performs key establishment for trusted communications. | |
| FCS_COP.1/Hash (Selection-based) | The PP includes FCS_COP.1/Hash to define the hash algorithms used in support of trusted communications. | |
| FCS_COP.1/KeyedHash (Selection-based) | The PP includes FCS_COP.1/KeyedHash to define the HMAC algorithms used in support of trusted communications. | |
| FCS_COP.1/SigGen (Selection-based) | The PP includes FCS_COP.1/SigGen to define the digital signature algorithms used in support of trusted communications. | |
| FCS_COP.1/SigVer (Selection-based) | The PP includes FCS_COP.1/SigVer to define the digital signature algorithms used in support of trusted communications and trusted updates. | |
| FCS_COP.1/SKC (Selection-based) | The PP includes FCS_COP.1/SKC to define the symmetric encryption algorithms used in support of trusted communications. | |
| FCS_HTTPS_EXT.1 (Selection-based) | The PP includes FCS_HTTPS_EXT.1 to define the TOE’s support for the HTTPS trusted communications protocol. | |
| FCS_HTTPS_EXT.2 (Selection-based) | The PP includes FCS_HTTPS_EXT.2 to define the TOE’s handling of X.509 certificates in the context of HTTPS communications. | |
| FCS_RBG.1 (Selection-based) | The PP includes FCS_RBG.1 to define the DRBG algorithms used in support of trusted communications. | |
| FCS_RBG.2 (Selection-based) | The PP includes FCS_RBG.2 to define how entropy is obtained for secure DRBG seeding. | |
| FCS_RBG.3 (Selection-based) | The PP includes FCS_RBG.3 to define how entropy is obtained for secure DRBG seeding. | |
| FCS_RBG.4 (Selection-based) | The PP includes FCS_RBG.4 to define how entropy is obtained for secure DRBG seeding. | |
| FCS_RBG.5 (Selection-based) | The PP includes FCS_RBG.5 to define how entropy is obtained for secure DRBG seeding. | |
| FCS_SNI_EXT.1 (Selection-based) | The PP includes FCS_SNI_EXT.1 to define the proper salt, nonce, and initialization vector usage to ensure proper cryptographic operation. | |
| FPT_FLS.1 (Selection-based) | The PP includes FPT_FLS.1 to ensure that the TSF will not operate when it is in a state where it is unable to generate secure random numbers. | |
| FPT_TST.1 (Selection-based) | The PP includes FPT_TST.1 to ensure that the TSF can determine whether or not it is capable of generating secure random numbers. | |
| FPT_TUD_EXT.2 (Selection-based) | The PP includes FPT_TUD_EXT.2 to define specific integrity protections for certain types of updates. | |
| T.NETWORK_EAVESDROP | FCS_CKM_EXT.1 | The PP includes FCS_CKM_EXT.1 to specify whether the TOE or the platform is responsible for generation of any asymmetric keys that may be used for establishing trusted communications. |
| FCS_RBG_EXT.1 | The PP includes FCS_RBG_EXT.1 to define whether the random bit generation services used in establishing trusted communications are implemented by the TSF or by the platform. | |
| FCS_STO_EXT.1 | The PP includes FCS_STO_EXT.1 to specify that the TSF may rely on platform-provided credential storage services. | |
| FDP_DAR_EXT.1 | The PP includes FDP_DAR_EXT.1 to specify that the TSF may rely on platform-provided data-at-rest protection services. | |
| FDP_NET_EXT.1 | The PP includes FDP_NET_EXT.1 to define the TOE’s usage of network communications, which may include the transmission or receipt of data over a trusted channel. | |
| FMT_MEC_EXT.1 | The PP includes FMT_MEC_EXT.1 to ensure that the TOE can use platform services to store and set configuration options. | |
| FMT_SMF.1 | The PP includes FMT_SMF.1 to define the security-relevant management functions that are supported by the TOE. | |
| FPR_ANO_EXT.1 | The PP includes FPR_ANO_EXT.1 to define how the TSF provides control to the user regarding the disclosure of any PII. | |
| FPT_API_EXT.1 | The PP includes FPT_API_EXT.1 to require the TOE to leverage platform functionality by using only documented and supported APIs. | |
| FPT_LIB_EXT.1 | The PP includes FPT_LIB_EXT.1 to ensure that the TOE does not include any unnecessary or unexpected third-party libraries which could present a privacy threat or vulnerability. | |
| FTP_DIT_EXT.1 | The PP includes FTP_DIT_EXT.1 to define the trusted channels used to protect data in transit, the data that is protected, and whether the trusted channels are implemented by the TSF or the platform. | |
| FPT_API_EXT.2 (Objective) | The PP includes FPT_API_EXT.2 to permit the TOE to use platform-provided libraries for parsing IANA MIME media formats. | |
| FPT_IDV_EXT.1 (Objective) | The PP includes FPT_IDV_EXT.1 to provide a mechanism to identify the TOE version so that it can be determined whether a vulnerability is present on the system based on the installed version. | |
| FCS_CKM.1/AK (Selection-based) | The PP includes FCS_CKM.1/AK to define whether the TSF or the platform generates asymmetric keys that are used in support of trusted communications. | |
| FCS_CKM.1/SK (Selection-based) | The PP includes FCS_CKM.1/SK to define the mechanism used to generate symmetric keys when the TOE performs this function. | |
| FCS_CKM.2 (Selection-based) | The PP includes FCS_CKM.2 to define whether the TSF or the platform performs key establishment for trusted communications. | |
| FCS_COP.1/Hash (Selection-based) | The PP includes FCS_COP.1/Hash to define the hash algorithms used in support of trusted communications. | |
| FCS_COP.1/KeyedHash (Selection-based) | The PP includes FCS_COP.1/KeyedHash to define the HMAC algorithms used in support of trusted communications. | |
| FCS_COP.1/SigVer (Selection-based) | The PP includes FCS_COP.1/SigVer to define the mechanism used to verify TOE updates if the TOE implements this functionality rather than the underlying platform. | |
| FCS_COP.1/SKC (Selection-based) | The PP includes FCS_COP.1/SKC to define the symmetric encryption algorithms used in support of trusted communications. | |
| FCS_HTTPS_EXT.1 (Selection-based) | The PP includes FCS_HTTPS_EXT.1 to define the TOE’s support for the HTTPS trusted communications protocol. | |
| FCS_HTTPS_EXT.2 (Selection-based) | The PP includes FCS_HTTPS_EXT.2 to define the TOE’s handling of X.509 certificates in the context of HTTPS communications. | |
| FCS_RBG.1 (Selection-based) | The PP includes FCS_RBG.1 to define the DRBG algorithms used in support of trusted communications. | |
| FCS_RBG.2 (Selection-based) | The PP includes FCS_RBG.2 to define how entropy is obtained for secure DRBG seeding. | |
| FCS_RBG.3 (Selection-based) | The PP includes FCS_RBG.3 to define how entropy is obtained for secure DRBG seeding. | |
| FCS_RBG.4 (Selection-based) | The PP includes FCS_RBG.4 to define how entropy is obtained for secure DRBG seeding. | |
| FCS_RBG.5 (Selection-based) | The PP includes FCS_RBG.5 to define how entropy is obtained for secure DRBG seeding. | |
| FPT_FLS.1 (Selection-based) | The PP includes FPT_FLS.1 to ensure that the TSF will not operate when it is in a state where it is unable to generate secure random numbers. | |
| FPT_TST.1 (Selection-based) | The PP includes FPT_TST.1 to ensure that the TSF can determine whether or not it is capable of generating secure random numbers. | |
| T.PHYSICAL_ACCESS | FCS_RBG_EXT.1 | The PP includes FCS_RBG_EXT.1 to define whether random bit generation services are implemented by the TSF or the platform. Depending on how data at rest is protected, the TOE may rely on the use of a random bit generator to create keys that are subsequently used for data protection. |
| FCS_STO_EXT.1 | The PP includes FCS_STO_EXT.1 to define the mechanism that the TSF uses or relies upon to protect stored credential data. | |
| FDP_DAR_EXT.1 | The PP includes FDP_DAR_EXT.1 to define the mechanism that the TSF uses or relies upon to protect sensitive data at rest. | |
| FPT_IDV_EXT.1 (Objective) | The PP includes FPT_IDV_EXT.1 to provide a mechanism to identify the TOE version so that it can be determined whether a vulnerability is present on the system based on the installed version. | |
| FCS_CKM.1/SK (Selection-based) | The PP includes FCS_CKM.1/SK to define the TOE’s capability to generate symmetric keys. These keys may subsequently be used to encrypt stored credential data based on the claims made in FCS_STO_EXT.1. | |
| FCS_COP.1/Hash (Selection-based) | The PP includes FCS_COP.1/Hash to define integrity mechanisms that may be used by the TOE as part of ensuring that data at rest is protected. | |
| FCS_COP.1/KeyedHash (Selection-based) | The PP includes FCS_COP.1/KeyedHash to define HMAC mechanisms that may be used by the TOE as part of ensuring that data at rest is protected. | |
| FCS_COP.1/SKC (Selection-based) | The PP includes FCS_COP.1/SKC to define the AES cryptographic algorithm that may be used to encrypt stored credential data based on the claims made in FCS_STO_EXT.1. | |
| FCS_PBKDF_EXT.1 (Selection-based) | The PP includes FCS_PBKDF_EXT.1 to define the password-based key derivation function that may be used to encrypt stored credential data based on the claims made in FCS_STO_EXT.1. | |
| FCS_RBG.1 (Selection-based) | The PP includes FCS_RBG.1 to define the DRBG algorithms used in support of trusted communications. | |
| FCS_RBG.2 (Selection-based) | The PP includes FCS_RBG.2 to define how entropy is obtained for secure DRBG seeding. | |
| FCS_RBG.3 (Selection-based) | The PP includes FCS_RBG.3 to define how entropy is obtained for secure DRBG seeding. | |
| FCS_RBG.4 (Selection-based) | The PP includes FCS_RBG.4 to define how entropy is obtained for secure DRBG seeding. | |
| FCS_RBG.5 (Selection-based) | The PP includes FCS_RBG.5 to define how entropy is obtained for secure DRBG seeding. | |
| FPT_FLS.1 (Selection-based) | The PP includes FPT_FLS.1 to ensure that the TSF will not operate when it is in a state where it is unable to generate secure random numbers. | |
| FPT_TST.1 (Selection-based) | The PP includes FPT_TST.1 to ensure that the TSF can determine whether or not it is capable of generating secure random numbers. |
The PP identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the documentation applicable for the evaluation and performs independent testing.
This section lists the set of SARs from CC part 3 that are required in evaluations against this PP. Individual Evaluation Activities (EAs) to be performed are specified both in Section 5 Security Requirements as well as in this section. These SARs were chosen based on the notion that a hypothetical attacker of the TOE lacks administrative privilege on its platform but otherwise has persistent access to the TOE itself and the sophistication to interact with the platform in a way that they can attempt to access stored data without authorization or to run tools that automate more sophisticated malicious activity.The general model for evaluation of TOEs against STs written to conform to this PP is as follows:After the ST has been approved for evaluation, the CCTL will obtain the TOE, supporting environmental IT, and the administrative/user guides for the TOE. The CCTL is expected to perform actions mandated by the Common Evaluation Methodology (CEM) for the ASE and ALC SARs. The CCTL also performs the evaluation activities contained within Section 5 Security Requirements, which are intended to be an interpretation of the other CEM assurance requirements as they apply to the specific technology instantiated in the TOE. The evaluation activities that are captured in Section 5 Security Requirements also provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the PP. The results of these activities will be documented and presented (along with the administrative guidance used) for validation.The IANA MIME types are listed at http://www.iana.org/assignments/media-types and include many image, audio, video, and content file formats.
This requirement does not apply if providing parsing services is the purpose of the application.The use of a SWID tag to identify application software is a requirement for DoD IT based on DoD Instruction 8500.01 which requires the use of SCAP which includes SWID tags per the NIST standard.
Valid SWID tags must contain a SoftwareIdentity element and an Entity element as defined in the ISO/IEC 19770-2:2015 standard. SWID tags must be stored with a .swidtag file extensions as defined in the ISO/IEC 19770-2:2015.This PP does not define any Implementation-dependent requirements.
As indicated in the introduction to this PP, the baseline requirements (those that must be performed by the TOE or its underlying platform) are contained in the body of this PP. There are additional requirements based on selections in the body of the PP: if certain selections are made, then additional requirements below must be included.
The ST should claim all key generation schemes used for key establishment and entity authentication. When key generation is used for key establishment, the schemes in FCS_CKM.2.1 and selected cryptographic protocols must match the selection. When key generation is used for entity authentication, the public key is expected to be associated with an X.509v3 certificate.
If the TOE acts as a receiver in the RSA key establishment scheme, the TOE does not need to implement RSA key generation.Note that ML-DSA and ML-KEM are not usable in any functions at the time of initial publication, they are added to this requirement in support of future protocol updates. As support is expanded for CNSA 2.0, CNSA 1.0 will be removed as an selection in a future update.The application shall [selection: invoke platform-provided functionality, implement functionality] to perform cryptographic key establishment in accordance with a specified cryptographic key establishment method:
[selection:
The ST author shall select all key establishment schemes used for the selected cryptographic protocols. TLS requires cipher suites that use RSA-based key establishment schemes.
The RSA-based key establishment schemes are described in Section 9 of NIST SP 800-56B; however, Section 9 relies on implementation of other sections in SP 800-56B. If the TOE acts as a receiver in the RSA key establishment scheme, the TOE does not need to implement RSA key generation.The elliptic curves used for the key establishment scheme shall correlate with the curves specified in FCS_CKM.1.1/AK.The domain parameters used for the finite field-based key establishment scheme are specified by the key generation according to FCS_CKM.1.1/AK.As support is expanded for CNSA 2.0, CNSA 1.0 will be removed as an selection in a future update.This is dependent on implementing cryptographic functionality, as in FTP_DIT_EXT.1.
The intent of this requirement is to specify the hashing function. The hash selection must support the message digest size selection.This is dependent on implementing cryptographic functionality, as in FTP_DIT_EXT.1.
The intent of this requirement is to specify the keyed-hash message authentication function used for key establishment purposes for the various cryptographic protocols used by the application (e.g., trusted channel). The hash selection must support the message digest size selection.This is dependent on implementing cryptographic functionality, as in FTP_DIT_EXT.1.
The ST author should choose the algorithm implemented to perform digital signatures; if more than one algorithm is available, this requirement should be iterated to specify the functionality. For the algorithm chosen, the ST author should make the appropriate assignments/selections to specify the parameters that are implemented for that algorithm.Note ML-DSA is not able to be used in any functions at the time of publication, it is being added for future support. As support is expanded for CNSA 2.0, CNSA 1.0 will be removed as an selection in a future update.This is dependent on implementing cryptographic functionality, as in FTP_DIT_EXT.1.
The ST author should choose the algorithm implemented to perform digital signatures; if more than one algorithm is available, this requirement should be iterated to specify the functionality. For the algorithm chosen, the ST author should make the appropriate assignments/selections to specify the parameters that are implemented for that algorithm.Note ML-DSA is not able to be used in any functions at the time of publication, it is being added for future support. As support is expanded for CNSA 2.0, CNSA 1.0 will be removed as an selection in a future update.If LMS or XMSS is claimed, then FCS_COP.1/XOF must also be claimed when SHAKE is utilized.In accordance with CNSA 2.0, SHAKE is permitted to be used only as a component of LMS or XMSS. Therefore this component is claimed only if LMS or XMSS is claimed in FCS_COP.1/SigVer and they use SHAKE.
This is dependent on implementing cryptographic functionality, as in FTP_DIT_EXT.1.
For the selection, the ST author should choose the mode or modes in which AES operates.It is expected that symmetric keys will be generated or imported by the TSF as a dependency on this function, so FCS_CKM.1/SK must be claimed when this SFR is claimed. FCS_SNI_EXT.1 must also be claimed to define what, if any, salts the cryptographic algorithm implementation uses.This should be included if selected in FCS_STO_EXT.1.
Conditioning can be performed using one of the identified hash functions or the process described in NIST SP 800-132; the method used is selected by the ST Author. SP 800-132 requires the use of a pseudorandom function (PRF) consisting of HMAC with an approved hash function. The ST author selects the hash function used, including the appropriate requirements for HMAC and the hash function.Appendix A of SP800-132 recommends setting the number of iterations as high as can be tolerated for the environment, while maintaining acceptable performance. For unconstrained environments, this could be 200,000 or much higher. The larger the iteration count, the greater protection is against a password recovery attack due to the increase computation needed to a derive a key. This value is expected to increase to a minimum of 10,000 in a future iteration based on NIST SP 800-63.For the selection in this requirement, the ST author selects "TSF noise source" if a single noise source is used as input to the DRBG. The ST author selects "multiple TSF noise sources" if a seed is formed from a combination of two or more noise sources within the TOE boundary. If the TSF implements two or more separate DRBGs that are seeded in separate manners, this SFR should be iterated for each DRBG. If multiple distinct noise sources exist such that each DRBG only uses one of them, then each iteration would select "TSF noise source"; "multiple TSF noise sources" is only selected if a single DRBG uses multiple noise sources for its seed. The ST author selects "TSF interface for seeding" if noise source data is generated outside the TOE boundary.
If "TSF noise source" is selected, FCS_RBG.3 must be claimed.If "multiple TSF noise sources" is selected, FCS_RBG.4 and FCS_RBG.5 must be claimed.If "TSF interface for seeding" is selected, FCS_RBG.2 must be claimed.This requirement ensures that salts, nonces, and initialization vectors are properly implemented. If the application is implementing a salt, nonce, or initialization vector they must select the corresponding selection. If the platform implements these functions, the corresponding "use no..." options are selected.
This requirement is dependent on selecting "implement functionality to securely store..." in FCS_STO_EXT.1.1 or any AES selection in FCS_COP.1.1/SKC.The specifics of the verification of installation packages involves requirements on the platform (and not the application), so these are not fully specified here.
If "Leighton-Micali Signature" or "eXtended Merkle Signature Scheme" is selected, the corresponding selection must be made in FCS_COP.1/SigVer.| Functional Class | Functional Components |
|---|---|
| Cryptographic Support (FCS) | FCS_CKM_EXT Cryptographic Key Management FCS_HTTPS_EXT HTTPS Protocol FCS_PBKDF_EXT Password Conditioning FCS_RBG_EXT Random Bit Generation FCS_STO_EXT Storage of Credentials |
| Privacy (FPR) | FPR_ANO_EXT User Consent for Transmission of Personally Identifiable Information |
| Protection of the TSF (FPT) | FPT_AEX_EXT Anti-Exploitation Capabilities FPT_API_EXT Use of Supported Services and APIs FPT_IDV_EXT Software Identification and Versions FPT_IPC_EXT Protection of Non-Network Local Inter-Process Communication FPT_LIB_EXT TSF Use of Third Party Libraries FPT_TUD_EXT Trusted Updates |
| Security Management (FMT) | FMT_CFG_EXT Secure by Default Configuration FMT_MEC_EXT Supported Configuration Mechanism |
| Trusted Path/Channels (FTP) | FTP_DIT_EXT Protection of Data in Transit |
| User Data Protection (FDP) | FDP_DAR_EXT Data-at-Rest Encryption FDP_DEC_EXT Access to Platform Resources FDP_NET_EXT Network Communications |
FCS_CKM_EXT.1, Cryptographic Key Generation Services, requires the TSF to specify whether asymmetric key generation is implemented by the TSF, invoked from the operational environment, or not used by the TOE.
No specific management functions are identified.
There are no auditable events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: | No dependencies. |
FCS_HTTPS_EXT.1, HTTPS Protocol, defines the capability of the TOE to implement HTTPS.
FCS_HTTPS_EXT.2, HTTPS Support for Authentication, defines the TSF's response when an invalid certificate is presented as part of HTTPS connection establishment.
No specific management functions are identified.
There are no auditable events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: | FCS_TLS_EXT.1 TLS Protocol |
The following actions could be considered for the management functions in FMT:
There are no auditable events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: | FCS_HTTPS_EXT.1 HTTPS Protocol FIA_X509_EXT.1 X.509 Certificate Validation |
FCS_PBKDF_EXT.1, Password Conditioning, defines the capability of the TOE to implement PBKDF2 for key derivation.
No specific management functions are identified.
There are no auditable events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: | FCS_COP.1 Cryptographic Operation FCS_RBG_EXT.1 Random Bit Generation Services |
FCS_RBG_EXT.1, Random Bit Generation Services, requires the TSF to specify whether random bit generation is implemented by the TSF, invoked from the operational environment, or not used by the TOE.
No specific management functions are identified.
There are no auditable events foreseen.
FCS_STO_EXT.1, Storage of Credentials, requires the application to define how to store credentials to non-volatile memory.
No specific management functions are identified.
There are no auditable events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: | No dependencies. |
FPR_ANO_EXT.1, User Consent for Transmission of Personally Identifiable Information, requires the TSF to transmit personally identifiable information only with explicit approval.
The following action could be considered for the management functions in FMT:
There are no auditable events foreseen.
FPT_AEX_EXT.1, Anti-Exploitation Capabilities, requires the application to implement functionality that protects against common software exploits.
No specific management functions are identified.
There are no auditable events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: | No dependencies. |
FPT_API_EXT.1, Use of Supported Services and APIs, requires the application to use only documented platform APIs.
FPT_API_EXT.2, Use of Supported Services and APIs, requires the application to implement media parsing in a specified manner.
No specific management functions are identified.
There are no auditable events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: | No dependencies. |
No specific management functions are identified.
There are no auditable events foreseen.
FPT_IPC_EXT.1, Protection of Non-Network Local Inter-Process Communication, requires the application to identify and describe the protection of non-network local inter-process communication between TOE Component Instances.
No specific management functions are identified.
There are no auditable events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: | No dependencies. |
FPT_IDV_EXT.1, Software Identification and Versions, requires the TSF to specify the versioning mechanism used.
No specific management functions are identified.
There are no auditable events foreseen.
FPT_LIB_EXT.1, Use of Third Party Libraries, requires the TOE to identify the third party libraries that it uses.
No specific management functions are identified.
There are no auditable events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: | No dependencies. |
FPT_TUD_EXT.1, Support for Trusted Updates, requires the TSF to specify how updates to it are acquired and verified.
FPT_TUD_EXT.2, Integrity for Installation and Update, requires TOE updates to be packaged in a certain manner.
No specific management functions are identified.
There are no auditable events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: | FPT_IDV_EXT.1 Software Identification and Versions |
No specific management functions are identified.
There are no auditable events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: | FPT_TUD_EXT.1 Integrity for Installation and Update |
FMT_CFG_EXT.1, Secure by Default Configuration, requires the application to define how to set new credentials and protect the application from modification by unprivileged users.
No specific management functions are identified.
There are no auditable events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: | No dependencies. |
FMT_MEC_EXT.1, Supported Configuration Mechanism, requires the application to store configuration data either through the use of an appropriate environmental mechanism or through its own file encryption capability.
No specific management functions are identified.
There are no auditable events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: | No dependencies. |
FTP_DIT_EXT.1, Protection of Data in Transit, requires the TSF to specify what data is transmitted outside the TOE or, where the TOE Component Instance peer is selected, over an in-scope network-mediated channel between TOE Component Instances, what protocol is used for data transmission, and whether the TSF implements this protocol or invokes an environmental interface to do so.
No specific management functions are identified.
There are no auditable events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: | No dependencies. |
FDP_DAR_EXT.1, Encryption Of Sensitive Application Data, requires the application to be able to protect all data with a chosen method of encryption.
No specific management functions are identified.
There are no auditable events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: | No dependencies. |
FDP_DEC_EXT.1, Access to Platform Resources, requires the application to restrict access to hardware sources and sensitive information repositories.
The following action could be considered for the management functions in FMT:
There are no auditable events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: | FCS_TLS_EXT.1 TLS Protocol FIA_X509_EXT.1 X.509 Certificate Validation |
FDP_NET_EXT.1, Network Communications, identifies the purpose for each network interface used by the TOE and how that interface is invoked.
No specific management functions are identified.
There are no auditable events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: | No dependencies. |
This appendix describes the required supplementary information for the entropy source used by the TOE.
The documentation of the entropy source should be detailed enough that, after reading, the evaluator will thoroughly understand the entropy source and why it can be relied upon to provide sufficient entropy. This documentation should include multiple detailed sections: design description, entropy justification, operating conditions, and health testing. This documentation is not required to be part of the TSS.
Documentation shall include the design of the entropy source as a whole, including the interaction of all entropy source components. Any information that can be shared regarding the design should also be included for any third-party entropy sources that are included in the product.
The documentation shall describe how unprocessed (raw) data was obtained for the analysis. This description shall be sufficiently detailed to explain at what point in the entropy source model the data was collected and what effects, if any, the process of data collection had on the overall entropy generation rate. The documentation should walk through the entropy source design indicating where the entropy comes from, where the entropy output is passed next, any post-processing of the raw outputs (hash, XOR, etc.), if/where it is stored, and finally, how it is output from the entropy source. Any conditions placed on the process (e.g., blocking) should also be described in the entropy source design. Diagrams and examples are encouraged.
This design must also include a description of the content of the security boundary of the entropy source and a description of how the security boundary ensures that an adversary outside the boundary cannot affect the entropy rate.
If implemented, the design description shall include a description of how third-party applications can add entropy to the RBG. A description of any RBG state saving between power-off and power-on shall be included.
There should be a technical argument for where the unpredictability in the source comes from and why there is confidence in the entropy source delivering sufficient entropy for the uses made of the RBG output (by this particular TOE). This argument will include a description of the expected min-entropy rate (i.e. the minimum entropy (in bits) per bit or byte of source data) and explain that sufficient entropy is going into the TOE randomizer seeding process. This discussion will be part of a justification for why the entropy source can be relied upon to produce bits with entropy.
The amount of information necessary to justify the expected min-entropy rate depends on the type of entropy source included in the product.
For developer provided entropy sources, in order to justify the min-entropy rate, it is expected that a large number of raw source bits will be collected, statistical tests will be performed, and the min-entropy rate determined from the statistical tests. While no particular statistical tests are required at this time, it is expected that some testing is necessary in order to determine the amount of min-entropy in each output.
For third party provided entropy sources, in which the TOE vendor has limited access to the design and raw entropy data of the source, the documentation will indicate an estimate of the amount of min-entropy obtained from this third-party source. It is acceptable for the vendor to “assume” an amount of min-entropy, however, this assumption must be clearly stated in the documentation provided. In particular, the min-entropy estimate must be specified and the assumption included in the ST.
Regardless of type of entropy source, the justification will also include how the DRBG is initialized with the entropy stated in the ST, for example by verifying that the min-entropy rate is multiplied by the amount of source data used to seed the DRBG or that the rate of entropy expected based on the amount of source data is explicitly stated and compared to the statistical rate. If the amount of source data used to seed the DRBG is not clear or the calculated rate is not explicitly related to the seed, the documentation will not be considered complete.
The entropy justification shall not include any data added from any third-party application or from any state saving between restarts.
The purpose of equivalence in PP-based evaluations is to find a balance between evaluation rigor and commercial practicability—to ensure that evaluations meet customer expectations while recognizing that there is little to be gained from requiring that every variation in a product or platform be fully tested. If a product is found to be compliant with a PP on one platform, then all equivalent products on equivalent platforms are also considered to be compliant with the PP.
A Vendor can make a claim of equivalence if the Vendor believes that a particular instance of their Product implements PP-specified security functionality in a way equivalent to the implementation of the same functionality on another instance of their Product on which the functionality was tested. The Product instances can differ in version number or feature level (model), or the instances may run on different platforms. Equivalency can be used to reduce the testing required across claimed evaluated configurations. It can also be used during Assurance Maintenance to reduce testing needed to add more evaluated configurations to a certification.
These equivalency guidelines do not replace Assurance Maintenance requirements or scheme-specific policy requirements for CAVP certificates. Nor may equivalency be used to leverage evaluations with expired certifications.
These Equivalency Guidelines represent a shift from complete testing of all product instances to more of a risk-based approach. Rather than require that every combination of product and platform be tested, these guidelines support an approach that recognizes that products are being used in a variety of environments—and often in cloud environments over where the vendor (and sometimes the customer) have little or no control over the underlying hardware. Developers should be responsible for the security functionality of their applications on the platforms they are developed for—whether that is an operating system, a virtual machine, or a software-based execution environment such as a container. But those platforms may themselves run within other environments—virtual machines or operating systems—that completely abstract away the underlying hardware from the application. The developer should not be held accountable for security functionality that is implemented by platform layers that are abstracted away. The implication is that not all security functionality will necessarily be tested for all platform layers down to the hardware for all evaluated configurations—especially for applications developed for software-based execution environments such as containers. For these cases, the balancing of evaluation rigor and commercial practicability tips in favor of practicability. Note that this does not affect the requirement that at least one product instance be fully tested on at least one platform with cryptography mapped to a CAVP certificate.
Equivalency has two aspects:
There are two scenarios for performing equivalency analysis. One is when a product has been certified and the vendor wants to show that a later product should be considered certified due to equivalence with the earlier product. The other is when multiple product variants are going though evaluation together and the vendor would like to reduce the amount of testing that must be done. The basic rules for determining equivalence are the same in both cases. But there is one additional consideration that applies to equivalence with previously certified products. That is, the product with which equivalence is being claimed must have a valid certification in accordance with scheme rules and the Assurance Maintenance process must be followed. If a product’s certification has expired, then equivalence cannot be claimed with that product.
When performing equivalency analysis, the Evaluator/Vendor should first use the factors and guidelines for Product Model equivalence to determine the set of Product Models to be evaluated. In general, Product models that do not differ in PP-specified security functionality are considered equivalent for purposes of evaluation against the this PP.
If multiple revision levels of Product Models are to be evaluated—or to determine whether a revision of an evaluated product needs re-evaluation—the Evaluator/Vendor and Validator should use the factors and guidelines for Product Version equivalence to analyze whether Product Versions are equivalent.
Having determined the set of Product Models and Versions to be evaluated, the next step is to determine the set of Platforms that the Products must be tested on.
Each non-equivalent Product for which compliance is claimed must be fully tested on each non-equivalent platform for which compliance is claimed. For non-equivalent Products on equivalent platforms, only the differences that affect PP-specified security functionality must be tested for each product.
“Differences in PP-Specified Security Functionality” Defined
If PP-specified security functionality is implemented by the TOE, then differences in the actual implementation between versions or product models break equivalence for that feature. Likewise, if the TOE implements the functionality in one version or model and the functionality is implemented by the platform in another version or model, then equivalence is broken. If the functionality is implemented by the platform in multiple models or versions on equivalent platforms, then the functionality is considered different if the product invokes the platform differently to perform the function.
Product Model equivalence attempts to determine whether different feature levels of the same product across a product line are equivalent for purposes of PP testing. For example, if a product has a “basic” edition and an “enterprise” edition, is it necessary to test both models? Or does testing one model provide sufficient assurance that both models are compliant?
Product models are considered equivalent if there are no differences that affect PP-specified security functionality—as indicated in Table 1.
| Factor | Same/Different | Guidance |
| PP-Specified Functionality | Same | If the differences between Models affect only non-PP-specified functionality, then the Models are equivalent. |
| Different | If PP-specified security functionality is affected by the differences between Models, then the Models are not equivalent and must be tested separately. It is necessary only to test the functionality affected by the software differences. If only differences are tested, then the differences must be enumerated, and for each difference the Vendor must provide an explanation of why each difference does or does not affect PP-specified functionality. If the Product Models are separately tested fully, then there is no need to document the differences. |
In cases of version equivalence, differences are expressed in terms of changes implemented in revisions of an evaluated Product. In general, versions are equivalent if the changes have no effect on any security-relevant claims about the TOE or assurance evidence. Non-security-relevant changes to TOE functionality or the addition of non-security-relevant functionality does not affect equivalence.
| Factor | Same/Different | Guidance |
| Product Models | Different | Versions of different Product Models are not equivalent unless the Models are equivalent as defined in Section 3. |
| PP-Specified Functionality | Same | If the differences affect only non-PP-specified functionality, then the Versions are equivalent. |
| Different | If PP-specified security functionality is affected by the differences, then the Versions are not considered equivalent and must be tested separately. It is necessary only to test the functionality affected by the changes. If only the differences are tested, then for each difference the Vendor must provide an explanation of why the difference does or does not affect PP-specified functionality. If the Product Versions are separately tested fully, then there is no need to document the differences. |
Platform equivalence is used to determine the platforms that equivalent versions of a Product must be tested on. Platform equivalence analysis done for one software application cannot be applied to another software application. Platform equivalence is not general—it is with respect to a particular application.
Product Equivalency analysis must already have been done and Products have been determined to be equivalent.
The platform can be hardware or virtual hardware, an operating system or similar entity, or a software execution environment such as a container. For purposes of determining equivalence for software applications, we address each type of platform separately. In general, platform equivalence is based on differences in the interfaces between the TOE and Platform that are relevant to the implementation of PP-specified security functionality.
If an application runs directly on hardware without an operating system—or directly on virtualized hardware without an operating system—then platform equivalence is based on processor architecture and instruction sets. In the case of virtualized hardware, it is the virtualized processor and architecture that are presented to the application that matters—not the physical hardware.
Platforms with different processor architectures and instruction sets are not equivalent. This is not likely to be an issue for equivalency analysis for applications since there is likely to be a different version of the application for different hardware environments. Equivalency analysis becomes important when comparing processors with the same architecture. Processors with the same architecture that have instruction sets that are subsets or supersets of each other are not disqualified from being equivalent for purposes of an App evaluation. If the application takes the same code paths when executing PP-specified security functionality on different processors of the same family, then the processors can be considered equivalent with respect to that application. For example, if an application follows one code path on platforms that support the AES-NI instruction and another on platforms that do not, then those two platforms are not equivalent with respect to that application functionality. But if the application follows the same code path whether or not the platform supports AES-NI, then the platforms are equivalent with respect to that functionality.
The platforms are equivalent with respect to the application if the platforms are equivalent with respect to all PP-specified security functionality.
| Factor | Same/Different/None | Guidance |
| Platform Architectures | Different | Platforms that present different processor architectures and instruction sets to the application are not equivalent. |
| PP-Specified Functionality | Same | For platforms with the same processor architecture, the platforms are equivalent with respect to the application if execution of all PP-specified security functionality follows the same code path on both platforms. |
For traditional applications that are built for and run on operating systems, platform equivalence is determined by the interfaces between the application and the operating system that are relevant to PP-specified security functionality. Generally, these are the processor interface, device interfaces, and OS APIs. The following factors applied in order:
| Factor | Same/Different/None | Guidance |
| Platform Architectures | Different | Platforms that run on different processor architectures and instruction sets are not equivalent. |
| Platform Vendors | Different | Platforms from different vendors are not equivalent. |
| Platform Versions | Different | Platforms from the same vendor with different major version numbers are not equivalent. |
| Platform Interfaces | Different | Platforms from the same vendor and major version are not equivalent if there are differences in device interfaces and OS APIs that are relevant to the way the platform provides PP-specified security functionality to the application. |
| Platform Interfaces | Same | Platforms from the same vendor and major version are equivalent if there are no differences in device interfaces and OS APIs that are relevant to the way the platform provides PP-specified security functionality to the application, or if the Platform does not provide such functionality to the application. |
If an Application is built for and runs in a non-OS software-based execution environment, such as a Container or Java Runtime, then the below criteria must be used to determine platform equivalence. The key point is that the underlying hardware (virtual or physical) and OS is not relevant to platform equivalence. This allows applications to be tested and run on software-based execution environments on any hardware—as in cloud deployments.
| Factor | Same/Different/None | Guidance |
| Platform Type/Vendor | Different | Software-based execution environments that are substantially different or come from different vendors are not equivalent. For example, a Java virtual machine is not the same as a container. A Docker container is not the same as a CoreOS container. |
| Platform Versions | Different | Execution environments that are otherwise equivalent are not equivalent if they have different major version numbers. |
| PP-Specified Security Functionality | Same | All other things being equal, execution environments are equivalent if there is no significant difference in the interfaces through which the environments provide PP-specified security functionality to applications. |
In order to make equivalency determinations, the vendor and evaluator must agree on the equivalency claims. They must then provide the scheme with sufficient information about the TOE instances and platforms that were evaluated, and the TOE instances and platforms that are claimed to be equivalent.
The ST must describe all configurations evaluated down to processor manufacturer, model number, and microarchitecture version.
The information regarding claimed equivalent configurations depends on the platform that the application was developed for and runs on.
Bare-Metal Applications
For applications that run without an operating system on bare-metal or virtual bare-metal, the claimed configuration must describe the platform down to the specific processor manufacturer, model number, and microarchitecture version. The Vendor must describe the differences in the TOE with respect to PP-specified security functionality and how the TOE functions differently to leverage platform differences (e.g., instruction set extensions) in the tested configuration versus the claimed equivalent configuration.
Traditional Applications
For applications that run with an operating system as their immediate platform, the claimed configuration must describe the platform down to the specific operating system version. If the platform is a virtualization system, then the claimed configuration must describe the platform down to the specific virtualization system version. The Vendor must describe the differences in the TOE with respect to PP-specified security functionality and how the TOE functions differently to leverage platform differences in the tested configuration versus the claimed equivalent configuration. Relevant platform differences could include instruction sets, device interfaces, and OS APIs invoked by the TOE to implement PP-specified security functionality.
Software-Based Execution Environments
For applications that run in a software-based execution environment such as a Java virtual machine or a Container, then the claimed configuration must describe the platform down to the specific version of the software execution environment. The Vendor must describe the differences in the TOE with respect to PP-specified security functionality and how the TOE functions differently to leverage platform differences in the tested configuration versus the claimed equivalent configuration.
Component implementation equivalence is an evidence-reuse mechanism for named SFR Implementation Instances used by one or more TOE Components and identified security-relevant configurations within one distributed TOE. It is distinct from Product Equivalence and Platform Equivalence, which compare product models, product versions, or evaluated configurations. Interfaces and communication relationships are not class members; they remain coverage targets and retain every interface-specific, channel-specific, and integration activity required by the applicable Evaluation Activities. Component implementation equivalence does not transfer compliance from one TOE Component or identified configuration to another. Every TOE Component remains subject to every SFR allocated to it, and every TOE Component Instance shall exhibit the claimed behavior of its TOE Component in its identified configuration. A Runtime Replica is not a separate SFR Implementation Instance or implementation-equivalence class member solely because it is an additional deployed occurrence.
The ST need not repeat identical completed SFR text or identical TSS descriptions for every TOE Component. The ST shall provide concise traceability from each TOE Component and identified security-relevant configuration, where applicable, to the applicable SFR iteration and, where evidence reuse is claimed, to a class identifier and common TSS description. The detailed rationale and the class-to-Evaluation-Activity mapping may be provided separately from the ST. A class definition may list multiple SFR iterations and implementation-specific portions of Evaluation Activities when the member SFR Implementation Instances and equivalence basis are identical for the entire listed scope.
The implementation-equivalence rationale shall identify the class members; the listed SFR iterations and exact implementation-specific Evaluation Activity paragraphs or test identifiers for which reuse is proposed; the common security-relevant implementation and version; completed SFR operations; wrapper and integration behavior; security-relevant build options; implementation configuration and values relevant to the reused activities; exercised code path and role; cryptographic provider where applicable; immediate platform services and interfaces relevant to the reused activities; and known peripheral differences reasonably capable of affecting the scoped results. The same security-relevant implementation, version, provider, wrapper or integration behavior, build options, implementation configuration and values that affect the reused activities, role, exercised code path, and relevant platform services and interfaces are prerequisites for class membership. Only peripheral differences outside that implementation may be addressed by a rationale that they cannot affect the scoped results. 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. When the prerequisites are not established, the affected SFR Implementation Instances may not share representative execution for that scope.
Use of a common library name, base image, runtime, source repository, or build pipeline is relevant evidence but is not sufficient by itself. Component-specific calling code or configuration can change security behavior even when the underlying library is shared. Likewise, an operational-environment service such as a service mesh or ingress controller is not a shared TOE implementation unless it is explicitly included in the TOE boundary.
For TLS and similar trusted-channel functionality, the SFR Implementation Instances in a class shall have the same client or server role, TLS versus mutual-TLS behavior, protocol implementation and version, wrapper or integration behavior, supported protocol versions and algorithms, cryptographic provider, certificate validation and reference-identifier processing, revocation behavior, trust and credential processing and source mechanism, immediate platform services and interfaces relevant to the reused protocol tests, and implementation configuration relevant to those tests. Channel-specific certificates, keys, trust-anchor values, endpoint identities, addresses, and similar deployed values may differ because they remain subject to the applicable interface- and channel-specific checks. Different interruption or recovery behavior does not necessarily change the protocol implementation class, but each distinct channel remains subject to the applicable interruption and recovery tests.
Class membership shall be re-established when a member's security-relevant implementation version, provider, wrapper or integration behavior, relevant build options, relevant implementation configuration, relevant platform service or interface, or exercised code path changes. A change outside the scoped implementation does not automatically invalidate the class, but the rationale shall be updated when the change is reasonably capable of affecting a reused result.
The evaluator selects one or more representative class-member SFR Implementation Instances for each substantiated class and, for each, an exact deployed TOE Component Instance through which it will be exercised. The evaluator performs the explicitly identified implementation-specific portions of the applicable Evaluation Activities using deployed TOE Component Instances that collectively expose all relevant behavior. The evaluator verifies membership of every other class member using objective implementation, dependency, build, and configuration evidence. This is representative execution with complete class-membership verification; it is not sampling.
Representative execution eliminates only duplicate execution of the same implementation-specific activity across mapped class members. It does not reduce any test count, parameter combination, supported algorithm, protocol role, configuration, certificate case, negative test, interface, channel, or communication-relationship coverage required by the originating Evaluation Activity. This rule also applies to Evaluation Activities incorporated from PP-Modules and Functional Packages.
Artifact-specific examination, tests of distinct interfaces, roles, configurations, component identities, or communication relationships, activities that expressly require every member to be examined or tested, and end-to-end testing of the distributed TOE remain applicable at their stated scope. A single execution may support more than one mapped SFR Implementation Instance, SFR, or Evaluation Activity only when it demonstrates every applicable objective and the evaluation report preserves traceability and a separate verdict for each.
| Acronym | Meaning |
|---|---|
| ADB | Android Debug Bridge |
| AES | Advanced Encryption Standard |
| API | Application Programming Interface |
| APK | Android Application Package |
| app | Application |
| APPX | Windows Universal Application Package |
| ASLR | Address Space Layout Randomization |
| Base-PP | Base Protection Profile |
| BIOS | Basic Input/Output System |
| CC | Common Criteria |
| CEM | Common Evaluation Methodology |
| CMC | Certificate Management over CMS |
| CMS | Cryptographic Message Syntax |
| cPP | Collaborative Protection Profile |
| DEP | Data Execution Prevention |
| DES | Data Encryption Standard |
| DHE | Diffie-Hellman Ephemeral |
| DMG | Apple Disk Image |
| DNS | Domain Name System |
| DPAPI | Data Protection Application Programming Interface |
| DRBG | Deterministic Random Bit Generator |
| DSS | Digital Signature Standard |
| DT | Date/Time Vector |
| DTLS | Datagram Transport Layer Security |
| EAP | Extensible Authentication Protocol |
| ECDHE | Elliptic Curve Diffie-Hellman Ephemeral |
| ECDSA | Elliptic Curve Digital Signature Algorithm |
| ELF | Executable and Linkable Format |
| EMET | Enhanced Mitigation Experience Toolkit |
| EP | Extended Package |
| EST | Enrollment over Secure Transport |
| FIPS | Federal Information Processing Standards |
| FP | Functional Package |
| GPS | Global Positioning System |
| HMAC | Hash-based Message Authentication Code |
| HTTP | Hypertext Transfer Protocol |
| HTTPS | Hypertext Transfer Protocol Secure |
| IANA | Internet Assigned Number Authority |
| IEC | International Electrotechnical Commission |
| IETF | Internet Engineering Task Force |
| IP | Internet Protocol |
| IPA | iOS Package archive |
| IR | Intermediate Integer |
| ISO | International Organization for Standardization |
| IT | Information Technology |
| ITSEF | Information Technology Security Evaluation Facility |
| JNI | Java Native Interface |
| LDAP | Lightweight Directory Access Protocol |
| MIME | Multi-purpose Internet Mail Extensions |
| MPKG | Meta Package |
| MSI | Microsoft Installer |
| NFC | Near Field Communication |
| NIAP | National Information Assurance Partnership |
| NIST | National Institute of Standards and Technology |
| OCSP | Online Certificate Status Protocol |
| OE | Operational Environment |
| OID | Object Identifier |
| OMB | Office of Management and Budget |
| OS | Operating System |
| Portable Document Format | |
| PE | Portable Executable |
| PID | Process Identifier |
| PII | Personally Identifiable Information |
| PKG | Package file |
| PKI | Public Key Infrastructure |
| PP | Protection Profile |
| PP-Configuration | Protection Profile Configuration |
| PP-Module | Protection Profile Module |
| RBG | Random Bit Generator |
| RFC | Request for Comment |
| RNGVS | Random Number Generator Validation System |
| S/MIME | Secure/Multi-purpose Internet Mail Extensions |
| SAN | Subject Alternative Name |
| SAR | Security Assurance Requirement |
| SE | Security Enhancements |
| SFR | Security Functional Requirement |
| SHA | Secure Hash Algorithm |
| SIP | Session Initiation Protocol |
| SP | Special Publication |
| SSH | Secure Shell |
| ST | Security Target |
| SWID | Software Identification |
| TLS | Transport Layer Security |
| TOE | Target of Evaluation |
| TSF | TOE Security Functionality |
| TSFI | TSF Interface |
| TSS | TOE Summary Specification |
| UI | User Interface |
| URI | Uniform Resource Identifier |
| URL | Uniform Resource Locator |
| USB | Universal Serial Bus |
| XCCDF | eXtensible Configuration Checklist Description Format |
| XOR | Exclusive Or |
