| Platform Type/Vendor | Different | Software-based execution environments that are substantially different or come
@@ -4332,7 +4446,7 @@ D.3 Specific Guidance for D
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
+ 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
@@ -4341,19 +4455,13 @@ D.3 Specific Guidance for D
functions differently to leverage platform differences in the tested configuration versus the claimed equivalent
configuration.
Appendix E - AcronymsTable 3: Acronyms
- | API | Application Programming Interface |
-| app | Application |
-| ASLR | Address Space Layout Randomization |
-| Base-PP | Base Protection Profile |
+ | Base-PP | Base Protection Profile |
| CC | Common Criteria |
| CEM | Common Evaluation Methodology |
| cPP | Collaborative Protection Profile |
-| DEP | Data Execution Prevention |
| EP | Extended Package |
| FP | Functional Package |
| OE | Operational Environment |
-| OS | Operating System |
-| PII | Personally Identifiable Information |
| PP | Protection Profile |
| PP-Configuration | Protection Profile Configuration |
| PP-Module | Protection Profile Module |
diff --git a/xml-builder-test/SanityChecksOutput.md b/xml-builder-test/SanityChecksOutput.md
index 450c9ec..396a69b 100644
--- a/xml-builder-test/SanityChecksOutput.md
+++ b/xml-builder-test/SanityChecksOutput.md
@@ -3,15 +3,6 @@
* Error: f-element FIA_X509_EXT.2.1 appears not to have an associated evaluation activity.:
/PP[1]""/sec:req[1]""/sec:SFRs[1]""/section[3]""/f-component[2]""/f-element[1]""
* Warning: Detected an empty _p_ element./PP[1]""/sec:Introduction[1]""/section[2]""/choice[1]"This PP i"/h:p[1]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:Conformance_Claims[1]""/cclaims[1]""/cclaim[3]""/description[1]"This PP d"/h:p[1]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:Conformance_Claims[1]""/cclaims[1]""/cclaim[3]""/description[1]"This PP d"/h:p[2]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:Conformance_Claims[1]""/cclaims[1]""/cclaim[3]""/description[1]"This PP d"/h:p[3]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:Conformance_Claims[1]""/cclaims[1]""/cclaim[3]""/description[1]"This PP d"/h:p[4]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:Conformance_Claims[1]""/cclaims[1]""/cclaim[3]""/description[1]"This PP d"/h:p[5]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:Conformance_Claims[1]""/cclaims[1]""/cclaim[3]""/description[1]"This PP d"/h:p[6]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:Conformance_Claims[1]""/cclaims[1]""/cclaim[3]""/description[1]"This PP d"/h:p[7]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:Conformance_Claims[1]""/cclaims[1]""/cclaim[3]""/description[1]"This PP d"/h:p[8]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:Conformance_Claims[1]""/cclaims[1]""/cclaim[3]""/description[1]"This PP d"/h:p[9]""
* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/sec:SFRs[1]""/section[1]""/f-component[2]""/f-element[1]""/note[1]"The ST au"/h:p[1]""
* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/sec:SFRs[1]""/section[1]""/f-component[2]""/f-element[1]""/aactivity[1]""/TSS[1]"The evalu"/h:p[1]""
* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/sec:SFRs[1]""/section[1]""/f-component[2]""/f-element[1]""/aactivity[1]""/TSS[1]"The evalu"/h:p[2]""
@@ -217,20 +208,17 @@
* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/sec:SFRs[1]""/section[7]""/f-component[1]""/f-element[1]""/note[1]"Encryptio"/h:p[9]""
* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/sec:SFRs[1]""/section[7]""/f-component[1]""/f-element[1]""/aactivity[1]""/TSS[1]"For platf"/h:p[1]""
* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/sec:SFRs[1]""/section[7]""/f-component[1]""/f-element[1]""/aactivity[1]""/Guidance[1]"None."/h:p[1]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]"The Secur"/h:p[1]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]"The Secur"/h:p[2]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]"The Secur"/h:p[3]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]"The Secur"/section[3]"The guida"/a-component[1]""/a-element[9]""/aactivity[1]"Some of t"/h:p[1]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]"The Secur"/section[3]"The guida"/a-component[1]""/a-element[9]""/aactivity[1]"Some of t"/h:p[2]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]"The Secur"/section[3]"The guida"/a-component[1]""/a-element[9]""/aactivity[1]"Some of t"/h:p[3]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]"The Secur"/section[3]"The guida"/a-component[1]""/a-element[9]""/aactivity[1]"Some of t"/h:p[4]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]"The Secur"/section[4]"At the as"/a-component[2]""/a-element[4]""/aactivity[1]"The "eval"/h:p[1]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]"The Secur"/section[4]"At the as"/a-component[3]"This comp"/a-element[6]""/aactivity[1]"The evalu"/h:p[1]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]"The Secur"/section[4]"At the as"/a-component[3]"This comp"/a-element[6]""/aactivity[1]"The evalu"/h:p[2]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]"The Secur"/section[5]"Testing i"/a-component[1]"Testing i"/a-element[4]""/aactivity[1]"The evalu"/h:p[1]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]"The Secur"/section[5]"Testing i"/a-component[1]"Testing i"/a-element[4]""/aactivity[1]"The evalu"/h:p[2]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]"The Secur"/section[5]"Testing i"/a-component[1]"Testing i"/a-element[4]""/aactivity[1]"The evalu"/h:p[3]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]"The Secur"/section[6]"For the c"/a-component[1]""/a-element[5]""/aactivity[1]"The evalu"/h:p[1]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]"The Secur"/section[6]"For the c"/a-component[1]""/a-element[5]""/aactivity[1]"The evalu"/h:p[2]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]"The Secur"/section[6]"For the c"/a-component[1]""/a-element[5]""/aactivity[1]"The evalu"/h:p[3]""
-* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]"The Secur"/section[6]"For the c"/a-component[1]""/a-element[5]""/aactivity[1]"The evalu"/h:p[4]""
+* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]""/section[3]"The guida"/a-component[1]""/a-element[9]""/aactivity[1]"Some of t"/h:p[1]""
+* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]""/section[3]"The guida"/a-component[1]""/a-element[9]""/aactivity[1]"Some of t"/h:p[2]""
+* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]""/section[3]"The guida"/a-component[1]""/a-element[9]""/aactivity[1]"Some of t"/h:p[3]""
+* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]""/section[3]"The guida"/a-component[1]""/a-element[9]""/aactivity[1]"Some of t"/h:p[4]""
+* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]""/section[4]"At the as"/a-component[2]""/a-element[4]""/aactivity[1]"The "eval"/h:p[1]""
+* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]""/section[4]"At the as"/a-component[3]"This comp"/a-element[6]""/aactivity[1]"The evalu"/h:p[1]""
+* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]""/section[4]"At the as"/a-component[3]"This comp"/a-element[6]""/aactivity[1]"The evalu"/h:p[2]""
+* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]""/section[5]"Testing i"/a-component[1]"Testing i"/a-element[4]""/aactivity[1]"The evalu"/h:p[1]""
+* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]""/section[5]"Testing i"/a-component[1]"Testing i"/a-element[4]""/aactivity[1]"The evalu"/h:p[2]""
+* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]""/section[5]"Testing i"/a-component[1]"Testing i"/a-element[4]""/aactivity[1]"The evalu"/h:p[3]""
+* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]""/section[6]"For the c"/a-component[1]""/a-element[5]""/aactivity[1]"The evalu"/h:p[1]""
+* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]""/section[6]"For the c"/a-component[1]""/a-element[5]""/aactivity[1]"The evalu"/h:p[2]""
+* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]""/section[6]"For the c"/a-component[1]""/a-element[5]""/aactivity[1]"The evalu"/h:p[3]""
+* Warning: Detected an empty _p_ element./PP[1]""/sec:req[1]""/section[1]""/section[6]"For the c"/a-component[1]""/a-element[5]""/aactivity[1]"The evalu"/h:p[4]""
diff --git a/xml-builder-test/TDValidationReport.txt b/xml-builder-test/TDValidationReport.txt
index e69de29..62b5f7b 100644
--- a/xml-builder-test/TDValidationReport.txt
+++ b/xml-builder-test/TDValidationReport.txt
@@ -0,0 +1,18 @@
+/home/runner/work/application/application/output/effective.xml:399:114: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/output/effective.xml:399:213: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/output/effective.xml:567:99: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/output/effective.xml:567:195: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/output/effective.xml:1104:112: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/output/effective.xml:1104:233: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/output/effective.xml:1104:367: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/output/effective.xml:1167:105: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/output/effective.xml:1167:197: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/output/effective.xml:1398:479: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/output/effective.xml:1398:549: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/output/effective.xml:1853:104: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/output/effective.xml:1853:205: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/output/effective.xml:2021:199: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/output/effective.xml:2021:344: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/output/effective.xml:2021:429: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/output/effective.xml:2735:97: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/output/effective.xml:2735:196: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
diff --git a/xml-builder-test/ValidationReport.txt b/xml-builder-test/ValidationReport.txt
index e69de29..b82bdd1 100644
--- a/xml-builder-test/ValidationReport.txt
+++ b/xml-builder-test/ValidationReport.txt
@@ -0,0 +1,18 @@
+/home/runner/work/application/application/input/application.xml:402:115: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/input/application.xml:402:215: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/input/application.xml:570:100: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/input/application.xml:570:197: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/input/application.xml:1107:113: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/input/application.xml:1107:235: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/input/application.xml:1107:370: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/input/application.xml:1170:106: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/input/application.xml:1170:199: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/input/application.xml:1401:485: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/input/application.xml:1401:556: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/input/application.xml:1856:105: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/input/application.xml:1856:207: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/input/application.xml:2024:200: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/input/application.xml:2024:346: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/input/application.xml:2024:432: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/input/application.xml:2738:98: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
+/home/runner/work/application/application/input/application.xml:2738:198: error: attribute "onlyone" not allowed here; expected attribute "exclusive" or "style"
diff --git a/xml-builder-test/application-release-linkable.html b/xml-builder-test/application-release-linkable.html
index a47c76d..173c60f 100644
--- a/xml-builder-test/application-release-linkable.html
+++ b/xml-builder-test/application-release-linkable.html
@@ -663,22 +663,22 @@ 1.1 OverviewThe scope of
Target of Evaluation (TOE) | The product under evaluation. |
TOE Security Functionality (TSF) | The security functionality of the product under evaluation. |
TOE Summary Specification (TSS) | A description of how a TOE satisfies the SFRs in an ST. |
- 1.2.2 Technical TermsAddress Space Layout Randomization (ASLR) |
+ |
1.2.2 Technical TermsAddress Space Layout Randomization |
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) |
+ | Application |
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. The
terms TOE and application are interchangeable in this document. |
-Application Programming Interface (API) |
+ | Application Programming Interface |
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. |
Credential |
Data that establishes the identity of a user, e.g. a cryptographic key or password. |
-Data Execution Prevention (DEP) |
+ | Data Execution Prevention |
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. |
@@ -690,10 +690,10 @@ 1.1 OverviewThe scope of
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) |
+ | Operating System |
Software that manages hardware resources and provides services for
applications. |
-Personally Identifiable Information (PII) |
+ | Personally Identifiable Information |
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
@@ -727,62 +727,62 @@ 1.3 Compliant Targets o
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 applications that run in software-based execution environments contact the Technical Community for guidance. - Android: Mobile operating systems based on Google Android.
- Microsoft Windows: Microsoft Windows operating systems.
- Apple iOS: Apple's mobile operating system for iPhones.
- Linux: Linux-based operating systems other than Android.
- Oracle Solaris: Oracle's enterprise operating system.
- Apple macOS: Apple's operating system for MACs.
+ other OS platforms, and applications that run in software-based execution environments contact the Technical Community for guidance. - Android: Mobile operating systems based on Google Android.
- Microsoft Windows: Microsoft Windows operating systems.
- Apple iOS: Apple's mobile operating system for iPhones.
- Linux: Linux-based operating systems other than Android.
- Oracle Solaris: Oracle's enterprise operating system.
- Apple macOS: Apple's operating system for MACs.
1.5 Use Cases
Requirements in this Protection Profile are designed to address the security problem in the following use cases. These use cases are intentionally very broad, as many specific use cases exist for application software. Many applications may be used in combinations of these broad use cases, and evaluation against PP-Modules of this PP, when available, may be most appropriate for some application types. - [USE CASE 1] Content Creation
- The application allows a user to create content, saving it to either local or remote storage. Example content includes text documents, presentations, and images.
- [USE CASE 2] Content Consumption
- The application allows a user to consume content, retrieving it from either local or remote storage. Example content includes web pages and video.
- [USE CASE 3] Communication
- The application allows for communication interactively or non-interactively with other users or applications over a communications channel. Example communications include instant messages, email, and voice.
- - Conformance Statement
- An ST must claim exact conformance to this PP, as defined in the CC and CEM addenda for Exact Conformance, Selection-Based SFRs, and Optional SFRs (dated May 2017).
- CC Conformance Claims
- This PP is conformant to Parts 2 (extended) and 3 (extended) of Common Criteria Version 3.1, Revision 5.
- PP Claim
- This PP does not claim conformance to any other Protection Profile. The following PPs and PP-Modules are allowed to be specified in a PP-Configuration with this PP. Protection Profile for Mobile Device Management Version 4.0PP-Module for File Encryption, Version 1.0PP-Module for File Encryption Enterprise Management, Version 1.0PP-Module for VPN Clients, Version 2.2PP-Module for VPN Clients, Version 2.3PP-Module for Endpoint Detection and Response, Version 1.0PP-Module for Host Agent, Version 1.0PP-Module for Voice and Video over IP (VVoIP), Version 1.0PP-Module for Email Clients, Version 1.0
- Package Claim
- This PP is Functional Package for TLS Version 1.1 Conformant.
- This PP is Functional Package for SSH Version 1.0 Conformant.
+ - Conformance Statement
- An ST must claim exact conformance to this PP, as defined in the CC and CEM addenda for Exact Conformance, Selection-Based SFRs, and Optional SFRs (dated May 2017).
- CC Conformance Claims
- This PP is conformant to Parts 2 (extended) and 3 (extended) of Common Criteria Version 3.1, Revision 5.
- PP Claims
- Package Claims
3 Security Problem Definition
- The security problem is described in terms of the threats that the TOE is expected to address, assumptions about the operational environment, and any organizational security policies that the TOE is expected to enforce.
+ The security problem is described in terms of the threats that the TOE is expected to address, assumptions about the operational environment, and any organizational security policies that the TOE is expected to enforce.
3.1 Threats
- - T.LOCAL_ATTACK
- An attacker can act through unprivileged software on the same computingplatform on which the application executes. Attackers may provide maliciously formattedinput to the application in the form of files or other localcommunications.
- T.NETWORK_ATTACK
- An attacker is positioned on a communications channel or elsewhere on thenetwork infrastructure. Attackers may engage in communications with the applicationsoftware or alter communications between the application software and other endpoints inorder to compromise it.
- T.NETWORK_EAVESDROP
- An attacker is positioned on a communications channel or elsewhere on thenetwork infrastructure. Attackers may monitor and gain access to data exchanged betweenthe application and other endpoints.
- T.PHYSICAL_ACCESS
- An attacker may try to access sensitive data at rest.
+ - T.LOCAL_ATTACK
- An attacker can act through unprivileged software on the same computingplatform on which the application executes. Attackers may provide maliciously formattedinput to the application in the form of files or other localcommunications.
- T.NETWORK_ATTACK
- An attacker is positioned on a communications channel or elsewhere on thenetwork infrastructure. Attackers may engage in communications with the applicationsoftware or alter communications between the application software and other endpoints inorder to compromise it.
- T.NETWORK_EAVESDROP
- An attacker is positioned on a communications channel or elsewhere on thenetwork infrastructure. Attackers may monitor and gain access to data exchanged betweenthe application and other endpoints.
- T.PHYSICAL_ACCESS
- An attacker may try to access sensitive data at rest.
3.2 Assumptions
- - A.PLATFORM
- The TOE relies upon a trustworthy computing platform with a reliable time clock for its execution. This includes the underlying platform and whatever runtime environment it provides to the TOE.
- A.PROPER_ADMIN
- The administrator of the application software is not careless, willfully negligent or hostile, and administers the software in compliance with the applied enterprise security policy.
- A.PROPER_USER
- The user of the application software is not willfully negligent or hostile, and uses the software in compliance with the applied enterprise security policy.
+ - A.PLATFORM
- The TOE relies upon a trustworthy computing platform with a reliable time clock for its execution. This includes the underlying platform and whatever runtime environment it provides to the TOE.
- A.PROPER_ADMIN
- The administrator of the application software is not careless, willfully negligent or hostile, and administers the software in compliance with the applied enterprise security policy.
- A.PROPER_USER
- The user of the application software is not willfully negligent or hostile, and uses the software in compliance with the applied enterprise security policy.
3.3 Organizational Security Policies
- This document does not define any additional OSPs.
+ This document does not define any additional OSPs.
4 Security Objectives
4.1 Security Objectives for the TOE
- - O.INTEGRITY
- Conformant TOEs ensure the integrity of their installation and update packages, and also leverage execution environment-based mitigations. Software is seldom, if ever, shipped without errors. The ability to deploy patches and updates to fielded software with integrity is critical to enterprise network security. Processor manufacturers, compiler developers, execution environment vendors, and operating system vendors have developed execution environment-based mitigations that increase the cost to attackers by adding complexity to the task of compromising systems. Application software can often take advantage of these mechanisms by using APIs provided by the runtime environment or by enabling the mechanism through compiler or linker options.
- O.MANAGEMENT
- To facilitate management by users and the enterprise, conformant TOEs provide consistent and supported interfaces for their security-relevant configuration and maintenance. This includes the deployment of applications and application updates through the use of platform-supported deployment mechanisms and formats, as well as providing mechanisms for configuration. This also includes providing control to the user regarding disclosure of any PII.
- O.PROTECTED_COMMS
- To address both passive (eavesdropping) and active (packet modification) network attack threats, conformant TOEs will use a trusted channel for sensitive data. Sensitive data includes cryptographic keys, passwords, and any other data specific to the application that should not be exposed outside of the application.
- O.PROTECTED_STORAGE
- To address the issue of loss of confidentiality of user data in the event of loss of physical control of the storage medium, conformant TOEs will use data-at-rest protection. This involves encrypting data and keys stored by the TOE in order to prevent unauthorized access to this data. This also includes unnecessary network communications whose consequence may be the loss of data.
- O.QUALITY
- To ensure quality of implementation, conformant TOEs leverage services and APIs provided by the runtime environment rather than implementing their own versions of these services and APIs. This is especially important for cryptographic services and other complex operations such as file and media parsing. Leveraging this platform behavior relies upon using only documented and supported APIs.
+ - O.INTEGRITY
- Conformant TOEs ensure the integrity of their installation and update packages, and also leverage execution environment-based mitigations. Software is seldom, if ever, shipped without errors. The ability to deploy patches and updates to fielded software with integrity is critical to enterprise network security. Processor manufacturers, compiler developers, execution environment vendors, and operating system vendors have developed execution environment-based mitigations that increase the cost to attackers by adding complexity to the task of compromising systems. Application software can often take advantage of these mechanisms by using APIs provided by the runtime environment or by enabling the mechanism through compiler or linker options.
- O.MANAGEMENT
- To facilitate management by users and the enterprise, conformant TOEs provide consistent and supported interfaces for their security-relevant configuration and maintenance. This includes the deployment of applications and application updates through the use of platform-supported deployment mechanisms and formats, as well as providing mechanisms for configuration. This also includes providing control to the user regarding disclosure of any PII.
- O.PROTECTED_COMMS
- To address both passive (eavesdropping) and active (packet modification) network attack threats, conformant TOEs will use a trusted channel for sensitive data. Sensitive data includes cryptographic keys, passwords, and any other data specific to the application that should not be exposed outside of the application.
- O.PROTECTED_STORAGE
- To address the issue of loss of confidentiality of user data in the event of loss of physical control of the storage medium, conformant TOEs will use data-at-rest protection. This involves encrypting data and keys stored by the TOE in order to prevent unauthorized access to this data. This also includes unnecessary network communications whose consequence may be the loss of data.
- O.QUALITY
- To ensure quality of implementation, conformant TOEs leverage services and APIs provided by the runtime environment rather than implementing their own versions of these services and APIs. This is especially important for cryptographic services and other complex operations such as file and media parsing. Leveraging this platform behavior relies upon using only documented and supported APIs.
4.2 Security Objectives for the Operational Environment
- - OE.PLATFORM
- The TOE relies upon a trustworthy computing platform for its execution. This includes the underlying operating system and any discrete execution environment provided to the TOE.
- OE.PROPER_ADMIN
- The administrator of the application software is not careless, willfully negligent or hostile, and administers the software within compliance of the applied enterprise security policy.
- OE.PROPER_USER
- The user of the application software is not willfully negligent or hostile, and uses the software within compliance of the applied enterprise security policy.
+ - OE.PLATFORM
- The TOE relies upon a trustworthy computing platform for its execution. This includes the underlying operating system and any discrete execution environment provided to the TOE.
- OE.PROPER_ADMIN
- The administrator of the application software is not careless, willfully negligent or hostile, and administers the software within compliance of the applied enterprise security policy.
- OE.PROPER_USER
- The user of the application software is not willfully negligent or hostile, and uses the software within compliance of the applied enterprise security policy.
4.3 Security Objectives Rationale
This section describes how the assumptions, threats, and organizational
- security policies map to the security objectives.
+ security policies map to the security objectives.
5 Security Requirements
- This chapter describes the security requirements which have to be fulfilled by the product under evaluation. Those requirements comprise functional components from Part 2 and assurance components from Part 3 of
- [CC].
+ This chapter describes the security requirements which have to be fulfilled by the product under evaluation. Those requirements comprise functional components from Part 2 and assurance components from Part 3 of
+ [CC].
The following conventions are used for the completion of operations:
-
Refinement operation (denoted by bold text or
strikethrough
text): Is used to add details to a requirement or to remove part of the requirement that is made irrelevant
- through the completion of another operation, and thus further restricts a requirement.
+ through the completion of another operation, and thus further restricts a requirement.
-
Selection (denoted by italicized text): Is used to select one or more options
- provided by the [CC] in stating a requirement.
+ provided by the [CC] in stating a requirement.
-
Assignment operation (denoted by italicized text): Is used to assign a
- specific value to an unspecified parameter, such as the length of a password. Showing the
- value in square brackets indicates assignment.
+ specific value to an unspecified parameter, such as the length of a password. Showing the
+ value in square brackets indicates assignment.
-
Iteration operation: Is indicated by appending the SFR name with a slash and unique identifier
- suggesting the purpose of the operation, e.g. "/EXAMPLE1."
+ suggesting the purpose of the operation, e.g. "/EXAMPLE1."
@@ -792,19 +792,19 @@ 5.1 Security Functional Requireme
5.1.1 Class: Cryptographic Support (FCS)
FCS_CKM.1 Cryptographic Key Generation Services
- The application shall[ selection: generate no asymmetric cryptographic keys, invoke platform-provided functionality for asymmetric key generation, implement asymmetric key generation] .
The evaluator shall inspect the application and its developer documentation
- to determine if the application needs asymmetric key generation services . If not, the
+ to determine if the application needs asymmetric key generation services . If not, the
evaluator shall verify the generate no asymmetric cryptographic keys selection is present
- in the ST. Otherwise, the evaluation activities shall be performed as stated in the
- selection-based requirements .
- Guidance
- Tests
+ in the ST. Otherwise, the evaluation activities shall be performed as stated in the
+ selection-based requirements .
+ Guidance
+ Tests
5.1.1 Class: Cryptographic Support
FCS_RBG_EXT.1 Random Bit Generation Services
- The application shall[ selection: use no DRBG functionality, invoke platform-provided DRBG functionality, implement DRBG functionality]for its cryptographic operations .
If " use no DRBG functionality" is selected, the evaluator shall inspect the application
- and its developer documentation and verify that the application needs no random bit generation services .
+ and its developer documentation and verify that the application needs no random bit generation services .
If " implement DRBG functionality" is selected, the evaluator shall ensure
- that additional FCS_RBG_EXT.2 elements are included in the ST.
+ that additional FCS_RBG_EXT.2 elements are included in the ST.
If " invoke platform-provided DRBG functionality" is selected, the evaluator
- performs the following activities . The evaluator shall examine
+ performs the following activities . The evaluator shall examine
the TSS to confirm that it identifies all functions (as described by the
- SFRs included in the ST) that obtain random numbers from the platform RBG . The evaluator
+ SFRs included in the ST) that obtain random numbers from the platform RBG . The evaluator
shall determine that for each of these functions, the TSS states which
- platform interface ( API) is used to obtain the random numbers . The evaluator shall confirm
+ platform interface (API) is used to obtain the random numbers . The evaluator shall confirm
that each of these interfaces corresponds to the acceptable interfaces listed for each platform
- below .
+ below .
It should be noted that there is no expectation that the evaluators attempt to confirm
that the APIs are being used correctly for the functions identified in the TSS;
- the activity is to list the used APIs and then do an existence check via decompilation .
- Guidance
+ the activity is to list the used APIs and then do an existence check via decompilation .
+ Guidance
Tests
If " invoke platform-provided DRBG functionality" is selected, the following tests shall be performed:
The evaluator shall decompile the application binary using a decompiler
- suitable for the application ( TOE) . The evaluator shall search the output of the
- decompiler to determine that, for each API listed in the TSS, that API
- appears in the output . If the representation of the API does not correspond directly to
+ suitable for the application ( TOE) . The evaluator shall search the output of the
+ decompiler to determine that, for each API listed in the TSS, that API
+ appears in the output . If the representation of the API does not correspond directly to
the strings in the following list, the evaluator shall provide a mapping from the
- decompiled text to its corresponding API, with a description of why the API text does
+ decompiled text to its corresponding API, with a description of why the API text does
not directly correspond to the decompiled text and justification that the decompiled text
- corresponds to the associated API.
+ corresponds to the associated API .
The following are the per-platform list of acceptable APIs:
@@ -879,7 +879,7 @@ 5.1.1 Class: Cryptographic Support
The evaluator shall verify that the application uses at least one of javax.crypto.KeyGenerator
class or the java.security.SecureRandom class or /dev/random
- or /dev/urandom.
+ or /dev/urandom.
@@ -888,13 +888,13 @@ 5.1.1 Class: Cryptographic Support
The evaluator shall verify that rand_s, RtlGenRandom, BCryptGenRandom, or
- CryptGenRandom API is used for classic desktop applications. The evaluator shall
+ CryptGenRandom API is used for classic desktop applications. The evaluator shall
verify the application uses the RNGCryptoServiceProvider class or derives a class
- from System.Security.Cryptography.RandomNumberGenerator API for Windows Universal
- Applications. It is only required that the API is called/invoked, there is no
- requirement that the API be used directly. In future versions of this document,
- CryptGenRandom may be removed as an option as it is no longer the preferred API per
- vendor documentation.
+ from System.Security.Cryptography.RandomNumberGenerator API for Windows Universal
+ Applications. It is only required that the API is called/invoked, there is no
+ requirement that the API be used directly. In future versions of this document,
+ CryptGenRandom may be removed as an option as it is no longer the preferred API per
+ vendor documentation.
@@ -903,7 +903,7 @@ 5.1.1 Class: Cryptographic Support
The evaluator shall verify that the application invokes either
- SecRandomCopyBytes, CCRandomGenerateBytes, or CCRandomCopyBytes, or uses /dev/random directly to acquire random.
+ SecRandomCopyBytes, CCRandomGenerateBytes, or CCRandomCopyBytes, or uses /dev/random directly to acquire random.
@@ -912,7 +912,7 @@ 5.1.1 Class: Cryptographic Support
The evaluator shall verify that the application collects random from /dev/random
- or /dev/urandom.
+ or /dev/urandom.
@@ -920,7 +920,7 @@ 5.1.1 Class: Cryptographic Support
- The evaluator shall verify that the application collects random from /dev/random.
+ The evaluator shall verify that the application collects random from /dev/random.
@@ -928,7 +928,7 @@ 5.1.1 Class: Cryptographic Support
- The evaluator shall verify that the application invokes either CCRandomGenerateBytes or CCRandomCopyBytes, or collects random from /dev/random.
+ The evaluator shall verify that the application invokes either CCRandomGenerateBytes or CCRandomCopyBytes, or collects random from /dev/random.
@@ -937,41 +937,41 @@ 5.1.1 Class: Cryptographic Support
FCS_STO_EXT.1 Storage of Credentials
- The application shall[ selection: - not store any credentials
- invoke the functionality provided by the platform to securely store [assignment:
- list of credentials ]
- implement functionality to securely store [assignment:
- list of credentials ] according to [selection: FCS_COP.1/SKC, FCS_CKM.1/PBKDF]
]to non-volatile memory .
The evaluator shall check the TSS to ensure that it lists all persistent
credentials (secret keys, PKI private keys, or passwords) needed to meet the
- requirements in the ST. For each of these items, the evaluator shall
- confirm that the TSS lists for what purpose it is used, and how it is stored .
- Guidance
+ requirements in the ST. For each of these items, the evaluator shall
+ confirm that the TSS lists for what purpose it is used, and how it is stored .
+ Guidance
Tests
For all credentials for which the application implements functionality, the evaluator shall
verify credentials are encrypted according to FCS_COP.1/SKC or conditioned according to
- FCS_CKM.1.1/AK and FCS_CKM.1/PBKDF. For all credentials for which the application invokes platform-provided
- functionality, the evaluator shall perform the following actions which vary per platform .
+ FCS_CKM.1.1/AK and FCS_CKM.1/PBKDF. For all credentials for which the application invokes platform-provided
+ functionality, the evaluator shall perform the following actions which vary per platform .
@@ -980,11 +980,11 @@ 5.1.1 Class: Cryptographic Support
The evaluator shall verify that all certificates are
- stored in the Windows Certificate Store. The evaluator shall verify that other
+ stored in the Windows Certificate Store. The evaluator shall verify that other
credentials, like passwords, are stored in the Windows Credential Manager or stored
- using the Data Protection API (DPAPI). For Windows Universal Applications, the evaluator shall
+ using the Data Protection API (DPAPI). For Windows Universal Applications, the evaluator shall
verify that the application is using the ProtectData class and storing credentials
- in IsolatedStorage.
+ in IsolatedStorage.
@@ -993,7 +993,7 @@ 5.1.1 Class: Cryptographic Support
The evaluator shall verify that all credentials are stored
- within a Keychain.
+ within a Keychain.
@@ -1002,7 +1002,7 @@ 5.1.1 Class: Cryptographic Support
- The evaluator shall verify that all keys are stored using Linux keyrings.
+ The evaluator shall verify that all keys are stored using Linux keyrings.
@@ -1011,7 +1011,7 @@ 5.1.1 Class: Cryptographic Support
The evaluator shall verify that all keys are stored using Solaris
- Key Management Framework (KMF).
+ Key Management Framework (KMF).
@@ -1019,7 +1019,7 @@ 5.1.1 Class: Cryptographic Support
The evaluator shall verify that all credentials are
- stored within Keychain.
+ stored within Keychain.
@@ -1028,40 +1028,40 @@ 5.1.1 Class: Cryptographic Support
5.1.2 Class: User Data Protection (FDP)
FDP_DAR_EXT.1 Encryption Of Sensitive Application Data
- The application shall[ selection: leverage platform-provided functionality to encrypt sensitive data, implement functionality to encrypt sensitive data as defined in the PP-Module for File Encryption, protect sensitive data in accordance with FCS_STO_EXT.1, not store any sensitive data]in non-volatile memory .
- The evaluator shall examine the TSS to ensure that it describes the sensitive data processed by the application .
- The evaluator shall then ensure that the following activities cover all of the sensitive data identified in the TSS.
+ The evaluator shall examine the TSS to ensure that it describes the sensitive data processed by the application .
+ The evaluator shall then ensure that the following activities cover all of the sensitive data identified in the TSS.
If not store any sensitive data is selected, the evaluator shall inspect the TSS to ensure
- that it describes how sensitive data cannot be written to non-volatile memory . The evaluator shall also
- ensure that this is consistent with the filesystem test below .
- Guidance
+ that it describes how sensitive data cannot be written to non-volatile memory . The evaluator shall also
+ ensure that this is consistent with the filesystem test below .
+ Guidance
Tests
Evaluation activities (after the identification of the sensitive data) are to be performed on all sensitive data listed
- that are not covered by FCS_STO_EXT.1.
- The evaluator shall inventory the filesystem locations where the application may write data .
- The evaluator shall run the application and attempt to store sensitive data . The evaluator shall
+ that are not covered by FCS_STO_EXT.1.
+ The evaluator shall inventory the filesystem locations where the application may write data .
+ The evaluator shall run the application and attempt to store sensitive data . The evaluator shall
then inspect those areas of the filesystem to note where data was stored (if any), and determine
- whether it has been encrypted .
+ whether it has been encrypted .
If " leverage platform-provided functionality" is selected, the evaluation activities will be performed as
- stated in the following requirements, which vary on a per-platform basis .
+ stated in the following requirements, which vary on a per-platform basis .
@@ -1070,9 +1070,9 @@ 5.1.2 Class: User Data Protection
The Windows platform currently does not provide data-at-rest
- encryption services which depend upon invocation by application developers. The evaluator shall
+ encryption services which depend upon invocation by application developers. The evaluator shall
verify that the Operational User Guidance makes the need to activate platform encryption,
- such as BitLocker or Encrypting File System (EFS), clear to the end user.
+ such as BitLocker or Encrypting File System (EFS), clear to the end user.
@@ -1082,7 +1082,7 @@ 5.1.2 Class: User Data Protection
The evaluator shall inspect the TSS and ensure that it describes how the
application uses the Complete Protection, Protected Unless Open, or Protected Until
- First User Authentication Data Protection Class for each data file stored locally.
+ First User Authentication Data Protection Class for each data file stored locally.
@@ -1092,9 +1092,9 @@ 5.1.2 Class: User Data Protection
The Linux platform currently does not provide data-at-rest encryption services which depend
- upon invocation by application developers. The evaluator shall verify that
+ upon invocation by application developers. The evaluator shall verify that
the Operational User Guidance makes the need to activate platform encryption clear
- to the end user.
+ to the end user.
@@ -1103,9 +1103,9 @@ 5.1.2 Class: User Data Protection
The Solaris platform currently does not provide data-at-rest encryption services which depend
- upon invocation by application developers. The evaluator shall verify that
+ upon invocation by application developers. The evaluator shall verify that
the Operational User Guidance makes the need to activate platform encryption clear
- to the end user.
+ to the end user.
@@ -1114,45 +1114,47 @@ 5.1.2 Class: User Data Protection
The macOS platform currently does not provide data-at-rest encryption services which depend
- upon invocation by application developers. The evaluator shall verify that
+ upon invocation by application developers. The evaluator shall verify that
the Operational User Guidance makes the need to activate platform encryption clear
- to the end user.
+ to the end user.
FDP_DEC_EXT.1 Access to Platform Resources
- The application shall restrict its access to[ selection: no hardware resources, network connectivity, camera, microphone, location services, NFC, USB, Bluetooth, list of additional hardware resources ] .
-
+
Guidance The evaluator shall perform the platform-specific actions below and inspect user
documentation to determine the application's access to hardware
- resources . The evaluator shall ensure that this is consistent with the selections
- indicated . The evaluator shall review documentation provided by the application
+ resources . The evaluator shall ensure that this is consistent with the selections
+ indicated . The evaluator shall review documentation provided by the application
developer and for each resource which it accesses, identify the
- justification as to why access is required .
+ justification as to why access is required . Tests
@@ -1168,16 +1170,16 @@ 5.1.2 Class: User Data Protection
For Windows Universal Applications the evaluator shall check
- the WMAppManifest.xml file for a list of required hardware capabilities. The evaluator
+ the WMAppManifest.xml file for a list of required hardware capabilities. The evaluator
shall verify that the user is made aware of the required hardware capabilities when
- the application is first installed. This includes permissions such as
+ the application is first installed. This includes permissions such as
ID_CAP_ISV_CAMERA, ID_CAP_LOCATION, ID_CAP_NETWORKING, ID_CAP_MICROPHONE,
- ID_CAP_PROXIMITY and so on. A complete list of Windows App permissions can be found at:
+ ID_CAP_PROXIMITY and so on. A complete list of Windows App permissions can be found at:
For Windows Desktop Applications the evaluator shall identify in either the
application software or its documentation the list of the required
- hardware resources.
+ hardware resources.
@@ -1187,7 +1189,7 @@ 5.1.2 Class: User Data Protection
The evaluator shall verify that either the
application or the documentation provides a list of the
- hardware resources it accesses.
+ hardware resources it accesses.
@@ -1196,7 +1198,7 @@ 5.1.2 Class: User Data Protection
The evaluator shall verify that either the
application software or its documentation provides a list of the
- hardware resources it accesses.
+ hardware resources it accesses.
@@ -1205,7 +1207,7 @@ 5.1.2 Class: User Data Protection
The evaluator shall verify that either the
application software or its documentation provides a list of the
- hardware resources it accesses.
+ hardware resources it accesses.
@@ -1214,17 +1216,17 @@ 5.1.2 Class: User Data Protection
The evaluator shall verify that either the application
software or its documentation provides a list of the hardware
- resources it accesses.
+ resources it accesses.
-
+
Guidance The evaluator shall perform the platform-specific actions below and inspect user
documentation to determine the application's access to sensitive information
- repositories . The evaluator shall ensure that this is consistent with the selections
- indicated . The evaluator shall review documentation provided by the application
+ repositories . The evaluator shall ensure that this is consistent with the selections
+ indicated . The evaluator shall review documentation provided by the application
developer and for each sensitive information repository which it accesses, identify the
- justification as to why access is required .
+ justification as to why access is required . Tests
- Test FDP_DEC_EXT.1.2:1[conditional, Platforms:Android: Mobile operating systems based on Google Android.]:
@@ -1232,7 +1234,7 @@
5.1.2 Class: User Data Protection
The evaluator shall verify that each uses-permission entry in the AndroidManifest.xml file
- for access to a sensitive information repository is reflected in the selection.
+ for access to a sensitive information repository is reflected in the selection.
@@ -1241,16 +1243,16 @@ 5.1.2 Class: User Data Protection
For Windows Universal Applications the evaluator shall check the
- WMAppManifest.xml file for a list of required capabilities. The evaluator shall
+ WMAppManifest.xml file for a list of required capabilities. The evaluator shall
identify the required information repositories when the
- application is first installed. This includes permissions such as
- ID_CAP_CONTACTS,ID_CAP_APPOINTMENTS,ID_CAP_MEDIALIB and so on. A complete list of
+ application is first installed. This includes permissions such as
+ ID_CAP_CONTACTS,ID_CAP_APPOINTMENTS,ID_CAP_MEDIALIB and so on. A complete list of
Windows App permissions can be found at:
For Windows Desktop Applications the evaluator shall identify in either the
application software or its documentation the list of
- sensitive information repositories it accesses.
+ sensitive information repositories it accesses.
@@ -1260,7 +1262,7 @@ 5.1.2 Class: User Data Protection
The evaluator shall verify that either the application
software or its documentation provides a list of
- the sensitive information repositories it accesses.
+ the sensitive information repositories it accesses.
@@ -1277,7 +1279,7 @@ 5.1.2 Class: User Data Protection
The evaluator shall verify that either the
application software or its documentation provides a list of
- sensitive information repositories it accesses.
+ sensitive information repositories it accesses.
@@ -1286,25 +1288,26 @@ 5.1.2 Class: User Data Protection
The evaluator shall verify that either the application
software or its documentation provides a list of
- sensitive information repositories it accesses.
+ sensitive information repositories it accesses.
FDP_NET_EXT.1 Network Communications
- The application shall restrict network communication to[ selection: no network communication, user-initiated communication for [assignment:
- list of functions for which the user can initiate network communication ], respond to [assignment:
- list of remotely initiated communication ], list of application-initiated network communication ] .
-
- Guidance
+
+ Guidance
Tests
The evaluator shall perform the following tests:
@@ -1313,19 +1316,19 @@ 5.1.2 Class: User Data Protection
Test FDP_NET_EXT.1.1:1:
- The evaluator shall run the application. While the application is running,
+ The evaluator shall run the application. While the application is running,
the evaluator shall sniff network traffic ignoring all non-application
associated traffic
- and verify that any network communications witnessed are documented in the TSS or are user-initiated.
+ and verify that any network communications witnessed are documented in the TSS or are user-initiated.
Test FDP_NET_EXT.1.1:2:
- The evaluator shall run the application. After the application initializes, the
+ The evaluator shall run the application. After the application initializes, the
evaluator shall run network port scans to verify that any ports
opened by the application have been captured in the ST for the third
- selection and its assignment. This includes
- connection-based protocols (e.g. TCP, DCCP) as well as connectionless protocols
- (e.g. UDP).
+ selection and its assignment . This includes
+ connection-based protocols (e.g . TCP, DCCP) as well as connectionless protocols
+ (e.g . UDP) .
- Test FDP_NET_EXT.1.1:3[conditional, Platforms:Android: Mobile operating systems based on Google Android.]:
@@ -1334,9 +1337,9 @@
5.1.2 Class: User Data Protection
If "no network communication" is selected, the evaluator shall ensure that the application's
AndroidManifest.xml file does not contain a uses-permission or uses-permission-sdk-23 tag
- containing android:name="android.permission.INTERNET". In this case,
+ containing android:name="android.permission.INTERNET". In this case,
it is not necessary to perform the above Tests 1 and 2, as the platform will not allow the
- application to perform any network communication.
+ application to perform any network communication.
@@ -1348,55 +1351,55 @@ 5.1.2 Class: User Data Protection
5.1.3 Class: Security Management (FMT)
FMT_CFG_EXT.1 Secure by Default Configuration
- The application shall provide only enough functionality to set new credentials when configured with default credentials or no credentials .
The evaluator shall check the TSS to determine if the application requires any type
- of credentials and if the application installs with default credentials .
- Guidance
+ of credentials and if the application installs with default credentials .
+ Guidance
Tests
- If the application uses any default credentials the evaluator shall run the following tests.
+ If the application uses any default credentials the evaluator shall run the following tests.
- Test FMT_CFG_EXT.1.1:1:
The evaluator shall install and run the application without generating or loading
new credentials and verify that only the minimal
- application functionality required to set new credentials is available.
+ application functionality required to set new credentials is available.
- Test FMT_CFG_EXT.1.1:2:
The evaluator shall attempt to clear all credentials and verify that only
- the minimal application functionality required to set new credentials is available.
+ the minimal application functionality required to set new credentials is available.
- Test FMT_CFG_EXT.1.1:3:
The evaluator shall run the application, establish new credentials and
verify that the original default credentials no longer provide access to
- the application.
+ the application.
-
- Guidance
+
+ Guidance
Tests
- The evaluator shall install and run the application . The evaluator shall
+ The evaluator shall install and run the application . The evaluator shall
inspect the filesystem of the platform (to the extent possible) for any files created
- by the application and ensure that their permissions are adequate to protect them . The method of doing so varies per platform .
+ by the application and ensure that their permissions are adequate to protect them . The method of doing so varies per platform .
- Test FMT_CFG_EXT.1.2:1[conditional, Platforms:Android: Mobile operating systems based on Google Android.]:
- The evaluator shall run the command
find -L . -perm /002
- inside the application's data directories to ensure that all files are not world-writable. The command
- should not print any files.
+ The evaluator shall run the command find -L . -perm /002
+ inside the application's data directories to ensure that all files are not world-writable. The command
+ should not print any files.
@@ -1407,9 +1410,9 @@ 5.1.3 Class: Security Management (
Process Monitor and Access Check (or tools of equivalent capability, like
icacls.exe) for Classic Desktop applications to verify that files written to disk
during an application's installation have the correct file permissions, such that a
- standard user cannot modify the application or its data files. For Windows Universal
+ standard user cannot modify the application or its data files. For Windows Universal
Applications the evaluator shall consider the requirement met because of the AppContainer
- sandbox.
+ sandbox.
@@ -1418,16 +1421,16 @@ 5.1.3 Class: Security Management (
The evaluator shall determine whether the application
leverages the appropriate Data Protection Class for each data file stored
- locally.
+ locally.
@@ -1435,9 +1438,9 @@ 5.1.3 Class: Security Management (
- The evaluator shall run the command find . \( -perm -002 \)
+ The evaluator shall run the command find . \( -perm -002 \)
inside the application's data directories to ensure that all files are not
- world-writable. The command should not print any files.
+ world-writable. The command should not print any files.
@@ -1445,8 +1448,8 @@ 5.1.3 Class: Security Management (
- The evaluator shall run the command find . -perm +002 inside
- the application's data directories to ensure that all files are not world-writable. The command should not print any files.
+ The evaluator shall run the command find . -perm +002 inside
+ the application's data directories to ensure that all files are not world-writable. The command should not print any files.
@@ -1456,22 +1459,22 @@ 5.1.3 Class: Security Management (
The application shall[ selection: invoke the mechanisms recommended by the platform vendor for storing and setting configuration options, implement functionality to encrypt and store configuration options as defined by FDP_PRT_EXT.1 in the PP-Module for File Encryption]
- Configuration options that are stored remotely are not subject to this requirement.
+ 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.
+ 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.
The evaluator shall review the TSS to identify the application's configuration options
- (e.g . settings) and determine whether these are stored and set using the mechanisms
- supported by the platform or implemented by the application in accordance with the PP-Module for File Encryption .
+ (e.g . settings) and determine whether these are stored and set using the mechanisms
+ supported by the platform or implemented by the application in accordance with the PP-Module for File Encryption .
At a minimum the TSS shall list settings related to any SFRs and any settings that are mandated in the
- operational guidance in response to an SFR.
+ operational guidance in response to an SFR.
Conditional: If "implement functionality to encrypt and store configuration options as defined by FDP_PRT_EXT.1
in the PP-Module for File Encryption" is selected, the evaluator shall ensure that the TSS identifies those options,
- as well as indicates where the encrypted representation of these options is stored .
- Guidance
+ as well as indicates where the encrypted representation of these options is stored .
+ Guidance
Tests
If "invoke the mechanisms recommended by the platform vendor for storing and setting configuration options" is chosen,
@@ -1482,12 +1485,12 @@ 5.1.3 Class: Security Management (
- The evaluator shall run the application and make security-related changes to its configuration. The evaluator shall check that at least one XML file at location
+ The evaluator shall run the application and make security-related changes to its configuration. The evaluator shall check that at least one XML file at location
reflects the changes made to the configuration to verify that the application used
SharedPreferences and/or PreferenceActivity classes
for storing configuration data, where package is the Java package
- of the application.
+ of the application.
@@ -1496,32 +1499,32 @@ 5.1.3 Class: Security Management (
The evaluator shall determine and verify that Windows
Universal Applications use either the Windows.Storage namespace, Windows.UI.ApplicationSettings namespace,
- or the IsolatedStorageSettings namespace for storing application specific settings. For .NET applications, the evaluator shall determine and verify that the application
+ or the IsolatedStorageSettings namespace for storing application specific settings. For .NET applications, the evaluator shall determine and verify that the application
uses one of the locations listed in
- https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/ for storing application specific settings. For Classic Desktop applications, the evaluator shall run the application while
+ https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/ for storing application specific settings. For Classic Desktop applications, the evaluator shall run the application while
monitoring it with the SysInternals tool and
- make changes to its configuration.
+ make changes to its configuration.
The evaluator shall verify that logs show corresponding changes to the
- the Windows Registry or C:\ProgramData\ directory.
+ the Windows Registry or C:\ProgramData\ directory.
- Test FMT_MEC_EXT.1.1:4[conditional, Platforms:Linux: Linux-based operating systems other than Android.]:
- The evaluator shall run the application while monitoring it with the utility . The evaluator shall make security-related changes to its configuration. The evaluator shall verify that logs corresponding changes to configuration
+ The evaluator shall run the application while monitoring it with the utility . The evaluator shall make security-related changes to its configuration. The evaluator shall verify that logs corresponding changes to configuration
files that reside in /etc (for system-specific configuration),
in the user's home directory (for user-specific configuration), or /var/lib/ (for configurations
- controlled by UI and not intended to be directly modified by an administrator).
+ controlled by UI and not intended to be directly modified by an administrator).
@@ -1530,10 +1533,10 @@ 5.1.3 Class: Security Management (
The evaluator shall run the application while monitoring it with the utility
- . The evaluator shall make security-related changes to its configuration. The evaluator shall verify that logs corresponding changes to
+ . The evaluator shall make security-related changes to its configuration. The evaluator shall verify that logs corresponding changes to
configuration
files that reside in /etc (for system-specific configuration) or
- in the user's home directory(for user-specific configuration).
+ in the user's home directory(for user-specific configuration).
@@ -1542,7 +1545,7 @@ 5.1.3 Class: Security Management (
The evaluator shall verify that the application stores and retrieves settings
- using the NSUserDefaults class.
+ using the NSUserDefaults class.
@@ -1550,49 +1553,50 @@ 5.1.3 Class: Security Management (
FMT_SMF.1 Specification of Management Functions
The TSF shall be capable of performing the following management functions[ selection: no management functions, enable/disable the transmission of any information describing the
- system's hardware, software, or configuration, enable/disable the transmission of any PII, enable/disable transmission of any application state (e.g. crashdump)
- information, enable/disable network backup functionality to [assignment:
- list of enterprise or commercial cloud backup systems ], list of other management functions to be provided bythe TSF ] . , enable/disable the transmission of any PII, enable/disable transmission of any application state (e.g. crashdump)
+ information, enable/disable network backup functionality to [assignment:
+ list of enterprise or commercial cloud backup systems ], [assignment:
+ list of other management functions to be provided bythe TSF ]] .
This requirement stipulates that an application needs to provide the ability to
- enable/disable only those functions that it actually implements. The application
- is not responsible for controlling the behavior of the platform or other applications.
+ enable/disable only those functions that it actually implements . The application
+ is not responsible for controlling the behavior of the platform or other applications .
-
+
Guidance
The evaluator shall verify that every management function
mandated by the PP is described in the operational guidance and that the description
contains the information required to perform the management duties associated with the
- management function .
+ management function . Tests
The evaluator shall test the application's ability to provide the
management functions by configuring the application and testing each option selected
- from above . The evaluator is expected to test these functions in all the ways in which
- the ST and guidance documentation state the configuration can be managed .
+ from above . The evaluator is expected to test these functions in all the ways in which
+ the ST and guidance documentation state the configuration can be managed . 5.1.4 Class: Privacy (FPR)
FPR_ANO_EXT.1 User Consent for Transmission of Personally Identifiable Information
- The application shall[ selection: not transmit PII over a network, require user approval before executing [assignment:
- list of functions that transmit PII over a network ]] .
@@ -1600,60 +1604,60 @@ 5.1.5 Class: Protection of the TSF
FPT_AEX_EXT.1 Anti-Exploitation Capabilities
The application shall not request to map memory at an explicit address except for[ assignment:
- list of explicit exceptions] .
- The application shall[ selection: not allocate any memory region with both write and execute permissions, allocate memory regions with write and execute permissions for only [assignment:
- list of functions performing just-in-time compilation ]] .
+ The application shall be built with stack-based buffer overflow protection enabled .
The evaluator shall ensure that the TSS describes the compiler flags used to
- enable ASLR when the application is compiled .
- Guidance
+ enable ASLR when the application is compiled .
+ Guidance
Tests
The evaluator shall perform either a static or dynamic
analysis to determine that no memory mappings are placed at an explicit and
- consistent address . The method of doing so varies per platform . For those platforms
+ consistent address . The method of doing so varies per platform . For those platforms
requiring the same application running on two different systems, the evaluator may
- alternatively use the same device . After collecting the first instance of mappings,
+ alternatively use the same device . After collecting the first instance of mappings,
the evaluator must uninstall the application, reboot the device, and reinstall the application
- to collect the second instance of mappings .
+ to collect the second instance of mappings .
- Test FPT_AEX_EXT.1.1:1[conditional, Platforms:Android: Mobile operating systems based on Google Android.]:
The evaluator shall run the same application on two
- different Android systems. Both devices do not need to be evaluated, as the second device is acting only as a tool.
- Connect via ADB and inspect /proc/PID/maps. Ensure the two different instances share no memory mappings made by the
- application at the same location.
+ different Android systems. Both devices do not need to be evaluated, as the second device is acting only as a tool.
+ Connect via ADB and inspect /proc/PID/maps. Ensure the two different instances share no memory mappings made by the
+ application at the same location.
@@ -1663,11 +1667,11 @@ 5.1.5 Class: Protection of the TSF
The evaluator shall run the same application on two
different Windows systems and run a tool that will list all memory mapped addresses
- for the application. The evaluator shall then verify the two different instances
- share no mapping locations. The Microsoft SysInternals tool, VMMap, could be used to
- view memory addresses of a running application. The evaluator shall use a tool
+ for the application. The evaluator shall then verify the two different instances
+ share no mapping locations. The Microsoft SysInternals tool, VMMap, could be used to
+ view memory addresses of a running application. The evaluator shall use a tool
such as Microsoft's BinScope Binary Analyzer to confirm that the application has
- ASLR enabled.
+ ASLR enabled.
@@ -1676,8 +1680,8 @@ 5.1.5 Class: Protection of the TSF
The evaluator shall perform a static analysis to search
- for any mmap calls (or API calls that call mmap), and ensure that
- no arguments are provided that request a mapping at a fixed address.
+ for any mmap calls (or API calls that call mmap), and ensure that
+ no arguments are provided that request a mapping at a fixed address.
@@ -1685,10 +1689,10 @@ 5.1.5 Class: Protection of the TSF
- The evaluator shall run the same application on two different Linux systems.
+ The evaluator shall run the same application on two different Linux systems.
The evaluator shall then compare their memory maps using
pmap -x PID
- to ensure the two different instances share no mapping locations.
+ to ensure the two different instances share no mapping locations.
@@ -1696,10 +1700,10 @@ 5.1.5 Class: Protection of the TSF
- The evaluator shall run the same application on two different Solaris systems.
+ The evaluator shall run the same application on two different Solaris systems.
The evaluator shall then compare their memory maps using
pmap -x PID
- to ensure the two different instances share no mapping locations.
+ to ensure the two different instances share no mapping locations.
@@ -1707,27 +1711,27 @@ 5.1.5 Class: Protection of the TSF
- The evaluator shall run the same application on two different Mac systems.
+ The evaluator shall run the same application on two different Mac systems.
The evaluator shall then compare their memory maps using
vmmap PID
- to ensure the two different instances share no mapping locations.
+ to ensure the two different instances share no mapping locations.
-
- Guidance
+
+ Guidance
Tests
The evaluator shall verify that no memory mapping requests are made with write and
- execute permissions . The method of doing so varies per platform .
+ execute permissions . The method of doing so varies per platform .
@@ -1736,9 +1740,9 @@ 5.1.5 Class: Protection of the TSF
The evaluator shall use a tool such as Microsoft's
- BinScope Binary Analyzer to confirm that the application passes the NXCheck. The
+ BinScope Binary Analyzer to confirm that the application passes the NXCheck. The
evaluator may also ensure that the /NXCOMPAT flag was used during
- compilation to verify that DEP protections are enabled for the application.
+ compilation to verify that DEP protections are enabled for the application.
@@ -1748,7 +1752,7 @@ 5.1.5 Class: Protection of the TSF
The evaluator shall perform static analysis on the
- application to verify that mprotect is never invoked with the PROT_EXEC permission.
+ application to verify that mprotect is never invoked with the PROT_EXEC permission.
@@ -1759,7 +1763,7 @@ 5.1.5 Class: Protection of the TSF
The evaluator shall perform static analysis on the
application to verify that both - mmap is never be invoked with both the PROT_WRITE and PROT_EXEC permissions,
- and
- mprotect is never invoked with the PROT_EXEC permission.
+ and mprotect is never invoked with the PROT_EXEC permission.
@@ -1769,7 +1773,7 @@ 5.1.5 Class: Protection of the TSF
The evaluator shall perform static analysis on the
application to verify that both - mmap is never be invoked with both the PROT_WRITE and PROT_EXEC permissions,
- and
- mprotect is never invoked with the PROT_EXEC permission.
+ and - mprotect is never invoked with the PROT_EXEC permission.
@@ -1778,13 +1782,13 @@ 5.1.5 Class: Protection of the TSF
The evaluator shall perform static analysis on the
- application to verify that mprotect is never invoked with the PROT_EXEC permission.
+ application to verify that mprotect is never invoked with the PROT_EXEC permission.
-
- Guidance
+
+ Guidance
Tests
The evaluator shall configure the platform in the ascribed manner and
@@ -1796,7 +1800,7 @@ 5.1.5 Class: Protection of the TSF
Applications running on Android cannot disable Android
- security features, therefore this requirement is met and no evaluation activity is required.
+ security features, therefore this requirement is met and no evaluation activity is required.
@@ -1804,18 +1808,18 @@ 5.1.5 Class: Protection of the TSF
- If the OS platform supports Windows Defender Exploit Guard
+ If the OS platform supports Windows Defender Exploit Guard
(Windows 10 version 1709 or later), then the evaluator shall ensure that the application can
run successfully with Windows Defender Exploit Guard Exploit Protection configured with the
following minimum mitigations enabled; Control Flow Guard (CFG), Randomize memory allocations
- (Bottom-Up ASLR), Export address filtering (EAF), Import address filtering (IAF), and
- Data Execution Prevention (DEP). The following link describes how to enable Exploit Protection,
- https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-exploit-guard/customize-exploit-protection.
- If the OS platform supports the Enhanced Mitigation Experience Toolkit (EMET) which can be
+ (Bottom-Up ASLR), Export address filtering (EAF), Import address filtering (IAF), and
+ Data Execution Prevention (DEP). The following link describes how to enable Exploit Protection,
+ https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-exploit-guard/customize-exploit-protection.
+ If the OS platform supports the Enhanced Mitigation Experience Toolkit (EMET) which can be
installed on Windows 10 version 1703 and earlier, then the evaluator shall ensure that
the application can run successfully with EMET configured with the following minimum
- mitigations enabled; Memory Protection Check, Randomize memory allocations (Bottom-Up ASLR),
- Export address filtering (EAF), and Data Execution Prevention (DEP).
+ mitigations enabled; Memory Protection Check, Randomize memory allocations (Bottom-Up ASLR),
+ Export address filtering (EAF), and Data Execution Prevention (DEP).
@@ -1824,7 +1828,7 @@ 5.1.5 Class: Protection of the TSF
Applications running on iOS cannot disable
- security features, therefore this requirement is met and no evaluation activity is required.
+ security features, therefore this requirement is met and no evaluation activity is required.
@@ -1833,7 +1837,7 @@ 5.1.5 Class: Protection of the TSF
The evaluator shall ensure that the application can
- successfully run on a system with either SELinux or AppArmor enabled and in enforce mode.
+ successfully run on a system with either SELinux or AppArmor enabled and in enforce mode.
@@ -1842,7 +1846,7 @@ 5.1.5 Class: Protection of the TSF
The evaluator shall ensure that the application can run with
- Solaris Trusted Extensions enabled and enforcing.
+ Solaris Trusted Extensions enabled and enforcing.
@@ -1851,25 +1855,25 @@ 5.1.5 Class: Protection of the TSF
The evaluator shall ensure that the application can
- successfully run on macOS without disabling any security features.
+ successfully run on macOS without disabling any security features.
-
- Guidance
+
+ Guidance
Tests
- The evaluator shall run the application and determine where it writes its files . For files where the user does not choose the destination, the evaluator shall
- check whether the destination directory contains executable files . This varies per platform:
+ The evaluator shall run the application and determine where it writes its files . For files where the user does not choose the destination, the evaluator shall
+ check whether the destination directory contains executable files . This varies per platform:
- Test FPT_AEX_EXT.1.4:1[conditional, Platforms:Android: Mobile operating systems based on Google Android.]:
- The evaluator shall run the program, mimicking normal usage, and note where all user-modifiable files are written.
- The evaluator shall ensure that there are no executable files stored under where package is the Java package of the application.
+ The evaluator shall run the program, mimicking normal usage, and note where all user-modifiable files are written.
+ The evaluator shall ensure that there are no executable files stored under where package is the Java package of the application.
@@ -1878,10 +1882,10 @@ 5.1.5 Class: Protection of the TSF
For Windows Universal Applications the evaluator shall consider
the requirement met because the platform forces applications to write all data
- within the application working directory (sandbox). For Windows Desktop Applications
+ within the application working directory (sandbox). For Windows Desktop Applications
the evaluator shall run the program, mimicking normal usage, and note where all user-modifiable
- files are written. The evaluator shall ensure that there are no executable files
- stored in the same directories to which the application wrote user-modifiable files.
+ files are written. The evaluator shall ensure that there are no executable files
+ stored in the same directories to which the application wrote user-modifiable files.
- Test FPT_AEX_EXT.1.4:4[conditional, Platforms:Linux: Linux-based operating systems other than Android.]:
@@ -1897,9 +1901,9 @@
5.1.5 Class: Protection of the TSF
The evaluator shall run the program, mimicking normal usage,
- and note where all user-modifiable files are written.
+ and note where all user-modifiable files are written.
The evaluator shall ensure that there are no executable files stored in the
- same directories to which the application wrote user-modifiable files.
+ same directories to which the application wrote user-modifiable files.
@@ -1908,9 +1912,9 @@ 5.1.5 Class: Protection of the TSF
The evaluator shall run the program, mimicking normal usage,
- and note where all user-modifiable files are written.
+ and note where all user-modifiable files are written.
The evaluator shall ensure that there are no executable files stored in the
- same directories to which the application wrote user-modifiable files.
+ same directories to which the application wrote user-modifiable files.
@@ -1918,47 +1922,47 @@ 5.1.5 Class: Protection of the TSF
The evaluator shall run the program, mimicking normal
- usage, and note where all user-modifiable files are written. The evaluator shall ensure that there
+ usage, and note where all user-modifiable files are written. The evaluator shall ensure that there
are no executable files stored in the same directories to which the application
- wrote user-modifiable files.
+ wrote user-modifiable files.
-
- Guidance
+
+ Guidance
Tests
The evaluator will inspect every native executable included in the TOE to ensure that stack-based buffer
- overflow protection is present .
+ overflow protection is present .
- Test FPT_AEX_EXT.1.5:1[conditional, Platforms:Microsoft Windows: Microsoft Windows operating systems.]:
Applications that run as Managed Code in the .NET Framework do not require
- these stack protections. Applications developed in Object Pascal using the Delphi IDE compiled with RangeChecking enabled
- comply with this element. For other code,
- the evaluator shall review the TSS and verify that the /GS flag was used during compilation. The
- evaluator shall run a tool like, BinScope, that can verify the correct usage of /GS.
+ these stack protections. Applications developed in Object Pascal using the Delphi IDE compiled with RangeChecking enabled
+ comply with this element. For other code,
+ the evaluator shall review the TSS and verify that the /GS flag was used during compilation. The
+ evaluator shall run a tool like, BinScope, that can verify the correct usage of /GS.
FPT_API_EXT.1 Use of Supported Services and APIs
- The application shall use only documented platform APIs .
The evaluator shall verify that the TSS lists the platform APIs
- used in the application .
- Guidance
+ used in the application .
+ Guidance
Tests
The evaluator shall then compare the list with the supported APIs
- (available through e.g . developer accounts, platform developer groups) and ensure that all
- APIs listed in the TSS are supported .
+ (available through e.g . developer accounts, platform developer groups) and ensure that all
+ APIs listed in the TSS are supported . 5.1.5 Class: Protection of the TSF
FPT_IDV_EXT.1 Software Identification and Versions
The application shall be versioned with[ selection: SWID tags
that comply with minimum requirements from ISO/IEC 19770-2:2015
- , other version information ] . , [assignment:
+ other version information ]] . The use of 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. The PP selection
+ the use of SCAP which includes SWID tags per the NIST standard. The PP selection
of "other version information" will be removed in the next major release of
- this protection profile. Vendors should begin to version software with valid SWID tags.
+ this protection profile. Vendors should begin to version software with valid SWID tags.
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.
+ 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 .
If "other version information" is selected the evaluator shall verify that the
- TSS contains an explanation of the versioning methodology .
- Guidance
+ TSS contains an explanation of the versioning methodology .
+ Guidance
Tests
The evaluator shall install the application, then check for the
- existence of version information . If SWID tags is selected the evaluator shall
- check for a .swidtag file . The evaluator shall open the file and verify that
- is contains at least a SoftwareIdentity element and an Entity element .
+ existence of version information . If SWID tags is selected the evaluator shall
+ check for a .swidtag file . The evaluator shall open the file and verify that
+ is contains at least a SoftwareIdentity element and an Entity element . FPT_LIB_EXT.1 Use of Third Party Libraries
The application shall be packaged with only[ assignment:
- list of third-party libraries] .
+ documentation of such libraries in case vulnerabilities are later discovered .
-
- Guidance
+
+ Guidance
Tests
The evaluator shall install the application and survey its installation directory for
- dynamic libraries .
+ dynamic libraries .
The evaluator shall verify that libraries found to be packaged with or employed by the
- application are limited to those in the assignment .
+ application are limited to those in the assignment . FPT_TUD_EXT.1 Integrity for Installation and Update
- The application shall[ selection: provide the ability, leverage the platform]to check for updates and patches to the application software .
+ Guidance
+ Tests
5.1.5 Class: Protection of the TSF
5.1.6 Class: Trusted Path/Channel (FTP)
FTP_DIT_EXT.1 Protection of Data in Transit
- The application shall[ selection: - not transmit any [selection: data, sensitive data]
- encrypt all transmitted [selection: sensitive data, data] with [selection: HTTPS as a client in accordance with FCS_HTTPS_EXT.1/Client, HTTPS as a server in accordance with FCS_HTTPS_EXT.1/Server, HTTPS as a server using mutual authentication in accordance with FCS_HTTPS_EXT.2, TLS as defined in the Functional Package for TLS, DTLS as defined in the Functional Package for TLS, SSH as defined in the Functional Package for Secure Shell, IPsec as defined in the PP-Module for VPN Client]
- invoke platform-provided functionality to encrypt all transmitted sensitive data with [selection: HTTPS, TLS, DTLS, SSH]
- invoke platform-provided functionality to encrypt all transmitted data with [selection: HTTPS, TLS, DTLS, SSH]
]between itself and another trusted IT product .
For platform-provided functionality, the evaluator shall verify the TSS contains
- the calls to the platform that TOE is leveraging to invoke the functionality .
- Guidance
+ the calls to the platform that TOE is leveraging to invoke the functionality .
+ Guidance
Tests
- The evaluator shall perform the following tests .
+ The evaluator shall perform the following tests .
- The evaluator shall perform the following tests.
+ The evaluator shall perform the following tests.
- Test FTP_DIT_EXT.1.1:1:
The evaluator shall exercise the application (attempting to transmit data; for
example by connecting to remote systems or websites) while capturing packets from
- the application. The evaluator shall verify from the packet capture that the
+ the application. The evaluator shall verify from the packet capture that the
traffic is encrypted with HTTPS, TLS, DTLS, SSH, or IPsec in accordance with the
- selection in the ST.
+ selection in the ST.
- Test FTP_DIT_EXT.1.1:2:
The evaluator shall exercise the application (attempting to transmit data; for
example by connecting to remote systems or websites) while capturing packets from
- the application. The evaluator shall review the packet capture and verify that no
- sensitive data is transmitted in the clear.
+ the application. The evaluator shall review the packet capture and verify that no
+ sensitive data is transmitted in the clear.
- Test FTP_DIT_EXT.1.1:3:
- The evaluator shall inspect the TSS to determine if user credentials are transmitted. If credentials are transmitted the evaluator shall set the credential to a known
- value. The evaluator shall capture packets from the application while causing
- credentials to be transmitted as described in the TSS. The evaluator shall perform
+ The evaluator shall inspect the TSS to determine if user credentials are transmitted. If credentials are transmitted the evaluator shall set the credential to a known
+ value. The evaluator shall capture packets from the application while causing
+ credentials to be transmitted as described in the TSS. The evaluator shall perform
a string search of the captured network packets and verify that the plaintext
- credential previously set by the evaluator is not found.
+ credential previously set by the evaluator is not found.
- Test FTP_DIT_EXT.1.1:4[conditional, Platforms:Android: Mobile operating systems based on Google Android.]:
@@ -2167,9 +2172,9 @@
5.1.6 Class: Trusted Path/Channel
If "not transmit any data" is selected, the evaluator shall ensure that the application's
AndroidManifest.xml file does not contain a uses-permission or uses-permission-sdk-23 tag
- containing android:name="android.permission.INTERNET". In this case, it is not necessary to perform
+ containing android:name="android.permission.INTERNET". In this case, it is not necessary to perform
the above Tests 1, 2, or 3, as the platform will not allow the application to perform any network
- communication.
+ communication.
@@ -2180,488 +2185,598 @@ 5.1.6 Class: Trusted Path/Channel
If "encrypt all transmitted data" is selected, the evaluator shall ensure that the application's
Info.plist file does not contain the NSAllowsArbitraryLoads or
NSExceptionAllowsInsecureHTTPLoads keys, as these keys disable iOS's Application
- Transport Security feature.
+ Transport Security feature.
5.1.7 TOE Security Functional Requirements RationaleThe following rationale provides justification for each security objective for the TOE,
- showing that the SFRs are suitable to meet and achieve the security objectives:
Table 2: SFR Rationale| Objective | Addressed by | Rationale |
|---|
O.INTEGRITY
| 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 compromise the integrity of the TOE. |
+ showing that the SFRs are suitable to meet and achieve the security objectives:
5.2 Security Assurance Requirements
-
- The Security Objectives for the TOE in Section 5 Security Requirements were constructed to address threats identified in
- Section 3.1 Threats. The Security Functional Requirements (SFRs) in Section 5.1 Security Functional Requirements are a formal
- instantiation of the Security Objectives. 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.
- 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.
- 5.2.1 Class ASE: Security Target
- As per ASE activities defined in [CEM]. 5.2.2 Class ADV: DevelopmentThe information about the TOE
+
+ 5.2.1 Class ASE: Security Target
+ As per ASE activities defined in [CEM].
+ 5.2.2 Class ADV: Development
+ The information about the TOE
is contained in the guidance documentation available to the end user as
- well as the TSS portion of the ST. The TOE developer
+ well as the TSS portion of the ST. The TOE developer
must concur with the description of the product that is contained in the TSS as it relates
- to the functional requirements. The evaluation activities contained in
- Section 5.1 Security Functional Requirements should provide the ST authors with sufficient information to
- determine the appropriate content for the TSS section.
- ADV_FSP.1 Basic Functional Specification (ADV_FSP.1)The functional
- specification describes the TSFIs. It is not necessary
- to have a formal or complete specification of these interfaces . Additionally, because
+ to the functional requirements . The evaluation activities contained in
+ Section 5.1 Security Functional Requirements should provide the ST authors with sufficient information to
+ determine the appropriate content for the TSS section .
+
+ ADV_FSP.1 Basic Functional Specification (ADV_FSP.1)
+ The functional
+ specification describes the TSFIs. It is not necessary
+ to have a formal or complete specification of these interfaces . Additionally, because
TOEs conforming to this PP will necessarily have interfaces to the
Operational Environment that are not directly invocable by TOE users,
there is little point specifying that such interfaces be described in and of themselves
- since only indirect testing of such interfaces may be possible . For this PP, the
+ since only indirect testing of such interfaces may be possible . For this PP, the
activities for this family should focus on understanding the interfaces presented in the
TSS in response to the functional requirements and the interfaces
- presented in the AGD documentation . No additional “functional specification” documentation
- is necessary to satisfy the evaluation activities specified . The interfaces that need to be
+ presented in the AGD documentation . No additional “functional specification” documentation
+ is necessary to satisfy the evaluation activities specified . The interfaces that need to be
evaluated are characterized through the information needed to perform the assurance
- activities listed, rather than as an independent, abstract list .
- Developer action elements: The developer shall provide a functional specification . The developer shall provide a tracing from the functional specification to the
- SFRs. Content and presentation elements: The functional specification shall describe the purpose and method of use for
+ each SFR-enforcing and SFR-supporting TSFI. The functional specification shall identify all parameters associated with each
+ SFR-enforcing and SFR-supporting TSFI. The functional specification shall provide rationale for the implicit
+ categorization of interfaces as SFR-non-interfering . The tracing shall demonstrate that the SFRs trace to TSFIs in the functional specification . Evaluator action elements: The evaluator shall confirm that the information provided meets all requirements
+ for content and presentation of evidence . The evaluator shall determine that the functional specification is an accurate
+ and complete instantiation of the SFRs.
There are no specific evaluation activities associated with these SARs, except
- ensuring the information is provided . The functional specification documentation is
- provided to support the evaluation activities described in Section 5.1 Security Functional Requirements, and
- other activities described for AGD, ATE, and AVA SARs. The requirements on the content
+ ensuring the information is provided . The functional specification documentation is
+ provided to support the evaluation activities described in Section 5.1 Security Functional Requirements, and
+ other activities described for AGD, ATE, and AVA SARs. The requirements on the content
of the functional specification information is implicitly assessed by virtue of the
other evaluation activities being performed; if the evaluator is unable to perform an
activity because there is insufficient interface information, then an adequate
- functional specification has not been provided . 5.2.3 Class AGD: Guidance Documentation
+ functional specification has not been provided . 5.2.3 Class AGD: Guidance Documentation
+
The guidance documents will be
- provided with the ST. Guidance must include a description of how the IT personnel verifies
- that the Operational Environment can fulfill its role for the security functionality. The
- documentation should be in an informal style and readable by the IT personnel. Guidance must
+ provided with the ST. Guidance must include a description of how the IT personnel verifies
+ that the Operational Environment can fulfill its role for the security functionality. The
+ documentation should be in an informal style and readable by the IT personnel. Guidance must
be provided for every operational environment that the product supports as claimed in the
- ST. This guidance includes instructions to successfully install the TSF in
+ ST. This guidance includes instructions to successfully install the TSF in
that environment; and Instructions to manage the security of the TSF as a
- product and as a component of the larger operational environment. Guidance pertaining to
+ product and as a component of the larger operational environment. Guidance pertaining to
particular security functionality is also provided; requirements on such guidance are
- contained in the evaluation activities specified with each requirement.
- AGD_OPE.1 Operational User Guidance (AGD_OPE.1)Developer action elements: The developer shall provide operational user guidance . AGD_PRE.1 Preparative Procedures (AGD_PRE.1)Developer action elements: The developer shall provide the TOE, including its preparative procedures .
+ AGD_PRE.1 Preparative Procedures (AGD_PRE.1)
+
+
+
+
+
+ Developer action elements: The developer shall provide the TOE, including its preparative procedures .
As with the operational guidance, the developer should look to
the evaluation activities to determine the required content with respect to preparative
- procedures. Content and presentation elements: The preparative procedures shall describe all the steps necessary for secure
+ procedures . Content and presentation elements: The preparative procedures shall describe all the steps necessary for secure
acceptance of the delivered TOE in accordance with the developer's
- delivery procedures . The preparative procedures shall describe all the steps necessary for secure
+ delivery procedures . The preparative procedures shall describe all the steps necessary for secure
installation of the TOE and for the secure preparation of the
operational environment in accordance with the security objectives for the operational
- environment as described in the ST. Evaluator action elements: The evaluator shall confirm that the information provided meets all requirements
- for content and presentation of evidence . The evaluator shall apply the preparative procedures to confirm that the TOE
- can be prepared securely for operation .
+ environment as described in the ST. Evaluator action elements: The evaluator shall confirm that the information provided meets all requirements
+ for content and presentation of evidence . The evaluator shall apply the preparative procedures to confirm that the TOE
+ can be prepared securely for operation .
As indicated in the introduction above, there are significant expectations
with respect to the documentation—especially when configuring the operational
- environment to support TOE functional requirements . The evaluator
+ environment to support TOE functional requirements . The evaluator
shall check to ensure that the guidance provided for the TOE
- adequately addresses all platforms claimed for the TOE in the ST. 5.2.4 Class ALC: Life-cycle Support
+ adequately addresses all platforms claimed for the TOE in the ST. 5.2.4 Class ALC: Life-cycle Support
+
At the assurance level provided for TOEs conformant to this PP, life-cycle support is limited
to end-user-visible aspects of the life-cycle, rather than an examination of the TOE vendor’s
- development and configuration management process. This is not meant to diminish the
+ development and configuration management process. This is not meant to diminish the
critical role that a developer’s practices play in contributing to the overall trustworthiness of a
product; rather, it is a reflection on the information to be made available for evaluation at this
- assurance level. ALC_CMC.1 Labeling of the TOE (ALC_CMC.1)
+ assurance level .
+ ALC_CMC.1 Labeling of the TOE (ALC_CMC.1)
+
This component is targeted at identifying the TOE such that it can be distinguished from
other products or versions from the same vendor and can be easily specified when being
- procured by an end user .
- Developer action elements: The developer shall provide the TOE and a reference for the TOE. Content and presentation elements: The application shall be labeled with a unique reference . ALC_CMS.1 TOE CM Coverage (ALC_CMS.1)Developer action elements: The developer shall provide a configuration list for the TOE. Content and presentation elements: The configuration list shall include the following: the TOE
- itself; and the evaluation evidence required by the SARs. The configuration list shall uniquely identify the configuration items . Evaluator action elements: The evaluator shall confirm that the information provided meets all requirements
- for content and presentation of evidence .
+ ALC_CMS.1 TOE CM Coverage (ALC_CMS.1)
+
+
+
+
+ Developer action elements: The developer shall provide a configuration list for the TOE. Content and presentation elements: The configuration list shall include the following: the TOE
+ itself; and the evaluation evidence required by the SARs. The configuration list shall uniquely identify the configuration items . Evaluator action elements: The evaluator shall confirm that the information provided meets all requirements
+ for content and presentation of evidence .
The "evaluation evidence required by the SARs" in this PP is limited to the
information in the ST coupled with the guidance provided to administrators and users
- under the AGD requirements . By ensuring that the TOE is specifically
+ under the AGD requirements . By ensuring that the TOE is specifically
identified and that this identification is consistent in the ST and in the AGD
guidance (as done in the evaluation activity for ALC_CMC.1), the evaluator implicitly
- confirms the information required by this component . Life-cycle support is targeted
+ confirms the information required by this component . Life-cycle support is targeted
aspects of the developer’s life-cycle and instructions to providers of applications
for the developer’s devices, rather than an in-depth examination of the TSF
- manufacturer’s development and configuration management process . This is not meant to diminish the critical role that a developer’s practices play in
+ manufacturer’s development and configuration management process . This is not meant to diminish the critical role that a developer’s practices play in
contributing to the overall trustworthiness of a product; rather, it’s a reflection on
- the information to be made available for evaluation . The evaluator shall ensure that the developer has identified (in guidance documentation for application
+ the information to be made available for evaluation . The evaluator shall ensure that the developer has identified (in guidance documentation for application
developers concerning the targeted platform) one or more development environments
- appropriate for use in developing applications for the developer’s platform . For each
+ appropriate for use in developing applications for the developer’s platform . For each
of these development environments, the developer shall provide information on how to
configure the environment to ensure that buffer overflow protection mechanisms in the
- environment(s) are invoked (e.g., compiler flags) . The evaluator shall ensure that
+ environment(s) are invoked (e.g., compiler flags) . The evaluator shall ensure that
this documentation also includes an indication of whether such protections are on by
- default, or have to be specifically enabled . The evaluator shall ensure that the
+ default, or have to be specifically enabled . The evaluator shall ensure that the
TSF is uniquely identified (with respect to other products from the
TSF vendor), and that documentation provided by the developer in
association with the requirements in the ST is associated with the
- TSF using this unique identification . ALC_TSU_EXT.1 Timely Security Updates
+ TSF using this unique identification .
+ ALC_TSU_EXT.1 Timely Security Updates
+
This component requires the TOE developer, in conjunction with any other necessary parties,
to provide information as to how the end-user devices are updated to address security issues
- in a timely manner . The documentation describes the process of providing updates to the
- public from the time a security flaw is reported/discovered, to the time an update is released . This description includes the parties involved (e.g., the developer, carriers(s)) and the steps
+ in a timely manner . The documentation describes the process of providing updates to the
+ public from the time a security flaw is reported/discovered, to the time an update is released . This description includes the parties involved (e.g., the developer, carriers(s)) and the steps
that are performed (e.g., developer testing, carrier testing), including worst case time periods,
- before an update is made available to the public . Developer action elements: The developer shall provide a description in the TSS of how timely
- security updates are made to the TOE.
The developer shall provide a description in the TSS of how users are notified when
- updates change security properties or the configuration of the product . Content and presentation elements: The description shall include the process for creating and deploying
- security updates for the TOE software . The description shall express the time window as the length of time,
+ updates change security properties or the configuration of the product . Content and presentation elements: The description shall include the process for creating and deploying
+ security updates for the TOE software . The description shall express the time window as the length of time,
in days, between public disclosure of a vulnerability and the public availability
- of security updates to the TOE. The description shall include the mechanisms publicly available for
- reporting security issues pertaining to the TOE. The description shall include the mechanisms publicly available for
+ reporting security issues pertaining to the TOE.
The reporting mechanism could include web sites, email addresses, as
well as a means to protect the sensitive nature of the report (e.g., public keys that could be
- used to encrypt the details of a proof-of-concept exploit). Evaluator action elements: The evaluator shall confirm that the information provided meets all
- requirements for content and presentation of evidence .
+ used to encrypt the details of a proof-of-concept exploit) . Evaluator action elements: The evaluator shall confirm that the information provided meets all
+ requirements for content and presentation of evidence .
The evaluator shall verify that the TSS contains a description of the timely security update
- process used by the developer to create and deploy security updates . The evaluator shall
- verify that this description addresses the entire application . The evaluator shall also
+ process used by the developer to create and deploy security updates . The evaluator shall
+ verify that this description addresses the entire application . The evaluator shall also
verify that, in addition to the TOE developer’s process, any
- third-party processes are also addressed in the description . The evaluator shall
- also verify that each mechanism for deployment of security updates is described .
+ third-party processes are also addressed in the description . The evaluator shall
+ also verify that each mechanism for deployment of security updates is described .
The evaluator shall verify that, for each deployment mechanism described for the update
process, the TSS lists a time between public disclosure of a vulnerability and public
availability of the security update to the TOE patching this vulnerability, to include any third-party
- or carrier delays in deployment . The evaluator shall verify that this time is expressed in
- a number or range of days .
+ or carrier delays in deployment . The evaluator shall verify that this time is expressed in
+ a number or range of days .
The evaluator shall verify that this description includes the publicly available mechanisms
- (including either an email address or website) for reporting security issues related to the TOE. The evaluator shall verify that the description of this mechanism includes a method for
+ (including either an email address or website) for reporting security issues related to the TOE. The evaluator shall verify that the description of this mechanism includes a method for
protecting the report either using a public key for encrypting email or a trusted channel for a
- website . 5.2.5 Class ATE: Tests
+ website .
+
+ 5.2.5 Class ATE: Tests
+
Testing is specified for functional aspects of
- the system as well as aspects that take advantage of design or implementation weaknesses . The former is done through the ATE_IND family, while the latter is through the AVA_VAN
- family . At the assurance level specified in this PP, testing is based on advertised
- functionality and interfaces with dependency on the availability of design information . One
+ the system as well as aspects that take advantage of design or implementation weaknesses . The former is done through the ATE_IND family, while the latter is through the AVA_VAN
+ family . At the assurance level specified in this PP, testing is based on advertised
+ functionality and interfaces with dependency on the availability of design information . One
of the primary outputs of the evaluation process is the test report as specified in the
- following requirements .
+ following requirements .
+
- ATE_IND.1 Independent Testing – Conformance (ATE_IND.1)
+ ATE_IND.1 Independent Testing – Conformance (ATE_IND.1)
+
+ Testing is performed to confirm the
+ functionality described in the TSS as well as the administrative
+ (including configuration and operational) documentation provided . The focus of the testing
+ is to confirm that the requirements specified in Section 5.1 Security Functional Requirements being met,
+ although some additional testing is specified for SARs in Section 5.2 Security Assurance Requirements. The
+ evaluation activities identify the additional testing activities associated with these
+ components . The evaluator produces a test report documenting the plan for and results of
+ testing, as well as coverage arguments focused on the platform/ TOE
+ combinations that are claiming conformance to this PP. Given the scope of the
+ TOE and its associated evaluation evidence requirements, this
+ component’s evaluation activities are covered by the evaluation activities listed for ALC_CMC.1.
+
+ Testing is performed to confirm the
+ functionality described in the TSS as well as the administrative
+ (including configuration and operational) documentation provided . The focus of the testing
+ is to confirm that the requirements specified in Section 5.1 Security Functional Requirements being met,
+ although some additional testing is specified for SARs in Section 5.2 Security Assurance Requirements. The
+ evaluation activities identify the additional testing activities associated with these
+ components . The evaluator produces a test report documenting the plan for and results of
+ testing, as well as coverage arguments focused on the platform/ TOE
+ combinations that are claiming conformance to this PP. Given the scope of the
+ TOE and its associated evaluation evidence requirements, this
+ component’s evaluation activities are covered by the evaluation activities listed for ALC_CMC.1.
+
Testing is performed to confirm the
functionality described in the TSS as well as the administrative
- (including configuration and operational) documentation provided . The focus of the testing
- is to confirm that the requirements specified in Section 5.1 Security Functional Requirements being met,
- although some additional testing is specified for SARs in Section 5.2 Security Assurance Requirements. The
+ (including configuration and operational) documentation provided . The focus of the testing
+ is to confirm that the requirements specified in Section 5.1 Security Functional Requirements being met,
+ although some additional testing is specified for SARs in Section 5.2 Security Assurance Requirements. The
evaluation activities identify the additional testing activities associated with these
- components . The evaluator produces a test report documenting the plan for and results of
+ components . The evaluator produces a test report documenting the plan for and results of
testing, as well as coverage arguments focused on the platform/ TOE
- combinations that are claiming conformance to this PP. Given the scope of the
+ combinations that are claiming conformance to this PP. Given the scope of the
TOE and its associated evaluation evidence requirements, this
- component’s evaluation activities are covered by the evaluation activities listed for ALC_CMC.1.
- Developer action elements: The developer shall provide the TOE for testing .
The evaluator shall prepare a test plan and report documenting the testing
- aspects of the system, including any application crashes during testing . The evaluator
+ aspects of the system, including any application crashes during testing . The evaluator
shall determine the root cause of any application crashes and include that information
- in the report . The test plan covers all of the testing actions contained in
- the [CEM] and the body of this PP’s evaluation activities .
+ in the report . The test plan covers all of the testing actions contained in
+ the [CEM] and the body of this PP’s evaluation activities .
While it is not necessary to have one test case per test listed in an evaluation activity, the
evaluator must document in the test plan that each applicable testing requirement in
- the ST is covered . The test plan identifies the platforms to be tested, and for those
+ the ST is covered . The test plan identifies the platforms to be tested, and for those
platforms not included in the test plan but included in the ST, the test plan provides
- a justification for not testing the platforms . This justification must address the
+ a justification for not testing the platforms . This justification must address the
differences between the tested platforms and the untested platforms, and make an
- argument that the differences do not affect the testing to be performed . It is not
+ argument that the differences do not affect the testing to be performed . It is not
sufficient to merely assert that the differences have no effect; rationale must be
- provided . If all platforms claimed in the ST are tested, then no rationale is
- necessary . The test plan describes the composition of each platform to be tested, and
- any setup that is necessary beyond what is contained in the AGD documentation . It
+ provided . If all platforms claimed in the ST are tested, then no rationale is
+ necessary . The test plan describes the composition of each platform to be tested, and
+ any setup that is necessary beyond what is contained in the AGD documentation . It
should be noted that the evaluator is expected to follow the AGD documentation for
installation and setup of each platform either as part of a test or as a standard
- pre-test condition . This may include special test drivers or tools . For each driver or
+ pre-test condition . This may include special test drivers or tools . For each driver or
tool, an argument (not just an assertion) should be provided that the driver or tool
- will not adversely affect the performance of the functionality by the TOE and its platform .
+ will not adversely affect the performance of the functionality by the TOE and its platform .
This also includes the configuration of the
- cryptographic engine to be used . The cryptographic algorithms implemented by this
+ cryptographic engine to be used . The cryptographic algorithms implemented by this
engine are those specified by this PP and used by the cryptographic protocols being
- evaluated (e.g SSH) . The test plan identifies high-level test objectives
- as well as the test procedures to be followed to achieve those objectives . These
- procedures include expected results .
+ evaluated (e.g SSH) . The test plan identifies high-level test objectives
+ as well as the test procedures to be followed to achieve those objectives . These
+ procedures include expected results .
The test report (which could just be an annotated
version of the test plan) details the activities that took place when the test
- procedures were executed, and includes the actual results of the tests . This shall be
+ procedures were executed, and includes the actual results of the tests . This shall be
a cumulative account, so if there was a test run that resulted in a failure; a fix
installed; and then a successful re-run of the test, the report would show a “fail”
- and “pass” result (and the supporting details), and not just the “pass” result . 5.2.6 Class AVA: Vulnerability Assessment
+ and “pass” result (and the supporting details), and not just the “pass” result .
+
+ 5.2.6 Class AVA: Vulnerability Assessment
+
For the current generation of
this protection profile, the evaluation lab is expected to survey open sources to discover
- what vulnerabilities have been discovered in these types of products . In most cases, these
- vulnerabilities will require sophistication beyond that of a basic attacker . Until
+ what vulnerabilities have been discovered in these types of products . In most cases, these
+ vulnerabilities will require sophistication beyond that of a basic attacker . Until
penetration tools are created and uniformly distributed to the evaluation labs, the
- evaluator will not be expected to test for these vulnerabilities in the TOE. The labs will be expected to comment on the likelihood of these vulnerabilities given
- the documentation provided by the vendor . This information will be used in the development
- of penetration testing tools and for the development of future protection profiles .
- AVA_VAN.1 Vulnerability Survey (AVA_VAN.1)Developer action elements: The developer shall provide the TOE for testing . Content and presentation elements: The application shall be suitable for testing .
+ application files and verify that no files are flagged as malicious .
+
+
Appendix A - Optional Requirements
As indicated in the introduction to this PP, the baseline requirements (those that must be
- performed by the TOE) are contained in the body of this PP. This appendix contains three other types of optional requirements:
+ performed by the TOE) are contained in the body of this PP. This appendix contains three other types of optional requirements:
- The first type, defined in Appendix A.1 Strictly Optional Requirements, are strictly optional requirements . If the TOE meets any of these requirements the vendor is encouraged to claim the associated SFRs
- in the ST, but doing so is not required in order to conform to this PP.
+ The first type, defined in Appendix A.1 Strictly Optional Requirements, are strictly optional requirements . If the TOE meets any of these requirements the vendor is encouraged to claim the associated SFRs
+ in the ST, but doing so is not required in order to conform to this PP.
- The second type, defined in Appendix A.2 Objective Requirements, are objective requirements . These describe security functionality that is not yet
- widely available in commercial technology .
+ The second type, defined in Appendix A.2 Objective Requirements, are objective requirements . These describe security functionality that is not yet
+ widely available in commercial technology .
Objective requirements are not currently mandated by this PP, but will be mandated in
- the future . Adoption by vendors is encouraged, but claiming these SFRs is not required in order to conform to this
- PP.
+ the future . Adoption by vendors is encouraged, but claiming these SFRs is not required in order to conform to this
+ PP.
- The third type, defined in Appendix A.3 Implementation-dependent Requirements, are Implementation-dependent requirements . If the TOE implements the product features associated with the listed SFRs, either the SFRs must be claimed
- or the product features must be disabled in the evaluated ocnfiguration .
+ The third type, defined in Appendix A.3 Implementation-dependent Requirements, are Implementation-dependent requirements . If the TOE implements the product features associated with the listed SFRs, either the SFRs must be claimed
+ or the product features must be disabled in the evaluated ocnfiguration .
A.1 Strictly Optional Requirements
A.1.1 Class: Cryptographic Support (FCS)FCS_CKM.1/SK Cryptographic Symmetric Key Generation
The application shall generate symmetric cryptographic keys using a Random Bit
- Generator as specified in FCS_RBG_EXT.1 and specified cryptographic key sizes[ selection: 128 bit, 256 bit] .
+ Symmetric keys may be used to generate keys along the key chain .
The evaluator shall review the TSS to determine that it describes how the functionality described by
- FCS_RBG_EXT.1 is invoked .
+ FCS_RBG_EXT.1 is invoked .
If the application is relying on random bit generation from the
host platform, the evaluator shall verify the TSS includes the
name/manufacturer of the external RBG and describes the function call and parameters
- used when calling the external DRBG function . If different external RBGs are used
+ used when calling the external DRBG function . If different external RBGs are used
for different platforms, the evaluator shall verify the TSS identifies each RBG for
- each platform . Also, the evaluator shall verify the TSS includes a short description
- of the vendor's assumption for the amount of entropy seeding the external DRBG . The
+ each platform . Also, the evaluator shall verify the TSS includes a short description
+ of the vendor's assumption for the amount of entropy seeding the external DRBG . The
evaluator uses the description of the RBG functionality in FCS_RBG_EXT or
documentation available for the operational environment to determine that the key
size being requested is identical to the key size and mode to be used for the
- encryption/decryption of the user data .
- Guidance
- Tests
+ encryption/decryption of the user data .
+ Guidance
+ Tests
A.2 Objective Requirements
A.2.1 Class: Protection of the TSF (FPT)FPT_API_EXT.2 Use of Supported Services and APIs
- The application[ selection, choose one of: shall use platform-provided libraries, does not implement functionality]for parsing[ assignment:
- list of formats parsed that are included in the IANA MIME media types] .
The evaluator shall verify that the TSS lists the IANA MIME media types
(as described by
http://www.iana.org/assignments/media-types )
for all formats the application processes
- and that it maps those formats to parsing services provided by the platform .
- Guidance
- Tests
+ and that it maps those formats to parsing services provided by the platform .
+ Guidance
+ Tests
A.3 Implementation-dependent Requirements
This PP does not define any
- Implementation-dependent requirements. Appendix B - Selection-based Requirements
+ Implementation-dependent requirements. Appendix B - Selection-based Requirements
As indicated in the introduction to this PP,
the baseline requirements
(those that must be performed by the TOE or its underlying platform)
- are contained in the body of this PP. There are additional requirements based on selections in the body of
+ 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.
+ if certain selections are made, then additional requirements below must be included.
B.1 Class: Cryptographic Support (FCS)FCS_CKM.1/AK Cryptographic Asymmetric Key GenerationThe inclusion of this selection-based component depends upon selection in
- FCS_CKM.1.1.
+ FCS_CKM.1.1. The application shall[ selection, choose one of: invoke platform-provided functionality, implement functionality]to generate asymmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm[ selection: - [RSA schemes] using cryptographic key sizes of [2048-bit or greater] that meet
- the following FIPS PUB 186-4, "Digital Signature Standard (DSS), Appendix B.3"
- [ECC schemes] using [“NIST curves” P-256, P-384 and [selection: P-521 , no other curves ] ]that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4]
- [FFC schemes] using cryptographic key sizes of [2048-bit or greater]
+
The application shall[ selection: invoke platform-provided functionality, implement functionality]to generate asymmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm[ selection: - [RSA schemes] using cryptographic key sizes of [2048-bit or greater] that meet
+ the following FIPS PUB 186-4, "Digital Signature Standard (DSS), Appendix B.3"
- [ECC schemes] using [“NIST curves” P-256, P-384 and [selection: P-521 , no other curves ] ]that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4]
- [FFC schemes] using cryptographic key sizes of [2048-bit or greater]
that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.1]
- [FFC Schemes] using Diffie-Hellman group 14 that meet the following:
- RFC 3526, Section 3
- [FFC Schemes] using “safe-prime” groups that meet the following: NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography” and [selection: RFC 3526, RFC 7919]
] . - [FFC Schemes] using “safe-prime” groups that meet the following: NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography” and [selection: RFC 3526, RFC 7919]
] .
The ST author shall select all key generation schemes used for key
- establishment and entity authentication. When key generation is 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.
+ 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.
+ the TOE does not need to implement RSA key generation.
The evaluator shall ensure that the TSS identifies the key sizes
- supported by the TOE. If the ST specifies more
+ supported by the TOE. If the ST specifies more
than one scheme, the evaluator shall examine the TSS to verify that
- it identifies the usage for each scheme .
+ it identifies the usage for each scheme .
If the application " invokes platform-provided functionality for asymmetric key generation,"
then the evaluator shall examine the TSS to verify that it describes
- how the key generation functionality is invoked .
+ how the key generation functionality is invoked .
Guidance
The evaluator shall verify that the AGD guidance instructs the administrator how to
configure the TOE to use the selected key generation scheme(s) and
- key size(s) for all uses defined in this PP.
+ key size(s) for all uses defined in this PP. Tests
If the application " implements asymmetric key generation," then the following test
- activities shall be carried out .
+ activities shall be carried out .
Evaluation Activity Note: The following tests may require the developer to provide access
to a developer environment that provides the evaluator with tools that are typically available
- to end-users of the application . Key Generation for FIPS PUB 186-4 RSA Schemes
+ to end-users of the application . Key Generation for FIPS PUB 186-4 RSA Schemes
The evaluator shall verify the implementation of RSA Key Generation by the
- TOE using the Key Generation test . This test verifies the ability of
+ TOE using the Key Generation test . This test verifies the ability of
the TSF to correctly produce values for the key components including
the public verification exponent e, the private prime factors p and q, the public
- modulus n and the calculation of the private signature exponent d . Key Pair generation
- specifies 5 ways (or methods) to generate the primes p and q .
+ modulus n and the calculation of the private signature exponent d . Key Pair generation
+ specifies 5 ways (or methods) to generate the primes p and q .
These include: - Random Primes:
- Provable primes
- Probable primes
- Primes with Conditions:
- Primes p1, p2, q1,q2, p and q shall all be provable primes
- Primes p1, p2, q1, and q2 shall be provable primes and p and q shall be
@@ -2669,91 +2784,91 @@
A.1 Strictly Optional R
To test the key generation method for the Random Provable primes method and for all
the Primes with Conditions methods, the evaluator must seed the TSF
key generation routine with sufficient data to deterministically generate the RSA key
- pair. This includes the random seed(s), the public exponent of the RSA key, and the
- desired key length. For each key length supported, the evaluator shall have the
- TSF generate 25 key pairs. The evaluator shall verify the
+ pair. This includes the random seed(s), the public exponent of the RSA key, and the
+ desired key length. For each key length supported, the evaluator shall have the
+ TSF generate 25 key pairs. The evaluator shall verify the
correctness of the TSF’s implementation by comparing values
generated by the TSF with those generated from a known good
- implementation.
+ implementation.
If possible, the Random Probable primes method should also be verified against a
- known good implementation as described above. Otherwise, the evaluator shall have
+ known good implementation as described above. Otherwise, the evaluator shall have
the TSF generate 10 keys pairs for each supported key length nlen
- and verify: - n = p⋅q,
- p and q are probably prime according to Miller-Rabin tests,
- GCD(p-1,e) = 1,
- GCD(q-1,e) = 1,
- 216 ≤ e ≤ 2256 and e is an odd integer,
- |p-q| > 2nlen/2 - 100,
- p ≥ 2nlen/2 -1/2,
- q ≥ 2nlen/2 -1/2,
- 2(nlen/2) < d < LCM(p-1,q-1),
- e⋅d = 1 mod LCM(p-1,q-1).
Key Generation for Elliptic Curve Cryptography (ECC)
+ and verify: - n = p⋅q,
- p and q are probably prime according to Miller-Rabin tests,
- GCD(p-1,e) = 1,
- GCD(q-1,e) = 1,
- 216 ≤ e ≤ 2256 and e is an odd integer,
- |p-q| > 2nlen/2 - 100,
- p ≥ 2nlen/2 -1/2,
- q ≥ 2nlen/2 -1/2,
- 2(nlen/2) < d < LCM(p-1,q-1),
- e⋅d = 1 mod LCM(p-1,q-1).
Key Generation for Elliptic Curve Cryptography (ECC)
FIPS 186-4 ECC Key Generation Test
For each supported NIST curve, i.e., P-256, P-384 and P-521, the evaluator shall
- require the implementation under test (IUT) to generate 10 private/public key pairs. The private key shall be generated using an approved random bit generator (RBG). To
+ require the implementation under test (IUT) to generate 10 private/public key pairs. The private key shall be generated using an approved random bit generator (RBG). To
determine correctness, the evaluator shall submit the generated key pairs to the
- public key verification (PKV) function of a known good implementation.
+ public key verification (PKV) function of a known good implementation.
FIPS 186-4 Public Key Verification (PKV) Test
For each supported NIST curve, i.e., P-256, P-384 and P-521, the evaluator shall
generate 10 private/public key pairs using the key generation function of a known
good implementation and modify five of the public key values so that they are
- incorrect, leaving five values unchanged (i.e., correct). The evaluator shall obtain
- in response a set of 10 PASS/FAIL values. Key Generation for Finite-Field Cryptography (FFC)
+ incorrect, leaving five values unchanged (i.e., correct). The evaluator shall obtain
+ in response a set of 10 PASS/FAIL values. Key Generation for Finite-Field Cryptography (FFC)
The evaluator shall verify the implementation of the Parameters Generation and the
Key Generation for FFC by the TOE using the Parameter Generation and
- Key Generation test. This test verifies the ability of the TSF to
+ Key Generation test. This test verifies the ability of the TSF to
correctly produce values for the field prime p, the cryptographic prime q (dividing
p-1), the cryptographic group generator g, and the calculation of the private key x
- and public key y. The Parameter generation specifies 2 ways (or methods) to generate
+ and public key y. The Parameter generation specifies 2 ways (or methods) to generate
the cryptographic prime q and the field prime p:
Cryptographic and Field Primes: - Primes q and p shall both be provable primes
- Primes q and field prime p shall both be probable primes
and two ways to generate the cryptographic group generator g:
Cryptographic Group Generator:
- - Generator g constructed through a verifiable process
- Generator g constructed through an unverifiable process.
+ - Generator g constructed through a verifiable process
- Generator g constructed through an unverifiable process.
The Key generation specifies 2 ways to generate the private key x:
Private Key:
- len(q) bit output of RBG where 1 ≤x ≤ q-1
- len(q) + 64 bit output of RBG, followed by a mod q-1 operation where
- 1≤ x≤q-1.
+ 1≤ x≤q-1.
The security strength of the RBG must be at least that of the security offered by the
- FFC parameter set. To test the cryptographic and field prime generation method for the provable primes
+ FFC parameter set. To test the cryptographic and field prime generation method for the provable primes
method and/or the group generator g for a verifiable process, the evaluator must seed
the TSF parameter generation routine with sufficient data to
- deterministically generate the parameter set. For each key length supported, the evaluator shall have the TSF
- generate 25 parameter sets and key pairs. The evaluator shall verify the correctness
+ deterministically generate the parameter set. For each key length supported, the evaluator shall have the TSF
+ generate 25 parameter sets and key pairs. The evaluator shall verify the correctness
of the TSF’s implementation by comparing values generated by the
- TSF with those generated from a known good implementation.
+ TSF with those generated from a known good implementation.
Verification must also confirm
- g ≠ 0,1
- q divides p-1
- gq mod p = 1
- gx mod p = y
- for each FFC parameter set and key pair. Diffie-Hellman Group 14 and FFC Schemes using “safe-prime” groups
+ for each FFC parameter set and key pair. Diffie-Hellman Group 14 and FFC Schemes using “safe-prime” groups
Testing for FFC Schemes using Diffie-Hellman group 14 and/or safe-prime groups is done as part of testing
- in CKM.2.1.
+ in CKM.2.1 .
A password/passphrase shall perform[ assignment:
Password-based Key Derivation Functions]in accordance with a specified cryptographic algorithm as specified in FCS_COP.1/KeyedHash, with[ assignment:
- positive integer of 1,000 or more]iterations, and output cryptographic key sizes[ selection: 128, 256]that meet the following [NIST SP 800-132] .
+ The TSF shall generate salts using a RBG that meets FCS_RBG_EXT.1 and with entropy corresponding to the security strength selected for PBKDF in FCS_CKM.1.1/PBKDF.
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 pseudo-random
- function (PRF) consisting of HMAC with an approved hash function. The ST author selects the hash function used,
- also includes the appropriate requirements for HMAC and the hash function.
+ in NIST SP 800-132; the method used is selected by the ST Author. SP 800-132 requires the use of a pseudo-random
+ function (PRF) consisting of HMAC with an approved hash function. The ST author selects the hash function used,
+ also includes the appropriate requirements for HMAC and the hash function.
Appendix A of SP 800-132 recommends setting the iteration count in order to increase the computation needed to derive a
- key from a password and, therefore, increase the workload of performing a password recovery attack. A significantly higher
- value is recommended to ensure optimal security. This value is expected to increase to a minimum of 10,000 in a future
- iteration based on SP800-63.
+ key from a password and, therefore, increase the workload of performing a password recovery attack . A significantly higher
+ value is recommended to ensure optimal security . This value is expected to increase to a minimum of 10,000 in a future
+ iteration based on SP800-63 .
Support for PBKDF: The evaluator shall examine the password hierarchy TSS to ensure that
the formation of all password based derived keys is described and that the key sizes match that
- described by the ST author .
+ described by the ST author .
The evaluator shall check that the TSS describes the method by which the password/passphrase is first encoded and then fed to
- the SHA algorithm . The settings for the algorithm (padding, blocking, etc.) shall be described, and the evaluator shall verify
- that these are supported by the selections in this component as well as the selections concerning the hash function itself .
+ the SHA algorithm . The settings for the algorithm (padding, blocking, etc.) shall be described, and the evaluator shall verify
+ that these are supported by the selections in this component as well as the selections concerning the hash function itself .
The evaluator shall verify that the TSS contains a description of how the output of the hash function is used to form the
- submask that will be input into the function . For the NIST SP 800-132-based conditioning of the password/passphrase, the required evaluation activities will be performed when
- doing the evaluation activities for the appropriate requirements ( FCS_COP.1.1/KeyedHash) . No explicit testing of the formation of the submask from the input password is required .
- FCS_CKM.1.1/PBKDF: The ST author shall provide a description in the TSS regarding the salt generation .
- The evaluator shall confirm that the salt is generated using an RBG described in FCS_RBG_EXT.1.
- Guidance
- Tests
+ submask that will be input into the function . For the NIST SP 800-132-based conditioning of the password/passphrase, the required evaluation activities will be performed when
+ doing the evaluation activities for the appropriate requirements ( FCS_COP.1.1/KeyedHash) . No explicit testing of the formation of the submask from the input password is required .
+ FCS_CKM.1.1/PBKDF: The ST author shall provide a description in the TSS regarding the salt generation .
+ The evaluator shall confirm that the salt is generated using an RBG described in FCS_RBG_EXT.1.
+ Guidance
+ Tests
The application shall[ selection, choose one of: invoke platform-provided functionality, implement functionality]to perform cryptographic key establishment in accordance with a specified cryptographic key establishment method: [ selection: - [RSA-based key establishment schemes] that meets the following: [NIST
+
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: - [RSA-based key establishment schemes] that meets the following: [NIST
Special Publication 800-56B, “Recommendation for Pair-Wise Key Establishment
Schemes Using Integer Factorization Cryptography”]
- [RSA-based key establishment schemes]
that meet the following: RSAES-PKCS1-v1_5 as specified in Section 7.2 of RFC 8017,
@@ -2762,349 +2877,349 @@
A.1 Strictly Optional R
Schemes Using Discrete Logarithm Cryptography”] - [Finite field-based key establishment schemes] that meets the following:
[NIST Special Publication 800-56A, “Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography”]
- [Key establishment scheme using Diffie-Hellman group 14]
- that meets the following: RFC 3526, Section 3
- [FFC Schemes using “safe-prime” groups] that meet the following: ‘NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography” and [selection: RFC 3526, RFC 7919].
] . - [FFC Schemes using “safe-prime” groups] that meet the following: ‘NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography” and [selection: RFC 3526, RFC 7919].
] .
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.
+ 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
+ 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.
+ RSA key generation.
The elliptic curves used for the key establishment scheme shall correlate with the curves
- specified in FCS_CKM.1.1/AK.
+ 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.
+ by the key generation according to FCS_CKM.1.1/AK.
The evaluator shall ensure that the supported key establishment schemes correspond to the
- key generation schemes identified in FCS_CKM.1.1. If the ST specifies more than one
+ key generation schemes identified in FCS_CKM.1.1. If the ST specifies more than one
scheme, the evaluator shall examine the TSS to verify that it identifies the usage for each
- scheme .
+ scheme .
Guidance
The evaluator shall verify that the AGD guidance instructs the administrator how to configure
- the TOE to use the selected key establishment scheme(s) .
+ the TOE to use the selected key establishment scheme(s) . Tests
Evaluation Activity Note: The following tests require the developer to provide access to a test
platform that provides the evaluator with tools that are typically not found on factory
- products . Key Establishment Schemes
+ products . Key Establishment Schemes
The evaluator shall verify the implementation of the key establishment schemes supported by
- the TOE using the applicable tests below . SP800-56A Key Establishment Schemes
+ the TOE using the applicable tests below . SP800-56A Key Establishment Schemes
The evaluator shall verify a TOE's implementation of SP800-56A key agreement schemes
- using the following Function and Validity tests . These validation tests for each key agreement
+ using the following Function and Validity tests . These validation tests for each key agreement
scheme verify that a TOE has implemented the components of the key agreement scheme
- according to the specifications in the Recommendation . These components include the
+ according to the specifications in the Recommendation . These components include the
calculation of the DLC primitives (the shared secret value Z) and the calculation of the
- derived keying material (DKM) via the Key Derivation Function (KDF) . If key confirmation
+ derived keying material (DKM) via the Key Derivation Function (KDF) . If key confirmation
is supported, the evaluator shall also verify that the components of key confirmation have
- been implemented correctly, using the test procedures described below . This includes the
- parsing of the DKM, the generation of MACdata and the calculation of MACtag . Function Test
+ been implemented correctly, using the test procedures described below . This includes the
+ parsing of the DKM, the generation of MACdata and the calculation of MACtag . Function Test
The Function test verifies the ability of the TOE to implement the key agreement
- schemes correctly . To conduct this test the evaluator shall generate or obtain test vectors
- from a known good implementation of the TOE supported schemes . For each supported
+ schemes correctly . To conduct this test the evaluator shall generate or obtain test vectors
+ from a known good implementation of the TOE supported schemes . For each supported
key agreement scheme-key agreement role combination, KDF type, and, if supported,
key confirmation role- key confirmation type combination, the tester shall generate 10
- sets of test vectors . The data set consists of one set of domain parameter values (FFC) or
- the NIST approved curve (ECC) per 10 sets of public keys . These keys are static,
- ephemeral or both depending on the scheme being tested .
+ sets of test vectors . The data set consists of one set of domain parameter values (FFC) or
+ the NIST approved curve (ECC) per 10 sets of public keys . These keys are static,
+ ephemeral or both depending on the scheme being tested .
The evaluator shall obtain the DKM, the corresponding TOE’s public keys (static and/or
ephemeral), the MAC tag(s), and any inputs used in the KDF, such as the Other
- Information (OtherInfo) and TOE id fields .
+ Information (OtherInfo) and TOE id fields .
If the TOE does not use a KDF defined in SP 800-56A, the evaluator shall obtain only
- the public keys and the hashed value of the shared secret .
+ the public keys and the hashed value of the shared secret .
The evaluator shall verify the correctness of the TSF’s implementation of a given
scheme by using a known good implementation to calculate the shared secret value,
derive the keying material DKM, and compare hashes or MAC tags generated from
- these values .
+ these values .
If key confirmation is supported, the TSF shall perform the above for each implemented
- approved MAC algorithm . Validity Test
+ approved MAC algorithm . Validity Test
The Validity test verifies the ability of the TOE to recognize another party’s valid and
- invalid key agreement results with or without key confirmation . To conduct this test, the
+ invalid key agreement results with or without key confirmation . To conduct this test, the
evaluator shall obtain a list of the supporting cryptographic functions included in the
SP800-56A key agreement implementation to determine which errors the TOE should
- be able to recognize . The evaluator generates a set of 24 (FFC) or 30 (ECC) test vectors
+ be able to recognize . The evaluator generates a set of 24 (FFC) or 30 (ECC) test vectors
consisting of data sets including domain parameter values or NIST approved curves, the
evaluator’s public keys, the TOE’s public/private key pairs, MACTag, and any inputs
- used in the KDF, such as the OtherInfo and TOE id fields .
+ used in the KDF, such as the OtherInfo and TOE id fields .
The evaluator shall inject an error in some of the test vectors to test that the TOE
recognizes invalid key agreement results caused by the following fields being incorrect:
the shared secret value Z, the DKM, the OtherInfo field, the data to be
- MACed, or the generated MACTag . If the TOE contains the full or partial (only ECC)
+ MACed, or the generated MACTag . If the TOE contains the full or partial (only ECC)
public key validation, the evaluator will also individually inject errors in both parties’
static public keys, both parties’ ephemeral public keys and the TOE’s static private key
to assure the TOE detects errors in the public key validation function and/or the partial
- key validation function (in ECC only) . At least two of the test vectors shall remain
- unmodified and therefore should result in valid key agreement results (they should pass) .
+ key validation function (in ECC only) . At least two of the test vectors shall remain
+ unmodified and therefore should result in valid key agreement results (they should pass) .
The TOE shall use these modified test vectors to emulate the key agreement scheme
- using the corresponding parameters . The evaluator shall compare the TOE’s results with
- the results using a known good implementation verifying that the TOE detects these errors . SP800-56B Key Establishment Schemes
+ using the corresponding parameters . The evaluator shall compare the TOE’s results with
+ the results using a known good implementation verifying that the TOE detects these errors . SP800-56B Key Establishment Schemes
The evaluator shall verify that the TSS describes whether the TOE acts as a sender, a
- recipient, or both for RSA-based key establishment schemes .
+ recipient, or both for RSA-based key establishment schemes .
If the TOE acts as a sender, the following evaluation activity shall be performed to ensure the
proper operation of every TOE supported combination of RSA-based key establishment scheme:
If the TOE acts as a receiver, the following evaluation activities shall be performed to ensure
the proper operation of every TOE supported combination of RSA-based key establishment scheme:
- The evaluator shall ensure that the TSS describes how the TOE handles decryption errors . In
+ The evaluator shall ensure that the TSS describes how the TOE handles decryption errors . In
accordance with NIST Special Publication 800-56B, the TOE must not reveal the particular
error that occurred, either through the contents of any outputted or logged error message or
- through timing variations . If KTS-OAEP is supported, the evaluator shall create separate
+ through timing variations . If KTS-OAEP is supported, the evaluator shall create separate
contrived ciphertext values that trigger each of the three decryption error checks described in
NIST Special Publication 800-56B section 7.2.2.3, ensure that each decryption attempt
- results in an error, and ensure that any outputted or logged error message is identical for each .
+ results in an error, and ensure that any outputted or logged error message is identical for each .
If KTS-KEM-KWS is supported, the evaluator shall create separate contrived ciphertext
values that trigger each of the three decryption error checks described in NIST Special
Publication 800-56B section 7.2.3.3, ensure that each decryption attempt results in an error,
- and ensure that any outputted or logged error message is identical for each . RSA-based key establishment
+ and ensure that any outputted or logged error message is identical for each . RSA-based key establishment
The evaluator shall verify the correctness of the TSF’s implementation of RSAES-PKCS1-v1_5 by using a
- known good implementation for each protocol selected in FTP_DIT_EXT.1 that uses RSAES-PKCS1-v1_5 . Diffie-Hellman Group 14
+ known good implementation for each protocol selected in FTP_DIT_EXT.1 that uses RSAES-PKCS1-v1_5 . Diffie-Hellman Group 14
The evaluator shall verify the correctness of the TSF’s implementation of Diffie-Hellman group 14 by using
- a known good implementation for each protocol selected in FTP_DIT_EXT.1 that uses Diffie-Hellman group 14 . FFC Schemes using “safe-prime” groups
+ a known good implementation for each protocol selected in FTP_DIT_EXT.1 that uses Diffie-Hellman group 14 . FFC Schemes using “safe-prime” groups
The evaluator shall verify the correctness of the TSF’s implementation of safe-prime groups by using a
- known good implementation for each protocol selected in FTP_DIT_EXT.1 that uses safe-prime groups . This test
- must be performed for each safe-prime group that each protocol uses . The application shall perform cryptographic hashing services in accordance with a specified cryptographic algorithm[ selection: SHA-1, SHA-256, SHA-384, SHA-512, no other]and message digest sizes[ selection: 160, 256, 384, 512, no other]bits that meet the following: FIPS Pub 180-4 .
The evaluator shall check that the association of the hash function with other
application cryptographic functions (for example, the digital signature verification
- function) is documented in the TSS.
- Guidance
+ function) is documented in the TSS.
+ Guidance
Tests
The following tests require the developer to provide access to a test application
- that provides the evaluator with tools that are typically not found in the production application.
+ that provides the evaluator with tools that are typically not found in the production application.
- Test FCS_COP.1.1/Hash:1:
- Short Messages Test - Bit oriented Mode. The evaluators devise an input set
- consisting of m+1 messages, where m is the block length of the hash algorithm. The
- length of the messages range sequentially from 0 to m bits. The message text shall
- be pseudorandomly generated. The evaluators compute the message digest for each of
+ Short Messages Test - Bit oriented Mode. The evaluators devise an input set
+ consisting of m+1 messages, where m is the block length of the hash algorithm. The
+ length of the messages range sequentially from 0 to m bits. The message text shall
+ be pseudorandomly generated. The evaluators compute the message digest for each of
the messages and ensure that the correct result is produced when the messages are
- provided to the TSF.
+ provided to the TSF.
- Test FCS_COP.1.1/Hash:2:
- Short Messages Test - Byte oriented Mode. The evaluators devise an input set
- consisting of m/8+1 messages, where m is the block length of the hash algorithm. The length of the messages range sequentially from 0 to m/8 bytes, with each
- message being an integral number of bytes. The message text shall be
- pseudorandomly generated. The evaluators compute the message digest for each of
+ Short Messages Test - Byte oriented Mode. The evaluators devise an input set
+ consisting of m/8+1 messages, where m is the block length of the hash algorithm. The length of the messages range sequentially from 0 to m/8 bytes, with each
+ message being an integral number of bytes. The message text shall be
+ pseudorandomly generated. The evaluators compute the message digest for each of
the messages and ensure that the correct result is produced when the messages are
- provided to the TSF.
+ provided to the TSF.
- Test FCS_COP.1.1/Hash:3:
- Selected Long Messages Test - Bit oriented Mode. The evaluators devise an input
- set consisting of m messages, where m is the block length of the hash algorithm. The length of the ith message is 512 + 99*i, where 1 ≤ i ≤ m. The message text
- shall be pseudorandomly generated. The evaluators compute the message digest for
+ Selected Long Messages Test - Bit oriented Mode. The evaluators devise an input
+ set consisting of m messages, where m is the block length of the hash algorithm. The length of the ith message is 512 + 99*i, where 1 ≤ i ≤ m. The message text
+ shall be pseudorandomly generated. The evaluators compute the message digest for
each of the messages and ensure that the correct result is produced when the
- messages are provided to the TSF.
+ messages are provided to the TSF.
- Test FCS_COP.1.1/Hash:4:
- Selected Long Messages Test - Byte oriented Mode. The evaluators devise an
+ Selected Long Messages Test - Byte oriented Mode. The evaluators devise an
input set consisting of m/8 messages, where m is the block length of the hash
- algorithm. The length of the ith message is 512 + 8*99*i, where 1 ≤ i ≤ m/8. The
- message text shall be pseudorandomly generated. The evaluators compute the message
+ algorithm. The length of the ith message is 512 + 8*99*i, where 1 ≤ i ≤ m/8. The
+ message text shall be pseudorandomly generated. The evaluators compute the message
digest for each of the messages and ensure that the correct result is produced
- when the messages are provided to the TSF.
+ when the messages are provided to the TSF.
- Test FCS_COP.1.1/Hash:5:
- Pseudorandomly Generated Messages Test. This test is for byte-oriented
- implementations only. The evaluators randomly generate a seed that is n bits long,
+ Pseudorandomly Generated Messages Test. This test is for byte-oriented
+ implementations only. The evaluators randomly generate a seed that is n bits long,
where n is the length of the message digest produced by the hash function to be
- tested. The evaluators then formulate a set of 100 messages and associated digests
- by following the algorithm provided in Figure 1 of [SHAVS]. The evaluators then
+ tested. The evaluators then formulate a set of 100 messages and associated digests
+ by following the algorithm provided in Figure 1 of [SHAVS]. The evaluators then
ensure that the correct result is produced when the messages are provided to the
- TSF.
+ TSF.
FCS_COP.1/KeyedHash Cryptographic Operation - Keyed-Hash Message AuthenticationThe inclusion of this selection-based component depends upon selection in
- FTP_DIT_EXT.1.1.
+ FTP_DIT_EXT.1.1. The application shall perform keyed-hash message authentication in accordance with a specified cryptographic algorithm and[ selection: HMAC-SHA-1, HMAC-SHA-384, HMAC-SHA-512, no other algorithms]with key sizes[ assignment:
- key size (in bits) used in HMAC]and message digest sizes 256 and[ selection: 160, 384, 512, no other size]bits that meet the following: FIPS Pub 198-1 The Keyed-Hash Message Authentication Code and FIPS Pub 180-4 Secure Hash Standard .
+ used by the application (e.g., trusted channel) . The hash selection must
+ support the message digest size selection . The hash selection
+ should be consistent with the overall strength of the algorithm used for FCS_COP.1/SKC.
- The evaluator shall perform the following activities based on the selections in the ST.
-
- Guidance
+ The evaluator shall perform the following activities based on the selections in the ST.
+
+ Guidance
Tests
- For each of the supported parameter sets, the evaluator shall compose 15 sets of test data . Each set shall consist of a key and message data . The evaluator shall have the TSF generate
- HMAC tags for these sets of test data . The resulting MAC tags shall be compared to the
- result of generating HMAC tags with the same key and IV using a known-good implementation .
+ For each of the supported parameter sets, the evaluator shall compose 15 sets of test data . Each set shall consist of a key and message data . The evaluator shall have the TSF generate
+ HMAC tags for these sets of test data . The resulting MAC tags shall be compared to the
+ result of generating HMAC tags with the same key and IV using a known-good implementation . The application shall perform cryptographic signature services (generation and
verification) in accordance with a specified cryptographic algorithm[ selection: - RSA schemes using cryptographic key sizes of 2048-bit or greater that meet the
- following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 4
- ECDSA schemes using “NIST curves” P-256, P-384 and [selection: P-521, no other curves] that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5
] . ECDSA schemes using “NIST curves” P-256, P-384 and [selection: P-521, no other curves] that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5] .
- This is dependent on implementing cryptographic functionality, as in FTP_DIT_EXT.1.
+ 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
+ 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.
+ algorithm .
- The evaluator shall perform the following activities based on the selections in the ST.
-
- Guidance
+ The evaluator shall perform the following activities based on the selections in the ST.
+
+ Guidance
Tests
ECDSA Algorithm Tests
- Test FCS_COP.1.1/Sig:1:
- ECDSA FIPS 186-4 Signature Generation Test. For each
+ ECDSA FIPS 186-4 Signature Generation Test. For each
supported NIST curve (i.e., P-256, P-384 and P-521) and SHA function pair, the
evaluator shall generate 10 1024-bit long messages and obtain for each message a
- public key and the resulting signature values R and S. To determine correctness,
+ public key and the resulting signature values R and S. To determine correctness,
the evaluator shall use the signature verification function of a known good
- implementation.
+ implementation.
- Test FCS_COP.1.1/Sig:2:
- ECDSA FIPS 186-4 Signature Verification Test. For each supported
+ ECDSA FIPS 186-4 Signature Verification Test. For each supported
NIST curve (i.e., P-256, P-384 and P-521) and SHA function pair, the evaluator
shall generate a set of 10 1024-bit message, public key and signature tuples and
modify one of the values (message, public key or signature) in five of the 10
- tuples. The evaluator shall obtain in response a set of 10 PASS/FAIL values.
+ tuples. The evaluator shall obtain in response a set of 10 PASS/FAIL values.
RSA Signature Algorithm Tests
- Test FCS_COP.1.1/Sig:3:
- Signature Generation Test. The evaluator shall
+ Signature Generation Test. The evaluator shall
verify the implementation of RSA Signature Generation by the TOE
- using the Signature Generation Test. To conduct this test the evaluator must
+ using the Signature Generation Test. To conduct this test the evaluator must
generate or obtain 10 messages from a trusted reference implementation for each
- modulus size/SHA combination supported by the TSF. The evaluator
+ modulus size/SHA combination supported by the TSF. The evaluator
shall have the TOE use their private key and modulus value to
- sign these messages. The evaluator shall verify the correctness of the
+ sign these messages. The evaluator shall verify the correctness of the
TSF’s signature using a known good implementation and the
- associated public keys to verify the signatures.
+ associated public keys to verify the signatures.
- Test FCS_COP.1.1/Sig:4:
- Signature Verification Test. The
+ Signature Verification Test. The
evaluator shall perform the Signature Verification test to verify the ability of
the TOE to recognize another party’s valid and invalid
- signatures. The evaluator shall inject errors into the test vectors produced
+ signatures. The evaluator shall inject errors into the test vectors produced
during the Signature Verification Test by introducing errors in some of the public
- keys, e, messages, IR format, and/or signatures. The TOE attempts
- to verify the signatures and returns success or failure.
+ keys, e, messages, IR format, and/or signatures. The TOE attempts
+ to verify the signatures and returns success or failure.
The application shall perform encryption/decryption in accordance with a specified cryptographic algorithm[ selection: AES-CBC (as defined in NIST SP 800-38A) mode, AES-GCM (as defined in NIST SP 800-38D) mode, AES-XTS (as defined in NIST SP 800-38E) mode, AES-CCM (as defined in NIST SP 800-38C) mode, AES-CTR (as defined in NIST SP 800-38A) mode]and cryptographic key sizes[ selection: 128-bit, 256-bit] .
-
+
Guidance
The evaluator checks the AGD documents to determine that any configuration that
is required to be done to configure the functionality for the required modes
- and key sizes is present .
+ and key sizes is present . Tests
The evaluator shall perform all of the following tests for each algorithm implemented by the TSF and used to
satisfy the requirements of this PP: AES-CBC Known Answer Tests
- There are four Known Answer Tests (KATs), described below . In all KATs, the plaintext, ciphertext, and IV values shall be 128-bit
- blocks . The results from each test may either be obtained by the
+ There are four Known Answer Tests (KATs), described below . In all KATs, the plaintext, ciphertext, and IV values shall be 128-bit
+ blocks . The results from each test may either be obtained by the
evaluator directly or by supplying the inputs to the implementer
- and receiving the results in response . To determine correctness,
+ and receiving the results in response . To determine correctness,
the evaluator shall compare the resulting values to those obtained
- by submitting the same inputs to a known good implementation . - KAT-1. To test the encrypt functionality of AES-CBC, the
+ by submitting the same inputs to a known good implementation.
- KAT-1. To test the encrypt functionality of AES-CBC, the
evaluator shall supply a set of 10 plaintext values and obtain
the ciphertext value that results from AES-CBC encryption of the
given plaintext using a key value of all zeros and an IV of all
- zeros. Five plaintext values shall be encrypted with a 128-bit
+ zeros. Five plaintext values shall be encrypted with a 128-bit
all-zeros key, and the other five shall be encrypted with a
- 256-bit all- zeros key. To test the decrypt functionality of
+ 256-bit all- zeros key. To test the decrypt functionality of
AES-CBC, the evaluator shall perform the same test as for
encrypt, using 10 ciphertext values as input and AES-CBC
- decryption.
- KAT-2. To test the encrypt functionality of AES-CBC, the
+ decryption.
- KAT-2. To test the encrypt functionality of AES-CBC, the
evaluator shall supply a set of 10 key values and obtain the
ciphertext value that results from AES-CBC encryption of an
all-zeros plaintext using the given key value and an IV of all
- zeros. Five of the keys shall be 128-bit keys, and the other five
- shall be 256-bit keys. To test the decrypt functionality of
+ zeros. Five of the keys shall be 128-bit keys, and the other five
+ shall be 256-bit keys. To test the decrypt functionality of
AES-CBC, the evaluator shall perform the same test as for
encrypt, using an all-zero ciphertext value as input and AES-CBC
- decryption.
- KAT-3. To test the encrypt functionality of AES-CBC, the
+ decryption.
- KAT-3. To test the encrypt functionality of AES-CBC, the
evaluator shall supply the two sets of key values described below
and obtain the ciphertext value that results from AES encryption
of an all-zeros plaintext using the given key value and an IV of
- all zeros. The first set of keys shall have 128 128-bit keys, and
- the second set shall have 256 256-bit keys. Key i in each set
+ all zeros. The first set of keys shall have 128 128-bit keys, and
+ the second set shall have 256 256-bit keys. Key i in each set
shall have the leftmost i bits be ones and the rightmost N-i bits
- be zeros, for i in [1,N]. To test the decrypt functionality of
+ be zeros, for i in [1,N]. To test the decrypt functionality of
AES-CBC, the evaluator shall supply the two sets of key and
ciphertext value pairs described below and obtain the plaintext
value that results from AES-CBC decryption of the given
- ciphertext using the given key and an IV of all zeros. The first
+ ciphertext using the given key and an IV of all zeros. The first
set of key/ciphertext pairs shall have 128 128-bit key/ciphertext
pairs, and the second set of key/ciphertext pairs shall have 256
- 256-bit key/ciphertext pairs. Key i in each set shall have the
+ 256-bit key/ciphertext pairs. Key i in each set shall have the
leftmost i bits be ones and the rightmost N-i bits be zeros, for
- i in [1,N]. The ciphertext value in each pair shall be the value
+ i in [1,N]. The ciphertext value in each pair shall be the value
that results in an all-zeros plaintext when decrypted with its
- corresponding key.
- KAT-4. To test the encrypt functionality of AES-CBC, the
+ corresponding key.
- KAT-4. To test the encrypt functionality of AES-CBC, the
evaluator shall supply the set of 128 plaintext values described
below and obtain the two ciphertext values that result from
AES-CBC encryption of the given plaintext using a 128-bit key
value of all zeros with an IV of all zeros and using a 256-bit
- key value of all zeros with an IV of all zeros, respectively. Plaintext value i in each set shall have the leftmost i bits be
+ key value of all zeros with an IV of all zeros, respectively. Plaintext value i in each set shall have the leftmost i bits be
ones and the rightmost 128-i bits be zeros, for i in
- [1,128].
To test the decrypt functionality of AES-CBC, the evaluator
+ [1,128].
To test the decrypt functionality of AES-CBC, the evaluator
shall perform the same test as for encrypt, using ciphertext values
of the same form as the plaintext in the encrypt test as input and
- AES-CBC decryption . AES-CBC Multi-Block Message Test
+ AES-CBC decryption . AES-CBC Multi-Block Message Test
The evaluator shall test the encrypt functionality by
- encrypting an i-block message where 1 < i < = 10 . The
+ encrypting an i-block message where 1 < i < = 10 . The
evaluator shall choose a key, an IV and plaintext message of length
i blocks and encrypt the message, using the mode to be tested, with
- the chosen key and IV . The ciphertext shall be compared to the
+ the chosen key and IV . The ciphertext shall be compared to the
result of encrypting the same plaintext message with the same key
- and IV using a known good implementation . The evaluator shall also
+ and IV using a known good implementation . The evaluator shall also
test the decrypt functionality for each mode by decrypting an
- i-block message where 1 < i < =10 . The evaluator shall choose
+ i-block message where 1 < i < =10 . The evaluator shall choose
a key, an IV and a ciphertext message of length i blocks and
decrypt the message, using the mode to be tested, with the chosen
- key and IV . The plaintext shall be compared to the result of
+ key and IV . The plaintext shall be compared to the result of
decrypting the same ciphertext message with the same key and IV
- using a known good implementation . AES-CBC Monte Carlo Tests The
+ using a known good implementation . AES-CBC Monte Carlo Tests The
evaluator shall test the encrypt functionality using a set of 200
- plaintext, IV, and key 3- tuples . 100 of these shall use 128 bit
- keys, and 100 shall use 256 bit keys . The plaintext and IV values
- shall be 128-bit blocks . For each 3-tuple, 1000 iterations shall be
+ plaintext, IV, and key 3- tuples . 100 of these shall use 128 bit
+ keys, and 100 shall use 256 bit keys . The plaintext and IV values
+ shall be 128-bit blocks . For each 3-tuple, 1000 iterations shall be
run as follows:
# Input: PT, IV, Key
@@ -3117,121 +3232,121 @@ A.1 Strictly Optional R
PT = CT[i-1]
The ciphertext computed in the 1000th iteration (i.e.,
- CT[1000]) is the result for that trial . This result shall be
+ CT[1000]) is the result for that trial . This result shall be
compared to the result of running 1000 iterations with the same
- values using a known good implementation .
+ values using a known good implementation .
The evaluator shall test the decrypt functionality using the
same test as for encrypt, exchanging CT and PT and replacing
- AES-CBC-Encrypt with AES-CBC-Decrypt . AES-GCM Monte Carlo Tests
+ AES-CBC-Encrypt with AES-CBC-Decrypt . AES-GCM Monte Carlo Tests
The evaluator shall test the authenticated encrypt
functionality of AES-GCM for each combination of the following
- input parameter lengths: - 128 bit and 256 bit keys
- Two plaintext lengths. One of the plaintext lengths shall be
+ input parameter lengths:
- 128 bit and 256 bit keys
- Two plaintext lengths. One of the plaintext lengths shall be
a non-zero integer multiple of 128 bits, if
- supported. The other plaintext length shall not be an integer
- multiple of 128 bits, if supported.
- Three AAD lengths. One AAD length shall be 0, if supported. One AAD length shall be a non-zero integer
- multiple of 128 bits, if supported. One AAD length shall not be
- an integer multiple of 128 bits, if supported.
- Two IV lengths. If 96 bit IV is supported, 96 bits shall be
- one of the two IV lengths tested.
The evaluator shall test the encrypt functionality using a set
+ supported. The other plaintext length shall not be an integer
+ multiple of 128 bits, if supported. - Three AAD lengths. One AAD length shall be 0, if supported. One AAD length shall be a non-zero integer
+ multiple of 128 bits, if supported. One AAD length shall not be
+ an integer multiple of 128 bits, if supported.
- Two IV lengths. If 96 bit IV is supported, 96 bits shall be
+ one of the two IV lengths tested.
The evaluator shall test the encrypt functionality using a set
of 10 key, plaintext, AAD, and IV tuples for each combination of
parameter lengths above and obtain the ciphertext value and tag
- that results from AES-GCM authenticated encrypt . Each supported tag
- length shall be tested at least once per set of 10 . The IV value
+ that results from AES-GCM authenticated encrypt . Each supported tag
+ length shall be tested at least once per set of 10 . The IV value
may be supplied by the evaluator or the implementation being
- tested, as long as it is known .
+ tested, as long as it is known .
The evaluator shall test the decrypt functionality using a
set of 10 key, ciphertext, tag, AAD, and IV 5-tuples for each
combination of parameter lengths above and obtain a Pass/Fail
- result on authentication and the decrypted plaintext if Pass . The
- set shall include five tuples that Pass and five that Fail .
+ result on authentication and the decrypted plaintext if Pass . The
+ set shall include five tuples that Pass and five that Fail .
The results from each test may either be obtained by the
evaluator directly or by supplying the inputs to the implementer
- and receiving the results in response . To determine correctness,
+ and receiving the results in response . To determine correctness,
the evaluator shall compare the resulting values to those obtained
by submitting the same inputs to a known good
- implementation . AES-XTS Tests
+ implementation . AES-XTS Tests
The evaluator shall test the encrypt functionality of XTS-AES for each combination
of the following input parameter lengths:
256 bit (for AES-128) and 512 bit (for AES-256) keys
- Three data unit (i.e., plaintext) lengths . One of the data unit lengths shall be a
- non-zero integer multiple of 128 bits, if supported . One of the data unit lengths
- shall be an integer multiple of 128 bits, if supported . The third data unit length
+ Three data unit (i.e., plaintext) lengths . One of the data unit lengths shall be a
+ non-zero integer multiple of 128 bits, if supported . One of the data unit lengths
+ shall be an integer multiple of 128 bits, if supported . The third data unit length
shall be either the longest supported data unit length or 216 bits, whichever is
- smaller .
+ smaller .
Using a set of 100 (key, plaintext and 128-bit random tweak value) 3-tuples and
- obtain the ciphertext that results from XTS-AES encrypt .
+ obtain the ciphertext that results from XTS-AES encrypt .
The evaluator may supply a data unit sequence number instead of the tweak value if
- the implementation supports it . The data unit sequence number is a base-10 number
- ranging between 0 and 255 that implementations convert to a tweak value internally .
+ the implementation supports it . The data unit sequence number is a base-10 number
+ ranging between 0 and 255 that implementations convert to a tweak value internally .
The evaluator shall test the decrypt functionality of XTS-AES using the same test as
for encrypt, replacing plaintext values with ciphertext values and XTS-AES encrypt
- with XTS-AES decrypt . AES-CCM Tests
+ with XTS-AES decrypt . AES-CCM Tests
It is not recommended that evaluators use values obtained from static sources such as
http://csrc.nist.gov/groups/STM/cavp/documents/mac/ccmtestvectors.zip or use values not generated expressly
- to exercise the AES-CCM implementation .
+ to exercise the AES-CCM implementation .
The evaluator shall test the generation-encryption and decryption-verification functionality of AES-CCM for
- the following input parameter and tag lengths: - Keys: All supported and selected key sizes (e.g., 128, 256 bits).
- Associated Data: Two or three values for associated data length: The minimum (≥ 0 bytes) and
- maximum (≤ 32 bytes) supported associated data lengths, and 2^16 (65536) bytes, if supported.
- Payload: Two values for payload length: The minimum (≥ 0 bytes) and maximum (≤ 32 bytes) supported
- payload lengths.
- Nonces: All supported nonce lengths (7, 8, 9, 10, 11, 12, 13) in bytes.
- Tag: All supported tag lengths (4, 6, 8, 10, 12, 14, 16) in bytes.
- The testing for CCM consists of five tests . To determine correctness in each of the below tests, the evaluator
- shall compare the ciphertext with the result of encryption of the same inputs with a known good implementation . Variable Associated Data Test
+ the following input parameter and tag lengths: - Keys: All supported and selected key sizes (e.g., 128, 256 bits).
- Associated Data: Two or three values for associated data length: The minimum (≥ 0 bytes) and
+ maximum (≤ 32 bytes) supported associated data lengths, and 2^16 (65536) bytes, if supported.
- Payload: Two values for payload length: The minimum (≥ 0 bytes) and maximum (≤ 32 bytes) supported
+ payload lengths.
- Nonces: All supported nonce lengths (7, 8, 9, 10, 11, 12, 13) in bytes.
- Tag: All supported tag lengths (4, 6, 8, 10, 12, 14, 16) in bytes.
+ The testing for CCM consists of five tests . To determine correctness in each of the below tests, the evaluator
+ shall compare the ciphertext with the result of encryption of the same inputs with a known good implementation . Variable Associated Data Test
For each supported key size and associated data length, and any supported payload length, nonce length, and tag
length, the evaluator shall supply one key value, one nonce value, and 10 pairs of associated data and payload
- values, and obtain the resulting ciphertext . Variable Payload Test
+ values, and obtain the resulting ciphertext . Variable Payload Test
For each supported key size and payload length, and any supported associated data length, nonce length, and tag
length, the evaluator shall supply one key value, one nonce value, and 10 pairs of associated data and payload
- values, and obtain the resulting ciphertext . Variable Nonce Test
+ values, and obtain the resulting ciphertext . Variable Nonce Test
For each supported key size and nonce length, and any supported associated data length, payload length, and tag
length, the evaluator shall supply one key value, one nonce value, and 10 pairs of associated data and payload
- values, and obtain the resulting ciphertext . Variable Tag Test
+ values, and obtain the resulting ciphertext . Variable Tag Test
For each supported key size and tag length, and any supported associated data length, payload length, and nonce
length, the evaluator shall supply one key value, one nonce value, and 10 pairs of associated data and payload
- values, and obtain the resulting ciphertext . Decryption-Verification Process Test
+ values, and obtain the resulting ciphertext . Decryption-Verification Process Test
To test the decryption-verification functionality of AES-CCM, for each combination of supported associated data
length, payload length, nonce length, and tag length, the evaluator shall supply a key value and 15 sets of input
- plus ciphertext, and obtain the decrypted payload . Ten of the 15 input sets supplied should fail verification and
- five should pass . AES-CTR TestsTest 1: Known Answer Tests (KATs)
- There are four Known Answer Tests (KATs) described below . For all KATs, the plaintext, IV, and ciphertext values
- shall be 128-bit blocks . The results from each test may either be obtained by the validator directly or by
- supplying the inputs to the implementer and receiving the results in response . To determine correctness, the
+ plus ciphertext, and obtain the decrypted payload . Ten of the 15 input sets supplied should fail verification and
+ five should pass . AES-CTR TestsTest 1: Known Answer Tests (KATs)
+ There are four Known Answer Tests (KATs) described below . For all KATs, the plaintext, IV, and ciphertext values
+ shall be 128-bit blocks . The results from each test may either be obtained by the validator directly or by
+ supplying the inputs to the implementer and receiving the results in response . To determine correctness, the
evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good
- implementation .
+ implementation .
To test the encrypt functionality, the evaluator shall supply a set of 10 plaintext values and obtain the
ciphertext value that results from encryption of the given plaintext using a key value of all zeros and an IV of
- all zeros . Five plaintext values shall be encrypted with a 128-bit all zeros key, and the other five shall be
- encrypted with a 256-bit all zeros key . To test the decrypt functionality, the evaluator shall perform the same
- test as for encrypt, using 10 ciphertext values as input .
+ all zeros . Five plaintext values shall be encrypted with a 128-bit all zeros key, and the other five shall be
+ encrypted with a 256-bit all zeros key . To test the decrypt functionality, the evaluator shall perform the same
+ test as for encrypt, using 10 ciphertext values as input .
To test the encrypt functionality, the evaluator shall supply a set of 10 key values and obtain the ciphertext
- value that results from encryption of an all zeros plaintext using the given key value and an IV of all zeros . Five of the key values shall be 128-bit keys, and the other five shall be 256-bit keys . To test the decrypt
+ value that results from encryption of an all zeros plaintext using the given key value and an IV of all zeros . Five of the key values shall be 128-bit keys, and the other five shall be 256-bit keys . To test the decrypt
functionality, the evaluator shall perform the same test as for encrypt, using an all zero ciphertext value as
- input .
+ input .
To test the encrypt functionality, the evaluator shall supply the two sets of key values described below and
obtain the ciphertext values that result from AES encryption of an all zeros plaintext using the given key values
- an an IV of all zeros . The first set of keys shall have 128 128-bit keys, and the second shall have 256 256-bit
- keys . Key_i in each set shall have the leftmost i bits be ones and the rightmost N-i bits be zeros, for i
- in [1, N] . To test the decrypt functionality, the evaluator shall supply the two sets of key and ciphertext
+ an an IV of all zeros . The first set of keys shall have 128 128-bit keys, and the second shall have 256 256-bit
+ keys . Key_i in each set shall have the leftmost i bits be ones and the rightmost N-i bits be zeros, for i
+ in [1, N] . To test the decrypt functionality, the evaluator shall supply the two sets of key and ciphertext
value pairs described below and obtain the plaintext value that results from decryption of the given ciphertext
- using the given key values and an IV of all zeros . The first set of key/ciphertext pairs shall have 128 128-bit
- key/ciphertext pairs, and the second set of key/ciphertext pairs shall have 256 256-bit pairs . Key_i in each
- set shall have the leftmost i bits be ones and the rightmost N-i bits be zeros for i in [1, N] . The ciphertext
+ using the given key values and an IV of all zeros . The first set of key/ciphertext pairs shall have 128 128-bit
+ key/ciphertext pairs, and the second set of key/ciphertext pairs shall have 256 256-bit pairs . Key_i in each
+ set shall have the leftmost i bits be ones and the rightmost N-i bits be zeros for i in [1, N] . The ciphertext
value in each pair shall be the value that results in an all zeros plaintext when decrypted with its corresponding
- key .
+ key .
To test the encrypt functionality, the evaluator shall supply the set of 128 plaintext values described below and
obtain the two ciphertext values that result from encryption of the given plaintext using a 128-bit key value of
- all zeros and using a 256 bit key value of all zeros, respectively, and an IV of all zeros . Plaintext value i in
- each set shall have the leftmost bits be ones and the rightmost 128-i bits be zeros, for i in [1, 128] . To test
+ all zeros and using a 256 bit key value of all zeros, respectively, and an IV of all zeros . Plaintext value i in
+ each set shall have the leftmost bits be ones and the rightmost 128-i bits be zeros, for i in [1, 128] . To test
the decrypt functionality, the evaluator shall perform the same test as for encrypt, using ciphertext values of
- the same form as the plaintext in the encrypt test as input . Test 2: Multi-Block Message Test
+ the same form as the plaintext in the encrypt test as input . Test 2: Multi-Block Message Test
The evaluator shall test the encrypt functionality by encrypting an i-block message where 1 less-than i
- less-than-or-equal to 10 . For each i the evaluator shall choose a key, IV, and plaintext message of length i
- blocks and encrypt the message, using the mode to be tested, with the chosen key . The ciphertext shall be compared
- to the result of encrypting the same plaintext message with the same key and IV using a known good implementation . The evaluator shall also test the decrypt functionality by decrypting an i-block message where 1 less-than i
- less-than-or-equal to 10 . For each i the evaluator shall choose a key and a ciphertext message of length i blocks
- and decrypt the message, using the mode to be tested, with the chosen key . The plaintext shall be compared to the
- result of decrypting the same ciphertext message with the same key using a known good implementation . Test 3: Monte-Carlo Test
+ less-than-or-equal to 10 . For each i the evaluator shall choose a key, IV, and plaintext message of length i
+ blocks and encrypt the message, using the mode to be tested, with the chosen key . The ciphertext shall be compared
+ to the result of encrypting the same plaintext message with the same key and IV using a known good implementation . The evaluator shall also test the decrypt functionality by decrypting an i-block message where 1 less-than i
+ less-than-or-equal to 10 . For each i the evaluator shall choose a key and a ciphertext message of length i blocks
+ and decrypt the message, using the mode to be tested, with the chosen key . The plaintext shall be compared to the
+ result of decrypting the same ciphertext message with the same key using a known good implementation . Test 3: Monte-Carlo Test
For AES-CTR mode perform the Monte Carlo Test for ECB Mode on the encryption engine of the counter mode
- implementation . There is no need to test the decryption engine .
- The evaluator shall test the encrypt functionality using 200 plaintext/key pairs . 100 of these shall use 128 bit
- keys, and 100 of these shall use 256 bit keys . The plaintext values shall be 128-bit blocks . For each pair,
+ implementation . There is no need to test the decryption engine .
+ The evaluator shall test the encrypt functionality using 200 plaintext/key pairs . 100 of these shall use 128 bit
+ keys, and 100 of these shall use 256 bit keys . The plaintext values shall be 128-bit blocks . For each pair,
1000 iterations shall be run as follows:
For AES-ECB mode
# Input: PT, Key
@@ -3239,35 +3354,35 @@ A.1 Strictly Optional R
CT[i] = AES-ECB-Encrypt(Key, PT)
PT = CT[i]
- The ciphertext computed in the 1000th iteration is the result for that trial . This result shall be compared to
- the result of running 1000 iterations with the same values using a known good implementation .
+ The ciphertext computed in the 1000th iteration is the result for that trial . This result shall be compared to
+ the result of running 1000 iterations with the same values using a known good implementation . The application shall implement the HTTPS protocol that complies with RFC 2818 . The application shall implement HTTPS using TLS as defined in the Functional Package for TLS . The application shall[ selection, choose one of: not establish the application-initiated connection, notify the user and not establish the user-initiated connection, notify the user and request authorization to establish the user-initiated connection]if the peer certificate is deemed invalid .
- Guidance
- Tests Other tests are performed in conjunction with the TLS package .
+ Guidance
+ Tests Other tests are performed in conjunction with the TLS package .
- Guidance
+ Guidance
Tests
@@ -3277,48 +3392,48 @@ A.1 Strictly Optional R
- Test FCS_HTTPS_EXT.1.3/Client:1:
The evaluator shall demonstrate that using a certificate without a valid
- certification path results in the selected action in the SFR. If "notify the user"
+ certification path results in the selected action in the SFR. If "notify the user"
is selected in the SFR, then the evaluator shall also determine that the user
- is notified of the certificate validation failure. Using the administrative
+ is notified of the certificate validation failure. Using the administrative
guidance, the evaluator shall then load a certificate or certificates to the
Trust Anchor Database needed to validate the certificate to be used in the
- function, and demonstrate that the function succeeds. The evaluator then shall
+ function, and demonstrate that the function succeeds. The evaluator then shall
delete one of the certificates, and show that again, using a certificate
without a valid certification path results in the selected action in the SFR,
and if "notify the user" was selected in the SFR, the user is notified of the
- validation failure.
+ validation failure.
The application shall implement the HTTPS protocol that complies with RFC 2818 . The application shall implement HTTPS using TLS as defined in the Functional Package for TLS . The application shall implement the HTTPS protocol that complies with RFC 2818 . The application shall implement HTTPS using TLS as defined in the Functional Package for TLS .
The evaluator shall examine the TSS and determine that enough detail is provided to
- explain how the implementation complies with RFC 2818 .
+ explain how the implementation complies with RFC 2818 .
Guidance
+ None . Tests
The evaluator shall attempt to establish an HTTPS connection to the TOE using a
client, observe the traffic with a packet analyzer, and verify that the connection
- succeeds and that the traffic is identified as TLS or HTTPS . Guidance
- Tests Other tests are performed in conjunction with the TLS package . Guidance
+ Tests Other tests are performed in conjunction with the TLS package . FCS_HTTPS_EXT.2 HTTPS Protocol with Mutual AuthenticationThe inclusion of this selection-based component depends upon selection in
- FTP_DIT_EXT.1.1.
+ FTP_DIT_EXT.1.1. The application shall[ selection, choose one of: not establish the connection, establish or not establish the connection based on an administrative or user setting]if the peer certificate is deemed invalid .
-
- Guidance
+
+ Guidance
Tests
@@ -3327,75 +3442,75 @@ A.1 Strictly Optional R
- Test FCS_HTTPS_EXT.2.1:1:
The evaluator shall demonstrate that using a certificate without a
- valid certification path results in the selected action in the SFR. Using the
+ valid certification path results in the selected action in the SFR. Using the
administrative guidance, the evaluator shall then load a certificate or
certificates to the Trust Anchor Database needed to validate the certificate
- to be used in the function, and demonstrate that the function succeeds. The
+ to be used in the function, and demonstrate that the function succeeds. The
evaluator then shall delete one of the certificates, and show that again,
using a certificate without a valid certification path results in the selected
- action in the SFR.
+ action in the SFR.
FCS_RBG_EXT.2 Random Bit Generation from ApplicationThe inclusion of this selection-based component depends upon selection in
- FCS_RBG_EXT.1.1.
+ FCS_RBG_EXT.1.1. The application shall perform all deterministic random bit generation (DRBG) services in accordance with NIST Special Publication 800-90A using[ selection: Hash_DRBG (any), HMAC_DRBG (any), CTR_DRBG (AES)] This requirement shall be included in STs in which
- "implement DRBG functionality" is chosen in FCS_RBG_EXT.1.1.
+ "implement DRBG functionality" is chosen in FCS_RBG_EXT.1.1.
The ST author should select the standard to which the RBG services comply (either SP 800-90A or FIPS
- 140-2 Annex C).
+ 140-2 Annex C).
SP 800-90A contains three different methods of generating random numbers; each of
these, in turn, depends on underlying cryptographic primitives
- (hash functions/ciphers). The ST author will select the function used (if SP 800-90A
+ (hash functions/ciphers). The ST author will select the function used (if SP 800-90A
is selected), and include the specific underlying cryptographic primitives used in the
- requirement or in the TSS. While any of the identified hash functions (SHA-1, SHA-224,
+ requirement or in the TSS. While any of the identified hash functions (SHA-1, SHA-224,
SHA-256, SHA-384, SHA-512) are allowed for Hash_DRBG or HMAC_DRBG, only AES-based
- implementations for CTR_DRBG are allowed. The deterministic RBG shall be seeded by an entropy source that accumulates entropy from a platform-based DRBG and[ selection: a software-based noise source, a hardware-based noise source, no other noise source]with a minimum of[ selection, choose one of: 128 bits, 256 bits]of entropy at least equal to the greatest security strength (according to NIST SP 800-57) of the keys and hashes that it will generate . The deterministic RBG shall be seeded by an entropy source that accumulates entropy from a platform-based DRBG and[ selection: a software-based noise source, a hardware-based noise source, no other noise source]with a minimum of[ selection: 128 bits, 256 bits]of entropy at least equal to the greatest security strength (according to NIST SP 800-57) of the keys and hashes that it will generate . This requirement shall be included in STs in which
- "implement DRBG functionality" is chosen in FCS_RBG_EXT.1.1. For the first
+ "implement DRBG functionality" is chosen in FCS_RBG_EXT.1.1. For the first
selection in this requirement, the ST author selects "software-based noise source" if
- any additional noise sources are used as input to the application's DRBG. Note that
- the application must use the platform's DRBG to seed its DRBG.
+ any additional noise sources are used as input to the application's DRBG. Note that
+ the application must use the platform's DRBG to seed its DRBG.
In the second selection in this requirement, the ST author selects the
appropriate number of bits of entropy that corresponds to the greatest security
- strength of the algorithms included in the ST. Security strength is defined in Tables
- 2 and 3 of NIST SP 800-57A. For example, if the implementation includes 2048-bit RSA
+ strength of the algorithms included in the ST. Security strength is defined in Tables
+ 2 and 3 of NIST SP 800-57A. For example, if the implementation includes 2048-bit RSA
(security strength of 112 bits) and AES 256 (security strength 256 bits),
- then the ST author would select 256 bits.
-
- Guidance
+
+ Guidance
Tests
The reference for the tests contained in this section is The Random Number Generator
- Validation System (RNGVS). The evaluators shall conduct the following two tests. Note
+ Validation System (RNGVS). The evaluators shall conduct the following two tests. Note
that the "expected values" are produced by a reference implementation of the algorithm
- that is known to be correct. Proof of correctness is left to each Scheme.
+ that is known to be correct. Proof of correctness is left to each Scheme.
- Test FCS_RBG_EXT.2.1:1:
- The evaluators shall perform a Variable Seed Test. The evaluators shall
+ The evaluators shall perform a Variable Seed Test. The evaluators shall
provide a set of 128 (Seed, DT) pairs to the TSF RBG function,
- each 128 bits. The evaluators shall also provide a key (of the length appropriate
- to the AES algorithm) that is constant for all 128 (Seed, DT) pairs. The DT value
- is incremented by 1 for each set. The seed values shall have no repeats within
- the set. The evaluators ensure that the values returned by the
- TSF match the expected values.
+ each 128 bits. The evaluators shall also provide a key (of the length appropriate
+ to the AES algorithm) that is constant for all 128 (Seed, DT) pairs. The DT value
+ is incremented by 1 for each set. The seed values shall have no repeats within
+ the set. The evaluators ensure that the values returned by the
+ TSF match the expected values.
- Test FCS_RBG_EXT.2.1:2:
- The evaluators shall perform a Monte Carlo Test. For this test, they supply
+ The evaluators shall perform a Monte Carlo Test. For this test, they supply
an initial Seed and DT value to the TSF RBG function; each of
- these is 128 bits. The evaluators shall also provide a key (of the length
- appropriate to the AES algorithm) that is constant throughout the test. The
+ these is 128 bits. The evaluators shall also provide a key (of the length
+ appropriate to the AES algorithm) that is constant throughout the test. The
evaluators then invoke the TSF RBG 10,000 times, with the DT
value being incremented by 1 on each iteration, and the new seed for the
subsequent iteration produced as specified in NIST-Recommended Random Number
Generator Based on ANSI X9.31 Appendix A.2.4 Using the 3-Key Triple DES and AES
- Algorithms, Section E.3. The evaluators ensure that the 10,000th value produced
- matches the expected value.
+ Algorithms, Section E.3. The evaluators ensure that the 10,000th value produced
+ matches the expected value.
@@ -3403,232 +3518,232 @@ A.1 Strictly Optional R
- Test FCS_RBG_EXT.2.1:3:
- The evaluator shall perform 15 trials for the RNG implementation. If the RNG is
- configurable, the evaluator shall perform 15 trials for each configuration. The
+ The evaluator shall perform 15 trials for the RNG implementation. If the RNG is
+ configurable, the evaluator shall perform 15 trials for each configuration. The
evaluator shall also confirm that the operational guidance contains appropriate
- instructions for configuring the RNG functionality.
+ instructions for configuring the RNG functionality.
If the RNG has prediction resistance enabled, each trial consists of (1)
instantiate DRBG, (2) generate the first block of random bits (3) generate a
- second block of random bits (4) uninstantiate. The evaluator verifies that the
- second block of random bits is the expected value. The evaluator shall generate
- eight input values for each trial. The first is a count (0 – 14). The next three
+ second block of random bits (4) uninstantiate. The evaluator verifies that the
+ second block of random bits is the expected value. The evaluator shall generate
+ eight input values for each trial. The first is a count (0 – 14). The next three
are entropy input, nonce, and personalization string for the instantiate
- operation. The next two are additional input and entropy input for the first call
- to generate. The final two are additional input and entropy input for the second
- call to generate. These values are randomly generated. “generate one block of
+ operation. The next two are additional input and entropy input for the first call
+ to generate. The final two are additional input and entropy input for the second
+ call to generate. These values are randomly generated. “generate one block of
random bits” means to generate random bits with number of returned bits equal to
- the Output Block Length (as defined in NIST SP 800-90A).
+ the Output Block Length (as defined in NIST SP 800-90A).
If the RNG does not have prediction resistance, each trial consists of (1)
instantiate DRBG, (2) generate the first block of random bits (3) reseed, (4)
- generate a second block of random bits (5) uninstantiate. The evaluator verifies
- that the second block of random bits is the expected value. The evaluator shall
- generate eight input values for each trial. The first is a count (0 – 14). The
+ generate a second block of random bits (5) uninstantiate. The evaluator verifies
+ that the second block of random bits is the expected value. The evaluator shall
+ generate eight input values for each trial. The first is a count (0 – 14). The
next three are entropy input, nonce, and personalization string for the
- instantiate operation. The fifth value is additional input to the first call to
- generate. The sixth and seventh are additional input and entropy input to the call
- to reseed. The final value is additional input to the second generate call.
+ instantiate operation. The fifth value is additional input to the first call to
+ generate. The sixth and seventh are additional input and entropy input to the call
+ to reseed. The final value is additional input to the second generate call.
The following paragraphs contain more information on some of the input values to
- be generated/selected by the evaluator. Entropy input: the length of the entropy input value must equal the seed length. Nonce: If a nonce is supported (CTR_DRBG with no Derivation Function does not use
- a nonce), the nonce bit length is one-half the seed length.
+ be generated/selected by the evaluator. Entropy input: the length of the entropy input value must equal the seed length. Nonce: If a nonce is supported (CTR_DRBG with no Derivation Function does not use
+ a nonce), the nonce bit length is one-half the seed length.
Personalization string: The length of the personalization string must be
- less then or equal to seed length. If the implementation only supports one
- personalization string length, then the same length can be used for both values.
+ less then or equal to seed length. If the implementation only supports one
+ personalization string length, then the same length can be used for both values.
If more than one string length is support, the evaluator shall use personalization
- strings of two different lengths. If the implementation does not use a
- personalization string, no value needs to be supplied. Additional input: the additional input bit lengths have the same defaults
- and restrictions as the personalization string lengths.
+ strings of two different lengths. If the implementation does not use a
+ personalization string, no value needs to be supplied. Additional input: the additional input bit lengths have the same defaults
+ and restrictions as the personalization string lengths.
- Guidance
+ Clarification to the Entropy Documentation and Assessment Annex .
+ Guidance
Tests
In the future, specific statistical testing (in line with NIST SP 800-90B) will
- be required to verify the entropy estimates .
+ be required to verify the entropy estimates . B.2 Class: Identification and Authentication (FIA)
- The application shall[ selection, choose one of: invoke platform-provided functionality, implement functionality]to validate certificates in accordance with the following rules: - RFC 5280 certificate validation and certificate path validation.
- The certificate path must terminate with a trusted CA certificate.
- The application shall validate a certificate path by ensuring the presence of the
+
The application shall[ selection: invoke platform-provided functionality, implement functionality]to validate certificates in accordance with the following rules: - RFC 5280 certificate validation and certificate path validation.
- The certificate path must terminate with a trusted CA certificate.
- The application shall validate a certificate path by ensuring the presence of the
basicConstraints extension and that the CA flag is set to TRUE for all CA
- certificates, and that any path constraints are met.
- The application shall validate that any CA certificate includes caSigning purpose in the key
+ certificates, and that any path constraints are met.
- The application shall validate that any CA certificate includes caSigning purpose in the key
usage field
- The application shall validate the revocation status of the certificate using
- [selection: OCSP as specified in RFC 6960, CRL as specified in RFC 5280 Section 6.3, CRL as specified in RFC 8603, an OCSP TLS Status Request Extension (OCSP stapling) as specified in RFC 6066, OCSP TLS Multi-Certificate Status Request Extension (i.e., OCSP Multi-Stapling) as specified in RFC 6961].
- The application shall validate the extendedKeyUsage (EKU) field according to the
+ [selection: OCSP as specified in RFC 6960, CRL as specified in RFC 5280 Section 6.3, CRL as specified in RFC 8603, an OCSP TLS Status Request Extension (OCSP stapling) as specified in RFC 6066, OCSP TLS Multi-Certificate Status Request Extension (i.e., OCSP Multi-Stapling) as specified in RFC 6961].
- The application shall validate the extendedKeyUsage (EKU) field according to the
following rules:
- Certificates used for trusted updates and executable code integrity verification
shall have the Code Signing Purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3) in the
- extendedKeyUsage field.
- Server certificates presented for TLS shall have the Server Authentication
- purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the EKU field.
-
+ extendedKeyUsage field.
- Server certificates presented for TLS shall have the Server Authentication
+ purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the EKU field.
-
Client certificates presented for TLS shall have the Client Authentication purpose
- (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the EKU field.
-
+ (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the EKU field.
-
S/MIME certificates presented for email encryption and signature shall have the
- Email Protection purpose (id-kp 4 with OID 1.3.6.1.5.5.7.3.4) in the EKU field.
-
+ Email Protection purpose (id-kp 4 with OID 1.3.6.1.5.5.7.3.4) in the EKU field.
-
OCSP certificates presented for OCSP responses shall have the OCSP Signing purpose
- (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the EKU field.
-
+ (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the EKU field.
-
Server certificates presented for EST shall have the CMC Registration Authority
- (RA) purpose (id-kp-cmcRA with OID 1.3.6.1.5.5.7.3.28) in the EKU field.
- The application shall treat a certificate as a CA certificate only if the basicConstraints extension is present and the CA flag is set to TRUE .
+ The application shall treat a certificate as a CA certificate only if the basicConstraints extension is present and the CA flag is set to TRUE .
This requirement applies to certificates that are used and processed by the
- TSF and restricts the certificates that may be added as trusted CA certificates.
+ TSF and restricts the certificates that may be added as trusted CA certificates .
The evaluator shall ensure the TSS describes where the check of validity of the certificates
- takes place . The evaluator ensures the TSS also provides a description of the certificate
- path validation algorithm .
- Guidance
+ takes place . The evaluator ensures the TSS also provides a description of the certificate
+ path validation algorithm .
+ Guidance
Tests
The tests described must be performed in conjunction with the other certificate services evaluation
- activities, including the functions in FIA_X509_EXT.2.1. The tests for the extendedKeyUsage rules are
- performed in conjunction with the uses that require those rules. If the application supports chains of
+ activities, including the functions in FIA_X509_EXT.2.1. The tests for the extendedKeyUsage rules are
+ performed in conjunction with the uses that require those rules. If the application supports chains of
length four or greater, the evaluator shall create a chain of at least four certificates:
- the node certificate to be tested, two Intermediate CAs, and the self-signed Root CA. If
+ the node certificate to be tested, two Intermediate CAs, and the self-signed Root CA. If
the application supports a maximum trust depth of two, then a chain with no Intermediate
- CA should instead be created.
+ CA should instead be created.
- Test FIA_X509_EXT.1.1:1:
The evaluator shall demonstrate that validating a certificate without a valid certification path results in the function
- failing, for each of the following reasons, in turn:
- by establishing a certificate path in which one of the issuing certificates is not a CA certificate,
- by omitting the basicConstraints field in one of the issuing certificates,
- by setting the basicConstraints field in an issuing certificate to have CA=False,
- by omitting the CA signing bit of the key usage field in an issuing certificate, and
- by setting the path length field of a valid CA field to a value strictly less than the certificate path.
+ failing, for each of the following reasons, in turn:- by establishing a certificate path in which one of the issuing certificates is not a CA certificate,
- by omitting the basicConstraints field in one of the issuing certificates,
- by setting the basicConstraints field in an issuing certificate to have CA=False,
- by omitting the CA signing bit of the key usage field in an issuing certificate, and
- by setting the path length field of a valid CA field to a value strictly less than the certificate path.
The evaluator shall then establish a valid certificate path consisting of valid CA certificates, and demonstrate that the
- function succeeds. The evaluator shall then remove trust in one of the CA certificates, and show that the function fails.
+ function succeeds. The evaluator shall then remove trust in one of the CA certificates, and show that the function fails.
- Test FIA_X509_EXT.1.1:2:
- The evaluator shall demonstrate that validating an expired certificate results in the function failing.
+ The evaluator shall demonstrate that validating an expired certificate results in the function failing.
- Test FIA_X509_EXT.1.1:3:
The evaluator shall test that the TOE can properly handle revoked certificates-“conditional on whether
CRL, OCSP, OCSP Stapling or OCSP Multi-stapling is selected; if multiple methods are selected, then
the following tests shall be performed for each method:
-
- The evaluator shall test revocation of the node certificate.
- The evaluator shall also test revocation of an intermediate CA certificate (i.e. the intermediate
- CA certificate should be revoked by the root CA), if intermediate CA certificates are supported. If OCSP stapling per RFC 6066 is the only supported revocation method, this test is omitted.
- The evaluator shall ensure that a valid certificate is used, and that the validation function
- succeeds. The evaluator then attempts the test with a certificate that has been revoked (for each
+
- The evaluator shall test revocation of the node certificate.
- The evaluator shall also test revocation of an intermediate CA certificate (i.e. the intermediate
+ CA certificate should be revoked by the root CA), if intermediate CA certificates are supported. If OCSP stapling per RFC 6066 is the only supported revocation method, this test is omitted.
- The evaluator shall ensure that a valid certificate is used, and that the validation function
+ succeeds. The evaluator then attempts the test with a certificate that has been revoked (for each
method chosen in the selection) to ensure when the certificate is no longer valid that the
- validation function fails.
+ validation function fails.
Test FIA_X509_EXT.1.1:4:
If any OCSP option is selected, the evaluator shall configure the OCSP server or use a
man-in-the-middle tool to present a certificate that does not have the OCSP signing purpose and verify
- that validation of the OCSP response fails. If CRL is selected, the evaluator shall configure the CA
+ that validation of the OCSP response fails. If CRL is selected, the evaluator shall configure the CA
to sign a CRL with a certificate that does not have the cRLsign key usage bit set, and verify that
- validation of the CRL fails.
+ validation of the CRL fails.
Test FIA_X509_EXT.1.1:5:
The evaluator shall modify any byte in the first eight bytes of the certificate and demonstrate that
- the certificate fails to validate. (The certificate will fail to parse correctly.)
+ the certificate fails to validate. (The certificate will fail to parse correctly.)
Test FIA_X509_EXT.1.1:6:
The evaluator shall modify any byte in the last byte of the certificate and demonstrate that the
- certificate fails to validate. (The signature on the certificate will not validate.)
+ certificate fails to validate. (The signature on the certificate will not validate.)
Test FIA_X509_EXT.1.1:7:
The evaluator shall modify any byte in the public key of the certificate and demonstrate that the
- certificate fails to validate. (The signature on the certificate will not validate.)
+ certificate fails to validate. (The signature on the certificate will not validate.)
Test FIA_X509_EXT.1.1:8:
- (Conditional on support for EC certificates as indicated in FCS_COP.1/Sig). The evaluator shall establish a valid,
+ (Conditional on support for EC certificates as indicated in FCS_COP.1/Sig). The evaluator shall establish a valid,
trusted certificate chain consisting of an EC leaf certificate, an EC Intermediate CA certificate not
designated as a trust anchor, and an EC certificate designated as a trusted anchor, where the elliptic
- curve parameters are specified as a named curve. The evaluator shall confirm that the TOE validates
- the certificate chain.
+ curve parameters are specified as a named curve. The evaluator shall confirm that the TOE validates
+ the certificate chain.
Test FIA_X509_EXT.1.1:9:
- (Conditional on support for EC certificates as indicated in FCS_COP.1/Sig). The evaluator shall replace
+ (Conditional on support for EC certificates as indicated in FCS_COP.1/Sig). The evaluator shall replace
the intermediate certificate in the certificate chain for Test 9 with a modified certificate, where
the modified intermediate CA has a public key information field where the EC parameters uses an
explicit format version of the Elliptic Curve parameters in the public key information field of the
intermediate CA certificate from Test 9, and the modified Intermediate CA certificate is signed by
- the trusted EC root CA, but having no other changes. The evaluator shall confirm the TOE treats the
- certificate as invalid.
+ the trusted EC root CA, but having no other changes. The evaluator shall confirm the TOE treats the
+ certificate as invalid.
-
- Guidance
+
+ Guidance
Tests
The tests described must be performed in conjunction with the other certificate
- services evaluation activities, including the functions in FIA_X509_EXT.2.1. If the application supports chains of length four or greater,
+ services evaluation activities, including the functions in FIA_X509_EXT.2.1. If the application supports chains of length four or greater,
the evaluator shall create a chain of at least four certificates: the
- node certificate to be tested, two Intermediate CAs, and the self-signed Root CA. If the application supports a maximum trust depth of two, then a chain with
- no Intermediate CA should instead be created.
+ node certificate to be tested, two Intermediate CAs, and the self-signed Root CA. If the application supports a maximum trust depth of two, then a chain with
+ no Intermediate CA should instead be created.
- Test FIA_X509_EXT.1.2:1:
The evaluator shall ensure that the certificate of at least one of the CAs in the chain does not contain the
- basicConstraints extension. The evaluator shall confirm that validation of the certificate path
+ basicConstraints extension. The evaluator shall confirm that validation of the certificate path
fails (i) as part of the validation of the peer certificate belonging to this chain; and/or
- (ii) when attempting to add the CA certificate without the basicConstraints extension to the TOE's trust store.
+ (ii) when attempting to add the CA certificate without the basicConstraints extension to the TOE's trust store.
- Test FIA_X509_EXT.1.2:2:
The evaluator shall ensure that the certificate of at least one of the CAs in the chain has the CA flag in the
- basicConstraints extension not set (or set to FALSE). The evaluator shall confirm that validation of the certificate
+ basicConstraints extension not set (or set to FALSE). The evaluator shall confirm that validation of the certificate
path fails (i) as part of the validation of the peer certificate belonging to this chain; and/or (ii) when attempting
- to add the CA certificate with the CA flag not set (or set to FALSE) in the basicConstraints extension to the TOE's trust store.
+ to add the CA certificate with the CA flag not set (or set to FALSE) in the basicConstraints extension to the TOE's trust store.
The application shall use X.509v3 certificates as defined by RFC 5280 to support authentication for[ selection: HTTPS, TLS, DTLS, SSH, IPsec] . B.3 Class: Protection of the TSF (FPT)FPT_TUD_EXT.2 Integrity for Installation and UpdateThe inclusion of this selection-based component depends upon selection in
- FPT_TUD_EXT.1.5.
+ FPT_TUD_EXT.1.5.
- The application shall be distributed using the format of the platform-supported package manager .
- The application shall be packaged such that its removal results in the deletion of all traces of the application, with the exception of configuration settings, output files, and audit/log events .
-
- Guidance
+
+ Guidance
Tests
The evaluator shall verify that application updates are distributed in the
- format supported by the platform . This varies per platform:
+ format supported by the platform . This varies per platform:
@@ -3690,9 +3805,9 @@ A.1 Strictly Optional R
The evaluator shall ensure that the application is
packaged in the standard Windows Installer (.MSI) format, the Windows Application
Software (.EXE) format signed using the Microsoft Authenticode process, or the
- Windows Universal Application package (.APPX) format. See
+ Windows Universal Application package (.APPX) format. See
https://msdn.microsoft.com/en-us/library/ms537364(v=vs.85).aspx for details
- regarding Authenticode signing.
+ regarding Authenticode signing.
@@ -3701,7 +3816,7 @@ A.1 Strictly Optional R
The evaluator shall ensure that the application is
- packaged in the IPA format.
+ packaged in the IPA format.
@@ -3710,9 +3825,9 @@ A.1 Strictly Optional R
The evaluator shall ensure that the application is
packaged in the format of the package management infrastructure of the chosen
- distribution. For example, applications running on Red Hat and Red Hat derivatives
- shall be packaged in RPM format. Applications running on Debian and Debian
- derivatives shall be packaged in DEB format.
+ distribution. For example, applications running on Red Hat and Red Hat derivatives
+ shall be packaged in RPM format. Applications running on Debian and Debian
+ derivatives shall be packaged in DEB format.
@@ -3720,7 +3835,7 @@ A.1 Strictly Optional R
The evaluator shall ensure that the application is
- packaged in the PKG format.
+ packaged in the PKG format.
@@ -3728,13 +3843,13 @@ A.1 Strictly Optional R
The evaluator shall ensure that application is packaged
- in the DMG format, the PKG format, or the MPKG format.
+ in the DMG format, the PKG format, or the MPKG format.
-
- Guidance
+
+ Guidance
Tests
- Test FPT_TUD_EXT.2.2:2[conditional, Platforms:Microsoft Windows: Microsoft Windows operating systems.]:
- The evaluator shall install the application and then locate all of its executable files.
+ The evaluator shall install the application and then locate all of its executable files.
The evaluator shall then, for each file, save off either a hash of the file or a copy of the
- file itself. The evaluator shall then run the application and exercise all features of
- the application as described in the ST. The evaluator shall then compare each executable
- file with the either the saved hash or the saved copy of the files. The evaluator shall
- verify that these are identical.
+ file itself. The evaluator shall then run the application and exercise all features of
+ the application as described in the ST. The evaluator shall then compare each executable
+ file with the either the saved hash or the saved copy of the files. The evaluator shall
+ verify that these are identical.
- Test FPT_TUD_EXT.2.2:4[conditional, Platforms:Linux: Linux-based operating systems other than Android.]:
- The evaluator shall install the application and then locate all of its executable files.
+ The evaluator shall install the application and then locate all of its executable files.
The evaluator shall then, for each file, save off either a hash of the file or a copy of the
- file itself. The evaluator shall then run the application and exercise all features of
- the application as described in the ST. The evaluator shall then compare each executable
- file with the either the saved hash or the saved copy of the files. The evaluator shall
- verify that these are identical.
+ file itself. The evaluator shall then run the application and exercise all features of
+ the application as described in the ST. The evaluator shall then compare each executable
+ file with the either the saved hash or the saved copy of the files. The evaluator shall
+ verify that these are identical.
- Test FPT_TUD_EXT.2.2:5[conditional, Platforms:Oracle Solaris: Oracle's enterprise operating system.]:
- The evaluator shall install the application and then locate all of its executable files.
+ The evaluator shall install the application and then locate all of its executable files.
The evaluator shall then, for each file, save off either a hash of the file or a copy of the
- file itself. The evaluator shall then run the application and exercise all features of
- the application as described in the ST. The evaluator shall then compare each executable
- file with the either the saved hash or the saved copy of the files. The evaluator shall
- verify that these are identical.
+ file itself. The evaluator shall then run the application and exercise all features of
+ the application as described in the ST. The evaluator shall then compare each executable
+ file with the either the saved hash or the saved copy of the files. The evaluator shall
+ verify that these are identical.
- Test FPT_TUD_EXT.2.2:6[conditional, Platforms:Apple macOS: Apple's operating system for MACs.]:
- The evaluator shall install the application and then locate all of its executable files.
+ The evaluator shall install the application and then locate all of its executable files.
The evaluator shall then, for each file, save off either a hash of the file or a copy of the
- file itself. The evaluator shall then run the application and exercise all features of
- the application as described in the ST. The evaluator shall then compare each executable
- file with the either the saved hash or the saved copy of the files. The evaluator shall
- verify that these are identical.
+ file itself. The evaluator shall then run the application and exercise all features of
+ the application as described in the ST. The evaluator shall then compare each executable
+ file with the either the saved hash or the saved copy of the files. The evaluator shall
+ verify that these are identical.
The evaluator shall verify that the TSS identifies how the application installation package
- is signed by an authorized source . The definition of an authorized source must be contained
- in the TSS.
- Guidance
- Tests
+ is signed by an authorized source . The definition of an authorized source must be contained
+ in the TSS.
+ Guidance
+ Tests
Appendix C - Entropy Documentation and Assessment
This appendix describes the required supplementary information for the entropy
- source used by the TOE.
+ 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
+ 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.
+ operating conditions, and health testing. This documentation is not required to
+ be part of the TSS.
C.1 Design Description
Documentation shall include the design of the entropy source as a whole,
- including the interaction of all entropy source components. Any information
+ 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.
+ third-party entropy sources that are included in the product.
The documentation will describe the operation of the entropy source to
include, how entropy is produced, and how unprocessed (raw) data can be
- obtained from within the entropy source for testing purposes. The documentation
+ obtained from within the entropy source for testing purposes. The documentation
should walk through the entropy source design indicating where the entropy
comes from, where the entropy output is passed next, any post-processing
of the raw outputs (hash, XOR, etc.), if/where it is stored, and finally,
- how it is output from the entropy source. Any conditions placed on the
+ 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.
+ 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.
+ 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
+ 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. C.2 Entropy Justification
+ power-on shall be included. C.2 Entropy Justification
There should be a technical argument for where the unpredictability in
the source comes from and why there is confidence in the entropy source
delivering sufficient entropy for the uses made of the RBG output
- (by this particular TOE). This argument will include a description of
- the expected min-entropy rate (i.e. the minimum entropy (in bits) per
+ (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
+ 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.
+ 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.
+ 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
+ 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.
+ 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
+ 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
+ clearly stated in the documentation provided. In particular, the
min-entropy estimate must be specified and the assumption included
- in the ST.
+ 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
+ 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.
+ 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. C.3 Operating Conditions
+ any third-party application or from any state saving between restarts. C.3 Operating Conditions
The entropy rate may be affected by conditions outside the control
- of the entropy source itself. For example, voltage, frequency,
+ of the entropy source itself. For example, voltage, frequency,
temperature, and elapsed time after power-on are just a few of the
- factors that may affect the operation of the entropy source. As such, documentation will also include the range of operating conditions
- under which the entropy source is expected to generate random data. It will clearly describe the measures that have been taken in the
+ factors that may affect the operation of the entropy source. As such, documentation will also include the range of operating conditions
+ under which the entropy source is expected to generate random data. It will clearly describe the measures that have been taken in the
system design to ensure the entropy source continues to operate
- under those conditions. Similarly, documentation shall describe
+ under those conditions. Similarly, documentation shall describe
the conditions under which the entropy source is known to malfunction
- or become inconsistent. Methods used to detect failure or degradation
- of the source shall be included. C.4 Health Testing
+ or become inconsistent. Methods used to detect failure or degradation
+ of the source shall be included. C.4 Health Testing
More specifically, all entropy source health tests and their rationale
- will be documented. This will include a description of the health tests,
+ will be documented. This will include a description of the health tests,
the rate and conditions under which each health test is performed
(e.g., at startup, continuously, or on-demand), the expected results
for each health test, and rationale indicating why each test is
believed to be appropriate for detecting one or more failures in the
- entropy source. Appendix D - Application Software Equivalency GuidelinesD.1 Introduction
+ entropy source. Appendix D - Application Software Equivalency GuidelinesD.1 Introduction
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.
+ 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 NIAP Policy #5 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.
+ 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 NIAP Policy #5 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
+ 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
+ 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
+ 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.
+ certificate.
Equivalency has two aspects:
- Product Equivalence: Products may be considered equivalent if there are no
- differences between Product Models and Product Versions with respect to PP-specified security functionality.
- Platform Equivalence: Platforms may be considered equivalent if there are no
+ differences between Product Models and Product Versions with respect to PP-specified security functionality.
- Platform Equivalence: Platforms may be considered equivalent if there are no
significant differences in the services they provide to the Product—or in the way the platforms
- provide those services—with respect to PP-specified security functionality.
- The equivalency determination is made in accordance with these guidelines by the Validator and Scheme using information provided by the Evaluator/Vendor. D.2 Approach to Equivalency Analysis
- 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
+ provide those services—with respect to PP-specified security functionality.
+ The equivalency determination is made in accordance with these guidelines by the Validator and Scheme using information provided by the Evaluator/Vendor. D.2 Approach to Equivalency Analysis
+ 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 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.
+ 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 AppPP.
+ 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 AppPP.
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.
+ 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.
+ 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
+ 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
+ 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
+ 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.
+ differently to perform the function.
D.3 Specific Guidance for Determining Product Model Equivalence
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”
+ 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.
| 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,
+ functionality—as indicated in Table 1.
| 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.
- |
Table 1. Determining Product Model Equivalence
D.4 Specific Guidance for Determining Product Version Equivalence
+ PP-specified functionality. If the Product Models are separately tested fully, then there is no need to document the differences.
+ |
Table 1. Determining Product Model Equivalence
D.4 Specific Guidance for Determining Product Version Equivalence
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.
| 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
+ 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.
| 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. |
Table 2. Factors for Determining Product Version Equivalence
- 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.
+ PP-specified functionality. If the Product Versions are separately tested fully, then there is
+ no need to document the differences. |
Table 2. Factors for Determining Product Version Equivalence
+ 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.
+ 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.
D.5.1 Platform Equivalence—Hardware/Virtual Hardware Platforms
+ 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.
D.5.1 Platform Equivalence—Hardware/Virtual Hardware Platforms
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
+ 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
+ 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
+ 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
+ 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.
+ 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. | 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. |
Table 3. Factors for Determining Hardware/Virtual Hardware Platform Equivalence
D.5.2 Platform Equivalence—OS Platforms
+ security functionality. | 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. |
Table 3. Factors for Determining Hardware/Virtual Hardware Platform Equivalence
D.5.2 Platform Equivalence—OS 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
+ security functionality. Generally, these are the processor interface, device interfaces, and OS APIs. The following
factors applied in order:
- | 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
+ | 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. |
Table 4. Factors for Determining OS/VS Platform Equivalence
D.5.3 Software-based Execution Environment Platform Equivalence
+ not provide such functionality to the application. |
Table 4. Factors for Determining OS/VS Platform Equivalence
D.5.3 Software-based Execution Environment Platform Equivalence
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.
+ 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.
| 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
+ 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. |
Table 5. Factors for Software-based Execution Environment Platform Equivalence
D.6 Level of Specificity for Tested Configurations and Claimed Equivalent Configurations
- In order to make equivalency determinations, the vendor and evaluator must agree on the equivalency claims. They must
+ functionality to applications. Table 5. Factors for Software-based Execution Environment Platform Equivalence
D.6 Level of Specificity for Tested Configurations and Claimed Equivalent Configurations
+ 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.
+ 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
+ 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
+ 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.
+ 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
+ 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
+ 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 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.
Appendix E - AcronymsTable 3: Acronyms
- | API | Application Programming Interface |
-| app | Application |
-| ASLR | Address Space Layout Randomization |
-| Base-PP | Base Protection Profile |
+ configuration.
Appendix E - AcronymsTable 3: Acronyms
+ | Base-PP | Base Protection Profile |
| CC | Common Criteria |
| CEM | Common Evaluation Methodology |
| cPP | Collaborative Protection Profile |
-| DEP | Data Execution Prevention |
| EP | Extended Package |
| FP | Functional Package |
| OE | Operational Environment |
-| OS | Operating System |
-| PII | Personally Identifiable Information |
| PP | Protection Profile |
| PP-Configuration | Protection Profile Configuration |
| PP-Module | Protection Profile Module |
@@ -4068,15 +4177,15 @@ D.3 Specific Guidance for D
Appendix F - BibliographyTable 4: Bibliography| [CC] | Common Criteria for Information Technology Security Evaluation - | | [CEM] | Common
Evaluation Methodology for Information Technology Security - Evaluation Methodology,
- CCMB-2017-04-004, Version 3.1, Revision 5, April 2017. | | [OMB] | Reporting Incidents Involving Personally Identifiable Information and Incorporating the
+ CCMB-2017-04-004, Version 3.1, Revision 5, April 2017. | | [OMB] | Reporting Incidents Involving Personally Identifiable Information and Incorporating the
Cost for Security in Agency Information Technology Investments, OMB M-06-19, July
- 12, 2006. | |
|
