From 7a43cb8d387166fe37047584b0f9897e854b625d Mon Sep 17 00:00:00 2001 From: Livi Thomas Date: Fri, 22 Nov 2024 13:55:49 -0700 Subject: [PATCH] Testing for new TipTapEditor --- input/virtualization.xml | 4399 ++++++++++++++++++++------------------ 1 file changed, 2288 insertions(+), 2111 deletions(-) diff --git a/input/virtualization.xml b/input/virtualization.xml index 9c97007..1cf5b23 100644 --- a/input/virtualization.xml +++ b/input/virtualization.xml @@ -45,94 +45,140 @@ /~https://github.com/commoncriteria/clientvirtualizationrelease-1.1https://www.niap-ccevs.org/Profile/Info.cfm?PPID=409&id=409/~https://github.com/commoncriteria/servervirtualizationrelease-1.1https://www.niap-ccevs.org/Profile/Info.cfm?PPID=410&id=410 -
A Virtualization System (VS) is a software product that enables multiple independent computing systems to execute on the same physical hardware platform without interference from one another. A VS creates a virtualized hardware environment (virtual machines or VMs) for each instance of an operating system permitting these environments to execute concurrently while maintaining isolation and the appearance of exclusive control over assigned computing resources. For the purposes of this document, the VS consists of a Virtual Machine Manager (VMM), Virtual Machine (VM) abstractions, a management subsystem, and other components.A VMM is a collection of software components responsible for enabling VMs to function as expected by the software executing within them. Generally, the VMM consists of a Hypervisor, Service VMs, and other components of the VS, such as virtual devices, binary translation systems, and physical device drivers. It manages concurrent execution of all VMs and virtualizes platform resources as needed.The Hypervisor is the software executive of the physical platform of a VS. A hypervisor operates at the highest CPU privilege level and manages access to all of the physical resources of the hardware platform. It exports a well-defined, protected interface for access to the resources it manages. A Hypervisor’s primary function is to mediate access to all CPU and memory resources, but it is also responsible for either the direct management or the delegation of the management of all other hardware devices on the hardware platform. This document does not specify any Hypervisor-specific requirements, though many VMM requirements would naturally apply to a Hypervisor.A Service VM is a VM whose purpose is to support the Hypervisor in providing the resources or services necessary to support Guest VMs. Service VMs may implement some portion of Hypervisor functionality, but also may contain important system functionality that is not necessary for Hypervisor operation. As with any VM, Service VMs necessarily execute without full Hypervisor privileges—only the privileges required to perform its designed functionality. Examples of Service VMs include device driver VMs that manage access to physical devices, VMs that provide life-cycle management and provisioning of Hypervisor and Guest VMs, and name-service VMs that help establish communication paths between VMs.A Guest VM is a VM that contains a virtual environment for the execution of an independent computing system. Virtual environments execute mission workloads and implement customer-specific client or server functionality in Guest VMs, such as a web server or desktop productivity applications. A Helper VM is a VM that performs services on behalf of one or more Guest VMs, but does not qualify as a Service VM—and therefore is not part of the VMM. Helper VMs implement functions or services that are particular to the workloads of Guest VMs. For example, a VM that provides a virus scanning service for a Guest VM would be considered a Helper VM. The line between Helper and Service VMs can easily be blurred. For instance, a VM that implements a cryptographic function—such as an in-line encryption VM—could be identified as either a Service or Helper VM depending on the particular virtualization solution. If the cryptographic functions are necessary only for the privacy of Guest VM data in support of the Guest’s mission applications, it would be proper to classify the encryption VM as a Helper. But if the encryption VM is necessary for the VMM to isolate Guest VMs, it would be proper to classify the encryption VM as a Service VM. For the purposes of this document, Helper VMs are subject to all requirements that apply to Guest VMs, unless specifically stated otherwise.
+
+ A Virtualization System (VS) is a software product that enables multiple independent computing systems to execute on the + same physical hardware platform without interference from one another. A VS creates a virtualized hardware environment + (virtual machines or VMs) for each instance of an operating system permitting these environments to execute + concurrently while maintaining isolation and the appearance of exclusive control over assigned computing resources. + For the purposes of this document, the VS consists of a Virtual Machine Manager (VMM), Virtual Machine (VM) + abstractions, a management subsystem, and other components. + A VMM is a collection of software components responsible for enabling VMs to function as expected by the software + executing within them. Generally, the VMM consists of a Hypervisor, Service VMs, and other components of the VS, + such as virtual devices, binary translation systems, and physical device drivers. It manages concurrent execution of + all VMs and virtualizes platform resources as needed. + The Hypervisor is the software executive of the physical platform of a VS. A hypervisor operates at + the highest CPU privilege level and manages access to all of the physical resources of the hardware platform. It + exports a well-defined, protected interface for access to the resources it manages. A Hypervisor’s primary function is + to mediate access to all CPU and memory resources, but it is also responsible for either the direct management or the + delegation of the management of all other hardware devices on the hardware platform. This document does not specify + any Hypervisor-specific requirements, though many VMM requirements would naturally apply to a Hypervisor. + A Service VM is a VM whose purpose is to support the Hypervisor in providing the resources or services necessary to + support Guest VMs. Service VMs may implement some portion of Hypervisor functionality, but also may contain important + system functionality that is not necessary for Hypervisor operation. As with any VM, Service VMs necessarily execute + without full Hypervisor privileges—only the privileges required to perform its designed functionality. Examples of + Service VMs include device driver VMs that manage access to physical devices, VMs that provide life-cycle management and + provisioning of Hypervisor and Guest VMs, and name-service VMs that help establish + communication paths between VMs. + A Guest VM is a VM that contains a virtual environment for the execution of an independent computing system. Virtual + environments execute mission workloads and implement customer-specific client or server functionality in Guest VMs, + such as a web server or desktop productivity applications. A Helper VM is a VM that performs services on behalf of + one or more Guest VMs, but does not qualify as a Service VM—and therefore is not part of the VMM. Helper VMs implement + functions or services that are particular to the workloads of Guest VMs. For example, a VM that provides a virus + scanning service for a Guest VM would be considered a Helper VM. The line between Helper and Service VMs can easily + be blurred. For instance, a VM that implements a cryptographic function—such as an in-line encryption VM—could be + identified as either a Service or Helper VM depending on the particular virtualization solution. If the cryptographic + functions are necessary only for the privacy of Guest VM data in support of the Guest’s mission applications, it would + be proper to classify the encryption VM as a Helper. But if the encryption VM is necessary for the VMM to isolate + Guest VMs, it would be proper to classify the encryption VM as a Service + VM. For the purposes of this document, Helper VMs are subject to all requirements + that apply to Guest VMs, unless specifically stated otherwise.
- Administrators perform management activities on the VS. These management functions do not - include administration of software running within Guest VMs, such as the Guest OS. Administrators need not be human - as in the case of embedded or headless VMs. Administrators are often nothing more than software entities that - operate within the VM. + Administrators perform management activities on the VS. These management functions do not + include administration of software running within Guest VMs, such as the Guest OS. Administrators need not be human + as in the case of embedded or headless VMs. Administrators are often nothing more than software entities that + operate within the VM. Auditors are responsible for managing the audit capabilities of the TOE. An Auditor may also be an - Administrator. It is not a requirement that the TOE be capable of supporting an Auditor role that is separate from - that of an Administrator. - A Domain or Information Domain is a policy construct that groups together execution environments and - networks by sensitivity of information and access control policy. For example, classification levels represent - information domains. Within classification levels, there might be other domains representing communities of interest - or coalitions. In the context of a VS, information domains are generally implemented as collections of VMs connected - by virtual networks. The VS itself can be considered an Information Domain, as can its Management Subsystem. + Administrator. It is not a requirement that the TOE be capable of supporting an Auditor role that is separate from + that of an Administrator. + A Domain or Information Domain is a policy construct that groups together execution environments and + networks by sensitivity of information and access control policy. For example, classification levels represent + information domains. Within classification levels, there might be other domains representing communities of interest + or coalitions. In the context of a VS, information domains are generally implemented as collections of VMs connected + by virtual networks. The VS itself can be considered an Information Domain, as can its Management Subsystem. See Operational Network. An operating system that runs within a Guest VM. A Guest VM is a VM that contains a virtual environment for the execution of an independent computing - system. Virtual environments execute mission workloads and implement customer-specific client or server functionality - in Guest VMs, such as a web server or desktop productivity applications. + system. Virtual environments execute mission workloads and implement customer-specific client or server functionality + in Guest VMs, such as a web server or desktop productivity applications. A Helper VM is a VM that performs services on behalf of one or more Guest VMs, but does not qualify - as a Service VM—and therefore is not part of the VMM. Helper VMs implement functions or services that are particular - to the workloads of Guest VMs. For example, a VM that provides a virus scanning service for a Guest VM would be - considered a Helper VM. For the purposes of this document, Helper VMs are considered a type of Guest VM, and are - therefore subject to all the same requirements, unless specifically stated otherwise. - An operating system onto which a VS is installed. Relative to the VS, the Host OS is - part of the Platform. There need not be a Host OS, but often VSes employ a Host OS or Control Domain to support - guest access to host resources. Sometimes these domains are themselves encapsulated within VMs. + as a Service VM—and therefore is not part of the VMM. Helper VMs implement functions or services that are particular + to the workloads of Guest VMs. For example, a VM that provides a virus scanning service for a Guest VM would be + considered a Helper VM. For the purposes of this document, Helper VMs are considered a type of Guest VM, and are + therefore subject to all the same requirements, unless specifically stated otherwise. + An operating system onto which a VS is installed. Relative to the VS, the Host OS is + part of the Platform. There need not be a Host OS, but often VSes employ a Host OS or Control Domain to support + guest access to host resources. Sometimes these domains are themselves encapsulated within VMs. The Hypervisor is part of the VMM. It is the software executive of the physical platform of a VS. - A Hypervisor’s primary function is to mediate access to all CPU and memory resources, but it is also responsible - for either the direct management or the delegation of the management of all other hardware devices on the hardware - platform. + A Hypervisor’s primary function is to mediate access to all CPU and memory resources, but it is also responsible + for either the direct management or the delegation of the management of all other hardware devices on the hardware + platform. An API function that allows VM-aware software running within a VM to invoke VMM functionality. See Domain. - A capability that allows a specially designated and privileged domain to have visibility into - another domain for purposes of anomaly detection or monitoring. - A network, which may have both physical and virtualized components, used to manage and - administer a VS. Management networks include networks used by VS Administrators to communicate with management - components of the VS, and networks used by the VS for communications between VS components. For purposes of this - document, networks that connect physical hosts and backend storage networks for purposes of VM transfer or backup - are considered management networks. - Components of the VS that allow VS Administrators to configure and manage the VMM, as - well as configure Guest VMs. VMM management functions include VM configuration, virtualized network configuration, - and allocation of physical resources. - An Operational Network is a network, which may have both physical and virtualized - components, used to connect Guest VMs to each other and potentially to other entities outside of the VS. Operational - Networks support mission workloads and customer-specific client or server functionality. Also called a - “Guest Network.” + A capability that allows a specially designated and privileged domain to have visibility into + another domain for purposes of anomaly detection or monitoring. + A network, which may have both physical and virtualized components, used to manage and + administer a VS. Management networks include networks used by VS Administrators to communicate with management + components of the VS, and networks used by the VS for communications between VS components. For purposes of this + document, networks that connect physical hosts and backend storage networks for purposes of VM transfer or backup + are considered management networks. + Components of the VS that allow VS Administrators to configure and manage the VMM, as + well as configure Guest VMs. VMM management functions include VM configuration, virtualized network configuration, + and allocation of physical resources. + An Operational Network is a network, which may have both physical and virtualized + components, used to connect Guest VMs to each other and potentially to other entities outside of the VS. Operational + Networks support mission workloads and customer-specific client or server functionality. Also called a + “Guest Network.” The hardware environment on which a VS executes. Physical platform resources include - processors, memory, devices, and associated firmware. + processors, memory, devices, and associated firmware. The hardware, firmware, and software environment into which a VS is installed and executes. A Service VM is a VM whose purpose is to support the Hypervisor in providing the resources or - services necessary to support Guest VMs. Service VMs may implement some portion of Hypervisor functionality, but - also may contain important system functionality that is not necessary for Hypervisor operation. As with any VM, - Service VMs necessarily execute without full Hypervisor privileges—only the privileges required to perform its - designed functionality. Examples of Service VMs include device driver VMs that manage access to physical devices, - VMs that provide life-cycle management and provisioning of Hypervisor and Guest VMs, and name-service VMs that - help establish communication paths between VMs. + services necessary to support Guest VMs. Service VMs may implement some portion of Hypervisor functionality, but + also may contain important system functionality that is not necessary for Hypervisor operation. As with any VM, + Service VMs necessarily execute without full Hypervisor privileges—only the privileges required to perform its + designed functionality. Examples of Service VMs include device driver VMs that manage access to physical devices, + VMs that provide life-cycle management and provisioning of Hypervisor and Guest VMs, and name-service VMs that + help establish communication paths between VMs. The overall policy enforced by the VS defining constraints on the behavior - of VMs and users. + of VMs and users. Users operate Guest VMs and are subject to configuration policies applied to the VS by Administrators. - Users need not be human as in the case of embedded or headless VMs, users are often nothing more than software - entities that operate within the VM. + Users need not be human as in the case of embedded or headless VMs, users are often nothing more than software + entities that operate within the VM. A Virtual Machine is a virtualized hardware environment in which an operating system - may execute. + may execute. A VMM is a collection of software components responsible for enabling VMs to - function as expected by the software executing within them. Generally, the VMM consists of a Hypervisor, Service - VMs, and other components of the VS, such as virtual devices, binary translation systems, and physical device - drivers. It manages concurrent execution of all VMs and virtualizes platform resources as needed. - A software product that enables multiple independent computing systems to - execute on the same physical hardware platform without interference from one another. For the purposes of this - document, the VS consists of a Virtual Machine Manager (VMM), Virtual Machine abstractions, a management subsystem, - and other components. + function as expected by the software executing within them. Generally, the VMM consists of a Hypervisor, Service + VMs, and other components of the VS, such as virtual devices, binary translation systems, and physical device + drivers. It manages concurrent execution of all VMs and virtualizes platform resources as needed. + A software product that enables multiple independent computing systems to + execute on the same physical hardware platform without interference from one another. For the purposes of this + document, the VS consists of a Virtual Machine Manager (VMM), Virtual Machine abstractions, a management subsystem, + and other components. - This Base-PP does not define any use cases for virtualization technology. Client Virtualization and Server Virtualization products have different use cases and so these are defined in their respective PP-Modules. + + This Base-PP does not define any use cases for virtualization technology. Client Virtualization and Server Virtualization + products have different use cases and so these are defined in their respective PP-Modules. + - A Security Target must claim exact conformance to this Protection Profile, as defined in the CC and CEM addenda for Exact Conformance, Selection-Based SFRs, and Optional SFRs (dated May 2017).The following PPs and PP-Modules are allowed to be specified in a PP-Configuration with this PP-Module with this PP.PP-Module for Client Virtualization Systems, Version 1.1PP-Module for Server Virtualization Systems, Version 1.1 + A Security Target must claim exact conformance to this Protection Profile, + as defined in the CC and CEM addenda for Exact Conformance, Selection-Based SFRs, and + Optional SFRs (dated May 2017). + The following PPs and PP-Modules are allowed to be specified in a PP-Configuration with this PP-Module + with this PP.PP-Module for Client Virtualization Systems, Version 1.1PP-Module for Server Virtualization Systems, Version 1.1 - This PP is conformant to Parts 2 (extended) and 3 (extended) of Common Criteria Version 3.1, Release 5 [CC]. + + This PP is conformant to Parts 2 (extended) and 3 (extended) of Common Criteria Version 3.1, + Release 5 [CC]. + - + - + @@ -142,13 +188,13 @@ - In some VS implementations, functions critical to the security of the TOE are by necessity performed by software not produced by the virtualization vendor. Such software may include physical device drivers, and even non-TOE entities such as Host Operating Systems. Since this software has the same or similar privilege level as the VS, vulnerabilities can be exploited by an adversary to compromise the VS and VMs. Where possible, the VS should mitigate the results of potential vulnerabilities or malicious content in third-party code on which it relies. For example, physical device drivers (potentially the Host OS) could be encapsulated within VMs in order to limit the effects of compromise. + In some VS implementations, functions critical to the security of the TOE are by necessity performed by software not produced by the virtualization vendor. Such software may include physical device drivers, and even non-TOE entities such as Host Operating Systems. Since this software has the same or similar privilege level as the VS, vulnerabilities can be exploited by an adversary to compromise the VS and VMs. Where possible, the VS should mitigate the results of potential vulnerabilities or malicious content in third-party code on which it relies. For example, physical device drivers (potentially the Host OS) could be encapsulated within VMs in order to limit the effects of compromise. The VMM integrity mechanisms include environment-based vulnerability mitigation and potentiallysupport for introspection and device driver isolation, all of which reduce the likelihood that any vulnerabilities in third-party software can be used to exploit the TOE. - It is a fundamental property of VMs that the domains encapsulated by different VMs remain separate unless data sharing is permitted by policy. For this reason, all Virtualization Systems shall support a policythat prohibits information transfer between VMs. It shall be possible to configure VMs such that data cannot be moved between domains from VM to VM, orthrough virtual or physical network components under the control of the VS. When VMs are configured assuch, it shall not be possible for data to leak between domains, neither by the express efforts ofsoftware or users of a VM, nor because of vulnerabilities or errors in the implementation of the VMM orother VS components. If it is possible for data to leak between domains when prohibited by policy, then an adversary on one domain or network can obtain data from another domain. Such cross-domain data leakage can, for example, causeclassified information, corporate proprietary information, or personally identifiable information to bemade accessible to unauthorized entities. + It is a fundamental property of VMs that the domains encapsulated by different VMs remain separate unless data sharing is permitted by policy. For this reason, all Virtualization Systems shall support a policythat prohibits information transfer between VMs. It shall be possible to configure VMs such that data cannot be moved between domains from VM to VM, orthrough virtual or physical network components under the control of the VS. When VMs are configured assuch, it shall not be possible for data to leak between domains, neither by the express efforts ofsoftware or users of a VM, nor because of vulnerabilities or errors in the implementation of the VMM orother VS components. If it is possible for data to leak between domains when prohibited by policy, then an adversary on one domain or network can obtain data from another domain. Such cross-domain data leakage can, for example, causeclassified information, corporate proprietary information, or personally identifiable information to bemade accessible to unauthorized entities. Logical separation of VMs and enforcement of domain integrity prevent unauthorized transmission of data from one VM to another. @@ -157,31 +203,31 @@ - A VM may block others from system resources (e.g., system memory, persistent storage, and processing time) via a resource exhaustion attack. + A VM may block others from system resources (e.g., system memory, persistent storage, and processing time) via a resource exhaustion attack. The ability of the TSF to ensure the proper allocation of resources makes denial of serviceattacks more difficult. - The VS may be misconfigured, which could impact its functioning and security. This misconfiguration could be due to an administrative error or the use of faulty configuration data. + The VS may be misconfigured, which could impact its functioning and security. This misconfiguration could be due to an administrative error or the use of faulty configuration data. Mechanisms to prevent the application of configurations that violate the current security policy help prevent misconfigurations. - The VS must be capable of protecting the platform from threats that originate within VMs and operational networks connected to the VS. The hosting of untrusted—even malicious—domains by the VS cannot be permitted to compromise the security and integrity of the platform on which the VS executes. If an attacker can access the underlying platform in a manner not controlled by the VMM, the attacker might be able to modify system firmware or software—compromising both the VS and the underlying platform. + The VS must be capable of protecting the platform from threats that originate within VMs and operational networks connected to the VS. The hosting of untrusted—even malicious—domains by the VS cannot be permitted to compromise the security and integrity of the platform on which the VS executes. If an attacker can access the underlying platform in a manner not controlled by the VMM, the attacker might be able to modify system firmware or software—compromising both the VS and the underlying platform. Platform integrity mechanisms used by the TOE reduce the risk that an attacker can ‘break out’ of a VM and affect the platform on which the VS is running. - Functions performed by the management layer include VM configuration, virtualized network configuration, allocation of physical resources, and reporting. Only certain authorized system users (administrators) are allowed to exercise management functions or obtain sensitive information from the TOE. Virtualization Systems are often managed remotely over communication networks. Members of these networks can be both geographically and logically separated from each other, and pass through a variety of other systems which may be under the control of an adversary, and offer the opportunity for communications to be compromised. An adversary with access to an open management network could inject commands into the management infrastructure or extract sensitive information. This would provide an adversary with administrator privilege on the platform, and administrative control over the VMs and virtual network connections. The adversary could also gain access to the management network by hijacking the management network channel. + Functions performed by the management layer include VM configuration, virtualized network configuration, allocation of physical resources, and reporting. Only certain authorized system users (administrators) are allowed to exercise management functions or obtain sensitive information from the TOE. Virtualization Systems are often managed remotely over communication networks. Members of these networks can be both geographically and logically separated from each other, and pass through a variety of other systems which may be under the control of an adversary, and offer the opportunity for communications to be compromised. An adversary with access to an open management network could inject commands into the management infrastructure or extract sensitive information. This would provide an adversary with administrator privilege on the platform, and administrative control over the VMs and virtual network connections. The adversary could also gain access to the management network by hijacking the management network channel. Ensuring that TSF management functions cannot be executed without authorization prevents untrustedsubjects from modifying the behavior of the TOE in an unanticipated manner. - System integrity is a core security objective for Virtualization Systems. To achieve system integrity, the integrity of each VMM component must be established and maintained. Malware running on the platform must not be able to undetectably modify VS components while the system is running or at rest. Likewise, malicious code running within a virtual machine must not be able to modify Virtualization System components. + System integrity is a core security objective for Virtualization Systems. To achieve system integrity, the integrity of each VMM component must be established and maintained. Malware running on the platform must not be able to undetectably modify VS components while the system is running or at rest. Likewise, malicious code running within a virtual machine must not be able to modify Virtualization System components. Enforcement of VMM integrity prevents the bypass of enforcement mechanisms and auditing ensuresthat abuse of legitimate authority can be detected. @@ -190,25 +236,25 @@ - It is common for attackers to target outdated versions of software containing known flaws. This means it is extremely important to update VS software as soon as possible when updates are available. But the source of the updates and the updates themselves must be trusted. If an attacker can write their own update containing malicious code they can take control of the VS. + It is common for attackers to target outdated versions of software containing known flaws. This means it is extremely important to update VS software as soon as possible when updates are available. But the source of the updates and the updates themselves must be trusted. If an attacker can write their own update containing malicious code they can take control of the VS. System integrity prevents the TOE from installing a software patch containing unknown andpotentially malicious code. - Vulnerabilities in outdated or unpatched software can be exploited by adversaries to compromise the VS or platform. + Vulnerabilities in outdated or unpatched software can be exploited by adversaries to compromise the VS or platform. The ability to patch the TOE software ensures that protections against vulnerabilities can be applied as they become available. - If a Virtualization System is capable of simultaneously displaying VMs of different domains to the same user at the same time, there is always the chance that the user will become confused and unintentionally leak information between domains. This is especially likely if VMs belonging to different domains are indistinguishable. Malicious code may also attempt to interfere with the user’s ability to distinguish between domains. The VS must take measures to minimize the likelihood of such confusion. + If a Virtualization System is capable of simultaneously displaying VMs of different domains to the same user at the same time, there is always the chance that the user will become confused and unintentionally leak information between domains. This is especially likely if VMs belonging to different domains are indistinguishable. Malicious code may also attempt to interfere with the user’s ability to distinguish between domains. The VS must take measures to minimize the likelihood of such confusion. Isolation of VMs includes clear attribution of those VMs to their respective domains which reducesthe likelihood that a user inadvertently inputs or transfers data meant for one VM into another. - The VS is designed to provide the appearance of exclusivity to the VMs and is designed to separate or isolate their functions except where specifically shared. Failure of security mechanisms could lead to unauthorized intrusion into or modification of the VMM, or bypass of the VMM altogether, by non-TOE software, such as that running in Guest or Helper VMs or on the host platform. This must be prevented to avoid compromising the VS. + The VS is designed to provide the appearance of exclusivity to the VMs and is designed to separate or isolate their functions except where specifically shared. Failure of security mechanisms could lead to unauthorized intrusion into or modification of the VMM, or bypass of the VMM altogether, by non-TOE software, such as that running in Guest or Helper VMs or on the host platform. This must be prevented to avoid compromising the VS. Maintaining the integrity of the VMM and ensuring that VMs execute in isolated domains mitigatethe risk that the VMM can be compromised or bypassed. @@ -217,7 +263,7 @@ - To the extent that VMs appear isolated within the VS, a threat of weak cryptography may arise if the VMM does not provide good entropy to support security-related features that depend on entropy to implement cryptographic algorithms. For example, a random number generator keeps an estimate of the number of bits of noise in the entropy pool. From this entropy pool random numbers are created. Good random numbers are essential to implementing strong cryptography. Cryptography implemented using poor random numbers can be defeated by a sophisticated adversary. Such defeat can result in the compromise of Guest VM data and credentials, and of VS data and credentials, and can enable unauthorized access to the VS or VMs. + To the extent that VMs appear isolated within the VS, a threat of weak cryptography may arise if the VMM does not provide good entropy to support security-related features that depend on entropy to implement cryptographic algorithms. For example, a random number generator keeps an estimate of the number of bits of noise in the entropy pool. From this entropy pool random numbers are created. Good random numbers are essential to implementing strong cryptography. Cryptography implemented using poor random numbers can be defeated by a sophisticated adversary. Such defeat can result in the compromise of Guest VM data and credentials, and of VS data and credentials, and can enable unauthorized access to the VS or VMs. Acquisition of good entropy is necessary to support the TOE's security-related cryptographicalgorithms. @@ -228,34 +274,37 @@ - The user of the VS is not willfully negligent or hostile, and uses the VS in compliance with the applied enterprise security policy and guidance. At the same time, malicious applications could act as the user, so requirements which confine malicious applications are still in scope. + The user of the VS is not willfully negligent or hostile, and uses the VS in compliance with the + applied enterprise security policy and guidance. At the same time, malicious applications could act as + the user, so requirements which confine malicious applications are still in scope. If the TOE is administered by a non-malicious and non-negligent user, the expected result is that the TOE - will be configured in a correct and secure manner. + will be configured in a correct and secure manner. If the organization properly vets and trains users, it is expected that they will be non-malicious. - Physical security commensurate with the value of the TOE and the data it contains is assumed to be provided by the environment. + Physical security commensurate with the value of the TOE and the data it contains is assumed to + be provided by the environment. If the TOE is deployed in a location that has appropriate physical safeguards, it can be assumed - to be physically secure. + to be physically secure. The platform has not been compromised prior to installation of the VS. If the underlying platform has not been compromised prior to installation of the TOE, its integrity - can be assumed to be intact. + can be assumed to be intact. TOE Administrators are trusted to follow and apply all administrator guidance. Providing guidance to administrators and ensuring that individuals are properly trained and - vetted before being given administrative responsibilities will ensure that they are trusted. + vetted before being given administrative responsibilities will ensure that they are trusted. @@ -263,7 +312,7 @@ - - requires the TSF to transmit audit data using a trusted channel to an outside entity and to specify - the action to be taken when local audit storage is full. + requires the TSF to transmit audit data using a trusted channel to an outside entity and to specify + the action to be taken when local audit storage is full. The following actions could be considered for the management functions in FMT: - Ability to configure and manage the audit system and audit data, - including the ability to configure name/address of audit/logging server - to which to send audit/logging records. - The following actions should be auditable if FAU_GEN Security audit data generation - is included in the PP/ST: - Failure of audit data capture due to lack of disk space or pre-defined limit.On failure of logging function, capture record of failure and record upon restart of logging function. + Ability to configure and manage the audit system and audit data, + including the ability to configure name/address of audit/logging server + to which to send audit/logging records. + The following actions should be auditable if FAU_GEN Security audit data generation + is included in the PP/ST: + Failure of audit data capture due to lack of disk space or pre-defined limit.On failure of logging function, capture record of failure and record upon restart of logging function. FAU_GEN.1 Audit Data Generation - FTP_ITC_EXT.1 Trusted Channel Communications + FTP_ITC_EXT.1 Trusted Channel Communications The TSF shall be able to transmit the generated audit data to an external IT entity using a trusted channel as specified in FTP_ITC_EXT.1. - The evaluator shall examine the TSS to ensure it describes the means by which - the audit data are transferred to the external audit server, and how the trusted channel is - provided. + The evaluator shall examine the TSS to ensure it describes the means by which + the audit data are transferred to the external audit server, and how the trusted channel is + provided. - The evaluator shall examine the operational guidance to ensure it describes how to establish the - trusted channel to the audit server, as well as describe any requirements - on the audit server (particular audit server protocol, version of the protocol required, etc.), as well - as configuration of the TOE needed to communicate with the audit server. - + The evaluator shall examine the operational guidance to ensure it describes how to establish the + trusted channel to the audit server, as well as describe any requirements + on the audit server (particular audit server protocol, version of the protocol required, etc.), as well + as configuration of the TOE needed to communicate with the audit server. + - - Protocols used for implementing the trusted channel must be selected in FTP_ITC_EXT.1. - + + Protocols used for implementing the trusted channel must be selected in FTP_ITC_EXT.1. + The evaluator shall establish a session between the TOE and the audit server according - to the configuration guidance provided. The evaluator shall then examine the traffic - that passes between the audit server and the TOE during several activities of the - evaluator’s choice designed to generate audit data to be transferred to the audit server. - The evaluator shall observe that these data are not able to be viewed in the clear during - this transfer, and that they are successfully received by the audit server. The evaluator - shall record the particular software (name, version) used on the audit server during - testing. - + to the configuration guidance provided. The evaluator shall then examine the traffic + that passes between the audit server and the TOE during several activities of the + evaluator’s choice designed to generate audit data to be transferred to the audit server. + The evaluator shall observe that these data are not able to be viewed in the clear during + this transfer, and that they are successfully received by the audit server. The evaluator + shall record the particular software (name, version) used on the audit server during + testing. + @@ -676,19 +838,19 @@ The TSF shall<selectables ><selectable id="fau_stg_ext.1.2_1" >drop new audit data</selectable><selectable id="fau_stg_ext.1.2_2">overwrite previous audit records according to the following rule:<assignable>rule for overwriting previous audit records</assignable></selectable><selectable id="fau_stg_ext.1.2_5" ><assignable>other action</assignable></selectable> </selectables>when the local storage space for audit data is full. An external log server, if available, might be used as alternative storage space - in case the local storage space is full. An ‘other action’ could be defined in this case as ‘send the - new audit data to an external IT entity’. - + in case the local storage space is full. An ‘other action’ could be defined in this case as ‘send the + new audit data to an external IT entity’. + - The evaluator shall examine the TSS to ensure it describes what happens when the - local audit data store is full. + The evaluator shall examine the TSS to ensure it describes what happens when the + local audit data store is full. - The evaluator shall also examine the operational guidance to - determine that it describes the relationship between the local audit data and the audit data that - are sent to the audit log server. For example, when an audit event is generated, is it simultaneously - sent to the external server and the local store, or is the local store used as a buffer and “cleared” - periodically by sending the data to the audit server. - + The evaluator shall also examine the operational guidance to + determine that it describes the relationship between the local audit data and the audit data that + are sent to the audit log server. For example, when an audit event is generated, is it simultaneously + sent to the external server and the local store, or is the local store used as a buffer and “cleared” + periodically by sending the data to the audit server. + @@ -721,70 +883,70 @@ The TSF shall generate <h:b>asymmetric</h:b> cryptographic keys in accordance with a specified cryptographic key generation algorithm<selectables linebreak="yes"><selectable id="fcs_ckm.1.1_1" >RSA schemes using cryptographic key sizes [2048-bit or greater] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3]</selectable><selectable id="fcs_ckm.1.1_2">ECC schemes using [“NIST curves” P-256, P-384, and<selectables><selectable id="fcs_ckm.1.1_3" >P-521</selectable><selectable id="fcs_ckm.1.1_4" >no other curves</selectable></selectables>that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4]</selectable><selectable id="fcs_ckm.1.1_5" >FFC schemes using cryptographic key sizes [2048-bit or greater] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.1]].</selectable><selectable id="fcs_ckm.1.1_6" >FFC Schemes using Diffie-Hellman group 14 that meet the following: [RFC 3526]</selectable><selectable id="fcs_ckm.1.1_7" >FFC Schemes using safe primes that meet the following: [‘NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes"]</selectable> </selectables><h:s>and specified cryptographic key sizes [assignment: cryptographic key sizes] that meet the following: [assignment: list of standards]</h:s> . The ST author selects all key generation schemes used for key establishment and - device authentication. When key generation is used for key establishment, the schemes in FCS_CKM.2.1 - and selected cryptographic protocols shall match the selection. When key generation is used for device - 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. - + device authentication. When key generation is used for key establishment, the schemes in FCS_CKM.2.1 + and selected cryptographic protocols shall match the selection. When key generation is used for device + 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 evaluator shall ensure that the TSS identifies the key sizes supported by - the TOE. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify - that it identifies the usage for each scheme. + The evaluator shall ensure that the TSS identifies the key sizes supported by + the TOE. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify + that it identifies the usage for each scheme. - The evaluator shall verify that the AGD guidance instructs the administrator how to configure - the TOE to use the selected key generation schemes and key sizes for all uses defined in this PP. - + The evaluator shall verify that the AGD guidance instructs the administrator how to configure + the TOE to use the selected key generation schemes and key sizes for all uses defined in this PP. + - 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 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 the TSF to correctly produce values for the - key components including the public verification exponent e, the private prime factors p and q, - the public modulus n and the calculation of the private signature exponent d. - Key Pair generation specifies 5 ways (or methods) to generate the primes p and q. These include: Random Primes: - Provable primesProbable primes Primes with Conditions: - Primes p1, p2, q1,q2, p and q shall all be provable primesPrimes p1, p2, q1, and q2 shall be provable primes and p and q shall be - probable primesPrimes p1, p2, q1,q2, p and q shall all be probable primes - To test the key generation method for the Random Provable primes method and for all the Primes with - Conditions methods, the evaluator shall seed the TSF key generation routine with sufficient data - to deterministically generate the RSA key pair. This includes the random seeds, 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.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 determine correctness, the evaluator - shall submit the generated key pairs to the 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) - The evaluator shall verify the implementation of the Parameters Generation and the Key Generation for - FFC by the TOE using the Parameter Generation and Key Generation test. This test verifies the - ability of the TSF to correctly produce values for the field prime p, the cryptographic prime q - (dividing p-1), the cryptographic group generator g, and the calculation of the private key x and - public key y. - The Parameter generation specifies two ways (or methods) to generate the cryptographic prime q and the - field prime p:Primes q and p shall both be provable primesPrimes q and field prime p shall both be probable primes - and two ways to generate the cryptographic group generator g: - Generator g constructed through a verifiable processGenerator g constructed through an unverifiable process. - The Key generation specifies two ways to generate the private key x: - 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 - The security strength of the RBG shall 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 method and the - group generator g for a verifiable process, the evaluator shall 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 of the TSF’s implementation by comparing values - generated by the TSF with those generated from a known good implementation. Verification shall - also confirm g != 0,1q divides p-1g^q mod p = 1g^x mod p = y - 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 "safe-prime" groups is done as part of testing in FCS_CKM.2.1. + 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 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 the TSF to correctly produce values for the + key components including the public verification exponent e, the private prime factors p and q, + the public modulus n and the calculation of the private signature exponent d. + Key Pair generation specifies 5 ways (or methods) to generate the primes p and q. These include: Random Primes: + Provable primesProbable primes Primes with Conditions: + Primes p1, p2, q1,q2, p and q shall all be provable primesPrimes p1, p2, q1, and q2 shall be provable primes and p and q shall be + probable primesPrimes p1, p2, q1,q2, p and q shall all be probable primes + To test the key generation method for the Random Provable primes method and for all the Primes with + Conditions methods, the evaluator shall seed the TSF key generation routine with sufficient data + to deterministically generate the RSA key pair. This includes the random seeds, 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.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 determine correctness, the evaluator + shall submit the generated key pairs to the 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) + The evaluator shall verify the implementation of the Parameters Generation and the Key Generation for + FFC by the TOE using the Parameter Generation and Key Generation test. This test verifies the + ability of the TSF to correctly produce values for the field prime p, the cryptographic prime q + (dividing p-1), the cryptographic group generator g, and the calculation of the private key x and + public key y. + The Parameter generation specifies two ways (or methods) to generate the cryptographic prime q and the + field prime p:Primes q and p shall both be provable primesPrimes q and field prime p shall both be probable primes + and two ways to generate the cryptographic group generator g: + Generator g constructed through a verifiable processGenerator g constructed through an unverifiable process. + The Key generation specifies two ways to generate the private key x: + 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 + The security strength of the RBG shall 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 method and the + group generator g for a verifiable process, the evaluator shall 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 of the TSF’s implementation by comparing values + generated by the TSF with those generated from a known good implementation. Verification shall + also confirm g != 0,1q divides p-1g^q mod p = 1g^x mod p = y + 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 "safe-prime" groups is done as part of testing in FCS_CKM.2.1. @@ -794,66 +956,66 @@ The TSF shall <h:s>distribute cryptographic keys</h:s> <h:b>implement functionality to perform cryptographic key establishment</h:b> in accordance with a specified cryptographic key establishment method:<selectables linebreak="yes"><selectable id="fcs_ckm.2.1_1" >RSA-based key establishment schemes that meets the following: RSAES-PKCS1-v1_5 as specified in Section 7.2 of RFC 8017, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.2"</selectable><selectable id="fcs_ckm.2.1_2" >Elliptic curve-based key establishment schemes that meets the following: NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography”</selectable><selectable id="fcs_ckm.2.1_3" >Finite field-based key establishment schemes that meets the following: NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography”</selectable><selectable id="fcs_ckm.2.1_4" >Key establishment scheme using Diffie-Hellman group 14 that meets the following: RFC 3526</selectable> </selectables><h:s>that meets the following [assignment: list of standards]</h:s> . - 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 - scheme, the evaluator shall examine the TSS to verify that it identifies the usage - for each scheme. + 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 + scheme, the evaluator shall examine the TSS to verify that it identifies the usage + for each scheme. - The evaluator shall verify that the AGD guidance instructs the administrator how to configure - the TOE to use the selected key establishment schemes. + The evaluator shall verify that the AGD guidance instructs the administrator how to configure + the TOE to use the selected key establishment schemes. - The evaluator shall verify the implementation of the key establishment schemes of the supported by the TOE - using the applicable tests below.Key Establishment SchemesRSAES-PKCS1-v1_5 Key Establishment Schemes - 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_ITC_EXT.1 that uses RSAES-PKCS1-v1_5.SP800-56A ECC Key Establishment Schemes - The evaluator shall verify a TOE's implementation of SP800-56A key agreement schemes using the following - Function and Validity tests. These validation tests for each key agreement scheme verify that a TOE has - implemented the components of the key agreement scheme according to the specifications in the - Recommendation. These components include the calculation of the DLC primitives (the shared secret - value Z) and the calculation of the derived keying material (DKM) via the Key Derivation Function - (KDF). If key confirmation is supported, the evaluator shall also verify that the components of key - confirmation have been implemented correctly, using the test procedures described below. This includes - the parsing of the DKM, the generation of MACdata and the calculation of MACtag.Function Test - The Function test verifies the ability of the TOE to implement the key agreement schemes correctly. To conduct - this test, the evaluator shall generate or obtain test vectors from a known good implementation of - the TOE supported schemes. For each supported key agreement scheme-key agreement role combination, KDF - type, and, if supported, key confirmation role- 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. - The evaluator shall obtain the DKM, the corresponding TOE’s public keys (static and ephemeral), the - MAC tags, and any inputs used in the KDF, such as the Other Information field OI and TOE ID fields. - If the TOE does not use a KDF defined in SP 800-56A, the evaluator shall obtain only the public keys - and the hashed value of the shared secret. - The evaluator shall verify the correctness of the TSF’s implementation of a given scheme by using a - known good implementation to calculate the shared secret value, derive the keying material DKM, - and compare hashes or MAC tags generated from these values. - If key confirmation is supported, the TSF shall perform the above for each implemented approved MAC - algorithm.Validity Test - The Validity test verifies the ability of the TOE to recognize another party’s valid and invalid key - agreement results with or without key confirmation. To conduct this test, the evaluator shall - obtain a list of the supporting cryptographic functions included in the SP800-56A key agreement - implementation to determine which errors the TOE should be able to recognize. The evaluator - generates a set of 24 (FFC) or 30 (ECC) test vectors consisting of data sets including domain - parameter values or NIST approved curves, the evaluator’s public keys, the TOE’s public/private - key pairs, MACTag, and any inputs used in the KDF, such as the other info 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 other information field OI, the data to be MACed, or the generated MACTag. - If the TOE contains the full or partial (only ECC) public key validation, the evaluator will also - individually inject errors in both parties’ static public keys, both parties’ ephemeral public - keys and the TOE’s static private key to assure the TOE detects errors in the public key - validation function and the partial key validation function (in ECC only). At least two of the - test vectors shall remain unmodified and therefore should result in valid key agreement results - (they should pass). - The TOE shall use these modified test vectors to emulate the key agreement scheme using the - corresponding parameters. The evaluator shall compare the TOE’s results with the results using - a known good implementation verifying that the TOE detects these errors.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_ITC_EXT.1 that uses Diffie-Hellman Group 14.FFC Schemes using "safe-prime" groups (identified in Appendix D of SP 800-56A Revision 3) - 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_ITC_EXT.1 that uses "safe-prime" groups. This test must be performed for each "safe-prime" group - that each protocol uses. + The evaluator shall verify the implementation of the key establishment schemes of the supported by the TOE + using the applicable tests below.Key Establishment SchemesRSAES-PKCS1-v1_5 Key Establishment Schemes + 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_ITC_EXT.1 that uses RSAES-PKCS1-v1_5.SP800-56A ECC Key Establishment Schemes + The evaluator shall verify a TOE's implementation of SP800-56A key agreement schemes using the following + Function and Validity tests. These validation tests for each key agreement scheme verify that a TOE has + implemented the components of the key agreement scheme according to the specifications in the + Recommendation. These components include the calculation of the DLC primitives (the shared secret + value Z) and the calculation of the derived keying material (DKM) via the Key Derivation Function + (KDF). If key confirmation is supported, the evaluator shall also verify that the components of key + confirmation have been implemented correctly, using the test procedures described below. This includes + the parsing of the DKM, the generation of MACdata and the calculation of MACtag.Function Test + The Function test verifies the ability of the TOE to implement the key agreement schemes correctly. To conduct + this test, the evaluator shall generate or obtain test vectors from a known good implementation of + the TOE supported schemes. For each supported key agreement scheme-key agreement role combination, KDF + type, and, if supported, key confirmation role- 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. + The evaluator shall obtain the DKM, the corresponding TOE’s public keys (static and ephemeral), the + MAC tags, and any inputs used in the KDF, such as the Other Information field OI and TOE ID fields. + If the TOE does not use a KDF defined in SP 800-56A, the evaluator shall obtain only the public keys + and the hashed value of the shared secret. + The evaluator shall verify the correctness of the TSF’s implementation of a given scheme by using a + known good implementation to calculate the shared secret value, derive the keying material DKM, + and compare hashes or MAC tags generated from these values. + If key confirmation is supported, the TSF shall perform the above for each implemented approved MAC + algorithm.Validity Test + The Validity test verifies the ability of the TOE to recognize another party’s valid and invalid key + agreement results with or without key confirmation. To conduct this test, the evaluator shall + obtain a list of the supporting cryptographic functions included in the SP800-56A key agreement + implementation to determine which errors the TOE should be able to recognize. The evaluator + generates a set of 24 (FFC) or 30 (ECC) test vectors consisting of data sets including domain + parameter values or NIST approved curves, the evaluator’s public keys, the TOE’s public/private + key pairs, MACTag, and any inputs used in the KDF, such as the other info 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 other information field OI, the data to be MACed, or the generated MACTag. + If the TOE contains the full or partial (only ECC) public key validation, the evaluator will also + individually inject errors in both parties’ static public keys, both parties’ ephemeral public + keys and the TOE’s static private key to assure the TOE detects errors in the public key + validation function and the partial key validation function (in ECC only). At least two of the + test vectors shall remain unmodified and therefore should result in valid key agreement results + (they should pass). + The TOE shall use these modified test vectors to emulate the key agreement scheme using the + corresponding parameters. The evaluator shall compare the TOE’s results with the results using + a known good implementation verifying that the TOE detects these errors.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_ITC_EXT.1 that uses Diffie-Hellman Group 14.FFC Schemes using "safe-prime" groups (identified in Appendix D of SP 800-56A Revision 3) + 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_ITC_EXT.1 that uses "safe-prime" groups. This test must be performed for each "safe-prime" group + that each protocol uses. @@ -861,82 +1023,82 @@ - requires the TSF to destroy or make unrecoverable empty keys in volatile and - non-volatile memory. Note that component level 4 is used here because of this - component’s similarity to the CC Part 2 component FCS_CKM.4. + requires the TSF to destroy or make unrecoverable empty keys in volatile and + non-volatile memory. Note that component level 4 is used here because of this + component’s similarity to the CC Part 2 component FCS_CKM.4. No specific management functions are identified. - + There are no auditable events foreseen. [FCS_CKM.1 Cryptographic Key Generation, or - FCS_CKM.2 Cryptographic Key Distribution] + FCS_CKM.2 Cryptographic Key Distribution] The TSF shall cause disused cryptographic keys in volatile memory to be destroyed or rendered unrecoverable. The threat addressed by this element is the recovery of disused cryptographic keys - from volatile memory by unauthorized processes. - The TSF must destroy or cause to be destroyed all copies of cryptographic keys created and - managed by the TOE once the keys are no longer needed. This requirement is the same for all instances - of keys within TOE volatile memory regardless of whether the memory is controlled by TOE manufacturer - software or by third-party TOE modules. The evaluation activities are designed with flexibility to - address cases where the TOE manufacturer has limited insight into the behavior of third-party TOE - components. - The preferred method for destroying keys in TOE volatile memory is by direct overwrite of the memory - occupied by the keys. The values used for overwriting can be all zeros, all ones, or any other pattern - or combination of values significantly different than the value of the key itself such that the keys - are rendered inaccessible to running processes. - Some implementations may find that direct overwriting of memory is not feasible or possible due to - programming language constraints. Many memory- and type-safe languages provide no mechanism for - programmers to specify that a particular memory location be accessed or written. The value of such - languages is that it is much harder for a programming error to result in a buffer or heap overflow. - The downside is that multiple copies of keys might be scattered throughout language-runtime memory. - In such cases, the TOE should take whatever actions are feasible to cause the keys to become - inaccessible—freeing memory, destroying objects, closing applications, programming using the minimum - possible scope for variables containing keys. - Likewise, if keys reside in memory within the execution context of a third-party module, then the - TOE should take whatever feasible actions it can to cause the keys to be destroyed. - Cryptographic keys in non-TOE volatile memory are not covered by this requirement. This expressly includes - keys created and used by Guest VMs. The Guest is responsible for disposing of such keys. - + from volatile memory by unauthorized processes. + The TSF must destroy or cause to be destroyed all copies of cryptographic keys created and + managed by the TOE once the keys are no longer needed. This requirement is the same for all instances + of keys within TOE volatile memory regardless of whether the memory is controlled by TOE manufacturer + software or by third-party TOE modules. The evaluation activities are designed with flexibility to + address cases where the TOE manufacturer has limited insight into the behavior of third-party TOE + components. + The preferred method for destroying keys in TOE volatile memory is by direct overwrite of the memory + occupied by the keys. The values used for overwriting can be all zeros, all ones, or any other pattern + or combination of values significantly different than the value of the key itself such that the keys + are rendered inaccessible to running processes. + Some implementations may find that direct overwriting of memory is not feasible or possible due to + programming language constraints. Many memory- and type-safe languages provide no mechanism for + programmers to specify that a particular memory location be accessed or written. The value of such + languages is that it is much harder for a programming error to result in a buffer or heap overflow. + The downside is that multiple copies of keys might be scattered throughout language-runtime memory. + In such cases, the TOE should take whatever actions are feasible to cause the keys to become + inaccessible—freeing memory, destroying objects, closing applications, programming using the minimum + possible scope for variables containing keys. + Likewise, if keys reside in memory within the execution context of a third-party module, then the + TOE should take whatever feasible actions it can to cause the keys to be destroyed. + Cryptographic keys in non-TOE volatile memory are not covered by this requirement. This expressly includes + keys created and used by Guest VMs. The Guest is responsible for disposing of such keys. + - The evaluator shall check to ensure the TSS lists each type of key and its origin - and location in memory or storage. The evaluator shall verify that the TSS - describes when each type of key is cleared. + The evaluator shall check to ensure the TSS lists each type of key and its origin + and location in memory or storage. The evaluator shall verify that the TSS + describes when each type of key is cleared. - For each key clearing situation the evaluator shall perform one of the following activities:The evaluator shall use appropriate combinations of specialized operational or development - environments, development tools (debuggers, emulators, simulators, etc.), or instrumented - builds (developmental, debug, or release) to demonstrate that keys are cleared correctly, - including all intermediate copies of the key that may have been created internally by the - TOE during normal cryptographic processing.In cases where testing reveals that third-party software modules or programming language - run-time environments do not properly overwrite keys, this fact must be documented. - Likewise, it must be documented if there is no practical way to determine whether such - modules or environments destroy keys properly.In cases where it is impossible or impracticable to perform the above tests, the evaluator shall describe how keys are destroyed in such cases, to include: - Which keys are affectedThe reasons why testing is impossible or impracticableEvidence that keys are destroyed appropriately (e.g., citations to component documentation, component developer/vendor attestation, component vendor test results)Aggravating and mitigating factors that may affect the timeliness or execution of key destruction (e.g., caching, garbage collection, operating system memory management) + For each key clearing situation the evaluator shall perform one of the following activities:The evaluator shall use appropriate combinations of specialized operational or development + environments, development tools (debuggers, emulators, simulators, etc.), or instrumented + builds (developmental, debug, or release) to demonstrate that keys are cleared correctly, + including all intermediate copies of the key that may have been created internally by the + TOE during normal cryptographic processing.In cases where testing reveals that third-party software modules or programming language + run-time environments do not properly overwrite keys, this fact must be documented. + Likewise, it must be documented if there is no practical way to determine whether such + modules or environments destroy keys properly.In cases where it is impossible or impracticable to perform the above tests, the evaluator shall describe how keys are destroyed in such cases, to include: + Which keys are affectedThe reasons why testing is impossible or impracticableEvidence that keys are destroyed appropriately (e.g., citations to component documentation, component developer/vendor attestation, component vendor test results)Aggravating and mitigating factors that may affect the timeliness or execution of key destruction (e.g., caching, garbage collection, operating system memory management) The TSF shall cause disused cryptographic keys in non-volatile storage to be destroyed or rendered unrecoverable. - The ultimate goal of this element is to ensure that disused cryptographic keys are inaccessible not only - to components of the running system, but are also unrecoverable through forensic analysis of discarded - storage media. The element is designed to reflect the fact that the latter may not be wholly practical - at this time due to the way some storage technologies are implemented (e.g., wear-leveling of flash - storage). - Key storage areas in non-volatile storage can be overwritten with any value that renders the keys - unrecoverable. The value used can be all zeros, all ones, or any other pattern or combination of - values significantly different than the value of the key itself. - The TSF must destroy all copies of cryptographic keys created and managed by the TOE once the - keys are no longer needed. Since this is a software-only TOE, the hardware controllers that manage - non-volatile storage media are necessarily outside the TOE boundary. Thus, the TOE manufacturer is - likely to have little control over—or insight into—the functioning of these storage devices. The - TOE must make a “best-effort” to destroy disused cryptographic keys by invoking the - appropriate platform interfaces—recognizing that the specific actions taken by the platform are out of - the TOE’s control. - But in cases where the TOE has insight into the non-volatile storage technologies used by the platform, - or where the TOE can specify a preference or method for destroying keys, the destruction should be - executed by a single, direct overwrite consisting of pseudorandom data or a new key, by a repeating - pattern of any static value, or by a block erase. - For keys stored on encrypted media, it is sufficient for the media encryption keys to be destroyed for - all keys stored on the media to be considered destroyed. - + The ultimate goal of this element is to ensure that disused cryptographic keys are inaccessible not only + to components of the running system, but are also unrecoverable through forensic analysis of discarded + storage media. The element is designed to reflect the fact that the latter may not be wholly practical + at this time due to the way some storage technologies are implemented (e.g., wear-leveling of flash + storage). + Key storage areas in non-volatile storage can be overwritten with any value that renders the keys + unrecoverable. The value used can be all zeros, all ones, or any other pattern or combination of + values significantly different than the value of the key itself. + The TSF must destroy all copies of cryptographic keys created and managed by the TOE once the + keys are no longer needed. Since this is a software-only TOE, the hardware controllers that manage + non-volatile storage media are necessarily outside the TOE boundary. Thus, the TOE manufacturer is + likely to have little control over—or insight into—the functioning of these storage devices. The + TOE must make a “best-effort” to destroy disused cryptographic keys by invoking the + appropriate platform interfaces—recognizing that the specific actions taken by the platform are out of + the TOE’s control. + But in cases where the TOE has insight into the non-volatile storage technologies used by the platform, + or where the TOE can specify a preference or method for destroying keys, the destruction should be + executed by a single, direct overwrite consisting of pseudorandom data or a new key, by a repeating + pattern of any static value, or by a block erase. + For keys stored on encrypted media, it is sufficient for the media encryption keys to be destroyed for + all keys stored on the media to be considered destroyed. + @@ -945,126 +1107,126 @@ The TSF shall perform [ <h:i>cryptographic hashing</h:i> ] in accordance with a specified cryptographic algorithm<selectables ><selectable id="sel-hash-sha-1" >SHA-1</selectable><selectable id="sel-hash-sha-256" >SHA-256</selectable><selectable id="sel-hash-sha-384" >SHA-384</selectable><selectable id="sel-hash-sha-512" >SHA-512</selectable><selectable id="sel-hash-sha-3-224" >SHA-3-224</selectable><selectable id="sel-hash-sha-3-256" >SHA-3-256</selectable><selectable id="sel-hash-sha-3-384" >SHA-3-384</selectable><selectable id="sel-hash-sha-3-512" >SHA-3-512</selectable> </selectables>and message digest sizes<selectables ><selectable id="fcs_cop.1.1_Hash_1" >160</selectable><selectable id="fcs_cop.1.1_Hash_2" >256</selectable><selectable id="fcs_cop.1.1_Hash_3" >384</selectable><selectable id="fcs_cop.1.1_Hash_4" >512 bits</selectable> </selectables>that meet the following:<selectables ><selectable id="fcs_cop.1.1_Hash_5" >FIPS PUB 180-4 "Secure Hash Standard"</selectable><selectable id="fcs_cop.1.1_Hash_6" >ISO/IEC 10118-3:2018</selectable> </selectables> - Per NIST SP 800-131A, SHA-1 for generating digital signatures is no longer allowed, and SHA-1 for - verification of digital signatures is strongly discouraged as there may be risk in accepting these - signatures. It is expected that vendors will implement SHA-2 algorithms in accordance with SP 800-131A. - - The intent of this requirement is to specify the hashing function. The hash selection shall support the - message digest size selection. The hash selection should be consistent with the overall strength of - the algorithm used (for example, SHA 256 for 128-bit keys). - + Per NIST SP 800-131A, SHA-1 for generating digital signatures is no longer allowed, and SHA-1 for + verification of digital signatures is strongly discouraged as there may be risk in accepting these + signatures. It is expected that vendors will implement SHA-2 algorithms in accordance with SP 800-131A. + + The intent of this requirement is to specify the hashing function. The hash selection shall support the + message digest size selection. The hash selection should be consistent with the overall strength of + the algorithm used (for example, SHA 256 for 128-bit keys). + - The evaluator shall check that the association of the hash function with other TSF - cryptographic functions (for example, the digital signature verification function) is documented - in the TSS. + The evaluator shall check that the association of the hash function with other TSF + cryptographic functions (for example, the digital signature verification function) is documented + in the TSS. - The evaluator checks the AGD documents to determine that any configuration that is required to - be done to configure the functionality for the required hash sizes is present. - + The evaluator checks the AGD documents to determine that any configuration that is required to + be done to configure the functionality for the required hash sizes is present. + SHA-1 and SHA-2 Tests - The TSF hashing functions can be implemented in one of two modes. The first mode is the byte-oriented - mode. In this mode the TSF only hashes messages that are an integral number of bytes in length; - i.e., the length (in bits) of the message to be hashed is divisible by 8. The second mode is the - bit-oriented mode. In this mode the TSF hashes messages of arbitrary length. As there are different - tests for each mode, an indication is given in the following sections for the bit-oriented vs. the - byte-oriented test MACs. - - The evaluator shall perform all of the following tests for each hash algorithm implemented by the TSF - and used to satisfy the requirements of this PP. - - The following tests require the developer to provide access - to a test platform that provides the evaluator with tools that are typically not found on factory - products. - 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. - 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. - 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. - 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 - digest for each of the messages and ensure that the correct result is produced when - the messages are provided to the TSF. - 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 ensure that the correct result is produced when the messages are - provided to the TSF.SHA-3 Tests - The tests below are derived from the The Secure Hash Algorithm-3 Validation System (SHA3VS), - Updated: April 7, 2016, from the National Institute of Standards and Technology. - For each SHA-3-XXX implementation, XXX represents d, the digest length in bits. The capacity, c, - is equal to 2d bits. The rate is equal to 1600-c bits. - The TSF hashing functions can be implemented with one of two orientations. The first is a bit-oriented - mode that hashes messages of arbitrary length. The second is a byte-oriented mode that hashes messages - that are an integral number of bytes in length (i.e., the length (in bits) of the message to be - hashed is divisible by 8). Separate tests for each orientation are given below. - The evaluator shall perform all of the following tests for each hash algorithm and orientation - implemented by the TSF and used to satisfy the requirements of this PP. The evaluator shall - compare digest values produced by a known-good SHA-3 implementation against those generated by - running the same values through the TSF.Short Messages Test, Bit-oriented Mode - The evaluators devise an input set consisting of rate+1 short messages. The length of the messages - ranges sequentially from 0 to rate 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. The message of length 0 is omitted if the - TOE does not support zero-length messages.Short Messages Test, Byte-oriented Mode - The evaluators devise an input set consisting of rate/8+1 short messages. The length of the - messages ranges sequentially from 0 to rate/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. The message of length 0 is omitted if the TOE does not support zero-length - messages.Selected Long Messages Test, Bit-oriented Mode - The evaluators devise an input set consisting of 100 long messages ranging in size from - rate+(rate+1) to rate+(100*(rate+1)), incrementing by rate+1. (For example, SHA-3-256 has a rate - of 1088 bits. Therefore, 100 messages will be generated with lengths 2177, 3266, …, 109988 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.Selected Long Messages Test, Byte-oriented Mode - The evaluators devise an input set consisting of 100 messages ranging in size from (rate+(rate+8)) - to (rate+100*(rate+8)), incrementing by rate+8. (For example, SHA-3-256 has a rate of 1088 bits. - Therefore 100 messages will be generated of lengths 2184, 3280, 4376, …, 110688 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.Pseudorandomly Generated Messages Monte Carlo) Test, Byte-oriented Mode - The evaluators supply a seed of d bits (where d is the length of the message digest produced by - the hash function to be tested. This seed is used by a pseudorandom function to generate 100,000 - message digests. One hundred of the digests (every 1000th digest) are recorded as checkpoints. The - TOE then uses the same procedure to generate the same 100,000 message digests and 100 checkpoint - values. The evaluators then compare the results generated to ensure that the correct result is - produced when the messages are generated by the TSF. + The TSF hashing functions can be implemented in one of two modes. The first mode is the byte-oriented + mode. In this mode the TSF only hashes messages that are an integral number of bytes in length; + i.e., the length (in bits) of the message to be hashed is divisible by 8. The second mode is the + bit-oriented mode. In this mode the TSF hashes messages of arbitrary length. As there are different + tests for each mode, an indication is given in the following sections for the bit-oriented vs. the + byte-oriented test MACs. + + The evaluator shall perform all of the following tests for each hash algorithm implemented by the TSF + and used to satisfy the requirements of this PP. + + The following tests require the developer to provide access + to a test platform that provides the evaluator with tools that are typically not found on factory + products. + 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. + 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. + 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. + 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 + digest for each of the messages and ensure that the correct result is produced when + the messages are provided to the TSF. + 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 ensure that the correct result is produced when the messages are + provided to the TSF.SHA-3 Tests + The tests below are derived from the The Secure Hash Algorithm-3 Validation System (SHA3VS), + Updated: April 7, 2016, from the National Institute of Standards and Technology. + For each SHA-3-XXX implementation, XXX represents d, the digest length in bits. The capacity, c, + is equal to 2d bits. The rate is equal to 1600-c bits. + The TSF hashing functions can be implemented with one of two orientations. The first is a bit-oriented + mode that hashes messages of arbitrary length. The second is a byte-oriented mode that hashes messages + that are an integral number of bytes in length (i.e., the length (in bits) of the message to be + hashed is divisible by 8). Separate tests for each orientation are given below. + The evaluator shall perform all of the following tests for each hash algorithm and orientation + implemented by the TSF and used to satisfy the requirements of this PP. The evaluator shall + compare digest values produced by a known-good SHA-3 implementation against those generated by + running the same values through the TSF.Short Messages Test, Bit-oriented Mode + The evaluators devise an input set consisting of rate+1 short messages. The length of the messages + ranges sequentially from 0 to rate 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. The message of length 0 is omitted if the + TOE does not support zero-length messages.Short Messages Test, Byte-oriented Mode + The evaluators devise an input set consisting of rate/8+1 short messages. The length of the + messages ranges sequentially from 0 to rate/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. The message of length 0 is omitted if the TOE does not support zero-length + messages.Selected Long Messages Test, Bit-oriented Mode + The evaluators devise an input set consisting of 100 long messages ranging in size from + rate+(rate+1) to rate+(100*(rate+1)), incrementing by rate+1. (For example, SHA-3-256 has a rate + of 1088 bits. Therefore, 100 messages will be generated with lengths 2177, 3266, …, 109988 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.Selected Long Messages Test, Byte-oriented Mode + The evaluators devise an input set consisting of 100 messages ranging in size from (rate+(rate+8)) + to (rate+100*(rate+8)), incrementing by rate+8. (For example, SHA-3-256 has a rate of 1088 bits. + Therefore 100 messages will be generated of lengths 2184, 3280, 4376, …, 110688 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.Pseudorandomly Generated Messages Monte Carlo) Test, Byte-oriented Mode + The evaluators supply a seed of d bits (where d is the length of the message digest produced by + the hash function to be tested. This seed is used by a pseudorandom function to generate 100,000 + message digests. One hundred of the digests (every 1000th digest) are recorded as checkpoints. The + TOE then uses the same procedure to generate the same 100,000 message digests and 100 checkpoint + values. The evaluators then compare the results generated to ensure that the correct result is + produced when the messages are generated by the TSF. - If "" is selected in FCS_COP.1/KeyedHash - then "" must be selected in FCS_COP.1.1/Hash. + If "" is selected in FCS_COP.1/KeyedHash + then "" must be selected in FCS_COP.1.1/Hash. The TSF shall perform [ <h:i>keyed-hash message authentication</h:i> ] in accordance with a specified cryptographic algorithm<selectables ><selectable id="sel-hmac-sha-1" >HMAC-SHA-1</selectable><selectable id="sel-hmac-sha-256" >HMAC-SHA-256</selectable><selectable id="sel-hmac-sha-384" >HMAC-SHA-384</selectable><selectable id="sel-hmac-sha-512" >HMAC-SHA-512</selectable><selectable id="sel-hmac-sha-3-224" >SHA-3-224</selectable><selectable id="sel-hmac-sha-3-256" >SHA-3-256</selectable><selectable id="sel-hmac-sha-3-384" >SHA-3-384</selectable><selectable id="sel-hmac-sha-3-512" >SHA-3-512</selectable> </selectables>and cryptographic key sizes<assignable>key size (in bits) used in HMAC</assignable>and message digest sizes<selectables ><selectable id="fcs_cop.1.1_KeyedHash_2" >160</selectable><selectable id="fcs_cop.1.1_KeyedHash_3" >256</selectable><selectable id="fcs_cop.1.1_KeyedHash_4" >384</selectable><selectable id="fcs_cop.1.1_KeyedHash_5" >512 bits</selectable> </selectables>that meet the following: [ <h:b><h:i>FIPS Pub 198-1, "The Keyed-Hash Message Authentication Code," and FIPS Pub 180-4, “Secure Hash Standard"</h:i></h:b> ]. The selection in this requirement must be consistent with the key size specified for - the size of the keys used in conjunction with the keyed-hash message authentication. + the size of the keys used in conjunction with the keyed-hash message authentication. The evaluator shall examine the TSS to ensure that it specifies the following - values used by the HMAC function: key length, hash function used, block size, and output MAC - length used. - - 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. + values used by the HMAC function: key length, hash function used, block size, and output MAC + length used. + + 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. @@ -1074,169 +1236,169 @@ The TSF shall perform [ <h:i>cryptographic signature services (generation and verification)</h:i> ] in accordance with a specified cryptographic algorithm<selectables linebreak="yes"><selectable id="sel-sig-rsa" >RSA schemes using cryptographic key sizes [2048-bit or greater] that meet the following: [<h:i>FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 4</h:i>]</selectable><selectable id="sel-sig-ecdsa">ECDSA schemes using [“NIST curves” P-256, P-384 and<selectables><selectable id="fcs_cop.1.1_Sig_1" >P-521</selectable><selectable id="fcs_cop.1.1_Sig_2" >no other curves</selectable></selectables>] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5]</selectable> </selectables>. The ST Author should choose the algorithm implemented to perform digital signatures; - if more than one algorithm is available, this requirement should be iterated to specify the - functionality. For the algorithm chosen, the ST author should make the appropriate - assignments/selections to specify the parameters that are implemented for that algorithm. - + if more than one algorithm is available, this requirement should be iterated to specify the + functionality. For the algorithm chosen, the ST author should make the appropriate + assignments/selections to specify the parameters that are implemented for that algorithm. + - 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. - ECDSA Algorithm TestsECDSA 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, the evaluator shall use the - signature verification function of a known good implementation. - 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. - RSA Signature Algorithm TestsSignature 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 shall generate or obtain 10 - messages from a trusted reference implementation for each 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 TSF’s signature using a known good implementation - and the associated public keys to verify the signatures. - 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 during the Signature Verification Test by introducing errors in some - of the public keys e, messages, IR format, or signatures. The TOE attempts to verify the - signatures and returns success or failure. - + 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. + ECDSA Algorithm TestsECDSA 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, the evaluator shall use the + signature verification function of a known good implementation. + 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. + RSA Signature Algorithm TestsSignature 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 shall generate or obtain 10 + messages from a trusted reference implementation for each 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 TSF’s signature using a known good implementation + and the associated public keys to verify the signatures. + 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 during the Signature Verification Test by introducing errors in some + of the public keys e, messages, IR format, or signatures. The TOE attempts to verify the + signatures and returns success or failure. + - If the SSH Package is included in the ST then "," - "," and "" must be selected in FCS_COP.1/UDE. - + If the SSH Package is included in the ST then "," + "," and "" must be selected in FCS_COP.1/UDE. + The TSF shall perform [ <h:i>encryption and decryption</h:i> ] in accordance with a specified cryptographic algorithm<selectables linebreak="yes"><selectable id="sel-ude-aes-kw" >AES Key Wrap (KW) (as defined in NIST SP 800-38F)</selectable><selectable id="sel-ude-aes-kwp" >AES Key Wrap with Padding (KWP) (as defined in NIST SP 800-38F)</selectable><selectable id="sel-ude-aes-gcm" >AES-GCM (as defined in NIST SP 800-38D)</selectable><selectable id="sel-ude-aes-ccm" >AES-CCM (as defined in NIST SP 800-38C)</selectable><selectable id="sel-ude-aes-xts" >AES-XTS (as defined in NIST SP 800-38E) mode</selectable><selectable id="sel-ude-aes-ccmp-256" >AES-CCMP-256 (as defined in NIST SP800-38C and IEEE 802.11ac-2013)</selectable><selectable id="sel-ude-aes-gcmp-256" >AES-GCMP-256 (as defined in NIST SP800-38D and IEEE 802.11ac-2013)</selectable><selectable id="sel-ude-aes-ccmp" >AES-CCMP (as defined in FIPS PUB 197, NIST SP 800-38C and IEEE 802.11-2012)</selectable><selectable id="sel-ude-aes-cbc" >AES-CBC (as defined in FIPS PUB 197, and NIST SP 800-38A) mode</selectable><selectable id="sel-ude-aes-ctr" >AES-CTR (as defined in NIST SP 800-38A) mode</selectable> </selectables>and cryptographic key sizes<selectables ><selectable id="sel-ude-keysize-128" >128-bit key sizes</selectable><selectable id="sel-ude-keysize-256" >256-bit key sizes</selectable> </selectables>. For the first selection of FCS_COP.1.1/UDE, the ST author should choose the mode or - modes in which AES operates. For the second selection, the ST author should choose the key sizes that - are supported by this functionality. + modes in which AES operates. For the second selection, the ST author should choose the key sizes that + are supported by this functionality. - - 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. + + 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. - For EACH supported key and associated data length and ANY supported payload, nonce 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. - + For EACH supported key and associated data length and ANY supported payload, nonce 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. + For EACH supported key and payload length and ANY supported associated data, nonce 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. - + 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. + For EACH supported key and nonce length and ANY supported associated data, payload and - tag length, the evaluator shall supply one key value and 10 associated data, payload - and nonce value 3-tuples and obtain the resulting ciphertext. - - For EACH supported key and tag length and ANY supported associated data, payload 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. - + tag length, the evaluator shall supply one key value and 10 associated data, payload + and nonce value 3-tuples and obtain the resulting ciphertext. + + For EACH supported key and tag length and ANY supported associated data, payload 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. + - Known Answer Tests (KATs) - - There are four Known Answer Tests (KATs) described below. For all KATs, the plaintext, - initialization vector (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. - Test 1a: 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. - Test 1b: 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 functionality, the - evaluator shall perform the same test as for encrypt, using an all zero ciphertext - value as input. - Test 1c: 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 and 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 value in each pair shall be the value - that results in an all zeros plaintext when decrypted with its corresponding key. - Test 1d: 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 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. - + Known Answer Tests (KATs) + + There are four Known Answer Tests (KATs) described below. For all KATs, the plaintext, + initialization vector (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. + Test 1a: 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. + Test 1b: 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 functionality, the + evaluator shall perform the same test as for encrypt, using an all zero ciphertext + value as input. + Test 1c: 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 and 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 value in each pair shall be the value + that results in an all zeros plaintext when decrypted with its corresponding key. + Test 1d: 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 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. + - 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. - + 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. + - 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, 1000 iterations shall be run as follows: - - For AES-ECB mode - # Input: PT, Key - for i = 1 to 1000: - CT[i] = AES-ECB-Encrypt(Key, PT) - PT = CT[i] - - The ciphertext computed in the 1000th iteration is the result for that - trial. This result shall be compared to the result of running 1000 - iterations with the same values using a known good implementation. - + 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, 1000 iterations shall be run as follows: + + For AES-ECB mode + # Input: PT, Key + for i = 1 to 1000: + CT[i] = AES-ECB-Encrypt(Key, PT) + PT = CT[i] + + The ciphertext computed in the 1000th iteration is the result for that + trial. This result shall be compared to the result of running 1000 + iterations with the same values using a known good implementation. + - - If "invoke platform-provided" is selected, the evaluator confirms that SSH connections are only successful if appropriate algorithms and appropriate key sizes are configured. To do this, the evaluator shall perform the following tests: - + + If "invoke platform-provided" is selected, the evaluator confirms that SSH connections are only successful if appropriate algorithms and appropriate key sizes are configured. To do this, the evaluator shall perform the following tests: + - [Conditional: TOE is an SSH server] The evaluator shall configure an SSH client to connect with an invalid cryptographic algorithm and key size for each listening SSH socket connection on the TOE. - The evaluator initiates SSH client connections to each listening SSH socket connection on the TOE and observes that the connection fails in each attempt. - + [Conditional: TOE is an SSH server] The evaluator shall configure an SSH client to connect with an invalid cryptographic algorithm and key size for each listening SSH socket connection on the TOE. + The evaluator initiates SSH client connections to each listening SSH socket connection on the TOE and observes that the connection fails in each attempt. + - [Conditional: TOE is an SSH client] The evaluator shall configure a listening SSH socket on a remote SSH server that accepts only invalid cryptographic algorithms and keys. - The evaluator uses the TOE to attempt an SSH connection to this server and observes that the connection fails. - + [Conditional: TOE is an SSH client] The evaluator shall configure a listening SSH socket on a remote SSH server that accepts only invalid cryptographic algorithms and keys. + The evaluator uses the TOE to attempt an SSH connection to this server and observes that the connection fails. + @@ -1254,22 +1416,22 @@ The TSF shall provide a mechanism to make available to VMs entropy that meets FCS_RBG_EXT.1 through<selectables ><selectable id="fcs_ent_ext.1.1_1" >Hypercall interface</selectable><selectable id="fcs_ent_ext.1.1_2" >virtual device interface</selectable><selectable id="fcs_ent_ext.1.1_3" >passthrough access to hardware entropy source</selectable> </selectables>. The evaluator shall verify that the TSS describes how the TOE provides entropy to Guest VMs, and - how to access the interface to acquire entropy or random numbers. The evaluator shall verify that - the TSS describes the mechanisms for ensuring that one VM does not affect the entropy acquired by - another. + how to access the interface to acquire entropy or random numbers. The evaluator shall verify that + the TSS describes the mechanisms for ensuring that one VM does not affect the entropy acquired by + another. - - The evaluator shall perform the following tests: - + + The evaluator shall perform the following tests: + - The evaluator shall invoke entropy from each Guest VM. The evaluator shall - verify that each VM acquires values from the interface. - - The evaluator shall invoke entropy from multiple VMs as nearly - simultaneously as practicable. The evaluator shall verify that the entropy used in one - VM is not identical to that invoked from the other VMs. - + The evaluator shall invoke entropy from each Guest VM. The evaluator shall + verify that each VM acquires values from the interface. + + The evaluator shall invoke entropy from multiple VMs as nearly + simultaneously as practicable. The evaluator shall verify that the entropy used in one + VM is not identical to that invoked from the other VMs. + @@ -1277,31 +1439,31 @@ The TSF shall provide independent entropy across multiple VMs. - This requirement ensures that sufficient entropy is available to any VM that requires it. The entropy - need not provide high-quality entropy for every possible method that a VM might acquire it. The VMM - must, however, provide some means for VMs to get sufficient entropy. For example, the VMM can - provide an interface that returns entropy to a Guest VM. Alternatively, the VMM could provide - pass-through access to entropy sources provided by the host platform. - This requirement allows for three general ways of providing entropy to guests: 1) The VS can provide a - Hypercall accessible to VM-aware guests, 2) access to a virtualized device that provides entropy, or - 3) pass-through access to a hardware entropy source (including a source of random numbers). In all - cases, it is possible that the guest is made VM-aware through installation of software or drivers. - For the second and third cases, it is possible that the guest could be VM-unaware. There is no - requirement that the TOE provide entropy sources as expected by VM-unaware guests. That is, the TOE - does not have to anticipate every way a guest might try to acquire entropy as long as it supplies a - mechanism that can be used by VM-aware guests, or provides access to a standard mechanism that a - VM-unaware guest would use. - The ST author should select “Hypercall interface” if the TSF provides an API function through which - guest-resident software can obtain entropy or random numbers. The ST author should select - “virtual device interface” if the TSF presents a virtual device interface to the Guest OS through - which it can obtain entropy or random numbers. Such an interface could present a virtualized real - device, such as a TPM, that can be accessed by VM-unaware guests, or a virtualized fictional device - that would require the Guest OS to be VM-aware. The ST author should select “passthrough access to - hardware entropy source” if the TSF permits Guest VMs to have direct access to hardware entropy or - random number source on the platform. The ST author should select all items that are appropriate. - For FCS_ENT_EXT.1.2, the VMM must ensure that the provision of entropy to one VM cannot affect the quality - of entropy provided to another VM on the same platform. - + This requirement ensures that sufficient entropy is available to any VM that requires it. The entropy + need not provide high-quality entropy for every possible method that a VM might acquire it. The VMM + must, however, provide some means for VMs to get sufficient entropy. For example, the VMM can + provide an interface that returns entropy to a Guest VM. Alternatively, the VMM could provide + pass-through access to entropy sources provided by the host platform. + This requirement allows for three general ways of providing entropy to guests: 1) The VS can provide a + Hypercall accessible to VM-aware guests, 2) access to a virtualized device that provides entropy, or + 3) pass-through access to a hardware entropy source (including a source of random numbers). In all + cases, it is possible that the guest is made VM-aware through installation of software or drivers. + For the second and third cases, it is possible that the guest could be VM-unaware. There is no + requirement that the TOE provide entropy sources as expected by VM-unaware guests. That is, the TOE + does not have to anticipate every way a guest might try to acquire entropy as long as it supplies a + mechanism that can be used by VM-aware guests, or provides access to a standard mechanism that a + VM-unaware guest would use. + The ST author should select “Hypercall interface” if the TSF provides an API function through which + guest-resident software can obtain entropy or random numbers. The ST author should select + “virtual device interface” if the TSF presents a virtual device interface to the Guest OS through + which it can obtain entropy or random numbers. Such an interface could present a virtualized real + device, such as a TPM, that can be accessed by VM-unaware guests, or a virtualized fictional device + that would require the Guest OS to be VM-aware. The ST author should select “passthrough access to + hardware entropy source” if the TSF permits Guest VMs to have direct access to hardware entropy or + random number source on the platform. The ST author should select all items that are appropriate. + For FCS_ENT_EXT.1.2, the VMM must ensure that the provision of entropy to one VM cannot affect the quality + of entropy provided to another VM on the same platform. + @@ -1312,24 +1474,24 @@ defines requirements for the implementation of the HTTPS protocol. No specific management functions are identified. - The following actions should be auditable if FAU_GEN Security audit data - generation is included in the PP/ST: - Failure to establish an HTTPS session.Establishment/termination of an HTTPS session. + The following actions should be auditable if FAU_GEN Security audit data + generation is included in the PP/ST: + Failure to establish an HTTPS session.Establishment/termination of an HTTPS session. [FCS_TLSC_EXT.1 TLS Client Protocol, or - FCS_TLSC_EXT.2 TLS Client Protocol with Mutual Authentication, or - FCS_TLSS_EXT.1 TLS Server Protocol, or - FCS_TLSS_EXT.2 TLS Server Protocol with Mutual Authentication] + FCS_TLSC_EXT.2 TLS Client Protocol with Mutual Authentication, or + FCS_TLSS_EXT.1 TLS Server Protocol, or + FCS_TLSS_EXT.2 TLS Server Protocol with Mutual Authentication] The TSF shall implement the HTTPS protocol that complies with RFC 2818. This SFR is included in the ST if the ST Author selects "TLS/HTTPS" in FTP_ITC_EXT.1.1. - The ST author must provide enough detail to determine how the implementation is - complying with the standards identified; this can be done either by adding elements to this - component, or by additional detail in the TSS. + The ST author must provide enough detail to determine how the implementation is + complying with the standards identified; this can be done either by adding elements to this + component, or by additional detail in the TSS. - The evaluator shall check the TSS to ensure that it is clear on how HTTPS uses - TLS to establish an administrative session, focusing on any client authentication required by - the TLS protocol vs. security administrator authentication which may be done at a different - level of the processing stack. + The evaluator shall check the TSS to ensure that it is clear on how HTTPS uses + TLS to establish an administrative session, focusing on any client authentication required by + the TLS protocol vs. security administrator authentication which may be done at a different + level of the processing stack. @@ -1352,111 +1514,111 @@ requires that IPsec be implemented as specified. No specific management functions are identified. - - The following actions should be auditable if FAU_GEN Security audit data - generation is included in the PP/ST: - Failure to establish an IPsec SA.Establishment/Termination of an IPsec SA. + + The following actions should be auditable if FAU_GEN Security audit data + generation is included in the PP/ST: + Failure to establish an IPsec SA.Establishment/Termination of an IPsec SA. FCS_CKM.1 Cryptographic Key Generation - FCS_CKM.2 Cryptographic Key Establishment - FCS_COP.1 Cryptographic Operation - FCS_RBG_EXT.1 Cryptographic Operation (Random Bit Generation) - FIA_X509_EXT.1 X.509 Certificate Validation + FCS_CKM.2 Cryptographic Key Establishment + FCS_COP.1 Cryptographic Operation + FCS_RBG_EXT.1 Cryptographic Operation (Random Bit Generation) + FIA_X509_EXT.1 X.509 Certificate Validation The TSF shall implement the IPsec architecture as specified in RFC 4301. - This SFR is included in the ST if the ST Author selected "IPsec" in FTP_ITC_EXT.1.1. - RFC 4301 calls for an IPsec implementation to protect IP traffic through the use - of a Security Policy Database (SPD). The SPD is used to define how IP packets are - to be handled: PROTECT the packet (e.g., encrypt the packet), BYPASS the IPsec - services (e.g., no encryption), or DISCARD the packet (e.g., drop the packet). The - SPD can be implemented in various ways, including router access control lists, - firewall rulesets, a "traditional" SPD, etc. Regardless of the implementation - details, there is a notion of a "rule" that a packet is "matched" against and a - resulting action that takes place. - While there must be a means to order the rules, a general approach to ordering - is not mandated, as long as the TOE can distinguish the IP packets and apply the - rules accordingly. There may be multiple SPDs (one for each network interface), - but this is not required. + This SFR is included in the ST if the ST Author selected "IPsec" in FTP_ITC_EXT.1.1. + RFC 4301 calls for an IPsec implementation to protect IP traffic through the use + of a Security Policy Database (SPD). The SPD is used to define how IP packets are + to be handled: PROTECT the packet (e.g., encrypt the packet), BYPASS the IPsec + services (e.g., no encryption), or DISCARD the packet (e.g., drop the packet). The + SPD can be implemented in various ways, including router access control lists, + firewall rulesets, a "traditional" SPD, etc. Regardless of the implementation + details, there is a notion of a "rule" that a packet is "matched" against and a + resulting action that takes place. + While there must be a means to order the rules, a general approach to ordering + is not mandated, as long as the TOE can distinguish the IP packets and apply the + rules accordingly. There may be multiple SPDs (one for each network interface), + but this is not required. In addition to the TSS EAs for the individual FCS_IPSEC_EXT.1 elements below, the - evaluator shall perform the following: - If the TOE boundary includes a general-purpose operating system or mobile device, the evaluator shall - examine the TSS to ensure that it describes whether the VPN client capability is architecturally integrated - with the platform itself or whether it is a separate executable that is bundled with the platform. + evaluator shall perform the following: + If the TOE boundary includes a general-purpose operating system or mobile device, the evaluator shall + examine the TSS to ensure that it describes whether the VPN client capability is architecturally integrated + with the platform itself or whether it is a separate executable that is bundled with the platform. - In addition to the Operational Guidance EAs for the individual FCS_IPSEC_EXT.1 elements below, the - evaluator shall perform the following: - If the configuration of the IPsec behavior is from an environmental source, most notably a VPN gateway - (e.g through receipt of required connection parameters from a VPN gateway), the evaluator shall ensure - that the operational guidance contains any appropriate information for ensuring that this configuration - can be properly applied. - Note in this case that the implementation of the IPsec protocol must be enforced entirely within the TOE - boundary; i.e. it is not permissible for a software application TOE to be a graphical front-end for IPsec - functionality implemented totally or in part by the underlying OS platform. The behavior referenced here - is for the possibility that the configuration of the IPsec connection is initiated from outside the TOE, which - is permissible so long as the TSF is solely responsible for enforcing the configured behavior. However, it is - allowable for the TSF to rely on low-level platform-provided networking functions to implement the SPD - from the client (e.g., enforcement of packet routing decisions). + In addition to the Operational Guidance EAs for the individual FCS_IPSEC_EXT.1 elements below, the + evaluator shall perform the following: + If the configuration of the IPsec behavior is from an environmental source, most notably a VPN gateway + (e.g through receipt of required connection parameters from a VPN gateway), the evaluator shall ensure + that the operational guidance contains any appropriate information for ensuring that this configuration + can be properly applied. + Note in this case that the implementation of the IPsec protocol must be enforced entirely within the TOE + boundary; i.e. it is not permissible for a software application TOE to be a graphical front-end for IPsec + functionality implemented totally or in part by the underlying OS platform. The behavior referenced here + is for the possibility that the configuration of the IPsec connection is initiated from outside the TOE, which + is permissible so long as the TSF is solely responsible for enforcing the configured behavior. However, it is + allowable for the TSF to rely on low-level platform-provided networking functions to implement the SPD + from the client (e.g., enforcement of packet routing decisions). - As a prerequisite for performing the Test EAs for the individual FCS_IPSEC_EXT.1 elements below, the - evaluator shall do the following: - The evaluator shall minimally create a test environment equivalent to the test environment illustrated - below. The traffic generator used to construct network packets should provide the - evaluator with the ability manipulate fields in the ICMP, IPv4, IPv6, UDP, and TCP packet headers. The - evaluator shall provide justification for any differences in the test environment.
- Note that the evaluator shall perform all tests using the Virtualization System and a representative sample of - platforms listed in the ST (for TOEs that claim to support multiple platforms). + As a prerequisite for performing the Test EAs for the individual FCS_IPSEC_EXT.1 elements below, the + evaluator shall do the following: + The evaluator shall minimally create a test environment equivalent to the test environment illustrated + below. The traffic generator used to construct network packets should provide the + evaluator with the ability manipulate fields in the ICMP, IPv4, IPv6, UDP, and TCP packet headers. The + evaluator shall provide justification for any differences in the test environment.
+ Note that the evaluator shall perform all tests using the Virtualization System and a representative sample of + platforms listed in the ST (for TOEs that claim to support multiple platforms). The evaluator shall examine the TSS and determine that it describes how the IPsec capabilities - are implemented. - The evaluator shall ensure that the TSS describes at a high level the architectural relationship between - the IPsec implementation and the rest of the TOE (e.g., is the IPsec implementation an integrated part - of the VS or is it a standalone executable that is bundled into the VS). - The evaluator shall ensure that the TSS describes how the SPD is implemented and the rules for processing - both inbound and outbound packets in terms of the IPsec policy. The TSS describes the rules that are - available and the resulting actions available after matching a rule. The TSS describes how the available - rules and actions form the SPD using terms defined in RFC 4301 such as BYPASS (e.g., no encryption), - DISCARD (e.g., drop the packet), and PROTECT (e.g., encrypt the packet) actions defined in RFC 4301. - - As noted in section 4.4.1 of RFC 4301, the processing of entries in the SPD is non-trivial and the evaluator - shall determine that the description in the TSS is sufficient to determine which rules will be applied given - the rule structure implemented by the TOE. For example, if the TOE allows specification of ranges, - conditional rules, etc., the evaluator shall determine that the description of rule processing (for both - inbound and outbound packets) is sufficient to determine the action that will be applied, especially in the - case where two different rules may apply. This description shall cover both the initial packets (that is, no - SA is established on the interface or for that particular packet) as well as packets that are part of an - established SA. + are implemented. + The evaluator shall ensure that the TSS describes at a high level the architectural relationship between + the IPsec implementation and the rest of the TOE (e.g., is the IPsec implementation an integrated part + of the VS or is it a standalone executable that is bundled into the VS). + The evaluator shall ensure that the TSS describes how the SPD is implemented and the rules for processing + both inbound and outbound packets in terms of the IPsec policy. The TSS describes the rules that are + available and the resulting actions available after matching a rule. The TSS describes how the available + rules and actions form the SPD using terms defined in RFC 4301 such as BYPASS (e.g., no encryption), + DISCARD (e.g., drop the packet), and PROTECT (e.g., encrypt the packet) actions defined in RFC 4301. + + As noted in section 4.4.1 of RFC 4301, the processing of entries in the SPD is non-trivial and the evaluator + shall determine that the description in the TSS is sufficient to determine which rules will be applied given + the rule structure implemented by the TOE. For example, if the TOE allows specification of ranges, + conditional rules, etc., the evaluator shall determine that the description of rule processing (for both + inbound and outbound packets) is sufficient to determine the action that will be applied, especially in the + case where two different rules may apply. This description shall cover both the initial packets (that is, no + SA is established on the interface or for that particular packet) as well as packets that are part of an + established SA. - The evaluator shall examine the operational guidance to verify it instructs the Administrator how - to construct entries into the SPD that specify a rule for processing a packet. The description - includes all three cases – a rule that ensures packets are encrypted/decrypted, dropped, and - flow through the TOE without being encrypted. The evaluator shall determine - that the description in the operational guidance is consistent with the description in the - TSS, and that the level of detail in the operational guidance is sufficient to - allow the administrator to set up the SPD in an unambiguous fashion. This includes a discussion - of how ordering of rules impacts the processing of an IP packet. + The evaluator shall examine the operational guidance to verify it instructs the Administrator how + to construct entries into the SPD that specify a rule for processing a packet. The description + includes all three cases – a rule that ensures packets are encrypted/decrypted, dropped, and + flow through the TOE without being encrypted. The evaluator shall determine + that the description in the operational guidance is consistent with the description in the + TSS, and that the level of detail in the operational guidance is sufficient to + allow the administrator to set up the SPD in an unambiguous fashion. This includes a discussion + of how ordering of rules impacts the processing of an IP packet. The evaluator shall configure the SPD such that there is a rule for dropping a packet, - encrypting a packet, and allowing a packet to flow in plaintext. The selectors used in - the construction of the rule shall be different such that the evaluator can generate a - packet and send packets to the gateway with the appropriate fields (fields that are used - by the rule - e.g., the IP addresses, TCP/UDP ports) in the packet header. The evaluator - performs both positive and negative test cases for each type of rule (e.g., a packet that - matches the rule and another that does not match the rule). The evaluator observes via the - audit trail, and packet captures that the TOE exhibited the expected - behavior: appropriate packets were dropped, allowed to flow without modification, - encrypted by the IPsec implementation. + encrypting a packet, and allowing a packet to flow in plaintext. The selectors used in + the construction of the rule shall be different such that the evaluator can generate a + packet and send packets to the gateway with the appropriate fields (fields that are used + by the rule - e.g., the IP addresses, TCP/UDP ports) in the packet header. The evaluator + performs both positive and negative test cases for each type of rule (e.g., a packet that + matches the rule and another that does not match the rule). The evaluator observes via the + audit trail, and packet captures that the TOE exhibited the expected + behavior: appropriate packets were dropped, allowed to flow without modification, + encrypted by the IPsec implementation. The evaluator shall devise several tests that cover a variety of scenarios for packet - processing. As with Test 1, the evaluator ensures both positive and negative test cases - are constructed. These scenarios shall exercise the range of possibilities for SPD entries - and processing modes as outlined in the TSS and operational guidance. Potential areas to - cover include rules with overlapping ranges and conflicting entries, inbound and outbound - packets, and packets that establish SAs as well as packets that belong to established SAs. - The evaluator shall verify, via the audit trail and packet captures, for each scenario - that the expected behavior is exhibited, and is consistent with both the TSS and the - operational guidance. + processing. As with Test 1, the evaluator ensures both positive and negative test cases + are constructed. These scenarios shall exercise the range of possibilities for SPD entries + and processing modes as outlined in the TSS and operational guidance. Potential areas to + cover include rules with overlapping ranges and conflicting entries, inbound and outbound + packets, and packets that establish SAs as well as packets that belong to established SAs. + The evaluator shall verify, via the audit trail and packet captures, for each scenario + that the expected behavior is exhibited, and is consistent with both the TSS and the + operational guidance. @@ -1464,42 +1626,42 @@ The TSF shall implement<selectables ><selectable id="fcs_ipsec_ext.1.2_1" >transport mode</selectable><selectable id="fcs_ipsec_ext.1.2_2" >tunnel mode</selectable> </selectables>. - If the TOE is used to connect to a VPN gateway for the purposes of establishing a - secure connection to a private network, the ST author shall select - tunnel mode. If the TOE uses IPsec to establish an end-to-end connection to - another IPsec VPN Client, the ST author shall select transport mode. If - the TOE uses IPsec to establish a connection to a specific endpoint device for the - purpose of secure remote administration, the ST author shall select - transport mode. + If the TOE is used to connect to a VPN gateway for the purposes of establishing a + secure connection to a private network, the ST author shall select + tunnel mode. If the TOE uses IPsec to establish an end-to-end connection to + another IPsec VPN Client, the ST author shall select transport mode. If + the TOE uses IPsec to establish a connection to a specific endpoint device for the + purpose of secure remote administration, the ST author shall select + transport mode. - The evaluator checks the TSS to ensure it states that an IPsec VPN can be - established to operate in tunnel mode or transport mode (as selected). + The evaluator checks the TSS to ensure it states that an IPsec VPN can be + established to operate in tunnel mode or transport mode (as selected). - The evaluator shall confirm that the operational guidance contains instructions on how to - configure the connection in each mode selected. - If both transport mode and tunnel mode are implemented, the evaluator shall review the operational - guidance to determine how the use of a given mode is specified. + The evaluator shall confirm that the operational guidance contains instructions on how to + configure the connection in each mode selected. + If both transport mode and tunnel mode are implemented, the evaluator shall review the operational + guidance to determine how the use of a given mode is specified. - - The evaluator shall perform the following tests based on the selections chosen: - - (conditional): If tunnel mode is selected, the evaluator uses the operational guidance to - configure the TOE/platform to operate in tunnel mode and also configures - a VPN peer to operate in tunnel mode. The evaluator configures the TOE/platform and the - VPN peer to use any of the allowable cryptographic algorithms, authentication methods, - etc. to ensure an allowable SA can be negotiated. The evaluator shall then initiate a - connection from the TOE/Platform to the VPN peer. The evaluator observes (for example, - in the audit trail and the captured packets) that a successful connection was established - using the tunnel mode. + + The evaluator shall perform the following tests based on the selections chosen: + + (conditional): If tunnel mode is selected, the evaluator uses the operational guidance to + configure the TOE/platform to operate in tunnel mode and also configures + a VPN peer to operate in tunnel mode. The evaluator configures the TOE/platform and the + VPN peer to use any of the allowable cryptographic algorithms, authentication methods, + etc. to ensure an allowable SA can be negotiated. The evaluator shall then initiate a + connection from the TOE/Platform to the VPN peer. The evaluator observes (for example, + in the audit trail and the captured packets) that a successful connection was established + using the tunnel mode. (conditional): If transport mode is selectted, the evaluator uses the operational guidance to - configure the TOE/platform to operate in - transport mode and also configures a VPN peer to operate in transport mode. The evaluator - configures the TOE/platform and the VPN peer to use any of the allowed cryptographic - algorithms, authentication methods, etc. to ensure an allowable SA can be negotiated. - The evaluator then initiates a connection from the TOE/platform to connect to the VPN - peer. The evaluator observes (for example, in the audit trail and the captured packets) - that a successful connection was established using the transport mode. + configure the TOE/platform to operate in + transport mode and also configures a VPN peer to operate in transport mode. The evaluator + configures the TOE/platform and the VPN peer to use any of the allowed cryptographic + algorithms, authentication methods, etc. to ensure an allowable SA can be negotiated. + The evaluator then initiates a connection from the TOE/platform to connect to the VPN + peer. The evaluator observes (for example, in the audit trail and the captured packets) + that a successful connection was established using the transport mode. @@ -1508,23 +1670,23 @@ The TSF shall have a nominal, final entry in the SPD that matches anything that is otherwise unmatched, and discards it. If both transport mode and tunnel mode are implemented, the evaluator shall review the - operational guidance to determine how the use of a given mode is specified. + operational guidance to determine how the use of a given mode is specified. - The evaluator shall check that the operational guidance provides instructions on how to construct or - acquire the SPD and uses the guidance to configure the TOE for the following test. + The evaluator shall check that the operational guidance provides instructions on how to construct or + acquire the SPD and uses the guidance to configure the TOE for the following test. - - The evaluator shall perform the following test: - + + The evaluator shall perform the following test: + : The evaluator shall configure the SPD such that it has entries that contain operations that DISCARD, - PROTECT, and (if applicable) BYPASS network packets. The evaluator may use the SPD that was created - for verification of FCS_IPSEC_EXT.1.1. The evaluator shall construct a network packet that matches a - BYPASS entry and send that packet. The evaluator should observe that the network packet is passed to - the proper destination interface with no modification. The evaluator shall then modify a field in the packet - header; such that it no longer matches the evaluator-created entries (there may be a “TOE-created” final - entry that discards packets that do not match any previous entries). The evaluator sends the packet, and - observes that the packet was not permitted to flow to any of the TOE’s interfaces. + PROTECT, and (if applicable) BYPASS network packets. The evaluator may use the SPD that was created + for verification of FCS_IPSEC_EXT.1.1. The evaluator shall construct a network packet that matches a + BYPASS entry and send that packet. The evaluator should observe that the network packet is passed to + the proper destination interface with no modification. The evaluator shall then modify a field in the packet + header; such that it no longer matches the evaluator-created entries (there may be a “TOE-created” final + entry that discards packets that do not match any previous entries). The evaluator sends the packet, and + observes that the packet was not permitted to flow to any of the TOE’s interfaces. @@ -1532,23 +1694,23 @@ The TSF shall implement the IPsec protocol ESP as defined by RFC 4303 using the cryptographic algorithms [AES-GCM-128, AES-GCM-256 (as specified in RFC 4106),<selectables ><selectable id="fcs_ipsec_ext.1.4_1" >AES-CBC-128 (specified in RFC 3602)</selectable><selectable id="fcs_ipsec_ext.1.4_2" >AES-CBC-256 (specified in RFC 3602)</selectable><selectable id="fcs_ipsec_ext.1.4_3" >no other algorithms</selectable> </selectables>] together with a Secure Hash Algorithm (SHA)-based HMAC. - The evaluator shall examine the TSS to verify that the algorithms AES-GCM-128 and - AES-GCM-256 are implemented. If the "ST" author has selected either - AES-CBC-128 or AES-CBC-256 in the requirement, then the evaluator verifies the - TSS describes these as well. In addition, the evaluator ensures that the - SHA-based HMAC algorithm conforms to the algorithms specified in FCS_COP.1/KeyedHash Cryptographic - Operations (Keyed Hash Algorithms). + The evaluator shall examine the TSS to verify that the algorithms AES-GCM-128 and + AES-GCM-256 are implemented. If the "ST" author has selected either + AES-CBC-128 or AES-CBC-256 in the requirement, then the evaluator verifies the + TSS describes these as well. In addition, the evaluator ensures that the + SHA-based HMAC algorithm conforms to the algorithms specified in FCS_COP.1/KeyedHash Cryptographic + Operations (Keyed Hash Algorithms). - The evaluator checks the operational guidance to ensure it provides instructions on how the TOE is - configured to use the algorithms selected in this component and whether this is performed through direct - configuration, defined during initial installation, or defined by acquiring configuration settings from an - environmental component. + The evaluator checks the operational guidance to ensure it provides instructions on how the TOE is + configured to use the algorithms selected in this component and whether this is performed through direct + configuration, defined during initial installation, or defined by acquiring configuration settings from an + environmental component. - The evaluator shall configure the TOE/platform as indicated in the - operational guidance configuring the TOE/platform to use each of the supported - algorithms, attempt to establish a connection using ESP, and verify that the attempt succeeds. - + The evaluator shall configure the TOE/platform as indicated in the + operational guidance configuring the TOE/platform to use each of the supported + algorithms, attempt to establish a connection using ESP, and verify that the attempt succeeds. + @@ -1556,33 +1718,33 @@ The TSF shall implement the protocol: <h:p/><selectables linebreak="yes"><selectable id="fcs_ipsec_ext.1.5_1">IKEv1, using Main Mode for Phase 1 exchanges, as defined in RFC 2407, RFC 2408, RFC 2409, RFC 4109,<selectables><selectable id="fcs_ipsec_ext.1.5_2" >no other RFCs for extended sequence numbers</selectable><selectable id="fcs_ipsec_ext.1.5_3" >RFC 4304 for extended sequence numbers</selectable></selectables>,<selectables><selectable id="fcs_ipsec_ext.1.5_4" >no other RFCs for hash functions</selectable><selectable id="fcs_ipsec_ext.1.5_5" >RFC 4868 for hash functions</selectable></selectables>, and<selectables><selectable id="fcs_ipsec_ext.1.5_6" >support for XAUTH</selectable><selectable id="fcs_ipsec_ext.1.5_7" >no support for XAUTH</selectable></selectables></selectable><selectable id="fcs_ipsec_ext.1.5_8">IKEv2 as defined in RFC 7296 (with mandatory support for NAT traversal as specified in section 2.23), RFC 8784, RFC 8247, and<selectables><selectable id="fcs_ipsec_ext.1.5_9" >no other RFCs for hash functions</selectable><selectable id="fcs_ipsec_ext.1.5_10" >RFC 4868 for hash functions</selectable></selectables>.</selectable> </selectables> If the TOE implements SHA-2 hash algorithms for IKEv1 or IKEv2, the ST author shall - select RFC 4868. + select RFC 4868. The evaluator shall examine the TSS to verify that IKEv1 or IKEv2 (as selected) are implemented. If IKEv1 is - implemented, the evaluator shall verify that the TSS indicates whether or not XAUTH is supported, and - that aggressive mode is not used for IKEv1 Phase 1 exchanges (i.e. only main mode is used). It may be that - these are configurable options. + implemented, the evaluator shall verify that the TSS indicates whether or not XAUTH is supported, and + that aggressive mode is not used for IKEv1 Phase 1 exchanges (i.e. only main mode is used). It may be that + these are configurable options. - The evaluator shall check the operational guidance to ensure it instructs the administrator how to - configure the TOE to use IKEv1 or IKEv2 (as selected), and uses the guidance to configure the TOE to - perform NAT traversal for the test below. If XAUTH is implemented, the evaluator shall verify that the - operational guidance provides instructions on how it is enabled or disabled. - If the TOE supports IKEv1, the evaluator shall verify that the operational guidance either asserts that only - main mode is used for Phase 1 exchanges, or provides instructions for disabling aggressive mode. + The evaluator shall check the operational guidance to ensure it instructs the administrator how to + configure the TOE to use IKEv1 or IKEv2 (as selected), and uses the guidance to configure the TOE to + perform NAT traversal for the test below. If XAUTH is implemented, the evaluator shall verify that the + operational guidance provides instructions on how it is enabled or disabled. + If the TOE supports IKEv1, the evaluator shall verify that the operational guidance either asserts that only + main mode is used for Phase 1 exchanges, or provides instructions for disabling aggressive mode. : The evaluator shall configure the TOE so that it will perform NAT traversal processing as described - in the TSS and RFC 7296, section 2.23. The evaluator shall initiate an IPsec connection and determine that - the NAT is successfully traversed. If the TOE supports IKEv1 with or without XAUTH, the evaluator shall - verify that this test can be successfully repeated with XAUTH enabled and disabled in the manner specified - by the operational guidance. If the TOE only supports IKEv1 with XAUTH, the evaluator shall verify that - connections not using XAUTH are unsuccessful. If the TOE only supports IKEv1 without XAUTH, the - evaluator shall verify that connections using XAUTH are unsuccessful. + in the TSS and RFC 7296, section 2.23. The evaluator shall initiate an IPsec connection and determine that + the NAT is successfully traversed. If the TOE supports IKEv1 with or without XAUTH, the evaluator shall + verify that this test can be successfully repeated with XAUTH enabled and disabled in the manner specified + by the operational guidance. If the TOE only supports IKEv1 with XAUTH, the evaluator shall verify that + connections not using XAUTH are unsuccessful. If the TOE only supports IKEv1 without XAUTH, the + evaluator shall verify that connections using XAUTH are unsuccessful. (conditional): : If the TOE supports IKEv1, the evaluator shall perform any applicable operational - guidance steps to disable the use of aggressive mode and then attempt to establish a connection using an - IKEv1 Phase 1 connection in aggressive mode. This attempt should fail. The evaluator shall show that the - TOE will reject a VPN gateway from initiating an IKEv1 Phase 1 connection in aggressive mode. The - evaluator should then show that main mode exchanges are supported. + guidance steps to disable the use of aggressive mode and then attempt to establish a connection using an + IKEv1 Phase 1 connection in aggressive mode. This attempt should fail. The evaluator shall show that the + TOE will reject a VPN gateway from initiating an IKEv1 Phase 1 connection in aggressive mode. The + evaluator should then show that main mode exchanges are supported. @@ -1591,21 +1753,21 @@ The TSF shall ensure the encrypted payload in the<selectables ><selectable id="fcs_ipsec_ext.1.6_1" >IKEv1</selectable><selectable id="fcs_ipsec_ext.1.6_2" >IKEv2</selectable> </selectables>protocol uses the cryptographic algorithms AES-CBC-128, AES-CBC-256 as specified in RFC 6379 and<selectables ><selectable id="fcs_ipsec_ext.1.6_3" >AES-GCM-128 as specified in RFC 5282</selectable><selectable id="fcs_ipsec_ext.1.6_4" >AES-GCM-256 as specified in RFC 5282</selectable><selectable id="fcs_ipsec_ext.1.6_5" >no other algorithm</selectable> </selectables>. The evaluator shall ensure the TSS identifies the algorithms used for encrypting the IKEv1 or IKEv2 - payload, and that the algorithms AES-CBC-128, AES-CBC-256 are specified, and if others are chosen in the - selection of the requirement, those are included in the TSS discussion. + payload, and that the algorithms AES-CBC-128, AES-CBC-256 are specified, and if others are chosen in the + selection of the requirement, those are included in the TSS discussion. - The evaluator checks the operational guidance to ensure it provides instructions on how the TOE is - configured to use the algorithms selected in this component and whether this is performed through direct - configuration, defined during initial installation, or defined by acquiring configuration settings from an - environmental component. + The evaluator checks the operational guidance to ensure it provides instructions on how the TOE is + configured to use the algorithms selected in this component and whether this is performed through direct + configuration, defined during initial installation, or defined by acquiring configuration settings from an + environmental component. The evaluator shall configure the TOE to use the ciphersuite under test to encrypt the IKEv1 or - IKEv2 payload and establish a connection with a peer device, which is configured to only accept the - payload encrypted using the indicated ciphersuite. The evaluator will confirm the algorithm was that used - in the negotiation. The evaluator will confirm that the connection is successful by confirming that data - can be passed through the connection once it is established. For example, the evaluator may connect to - a webpage on the remote network and verify that it can be reached. + IKEv2 payload and establish a connection with a peer device, which is configured to only accept the + payload encrypted using the indicated ciphersuite. The evaluator will confirm the algorithm was that used + in the negotiation. The evaluator will confirm that the connection is successful by confirming that data + can be passed through the connection once it is established. For example, the evaluator may connect to + a webpage on the remote network and verify that it can be reached. @@ -1613,57 +1775,57 @@ The TSF shall ensure that<selectables ><selectable id="fcs_ipsec_ext.1.7_1">IKEv2 SA lifetimes can be configured by<selectables><selectable id="fcs_ipsec_ext.1.7_2" >an Administrator</selectable><selectable id="fcs_ipsec_ext.1.7_3" >a VPN Gateway</selectable></selectables>based on<selectables><selectable id="fcs_ipsec_ext.1.7_4" >number of packets/number of bytes</selectable><selectable id="fcs_ipsec_ext.1.7_5" >length of time</selectable></selectables></selectable><selectable id="fcs_ipsec_ext.1.7_6">IKEv1 SA lifetimes can be configured by<selectables><selectable id="fcs_ipsec_ext.1.7_7" >an Administrator</selectable><selectable id="fcs_ipsec_ext.1.7_8" >a VPN Gateway</selectable></selectables>based on<selectables><selectable id="fcs_ipsec_ext.1.7_9" >number of packets/number of bytes</selectable><selectable id="fcs_ipsec_ext.1.7_10" >length of time</selectable></selectables></selectable><selectable id="fcs_ipsec_ext.1.7_11">IKEv1 SA lifetimes are fixed based on<selectables><selectable id="fcs_ipsec_ext.1.7_12" >number of packets/number of bytes</selectable><selectable id="fcs_ipsec_ext.1.7_13" >length of time</selectable></selectables>. If length of time is used, it must include at least one option that is 24 hours or less for Phase 1 SAs and 8 hours or less for Phase 2 SAs.</selectable> </selectables> - The ST author is afforded a selection based on the version of IKE in their - implementation. There is a further selection within this selection that allows the - ST author to specify which entity is responsible for “configuring” the life of the - SA. An implementation that allows an administrator to configure the client or a - VPN gateway that pushes the SA lifetime down to the client are both acceptable. - As far as SA lifetimes are concerned, the TOE can limit the lifetime based on the - number of bytes transmitted, or the number of packets transmitted. Either - packet-based or volume-based SA lifetimes are acceptable; the ST author makes - the appropriate selection to indicate which type of lifetime limits are supported. - The ST author chooses either the IKEv1 requirements or IKEv2 requirements (or - both, depending on the selection in FCS_IPSEC_EXT.1.5. The IKEv1 requirement - can be accomplished either by providing Authorized Administrator-configurable - lifetimes (with appropriate instructions in documents mandated by AGD_OPE), - or by “hard coding” the limits in the implementation. For IKEv2, there are no - hardcoded limits, but in this case it is required that an administrator be able to - configure the values. In general, instructions for setting the parameters of the - implementation, including lifetime of the SAs, should be included in the - operational guidance generated for AGD_OPE. It is appropriate to refine the - requirement in terms of number of MB/KB instead of number of packets, as long - as the TOE is capable of setting a limit on the amount of traffic that is protected - by the same key (the total volume of all IPsec traffic protected by that key). - + The ST author is afforded a selection based on the version of IKE in their + implementation. There is a further selection within this selection that allows the + ST author to specify which entity is responsible for “configuring” the life of the + SA. An implementation that allows an administrator to configure the client or a + VPN gateway that pushes the SA lifetime down to the client are both acceptable. + As far as SA lifetimes are concerned, the TOE can limit the lifetime based on the + number of bytes transmitted, or the number of packets transmitted. Either + packet-based or volume-based SA lifetimes are acceptable; the ST author makes + the appropriate selection to indicate which type of lifetime limits are supported. + The ST author chooses either the IKEv1 requirements or IKEv2 requirements (or + both, depending on the selection in FCS_IPSEC_EXT.1.5. The IKEv1 requirement + can be accomplished either by providing Authorized Administrator-configurable + lifetimes (with appropriate instructions in documents mandated by AGD_OPE), + or by “hard coding” the limits in the implementation. For IKEv2, there are no + hardcoded limits, but in this case it is required that an administrator be able to + configure the values. In general, instructions for setting the parameters of the + implementation, including lifetime of the SAs, should be included in the + operational guidance generated for AGD_OPE. It is appropriate to refine the + requirement in terms of number of MB/KB instead of number of packets, as long + as the TOE is capable of setting a limit on the amount of traffic that is protected + by the same key (the total volume of all IPsec traffic protected by that key). + There are no TSS EAs for this requirement. - The evaluator shall check the operational guidance to ensure it provides instructions on how the TOE - configures the values for SA lifetimes. In addition, the evaluator shall check that the guidance has the - option for either the Administrator or VPN Gateway to configure Phase 1 SAs if time-based limits are - supported. Currently there are no values mandated for the number of packets or number of bytes, the - evaluator shall simply check the operational guidance to ensure that this can be configured if selected in - the requirement. - + The evaluator shall check the operational guidance to ensure it provides instructions on how the TOE + configures the values for SA lifetimes. In addition, the evaluator shall check that the guidance has the + option for either the Administrator or VPN Gateway to configure Phase 1 SAs if time-based limits are + supported. Currently there are no values mandated for the number of packets or number of bytes, the + evaluator shall simply check the operational guidance to ensure that this can be configured if selected in + the requirement. + - - Each of the following tests shall be performed for each version of IKE selected in the - FCS_IPSEC_EXT.1.5 protocol selection: - + + Each of the following tests shall be performed for each version of IKE selected in the + FCS_IPSEC_EXT.1.5 protocol selection: + (Conditional): : The evaluator shall configure a maximum lifetime in terms of the # of packets (or - bytes) allowed following the operational guidance. The evaluator shall establish an SA and determine that - once the allowed # of packets (or bytes) through this SA is exceeded, the connection is closed. + bytes) allowed following the operational guidance. The evaluator shall establish an SA and determine that + once the allowed # of packets (or bytes) through this SA is exceeded, the connection is closed. (Conditional): The evaluator shall construct a test where a Phase 1 SA is established and attempted - to be maintained for more than 24 hours before it is renegotiated. The evaluator shall observe that this - SA is closed or renegotiated in 24 hours or less. If such an action requires that the TOE be configured in a - specific way, the evaluator shall implement tests demonstrating that the configuration capability of the - TOE works as documented in the operational guidance. - [conditional]: The evaluator shall perform a test similar to Test 2 - for Phase 2 SAs, except that the lifetime will be 8 hours or less instead of 24 hours or less. + to be maintained for more than 24 hours before it is renegotiated. The evaluator shall observe that this + SA is closed or renegotiated in 24 hours or less. If such an action requires that the TOE be configured in a + specific way, the evaluator shall implement tests demonstrating that the configuration capability of the + TOE works as documented in the operational guidance. + [conditional]: The evaluator shall perform a test similar to Test 2 + for Phase 2 SAs, except that the lifetime will be 8 hours or less instead of 24 hours or less. [conditional]: If a fixed limit for IKEv1 SAs is supported, the evaluator - shall establish an SA and observe that the connection is closed after - the fixed traffic or time value is reached. + shall establish an SA and observe that the connection is closed after + the fixed traffic or time value is reached. @@ -1671,33 +1833,33 @@ The TSF shall ensure that all IKE protocols implement DH groups [19 (256-bit Random ECP), 20 (384-bit Random ECP), and<selectables ><selectable id="fcs_ipsec_ext.1.8_1" >24 (2048-bit MODP with 256-bit POS)</selectable><selectable id="fcs_ipsec_ext.1.8_2" >15 (3072-bit MODP)</selectable><selectable id="fcs_ipsec_ext.1.8_3" >14 (2048-bit MODP)</selectable><selectable id="fcs_ipsec_ext.1.8_4" >no other DH groups</selectable> </selectables>]. - The selection is used to specify additional DH groups supported. This applies to - IKEv1 and IKEv2 exchanges. It should be noted that if any additional DH groups - are specified, they must comply with the requirements (in terms of the - ephemeral keys that are established) listed in FCS_CKM.1. - Since the implementation may allow different Diffie-Hellman groups to be - negotiated for use in forming the SAs, the assignments in FCS_IPSEC_EXT.1.9 - and FCS_IPSEC_EXT.1.10 may contain multiple values. For each DH group - supported, the ST author consults Table 2 in 800-57 to determine the “bits of - security” associated with the DH group. Each unique value is then used to fill in - the assignment (for 1.9 they are doubled; for 1.10 they are inserted directly into - the assignment). For example, suppose the implementation supports DH group - 14 (2048-bit MODP) and group 20 (ECDH using NIST curve P-384). From Table 2, - the bits of security value for group 14 is 112, and for group 20 it is 192. For - FCS_IPSEC_EXT.1.9, then, the assignment would read “[224, 384]” and for - FCS_IPSEC_EXT.1.10 it would read “[112, 192]” (although in this case the - requirement should probably be refined so that it makes sense mathematically). + The selection is used to specify additional DH groups supported. This applies to + IKEv1 and IKEv2 exchanges. It should be noted that if any additional DH groups + are specified, they must comply with the requirements (in terms of the + ephemeral keys that are established) listed in FCS_CKM.1. + Since the implementation may allow different Diffie-Hellman groups to be + negotiated for use in forming the SAs, the assignments in FCS_IPSEC_EXT.1.9 + and FCS_IPSEC_EXT.1.10 may contain multiple values. For each DH group + supported, the ST author consults Table 2 in 800-57 to determine the “bits of + security” associated with the DH group. Each unique value is then used to fill in + the assignment (for 1.9 they are doubled; for 1.10 they are inserted directly into + the assignment). For example, suppose the implementation supports DH group + 14 (2048-bit MODP) and group 20 (ECDH using NIST curve P-384). From Table 2, + the bits of security value for group 14 is 112, and for group 20 it is 192. For + FCS_IPSEC_EXT.1.9, then, the assignment would read “[224, 384]” and for + FCS_IPSEC_EXT.1.10 it would read “[112, 192]” (although in this case the + requirement should probably be refined so that it makes sense mathematically). The evaluator shall check to ensure that the DH groups specified in the requirement are listed as being - supported in the TSS. If there is more than one DH group supported, the evaluator checks to ensure the - TSS describes how a particular DH group is specified/negotiated with a peer. + supported in the TSS. If there is more than one DH group supported, the evaluator checks to ensure the + TSS describes how a particular DH group is specified/negotiated with a peer. - There are no AGD EAs for this requirement. - + There are no AGD EAs for this requirement. + For each supported DH group, the evaluator shall test to ensure that all supported IKE protocols - can be successfully completed using that particular DH group. + can be successfully completed using that particular DH group. @@ -1706,106 +1868,106 @@ The TSF shall generate the secret value x used in the IKE Diffie-Hellman key exchange (“x” in gx mod p) using the random bit generator specified in FCS_RBG_EXT.1, and having a length of at least<assignable>(one or more) number of bits that is at least twice the “bits of security” value associated with the negotiated Diffie-Hellman group as listed in Table 2 of NIST SP 800-57, Recommendation for Key Management – Part 1: General</assignable>bits. The evaluator shall check to ensure that, for each DH group supported, the TSS describes the process for - generating "x" (as defined in FCS_IPSEC_EXT.1.9) and each nonce. The evaluator shall verify that the TSS - indicates that the random number generated that meets the requirements in this EP is used, and that the - length of "x" and the nonces meet the stipulations in the requirement. + generating "x" (as defined in FCS_IPSEC_EXT.1.9) and each nonce. The evaluator shall verify that the TSS + indicates that the random number generated that meets the requirements in this EP is used, and that the + length of "x" and the nonces meet the stipulations in the requirement. - There are no AGD EAs for this requirement. + There are no AGD EAs for this requirement. - There are no test EAs for this requirement. + There are no test EAs for this requirement. The TSF shall generate nonces used in IKE exchanges in a manner such that the probability that a specific nonce value will be repeated during the life a specific IPsec SA is less than 1 in 2^<assignable>(one or more) “bits of security” value associated with the negotiated Diffie-Hellman group as listed in Table 2 of NIST SP 800-57, Recommendation for Key Management – Part 1: General</assignable>. - + The TSF shall ensure that all IKE protocols perform peer authentication using a<selectables ><selectable id="fcs_ipsec_ext.1.11_1" >RSA</selectable><selectable id="fcs_ipsec_ext.1.11_2" >ECDSA</selectable> </selectables>that use X.509v3 certificates that conform to RFC 4945 and<selectables ><selectable id="fcs_ipsec_ext.1.11_3" >Pre-shared Keys</selectable><selectable id="fcs_ipsec_ext.1.11_4" >no other method</selectable> </selectables>. - At least one public-key-based Peer Authentication method is required in order to - conform to this PP-Module; one or more of the public key schemes is chosen by - the ST author to reflect what is implemented. The ST author also ensures that - appropriate FCS requirements reflecting the algorithms used (and key - generation capabilities, if provided) are listed to support those methods. Note - that the TSS will elaborate on the way in which these algorithms are to be used - (for example, 2409 specifies three authentication methods using public keys; - each one supported will be described in the TSS). - If “pre-shared keys” is selected, the selection-based requirement FIA_PSK_EXT.1 - must be claimed. - + At least one public-key-based Peer Authentication method is required in order to + conform to this PP-Module; one or more of the public key schemes is chosen by + the ST author to reflect what is implemented. The ST author also ensures that + appropriate FCS requirements reflecting the algorithms used (and key + generation capabilities, if provided) are listed to support those methods. Note + that the TSS will elaborate on the way in which these algorithms are to be used + (for example, 2409 specifies three authentication methods using public keys; + each one supported will be described in the TSS). + If “pre-shared keys” is selected, the selection-based requirement FIA_PSK_EXT.1 + must be claimed. + The evaluator ensures that the TSS identifies RSA or ECDSA as being used to perform peer - authentication. - If pre-shared keys are chosen in the selection, the evaluator shall check to ensure that the TSS describes - how pre-shared keys are established and used in authentication of IPsec connections. The description in - the TSS shall also indicate how pre-shared key establishment is accomplished depending on whether the - TSF can generate a pre-shared key, accept a pre-shared key, or both. - The evaluator shall ensure that the TSS describes how the TOE compares the peer’s presented identifier - to the reference identifier. This description shall include whether the certificate presented identifier is - compared to the ID payload presented identifier, which fields of the certificate are used as the presented - identifier (DN, Common Name, or SAN) and, if multiple fields are supported, the logical order comparison. - If the ST author assigned an additional identifier type, the TSS description shall also include a description - of that type and the method by which that type is compared to the peer’s presented certificate. + authentication. + If pre-shared keys are chosen in the selection, the evaluator shall check to ensure that the TSS describes + how pre-shared keys are established and used in authentication of IPsec connections. The description in + the TSS shall also indicate how pre-shared key establishment is accomplished depending on whether the + TSF can generate a pre-shared key, accept a pre-shared key, or both. + The evaluator shall ensure that the TSS describes how the TOE compares the peer’s presented identifier + to the reference identifier. This description shall include whether the certificate presented identifier is + compared to the ID payload presented identifier, which fields of the certificate are used as the presented + identifier (DN, Common Name, or SAN) and, if multiple fields are supported, the logical order comparison. + If the ST author assigned an additional identifier type, the TSS description shall also include a description + of that type and the method by which that type is compared to the peer’s presented certificate. - The evaluator shall check that the operational guidance describes how pre-shared keys are to be - generated and established. - The evaluator ensures the operational guidance describes how to set up the TOE to use the cryptographic - algorithms RSA or ECDSA (as selected). - In order to construct the environment and configure the TOE for the following tests, the evaluator will - ensure that the operational guidance also describes how to configure the TOE to connect to a trusted CA, - and ensure a valid certificate for that CA is loaded into the TOE as a trusted CA. - The evaluator shall also ensure that the operational guidance includes the configuration of the reference - identifiers for the peer. + The evaluator shall check that the operational guidance describes how pre-shared keys are to be + generated and established. + The evaluator ensures the operational guidance describes how to set up the TOE to use the cryptographic + algorithms RSA or ECDSA (as selected). + In order to construct the environment and configure the TOE for the following tests, the evaluator will + ensure that the operational guidance also describes how to configure the TOE to connect to a trusted CA, + and ensure a valid certificate for that CA is loaded into the TOE as a trusted CA. + The evaluator shall also ensure that the operational guidance includes the configuration of the reference + identifiers for the peer. : The evaluator shall have the TOE generate a public-private key pair, and submit a CSR (Certificate - Signing Request) to a CA (trusted by both the TOE and the peer VPN used to establish a connection) for - its signature. The values for the DN (Common Name, Organization, Organizational Unit, and Country) will - also be passed in the request. Alternatively, the evaluator may import to the TOE a previously generated - private key and corresponding certificate. + Signing Request) to a CA (trusted by both the TOE and the peer VPN used to establish a connection) for + its signature. The values for the DN (Common Name, Organization, Organizational Unit, and Country) will + also be passed in the request. Alternatively, the evaluator may import to the TOE a previously generated + private key and corresponding certificate. The evaluator shall configure the TOE to use a private key and associated certificate signed by a - trusted CA and shall establish an IPsec connection with the peer. + trusted CA and shall establish an IPsec connection with the peer. The evaluator shall test that the TOE can properly handle revoked certificates – conditional on - whether CRL or OCSP is selected; if both are selected, and then a test is performed for each method. For - this current version of the PP-Module, the evaluator has to only test one up in the trust chain (future - drafts may require to ensure the validation is done up the entire chain). The evaluator shall ensure that a - valid certificate is used, and that the SA is established. The evaluator then attempts the test with a - certificate that will be revoked (for each method chosen in the selection) to ensure when the certificate - is no longer valid that the TOE will not establish an SA. + whether CRL or OCSP is selected; if both are selected, and then a test is performed for each method. For + this current version of the PP-Module, the evaluator has to only test one up in the trust chain (future + drafts may require to ensure the validation is done up the entire chain). The evaluator shall ensure that a + valid certificate is used, and that the SA is established. The evaluator then attempts the test with a + certificate that will be revoked (for each method chosen in the selection) to ensure when the certificate + is no longer valid that the TOE will not establish an SA. [conditional]: The evaluator shall generate a pre-shared key and use it, as indicated in the - operational guidance, to establish an IPsec connection with the VPN GW peer. If the generation of the - pre-shared key is supported, the evaluator shall ensure that establishment of the key is carried out for an - instance of the TOE generating the key as well as an instance of the TOE merely taking in and using the - key. - For each supported identifier type (excluding DNs), the evaluator shall repeat the following tests: + operational guidance, to establish an IPsec connection with the VPN GW peer. If the generation of the + pre-shared key is supported, the evaluator shall ensure that establishment of the key is carried out for an + instance of the TOE generating the key as well as an instance of the TOE merely taking in and using the + key. + For each supported identifier type (excluding DNs), the evaluator shall repeat the following tests: For each field of the certificate supported for comparison, the evaluator shall configure the peer’s - reference identifier on the TOE (per the administrative guidance) to match the field in the peer’s - presented certificate and shall verify that the IKE authentication succeeds. + reference identifier on the TOE (per the administrative guidance) to match the field in the peer’s + presented certificate and shall verify that the IKE authentication succeeds. For each field of the certificate support for comparison, the evaluator shall configure the peer’s - reference identifier on the TOE (per the administrative guidance) to not match the field in the peer’s - presented certificate and shall verify that the IKE authentication fails. - The following tests are conditional: + reference identifier on the TOE (per the administrative guidance) to not match the field in the peer’s + presented certificate and shall verify that the IKE authentication fails. + The following tests are conditional: [conditional]: If, according to the TSS, the TOE supports both Common Name and SAN certificate - fields and uses the preferred logic outlined in the Application Note, the tests above with the Common - Name field shall be performed using peer certificates with no SAN extension. Additionally, the evaluator - shall configure the peer’s reference identifier on the TOE to not match the SAN in the peer’s presented - certificate but to match the Common Name in the peer’s presented certificate, and verify that the IKE - authentication fails. + fields and uses the preferred logic outlined in the Application Note, the tests above with the Common + Name field shall be performed using peer certificates with no SAN extension. Additionally, the evaluator + shall configure the peer’s reference identifier on the TOE to not match the SAN in the peer’s presented + certificate but to match the Common Name in the peer’s presented certificate, and verify that the IKE + authentication fails. [conditional]: If the TOE supports DN identifier types, the evaluator shall configure the peer's - reference identifier on the TOE (per the administrative guidance) to match the subject DN in the peer's - presented certificate and shall verify that the IKE authentication succeeds. To demonstrate a bit-wise - comparison of the DN, the evaluator shall change a single bit in the DN (preferably, in an Object Identifier - (OID) in the DN) and verify that the IKE authentication fails. To demonstrate a comparison of DN values, - the evaluator shall change any one of the four DN values and verify that the IKE authentication fails. + reference identifier on the TOE (per the administrative guidance) to match the subject DN in the peer's + presented certificate and shall verify that the IKE authentication succeeds. To demonstrate a bit-wise + comparison of the DN, the evaluator shall change a single bit in the DN (preferably, in an Object Identifier + (OID) in the DN) and verify that the IKE authentication fails. To demonstrate a comparison of DN values, + the evaluator shall change any one of the four DN values and verify that the IKE authentication fails. [conditional]: If the TOE supports both IPv4 and IPv6 and supports IP address identifier types, the - evaluator must repeat test 1 and 2 with both IPv4 address identifiers and IPv6 identifiers. Additionally, - the evaluator shall verify that the TOE verifies that the IP header matches the identifiers by setting the - presented identifiers and the reference identifier with the same IP address that differs from the actual IP - address of the peer in the IP headers and verifying that the IKE authentication fails. + evaluator must repeat test 1 and 2 with both IPv4 address identifiers and IPv6 identifiers. Additionally, + the evaluator shall verify that the TOE verifies that the IP header matches the identifiers by setting the + presented identifiers and the reference identifier with the same IP address that differs from the actual IP + address of the peer in the IP headers and verifying that the IKE authentication fails. [conditional]: If, according to the TSS, the TOE performs comparisons between the peer’s ID - payload and the peer’s certificate, the evaluator shall repeat the following test for each combination of - supported identifier types and supported certificate fields (as above). The evaluator shall configure the - peer to present a different ID payload than the field in the peer’s presented certificate and verify that the - TOE fails to authenticate the IKE peer. + payload and the peer’s certificate, the evaluator shall repeat the following test for each combination of + supported identifier types and supported certificate fields (as above). The evaluator shall configure the + peer to present a different ID payload than the field in the peer’s presented certificate and verify that the + TOE fails to authenticate the IKE peer. @@ -1813,75 +1975,75 @@ The TSF shall not establish an SA if the [<selectables ><selectable id="fcs_ipsec_ext.1.12_1" >IP address</selectable><selectable id="fcs_ipsec_ext.1.12_2" >Fully Qualified Domain Name (FQDN)</selectable><selectable id="fcs_ipsec_ext.1.12_3" >user FQDN</selectable><selectable id="fcs_ipsec_ext.1.12_4" >Distinguished Name (DN)</selectable> </selectables>and<selectables ><selectable id="fcs_ipsec_ext.1.12_5" >no other reference identifier type</selectable><selectable id="fcs_ipsec_ext.1.12_7" ><assignable>other supported reference identifier types</assignable></selectable> </selectables>] contained in a certificate does not match the expected values for the entity attempting to establish a connection. - The TOE must support at least one of the following identifier types: IP address, - Fully Qualified Domain Name (FQDN), user FQDN, or Distinguished Name (DN). - In the future, the TOE will be required to support all of these identifier types. The - TOE is expected to support as many IP address formats (IPv4 and IPv6) as IP - versions supported by the TOE in general. The ST author may assign additional - supported identifier types in the second selection. - - + The TOE must support at least one of the following identifier types: IP address, + Fully Qualified Domain Name (FQDN), user FQDN, or Distinguished Name (DN). + In the future, the TOE will be required to support all of these identifier types. The + TOE is expected to support as many IP address formats (IPv4 and IPv6) as IP + versions supported by the TOE in general. The ST author may assign additional + supported identifier types in the second selection. + + The TSF shall not establish an SA if the presented identifier does not match the configured reference identifier of the peer. - At this time, only the comparison between the presented identifier in the peer’s - certificate and the peer’s reference identifier is mandated by the testing below. - However, in the future, this requirement will address two aspects of the peer - certificate validation: 1) comparison of the peer’s ID payload to the peer’s - certificate which are both presented identifiers, as required by RFC 4945 and 2) - verification that the peer identified by the ID payload and the certificate is the - peer expected by the TOE (per the reference identifier). At that time, the TOE will - be required to demonstrate both aspects (i.e. that the TOE enforces that the - peer’s ID payload matches the peer’s certificate which both match configured - peer reference identifiers). - Excluding the DN identifier type (which is necessarily the Subject DN in the peer - certificate), the TOE may support the identifier in either the Common Name or - Subject Alternative Name (SAN) or both. If both are supported, the preferred - logic is to compare the reference identifier to a presented SAN, and only if the - peer’s certificate does not contain a SAN, to fall back to a comparison against - the Common Name. In the future, the TOE will be required to compare the - reference identifier to the presented identifier in the SAN only, ignoring the - Common Name. - The configuration of the peer reference identifier is addressed by - FMT_SMF.1.1/VPN. - + At this time, only the comparison between the presented identifier in the peer’s + certificate and the peer’s reference identifier is mandated by the testing below. + However, in the future, this requirement will address two aspects of the peer + certificate validation: 1) comparison of the peer’s ID payload to the peer’s + certificate which are both presented identifiers, as required by RFC 4945 and 2) + verification that the peer identified by the ID payload and the certificate is the + peer expected by the TOE (per the reference identifier). At that time, the TOE will + be required to demonstrate both aspects (i.e. that the TOE enforces that the + peer’s ID payload matches the peer’s certificate which both match configured + peer reference identifiers). + Excluding the DN identifier type (which is necessarily the Subject DN in the peer + certificate), the TOE may support the identifier in either the Common Name or + Subject Alternative Name (SAN) or both. If both are supported, the preferred + logic is to compare the reference identifier to a presented SAN, and only if the + peer’s certificate does not contain a SAN, to fall back to a comparison against + the Common Name. In the future, the TOE will be required to compare the + reference identifier to the presented identifier in the SAN only, ignoring the + Common Name. + The configuration of the peer reference identifier is addressed by + FMT_SMF.1.1/VPN. + The<selectables ><selectable id="fcs_ipsec_ext.1.14_1" >TSF</selectable><selectable id="fcs_ipsec_ext.1.14_2" >VPN Gateway</selectable> </selectables>shall be able to ensure by default that the strength of the symmetric algorithm (in terms of the number of bits in the key) negotiated to protect the<selectables ><selectable id="fcs_ipsec_ext.1.14_3" >IKEv1 Phase 1</selectable><selectable id="fcs_ipsec_ext.1.14_4" >IKEv2 IKE_SA</selectable> </selectables>connection is greater than or equal to the strength of the symmetric algorithm (in terms of the number of bits in the key) negotiated to protect the [selection: IKEv1 Phase 2, IKEv2 CHILD_SA] connection. - If this functionality is configurable, the TSF may be configured by a VPN Gateway - or by an Administrator of the TOE itself. - The ST author chooses either or both of the IKE selections based on what is - implemented by the TOE. Obviously, the IKE versions chosen should be - consistent not only in this element, but with other choices for other elements in - this component. While it is acceptable for this capability to be configurable, the - default configuration in the evaluated configuration (either "out of the box" or - by configuration guidance in the AGD documentation) must enable this - functionality. - + If this functionality is configurable, the TSF may be configured by a VPN Gateway + or by an Administrator of the TOE itself. + The ST author chooses either or both of the IKE selections based on what is + implemented by the TOE. Obviously, the IKE versions chosen should be + consistent not only in this element, but with other choices for other elements in + this component. While it is acceptable for this capability to be configurable, the + default configuration in the evaluated configuration (either "out of the box" or + by configuration guidance in the AGD documentation) must enable this + functionality. + The evaluator shall check that the TSS describes the potential strengths (in terms of the number of bits in - the symmetric key) of the algorithms that are allowed for the IKE and ESP exchanges. The TSS shall also - describe the checks that are done when negotiating IKEv1 Phase 2 and IKEv2 CHILD_SA suites to ensure - that the strength (in terms of the number of bits of key in the symmetric algorithm) of the negotiated - algorithm is less than or equal to that of the IKE SA that is protecting the negotiation. + the symmetric key) of the algorithms that are allowed for the IKE and ESP exchanges. The TSS shall also + describe the checks that are done when negotiating IKEv1 Phase 2 and IKEv2 CHILD_SA suites to ensure + that the strength (in terms of the number of bits of key in the symmetric algorithm) of the negotiated + algorithm is less than or equal to that of the IKE SA that is protecting the negotiation. - There are no AGD EAs for this requirement. - + There are no AGD EAs for this requirement. + This test shall be performed for each version of IKE supported. The evaluator shall successfully - negotiate an IPsec connection using each of the supported algorithms and hash functions identified in the - requirements. + negotiate an IPsec connection using each of the supported algorithms and hash functions identified in the + requirements. [conditional]: This test shall be performed for each version of IKE supported. The evaluator shall - attempt to establish an SA for ESP that selects an encryption algorithm with more strength than that being - used for the IKE SA (i.e., symmetric algorithm with a key size larger than that being used for the IKE SA). - Such attempts should fail. + attempt to establish an SA for ESP that selects an encryption algorithm with more strength than that being + used for the IKE SA (i.e., symmetric algorithm with a key size larger than that being used for the IKE SA). + Such attempts should fail. This test shall be performed for each version of IKE supported. The evaluator shall attempt to - establish an IKE SA using an algorithm that is not one of the supported algorithms and hash functions - identified in the requirements. Such an attempt should fail. + establish an IKE SA using an algorithm that is not one of the supported algorithms and hash functions + identified in the requirements. Such an attempt should fail. : This test shall be performed for each version of IKE supported. The evaluator shall attempt to - establish an SA for ESP (assumes the proper parameters where used to establish the IKE SA) that selects - an encryption algorithm that is not identified in FCS_IPSEC_EXT.1.4. Such an attempt should fail. + establish an SA for ESP (assumes the proper parameters where used to establish the IKE SA) that selects + an encryption algorithm that is not identified in FCS_IPSEC_EXT.1.4. Such an attempt should fail. @@ -1900,62 +2062,62 @@ requires random bit generation to be performed in accordance with - selected standards and seeded by an entropy source. + selected standards and seeded by an entropy source. No specific management functions are identified. The following actions should be auditable if FAU_GEN Security audit data - generation is included in the PP/ST: - Failure of the randomization process. + generation is included in the PP/ST: + Failure of the randomization process. FCS_COP.1 Cryptographic Operation The TSF shall perform all deterministic random bit generation services in accordance with NIST Special Publication 800-90A using<selectables ><selectable id="fcs_rbg_ext.1.1_1" >Hash_DRBG (any)</selectable><selectable id="fcs_rbg_ext.1.1_2" >HMAC_DRBG (any)</selectable><selectable id="fcs_rbg_ext.1.1_3" >CTR_DRBG (AES)</selectable> </selectables> - The evaluator shall also perform the following tests, depending on the standard to which the RBG - conforms. - The evaluator shall perform 15 trials for the RBG implementation. If the RBG 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 RBG functionality. - If the RBG has prediction resistance enabled, each trial consists of (1) instantiate DRBG, (2) - generate the first block of random bits (3) generate a second block of random bits (4) - uninstantiate. The evaluator verifies that the second block of random bits is the expected value. - The evaluator shall generate eight input values for each trial. The first is a count (0 – 14). The - next three are entropy input, nonce, and personalization string for the instantiate operation. The - next two are additional input and entropy input for the first call to generate. The final two are - additional input and entropy input for the second call to generate. These values are randomly - generated. “generate one block of random bits” means to generate random bits with number of - returned bits equal to the Output Block Length (as defined in NIST SP 800-90A). - If the RBG does not have prediction resistance, each trial consists of (1) instantiate DRBG, (2) - generate the first block of random bits (3) reseed, (4) generate a second block of random bits (5) - uninstantiate. The evaluator verifies that the second block of random bits is the expected value. - The evaluator shall generate eight input values for each trial. The first is a count (0 – 14). The - next three are entropy input, nonce, and personalization string for the instantiate operation. The - fifth value is additional input to the first call to generate. The sixth and seventh are additional - input and entropy input to the call to reseed. The final value is additional input to the second - generate call. - The following 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 lengthNonce: If a nonce is supported (CTR_DRBG with no df 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 < = 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 supported, 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. + The evaluator shall also perform the following tests, depending on the standard to which the RBG + conforms. + The evaluator shall perform 15 trials for the RBG implementation. If the RBG 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 RBG functionality. + If the RBG has prediction resistance enabled, each trial consists of (1) instantiate DRBG, (2) + generate the first block of random bits (3) generate a second block of random bits (4) + uninstantiate. The evaluator verifies that the second block of random bits is the expected value. + The evaluator shall generate eight input values for each trial. The first is a count (0 – 14). The + next three are entropy input, nonce, and personalization string for the instantiate operation. The + next two are additional input and entropy input for the first call to generate. The final two are + additional input and entropy input for the second call to generate. These values are randomly + generated. “generate one block of random bits” means to generate random bits with number of + returned bits equal to the Output Block Length (as defined in NIST SP 800-90A). + If the RBG does not have prediction resistance, each trial consists of (1) instantiate DRBG, (2) + generate the first block of random bits (3) reseed, (4) generate a second block of random bits (5) + uninstantiate. The evaluator verifies that the second block of random bits is the expected value. + The evaluator shall generate eight input values for each trial. The first is a count (0 – 14). The + next three are entropy input, nonce, and personalization string for the instantiate operation. The + fifth value is additional input to the first call to generate. The sixth and seventh are additional + input and entropy input to the call to reseed. The final value is additional input to the second + generate call. + The following 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 lengthNonce: If a nonce is supported (CTR_DRBG with no df 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 < = 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 supported, 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. The deterministic RBG shall be seeded by an entropy source that accumulates entropy from<selectables ><selectable id="fcs_rbg_ext.1.2_1" >a software-based noise source</selectable><selectable id="fcs_rbg_ext.1.2_2" >a hardware-based noise source</selectable> </selectables>with a minimum of<selectables ><selectable id="fcs_rbg_ext.1.2_3" >128 bits</selectable><selectable id="fcs_rbg_ext.1.2_4" >192 bits</selectable><selectable id="fcs_rbg_ext.1.2_5" >256 bits</selectable> </selectables>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. - NIST 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, and include the specific underlying cryptographic primitives - used in the requirement. While any of the identified hash functions (SHA-1, SHA-224, SHA-256, SHA-384, - SHA-44 512) are allowed for Hash_DRBG or HMAC_DRBG, only AES-based - implementations for CTR_DRBG are allowed. - If the key length for the AES implementation used here is different than that used to encrypt the user - data, then FCS_COP.1/UDE may have to be adjusted or iterated to reflect the different key length. For the - selection in FCS_RBG_EXT.1.2, the ST author selects the minimum number of bits of - entropy that is used to seed the RBG. - + NIST 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, and include the specific underlying cryptographic primitives + used in the requirement. While any of the identified hash functions (SHA-1, SHA-224, SHA-256, SHA-384, + SHA-44 512) are allowed for Hash_DRBG or HMAC_DRBG, only AES-based + implementations for CTR_DRBG are allowed. + If the key length for the AES implementation used here is different than that used to encrypt the user + data, then FCS_COP.1/UDE may have to be adjusted or iterated to reflect the different key length. For the + selection in FCS_RBG_EXT.1.2, the ST author selects the minimum number of bits of + entropy that is used to seed the RBG. + Failure of the randomization process. @@ -1983,25 +2145,25 @@ requires the TSF to identify the mechanisms used to isolate Guest VMs from platform - hardware resources. + hardware resources. No specific management functions are identified. There are no auditable events foreseen. FDP_VMS_EXT.1 VM Separation The TSF shall use<selectables ><selectable id="fdp_hbi_ext.1.1_1" >no mechanism</selectable><selectable id="fdp_hbi_ext.1.1_3" ><assignable>list of platform-provided, hardware-based mechanisms</assignable></selectable> </selectables>to constrain a Guest VM's direct access to the following physical devices:<selectables ><selectable id="fdp_hbi_ext.1.1_4" >no devices</selectable><selectable id="fdp_hbi_ext.1.1_6" ><assignable>physical devices to which the VMM allows Guest VMs physical access</assignable></selectable> </selectables>. The TSF must use available hardware-based isolation mechanisms to constrain VMs - when VMs have direct access to physical devices. “Direct access” in this context means that the - VM can read or write device memory or access device I/O ports without the VMM being able to intercept - and validate every transaction. + when VMs have direct access to physical devices. “Direct access” in this context means that the + VM can read or write device memory or access device I/O ports without the VMM being able to intercept + and validate every transaction. The evaluator shall ensure that the TSS provides evidence that hardware-based - isolation mechanisms are used to constrain VMs when VMs have - direct access to physical devices, including an explanation of the conditions under which the - TSF invokes these protections. + isolation mechanisms are used to constrain VMs when VMs have + direct access to physical devices, including an explanation of the conditions under which the + TSF invokes these protections. - The evaluator shall verify that the operational guidance contains instructions on how to ensure - that the platform-provided, hardware-based mechanisms are enabled. - + The evaluator shall verify that the operational guidance contains instructions on how to ensure + that the platform-provided, hardware-based mechanisms are enabled. + @@ -2010,65 +2172,65 @@ requires the TSF to define the hardware resources that Guest VMs may always access, may never access, - and may conditionally access based on administrative configuration. + and may conditionally access based on administrative configuration. The following actions could be considered for the management functions in FMT: - Ability to configure VM access to physical devices. - The following actions should be auditable if FAU_GEN Security audit data - generation is included in the PP/ST: - Successful and failed VM connections to physical devices where - connection is governed by configurable policy.Security policy violations. + Ability to configure VM access to physical devices. + The following actions should be auditable if FAU_GEN Security audit data + generation is included in the PP/ST: + Successful and failed VM connections to physical devices where + connection is governed by configurable policy.Security policy violations. FDP_HBI_EXT.1 Hardware-Based Isolation Mechanisms - FMT_SMR.1 Security Roles + FMT_SMR.1 Security Roles The TSF shall allow an authorized administrator to control Guest VM access to the following physical platform resources:<assignable>list of physical platform resources the VMM is able to control access to</assignable>. The evaluator shall examine the TSS to determine that it describes the mechanism by which the VMM controls a Guest VM's access to - physical platform resources. This description shall cover all of the physical - platforms allowed in the evaluated configuration by the ST. It should explain how the VMM distinguishes among Guest VMs, and - how each physical platform resource that is controllable (that is, listed in the assignment - statement in the first element) is identified to an Administrator. - The evaluator shall ensure that the TSS describes how the Guest VM is associated with each - physical resource, and how other Guest VMs cannot access a physical resource - without being granted explicit access. For TOEs that implement a robust - interface (other than just "allow access" or "deny access"), the evaluator shall ensure that the - TSS describes the possible operations or modes of access between a Guest - VM's and physical platform resources. - If physical resources are listed in the second element, the evaluator shall examine the - TSS and operational guidance to determine that there appears to be no way to - configure those resources for access by a Guest VM. The evaluator shall - document in the evaluation report their analysis of why the controls offered to configure access - to physical resources can't be used to specify access to the resources identified in the second - element (for example, if the interface offers a drop-down list of resources to assign, and the - denied resources are not included on that list, that would be sufficient justification in the - evaluation report). + physical platform resources. This description shall cover all of the physical + platforms allowed in the evaluated configuration by the ST. It should explain how the VMM distinguishes among Guest VMs, and + how each physical platform resource that is controllable (that is, listed in the assignment + statement in the first element) is identified to an Administrator. + The evaluator shall ensure that the TSS describes how the Guest VM is associated with each + physical resource, and how other Guest VMs cannot access a physical resource + without being granted explicit access. For TOEs that implement a robust + interface (other than just "allow access" or "deny access"), the evaluator shall ensure that the + TSS describes the possible operations or modes of access between a Guest + VM's and physical platform resources. + If physical resources are listed in the second element, the evaluator shall examine the + TSS and operational guidance to determine that there appears to be no way to + configure those resources for access by a Guest VM. The evaluator shall + document in the evaluation report their analysis of why the controls offered to configure access + to physical resources can't be used to specify access to the resources identified in the second + element (for example, if the interface offers a drop-down list of resources to assign, and the + denied resources are not included on that list, that would be sufficient justification in the + evaluation report). - The evaluator shall examine the operational guidance to determine that it describes how an - administrator is able to configure access to physical platform resources for Guest - VMs for each platform allowed in the evaluated configuration according to the - ST. The evaluator shall also determine that the operational guidance identifies - those resources listed in the second and third elements of the component and notes that access to - these resources is explicitly denied/allowed, respectively. - + The evaluator shall examine the operational guidance to determine that it describes how an + administrator is able to configure access to physical platform resources for Guest + VMs for each platform allowed in the evaluated configuration according to the + ST. The evaluator shall also determine that the operational guidance identifies + those resources listed in the second and third elements of the component and notes that access to + these resources is explicitly denied/allowed, respectively. + For each physical platform resource identified in the first element, the evaluator shall - configure a Guest VM to have access to that resource and show that the Guest VM is able to - successfully access that resource. + configure a Guest VM to have access to that resource and show that the Guest VM is able to + successfully access that resource. For each physical platform resource identified in the first element, the evaluator shall - configure the system such that a Guest VM does not have access to that resource and show - that the Guest VM is unable to successfully access that resource. - [conditional]: For TOEs that have a robust control interface, the evaluator shall exercise - each element of the interface as described in the TSS and the operational guidance to - ensure that the behavior described in the operational guidance is exhibited. + configure the system such that a Guest VM does not have access to that resource and show + that the Guest VM is unable to successfully access that resource. + [conditional]: For TOEs that have a robust control interface, the evaluator shall exercise + each element of the interface as described in the TSS and the operational guidance to + ensure that the behavior described in the operational guidance is exhibited. [conditional]: If the TOE explicitly denies access to certain physical resources, the - evaluator shall attempt to access each listed (in FDP_PPR_EXT.1.2) physical resource - from a Guest VM and observe that access is denied. - [conditional]: If the TOE explicitly allows access to certain physical resources, the - evaluator shall attempt to access each listed (in FDP_PPR_EXT.1.3) physical resource - from a Guest VM and observe that the access is allowed. If the operational guidance - specifies that access is allowed simultaneously by more than one Guest VM, the evaluator - shall attempt to access each resource listed from more than one Guest VM and show that - access is allowed. + evaluator shall attempt to access each listed (in FDP_PPR_EXT.1.2) physical resource + from a Guest VM and observe that access is denied. + [conditional]: If the TOE explicitly allows access to certain physical resources, the + evaluator shall attempt to access each listed (in FDP_PPR_EXT.1.3) physical resource + from a Guest VM and observe that the access is allowed. If the operational guidance + specifies that access is allowed simultaneously by more than one Guest VM, the evaluator + shall attempt to access each resource listed from more than one Guest VM and show that + access is allowed. @@ -2079,14 +2241,14 @@ The TSF shall explicitly allow all Guest VMs access to the following physical platform resources:<selectables ><selectable id="fdp_ppr_ext.1.3_1" >no physical platform resources</selectable><selectable id="fdp_ppr_ext.1.3_3" ><assignable>list of physical platform resources to which access is always allowed</assignable></selectable> </selectables>. - For purposes of this requirement, physical platform resources are divided into three categories: - those to which Guest OS access is configurable and moderated by the VMMthose to which the Guest OS is never allowed to have direct access, andthose to which the Guest OS is always allowed to have direct access. - For element 1, the ST author lists the physical platform resources that can be configured for Guest VM access by - an administrator. For element 2, the ST author lists the physical platform resources to which - Guest VMs may never be allowed direct access. If there are no such resources, the ST author selects "no physical platform - resources." Likewise, any resources to which all Guest VMs automatically have access to are to be listed in - the third element. If there are no such resources, then "no physical platform resources" is selected. - + For purposes of this requirement, physical platform resources are divided into three categories: + those to which Guest OS access is configurable and moderated by the VMMthose to which the Guest OS is never allowed to have direct access, andthose to which the Guest OS is always allowed to have direct access. + For element 1, the ST author lists the physical platform resources that can be configured for Guest VM access by + an administrator. For element 2, the ST author lists the physical platform resources to which + Guest VMs may never be allowed direct access. If there are no such resources, the ST author selects "no physical platform + resources." Likewise, any resources to which all Guest VMs automatically have access to are to be listed in + the third element. If there are no such resources, then "no physical platform resources" is selected. + Successful and failed VM connections to physical devices where connection is governed by configurable policy. @@ -2101,27 +2263,27 @@ requires the TSF to ensure that physical memory is cleared to zeros prior to its allocation to a - Guest VM. + Guest VM. No specific management functions are identified. There are no auditable events foreseen. No dependencies. The TSF shall ensure that any previous information content of physical memory is cleared prior to allocation to a Guest VM. Physical memory must be zeroed before it is made accessible to a VM for general use - by a Guest OS. - The purpose of this requirement is to ensure that a VM does not receive memory - containing data previously used by another VM or the host. - “For general use” means for use by the Guest OS in its page tables for running applications or system - software. - This does not apply to pages shared by design or policy between VMs or between the VMMs and VMs, such - as read-only OS pages or pages used for virtual device buffers. - + by a Guest OS. + The purpose of this requirement is to ensure that a VM does not receive memory + containing data previously used by another VM or the host. + “For general use” means for use by the Guest OS in its page tables for running applications or system + software. + This does not apply to pages shared by design or policy between VMs or between the VMMs and VMs, such + as read-only OS pages or pages used for virtual device buffers. + The evaluator shall ensure that the TSS documents the process used for clearing - physical memory prior to allocation to a Guest VM, providing details on when - and how this is performed. Additionally, the evaluator shall ensure that the TSS - documents the conditions under which physical memory is not cleared prior to allocation to a - Guest VM, and describes when and how the memory is cleared. + physical memory prior to allocation to a Guest VM, providing details on when + and how this is performed. Additionally, the evaluator shall ensure that the TSS + documents the conditions under which physical memory is not cleared prior to allocation to a + Guest VM, and describes when and how the memory is cleared. @@ -2129,36 +2291,36 @@ - requires the TSF to ensure that physical disk storage is cleared upon - allocation to a Guest VM. + requires the TSF to ensure that physical disk storage is cleared upon + allocation to a Guest VM. No specific management functions are identified. There are no auditable events foreseen. No dependencies. The TSF shall ensure that any previous information content of physical disk storage is cleared to zeros upon allocation to a Guest VM. - The purpose of this requirement is to ensure that a VM does not receive disk storage containing data - previously used by another VM or by the host. - Clearing of disk storage only upon deallocation does not meet this requirement. - This does not apply to disk-resident files shared by design or policy between VMs or between the VMMs and - VMs, such as read-only data files or files used for inter-VM data transfers permitted by policy. + The purpose of this requirement is to ensure that a VM does not receive disk storage containing data + previously used by another VM or by the host. + Clearing of disk storage only upon deallocation does not meet this requirement. + This does not apply to disk-resident files shared by design or policy between VMs or between the VMMs and + VMs, such as read-only data files or files used for inter-VM data transfers permitted by policy. - The evaluator shall ensure that the TSS documents how the TSF ensures that disk storage is zeroed upon allocation to - Guest VMs. Also, the TSS must document any conditions under which disk storage is not cleared prior to allocation to a Guest VM. - Any file system format and metadata information needed by the evaluator to perform the below test shall be made available - to the evaluator, but need not be published in the TSS. + The evaluator shall ensure that the TSS documents how the TSF ensures that disk storage is zeroed upon allocation to + Guest VMs. Also, the TSS must document any conditions under which disk storage is not cleared prior to allocation to a Guest VM. + Any file system format and metadata information needed by the evaluator to perform the below test shall be made available + to the evaluator, but need not be published in the TSS. - On the host, the evaluator creates a file that is more than half the size of a connected physical - storage device (or multiple files whose individual sizes add up to more than half the size of - the storage media). This file (or files) shall be filled entirely with a non-zero value. - Then, the file (or files) shall be released (freed for use but not cleared). Next, the - evaluator (as a VS Administrator) creates a virtual disk at least that large on the same - physical storage device and connects it to a powered-off VM. Then, from outside the Guest VM, - scan through and check that all the non-metadata (as documented in the TSS) in the file - corresponding to that virtual disk is set to zero. - + On the host, the evaluator creates a file that is more than half the size of a connected physical + storage device (or multiple files whose individual sizes add up to more than half the size of + the storage media). This file (or files) shall be filled entirely with a non-zero value. + Then, the file (or files) shall be released (freed for use but not cleared). Next, the + evaluator (as a VS Administrator) creates a virtual disk at least that large on the same + physical storage device and connects it to a powered-off VM. Then, from outside the Guest VM, + scan through and check that all the non-metadata (as documented in the TSS) in the file + corresponding to that virtual disk is set to zero. + @@ -2169,35 +2331,35 @@ requires the TSF to maintain logical separation between Guest VMs - except through the use of specific configurable methods. - The following actions could be considered for the management - functions in FMT: - Ability to configure inter-VM data sharing. + except through the use of specific configurable methods. + The following actions could be considered for the management + functions in FMT: + Ability to configure inter-VM data sharing. There are no auditable events foreseen. No dependencies. The VS shall provide the following mechanisms for transferring data between Guest VMs:<selectables linebreak="yes"><selectable id="fdp_vms_ext.1.1_1" >no mechanism</selectable><selectable id="fdp_vms_ext.1.1_2" >virtual networking</selectable><selectable id="fdp_vms_ext.1.1_4" ><assignable>other inter-VM data sharing mechanisms</assignable></selectable> </selectables>. - The evaluator shall examine the TSS to verify that it documents all inter-VM - communications mechanisms (as defined above), and explains how the TSF prevents the transfer of data - between VMs outside of the mechanisms listed in FDP_VMS_EXT.1.1. + The evaluator shall examine the TSS to verify that it documents all inter-VM + communications mechanisms (as defined above), and explains how the TSF prevents the transfer of data + between VMs outside of the mechanisms listed in FDP_VMS_EXT.1.1. - The evaluator shall examine the operational guidance to ensure that it documents how to configure all inter-VM - communications mechanisms, including how they are invoked and how they are disabled. - + The evaluator shall examine the operational guidance to ensure that it documents how to configure all inter-VM + communications mechanisms, including how they are invoked and how they are disabled. + - - The evaluator shall perform the following tests for each documented inter-VM communications channel: - + + The evaluator shall perform the following tests for each documented inter-VM communications channel: + Create two VMs without specifying any communications mechanism or overriding - the default configuration. Test that the two VMs cannot communicate through the mechanisms selected in FDP_VMS_EXT.1.1.Create two new VMs, overriding the default configuration to allow communications through a - channel selected in FDP_VMS_EXT.1.1.Test that communications can be passed between the VMs through the channel.Create two new VMs, the first with the inter-VM communications channel currently being - tested enabled, and the second with the inter-VM communications channel currently - being tested disabled.Test that communications cannot be passed between the VMs through the channel.As an Administrator, enable inter-VM communications between the VMs on the second VM.Test that communications can be passed through the inter-VM channel.As an Administrator again, disable inter-VM communications between the two VMs.Test that communications can no longer be passed through the channel. - FDP_VMS_EXT.1.2 is met if communication is unsuccessful in step (b). - FDP_VMS_EXT.1.3 is met if communication is successful in step (d) and unsuccessful in step (f). - + the default configuration. Test that the two VMs cannot communicate through the mechanisms selected in FDP_VMS_EXT.1.1.Create two new VMs, overriding the default configuration to allow communications through a + channel selected in FDP_VMS_EXT.1.1.Test that communications can be passed between the VMs through the channel.Create two new VMs, the first with the inter-VM communications channel currently being + tested enabled, and the second with the inter-VM communications channel currently + being tested disabled.Test that communications cannot be passed between the VMs through the channel.As an Administrator, enable inter-VM communications between the VMs on the second VM.Test that communications can be passed through the inter-VM channel.As an Administrator again, disable inter-VM communications between the two VMs.Test that communications can no longer be passed through the channel. + FDP_VMS_EXT.1.2 is met if communication is unsuccessful in step (b). + FDP_VMS_EXT.1.3 is met if communication is successful in step (d) and unsuccessful in step (f). + @@ -2211,20 +2373,20 @@ The VS shall ensure that no Guest VM is able to read or transfer data to or from another Guest VM except through the mechanisms listed in FDP_VMS_EXT.1.1. - The fundamental requirement of a Virtualization System is the ability to enforce separation between - information domains implemented as Virtual Machines and Virtual Networks. The intent of this - requirement is to ensure that VMs, VMMs, and the VS as a whole is implemented with - this fundamental requirement in mind. - The ST author should select “no mechanism” in the unlikely event that the VS implements no mechanisms for - transferring data between Guest VMs. Otherwise, the ST author should select “virtual networking” - and identify all other mechanisms through which data can be transferred between Guest VMs. - Examples of non-network inter-VM sharing mechanisms are:User interface-based mechanisms, such as copy-paste and drag-and-dropShared virtual or physical devicesAPI-based mechanisms such as Hypercalls - For data transfer mechanisms implemented in terms of Hypercall functions, FDP_VMS_EXT.1.3 is met if - FPT_HCL_EXT.1.1 is met for those Hypercall functions (Hypercall function parameters are checked). - For data transfer mechanisms that use shared physical devices, FDP_VMS_EXT.1.3 is met if the device is - listed in and meets FDP_PPR_EXT.1.1 (VM access to the physical device is configurable). - For data transfer mechanisms that use virtual networking, FDP_VMS_EXT.1.3 is met if FDP_VNC_EXT.1.1 - is met (VM access to virtual networks is configurable). + The fundamental requirement of a Virtualization System is the ability to enforce separation between + information domains implemented as Virtual Machines and Virtual Networks. The intent of this + requirement is to ensure that VMs, VMMs, and the VS as a whole is implemented with + this fundamental requirement in mind. + The ST author should select “no mechanism” in the unlikely event that the VS implements no mechanisms for + transferring data between Guest VMs. Otherwise, the ST author should select “virtual networking” + and identify all other mechanisms through which data can be transferred between Guest VMs. + Examples of non-network inter-VM sharing mechanisms are:User interface-based mechanisms, such as copy-paste and drag-and-dropShared virtual or physical devicesAPI-based mechanisms such as Hypercalls + For data transfer mechanisms implemented in terms of Hypercall functions, FDP_VMS_EXT.1.3 is met if + FPT_HCL_EXT.1.1 is met for those Hypercall functions (Hypercall function parameters are checked). + For data transfer mechanisms that use shared physical devices, FDP_VMS_EXT.1.3 is met if the device is + listed in and meets FDP_PPR_EXT.1.1 (VM access to the physical device is configurable). + For data transfer mechanisms that use virtual networking, FDP_VMS_EXT.1.3 is met if FDP_VNC_EXT.1.1 + is met (VM access to virtual networks is configurable). @@ -2233,36 +2395,36 @@ requires the TSF to support the configuration of virtual networking between Guest VMs. The following actions could be considered for the management - functions in FMT: - Ability to configure virtual networks including VM. + functions in FMT: + Ability to configure virtual networks including VM. The following actions should be auditable if FAU_GEN Security audit data - generation is included in the PP/ST: - Successful and failed attempts to connect VMs to virtual and physical - networking components.Security policy violations.Administrator configuration of inter-VM communications channels between - VMs. + generation is included in the PP/ST: + Successful and failed attempts to connect VMs to virtual and physical + networking components.Security policy violations.Administrator configuration of inter-VM communications channels between + VMs. FDP_VMS_EXT.1 VM Separation - FMT_SMR.1 Security Roles + FMT_SMR.1 Security Roles The TSF shall allow Administrators to configure virtual networking components to connect VMs to each other and to physical networks. - The evaluator shall examine the TSS (or a proprietary annex) to verify that it describes the mechanism - by which virtual network traffic is ensured to be visible only to Guest VMs configured to be on that virtual network. + The evaluator shall examine the TSS (or a proprietary annex) to verify that it describes the mechanism + by which virtual network traffic is ensured to be visible only to Guest VMs configured to be on that virtual network. - The evaluator must ensure that the Operational Guidance describes how - to create virtualized networks and connect VMs to each other and to physical networks. - + The evaluator must ensure that the Operational Guidance describes how + to create virtualized networks and connect VMs to each other and to physical networks. + The evaluator shall assume the role of the Administrator and attempt to configure a VM to - connect to a network component. The evaluator shall verify that the attempt is successful. The - evaluator shall then assume the role of an unprivileged user and attempt the same connection. - If the attempt fails, or there is no way for an unprivileged user to configure VM network - connections, the requirement is met. + connect to a network component. The evaluator shall verify that the attempt is successful. The + evaluator shall then assume the role of an unprivileged user and attempt the same connection. + If the attempt fails, or there is no way for an unprivileged user to configure VM network + connections, the requirement is met. The evaluator shall assume the role of the Administrator and attempt to configure a VM to connect - to a physical network. The evaluator shall verify that the attempt is successful. The - evaluator shall then assume the role of an unprivileged user and make the same attempt. - If the attempt fails, or there is no way for an unprivileged user to configure VM network - connections, the requirement is met. + to a physical network. The evaluator shall verify that the attempt is successful. The + evaluator shall then assume the role of an unprivileged user and make the same attempt. + If the attempt fails, or there is no way for an unprivileged user to configure VM network + connections, the requirement is met. @@ -2270,10 +2432,10 @@ The TSF shall ensure that network traffic visible to a Guest VM on a virtual network--or virtual segment of a physical network--is visible only to Guest VMs configured to be on that virtual network or segment. - Virtual networks must be separated from one another to provide isolation commensurate with that provided by - physically separate networks. It must not be possible for data to cross between properly configured - virtual networks regardless of whether the traffic originated from a local Guest VM or a remote host. - Unprivileged users must not be able to connect VMs to each other or to external networks. + Virtual networks must be separated from one another to provide isolation commensurate with that provided by + physically separate networks. It must not be possible for data to cross between properly configured + virtual networks regardless of whether the traffic originated from a local Guest VM or a remote host. + Unprivileged users must not be able to connect VMs to each other or to external networks. Successful and failed attempts to connect VMs to virtual and physical networking components. @@ -2308,46 +2470,46 @@ requires the TSF to lock an administrator account when an excessive number of failed authentication attempts - have been observed until some restorative event occurs to enable the account. + have been observed until some restorative event occurs to enable the account. The following actions could be considered for the management functions - in FMT: - Ability to configure lockout policy through unsuccessful authentication attempts. - The following actions should be auditable if FAU_GEN Security audit data generation is - included in the PP/ST: - Unsuccessful login attempts limit is met or exceeded. + in FMT: + Ability to configure lockout policy through unsuccessful authentication attempts. + The following actions should be auditable if FAU_GEN Security audit data generation is + included in the PP/ST: + Unsuccessful login attempts limit is met or exceeded. FIA_UIA_EXT.1 Administrator Identification and Authentication - FMT_SMR.1 Security Roles + FMT_SMR.1 Security Roles The TSF shall detect when<selectables linebreak="yes"><selectable id="fia_afl_ext.1.1_2" ><assignable>a positive integer number</assignable></selectable><selectable id="fia_afl_ext.1.1_3">an administrator configurable positive integer within a<assignable>range of acceptable values</assignable></selectable> </selectables>unsuccessful authentication attempts occur related to Administrators attempting to authenticate remotely using<selectables ><selectable id="fia_afl_ext.1.1_5" >username and password</selectable><selectable id="fia_afl_ext.1.1_6" >username and PIN</selectable> </selectables>. - - The evaluator will set an Administrator-configurable threshold n for failed attempts, or note - the ST-specified assignment. - - The evaluator will attempt to authenticate remotely with the credential n-1 times. The - evaluator will then attempt to authenticate - using a good credential and verify that authentication is successful. + + The evaluator will set an Administrator-configurable threshold n for failed attempts, or note + the ST-specified assignment. + + The evaluator will attempt to authenticate remotely with the credential n-1 times. The + evaluator will then attempt to authenticate + using a good credential and verify that authentication is successful. The evaluator will make n attempts to authenticate using a bad credential. The evaluator - will then attempt to authenticate using a good credential and verify that the attempt is - unsuccessful. Note that the authentication attempts and lockouts must also be logged as - specified in FAU_GEN.1. + will then attempt to authenticate using a good credential and verify that the attempt is + unsuccessful. Note that the authentication attempts and lockouts must also be logged as + specified in FAU_GEN.1. - - After reaching the limit for unsuccessful authentication attempts the evaluator will proceed - as follows: - + + After reaching the limit for unsuccessful authentication attempts the evaluator will proceed + as follows: + If the Administrator action selection in FIA_AFL_EXT.1.2 is selected, then the evaluator - will confirm by testing that following the operational guidance and performing each action - specified in the ST to re-enable the remote Administrator’s access results in successful - access (when using valid credentials for that Administrator). + will confirm by testing that following the operational guidance and performing each action + specified in the ST to re-enable the remote Administrator’s access results in successful + access (when using valid credentials for that Administrator). If the time period selection in FIA_AFL_EXT.1.2 is selected, the evaluator will wait for - just less than the time period configured and show that an authentication attempt using - valid credentials does not result in successful access. The evaluator will then wait until - just after the time period configured and show that an authentication attempt using valid - credentials results in successful access. + just less than the time period configured and show that an authentication attempt using + valid credentials does not result in successful access. The evaluator will then wait until + just after the time period configured and show that an authentication attempt using valid + credentials results in successful access. @@ -2355,12 +2517,12 @@ When the defined number of unsuccessful authentication attempts has been met, the TSF shall:<selectables ><selectable id="fia_afl_ext.1.2_1">prevent the offending Administrator from successfully establishing a remote session using any authentication method that involves a password or PIN until<assignable>action to unlock</assignable>is taken by an Administrator</selectable><selectable id="fia_afl_ext.1.2_3" >prevent the offending Administrator from successfully establishing a remote session using any authentication method that involves a password or PIN until an Administrator-defined time period has elapsed</selectable> </selectables> The action to be taken shall be populated in the selection of the ST - and defined in the Administrator guidance. - This requirement applies to a defined number of successive unsuccessful remote password or PIN-based - authentication attempts and does not apply to local Administrative access. Compliant TOEs may optionally - include cryptographic and local authentication failures in the number of - unsuccessful authentication attempts. - + and defined in the Administrator guidance. + This requirement applies to a defined number of successive unsuccessful remote password or PIN-based + authentication attempts and does not apply to local Administrative access. Compliant TOEs may optionally + include cryptographic and local authentication failures in the number of + unsuccessful authentication attempts. + Unsuccessful login attempts limit is met or exceeded. @@ -2371,38 +2533,38 @@ requires the TSF to ensure that administrator passwords meet a - defined password policy. - The following actions could be considered for the management functions - in FMT: - Ability to configure Administrator password policy, including - the ability to change default authorization factors. + defined password policy. + The following actions could be considered for the management functions + in FMT: + Ability to configure Administrator password policy, including + the ability to change default authorization factors. There are no auditable events foreseen. FIA_UIA_EXT.1 Administrator Identification and Authentication The TSF shall provide the following password management capabilities for administrative passwords: <h:ol><h:li>Passwords shall be able to be composed of any combination of upper and lower case characters, digits, and the following special characters:<selectables ><selectable id="fia_pmg_ext.1.1_1" >“!”</selectable><selectable id="fia_pmg_ext.1.1_2" >“@”</selectable><selectable id="fia_pmg_ext.1.1_3" >“#”</selectable><selectable id="fia_pmg_ext.1.1_4" >“$”</selectable><selectable id="fia_pmg_ext.1.1_5" >“%”</selectable><selectable id="fia_pmg_ext.1.1_6" >“^”</selectable><selectable id="fia_pmg_ext.1.1_7" >“& ”</selectable><selectable id="fia_pmg_ext.1.1_8" >“*”</selectable><selectable id="fia_pmg_ext.1.1_9" >“(“</selectable><selectable id="fia_pmg_ext.1.1_10" >“)”</selectable><selectable id="fia_pmg_ext.1.1_12" ><assignable>other characters</assignable></selectable> </selectables></h:li><h:li>Minimum password length shall be configurable</h:li><h:li>Passwords of at least 15 characters in length shall be supported</h:li></h:ol> - This SFR is included in the ST if the ST Author selects ‘authentication based on username and password’ - in FIA_UAU.5.1. - The ST author selects the special characters that are supported by the TOE; they may - optionally list additional special characters supported using the assignment. “Administrative - passwords” refers to passwords used by administrators to gain access to the Management Subsystem. + This SFR is included in the ST if the ST Author selects ‘authentication based on username and password’ + in FIA_UAU.5.1. + The ST author selects the special characters that are supported by the TOE; they may + optionally list additional special characters supported using the assignment. “Administrative + passwords” refers to passwords used by administrators to gain access to the Management Subsystem. - The evaluator shall examine the operational guidance to determine that it provides guidance to - security administrators in the composition of strong passwords, and that it provides instructions - on setting the minimum password length. - + The evaluator shall examine the operational guidance to determine that it provides guidance to + security administrators in the composition of strong passwords, and that it provides instructions + on setting the minimum password length. + - - The evaluator shall also perform the following test. - - The evaluator shall compose passwords that either meet the requirements, or fail to meet the - requirements, in some way. For each password, the evaluator shall verify that the TOE supports - the password. While the evaluator is not required (nor is it feasible) to test all possible - combinations of passwords, the evaluator shall ensure that all characters, rule - characteristics, and a minimum length listed in the requirement are supported, and justify the - subset of those characters chosen for testing. + + The evaluator shall also perform the following test. + + The evaluator shall compose passwords that either meet the requirements, or fail to meet the + requirements, in some way. For each password, the evaluator shall verify that the TOE supports + the password. While the evaluator is not required (nor is it feasible) to test all possible + combinations of passwords, the evaluator shall ensure that all characters, rule + characteristics, and a minimum length listed in the requirement are supported, and justify the + subset of those characters chosen for testing. @@ -2411,71 +2573,71 @@ - If "directory-based" is selected anywhere in FIA_UAU.5.1 then - "Ability to configure name/address of directory server to bind with" must be selected in the Client or Server module - management function table. + If "directory-based" is selected anywhere in FIA_UAU.5.1 then + "Ability to configure name/address of directory server to bind with" must be selected in the Client or Server module + management function table. The TSF shall provide the following authentication mechanisms:<selectables linebreak="yes"><selectable id="sel-uau-pwd"><selectables><selectable id="fia_uau.5.1_1" >local</selectable><selectable id="sel-uau-pwd-dirbased" >directory-based</selectable></selectables>authentication based on username and password</selectable><selectable id="fia_uau.5.1_2" >authentication based on username and a PIN that releases an asymmetric key stored in OE-protected storage</selectable><selectable id="sel-uau-x509"><selectables><selectable id="fia_uau.5.1_3" >local</selectable><selectable id="sel-uau-x509-dirbased" >directory-based</selectable></selectables>authentication based on X.509 certificates</selectable><selectable id="sel-uau-ssh"><selectables><selectable id="fia_uau.5.1_4" >local</selectable><selectable id="sel-uau-ssh-dirbased" >directory-based</selectable></selectables>authentication based on an SSH public key credential</selectable> </selectables>to support Administrator authentication. - Selection of ‘authentication based on username and password’ requires that - FIA_PMG_EXT.1 be included in the ST. This also requires that the ST include a management function for - password management. If the ST author selects ‘authentication based on an SSH public-key credential’, - the TSF shall be validated against the Functional Package for Secure Shell. The ST must include - FIA_X509_EXT.1 and FIA_X509_EXT.2 if 'authentication based on X.509 certificates' is selected. - PINs used to access OE-protected storage are set and managed by the OE-protected storage mechanism. Thus - requirements on PIN management are outside the scope of the TOE. + Selection of ‘authentication based on username and password’ requires that + FIA_PMG_EXT.1 be included in the ST. This also requires that the ST include a management function for + password management. If the ST author selects ‘authentication based on an SSH public-key credential’, + the TSF shall be validated against the Functional Package for Secure Shell. The ST must include + FIA_X509_EXT.1 and FIA_X509_EXT.2 if 'authentication based on X.509 certificates' is selected. + PINs used to access OE-protected storage are set and managed by the OE-protected storage mechanism. Thus + requirements on PIN management are outside the scope of the TOE. - - If ‘username and password authentication‘ is selected, the evaluator will configure the VS with a - known username and password and conduct the following tests: - + + If ‘username and password authentication‘ is selected, the evaluator will configure the VS with a + known username and password and conduct the following tests: + The evaluator will attempt to authenticate to the VS using the known username and password. - The evaluator will ensure that the authentication attempt is successful. + The evaluator will ensure that the authentication attempt is successful. The evaluator will attempt to authenticate to the VS using the known username but an incorrect - password. The evaluator will ensure that the authentication attempt is unsuccessful. + password. The evaluator will ensure that the authentication attempt is unsuccessful. - - If ‘username and PIN that releases an asymmetric key‘ is selected, the evaluator will examine the TSS for - guidance on supported protected storage and will then configure the TOE or OE to establish a PIN - which enables release of the asymmetric key from the protected storage (such as a TPM, a hardware - token, or isolated execution environment) with which the VS can interface. The evaluator will then - conduct the following tests: - + + If ‘username and PIN that releases an asymmetric key‘ is selected, the evaluator will examine the TSS for + guidance on supported protected storage and will then configure the TOE or OE to establish a PIN + which enables release of the asymmetric key from the protected storage (such as a TPM, a hardware + token, or isolated execution environment) with which the VS can interface. The evaluator will then + conduct the following tests: + The evaluator will attempt to authenticate to the VS using the known user name and PIN. The - evaluator will ensure that the authentication attempt is successful. + evaluator will ensure that the authentication attempt is successful. The evaluator will attempt to authenticate to the VS using the known user name but an incorrect - PIN. The evaluator will ensure that the authentication attempt is unsuccessful. + PIN. The evaluator will ensure that the authentication attempt is unsuccessful. - - If ‘X.509 certificate authentication‘ is selected, the evaluator will generate an X.509v3 certificate for - an Administrator user with the Client Authentication Enhanced Key Usage field set. The evaluator - will provision the VS for authentication with the X.509v3 certificate. The evaluator will ensure - that the certificates are validated by the VS as per FIA_X509_EXT.1.1 and then conduct the - following tests: - - The evaluator will attempt to authenticate to the VS using the X.509v3 certificate. The - evaluator will ensure that the authentication attempt is successful. + + If ‘X.509 certificate authentication‘ is selected, the evaluator will generate an X.509v3 certificate for + an Administrator user with the Client Authentication Enhanced Key Usage field set. The evaluator + will provision the VS for authentication with the X.509v3 certificate. The evaluator will ensure + that the certificates are validated by the VS as per FIA_X509_EXT.1.1 and then conduct the + following tests: + + The evaluator will attempt to authenticate to the VS using the X.509v3 certificate. The + evaluator will ensure that the authentication attempt is successful. The evaluator will generate a second certificate identical to the first except for the public - key and any values derived from the public key. The evaluator will attempt to authenticate to - the VS with this certificate. The evaluator will ensure that the authentication attempt is - unsuccessful. + key and any values derived from the public key. The evaluator will attempt to authenticate to + the VS with this certificate. The evaluator will ensure that the authentication attempt is + unsuccessful. - - If ‘SSH public-key credential authentication‘ is selected, the evaluator shall generate a public-private - host key pair on the TOE using RSA or ECDSA, and a second public-private key pair on a remote - client. The evaluator shall provision the VS with the client public key for authentication over - SSH, and conduct the following tests: - + + If ‘SSH public-key credential authentication‘ is selected, the evaluator shall generate a public-private + host key pair on the TOE using RSA or ECDSA, and a second public-private key pair on a remote + client. The evaluator shall provision the VS with the client public key for authentication over + SSH, and conduct the following tests: + The evaluator will attempt to authenticate to the VS using a message signed by the client - private key that corresponds to provisioned client public key. The evaluator will ensure that - the authentication attempt is successful. - The evaluator will generate a second client key pair and will attempt to authenticate to the VS - with the private key over SSH without first provisioning the VS to support the new key pair. - The evaluator will ensure that the authentication attempt is unsuccessful. + private key that corresponds to provisioned client public key. The evaluator will ensure that + the authentication attempt is successful. + The evaluator will generate a second client key pair and will attempt to authenticate to the VS + with the private key over SSH without first provisioning the VS to support the new key pair. + The evaluator will ensure that the authentication attempt is unsuccessful. @@ -2489,26 +2651,26 @@ requires the TSF to ensure that all subjects attempting to perform TSF-mediated actions - are identified and authenticated prior to authorizing these actions to be performed. + are identified and authenticated prior to authorizing these actions to be performed. No specific management functions are identified. - The following actions should be auditable if FAU_GEN Security audit data - generation is included in the PP/ST: - Administrator authentication attempts.All use of the identification and authentication mechanism.Administrator session start time and end time. + The following actions should be auditable if FAU_GEN Security audit data + generation is included in the PP/ST: + Administrator authentication attempts.All use of the identification and authentication mechanism.Administrator session start time and end time. FIA_UAU.5 Multiple Authentication Mechanisms The TSF shall require Administrators to be successfully identified and authenticated using one of the methods in FIA_UAU.5 before allowing any TSF-mediated management function to be performed by that Administrator. Users do not have to authenticate, only Administrators need to authenticate. The evaluator shall examine the TSS to determine that it describes the logon - process for each logon method (local, remote (HTTPS, SSH, etc.)) supported for the product. - This description shall contain information pertaining to the credentials allowed/used, any - protocol transactions that take place, and what constitutes a “successful logon.” The evaluator - shall examine the operational guidance to determine that any necessary preparatory steps (e.g., - establishing credential material such as pre-shared keys, tunnels, certificates) to logging - in are described. For each supported login method, the evaluator shall ensure the operational - guidance provides clear instructions for successfully logging on. If configuration is necessary - to ensure the services provided before login are limited, the evaluator shall determine that the - operational guidance provides sufficient instruction on limiting the allowed services. + process for each logon method (local, remote (HTTPS, SSH, etc.)) supported for the product. + This description shall contain information pertaining to the credentials allowed/used, any + protocol transactions that take place, and what constitutes a “successful logon.” The evaluator + shall examine the operational guidance to determine that any necessary preparatory steps (e.g., + establishing credential material such as pre-shared keys, tunnels, certificates) to logging + in are described. For each supported login method, the evaluator shall ensure the operational + guidance provides clear instructions for successfully logging on. If configuration is necessary + to ensure the services provided before login are limited, the evaluator shall determine that the + operational guidance provides sufficient instruction on limiting the allowed services. @@ -2536,77 +2698,77 @@ defines how the TSF must validate X.509 certificates that are presented to it. The following actions could be considered for the management functions in FMT: - Configuration of action to take if unable to determine the validity of a certificate. + Configuration of action to take if unable to determine the validity of a certificate. The following actions should be auditable if FAU_GEN Security audit data - generation is included in the PP/ST: - Failure to validate a certificate. + generation is included in the PP/ST: + Failure to validate a certificate. FPT_STM.1 Reliable Time Stamps The TSF shall validate certificates in accordance with the following rules: <h:ul><h:li>RFC 5280 certificate validation and certificate path validation</h:li><h:li>The certificate path must terminate with a trusted certificate</h:li><h:li>The TOE shall validate a certificate path by ensuring the presence of the basicConstraints extension, that the CA flag is set to TRUE for all CA certificates, and that any path constraints are met.</h:li><h:li>The TSF shall validate that any CA certificate includes caSigning purpose in the key usage field</h:li><h:li>The TSF shall validate revocation status of the certificate using<selectables ><selectable id="fia_x509_ext.1.1_1" >OCSP as specified in RFC 6960</selectable><selectable id="fia_x509_ext.1.1_2" >a CRL as specified in RFC 5759</selectable><selectable id="fia_x509_ext.1.1_3" >an OCSP TLS Status Request Extension (OCSP stapling) as specified in RFC 6066</selectable><selectable id="fia_x509_ext.1.1_4" >OCSP TLS Multi-Certificate Status Request Extension (i.e., OCSP Multi-Stapling) as specified in RFC 6961</selectable> </selectables>. </h:li><h:li>The TSF shall validate the extendedKeyUsage field according to the following rules: <h:ul><h:li>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.</h:li><h:li>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 extendedKeyUsage field.</h:li><h:li>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.</h:li><h:li>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.</h:li></h:ul></h:li></h:ul> This SFR must be included in the ST if the selection for FPT_TUD_EXT.1.3 is “digital - signature mechanism,” if "certificate-based authentication of the remote peer" is - selected in FTP_ITC_EXT.1.1, or if "authentication based on X.509 certificates" - is selected in FIA_UAU.5.1. - FIA_X509_EXT.1.1 lists the rules for validating certificates. The ST author shall select whether revocation - status is verified using OCSP or CRLs. FIA_X509_EXT.2 requires that certificates are used for IPsec; - this use requires that the extendedKeyUsage rules are verified. Certificates may optionally be used - for SSH, TLS, and HTTPs and, if implemented, must be validated to contain the corresponding - extendedKeyUsage. - OCSP stapling and OCSP multi-stapling support only TLS server certificate validation. If other certificate - types are validated, either OCSP or CRL must be claimed. If OCSP is not supported the EKU provision - for checking the OCSP Signing purpose is met by default. - Regardless of the selection of TSF or TOE platform, the validation must result in a trusted root - CA certificate in a root store managed by the platform. - OCSP responses are signed using either the certificate’s issuer’s CA certificate or an OCSP certificate - issued to an OCSP responder delegated by that issuer to sign OCSP responses. A compliant TOE is able to - validate OCSP responses in either case, but the OCSP signing extended key usage purpose is only required - to be checked in OCSP certificates. - + signature mechanism,” if "certificate-based authentication of the remote peer" is + selected in FTP_ITC_EXT.1.1, or if "authentication based on X.509 certificates" + is selected in FIA_UAU.5.1. + FIA_X509_EXT.1.1 lists the rules for validating certificates. The ST author shall select whether revocation + status is verified using OCSP or CRLs. FIA_X509_EXT.2 requires that certificates are used for IPsec; + this use requires that the extendedKeyUsage rules are verified. Certificates may optionally be used + for SSH, TLS, and HTTPs and, if implemented, must be validated to contain the corresponding + extendedKeyUsage. + OCSP stapling and OCSP multi-stapling support only TLS server certificate validation. If other certificate + types are validated, either OCSP or CRL must be claimed. If OCSP is not supported the EKU provision + for checking the OCSP Signing purpose is met by default. + Regardless of the selection of TSF or TOE platform, the validation must result in a trusted root + CA certificate in a root store managed by the platform. + OCSP responses are signed using either the certificate’s issuer’s CA certificate or an OCSP certificate + issued to an OCSP responder delegated by that issuer to sign OCSP responses. A compliant TOE is able to + validate OCSP responses in either case, but the OCSP signing extended key usage purpose is only required + to be checked in OCSP 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. - - The evaluator shall examine the TSS to confirm that it describes the behavior of the TOE when a - connection cannot be established during the validity check of a certificate used in establishing - a trusted channel. If the requirement that the administrator is able to specify the default - action, then the evaluator shall ensure that the operational guidance contains instructions on how - this configuration action is performed. + The evaluator ensures the TSS also provides a description of the certificate path validation algorithm. + + The evaluator shall examine the TSS to confirm that it describes the behavior of the TOE when a + connection cannot be established during the validity check of a certificate used in establishing + a trusted channel. If the requirement that the administrator is able to specify the default + action, then the evaluator shall ensure that the operational guidance contains instructions on how + this configuration action is performed. 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, andby 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. - + 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, andby 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. + The evaluator shall demonstrate that validating an expired certificate results in the - function failing. + function failing. 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 a test is performed for each method. The evaluator has to - only test one up in the trust chain (future revisions may require to ensure the validation - is done up the entire chain). The evaluator shall ensure that a valid certificate is used, - and that the validation function succeeds. The evaluator shall then attempt the test with - a certificate that will be revoked (for each method chosen in the selection) and verify - that the validation function fails. - If any OCSP option is selected, the evaluator shall present a delegated OCSP 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 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. + on whether CRL, OCSP, OCSP stapling, or OCSP multi-stapling is selected; if multiple + methods are selected, then a test is performed for each method. The evaluator has to + only test one up in the trust chain (future revisions may require to ensure the validation + is done up the entire chain). The evaluator shall ensure that a valid certificate is used, + and that the validation function succeeds. The evaluator shall then attempt the test with + a certificate that will be revoked (for each method chosen in the selection) and verify + that the validation function fails. + If any OCSP option is selected, the evaluator shall present a delegated OCSP 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 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. (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.. + 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.. (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 5 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 5, 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. - + replace the intermediate certificate in the certificate chain for Test 5 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 5, 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. + @@ -2614,7 +2776,7 @@ The TSF shall only treat a certificate as a CA certificate 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. + restricts the certificates that may be added as trusted CA certificates. Failure to validate a certificate. @@ -2626,49 +2788,49 @@ - requires the TSF to identify the functions for which it uses X.509 - certificates for authentication + requires the TSF to identify the functions for which it uses X.509 + certificates for authentication The following actions could be considered for the management functions in FMT: - Configuration of TSF behavior when certificate revocation status - cannot be determined. + Configuration of TSF behavior when certificate revocation status + cannot be determined. There are no auditable events foreseen. FIA_X509_EXT.1 X.509 Certificate Validation - FTP_ITC_EXT.1 Trusted Channel Communications - If "" is selected then - "Ability to configure action taken if unable to determine the validity of a certificate" in the Client or Server module - management function table must also be selected. + FTP_ITC_EXT.1 Trusted Channel Communications + If "" is selected then + "Ability to configure action taken if unable to determine the validity of a certificate" in the Client or Server module + management function table must also be selected. The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for<selectables ><selectable id="sel-x509-2-ipsec" >IPsec</selectable><selectable id="sel-x509-2-tls" >TLS</selectable><selectable id="sel-x509-2-https" >HTTPS</selectable><selectable id="sel-x509-2-ssh" >SSH</selectable><selectable id="sel-x5092-signed-updates" >code signing for system software updates</selectable><selectable id="fia_x509_ext.2.1_2" ><assignable>other uses</assignable></selectable> </selectables> This SFR must be included in the ST if the selection for FPT_TUD_EXT.1.3 is “digital - signature mechanism,” if "certificate-based authentication of the remote peer" is - selected in FTP_ITC_EXT.1, or if "authentication based on X.509 certificates" - is selected in FIA_UAU.5.1. - This SFR must also be included in the ST if X.509 certificate-based authentication is used for "other uses" - as listed in the assignment in FIA_X509_EXT.2.1. + signature mechanism,” if "certificate-based authentication of the remote peer" is + selected in FTP_ITC_EXT.1, or if "authentication based on X.509 certificates" + is selected in FIA_UAU.5.1. + This SFR must also be included in the ST if X.509 certificate-based authentication is used for "other uses" + as listed in the assignment in FIA_X509_EXT.2.1. - The evaluator shall check the TSS to ensure that it describes how the - TOE chooses which certificates to use, and any necessary instructions in the - administrative guidance for configuring the operating environment so that the TOE - can use the certificates. - The evaluator shall examine the TSS to confirm that it describes the behavior of the - TOE when a connection cannot be established during the validity check of a - certificate used in establishing a trusted channel. If the requirement states that the administrator - specifies the default action, then the evaluator shall ensure that the operational guidance contains - instructions on how this configuration action is performed. + The evaluator shall check the TSS to ensure that it describes how the + TOE chooses which certificates to use, and any necessary instructions in the + administrative guidance for configuring the operating environment so that the TOE + can use the certificates. + The evaluator shall examine the TSS to confirm that it describes the behavior of the + TOE when a connection cannot be established during the validity check of a + certificate used in establishing a trusted channel. If the requirement states that the administrator + specifies the default action, then the evaluator shall ensure that the operational guidance contains + instructions on how this configuration action is performed. The evaluator shall demonstrate that using a certificate without a valid certification path - results in the function failing. Using the administrative guidance, the evaluator shall - then load a certificate or certificates needed to validate the certificate to be used in - the function, and demonstrate that the function succeeds. The evaluator then shall delete - one of the certificates, and show that the function fails. - The evaluator shall demonstrate that using a valid certificate requires that certificate - validation checking be performed in at least some part by communicating with a non-TOE - IT entity. The evaluator shall then manipulate the environment so that the TOE is unable - to verify the validity of the certificate, and observe that the action selected in - FIA_X509_EXT.2.2 is performed. If the selected action is administrator-configurable, then - the evaluator shall follow the operational guidance to determine that all supported - administrator-configurable options behave in their documented manner. + results in the function failing. Using the administrative guidance, the evaluator shall + then load a certificate or certificates needed to validate the certificate to be used in + the function, and demonstrate that the function succeeds. The evaluator then shall delete + one of the certificates, and show that the function fails. + The evaluator shall demonstrate that using a valid certificate requires that certificate + validation checking be performed in at least some part by communicating with a non-TOE + IT entity. The evaluator shall then manipulate the environment so that the TOE is unable + to verify the validity of the certificate, and observe that the action selected in + FIA_X509_EXT.2.2 is performed. If the selected action is administrator-configurable, then + the evaluator shall follow the operational guidance to determine that all supported + administrator-configurable options behave in their documented manner. @@ -2676,15 +2838,15 @@ When the TSF cannot establish a connection to determine the validity of a certificate, the TSF shall<selectables ><selectable id="sel-x509-adminset" >allow the administrator to choose whether to accept the certificate in these cases</selectable><selectable id="fia_x509_ext.2.2_1" >accept the certificate</selectable><selectable id="fia_x509_ext.2.2_2" >not accept the certificate</selectable> </selectables>. - - Often a connection must be established to check the revocation status of a - certificate - either to download a CRL or to perform a lookup using OCSP. The selection is used to - describe the behavior in the event that such a connection cannot be established (for example, due to - a network error). If the TOE has determined the certificate valid according to all other rules in - FIA_X509_EXT.1, the behavior indicated in the selection shall determine the validity. The TOE must - not accept the certificate if it fails any of the other validation rules in FIA_X509_EXT.1. If the - administrator-configured option is selected by the ST Author, the ST Author must ensure that this is - also defined as a management function that is provided by the TOE. + + Often a connection must be established to check the revocation status of a + certificate - either to download a CRL or to perform a lookup using OCSP. The selection is used to + describe the behavior in the event that such a connection cannot be established (for example, due to + a network error). If the TOE has determined the certificate valid according to all other rules in + FIA_X509_EXT.1, the behavior indicated in the selection shall determine the validity. The TOE must + not accept the certificate if it fails any of the other validation rules in FIA_X509_EXT.1. If the + administrator-configured option is selected by the ST Author, the ST Author must ensure that this is + also defined as a management function that is provided by the TOE. @@ -2697,47 +2859,47 @@ - requires the TSF to separate its management and operational networks through a defined - mechanism. + requires the TSF to separate its management and operational networks through a defined + mechanism. No specific management functions are identified. There are no auditable events foreseen. No dependencies. The TSF shall support the separation of management and operational network traffic through<selectables ><selectable id="fmt_smo_ext.1.1_1" >separate physical networks</selectable><selectable id="fmt_smo_ext.1.1_2" >separate logical networks</selectable><selectable id="fmt_smo_ext.1.1_3" >trusted channels as defined in FTP_ITC_EXT.1</selectable><selectable id="fmt_smo_ext.1.1_4" >data encryption using an algorithm specified in FCS_COP.1/UDE</selectable> </selectables>. - Management communications must be separate from user workload communications. Administrative - network traffic—including communications between physical hosts concerning load balancing, audit data, - VM startup and shutdown—must be isolated from guest operational networks. For purposes of this requirement, - management traffic also includes VMs transmitted over management networks whether for backup, live migration, - or deployment. - “Separate physical networks” refers to using separate physical interfaces and cables to isolate management and operational networks from - each other. - “Separate logical networks” refers to using logical networking constructs, such as separate IP spaces or virtual networks to isolate traffic - across general-purpose networking ports. - Management and operational networks are kept separate within the - hosts using separate virtualized networking components. - If the ST author selects “trusted channels...” then the protocols used for network separation must be - selected in FTP_ITC_EXT.1. - The ST author selects "data encryption..." if, for example, the TOE encrypts VMs as data blobs for backup, storage, - deployment, or live migration, and does not send the data through a tunnel. - If the ST author selects "data encryption..." then the algorithms and key sizes must be selected in FCS_COP.1/UDE. - The ST author should select as many mechanisms as apply. - + Management communications must be separate from user workload communications. Administrative + network traffic—including communications between physical hosts concerning load balancing, audit data, + VM startup and shutdown—must be isolated from guest operational networks. For purposes of this requirement, + management traffic also includes VMs transmitted over management networks whether for backup, live migration, + or deployment. + “Separate physical networks” refers to using separate physical interfaces and cables to isolate management and operational networks from + each other. + “Separate logical networks” refers to using logical networking constructs, such as separate IP spaces or virtual networks to isolate traffic + across general-purpose networking ports. + Management and operational networks are kept separate within the + hosts using separate virtualized networking components. + If the ST author selects “trusted channels...” then the protocols used for network separation must be + selected in FTP_ITC_EXT.1. + The ST author selects "data encryption..." if, for example, the TOE encrypts VMs as data blobs for backup, storage, + deployment, or live migration, and does not send the data through a tunnel. + If the ST author selects "data encryption..." then the algorithms and key sizes must be selected in FCS_COP.1/UDE. + The ST author should select as many mechanisms as apply. + The evaluator shall examine the TSS to verify that it describes how management and - operational traffic is separated. + operational traffic is separated. - The evaluator shall examine the operational guidance to verify that it details how to configure the - VS to keep Management and Operational traffic separate. - + The evaluator shall examine the operational guidance to verify that it details how to configure the + VS to keep Management and Operational traffic separate. + - The evaluator shall configure the TOE as documented in the guidance. - If separation is logical, then the evaluator shall capture packets on the management network. If plaintext Guest network traffic is - detected, the requirement is not met. - If separation uses trusted channels, then the evaluator shall capture packets on the network over which traffic is tunneled. - If plaintext Guest network traffic is detected, the requirement is not met. - If data encryption is used, then the evaluator shall capture packets on the network over which the data is sent - while a VM or other large data structure is being transmitted. If plaintext VM contents are detected, the - requirement is not met. + The evaluator shall configure the TOE as documented in the guidance. + If separation is logical, then the evaluator shall capture packets on the management network. If plaintext Guest network traffic is + detected, the requirement is not met. + If separation uses trusted channels, then the evaluator shall capture packets on the network over which traffic is tunneled. + If plaintext Guest network traffic is detected, the requirement is not met. + If data encryption is used, then the evaluator shall capture packets on the network over which the data is sent + while a VM or other large data structure is being transmitted. If plaintext VM contents are detected, the + requirement is not met. @@ -2794,24 +2956,24 @@ The TSF shall ensure that device drivers for physical devices are isolated from the VMM and all other domains. In order to function on physical hardware, the VMM must have access to the device - drivers for the physical platform on which it runs. These drivers are often written by third parties, - and yet are effectively a part of the VMM. Thus the integrity of the VMM in part depends on the quality - of third party code that the virtualization vendor has no control over. By encapsulating these drivers - within one or more dedicated driver domains (e.g., Service VM or VMs) the damage of a driver failure or - vulnerability can be contained within the domain, and would not compromise the VMM. When driver domains - have exclusive access to a physical device, hardware isolation mechanisms, such as Intel's VT-d, AMD's - Input/Output Memory Management Unit (IOMMU), or ARM's System Memory Management Unit (MMU) should be used - to ensure that operations performed by Direct Memory Access (DMA) hardware are properly constrained. + drivers for the physical platform on which it runs. These drivers are often written by third parties, + and yet are effectively a part of the VMM. Thus the integrity of the VMM in part depends on the quality + of third party code that the virtualization vendor has no control over. By encapsulating these drivers + within one or more dedicated driver domains (e.g., Service VM or VMs) the damage of a driver failure or + vulnerability can be contained within the domain, and would not compromise the VMM. When driver domains + have exclusive access to a physical device, hardware isolation mechanisms, such as Intel's VT-d, AMD's + Input/Output Memory Management Unit (IOMMU), or ARM's System Memory Management Unit (MMU) should be used + to ensure that operations performed by Direct Memory Access (DMA) hardware are properly constrained. The evaluator shall examine the TSS documentation to verify that it describes the - mechanism used for device driver isolation. If the TSS document indicates that a - hardware isolation mechanism is used, the evaluator shall verify that the TSS - documentation enumerates the hardware-isolated DMA-capable devices, and that it also provides a - complete list of the accessible targets for memory transactions for each of those DMA-capable - devices. (An example of information that might be included in the TSS documentation: - a listing of all pages belonging to the driver domain, the identification of a subset of the driver - domain's pages that the driver domain has permitted the device access to, or the identification of a - dedicated area of memory reserved for the device or driver domain). + mechanism used for device driver isolation. If the TSS document indicates that a + hardware isolation mechanism is used, the evaluator shall verify that the TSS + documentation enumerates the hardware-isolated DMA-capable devices, and that it also provides a + complete list of the accessible targets for memory transactions for each of those DMA-capable + devices. (An example of information that might be included in the TSS documentation: + a listing of all pages belonging to the driver domain, the identification of a subset of the driver + domain's pages that the driver domain has permitted the device access to, or the identification of a + dedicated area of memory reserved for the device or driver domain). @@ -2820,47 +2982,47 @@ requires the TSF to prevent Guest VMs from accessing virtual devices - that it is not configured to have access to. + that it is not configured to have access to. No specific management functions are identified. There are no auditable events foreseen. FPT_VDP_EXT.1 Virtual Device Parameters The TSF shall prevent Guest VMs from accessing virtual device interfaces that are not present in the VM’s current virtual hardware configuration. The virtualized hardware abstraction implemented by a particular VS might include the - virtualized interfaces for many different devices. Sometimes these devices are not present in a - particular instantiation of a VM. The interface for devices not present must not be accessible by the - VM. - Such interfaces include memory buffers, PCI Bus interfaces, and processor I/O ports. - The purpose of this requirement is to reduce the attack surface of the VMM by blocking access to unused interfaces. - - + virtualized interfaces for many different devices. Sometimes these devices are not present in a + particular instantiation of a VM. The interface for devices not present must not be accessible by the + VM. + Such interfaces include memory buffers, PCI Bus interfaces, and processor I/O ports. + The purpose of this requirement is to reduce the attack surface of the VMM by blocking access to unused interfaces. + + requires the TSF to identify the execution environment-based - protection mechanisms that it can use for self-protection. + protection mechanisms that it can use for self-protection. No specific management functions are identified. There are no auditable events foreseen. No dependencies. The TSF shall take advantage of execution environment-based vulnerability mitigation mechanisms supported by the Platform such as:<selectables linebreak="yes"><selectable id="fpt_eem_ext.1.1_1" >Address space randomization</selectable><selectable id="fpt_eem_ext.1.1_2" >Memory execution protection (e.g., DEP)</selectable><selectable id="fpt_eem_ext.1.1_3" >Stack buffer overflow protection</selectable><selectable id="fpt_eem_ext.1.1_4" >Heap corruption detection</selectable><selectable id="fpt_eem_ext.1.1_6" ><assignable>other mechanisms</assignable></selectable><selectable id="fpt_eem_ext.1.1_7" >No mechanisms</selectable> </selectables> - Processor manufacturers, compiler developers, 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. Software can often take advantage of these mechanisms - by using APIs provided by the operating system or by enabling the mechanism through compiler or linker - options. - This requirement does not mandate that these protections be enabled throughout the Virtualization - System—only that they be enabled where they have likely impact. For example, code that receives and - processes user input should take advantage of these mechanisms. - For the selection, the ST author selects the supported mechanisms and uses the assignment to include - mechanisms not listed in the selection, if any. + Processor manufacturers, compiler developers, 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. Software can often take advantage of these mechanisms + by using APIs provided by the operating system or by enabling the mechanism through compiler or linker + options. + This requirement does not mandate that these protections be enabled throughout the Virtualization + System—only that they be enabled where they have likely impact. For example, code that receives and + processes user input should take advantage of these mechanisms. + For the selection, the ST author selects the supported mechanisms and uses the assignment to include + mechanisms not listed in the selection, if any. The evaluator shall examine the TSS to ensure that it states, for each platform - listed in the ST, the execution environment-based vulnerability mitigation - mechanisms used by the TOE on that platform. The evaluator shall ensure that the - lists correspond to what is specified in FPT_EEM_EXT.1.1. + listed in the ST, the execution environment-based vulnerability mitigation + mechanisms used by the TOE on that platform. The evaluator shall ensure that the + lists correspond to what is specified in FPT_EEM_EXT.1.1. @@ -2869,32 +3031,32 @@ requires the TSF to specify the mechanisms it uses to verify the - integrity of Guest VMs. + integrity of Guest VMs. No specific management functions are identified. - The following actions should be auditable if FAU_GEN Security - audit data generation is included in the PP/ST: - Actions taken due to failed integrity check. + The following actions should be auditable if FAU_GEN Security + audit data generation is included in the PP/ST: + Actions taken due to failed integrity check. No dependencies. The TSF shall verify the integrity of Guest VMs through the following mechanisms:<assignable>list of Guest VM integrity mechanisms</assignable>. - The primary purpose of this requirement is to identify and describe - the mechanisms used to verify the integrity of Guest VMs that have been 'imported' in some fashion, - though these mechanisms could also be applied to all Guest VMs, depending on the mechanism used. - Importation for this requirement could include VM migration (live or otherwise), the importation of - virtual disk files that were previously exported, VMs in shared storage, etc. It is possible that a - trusted VM could have been modified during the migration or import/export process, or VMs could have - been obtained from untrusted sources in the first place, so integrity checks on these VMs can be a - prudent measure to take. These integrity checks could be as thorough as making sure the entire VM - exactly matches a previously known VM (by hash for example), or by simply checking certain - configuration settings to ensure that the VM's configuration will not violate the security model - of the VS. + The primary purpose of this requirement is to identify and describe + the mechanisms used to verify the integrity of Guest VMs that have been 'imported' in some fashion, + though these mechanisms could also be applied to all Guest VMs, depending on the mechanism used. + Importation for this requirement could include VM migration (live or otherwise), the importation of + virtual disk files that were previously exported, VMs in shared storage, etc. It is possible that a + trusted VM could have been modified during the migration or import/export process, or VMs could have + been obtained from untrusted sources in the first place, so integrity checks on these VMs can be a + prudent measure to take. These integrity checks could be as thorough as making sure the entire VM + exactly matches a previously known VM (by hash for example), or by simply checking certain + configuration settings to ensure that the VM's configuration will not violate the security model + of the VS. - For each mechanism listed in the assignment, the evaluator shall ensure that the TSS - documents the mechanism, including how it verifies VM integrity, which set of Guest - VMs it will check (all Guest VMs, only migrated VM - s, etc.), when such checks occur (before VM startup, immediately following - importation/migration, on demand, etc.), and which actions are taken if a VM fails - the integrity check (or which range of actions are possible if the action is configurable). + For each mechanism listed in the assignment, the evaluator shall ensure that the TSS + documents the mechanism, including how it verifies VM integrity, which set of Guest + VMs it will check (all Guest VMs, only migrated VM + s, etc.), when such checks occur (before VM startup, immediately following + importation/migration, on demand, etc.), and which actions are taken if a VM fails + the integrity check (or which range of actions are possible if the action is configurable). @@ -2905,7 +3067,7 @@ requires the TSF to identify the hardware assists it uses to reduce - TOE complexity. + TOE complexity. No specific management functions are identified. There are no auditable events foreseen. No dependencies. @@ -2913,28 +3075,28 @@ The VMM shall use<assignable>list of hardware-based virtualization assists</assignable>to reduce or eliminate the need for binary translation. The evaluator shall examine the TSS to ensure that it states, for each platform - listed in the ST, the hardware assists and memory-handling extensions used by the - TOE on that platform. The evaluator shall ensure that these lists correspond to what - is specified in the applicable FPT_HAS_EXT component. + listed in the ST, the hardware assists and memory-handling extensions used by the + TOE on that platform. The evaluator shall ensure that these lists correspond to what + is specified in the applicable FPT_HAS_EXT component. The VMM shall use<assignable>list of hardware-based virtualization memory-handling assists</assignable>to reduce or eliminate the need for shadow page tables. These hardware-assists help reduce the size and complexity of the VMM, and thus, of - the trusted computing base, by eliminating or reducing the need for paravirtualization or binary - translation. Paravirtualization involves modifying guest software so that instructions that cannot be - properly virtualized are never executed on the physical processor. - For the assignment in FPT_HAS_EXT.1, the ST author lists the hardware-based virtualization assists on all - platforms included in the ST that are used by the VMM to reduce or eliminate the need for - software-based binary translation. Examples for the x86 platform are Intel VT-x and AMD-V. “None” is - an acceptable assignment for platforms that do not require virtualization assists in order to - eliminate the need for binary translation. This must be documented in the TSS. - For the assignment in FPT_HAS_EXT.1.2, the ST author lists the set of hardware-based virtualization - memory-handling extensions for all platforms listed in the ST that are used by the VMM to reduce or - eliminate the need for shadow page tables. Examples for the x86 platform are Intel EPT and AMD RVI. - “None” is an acceptable assignment for platforms that do not require memory-handling assists in order - to eliminate the need for shadow page tables. This must be documented in the TSS. - + the trusted computing base, by eliminating or reducing the need for paravirtualization or binary + translation. Paravirtualization involves modifying guest software so that instructions that cannot be + properly virtualized are never executed on the physical processor. + For the assignment in FPT_HAS_EXT.1, the ST author lists the hardware-based virtualization assists on all + platforms included in the ST that are used by the VMM to reduce or eliminate the need for + software-based binary translation. Examples for the x86 platform are Intel VT-x and AMD-V. “None” is + an acceptable assignment for platforms that do not require virtualization assists in order to + eliminate the need for binary translation. This must be documented in the TSS. + For the assignment in FPT_HAS_EXT.1.2, the ST author lists the set of hardware-based virtualization + memory-handling extensions for all platforms listed in the ST that are used by the VMM to reduce or + eliminate the need for shadow page tables. Examples for the x86 platform are Intel EPT and AMD RVI. + “None” is an acceptable assignment for platforms that do not require memory-handling assists in order + to eliminate the need for shadow page tables. This must be documented in the TSS. + @@ -2942,35 +3104,35 @@ requires the TSF to implement appropriate parameter validation - to protect the VMM from unauthorized access through a hypercall interface. + to protect the VMM from unauthorized access through a hypercall interface. No specific management functions are identified. The following actions should be auditable if FAU_GEN Security - audit data generation is included in the PP/ST: - Invalid parameter to hypercall detected.Hypercall interface invoked when documented preconditions are not met. + audit data generation is included in the PP/ST: + Invalid parameter to hypercall detected.Hypercall interface invoked when documented preconditions are not met. FMT_SMR.1 Security Roles The TSF shall validate the parameters passed to Hypercall interfaces prior to execution of the VMM functionality exposed by each interface. The purpose of this requirement is to help ensure the integrity of the - VMM by protecting the attack surface exposed to untrusted Guest VMs through Hypercalls. - A Hypercall interface allows VMM functionality to be invoked by VM-aware guest software. - For example, a hypercall interface could be used to get information about - the real world, such as the time of day or the underlying hardware of the host system. A hypercall - could also be used to transfer data between VMs through a copy-paste mechanism. Because hypercall - interfaces expose the VMM to Guest software, these interfaces constitute attack surface. - There is no expectation that the evaluator will need to review source code in order to accomplish the - evaluation activity. - + VMM by protecting the attack surface exposed to untrusted Guest VMs through Hypercalls. + A Hypercall interface allows VMM functionality to be invoked by VM-aware guest software. + For example, a hypercall interface could be used to get information about + the real world, such as the time of day or the underlying hardware of the host system. A hypercall + could also be used to transfer data between VMs through a copy-paste mechanism. Because hypercall + interfaces expose the VMM to Guest software, these interfaces constitute attack surface. + There is no expectation that the evaluator will need to review source code in order to accomplish the + evaluation activity. + - The evaluator shall examine the TSS (or proprietary TSS Annex) to ensure that all hypercall functions are - documented at the level necessary for the evaluator to run the below test. Documentation for each hypercall - interface must include: how to invoke the interface, parameters and legal values, - and any conditions under which the interface can be invoked (e.g., from guest user mode, guest privileged mode, - during guest boot only). + The evaluator shall examine the TSS (or proprietary TSS Annex) to ensure that all hypercall functions are + documented at the level necessary for the evaluator to run the below test. Documentation for each hypercall + interface must include: how to invoke the interface, parameters and legal values, + and any conditions under which the interface can be invoked (e.g., from guest user mode, guest privileged mode, + during guest boot only). - There is no operational guidance for this component. - + There is no operational guidance for this component. + - The evaluator shall perform the following test: + The evaluator shall perform the following test: @@ -2992,16 +3154,16 @@ The TSF shall include software identification (SWID) tags that contain a SoftwareIdentity element and an Entity element as defined in ISO/IEC 19770-2:2009. The evaluator shall examine the TSS to ensure it describes how SWID tags are - implemented and the format of the tags. The evaluator shall verify that the format complies with - FPT_IDV_EXT.1.1 and that SWIDs are stored in accordance with FPT_IDV_EXT.1.2. + implemented and the format of the tags. The evaluator shall verify that the format complies with + FPT_IDV_EXT.1.1 and that SWIDs are stored in accordance with FPT_IDV_EXT.1.2. - - The evaluator shall perform the following test: - - The evaluator shall check for the existence of SWID tags in a .swidtag file. The evaluator - shall open the file and verify that each SWID contains at least a SoftwareIdentity element - and an Entity element. + + The evaluator shall perform the following test: + + The evaluator shall check for the existence of SWID tags in a .swidtag file. The evaluator + shall open the file and verify that each SWID contains at least a SoftwareIdentity element + and an Entity element. @@ -3009,9 +3171,9 @@ The TSF shall store SWIDs in a .swidtag file as defined in ISO/IEC 19770-2:2009. SWID tags are XML files embedded within software that provide a standard method for - IT departments to track and manage the software. The presence of SWIDs can greatly simplify the - software management process and improve security by enhancing the ability of IT departments to manage - updates. + IT departments to track and manage the software. The presence of SWIDs can greatly simplify the + software management process and improve security by enhancing the ability of IT departments to manage + updates. @@ -3020,28 +3182,28 @@ requires the TSF to support introspection. No specific management functions are identified. - The following actions should be auditable if FAU_GEN Security - audit data generation is included in the PP/ST: - Introspection initiated/enabled. + The following actions should be auditable if FAU_GEN Security + audit data generation is included in the PP/ST: + Introspection initiated/enabled. No dependencies. The TSF shall support a mechanism for permitting the VMM or privileged VMs to access the internals of another VM for purposes of introspection. Introspection can be used to support malware and anomaly detection from outside of - the guest environment. This not only helps protect the Guest OS, it also protects the VS by providing - an opportunity for the VS to detect threats to itself that originate within VMs, and that may attempt - to break out of the VM and compromise the VMM or other VMs. - The hosting of malware detection software outside of the guest VM helps protect the guest and helps ensure - the integrity of the malware detection/antivirus software. This capability can be implemented in - the VMM itself, but ideally it should be hosted by a Service VM so that it can be better contained - and does not introduce bugs into the VMM. + the guest environment. This not only helps protect the Guest OS, it also protects the VS by providing + an opportunity for the VS to detect threats to itself that originate within VMs, and that may attempt + to break out of the VM and compromise the VMM or other VMs. + The hosting of malware detection software outside of the guest VM helps protect the guest and helps ensure + the integrity of the malware detection/antivirus software. This capability can be implemented in + the VMM itself, but ideally it should be hosted by a Service VM so that it can be better contained + and does not introduce bugs into the VMM. The evaluator shall examine the TSS documentation to verify that it describes the - interface for VM introspection and whether the introspection is performed by the - VMM or another VM. + interface for VM introspection and whether the introspection is performed by the + VMM or another VM. - The evaluator shall examine the operational guidance to ensure that it contains instructions for - configuration of the introspection mechanism. - + The evaluator shall examine the operational guidance to ensure that it contains instructions for + configuration of the introspection mechanism. + @@ -3054,17 +3216,17 @@ requires the TSF to support a measured launch of itself. No specific management functions are identified. - The following actions should be auditable if FAU_GEN Security - audit data generation is included in the PP/ST: - Integrity measurements collected. + The following actions should be auditable if FAU_GEN Security + audit data generation is included in the PP/ST: + Integrity measurements collected. No dependencies. The TSF shall support a measured launch of the Virtualization System. Measured components of the VS shall include the static executable image of the Hypervisor and:<selectables linebreak="yes"><selectable id="fpt_ml_ext.1.1_1" >Static executable images of the Management Subsystem</selectable><selectable id="fpt_ml_ext.1.1_3" ><assignable>list of (static images of) Service VMs</assignable></selectable><selectable id="fpt_ml_ext.1.1_5" ><assignable>list of configuration files</assignable></selectable><selectable id="fpt_ml_ext.1.1_6" >no other components</selectable> </selectables> - The evaluator shall verify that the TSS or Operational Guidance describes how - integrity measurements are performed and made available to the Management Subsystem. The evaluator - shall examine the operational guidance to verify that it documents how to access the measurements in - the Management Subsystem. + The evaluator shall verify that the TSS or Operational Guidance describes how + integrity measurements are performed and made available to the Management Subsystem. The evaluator + shall examine the operational guidance to verify that it documents how to access the measurements in + the Management Subsystem. The evaluator shall start the VS, login as an Administrator, and verify that the measurements for the specified components are viewable in the Management Subsystem. @@ -3075,27 +3237,27 @@ The TSF shall make the measurements selected in FPT_ML_EXT.1.1 available to the Management Subsystem. - A measured launch of the platform and VS demonstrates that the proper TOE software was - loaded. A measured launch process employs verifiable integrity measurement mechanisms. For example, a - VS may hash components such as the hypervisor, service VMs, or the Management Subsystem. A - measured launch process only allows components to be executed after the measurement has been recorded. - An example process may add each component’s hash before it is executed so that the final hash reflects - the evidence of a component’s state prior to execution. The measurement may be verified as the system - boots, but this is not required. - The Platform is outside of the TOE. However, this requirement specifies that the VS must be capable of - receiving Platform measurements if the Platform provides them. This requirement is requiring TOE - support for Platform measurements if provided; it is not placing a requirement on the Platform to take - such measurements. - If available, hardware should be used to store measurements in such a manner that they cannot be modified - in any manner except to be extended. These measurements should be produced in a repeatable manner so - that a third party can verify the measurements if given the inputs. Hardware devices, like Trusted - Platform Modules (TPM), TrustZone, and MMU are some examples that may serve as foundations for storing - and reporting measurements. - Platforms with a root of trust for measurement (RTM) should initiate the measured launch process. This may - include core BIOS or the chipset. The chipset is the preferred RTM, but core BIOS or other firmware is - acceptable. In a system without a traditional RTM, the first component that boots would be considered - the RTM, this is not preferred. - + A measured launch of the platform and VS demonstrates that the proper TOE software was + loaded. A measured launch process employs verifiable integrity measurement mechanisms. For example, a + VS may hash components such as the hypervisor, service VMs, or the Management Subsystem. A + measured launch process only allows components to be executed after the measurement has been recorded. + An example process may add each component’s hash before it is executed so that the final hash reflects + the evidence of a component’s state prior to execution. The measurement may be verified as the system + boots, but this is not required. + The Platform is outside of the TOE. However, this requirement specifies that the VS must be capable of + receiving Platform measurements if the Platform provides them. This requirement is requiring TOE + support for Platform measurements if provided; it is not placing a requirement on the Platform to take + such measurements. + If available, hardware should be used to store measurements in such a manner that they cannot be modified + in any manner except to be extended. These measurements should be produced in a repeatable manner so + that a third party can verify the measurements if given the inputs. Hardware devices, like Trusted + Platform Modules (TPM), TrustZone, and MMU are some examples that may serve as foundations for storing + and reporting measurements. + Platforms with a root of trust for measurement (RTM) should initiate the measured launch process. This may + include core BIOS or the chipset. The chipset is the preferred RTM, but core BIOS or other firmware is + acceptable. In a system without a traditional RTM, the first component that boots would be considered + the RTM, this is not preferred. + Integrity initiated/enabled. @@ -3106,36 +3268,36 @@ requires the TSF to ensure that VMs are not inadvertently given access to information - in different domains because removable media is simultaneously accessible from separate - domains. - The following actions could be considered for the - management functions in FMT: - Ability to configure removable media policy.Ability to connect/disconnect removable devices to/from a VM. - The following actions should be auditable if FAU_GEN Security - audit data generation is included in the PP/ST: - Connection/disconnection of removable media or device - to/from a VM.Ejection/insertion of removable media or device from/to - an already connected VM. + in different domains because removable media is simultaneously accessible from separate + domains. + The following actions could be considered for the + management functions in FMT: + Ability to configure removable media policy.Ability to connect/disconnect removable devices to/from a VM. + The following actions should be auditable if FAU_GEN Security + audit data generation is included in the PP/ST: + Connection/disconnection of removable media or device + to/from a VM.Ejection/insertion of removable media or device from/to + an already connected VM. FDP_VMS_EXT.1 VM Separation The TSF shall implement controls for handling the transfer of virtual and physical removable media and virtual and physical removable media devices between information domains. The evaluator shall examine the TSS to ensure it describes the association between - the media or devices supported by the TOE and the actions that can occur when - switching information domains. + the media or devices supported by the TOE and the actions that can occur when + switching information domains. - The evaluator shall examine the operational guidance to ensure it - documents how an administrator or user configures the behavior of each media or device. - + The evaluator shall examine the operational guidance to ensure it + documents how an administrator or user configures the behavior of each media or device. + - - The evaluator shall perform the following test for each listed media or device: - + + The evaluator shall perform the following test for each listed media or device: + The evaluator shall configure two VMs that are members of different information domains, - with the media or device connected to one of the VMs. The evaluator shall disconnect the - media or device from the VM and connect it to the other VM. The evaluator shall verify - that the action performed is consistent with the action assigned in the TSS. + with the media or device connected to one of the VMs. The evaluator shall disconnect the + media or device from the VM and connect it to the other VM. The evaluator shall verify + that the action performed is consistent with the action assigned in the TSS. @@ -3143,91 +3305,91 @@ The TSF shall enforce the following rules when<assignable>virtual or physical removable media and virtual or physical removable media devices</assignable>are switched between information domains, then<selectables linebreak="yes"><selectable id="fpt_rdm_ext.1.2_2" >the Administrator has granted explicit access for the media or device to be connected to the receiving domain</selectable><selectable id="fpt_rdm_ext.1.2_3" >the media in a device that is being transferred is ejected prior to the receiving domain being allowed access to the device</selectable><selectable id="fpt_rdm_ext.1.2_4" >the user of the receiving domain expressly authorizes the connection</selectable><selectable id="fpt_rdm_ext.1.2_5" >the device or media that is being transferred is prevented from being accessed by the receiving domain</selectable> </selectables> - The purpose of these requirements is to ensure that VMs are not given inadvertent access to information - from different domains because of media or removable media devices left connected to physical machines. - Removable media is media that can be ejected from a device, such as a compact disc, floppy disk, SD, or - compact flash memory card. - Removable media devices are removable devices that include media, such as USB flash drives and USB hard - drives. Removable media devices can themselves contain removable media (e.g., USB CDROM drives). - For purposes of this requirement, an Information Domain is: - A VM or collection of VMsThe Virtualization SystemHost OSManagement Subsystem - These requirements also apply to virtualized removable media—such as virtual CD drives that connect to - ISO images—as well as physical media—such as CDROMs and USB flash drives. In the case of virtual - CDROMs, virtual ejection of the virtual media is sufficient. - In the first assignment, the ST author lists all removable media and removable media devices (both virtual - and real) that are supported by the TOE. The ST author then - selects actions that are appropriate for all removable media and removable media devices (both - virtual and real) that are being claimed in the assignment. - For clarity, the ST author may iterate this requirement so that like actions are grouped with the - removable media or devices to which they apply (e.g., the first iteration could contain all devices - for which media is ejected on a switch; the second iteration could contain all devices for which - access is prevented on a switch, etc.). - + The purpose of these requirements is to ensure that VMs are not given inadvertent access to information + from different domains because of media or removable media devices left connected to physical machines. + Removable media is media that can be ejected from a device, such as a compact disc, floppy disk, SD, or + compact flash memory card. + Removable media devices are removable devices that include media, such as USB flash drives and USB hard + drives. Removable media devices can themselves contain removable media (e.g., USB CDROM drives). + For purposes of this requirement, an Information Domain is: + A VM or collection of VMsThe Virtualization SystemHost OSManagement Subsystem + These requirements also apply to virtualized removable media—such as virtual CD drives that connect to + ISO images—as well as physical media—such as CDROMs and USB flash drives. In the case of virtual + CDROMs, virtual ejection of the virtual media is sufficient. + In the first assignment, the ST author lists all removable media and removable media devices (both virtual + and real) that are supported by the TOE. The ST author then + selects actions that are appropriate for all removable media and removable media devices (both + virtual and real) that are being claimed in the assignment. + For clarity, the ST author may iterate this requirement so that like actions are grouped with the + removable media or devices to which they apply (e.g., the first iteration could contain all devices + for which media is ejected on a switch; the second iteration could contain all devices for which + access is prevented on a switch, etc.). + Connection/disconnection of removable media or device to/from a VM. VM Identifier, Removable media/device identifier, event description or identifier - (connect/disconnect, ejection/insertion, etc.). + (connect/disconnect, ejection/insertion, etc.). Ejection/insertion of removable media or device from/to an already connected VM. - VM Identifier, Removable media/device identifier, event description or identifier - (connect/disconnect, ejection/insertion, etc.). + VM Identifier, Removable media/device identifier, event description or identifier + (connect/disconnect, ejection/insertion, etc.). requires the TSF to define the mechanism for applying and verifying TOE updates. - The following actions could be considered for the - management functions in FMT: - Ability to update the Virtualization System. + The following actions could be considered for the + management functions in FMT: + Ability to update the Virtualization System. The following actions should be auditable if FAU_GEN Security - audit data generation is included in the PP/ST: - Initiation of update.Failure of signature verification. + audit data generation is included in the PP/ST: + Initiation of update.Failure of signature verification. FCS_COP.1 Cryptographic Operation - If is selected in FPT_TUD_EXT.1.3 - then must be selected in FIA_X509_EXT.2.1. + If is selected in FPT_TUD_EXT.1.3 + then must be selected in FIA_X509_EXT.2.1. The TSF shall provide administrators the ability to query the currently executed version of the TOE firmware/software as well as the most recently installed version of the TOE firmware/software. - The version currently running (being executed) may not be the version most recently installed. For - instance, maybe the update was installed but the system requires a reboot before this update will run. - Therefore, it needs to be clear that the query should indicate both the most recently executed version - as well as the most recently installed update. - + The version currently running (being executed) may not be the version most recently installed. For + instance, maybe the update was installed but the system requires a reboot before this update will run. + Therefore, it needs to be clear that the query should indicate both the most recently executed version + as well as the most recently installed update. + The evaluator shall verify that the TSS describes all TSF software - update mechanisms for updating the system software. Updates to the TOE either have a - hash associated with them, or are signed by an authorized source. The evaluator shall verify that the - description includes either a digital signature or published hash verification of the software before - installation and that installation fails if the verification fails. The evaluator shall verify that - the TSS describes the method by which the digital signature or published hash is - verified to include how the candidate updates are obtained, the processing associated with verifying - the update, and the actions that take place for both successful and unsuccessful verification. If - digital signatures are used, the evaluator shall also ensure the definition of an authorized source is - contained in the TSS. - If the ST author indicates that a certificate-based mechanism is used for software - update digital signature verification, the evaluator shall verify that the TSS - contains a description of how the certificates are contained on the device. The evaluator also ensures - that the TSS (or administrator guidance) describes how the certificates are - installed/updated/selected, if necessary. + update mechanisms for updating the system software. Updates to the TOE either have a + hash associated with them, or are signed by an authorized source. The evaluator shall verify that the + description includes either a digital signature or published hash verification of the software before + installation and that installation fails if the verification fails. The evaluator shall verify that + the TSS describes the method by which the digital signature or published hash is + verified to include how the candidate updates are obtained, the processing associated with verifying + the update, and the actions that take place for both successful and unsuccessful verification. If + digital signatures are used, the evaluator shall also ensure the definition of an authorized source is + contained in the TSS. + If the ST author indicates that a certificate-based mechanism is used for software + update digital signature verification, the evaluator shall verify that the TSS + contains a description of how the certificates are contained on the device. The evaluator also ensures + that the TSS (or administrator guidance) describes how the certificates are + installed/updated/selected, if necessary. - The evaluator performs the version verification activity to determine the current version - of the product. The evaluator obtains a legitimate update using procedures described in - the operational guidance and verifies that it is successfully installed on the TOE. After - the update, the evaluator performs the version verification activity again to verify the - version correctly corresponds to that of the update. - The evaluator performs the version verification activity to determine the current version - of the product. The evaluator obtains or produces illegitimate updates as defined below, - and attempts to install them on the TOE. The evaluator verifies that the TOE rejects all - of the illegitimate updates. The evaluator performs this test using all of the following - forms of illegitimate updates: - A modified version (e.g., using a hex editor) of a legitimately signed or hashed - updateAn image that has not been signed/hashedAn image signed with an invalid hash or invalid signature (e.g., by using a - different key as expected for creating the signature or by manual modification - of a legitimate hash/signature) + The evaluator performs the version verification activity to determine the current version + of the product. The evaluator obtains a legitimate update using procedures described in + the operational guidance and verifies that it is successfully installed on the TOE. After + the update, the evaluator performs the version verification activity again to verify the + version correctly corresponds to that of the update. + The evaluator performs the version verification activity to determine the current version + of the product. The evaluator obtains or produces illegitimate updates as defined below, + and attempts to install them on the TOE. The evaluator verifies that the TOE rejects all + of the illegitimate updates. The evaluator performs this test using all of the following + forms of illegitimate updates: + A modified version (e.g., using a hex editor) of a legitimately signed or hashed + updateAn image that has not been signed/hashedAn image signed with an invalid hash or invalid signature (e.g., by using a + different key as expected for creating the signature or by manual modification + of a legitimate hash/signature) @@ -3237,27 +3399,27 @@ The TSF shall provide means to authenticate firmware/software updates to the TOE using a<selectables ><selectable id="sel-tud-digsign-cert" >digital signature mechanism using certificates</selectable><selectable id="sel-tud-digsign" >digital signature mechanism not using certificates</selectable><selectable id="fpt_tud_ext.1.3_1" >published hash</selectable> </selectables>prior to installing those updates. - The digital signature mechanism referenced in FPT_TUD_EXT.1.3 is one of the - algorithms specified in FCS_COP.1/SIG. - If certificates are used by the update verification mechanism, then FIA_X509_EXT.1 and FIA_X509_EXT.2 - must be included in the ST. Certificates are validated in accordance with FIA_X509_EXT.1 and - the appropriate selections should be made in FIA_X509_EXT.2.1. Additionally, FPT_TUD_EXT.2 must be - included in the ST. - “Update” in the context of this SFR refers to the process of replacing a non-volatile, system resident - software component with another. The former is referred to as the NV image, and the latter is the - update image. While the update image is typically newer than the NV image, this is not a requirement. - There are legitimate cases where the system owner may want to rollback a component to an older version - (e.g., when the component manufacturer releases a faulty update, or when the system relies on an - undocumented feature no longer present in the update). Likewise, the owner may want to update with the - same version as the NV image to recover from faulty storage. - All discrete software components (e.g., applications, drivers, kernel, firmware) of the TSF, should be - digitally signed by the corresponding manufacturer and subsequently verified by the mechanism - performing the update. Since it is recognized that components may be signed by different manufacturers, - it is essential that the update process verify that both the update and NV images were produced by the - same manufacturer (e.g., by comparing public keys) or signed by legitimate signing keys (e.g., - successful verification of certificates when using X.509 certificates). - The Digital Signature option is the preferred mechanism for authenticating updates. The Published Hash - option will be removed from a future version of this PP. + The digital signature mechanism referenced in FPT_TUD_EXT.1.3 is one of the + algorithms specified in FCS_COP.1/SIG. + If certificates are used by the update verification mechanism, then FIA_X509_EXT.1 and FIA_X509_EXT.2 + must be included in the ST. Certificates are validated in accordance with FIA_X509_EXT.1 and + the appropriate selections should be made in FIA_X509_EXT.2.1. Additionally, FPT_TUD_EXT.2 must be + included in the ST. + “Update” in the context of this SFR refers to the process of replacing a non-volatile, system resident + software component with another. The former is referred to as the NV image, and the latter is the + update image. While the update image is typically newer than the NV image, this is not a requirement. + There are legitimate cases where the system owner may want to rollback a component to an older version + (e.g., when the component manufacturer releases a faulty update, or when the system relies on an + undocumented feature no longer present in the update). Likewise, the owner may want to update with the + same version as the NV image to recover from faulty storage. + All discrete software components (e.g., applications, drivers, kernel, firmware) of the TSF, should be + digitally signed by the corresponding manufacturer and subsequently verified by the mechanism + performing the update. Since it is recognized that components may be signed by different manufacturers, + it is essential that the update process verify that both the update and NV images were produced by the + same manufacturer (e.g., by comparing public keys) or signed by legitimate signing keys (e.g., + successful verification of certificates when using X.509 certificates). + The Digital Signature option is the preferred mechanism for authenticating updates. The Published Hash + option will be removed from a future version of this PP. Initiation of update. @@ -3275,25 +3437,25 @@ No specific management functions are identified. There are no auditable events foreseen. FPT_TUD_EXT.1 Trusted Updates to the Virtualization System - FIA_X509_EXT.1 X.509 Validation - FIA_X509_EXT.2 X.509 Authentication + FIA_X509_EXT.1 X.509 Validation + FIA_X509_EXT.2 X.509 Authentication The TSF shall not install an update if the code signing certificate is deemed invalid. Certificates may optionally be used for code signing of system software updates - (FPT_TUD_EXT.1.3). This element must be included in the ST if certificates are used for validating - updates. If “code signing for system software updates” is selected in FIA_X509_EXT.2.1, FPT_TUD_EXT.2 - must be included in the ST. - Validity is determined by the certificate path, the expiration date, and the revocation status in - accordance with FIA_X509_EXT.1. - + (FPT_TUD_EXT.1.3). This element must be included in the ST if certificates are used for validating + updates. If “code signing for system software updates” is selected in FIA_X509_EXT.2.1, FPT_TUD_EXT.2 + must be included in the ST. + Validity is determined by the certificate path, the expiration date, and the revocation status in + accordance with FIA_X509_EXT.1. + requires the TSF to interface with Guest VMs through virtual hardware abstractions - so that any data transmitted to the TOE from a Guest VM can be validated - as well-formed. + so that any data transmitted to the TOE from a Guest VM can be validated + as well-formed. No specific management functions are identified. There are no auditable events foreseen. FPT_VIV_EXT.1 VMM Isolation from VMs @@ -3301,26 +3463,26 @@ The TSF shall provide interfaces for virtual devices implemented by the VMM as part of the virtual hardware abstraction. The evaluator shall examine the TSS to ensure it lists all virtual devices - accessible by the guest OS. The TSS, or a separate proprietary document, must - also document all virtual device interfaces at the level of I/O ports or PCI Bus - interfaces - including - port numbers (absolute or relative to a base), port name, address range, and a description of - legal input values. - The TSS must also describe the expected behavior of the interface when presented with illegal input - values. This behavior must be deterministic and indicative of parameter checking by the TSF. - The evaluator must ensure that there are no obvious or publicly known virtual I/O - ports missing from the TSS. - There is no expectation that evaluators will examine source code to verify the “all” part of the - evaluation activity. + accessible by the guest OS. The TSS, or a separate proprietary document, must + also document all virtual device interfaces at the level of I/O ports or PCI Bus + interfaces - including + port numbers (absolute or relative to a base), port name, address range, and a description of + legal input values. + The TSS must also describe the expected behavior of the interface when presented with illegal input + values. This behavior must be deterministic and indicative of parameter checking by the TSF. + The evaluator must ensure that there are no obvious or publicly known virtual I/O + ports missing from the TSS. + There is no expectation that evaluators will examine source code to verify the “all” part of the + evaluation activity. The TSF shall validate the parameters passed to the virtual device interface prior to execution of the VMM functionality exposed by those interfaces. The purpose of this requirement is to ensure that the VMM is not vulnerable to - compromise through the processing of malformed data passed to the virtual device interface from a - Guest OS. The VMM cannot assume that any data coming from a VM is well-formed—even if the virtual - device interface is unique to the VS and the data comes from a virtual device - driver supplied by the Virtualization Vendor. + compromise through the processing of malformed data passed to the virtual device interface from a + Guest OS. The VMM cannot assume that any data coming from a VM is well-formed—even if the virtual + device interface is unique to the VS and the data comes from a virtual device + driver supplied by the Virtualization Vendor. @@ -3328,38 +3490,38 @@ requires the TSF to ensure that there is no mechanism by which a Guest VM can interface - with the TOE, other VMs, or the hardware platform without authorization. + with the TOE, other VMs, or the hardware platform without authorization. No specific management functions are identified. There are no auditable events foreseen. FDP_PPR_EXT.1 Physical Platform Resource Controls - FDP_VMS_EXT.1 VM Separation + FDP_VMS_EXT.1 VM Separation The TSF must ensure that software running in a VM is not able to degrade or disrupt the functioning of other VMs, the VMM, or the Platform. - The evaluator shall verify that the TSS (or a proprietary annex to the TSS) describes how the TSF ensures - that guest software cannot degrade or disrupt the functioning of other VMs, the VMM or the platform. And - how the TSF prevents guests from invoking higher-privilege platform code, such as the examples in the note. + The evaluator shall verify that the TSS (or a proprietary annex to the TSS) describes how the TSF ensures + that guest software cannot degrade or disrupt the functioning of other VMs, the VMM or the platform. And + how the TSF prevents guests from invoking higher-privilege platform code, such as the examples in the note. The TSF must ensure that a Guest VM is unable to invoke platform code that runs at a privilege level equal to or exceeding that of the VMM without involvement of the VMM. This requirement is intended to ensure that software running within a Guest VM cannot - compromise other VMs, the VMM, or the platform. This requirement is not met if Guest VM - software—whatever its privilege level—can crash the VS or the Platform, or breakout - of its virtual hardware abstraction to gain execution on the platform, within or outside of the context - of the VMM. - This requirement is not violated if software running within a VM can crash the Guest OS and there is no - way for an attacker to gain execution in the VMM or outside of the virtualized domain. - FPT_VIV_EXT.1.2 addresses several specific mechanisms that must not be permitted to bypass the VMM and - invoke privileged code on the Platform. - At a minimum, the TSF should enforce the following:On the x86 platform, a virtual System Management Interrupt (SMI) cannot invoke platform System - Management Mode (SMM).An attempt to update virtual firmware or virtual BIOS cannot cause physical platform firmware - or physical platform BIOS to be modified.An attempt to update virtual firmware or virtual BIOS cannot cause the VMM to be modified. - Of the above, the first bullet does not apply to platforms that do not support SMM. The rationale behind the third bullet - is that a firmware update of a single VM must not affect other VMs. So if multiple VMs share the same - firmware image as part of a common hardware abstraction, then the update of a single machine’s BIOS - must not be allowed to change the common abstraction. The virtual hardware abstraction is part of the - VMM. + compromise other VMs, the VMM, or the platform. This requirement is not met if Guest VM + software—whatever its privilege level—can crash the VS or the Platform, or breakout + of its virtual hardware abstraction to gain execution on the platform, within or outside of the context + of the VMM. + This requirement is not violated if software running within a VM can crash the Guest OS and there is no + way for an attacker to gain execution in the VMM or outside of the virtualized domain. + FPT_VIV_EXT.1.2 addresses several specific mechanisms that must not be permitted to bypass the VMM and + invoke privileged code on the Platform. + At a minimum, the TSF should enforce the following:On the x86 platform, a virtual System Management Interrupt (SMI) cannot invoke platform System + Management Mode (SMM).An attempt to update virtual firmware or virtual BIOS cannot cause physical platform firmware + or physical platform BIOS to be modified.An attempt to update virtual firmware or virtual BIOS cannot cause the VMM to be modified. + Of the above, the first bullet does not apply to platforms that do not support SMM. The rationale behind the third bullet + is that a firmware update of a single VM must not affect other VMs. So if multiple VMs share the same + firmware image as part of a common hardware abstraction, then the update of a single machine’s BIOS + must not be allowed to change the common abstraction. The virtual hardware abstraction is part of the + VMM. @@ -3371,10 +3533,10 @@ Before establishing an administrative user session, the TSF shall display a security Administrator-specified advisory notice and consent warning message regarding use of the TOE. - This requirement is intended to apply to interactive sessions between a human user and a TOE. IT - entities establishing connections or programmatic connections (e.g., remote procedure calls over - a network) are not required to be covered by this requirement. - + This requirement is intended to apply to interactive sessions between a human user and a TOE. IT + entities establishing connections or programmatic connections (e.g., remote procedure calls over + a network) are not required to be covered by this requirement. + @@ -3390,32 +3552,32 @@ requires the TSF to implement one or more cryptographic protocols - to secure connectivity between the TSF and various external entities. + to secure connectivity between the TSF and various external entities. No specific management functions are identified. - + The following actions should be auditable if FAU_GEN Security audit data - generation is included in the PP/ST: - Initiation of the trusted channel.Termination of the trusted channel.Failures of the trusted path functions. + generation is included in the PP/ST: + Initiation of the trusted channel.Termination of the trusted channel.Failures of the trusted path functions. FAU_STG_EXT.1 Off-Loading of Audit Data If "" and "" are selected in FTP_ITC_EXT.1.1 - then "" must be selected in FIA_X509_EXT.2.1. + then "" must be selected in FIA_X509_EXT.2.1. The TSF shall use<selectables linebreak="yes"><selectable id="sel-itc-tls" >TLS as conforming to the <h:a href="https://www.niap-ccevs.org/MMO/PP/-439-/">Functional Package for Transport Layer Security</h:a></selectable><selectable id="sel-itc-https" >TLS/HTTPS as conforming to FCS_HTTPS_EXT.1</selectable><selectable id="sel-itc-ipsec" >IPsec as conforming to FCS_IPSEC_EXT.1</selectable><selectable id="sel-itc-ssh" >SSH as conforming to the <h:a href="https://www.niap-ccevs.org/MMO/PP/-459-/">Functional Package for Secure Shell</h:a></selectable> </selectables>and<selectables linebreak="yes"><selectable id="sel-itc-certauth" >certificate-based authentication of the remote peer</selectable><selectable id="ftp_itc_ext.1.1_1" >non-certificate-based authentication of the remote peer</selectable><selectable id="ftp_itc_ext.1.1_2" >no authentication of the remote peer</selectable> </selectables>to provide a trusted communication channel between itself, and <h:p/> <h:li>audit servers (as required by FAU_STG_EXT.1), and</h:li><selectables linebreak="yes"><selectable id="ftp_itc_ext.1.1_3" >remote administrators (as required by FTP_TRP.1.1 if selected in FMT_MOF_EXT.1.1 in the Client or Server PP-Module)</selectable><selectable id="ftp_itc_ext.1.1_4" >separation of management and operational networks (if selected in FMT_SMO_EXT.1)</selectable><selectable id="ftp_itc_ext.1.1_6" ><assignable>other capabilities</assignable></selectable><selectable id="ftp_itc_ext.1.1_7" >no other capabilities</selectable> </selectables>that is logically distinct from other communication paths and provides assured identification of its endpoints and protection of the communicated data from disclosure and detection of modification of the communicated data. - If the ST author selects either TLS or HTTPS, the TSF shall be validated against the - Functional Package for TLS. This PP does not mandate that a product implement TLS with mutual authentication, - but if the product includes the capability to perform TLS with mutual authentication, then - mutual authentication must be included within the TOE boundary. The TLS Package requires that the X509 - requirements be included by the PP, so selection of TLS or HTTPS causes FIA_X509_EXT.* to be selected. - If the ST author selects SSH, the TSF shall be validated against the Functional Package for Secure Shell. - If the ST author selects "certificate-based authentication of the remote peer," then FIA_X509_EXT.1 and FIA_X509_EXT.2 - must be included in the ST. "No authentication of the remote peer" should be selected only if the TOE is acting - as a server in a non-mutual authentication configuration. - The ST author must include the security functional requirements for the - trusted channel protocol selected in FTP_ITC_EXT.1 in the main body of the ST. + If the ST author selects either TLS or HTTPS, the TSF shall be validated against the + Functional Package for TLS. This PP does not mandate that a product implement TLS with mutual authentication, + but if the product includes the capability to perform TLS with mutual authentication, then + mutual authentication must be included within the TOE boundary. The TLS Package requires that the X509 + requirements be included by the PP, so selection of TLS or HTTPS causes FIA_X509_EXT.* to be selected. + If the ST author selects SSH, the TSF shall be validated against the Functional Package for Secure Shell. + If the ST author selects "certificate-based authentication of the remote peer," then FIA_X509_EXT.1 and FIA_X509_EXT.2 + must be included in the ST. "No authentication of the remote peer" should be selected only if the TOE is acting + as a server in a non-mutual authentication configuration. + The ST author must include the security functional requirements for the + trusted channel protocol selected in FTP_ITC_EXT.1 in the main body of the ST. - The evaluator will review the TSS to determine that it lists all trusted channels - the TOE uses for remote communications, including both the external entities and - remote users used for the channel as well as the protocol that is used for each. + The evaluator will review the TSS to determine that it lists all trusted channels + the TOE uses for remote communications, including both the external entities and + remote users used for the channel as well as the protocol that is used for each. @@ -3436,33 +3598,33 @@ The TSF shall <h:b>use a trusted channel as specified in FTP_ITC_EXT.1 to</h:b> provide a <h:b>trusted</h:b> communication path between itself and [ <h:i>remote</h:i> ] <h:b>administrators</h:b> that is logically distinct from other communication paths and provides assured identification of its end points and protection of the communicated data from [ <h:i>modification, disclosure</h:i> ]. - The evaluator shall examine the TSS to determine that the methods of remote - TOE administration are indicated, along with how those communications are protected. - The evaluator shall also confirm that all protocols listed in the TSS in support of - TOE administration are consistent with those specified in the requirement, and are - included in the requirements in the ST. + The evaluator shall examine the TSS to determine that the methods of remote + TOE administration are indicated, along with how those communications are protected. + The evaluator shall also confirm that all protocols listed in the TSS in support of + TOE administration are consistent with those specified in the requirement, and are + included in the requirements in the ST. - The evaluator shall confirm that the - operational guidance contains instructions for establishing the remote administrative sessions for - each supported method. - + The evaluator shall confirm that the + operational guidance contains instructions for establishing the remote administrative sessions for + each supported method. + - - The evaluator shall also perform the following tests: - + + The evaluator shall also perform the following tests: + The evaluators shall ensure that communications using each specified (in the operational - guidance) remote administration method is tested during the course of the evaluation, - setting up the connections as described in the operational guidance and ensuring that - communication is successful. - For each method of remote administration supported, the evaluator shall follow the - operational guidance to ensure that there is no available interface that can be used by - a remote user to establish remote administrative sessions without invoking the trusted - path. + guidance) remote administration method is tested during the course of the evaluation, + setting up the connections as described in the operational guidance and ensuring that + communication is successful. + For each method of remote administration supported, the evaluator shall follow the + operational guidance to ensure that there is no available interface that can be used by + a remote user to establish remote administrative sessions without invoking the trusted + path. The evaluator shall ensure, for each method of remote administration, the channel data is - not sent in plaintext. - The evaluator shall ensure, for each method of remote administration, modification of the - channel data is detected by the TOE. + not sent in plaintext. + The evaluator shall ensure, for each method of remote administration, modification of the + channel data is detected by the TOE. @@ -3473,15 +3635,15 @@ The TSF shall require the use of the trusted path for [ <h:i>[all remote administration actions]</h:i> ]. - This SFR is included in the ST if "remote" is selected in FMT_MOF_EXT.1.1 of the client or server PP-Module. - Protocols used to implement the remote administration trusted channel must be - selected in FTP_ITC_EXT.1. - This requirement ensures that authorized remote administrators initiate all communication with the - TOE via a trusted path, and that all communications with the TOE by remote administrators is performed - over this path. The data passed in this trusted communication channel are encrypted as defined the - protocol chosen in the first selection in FTP_ITC_EXT.1. The ST author chooses the mechanism or mechanisms supported by - the TOE, and then ensures that the detailed requirements in Appendix B corresponding to their selection - are copied to the ST if not already present. + This SFR is included in the ST if "remote" is selected in FMT_MOF_EXT.1.1 of the client or server PP-Module. + Protocols used to implement the remote administration trusted channel must be + selected in FTP_ITC_EXT.1. + This requirement ensures that authorized remote administrators initiate all communication with the + TOE via a trusted path, and that all communications with the TOE by remote administrators is performed + over this path. The data passed in this trusted communication channel are encrypted as defined the + protocol chosen in the first selection in FTP_ITC_EXT.1. The ST author chooses the mechanism or mechanisms supported by + the TOE, and then ensures that the detailed requirements in Appendix B corresponding to their selection + are copied to the ST if not already present. Initiation of the trusted channel. @@ -3500,25 +3662,25 @@ requires the TSF to unambiguously identify the Guest VM that has - the current input focus for input peripherals. + the current input focus for input peripherals. No specific management functions are identified. There are no auditable events foreseen. No dependencies The TSF shall indicate to users which VM, if any, has the current input focus. This requirement applies to all users—whether User or Administrator. - In environments where multiple VMs run at the same time, the user must have a way of knowing which - VM user input is directed to at any given moment. This is especially important in multiple-domain - environments. - In the case of a human user, this is usually a visual indicator. In the case of headless VMs, the user is - considered to be a program, but this program still needs to know which VM it is sending input to; - this would typically be accomplished through programmatic means. + In environments where multiple VMs run at the same time, the user must have a way of knowing which + VM user input is directed to at any given moment. This is especially important in multiple-domain + environments. + In the case of a human user, this is usually a visual indicator. In the case of headless VMs, the user is + considered to be a program, but this program still needs to know which VM it is sending input to; + this would typically be accomplished through programmatic means. The evaluator shall ensure that the TSS lists the supported user input devices. - The evaluator shall ensure that the operational guidance specifies how the current input focus is - indicated to the user. - + The evaluator shall ensure that the operational guidance specifies how the current input focus is + indicated to the user. + @@ -3527,25 +3689,25 @@ requires the TOE to perform power on self-tests to verify its functionality and - the integrity of its stored executable code. + the integrity of its stored executable code. No specific management functions are identified. There are no auditable events foreseen. No dependencies The TSF shall support the unique identification of a VM’s output display to users. - In environments where a user has access to more than one VM at the same time, the - user must be able to determine the identity of each VM displayed in order to avoid inadvertent - cross-domain data entry. - There must be a mechanism for associating an identifier with a VM so that an application or program - displaying the VM can identify the VM to users. This is generally indicated visually for human users - (e.g., VM identity in the window title bar) and programmatically for headless VMs (e.g., an API - function). The identification must be unique to the VS, but does not need to be universally unique. + In environments where a user has access to more than one VM at the same time, the + user must be able to determine the identity of each VM displayed in order to avoid inadvertent + cross-domain data entry. + There must be a mechanism for associating an identifier with a VM so that an application or program + displaying the VM can identify the VM to users. This is generally indicated visually for human users + (e.g., VM identity in the window title bar) and programmatically for headless VMs (e.g., an API + function). The identification must be unique to the VS, but does not need to be universally unique. - The evaluator shall ensure that the TSS describes the mechanism for identifying - VMs to the user, how identities are assigned to VMs, and how - conflicts are prevented. + The evaluator shall ensure that the TSS describes the mechanism for identifying + VMs to the user, how identities are assigned to VMs, and how + conflicts are prevented. - The evaluator shall perform the following test: + The evaluator shall perform the following test: @@ -3554,18 +3716,33 @@
- The Security Objectives for the TOE in Section 4 were constructed to address threats identified in Section 3.1. The Security Functional Requirements (SFRs) in Section 5.1 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 Security Assurance Requirements (SARs) from Part 3 of the Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 5 that are required in evaluations against this PP. Individual evaluation activities to be performed are specified in both Section 5.1 as well as in this section.After the ST has been approved for evaluation, the Information Technology Security Evaluation Facility (ITSEF) will obtain the TOE, supporting environmental IT, and the administrative/user guides for the TOE. The ITSEF is expected to perform actions mandated by the CEM for the ASE and ALC SARs. The ITSEF also performs the evaluation activities contained within Section 5, 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 also provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the PP. + + The Security Objectives for the TOE in Section 4 were constructed to address threats identified in Section 3.1. The + Security Functional Requirements (SFRs) in Section 5.1 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 Security Assurance Requirements (SARs) from Part 3 of the Common Criteria for Information + Technology Security Evaluation, Version 3.1, Revision 5 that are required in evaluations against this PP. Individual + evaluation activities to be performed are specified in both Section 5.1 as well as in this section. + After the ST has been approved for evaluation, the Information Technology Security Evaluation Facility (ITSEF) will obtain + the TOE, supporting environmental IT, and the administrative/user guides for the TOE. The ITSEF is expected to perform + actions mandated by the CEM for the ASE and ALC SARs. The ITSEF also performs the evaluation activities contained + within Section 5, 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 also + provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the PP. + +
- As per ASE activities defined in [CEM] plus the TSS evaluation activities defined for any SFRs claimed by the TOE. -
+ As per ASE activities defined in [CEM] plus the TSS evaluation activities defined for any SFRs claimed by the TOE. +
- - The information about the TOE is contained in the guidance documentation available to the end user as well as the TOE - Summary Specification (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.2 - should provide the ST authors with sufficient information to determine the appropriate content for the TSS section. - + The information about the TOE is contained in the guidance documentation available to the end user as well as the TOE + Summary Specification (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.2 + should provide the ST authors with sufficient information to determine the appropriate content for the TSS section. + + The developer shall provide a functional specification. @@ -3574,26 +3751,26 @@ The developer shall provide a tracing from the functional specification to the SFRs. - As indicated in the introduction to this section, the functional specification is composed of the information - contained in the AGD_OPR and AGD_PRE documentation, coupled with the information provided in the TSS of the - ST. The evaluation activities in the functional requirements point to evidence that should exist in the - documentation and TSS section; since these are directly associated with the SFRs, the tracing in element - ADV_FSP.1.2D is implicitly already done and no additional documentation is necessary. + As indicated in the introduction to this section, the functional specification is composed of the information + contained in the AGD_OPR and AGD_PRE documentation, coupled with the information provided in the TSS of the + ST. The evaluation activities in the functional requirements point to evidence that should exist in the + documentation and TSS section; since these are directly associated with the SFRs, the tracing in element + ADV_FSP.1.2D is implicitly already done and no additional documentation is necessary. The functional specification shall describe the purpose and method of use for each SFR-enforcing and - SFR-supporting TSFI. + SFR-supporting TSFI. The functional specification shall identify all parameters associated with each SFR-enforcing and - SFR-supporting TSFI. + SFR-supporting TSFI. The functional specification shall provide rationale for the implicit categorization of interfaces as - SFR-non-interfering. + SFR-non-interfering. @@ -3602,80 +3779,80 @@ The evaluator shall confirm that the information provided meets all requirements for content and presentation - of evidence. + of evidence. - The evaluator shall determine that the functional specification is an accurate and complete instantiation of - the SFRs. + 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. The functional specification documentation - is provided to support the evaluation activities described in Section 5.2, 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. - + There are no specific evaluation activities associated with these SARs. The functional specification documentation + is provided to support the evaluation activities described in Section 5.2, 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. +
- - The guidance documents will be provided with the developer’s security target. Guidance must include a description of - how the authorized user verifies that the Operational Environment can fulfill its role for the security - functionality. The documentation should be in an informal style and readable by an authorized user. - 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 TOE in that environment; andinstructions to manage the security of the TOE as a product and as a component of the larger operational - environment. - Guidance pertaining to particular security functionality is also provided; specific requirements on such guidance are - contained in the evaluation activities specified with individual SFRs where applicable. - - + + The guidance documents will be provided with the developer’s security target. Guidance must include a description of + how the authorized user verifies that the Operational Environment can fulfill its role for the security + functionality. The documentation should be in an informal style and readable by an authorized user. + 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 TOE in that environment; andinstructions to manage the security of the TOE as a product and as a component of the larger operational + environment. + Guidance pertaining to particular security functionality is also provided; specific requirements on such guidance are + contained in the evaluation activities specified with individual SFRs where applicable. + + The developer shall provide operational user guidance. - + - Rather than repeat information here, the developer should review the evaluation activities for this - component to ascertain the specifics of the guidance that the evaluators will be checking for. This - will provide the necessary information for the preparation of acceptable guidance. + Rather than repeat information here, the developer should review the evaluation activities for this + component to ascertain the specifics of the guidance that the evaluators will be checking for. This + will provide the necessary information for the preparation of acceptable guidance. The operational user guidance shall describe what <h:s>for each user role </h:s><h:b>the authorized user-</h:b>accessible functions and - privileges that should be controlled in a secure processing environment, including appropriate - warnings. + privileges that should be controlled in a secure processing environment, including appropriate + warnings. The operational user guidance shall describe, for <h:s>each user role </h:s><h:b>the authorized user</h:b>, how to use the available - interfaces provided by the TOE in a secure manner. + interfaces provided by the TOE in a secure manner. - The operational user guidance shall describe, for <h:s>each user role </h:s><h:b>the authorized user</h:b>, the available functions and - interfaces, in particular all security parameters under the control of the user, indicating secure - values as appropriate. + The operational user guidance shall describe, for <h:s>each user role </h:s><h:b>the authorized user</h:b>, the available functions and + interfaces, in particular all security parameters under the control of the user, indicating secure + values as appropriate. - The operational user guidance shall, for <h:s>each user role </h:s><h:b>the authorized user</h:b>, clearly present each type of - security-relevant event relative to the user-accessible functions that need to be performed, - including changing the security characteristics of entities under the control of the TSF. + The operational user guidance shall, for <h:s>each user role </h:s><h:b>the authorized user</h:b>, clearly present each type of + security-relevant event relative to the user-accessible functions that need to be performed, + including changing the security characteristics of entities under the control of the TSF. The operational user guidance shall identify all possible modes of operation of the TOE - (including operation following failure or operational error), their consequences and implications for - maintaining secure operation. + (including operation following failure or operational error), their consequences and implications for + maintaining secure operation. - The operational user guidance shall, for <h:s>each user role </h:s><h:b>the authorized user</h:b>, describe the security measures to be - followed in order to fulfill the security objectives for the operational environment as described in - the ST. + The operational user guidance shall, for <h:s>each user role </h:s><h:b>the authorized user</h:b>, describe the security measures to be + followed in order to fulfill the security objectives for the operational environment as described in + the ST. @@ -3683,302 +3860,302 @@ - The evaluator shall confirm that the information provided meets all requirements for content and - presentation of evidence. + The evaluator shall confirm that the information provided meets all requirements for content and + presentation of evidence. - Some of the contents of the operational guidance will be verified by the evaluation activities in - Section 5.2 and evaluation of the TOE according to the CEM. The - following additional information is also required. - The operational guidance shall contain instructions for configuring the password characteristics, - number of allowed authentication attempt failures, the lockout period times for inactivity, and the - notice and consent warning that is to be provided when authenticating. - The operational guidance shall contain step-by-step instructions suitable for use by an end-user - of the VS to configure a new, out-of-the-box system into the configuration - evaluated under this Protection Profile. - The documentation shall describe the process for verifying updates to the TOE, - either by checking the hash or by verifying a digital signature. The evaluator shall verify that - this process includes the following steps: - Instructions for querying the current version of the TOE software.For hashes, a description of where the hash for a given update can be obtained. For digital - signatures, instructions for obtaining the certificate that will be used by the - FCS_COP.1/SIG mechanism to ensure that a signed update has been received from the - certificate owner. This may be supplied with the product initially, or may be obtained by - some other means.Instructions for obtaining the update itself. This should include instructions for making - the update accessible to the TOE (e.g., placement in a specific directory).Instructions for initiating the update process, as well as discerning whether the process - was successful or unsuccessful. This includes generation of the hash/digital signature. + Some of the contents of the operational guidance will be verified by the evaluation activities in + Section 5.2 and evaluation of the TOE according to the CEM. The + following additional information is also required. + The operational guidance shall contain instructions for configuring the password characteristics, + number of allowed authentication attempt failures, the lockout period times for inactivity, and the + notice and consent warning that is to be provided when authenticating. + The operational guidance shall contain step-by-step instructions suitable for use by an end-user + of the VS to configure a new, out-of-the-box system into the configuration + evaluated under this Protection Profile. + The documentation shall describe the process for verifying updates to the TOE, + either by checking the hash or by verifying a digital signature. The evaluator shall verify that + this process includes the following steps: + Instructions for querying the current version of the TOE software.For hashes, a description of where the hash for a given update can be obtained. For digital + signatures, instructions for obtaining the certificate that will be used by the + FCS_COP.1/SIG mechanism to ensure that a signed update has been received from the + certificate owner. This may be supplied with the product initially, or may be obtained by + some other means.Instructions for obtaining the update itself. This should include instructions for making + the update accessible to the TOE (e.g., placement in a specific directory).Instructions for initiating the update process, as well as discerning whether the process + was successful or unsuccessful. This includes generation of the hash/digital signature. 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. - + + As with the operational guidance, the developer should look to the evaluation activities + to determine the required content with respect to preparative procedures. + - The preparative procedures shall describe all the steps necessary for secure acceptance of the - delivered TOE in accordance with the developer’s delivery procedures. + The preparative procedures shall describe all the steps necessary for secure acceptance of the + delivered TOE in accordance with the developer’s delivery procedures. The preparative procedures shall describe all the steps necessary for secure installation of the TOE - and for the secure preparation of the operational environment in accordance with the security - objectives for the operational environment as described in the ST. + and for the secure preparation of the operational environment in accordance with the security + objectives for the operational environment as described in the ST. The evaluator shall confirm that the information provided meets all requirements for content and - presentation of evidence. + presentation of evidence. - The evaluator shall apply the preparative procedures to confirm that the TOE can be prepared securely - for operation. + 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 shall check to ensure that the guidance provided for the - TOE adequately addresses all platforms (that is, combination of hardware and - operating system) claimed for the TOE in the ST. - The operational guidance shall contain step-by-step instructions suitable for use by an end-user of - the VS to configure a new, out-of-the-box system into the configuration evaluated - under this Protection Profile. - + 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 shall check to ensure that the guidance provided for the + TOE adequately addresses all platforms (that is, combination of hardware and + operating system) claimed for the TOE in the ST. + The operational guidance shall contain step-by-step instructions suitable for use by an end-user of + the VS to configure a new, out-of-the-box system into the configuration evaluated + under this Protection Profile. +
- - At the assurance level specified for TOEs conformant to this PP, life-cycle support is limited to an examination of - the TOE vendor’s development and configuration management process in order to provide a baseline level of - assurance that the TOE itself is developed in a secure manner and that the developer has a well-defined process - in place to deliver updates to mitigate known security flaws. This is a result of the critical role that a - developer’s practices play in contributing to the overall trustworthiness of a product. - + At the assurance level specified for TOEs conformant to this PP, life-cycle support is limited to an examination of + the TOE vendor’s development and configuration management process in order to provide a baseline level of + assurance that the TOE itself is developed in a secure manner and that the developer has a well-defined process + in place to deliver updates to mitigate known security flaws. This is a result of the critical role that a + developer’s practices play in contributing to the overall trustworthiness of a product. + + The developer shall provide the TOE and a reference for the TOE. - + The TOE shall be labeled with its unique reference. - + - The evaluator shall confirm that the information provided meets all requirements for content and - presentation of evidence. - + The evaluator shall confirm that the information provided meets all requirements for content and + presentation of evidence. + - The evaluator shall check the ST to ensure that it contains an identifier (such as a product - name/version number) that specifically identifies the version that meets the requirements of the ST. - The evaluator shall check the AGD guidance and TOE samples received for testing to ensure - that the version number is consistent with that in the ST. - If the vendor maintains a website advertising the TOE, the evaluator shall examine the information on the website to ensure that - the information in the ST is sufficient to distinguish the product. + The evaluator shall check the ST to ensure that it contains an identifier (such as a product + name/version number) that specifically identifies the version that meets the requirements of the ST. + The evaluator shall check the AGD guidance and TOE samples received for testing to ensure + that the version number is consistent with that in the ST. + If the vendor maintains a website advertising the TOE, the evaluator shall examine the information on the website to ensure that + the information in the ST is sufficient to distinguish the product. The developer shall provide a configuration list for the TOE. - + The configuration list shall include the following: the TOE itself; and the - evaluation evidence required by the SARs. - + evaluation evidence required by the SARs. + The configuration list shall uniquely identify the configuration items. - + The evaluator shall confirm that the information provided meets all requirements for content and - presentation of evidence. + presentation of evidence. - The evaluator shall ensure that the developer has identified (in public-facing development - guidance for their platform) one or more development environments appropriate for use in developing - applications for the developer’s platform. For each of these development environments, the developer - shall provide information on how to configure the environment to ensure that buffer overflow protection - mechanisms in the environment are invoked (e.g., compiler and linker flags). The evaluator shall - ensure that this documentation also includes an indication of whether such protections are on by - default, or have to be specifically enabled. - The evaluator shall ensure that the TSF is uniquely identified (with respect to other products from - the TSF vendor), and that documentation provided by the developer in association with the requirements - in the ST is associated with the TSF using this unique identification. - + The evaluator shall ensure that the developer has identified (in public-facing development + guidance for their platform) one or more development environments appropriate for use in developing + applications for the developer’s platform. For each of these development environments, the developer + shall provide information on how to configure the environment to ensure that buffer overflow protection + mechanisms in the environment are invoked (e.g., compiler and linker flags). The evaluator shall + ensure that this documentation also includes an indication of whether such protections are on by + default, or have to be specifically enabled. + The evaluator shall ensure that the TSF is uniquely identified (with respect to other products from + the TSF vendor), and that documentation provided by the developer in association with the requirements + in the ST is associated with the TSF using this unique identification. + - - This component requires the TOE developer, in conjunction with any other necessary parties, to provide information - as to how the VS is 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, hardware vendors) and the steps that are performed (e.g., developer testing), including - worst case time periods, before an update is made available to the public. - - + + This component requires the TOE developer, in conjunction with any other necessary parties, to provide information + as to how the VS is 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, hardware vendors) and the steps that are performed (e.g., developer testing), including + worst case time periods, before an update is made available to the public. + + The developer shall provide a description in the TSS of how timely security updates are made to the - TOE. + TOE. The description shall include the process for creating and deploying security updates for the TOE - software/firmware. + software/firmware. 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. + of a vulnerability and the public availability of security updates to the TOE. - The total length of time may be presented as a summation of the periods of time that each party (e.g., - TOE developer, hardware vendor) on the critical path consumes. The time period until public - availability per deployment mechanism may differ; each is described. + The total length of time may be presented as a summation of the periods of time that each party (e.g., + TOE developer, hardware vendor) on the critical path consumes. The time period until public + availability per deployment mechanism may differ; each is described. The description shall include the mechanisms publicly available for reporting security issues - pertaining to the TOE. + pertaining to the TOE. - The reporting mechanism could include websites, email addresses, and 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). + The reporting mechanism could include websites, email addresses, and 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). The evaluator shall confirm that the information provided meets all requirements for content and - presentation of evidence. + presentation of evidence.
- - 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 of the primary outputs of the evaluation process is - the test report as specified in the following requirements. - + 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 of the primary outputs of the evaluation process is + the test report as specified in the following requirements. + + - - Testing is performed to confirm the functionality described in the TSS as well as the administrative (including - configuration and operation) documentation provided. The focus of the testing is to confirm that the - requirements specified in Section 5.1 are being met, although some additional testing is specified for SARs - in Section 5.2. 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. - - + + Testing is performed to confirm the functionality described in the TSS as well as the administrative (including + configuration and operation) documentation provided. The focus of the testing is to confirm that the + requirements specified in Section 5.1 are being met, although some additional testing is specified for SARs + in Section 5.2. 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. + + The developer shall provide the TOE for testing. - + The TOE shall be suitable for testing. - + The evaluator shall confirm that the information provided meets all requirements for content and - presentation of evidence. + presentation of evidence. The evaluator shall test a subset of the TSF to confirm that the TSF operates as specified. - + - The evaluator shall prepare a test plan and report documenting the testing aspects of the system. - While it is not necessary to have one test case per test listed in an evaluation activity, the - evaluators must document in the test plan that each applicable testing requirement in the - ST is covered. - The Test Plan identifies the platforms to be tested, and for those platforms not included in the test - plan but included in the ST, the test plan provides a justification for not - testing the platforms. This justification must address the differences between the tested platforms - and the untested platforms, and make an argument that the differences do not affect the testing to - be performed. It is not sufficient to merely assert that the differences have no affect; rationale - must be provided. If all platforms claimed in the ST are tested, then no - rationale is necessary. - The test plan describes the composition of each platform to be tested, and any setup that is necessary - beyond what is contained in the AGD documentation. It should be noted that the evaluators are - expected to follow the AGD documentation for installation and setup of each platform either as - part of a test or as a standard pre-test condition. This may include special test drivers or - tools. For each driver or tool, an argument (not just an assertion) is provided that the driver or - tool will not adversely affect the performance of the functionality by the TOE and its platform. - This also includes the configuration of cryptographic engines to be used. The cryptographic - algorithms implemented by these engines are those specified by this PP and used by the - cryptographic protocols being evaluated (IPsec, TLS/HTTPS, 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 a - cumulative account, so if there was a test run that resulted in a failure; a fix installed; and - then a successful re-run of the test, the report would show a “fail” and “pass” result (and the - supporting details), and not just the “pass” result. - + The evaluator shall prepare a test plan and report documenting the testing aspects of the system. + While it is not necessary to have one test case per test listed in an evaluation activity, the + evaluators must document in the test plan that each applicable testing requirement in the + ST is covered. + The Test Plan identifies the platforms to be tested, and for those platforms not included in the test + plan but included in the ST, the test plan provides a justification for not + testing the platforms. This justification must address the differences between the tested platforms + and the untested platforms, and make an argument that the differences do not affect the testing to + be performed. It is not sufficient to merely assert that the differences have no affect; rationale + must be provided. If all platforms claimed in the ST are tested, then no + rationale is necessary. + The test plan describes the composition of each platform to be tested, and any setup that is necessary + beyond what is contained in the AGD documentation. It should be noted that the evaluators are + expected to follow the AGD documentation for installation and setup of each platform either as + part of a test or as a standard pre-test condition. This may include special test drivers or + tools. For each driver or tool, an argument (not just an assertion) is provided that the driver or + tool will not adversely affect the performance of the functionality by the TOE and its platform. + This also includes the configuration of cryptographic engines to be used. The cryptographic + algorithms implemented by these engines are those specified by this PP and used by the + cryptographic protocols being evaluated (IPsec, TLS/HTTPS, 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 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. +
- - For the first generation of this Protection Profile, the evaluation lab is expected to survey open sources to learn - 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, evaluators 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 PPs. - + For the first generation of this Protection Profile, the evaluation lab is expected to survey open sources to learn + 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, evaluators 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 PPs. + + The developer shall provide the TOE for testing. - + The TOE shall be suitable for testing. - + The evaluator shall confirm that the information provided meets all requirements for content and - presentation of evidence. + presentation of evidence. The evaluator shall perform a search of public domain sources to identify potential vulnerabilities - in the TOE. + in the TOE. The evaluator shall conduct penetration testing, based on the identified potential vulnerabilities, - to determine that the TOE is resistant to attacks performed by an attacker possessing Basic attack - potential. + to determine that the TOE is resistant to attacks performed by an attacker possessing Basic attack + potential. As with ATE_IND the evaluator shall generate a report to document their findings with respect - to this requirement. This report could physically be part of the overall test report mentioned in - ATE_IND, or a separate document. The evaluator performs a search of public information to determine - the vulnerabilities that have been found in virtualization in general, as well as those that pertain - to the particular TOE. The evaluator documents the sources consulted and the - vulnerabilities found in the report. For each vulnerability found, the evaluator either provides a - rationale with respect to its non-applicability or the evaluator formulates a test (using the - guidelines provided in ATE_IND) to confirm the vulnerability, if suitable. Suitability is determined - by assessing the attack vector needed to take advantage of the vulnerability. For example, if the - vulnerability can be detected by pressing a key combination on boot-up, a test would be suitable at - the assurance level of this PP. If exploiting the vulnerability requires expert skills and an electron - microscope, for instance, then a test would not be suitable and an appropriate justification would be - formulated. - + to this requirement. This report could physically be part of the overall test report mentioned in + ATE_IND, or a separate document. The evaluator performs a search of public information to determine + the vulnerabilities that have been found in virtualization in general, as well as those that pertain + to the particular TOE. The evaluator documents the sources consulted and the + vulnerabilities found in the report. For each vulnerability found, the evaluator either provides a + rationale with respect to its non-applicability or the evaluator formulates a test (using the + guidelines provided in ATE_IND) to confirm the vulnerability, if suitable. Suitability is determined + by assessing the attack vector needed to take advantage of the vulnerability. For example, if the + vulnerability can be detected by pressing a key combination on boot-up, a test would be suitable at + the assurance level of this PP. If exploiting the vulnerability requires expert skills and an electron + microscope, for instance, then a test would not be suitable and an appropriate justification would be + formulated. +
@@ -3992,9 +4169,9 @@ CEM Common - Evaluation Methodology for Information Technology Security - Evaluation Methodology, - CCMB-2017-04-004, Version 3.1, Revision 5, April 2017. - + Evaluation Methodology for Information Technology Security - Evaluation Methodology, + CCMB-2017-04-004, Version 3.1, Revision 5, April 2017. + - + \ No newline at end of file