The purpose of the Protection Profile for Encrypted Retransmission Devices is to provide requirements for data-in-transit
protection between two end-user devices communicating over an untrusted domain (aka “Black Transport Networks”). The form
factors may vary according to the needs of the mission and the specific supported end-user devices.
Data-in-transit protection encrypts all data which originates from or is sent to an end-user device. Since a retransmission
device could be any number of configurations, two PPs describe the requirements for the ERD components described in section 2.
This PP covers devices which meet one of three use cases: Encryption Unit (EU), Communication Unit (CU), or a combined EU+CU
1.2 Terms
The following sections list Common Criteria and technology terms used in this document.
1.2.1 Common Criteria Terms
Assurance
Grounds for confidence that a TOE meets the SFRs [CC].
Base Protection Profile (Base-PP)
Protection Profile used as a basis to build a PP-Configuration.
Collaborative Protection Profile (cPP)
A Protection Profile developed by
international technical communities and approved by multiple schemes.
Common Criteria (CC)
Common Criteria for Information Technology Security Evaluation (International Standard ISO/IEC 15408).
Common Criteria Testing Laboratory
Within the context of the Common Criteria Evaluation and Validation Scheme (CCEVS), an IT security evaluation facility
accredited by the National Voluntary Laboratory Accreditation Program (NVLAP) and approved by the NIAP Validation Body to conduct Common Criteria-based evaluations.
Common Evaluation Methodology (CEM)
Common Evaluation Methodology for Information Technology Security Evaluation.
Distributed TOE
A TOE composed of multiple components operating as a logical whole.
Extended Package (EP)
A deprecated document form for collecting SFRs that implement a particular protocol, technology,
or functionality. See Functional Packages.
Functional Package (FP)
A document that collects SFRs for a particular protocol, technology,
or functionality.
Operational Environment (OE)
Hardware and software that are outside the TOE boundary that support the TOE functionality and security policy.
Protection Profile (PP)
An implementation-independent set of security requirements for a category of products.
A comprehensive set of security requirements for a product type that consists of at least one Base-PP and at least one PP-Module.
Protection Profile Module (PP-Module)
An implementation-independent statement of security needs for a TOE type complementary to one or more Base-PPs.
Security Assurance Requirement (SAR)
A requirement to assure the security of the TOE.
Security Functional Requirement (SFR)
A requirement for security enforcement by the TOE.
Security Target (ST)
A set of implementation-dependent security requirements for a specific product.
Target of Evaluation (TOE)
The product under evaluation.
TOE Security Functionality (TSF)
The security functionality of the product under evaluation.
TOE Summary Specification (TSS)
A description of how a TOE satisfies the SFRs in an ST.
1.2.2 Technical Terms
Address Space Layout Randomization (ASLR)
An anti-exploitation feature which loads memory mappings into unpredictable
locations. ASLR makes it more difficult for an attacker to redirect control to code
that they have introduced into the address space of an application process.
Application (app)
Software that runs on a platform and performs tasks on behalf of
the user or owner of the platform, as well as its supporting documentation. The
terms TOE and application are interchangeable in this document.
Application Programming Interface (API)
A specification of routines, data structures, object classes, and variables
that allows an application to make use of services provided by another software
component, such as a library. APIs are often provided for a set of libraries included
with the platform.
Credential
Data that establishes the identity of a user, e.g. a cryptographic key or password.
Data Execution Prevention (DEP)
An anti-exploitation feature of modern operating systems executing on
modern computer hardware, which enforces a non-execute permission on pages of memory.
DEP prevents pages of memory from containing both data and instructions, which makes
it more difficult for an attacker to introduce and execute code.
Developer
An entity that writes application software. For the purposes of this
document, vendors and developers are the same.
Encrypting Retransmission Device (ERD)
An RD with the additional capability to encrypt all traffic from the EUD through the
LAN interface to form an encrypted tunnel to another encryption end-point through the
ERD’s WAN interface.
An HWS-ERD will encrypt traffic between two endpoints while maintaining a defined physical
and logical protocol break between the trusted and the untrusted trusted domains. The
protocol break will be both physically and logically enforced.
Mobile Code
Software transmitted from a remote system for
execution within a limited execution environment on the local system.
Typically, there is no persistent installation and
execution begins without the user's consent or even notification.
Examples of mobile code technologies include JavaScript, Java applets, Adobe Flash,
and Microsoft Silverlight.
Operating System (OS)
Software that manages hardware resources and provides services for
applications.
Personally Identifiable Information (PII)
Any information about an individual maintained by an agency, including, but
not limited to, education, financial transactions, medical history, and criminal or
employment history and information which can be used to distinguish or trace an
individual's identity, such as their name, social security number, date and place of
birth, mother’s maiden name, biometric records, etc., including any other personal
information which is linked or linkable to an individual. [OMB]
Platform
The environment in which application software runs.
The platform can be an operating system, hardware environment, a software based execution environment,
or some combination of these. These types of platforms may also run atop other platforms.
Retransmission Device (RD)
A lightweight computing device that acts as both a retransmission device and a boundary.
The RD sits between an EUD and the untrusted transport network. The interconnect between the
EUD and the RD is always a wired connection.
Sensitive Data
Sensitive data may include all user or enterprise data or may be
specific application data such as emails, messaging, documents,
calendar items, and contacts. Sensitive data must minimally include
PII, credentials, and keys. Sensitive data shall be identified in
the application’s TSS by the ST author.
Stack Cookie
An anti-exploitation feature that places a value on the stack at the start
of a function call, and checks that the value is the same at the end of the function
call. This is also referred to as Stack Guard, or Stack Canaries.
Vendor
An entity that sells application software. For purposes of this document,
vendors and developers are the same. Vendors are responsible for maintaining and
updating application software.
1.3 Compliant Targets of Evaluation
1.3.1 TOE Overview
An encrypting retransmission device (ERD) consists of two computing units: the encryption unit (EU) and the communication unit (CU),
interconnected by one connectionless bus (IC 3) that carries stateless frames. A conformant TOE may meet the requirements of either
EU or CU alone, or together in one physical enclosure.
Within an ERD, each EU establishes an encrypted tunnel between itself and a peer (or potentially “gateway”) EU on the other side of the
untrusted domain and behind the remote CU. On the local side, the EU will receive frames from its paired end user device (EUD) and encrypt
them before sending them to the CU, which will process the frame and send it across the untrusted domain to an ERD on the other side. There,
the peer ERD’s EU will decrypt the frame and determine to either send the frame to the EUD or to the controller running in the EU. While EU to
EU tunnels are pairwise, CU’s may have a one-to-many relationship among EUs.
There shall be no other interfaces to the external world attached to the EU, (e.g., camera, microphone, radio, etc.). There shall be no additional
interfaces to the CU except to configure it or to connect it to the transport medium to its peer ERD. All traffic between the EUD and the CU must
go through the EU. There shall be no cryptographic or communications bypass, which would permit the EUD to communicate except through the EU and CU.
1.3.2 TOE Boundary
This PP is written to apply only to the Encryption Unit (EU). It is meant to be used in conjunction with a matching device
certified against the CUPP, PP_RD_CU. Conformant TOEs may also evaluate against both PPs.
1.3.3 TOE Description
1.3.3.1 Encryption Unit
The EU provides cryptographic protection services for traffic originating from or destined to an EUD.
EU Characteristics
Connects to an EUD via Ethernet or Ethernet-over-USB.
Implements one selectable encryption option from the following set.
IPsec
MACsec
PFED
Only the selected encryption option is enabled and active in a given TOE configuration.
Does not implement routing functionality.
Does not implement Layer-3/Layer-4 firewalling.
Implements stateless Layer-2 traffic filtering when MACsec or PFED is selected, limited to Ethernet
frame attributes (e.g., EtherType, source/destination MAC address).
When MACsec or PFED is selected, the EU presents a non-addressable Ethernet interface toward the CU
(i.e., no IP address or higher-layer protocol termination is supported on the EU–CU interface).
Does not provide direct connectivity to untrusted networks and cannot be bypassed..
1.3.3.2 Communication Unit
The CU provides isolation between trusted components and untrusted Black Transport Networks and represents the
minimum TOE configuration supported by this Protection Profile.
The CU provides routing and isolation services between trusted and untrusted networks.
When the EU implements IPsec, the CU routes IPsec-protected IP packets and performs a Layer-2 protocol break for isolation.
The CU does not terminate IPsec security associations.
When the EU implements MACsec or PFED, the CU forwards or transports already-encrypted Ethernet frame or packet traffic
across untrusted networks without terminating, decrypting, or re-originating cryptographic protection, and without performing
a Layer-2 protocol break that would disrupt cryptographic continuity.
The CU does not implement cryptographic services for MACsec or PFED traffic and forwards already-encrypted traffic when
those options are selected.
In all TOE configurations, the CU does not act as a cryptographic endpoint for user data traffic. The CU routes or forwards
already-encrypted traffic across untrusted Black Transport Networks without terminating, decrypting, or re-originating cryptographic
protection.
Protocol Break Definition:
A protocol break is the stripping (decapsulation) and replacement (encapsulation) of Layer-2 headers when
forwarding traffic between interfaces, preventing transparent bridging across trust
boundaries.
Protocol Break Applicability:
The protocol break shall be enforced by the CU when the EU implements IPsec or when no EU is present (CU-only TOE).
The protocol break shall NOT be enforced by the CU when the EU implements MACsec or PFED, as these mechanisms require preservation of
Layer-2 continuity between the EU and CU.
1.4 Use Cases
[USE CASE 1] Dedicated Communications Unit (CU) Retransmission Device (CU-Only)
The TOE is a retransmission device that only provides network transport and routing functionality, as well
as hardware isolation between trusted components and untrusted Black Transport Networks.
[USE CASE 2] Dedicated Encrytpion Unit (EU) Retransmission Device (EU-Only)
The TOE is a retransmission device that provides hardware isolation between the EUD and untrusted Black
Transport Networks, as well as capability to encrypt all traffic from the EUD to form an encrypted tunnel to another
encryption end-point. This use case is limited to Wireless LAN encryption implementations
(i.e., dedicated WLAN encryption component). CU only is the RD use case, EU+CU is the HWS-ERD use case
The ERD use case doesn’t exist as a separate thing (rolled into HWS-ERD now), nor is “EU only” a valid use case
[USE CASE 3] Hardware-Separated Encrypting Retransmission Device (HWS-ERD
The TOE is a retransmission device composed of a hardware-separated EU and CU.
The EU and CU are implemented as distinct hardware components with independent processors and memory.
Communication between the EU and CU occurs only via a dedicated wired interface.
The EU is solely responsible for cryptographic processing of the EUD payload.
The CU is solely responsible for routing or transport of encrypted traffic and isolation from untrusted networks.
1.5 Product Features Mapped to Implementation-Dependent Requirements
A conformant TOE may implement either IPsec, MACsec, PFED, or WLAN for data in transit encryption in the EU. Depending on which is
supported, different requirements will apply to the TOE as they each implement different methods of protection of data in transit.
The evaluation methods used for evaluating the TOE are a combination of the workunits
defined in [CEM] as well as the Evaluation Activities for ensuring that individual SFRs
and SARs have a sufficient level of supporting evidence in the Security Target and guidance
documentation and have been sufficiently tested by the laboratory as part of completing
ATE_IND.1. Any functional packages this PP claims similarly contain their own Evaluation
Activities that are used in this same manner.
CC Conformance Claims
This PP is conformant to
Part 2 (extended)
and Part 3 (extended)
of Common Criteria CC:2022, Revision 1.
PP Claim
This PP does not claim conformance to
any Protection Profile.
The following PPs and PP-Modules are allowed to be specified in a
PP-Configuration with this PP:
Package Claim
This PP is
***UPDATE WITH APPLICABLE PACKAGES conformant.
This PP does not conform to any
assurance packages.
The functional packages to which the PP conforms may include SFRs that are not mandatory
to claim for the sake of conformance. An ST that claims one or more of these functional
packages may include any non-mandatory SFRs that are appropriate to claim based on the
capabilities of the TSF and on any triggers for their inclusion based inherently on the SFR
selections made.
3 Security Problem Definition
The security problem is described in terms
of the threats that the TOE is expected to address, assumptions about the
operational environment, and any organizational security policies that the TOE
is expected to enforce.
This section needs to be updated and mapping completed.
3.1 Threats
T.TBD_TBD
TBD
3.2 Assumptions
This section needs to be updated and mapping completed.
A.TBD
TBD
4 Security Objectives
This section needs to be updated and mapping completed.
4.1 Security Objectives for the Operational Environment
The following security objectives for the operational
environment assist the TOE in correctly providing its security
functionality. These track with the assumptions about the environment.
OE.TBD
TBD
4.2 Security Objectives Rationale
This section describes how the assumptions and organizational
security policies map to operational environment security objectives.
This chapter describes the security requirements which have to be fulfilled by the product under evaluation.
Those requirements comprise functional components from Part 2 and assurance components from Part 3 of
[CC].
The following conventions are used for the completion of operations:
Refinement operation (denoted by bold text or strikethrough
text): Is used to add details to a requirement or to remove part of the requirement that is made irrelevant
through the completion of another operation, and thus further restricts a requirement.
Selection (denoted by italicized text): Is used to select one or more options
provided by the [CC] in stating a requirement.
Assignment operation (denoted by italicized text): Is used to assign a
specific value to an unspecified parameter, such as the length of a password. Showing the
value in square brackets indicates assignment.
Iteration operation: Is indicated by appending the SFR name with a slash and unique identifier
suggesting the purpose of the operation, e.g. "/EXAMPLE1."
5.1 Security Functional Requirements
5.1.1 Auditable Events for Mandatory SFRs
Table 2: Auditable Events for Mandatory Requirements
Additional information defined in the audit table for the TBD
Additional information defined in the audit table for the TBD
no other information
].
Application
Note:
The ST Author should include this SFR in the ST if the TOE generates audit events for integrity verification
or boot failures as indicated by the appropriate selections in FPT_ROT_EXT.2, FPT_ROT_EXT.3,
FPT_TUD_EXT.2, or FPT_TUD_EXT.3.4.
If this SFR is included in the ST, then all the other FAU SFRs must also be claimed.
Appropriate entries from Table t-audit-optional, Table t-audit-objective, and
Table t-audit-sel-based should be included in the ST if the
associated SFRs and selections are included.
Specific auditable events required for SFRs from the functional packages are defined in the respective packages.
The evaluator shall check the TSS and ensure that it lists all of the auditable events
and provides a format for audit records. Each audit record format type shall be covered, along with a
brief description of each field.
Guidance
The evaluator shall also make a determination of the administrative actions that are relevant in the
context of this PP. The evaluator shall examine the AGD and make a determination of which
administrative commands, including subcommands, scripts, and configuration files, are related to the
configuration (including enabling or disabling) of the mechanisms implemented in the TOE
that are necessary to enforce the requirements claimed in the ST. The evaluator shall document the
methodology or approach taken while determining which actions in the AGD are
security-relevant with respect to this PP.
Tests
The evaluator shall test the TOE’s ability to correctly generate audit records by
having the TOE generate audit records for the events listed and administrative actions.
For administrative actions, the evaluator shall test that each action determined by the evaluator above to
be security relevant in the context of this PP is auditable. When verifying the test results, the
evaluator shall ensure the audit records generated during testing match the format specified in the
administrative guide, and that the fields in each audit record have the proper entries.
Note that the testing here can be accomplished in conjunction with the testing of the security mechanisms
directly.
There are no additional TSS evaluation activities for this component.
Guidance
The evaluator shall review the AGD for the procedure on how to review the audit
records.
Tests
The evaluator shall verify that the audit records provide all of the information specified in
FAU_GEN.1 and that this information is suitable for human interpretation. The evaluation
activity for this requirement is performed in conjunction with the evaluation activity for
FAU_GEN.1.
The TSF shall be able to[selection: store audit data on the TOE itself, transmit audit data to an external IT entity using a trusted
channel in accordance with FTP_ITC_EXT.1]
Application
Note:
The ST Author selects "trusted channel" and includes FTP_ITC_EXT.1 in the ST if the TOE offloads
audit data to external IT entity over a network connection. Protocols used for implementing the trusted
channel must be selected 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.
Guidance
If "trusted channel" is selected above, the evaluator shall examine the AGD 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. Furthermore, it must describe whether the
transfer mechanism is periodic or continuous, and what happens in the event of a loss of connectivity.
Tests
If "trusted channel" is selected above, testing of the trusted channel mechanism itself is to be performed as specified in the
evaluation activities for FTP_ITC_EXT.1. In addition, the evaluator must perform the
following test:
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.
The TSF shall be able to [prevent] unauthorized modifications to the stored audit data
in the audit trail.
Application
Note:
Deletion of audit data within the TOE is "authorized" if the deletion is initiated or performed by
an Administrator.
Notwithstanding this requirement, audit records may be overwritten if local audit record storage is full
in accordance with FAU_STG.5.
This SFR must be included in the ST if FAU_GEN.1 is claimed.
The evaluator shall ensure that the TSS lists the locations of all logs and the access
controls of those files such that unauthorized modification and deletion are prevented.
Guidance
The evaluator shall ensure that the Guidance describes the steps necessary for an authorized
administrator to delete audit records, if such a capability is implemented.
Tests
The evaluator shall perform the following tests:
Test FAU_STG.2:1:
[conditional] If the TOE implements an audit record deletion capability, then
the evaluator shall attempt to delete the audit trail in a manner that the access
controls should prevent (as an unauthorized user) and shall verify that the attempt
fails.
Test FAU_STG.2:2:
The evaluator shall attempt to modify the audit trail in a manner that the access
controls should prevent (as an unauthorized application) and shall verify that the
attempt fails.
The TSF shall optionally notify the administrator or user that storage is full and
[overwrite the oldest stored audit records] if the audit data storage is full.
The evaluator shall examine the TSS to ensure that it describes the size limits on the
audit records, the detection of a full audit trail, and the action(s) taken by the TSF
when the audit trail is full. The evaluator shall ensure that the action(s) results in the
deletion or overwrite of the oldest stored record.
Guidance
The evaluator shall examine the AGD to ensure that it describes the means used by the TOE
to indicate that the audit trail is full and overwrite is about to commence.
Tests
The evaluator shall cause audit records to be written until the size limits are met and exceeded.
The evaluator shall verify that the overwrite function works as described in the TSS and that the
indication of full audit trail is evident as described in the AGD.
The TSF shall be able to generate evidence of origin for transmitted [assignment:
list of information types] at the
request of the [selection: originator, recipient, [assignment:
list of third parties]].
The TSF shall be able to relate the [assignment:
list of attributes] of the originator of the information, and the
[assignment:
list of information fields] of the information to which the evidence applies.
The TSF shall provide a capability to verify the evidence of origin of information to [selection: originator, recipient, [assignment:
list of third parties]] given [assignment:
limitations on the evidence of origin].
The TSF shall be able to generate evidence of receipt for received [assignment:
list of information typles]at the request
of the [selection: originator, recipient, [assignment:
list of third parties]].
The TSF shall be able to relate the [assignment:
list of attributes] of the recipient of the information, and the
[assignment:
list of information fields] of the information to which the evidence applies.
The TSF shall provide a capability to verify the evidence of receipt of information to [selection: originator, recipient, [assignment:
list of third parties]] given [assignment:
limitations on the evidence of receipt].
The TSF shall be able to generate evidence of receipt for received [authentication requests,
[selection: authentication responses and queries, none]] at the request of the [originator].
Application
Note:
The intent of this requirement is for the TOE to be able to return a valid response to the relying party upon receipt of an Access-Request.
If the TSF supports pass-through functionality, the ST author claims ‘authentication responses and queries’
in the selection for authentication in communications with external authentication servers.
The TSF shall be able to relate the [claimant identifier and claimant authenticators] of the recipient of the information, and the
[identity assertion, information requests, and error responses] of the information to which the evidence applies.
Application
Note:
The intent of this requirement is for the ST author to list the information supplied by the TOE in response to an authentication request that confirms
receipt of the request, and identifies:
the authentication request that is being responded to;
the mutually authenticated channel between the trusted relying party and the TOE.
The TSF shall provide a capability to verify the evidence of receipt of information to
[originator] given [establishment of a mutually authenticated channel with a trusted relying party].
The evaluator shall ensure that the ST includes a description of each messaging protocol and the specific messages provided to a relying party in
response to authentication requests,
to include any affirmative and negative responses, and requests for additional information.
The evaluator shall verify that the descriptions specify how the TSF indicates the identity of the claimant associated with any responses to a
request.
The evaluator shall verify that the ST describes how the TSF handles session interruptions and resumptions to ensure the relying party is able to
associate data
associated with a claimant to the authentication request by the relying party and the authenticator provided by the claimant.
Guidance
The evaluator shall ensure that any instructions for configuring the TSF to meet the requirements are provided.
Tests
For each messaging protocol supported, the evaluator shall perform the following test:
Test FCO_NRR.1:1:
The evaluator shall establish a connection between a trusted relying party and the TOE and send an authentication request for a registered
claimant, in accordance with the messaging protocol standard.
The evaluator shall confirm the TOE responds to each message sent by the relying party with a message that appropriately identifies the
claimant and confirms receipt of the request.
The TSF shall derive shared cryptographic keys with input from multiple parties in accordance
with specified cryptographic key agreement algorithms
[selection:
Cryptographic algorithm]
and specified cryptographic parameters
[selection:
Cryptographic parameters]
that meet the following:
[selection:
List of standards]
The following table provides the allowable choices for
completion of the selection operations of FCS_CKM_EXT.7.
Application
Note:
All of the above algorithms with the selectable parameters are CNSA 1.0 compliant.
This SFR must be included in the ST if key agreement or transport is a service provided by the TOE to
tenant software, or if they are used by the TOE itself to support or implement PP-specified security
functionality.
If this SFR is claimed, then FCS_CKM.6 an FCS_CKM.1/AKG must also be claimed.
This SFR has dependencies on FCS_COP.1/Hash and FCS_COP.1/XOF only if ML-KEM is selected.
The evaluator shall ensure that the TSS documents that the security strength of the
material contributed by the TOE is sufficient for the security strength of the key and the
agreement method.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The following tests are conditional based upon the selections made in the SFR.
The evaluator shall perform the following test or witness respective tests
executed by the developer. The tests must be executed on a platform that is as
close as practically possible to the operational platform (but which may be
instrumented in terms of, for example, use of a debug mode). Where the test is
not carried out on the TOE itself, the test platform shall be identified and the
differences between test environment and TOE execution environment shall be
described.
KAS2
To test the TOE’s implementation of the of the KAS2 RSA Key Agreement scheme, the evaluator
shall perform the Algorithm Functional Test and Validation Test using the
following input parameters:
RSA Private key format [Basic, Prime Factor, Chinese Remainder Theorem]
Modulo value [3072, 4096, 6144, 8192]
Role [initiator, responder]
The evaluator shall generate a test group (i.e. set of tests) for each parameter
value of the above parameter type with the largest number of supported values.
For example, if the TOE supports all five Modulo values, then the evaluator
shall generate five test groups. Each of the above supported parameter values
must be included in at least one test group.
Regardless of how many parameter values are supported, there must be at least two
test groups.
Half of the test groups are designated as Algorithm Functional Tests (AFT) and the
remainder are designated as Validation Tests (VAT). If there is an odd number of
groups, then the extra group is designated randomly as either AFT or VAT.
Algorithm Functional Test
For each test group designated as AFT, the evaluator shall generate 10 test
cases using random data (except for a fixed public exponent, if supported).
The resulting shared secrets shall be compared with those generated by a
known-good implementation using the same inputs.
Validation Test
For each test group designated as VAT, the evaluator shall generate 25 test cases are
using random data (except for a fixed public exponent, if supported). Of the 25
test cases:
Two test cases must have a shared secret with a leading nibble of 0s,
Two test cases have modified derived key material,
Two test cases have modified tags, if key confirmation is supported,
Two test cases have modified MACs, if key confirmation is supported, and
The remaining test cases are not modified.
To determine correctness, the evaluator shall confirm that the resulting 25 shared
secrets correspond as expected for both the modified and unmodified values.
FFC Diffie-Hellman Key Agreement
Identifier
Cryptographic Algorithm
Cryptographic Parameters
List of Standards
DH
Finite Field Cryptography Diffie-Hellman
Static domain parameters approved for [selection:
IKE groups [selection: MODP-3072, MODP-4096,
MODP-6144, MODP-8192], TLS groups [selection:
ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192]]]
To test the TOE’s implementation of FFC Diffie-Hellman Key Agreement, the evaluator shall
perform the Algorithm Functional Test and Validation Test using the following
input parameters:
Algorithm Functional Test
For each supported domain parameter group, the evaluator shall generate 10 test
cases by generating the initiator and responder secret keys using random data,
calculating the responder public key, and creating the shared secret. The
resulting shared secrets shall be compared with those generated by a known-good
implementation using the same inputs.
Validation Test
For each supported combination of the above parameters the evaluator shall
generate 15 Diffie Hellman initiator/responder key pairs using the key generation
function of a known-good implementation. For each set of key pairs, the
evaluator shall modify five initiator private key values. The remaining key
values are left unchanged (i.e., correct). To determine correctness, the
evaluator shall confirm that the 15 shared secrets correspond as expected for
both the modified and unmodified inputs.
Elliptic Curve Diffie-Hellman Key Agreement
To test the TOE’s implementation of Elliptic Curve Diffie-Hellman Key Agreement,
the evaluator shall perform the Algorithm Functional Test and Validation Test
using the following input parameters:
Elliptic Curve [P-384, P-521]
Algorithm Functional Test
For each supported Elliptic Curve the evaluator shall generate 10 test cases by
generating the initiator and responder secret keys using random data, calculating
the responder public key, and creating the shared secret. The resulting shared
secrets shall be compared with those generated by a known-good implementation using
the same inputs.
Validation Test
For each supported Elliptic Curve the evaluator shall generate 15 Diffie Hellman
initiator/responder key pairs using the key generation function of a known-good
implementation. For each set of key pairs, the evaluator shall modify five
initiator private key values. The remaining key values are left unchanged (i.e.,
correct). To determine correctness, the evaluator shall confirm that the 15
shared secrets correspond as expected for the modified and unmodified values.
The TSF shall provide
[selection: mutable hardware-based, immutable hardware-based, software-based] protected storage for asymmetric private keys, [symmetric keys, and persistent secrets].
Application
Note:
If the protected storage is implemented in software that is protected as required by FCS_STG_EXT.2, the ST Author is expected to select
"software-based." If "software-based" is selected, the ST Author is expected to select "software-based key storage" in FCS_STG_EXT.2 and
also claim FCS_STG_EXT.3.
If this SFR is included in the ST, then FCS_CKM.6 must also be claimed.
causing the TOE to generate
[selection: asymmetric, symmetric]keys/secrets
] upon request of
[selection: a client application, an administrator].
Application
Note:
If "causing the TOE to generate keys/secrets" is selected in FCS_STG_EXT.1.2, then the
ST must include at least one of FCS_CKM.1/AKG or FCS_CKM.1/SKG depending on the value of the
internal selection.
The TSF shall have the capability to allow only the application that imported the key or secret the use of the key or secret. Exceptions may only be
explicitly authorized by [selection: the user, the administrator, a common application developer].
The TSF shall allow only the application that imported the key or secret to request that the key or secret be destroyed. Exceptions may only be
explicitly authorized by [selection: the user, the administrator, a common application developer].
The evaluator shall review the TSS to determine that the TOE implements the
required protected storage. The evaluator shall ensure that the TSS contains a
description of the protected storage mechanism that justifies the selection of
mutable hardware-based or software-based.
Guidance
The evaluator shall examine the AGD to ensure that it describes the
process for generating keys, importing keys, or both, based on what is claimed by
the ST. The evaluator shall also examine the AGD to ensure that it
describes the process for destroying keys that have been imported or generated.
Tests
The evaluator shall test the functionality of each security function as described
below. If the TOE supports both import and generation of keys, the evaluator shall
repeat the testing as needed to demonstrate that the keys resulting from both
operations are treated in the same manner. The devices used with the tooling may
need to be non-production devices in order to enable the execution of testing and gathering of
evidence.
Test FCS_STG_EXT.1:1:
The evaluator shall import or generate keys/secrets of each supported type
according to the operational guidance. The evaluator shall write, or the developer
shall provide access to, an application that generates a key/secret of each supported
type and calls the import functions. The evaluator shall verify that no errors occur
during import.
Test FCS_STG_EXT.1:2:
The evaluator shall write, or the developer shall provide access to,
tenant software that uses a generated or imported key/secret:
The evaluator shall verify that the tenant software is able to access and
use the key/secret as described.
Test FCS_STG_EXT.1:3:
The evaluator shall destroy keys/secrets of each supported type according to the operational guidance. The evaluator shall write, or the
developer shall provide access to, tenant software that destroys an imported or generated key/secret. The evaluator shall verify that the
tenant software is able to cause the deletion of only keys that were created or imported on its behalf.
The TSF shall enforce the [assignment: information flow control SFP] on [assignment: list of
subjects and information] and all operations that cause that information to flow to and from
subjects covered by the SFP.
The TSF shall ensure that all operations that cause any information in the TOE to flow
to and from any subject in the TOE are covered by an information flow control SFP.
The TSF shall explicitly authorize an information flow based on the following rules:
[assignment:
rules, based on security attributes, that explicitly authorize information
flows].
The TSF shall explicitly deny an information flow based on the following rules:
[assignment:
rules, based on security attributes, that explicitly deny information
flows].
The TSF shall enforce the [assignment: information flow control SFP] based on the following types of subject and
information security attributes: [assignment: list of subjects and information controlled under the indicated SFP,
and for each, the security attributes].
The TSF shall permit an information flow between a controlled subject and controlled information via a controlled
operation if the following rules hold: [assignment: for each operation, the security attribute-based relationship that
hold between subject and information security attributes].
The TSF shall explicitly authorize an information flow based on the following rules:
[assignment: rules, based on security attributes, that explicitly authorize information flows].
The TSF shall explicitly deny an information flow based on the following rules:
[assignment: rules, based on security attributes, that explicitly deny information flows].
The evaluator shall ensure the TSS describes the Trust Anchor Database
implemented that contain certificates used to meet the requirements of this PP. This
description shall contain information pertaining to how certificates are loaded into
the store, and how the store is protected from unauthorized access (for example,
UNIX permissions) in accordance with the permissions established in FMT_SMF_EXT.1
and FMT_MOF_EXT.1.1.
Guidance
There are no additional Guidance evaluation activities for this component.
The TSF shall support the following for the Password Authentication Factor:
Passwords shall be able to be composed of any combination of
[selection: upper and lower case letters, [assignment:
a character set of at least 52 characters]], numbers, and special characters:
[selection: "!", "@", "#", "$", "%", "^", "&", "*", "(", ")", [assignment:
other characters]]
Password length up to
[assignment:
an integer greater than or equal to 14] characters shall be
supported.
Application
Note:
While some corporate policies require passwords of 14 characters or better, the use of a Root
Encryption Key for DAR protection and key storage protection and the anti-hammer requirement (FIA_TRT_EXT.1)
addresses the threat of attackers with physical access using much smaller and less complex
passwords.
The ST Author selects the character set: either the upper and lower case Basic Latin letters
or another assigned character set containing at least 52 characters. The assigned character
set must be well defined: either according to an international encoding standard (such as
Unicode) or defined in the assignment by the ST Author. The ST Author also selects the special
characters that are supported by TOE; they may optionally list additional special characters
supported using the assignment.
There are no additional TSS evaluation activities for this component.
Guidance
The evaluator shall examine the operational guidance to determine that it provides
guidance to security administrators on the composition of strong passwords, and that it
provides instructions on setting the minimum password length. The evaluator shall also
perform the following tests. Note that one or more of these tests can be performed with a
single test case.
Tests
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
compositions 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 TSF shall limit automated user authentication attempts by [selection: preventing authentication via
an external port, enforcing a delay between incorrect authentication attempts] for all authentication mechanisms
selected in FIA_UAU.5.1. The minimum delay shall be such that no more than 10 attempts can be attempted per 500
milliseconds.
Application
Note:
The authentication throttling applies to all authentication mechanisms selected in FIA_UAU.5.1. The user authentication
attempts in this requirement are attempts to guess the Authentication Factor. The developer can implement the timing of
the delays in the requirements using unequal or equal timing of delays. The minimum delay specified in this requirement
provides defense against brute forcing.
The evaluator shall verify that the TSS describes the method by which authentication attempts are not able to be
automated. The evaluator shall ensure that the TSS describes either how the TSF disables authentication via external
interfaces (other than the ordinary user interface) or how authentication attempts are delayed in order to slow
automated entry and shall ensure that this delay totals at least 500 milliseconds over 10 attempts for all authentication
mechanisms selected in FIA_UAU.5.1.
Guidance
There are no additional Guidance evaluation activities for this component.
The TSF shall require each user to be successfully authenticated before allowing
any other TSF-mediated actions on behalf of that user.
Application
Note:
The security relevant actions allowed by unauthorized users in
locked state must be listed. At a minimum the actions that correspond to the functions
available to the user in FMT_SMF_EXT.1 and are allowed by unauthorized users in locked
state should be listed. For example, if the user can enable/disable the camera per
function of FMT_SMF_EXT.1 and unauthorized users can
take a picture when the device is in locked state, this action must be listed.
The evaluator shall verify that the TSS describes the actions allowed by
unauthorized users in the locked state.
Guidance
There are no guidance evaluation activities for this component.
Tests
The evaluator shall attempt to perform some actions not listed in the selection
while the device is in the locked state and verify that those actions do not
succeed.
5.1.7 Security Management (FMT)
FMT_MOF.1 Management of Security Functions Behavior
The TSF shall restrict the ability to [determine the behaviour of]
the functions [listed in Table 4] to [the roles
indicated in Table 4].
Application
Note:
There are two roles defined in this PP: Administrator and User
(see FIA_SMR.1). Aministrators can perform most management functions on the platform, and only
Administrators are required to authenticate themselves to the platform.
Users have a limited ability to select responses to certain events
as specified in the Management Functions table in FMT_SMF.1.
The evaluator shall verify that the TSS describes those management functions that
may be performed by the Administrator, and those that can be performed by
ordinary users. The TSS also describes any functionality that is affected by
administrator-configured policy and how. This activity will be performed in conjunction with
FMT_SMF.1.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
Testing of this SFR is covered in the tests for FMT_SMF.1.
Decide whether we are using and completed unfinished fields (EAs, App Notes, etc.)
The TSF shall enforce the [assignment:
access control SFP, information flow control SFP] to provide [selection, choose one of: restrictive, permissive, [assignment:
other property]] default values for security attributes that are used to enforce the SFP.
The TSF shall allow the [assignment:
the authorized identified roles] to specify alternative
initial values to override the derfault values when an object or information is created.
The TSF shall be capable of performing the following management functions: [
Table 4: Management Functions
Status Markers:
M - Mandatory
O - Optional/Selectable/Conditional
X - Not permitted
#
Management Function
Admin
User
Application Notes
1
Ability to administer the platform
[selection: locally, remotely].
OOptional/Conditional
XNot permitted
Administration is considered “local” if the Administrator is physically present at the GPCP.
Administration is considered “remote” if communications between the Administrator and GPCP is over a network.
If "locally" is selected, then function 6 is mandatory.
If "remotely" is selected, then FTP_TRP.1 must be claimed in the
ST and functions 5, 6, and 13
are mandatory.
2
Ability to configure and manage the audit functionality and audit data.
OOptional/Conditional
XNot permitted
Management of audit data includes the ability to delete it.
This Function must be claimed if FAU_GEN.1 is claimed in the ST.
3
Ability to configure name/address of audit/logging server to which to send audit/logging records.
OOptional/Conditional
XNot permitted
This function must be claimed if FAU_STG.1 is claimed in the ST.
4
Ability to review audit records.
OOptional/Conditional
XNot permitted
This Function must be claimed if FAU_SAR.1 is claimed in the ST.
5
Ability to initiate a trusted channel or accept an incoming channel
for remote administration.
OOptional/Conditional
XNot permitted
This Function must be claimed if FTP_TRP.1 is claimed in the ST.
This function is mandatory when function 1 remote administrator is selected.
6
Ability to manage authentication credentials for Administrators.
OOptional/Conditional
XNot permitted
This Function must be claimed if FIA_UIA_EXT.1 is claimed in the ST.
This function is mandatory when function 1 is selected (local or remote).
7
Ability to set parameters for allowable number of authentication failures.
OOptional/Conditional
XNot permitted
This Function must be claimed if FIA_AFL_EXT.1 is claimed in the ST.
8
Ability to configure password length and complexity.
OOptional/Conditional
XNot permitted
This Function must be claimed if FIA_PMG_EXT.1 is claimed in the ST.
If password length and complexity are not configurable, then the Administrator
Option should be denied.
9
Ability to configure authentication throttling policy.
OOptional/Conditional
XNot permitted
This Function must be claimed if FIA_TRT_EXT.1 is claimed in the ST.
If authentication throttling policy is not configurable, then the Administrator
Option should be denied.
10
Ability to manage authentication methods and change default authorization
factors.
OOptional/Conditional
XNot permitted
This Function must be claimed if FIA_UAU.5 is claimed in the ST.
If authentication methods are not configurable, then the Administrator
Option should be denied.
11
Ability to configure certificate revocation checking methods.
OOptional/Conditional
XNot permitted
This function must be claimed if FIA_X509_EXT.1 is claimed in the ST (i.e., the TOE claims conformance to .
If TOE does not support configuration of certificate revocation checking methods,
then the Administrator option should be denied.
12
Ability to configure TSF behavior when certificate revocation status cannot be
determined.
OOptional/Conditional
XNot permitted
This function must be claimed if FIA_X509_EXT.2 is claimed in the ST (i.e., the TOE claims conformance
to and the claims made in the SFR indicate that the administrator is allowed to
configure how the TSF treats a certificate with undetermined revocation status.
13
Ability to manage the IPsec reference identifier.
OOptional/Conditional
XNot permitted
This function must be claimed if FCS_IPSEC_EXT.1 is claimed in the ST.
This function is mandatory when function 1 remote administrator is selected.
14
Ability to configure default action to take on boot integrity failure.
OOptional/Conditional
XNot permitted
This Function must be claimed if "in accordance with Administrator-configurable policy"
is selected in FPT_ROT_EXT.2.2 or FPT_ROT_EXT.3.2.
15
Ability to configure default action to take on update failure.
Ability to determine the action to take on integrity check failure.
OOptional/Conditional
OOptional/Conditional
This Function must be claimed if FPT_ROT_EXT.2 or FPT_ROT_EXT.3 is claimed in the ST.
The Administrator Option must be selected if "by express determination of an [Administrator]" is selected
in FPT_ROT_EXT.2.2 or FPT_ROT_EXT.3.2.
The User Option must be selected if "by express determination of an [User]" is selected
in FPT_ROT_EXT.2.2 or FPT_ROT_EXT.3.2.
19
Ability to manage import and export of keys/secrets to and from protected storage.
OOptional/Conditional
XNot permitted
This Function must be claimed if FCS_STG_EXT.1 is claimed in the ST.
Application
Note:
These functions become Mandatory or Selectable as indicated in the Notes.
If function 1 is not selected, then no other
administrative functions may be selected.
The evaluator shall examine the TSS to ensure that it describes each management function
and its associated actions.
Guidance
The evaluator shall examine the AGD to ensure that it describes how the Administrator
performs each management function that the ST claims the TOE supports.
The evaluator shall verify for each claimed management function that
the guidance is sufficiently detailed to allow the function to be performed.
Tests
The evaluator shall test each management function included in the ST
to demonstrate that the function can be performed only by the roles
indicated in Table 4 and the result of the function is demonstrated.
The TSF shall be able to associate users with roles.
Application
Note:
If "Administrator" is selected, then the user authentication SFRs in FIA must be claimed.
A User is a human who interacts with the GPCP through a user interface. Users do not
authenticate themselves to the GPCP, though they may be authenticated by tenant
software. The User role is considered to exist even if no humans normally interact with a GPCP.
An Administrator is a privileged user that must be authenticated by the GPCP in order
to administer the GPCP. This role is distinct from OS or VS administrators, who are
may are authenticated to tenant software and are considered to be Users in the context of the GPCP.
Application
Note:
This element identifies the protocols and references the protocol definitions that serve to define to what extent the
network traffic can be interpreted by the TOE when importing (receiving network traffic or ingress) and exporting
(sending–or forming to be sent–network traffic or egress).
While the protocol formatting specified in the RFCs is still used, many RFCs define behaviors which are no longer
considered safe to follow. For example, RFC 792 defined the “Redirect” Internet Control Message Protocol (ICMP) type,
which is not considered safe to honor when it might come from an adversary; the “source quench” message, which is
insecure because its source cannot be validated.
It also identifies the various attributes that are applicable when constructing rules to be enforced by this requirement
– the applicable interface is a property of the TOE and the rest of the identified attributes are defined in the associated
RFCs. Note that the Protocol is the IPv4 field (in IPv6 this field is called the “next header”) that identifies the applicable
protocol, such as TCP, UDP, ICMP, etc. Also, ‘Interface’ identified above is the external port where the applicable network
traffic was received or alternately will be sent.
The TSF shall allow the packet filtering rules to be assigned to each distinct network interface.
Application
Note:
This element identifies where rules can be assigned. Specifically, a conforming TOE must be able to assign filtering rules specific
to each of its available and identifiable distinct network interfaces that handle layer 3 and 4 network traffic. Identifiable means
the interface is unique and identifiable within the TOE, and does not necessarily require the interface to be visible from the network
perspective (e.g., does not need to have an IP address assigned to it). A distinct network interface is one or more physical connections
that share a common logical path into the TOE. For example, the TOE might have a small form-factor pluggable (SFP) port supporting SFP
modules that expose a number of physical network ports, but since a common driver is used for all external ports they can be treated as
a single distinct network interface.
Note that there could be a separate ruleset for each interface or alternately a shared ruleset that somehow associates rules with specific
interfaces.
The TSF shall process the applicable packet filtering rules (as determined in accordance with FPF_RUL_EXT.1.4) in the following order:
[
Administrator-defined
].
Application
Note:
This element requires that an administrator is able to define the order in which configured filtering rules are precessed for matches.
The evaluator shall verify that the TSS describes the algorithm applied to incoming packets, including the processing of
default rules, determination of whether a packet is part of an established session, and application of administrator defined
and ordered ruleset.
The evaluator shall verify that the TSS describes the process for applying packet filtering rules and also that the behavior
(either by default, or as configured by the administrator) is to discard packets when there is no rule match. The evaluator
shall verify the TSS describes when the IPv4 and IPv6 protocols supported by the TOE differ from the full list provided in the
RFC Values for IPv4 and IPv6 table.
Guidance
The evaluator shall verify that the operational guidance describes how the order of packet filtering rules is determined and
provides the necessary instructions so that an administrator can configure the order of rule processing.
The evaluator shall verify that the operational guidance describes the behavior if no rules or special conditions apply to the
network traffic. If the behavior is configurable, the evaluator shall verify that the operational guidance provides the appropriate
instructions to configure the behavior to discard packets with no matching rules. The evaluator shall verify that the operational
guidance describes the range of IPv4 and IPv6 protocols supported by the TOE.
Tests
Test FPT_RUL_EXT.1:1:
The evaluator shall devise two equal packet filtering rules with alternate operations – permit and discard. The rules
should then be deployed in two distinct orders and in each case the evaluator shall ensure that the first rule is enforced
in both cases by generating applicable packets and using packet capture and logs for
Test FPT_RUL_EXT.1:2:
The evaluator shall repeat the procedure above, except that the two rules should be devised where one is a subset of the
other (e.g., a specific address vs. a network segment). Again, the evaluator shall test both orders to ensure that the
first is enforced regardless of the specificity of the rule.
Test FPT_RUL_EXT.1:3:
The evaluator shall configure the TOE to permit and log each supported IPv4 Transport Layer Protocol (see RFC Values for
IPv4 and IPv6 table for full possible list) in conjunction with a specific source address and specific destination address,
specific source address and wildcard destination address, wildcard source address and specific destination address, and
wildcard source address and wildcard destination address. The evaluator shall generate packets matching each supported IPv4
Transport Layer Protocol and within the configured source and destination addresses in order to ensure that the supported
protocols are permitted (i.e., by capturing the packets after passing through the TOE) and logged. Any protocols not supported
by the TOE must be denied.
Test FPT_RUL_EXT.1:4:
The evaluator shall configure the TOE to permit all traffic except to discard and log each supported IPv4 Transport Layer
Protocol (see RFC Values for IPv4 and IPv6 table for full possible list) in conjunction with a specific source address and
specific destination address, specific source address and wildcard destination address, wildcard source address and specific
destination address, and wildcard source address and wildcard destination address. The evaluator shall generate packets
matching each defined IPv4 Transport Layer Protocol and within the configured source and destination addresses in order to
ensure that the supported protocols are denied (i.e., by capturing no applicable packets passing through the TOE) and logged.
Any protocols not supported by the TOE must also be denied but are not required to be logged.
Test FPT_RUL_EXT.1:5:
The evaluator shall configure the TOE to permit and log each supported IPv4 Transport Layer Protocol (see RFC Values for IPv4
and IPv6 table for full possible list) in conjunction with a specific source address and specific destination address, specific
source address and wildcard destination address, wildcard source address and specific destination address, and wildcard source
address and wildcard destination address. Additionally, the evaluator shall configure the TOE to discard and log each supported
IPv4 Transport Layer Protocol (see RFC Values for IPv4 and IPv6 table for full possible list) in conjunction with different
(than those permitted above) combinations of a specific source address and specific destination address, specific source address
and wildcard destination address, wildcard source address and specific destination address, and wildcard source address and
wildcard destination address. The evaluator shall generate packets matching each supported IPv4 Transport Layer Protocol and o
utside the scope of all source and destination addresses configured above in order to ensure that the supported protocols are
denied (i.e., by capturing no applicable packets passing through the TOE) and logged. Any protocols not supported by the TOE
must be denied.
Test FPT_RUL_EXT.1:6:
The evaluator shall configure the TOE to permit and log each supported IPv6 Transport Layer Protocol (see RFC Values for IPv4
and IPv6 table for full possible list) in conjunction with a specific source address and specific destination address, specific
source address and wildcard destination address, wildcard source address and specific destination address, and wildcard source
address and wildcard destination address. The evaluator shall generate packets matching each defined IPv6 Transport Layer
Protocol and within the configured source and destination addresses in order to ensure that the supported protocols are
permitted (i.e., by capturing the packets after passing through the TOE) and logged. Any protocols not supported by the TOE
must be denied.
Test FPT_RUL_EXT.1:7:
The evaluator shall configure the TOE to permit all traffic except to discard and log each supported IPv6 Transport Layer
Protocol (see RFC Values for IPv4 and IPv6 table for full possible list) in conjunction with a specific source address and
specific destination address, specific source address and wildcard destination address, wildcard source address and specific
destination address, and wildcard source address and wildcard destination address. The evaluator shall generate packets
matching each defined IPv6 Transport Layer Protocol and within the configured source and destination addresses in order to
ensure that the supported protocols are denied (i.e., by capturing no applicable packets passing through the TOE) and logged.
Any protocols not supported by the TOE must also be denied but are not required to be logged.
Test FPT_RUL_EXT.1:8:
The evaluator shall configure the TOE to permit and log each supported IPv6 Transport Layer Protocol (see RFC Values for IPv4
and IPv6 table for full possible list) in conjunction with a specific source address and specific destination address, specific
source address and wildcard destination address, wildcard source address and specific destination address, and wildcard source
address and wildcard destination address. Additionally, the evaluator shall configure the TOE to discard and log each supported
IPv6 Transport Layer Protocol (see RFC Values for IPv4 and IPv6 table for full possible list) in conjunction with different
(than those permitted above) combinations of a specific source address and specific destination address, specific source address
and wildcard destination address, wildcard source address and specific destination address, and wildcard source address and
wildcard destination address. The evaluator shall generate packets matching each defined IPv6 Transport Layer Protocol and
outside the scope of all source and destination addresses configured above in order to ensure that the supported protocols are
dropped (i.e., by capturing no applicable packets passing through the TOE) and logged. Any protocols not supported by the TOE
must be denied.
Test FPT_RUL_EXT.1:9:
The evaluator shall configure the TOE to permit and log protocol 6 (TCP) using a selected source port, a selected destination
port, and a selected source and destination port combination. The evaluator shall generate packets matching the configured
source and destination TCP ports in order to ensure that they are permitted (i.e., by capturing the packets after passing
through the TOE) and logged.
Test FPT_RUL_EXT.1:10:
The evaluator shall configure the TOE to discard and log protocol 6 (TCP) using a selected source port, a selected destination
port, and a selected source and destination port combination. The evaluator shall generate packets matching the configured
source and destination TCP ports in order to ensure that they are denied (i.e., by capturing no applicable packets passing
through the TOE) and logged.
Test FPT_RUL_EXT.1:11:
The evaluator shall configure the TOE to permit and log protocol 17 (UDP) using a selected source port, a selected destination
port, and a selected source and destination port combination. The evaluator shall generate packets matching the configured
source and destination UDP ports in order to ensure that they are permitted (i.e., by capturing the packets after passing
through the TOE) and logged. Here the evaluator shall ensure that the UDP port 500 (IKE) is included in the set of tests.
Test FPT_RUL_EXT.1:12:
The evaluator shall configure the TOE to discard and log protocol 17 (UDP) using a selected source port, a selected destination
port, and a selected source and destination port combination. The evaluator shall generate packets matching the configured
source and destination UDP ports in order to ensure that they are denied (i.e., by capturing no applicable packets passing
through the TOE) and logged. Again, the evaluator shall ensure that UDP port 500 is included in the set of tests.
The following table identifies the RFC defined values for the protocol fields for IPv4 and IPv6 to be used in configuring and otherwise
testing packet filtering rule definition and enforcement:
Protocol
Defined Attributes
IPv4
Transport Layer Protocol 1 - Internet Control Message
Transport Layer Protocol 2 - Internet Group Management
Transport Layer Protocol 3 - Gateway-to-Gateway
Transport Layer Protocol 4 - IP in IP (encapsulation)
Transport Layer Protocol 5 - Stream
Transport Layer Protocol 6 - Transmission Control
Transport Layer Protocol 7 - UCL
Transport Layer Protocol 8 - Exterior Gateway Protocol
Transport Layer Protocol 9 - Any private interior gateway
Transport Layer Protocol 10 - BBN RCC Monitoring
Transport Layer Protocol 11 - Network Voice Protocol
Transport Layer Protocol 12 - PUP
Transport Layer Protocol 13 - ARGUS
Transport Layer Protocol 14 - EMCON
Transport Layer Protocol 15 - Cross Net Debugger
Transport Layer Protocol 16 - Chaos
Transport Layer Protocol 17 - User Datagram
Transport Layer Protocol 18 - Multiplexing
Transport Layer Protocol 19 - DCN Measurement Subsystems
Transport Layer Protocol 20 - Host Monitoring
Transport Layer Protocol 21 - Packet Radio Measurement
Transport Layer Protocol 22 - XEROX NS IDP
Transport Layer Protocol 23 - Trunk-1
Transport Layer Protocol 24 - Trunk-2
Transport Layer Protocol 25 - Leaf-1
Transport Layer Protocol 26 - Leaf-2
Transport Layer Protocol 27 - Reliable Data Protocol
Transport Layer Protocol 28 - Internet Reliable Transaction
Transport Layer Protocol 29 - ISO Transport Protocol Class 4
Transport Layer Protocol 30 - Bulk Data Transfer Protocol
Transport Layer Protocol 31 - MFE Network Services Protocol
Transport Layer Protocol 32 - MERIT Internodal Protocol
Transport Layer Protocol 33 - Sequential Exchange Protocol
Transport Layer Protocol 34 - Third Party Connect Protocol
Transport Layer Protocol 35 - Inter-Domain Policy Routing Protocol
Transport Layer Protocol 36 - XTP
Transport Layer Protocol 37 - Datagram Delivery Protocol
Transport Layer Protocol 38 - IDPR Control Message Transport Protocol
Transport Layer Protocol 39 - TP++ Transport Protocol
Transport Layer Protocol 40 - IL Transport Protocol
Transport Layer Protocol 41 - Simple Internet Protocol
Transport Layer Protocol 42 - Source Demand Routing Protocol
The evaluator shall verify that the TSS provide a description of the TOE’s initialization and startup process, which clearly
indicates where processing of network packets begins to take place, and provides a discussion that supports the assertion that
packets cannot flow during this process.
The evaluator shall verify that the TSS also includes a narrative that identifies the components (e.g., active entity such as a
process or task) involved in processing the network packets and describes the safeguards that would prevent packets flowing
through the TOE without applying the ruleset in the event of a component failure. This could include the failure of a component,
such as a process being terminated, or a failure within a component, such as memory buffers full and cannot process packets.
Guidance
The operational guidance associated with this requirment is assessed in the subsequent test EAs.
Tests
Test FPT_RUL_EXT.1.1:1:
The evaluator shall attempt to get network traffic to flow through the TOE while the TOE is being initialized.
A steady flow of network packets that would otherwise be denied by the ruleset should be sourced and directed to
a host. The evaluator shall use a packet sniffer to verify none of the generated network traffic is permitted through
the TOE during initialization.
Test FPT_RUL_EXT.1.1:2:
The evaluator shall attempt to get network traffic to flow through the TOE while the TOE is being initialized. A steady
flow of network packets that would be permitted by the ruleset should be sourced and directed to a host. The evaluator
shall use a packet sniffer to verify none of the generated network traffic is permitted through the TOE during initialization
and is only permitted once initialization is complete.
Note: The remaining testing associated with application of the ruleset is addressed in the subsequent test EAs.
There are no EAs specified for this element. Definition of packet filtering policy, association of operations with packet filtering
rules, and association of these rules to network interfaces is described collectively under FPF_RUL_EXT.1.4.
There are no EAs specified for this element. Definition of packet filtering policy, association of operations with packet filtering
rules, and association of these rules to network interfaces is described collectively under FPF_RUL_EXT.1.4.
The evaluator shall verify that the TSS describes a packet filtering policy that can use the following fields for each identified
protocol, and that the RFCs identified for each protocol are supported:
The evaluator shall verify that the TSS describes how conformance with the identified RFCs has been determined by the TOE developer
(e.g., third party interoperability testing, protocol compliance testing).
The evaluator shall verify that each rule can identify the following actions: permit, discard, and log.
The evaluator shall verify that the TSS identifies all interface types subject to the packet filtering policy and explains how rules
are associated with distinct network interfaces. Where interfaces can be grouped into a common interface type (e.g., where the same
internal logical path is used, perhaps where a common device driver is used), they can be treated collectively as a distinct network
interface.
Guidance
The evaluator shall verify that the operational guidance identifies the following protocols as being supported and the following
attributes as being configurable within packet filtering rules for the associated protocols:
The evaluator shall verify that the operational guidance indicates that each rule can identify the following actions: permit,
discard, and log.
The evaluator shall verify that the operational guidance explains how rules are associated with distinct network interfaces.
The guidance may describe the other protocols contained within the ST (e.g., IPsec, IKE, potentially HTTPS, SSH, and TLS) that
are processed by the TOE. The evaluator shall ensure that it is made clear what protocols were not considered as part of the
TOE evaluation.
Tests
Test FPT_RUL_EXT.1.4:1:
The evaluator shall use the instructions in the operational guidance to test that packet filter rules can be created that permit,
discard, and log packets for each of the following attributes:
Test FPT_RUL_EXT.1.4:2:
The evaluator shall repeat Test 1 above for each distinct network interface type supported by the TOE to ensure that
packet filtering rules can be defined for all supported types.
Note that these test activities should be performed in conjunction with those of FPF_RUL_EXT.1.6 where the effectiveness
of the rules is tested; here the evaluator is just ensuring the guidance is sufficient and the TOE supports the
administrator creating a ruleset based on the above attributes. The test activities for FPF_RUL_EXT.1.6 define the
combinations of protocols and attributes required to be tested. If those combinations are configured manually, that
will fulfill the objective of these test activities, but if those combinations are configured otherwise (e.g., using
automation), these test activities may be necessary in order to ensure the guidance is correct and the full range of
configurations can be achieved by a TOE administrator.
5.1.9 Protection of the TSF (FPT)
FPT_APW_EXT.1 Protection of Administrator Password
The TSF shall prevent the reading of plaintext administrative passwords.
Application
Note:
This requirement is applicable only if the TOE provides its own password-based
authentication mechanism. Thus it is included in the ST only if "password-based
authentication mechanism" is selected in FIA_UAU_EXT.1.1.
The intent of the requirement is that raw password authentication data are not
stored in the clear, and that no user or administrator is able to read the plaintext
password through normal interfaces. An all-powerful administrator
could directly read memory to capture a password, but is trusted not to do so.
In this version of the PP there are no requirements on the method used to store
the passwords in non-plaintext form, but cryptographic methods based on the
requirements in FCS_COP are preferred. In future versions of this PP, FCS_COP-based cryptographic methods that conform to the Level 2 Credential Storage
requirements from NISTSP 800-63 will be required.
The evaluator shall examine the TSS to determine that it details all
authentication data that are subject to this requirement, and the method used
to obscure the plaintext password data when stored. The evaluator shall
ensure that the TSS also details that passwords are stored in such a way that
they are unable to be viewed through an interface designed specifically for that
purpose, as outlined in the application note.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The evaluator shall perform the following test:
Test FPT_APW_EXT.1:1:
The evaluator shall use forensic tools to search storage media
to verify that passwords cannot be found in an unobscured (e.g.,
plaintext) form.
Equivalency
Testing of the TOE may be performed on a subset of the platforms listed in the
TOE’s ST. Justification must be provided for those platforms that were excluded
from testing.
The TSF shall prevent code executing on any baseband processor (BP) from
accessing application processor (AP) resources except when mediated by the AP.
Application
Note:
These resources include:
Volatile and non-volatile memory
Control of and data from integrated and non-integrated peripherals (e.g. USB
controllers, touch screen controllers, LCD controller, codecs)
Control of and data from integrated and non-integrated I/O sensors (e.g.
camera, light, microphone, GPS, accelerometers, geomagnetic field
sensors)
Mobile devices are becoming increasingly complex having an application
processor that runs an operating system and user applications and separate
baseband processors that handle cellular and other wireless network connectivity.
The application processor within most modern Mobile Devices is a system on a
chip (SoC) that integrates, for example, CPU/GPU cores and memory interface
electronics into a single, power-efficient package.
Baseband processors are becoming increasingly complex themselves delivering
voice encoding alongside multiple independent radios (LTE, Wi-Fi, Bluetooth, FM,
GPS) in a single package containing multiple CPUs and DSPs.
Thus, the baseband processors in these requirements include such
integrated SoCs and include any radio processors (integrated or not) on the Mobile
Device.
All other requirements mostly, except where noted, apply to
firmware/software on the application processor, but future requirements (notably, all
Integrity, Access Control, and Anti-Exploitation requirements) will apply to
application processors and baseband processors.
The evaluator shall ensure that the TSS section of the ST describes at a high
level how the processors on the Mobile Device interact, including which bus
protocols they use to communicate, any other devices operating on that bus
(peripherals and sensors), and identification of any shared resources. The evaluator
shall verify that the design described in the TSS does not permit any BPs from
accessing any of the peripherals and sensors or from accessing main memory (volatile
and non-volatile) used by the AP. In particular, the evaluator shall ensure that the
design prevents modification of executable memory of the AP by the BP.
Guidance
There are no guidance evaluation activities for this component.
Tests
There are no test evaluation activities for this component.
The TOE initialization function shall ensure that certain properties hold on certain elements
immediately before establishing the TSF in a secure initial state, as specified in Table 2:
Properties and assignments
If disable access through hardware is selected: The evaluator shall examine the TSS to determine the location of the JTAG ports on the TSF, to include the order of the ports (i.e. Data In, Data Out, Clock, etc.).
If control access by a signing key is selected: The evaluator shall examine the TSS to determine how access to the JTAG is controlled by a signing key. The evaluator shall examine the TSS to determine when the JTAG can be accessed, i.e. what has the access to the signing key.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
Test FPT_JTA_EXT.1:1:
Evaluation Activity Note: The following test requires the developer to provide access to a test platform that provides
the evaluator with chip level access.
If disable access through hardware is selected: The evaluator shall connect a packet analyzer to the JTAG ports. The evaluator
shall query the JTAG port for its device ID and confirm that the device ID cannot be retrieved.
The TSF shall not store any plaintext key material in readable non-volatile
memory.
Application
Note:
The intention of this requirement is that the TOE will not
write plaintext keying material to persistent storage. For the purposes of this
requirement, keying material refers to authentication data, passwords, secret/private
symmetric keys, private asymmetric keys, data used to derive keys, etc. These values
must be stored encrypted.
This requirement also applies to any
value derived from passwords. Thus, the TOE cannot store plaintext password hashes for
comparison purposes before protected data is decrypted, and the TOE should use key
derivation and decryption to verify the Password Authentication Factor.
If is selected in FIA_UAU.5.1 keying
material also refers to the PIN/password used as part of the hybrid authentication.
The evaluator shall consult the TSS section of the ST in performing the Evaluation
Activities for this requirement.
In performing their review, the
evaluator shall determine that the TSS contains a description of the activities that
happen on power-up and password authentication relating to the decryption of DEKs,
stored keys, and data.
The evaluator shall ensure that the
description also covers how the cryptographic functions in the FCS requirements are
being used to perform the encryption functions, including how the KEKs, DEKs, and
stored keys are unwrapped, saved, and used by the TOE so as to prevent plaintext
from being written to non-volatile storage. The evaluator shall ensure that the TSS
describes, for each power-down scenario how the TOE ensures that all keys in
non-volatile storage are not stored in plaintext.
The evaluator
shall ensure that the TSS describes how other functions available in the system
(e.g., regeneration of the keys) ensure that no unencrypted key material is present
in persistent storage.
The evaluator shall review the TSS to
determine that it makes a case that key material is not written unencrypted to the
persistent storage.
Guidance
There are no guidance evaluation activities for this component.
Tests
There are no test evaluation activities for this component.
The TSF shall not transmit any plaintext key material outside the security
boundary of the TOE.
Application
Note:
The intention of this requirement is to prevent the logging of
plaintext key information to a service that transmits the information off-device. For
the purposes of this requirement, key material refers to keys, passwords, and other
material that is used to derive keys.
The evaluator shall consult the TSS section of the ST in performing the Evaluation
Activities for this requirement. The evaluator shall ensure that the TSS describes
the TOE security boundary. The cryptographic module may very well be a particular
kernel module, the Operating System, the Application Processor, or up to the entire
Mobile Device.
In performing their review, the evaluator shall
determine that the TSS contains a description of the activities that happen on
power-up and password authentication relating to the decryption of DEKs, stored
keys, and data.
The evaluator shall ensure that the TSS describes
how other functions available in the system (e.g., regeneration of the keys) ensure
that no unencrypted key material is transmitted outside the security boundary of the
TOE.
The evaluator shall review the TSS to determine that it
makes a case that key material is not transmitted outside the security boundary of
the TOE.
Guidance
There are no guidance evaluation activities for this component.
Tests
There are no test evaluation activities for this component.
The TSF shall ensure it is not possible for the TOE users to export plaintext
keys.
Application
Note:
Plaintext keys include DEKs, KEKs, and all keys stored in the
secure key storage (FCS_STG_EXT.1). The intent of this requirement is to prevent the
plaintext keys from being exported during a backup authorized by the TOE user or
administrator.
The ST author shall provide a statement of their policy for handling and
protecting keys. The evaluator shall check to ensure the TSS describes a policy in
line with not exporting either plaintext DEKs, KEKs, or keys stored in the secure
key storage.
Guidance
There are no guidance evaluation activities for this component.
Tests
There are no test evaluation activities for this component.
The TSF shall transition to non-operational mode and [selection: log failures in the audit record, notify the administrator, [assignment:
other actions], no other actions] when the following types of failures occur:
The evaluator shall verify that the TSS describes critical failures that may
occur and the actions to be taken upon these critical failures.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
Evaluation Activity Note: The following test require the developer to
provide access to a test platform that provides the evaluator with tools that are
typically not found on consumer Mobile Device products.
Test FPT_NOT_EXT.1:1:
The evaluator shall use a tool provided by the developer to modify files and
processes in the system that correspond to critical failures specified in the
second list. The evaluator shall verify that creating these critical failures
causes the device to take the remediation actions specified in the first
list.
The TSF shall provide the capability to determine whether physical
tampering with the TSF's devices or TSF's elements has occurred.
Application
Note:
The audit event "Detection of intrusion" should be claimed if the TOE is capable of generating
an audit event in circumstances where an intrusion is detected.
The evaluator shall examine the TSS to ensure it describes the methods used by the
TOE to detect physical tampering and how tampering is indicated when detected.
Guidance
The evaluator shall ensure that the AGD describes how the TOE indicates to users
and Administrators that it has detected tampering.
Tests
The evaluator shall verify that attempts to open the TOE enclosure
result in indications consistent with the operational guidance. Such indications
could include damaged tamper seals, logged events, or other physical or
electronic manifestations.
For [assignment:
list of TSF devices/elements for which active detection is
required], the TSF shall monitor the devices and elements and notify
[assignment:
a designated user or role] when physical tampering with the
TSF's devices or TSF's elements has occurred.
Application
Note:
FPT_PHP.2 is hierarchical to FPT_PHP.1 which means that all requirements of FPT_PHP.1 are
also included as part of FPT_PHP.2. A TOE that conforms to FPT_PHP.2 therefore does not claim FPT_PHP.1.
The audit event "Detection of intrusion" should be claimed if the TOE is capable of generating
an audit event in circumstances where an intrusion is detected.
The evaluator shall examine the TSS to ensure it describes the methods used by the
TOE to detect physical tampering and how the TOE will respond when physical
tampering has been detected for each device/element specified in FPT_PHP.2.3.
Guidance
The evaluator shall ensure that the AGD describes how the TOE notifies users
or Administrators that it has detected tampering.
Tests
The evaluator shall perform the following tests:
Test FPT_PHP.2:1:
The evaluator shall verify that attempts to open the TOE enclosure
result in indications consistent with the operational guidance. Such indications
could include damaged tamper seals, logged events, or other physical or
electronic manifestations.
Test FPT_PHP.2:2:
For each device/element listed in FPT_PHP.2.3, the evaluator shall verify that
attempts to physically tamper with the device/element results in notification
to the designated users or roles consistent with the operational guidance.
The TSF shall resist [assignment:
physical tampering scenarios] to the
[assignment:
list of TSF devices/elements] by responding automatically
such that the SFRs are always enforced.
Application
Note:
This SFR should be included in the ST if the TOE implements the following use cases:
The evaluator shall examine the TSS to ensure it describes the methods used by the
TOE to detect physical tampering and how the TOE will respond when physical
tampering has been detected such that SFRs are always enforced.
Guidance
The evaluator shall examine the AGD to ensure that it describes the expected response
of the TOE when physical tampering is detected.
Tests
The evaluator shall perform the following test:
For each physical tampering scenario and device/element
listed in FPT_PHP.3.1, the evaluator shall verify that tampering attempts
result in a response from the TSF consistent with the operational guidance.
FPT_PPF_EXT.1 Protection of Platform Firmware and Critical Data
The TSF shall allow modification of platform firmware and critical data only through the
update mechanisms described in FPT_TUD_EXT.1.
Application
Note:
Platform firmware must be modifiable only through one of the secure update mechanisms
specified in FPT_TUD_EXT.1. If the update mechanism itself is implemented in platform
firmware, then naturally, it must itself also be modifiable only through the secure update
mechanism. Configuration data used by platform firmware that is stored in nonvolatile
memory is not included in these protections. Executable portions of the TSF and data critical
for ensuring the integrity of the TSF are included in these protections. Specifically,
this includes the key store and the signature verification algorithm used by the update
mechanisms.
The evaluator shall examine the TSS to ensure that it explains how the various areas of platform firmware and critical data
are protected from modification outside of the platform firmware update mechanism described in FPT_TUD_EXT.1.
If the TOE implements an authenticated update mechanism as specified in FPT_TUD_EXT.2, then the evaluator shall ensure
that the TSS describes specifically how the signature verification code and key store is protected from update
outside of the secure platform firmware update mechanism.
Guidance
The evaluator shall check the AGD to ensure that there are instructions for how to
securely modify the platform firmware and critical data using a mechanism specified in
FPT_TUD_EXT.1.
Tests
The evaluator shall perform the following test:
The evaluator shall attempt to overwrite or modify the platform firmware without invoking one of
the update mechanisms specified in FPT_TUD_EXT.1. The test succeeds
if the attempts to overwrite platform firmware fail. The evaluator shall attempt at least three
such tests--one that attempts to overwrite the first platform firmware that executes after boot,
one that targets the secure update mechanism (if implemented), and one that targets firmware
that has been integrity-checked since the last boot.
The TSF shall verify that the new firmware package is not downgrading to a lower
security version number by [assignment:
method of verifying the security version number
is the same as or higher than the currently installed version].
The TSF shall generate and return an error code if the attempted firmware
update package is detected to be an invalid version.
Application
Note:
This requirement prevents an unauthorized rollback of the firmware to an
earlier authentic version. This mitigates against unknowing installation of an earlier authentic
firmware version that may have a security weakness. It is expected that vendors will increase
security version numbers with each new update package.
For FPT_RBP_EXT.1.1 the purpose is to verify that the new package has a security version
number equal to or larger than the security version number of currently installed firmware
package.
The administrator guidance would include instructions for the administrator to configure the
rollback prevention mechanism, if appropriate.
The evaluator shall examine the TSS to ensure that it describes at a high level the process for verifying
that security version checking is performed before an upgrade is installed. The evaluator shall verify that
a high level description of the types of error codes are provided and when an error would be triggered.
Guidance
The evaluator ensures that a description is provided on how the user should interpret the error codes.
KMD
There are no additional KMD evaluation activities for this component.
Tests
The evaluator shall perform the following test:
Test FPT_RBP_EXT.1:1:
The evaluator shall try installing a lower security version number upgrade (either by just modifying the
version number or by using an upgrade provided by the vendor) and will verify that the lower version cannot
be installed and an error is presented to the user.
This SFR needs to be completed in full.
When automated recovery from [assignment:
list of failures or service discontinuities] is not possible, the TSF shall enter a
maintenance mode where the ability to return to a secure state is provided.
The integrity of platform firmware shall be rooted in
[selection:
code and/or data written to immutable memory or storage
credentials held in immutable storage on-platform or protected storage off-platform
a separate management controller that is itself rooted in a mechanism that meets this requirement
integrity measurements held securely in an on-platform dedicated security component
integrity measurements held securely by an off-platform entity
].
Application
Note:
Roots of Trust are components that constitute a set of unconditionally trusted functions. The above are acceptable
roots of trust for platform firmware integrity.
The ST Author must select the root of trust used to ensure the integrity of the first platform firmware that executes. The integrity
of subsequently executed platform firmware must be traceable back to this root or to some other root as specified in FPT_ROT_EXT.2.
This SFR should be iterated for additional TOE roots (for example, a management controller or firmware executed from
an add-in card).
An "on-platform dedicated security component" could be, for example, a TPM or other secure element
that provides security services to the platform such as measurement or secure storage.
Selection of "a separate management controller..." implies the existence of an Administrator role.
The evaluator shall verify that the TSS describes the Root of Trust on which initial integrity
of platform firmware is anchored, consistent with the selection above. The description shall
include means by which the Root of Trust is protected from modification.
Guidance
There are no additional Guidance evaluation activities for this component.
The integrity of all mutable platform firmware outside of the platform integrity root specified in FPT_ROT_EXT.1 shall be verified
prior to
[selection: execution, use, or access to TSF data]
through
[selection:
computation and verification of a hash by trusted code/data
verification of a digital signature by trusted code/data
measurement and verification by trusted code/data
measurement by an on-platform dedicated security component and verification by an off-platform entity
].
Application
Note:
This requirement specifies the means to extend the initial integrity
of platform firmware established by FPT_ROT_EXT.1.1 to subsequently executed
platform firmware and data located in mutable storage.
(Integrity of code and data written to immutable storage is assured).
Otherwise, integrity must be extended through cryptographic means: either through hashes
or digital signatures computed and verified by firmware that is trusted because it has
previously had its integrity verified or is itself a Root of Trust. Verification can be performed
by TOE components such as management controllers or non-TOE trusted entities such as remote verifiers.
If "computation and verification of a hash by trusted code/data" is selected, then FCS_COP.1/Hash must be claimed.
If "verification of a digital signature by trusted code/data" is selected, then FCS_COP.1/SigVer must be claimed.
The TOE shall take the following actions if an integrity check specified in FPT_ROT_EXT.2.1 fails:
[selection:
Stop all execution, or
Notify an
[selection: Administrator, User] by
[selection: generating an audit event, [assignment:
other notification method(s)]], and
[selection:
Stop all execution
Shut down, or
Initiate a recovery process as specified in FPT_RVR_EXT.1
Skip all instructions that failed the integrity check and continue execution
]
[selection:
automatically
in accordance with Administrator-configurable policy
by express determination of an
[selection: Administrator, User]
]
].
Application
Note:
Notification of an administrator can take many forms. For server-class platforms, such notification could take the form
of administrator alerts or audit events. For platforms without management controllers, notification could be achieved, for
example, by blinking lights, beep codes, screen indications, or local logging.
If "Administrator" is selected anywhere in FPT_ROT_EXT.2.2, or if "in accordance with Administrator-configurable
policy" is selected, then all Administrator authentication requirements must be included in the ST
(FIA_UIA_EXT.1, FIA_UAU.5, FIA_PMG_EXT.1, FIA_AFL_EXT.1, FIA_UAU.7).
If "generating an audit event" is selected, then FAU_GEN.1, FAU_SAR.1, FAU_STG.1, FAU_STG.2, and FAU_STG.5
must be claimed in the ST. This selection should be made only if the TOE is capable of generating an audit event, e.g.
if the TOE is a server that includes a management controller.
If "Initiate a recovery process as specified in FPT_RVR_EXT.1" is selected, then FPT_RVR_EXT.1 must be included in the ST.
If "in accordance with administrator-configurable policy" is selected, then management function
14 must be claimed in FMT_SMF.1.
The evaluator shall verify that the TSS describes the means by which initial integrity of platform firmware is
extended to other platform components, and that the means are consistent with the selection(s) made in FPT_ROT_EXT.2.
The TSS shall also describe how the TOE responds to failure of verification consistent with the selections in
FPT_ROT_EXT.2.2.
Guidance
The evaluator shall examine the AGD to ensure that it describes the actions taken and notification
methods used in case of failure to establish the integrity of the platform firmware root. If the actions are
configurable, the AGD shall explain how they are configured.
Tests
The evaluator shall modify the platform firmware in a way that should cause a failure of the integrity check.
The test passes if the mechanism specified in FPT_ROT_EXT.2.2 is triggered on the first subsequent boot
of the platform.
Depending on the protections implemented, the evaluator may need a specially crafted update module from the vendor
to perform this test. But note that this is not necessarily the same as a test of the update mechanism.
The update mechanism can be tested either at boot time or at the time of the update. This verification
check must be done during boot.
If modification of platform firmware in situ or using the update mechanism is deemed to be
not feasible within the time and cost constraints of the evaluation, then the evaluator shall make such
an argument in the AAR, and with concurrence of the CC scheme, this test can be replaced by evidence of
vendor testing.
FPT_SKP_EXT.1 Protection of TSF Data (for reading of all symmetric keys
The TSF shall prevent reading of all pre-shared, symmetric keys, and private keys.
Application
Note:
The intent of this requirement is for the device to protect keys, key material, and authentication credentials from unauthorised
disclosure. This data should only be accessed for the purposes of their assigned security functionality, and there is no need for
them to be displayed/accessed at any other time. This requirement does not prevent the device from providing indication that these
exist, are in use, or are still valid. It does, however, restrict the reading of the values outright.
Regardless of whether this requirement is met by the TOE or the operational environment, the evaluator shall examine the TSS
to determine that it details
each persistent private and secret key needed to meet the requirements in the
ST. For each of these items, the evaluator shall confirm that the TSS details how
any secret or private keys are stored and that they are unable to be viewed
through an interface designed specifically for that purpose, as outlined in the
application note. If these values are not stored in plaintext, the TSS shall
describe how they are protected and obscured.
Guidance
The evaluator shall examine the AGD guidance to ensure it contains any
necessary instructions for configuring the TOE or operational environment to
support this requirement.
Tests
The evaluator shall perform the following test:
Test FPT_SKP_EXT.1:1:
The evaluator shall assume each of the non-administrator
roles supported by the TOE and shall attempt to use the available
TOE interface to read the keys specified by the TOE. The evaluator
shall verify that these attempts fail.
Equivalency
Testing of the TOE may be performed on a subset of the platforms listed in the
TOE’s ST. Justification must be provided for those platforms that were excluded
from testing.
The TSF shall be able to provide reliable time stamps.
Application
Note:
It is acceptable for the TSF to provide timestamp data either through an internal clock or a
counter. It is also permissible for the TSF to obtain time data from a clock contained within the
same physical enclosure as the TOE.
The evaluator shall examine the TSS to ensure that it lists each security function
that makes use of time. The TSS provides a description of how the time is
maintained and considered reliable in the context of each of the time related
functions.
Guidance
The evaluator shall examine the AGD to ensure it instructs the
Administrator on any mechanisms for configuring the time source.
Tests
The evaluator shall perform the following tests:
[conditional] If the TSF provides a mechanism to manually set the time, the
evaluator shall use the guidance documentation to set the time. The evaluator shall
then use an available interface to observe that the time is reported correctly.
The TSF shall run a suite of the following self-tests [selection: during initial start-up, periodically during normal operation, at the request of the authorized user, at the conditions [assignment:
conditions under which self-test should occur]]
to demonstrate the correct operation of [TSFDRBG specified in FCS_RBG.1].
The TSF shall provide authorized users with the capability to verify the integrity of [[TSFDRBG specified in FCS_RBG.1]].
Application
Note:
This SFR is a required dependency of FCS_RBG.1. It is intended to require that any DRBG implemented by the TOE undergo
health testing to ensure that the random bit generation functionality has not been degraded. If the TSF supports multiple DRBGs, this SFR
should be iterated to describe the self-test behavior for each.
The evaluator shall examine the TSS to ensure that it details the self-tests that are run by the TSF along with how they are run. This
description should include an outline of what the tests are actually doing. The evaluator shall ensure that the TSS makes an argument
that the tests are sufficient to demonstrate that the DRBG is operating correctly.
If a self-test can be executed at the request of an authorized user, the evaluator shall verify that the operational guidance
provides instructions on how to execute that self-test.
Tests
For each self-test, the evaluator shall verify that evidence is produced that the self-test is executed when specified by FPT_TST.1.1.
If a self-test can be executed at the request of an authorized user, the evaluator shall verify that following the steps documented in
the operational guidance to perform the self-test will result in execution of the self-test.
The TSF shall run a suite of the following self-tests.
during initial start-up (on power on) to verify the integrity of the TOE firmware and software
Prior to providing any cryptographic service and [selection: at no other time, on-demand, continuously [assignment:
conditions under which self-tests should occur]] to verify correct operation of cryptographic implementation necessary to fulfil the TSF
[selection: no other, start-up, on-demand, continuous, at the conditions [assignment:
conditions under which self-tests should occur] self tests[assignment:
'list an
identifier for each self-test that is additional to those identified in the first two bullet points']]
Application
Note:
This requirement may be met by performing known answer tests
or pair-wise consistency tests. The self-tests must be performed before the
cryptographic functionality is exercised (for example, during the initialization of a
process that utilizes the functionality).
The cryptographic
functionality includes the cryptographic operations in FCS_COP, the key generation
functions in FCS_CKM, and the random bit generation in FCS_RBG.1.
The TSF shall respond to [selection: all failures, [assignment:
list of failures detected by self-tests]] by [selection: entering a maintenance mode, rebooting, [assignment:
other methods to enter a secure state]].
The evaluator shall examine the TSS to ensure that it specifies the self-tests
that are performed at start-up. This description must include an outline of the test
procedures conducted by the TSF (e.g., rather than saying "memory is tested", a
description similar to "memory is tested by writing a value to each memory location
and reading it back to ensure it is identical to what was written" shall be used).
The TSS must include any error states that they TSF may enter when self-tests fail,
and the conditions and actions necessary to exit the error states and resume normal
operation. The evaluator shall verify that the TSS indicates these self-tests are
run at start-up automatically, and do not involve any inputs from or actions by the
user or operator.
The evaluator shall inspect the list of
self-tests in the TSS and verify that it includes algorithm self-tests. The
algorithm self-tests will typically be conducted using known answer tests.
Guidance
There are no guidance evaluation activities for this component.
Tests
There are no test evaluation activities for this component.
an authenticated platform firmware update mechanism as
described in FPT_TUD_EXT.2
a delayed-authentication platform firmware update mechanism as described in
FPT_TUD_EXT.3
a secure local platform firmware update mechanism
described in FPT_TUD_EXT.4
].
Application
Note:
The purpose of the platform firmware update mechanism is to ensure the authenticity and integrity of
platform firmware updates.
If platform firmware is immutable (not updateable by any non-destructive means), then the ST Author selects
"no mechanism for platform firmware update."
If the platform implements an update mechanism that does not require physical presence at the platform, and
that authenticates firmware updates prior to installing them, then the ST Author selects
"an authenticated platform firmware update mechanism..." and includes FPT_TUD_EXT.2
and FCS_COP.1/SigVer in the ST.
If the platform implements an update mechanism that does not require physical presence at the
platform, and that does not authenticate firmware updates prior to installing them,
then the ST Author selects "a delayed-authentication platform firmware update mechanism..." and
includes FPT_TUD_EXT.3 and FCS_COP.1/SigVer in the ST.
If platform firmware is modifiable only through a local update requiring physical presence at the platform,
then the ST Author must select "a secure local platform firmware update mechanism..." and include FPT_TUD_EXT.4 in the ST.
If the ST Author selects "no provision for platform firmware update," then the
evaluator shall examine the TSS to ensure that it explains all ways of modifying platform
firmware in the absence of any provided mechanism. For example, breaking open the case
and prying a chip off the motherboard and then reprogramming the chip. The purpose of this
activity is to ensure that the TOE does not implement a local update mechanism that does not
meet the requirements of FPT_TUD_EXT.4.
This requirement is met if the platform implements no means for updating platform firmware
and the TSS describes a method for updating or replacing platform firmware that involves
potentially destroying or damaging the TOE or some of its components.
If the ST Author selects "an authenticated platform firmware update mechanism...," then this requirement is
satisfied if FPT_TUD_EXT.2 is satisfied.
If the ST Author selects "a delayed-authentication platform firmware update mechanism...," then this requirement is
satisfied if FPT_TUD_EXT.3 is satisfied.
If the ST Author selects "a secure local platform firmware update mechanism...," then this requirement is
satisfied if FPT_TUD_EXT.4 is satisfied.
Guidance
There are no additional Guidance evaluation activities for this component.
This SFR will need to be completed with all sections.The TSF shall terminate a remote interactive session after a security
administrator-configurable time interval of session inactivity
Application
Note:
An interactive session governed by this SFR is a session in which an authenticated state is achieved and then preserved across multiple commands. By
contrast, if authentication accompanies each individual command (without preservation of the same authenticated state) then this is not considered an
interactive session.
This SFR will need to be completed with all sections. The TSF shall allow administrator-initiated termination of the
administrator's
own interactive session.
FTA_SSL_EXT.1 TSF- and TSF-initiated Session Blocking
The TSF shall, for local interactive sessions,[selection: lock the session - disable any activity of the Administrator’s data access/display devices other than unlocking the session, and requiring
that the Administrator reauthenticate to the TSF prior to unlocking the session, terminate the session] after a security administrator-specified time period of inactivity.
Application
Note:
An interactive session governed by this SFR is a session in which an authenticated state is achieved and then preserved across multiple commands.
By contrast, if authentication accompanies each individual command (without preservation of the same authenticated state) then this is not considered
an interactive session.
The TSF shall, upon transitioning to the locked state, perform the following
operations:
Clearing or overwriting display devices, obscuring the previous contents;
[assignment:
Other actions performed upon transitioning to the locked
state].
Application
Note:
The time interval of inactivity is configured using FMT_SMF_EXT.1 function . The user/administrator-initiated lock is
specified in FMT_SMF_EXT.1 function .
The evaluator shall verify the TSS describes the actions performed upon
transitioning to the locked state.
Guidance
The evaluation shall verify that the AGD guidance describes the method of
setting the inactivity interval and of commanding a lock. The evaluator shall verify
that the TSS describes the information allowed to be displayed to unauthorized
users.
Tests
Test FTA_SSL_EXT.1:1:
The evaluator shall configure the TSF to transition to the locked state
after a time of inactivity (FMT_SMF_EXT.1) according to the AGD guidance. The
evaluator shall wait until the TSF locks and verify that the display is cleared
or overwritten and that the only actions allowed in the locked state are
unlocking the session and those actions specified in FIA_UAU_EXT.2.
Test FTA_SSL_EXT.1:2:
The evaluator shall command the TSF to transition to the locked state
according to the AGD guidance as both the user and the administrator. The
evaluator shall wait until the TSF locks and verify that the display is cleared
or overwritten and that the only actions allowed in the locked state are
unlocking the session and those actions specified in FIA_UAU_EXT.2.
Before establishing a user session, the [TSF] shall display a
[security administrator-specified advisory notice and consent warning regarding use of the TOE] message.
Application
Note:
This requirement may be met with the configuration of either
text or an image containing the text of the desired message. The TSF must minimally
display this information at startup, but may also display the information at every
unlock. The banner is configured according to FMT_SMF_EXT.1 function .
The TSS shall describe when the banner is displayed.
Guidance
There are no guidance evaluation activities for this component.
Tests
The evaluator shall also perform the following test:
Test FTA_TAB.1:1:
The evaluator follows the operational guidance to configure a notice and
consent warning message. The evaluator shall then start up or unlock the TSF.
The evaluator shall verify that the notice and consent warning message is
displayed in each instance described in the TSS.
This SFR needs missing sections completed.
The TSF shall be capable of using [selection: IPsec, MACsec, PFED, WLAN] to provide a trustedcommunication channel between itself and another trustedauthorizedITentities
supporting the following capabilities: audit server, [selection: authentication server, [assignment:
other capabilities], no other capabilities]product that is logically distinct from other communication channels and provides assured
identification of its end points and protection of the channel data from disclosure and detection of modification of the channel data.
The TSF shall provide a physically protected communication channel between itself and [assignment:
list of other IT entities within the same
platform].
Application
Note:
This SFR focuses on persistent internal communication channels and does not apply to communication channels intended
for use with external media, ephemeral devices, or peripherals. This SFR must be claimed if
"physically protected channels as specified in FTP_ITP_EXT.1" is selected in either
FDP_ITC_EXT.1, or if "Keys exchanged using a physically protected communication mechanism
conformant with FTP_ITP_EXT.1" is selected in FTP_ITE_EXT.1.1.
The evaluator shall review the TSS to determine that it lists all mechanisms the TOE
uses for physically protected external communications, along with the types of
communications protected using each mechanism.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
There are no test activities for this component.
5.1.12 TOE Security Functional Requirements Rationale
The following rationale provides justification for each SFR for the TOE,
showing that the SFRs are suitable to address the specified threats:
The PP identifies the Security Assurance Requirements (SARs) to frame the extent to which
the evaluator assesses the documentation applicable for the evaluation and performs independent testing.
This section lists the set of SARs from CC part 3 that are required in evaluations against this
PP. Individual Evaluation Activities (EAs) to be performed are specified both
in Section 5 Security Requirements as well as in this section. These SARs were chosen based on the notion that a hypothetical attacker of the TOE lacks administrative privilege
on its platform but otherwise has persistent access to the TOE itself and the sophistication to interact with the platform in a way that they can
attempt to access stored data without authorization or to run tools that automate more sophisticated malicious activity.
The general model for evaluation of TOEs against STs written to conform to this PP is as follows:
After the ST has been approved for evaluation, the CCTL will obtain the TOE, supporting
environmental IT, and the administrative/user guides for the TOE. The CCTL is expected to
perform actions mandated by the Common Evaluation Methodology (CEM) for the ASE and
ALC SARs. The CCTL also performs the evaluation activities contained within Section 5 Security Requirements,
which are intended to be an interpretation of the other CEM assurance requirements as they
apply to the specific technology instantiated in the TOE. The evaluation activities that are
captured in Section 5 Security Requirements also provide clarification as to what the developer needs
to provide to demonstrate the TOE is compliant with the PP. The results of these activities will be documented
and presented (along with the administrative guidance used) for validation.
The information about the TOE
is contained in the guidance documentation available to the end user as
well as the TSS portion of the ST. The TOE developer
must concur with the description of the product that is contained in the TSS as it relates
to the functional requirements. The evaluation activities contained in
Section 5.1 Security Functional Requirements should provide the ST authors with sufficient information to
determine the appropriate content for the TSS section.
The functional
specification describes the TSFIs. It is not necessary
to have a formal or complete specification of these interfaces. Additionally, because
TOEs conforming to this PP will necessarily have interfaces to the
Operational Environment that are not directly invocable by TOE users,
there is little point specifying that such interfaces be described in and of themselves
since only indirect testing of such interfaces may be possible. For this PP, the
activities for this family should focus on understanding the interfaces presented in the
TSS in response to the functional requirements and the interfaces
presented in the AGD documentation. No additional “functional specification” documentation
is necessary to satisfy the evaluation activities specified. The interfaces that need to be
evaluated are characterized through the information needed to perform the assurance
activities listed, rather than as an independent, abstract list.
The developer shall provide a tracing from the functional specification to the
SFRs.
Application
Note:
As indicated in the introduction to this section, the
functional specification is comprised of the information contained in the AGD_OPE and
AGD_PRE documentation. The developer may reference a website accessible to application
developers and the evaluator. The evaluation activities in the functional requirements
point to evidence that should exist in the documentation and TSS
section; since these are directly associated with the SFRs, the tracing in element
ADV_FSP.1.2D is implicitly already done and no additional documentation is
necessary.
There are no specific evaluation activities associated with these SARs, except
ensuring the information is provided. The functional specification documentation is
provided to support the evaluation activities described in Section 5.1 Security Functional Requirements, and
other activities described for AGD, ATE, and AVA SARs. The requirements on the content
of the functional specification information is implicitly assessed by virtue of the
other evaluation activities being performed; if the evaluator is unable to perform an
activity because there is insufficient interface information, then an adequate
functional specification has not been provided.
5.2.3 Class AGD: Guidance Documentation
The guidance documents will be
provided with the ST. Guidance must include a description of how the IT personnel verifies
that the Operational Environment can fulfill its role for the security functionality. The
documentation should be in an informal style and readable by the IT personnel. Guidance must
be provided for every operational environment that the product supports as claimed in the
ST. This guidance includes instructions to successfully install the TSF in
that environment; and instructions to manage the security of the TSF as a
product and as a component of the larger operational environment. Guidance pertaining to
particular security functionality is also provided; requirements on such guidance are
contained in the evaluation activities specified with each requirement.
The developer shall provide operational user guidance.
Application
Note:
The operational user guidance does not have to be contained in a
single document. Guidance to users, administrators and application developers can be
spread among documents or web pages. Where appropriate, the guidance documentation is
expressed in the eXtensible Configuration Checklist Description Format (XCCDF) to
support security automation. Rather than repeat information here, the developer should
review the evaluation activities for this component to ascertain the specifics of the
guidance that the evaluator will be checking for. This will provide the necessary
information for the preparation of acceptable guidance.
The operational user guidance shall describe, for each user role, the
user-accessible functions and privileges that should be controlled in a secure
processing environment, including appropriate warnings.
Application
Note:
User and administrator are to be considered in the definition
of user role.
The operational user guidance shall describe, for each user role, the available
functions and interfaces, in particular all security parameters under the control of
the user, indicating secure values as appropriate.
The operational user guidance shall, for each user role, clearly present each
type of security-relevant event relative to the user-accessible functions that need to
be performed, including changing the security characteristics of entities under the
control of the TSF.
The operational user guidance shall identify all possible modes of operation of
the TOE (including operation following failure or operational
error), their consequences, and implications for maintaining secure operation.
The operational user guidance shall, for each user role, describe the security
measures to be followed in order to fulfill the security objectives for the
operational environment as described in the ST.
Some of the contents of the operational guidance will be verified by the
evaluation activities in Section 5.1 Security Functional Requirements and evaluation of the TOE
according to the [CEM]. The following additional
information is also required.
If cryptographic functions are provided by the
TOE, the operational guidance shall contain instructions for
configuring the cryptographic engine associated with the evaluated configuration of
the TOE. It shall provide a warning to the administrator that use of
other cryptographic engines was not evaluated nor tested during the CC evaluation of
the TOE.
The documentation must describe the process for verifying
updates to the TOE by verifying a digital signature – this may
be done by the TOE or the underlying platform.
The evaluator shall verify that this process includes the following steps:
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 digital signature.
The TOE will likely contain security functionality that does not
fall in the scope of evaluation under this PP. The operational guidance shall make it
clear to an administrator which security functionality is covered by the evaluation
activities.
The developer shall provide the TOE, including its preparative procedures.
Application
Note:
As with the operational guidance, the developer should look to
the evaluation activities to determine the required content with respect to preparative
procedures.
The preparative procedures shall describe all the steps necessary for secure
acceptance of the delivered TOE in accordance with the developer's
delivery procedures.
The preparative procedures shall describe all the steps necessary for secure
installation of the TOE and for the secure preparation of the
operational environment in accordance with the security objectives for the operational
environment as described in the ST.
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 claimed for the TOE in the ST.
5.2.4 Class ALC: Life-cycle Support
At the assurance level provided for TOEs conformant to this PP, life-cycle support is limited
to end-user-visible aspects of the life-cycle, rather than an examination of the TOE vendor’s
development and configuration management process. This is not meant to diminish the
critical role that a developer’s practices play in contributing to the overall trustworthiness of a
product; rather, it is a reflection on the information to be made available for evaluation at this
assurance level.
ALC_CMC.1 Labeling of the TOE (ALC_CMC.1)
This component is targeted at identifying the TOE such that it can be distinguished from
other products or versions from the same vendor and can be easily specified when being
procured by an end user.
The evaluator 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. Further, the evaluator shall check the operational 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 "evaluation evidence required by the SARs" in this PP is limited to the
information in the ST coupled with the guidance provided to administrators and users
under the AGD requirements. By ensuring that the TOE is specifically
identified and that this identification is consistent in the ST and in the AGD
guidance (as done in the evaluation activity for ALC_CMC.1), the evaluator implicitly
confirms the information required by this component. Life-cycle support is targeted
aspects of the developer’s life-cycle and instructions to providers of applications
for the developer’s devices, rather than an in-depth examination of the TSF
manufacturer’s development and configuration management process.
This is not meant to diminish the critical role that a developer’s practices play in
contributing to the overall trustworthiness of a product; rather, it’s a reflection on
the information to be made available for evaluation.
The evaluator shall ensure that the developer has identified (in guidance documentation for application
developers concerning the targeted platform) one or more development environments
appropriate for use in developing applications for the developer’s platform. For each
of these development environments, the developer shall provide information on how to
configure the environment to ensure that buffer overflow protection mechanisms in the
environment(s) are invoked (e.g., compiler flags). The evaluator shall ensure that
this documentation also includes an indication of whether such protections are on by
default, or have to be specifically enabled. The evaluator shall ensure that the
TSF is uniquely identified (with respect to other products from the
TSF vendor), and that documentation provided by the developer in
association with the requirements in the ST is associated with the
TSF using this unique identification.
ALC_TSU_EXT.1 Timely Security Updates
This component requires the TOE developer, in conjunction with any other necessary parties,
to provide information as to how the end-user devices are updated to address security issues
in a timely manner. The documentation describes the process of providing updates to the
public from the time a security flaw is reported/discovered, to the time an update is released.
This description includes the parties involved (e.g., the developer, carriers(s)) and the steps
that are performed (e.g., developer testing, carrier 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 users are notified when
updates change security properties or the configuration of the product.
The description shall express the time window as the length of time,
in days, between public disclosure of a vulnerability and the public availability
of security updates to the TOE.
The description shall include the mechanisms publicly available for
reporting security issues pertaining to the TOE.
Application
Note:
The reporting mechanism could include a website or email address as
well as a means to protect the sensitive nature of the report (e.g., public keys that could be
used to encrypt the details of a proof-of-concept exploit).
The evaluator shall verify that the TSS contains a description of the timely security update
process used by the developer to create and deploy security updates. The evaluator shall
verify that this description addresses the entire application. The evaluator shall also
verify that, in addition to the TOE developer’s process, any
third-party processes are also addressed in the description. The evaluator shall
also verify that each mechanism for deployment of security updates is described.
The evaluator shall verify that, for each deployment mechanism described for the update
process, the TSS lists a time between public disclosure of a vulnerability and public
availability of the security update to the TOE patching this vulnerability, to include any third-party
or carrier delays in deployment. The evaluator shall verify that this time is expressed in
a number or range of days.
The evaluator shall verify that this description includes the publicly available mechanisms
(including either an email address or website) for reporting security issues related to the TOE.
The evaluator shall verify that the description of this mechanism includes a method for
protecting the report either using a public key for encrypting email or a trusted channel for a
website.
5.2.5 Class ATE: Tests
Testing is specified for functional aspects of
the system as well as aspects that take advantage of design or implementation weaknesses.
The former is done through the ATE_IND family, while the latter is through the AVA_VAN
family. At the assurance level specified in this PP, testing is based on advertised
functionality and interfaces with dependency on the availability of design information. One
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 operational) documentation provided. The focus of the testing
is to confirm that the requirements specified in Section 5.1 Security Functional Requirements are being met,
although some additional testing is specified for SARs in Section 5.2 Security Assurance Requirements. The
evaluation activities identify the additional testing activities associated with these
components. The evaluator produces a test report documenting the plan for and results of
testing, as well as coverage arguments focused on the platform/TOE
combinations that are claiming conformance to this PP. Given the scope of the
TOE and its associated evaluation evidence requirements, this
component’s evaluation activities are covered by the evaluation activities listed for ALC_CMC.1.
Application
Note:
The developer must provide at least one product instance of the TOE for complete testing on at least one
platform regardless of equivalency. See the Equivalency Appendix for more details.
The evaluator shall prepare a test plan and report documenting the testing
aspects of the system, including any application crashes during testing. The evaluator
shall determine the root cause of any application crashes and include that information
in the report. The test plan covers all of the testing actions contained in
the [CEM] and the body of this PP’s evaluation activities.
While it is not necessary to have one test case per test listed in an evaluation activity, the
evaluator must document in the test plan that each applicable testing requirement in
the ST is covered. The test plan identifies the platforms to be tested, and for those
platforms not included in the test plan but included in the ST, the test plan provides
a justification for not testing the platforms. This justification must address the
differences between the tested platforms and the untested platforms, and make an
argument that the differences do not affect the testing to be performed. It is not
sufficient to merely assert that the differences have no effect; rationale must be
provided. If all platforms claimed in the ST are tested, then no rationale is
necessary. The test plan describes the composition of each platform to be tested, and
any setup that is necessary beyond what is contained in the AGD documentation. It
should be noted that the evaluator is expected to follow the AGD documentation for
installation and setup of each platform either as part of a test or as a standard
pre-test condition. This may include special test drivers or tools. For each driver or
tool, an argument (not just an assertion) should be provided that the driver or tool
will not adversely affect the performance of the functionality by the TOE and its platform.
This also includes the configuration of the
cryptographic engine to be used. The cryptographic algorithms implemented by this
engine are those specified by this PP and used by the cryptographic protocols being
evaluated (e.g., SSH). The test plan identifies high-level test objectives
as well as the test procedures to be followed to achieve those objectives. These
procedures include expected results.
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.
5.2.6 Class AVA: Vulnerability Assessment
For the current generation of
this protection profile, the evaluation lab is expected to survey open sources to discover
what vulnerabilities have been discovered in these types of products. In most cases, these
vulnerabilities will require sophistication beyond that of a basic attacker. Until
penetration tools are created and uniformly distributed to the evaluation labs, the
evaluator will not be expected to test for these vulnerabilities in the TOE. The labs will be expected to comment on the likelihood of these vulnerabilities given
the documentation provided by the vendor. This information will be used in the development
of penetration testing tools and for the development of future protection profiles.
Application
Note:
Suitability for testing means not being obfuscated or
packaged in such a way as to disrupt either static or dynamic analysis by the
evaluator.
The evaluator shall perform a search of public domain sources to identify
potential vulnerabilities in the TOE.
Application
Note:
Public domain sources include the Common Vulnerabilities
and Exposures (CVE) dictionary for publicly known vulnerabilities. Public domain
sources also include sites which provide free checking of files for viruses.
The evaluator shall conduct penetration testing, based on the identified
potential vulnerabilities, to determine that the TOE is resistant to
attacks performed by an attacker possessing Basic attack potential.
The evaluator shall generate a report to document their findings with respect to this
requirement. This report could physically be part of the overall test report mentioned in
ATE_IND, or a separate document. The evaluator performs a search of public information to find
vulnerabilities that have been found in similar applications with a particular focus on network
protocols the application uses and document formats it parses.
The evaluator documents the sources consulted and the vulnerabilities found in the report.
For each vulnerability found, the evaluator either provides a rationale with respect to its
non-applicability, or the evaluator formulates a test (using the guidelines provided in ATE_IND)
to confirm the vulnerability, if suitable. Suitability is determined by assessing the attack
vector needed to take advantage of the vulnerability. If exploiting the vulnerability requires
expert skills and an electron microscope, for instance, then a test would not be suitable and
an appropriate justification would be formulated.
The evaluator shall also run a virus scanner with the most current virus definitions against the
application files and verify that no files are flagged as malicious.
Appendix A - Optional Requirements
As indicated in the introduction to this PP, the baseline requirements (those that must be
performed by the TOE) are contained in the body of this PP.
This appendix contains three other types of optional requirements:
The first type, defined in Appendix A.1 Strictly Optional Requirements, are strictly optional requirements.
If the TOE meets any of these requirements the vendor is encouraged to claim the associated SFRs
in the ST, but doing so is not required in order to conform to this PP.
The second type, defined in Appendix A.2 Objective Requirements, are objective requirements. These describe security functionality that is not yet
widely available in commercial technology.
Objective requirements are not currently mandated by this PP, but will be mandated in
the future. Adoption by vendors is encouraged, but claiming these SFRs is not required in order to conform to this
PP.
The third type, defined in Appendix A.3 Implementation-dependent Requirements, are Implementation-dependent requirements.
If the TOE implements the product features associated with the listed SFRs, either the SFRs must be claimed
or the product features must be disabled in the evaluated configuration.
A.1 Strictly Optional Requirements
A.1.1 Class ALC: Life-cycle Support
ALC_FLR.1 Basic Flaw Remediation (ALC_FLR.1)
This SAR is optional and may be claimed at the ST-Author's discretion.
The flaw remediation procedures shall require that a description of the nature and effect
of each security flaw be provided, as well as the status of finding a correction to that flaw.
The flaw remediation procedures documentation shall describe the methods used to
provide flaw information, corrections and guidance on corrective actions to TOE users.
The flaw remediation procedures shall require that a description of the nature and effect of each
security flaw be provided, as well as the status of finding a correction to that flaw.
The flaw remediation procedures documentation shall describe the methods used to provide flaw
information, corrections and guidance on corrective actions to TOE users.
The flaw remediation procedures shall describe a means by which the developer receives
from TOE users reports and enquiries of suspected security flaws in the TOE.
The procedures for processing reported security flaws shall ensure that any reported
flaws are remediated and the remediation procedures issued to TOE users.
The procedures for processing reported security flaws shall provide safeguards that any
corrections to these security flaws do not introduce any new flaws.
The flaw remediation procedures shall require that a description of the nature and effect of each
security flaw be provided, as well as the status of finding a correction to that flaw.
The flaw remediation procedures documentation shall describe the methods used to provide flaw
information, corrections and guidance on corrective actions to TOE users.
The flaw remediation procedures shall describe a means by which the developer receives from
TOE users reports and enquiries of suspected security flaws in the TOE.
The flaw remediation procedures shall include a procedure requiring timely response and
the automatic distribution of security flaw reports and the associated corrections to
registered users who might be affected by the security flaw.
The procedures for processing reported security flaws shall ensure that any reported flaws are
remediated and the remediation procedures issued to TOE users.
The procedures for processing reported security flaws shall provide safeguards that any
corrections to these security flaws do not introduce any new flaws.
The flaw remediation guidance shall describe a means by which TOE users may register
with the developer, to be eligible to receive security flaw reports and corrections.
The TSF shall destroy [all plaintext keying material and critical security
parameters (CSPs)] when
[selection: no longer needed, [assignment:
other circumstances for destruction]].
The TSF shall destroy plaintext keying material and critical security parameters by
implementing key destruction in accordance with the following rules: [
For volatile memory, the destruction shall be executed by a single direct overwrite consisting of [selection: a pseudo-random pattern using a TSFDRBG (as specified in FCS_RBG.1), zeroes]
For non-volatile EEPROM, the destruction shall be executed by a single direct overwrite consisting of a pseudo-random pattern using a
TSFDRBG (as specified in FCS_RBG.1), followed by a read-verify.
For non-volatile flash memory, that is not wear-leveled, the destruction shall be executed by[selection: a single direct overwrite consisting of zeros followed by a read-verify, a block erase that erases the reference to memory that stores data as well as the data itself]
For non-volatile flash memory that is wear-leveled, the destruction shall be executed by[selection: a single direct overwrite consisting of zeros, a block erase]
For non-volatile memory other than EEPROM and flash, the destruction shall be executed by a single direct overwrite with a random pattern that
is changed before each write.
]
Application
Note:
For the purposes of this requirement, keying material refers to authentication data, passwords, secret/private symmetric keys, private asymmetric keys,
data used to derive keys, values derived from passwords, etc. “Plaintext keying material” may refer to a KEK that is used to encrypt other keying
material. Destruction of encrypted keying material may be accomplished by destroying the KEK used to encrypt it. If different mechanisms are used
for destroying different keying material, all relevant claims should be selected and the TSS should identify which keying material is destroyed by
which mechanism.
Key storage areas in non-volatile storage can be overwritten with any value that renders the keys unrecoverable. The value used can be all zeroes,
all ones, or any other pattern or combination of values significantly different than the value of the key itself. When ‘a value that does not contain
any CSP’ is chosen, it means that the TOE uses some other specified data not drawn from a source that may contain keying material or reveal information
about it or any other TSF-protected data. In other words, the data used for overwriting is carefully selected and not taken from a general ‘pool’ that
might contain current or residual data that itself requires confidentiality protection. If multiple copies exist, all copies must be destroyed.
The evaluator shall verify that the TSS identifies all plaintext keying material and CSPs stored by the TOE, the type of memory in which it is stored,
and when and how the keying material is erased. If the TOE uses one or more KEKs to protect stored keying material, the evaluator shall verify that the
TSS describes the destruction of that keying material, either directly or by destruction of the KEK used to encrypt it.
If different types of memory are used to store the materials to be protected, the evaluator shall check to ensure that the TSS describes the
clearing procedure in terms of the memory in which the data are stored (for example, "secret keys stored on flash are cleared by overwriting once
with zeros, while secret keys stored on the internal persistent storage device are cleared by overwriting one time with a random pattern that is
changed before each write"). For block erases, the evaluator shall also ensure that the TSS identifies the block erase command that is used and
shall verify that the command used also addresses any copies of the plaintext key material that may be created, e.g. in order to optimize the use
of Flash memory.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
Evaluation Activity Note: The following tests likely require the TOE developer to
provide access to a test platform that provides the evaluator with tools that are
typically not found on the end consumer version of the TOE.
The evaluator shall perform the following tests for all keys and key material subject to destruction by the TOE. For these tests, the evaluator
shall utilize an appropriate development environment (e.g., a virtual machine) and development tools (debuggers, simulators, etc.) to test that
keys are cleared, including all copies of the key that may have been created internally by the TOE during normal cryptographic
processing with that key.
Test FCS_CKM.6:1:
Applied to each key held as plaintext in volatile memory and subject to
destruction by overwrite by the TOE (whether or not the plaintext value is
subsequently encrypted for storage in volatile or non-volatile memory). In the
case where the only selection made for the destruction method key was removal of
power, then this test is unnecessary. The evaluator shall:
Record the value of the key in the TOE subject to clearing.
Cause the TOE to perform a normal cryptographic processing with the
key from Step #1.
Cause the TOE to dump the entire memory of the TOE into a binary
file.
Search the content of the binary file created in Step #5 for instances
of the known key value from Step #1.
Break the key value from Step #1 into 3 similar sized pieces and
perform a search using each piece.
Steps 1-6 ensure that the complete key does not exist anywhere in
volatile memory. If a copy is found, then the test fails.
Step 7 ensures that partial key fragments do not remain in memory. If a fragment
is found, there is a minuscule chance that it is not within the context of a key
(e.g., some random bits that happen to match). If this is the case the test
should be repeated with a different key in Step #1. If a fragment is found the
test fails.
Test FCS_CKM.6:2:
Applied to each key held in non-volatile memory and subject to destruction
by overwrite by the TOE. The evaluator shall use special tools (as needed),
provided by the TOE developer if necessary, to view the key storage location:
Record the value of the key in the TOE subject to clearing.
Cause the TOE to perform a normal cryptographic processing with the
key from Step #1.
Search the non-volatile memory the key was stored in for instances of
the known key value from Step #1. If a copy is found, then the test
fails.
Break the key value from Step #1 into 3 similar sized pieces and
perform a search using each piece. If a fragment is found then the test is
repeated (as described for test 1 above), and if a fragment is found in the
repeated test then the test fails.
Test FCS_CKM.6:3:
Applied to each key held as non-volatile memory and subject to destruction
by overwrite by the TOE. The evaluator shall use special tools (as needed),
provided by the TOE developer if necessary, to view the key storage location:
Record the storage location of the key in the TOE subject to
clearing.
Cause the TOE to perform a normal cryptographic processing with the
key from Step #1.
TSF shall perform deterministic random bit generation services using
[selection:
DRBG Algorithm]
in accordance with
[selection:
List of standards]
after initialization.The following table provides the allowable choices for
completion of the selection operations of FCS_RBG.1.1.
Application
Note:
CNSA 1.0 and 2.0 requires the use of 256-bit AES and SHA-384 or SHA-512. SHA-256 and all SHA3
hashes are not allowed.
NISTSP 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 or in the TSS.
While any of the identified hash functions (SHA-384, SHA-512) are allowed for Hash_DRBG or HMAC_DRBG,
only AES-based implementations for CTR_DRBG are allowed.
This SFR must be included in the ST if random bits are provided by the TOE to tenant software,
or if it is used by the TOE itself to support or implement PP-specified security functionality.
This SFR is also needed if the following SFRs are included in the ST: FCS_IPSEC_EXT.1,
FCS_CKM.1/AKG, FCS_CKM.1/SKG, and FCS_COP.1/SigGen.
Also, this SFR must be claimed if "KDF-CTR," "KDF-FB," or
"KDF-DPI" is selected in FCS_CKM.5.
If "HMAC_DRBG" is selected, then FCS_COP.1/KeyedHash must be claimed.
If "Hash_DRBG" is selected, then FCS_COP.1/Hash must be claimed.
If "CTR_DRBG" is selected, then FCS_COP.1/SKC must be claimed.
The TSF shall use a [selection: TSF entropy source [assignment:
name of entropy
source],, multiple TSF entropy sources [assignment:
name of
entropy sources],, TSF interface for seeding]
for initialization and reseeding.
Application
Note:
For the selection in this requirement, the ST author selects "TSF entropy source" if a single entropy
source is used as input to the DRBG. The ST author selects "multiple TSF entropy sources" if a seed is
formed from a combination of two or more entropy sources within the TOE boundary. If the TSF implements
two or more separate DRBGs that are seeded in separate manners, this SFR should be iterated for each DRBG.
If multiple distinct entropy sources exist such that each DRBG only uses one of them, then each iteration
would select "TSF entropy source"; "multiple TSF entropy sources" is only selected if a single DRBG uses
multiple entropy sources for its seed. The ST author selects "TSF interface for seeding" if entropy source
data is generated outside the TOE boundary.
The TSF shall update the DRBG state by [selection: reseeding, uninstantiating and re-instantiating] using a [selection: TSF entropy source [assignment:
name of entropy source], multiple TSF entropy sources [assignment:
name of entropy sources],, TSF interface for obtaining entropy [assignment:
name of the interface]]
in the following situations: [selection:
never
on demand
on the condition: [assignment:
condition]
after [assignment:
time]
]
in accordance with [assignment:
list of standards].
FCS_RBG.4 Random Bit Generation (Internal Seeding - Multiple Sources)
The TSF shall be able to seed the DRBG using [selection: [assignment:
number] TSF software-based entropy sources, [assignment:
number] TSF hardware-based entorpy sources].
FCS_RBG.5 Random Bit Generation (Combining Entropy Sources)
The TSF shall [selection: hash, concatenate and hash, XOR, input into a linear feedback shift register, [assignment:
combining operation]]
[selection: output from TSF entropy sources, input from TSF interfaces for obtaining entropy]
resulting in a minimum of [assignment:
number of bits] bits of min-entropy to create
the entropy input into the derivation function as defined in [NISTSP 800-90A Revision
1].
Appendix B - Selection-based Requirements
As indicated in the introduction to this PP,
the baseline requirements
(those that must be performed by the TOE or its underlying platform)
are contained in the body of this PP.
There are additional requirements based on selections in the body of
the PP:
if certain selections are made, then additional requirements below must be included.
The TOE shall generate asymmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm
[selection:
Cryptographic key generation algorithm]
and specified cryptographic algorithm parameterskey sizes
[selection:
Cryptographic algorithm parameters]
that meet the following:
[selection:
List of standards]
The following table provides the allowable choices for
completion of the selection operations of FCS_CKM.1/AKG.
This SFR must be included in the ST if asymmetric key generation is a service provided by the TOE to tenant software, or if it is
used by the TOE itself to support or implement PP-specified security functionality.
This SFR must also be claimed in the ST if FCS_IPSEC_EXT.1 is claimed, or if "causing the TOE to generate [asymmetric] keys/secrets"
is selected in FCS_STG_EXT.1.2.
For RSA the choice of the modulus implies the resulting key sizes of the public and private keys generated using the specified standard
methods. RSA key generation with modulus size 2048 bits is no longer permitted by CNSA.
For Finite Field Cryptography (FFC) DSA, ST authors should consult schemes for guidelines on use. FIPS PUB 186-5 does not approve DSA for
digital signature generation but allows DSA for digital signature verification for legacy purposes. “FFC-ERB” or “FFC–RS” may be claimed
only for generating private and public keys when “DH” is claimed in FCS_CKM_EXT.7.
When generating ECC keys pairs for key agreement and if “ECDH” is claimed in FCS_CKM_EXT.7, then “ECC–ERB” or “ECC–RS” must be claimed. The
sizes of the private key, which is a scalar, and the public key, which is a point on the elliptic curve, are determined by the choice of the curve.
When generating ECC key pairs for digital signature generation and if “ECDSA” is claimed in FCS_COP.1/SigGen, then “ECC–ERB” or “ECC–RS”
must be claimed. The sizes of the private key, which is a scalar, and the public key, which is a point on the elliptic curve, are determined
by the choice of the curve.
The evaluator shall examine the TSS to verify that it describes how the TOE generates a key based on output from a random bit generator
as specified in FCS_RBG.1. The evaluator shall review the TSS to verify that it describes how the functionality described by FCS_RBG.1
is invoked.
The evaluator shall examine the TSS to verify that it identifies the usage, and key lifecycle for keys generated using each selected algorithm.
The evaluator shall examine the TSS to verify that any one-time values such as nonces or masks are constructed in accordance with the relevant
standards.
If the TOE uses the generated key in a key chain/hierarchy then the evaluator shall verify that the TSS describes how the key is used as part of
the key chain/hierarchy.
Guidance
The evaluator shall verify that the Guidance instructs the administrator how to configure the TOE to generate keys for the selected key generation
algorithms for all key types and uses identified in the TSS.
Tests
The following tests are conditional based upon the selections made in the SFR.
The evaluator shall perform the following test or witness respective tests
executed by the developer. The tests must be executed on a platform that is as
close as practically possible to the operational platform (but which may be
instrumented in terms of, for example, use of a debug mode). Where the test is
not carried out on the TOE itself, the test platform shall be identified and the
differences between test environment and TOE execution environment shall be
described.
RSA Key Generation
Identifier
Cryptographic Key Generation Algorithm
Cryptographic Algorithm Parameters
List of Standards
RSA
RSA
Modulus of size [selection: 3072, 4096, 6144, 8192] bits
Rabin-Miller prime test [2100, 2Security String] (methods 2, 4, 5 only)
p mod 8 value [0,1,3,5,7]
q mod 8 value [0,1,3,5,7]
Private key format [standard, Chinese Remainder Theorem]
Public exponent [fixed value, random]
The evaluator shall verify the ability of the TSF to correctly produce values
for the RSA 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.
Testing for Random Provable Primes and Conditional Methods
To test the key generation method for the Random Provable primes method and for
all the Primes with Conditions methods (methods 1, 3-5), the evaluator must seed
the TSF key generation routine with sufficient data to deterministically
generate the RSA key pair.
For each supported combination of the above input parameters, 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 by a known good implementation using the same input
parameters.
Testing for Random Probable Primes Method
If the TOE generates Random Probable Primes (method 2) then, if possible, the
Random Probable primes method should also be verified against a known good
implementation as described above. If verification against a known good
implementation is not possible, the evaluator shall have the TSF generate 25 key
pairs for each supported key length nlen and verify that all of the following
are true:
n = p*q
p and q are probably prime according to Miller-Rabin tests with error
probability <2(-125)
To test the TOE’s ability to generate asymmetric cryptographic keys using
elliptic curves, the evaluator shall perform the ECC Key Generation Test
and the ECC Key Validation Test using the following input parameters:
Elliptic curve [P-384, P-521]
Key pair generation method [extra random bits, rejection sampling]
ECC Key Generation Test
For each supported combination of the above input parameters the evaluator shall
require the implementation under test to generate 10 private/public key pairs
(d, Q). The private key, d, shall be generated using a
random bit generator as specified in FCS_RBG.1. The private key, d, is
used to compute the public key, Q’. The evaluator shall confirm that
0<d<n (where n is the order of the group),
and the computed value Q’ is then compared to the generated
public/private key pairs’ public key, Q, to confirm that Q is
equal to Q’.
ECC Key Validation Test
For each supported combination of the above parameters the evaluator shall
generate 12 private/public key pairs using the key generation function of a
known-good implementation. For each set of 12 public keys, the evaluator shall
modify four public key values by shifting x or y out of
range by adding the order of the field and modify four other public key values
by shifting x or y so that they are still in bounds, but
not on the curve. The remaining public key values are left unchanged (i.e.,
correct). To determine correctness, the evaluator shall submit the public keys
to the public key validation (PKV) function of the TOE and shall confirm that
the results correspond as expected for the modified and unmodified values.
Finite Field Cryptography Key Generation
Identifier
Cryptographic Key Generation Algorithm
Cryptographic Algorithm Parameters
List of Standards
FFC-ERB
FFC – Extra Random Bits
Static domain parameters approved for [selection:
IKE groups [selection: MODP-3072, MODP-4096,
MODP-6144, MODP-8192], TLS groups [selection:
ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192]]]
Static domain parameters approved for [selection:
IKE groups [selection: MODP-3072, MODP-4096,
MODP-6144, MODP-8192], TLS groups [selection:
ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192]]]
To test the TOE’s ability to generate asymmetric cryptographic keys using finite
fields, the evaluator shall perform the Safe Primes Generation Test and the Safe
Primes Validation Test using the following input parameter:
Safe Primes Generation Test
For each supported safe primes group, generate 10 key pairs. The evaluator shall
verify the correctness of the TSF’s implementation by comparing values generated
by the TSF with those generated by a known good implementation using the same
input parameters.
Safe Primes Verification Test
For each supported safe primes group, use a known good implementation to generate
10 key pairs. For each set of 10, the evaluator shall modify three such that
they are incorrect. The remaining values are left unmodified (i.e. correct). To
determine correctness, the evaluator shall submit the key pairs to the public
key validation (PKV) function of the TOE and shall confirm that the results
correspond as expected for the modified and unmodified values.
LMS Key Generation
To test the TOE’s ability to generate asymmetric cryptographic keys using LMS, the
evaluator shall perform the LMS Key Generation Test using the following input parameters:
LMS Key Generation Test
For each supported combination of the hash algorithm, Winternitz parameter, and tree height the
evaluator shall generate one public key for each of the test cases. The number of test cases
depends on the tree height:
Table 8: Number of LMS Test Cases
Height
Number of test cases
5
5
10
4
15
3
20
2
25
1
The evaluator shall verify the correctness of the TSF’s implementation by
comparing the public key generated by the TSF with that generated by a known
good implementation using the same input parameters.
ML-KEM Key Generation
To test the TOE’s ability to generate asymmetric cryptographic keys using ML-KEM,
the evaluator shall perform the Algorithm Functional Test using the following
input parameters:
Parameter set [ML-KEM-1024]
Random seed d [32 bytes]
Random seed z [32 bytes]
Algorithm Functional Test
For each supported parameter set the evaluator shall require the implementation under test to
generate 25 key pairs using 25 different randomly generated pairs of 32-byte seed values (d, z).
To determine correctness, the evaluator shall compare the resulting key pairs (ek, dk) with those
generated using a known-good implementation using the same inputs.
ML-DSA Key Generation
To test the TOE’s ability to generate asymmetric cryptographic keys using ML-DSA,
the evaluator shall perform the Algorithm Functional Test using the following
input parameters:
Parameter set [ML-DSA-87]
Random seed [32 bytes]
Algorithm Functional Test
For each supported parameter set the evaluator shall require the implementation
under test to generate 25 key pairs using 25 different randomly generated 32-byte
seed values. To determine correctness, the evaluator shall compare the resulting
key pairs with those generated using a known-good implementation using the same
inputs.
XMSS Key Generation
Identifier
Cryptographic Key Generation Algorithm
Cryptographic Algorithm Parameters
List of Standards
XMSS
XMSS
Private key size = [selection: 192 bits
with [selection:SHA-256/192, SHAKE256/192], 256 bits
with [selection:SHA-256, SHAKE256]], tree height =
[selection: 10, 16, 20]
To test the TOE’s ability to generate asymmetric cryptographic keys using
XMSS, the evaluator shall perform the XMSS Key
Generation Test using the following input parameters:
XMSS Key Generation Test
For each supported combination of hash algorithm and tree height, the evaluator
shall generate one public key for each test case. The number of test cases
depends on the tree height as specified in .
The evaluator shall verify the correctness of the TSF’s implementation by comparing
values generated by the TSF with those generated by a known good implementation using
the same input parameters.
Note: The number of test cases is limited due to the extreme amount of time it can
take to generate XMSS trees.
The TSF shall generate symmetric cryptographic keys in accordance with
a specified cryptographic key generation algorithm
[selection:
Cryptographic Key Generation Algorithm]
and specified cryptographic key sizes
[selection:
Cryptographic Key Sizes]
that meet the following:
[selection:
List of standards]
The following table provides the allowable choices for
completion of the selection operations of FCS_CKM.1/SKG.
Direct Generation from a Random Bit Generator as specified in FCS_RBG.1
[selection: 256, 384, 512] bits
NISTSP 800-133 Revision 2 (Section 6.1)[Direct generation of symmetric keys]
Application
Note:
This SFR must be included in the ST if it is a service provided by the TOE to tenant software,
or if it is used by the TOE itself to support or implement PP-specified security functionality.
This SFR must be included in the ST if "causing the TOE to generate [symmetric] keys/secrets"
is selected in FCS_STG_EXT.1.2.
This SFR must be claimed if any SFRs are claimed that require generation of a symmetric key, such as
FCS_COP.1/AEAD, FCS_COP.1/KeyedHash, FCS_COP.1/KeyWrap, FCS_COP.1/CMAC, or FCS_COP.1/SKC.
If this SFR is claimed in the ST, then FCS_CKM.6 and FCS_RBG.1 must also be claimed.
The evaluator shall examine the TSS to verify that it describes how the TOE obtains a symmetric
cryptographic key through direct generation from a random bit generator as specified in
FCS_RBG.1. The evaluator shall review the TSS to verify that it describes how the functionality
described by FCS_RBG.1 is invoked.
The evaluator shall examine the TSS to verify that it identifies the usage, and key lifecycle for
keys generated using each selected algorithm.
If the TOE uses the generated key in a key chain/hierarchy then the evaluator shall verify that the
TSS describes how the key is used as part of the key chain/hierarchy.
Guidance
The evaluator shall verify that the AGD instructs the administrator how to configure the TOE to
use the RBG to generate symmetric keys for all uses identified in the ST.
Tests
The following tests are conditional based upon the selections made in the SFR.
The evaluator shall perform the following test or witness respective tests
executed by the developer. The tests must be executed on a platform that is as
close as practically possible to the operational platform (but which may be
instrumented in terms of, for example, use of a debug mode). Where the test
is not carried out on the TOE itself, the test platform shall be identified and
the differences between test environment and TOE execution environment shall be
described.
To test the TOE’s ability to generate symmetric cryptographic keys using a
random bit generator, the evaluator shall configure the asymmetric cryptographic
key generation capability for each claimed key size. The evaluator shall use the
description of the RBG interface to verify that the TOE requests and receives an
amount of RBG output greater than or equal to the requested key size.
FCS_CKM.2 Cryptographic Key Distribution
This component must be included in the ST if the TOE implements any of the following features:
The TSF shall distribute cryptographic keys in accordance with a specified cryptographic
key distribution method [selection: key encapsulation, key wrapping, encrypted channels] that meets the following: [none].
Application
Note:
If "key encapsulation" is selected, FCS_COP.1/KeyEncap must be claimed, which specifies the
relevant list of standards.
If "key wrapping" is selected, FCS_COP.1/KeyWrap must be claimed, which specifies the relevant
list of standards.
If "encrypted channels" is selected, FTP_ITC_EXT.1 must be claimed.
The evaluator shall ensure that the TSS documents that the security strength supported by
the selected key distribution methods is sufficient for the security strength of the keys
distributed through those methods.
It is not necessary to identify the services that use each key distribution method here. That
information should be documented in the requirements for the individual services and
protocols that invoke key distribution.
Guidance
The evaluator shall verify that the AGD guidance instructs the administrator
how to configure the TOE to use the selected key distribution methods.
The TSF shall perform [authenticated encryption with associated data] in accordance with a specified
cryptographic algorithm
[selection:
Cryptographic algorithm]
and cryptographic key sizes
[selection:
Cryptographic key sizes]
that meet the following:
[selection:
List of standards]
The following table provides the allowable choices for
completion of the selection operations of FCS_COP.1/AEAD.
AES in GCM mode with non-repeating IVs using [selection: deterministic, RBG-based],
IV construction; the tag must be of length
[selection: 96, 104, 112, 120, 128] bits.
The evaluator shall examine the TSS to ensure that it describes the construction of any IVs,
nonces, and tags in conformance with the relevant specifications.
If a CCM mode algorithm is selected, then the evaluator shall examine the TOE summary
specification to confirm that it describes how the nonce is generated and that the same nonce is
never reused to encrypt different plaintext pairs under the same key.
If a GCM mode algorithm is selected, then the evaluator shall examine the TOE summary
specification to confirm that it describes how the IV is generated and that the same IV is never
reused to encrypt different plaintext pairs under the same key. The evaluator shall also confirm
that for each invocation of GCM, the length of the plaintext is at most (232)-2 blocks.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The following tests may 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 are conditional based upon the selections made in the SFR. The
evaluator shall perform the following test or witness respective tests executed by
the developer. The tests must be executed on a platform that is as close as practically
possible to the operational platform (but which may be instrumented in terms of,
for example, use of a debug mode). Where the test is not carried out on the TOE
itself, the test platform shall be identified and the differences between test
environment and TOE execution environment shall be described.
AES-CCM
To test the TOE’s implementation of AES-CCM authenticated encryption functionality the
evaluator shall perform the Algorithm Functional Tests described below using the following
input parameters:
Key Size [256] bits
Associated data size [0-65536] bits in increments of 8
Payload size [0-256] bits in increments of 8
IV/Nonce size [64-104] bits in increments of 8
Tag size [32-128] bits in increments of 16
Algorithm Functional Tests
Unless otherwise specified, the following tests should use random data, a tag size of 128 bits,
IV/Nonce size of 104 bits, payload size of 256 bits, and associated data size of 256 bits. If any of
these values are not supported, any supported value may be used. The evaluator shall compare
the output from each test case against results generated by a known-good implementation with
the same input parameters.
Variable Associated Data Test
For each claimed key size, and for each supported associated data size from 0 through 256 bits in
increments of 8 bits, the TOE must be tested by encrypting 10 test cases using all random data.
In addition, for each key size, the TOE must be tested by encrypting 10 cases with associated
data lengths of 65536 bits, if supported.
Variable Payload Test
For each claimed key size, and for each supported payload size from 0 through 256 bits in
increments of 8 bits, the TOE must be tested by encrypting 10 test cases using all random data.
Variable Nonce Test
For each claimed key size, and for each supported IV/Nonce size from 64 through 104 bits in
increments of 8 bits, the TOE must be tested by encrypting 10 test cases using all random data.
Variable Tag Test
For each claimed key size, and for each supported tag size from 32 through 128 bits in
increments of 16 bits, the TOE must be tested by encrypting 10 test cases using all random data.
Decryption Verification Test
For each claimed key size, for each supported associated data size from 0 through 256 bits in
increments of 8 bits, for each supported payload size from 0 through 256 bits in increments of 8
bits, for each supported IV/Nonce size from 64 through 104 bits in increments of 8 bits, and for
each supported tag size from 32 through 128 bits in increments of 16 bits, the TOE must be
tested by decrypting 10 test cases using all random data.
AES-GCM
AES in GCM mode with nonrepeating IVs using
[selection: deterministic, RBG-based] IV construction;
the tag must be of length [selection: 96, 104, 112, 120, or 128] bits.
To test the TOE’s implementation of AES-GCM authenticated encryption functionality the
evaluator shall perform the Encryption Algorithm Functional Tests and Decryption Algorithm
Functional Tests as described below using the following input parameters:
Key Size [256] bits
Associated data size [0-65536] bits
Payload size [0-65536] bits
IV size [96] bits
Tag size [96, 104, 112, 120, 128] bits
Encryption Algorithm Functional Tests
The evaluator shall generate 15 test cases using random data for each combination of
the above parameters as follows:
Each claimed key size,
Each supported tag size,
Four supported non-zero payload sizes, such that two are multiples of 128 bits
and two are not multiples of 128 bits,
Four supported non-zero associated data sizes, such that two are multiples of
128 bits and two are not multiples of 128 bits, and
An associated data size of zero, if supported.
Note that the IV size is always 96 bits.
The evaluator shall compare the output from each test case against results generated by a known-
good implementation with the same input parameters.
Decryption Algorithm Functional Tests
The evaluator shall test the authenticated decrypt functionality of AES-GCM by supplying 15
test cases for the supported combinations of the parameters as described above. For each
parameter combination the evaluator shall introduce an error into either the Ciphertext or the Tag
such that approximately half of the cases are correct and half the cases contain errors.
FCS_COP.1/CMAC Cryptographic Operation - CMAC
This component may also be included in the ST as if optional.
The TSF shall perform [CMAC] in accordance with a specified cryptographic algorithm
[selection:
Cryptographic algorithm]
and cryptographic key sizes
[selection:
Cryptographic key sizes]
that meet the following:
[selection:
List of standards]
The following table provides the allowable choices for
completion of the selection operations of FCS_COP.1/CMAC.
The evaluator shall examine the TSS to verify that the IV consists of all zeros in accordance with
the relevant standards.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The following tests may 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 are conditional based upon the selections made in the SFR. The
evaluator shall perform the following test or witness respective tests executed by
the developer. The tests must be executed on a platform that is as close as practically
possible to the operational platform (but which may be instrumented in terms of,
for example, use of a debug mode). Where the test is not carried out on the TOE
itself, the test platform shall be identified and the differences between test
environment and TOE execution environment shall be described.
AES-CMAC
To test the TOE’s ability to generate MAC values using AES in CMAC mode the evaluator shall
perform the CMAC Generation Test and CMAC Verification Test using the following input
parameters:
Key Size [256] bits
Message size [0-524288] bits in increments of 8
MAC sizes [1-128] bits
CMAC Generation Test
The evaluator shall generate eight test cases using random keys and data for each combination of
the above parameters as follows:
For each claimed key size,
For four message sizes as follows:
The smallest supported message size,
The largest supported message size,
Two sizes that are divisible by the block size, and
Two sizes that are not divisible by the block size
For three MAC sizes as follows:
The smallest supported MAC size,
The largest supported MAC size, and
Some other supported MAC size
The evaluator shall compare the output from each test case against results generated by a known-
good implementation with the same input parameters.
CMAC Verification Test
The evaluator shall generate 20 test cases using random keys and data for each combination of
the above parameters as follows:
For each claimed key size,
For four message sizes as follows:
The smallest supported message size,
The largest supported message size,
Two sizes that are divisible by the block size, and
Two sizes that are not divisible by the block size
For three MAC sizes as follows:
The smallest supported MAC size,
The largest supported MAC size, and
Some other supported MAC size
The evaluator shall modify the tag such that 25% of the test cases in each group of 20 test
cases should fail.
The evaluator shall determine that the verification fails for the test cases with modified inputs,
and succeeds for those with unmodified inputs.
FCS_COP.1/Hash Cryptographic Operation - Hashing
This component may also be included in the ST as if optional.
The TSF shall perform [cryptographic hashing] in accordance with a specified
cryptographic algorithm
[selection: SHA-256, SHA-384, SHA-512, SHA3-384, SHA3-512] that meet the following:
[selection: ISO/IEC 10118-3:2018 [SHA, SHA3], FIPS PUB 180-4 [SHA], FIPS PUB 202 [SHA3]].
Application
Note:
In accordance with CNSA 1.0 and 2.0:
SHA-1 hash is no longer permitted to be used as a hash function,
SHA3 hashes may be used only for internal hardware functionality such as
boot integrity checks, and
SHA-256 is permitted only for use as a PRF or MAC as part of a key derivation function,
or as part of LMS or XMSS.
The hash selection should be consistent with the overall strength of the
algorithm used for signature generation. For example, the TOE should choose SHA-384 for 3072-bit RSA,
4096-bit RSA, or ECC with P-384; and SHA-512 for ECC with P-521.
The evaluator shall examine the TSS to verify that if SHA-256 is selected, that it is being
used only as a PRF or MAC step in a key derivation function or as part of LMS, and not as a hash algorithm.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The following tests may 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 are conditional based upon the selections made in the SFR. The
evaluator shall perform the following test or witness respective tests executed by
the developer. The tests must be executed on a platform that is as close as practically
possible to the operational platform (but which may be instrumented in terms of,
for example, use of a debug mode). Where the test is not carried out on the TOE
itself, the test platform shall be identified and the differences between test
environment and TOE execution environment shall be described.
SHA-256, SHA-384, SHA-512
To test the TOE’s ability to generate hash digests using SHA2 the evaluator shall
perform the Algorithm Functional Test, Monte Carlo Test, and Large Data Test for each claimed
SHA2 algorithm.
Algorithm Functional Test
The evaluator shall generate a number of test cases equal to the block size of the hash (512 for
SHA2-256; 1024 for the other SHA2 algorithms).
Each test case is to consist of random data of a random length between 0 and 65536 bits, or the
largest size supported.
Each test case is to consist of random data of a random length between 0 and 65536 bits, or the
largest size supported.
Monte Carlo Test
Monte Carlo tests begin with a single seed and run 100 iterations of the chained computation.
There are two versions of the Monte Carlo test for SHA-1 and SHA-2. Either one is acceptable.
For the Standard Monte Carlo test the message hashed is always three times the length of the
initial seed.
For j = 0 to 99
A = B = C = SEED
For i = 0 to 999
MSG = A || B || C
MD = SHA(MSG)
A = B
B = C
C = MD
Output MD
SEED = MD
For the alternate version of the Monte Carlo Test, the hashed message is always the same length as
the seed.
INITIAL_SEED_LENGTH = LEN(SEED)
For j = 0 to 99
A = B = C = SEED
For i = 0 to 999
MSG = A || B || C
if LEN(MSG) >= INITIAL_SEED_LENGTH:
MSG = leftmost INITIAL_SEED_LENGTH bits of MSG
else:
MSG = MSG || INITIAL_SEED_LENGTH - LEN(MSG) 0 bits
MD = SHA(MSG)
A = B
B = C
C = MD
Output MD
SEED = MD
The evaluator shall compare the output against results generated by a known-good
implementation with the same input.
Large Data Test
The implementation must be tested against one test case each on large data messages of 1GB,
2GB, 4GB, and 8GB of data as supported. The data need not be random. It may, for example,
consist of a repeated pattern of 64 bits.
The evaluator shall compare the output against results generated by a known-good
implementation with the same input.
SHA3-384, SHA3-512
To test the TOE’s ability to generate hash digests using SHA3 the evaluator shall perform the
Algorithm Functional Test, Monte Carlo Test, and Large Data Tests for each claimed SHA3
algorithm.
Algorithm Functional Test
Generate a test case consisting of random data for every message length from 0 bits (or the
smallest supported message size) to rate bits, where rate equals
832 for SHA3-384 and
576 for SHA3-512.
Additionally, generate tests cases of random data for messages of every multiple of (rate+1) bits
starting at length rate, and continuing until 65535 is exceeded.
The evaluator shall compare the output against results generated by a known-good
implementation with the same input.
Monte Carlo Test
Monte Carlo tests begin with a single seed and run 100 iterations of the chained computation.
For this Monte Carlo Test, the hashed message is always the same length as the seed.
MD[0] = SEED
INITIAL_SEED_LENGTH = LEN(SEED)
For 100 iterations
For i = 1 to 1000
MSG = MD[i-1];
if LEN(MSG) >= INITIAL_SEED_LENGTH:
MSG = leftmost INITIAL_SEED_LENGTH bits of MSG
else:
MSG = MSG || INITIAL_SEED_LENGTH - LEN(MSG) 0 bits
MD[i] = SHA3(MSG)
MD[0] = MD[1000]
Output MD[0]
The evaluator shall compare the output against results generated by a known-good
implementation with the same input.
Large Data Test
The implementation must be tested against one test case each on large data messages of 1GB,
2GB, 4GB, and 8GB of data as supported. The data need not be random. It may, for example,
consist of a repeated pattern of 64 bits.
The evaluator shall compare the output against results generated by a known-good
implementation with the same input.
The TSF shall perform [keyed hash message authentication] in accordance
with a specified cryptographic algorithm
[selection:
Keyed Hash Algorithm]
and cryptographic key sizes
[selection:
Cryptographic key sizes]
that meet the following:
[selection:
List of standards]
The following table provides the allowable choices for
completion of the selection operations of FCS_COP.1/KeyedHash.
Application
Note:
The HMAC minimum key sizes in the table are specified in ISO/IEC 9797-2:2021, which requires that the
minimum key size be equal to the digest size. The FIPS standard specifies no minimum or maximum
key sizes, so if FIPS PUB 198-1 is selected, larger or smaller key sizes may be used. This is
indicated by the parenthesized annotations in the Cryptographic Key Sizes column.
In accordance with CNSA 1.0 and 2.0, HMAC-SHA-256 may be used only as a PRF or MAC step in a
key derivation function.
The evaluator shall examine the TSS to ensure that the size of the key is sufficient for the desired
security strength of the output.
The evaluator shall examine the TSS to verify that if HMAC-SHA-256 is selected, that it is being
used only as a PRF or MAC step in a key derivation function.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The following tests are conditional based upon the selections made in the SFR. The evaluator
shall perform the following test or witness respective tests executed by the developer. The tests
must be executed on a platform that is as close as practically possible to the operational platform
(but which may be instrumented in terms of, for example, use of a debug mode). Where the test
is not carried out on the TOE itself, the test platform shall be identified and the differences
between test environment and TOE execution environment shall be described.
HMAC
[selection:ISO/IEC 9797-2:2021 (Section 7 “MAC Algorithm 2”), FIPS PUB 198-1]
To test the TOE’s ability to generate keyed hashes using HMAC the evaluator shall perform the
Algorithm Functional Test for each combination of claimed HMAC algorithm the following
parameters:
MAC length [32-[digest size of hash function (256, 384, 512)]] bits
Algorithm Functional Test
For each supported Hash function the evaluator shall generate 150 test cases using random input
messages of 128 bits, random supported key lengths, random keys, and random supported MAC
lengths such that across the 150 test cases:
The key length includes the minimum, the maximum, a key length equal to the block
size, and key lengths that are both larger and smaller than the block size.
The MAC size includes the minimum, the maximum, and two other random values.
The evaluator shall compare the output against results generated by a known-good
implementation with the same input.
The TSF shall perform [key encapsulation] in accordance with a specified cryptographic algorithm
[selection:
Cryptographic algorithm]
and cryptographic key sizes
[selection:
Cryptographic key sizes]
that meet the following:
[selection:
List of standards]
The following table provides the allowable choices for
completion of the selection operations of FCS_COP.1/KeyEncap.
Application
Note:
This SFR is claimed when "key encapsulation" is selected in FCS_CKM.2.1. For this PP, the only anticipated use of key encapsulation is
the use of ML-KEM as part of key establishment for trusted communications.
The evaluator shall ensure that the TSS documents that the selection of the key size is
sufficient for the security strength of the key encapsulated.
The evaluator shall examine the TSS to verify that any one-time values such as nonces or masks
are constructed and used in accordance with the relevant standards.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The following tests may 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 are conditional based upon the selections made in the SFR. The
evaluator shall perform the following test or witness respective tests executed by
the developer. The tests must be executed on a platform that is as close as practically
possible to the operational platform (but which may be instrumented in terms of,
for example, use of a debug mode). Where the test is not carried out on the TOE
itself, the test platform shall be identified and the differences between test
environment and TOE execution environment shall be described.
ML-KEM Key Encapsulation
To test the TOE’s implementation of ML-KEM key encapsulation/decapsulation, the evaluator
shall perform the Encapsulation Test and the Decapsulation Test using the following input
parameters:
Encapsulation Parameters:
Parameter set [ML-KEM-1024]
Previously generated encapsulation key (ek)
Random value (m) [32 bytes]
Decapsulation Parameters:
Parameter set [ML-KEM-1024]
Previously generated decapsulation key (dk)
Previously generated ciphertext (c) [32 bytes]
Encapsulation Test
For each supported parameter set the evaluator shall generate 25 test cases consisting of an
encapsulation key ek and random value m. For each test case the valuator shall require the
implementation under test to generate the corresponding shared secret k and ciphertext c. To
determine correctness, the evaluator shall compare the resulting values with those generated
using a known-good implementation using the same inputs.
Encapsulation Key Check (if supported)
The evaluator shall generate 10 encapsulation keys such that:
Five of the encapsulation keys are valid, and
Five of the encapsulation keys are modified such that a value in the noisy linear
system is encoded into the key as a value greater than Q.
The evaluator shall invoke the TOE’s Encapsulation Key Check functionality to determine the
validity of the 10 keys. The unmodified keys should be determined valid, and the modified keys
should be determined invalid.
Decapsulation Key Check (if supported)
The evaluator shall generate 10 decapsulation keys such that:
Five of the decapsulation keys are valid, and
Five of the decapsulation keys are modified such that the concatenated
values ek||H(ek) will no longer match by modifying H(ek) to be a different value.
The evaluator shall invoke the TOE’s Decapsulation Key Check functionality to determine the
validity of the 10 keys. The unmodified keys should be determined valid, and the modified keys
should be determined invalid.
Decapsulation Test
For each supported parameter set the evaluator shall use a single previously generated
decapsulation key dk and generate 10 test cases consisting of valid and invalid ciphertexts c. For
each test case the evaluator shall require the implementation under test to generate the
corresponding shared secret k whether or not the ciphertext is valid. To determine correctness,
the evaluator shall compare the resulting values with those generated using a known-good
implementation using the same inputs.
The TSF shall perform [digital signature generation] in accordance with a specified
cryptographic algorithm
[selection:
Cryptographic algorithm]
and cryptographic key sizes
[selection:
Cryptographic key sizes]
that meet the following:
[selection:
List of standards]
The following table provides the allowable choices for
completion of the selection operations of FCS_COP.1/SigGen.
Elliptic Curve [selection: P-384, P-521], per-message secret number generation [selection: extra random bits, rejection sampling, deterministic] and hash function using[selection: SHA-384, SHA-512]
Application
Note:
This SFR must be included in the ST if digital signature generation is a service provided by the TOE to
tenant software, or if digital signature generation is used by the TOE itself to support or implement
PP-specified security functionality.
Specifically, this SFR must be included if "A digital signature of the stored key in accordance with FCS_COP.1/SigGen
using an asymmetric key that is protected in accordance with FCS_STG_EXT.2" is selected in FCS_STG_EXT.3.
If this SFR is included in the ST, then FCS_COP.1/Hash and FCS_RBG.1 must also be claimed.
The evaluator shall examine the TSS and verify that any hash function is the appropriate security
strength for the signing algorithm.
The evaluator shall examine the TSS to verify that any one-time values such as nonces or masks
are constructed and used in accordance with the relevant standards.
The evaluator shall examine the TSS to verify that the TOE has appropriate measures in place to
ensure that hash-based signature algorithms do not reuse private keys
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The following tests are conditional based upon the selections made in the SFR. The evaluator
shall perform the following test or witness respective tests executed by the developer. The tests
must be executed on a platform that is as close as practically possible to the operational platform
(but which may be instrumented in terms of, for example, use of a debug mode). Where the test
is not carried out on the TOE itself, the test platform shall be identified and the differences
between test environment and TOE execution environment shall be described.
RSA-PKCS Signature Generation
To test the TOE’s ability to perform RSA Digital Signature Generation using PKCS1-v1,5
signature type, the evaluator shall perform the Generated Data Test using the following input
parameters:
Generated Data Test
For each supported combination of the above parameters, the evaluator shall cause the TOE to
generate three test cases using random data. The evaluator shall compare the results against those
from a known-good implementation.
RSA-PSS Signature Generation
Identifier
Cryptographic Algorithm Parameters
Cryptographic Key Sizes
List of Standards
RSA-PSS
RSASSA-PSS
Modulus of size [selection: 3072, 4096, 6144, 8192] bits,
hash [selection:SHA-384, SHA-512], Salt Length (sLen)
such that [assignment:0 ≤ sLen ≤ hLen (Hash Output Length)]
and Mask Generation Function = MGF1
To test the TOE’s ability to perform RSA Digital Signature Generation using PSS signature type,
the evaluator shall perform the Generated Data Test using the following input parameters:
Generated Data Test
For each supported combination of the above parameters, the evaluator shall cause the TOE to
generate three test cases using random data. The evaluator shall compare the results against those
from a known-good implementation.
ECDSA Signature Generation
Elliptic Curve [selection: P-384, P-521],
per-message secret number generation
[selection: extra random bits, rejection sampling, deterministic]
and hash function using [selection:SHA-384, SHA-512]
To test the TOE’s ability to perform ECDSA Digital Signature Generation using extra random
bits or rejection sampling for secret number generation, the evaluator shall perform the
Algorithm Functional Test using the following input parameters:
To test the TOE’s ability to perform ECDSA Digital Signature Generation using deterministic
secret number generation, the evaluator shall perform the Algorithm Functional Test using the
following input parameters:
Algorithm Functional Test
For each supported combination of the above parameters, the evaluator shall cause the TOE to
generate 10 test cases using random data. The evaluator shall compare the results against those
from a known-good implementation.
LMS Signature Generation
Identifier
Cryptographic Algorithm Parameters
Cryptographic Key Sizes
List of Standards
LMS
LMS
Private key size = [selection:
192 bits with [selection: SHA256/192, SHAKE256/192],
256 bits with [selection:SHA-256, SHAKE256]] ,
Winternitz parameter = [selection: 1, 2, 4, 8],
and tree height = [selection: 5, 10, 15, 20, 25]
To test the TOE’s ability to generate cryptographic digital signature using LMS, the
evaluator shall perform the Algorithm Functional Test using the following input parameters:
Algorithm Functional Test
For each supported combination of the above parameters, the evaluator shall generate 10
signatures. The evaluator shall verify the correctness of the implementation by comparing values
generated by the TOE with those generated by a known good implementation using the same
input parameters.
ML-DSA Signature Generation
To test the TOE’s ability to generate digital signatures using ML-DSA, the
evaluator shall perform the Algorithm Functional Test using the following input parameters:
Parameter set [ML-DSA-87]
Seed [32 random bytes] (for non-deterministic signature testing), or
Seed [32 zero bytes] (for deterministic signature testing)
Message to sign [8-65535] bytes
Mu value (if generated externally)
Previously generated private key (sk)
Context (for external interface testing)
Algorithm Functional Test
For each combination of supported parameter set and capabilities, the evaluator shall require the
implementation under test to generate 15 signatures pairs using 15 different randomly generated
32-byte seed values. To determine correctness, the evaluator shall
compare the resulting key pairs with those generated using a known-good implementation using
the same inputs.
Known Answer Test for Rejection Cases
For each supported parameter set, the evaluator shall cause the TOE to generate signatures using
the data below and a deterministic seed of all 0’s. Correctness is determined by
comparing the hash of the resulting signature with the hash in the fourth row
for each corresponding test case below.
The test values are defined as follows:
Seed is the seed to generate the key pair (pk, sk)
Test case 87-RC-01
Seed: E4F5AFCF697E0EC3C1BDEB66FAA903221E803902F9C3F716E1056A63D77DC250
Hash of Keys: 61618E8DDA6998072C8EB36974E03880D741CAF0BD523356DFC161E7C9E63934
Message: F4F1C05004D5B946F69EAFE104C4020519086ADDB9582A20FDE887D13DFC36B1
Hash of sig: B584E38FA442FC3C81A147D4BDBF058D73C822CAF5CA4C06B0110867F60A8001
Test case 87-RC-02
Seed: 8B828D871254D6C57384A8E7025AA3F7160CAD1D2C754499DF3844426062C3DD
Hash of Keys: BB64481317D6C0DBAD20C0C7EF11078AD54E5D574F4A07652115A95F77C655FA
Message: 0F9409C5A4930C25B83FC5B77FDB5BB49C75372DE724D9C1A77DB700CF0CF154
Hash of sig: F86B49BE9DEB2B209BDEB4E922E5939E92D38E562C44BB09AFBD67323C345192
Test case 87-RC-03
Seed: E693D282CACB8CE65FD4D108DA7A373F097F0AA9713550BE242AAD5BD3E2E452
Hash of Keys: B0BEAF56713A69BD4AB2CBEE006FA5001E7B41F3AE541E05F088933AA0CC78DF
Message: 24DABB9D57ADEBD560ED65D9451C5106D437061708F849BA53F3543CDF9AAAE0
Hash of sig: DBF65CEFF9F96A74AAF6F3AB27B043231BE6AA04FBA2EEC987A24A00BDD6A08E
Test case 87-RC-04
Seed: 4002163EB8EED01A8E0919BA8C07D291341EDCAE25B02B9779A2CFFE50561AF0
Hash of Keys: FED1BE685C20ECB322FC40D41DEE7E0E98D0409FBF989CAE71B8AD2D58AD645E
Message: EE316BB5EBED53325B4A55571C60657B53E353B51B831F4A0BBB28107EBA4BA8
Hash of sig: 3BE9B5545FDCED92547B3409C83B3312CCB5792A8EC3A4DA63BA692C79BEF17C
Test case 87-RC-05
Seed: 9C7AD524F65854C27E565BCEDF8E86D650F13A40D0448F9AE10C05F10F777120
Hash of Keys: 0EA872CA5A4BEA94F4E8EF7ED31800727899A51059FDEE111E5CB15F0233B534
Message: CE09831294AA96CAF684B9E667947B021C57B24C138EC7D4DA270694C82F2E08
Hash of sig: 3B9526CEE6587F2418BFE603ADB0F7DF0D69EBA31C9F9F005C60C993945EBD33
Test case 87-RC-06
Seed: 2EB7676D4A28700DA7772A7A035EB495CAA6F842352A74824EF5FD891BC38B2A
Hash of Keys: D5B73703A1DDC5BCB0D14AE39B193A25D6ADA6535827973181ADB0BE70435A5B
Message: C2B3A0AC483A5517682285C205974B2A506946448A8F7D3E1934C155EFDFE922
Hash of sig: 375D598704B722C8A1FEF1626FD7738A532C06329AA4217357460E3B729660F8
Test case 87-RC-07
Seed: E4E80CCE8B26DF1B02B99949851EE2F907FE4F0CC34790352C76D5D91634D073
Hash of Keys: 84B7E61684A12698400B09EA332EA3C4FBCFA47FE37FD6AE725CBC5FA8A99D3F
Message: 89E6AB43C9CB1CC59C3986D53217A558357E62102A26F666F2B64CD1DBB7A536
Hash of sig: 7C4AABD163CAEF8F6EBFDA3E3EEBC0A9604675B0E991ABAFD284F1AE8BA07B2A
Test case 87-RC-08
Seed: 5787262B803499223D4E5A8C1EE572E89F7A69B359B3F8505355B0BDEAB95E5C
Hash of Keys: 85AE1DE605A7B479C02730BF4B7DD6D0FD8FFE5C980893CA6DAD00BD8BD1CE68
Message: D3230C4E061964BBFB17702432D5D36FC1EB3D1068F8CCAA84044776E3B5CC55
Hash of sig: D3ABE460EE2DD9595F413CFE2780A319E4E4DFD6592995298A7AB0B82A5E2815
Test case 87-RC-09
Seed: CE099B99330537DD153052243FC32ACAD509A126AB982410258858567D410D79
Hash of Keys: E04A9F15EDF8F078EB336CE624249EF2A8EDF2CDBF6A8276E9F5E92ED9B0BAE8
Message: 0035931762665F561A1B22176567E3B10FDE2441521F77030733A8E39312EEEE
Hash of sig: 3EEF413CB5EB179896ECA172D0DBFB9B251545DC561D61580BD5BBC8B6D734E1
Test case 87-RC-10
Seed: FC8F2929878CBD81E1CCC23913F290380120C043A4A8A251AEEBF09705B8E590
Hash of Keys: 7E2ECCA86F532E8E8092FEBB6E0007F92E7909AD2BCBE2E02AB375DAC9969E5E
Message: D3C28875D2671C0EF23BFDC8869E8ECF8868D3F0561C3134D254F7479D0CE0E5
Hash of sig: EB69A908EDCC04320A0B61AD57E21B044465F2037698636B64229CF2DB259789
Known Answer Test for Large Number of Rejection Cases (Total Rejection Count)
For each supported parameter set, the evaluator shall cause the TOE to generate signatures using
the data below and a deterministic seed of all 0’s. Correctness is determined by
comparing the hash of the resulting signature with the hash in the fourth row
of the corresponding test case below.
ML-DSA-87 Test Cases for Total Rejection Count
Test case 87-LN-01
Seed: 98B6298051D92BF37293C93C97370747BF527B87B71F6C4264182F45155ADE4C
Hash of Keys: 04A135B5C9B7020332C7B16E7108E8FF7FC1EAE1C23C5FA0B5D5CED0FEEE7424
Message: D7B0341269259083ABF3C8DC47559A19D57669B4486E0224F376DC43E577A3D8
Hash of sig: 58D72D76EC0FB65BFB9893C4479366B79DD7B8B7577E4291D13514FCC76C26DD
Test case 87-LN-02
Seed: DFB5BDD90F58571DCA962426C623F13D046BBE814D183886AC90D143EAD725A7
Hash of Keys: 2B6AB8CFCCCC41F759CAF01932E9413F5DC6D949BC827F739866929683FB155E
Message: 21005DB2B583CC826A9684BFFD0EE00AB97E0479FE4A1D266699337540145778
Hash of sig: C93EA34E00FFFFC3ECEA072D5FB038A83B5539CAF7B831AEDCFA785E50B3CA5E
Test case 87-LN-03
Seed: 5AD414E0DD0EF2FE685F342871875FDF06F503717A86C3B3466565ADD2096417
Hash of Keys: BD9C2D52F3FC78DB17E682DA2E78947ECFC0898333838D60C892700B2B0DDA9F
Message: 29139C279816B25F2D6BB52C8247D163544F7BA332C3CF63359B9E23FBC56515
Hash of sig: DB4BE2DE19FB40437BDB7E9B6578D665DB05B4E88C16907DF4546EBA9BE03AEA
Test case 87-LN-04
Seed: 484DD2F406A4D15F49A91AD5FC3BDC1D0FF253622EB68F83D6E1C870D0E89E29
Hash of Keys: A719DC9A77C91C46295555C2353BA0CBEA513DA9A92A5C34D2E949EFF46A12D8
Message: 6AD6E959F0EA60126364FB7C95FA71133F246A9265A11B4965EE78AB0CB5AF0E
Hash of sig: 5050D7A665074EC63D9F3966C1F01A1BFB18F9E83AE0B09F838BC1E2342ED6F4
Test case 87-LN-05
Seed: B25C1816F82D59940D5CB829BAC364AAD013C4C16415CE1CF6DCC2F15199B391
Hash of Keys: ADBB2CD43F222640BD9FF4E61C80E63853E8DC1F759C581B7447C9C166EAA38E
Message: 824E47322895BFFE37B6B4AFC41CF6115C07EEC0C24EB81076C87A1B01AE8617
Hash of sig: 667ADA46073BC69D64DC47BB9A76DD0D78302E7415D87D5E816B05FB95F9E84D
Test case 87-LN-06
Seed: B2CE72B3560AF07E06465881F56ADA00262BA708D87B73F39E04E310F3B8A3E9
Hash of Keys: FD9C4AC53AE803242A62DF933B8E8BAD6CE5207AC4A73683B6D9383B5E70B17A
Message: A1501CC84C917E0D2D7C27C2AC382220BD8FFFE807DB38E37A9E429EC2781911
Hash of sig: 779553B195E11558EE59EF3942F5F6B446A2144600D1F4F50B300C6C56504760
Test case 87-LN-07
Seed: AB01D0E591B7DDCD3C03395AED808FA2763C0A486D44119D621BE0FD0B022B25
Hash of Keys: 93B6ADE34F78A4ADB36B2F6D2C51DB793E659E1243E80488AE1C03B65125D6D7
Message: 8DE8122D89D15FE84A4C34F6B59B2C4B11F33B6A053154D199B634F557FDF5F6
Hash of sig: 0483045999A79B583F403DB96A736F0F0B24E2DFBC4E5CFA9B50E3D910786F07
Test case 87-LN-08
Seed: 15D60D3693762F82C9AC1DCB0576936651AC81D863842EDB91109C8EE83AE705
Hash of Keys: 2DF544E2E939AA717741C2437288FAEB308DEB8FF37A2652FAE34BAE8B84D779
Message: F05946A6113905C34163AEF2246FD69016CE24A7BA40F8E7E42EDAC2D0A44605
Hash of sig: F8383917AF79C8E540D2356AB05F08B465BF32DFEC444B787CE31BF48CC6C3DD
Test case 87-LN-09
Seed: 21212285BED53B3411705DAF5F3BDDB6F0618EB571B36EE11A74053407A269F5
Hash of Keys: 737061155A9A03F11F9FEBBB940BED4DD54542C4A6212F89A5EB4EC2BE542782
Message: FFE38246BF3DEFD9CAD15CC17CEA511C067D582E04227B479E32F9197CF91482
Hash of sig: C4C12C58032052FB2D21F0C6A7388A63154FB85B74287D2859DE6C1C6F7F277B
Test case 87-LN-10
Seed: A2744470587C71BA43EC26DC390CE3531978F315993C653E5D3EFD2849D5D9F1
Hash of Keys: B1BF37BFFB11531B6ADD697870D7DB2E2462D0A97A63F09C1D0038457C6D795A
Message: 9831A830231A160B9847203341A5F30BF3E87A2A482AEEA6886315C92B5C4E4C
Hash of sig: 46C669D2FEB643A38E54FF87B790CC33F44043A1B6B31DB9474D301328CA2A7F
XMSS Signature Generation
Identifier
Cryptographic Algorithm Parameters
Cryptographic Key Sizes
List of Standards
XMSS
XMSS
Private key size = [selection:
192 bits with [selection: SHA256/192, SHAKE256/192],
256 bits with [selection:SHA-256, SHAKE256]],
and tree height = [selection: 10, 16, 20]
To test the TOE’s ability to generate digital signatures using XMSS, the evaluator
shall perform the XMSS Key Generation Test using the following input parameters:
XMSS Key Generation Test
For each supported combination of the above parameters, the evaluator shall generate 10
signatures. The evaluator shall verify the correctness of the implementation by comparing values
generated by the TOE with those generated by a known-good implementation using the same
input parameters.
The TSF shall perform [digital signature verification] in accordance with a specified
cryptographic algorithm
[selection:
Cryptographic algorithm]
and cryptographic key sizes
[selection:
Cryptographic key sizes]
that meet the following:
[selection:
List of standards]
The following table provides the allowable choices for
completion of the selection operations of FCS_COP.1/SigVer.
Application
Note:
This SFR must be included in the ST if digital signature verification is a service provided by
the TOE to tenant software, or if digital signature verification is used by the TOE itself to
support or implement PP-specified security functionality.
Specifically, this SFR must be included if the ST Author chooses "implement an authenticated platform
firmware update mechanism as described in FPT_TUD_EXT.2" or "implement a delayed-authentication platform
firmware update mechanism as described in FPT_TUD_EXT.3" in FPT_TUD_EXT.1; or if the ST Author
selects "verification of a digital signature by trusted code/data" in FPT_ROT_EXT.2.
If this SFR is included in the ST, then FCS_COP.1/Hash must also be claimed.
The ST Author should choose the algorithm implemented to perform verification of digital signatures.
For the algorithm chosen, the ST Author should make the appropriate assignments/selections to specify the
parameters that are implemented for that algorithm. In particular, if ECDSA is selected as one of the signature
algorithms, the key size specified must match the selection for the curve used in the algorithm.
For elliptic curve-based schemes, the key size refers to the binary logarithm (log2) of the order of the
base point. As the preferred approach for digital signatures, elliptic curves will be required after all the
necessary standards and other supporting information are fully established.
The TOE may contain a public key which is integrity protected (e.g., in hardware), in which
case the FDP_ITC.1 and FDP_ITC.2 dependencies do not apply. In this case, no dependencies
may be chosen. For signature verifications, private keys are not necessary, so there are no
dependencies required for generating or destroying cryptographic keys.
If LMS or XMSS is claimed, then FCS_COP.1/XOF must also be claimed.
The evaluator shall examine the TSS to verify that any one-time values such as nonces or masks
are constructed and used in accordance with the relevant standards.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The following tests are conditional based upon the selections made in the SFR. The evaluator
shall perform the following test or witness respective tests executed by the developer. The tests
must be executed on a platform that is as close as practically possible to the operational platform
(but which may be instrumented in terms of, for example, use of a debug mode). Where the test
is not carried out on the TOE itself, the test platform shall be identified and the differences
between test environment and TOE execution environment shall be described.
RSA-PKCS Signature Verification
To test the TOE’s ability to perform RSA Digital Signature Verification using PKCS1-v1,5
signature type, the evaluator shall perform Generated Data Test using the following input
parameters:
Generated Data Test
For each supported combination of the above parameters, the evaluator shall cause the TOE to
generate six test cases using a random message and its signature such that the test cases are
modified as follows:
To test the TOE’s ability to perform RSA Digital Signature Verification using PSS signature
type, the evaluator shall perform the Generated Data Test using the following input parameters:
Generated Data Test
For each supported combination of the above parameters, the evaluator shall cause the TOE to
generate six test cases using random data such that the test cases are modified as follows:
The TOE must correctly verify the unmodified signatures and fail to verify the modified
signatures.
DSA Signature Verification
Identifier
Cryptographic Algorithm Parameters
Cryptographic Key Sizes
List of Standards
DSA
DSA
Domain parameters for (L, N) = [(3072, 256)] bits
FIPS PUB 186-4 (Section 4.7) [DSA Signature Verification]
To test the TOE’s ability to perform DSA Digital Signature Verification, the evaluator shall
perform the Algorithm Functional Test using the following input parameters:
Algorithm Functional Test
For each supported combination of the above parameters, the evaluator shall cause the TOE to
generate 15 test cases consisting of messages and signatures such that the 15 test cases are
modified as follows:
Three test cases are left unmodified
For three test cases the Message is modified
For three test cases the key is modified
For three test cases the r value is modified
For three test cases the s value is modified
The TOE must correctly verify the unmodified signatures and fail to verify the modified
signatures.
ECDSA Signature Verification
To test the TOE’s ability to perform ECDSA Digital Signature Verification, the evaluator shall
perform the Algorithm Functional Test using the following input parameters:
Algorithm Functional Test
For each supported combination of the above parameters, the evaluator shall cause the TOE to
generate test cases consisting of messages and signatures such that the 21 test cases are
modified as follows:
Three test cases are left unmodified
For three test cases the Message is modified
For three test cases the key is modified
For three test cases the r value is modified
For three test cases the s value is modified
For three test cases the value r is zeroed
For three test cases the value s is zeroed
The TOE must correctly verify the unmodified signatures and fail to verify the modified
signatures.
LMS Signature Verification
Identifier
Cryptographic Algorithm Parameters
Cryptographic Key Sizes
List of Standards
LMS
LMS
Private key size = [selection:
192 bits with [selection: SHA256/192, SHAKE256/192],
256 bits with [selection:SHA-256, SHAKE256]],
Winternitz parameter = [selection: 1, 2, 4, 8],
and tree height = [selection: 5, 10, 15, 20, 25]
To test the TOE’s ability to verify cryptographic digital signature using LMS, the
evaluator shall perform the Algorithm Functional Test using the following input parameters:
Algorithm Functional Test
For each supported combination of the above parameters, the evaluator shall generate 4 test cases
consisting of signed messages and keys, such that
One test case is unmodified (i.e. correct)
For one test case modify the message, i.e. the message is different
For one test case modify the signature, i.e. signature is different
For one test case modify the signature header so that it is a valid header for a different
LMS parameter set.
The TOE must correctly verify the unmodified test case and fail to verify the modified test cases.
XMSS Signature Verification
Identifier
Cryptographic Algorithm Parameters
Cryptographic Key Sizes
List of Standards
XMSS
XMSS
Private key size = [selection:
192 bits with [selection: SHA256/192, SHAKE256/192],
256 bits with [selection:SHA-256, SHAKE256]],
and tree height = [selection: 10, 16, 20]
To test the TOE’s ability to verify digital signatures using XMSS or XMSS MT, the evaluator shall
perform the XMSS digital signature verification test using the following input parameters:
XMSS Digital Signature Verification Test
For each supported combination of the above parameters, the evaluator shall generate four test
cases consisting of signed messages and keys, such that
One test case is unmodified (i.e. correct)
For one test case modify the message, i.e. the message is different
For one test case modify the signature, i.e. signature is different
For one test case modify the signature header so that it is a valid header
for a different XMSS parameter set
The evaluator shall verify the correctness of the implementation by verifying that the TOE
correctly verifies the unmodified test case and fails to verify the modified test cases.
ML-DSA Signature Verification
To test the TOE’s ability to validate digital signatures using ML-DSA, the
evaluator shall perform the Algorithm Functional Test using the following input parameters:
Parameter set [ML-DSA-87]
Previously generated signed Message [8-65535] bytes
Mu value (if generated externally)
Context (for external interface testing)
Previously generated Public key (pk)
Previously generated Signature
Algorithm Functional Test
For each combination of supported parameter set and capabilities, the evaluator shall require the
implementation under test to validate 15 signatures. Each group of 15 test
cases is modified as follows:
Three test cases are left unmodified
For three test cases the Signed message is modified
For three test cases the component of the signature that commits the signer to the message is
modified
For three test cases the component of the signature that allows the verifier to construct the vector z is
modified
For three test cases the component of the signature that allows the verifier to construct the hint array
is modified
The TOE must correctly verify the unmodified signatures and fail to verify the modified
signatures.
The TSF shall perform [symmetric-key encryption/decryption] in accordance with a
specified cryptographic algorithm
[selection:
Cryptographic Algorithm]
and cryptographic key sizes
[selection:
Cryptographic Key Sizes]
that meet the following:
[selection:
List of Standards]
The following table provides the allowable choices for
completion of the selection operations of FCS_COP.1/SKC.
Application
Note:
This SFR must be included in the ST if symmetric-key cryptography is a service provided by the TOE
to tenant software, or if the TOE itself uses SKC to support or implement PP-specified security
functionality.
Specifically, this SFR must be included if the ST includes FCS_IPSEC_EXT.1 or FCS_STG_EXT.2, or includes
any of the following selections:
The evaluator shall examine the TSS to ensure that it describes the construction of any IVs,
tweak values, and counters in conformance with the relevant specifications.
If XTS-AES is claimed then the evaluator shall examine the TSS to verify that the TOE creates
full-length keys by methods that ensure that the two key halves are different and independent.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
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 are conditional based upon the selections made in the SFR. The
evaluator shall perform the following test or witness respective tests executed by
the developer. The tests must be executed on a platform that is as close as practically
possible to the operational platform (but which may be instrumented in terms of,
for example, use of a debug mode). Where the test is not carried out on the TOE
itself, the test platform shall be identified and the differences between test
environment and TOE execution environment shall be described.
AES-CBC
To test the TOE’s ability to encrypt/decrypt data using AES in CBC mode, the evaluator
shall perform Algorithm Functional Tests and Monte Carlo Tests using the following
input parameters:
Key size [256] bits
Direction [encryption, decryption]
Algorithm Functional Tests
Algorithm Functional Tests are designed to verify the correct operation of the logical
components of the algorithm implementation under normal operation using different block sizes.
For AES-CBC, there are two types of AFTs:
Known-Answer Tests
For each combination of direction and claimed key size, the TOE must be tested using the
GFSBox, KeySbox, VarTxt, and VarKey test cases listed in Appendixes B through E of The
Advanced Encryption Standard Algorithm Validation Suite (AESAVS), NIST, 15 November 2002.
Multi-Block Message Tests
For each combination of direction and claimed key size, the TOE must be tested against 10 test
cases consisting of a random IV, random key, and random plaintext/ciphertext. The
plaintext/ciphertext starts with a length of 16 bytes and increases by 16 bytes for each test case
until reaching 160 bytes.
Monte Carlo Tests
Monte Carlo tests are intended to test the implementation under strenuous conditions. The TOE
must process the test cases according to the following algorithm once for each combination of
direction and key size:
Key[0] = Key
IV[0] = IV
PT[0] = PT
for i = 0 to 99 {
Output Key[i], IV[i], PT[0]
for j = 0 to 999 {
if (j == 0) {
CT[j] = AES-CBC-Encrypt(Key[i], IV[i], PT[j])
PT[j+1] = IV[i]
} else {
CT[j] = AES-CBC-Encrypt(Key[i], PT[j])
PT[j+1] = CT[j-1]
}
}
Output CT[j]
AES_KEY_SHUFFLE(Key, CT)
IV[i+1] = CT[j]
PT[0] = CT[j-1]
}
The above pseudocode is for encryption. For decryption, swap all instances of CT and PT.
The initial IV, key, and plaintext/ciphertext should be random.
The evaluator shall test the decrypt functionality using the same test as above,
exchanging CT and PT, and replacing AES-CBC-Encrypt with AES-CBC-Decrypt.
XTS-AES
Identifier
Cryptographic Algorithm
Cryptographic Key Sizes
List of Standards
XTS-AES
AES in XTS mode with unique tweak values that are consecutive
non-negative integers starting at an arbitrary non-negative integer
To test the TOE’s ability to encrypt/decrypt data using AES in XTS mode, the evaluator shall
perform the Single Data Unit Test and the Multiple Data Unit Test using the following input
parameters:
Direction [encryption, decryption]
Key size [512] bits
Tweak value format [128-bit hex string, data unit sequence number]
Single Data Unit Test
For each combination of claimed key size, direction, and supported tweak value format, the
evaluator shall generate 50 test cases consisting of random payload data. The payload data size is
determined randomly for each test case from supported values within the range [128-65536] bits.
The payload size and data unit size must be equal.
Multiple Data Unit Test
For each combination of claimed key size, direction, and supported tweak value format, the
evaluator shall generate 50 test cases consisting of random payload data. The payload data size is
determined randomly for each test case from supported values within the range [128-65536] bits.
Likewise, the data unit size is determined randomly for each test case from supported values
within the range [128-65535] bits. The payload size and data unit size must not be equal.
The evaluator shall verify the correctness of the TSF’s implementation by comparing values
generated by the TSF with those generated by a known good implementation using the same
input parameters.
AES-CTR
To test the TOE’s ability to encrypt/decrypt data using AES in CTR mode, the evaluator shall
perform the Algorithm Functional Test and the Counter Test using the following input
parameters:
Direction [encryption, decryption]
Key size [256] bits
Algorithm Functional Tests
Algorithm Functional Tests are designed to verify the correct operation of the logical
components of the algorithm implementation under normal operation using different block sizes.
For AES-CTR, there are three types of AFTs:
Known-Answer Tests
For each combination of direction and claimed key size, the TOE must be tested using the
GFSBox, KeySbox, VarTxt, and VarKey test cases listed in Appendixes B through E of The
Advanced Encryption Standard Algorithm Validation Suite (AESAVS), NIST, 15 November 2002.
Single Block Message Tests
For each combination of direction and claimed key, the evaluator shall generate 10 test cases
with a data size of 128 bits.
Partial Block Message Tests
Monte Carlo tests are intended to test the implementation under strenuous conditions. The TOE
must process the test cases according to the following algorithm once for each combination of
direction and key size:
For each combination of direction and claimed key, the evaluator shall generate five test cases
such that the data size is not a multiple of 128 bits.
The evaluator shall verify the correctness of the TSF’s implementation by comparing values
generated by the TSF with those generated by a known good implementation using the same
input parameters.
Counter Test
The evaluator shall generate a single message of 1000 blocks (128000 bits) and either encrypt or
decrypt it. Back-compute the IVs used. Verify that they are unique and increasing (encryption) or
decreasing (decryption).
The TSF shall perform [key wrapping] in accordance with a specified cryptographic algorithm
[selection:
Cryptographic algorithm]
and cryptographic key sizes
[selection:
Cryptographic key sizes]
that meet the following:
[selection:
List of standards]
The following table provides the allowable choices for
completion of the selection operations of FCS_COP.1/KeyWrap.
AES in GCM mode with non-repeating IVs using [selection: deterministic, RBG-based],
IV construction; the tag must be of length
[selection: 96, 104, 112, 120, 128] bits.
Application
Note:
This SFR is claimed when "key wrapping" is selected in FCS_CKM.2.1 or is used as a mechanism supporting verification of imported key integrity (FDP_ITC_EXT.1.2) or the integrity of stored key data (FCS_STG_EXT.3.1). NIST 800-57p1rev5 sec. 5.6.2 specifies that the size of key used to protect the key being
transported should be at least the security strength of the key it is protecting.
The evaluator shall ensure that the TSS documents that the selection of the key size is
sufficient for the security strength of the key wrapped.
The evaluator shall examine the TSS to ensure that it describes the construction of any IVs,
nonces, and MACs in conformance with the relevant specifications.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
For tests of AES-GCM and AES-CCM, see testing for FCS_COP.1/AEAD.
The following tests are conditional based upon the selections made in the SFR. The evaluator
shall perform the following test or witness respective tests executed by the developer. The tests
must be executed on a platform that is as close as practically possible to the operational platform
(but which may be instrumented in terms of, for example, use of a debug mode). Where the test
is not carried out on the TOE itself, the test platform shall be identified and the differences
between test environment and TOE execution environment shall be described.
AES-KW
To test the TOE’s ability to wrap keys using AES in Key Wrap mode the evaluator shall perform
the Algorithm Functional Tests using the following input parameters:
Key size [256] bits
Keyword cipher type [cipher, inverse]
Payload sizes [128-4096] bits by 64s
Algorithm Functional Test
The evaluator shall generate 100 encryption test cases using random data for each combination
of claimed key size, keyword cipher type, and six supported payload sizes such that the payload
sizes include the minimum, the maximum, two that are divisible by 128, and two that are not
divisible by 128.
The results shall be compared with those generated by a known-good implementation using the
same inputs.
The evaluator shall generate 100 decryption test cases using the same parameters as above, but
with 20 of each 100 test cases having modified ciphertext to produce an incorrect result. To
determine correctness, the evaluator shall confirm that the results correspond as expected for
both the modified and unmodified values.
AES-KWP
To test the TOE’s ability to wrap keys using AES in Key Wrap with Padding mode with padding
the evaluator shall perform the Algorithm Functional Tests using the following input parameters:
Key size [256] bits
Keyword cipher type [cipher, inverse]
Payload sizes [8-4096] bits by 8s
Algorithm Functional Test
The evaluator shall generate 100 encryption test cases using random data for each combination
of claimed key size, keyword cipher type, and six supported payload sizes such that the payload
sizes include the minimum, the maximum, two that are divisible by 128, and two that are not
divisible by 128.
The results shall be compared with those generated by a known-good implementation using the
same inputs.
The evaluator shall generate 100 decryption test cases using the same parameters as above, but
with 20 of each 100 test cases having modified ciphertext to produce an incorrect result. To
determine correctness, the evaluator shall confirm that the results correspond as expected for
both the modified and unmodified values.
FCS_COP.1/XOF Cryptographic Operation - Extendable-Output Function
The inclusion of this selection-based component depends upon selection in
FCS_COP.1.1/SigVer.
The TSF shall perform [extendable-output function] in accordance with a specified cryptographic algorithm
[selection:
Cryptographic Algorithm]
and parameters
[selection:
Parameters]
that meet the following:
[selection:
List of Standards]
The following table provides the allowable choices for
completion of the selection operations of FCS_COP.1/XOF.
Application
Note:
In accordance with CNSA 2.0, SHAKE is permitted to be used only as a component of LMS or XMSS.
Therefore this component is claimed only if LMS or XMSS is claimed in FCS_COP.1/SigVer.
Since LMS and XMSS use both SHAKE128 and SHAKE256 internally, claiming and testing of both functions is mandatory.
There are no additional TSS evaluation activities for this component.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The following tests are conditional based on the selections made in the SFR. The evaluator
shall perform the following tests or witness respective tests executed by the developer. The tests
must be executed on a platform that is as close as practically possible to the operational platform
(but which may be instrumented in terms of, for example, use of a debug mode). Where the test
is not carried out on the TOE itself, the test platform shall be identified and the differences
between test environment and TOE execution environment shall be described.
SHAKE
To test the TOE’s implementation of the SHAKE Extendable Output Function the evaluator shall
perform the Algorithm Functional Test, Monte Carlo Test, and Variable Output Test using the
following input parameters:
Function [SHAKE256]
Output length [16-65536] bits
Algorithm Functional Test
For each supported function, generate test cases consisting of random data for every message
length from 0 bits (if supported) to rate-1 bits, where rate equals 1088.
Additionally, generate tests cases of random data for messages of every multiple of (rate+1) bits
starting at length rate, and continuing until 65535 is exceeded.
Monte Carlo Test
The Monte Carlo test takes in a single 128-bit message (SEED) and desired output length in
bits, and runs 100 iterations of the chained computation. MaxOutBytes and MinOutBytes are the
largest and smallest supported input and output sizes in bytes, respectively.
Range = maxOutBytes - minOutBytes + 1
OutputLen = maxOutBytes
For j = 0 to 99
MD[0] = SEED
For i = 1 to 1000
MSG[i] = 128 leftmost bits of MD[i-1]
if (MSG[i] < 128 bits)
Append 0 bits on rightmost side of MSG[i] til MSG[i] is 128 bits
MD[i] = SHAKE(MSG[i], OutputLen * 8)
RightmostOutputBits = 16 rightmost bits of MD[i] as an integer
OutputLen = minOutBytes + (RightmostOutputBits % Range)
Output MD[1000], OutputLen
SEED = MD[1000]
Variable Output Test
This test measures the ability of the TOE to generate output digests of varying sizes.
The evaluator shall generate 512 test cases such that the input for each test case consists of 128-
bits of random data, and the output length includes the minimum supported value, the maximum
supported value, and 510 random values between the minimum and maximum digest sizes
supported by the implementation.
FCS_RBG.1 Random Bit Generation (RBG)
This component may also be included in the ST as if optional.
TSF shall perform deterministic random bit generation services using
[selection:
DRBG Algorithm]
in accordance with
[selection:
List of standards]
after initialization.The following table provides the allowable choices for
completion of the selection operations of FCS_RBG.1.
Application
Note:
CNSA 1.0 and 2.0 requires the use of 256-bit AES and SHA-384 or SHA-512. SHA-256 and all SHA3
hashes are not allowed.
NISTSP 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 or in the TSS.
While any of the identified hash functions (SHA-384, SHA-512) are allowed for Hash_DRBG or HMAC_DRBG,
only AES-based implementations for CTR_DRBG are allowed.
This SFR must be included in the ST if random bits are provided by the TOE to tenant software,
or if it is used by the TOE itself to support or implement PP-specified security functionality.
This SFR is also needed if the following SFRs are included in the ST: FCS_IPSEC_EXT.1,
FCS_CKM.1/AKG, FCS_CKM.1/SKG, and FCS_COP.1/SigGen.
Also, this SFR must be claimed if "KDF-CTR," "KDF-FB," or
"KDF-DPI" is selected in FCS_CKM.5.
If "HMAC_DRBG" is selected, then FCS_COP.1/KeyedHash must be claimed.
If "Hash_DRBG" is selected, then FCS_COP.1/Hash must be claimed.
If "CTR_DRBG" is selected, then FCS_COP.1/SKC must be claimed.
The TSF shall use a [selection: TSF entropy source [assignment:
name of entropy
source],, multiple TSF entropy sources [assignment:
name of
entropy sources],, TSF interface for seeding]
for initialization and reseeding.
Application
Note:
For the selection in this requirement, the ST author selects "TSF entropy source" if a single entropy
source is used as input to the DRBG. The ST author selects "multiple TSF entropy sources" if a seed is
formed from a combination of two or more entropy sources within the TOE boundary. If the TSF implements
two or more separate DRBGs that are seeded in separate manners, this SFR should be iterated for each DRBG.
If multiple distinct entropy sources exist such that each DRBG only uses one of them, then each iteration
would select "TSF entropy source"; "multiple TSF entropy sources" is only selected if a single DRBG uses
multiple entropy sources for its seed. The ST author selects "TSF interface for seeding" if entropy source
data is generated outside the TOE boundary.
If TSF entropy sources" is selected, FCS_RBG.3 must be claimed.
If "multiple TSF entropy sources" is selected, FCS_RBG.4 and FCS_RBG.5 must be claimed.
If "TSF interface for seeding" is selected, FCS_RGB.2 must be claimed.
The security strength of the entropy used for seeding depends on the functions for which the TSF uses
entropy. The security strength for the various functions is defined in Tables 2 and 3 of NISTSP 800-57A.
The TSF shall update the DRBG state by [selection: reseeding, uninstantiating and re-instantiating] using a [selection: TSF entropy source [assignment:
name of entropy source], multiple TSF entropy sources [assignment:
name of entropy sources],, TSF interface for obtaining entropy [assignment:
name of the interface]]
in the following situations: [selection:
never
on demand
on the condition: [assignment:
condition]
after [assignment:
time]
]
in accordance with [assignment:
list of standards].
Application
Note:
If a reseeding is selected in the first selection and something other than “never” is selected in the third
selection of FCS_RBG.1.3, but reseeding is not feasible, the TSF will uninstantiate RBGs, rather than produce
output that is of insufficient quality. The listed standards should specify the reseed interval and procedure
for uninstantiating and reseeding. The remaining selection allows the PP Author to require application-specific
conditions for reseeding.
"Uninstantiate” means that the internal state of the DRBG is no longer available for use. In the second
selection of FCS_RBG.1.3, “on demand” means that a TOE presents an interface to reseed as a TSFI (e.g.,
an API call). The interface causes the DRBG to reseed at the request of an authorized user, either with an
internal source, an external source, or from input provided through the TSFI (e.g., the API call).
If the ST specifies more than one DRBG, the evaluator shall examine the TSS to verify that it identifies the
usage of each DRBG mechanism.
The evaluator shall examine the TSS to verify that it specifies the DRBG type, identifies entropy sources
initializing and reseeding the DRBG, and the situations under which this may occur.
Guidance
The evaluator shall verify that the Guidance instructs the administrator how to configure the TOE to use the
selected DRBG mechanism(s), if necessary, and provides information regarding how to instantiate/call the DRBG
for RBG services.
If the ST claims that the DRBG state can be updated on demand, the evaluator shall verify that the guidance
includes instructions for how to perform this operation.
Tests
The following tests are conditional based upon the selections made in the SFR. The evaluator
shall perform the following test or witness respective tests executed by the developer. The tests
must be executed on a platform that is as close as practically possible to the operational platform
(but which may be instrumented in terms of, for example, use of a debug mode). Where the test
is not carried out on the TOE itself, the test platform shall be identified and the differences
between test environment and TOE execution environment shall be described.
HASH_DRBG, HMAC_DRBG
To test the TOE’s ability to generate random bits using Hash_DRBG or HMAC_DRBG, the
evaluator shall perform
the Algorithm Functional Test using the following input parameters:
Algorithm Functional Test
The evaluator shall generate 16 test groups for each claimed function. Eight with prediction
resistance enabled, and eight with prediction resistance turned off. For each of the eight test
groups, four must have reseed enabled and four must have reseed turned off.
Each test group within the core sets of four test groups shall consist of 15 test cases each, such
that minimum lengths and maximum lengths for the above parameters are used at least once
across the four groups, and the rest are random lengths.
Correctness is determined by comparing the results from a known-good implementation using
the same input parameters.
CTR_DRBG
To test the TOE’s ability to generate random bits using CTR_DRBG, the
evaluator shall perform the Algorithm Functional Test using the following input parameters:
Algorithm Functional Test
The evaluator shall generate 16 test groups for each claimed function and supported derivation
function state (on or off). Eight with prediction resistance enabled, and eight with prediction
resistance turned off. For each of the eight test groups, four must have reseed enabled and four
must have reseed turned off.
Each test group within the core sets of four test groups shall consist of 15 test cases each, such
that minimum supported lengths and maximum supported lengths for the above parameters are
used at least once across the four groups, and the rest are random lengths.
Correctness is determined by comparing the results from a known-good implementation using
the same input parameters.
FCS_RBG.2 Random Bit Generation (External Seeding)
The inclusion of this selection-based component depends upon selection in
FCS_RBG.1.2, FCS_RBG.1.2.
The TSF shall be able to accept a minimum input of [assignment:
minimum input length greater than zero]
from a TSF interface for the purpose of seeding.
Application
Note:
This requirement is claimed when a DRBG is seeded with entropy from one or more noise source that is outside
the TOE boundary. In the case of a mobile device this would likely only occur when the entropy source is a
Dedicated Security Component that is integrated with the TOE. Typically the entropy produced by an environmental
noise source is conditioned such that the input length has full entropy and is therefore usable as the seed.
However, if this is not the case, it should be noted what the minimum entropy rate of the noise source is so
that the TSF can collect a sufficiently large sample of noise data to be conditioned into a seed value.
The evaluator shall examine the entropy documentation required by FCS_RBG.1.2 to verify that it identifies, for each
DRBG function implemented by the TOE, the TSF external interface used to seed the TOE's DRBG. The evaluator shall
verify that this includes the amount of sampled data and the min-entropy rate of the sampled data such that it can be
determined that sufficient entropy can be made available for the highest strength keys that the TSF can generate
(e.g., 256 bits). If the seed data cannot be assumed to have full entropy (e.g., the min-entropy of the sampled bits
is less than 1), the evaluator shall ensure that the entropy documentation describes the method by which the TOE
estimates the amount of entropy that has been accumulated to ensure that sufficient data is collected and any
conditioning that the TSF applies to the output data to create a seed of sufficient size with full entropy.
The TSF shall be able to seed the RBG using a [selection, choose one of: TSF software-based noise source, TSF hardware-based noise source [assignment:
name of noise source]]
with a minimum of [assignment:
number of bits] bits of min-entropy.
Application
Note:
The ST author claims this requirement when a TOE uses a single internal source of entropy
to initialize or reseed a DRBG. Seeding a DRBG is the same as initializing a DRBG.
Hardware-based noise sources are entropy sources whose primary function is noise generation, such as ring
oscillators, diodes, and thermal noise. While a TOE may use software to collect the noise from these hardware
sources, these are not software-based.
Software-based noise sources generate noise as a byproduct of their normal operation. Examples of software-based
noise sources can be user or system-based events such as reading the least significant bits from an event timer,
etc.
The TOE collects enough input from the internal noise source such that the total measured entropy of the input is
sufficient to initialize or reseed a DRBG. The ST author ensures that the assignment is completed with the number
of bits of the input sufficient to initialize or reseed a DRBG.
The evaluator shall verify that the TSS documents the types of entropy sources selected
in FCS_RBG.3.1 and indicates the amount of entropy provided by these sources.
Guidance
The evaluator shall verify that the guidance describes any settings, operational
requirements, or user input necessary for the proper function of the entropy sources.
Tests
The evaluator shall exercise the interface to determine whether the interface can
handle at least the number of bits claimed in the assignment.
FCS_RBG.4 Random Bit Generation (Internal Seeding - Multiple Sources)
The inclusion of this selection-based component depends upon selection in
FCS_RBG.1.2, FCS_RBG.1.2.
The TSF shall be able to seed the DRBG using [selection: [assignment:
number] TSF software-based entropy sources, [assignment:
number] TSF hardware-based entropy sources].
Application
Note:
The ST author claims this requirement when a TOE uses two or more internal sources of entropy to initialize or
reseed a DRBG. Seeding a DRBG is the same as initializing a DRBG. FCS_RBG.5 defines the mechanism by which these
sources are combined to ensure sufficient minimum entropy.
The evaluator shall verify that the TSS documents number and the types of entropy sources selected in FCS_RBG.4.1.
Guidance
The evaluator shall verify that the Guidance describes any settings, operational requirements, or user input necessary
for the proper function of the noise sources.
Tests
There are no test activities for this component.
FCS_RBG.5 Random Bit Generation (Combining Entropy Sources)
The inclusion of this selection-based component depends upon selection in
FCS_RBG.1.2, FCS_RBG.1.2.
The TSF shall [assignment:
combining operation] [selection: output from TSF noise source(s), input from TSF interface(s) for seeding]
to create the entropy input into the derivation function as defined in [assignment:
list of standards], resulting
in a minimum of [assignment:
number of bits] bits of min-entropy.
Application
Note:
Examples of typical combining operations include, but are not limited to, XORing or hashing.
Using the entropy sources specified in FCS_RBG.4, the evaluator shall examine the entropy documentation required by FCS_RBG.1.2 to verify that it describes the method by which the various entropy sources are combined into a single seed. This should include an estimation of the rate at which each noise source outputs data and whether this is dependent on any system-specific factors so that each source's relative contribution to the overall entropy is understood. The evaluator shall verify that the resulting combination of sampled data and the min-entropy rate of the sampled data is described in sufficient detail to determine that sufficient entropy can be made available for the highest strength keys that the TSF can generate (e.g., 256 bits). If the seed data cannot be assumed to have full entropy (e.g., the min-entropy of the sampled bits is less than 1), the evaluator shall ensure that the entropy documentation describes the method by which the TOE estimates the amount of entropy that has been accumulated to ensure that sufficient data is collected and any conditioning that the TSF applies to the output data to create a seed of sufficient size with full entropy.
The TSF shall provide a [selection: hardware, software, [assignment:
other interface type]]
interface to make the DRBG output, as specified in FCS_RBG.1 Random Bit Generation (RBG),
available as a service to entities outside of the TOE.
Application
Note:
This SFR must be included in the ST if the TOE provides an entropy source accessible to tenant software.
This requirement ensures that the TOE makes available entropy to any tenant
that requires it.
The evaluator shall examine the TSS to verify that it describes how the DRBG output is made
available to entities outside the TOE.
Guidance
The evaluator shall examine the guidance to verify that it describes how to configure and use the
claimed interface(s) so that DRBG output is available to entities outside of the TOE.
Tests
The evaluator shall perform the following test:
The evaluator shall invoke the entropy sources from tenant software.
The evaluator shall verify that the tenant acquires values from the interface.
FCS_STG_EXT.2 Encrypted Cryptographic Key Storage
The inclusion of this selection-based component depends upon selection in
FCS_STG_EXT.1.1.
The TSF shall encrypt [AKs, SKs, KEKs, and
[selection: long-term trusted channel key material, all software-based key storage, no other keys]] using Key Wrapping as defined in FCS_COP.1/KeyWrap.
Application
Note:
This SFR is included in the ST if "software-based" is selected in FCS_STG_EXT.1.
The evaluator shall review the TSS to determine that the TSS describes the
protection of symmetric keys, KEKs, long-term trusted channel key material, and
software-based key storage as claimed in FCS_STG_EXT.2.1.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
There are no test activities for this component.
FCS_STG_EXT.3 Key Integrity Protection
The inclusion of this selection-based component depends upon selection in
FCS_STG_EXT.1.1.
The TSF shall protect the integrity of any encrypted [AKs, SKs, KEKs, and
[selection: long-term trusted channel key material, all software-based key storage, no other keys]] by using
[selection:
A digital signature of the stored key in accordance with FCS_COP.1/SigGen
using an asymmetric key that is protected in accordance with FCS_STG_EXT.2
An immediate application of the key for decrypting the protected data followed
by a successful verification of the decrypted data with previously known information
].
Application
Note:
This SFR is included in the ST if "software-based" is selected in FCS_STG_EXT.1.
The TSF shall verify the integrity of the
[selection: digital signature, MAC] of the stored key prior to use of the key.
Application
Note:
This requirement is not applicable to derived keys that are not stored. It is not expected that a
single key will be protected from corruption by multiple of these methods; however, a product may
use one integrity-protection method for one type of key and a different method for other types of
keys.
The evaluator shall examine the TSS and ensure that it contains a description of
how the TOE protects the integrity of its keys.
Guidance
There are no additional Guidance evaluation activities for this component.
KMD
The documentation of the product’s encryption key management should be detailed enough that,
after reading, the evaluator will thoroughly understand the product’s key management and how it
meets the requirements to ensure the keys are adequately protected. This documentation should
include an essay and diagrams. This documentation may be marked as developer proprietary.
The TSF shall support importing keys/key material using [selection: physically protected channels as specified in
FTP_ITP_EXT.1, encrypted data buffers as specified in FTP_ITE_EXT.1, key distribution mechanisms as specified in
FCS_CKM.2].
The TSF shall verify the integrity of imported keys/key material using [selection: cryptographic hash as specified
in FCS_COP.1/Hash, keyed hash as specified in FCS_COP.1/KeyedHash, integrity-providing encryption algorithm as specified
in FCS_COP.1/KeyWrap, digital signature as specified in FCS_COP.1/SigVer, integrity verification provided through FCS_CKM.2
key distribution mechanisms, integrity verification supported by FTP_ITC_EXT.1].
Application
Note:
This SFR is included in the ST when "importing keys/secrets into the TOE" is selected in FCS_STG_EXT.1.
The way the TSF checks the integrity of the keys depends on the method of importation. For example, the encrypted data channel
may provide data integrity as part of its service.
The evaluator shall confirm the TSS contains descriptions of the supported methods the TSF uses to import keys and key
material into the TOE. For each import method selected, the TSS shall describe integrity verification schemes employed.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
For each supported import method selected in FDP_ITC_EXT.1.1 and for each supported integrity verification method selected
in FDP_ITC_EXT.1.2, used by the selected import method, provide one key/credential with valid integrity credentials, one
with invalid integrity credentials (e.g. hash). The operations with invalid integrity credentials must result in error. The
operations with valid integrity credentials must accept the keys/credentials.
B.3 Identification and Authentication (FIA)
FIA_AFL_EXT.1 Authentication Failure Handling
The inclusion of this selection-based component depends upon selection in
FMT_SMR.1.1.
The TSF shall consider password and
[selection: [assignment:
other authentication mechanisms], no other authentication mechanisms]
as critical authentication mechanisms.
Application
Note:
This SFR is included in the ST if the "Administrator" role is selected
in FMT_SMR.1, or if the "Server-Class Platform, Basic" or "Server-Class Platform, Enhanced"
use cases are selected.
If this SFR is included in the ST, then FCS_CKM.6 must also be claimed.
This SFR specifies the actions to be taken in the event of multiple authentication failures.
This requirement applies to both critical and non-critical authentication mechanisms. The difference
between the two is that excessive authentication failures of critical authentication mechanisms
result in the actions defined in FIA_AFL_EXT.1.5.
If the TOE implements multiple Authentication Factor interfaces (for example, a DAR decryption
interface, a lockscreen interface, an auxiliary boot mode interface), this element applies
to all available interfaces. For example, a password is a critical authentication mechanism
regardless of if it is being entered at the DAR decryption interface or at a lockscreen
interface.
The TSF shall detect when a configurable positive non-zero integer within
[assignment:
range of acceptable values for each authentication mechanism]
of [selection, choose one of: unique, non-unique] unsuccessful authentication attempts occur related to last successful authentication for
each authentication mechanism.
Application
Note:
The positive integer is configured according to Table 4 in FMT_SMF.1.1.
An unique authentication attempt is defined as any attempt to verify an authentication attempt
in which the input is different from a previous attempt. "Unique" must be selected if
the authentication system increments the counter only for unique unsuccessful authentication
attempts. For example, if the same incorrect password is attempted twice the authentication
system increments the counter once. "Non-unique" must be selected if the authentication system
increments the counter for each unsuccessful authentication attempt, regardless of whether the
input is unique. For example, if the same incorrect password is attempted twice the
authentication system increments the counter twice.
If the TOE supports multiple authentication mechanisms per FIA_UAU.5.1, this element applies
to all authentication mechanisms. It is acceptable for each authentication mechanism to
utilize an independent counter or for multiple authentication mechanisms to utilize a shared
counter. The interaction between the authentication factors with regard to the authentication
counter must be in accordance with FIA_UAU.5.2.
If the TOE implements multiple Authentication Factor interfaces (for example, a DAR decryption
interface, a lockscreen interface, an auxiliary boot mode interface), this element applies
to all available interfaces. However, it is acceptable for each Authentication Factor interface
to be configurable with a different number of unsuccessful authentication attempts.
The TSF shall maintain the number of unsuccessful authentication attempts that have occurred
upon power off if the minimum boot time of the system is shorter than the lockout time
specified in FIA_AFL_EXT.1.5.
Application
Note:
The purpose of this requirement is to prevent hammering attacks focused on a device's pre-OS-firmware
from bypassing the actions in FIA_AFL_EXT.1.5 by power cycling the system in order to zero the
authentication failure count. The intention is to protect the pre-OS firmware without making
assumptions as to boot duration per device. This purpose is achieved by default if the minimum reboot
time of the system is greater than the timeout penalty specified in FIA_AFL_EXT.1.5.
If the actions specified in FIA_AFL_EXT.1.5 are device wipe or a non-time-limited lockout, or if the
minimum reboot time is shorter than the specified lockout time, then the authentication failure count
must be maintained across power cycles. The variation of boot duration of individual devices and the
configurability of FIA_AFL_EXT.1.5 may create scenarios where some devices are compliant by default
(specifically slow-booting servers and workstations) while other devices (specifically fast-booting
desktops and notebooks) may need to implement this requirement.
The TOE may implement an Authentication Factor interface that precedes another Authentication Factor
interface in the boot sequence (for example, a volume DAR decryption interface which precedes the
lockscreen interface) before the user can access the GPCP. In this situation, because the user must
successfully authenticate to the first interface to access the second, the number of unsuccessful
authentication attempts need not be maintained for the second interface.
When the defined number of unsuccessful authentication attempts has exceeded the maximum
allowed for a given authentication mechanism, all future authentication attempts shall be
limited to other available authentication mechanisms, unless the given mechanism is designated
as a critical authentication mechanism.
Application
Note:
See FIA_AFL_EXT.1.5 for exceeding the maximum failure threshold for critical authentication mechanisms.
In accordance with FIA_AFL_EXT.1.3, this requirement also applies after the TOE is powered off
and powered back on.
When the defined number of unsuccessful authentication attempts for the last available
authentication mechanism or a critical authentication mechanism has been surpassed, the
TSF shall
[selection:
perform a wipe of all protected data
exclude the current Administrator from further authentication attempts
exclude the current Administrator from further authentication
attempts for [assignment:
a period of time greater than zero seconds]
exclude the current Administrator from further authentication
attempts for [assignment:
a period of time greater than the minimum boot time of the system]
].
Application
Note:
The "current Administrator" is the entity attempting to authenticate to the TOE that has run afoul of
the limit on authentication attempts. For platforms that support multiple Administrator identities, only the
identity that has run afoul is punished. For platforms without such support, these actions
are effectively applied to the authentication mechanism rather than a specific user.
Wipe is performed in accordance with FCS_CKM.6. Protected data is all non-TSF data,
including all user or enterprise data. Some or all of this data may be considered sensitive
data as well.
If the TOE implements multiple Authentication Factor interfaces (for example, a DAR decryption
interface, a lockscreen interface, an auxiliary boot mode interface), this element applies
to all available interfaces.
The TSF shall increment the number of unsuccessful authentication attempts prior to notifying the
user that the authentication was unsuccessful.
Application
Note:
This requirement is to ensure that if power is cut to the device directly after an
authentication attempt, the counter will be incremented to reflect that attempt.
The evaluator shall ensure that the TSS describes that a value corresponding to the number
of unsuccessful authentication attempts since the last successful authentication is kept
for each Authentication Factor interface. The evaluator shall ensure that this description
also includes if and how this value is maintained when the TOE loses power, either through
a graceful powered off or an ungraceful loss of power. The evaluator shall ensure that if
the value is not maintained, the interface is after another interface in the boot sequence
for which the value is maintained.
If the TOE supports multiple authentication mechanisms, the evaluator shall ensure that
this description also includes how the unsuccessful authentication attempts for each
mechanism selected in FIA_UAU.5.1 is handled. The evaluator shall verify that the TSS
describes if each authentication mechanism utilizes its own counter or if multiple
authentication mechanisms utilize a shared counter. If multiple authentication mechanisms
utilize a shared counter, the evaluator shall verify that the TSS describes this
interaction.
The evaluator shall confirm that the TSS describes how the process used to determine if
the authentication attempt was successful. The evaluator shall ensure that the counter
would be updated even if power to the device is cut immediately following notifying the
TOE user if the authentication attempt was successful or not.
Guidance
The evaluator shall verify that the AGD describes how the Administrator configures
the maximum number of unique unsuccessful authentication attempts, and the lockout time period,
if applicable.
The evaluator shall verify that the AGD describes how an Administrator may recover from
authentication failure when another Administrator is locked out.
Tests
The evaluator shall configure the device with all authentication mechanisms
selected in FIA_UAU.5.1, and configure a maximum number of unsuccessful authentication
attempts for each mechanism.
Test FIA_AFL_EXT.1:1:
The evaluator shall for each authentication mechanism make
unsuccessful authentication attempts until the maximum is exceeded and verify that
the number of failures corresponds to the configured maximum and that no further
authentication attempts can be made using that mechanism.
Test FIA_AFL_EXT.1:2:
[conditional] If the mechanism is critical or if all authentication mechanisms are
exhausted, then if "perform a wipe of all protected data" is selected in
FIA_AFL_EXT.1.5 the evaluator shall verify that the wipe is implemented.
Test FIA_AFL_EXT.1:3:
[conditional] If the mechanism is critical or if all authentication mechanisms are
exhausted, then if "exclude the current User/Administrator from further authentication
attempts" is selected in FIA_AFL_EXT.1.5 the evaluator shall verify that
the User/Administrator can make no further authentication attempts.
Test FIA_AFL_EXT.1:4:
[conditional] If the mechanism is critical or if all authentication mechanisms are
exhausted, then if "exclude the current User/Administrator from further authentication
attempts for a period of [assignment: greater than zero seconds] time" is selected in
FIA_AFL_EXT.1.5 the evaluator shall verify that the User/Administrator can make no further
authentication attempts until the specified time period has expired.
The TSF shall provide [password and[selection: certificate-based authentication, public key-based authentication, biometric authentication, no other mechanism]] to support user authentication.
Application
Note:
This SFR is included in the ST if the "Administrator" role is selected in FMT_SMR.1.
A "user" in the context of this SFR is an Administrator.
The TSF must support a Password Authentication Factor and may optionally implement a biometric authentication factor.
The Password Authentication Factor is configured according to FIA_PMG_EXT.1.
If "X.509 certificate-based authentication" is selected, then the ST must include FIA_X509_EXT.1 and FIA_X509_EXT.2 from.
If "public key-based authentication" is selected, then the ST must claim the.
The TSF shall authenticate any user's claimed identity according to the [assignment:
rules describing how the multiple authentication
mechanisms provide authentication].
Application
Note:
Rules regarding how the authentication factors interact in terms of unsuccessful authentication are covered in FIA_AFL_EXT.1.
The evaluator shall ensure that the TSS describes each mechanism provided to support user authentication and the rules
describing how the authentication mechanism(s) provide authentication.
Specifically, for all authentication mechanisms specified in FIA_UAU.5.1, the evaluator shall ensure that the TSS describes
the rules as to how each authentication mechanism is used. Example rules are how the authentication mechanism authenticates
the user (i.e. how does the TSF verify that the correct password or biometric sample was entered), the result of a successful
authentication (i.e. is the user input used to derive or unlock a key) and which authentication mechanism can be used at which
authentication factor interfaces (i.e. if there are times, for example, after a reboot, that only specific authentication
mechanisms can be used). If multiple Biometric Authentication Factors (BAF) are supported per FIA_UAU.5.1, the interaction
between the BAFs must be described. For example, whether the multiple BAFs can be enabled at the same time.
Guidance
The evaluator shall verify that configuration information for each authentication mechanism is addressed in the AGD guidance.
Tests
Test FIA_UAU.5:1:
For each authentication mechanism selected in FIA_UAU.5.1, the evaluator shall enable that mechanism and verify that it can be used to authenticate the user at the specified authentication factor interfaces.
Test FIA_UAU.5:2:
For each authentication mechanism rule, the evaluator shall ensure that the authentication mechanism behaves accordingly.
FIA_UAU.7 Protected Authentication Feedback
The inclusion of this selection-based component depends upon selection in
FMT_SMR.1.1.
The TSF shall provide only [obscured feedback] to the user
while the authentication is in progress.
Application
Note:
This SFR is included in the ST if the "Administrator" role is selected
in FMT_SMR.1, or if the "Server-Class Platform, Basic" or "Server-Class Platform, Enhanced"
use cases are selected.
This requirement applies to all authentication mechanisms specified in FIA_UAU.5.1 that provide
feedback to a user or Administrator during authentication.
For authentication mechanisms that require the user or Administrator to enter a
password or PIN, the TSF may briefly (1 second or less) display each character or provide an option
to allow the user to unmask the user input; however, the user input must be obscured by default.
If a BAF is selected in FIA_UAU.5.1, the TSF must not display sensitive information regarding
the biometric that could aid an adversary in identifying or spoofing the respective
biometric characteristics of a given human user. While it is true that biometric samples, by
themselves, are not secret, the analysis performed by the respective biometric algorithms, as
well as output data from these biometric algorithms, is considered sensitive and must be kept
secret. Where applicable, the TSF must not reveal or make public the reasons for
authentication failure.
In the cases of SSH- or X.509-based authentication, the TSF must likewise not display sensitive
information regarding the authentication factors that could aid an adversary in spoofing or
circumventing the authentication protocols.
The evaluator shall ensure that the TSS describes the means of obscuring the authentication
information for all authentication methods specified in FIA_UAU.5.1.
Guidance
The evaluator shall verify that any configuration of this requirement is addressed in the
AGD guidance and that user authentication input is obscured by default.
Tests
The evaluator shall perform the following tests:
Test FIA_UAU.7:1:
The evaluator shall enter passwords on the device, including at least the Password
Authentication Factor at lockscreen, and verify that the password is not displayed
on the device.
Test FIA_UAU.7:2:
[conditional] For each Biometric Authentication Factor (BAF) selected
in FIA_UAU.5.1, the evaluator shall
authenticate by producing a biometric sample at lockscreen. As the biometric
algorithms are performed, the evaluator shall verify that sensitive images, audio,
or other information identifying the user are kept secret and are not revealed to
the user. Additionally, the evaluator shall produce a biometric sample that fails
to authenticate and verify that the reason(s) for authentication failure (user
mismatch, low sample quality, etc.) are not revealed to the user. It is acceptable
for the BAF to state that it was unable to physically read the biometric sample,
for example, if the sensor is unclean or the biometric sample was removed too
quickly. However, specifics regarding why the presented biometric sample failed
authentication shall not be revealed to the user.
[conditional] For each SSH- or X.509-based authentication mechanism, the evaluator shall
examine whether the TSF displays sensitive information during the authentication process
for both successful and failed authentication attempts.
FIA_UAU_EXT.1 Authentication for Cryptographic Operation
The TSF shall require the user to present the Password Authentication Factor
prior to decryption of protected data and encrypted DEKs, KEKs and [selection: long-term trusted channel key material, all software-based key storage, no other keys] at startup.
Application
Note:
The intent of this requirement is to prevent decryption of
protected data before the user has authorized to the device using the Password
Authentication Factor. The Password Authentication Factor is also required in order
derive the key used to decrypt sensitive data, which includes software-based secure
key storage.
The evaluator shall verify that the TSS section of the ST describes the process
for decrypting protected data and keys. The evaluator shall ensure that this process
requires the user to enter a Password Authentication Factor and, in accordance with
FCS_CKM_EXT.3, derives a KEK, which is used to protect the software-based secure key
storage and (optionally) DEKs for sensitive data, in accordance with
FCS_STG_EXT.2.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The following tests may be performed in conjunction with FDP_DAR_EXT.1 and
FDP_DAR_EXT.2.
Evaluation Activity Note: The following test require the developer to
provide access to a test platform that provides the evaluator with tools that are
typically not found on consumer Mobile Device products.
Test FIA_UAU_EXT.1:1:
The evaluator shall enable encryption of protected data and require user
authentication according to the AGD guidance. The evaluator shall write, or the
developer shall provide access to, an application that includes a unique string
treated as protected data.
The evaluator shall reboot the
device, use a tool provided by developer to search for the unique string within
the application data, and verify that the unique string cannot be found. The
evaluator shall enter the Password Authentication Factor to access full device
functionality, use a tool provided by the developer to access the unique string
within the application data, and verify that the unique string can be found.
Test FIA_UAU_EXT.1:2:
[conditional] The evaluator shall require user authentication according to
the AGD guidance. The evaluator shall store a key in the software-based secure
key storage.
The evaluator shall lock the device, use a tool
provided by developer to access the key within the stored data, and verify that
the key cannot be retrieved or accessed. The evaluator shall enter the Password
Authentication Factor to access full device functionality, use a tool provided
by developer to access the key, and verify that the key can be retrieved or
accessed.
Test FIA_UAU_EXT.1:3:
[conditional] The evaluator shall enable encryption of sensitive data and
require user authentication according to the AGD guidance. The evaluator shall
write, or the developer shall provide access to, an application that includes a
unique string treated as sensitive data.
The evaluator shall
lock the device, use a tool provided by developer to attempt to access the
unique string within the application data, and verify that the unique string
cannot be found. The evaluator shall enter the Password Authentication Factor to
access full device functionality, use a tool provided by developer to access the
unique string within the application data, and verify that the unique string
can be retrieved.
FIA_UIA_EXT.1 Administrator Authentication
This component must be included in the ST if any of the following SFRs are included:
The TSF shall require Administrators to be successfully authenticated
using one of the methods in FIA_UAU.5 before allowing any TSF-mediated management
function to be performed by that Administrator.
Application
Note:
This SFR is included in the ST if the "Administrator" role is selected
in FMT_SMR.1, or if the "Server-Class Platform, Basic" or "Server-Class Platform, Enhanced"
use cases are selected.
Ordinary unprivileged users of the platform need not authenticate to the platform, though they
may well have to authenticate themselves to tenant software such as an Operating System.
The TSF-mediated management functions are listed in the management functions table
(Table 4) in FMT_SMF.1.
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 platform.
This description shall contain information pertaining to the credentials allowed/used, any
protocol transactions that take place, and what constitutes a “successful logon.”
Guidance
The evaluator shall examine the AGD 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 AGD
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
AGD provides sufficient instruction on limiting the allowed services.
Tests
There are no test activities for this component.
B.4 Protection of the TSF (FPT)
FPT_FLS.1 Failure with Preservation of Secure State
This component must be included in the ST if the TOE implements any of the following features:
The TSF shall preserve a secure state when the following types of failures occur: [DRBG self-test failure].
Application
Note:
The intent of this requirement is to ensure that cryptographic services requiring random bit
generation cannot be performed if a failure of a self-test defined in FPT_TST.1 occurs.
The evaluator shall verify that the TSF describes how the TOE enters an error state in the event of a DRBG
self-test failure.
Guidance
The evaluator shall verify that the guidance documentation describes the error state that results from a
DRBG self-test failure and the actions that a user or administrator should take in response to attempt to
resolve the error state.
The TOE implements a recovery mechanism for firmware corruption not necessarily related to
integrity or update failure.
If the ST Author selects "the secure local update mechanism described in FPT_TUD_EXT.4," then
FPT_TUD_EXT.4 must be claimed in the ST.
As indicated above, in addition to integrity or update failure, the TOE may use a recovery
mechanism to deal with non-security-related failures, such as a power outage during update or a
power surge during normal operation.
The recovery process may be initiated automatically on failure, as the result of physically present user
action, or as the result of pre-configured policy. The action taken may depend on the nature of the
failure as specified in FPT_ROT_EXT.2.2 and FPT_TUD_EXT.2.5.
The evaluator shall examine the TSS section to confirm that it describes how the platform
firmware recovery mechanism works and the conditions under which it is invoked.
Guidance
The evaluator shall examine the AGD to ensure that is describes how to configure the
conditions under which the recovery mechanism is initiated (if configurable).
Tests
The evaluator shall perform the following tests:
Test FPT_RVR_EXT.1:1:
To test this requirement, the evaluator shall trigger the recovery process
either by forcing an update error or a boot integrity failure and observing that
the recovery process has been initiated.
Test FPT_RVR_EXT.1:2:
The evaluator shall engage with the recovery process as necessary, and after recovery
will determine the version of the current firmware image. The test is passed
if the resultant image is as expected in accordance with policy and the selections
in FPT_RVR_EXT.1.1. If the recovery process uses the secure
local update process as specified in FPT_TUD_EXT.4, then this test is satisfied by
testing of that requirement.
The TSF shall authenticate the source of all platform firmware updates using a
digital signature algorithm specified in FCS_COP.1/SigVer and using a key store
that contains
[selection: the public key, hash value of the public key].
Application
Note:
This SFR must be included in the ST if "an authenticated platform firmware update mechanism
as described in FPT_TUD_EXT.2" is selected in FPT_TUD_EXT.1.1.
The ST must include FCS_COP.1/Hash if "hash value of the public key" is selected.
The TSF shall allow installation of updates only if the digital signature has been
successfully verified as specified in FCS_COP.1/SigVer and
[selection: the version number of the platform firmware update is more recent than
the version number of the current installed platform firmware, no other conditions].
Application
Note:
The ST Author should select "the version number..." if the TSF supports rollback prevention. That is, the TSF
does not allow "update" to an older version of the platform firmware. In general, rollback should be permitted
only through a secure local update mechanism at the express direction of an physically present Administrator or User.
The TSF shall include a platform firmware version identifier that is accessible by the update mechanism and
includes information that enables the update mechanism to determine the relative order of updates.
The TSF shall provide an observable indication of the success or failure of the update operation.
Application
Note:
For success, this indication should include the version number of the newly installed firmware.
Notification of failure could include generation of an audit event by a management subsystem, a
beep code, an updated version number on a splash screen, or simple failure to continue functioning.
The TOE shall take the following actions if a platform firmware integrity, authenticity,
or rollback-prevention check fails, or a platform firmware update fails for any other reason:
in accordance with administrator-configurable policy
by express determination of a User
].
Application
Note:
If "generating an audit event" is selected, then FAU_GEN.1 and the other audit requirements must be claimed.
If "Initiate recovery as specified in FPT_RVR_EXT.1" is selected, then FPT_RVR_EXT.1 must be included in the ST.
The platform firmware authenticated update mechanism employs digital signatures to ensure the authenticity of the
firmware update image. The TSF includes a signature verification algorithm and a key
store containing the public key needed to verify the signature on the firmware update image.
A hash of the public key may be stored if a copy of the public key is provided with firmware
update images. In this case, the update mechanism hashes the public key provided with the update
image, and ensure that it matches a hash which appears in the key store before using the provided public
key to verify the signature of the update image. If the hash of the public key is selected, the ST Author may
iterate the FCS_COP.1/Hash requirement to specify the hashing functions used.
An indication of success or failure can be generation of an audit event by a management subsystem, a beep code,
an updated version number on a splash screen, or simple failure to continue functioning.
If the update mechanism generates audit events, the ST Author must make the appropriate selections
from the audit events table (Table t-audit-sel-based).
In the selection "by express determination of a User," the "User" could be more properly expressed as
the "operator." It can be either a User or an Administrator, but the distinction is not important in the
context of this requirement.
The evaluator shall ensure that the TSS includes a comprehensive description of how the
authentication of platform firmware updates is implemented by the TSF. The TSS should cover the
initialization process and the activities that are performed to ensure that the
digital signature of the update image is verified before modification of the firmware.
The evaluator shall examine the TSF to ensure that it describes the platform firmware version identifier
and explains its meaning and encoding.
The evaluator shall also ensure that the TSS describes the actions taken by the TSF is
an update image fails authentication.
Guidance
The evaluator shall examine the AGD to ensure that it describes the process for
updating the platform firmware.
The evaluator shall examine the AGD to ensure that it documents the observable indications
of update success or failure, and that it describes how to access the platform firmware version indicators.
Tests
The evaluator shall perform the following tests:
Test FPT_TUD_EXT.2:1:
The evaluator determines the current version of the platform firmware, and obtains or
produces a valid, authentic, and permissible update image of platform firmware. The evaluator
initiates an update using this image through the process described in the operational guidance.
After the process is complete, the evaluator checks the current firmware version to ensure
that the new firmware version matches that of the update.
Test FPT_TUD_EXT.2:2:
The evaluator performs the same test, this time using a valid update image that is signed
with an incorrect key. The update must fail.
Test FPT_TUD_EXT.2:3:
The evaluator performs the same test, this time using an update image that is corrupted
but is signed with the correct key. The update must fail.
Test FPT_TUD_EXT.2:4:
The evaluator performs the same test, this time using a valid update image that is not signed.
The update must fail.
Test FPT_TUD_EXT.2:5:
[conditional] If the TSF implements rollback protections, the evaluator performs the same test, this time using
a valid, signed update image that has an earlier version number than the currently installed
firmware. The update must fail.
The TSF shall allow execution or use of platform firmware updates only if new platform firmware
is integrity- and authenticity-checked using the mechanism described in FPT_ROT_EXT.2 prior to its
execution or use, and
[selection: the version number of the platform firmware update is more recent than
the version number of the previously installed platform firmware, no other conditions].
Application
Note:
This requirement must be included in the ST if "implement a delayed-authentication platform firmware
update mechanism as described in FPT_TUD_EXT.3" is selected in FPT_TUD_EXT.1.1.
This update mechanism does not require an integrity or authenticity check prior to installation, but the
newly installed platform firmware must have its integrity and authenticity verified prior to
being executed or used. This update mechanism takes advantage of the existing FPT_ROT_EXT.2
requirement to avoid having to verify the integrity and authenticity of an update package
at install time.
The ST Author should select "the version number of the platform firmware update is more recent than
the version number of the previously installed platform firmware" if the TSF supports rollback prevention.
The TSF shall include an observable platform firmware version identifier that is accessible by the
update mechanism and includes information that enables the update mechanism to determine the relative
order of updates.
The TSF shall provide an observable indication of the success or failure of the update operation.
Application
Note:
For success, this should at least include an indication of the version number of the newly installed firmware.
Notification of failure could include generation of an audit event by a management subsystem, a
beep code, an updated version number on a splash screen, or simple failure to continue functioning.
The TOE shall take the following actions if a platform firmware update integrity, authentication, or
rollback-prevention check fails, or a platform firmware update fails for any other reason:
[selection, choose one of:
Halt
Stop all execution and shut down
Initiate a recovery process as specified in FPT_RVR_EXT.1
]
[selection, choose one of:
automatically
in accordance with administrator-configurable policy
by express determination of a User
].
Application
Note:
If "generating an audit event" is selected, then FAU_GEN.1 and the other audit SFRs must be claimed.
If "Initiate recovery as specified in FPT_RVR_EXT.1" is selected, then FPT_RVR_EXT.1 must be included in the ST.
The platform firmware unauthenticated update mechanism installs platform firmware updates without
first checking their integrity or authenticity. Instead, this mechanism either invokes a
special authentication/integrity check on the firmware in situ after install or relies on the
firmware checks required by FPT_ROT_EXT.2 to ensure the integrity and authenticity of the update
image. In either case, the integrity and authenticity of the update must be verified before the
updated firmware is executed or used.
Likewise, if the TSF implements rollback prevention, this check must be made before the newly installed
firmware is executed.
In the selection "by express determination of a User," the "User" could be more properly expressed as
the "operator." It can be either a User or an Administrator, but the distinction is not important in the
context of this requirement.
The evaluator shall ensure that the TSS includes a comprehensive description of how the
authentication of platform firmware updates is implemented by the TSF. The TSS should cover the
initialization process and the activities that are performed to ensure that the
digital signature of the update image is verified before it is executed or used.
The evaluator shall examine the TSF to ensure that it describes the platform firmware version identifier
and explains its meaning and encoding.
The evaluator shall also ensure that the TSS describes the actions taken by the TSF if
an update image fails authentication, integrity, or rollback-prevention checks.
Guidance
The evaluator shall examine the AGD to ensure that it describes the process for
updating the platform firmware.
The evaluator shall examine the AGD to ensure that it documents the observable indications
of update success or failure, and that it describes how to access the platform firmware version indicators.
Tests
The evaluator shall perform the following tests:
Test FPT_TUD_EXT.3:1:
The evaluator determines the current version of the platform firmware, and obtains or
produces a valid, authentic, and permissible update image of platform firmware. The evaluator
initiates an update using this image through the process described in the operational guidance.
After the process is complete, the evaluator checks the current firmware version to ensure
that the new firmware version matches that of the update.
Test FPT_TUD_EXT.3:2:
The evaluator performs the same test, this time using a inauthentic update image. The update code
must fail to execute.
Test FPT_TUD_EXT.3:3:
The evaluator performs the same test, this time using an update image that is corrupted
but is otherwise authentic. The update code must fail to execute.
Test FPT_TUD_EXT.3:4:
[conditional] If the TSF implements rollback protections, the evaluator performs the same test, this time using
a valid, signed update image that is has an earlier version number than the currently installed
firmware. The update code must fail to execute.
FPT_TUD_EXT.4 Secure Local Platform Firmware Update Mechanism
A user shall assert physical presence to the TSF through:
[selection:
login to the TOE from a physically connected console or terminal
physical connection of a jumper or cable
connection to a debug port
[assignment:
description of other mechanism for asserting physical presence]
].
Application
Note:
The requirement included in the ST if "the secure local update mechanism described in FPT_TUD_EXT.4"
is selected in FPT_RVR_EXT.1.1 or
"implement a secure local platform firmware update mechanism described in FPT_TUD_EXT.4" is selected
in FPT_TUD_EXT.1.1.
This requirement pertains to platform firmware update mechanisms that do not use the
authentication-based update mechanism described in FPT_TUD_EXT.2 or the delayed-authentication
described in FPT_TUD_EXT.3. The secure local update
mechanism ensures the authenticity and integrity of the firmware update image by requiring a
user to be physically present at the TOE. An assertion of physical presence can take the form, for example, of
requiring entry of a password at a boot screen, unlocking of a physical lock (e.g., a motherboard
jumper), or inserting a USB cable before permitting platform firmware to be updated.
There is no requirement that the local update mechanism support rollback prevention.
The local update mechanism must be a designed mechanism. If update can be accomplished only
through the physical removal and replacement of a part, then that is not a secure local
update mechanism, and "make no provision for platform firmware update" should be selected in FPT_TUD_EXT.1.1.
The TSF shall provide an observable indication of the success or failure of the update operation.
Application
Note:
For success, this indication should include the version number of the newly installed firmware.
Notification of failure could be through a beep code, an indication on a splash screen, or simple failure to
continue functioning.
The evaluator shall check the TSS section to confirm that it clearly and thoroughly describes how the
secure local update functionality is implemented.
Guidance
The evaluator shall examine the AGD to ensure that it describes instructions for
using the local update mechanism, and how to validate that the update was successful.
Tests
The evaluator shall perform the following tests:
Test FPT_TUD_EXT.4:1:
The evaluator tests the secure local update by following the instructions provided in the operational
guidance to update the platform firmware image. The update must succeed.
Test FPT_TUD_EXT.4:2:
The evaluator next tries to update the platform firmware image without
first asserting physical presence. The update must fail or be not possible.
This SFR needs missing sections completed.
The TSF shall be capable of using IPsec to provide a communication channel between itself and another trustedauthorizedITentities supporting VPN communications that is logically distinct from other communication channels and provides assured
identification of its end points and protection of the channel data from disclosure and detection of modification of the channel data.
This SFR needs missing sections completed.
The TSF shall use 802.11-2020, 8021X, and EAP-TLS to provide a communication channel between itself and another trusteda
wireless access point that is logically distinct from other communication channels and provides assured
identification of its end points and protection of the channel data from modification or disclosure.
TLS as conforming to the as a [selection: client, server]
DTLS as conforming to the as a [selection: client, server]
IPsec as conforming to PP-Module for Virtual Private Network (VPN) Clients
]
and [selection:
SSH as conforming to the as a [selection: client, server]
no other protocols
]
to provide a communication channel between itself and authorized IT entities supporting the following capabilities:
[selection:
audit server
authentication sever
management server
[assignment:
other capabilities]
] using [selection: certificates as defined in Functional Package for X.509, version 1.0, SSH host keys as defined in Functional Package for Secure Shell (SSH), version 2.0]
that is logically distinct from other communication channels, provides assured
identification of its end points, protects channel data from disclosure, and detects modification
of the channel data.
Application
Note:
This SFR is included in the ST if a trusted channel is used to offload audit data
or if the platform is administered remotely. That is, if "a trusted channel as specified in FTP_ITC_EXT.1"
is selected in FAU_STG.1.1, if "physically protected channels as specified in FTP_ITP_EXT.1" is
selected in FDP_ITC_EXT.1.1, or if "remotely" is selected in Management Function 1 in FMT_SMF.1.1.
The ST author must include the security functional requirements for the trusted channel protocol selected in
FTP_ITC_EXT.1.1 as part of the TSF.
If TLS or DTLS is selected, the TSF must be validated against the appropriate requirements in the Functional Package for Transport Layer Security (TLS),
version 2.1.
If IPsec as conforming to the PP-Module for Virtual Private Network (VPN) Clients is selected, then FDP_IFC_EXT.1 must be included in the ST.
If SSH is selected, the TSF must be validated against the Functional Package for Secure Shell (SSH), version 2.0 and the corresponding selection is
expected to be made in FIA_UAU.5.1. The ST author must include the security functional requirements for the trusted channel protocol selected in
FTP_ITC_EXT.1 as part of the TSF.
Claims from the Functional Package for X.509, version 1.0 are only required to the extent that they are needed to support the functionality required by
the trusted protocols that are claimed.
If the TSF implements a protocol that requires the validation of a certificate presented by an external entity, FIA_X509_EXT.1 and FIA_X509_EXT.2 will be
claimed, as will FIA_TSM_EXT.1 for management of the trust store..
If the TSF implements a protocol that requires the presentation of any certificates to an external entity, FIA_XCU_EXT.2 will be claimed. FIA_X509_EXT.3
will also be claimed, along with any applicable dependencies, depending on how the certificates presented by the TOE are obtained.
The evaluator shall review the TSS to determine that it lists all trusted channels
the TOE uses for remote communications, including both the external IT entities and
remote users that use the channel as well as the protocol that is used for each.
Guidance
The evaluator shall confirm that the AGD contains
instructions for establishing connections to external IT entities and
remote users.
Tests
The evaluator will configure the TOE to communicate with each external IT entity
and type of remote user identified in the TSS. The evaluator will monitor network
traffic while the VS performs communication with each of these destinations. The evaluator will ensure
that for each session a trusted channel was established in conformance with the protocols identified
in the selection.
FTP_ITC_EXT.1/IPsec Trusted Channel Communication
This component must be included in the ST if the TOE implements any of the following features:
IPsec in accordance with the PP-Module for Virtual Private Network (VPN) Clients, version
3.0
IPsec in accordance with the PP-Module for Virtual Private Network (VPN) Clients, version
2.0
]
protocols to provide a communication channel between itself and another trusted IT product using certificates as defined in [Functional
Package for X.509, version 1.0]
that is logically distinct from other communication channels, provides assured
identification of its end points, protects channel data from disclosure, and detects modification
of the channel data.
Application
Note:
The intent of the mandatory portion of the above requirement is to use the cryptographic protocols identified in the requirement to establish and
maintain a trusted channel between the TOE and a VPN Gateway, or other trusted IT product.
Appendix B - Selection-based Requirements contains the requirements for implementing each of the other optional trusted channel protocols. 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.
Assured identification of endpoints is performed according to the authentication mechanisms used by the listed trusted channel protocols
Claims from the Functional Package for X.509, version 1.0 are only required to the extent that they are needed to support the functionality
required by the trusted protocols that are claimed.
The evaluator shall review the TSS to determine that it lists all trusted channels
the TOE uses for remote communications, including both the external IT entities and
remote users that use the channel as well as the protocol that is used for each.
Guidance
The evaluator shall confirm that the AGD contains
instructions for establishing connections to external IT entities and
remote users.
Tests
The evaluator will configure the TOE to communicate with each external IT entity
and type of remote user identified in the TSS. The evaluator will monitor network
traffic while the VS performs communication with each of these destinations. The evaluator will ensure
that for each session a trusted channel was established in conformance with the protocols identified
in the selection.
FTP_ITC_EXT.1/WLAN Trusted Channel Communication
This component must be included in the ST if the TOE implements any of the following features:
802.11-2012 in accordance with the [PP-Module for Wireless LAN Clients, version
2.0]
802.1X in accordance with the [PP-Module for Wireless LAN Clients, version
2.0]
EAP-TLS in accordance with the [PP-Module for Wireless LAN Clients, version
2.0]
Mutually authenticated TLS in accordance with [Functional Package for Transport Layer
Security (TLS), version 2.1]
] and [selection: Mutually authenticated DTLS in accordance with [Functional Package for Transport
Layer Security (TLS), version 2.1], HTTPS]
protocols to provide a communication channel between itself and another trusted IT product using certificates as defined in
[Functional Package for X.509, version 1.0] that is logically distinct from other communication channels, provides assured
identification of its end points, protects channel data from disclosure, and detects modification of the channel data.
Application
Note:
The intent of the mandatory portion of the above requirement is to use the cryptographic protocols identified in the requirement to establish
and maintain a trusted channel between the TOE and a VPN Gateway, or other trusted IT product.
Appendix B - Selection-based Requirements contains the requirements for implementing each of the other optional trusted channel protocols.
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.
Assured identification of endpoints is performed according to the authentication mechanisms used by the listed trusted channel protocols
Claims from the Functional Package for X.509, version 1.0 are only required to the extent that they are needed to support the functionality
required by the trusted protocols that are claimed.
The evaluator shall review the TSS to determine that it lists all trusted channels
the TOE uses for remote communications, including both the external IT entities and
remote users that use the channel as well as the protocol that is used for each.
Guidance
The evaluator shall confirm that the AGD contains
instructions for establishing connections to external IT entities and
remote users.
Tests
The evaluator will configure the TOE to communicate with each external IT entity
and type of remote user identified in the TSS. The evaluator will monitor network
traffic while the VS performs communication with each of these destinations. The evaluator will ensure
that for each session a trusted channel was established in conformance with the protocols identified
in the selection.
Appendix C - Extended Component Definitions
This appendix contains the definitions for all extended requirements specified in the PP.
C.1 Extended Components Table
All extended components specified in the PP are listed in this table:
Table 21: Extended Component Definitions
Functional Class
Functional Components
Cryptographic Support (FCS)
FCS_CKM_EXT Cryptographic Key Management FCS_RBG_EXT Random Bit Generation
FDP_ITC_EXT Key/Credential Import FDP_STG_EXT User Data Storage
C.2 Extended Component Definitions
C.2.1 Cryptographic Support (FCS)
This PP defines the following extended components as part of the
FCS class originally defined by CC Part 2:
C.2.1.1 FCS_CKM_EXT Cryptographic Key Management
Family Behavior
This family defines requirements for management of cryptographic keys that are not addressed by FCS_CKM in CC Part 2.
Component Leveling
FCS_CKM_EXT.7,
Cryptographic Key Agreement,
requires that cryptographic key agreement be performed in accordance with specified standards.
Management: FCS_CKM_EXT.7
There are no management functions foreseen.
Audit: FCS_CKM_EXT.7
The following actions should be auditable if FAU_GEN Security audit data generation is
included in the PP, PP-Module, functional package or ST:
minimal: Success and failure of the activity;
basic: The object attribute(s), and object value(s) excluding any sensitive information.
FCS_CKM_EXT.7 Cryptographic Key Agreement
Hierarchical to:
No other components.
Dependencies to:
[FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes],
[FCS_CKM.1 Cryptographic key generation, or
FCS_CKM.5 Cryptographic key derivation, or
FCS_CKM_EXT.8 Password-based key derivation] and
[FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation] and
FCS_CKM.6 Timing and event of cryptographic key destruction and
[FCS_COP.1 Cryptographic operation, or
no other dependencies].
FCS_CKM_EXT.7.1
The TSF shall derive shared cryptographic keys with input from multiple parties in accordance
with specified cryptographic key agreement algorithms
[selection:
Cryptographic algorithm]
and specified cryptographic parameters
[selection:
Cryptographic parameters]
that meet the following:
[selection:
List of standards]
The following table provides the allowable choices for
completion of the selection operations of FCS_CKM_EXT.7.
This family defines requirements for the TOE’s behavior when repeated failed attempts to gain
authorization to access TSF data occur.
Component Leveling
FIA_AFL_EXT.1,
Authentication Failure Handling,
requires the TSF to monitor authorization attempts, including counting and limiting the number of
attempts at failed or passed authorizations. This extended component permits considerably
more flexibility for dealing with multiple authentication mechanisms than FIA_AFL.
Management: FIA_AFL_EXT.1
The following actions could be considered for the management functions in FMT:
Ability to set parameters for allowable number of authentication failures.
Audit: FIA_AFL_EXT.1
If FAU_GEN.1 is included in the ST, then the following audit events should be considered:
Failed attempt at Administrator authentication.
FIA_AFL_EXT.1 Authentication Failure Handling
Hierarchical to:
No other components.
Dependencies to:
FCS_CKM.6 Timing and Event of Cryptographic Key Destruction
FIA_SMF.1 Specification of Management Functions
FIA_AFL_EXT.1.1
The TSF shall consider password and
[assignment:
type of authentication mechanisms]
as critical authentication mechanisms.
FIA_AFL_EXT.1.2
The TSF shall detect when a configurable positive non-zero integer within
[assignment:
range of acceptable values for each authentication mechanism]
of [selection, choose one of: unique, non-unique] unsuccessful authentication attempts occur related to last successful authentication for
each authentication mechanism.
FIA_AFL_EXT.1.3
The TSF shall maintain the number of unsuccessful authentication attempts that have occurred
upon power off if the minimum boot time of the system is shorter than the lockout time
specified in FIA_AFL_EXT.1.5.
FIA_AFL_EXT.1.4
When the defined number of unsuccessful authentication attempts has exceeded the maximum
allowed for a given authentication mechanism, all future authentication attempts shall be
limited to other available authentication mechanisms, unless the given mechanism is designated
as a critical authentication mechanism.
FIA_AFL_EXT.1.5
When the defined number of unsuccessful authentication attempts for the last available
authentication mechanism or a critical authentication mechanism has been surpassed, the
TSF shall
[selection:
perform a wipe of all protected data
exclude the current Administrator from further authentication attempts
exclude the current Administrator from further authentication
attempts for [assignment:
a period of time greater than zero seconds]
exclude the current Administrator from further authentication
attempts for [assignment:
a period of time greater than the minimum boot time of the system]
].
FIA_AFL_EXT.1.6
The TSF shall increment the number of unsuccessful authentication attempts prior to notifying the
user that the authentication was unsuccessful.
C.2.2.2 FIA_PMG_EXT Password Management
Family Behavior
This family defines requirements for the composition of
administrator passwords.
Component Leveling
FIA_PMG_EXT.1,
Password Management,
requires the TSF to support passwords with varying composition and length requirements.
Management: FIA_PMG_EXT.1
The following actions could be considered for the management functions in FMT:
Ability to configure password composition and length requirements
for authorization of Administrators.
Ability to manage authentication methods and change default authorization factors
Audit: FIA_PMG_EXT.1
There are no audit events foreseen.
FIA_PMG_EXT.1 Password Management
Hierarchical to:
No other components.
Dependencies to:
No dependencies.
FIA_PMG_EXT.1.1
The TSF shall support the following for the Password Authentication Factor:
Passwords shall be able to be composed of any combination of
[assignment:
characters sets],
numbers, and special characters: [assignment:
special characters].
Password length up to
[assignment:
an integer greater than or equal to 14] characters shall be
supported.
C.2.2.3 FIA_PSK_EXT Pre-Shared Key Composition
Family Behavior
This family defines requirements for the use of pre-shared keys.
Component Leveling
FIA_PSK_EXT.1,
Pre-Shared Key Composition,
requires the TSF to allow the use of pre-shared keys and the ability to accept and generate them.
Management: FIA_PSK_EXT.1
There are no management functions foreseen.
Audit: FIA_PSK_EXT.1
There are no audit events foreseen.
FIA_PSK_EXT.1 Pre-Shared Key Composition
Hierarchical to:
No other components.
Dependencies to:
No dependencies.
FIA_PSK_EXT.1.1
The TSF shall be able to use pre-shared keys that conform to RFC 8784 for IPsec
FIA_PSK_EXT.1.2
The TSF shall be able to [selection: accept externally generated pre-shared keys, generate 256 bit-based pre-shared keys via FCS_RBG.1].
C.2.2.4 FIA_TRT_EXT Authentication Throttling
Family Behavior
This family defines requirements for managing the number of authentication attempts.
Component Leveling
FIA_TRT_EXT.1,
Authentication Throttling,
requires the TSF to limit user authentication attempts.
Management: FIA_TRT_EXT.1
The following actions could be considered for the management functions in FMT:
Ability to configure authentication throttling policy.
The TSF shall limit automated user authentication attempts by [selection: preventing authentication via
an external port, enforcing a delay between incorrect authentication attempts] for all authentication mechanisms
selected in FIA_UAU.5.1. The minimum delay shall be such that no more than 10 attempts can be attempted per 500
milliseconds.
C.2.2.5 FIA_UAU_EXT User Authentication
Family Behavior
This family defines requirements for user authentication that are not addressed by FIA_UAU in CC Part 2.
Component Leveling
FIA_UAU_EXT.1,
Authentication for Cryptographic Operation,
requires the TSF enforce data-at-rest protection until successful authentication has occurred.
FIA_UAU_EXT.2,
Timing of Authentication,
requires the TSF to prevent a subject’s use of TOE until the user is authenticated.
Management: FIA_UAU_EXT.1
There are no management activities foreseen.
Audit: FIA_UAU_EXT.1
There are no auditable events foreseen.
FIA_UAU_EXT.1 Authentication for Cryptographic Operation
Hierarchical to:
No other components.
Dependencies to:
FDP_DAR_EXT.1 Protected Data Encryption
FDP_DAR_EXT.2 Sensitive Data Encryption
FIA_UAU_EXT.1.1
The TSF shall require the user to present the Password Authentication Factor
prior to decryption of protected data and encrypted DEKs, KEKs and [selection: long-term trusted channel key material, all software-based key storage, no other keys] at startup.
Management: FIA_UAU_EXT.2
The following actions could be considered for the management functions in FMT:
Enabling/disabling display TSF notifications while in the locked state.
Enabling/disabling bypass of local user authentication.
Audit: FIA_UAU_EXT.2
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
Action performed before authentication.
FIA_UAU_EXT.2 Timing of Authentication
Hierarchical to:
No other components.
Dependencies to:
No dependencies.
FIA_UAU_EXT.2.1
The TSF shall allow [selection:
[assignment:
list of actions], no actions] on behalf of the user to be performed before the user is authenticated.
FIA_UAU_EXT.2.2
The TSF shall require each user to be successfully authenticated before allowing
any other TSF-mediated actions on behalf of that user.
C.2.3 Packet Filtering (FPF)
This PP defines the following extended components as part of the
FPF class originally defined by CC Part 2:
C.2.3.1 FPF_RUL_EXT Packet Filtering
Family Behavior
This family defines requirements for using packet filtering.
Component Leveling
C.2.4 Protection of the TSF (FPT)
This PP defines the following extended components as part of the
FPT class originally defined by CC Part 2:
C.2.4.1 FPT_APW_EXT Protection of Administrator Password
Family Behavior
Components in this family ensure that the TSF will protect plaintext administrator credential
data such as passwords from unauthorized disclosure.
Component Leveling
FPT_APW_EXT.1,
Protection of Administrator Password,
requires that the TSF
prevent plaintext administrator credential data from being read by any user or subject.
Management: FPT_APW_EXT.1
No specific management functions are identified.
Audit: FPT_APW_EXT.1
There are no auditable events foreseen.
FPT_APW_EXT.1 Protection of Administrator Password
Hierarchical to:
No other components.
Dependencies to:
No dependencies.
FPT_APW_EXT.1.1
The TSF shall store administrative passwords in non-plaintext form.
FPT_APW_EXT.1.2
The TSF shall prevent the reading of plaintext administrative passwords.
C.2.4.2 FPT_BBD_EXT Baseband Processing
Family Behavior
This family defines requirements for separation of baseband and application processor execution.
Component Leveling
FPT_BBD_EXT.1,
Application Processor Mediation,
requires the TSF to enforce separation between baseband and application processor execution except through application processor mechanisms.
Management: FPT_BBD_EXT.1
There are no management activities foreseen.
Audit: FPT_BBD_EXT.1
There are no auditable events foreseen.
FPT_BBD_EXT.1 Application Processor Mediation
Hierarchical to:
No other components.
Dependencies to:
No dependencies.
FPT_BBD_EXT.1.1
The TSF shall prevent code executing on any baseband processor (BP) from
accessing application processor (AP) resources except when mediated by the AP.
C.2.4.3 FPT_JTA_EXT JTAG Disablement
Family Behavior
This family defines requirements for disabling JTAG.
Component Leveling
FPT_JTA_EXT.1,
JTAG Disablement,
requires the TSF to disable JTAG through a selected method.
Management: FPT_JTA_EXT.1
No specific management functions are identified.
Audit: FPT_JTA_EXT.1
There are no auditable events foreseen.
FPT_JTA_EXT.1 JTAG Disablement
Hierarchical to:
No other components.
Dependencies to:
No dependencies
FPT_JTA_EXT.1.1
The TSF shall [assignment:
access method] to JTAG.
C.2.4.4 FPT_KST_EXT Key Storage
Family Behavior
This family defines requirements for protecting plaintext keys.
Component Leveling
FPT_KST_EXT.1,
Key Storage,
requires the TSF to avoid storage of plaintext keys in readable memory.
FPT_KST_EXT.2,
No Key Transmission,
requires the TSF to prevent transmitting plaintext key material to the operational environment.
FPT_KST_EXT.3,
No Plaintext Key Export,
requires the TSF to prevent the export of plaintext keys.
Management: FPT_KST_EXT.1
There are no management activities foreseen.
Audit: FPT_KST_EXT.1
There are no auditable events foreseen.
FPT_KST_EXT.1 Key Storage
Hierarchical to:
No other components.
Dependencies to:
No dependencies.
FPT_KST_EXT.1.1
The TSF shall not store any plaintext key material in readable non-volatile
memory.
Management: FPT_KST_EXT.2
There are no management activities foreseen.
Audit: FPT_KST_EXT.2
There are no auditable events foreseen.
FPT_KST_EXT.2 No Key Transmission
Hierarchical to:
No other components.
Dependencies to:
No dependencies.
FPT_KST_EXT.2.1
The TSF shall not transmit any plaintext key material outside the security
boundary of the TOE.
Management: FPT_KST_EXT.3
There are no management activities foreseen.
Audit: FPT_KST_EXT.3
There are no auditable events foreseen.
FPT_KST_EXT.3 No Plaintext Key Export
Hierarchical to:
No other components.
Dependencies to:
No dependencies.
FPT_KST_EXT.3.1
The TSF shall ensure it is not possible for the TOE users to export plaintext
keys.
C.2.4.5 FPT_NOT_EXT Self-Test Notification
Family Behavior
This family defines requirements for generation of notifications in response to completed self-tests.
Component Leveling
FPT_NOT_EXT.1,
Self-Test Notification,
requires the TSF to become non-operational when certain failures occur.
Management: FPT_NOT_EXT.1
There are no management activities foreseen.
Audit: FPT_NOT_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
The TSF shall transition to non-operational mode and [selection: log failures in the audit record, notify the administrator, [assignment:
other actions], no other actions] when the following types of failures occur:
[selection: no other failures,
[assignment:
other failures]]
C.2.4.6 FPT_PPF_EXT Protection of Platform Firmware
Family Behavior
This family defines requirements for protecting platform firmware from unauthorized update.
Component Leveling
FPT_PPF_EXT.1,
Protection of Platform Firmware and Critical Data,
requires that the TSF prevent platform firmware from being modified outside
of the update mechanisms defined in FPT_TUD_EXT.
Management: FPT_PPF_EXT.1
There are no management functions foreseen.
Audit: FPT_PPF_EXT.1
There are no audit events foreseen.
FPT_PPF_EXT.1 Protection of Platform Firmware and Critical Data
Hierarchical to:
No other components.
Dependencies to:
No dependencies.
FPT_PPF_EXT.1.1
The TSF shall allow modification of platform firmware and critical data only through the
update mechanisms described in FPT_TUD_EXT.1.
C.2.4.7 FPT_RBP_EXT Rollback Protection
Family Behavior
This family requires that the TSF protects against rollbacks or downgrades
to its firmware.
Component Leveling
FPT_RBP_EXT.1,
Rollback Protection,
requires the TSF to detect and prevent unauthorized rollback.
Management: FPT_RBP_EXT.1
There are no management functions foreseen.
Audit: FPT_RBP_EXT.1
There are no audit events foreseen.
FPT_RBP_EXT.1 Rollback Protection
Hierarchical to:
No other components.
Dependencies to:
No dependencies.
FPT_RBP_EXT.1.1
The TSF shall verify that the new firmware package is not downgrading to a lower
security version number by [assignment:
method of verifying the security version number
is the same as or higher than the currently installed version].
FPT_RBP_EXT.1.2
The TSF shall generate and return an error code if the attempted firmware
update package is detected to be an invalid version.
C.2.4.8 FPT_ROT_EXT Platform Integrity
Family Behavior
This family defines requirements for platform firmware and hardware integrity.
Component Leveling
FPT_ROT_EXT.1,
Platform Integrity Root,
requires that the platform integrity be anchored in a root of trust.
FPT_ROT_EXT.2,
Platform Integrity Extension,
specifies how platform integrity is extended from the integrity root to other platform firmware.
Management: FPT_ROT_EXT.1
There are no management functions foreseen.
Audit: FPT_ROT_EXT.1
There are no audit events foreseen.
FPT_ROT_EXT.1 Platform Integrity Root
Hierarchical to:
No other components.
Dependencies to:
No dependencies.
FPT_ROT_EXT.1.1
The integrity of platform firmware shall be rooted in
[assignment:
platform firmware root of trust].
Management: FPT_ROT_EXT.2
The following actions could be considered for the management functions in FMT:
Configuration of action to take on integrity failure.
Audit: FPT_ROT_EXT.2
The following actions should be auditable if FAU_GEN Security audit data generation is
included in the PP/ST:
The integrity of all mutable platform firmware outside of the platform integrity root specified in FPT_ROT_EXT.1 shall be verified
prior to execution or use through:
[assignment:
method for extending the platform integrity root].
FPT_ROT_EXT.2.2
The TOE shall take the following actions if an integrity check specified in FPT_ROT_EXT.2.1 fails:
[selection:
Stop all execution, or
Notify an
[selection: Administrator, User] by
[selection: generating an audit event, [assignment:
other notification method(s)]], and
[selection:
Stop all execution
Shut down, or
Initiate a recovery process as specified in FPT_RVR_EXT.1
Skip all instructions that failed the integrity check and continue execution
]
[selection:
automatically
in accordance with Administrator-configurable policy
by express determination of an
[selection: Administrator, User]
]
].
C.2.4.9 FPT_RVR_EXT Platform Firmware Recovery
Family Behavior
This family defines requirements for recovering from a firmware integrity failure.
Component Leveling
FPT_RVR_EXT.1,
Platform Firmware Recovery,
defines mechanisms for recovering from a platform firmware integrity failure.
Management: FPT_RVR_EXT.1
The following actions could be considered for the management functions in FMT:
Configuration of action to take on integrity failure.
The TSF shall implement a mechanism for recovering from boot firmware failure consisting of
[assignment:
recovery mechanism].
C.2.4.10 FPT_SKP_EXT Protection of TSF Data
Family Behavior
Components in this family define requirements for managing and protecting
TSF data, such as cryptographic keys.
Component Leveling
FPT_SKP_EXT.1,
Protection of TSF Data (for reading of all symmetric keys,
requires
preventing symmetric keys from being read by any user or subject.
Management: FPT_SKP_EXT.1
No specific management functions are identified.
Audit: FPT_SKP_EXT.1
There are no auditable events foreseen.
FPT_SKP_EXT.1 Protection of TSF Data (for reading of all symmetric keys
Hierarchical to:
No other components.
Dependencies to:
No dependencies.
FPT_SKP_EXT.1.1
The TSF shall prevent reading of all pre-shared, symmetric keys, and private keys.
C.2.4.11 FPT_TUD_EXT Trusted Updates
Family Behavior
This family defines requirements for applying updates to the TOE.
Component Leveling
FPT_TUD_EXT.1,
TOE Firmware Update,
requires that the TSF support update of platform firmware.
FPT_TUD_EXT.2,
Platform Firmware Authenticated Update Mechanism,
specifies the requirements for authenticated update of platform firmware.
FPT_TUD_EXT.3,
Platform Firmware Delayed-Authentication Update Mechanism,
specifies the requirements for delayed-authentication update of platform firmware.
FPT_TUD_EXT.4,
Secure Local Platform Firmware Update Mechanism,
specifies the requirements for secure local update of platform firmware.
Management: FPT_TUD_EXT.1
The following actions could be considered for the management functions in FMT:
The TSF shall authenticate the source of all platform firmware updates using a
digital signature algorithm specified in FCS_COP.1 and using a key store
that contains
[selection: the public key, hash value of the public key].
FPT_TUD_EXT.2.2
The TSF shall allow installation of updates only if the digital signature has been
successfully verified as specified in FCS_COP.1 and
[assignment:
additional constraints on updates].
FPT_TUD_EXT.2.3
The TSF shall include a platform firmware version identifier that is accessible by the update mechanism and
includes information that enables the update mechanism to determine the relative order of updates.
FPT_TUD_EXT.2.4
The TSF shall provide an observable indication of the success or failure of the update operation.
FPT_TUD_EXT.2.5
The TOE shall take the following actions if a platform firmware integrity, authenticity,
or rollback-prevention check fails, or a platform firmware update fails for any other reason:
The TSF shall allow execution or use of platform firmware updates only if new platform firmware
is integrity- and authenticity-checked using the mechanism described in FPT_ROT_EXT.2 prior to its
execution or use, and [assignment:
additional constraints on update].
FPT_TUD_EXT.3.2
The TSF shall include an observable platform firmware version identifier that is accessible by the
update mechanism and includes information that enables the update mechanism to determine the relative
order of updates.
FPT_TUD_EXT.3.3
The TSF shall provide an observable indication of the success or failure of the update operation.
FPT_TUD_EXT.3.4
The TOE shall take the following actions if a platform firmware update integrity, authentication, or
rollback-prevention check fails, or a platform firmware update fails for any other reason:
[selection, choose one of:
Halt
Stop all execution and shut down
Initiate a recovery process as specified in FPT_RVR_EXT.1
]
[selection, choose one of:
automatically
in accordance with administrator-configurable policy
by express determination of a User
].
Management: FPT_TUD_EXT.4
There are no management functions foreseen.
Audit: FPT_TUD_EXT.4
There are no audit events foreseen.
FPT_TUD_EXT.4 Secure Local Platform Firmware Update Mechanism
Hierarchical to:
No other components.
Dependencies to:
No dependencies.
FPT_TUD_EXT.4.1
The TSF shall provide a secure local update mechanism that requires an assertion of physical access to the TOE
before installation of an update.
FPT_TUD_EXT.4.2
A user shall assert physical presence to the TSF through:
[assignment:
method for asserting physical presence].
FPT_TUD_EXT.4.3
The TSF shall include a platform firmware version identifier that is accessible by the update mechanism or
to the user who asserts physical presence.
FPT_TUD_EXT.4.4
The TSF shall provide an observable indication of the success or failure of the update operation.
C.2.5 TOE Access (FTA)
This PP defines the following extended components as part of the
FTA class originally defined by CC Part 2:
C.2.5.1 FTA_SSL_EXT Session Locking and Termination
Family Behavior
This family defines requirements for session locking capabilities that are not addressed by FTA_SSL in CC Part 2.
This SFR will need to be completed with all sections.
Component Leveling
FTA_SSL_EXT.1,
TSF- and TSF-initiated Session Blocking,
requires the TSF to manage the transition to a locked state and what operations can be performed.
Management: FTA_SSL_EXT.1
The following actions could be considered for the management functions in FMT:
Configuring session locking policy.
Transitioning to the locked state.
Audit: FTA_SSL_EXT.1
There are no auditable events foreseen.
FTA_SSL_EXT.1 TSF- and TSF-initiated Session Blocking
The TSF shall, for local interactive sessions,[selection: lock the session - disable any activity of the Administrator’s data access/display devices other than unlocking the session, and requiring
that the Administrator reauthenticate to the TSF prior to unlocking the session, terminate the session] after a security administrator-specified time period of inactivity.
FTA_SSL_EXT.1.2
The TSF shall transition to a locked state after initiation by either the user or
the administrator.
FTA_SSL_EXT.1.3
The TSF shall, upon transitioning to the locked state, perform the following
operations:
Clearing or overwriting display devices, obscuring the previous contents;
[assignment:
Other actions performed upon transitioning to the locked
state].
C.2.6 Trusted Path/Channel (FTP)
This PP defines the following extended components as part of the
FTP class originally defined by CC Part 2:
This family defines requirements for protection of
data in transit between the TOE and its operational environment.
Component Leveling
FTP_ITC_EXT.1,
Physically Protected Channel,
requires the TSF to implement one or more cryptographic protocols
to secure connectivity between the TSF and various external entities.
Management: FTP_ITC_EXT.1
The following actions could be considered for the management functions in FMT:
Ability to configure the cryptographic functionality.
Audit: FTP_ITC_EXT.1
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.
FTP_ITC_EXT.1 Physically Protected Channel
Hierarchical to:
No other components.
Dependencies to:
No dependencies.
FTP_ITC_EXT.1.1
The TSF shall use [assignment:
trusted channel protocols]
to provide a communication channel between itself and
[assignment:
external IT entities]
that is logically distinct from other communication channels, provides assured
identification of its end points, protects channel data from disclosure, and detects modification
of the channel data.
C.2.6.2 FTP_ITP_EXT Physically Protected Channel
Family Behavior
This family defines requirements for use of physically protected communications
mechanisms.
Component Leveling
FTP_ITP_EXT.1,
Physically Protected Channel,
requires the TSF to use a physically protected
channel for transmission of data to an external entity.
Management: FTP_ITP_EXT.1
There are no management functions foreseen.
Audit: FTP_ITP_EXT.1
There are no audit events foreseen.
FTP_ITP_EXT.1 Physically Protected Channel
Hierarchical to:
No other components.
Dependencies to:
No dependencies.
FTP_ITP_EXT.1.1
The TSF shall provide a physically protected communication channel between itself and [assignment:
list of other IT entities within the same
platform].
C.2.7 User Data Protection (FDP)
This PP defines the following extended components as part of the
FDP class originally defined by CC Part 2:
C.2.7.1 FDP_ITC_EXT Key/Credential Import
Family Behavior
This family defines requirements for supporting and integrity of importing keys and key
material.
Component Leveling
FDP_ITC_EXT.1,
Key/Credential Import,
requires the TSF to choose a method for importing keys and key material.
Management: FDP_ITC_EXT.1
No specific management functions are identified.
Audit: FDP_ITC_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is
included in the PP, PP-Module, functional package or ST:
The TSF shall support importing keys/key material using [selection: physically protected channels as specified in
FTP_ITP_EXT.1, encrypted data buffers as specified in FTP_ITE_EXT.1, key distribution mechanisms as specified in
FCS_CKM.2].
FDP_ITC_EXT.1.2
The TSF shall verify the integrity of imported keys/key material using [selection: cryptographic hash as specified
in FCS_COP.1/Hash, keyed hash as specified in FCS_COP.1/KeyedHash, integrity-providing encryption algorithm as specified
in FCS_COP.1/KeyWrap, digital signature as specified in FCS_COP.1/SigVer, integrity verification provided through FCS_CKM.2
key distribution mechanisms, integrity verification supported by FTP_ITC_EXT.1].
C.2.7.2 FDP_STG_EXT User Data Storage
Family Behavior
This family defines requirements for managing data storage.
Component Leveling
FDP_STG_EXT.1,
User Data Storage,
requires the TSF to be able to label, encrypt, store, and decrypt sensitive data and keys.
Management: FDP_STG_EXT.1
There are no management activities foreseen.
Audit: FDP_STG_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
The TSF shall provide protected storage for the Trust Anchor Database.
Appendix D - Entropy Documentation and Assessment
This appendix describes the required supplementary information for the entropy
source used by the TOE.
The documentation of the entropy source should be detailed enough that, after
reading, the evaluator will thoroughly understand the entropy source and why
it can be relied upon to provide sufficient entropy. This documentation should
include multiple detailed sections: design description, entropy justification,
operating conditions, and health testing. This documentation is not required to
be part of the TSS.
D.1 Design Description
Documentation shall include the design of the entropy source as a whole,
including the interaction of all entropy source components. Any information
that can be shared regarding the design should also be included for any
third-party entropy sources that are included in the product.
The documentation shall describe how unprocessed (raw) data was obtained for the analysis. This
description shall be sufficiently detailed to explain at what point in the entropy source model the data
was collected and what effects, if any, the process of data collection had on the overall entropy
generation rate. The documentation
should walk through the entropy source design indicating where the entropy
comes from, where the entropy output is passed next, any post-processing
of the raw outputs (hash, XOR, etc.), if/where it is stored, and finally,
how it is output from the entropy source. Any conditions placed on the
process (e.g., blocking) should also be described in the entropy source
design. Diagrams and examples are encouraged.
This design must also include a description of the content of the
security boundary of the entropy source and a description of how
the security boundary ensures that an adversary outside the boundary
cannot affect the entropy rate.
If implemented, the design description shall include a description
of how third-party applications can add entropy to the RBG. A
description of any RBG state saving between power-off and
power-on shall be included.
D.2 Entropy Justification
There should be a technical argument for where the unpredictability in
the source comes from and why there is confidence in the entropy source
delivering sufficient entropy for the uses made of the RBG output
(by this particular TOE). This argument will include a description of
the expected min-entropy rate (i.e. the minimum entropy (in bits) per
bit or byte of source data) and explain that sufficient entropy is
going into the TOE randomizer seeding process. This discussion will
be part of a justification for why the entropy source can be relied
upon to produce bits with entropy.
The amount of information necessary to justify the expected
min-entropy rate depends on the type of entropy source included in the
product.
For developer provided entropy sources, in order to justify the
min-entropy rate, it is expected that a large number of raw source
bits will be collected, statistical tests will be performed, and the
min-entropy rate determined from the statistical tests. While no
particular statistical tests are required at this time, it is expected
that some testing is necessary in order to determine the amount of
min-entropy in each output.
For third party provided entropy sources, in which the TOE vendor
has limited access to the design and raw entropy data of the source, the
documentation will indicate an estimate of the amount of min-entropy
obtained from this third-party source. It is acceptable for the vendor
to “assume” an amount of min-entropy, however, this assumption must be
clearly stated in the documentation provided. In particular, the
min-entropy estimate must be specified and the assumption included
in the ST.
Regardless of type of entropy source, the justification will also
include how the DRBG is initialized with the entropy stated in the ST,
for example by verifying that the min-entropy rate is multiplied by the
amount of source data used to seed the DRBG or that the rate of entropy
expected based on the amount of source data is explicitly stated and
compared to the statistical rate. If the amount of source data used to
seed the DRBG is not clear or the calculated rate is not explicitly
related to the seed, the documentation will not be considered complete.
The entropy justification shall not include any data added from
any third-party application or from any state saving between restarts.
D.3 Operating Conditions
The entropy rate may be affected by conditions outside the control
of the entropy source itself. For example, voltage, frequency,
temperature, and elapsed time after power-on are just a few of the
factors that may affect the operation of the entropy source.
As such, documentation will also include the range of operating conditions
under which the entropy source is expected to generate random data.
It will clearly describe the measures that have been taken in the
system design to ensure the entropy source continues to operate
under those conditions. Similarly, documentation shall describe
the conditions under which the entropy source is known to malfunction
or become inconsistent. Methods used to detect failure or degradation
of the source shall be included.
D.4 Health Testing
More specifically, all entropy source health tests and their rationale
will be documented. This will include a description of the health tests,
the rate and conditions under which each health test is performed
(e.g., at startup, continuously, or on-demand), the expected results
for each health test, and rationale indicating why each test is
believed to be appropriate for detecting one or more failures in the
entropy source.
Appendix E - Application Software Equivalency Guidelines
E.1 Introduction
The purpose of equivalence in PP-based evaluations is to find a balance between evaluation rigor and commercial practicability—to
ensure that evaluations meet customer expectations while recognizing that there is little to be gained from requiring that every
variation in a product or platform be fully tested. If a product is found to be compliant with a PP on one platform, then all
equivalent products on equivalent platforms are also considered to be compliant with the PP.
A Vendor can make a claim of equivalence if the Vendor believes that a particular instance of their Product implements PP-specified
security functionality in a way equivalent to the implementation of the same functionality on another instance of their Product on
which the functionality was tested. The Product instances can differ in version number or feature level (model), or the instances may
run on different platforms. Equivalency can be used to reduce the testing required across claimed evaluated configurations. It can
also be used during Assurance Maintenance to reduce testing needed to add more evaluated configurations to a certification.
These equivalency guidelines do not replace Assurance Maintenance requirements or NIAP Policy #5 requirements for CAVP certificates.
Nor may equivalency be used to leverage evaluations with expired certifications.
These Equivalency Guidelines represent a shift from complete testing of all product instances to more of a risk-based approach.
Rather than require that every combination of product and platform be tested, these guidelines support an approach that recognizes
that products are being used in a variety of environments—and often in cloud environments over where the vendor (and sometimes the
customer) have little or no control over the underlying hardware. Developers should be responsible for the security functionality of
their applications on the platforms they are developed for—whether that is an operating system, a virtual machine, or a software-based
execution environment such as a container. But those platforms may themselves run within other environments—virtual machines or
operating systems—that completely abstract away the underlying hardware from the application. The developer should not be held
accountable for security functionality that is implemented by platform layers that are abstracted away. The implication is that
not all security functionality will necessarily be tested for all platform layers down to the hardware for all evaluated
configurations—especially for applications developed for software-based execution environments such as containers. For these cases,
the balancing of evaluation rigor and commercial practicability tips in favor of practicability. Note that this does not affect
the requirement that at least one product instance be fully tested on at least one platform with cryptography mapped to a CAVP
certificate.
Equivalency has two aspects:
Product Equivalence: Products may be considered equivalent if there are no
differences between Product Models and Product Versions with respect to PP-specified security functionality.
Platform Equivalence: Platforms may be considered equivalent if there are no
significant differences in the services they provide to the Product—or in the way the platforms
provide those services—with respect to PP-specified security functionality.
The equivalency determination is made in accordance with these guidelines by the Validator and Scheme using information provided by the Evaluator/Vendor.
E.2 Approach to Equivalency Analysis
There are two scenarios for performing equivalency analysis. One is when a product has been certified and the vendor
wants to show that a later product should be considered certified due to equivalence with the earlier product. The
other is when multiple product variants are going though evaluation together and the vendor would like to reduce
the amount of testing that must be done. The basic rules for determining equivalence are the same in both cases.
But there is one additional consideration that applies to equivalence with previously certified products. That is,
the product with which equivalence is being claimed must have a valid certification in accordance with scheme rules
and the Assurance Maintenance process must be followed. If a product’s certification has expired, then equivalence
cannot be claimed with that product.
When performing equivalency analysis, the Evaluator/Vendor should first use the factors and guidelines for Product
Model equivalence to determine the set of Product Models to be evaluated. In general, Product Models that do not differ
in PP-specified security functionality are considered equivalent for purposes of evaluation against the AppPP.
If multiple revision levels of Product Models are to be evaluated—or to determine whether a revision of an evaluated
product needs re-evaluation—the Evaluator/Vendor and Validator should use the factors and guidelines for Product
Version equivalence to analyze whether Product Versions are equivalent.
Having determined the set of Product Models and Versions to be evaluated, the next step is to determine the set of
Platforms that the Products must be tested on.
Each non-equivalent Product for which compliance is claimed must be fully tested on each non-equivalent platform
for which compliance is claimed. For non-equivalent Products on equivalent platforms, only the differences that
affect PP-specified security functionality must be tested for each product.
“Differences in PP-Specified Security Functionality” Defined
If PP-specified security functionality is implemented by the TOE, then differences in the actual implementation
between versions or product models break equivalence for that feature. Likewise, if the TOE implements the
functionality in one version or model and the functionality is implemented by the platform in another version
or model, then equivalence is broken. If the functionality is implemented by the platform in multiple models or
versions on equivalent platforms, then the functionality is considered different if the product invokes the platform
differently to perform the function.
E.3 Specific Guidance for Determining Product Model Equivalence
Product Model equivalence attempts to determine whether different feature levels of the same product across
a product line are equivalent for purposes of PP testing. For example, if a product has a “basic” edition and an “enterprise”
edition, is it necessary to test both models? Or does testing one model provide sufficient assurance that both models
are compliant?
Product models are considered equivalent if there are no differences that affect PP-specified security
functionality—as indicated in Table 1.
If the differences between Models affect only non-PP-specified functionality, then the Models are equivalent.
Different
If PP-specified security functionality is affected by the differences between Models,
then the Models are not equivalent and must be tested separately. It is necessary only to test the functionality
affected by the software differences. If only differences are tested, then the differences must be enumerated,
and for each difference the Vendor must provide an explanation of why each difference does or does not affect
PP-specified functionality. If the Product Models are separately tested fully, then there is no need to document the differences.
Table 1. Determining Product Model Equivalence
E.4 Specific Guidance for Determining Product Version Equivalence
In cases of version equivalence, differences are expressed in terms of changes implemented in revisions
of an evaluated Product. In general, versions are equivalent if the changes have no effect on any
security-relevant claims about the TOE or assurance evidence. Non-security-relevant changes to TOE
functionality or the addition of non-security-relevant functionality does not affect equivalence.
Factor
Same/Different
Guidance
Product Models
Different
Versions of different Product Models are not equivalent unless the Models are equivalent as defined in Section 3.
If the differences affect only non-PP-specified functionality, then the Versions are equivalent.
Different
If PP-specified security functionality is affected by the differences, then the
Versions are not considered equivalent and must be tested separately. It is necessary only to test
the functionality affected by the changes. If only the differences are tested, then for each
difference the Vendor must provide an explanation of why the difference does or does not affect
PP-specified functionality. If the Product Versions are separately tested fully, then there is
no need to document the differences.
Table 2. Factors for Determining Product Version Equivalence
E.5 Specific Guidance for Determining Platform Equivalence
Platform equivalence is used to determine the platforms that equivalent versions of a Product must be tested on.
Platform equivalence analysis done for one software application cannot be applied to another software application.
Platform equivalence is not general—it is with respect to a particular application.
Product Equivalency analysis must already have been done and Products have been determined to be equivalent.
The platform can be hardware or virtual hardware, an operating system or similar entity, or a software execution
environment such as a container. For purposes of determining equivalence for software applications, we address each
type of platform separately. In general, platform equivalence is based on differences in the interfaces between the
TOE and Platform that are relevant to the implementation of PP-specified security functionality.
If an application runs directly on hardware without an operating system—or directly on virtualized
hardware without an operating system—then platform equivalence is based on processor architecture and
instruction sets. In the case of virtualized hardware, it is the virtualized processor and architecture
that are presented to the application that matters—not the physical hardware.
Platforms with different processor architectures and instruction sets are not equivalent. This is not
likely to be an issue for equivalency analysis for applications since there is likely to be a different
version of the application for different hardware environments.
Equivalency analysis becomes important when comparing processors with the same architecture. Processors
with the same architecture that have instruction sets that are subsets or supersets of each other are not
disqualified from being equivalent for purposes of an App evaluation. If the application takes the same
code paths when executing PP-specified security functionality on different processors of the same family,
then the processors can be considered equivalent with respect to that application.
For example, if an application follows one code path on platforms that support the AES-NI instruction
and another on platforms that do not, then those two platforms are not equivalent with respect to that
application functionality. But if the application follows the same code path whether or not the platform
supports AES-NI, then the platforms are equivalent with respect to that functionality.
The platforms are equivalent with respect to the application if the platforms are equivalent with respect to all PP-specified
security functionality.
Factor
Same/Different/None
Guidance
Platform Architectures
Different
Platforms that present different processor architectures and instruction sets to the application are not equivalent.
For platforms with the same processor architecture, the platforms are equivalent with
respect to the application if execution of all PP-specified security functionality follows the same code path on both platforms.
Table 3. Factors for Determining Hardware/Virtual Hardware Platform Equivalence
E.5.2 Platform Equivalence—OS Platforms
For traditional applications that are built for and run on operating systems, platform equivalence is
determined by the interfaces between the application and the operating system that are relevant to PP-specified
security functionality. Generally, these are the processor interface, device interfaces, and OS APIs. The following
factors applied in order:
Factor
Same/Different/None
Guidance
Platform Architectures
Different
Platforms that run on different processor architectures and instruction sets are not equivalent.
Platform Vendors
Different
Platforms from different vendors are not equivalent.
Platform Versions
Different
Platforms from the same vendor with different major version numbers are not equivalent.
Platform Interfaces
Different
Platforms from the same vendor and major version are not equivalent if there are
differences in device interfaces and OS APIs that are relevant to the way the platform provides PP-specified
security functionality to the application.
Platform Interfaces
Same
Platforms from the same vendor and major version are equivalent if there are
no differences in device interfaces and OS APIs that are relevant to the way the platform
provides PP-specified security functionality to the application, or if the Platform does
not provide such functionality to the application.
Table 4. Factors for Determining OS/VS Platform Equivalence
If an Application is built for and runs in a non-OS software-based execution environment, such as a Container or
Java Runtime, then the below criteria must be used to determine platform equivalence. The key point is that the
underlying hardware (virtual or physical) and OS is not relevant to platform equivalence. This allows applications
to be tested and run on software-based execution environments on any hardware—as in cloud deployments.
Factor
Same/Different/None
Guidance
Platform Type/Vendor
Different
Software-based execution environments that are substantially different or come
from different vendors are not equivalent. For example, a Java virtual machine is not the same as a
container. A Docker container is not the same as a CoreOS container.
Platform Versions
Different
Execution environments that are otherwise equivalent are not equivalent if they have
different major version numbers.
All other things being equal, execution environments are equivalent if there is no
significant difference in the interfaces through which the environments provide PP-specified security
functionality to applications.
Table 5. Factors for Software-based Execution Environment Platform Equivalence
E.6 Level of Specificity for Tested Configurations and Claimed Equivalent Configurations
In order to make equivalency determinations, the vendor and evaluator must agree on the equivalency claims. They must
then provide the scheme with sufficient information about the TOE instances and platforms that were evaluated, and the
TOE instances and platforms that are claimed to be equivalent.
The ST must describe all configurations evaluated down to processor manufacturer, model number, and microarchitecture version.
The information regarding claimed equivalent configurations depends on the platform that the application was developed for and runs on.
Bare-Metal Applications
For applications that run without an operating system on bare-metal or virtual bare-metal, the claimed configuration must
describe the platform down to the specific processor manufacturer, model number, and microarchitecture version. The Vendor
must describe the differences in the TOE with respect to PP-specified security functionality and how the TOE functions
differently to leverage platform differences (e.g., instruction set extensions) in the tested configuration versus the
claimed equivalent configuration.
Traditional Applications
For applications that run with an operating system as their immediate platform, the claimed configuration must describe
the platform down to the specific operating system version. If the platform is a virtualization system, then the claimed
configuration must describe the platform down to the specific virtualization system version. The Vendor must describe the
differences in the TOE with respect to PP-specified security functionality and how the TOE functions differently to leverage
platform differences in the tested configuration versus the claimed equivalent configuration. Relevant platform differences
could include instruction sets, device interfaces, and OS APIs invoked by the TOE to implement PP-specified security
functionality.
Software-Based Execution Environments
For applications that run in a software-based execution environment such as a Java virtual machine or a Container, then
the claimed configuration must describe the platform down to the specific version of the software execution environment.
The Vendor must describe the differences in the TOE with respect to PP-specified security functionality and how the TOE
functions differently to leverage platform differences in the tested configuration versus the claimed equivalent
configuration.
