Version | Date | Comment |
---|---|---|
0.1 | 2020-11-16 | Started |
1.0.92022 | 2022-02-10 | Initial publication. |
1.1 | 2024-12-13 | Updates for CC:2022 |
2.0 | 2025-01-10Latest draft13 | Draft: Incorporate TRRTs |
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. |
Extended Package (EP)
| A deprecated document form for collecting SFRs that implement a particular protocol, technology, or functionality. See Functional Packages. |
Functional Package (FP)
| A document that collects SFRs for a particular protocol, technology, or functionality. |
Operational Environment (OE)
| Hardware and software that are outside the TOE boundary that support the TOE functionality and security policy. |
Protection Profile (PP)
| An implementation-independent set of security requirements for a category of products. |
Protection Profile Configuration (PP-Configuration)
| A comprehensive set of security requirements for a product type that consists of at least one Base-PP and at least one PP-Module. |
Protection Profile Module (PP-Module)
| An implementation-independent statement of security needs for a TOE type complementary to one or more Base |
-PPs. | |
Security Assurance Requirement (SAR)
| A requirement to assure the security of the TOE. |
Security Functional Requirement (SFR)
| A requirement for security enforcement by the TOE. |
Security Target (ST)
| A set of implementation-dependent security requirements for a specific product. |
Target of Evaluation (TOE)
| The product under evaluation. |
TOE Security Functionality (TSF)
| The security functionality of the product under evaluation. |
TOE Summary Specification (TSS)
| A description of how a TOE satisfies the SFRs in an ST. |
Administrator
| An Administrator is responsible for management activities, including setting policies that are applied by the enterprise on the platform. An Administrator can act remotely through a management server, from which the platform receives configuration policies and updates. An Administrator can enforce settings on the system that cannot be overridden by non-Administrator users. |
American National Standards Institute (ANSI)
| A private organization that oversees development of standards in the United States. |
Application
| Software that runs on a platform and performs tasks on behalf of the user or owner of the platform. |
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. |
Baseboard Management Controller (BMC)
| Or Management Controller. A small computer generally found on Server motherboards that performs management tasks on behalf of an Administrator. |
Cipher-based Message Authentication Code (CMAC)
| A mode of AES that provides authentication, but not confidentiality. |
Commercial Solutions for Classified (CSfC)
| An US Department of Defense program for delivering cybersecurity solutions that leverage commercial technologies and products. |
Credential
| Data that establishes the identity of a user, e.g. a cryptographic key or password. |
Critical Security Parameters (CSP)
| Information that is either user or system defined and is used to operate a cryptographic module in processing encryption functions including cryptographic keys and authentication data, such as passwords, the disclosure or modification of which can compromise the security of a cryptographic module or the security of the information protected by the module. |
Data-at-Rest (DAR) Protection
| Countermeasures that prevent attackers, even those with physical access, from extracting data from non-volatile storage. Common techniques include data encryption and wiping. |
Developer
| An entity that manufactures platform hardware or writes |
platform software/firmware. For the purposes of this document, vendors and developers are the same. | |
Diffie-Hellman Key Exchange (DH)
| A cryptographic key exchange protocol using public/private key pairs. |
Distinguished Name (DN)
| Information used in certificate-based operations to uniquely identify a person, organization, or business. |
End-User Device (EUD)
| A class of computing platform characterized by having a user interface for a single user. Often, EUDs are portable (e.g., laptop, tablet, mobile device), but this is not necessarily the case (e.g., desktop PC). |
General Purpose Operating System
| A class of OS designed to support a wide-variety of workloads consisting of many concurrent applications or services. Typical characteristics for OSes in this class include support for third-party applications, support for multiple users, and security separation between users and their respective resources. |
General-Purpose Computing Platform (GPCP)
| A physical computing platform designed to support general-purpose operating systems, virtualization systems, and applications. |
Internet of Things (IoT)
| Physical computing devices that are embedded with sensors, processing ability, software, and other technologies that connect and exchange data with other devices and systems over communications networks. |
Joint Test Action Group (JTAG)
| A standard for verifying and testing circuit boards after manufacture. |
KECCAK Message Authentication Code (KMAC)
| A variable-length keyed hash function described in NIST SP 800-185. |
Management Controller (MC)
| Or Baseboard Management Controller (BMC). A small computer generally found on server motherboards that performs management tasks on behalf of an Administrator. |
Open Mobile Terminal Platform (OMTP)
| A forum created by mobile network operators to discuss standards with manufacturers of mobile devices. |
Operating System (OS)
| Software that manages physical and logical resources and provides services for applications. Operating systems are the generally the primary tenant of a GPCP. |
Physical Presence
| A user or administrator having physical access to 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. |
Root of Trust (RoT)
| Roots of trust are highly reliable hardware, firmware, and software components that perform specific, critical security functions. Roots of trust are the foundation for integrity of computing devices. |
Sensitive Data
| Sensitive data may include all user or enterprise data or may be specific application data such as PII, emails, messaging, documents, calendar items, and contacts. Sensitive data must minimally include credentials and keys. |
Subject Alternative Name (SAN)
| An extended X.509 certificate field. |
Tenant Software
| Software that runs on and is supported by a platform. In the case of a GPCP, tenant software generally consists of an operating system, virtualization system, or "bare-metal" application. |
Trusted Execution Environment (TEE)
| An isolated and secure area that ensures the confidentiality and integrity of code and data loaded inside. |
User
| In the context of a GPCP, a User is a human who interacts with the platform through a user interface. Users do not need to be authenticated by the platform to use the platform, but generally authenticate to tenant software such as on Operating System. |
Virtualization System (VS)
| A software product that enables multiple independent computing systems to execute on the same physical hardware platform without interference from one other. |
Addresses TRRT 1567 If the GPCP includes Full Drive Encryption (FDE), and the FDE component has been previously evaluated against the FDEcPPs, or will be evaluated against the FDEcPPs concurrently with the GPCP evaluation, then the FDE component may be excluded from the TOE for purposes of the GPCP evaluation.
The requirements associated with some use case encompass those of other use cases. In these situations, a TOE that meets the larger set of requirements meets both use cases. Specifically
This use case adds audit requirements and Administrator authentication requirements to the base mandatory requirements.
For changes to included SFRs, selections, and assignments required for this use case, see G.1 Server-Class Platform, Basic.
This use case adds requirements for audit, physical protections, and Administrator authentication to the base mandatory SFRs. It removes the assumption that the TOE is physically protected by the OE.
For changes to included SFRs, selections, and assignments required for this use case, see G.2 Server-Class Platform, Enhanced.
This use case adds no requirements to the base mandatory SFRs.
For changes to included SFRs, selections, and assignments required for this use case, see G.4 Portable Clients (laptops, tablets), Enhanced.
Although CSfC requires that users maintain physical control of EUDs at all times, this . This use case removes the assumption that the TOE is protected by the OE and adds requirements for audit and basic tamper detection and reportingfor protection of debug ports .
For changes to included SFRs, selections, and assignments required for this use case, see G.5 CSfC EUD.
For changes to included SFRs, selections, and assignments required for this use case, see G.6 Tactical EUD.
This use case adds only audit to the base mandatory SFRs.
For changes to included SFRs, selections, and assignments required for this use case, see G.7 Enterprise Desktop clients.
For changes to included SFRs, selections, and assignments required for this use case, see G.8 IoT Devices.
Threat, Assumption , or OSP | Security Objectives | Rationale |
T.PHYSICAL
| O.PHYSICAL_INTEGRITY | The threat T.PHYSICAL is countered by O.PHYSICAL_INTEGRITY as this objective supports detection or prevention of attempts to compromise the physical platform. |
O.ATTACK_DETECTION_AND_RESPONSE | The threat T.PHYSICAL is countered by O.ATTACK_DETECTION_AND_RESPONSE as this objective supports detection and reporting of attempts to compromise the TOE. | |
T.SIDE_CHANNEL_LEAKAGE
| O.MITIGATE_FUNDAMENTAL_FLAWS | The threat T.SIDE_CHANNEL_LEAKAGE is countered by O.MITIGATE_FUNDAMENTAL_FLAWS as this objective supports the remedy of critical flaws through update or other technical or operational means. |
T.PERSISTENCE
| O.PROTECTED_FIRMWARE | The threat T.PERSISTENCE is countered by O.PROTECTED_FIRMWARE as this objective supports maintenance of platform firmware integrity. |
T.UPDATE_COMPROMISE
| O.UPDATE_INTEGRITY | The threat T.UPDATE_COMPROMISE is countered by O.UPDATE_INTEGRITY as this objective supports ensuring that platform firmware updates are authentic and properly validated prior to installation. |
O.STRONG_CRYPTOGRAPHY | The threat T.UPDATE_COMPROMISE is countered by O.STRONG_CRYPTOGRAPHY as this objective supports use of proven, standards-based cryptographic mechanisms for ensuring that updates are authentic and maintain their integrity. | |
O.ATTACK_DETECTION_AND_RESPONSE | The threat T.UPDATE_COMPROMISE is countered by O.ATTACK_DETECTION_AND_RESPONSE as this objective supports detection and reporting of attempts to compromise the TOE. | |
T.SECURITY_FUNCTIONALITY_FAILURE
| O.SECURITY_FUNCTIONALITY_INTEGRITY | The threat T.SECURITY_FUNCTIONALITY_FAILURE is countered by O.SECURITY_FUNCTIONALITY_INTEGRITY as this objective supports integrity and proper functioning of security functionality. |
T.TENANT_BASED_ATTACK
| O.TENANT_SECURITY | The threat T.TENANT_BASED_ATTACK is countered by O.TENANT_SECURITY as this objective supports tenant-based security mechanisms to prevent tenant compromise. |
T.NETWORK_BASED_ATTACK
| O.TRUSTED_CHANNELS | The threat T.NETWORK_BASED_ATTACK is countered by O.TRUSTED_CHANNELS as this provides for integrity and confidentiality of transmitted data. |
T.UNAUTHORIZED_RECONFIGURATION
| O.CONFIGURATION_INTEGRITY | The threat T.UNAUTHORIZED_RECONFIGURATION is countered by O.CONFIGURATION_INTEGRITY as this provides for integrity of platform configuration. |
T.UNAUTHORIZED_PLATFORM_ADMINISTRATOR
| O.AUTHORIZED_ADMINISTRATOR | The threat T.UNAUTHORIZED_PLATFORM_ADMINISTRATOR is countered by O.AUTHORIZED_ADMINISTRATOR as this provides for authentication of privileged Administrators. |
A.PHYSICAL_PROTECTIONA.PHYSICAL_​PROTECTION | OE.PHYSICAL_PROTECTION​PROTECTION | The operational environment objective OE.PHYSICAL_PROTECTION is realized through A.PHYSICAL_PROTECTION. |
A.ROT_INTEGRITY​INTEGRITY | OE.SUPPLY_CHAIN​CHAIN | The operational environment objective OE.SUPPLY_CHAIN is realized through A.ROT_INTEGRITY. |
A.TRUSTED_ADMIN​ADMIN | OE.TRUSTED_ADMIN​ADMIN | The operational environment objective OE.TRUSTED_ADMIN is realized through A.TRUSTED_ADMIN. |
A.MFR_ROT​ROT | OE.TRUSTED_ADMIN​ADMIN | The operational environment objective OE.TRUSTED_ADMIN is realized through A.TRUSTED_ADMIN. |
A.TRUSTED_DEVELOPMENT​DEVELOPMENT_AND​AND_BUILD​BUILD_PROCESSES​PROCESSES | OE.TRUSTED_ADMIN​ADMIN | The operational environment objective OE.TRUSTED_ADMIN is realized through A.TRUSTED_ADMIN. |
A.SUPPLY_CHAIN​CHAIN_SECURITY​SECURITY | OE.TRUSTED_ADMIN​ADMIN | The operational environment objective OE.TRUSTED_ADMIN is realized through A.TRUSTED_ADMIN. |
A.CORRECT_INITIAL​INITIAL_CONFIGURATION​CONFIGURATION | OE.TRUSTED_ADMIN​ADMIN | The operational environment objective OE.TRUSTED_ADMIN is realized through A.TRUSTED_ADMIN. |
A.TRUSTED_USERS​USERS | OE.TRUSTED_ADMIN​ADMIN | The operational environment objective OE.TRUSTED_ADMIN is realized through A.TRUSTED_ADMIN. |
A.REGULAR_UPDATES​UPDATES | OE.TRUSTED_ADMIN​ADMIN | The operational environment objective OE.TRUSTED_ADMIN is realized through A.TRUSTED_ADMIN. |
Requirement | Auditable Events | Additional Audit Record Contents |
---|---|---|
FCS_COP.1/KeyEncap | ||
No events specified | N/A | |
FCS_COP.1/KeyWrap | ||
No events specified | N/A | |
FCS_COP.1/XOF | ||
No events specified | N/A | |
FCS_OTV_EXT.1 | ||
No events specified | N/A | |
FCS_RBG.6 | ||
No events specified | N/A | |
FMT_CFG_EXT.1 | ||
No events specified |
N/A | |
FMT_MOF.1 | |
No events specified |
N/A | |
FMT_SMF.1 | |
No events specified |
N/A | |
FMT_SMR.1 | |
No events specified |
N/A | |
FPT_JTA_EXT.1 | |
No events specified |
N/A | |
FPT_PPF_EXT.1 | |
No events specified |
N/A | |
FPT_ROT_EXT.1 | |
No events specified |
N/A | |
FPT_ROT_EXT.2 | |
[selection: Failure of integrity verification, None] |
None. | |
FPT_STM.1 | |
No events specified |
N/A | |
FPT_TUD_EXT.1 | |
No events specified |
N/A |
The following table provides the recommended choices for completion of the selection operations of FCS_COP.1/KeyEncap.
Identifier | Cryptographic algorithm | Cryptographic key sizes | List of standards |
---|---|---|---|
KAS1 | KAS1 [RSA-single party] | [selection: 2048 bit, 3072 bit, 4096 bit, 8192 bit] | NIST SP 800-56B Revision 2 (Sections 6.3 and 8.2) |
KTS-OAEP | KTS-OAEP [RSA-OAEP] | [selection: 2048 bit, 3072 bit, 4096 bit, 8192 bit] | NIST SP 800-56B Revision 2 (Sections 6.3 and 9) |
ML-KEM | ML-KEM Key Encapsulation | Parameter set = [selection: ML-KEM-512, ML-KEM-768, ML-KEM-1024] | NIST FIPS 203 (Section 7.2) |
The following table provides the recommended choices for completion of the selection operations of FCS_COP.1/KeyWrap.
Identifier | Cryptographic algorithm | Cryptographic key sizes | List of standards |
---|---|---|---|
KW | [selection: AES, CAM, SEED, LEA] in KW mode | [selection: 128 (AES, CAM, SEED, LEA), 192 (AES, CAM, LEA), 256 (AES, CAM, LEA)] bits | [selection: ISO/IEC 19772:2020 (clause 6), NIST SP 800-38F (Section 6.2)] [KW mode] |
KWP | [selection: AES, CAM, SEED, LEA] in KWP mode | [selection: 128 (AES, CAM, SEED, LEA), 192 (AES, CAM, LEA), 256 (AES, CAM, LEA)] bits | NIST SP 800-38F (Section 6.3) [KWP mode] |
CCM | [selection: AES, CAM, SEED, LEA] in CCM mode with non-repeating nonce, minimum size of 64 bits | [selection: 128 (AES, CAM, SEED, LEA), 192 (AES, CAM, LEA), 256 (AES, CAM, LEA)] bits | [selection: ISO/IEC 19772:2020 (Clause 7), NIST SP 800-38C] [CCM mode] |
GCM | [selection: AES, CAM, SEED, LEA] in GCM mode with non-repeating IVs IV length must be equal to 96 bits; the deterministic IV construction method [SP800-38D, Section 8.2.1] must be used; the MAC length t must be one of the values 96, 104, 112, 120, and 128 bits. | [selection: 128 (AES, CAM, SEED, LEA), 192 (AES, CAM, LEA), 256 (AES, CAM, LEA)] bits | [selection: ISO/IEC 19772:2020 (Clause 10), NIST SP 800-38D] [GCM mode] |
The SEED algorithm supports keys of size 128 bits only.
The following table provides the recommended choices for completion of the selection operations of FCS_COP.1/XOF.
Cryptographic algorithm | Parameters | List of standards |
---|---|---|
cSHAKE | Output length d = [selection: 128, 256] bits and function [selection: SHAKEd, KECCAK[2d]] | NIST SP 800-185 Section 3 [cSHAKE], Section 6.2 [SHAKE]
NIST FIPS PUB 202 Section 5 [KECCAK] |
KMACXOF | Output length d = [selection: 128, 256] bits | NIST SP 800-185 Section 4.3.1 [KMACXOF] |
SHAKE | Output length d = [selection: 128, 256] bits | NIST FIPS PUB 202 Section 6.2 [SHAKE] |
The following table provides the recommended choices for completion of the selection operations of FCS_COP.1/XOF.
Algorithm or mode | List of standards | Notes |
---|---|---|
HMAC | FIPS PUB 198-1, NIST SP 800-56C Revision 2 | Depending on the use case, salts can be secret or known, randomly generated or all zero. Secret IVs may be required, e.g., for key derivation. Refer to the relevant standards for your use case. |
KMAC | NIST SP 800-185,
NIST SP 800-56C Revision 2 | Depending on the use case, salts can be secret or known, randomly generated or all zero. Secret IVs may be required, e.g., for key derivation. Refer to the relevant standards for your use case. |
KDF | NIST SP 800-108 Revision 1,
NIST SP 800-135 Revision 1, ISO/IEC 11770-6:2016 (Subclause 7.3.2) | Salts and IVs are generated as directed for HMAC, AES, and CAM cryptographic algorithms. Refer to the relevant standards. |
PBKDF | NIST SP 800-132 | Salts are generated and used as directed in PBKDFs. |
CTR | NIST SP 800-38A | "Initial Counter" (nonce) shall be non-repeating. No counter value shall be repeated across multiple messages with the same secret key. |
CBC | NIST SP 800-38A Appendix C | Depending on the use case, IVs shall be unpredictable. Repeating IVs leak information about whether the first one or more blocks are shared between two messages, so IVs should be non-repeating in such situations. Refer to the relevant standards for your use case. |
OFB | NIST SP 800-38A | IVs shall be non-repeating and shall not be generated by invoking the cipher on another IV. OFB may require the IV to be a nonce. |
CFB | NIST SP 800-38A | IVs should be non-repeating as repeating IVs leak information about the first plaintext block and about common shared prefixes in messages |
XTS | NIST SP 800-38E,
IEEE Std 1619-2018 | Tweak values shall be non-negative integers, assigned consecutively, and starting at an arbitrary non-negative integer (i.e., sequential nonces). |
CMAC | NIST SP 800-38B | IV is all zeroes |
KW, KWP | NIST SP 800-38F | Depending on the use case, nonces may be required. Please reference the relevant standards for your use case. |
CCM | NIST SP 800-38C | Nonces shall be non-repeating. |
GCM | NIST SP 800-38D | For RBG-based IV construction (section 8.2.2) the number of invocations of GCM shall not exceed 2^32 for a given secret key. |
RSA-OAEP | NIST SP 800-56B Revision 2 | Mask for padding shall be randomly generated |
# | Management Function | Admin | User | Application Notes |
1 | Ability to administer the platform [selection: locally, remotely, not at all] |
MMandatory
|
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."Not at all" is the proper selection for Function 1 only in the case where the GPCP is incapable of being Administered at all. If "remotely" is selected, then FTP_TRP.1 |
must be claimed in the ST and |
Function 5 must be selected.
|
2 | Ability to configure and manage the audit functionality and audit data. |
OOptional/Conditional
|
X
|
Not permitted
|
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
|
X
|
Not permitted
|
This function must be claimed if FAU_STG |
.1 is |
claimed in the ST |
. |
|||
4 | Ability to review audit records. |
OOptional/Conditional
|
X
|
Not permitted
|
This Function must be claimed if FAU_SAR.1 is claimed in |
the ST |
. |
|||
5 | Ability to initiate a trusted channel for remote administration. |
OOptional/Conditional
|
X
|
Not permitted
|
This Function must be claimed if FTP_TRP.1 is |
claimed in the ST |
. |
|||
6 | Ability to set parameters for allowable number of authentication failures. |
OOptional/Conditional
|
X
|
Not permitted
|
This Function must be claimed if FIA_AFL_EXT.1 is |
claimed in the ST |
. |
|||
7 | Ability to configure password length and complexity. |
OOptional/Conditional
|
X
|
Not 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.
|
|||
8 | Ability to configure authentication throttling policy. |
OOptional/Conditional
|
X
|
Not 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.
|
|||
9 | Ability to manage authentication methods and change default authorization factors. |
OOptional/Conditional
|
X
|
Not 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.
|
|||
10 | Ability to configure of certificate revocation checking methods. |
OOptional/Conditional
|
X
|
Not permitted
|
This function must be claimed if FIA_X509_EXT.1 is |
claimed in the ST |
(i.e., the TOE claims conformance to , version . If TOE does not support configuration of certificate revocation checking methods, then the Administrator option should be denied.
|
|||
11 | Ability to configure TSF behavior when certificate revocation status cannot be determined. |
OOptional/Conditional
|
X
|
Not permitted
|
This function must be claimed if FIA_X509_EXT.2 is |
claimed in the ST |
(i.e., the TOE claims conformance to , version . 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. |
|||
12 | Ability to configure default action to take on integrity failure. |
OOptional/Conditional
|
X
|
Not permitted
|
This Function must be claimed if FPT_ROT_EXT.2 or FPT_ROT_EXT.3 |
are claimed in the ST and "in accordance with Administrator-configurable policy" is selected in FPT_ROT_EXT.2.2 or FPT_ROT_EXT.3.2 |
. |
|||
13 | Ability to configure default action to take on update failure. |
OOptional/Conditional
|
X
|
Not permitted
|
This Function must be claimed if FPT_TUD_EXT.2 or FPT_TUD_EXT.3 is |
claimed in the ST and "in accordance with Administrator-configurable policy" is selected in FPT_TUD_EXT.2.5 or FPT_TUD_EXT.3.4 |
. |
|||
14 | Ability to initiate the update process. |
OOptional/Conditional
|
X
|
Not permitted
|
This Function must be claimed if something other than "no mechanism for platform firmware update" is selected in FPT_TUD_EXT.1.1 |
. |
|||
15 | Ability to determine the action to take on update failure. |
OOptional/Conditional
|
O
|
Optional/Conditional
|
This Function must be claimed if FPT_TUD_EXT.2 or FPT_TUD_EXT.3 |
are claimed in the ST |
. The Administrator Option must be selected if "by express determination of an [Administrator]" is selected in FPT_TUD_EXT.2.5 or FPT_TUD_EXT.3.4 |
.
The User Option must be selected |
if "by express determination of an [User]" is selected |
in FPT_TUD_EXT.2.5 or FPT_TUD_EXT.3.4.
|
|||
16 | Ability to determine the action to take on integrity check failure. |
OOptional/Conditional
|
O
|
Optional/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.
|
|||
17 | Ability to manage import and export of keys/secrets to and from protected storage. |
OOptional/Conditional
|
X
|
Not permitted
|
This Function must be claimed if FCS_STG_EXT.1 is |
claimed in the ST |
. |
Administration is considered “remote” if communications between the Administrator and GPCP is over a network.
"Not If "not at all" is the proper selection for Function 1 only in the case where the GPCP is incapable of being Administered at allselected in Function 1, then no other management Management Functions may be selected.
The following rationale provides justification for each security objective SFR for the TOE, showing that the SFRs are suitable to meet and achieve the security objectivesaddress the specified threats:
ObjectiveThreat | Addressed by | Rationale | ||
---|---|---|---|---|
T.PHYSICAL | _INTEGRITYFPT_JTA_EXT.1 | Supports the objective through Mitigates threat by restricting access to debug ports . | FPT_TUD_EXT.1 | Supports the objective through requiring that a TOE be either updateable or immutable|
to authorized Administrators or physical presence. | ||||
FPT_ROT_EXT.3 (objective)Supports the objective through requiring supply chain traceability | Mitigates threat by ensuring integrity of physical components and responding to integrity failures. | |||
FPT_JTA_EXT.2 (sel-based) | Supports the objective through requiring Mitigates threat by enforcing access control to debug ports to be disabled. | |||
FPT_PHP.1 (sel-based/objective) | Supports the objective through passive detection of Mitigates threat by passively detecting physical tampering. | |||
FPT_PHP.2 (sel-based/objective) | Supports the objective through detection and reporting of Mitigates threat by providing methods to detect and report physical tampering. | |||
FPT_PHP.3 (sel-based) | Supports the objective through resistance to Mitigates threat by resisting physical tampering. | |||
T.SIDE_​CHANNEL_​LEAKAGE | FPT_TUD_EXT. | |||
1 | Mitigates threat by providing a means to eliminate side-channel flaws through updates. | |||
T.PERSISTENCE | FPT_ROT_EXT.1 | Mitigates threat by providing platform integrity to prevent intrusion of a persistent presence on the platform. | ||
FPT_TUDRVR_EXT.31 (sel-based) | Supports the objective through specifying a firmware update mechanism with delayed authentication. | FPT_TUDMitigates threat with firmware recovery mechanism in case of failure. | ||
FCS_STG_EXT.42 (sel-based) | Supports the objective through specifying a secure local firmware update mechanism. | O.ATTACK_DETECTION_AND_RESPONSE
| FPT_ROT_EXT.2 | |
Mitigates threat by enforcing access control on key data to prevent its unauthorized disclosure. | ||||
T.UPDATE_​COMPROMISE | FPT_PPF_EXT.1 | Mitigates threat by using the official update process to be the only method to modify platform firmware. | ||
FPT_STMROT_EXT.1 | Supports the objective by ensuring that audit events are marked with reliable time stamps. | |||
FAU_GEN.1 (sel-based) | Supports the objective by requiring reporting of security-related audit events. | |||
FAU_SAR.1 2 | Mitigates threat by providing a means to attest the validity of updates. | |||
FCS_COP.1/Hash (sel-based) | Supports the objective by requiring that audit events be readable by an Administrator. | FAU_STG.1 Mitigates threat by providing a means to validate the integrity of an update using a hash. | ||
FCS_COP.1/SigVer (sel-based) | Supports the objective by requiring that audit records be protected from unauthorized deletion. | |||
FAU_STG.4 (sel-based) | Supports the objective by requiring that audit records be protected from automatic deletion. | |||
FAU_STG_EXT.1 Mitigates threat by providing a means to validate the integrity of an update using a hash. | ||||
FPT_TUD_EXT.2 (sel-based) | Supports the objective by requiring that audit records be off-loaded to an external IT entityMitigates threat by using a digital signature mechanism to verify the integrity of updates and a rollback protection mechanism to prevent application of an unauthorized update. | |||
FPT_PHPTUD_EXT.13 (sel-based) | Supports the objective through passive detection of physical tamperingMitigates threat by using the TOE's root of trust to validate the authenticity and integrity of an update when it is applied. | |||
FPT_PHPTUD_EXT.34 (sel-based) | Supports the objective through resistance to physical tampering. | O.MITIGATE_FUNDAMENTAL_FLAWS
|
||
Mitigates threat through an update mechanism that requires physical access to the TOE to use. | ||||
T.SECURITY_​FUNCTIONALITY_​FAILURE | FCS_STG_EXT.1 | Supports the objective through requiring that a TOE be either updateable or immutable. | ||
(optional) | Mitigates threat by generating keys/secrets and storing them in a secure manner, as well as destroying them on request. | |||
FCS_CKM.6 (sel-based) | Supports the objective through specifying an authenticated firmware update mechanism. | FPT_TUD_EXT.3 Mitigates threat by using appropriate key destruction methods to protect the confidentiality of credential data. | ||
FCS_COP.1/SigGen (sel-based) | Supports the objective through specifying a firmware update mechanism with delayed authentication. | FPT_TUD_EXT.4 Mitigates threat by generating digital signatures with strong encryption. | ||
FCS_COP.1/SKC (sel-based) | Supports the objective through specifying a secure local firmware update mechanism. | |||
O.PROTECTED_FIRMWARE
| FPT_ROT_EXT.1 | Supports the objective by ensuring that platform integrity is rooted in a trust anchor. | ||
FPT_PPF_EXT.1 | Supports the objective by requiring that platform firmware be modifiable only through the update process. | |||
FPT_TUD_EXT.1 | Supports the objective through requiring that a TOE be either updateable or immutable. | |||
FPT_ROT_EXT.2 Mitigates threat by establishing strong symmetric-key cryptography. | ||||
FPT_FLS.1 (sel-based) | Mitigates threat by ensuring a DRBG self-test failure causes the TOE to enter an error state where it cannot perform secure functions using that DRBG. | |||
FDP_ITC_EXT.1 (sel-based) | Supports the objective by detecting integrity failures in platform firmware. | FPT_RVR_EXTMitigates threat by importing keys and credentials in a secure fashion. | ||
FCS_RBG.1 (sel-based) | Supports the objective by specifying a means for recovery from a boot firmware failure. | FPT_TUD_EXTMitigates threat by performing random-bit generation with sufficient complexity. | ||
FCS_RBG.2 (sel-based) | Supports the objective through specifying an authenticated firmware update mechanism. | FPT_TUD_EXTMitigates threat by using an external seed source to ensure sufficiently strong random-bit generation. | ||
FCS_RBG.3 (sel-based) | Supports the objective through specifying a firmware update mechanism with delayed authentication. | FPT_TUD_EXTMitigates threat by using an internal seed source to ensure sufficiently strong random-bit generation. | ||
FCS_RBG.4 (sel-based) | Supports the objective through specifying a secure local firmware update mechanism. | |||
O.UPDATE_INTEGRITY
| FPT_PPF_EXT.1 | Supports the objective by requiring that platform firmware be modifiable only through the update process. | ||
FPT_ROT_EXT.2 | Supports the objective by validating the integrity of platform firmware prior to execution. | |||
FPT_TUD_EXT.1 | Supports the objective through requiring that a TOE be either updateable or immutable. | |||
FPT_TUD_EXT.2 (sel-based) | Supports the objective through specifying an authenticated firmware update mechanism. | |||
FPT_TUD_EXT.3 (sel-based) | Supports the objective through specifying a firmware update mechanism with delayed authentication. | |||
FPT_TUD_EXT.4 (sel-based) | Supports the objective through specifying a secure local firmware update mechanism. | O.STRONG_CRYPTOGRAPHY
|
||
Mitigates threat by using multiple internal seed sources to ensure sufficiently strong random-bit generation. | ||||
FCS_RBG.5 (sel-based) | Mitigates threat by ensuring that each noise source's random data is combined to ensure strong entropy when multiple sources are used. | |||
FPT_TST.1 (sel-based) | Mitigates threat by using self-tests to ensure correct operation of the DRBG. | |||
T.TENANT_​BASED_​ATTACK | FPT_STM.1 | Mitigates threat by ensuring that audit data indicating a potential attack is accurately timestamped. | ||
FCS_RBG.6 (optional) | Mitigates threat by providing a well-defined interface by which tenant software can access the TSF to obtain random data. | |||
FCS_SLT_EXT.1 (optional) | Mitigates threat by using salts to increase the effectiveness of cryptographic functions used to protect against attack. | |||
FDP_TEE_EXT.1 (optional) | ||||
Mitigates threat by establishing a trusted execution environment for tenant software to use. | ||||
FCS_CKM.1/AKAKG (sel-based/optional) | Supports the objective by specifying the requirements for generating asymmetric keysMitigates threat by generating strong cryptographic asymmetric keys to protect stored data. | |||
FCS_CKM.1/SKSKG (sel-based/optional) | Supports the objective by specifying the requirements for generating symmetric keysMitigates threat by generating strong cryptographic symmetric keys to protect stored data. | |||
FCS_CKM.26 (sel-based/optional) | Supports the objective by specifying the requirements for cryptographic key establishmentMitigates threat by implementing key destruction to prevent the disclosure of keys used to protect stored data. | |||
FCS_CKM_EXT.5 (sel-based/optional) | Supports the objective by specifying the requirements for cryptographic key derivationMitigates threat by utilizing strong algorithms to derive keys that protect stored data. | |||
FCS_COP.1/Hash (sel-based/optional) | Supports the objective by specifying the requirements for cryptographic hashingMitigates threat by implementing hash functions used for trusted communications. | |||
FCS_COP.1/KATKeyedHash (sel-based/optional) | Supports the objective by specifying the requirements for key agreement and transportMitigates threat by implementing MAC functions used for trusted communications. | |||
FCS_COP.1/KeyedHashSigGen (sel-based/optional) | Supports the objective by specifying the requirements for keyed hashesMitigates threat by implementing signature generation functions used for protected storage. | |||
FCS_COP.1/SigGenSigVer (sel-based/optional) | Supports the objective by specifying the requirements for digital signature generationMitigates threat by implementing signature verification functions used for protected storage. | |||
FCS_COP.1/SigVerSKC (sel-based/optional) | Supports the objective by specifying the requirements for digital signature verification. | FCS_COP.1/SKC Mitigates threat by implementing symmetric encryption functions used for protected storage. | ||
FAU_GEN.1 (sel-based/optional) | Supports the objective by specifying the requirements for symmetric-key cryptography. | FCS_RBG_EXTMitigates threat by generating audit records that could provide evidence of attack or misuse. | ||
FAU_SAR.1 (sel-based/optional) | Supports the objective by specifying the requirements for random-bit generation services. | |||
O.SECURITY_FUNCTIONALITY_INTEGRITY
| FPT_PPF_EXT.1 | Supports the objective by requiring that platform firmware be modifiable only through the update process. | ||
FCS_STG_EXT.1 (optional) | Supports the objective by specifying the types of credential storage supported by the TOE. | |||
FCS_CKM.4 Mitigates threat by recording audit data in a manner that could be interpreted to discover evidence of attack. | ||||
FAU_STG.1 (sel-based) | Mitigates threat by using an external server to preserve audit data that may provide evidence of an attack. | |||
FAU_STG.2 (sel-based) | Mitigates threat by preventing audit records indicating a potential attack from being destroyed. | |||
FAU_STG.5 (sel-based) | Supports the objective by specifying the requirements for credential and key destructionMitigates threat by ensuring that exhaustion of audit storage does not prevent audit data indicating a potential attack from being generated. | |||
FCS_CKMSTG_EXT.42 (sel-based) | Supports the objective by specifying the timing for credential and key destructionMitigates threat by using cryptography to protect the confidentiality of key data from outside access. | |||
FCS_STG_EXT.23 (sel-based) | Supports the objective by specifying the types of material that must be encrypted for storageMitigates threat by using cryptography to protect the integrity of key data from outside modification. | |||
T.NETWORK_​BASED_​ATTACK | FPT_STM.1 | Mitigates threat by ensuring that audit data indicating a potential attack is accurately timestamped. | ||
FCS_STGSLT_EXT.3 (1 (optional) | Mitigates threat by using salts to increase the effectiveness of cryptographic functions used to protect against attack. | |||
FCS_CKM.1/AKG (sel-based) | Supports the objective by specifying the encryption requirements for credential storage. | FDP_ITC_EXT.1 Mitigates threat by generating strong cryptographic asymmetric keys to protect data in transit. | ||
FCS_CKM.1/SKG (sel-based) | Supports the objective by specifying the requirements for import of keys and credentials. | |||
O.TENANT_SECURITY
| FCS_ENT_EXT.1 (optional) | Supports the objective by requiring that the TOE provide entropy to tenant software. | ||
FCS_STG_EXT.1 (optional) | Supports the objective by specifying the types of credential storage supported by the TOE. | |||
FDP_TEE_EXT.1 (optional) | Supports the objective by specifying the requirements for a trusted execution environment. | |||
FCS_STG_EXT.2 Mitigates threat by generating strong cryptographic symmetric keys to protect data in transit. | ||||
FCS_CKM.2 (sel-based) | Mitigates threat by implementing key establishment to negotiate trusted channels to protect data in transit. | |||
FCS_CKM.6 (sel-based) | Mitigates threat by implementing key destruction to prevent the compromise of trusted channels. | |||
FCS_COP.1/Hash (sel-based) | Mitigates threat by implementing hash functions used for trusted communications. | |||
FCS_COP.1/KAT (sel-based) | Supports the objective by specifying the types of material that must be encrypted for storageMitigates threat by implementing key agreement and transport functions used for trusted communications. | |||
FCS_STG_EXT.3COP.1/KeyedHash (sel-based) | Supports the objective by specifying the encryption requirements for credential storage. | FDP_ITC_EXT.1 Mitigates threat by implementing MAC functions used for trusted communications. | ||
FCS_COP.1/SigGen (sel-based) | Supports the objective by specifying the requirements for import of keys and credentials. | O.TRUSTED_CHANNELS
|
||
Mitigates threat by implementing signature generation functions used for trusted communications. | ||||
FCS_COP.1/SigVer (sel-based) | ||||
Mitigates threat by implementing signature verification functions used for trusted communications. | ||||
FCS_IPSEC_EXTCOP.1/SKC (sel-based) | Supports the objective by specifying requirements for the IPSec protocol. | FIA_X509_Mitigates threat by implementing symmetric encryption functions used for trusted communications. | ||
FAU_GEN.1 (sel-based) | Mitigates threat by generating audit records that could provide evidence of attack or misuse. | |||
FCS_HTTPS_EXT.1 (sel-based) | Supports the objective by specifying how X.509 certificate validation is performed. | FIA_X509_EXT.2 Mitigates threat by implementing HTTPS as a means to protect data in transit. | ||
FCS_IPSEC_EXT.1 (sel-based) | Supports the objective by specifying how X.509 certificate authentication is performed.Mitigates threat by implementing IPsec as a means to protect data in transit. | |||
FTP_ITC_EXT.1 (sel-based) | Supports the objective by specifying allowable trusted channel Mitigates threat by ensuring that sensitive data in transit uses trusted protocols. | |||
FTP_ITE_EXT.1 (sel-based) | Supports the objective by specifying requirements for moving data through untrusted channelsMitigates threat by ensuring that sensitive data transmitted over untrusted channels is encrypted prior to transit. | |||
FTP_ITP_EXT.1 (sel-based) | Supports the objective by allowing physically protected communications channels. | FTP_TRPMitigates threat by using a physically protected channel to protect data in transit. | ||
FAU_SAR.1 (sel-based) | Supports the objective by specifying allowable uses for trusted channels. | |||
O.CONFIGURATION_INTEGRITY
| FMT_CFG_EXT.1 | Supports the objective by requiring that default Administrator credentials be changed. | ||
FIA_UIA_EXTMitigates threat by recording audit data in a manner that could be interpreted to discover evidence of attack. | ||||
FAU_STG.1 (sel-based) | Supports the objective by requiring Administrators be authenticated before making changes. | FMT_MOF_EXT.1 Mitigates threat by using an external server to preserve audit data that may provide evidence of an attack. | ||
FAU_STG.2 (sel-based) | Supports the objective by specifying that management functions be performed by Administrators. | FMT_SMF.1 Mitigates threat by preventing audit records indicating a potential attack from being destroyed. | ||
FAU_STG.5 (sel-based) | Supports the objective by specifying the management functions implemented by the TOE. | FMT_SMRMitigates threat by ensuring that exhaustion of audit storage does not prevent audit data indicating a potential attack from being generated. | ||
FTP_TRP.1 (sel-based) | Supports the objective by defining the roles of Administrator and User. | |||
Mitigates threat by ensuring that remote administration only uses trusted channels. | ||||
T.UNAUTHORIZED_​RECONFIGURATION | FMT_CFG_EXT.1 | Supports the objective by requiring that default Administrator credentials be changed. | ||
FIA_TRT_EXT.1 (optional) | Supports the objective by limiting the number of automated authentication attempts. | |||
FIA_AFL_EXT.1 (sel-based) | Supports the objective by requiring that Administrators be authenticated. | |||
Mitigates threat by preventing knowledge of a default credential from being used to access the TSF without authorization. | ||||
FMT_MOF.1 | Mitigates threat by permitting management functions to be used only by authorized users. | |||
FMT_SMF.1 | Mitigates threat by specifying the management functions implemented by the TSF. | |||
FMT_SMR.1 | Mitigates threat by defining the management roles which can be used to grant access to management functions. | |||
FIA_UIA_EXT.1 (sel-based) | Supports the objective by specifying password complexity requirements. | |||
FIA_UAU.5 (sel-based) | Supports the objective by specifying supported authentication mechanisms. | |||
FIA_UAU.7 (sel-based) | Supports the objective by requiring that authentication factor feedback be suppressed. | |||
FIA_UIAMitigates threat by preventing the TSF from being modified by an unauthenticated subject. | ||||
T.UNAUTHORIZED_​PLATFORM_​ADMINISTRATOR | FPT_STM.1 | Mitigates threat by ensuring that time-based authentication throttling or lockout is accurately enforced. | ||
FIA_TRT_EXT.1 (sel-basedoptional) | Supports the objective by requiring Administrators be authenticated before making changesMitigates threat by throttling authentication to prevent access via brute force. | |||
FIA_X509AFL_EXT.1 (sel-based) | Supports the objective by specifying how X.509 certificate validation is performed.Mitigates threat by limiting further authentication attempts once a failure threshold of a critical authentication mechanism has been reached. | |||
FIA_X509PMG_EXT.2 (sel-based) | Supports the objective by specifying how X.509 certificate authentication is performed. | FMT_MOF_EXT.1 (sel-based) | Supports the objective by specifying that management functions be performed by Administrators. | FMT_SMF.1 Mitigates threat by enforcing password complexity requirements to prevent credentials from being easily guessed. |
FIA_UAU.5 (sel-based) | Supports the objective by specifying the management functions implemented by the TOE. | FMT_SMR.1 Mitigates threat by implementing multiple authentication mechanisms for accessing the TSF. | ||
FIA_UAU.7 (sel-based) | Supports the objective by defining the roles of Administrator and UserMitigates threat by preventing disclosure of authentication data during authentication attempts. |
Requirement | Auditable Events | Additional Audit Record Contents |
---|---|---|
FCS_CKM_EXT.5 | ||
No events specified |
N/A | |
FCS_ |
CKM_EXT. |
8 |
No events specified |
N/A | |
FCS_SLT_EXT.1 | |
No events specified |
N/A | |
FCS_STG_EXT.1 | |
No events specified |
N/A | |
FDP_TEE_EXT.1 | |
No events specified |
N/A | |
FIA_TRT_EXT.1 | |
Authentication throttling triggered. | None. |
The evaluator shall invoke the entropy source(s) from tenant software. The evaluator shall verify that the tenant acquires values from the interface.
Table 6: Choices The following table provides the recommended choices for completion of the assignment selection operations in of FCS_CKM_EXT.5.
Identifier | |||||
---|---|---|---|---|---|
Key type | Input parameters | Key derivation algorithm | Cryptographic key Key sizes | List of standards | |
KDF-CTR | [selection: Direct Generation from a Random Bit Generator as specified in FCS_RBG_EXT.1, Concatenated keys] | KPF2 - KDF in Counter Mode using [selection: AES-128-CMAC, AES-192-CMAC, AES-256-CMAC, Camillia-128-CMAC, Camillia-192-CMAC, Camillia-AES256-192CMAC, CMAC-AES-256, HIGHT-128, CMAC-LEA-128, CMAC-LEA-256, CMAC-SEED-128, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-512] as the PRF | [selection: 128, 192, 256, 512] bitsNIST | SP 800-108 sec. 5.1 (KDF in Counter Mode)
[selection: ISO/IEC 9797 11770-16:2011 (CMAC)2016 (Subclause 7.3.2) [KPF2], NIST SP 800-38B (CMAC), ISO/IEC 18033-3:2010 (AES), ISO/IEC 9797-2:2011 (HMAC), FIPS PUB 198-1 (HMAC), ISO/IEC 10118-3:2018 (SHA), FIPS PUB 180-4 (SHA)]108 Revision 1 Update 1 (Section 4.1) [KDF in Counter Mode]] |
|
KDF-FB | [selection: Direct Generation from a Random Bit Generator as specified in FCS_RBG_EXT.1, Concatenated keys] | KPF3 - KDF in Feedback Mode using [selection: AES-128-CMAC, AES-192-CMAC, AES-256-CMAC, Camillia-128-CMAC, Camillia-192-CMAC, Camillia-AES256-192CMAC, CMAC-AES-256, HIGHT-128, CMAC-LEA-128, CMAC-LEA-256, CMAC-SEED-128, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-512] as the PRF | [selection: 128, 192, 256, 512] bitsNIST | SP 800-108 sec 5.2 (KDF in Feedback Mode)
[selection: ISO/IEC 9797 11770-16:2011 (CMAC)2016 (Subclause 7.3.3) [KPF3], NIST SP 800-38B (CMAC), ISO/IEC 18033-3:2010 (AES), ISO/IEC 9797-2:2011 (HMAC), FIPS PUB 198-1 (HMAC), ISO/IEC 10118-3:2018 (SHA), FIPS PUB 180-4 (SHA)]108 Revision 1 Update 1 (Section 4.2) [KDF in Feedback Mode]] |
|
KDF-DPI | [selection: Direct Generation from a Random Bit Generator as specified in FCS_RBG_EXT.1, Concatenated keys] | KDF in Double Pipeline Iteration Mode using [selection: AES-128-CMAC, AES-192-CMAC, AES-256-CMAC, Camillia-128-CMAC, Camillia-192-CMAC, Camillia-AES256-192CMAC, CMAC-AES-256, HIGHT-128, CMAC-LEA-128, CMAC-LEA-256, CMAC-SEED-128, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-512] as the PRF | [selection: 128, 192, 256, 512]bitsNIST | SP 800-108 sec. 5.3 (KDF in n Double Pipeline Iteration Mode)
[selection: ISO/IEC 9797 11770-16:2011 (CMAC)2016 (Subclause 7.3.4) [KPF4], NIST SP 800-38B (CMAC), ISO/IEC 18033-3:2010 (AES), ISO/IEC 9797-2:2011 (HMAC), FIPS PUB 198-1 (HMAC), ISO/IEC 10118-3:2018 (SHA), FIPS PUB 180-4 (SHA)]108 Revision 1 Update 1 (Section 4.3) [KDF in Double-Pipeline Iteration Mode]] |
|
KDF-XOR | Intermediary keys | [selection: More than one intermediary key | exclusive OR (XOR), SHA-256, SHA-512] | [selection: 128, 192, 256, 512] bits[selection: ISO/IEC 10118-3:2018 (SHA), FIPS PUB 180-4 (SHA)] | N/A |
KDF-ENC | Two keys | Encryption Encrypting using an algorithm specified in [selection: AES-CCM, AES-GCM, AES-CBC, AES-KWP, AES-KW FCS_COP.1/SKC, FCS_COP.1/AEAD] | [selection: 128, 192, 256, 512] bits[selection: ISO/IEC 18033-3:2010 (subclause 5.2) (AES), FIPS PUB 197 (AES), ISO/IEC 10116:2017 (clause 7) (CBC), NIST SP 800-38A sec. 6.2 (CBC), ISO/IEC 19772:2009 (clause 8) (CCM), NIST SP 800-38C (CCM), ISO/IEC 19772:2009 (clause 11) (GCM), NIST SP 800-38D (GCM), IEEE Std. 1619-2007 (XTS), NIST SP 800-38E (XTS), ISO/IEC 19772:2009, clause 7 (Key wrap), NIST SP 800-38F sec. 6.2 (KW), NIST SP 800-38F sec. 6.3 (KWP)] | N/A | |
KDF-HASH | Shared secret, salt, output length, fixed information | [assignment: Hash function from FCS_COP.1/Hash] | [selection: 128, 192, 256, 512] bits | NIST SP 800-56C rev2, sec. 4Revision 2 (Section 4.1, Option 1) [One-Step Key Derivation] | |
KDF-MAC-1S | Shared secret, salt, IV, output length, fixed information | [assignment: keyed Keyed hash from FCS_COP.1/KeyedHash] | [selection: 128, 192, 256, 512] bits | NIST SP 800-56C rev2, sec. 4Revision 2 (Section 4.1, Options 2, 3) [One-Step Key Derivation] | |
KDF-PBKDFPasswordMAC-2S | Shared secret, salt, iteration countIV, output length, fixed information | MAC Step [selection: HMACAES-SHA128-1CMAC, HMACAES-SHA192-224CMAC, HMACAES-SHA-256256-CMAC, Camillia-128-CMAC, Camillia-192-CMAC, Camillia-256-CMAC, HMAC-SHA-3841, HMAC-SHA-512256, HMAC-SHA-512/224, HMAC-SHA-512/256, HMAC-SHA3-224, HMAC-SHA3-256, HMAC-SHA3-384, HMAC-SHA3-512]] as randomness extraction and; KDF Step [selection: KDF-CTR, KDF-FB, KDF-DPI] using [selection: AES-128-CMAC, AES-192-CMAC, AES-256-CMAC, Camillia-128-CMAC, Camillia-192-CMAC, Camillia-256-CMAC, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-512] as PRF. | [selection: 128, 192, 256, 512] bits | NIST SP 800-13256C Revision 2 (Section 5) [Two-Step Key Derivation] | |
KDF-KMAC | Key, context string, output length, label | [selection: KMAC128, KMAC256] | [selection: 128, 192, 256, 512] bits | NIST SP 800-108 Revision 1 Update 1 (Section 4.4 “KDF Using KMAC”) |
From catalogIn KDF-MAC-2S, if a CMAC is selected in the MAC step, then select AES-128-CMAC or Camellia-128-CMAC in the KDF step and select 128 as the output key size. If HMAC is selected in the MAC step, then select the same HMAC in the KDF.
The respective FCS_COP.1 component must be claimed for each primitive selected in key derivation algorithm.
This requirement ensures that the TOE makes available sufficient entropy to any tenant that requires it. Every entropy source need not provide high-quality entropy, but tenant software must have a means of acquiring sufficient entropy.
NIST recommends that the randomly generated portion of the salt have length of at least 128 bits and must be derived from a Random Bit Generation. Therefore FCS_OTV_EXT.1 must be claimed.
Requirement | Auditable Events | Additional Audit Record Contents |
---|---|---|
FPT_ROT_EXT.3 | ||
Detection of attempted intrusion. | None. |
This PP does not define any Implementation-Based dependent requirements.
As indicated in the introduction to this PP, the baseline requirements (those that must be performed by the TOE or its underlying platform) are contained in the body of this PP. There are additional requirements based on selections in the body of the PP: if certain selections are made, then additional requirements below must be included.
Requirement | Auditable Events | Additional Audit Record Contents |
---|---|---|
FAU_GEN.1 | ||
No events specified |
N/A | |
FAU_STG.1 |
On failure of logging function, capture record of failure and record upon restart of logging function. | None. |
FAU_STG. |
2 |
No events specified |
N/A | |
FAU_STG |
. |
5 | |
No events specified | N/A |
FCS_CKM.1/ |
AKG |
No events specified |
N/A | |
FCS_CKM.1/ |
SKG |
No events specified |
N/A | |
FCS_CKM.2 | |
No events specified |
N/A | |
FCS_CKM. |
6 |
No events specified |
N/A | |
FCS_CKM_EXT. |
7 |
No events specified |
N/A | |
FCS_COP.1/ |
AEAD |
No events specified |
N/A | |
FCS_COP.1/ |
CMAC |
No events specified |
N/A | |
FCS_COP.1/ |
Hash |
No events specified |
N/A | |
FCS_COP.1/ |
KeyedHash |
No events specified |
N/A | |
FCS_COP.1/ |
SKC |
No events specified |
N/A | |
FCS_COP.1/ |
SigGen | |
No events specified | N/A |
FCS_COP.1/SigVer | |
No events specified | N/A |
FCS_HTTPS_EXT.1 | |
Failure to establish a HTTPS Session. |
|
Establishment/Termination of a HTTPS session. | Non-TOE endpoint of connection (IP address). |
FCS_IPSEC_EXT.1 | |
Failure to establish an IPsec SA. |
|
Establishment/Termination of an IPsec SA. | Non-TOE endpoint of connection (IP address). |
FCS_RBG |
.1 | |
Failure of the randomization process | None. |
FCS_RBG.2 | |
No events specified | N/A |
FCS_RBG.3 | |
No events specified | N/A |
FCS_RBG.4 | |
No events specified | N/A |
FCS_RBG.5 | |
No events specified | N/A |
FDP_ITC_EXT.1 | |
No events specified |
N/A | |
FIA_AFL_EXT.1 | |
Failed attempt at Administrator authentication. | None. |
FIA_PMG_EXT.1 | |
No events specified |
N/A | |
FIA_UAU.5 | |
No events specified |
N/A | |
FIA_UAU.7 | |
No events specified |
N/A | |
FIA_UIA_EXT.1 | |
All use of the identification and authentication mechanism. | Provided user identity, origin of the attempt (e.g. console, remote IP address). |
FPT_ |
FLS.1 |
Failure |
of the TSF. |
None. |
FPT_JTA_EXT.2 |
No events specified |
N/A | |
FPT_PHP.1 | |
Detection of intrusion. | None. |
FPT_PHP.2 | |
Detection of intrusion. | None. |
FPT_PHP.3 | |
Detection of attempted intrusion. | None. |
FPT_RVR_EXT.1 | |
No events specified |
N/A | |
FPT_TST.1 | |
Execution of self-tests. | None. |
FPT_TUD_EXT.2 | |
[selection: Failure of update authentication/integrity check/rollback, None] |
Version numbers of the current firmware and of the attempted update. |
[selection: Failure of update operation, None] |
Version numbers of the current firmware and of the attempted update. |
[selection: Success of update operation, None] |
Version numbers of the new and old firmware images. | |
FPT_TUD_EXT.3 | |
[selection: Failure of update authentication/integrity/rollback check, None] |
Version numbers of the current firmware and of the attempted update. |
[selection: Failure of update operation, None] |
Version numbers of the current firmware and of the attempted update. |
[selection: Success of update operation, None] |
Version numbers of the new and old firmware images. | |
FPT_TUD_EXT.4 | |
No events specified |
N/A | |
FTP_ITC_EXT.1 |
Termination of the trusted channel. | User ID and remote source (IP Address) if feasible. |
Failures of the trusted |
path functions. | User ID and remote source (IP Address) if feasible. |
Initiation of the trusted |
channel. | User ID and remote source (IP Address) if feasible. |
FTP_ITE_EXT.1 | |
No events specified |
N/A | |
FTP_ITP_EXT.1 | |
No events specified |
N/A | |
FTP_TRP.1 | |
Initiation of the trusted channel. | Administrator ID and remote source (IP Address), if feasible. |
Termination of the trusted channel. | Administrator ID and remote source (IP Address), if feasible. |
Failures of the trusted path functions. | User ID and remote source (IP Address), if feasible. |
Table 9: Auditable Events for the TLS Functional Package
FCS_TLSC_EXT.1 | Failure to establish a session. | Reason for failure. |
FCS_TLSC_EXT.1 | Failure to verify presented identifier. | Presented identifier and reference identifier. |
FCS_TLSC_EXT.1 | Establishment/termination of a TLS session. | Non-TOE endpoint of connection. |
FCS_TLSS_EXT.1 | Failure to establish a session. | Reason for failure. |
FCS_DTLSC_EXT.1 | Failure of the certificate validity check. | Issuer Name and Subject Name of certificate. |
FCS_DTLSS_EXT.1 | Failure of the certificate validity check. | Issuer Name and Subject Name of certificate. |
The ST Author must select "removable media" if the TOE supports offload of audit data using removable media such as thumb drives or disks.
This component must be included in the ST if any of the following SFRs are included:
This component may also be included in the ST as if optional.
Identifier | Cryptographic key generation algorithm | Cryptographic |
---|
algorithm parameters | List of standards | |
---|---|---|
RSA | RSA | Modulus of size [selection: 2048 |
, 3072 |
FIPS PUB 186-4 sec. B.4 [key generation]
FIPS PUB 186-4 sec. B.4 [key generation]
5 (Section A.2.2)
[selection: NIST SP 800-186 (Section 3) [NIST Curves], RFC 5639 (Section 3) [Brainpool curves]] |
|||
FFC-ERB | FFC-ERB - Extra Random Bits | Static domain parameters approved for [selection:
| NIST SP 800-56A Revision 3 (Section 5.6.1.1.3) [key pair generation]
[selection: RFC 3526 [IKE groups], RFC 7919 [TLS groups]] |
FFC-RS | FFC-RS - Extra Random Bits | Static domain parameters approved for [selection:
| NIST SP 800-56A Revision 3 (Section 5.6.1.1.3) [key pair generation]
[selection: RFC 3526 [IKE groups], RFC 7919 [TLS groups]] |
EdDSA | EdDSA | Domain parameters approved for elliptic curves [selection: Edwards25519, Edwards448] | NIST FIPS PUB 186-5 (Section 6.2.1) [key-pair generation]
NIST SP 800-186 (Section 3.2.3) [Edwards Curves] |
KCDSA | KCDSA | Domain parameters generation with (L, N) = [selection: (2048, 224), (2048, 256), ( |
3072, 256)] |
FIPS PUB 186-4 sec. B.4 [key generation]
bits | ISO/IEC 14888-3:2018 (Subclause 6.3) [KCDSA] | ||
EC-KCDSA | EC-KCDSA | Elliptic Curves [selection: P-224, B-233, K-233, P-256, B-283, K-283] | ISO/IEC 14888-3:2018 (Subclause 6.7) [EC-KCDSA]
NIST SP 800-186 (Section 3) [NIST Curves] |
LMS | LMS | Private key size = [selection:
]
Winternitz parameter = [selection: 1, 2, 4, 8] Tree height = [selection: 5, 10, 15, 20, 25] | RFC 8554 [LMS]
NIST SP 800-208 [parameters] |
HSS | HSS | Private key size = [selection:
]
Winternitz parameter = [selection: 1, 2, 4, 8] Tree height = [selection: 5, 10, 15, 20, 25] Number of levels = [selection: 1, 2, 3, 4, 5, 6, 7, 8] | RFC 8554 [HSS]
NIST SP 800-208 [parameters] |
XMSS | XMSS | Private key size = [selection:
]
Tree height = [selection: 10, 16, 20] | RFC 8391 [XMSS]
NIST SP 800-208 [parameters] |
XMSS(MT) | XMSS(MT) | Private key size = [selection:
]
(Total Tree height, Number of Levels) = [selection: (20, 2), (20, 4), (40, 2), (40, 4), (40, 8), (60, 3), (60, 6), (60, 12)] | RFC 8391 [XMSS(MT)]
NIST SP 800-208 [parameters] |
ML-KEM | ML-KEM KeyGen | Parameter set = [selection: ML-KEM-512, ML-KEM-768, ML-KEM-1024] | NIST FIPS 203 (Section 7.1) |
ML-DSA | ML-DSA KeyGen | Parameter set = [selection: ML-DSA-44, ML-DSA-65, ML-DSA-87] | NIST FIPS 204 (Section 5.1) |
Also, this SFR must be included 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.
If this SFR is included in the ST, then FCS_CKM.
For Curve25519, see also, final draft NIST FIPS PUB 186-5, Oct 2019.
When generating ECC keys pairs for key agreement and if “ECDH” or “ECDH-Ed” 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” or “EC-KCDSA” are 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.
When generating EdDSA key pairs for digital signatures and if “EdDSA” is claimed in FCS_COP.1/SigGen, then “EdDSA” must be claimed here. The chosen domain parameters determine the size of the private keys and the public keys.
For LMS, HSS, XMSS, and XMSSMT, the key sizes do not represent the expected security strength. All key sizes given here correspond to an expected security strength of 128 bits, per NIST SP 800-208.
For HSS and XMSSMT the same hash or XOF function must be used at each level. Within each level, the same Winternitz parameter must be used but can be different for each level. For HSS, within each level, the same tree height must be used but can be different for each level.
RSA: RSA Key Generation
The below tests are derived from The 186-4 RSA Validation System (RSA2VS), Updated 8 July 2014, Section 6.2, from the National Institute of Standards and Technology.
The evaluator shall verify the implementation of RSA Key Generation by the TOE using the Key Generation test. This test verifies the ability of the TSF to correctly produce values for the key components including the public verification exponent e, the private prime factors p and q, the public modulus n and the calculation of the private signature exponent d.
FIPS PUB 186-4 Key Pair generation specifies 5
These tests are derived from The FIPS 186-4 Elliptic Curve Digital Signature Algorithm Validation System (ECDSA2VS), Updated 18 Mar 2014, Section 6.
ECC Key Generation Test
The evaluator shall verify the implementation of the Parameters Generation and the Key Generation for FFC by the TOE using the Parameter Generation and Key Generation test. This test verifies the ability of the TSF to correctly produce values for the field prime p, the cryptographic prime q (dividing p-1), the cryptographic group generator g, and the calculation of the private key x and public key y.
The Parameter generation specifies 2 ways (or methods) to generate the cryptographic prime q and the field prime p:
To test the cryptographic and field prime generation method for the provable primes method or the group generator g for a verifiable process, the evaluator must seed the TSF parameter generation routine with sufficient data to deterministically generate the parameter set.
For each key length supported, the evaluator shall have the TSF generate 25 parameter sets and
Curve25519: Curve25519 Key Generation
The
Note: Assuming the PKV function of the good implementation will (using little-endian order):
This component may also be included in the ST as if optional.
The following table provides the recommended choices for completion of the selection operations of FCS_CKM.1/SKG.
Identifier | Cryptographic Key Generation Algorithm | Cryptographic Key Sizes | List of standards |
---|---|---|---|
RSK | Direct Generation from a Random Bit Generator as specified in FCS_RBG |
[selection: |
123, |
256, |
512] bits | NIST SP 800-133 |
Revision 2 |
(Section 6.1)[Direct generation of symmetric keys] |
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.
If this SFR is included in the ST, then FCS_CKM.
This component may also be included in the ST as if optional.
This SFR must be included in the ST if key establishment is a service provided by the TOE to tenant software, or if key establishment is used by the TOE itself to support or implement PP-specified security functionality.
Also, this SFR must be included in the ST if FCS_IPSEC_EXT.1 is claimed, or if "Keys established according to FCS_CKM.2" is selected in FTP_ITE_EXT.1.1.
If this SFR is included in the ST, then FCS_CKM.4 must also be claimed.
The ST Author selects all key establishment schemes used for the selected cryptographic protocols.
The elliptic curves used for the key establishment scheme correlate with the curves specified in FCS_CKM.1/AK.
The selections in this SFR must be consistent with those for FCS_COP.1/KAT. Specifically:
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_PRO.1 must be claimed, which specifies the relevant list of standards.
This SFR does not apply to the public component of asymmetric key pairs or to keys that are permitted to remain stored, such as device identification keys.
In the case of volatile memory, the selection “removal of all references to the key directly followed by a request for garbage collection” is used in a situation where the TSF cannot address the specific physical memory locations holding the data to be erased and therefore relies on addressing logical addresses (which frees the relevant physical addresses holding the old data) and then requesting the platform to ensure that the data in the physical addresses is no longer available for reading (i.e. the “garbage collection” referred to in the SFR text).
The selection for destruction of data in non-volatile memory includes block erase as an option, and this option applies only to flash memory. A block erase does not require a read verify, since the mappings of logical addresses to the erased memory locations are erased as well as the data itself.
Some selections allow assignment of “some value that does not contain any CSP.” This means that the TOE uses some specified data not drawn from an RBG meeting FCS_RBG
From crypto catalogIn the case of volatile memory, the selection “removal of all references to the key directly followed by a request for garbage collection” is used in a situation where the TSF cannot address the specific physical memory locations holding the data to be erased and therefore relies on addressing logical addresses (which frees the relevant physical addresses holding the old data) and then requesting the platform to ensure that the data in the physical addresses is no longer available for reading (i.e. the “garbage collection” referred to in the SFR text).
The selection for destruction of data in non-volatile memory includes block erase as an option, and this option applies only to flash memory. A block erase does not require a read verify, since the mappings of logical addresses to the erased memory locations are erased, as well as the data itself.
Some selections allow the assignment of “some value that does not contain any CSP.” This means that the TOE uses some specified data not drawn from an RBG meeting FCS_RBG requirements, and not being any of the values listed as other selection options. The point of the phrase “does not contain any CSP” is to ensure that the overwritten data is carefully selected, and not taken from a general pool that might contain data that itself requires confidentiality protection.
This component
may also be included in the ST
as if optional.
The following table provides the recommended choices for completion of the selection operations of FCS_CKM_EXT.7.
Identifier | Cryptographic algorithm | Cryptographic parameters | List of standards |
---|---|---|---|
KAS2 | RSA | Modulus size [selection: 2048, 3072, 4096, 6144, 8192] bits | NIST SP 800-56B Revision 2 (Section 8.3) [KAS2] |
DH | Finite Field Cryptography Diffie-Hellman | Static domain parameters approved for [selection:
| NIST SP 800-56A Revision 3 (Section 5.7.1.1) [DH]
[selection: RFC 3526 [IKE groups], RFC 7919 [TLS groups]] |
ECDH | Elliptic Curve Diffie-Hellman | Elliptic Curve [selection: P-256, brainpoolP256r1, P-384, brainpoolP384r1, P-521, brainpoolP512r1] | NIST SP 800-56A Revision 3 (Section 5.7.1.2) [ECDH]
[selection: : NIST SP 800-186 (Section 3.2.1) [NIST Curves], RFC 5639 (Section 3) [Brainpool curves]] |
ECDH-Ed | ECDH with Montgomery Curves | Domain parameters approved for elliptic curves [selection: curve25519, curve448] | RFC 7748 (Section 5) [ECDH-Ed]
NIST SP 800-186 (Section 3.2.2) [Montgomery Curves] |
The TOE will have mechanisms to destroy keys and key material when the keys and key material is no longer needed. Based on their implementations, vendors will explain when certain keys are no longer needed. Evaluation Activities
The evaluator shall verify that the KMD includes a key lifecycle that includes a description where key materials reside, how the key materials are used, how it is determined that keys and key material are no longer needed, and how the material is destroyed once it is no longer needed. The evaluator shall also verify that all key destruction operations are performed in a manner specified by FCS_CKM.4.
If this SFR is included in the ST, then FCS_CKM.6 must also be claimed.
This SFR has dependencies FCS_COP.1/Hash and FCS_COP.1/XOF only is ML-KEM is selected.
This component must be included in the ST if any of the following SFRs are included:
This component may also be included in the ST as if optional.
The following table provides the recommended choices for completion of the selection operations of FCS_COP.1/AEAD.
Identifier | Cryptographic algorithm | Cryptographic key sizes | List of standards |
---|---|---|---|
AES-CCM | AES in CCM mode with unpredictable, non-repeating nonce, minimum size of 64 bits | [selection: 128 bits, 192 bits, 256 bits] | [selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES]
[selection: ISO/IEC 19772:2020 (Clause 7), NIST SP 800-38C] [CCM] |
AES-GCM | 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. | [selection: 128 bits, 192 bits, 256 bits] | [selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES]
[selection: ISO/IEC 19772:2020 (Clause 10), NIST SP 800-38D] [GCM] |
CAM-CCM | Camellia in CCM mode with non-repeating nonce, minimum size of 64 bits | [selection: 128 bits, 192 bits, 256 bits] | ISO/IEC 18033-3:2010 (Subclause 5.3) [Camellia]
[selection: ISO/IEC 19772:2020 (Clause 7), NIST SP 800-38C] [CCM] |
CAM-GCM | Camillia 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. | [selection: 128 bits, 192 bits, 256 bits] | ISO/IEC 18033-3:2010 (Subclause 5.3) [Camellia]
[selection: ISO/IEC 19772:2020 (Clause 10), NIST SP 800-38D] [GCM] |
SEED-CCM | SEED in CCM mode with non-repeating nonce, minimum size of 64 bits | 128 bits | ISO/IEC 18033-3:2010 (Subclause 5.4) [SEED]
[selection: ISO/IEC 19772:2020 (Clause 7), NIST SP 800-38C] [CCM] |
SEED-GCM | SEED 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. | 128 bits | ISO/IEC 18033-3:2010 (Subclause 5.4) [SEED]
[selection: ISO/IEC 19772:2020 (Clause 10), NIST SP 800-38D] [GCM] |
LEA-CCM | LEA in CCM mode with non-repeating nonce, minimum size of 64 bits | [selection: 128 bits, 192 bits, 256 bits] | ISO/IEC 29192-2:2019 (Subclause 6.3 [LEA]
[selection: ISO/IEC 19772:2020 (Clause 7), NIST SP 800-38C] [CCM] |
LEA-GCM | LEA 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. | [selection: 128 bits, 192 bits, 256 bits] | ISO/IEC 29192-2:2019 (Subclause 6.3 [LEA]
[selection: ISO/IEC 19772:2020 (Clause 10), NIST SP 800-38D] [GCM] |
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 following table provides the recommended choices for completion of the selection operations of FCS_COP.1/CMAC.
Identifier | Cryptographic algorithm | Cryptographic key sizes | List of standards |
---|---|---|---|
AEC-CMAC | AES using CMAC mode | [selection: 128 bits, 192 bits, 256 bits] | [selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES]
[selection: : ISO/IEC 9797-1:2011 Subclause 7.6, NIST SP 800-38B] [CMAC] |
CAM-CMAC | Camillia using CMAC mode | [selection: 128 bits, 192 bits, 256 bits] | ISO/IEC 18033-3:2010 Subclause 5.3 [Camellia]
[selection: : ISO/IEC 9797-1:2011 Subclause 7.6, NIST SP 800-38B] [CMAC] |
This component may also be included in the ST as if optional.
From catalogThe hash selection should be consistent with the overall strength of the algorithm used for signature generation. For example, the TOE should choose SHA-256 for 2048-bit RSA or ECC with P-256; SHA-384 for 3072-bit RSA, 4096-bit RSA, or ECC with P-384; and SHA-512 for ECC with P-521. The ST author selects the standard based on the algorithms selected.
SHA-1 may be used as a general hash function and for the following applications: generating and verifying hash-based message authentication codes (HMACs), key derivation functions (KDFs), and random bit/number generation. SHA-1 may also be used for verifying old digital signatures and time stamps, if this is explicitly allowed by the application domain. SHA-1 should not be used in applications in which collision resistance is needed.
This component may also be included in the ST as if optional.
The following table provides the recommended choices for completion of the selection operations of FCS_COP.1/KeyedHash.
Keyed Hash Algorithm | Cryptographic key sizes | List of standards |
---|---|---|
HMAC-SHA-1 | [selection: (ISO, FIPS) 160, (FIPS) 128] bits | [selection: ISO/IEC 9797-2:2021 (Section 7 “MAC Algorithm 2”), FIPS PUB 198-1] |
HMAC-SHA-224 | [selection: 224 (ISO, FIPS), 192 (FIPS), 128 (FIPS)] bits | [selection: ISO/IEC 9797-2:2021 (Section 7 “MAC Algorithm 2”), FIPS PUB 198-1] |
HMAC-SHA-256 | [selection: 256 (ISO, FIPS), 192 (FIPS), 128 (FIPS)] bits | [selection: ISO/IEC 9797-2:2021 (Section 7 “MAC Algorithm 2”), FIPS PUB 198-1] |
HMAC-SHA-384 | [selection: 384 (ISO, FIPS), 256 (FIPS), 192 (FIPS), 128 (FIPS)] bits | [selection: ISO/IEC 9797-2:2021 (Section 7 “MAC Algorithm 2”), FIPS PUB 198-1] |
HMAC-SHA-512 |
[selection: 512 (ISO, FIPS), 384 (FIPS), 256 (FIPS), 192 (FIPS), 128 (FIPS)] bits | [selection: ISO/IEC 9797-2:2021 (Section 7 “MAC Algorithm 2”), FIPS PUB 198-1] | |
KMAC128 | 128 bits | [selection: ISO/IEC 9797-2:2021 |
(Section 9 “MAC Algorithm 4”), NIST SP 800-185 (Section 4 “KMAC”)] | ||
KMAC256 | 256 bits | [selection: ISO/IEC 9797-2:2021 |
(Section 9 “MAC Algorithm 4”), NIST SP 800-185 (Section 4 “KMAC”)] | ||
KMACXOF128 | [assignment: integer 256 le Lk lt 2^2040] | [selection: ISO/IEC 9797-2:2021 (Section 9 “MAC Algorithm 4”), NIST SP 800-185 (Section 4 “KMAC”)] |
KMACXOF256 | [assignment: integer 256 le Lk lt 2^2040] | [selection: ISO/IEC 9797-2:2021 (Section 9 “MAC Algorithm 4”), NIST SP 800-185 |
(Section 4 |
“KMAC”)] |
From catalog 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.
If “KMACXOF128” or “KMACXOF256” is selected as Keyed Hash Algorithm, then FCS_COP.1/XOF must be claimed.
Identifier | Cryptographic algorithm | Cryptographic key |
---|
sizes | List of standards |
---|
RSA |
- |
PKCS | RSASSA-PKCS1-v1_5 |
Modulus of size [selection: 2048, 3072, 4096 |
] bits, hash or XOF [selection: |
SHA-256 |
, |
SHA-384 |
, SHA-512 |
Also, this SFR must be included in the TOE if FCS_CKM.2 is claimed and a key establishment scheme other than FFC is selected.
If "ECIES" is selected, then FCS_COP.1/KeyedHash and FCS_COP.1/SKC must be claimed.
If this SFR is included in the ST, then FCS_CKM.4 must also be claimed.
The evaluator shall ensure that, for each key agreement/transport scheme, the size of the derived keying material is at least the same as the intended strength of the key agreement/transport scheme, and where feasible this should be twice the intended security strength of the key agreement/transport scheme.
Table 2 of NIST SP 800-57 identifies the key strengths for the different algorithms that can be used for the various key agreement/transport schemes.
The evaluator shall verify the implementation of the key generation routines of the supported schemes using the following tests:
If ECDH-NIST or ECDH-BPC is claimed:
SP 800-56A Key Agreement Schemes
The evaluator shall verify a TOE's implementation of SP 800-56A key agreement schemes using the following Function and Validity tests. These validation tests for each key agreement scheme verify that a TOE has implemented the components of the key agreement scheme according to the specifications in the Recommendation. These components include the calculation of the DLC primitives (the shared secret value Z) and the calculation of the derived keying material (DKM) via the Key Derivation Function (KDF). If key confirmation is supported, the evaluator shall also verify that the components of key confirmation have been implemented correctly, using the test procedures described below. This includes the parsing of the DKM, the generation of MACdata and the calculation of MACtag.
Function Test
The Function test verifies the ability of the TOE to implement the key agreement schemes correctly. To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each supported key agreement scheme-key agreement role combination, KDF type, and, if supported, key confirmation role-key confirmation type combination, the tester shall generate 10 sets of test vectors. The data set consists of one set of domain parameter values (FFC) or the NIST approved curve (ECC) per 10 sets of public keys. These keys are static, ephemeral or both depending on the scheme being tested.
The evaluator shall obtain the DKM, the corresponding TOE’s public keys (static or ephemeral), the MAC tags, and any inputs used in the KDF, such as the Other Information field OI and TOE id fields.
If the TOE does not use a KDF defined in SP 800-56A, the evaluator shall obtain only the public keys and the hashed value of the shared secret.
The evaluator shall verify the correctness of the TSF’s implementation of a given scheme by using a known good implementation to calculate the shared secret value, derive the keying material DKM, and compare hashes or MAC tags generated from these values.
If key confirmation is supported, the TSF shall perform the above for each implemented approved MAC algorithm.
Validity Test
The Validity test verifies the ability of the TOE to recognize another party’s valid and invalid key agreement results with or without key confirmation. To conduct this test, the evaluator shall obtain a list of the supporting cryptographic functions included in the SP 800-56A key agreement implementation to determine which errors the TOE should be able to recognize. The evaluator generates a set of 24 (FFC) or 30 (ECC) test vectors consisting of data sets including domain parameter values or NIST approved curves, the evaluator’s public keys, the TOE’s public/private key pairs, MACTag, and any inputs used in the KDF, such as the other info and TOE id fields.
The evaluator shall inject an error in some of the test vectors to test that the TOE recognizes invalid key agreement results caused by the following fields being incorrect: the shared secret value Z, the DKM, the other information field OI, the data to be MACed, or the generated MACTag. If the TOE contains the full or partial (only ECC) public key validation, The evaluator shall also individually inject errors in both parties’ static public keys, both parties’ ephemeral public keys and the TOE’s static private key to assure the TOE detects errors in the public key validation function or the partial key validation function (in ECC only). At least two of the test vectors shall remain unmodified and therefore should result in valid key agreement results (they should pass).
The TOE shall use these modified test vectors to emulate the key agreement scheme using the corresponding parameters. The evaluator shall compare the TOE’s results with the results using a known good implementation verifying that the TOE detects these errors.
If KAS1, KAS2, KTS-OAEP, or RSAES-PKCS1-v1_5 is claimed:
SP 800-56B and PKCS#1 Key Establishment Schemes
If the TOE acts as a sender, the following evaluation activity shall be performed to ensure the proper operation of every TOE supported combination of RSA-based key establishment scheme:
To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each combination of supported key establishment scheme and its options (with or without key confirmation if supported, for each supported key confirmation MAC function if key confirmation is supported, and for each supported mask generation function if KTS-OAEP is supported), the tester shall generate 10 sets of test vectors. Each test vector shall include the RSA public key, the plaintext keying material, any additional input parameters if applicable, the MacKey and MacTag if key confirmation is incorporated, and the outputted ciphertext. For each test vector, the evaluator shall perform a key establishment encryption operation on the TOE with the same inputs (in cases where key confirmation is incorporated, the test shall use the MacKey from the test vector instead of the randomly generated MacKey used in normal operation) and ensure that the outputted ciphertext is equivalent to the ciphertext in the test vector.
If the TOE acts as a receiver, the following evaluation activities shall be performed to ensure the proper operation of every TOE supported combination of RSA-based key establishment scheme:
To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each combination of supported key establishment scheme and its options (with our without key confirmation if supported, for each supported key confirmation MAC function if key confirmation is supported, and for each supported mask generation function if KTSOAEP is supported), the tester shall generate 10 sets of test vectors. Each test vector shall include the RSA private key, the plaintext keying material (KeyData), any additional input parameters if applicable, the MacTag in cases where key confirmation is incorporated, and the outputted ciphertext. For each test vector, the evaluator shall perform the key establishment decryption operation on the TOE and ensure that the outputted plaintext keying material (KeyData) is equivalent to the plain text keying material in the test vector. In cases where key confirmation is incorporated, the evaluator shall perform the key confirmation steps and ensure that the outputted MacTag is equivalent to the MacTag in the test vector.
The evaluator shall ensure that the TSS describes how the TOE handles decryption errors. In accordance with NIST Special Publication 800-56B, the TOE must not reveal the particular error that occurred, either through the contents of any outputted or logged error message or through timing variations. If KTS-OAEP is supported, the evaluator shall create separate contrived ciphertext values that trigger each of the three decryption error checks described in NIST Special Publication 800-56B section 7.2.2.3, ensure that each decryption attempt results in an error, and ensure that any outputted or logged error message is identical for each.
DH:
The evaluator shall verify the correctness of each TSF implementation of each supported Diffie-Hellman group by comparison with a known good implementation.
Curve25519:
The evaluator shall verify a TOE's implementation of the key agreement scheme using the following Function and Validity tests. These validation tests for each key agreement scheme verify that a TOE has implemented the components of the key agreement scheme according to the specification. These components include the calculation of the shared secret K and the hash of K.
Function Test
The Function test verifies the ability of the TOE to implement the key agreement schemes correctly. To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each supported key agreement role and hash function combination, the tester shall generate 10 sets of public keys. These keys are static, ephemeral or both depending on the scheme being tested.
The evaluator shall obtain the shared secret value K, and the hash of K. The evaluator shall verify the correctness of the TSF’s implementation of a given scheme by using a known good implementation to calculate the shared secret value K and compare the hash generated from this value.
Validity Test
The Validity test verifies the ability of the TOE to recognize another party’s valid and invalid key agreement results. To conduct this test, the evaluator generates a set of 30 test vectors consisting of data sets including the evaluator’s public keys and the TOE’s public/private key pairs.
The evaluator shall inject an error in some of the test vectors to test that the TOE recognizes invalid key agreement results caused by the following fields being incorrect: the shared secret value K or the hash of K. At least two of the test vectors shall remain unmodified and therefore should result in valid key agreement results (they should pass).
The TOE shall use these modified test vectors to emulate the key agreement scheme using the corresponding parameters. The evaluator shall compare the TOE’s results with the results using a known good implementation verifying that the TOE detects these errors.
ECIES:
The evaluator shall verify the correctness of each TSF implementation of each supported use of ECIES by comparison with a known good implementation.
This component may also be included in the ST as if optional.
Identifier | Cryptographic algorithm | Cryptographic key sizes | List of standards | |||
---|---|---|---|---|---|---|
RSASSA-PKCS1 | RSASSA-PKCS1-v1_5 , SHA3-256, SHA3-384, SHA3-512] | RFC 8017 (Section 8.2) [PKCS #1 v2.2]
FIPS PUB 186-5 (Section 5.4) [RSASSA-PKCS1-v1_5] |
||||
RSA-PSS | RSASSA-PSS | Modulus of size [selection: 2048, 3072, 4096] bits, hash or XOF [selection: SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512, SHAKE128, SHAKE256] | RFC 8017 (Section 8.1) [PKCS#1 v2.2]
FIPS PUB 186-5 (Section 5.4) [RSASSA-PSS] |
|||
ECDSA | ECDSA | Elliptic Curve [selection: NIST P-256, brainpoolP256r1, NIST P-384, brainpoolP384r1, NIST P-521, brainpoolP512r1], per-message secret number generation [selection: extra random bits, rejection sampling, deterministic] and hash or XOF function using[selection: SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512][selection: 2048 bit, 3072 bit, SHAKE128, SHAKE256] | [selection: RFC 8017, PKCS #1 v2.2 (sec. 8.2 ISO/IEC 14888-3:2018 (Subclause 6.6), FIPS PUB 186-4, 5 (secSections 6. 5.5)](RSASSA-PKCS1-v1_5)3.1, 6.4.1]][ECDSA] [selection: ISO/IEC 10118-3 (cl. 10, 11) [SHA1/2], FIPS PUB 180-4 (sec. 6) [SHA1/2], FIPS PUB 202 [SHA3]] | DSS2 | Digital signature scheme 2 RFC 5639 (Section 3) [Brainpool Curves], NIST SP-800 186 (Section 4) [NIST Curves]]] | |
KCDSA | KCDSA | hash function using[selection: SHA-256224, SHA-384256, SHA-512, SHA3-256, SHA3-384, SHA3 SHA-512] | [selection: 2048 bit, 3072 bit] | ISO/IEC 9796 14888-2 (cl. 9) [Digital signature scheme 2]
[selection: ISO/IEC 10118-3 (cl. 10, 11) [SHA1/2], FIPS PUB 180-4 (sec. 6) [SHA1/2], FIPS PUB 202 [SHA3]] | DSS3 | Digital signature scheme 3 using 3:2018 (Subclause 6.3) [KCDSA] |
EC-KCDSA | EC-KCDSA | Elliptic Curve [selection: P-224, P-256, B-233, B-283, K-233, K-283] using hash [selection: SHA-256224, SHA-384256, SHA-512, SHA3-256, SHA3-384, SHA3 SHA-512] | [selection: 2048 bit, 3072 bit] | ISO/IEC 9796 14888-2 (cl. 10) [Digital signature scheme 3]
[selection: ISO/IEC 10118-3 (cl. 10, 11) [SHA1/2], FIPS PUB 180-4 (sec. 6) [SHA1/2], FIPS PUB 202 [SHA3]] |
||
RSASSA-PSS | RSASSA-PSS using [selection: SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512] | [selection: 2048 bit, 3072 bit] | RFC 8017, PKCS#1v2.2 sec. 8.1 [RSASSAPSS]
[selection: ISO/IEC 10118-3 (cl. 10, 11) [SHA1/2], FIPS PUB 180-4 (sec. 6) [SHA1/2], FIPS PUB 202 [SHA3]] |
|||
ECDSA | ECDSA on [selection: brainpoolP256r1, brainpoolP384r1, brainpoolP512r1, NIST P-256, NIST P-384, NIST P-521] using [selection: SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512] | [selection: 2048 bit, 3072 bit] | [selection:
[selection: ISO/IEC 10118-3 (cl. 10, 11) [SHA1/2], FIPS PUB 180-4 (sec. 6) [SHA1/2], FIPS PUB 202 [SHA3]] |
|||
3:2018 (Subclause 6.7) [EC-KCDSA]
NIST SP 800-186 (Section 3) [NIST Curves] |
||||||
EdDSA | Edwards-Curve Digital Signature Algorithm | Domain parameters approved for elliptic curves [selection: Edwards25519, Edwards448] | NIST FIPS PUB 186-5 (Section 7.6) [EdDSA]
RFC 8032 [Edwards Curves] |
|||
LMS | LMS | Private key size = [selection:
]
Winternitz parameter = [selection: 1, 2, 4, 8] Tree height = [selection: 5, 10, 15, 20, 25] | RFC 8554 [LMS]
NIST SP 800-208 [parameters] |
|||
HSS | Multitree version of LMS | Private key size = [selection:
]
Winternitz parameter = [selection: 1, 2, 4, 8] Tree height = [selection: 5, 10, 15, 20, 25] Number of levels = [selection: 1, 2, 3, 4, 5, 6, 7, 8] | RFC 8554 [HSS]
NIST SP 800-208 [parameters] |
|||
XMSS | XMSS | Private key size = [selection:
]
Tree height = [selection: 10, 16, 20] | RFC 8391 [XMSS]
NIST SP 800-208 [parameters] |
|||
ML-DSA | ML-DSA Signature Generation | Perameter set = [selection: ML-DSA-44, ML-DSA-65, ML-DSA-87] | NIST FIPS 204 (Section 5.2) |
From catalogThe dependency on FCS_OTV_EXT.1 is needed only for signature schemes that require random bits, such as ECDSA, LMS, HSS, XMSS, XMSSMT, and ML-DSA.
This component may also be included in the ST as if optional.
Table 13: Choices The following table provides the recommended choices for completion of the assignments in selection operations of FCS_COP.1/SigVer.
Identifier | Cryptographic algorithm | Cryptographic key sizes | List of standards | |||||
---|---|---|---|---|---|---|---|---|
RSASSARSA-PKCS1PKCS | RSASSA-PKCS1-v1_5 using | Modulus of size [selection: 2048, 3072, 4096] bits, hash or XOF [selection: SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512] | [selection: 2048 bit, 3072 bit] | [selection: RFC 8017, RFC 8017 (Section 8.2) [PKCS #1 v2.2 (sec. 8.2), ]
FIPS PUB 186-4, 5 (sec Section 5.54) ] [RSASSA-PKCS1-v1_5] |
||||
RSA-PSS | RSASSA-PSS | Modulus of size [selection: ISO/IEC 10118-3 (cl. 10, 11) [SHA1/2], FIPS PUB 180-4 (sec. 6) [SHA1/2], FIPS PUB 202 [SHA3]] | DSS2 | Digital signature scheme 2 using [2048, 3072, 4096] bits, hash or XOF [selection: SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512, SHAKE128, SHAKE256] | [selection: 2048 bit, 3072 bit] | ISO/IEC 9796-2 (cl. 9) [Digital signature scheme 2]
[selection: ISO/IEC 10118-3 (cl. 10, 11) [SHA1/2], FIPS PUB 180-4 (sec. 6) [SHA1/2], FIPS PUB 202 [SHA3]] | DSS3 | Digital signature scheme 3 using RFC 8017 (Section 8.1) [PKCS#1 v2.2]
FIPS PUB 186-5 (Section 5.4) [RSASSA-PSS] |
DSA | DSA | Domain parameters for (L, N) = [selection: (2048, 224), (2048, 256), (3072, 256) ] bits | FIPS PUB 186-4 (Section 4.7) [DSA Signature Verification] | |||||
ECDSA | ECDSA | Elliptic Curve [selection: NIST P-256, brainpoolP256r1, NIST P-384, brainpoolP384r1, NIST P-521, brainpoolP512r1] using hash or XOF [selection: SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512, SHAKE128, SHAKE256] | [selection: 2048 bit, 3072 bit]ISO/IEC 9796-2, (Clause 10) (Digital signature scheme 3)
[selection: ISO/IEC 10118-3 (cl. 10, 11) [SHA1/2], FIPS PUB 180-4 (sec. 6) [SHA1/2], FIPS PUB 202 [SHA3]] | RSASSA-PSS | RSASSA-PSS 14888-3:2018 (Subclause 6.6), FIPS PUB 186-5 (Section 6.4.2)][ECDSA]
[selection: RFC 5639 (Section 3) [Brainpool Curves], NIST SP-800 186 (Section 4) [NIST Curves]] |
|||
KCDSA | KCDSA | hash function using[selection: SHA-224, SHA-256, SHA-384, SHA-512, SHA3] | ISO/IEC 14888-3:2018 (Subclause 6.3) [KCDSA] | |||||
EC-KCDSA | EC-KCDSA | Elliptic Curve [selection: P-224, P-256, SHA3B-384233, SHA3-512] B-283, K-233, K-283] using hash [selection: 2048 bit, 3072 bit] | [RFC 8017, PKCS#1v2.2 (Section 8.1)] (RSASSAPSS)
[selection: ISO/IEC 10118-3 (cl. 10, 11) [SHA1/2], FIPS PUB 180-4 (sec. 6) [SHA1/2], FIPS PUB 202 [SHA3]] | ECDSA | ECDSA on [selection: brainpoolP256r1, brainpoolP384r1, brainpoolP512r1, NIST P-256, NIST P-384, NIST P-521] using [selection: SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512] | [selection: 2048 bit, 3072 bit] | [selection:
[selection: ISO/IEC 10118-3 (cl. 10, 11) [SHA1/2], FIPS PUB 180-4 (sec. 6) [SHA1/2], FIPS PUB 202 [SHA3]]SHA-224, SHA-256, SHA-384, SHA-512] | ISO/IEC 14888-3:2018 (Subclause 6.7) [EC-KCDSA]
NIST SP 800-186 (Section 3) [NIST Curves] |
EdDSA | Edwards-Curve Digital Signature Algorithm | Domain parameters approved for elliptic curves [selection: Edwards25519, Edwards448] | NIST FIPS PUB 186-5 (Section 7.6) [EdDSA]
RFC 8032 [Edwards Curves] |
|||||
LMS | LMS | Private key size = [selection:
]
Winternitz parameter = [selection: 1, 2, 4, 8] Tree height = [selection: 5, 10, 15, 20, 25] | RFC 8554 [LMS]
NIST SP 800-208 [parameters] |
|||||
HSS | Multitree version of LMS | Private key size = [selection:
]
Winternitz parameter = [selection: 1, 2, 4, 8] Tree height = [selection: 5, 10, 15, 20, 25] Number of levels = [selection: 1, 2, 3, 4, 5, 6, 7, 8] | RFC 8554 [HSS]
NIST SP 800-208 [parameters] |
|||||
XMSS | XMSS | Private key size = [selection:
]
Tree height = [selection: 10, 16, 20] | RFC 8391 [XMSS]
NIST SP 800-208 [parameters] |
|||||
XMSS(MT) | Multitree version of XMSS | Private key size = [selection:
]
(Total Tree height, Number of Levels) = [selection: (20, 2), (20, 4), (40, 2), (40, 4), (40, 8), (60, 3), (60, 6), (60, 12)] | RFC 8391 [XMSS(MT)]
NIST SP 800-208 [parameters] |
|||||
ML-DSA | ML-DSA Signature Verification | Perameter set = [selection: ML-DSA-44, ML-DSA-65, ML-DSA-87] | NIST FIPS 204 (Section 5.3) |
From catalog 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.
This component may also be included in the ST as if optional.
Table 14: Choices The following table provides the recommended choices for completion of the assignments in selection operations of FCS_COP.1/SKC.
Identifier | Cryptographic algorithm | Cryptographic key sizes | List of standards | ||
---|---|---|---|---|---|
AES-CCMCBC | AES in CCM CBC mode with unpredictable, non-repeating nonce, minimum size of 64 bitsand unpredictable IVs | [selection: 128 bits, 192 bits, 256] bits] | [selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: ISO/IEC 19772 cl. 8 10116:2017 (Clause 7), NIST SP 800-38C 38A] [CCMCBC] | ||
XTS-AES-GCM | AES in GCM XTS mode with non-repeating IVs; IV length must be equal to 96 bits; the deterministic IV construction method (SP 800-38D, Section 8.2.1) must be used; the MAC length t must be one of the values [selection: 96, 104, 112, 120, 128] | [selection: 128 bits, 192 bits, 256 bits] | unique tweak values that are consecutive non-negative integers starting at an arbitrary non-negative integer | [selection: 256, 512] bits | [selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES]
[selection: IEEE Std. 1619-2018, NIST SP 800-38E] [XTS] |
AES-CTR | AES in Counter Mode with a non-repeating initial counter and with no repeated use of counter values across multiple messages with the same secret key | [selection: 128, 192, 256] bits | [selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: : ISO/IEC 19772 cl. 11 10116:2017 (Clause 10), NIST SP 800-38D 38A] [GCMCBC] | ||
AESCAM-CBC | AES Camellia in CBC mode with non-repeating and unpredictable IVs | [selection: 128 bits, 192 bits, 256] bits | ISO/IEC 18033-3:2010 (Subclause 5.3) [Camellia]
[selection: ISO/IEC 10116:2017 (Clause 7), NIST SP 800-38A] [CBC] |
||
CAM-CFB | Camellia in CFB mode with non-repeating and unpredictable IVs | [selection: 128, 192, 256] bits | ISO/IEC 18033-3, FIPS PUB 197 [AES]
ISO/IEC 10116:2010 (Subclause 5.3) [Camellia] [selection: ISO/IEC 10116:2017 (Clause 8), NIST SP 800-38A] [CFB] |
||
CAM-OFB | Camellia in OFB mode with unique IVs | [selection: 128, 192, 256] bits | ISO/IEC 18033-3:2010 (Subclause 5.3) [Camellia]
[selection: ISO/IEC 10116:2017 (Clause 9), NIST SP 800-38A] [CBCOFB] | AES-CTR | |
AES in counter XTS-CAM | Camellia in XTS mode with unique tweak values that are consecutive non-negative integers starting at an arbitrary non-negative integer | [selection: 256, 512] bits | ISO/IEC 18033-3:2010 (Subclause 5.3) [Camellia]
[selection: IEEE Std. 1619-2018, NIST SP 800-38E] [XTS] |
||
CAM-CTR | Camellia in CTR mode with a non-repeating initial counter and with no repeated use of counter values across multiple messages with the same secret key. | [selection: 128 bits, 192 bits, 256] bits] | ISO/IEC 18033-3, FIPS PUB 197 [AES]
:2010 (Subclause 5.3) [Camellia] [selection: ISO/IEC 10116:2017 (Clause 10), NIST SP 800-38A] [CTR] |
||
XTSSEED-AESCBC | AES SEED in XTS mode with unique [selection: consecutive non-negative integers starting at an arbitrary non-negative integer, data unit sequence numbers] tweak values | [selection: 256 bits, 512 bits] | ISO/IEC 18033-3, FIPS PUB 197 [AES]
IEEE 1619, NIST SP 800-38E [XTS] |
||
AES-KWP | KWP based on AES | [selection: 128 bits, 192 bits, 256 bits] | ISO/IEC 18033-3, FIPS PUB 197 [AES]
ISO/IEC 19772 cl. 7 [key wrap] NIST SP 800-38F sec. 6.3 [KWP] |
||
AES-KW | KW based on AES | [selection: 128 bits, 192 bits, 256 bits] | ISO/IEC 18033-3, FIPS PUB 197 [AES]
ISO/IEC 19772 cl. 7 [key wrap] NIST SP 800-38F, sec. 6.2 (KW)CBC mode with non-repeating and unpredictable IVs | 128 bits | ISO/IEC 18033-3:2010 (Subclause 5.4) [SEED]
[selection: ISO/IEC 10116:2017 (Clause 7), NIST SP 800-38A] [CBC] |
SEED-CFB | SEED in CFB mode with non-repeating and unpredictable IVs | 128 bits | ISO/IEC 18033-3:2010 (Subclause 5.4) [SEED]
[selection: ISO/IEC 10116:2017 (Clause 8), NIST SP 800-38A] [CFB] |
||
SEED-OFB | SEED in OFB mode with unique IVs | 128 bits | ISO/IEC 18033-3:2010 (Subclause 5.4) [SEED]
[selection: ISO/IEC 10116:2017 (Clause 9), NIST SP 800-38A] [OFB] |
||
SEED-CTR | SEED in CTR mode with unique, incremental counter | 128 bits | ISO/IEC 18033-3:2010 (Subclause 5.4) [SEED]
[selection: ISO/IEC 10116:2017 (Clause 10), NIST SP 800-38A] [CTR] |
||
HIGHT-CBC | HIGHT in CBC mode with non-repeating and unpredictable IVs | 128 bits | ISO/IEC 18033-3:2010 (Subclause 4.5) [HIGHT]
[selection: ISO/IEC 10116:2017 (Clause 7), NIST SP 800-38A] [CBC] |
||
HIGHT-CFB | HIGHT in CFB mode with non-repeating and unpredictable IVs | 128 bits | ISO/IEC 18033-3:2010 (Subclause 4.5) [HIGHT]
[selection: ISO/IEC 10116:2017 (Clause 8), NIST SP 800-38A] [CFB] |
||
HIGHT-OFB | HIGHT in OFB mode with unique IVs | 128 bits | ISO/IEC 18033-3:2010 (Subclause 4.5) [HIGHT]
[selection: ISO/IEC 10116:2017 (Clause 9), NIST SP 800-38A] [OFB] |
||
HIGHT-CTR | HIGHT in CTR mode with unique, incremental counter | 128 bits | ISO/IEC 18033-3:2010 (Subclause 4.5) [HIGHT]
[selection: ISO/IEC 10116:2017 (Clause 10), NIST SP 800-38A] [CTR] |
||
LEA-CBC | LEA in CBC mode with non-repeating and unpredictable IVs | [selection: 128, 192, 256] bits | ISO/IEC 29192-2:2019 (Subclause 6.3) [LEA]
[selection: ISO/IEC 10116:2017 (Clause 7), NIST SP 800-38A] [CBC] |
||
LEA-CFB | LEA in CFB mode with non-repeating and unpredictable IVs | [selection: 128, 192, 256] bits | ISO/IEC 29192-2:2019 (Subclause 6.3) [LEA]
[selection: ISO/IEC 10116:2017 (Clause 8), NIST SP 800-38A] [CFB] |
||
LEA-OFB | LEA in OFB mode with unique IVs | [selection: 128, 192, 256] bits | ISO/IEC 29192-2:2019 (Subclause 6.3) [LEA]
[selection: ISO/IEC 10116:2017 (Clause 9), NIST SP 800-38A] [OFB] |
||
LEA-CTR | LEA in CTR mode with a non-repeating initial counter and with no repeated use of counter values across multiple messages with the same secret key. | [selection: 128, 192, 256] bits | ISO/IEC 29192-2:2019 (Subclause 6.3) [LEA]
[selection: ISO/IEC 10116:2017 (Clause 10), NIST SP 800-38A] [CTR] |
If “pre-shared keys” is selected, the selection-based requirement FIA_PSK_EXT.1 must be claimed. Applicable claims from the , version are made to support X.509 validation functionality, most notably FIA_XCU_EXT.1 (mandatory requirement defining the TOE's use of certificates), FIA_X509_EXT.1 (X.509 certificate validation) and FIA_X509_EXT.2 (X.509 certificate authentication).
This component must be included in the ST if any of the following SFRs are included:
This component may also be included in the ST as if optional.
The following table provides the recommended choices for completion of the selection operations of FCS_RBG.1.
Identifier | DRBG Algorithm | List of standards |
---|---|---|
HASH_DRBG | Hash_DRBG with [selection: SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512] | [selection: ISO/IEC 18031: 2011 |
(Section C.2.2), NIST SP 800-90A Revision 1 Section 10.1.1] | ||
HMAC_DRBG | HMAC_DRBG with [selection: SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512] | [selection: ISO/IEC 18031: 2011 (Section C.2.3), NIST SP 800-90A Revision 1 Section 10.1.2] |
CTR_DRBG | CTR_DRBG with [selection: AES-128, AES-192, AES-256, CAM-128, CAM-192, CAM-256, SEED-128, HIGHT-128, LEA-128, LEA-192, LEA-256] | [selection: ISO/IEC 18031: 2011 (Section C.3.2), NIST SP800-90A Revision 1 Section 10.2.1] |
NIST SP 800-90A contains three different methods of generating random numbers; each of these, in turn, depends on underlying cryptographic primitives (hash functions/ciphers). The ST author will select the function used and include the specific underlying cryptographic primitives used in the requirement or in the TSS. While any of the identified hash functions (SHA-224, SHA-256, SHA-384, SHA-512) are allowed for Hash_DRBG or HMAC_DRBG, only AES-based implementations for CTR_DRBG are allowed.
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_SLT_EXT.1, FCS_CKM.1/Also, this SFR must be claimed if "KDF-CTR," "KDF-FB," or "KDF-DPI" is selected in FCS_CKM_EXT.5.
If "HMAC_DRBG (any)" is selected, then FCS_COP.1/KeyedHash must be claimed.
If "Hash_DRBG (any)" is selected, then FCS_COP.1/Hash must be claimed. If "CTR_DRBG (any)" is selected, then FCS_COP.1/SKC must be claimed.
this requirement, the ST
author selects "TSF noise source" if a single noise source is used as input to the DRBG. The ST author selects "multiple TSF noise sources" if a seed is formed from a combination of two or more noise sources within the TOE boundary. If the TSF implements two or more separate DRBGs that are seeded in separate manners, this SFR should be iterated for each DRBG. It multiple distinct noise sources exist such that each DRBG only uses one of them, then each iteration would select "TSF noise source"; "multiple TSF noise sources" is only selected if a single DRBG uses multiple noise sources for its seed. The ST author selects "TSF interface for seeding" if noise source data is generated outside the TOE boundary.
If "TSF noise source" is selected, FCS_RBG.3 must be claimed.
If "multiple TSF noise sources" is selected, FCS_RBG.4 and FCS_RBG.5 must be claimed.
If "TSF interface for seeding" is selected, FCS_RBG.2 must be claimed.
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 NIST SP 800-57A.
This requirement must be included in the ST if the TOE generates keys, signatures, or salts for its own use or for tenant software (FCS_CKM.1/AK, FCS_CKM.1/SK, FCS_COP.1/SigGen, FCS_SLT_EXT.1) or if it provides RNG services for tenant software (FCS_RBG_EXT.1
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).
In addition to the materials below, documentation shall be produced—and the evaluator shall perform the activities—in accordance with Appendix E - Entropy Documentation and Assessment.
The TSF interface for the purpose of seeding here is the interface used to gather entropy for initializing the seed.
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 are those sources that have some other primary function, and the noise is a byproduct of their normal operation. Examples of software-based noise sources are user or system-based events, reading the least significant bits from an event timer, etc.
Hardware-based noise sources may be stochastically modelled, in which case the amount of entropy is well understood. Software-based noise sources are usually less well understood and therefore will typically take a more conservative approach, gathering larger numbers of bits than required, then performing a compression function to derive the final output. Software-based noise sources often rely on an entropy estimator.
FCS_RBG.5 specifies the combining operation such that the combined min-entropy of all the internal sources and the estimated entropy of the external sources is greater than or equal to the desired entropy of the output of the combining operation. The output could be used as a nonce or a seed for a DRBG. The combining operation should avoid crushing the entropy of the sources such that the desired entropy of the output cannot be met.
The TSF interface(s) for seeding here is the interface used to gather entropy for initializing the seed.
This component must be included in the ST if any of the following SFRs are included:
FIA_X509_EXT.1.1 lists the rules for validating certificates. The ST Author should select whether revocation status is verified using OCSP or CRLs. FIA_X509_EXT.2 requires that certificates are used for IPsec; this use requires that the extendedKeyUsage rules are verified. Certificates may optionally be used for SSH, TLS, and HTTPS and, if implemented, must be validated to contain the corresponding extendedKeyUsage.
OCSP stapling and OCSP multi-stapling support only TLS server certificate validation. If other certificate types are validated, either OCSP or CRL must be claimed. If OCSP is not supported the EKU provision for checking the OCSP Signing purpose is met by default.
Regardless of the selection of TSF or TOE platform, the validation must result in a trusted root CA certificate in a root store managed by the platform.
OCSP responses are signed using either the certificate’s issuer’s CA certificate or an OCSP certificate issued to an OCSP responder delegated by that issuer to sign OCSP responses. A compliant TOE is able to validate OCSP responses in either case, but the OCSP signing extended key usage purpose is only required to be checked in OCSP certificates.
The evaluator shall examine the TSS to confirm that it describes the behavior of the TOE when a connection cannot be established during the validity check of a certificate used in establishing a trusted channel. If the requirement that the administrator is able to specify the default action, then the evaluator shall ensure that the operational guidance contains instructions on how this configuration action is performed.
This component must be included in the ST if any of the following SFRs are included:
This component may also be included in the ST
This SFR must also be included if FIA_X509_EXT.1 is claimed.
If "HTTPS" is selected, then FCS_HTTPS_EXT.1 must be claimed.
If "IPsec" is selected, then FCS_IPSEC_EXT.1 must be claimed.
If "TLS" is selected, then the Functional Package for Transport Layer Security must also be claimed.
If "SSH" is selected, then the Functional Package for Secure Shell (SSH) must also be claimed.
The evaluator shall examine the TSS to confirm that it describes the behavior of the TOE when a connection cannot be established during the validity check of a certificate used in establishing a trusted channel. If the requirement that the administrator is able to specify the default action, then the evaluator shall ensure that the operational guidance contains instructions on how this configuration action is performed.
as if optional.
This component may also be included in the ST as if optional, but may be mandatory in the future.
This component may also be included in the ST as if optional, but may be mandatory in the future.
This component must be included in the ST if any of the following SFRs are included:
This component may also be included in the ST as if optional.
Claims from this package 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 must be included in the ST. will be claimed. FIA_TSM_EXT.1 may also be claimed if the TSF implements its own 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.
"No authentication of the remote peer" should be selected only if the TOE is acting as a server in a non-mutual authentication configuration. .
Functional Class | Functional Components |
---|---|
Class: |
Cryptographic Support (FCS) | FCS_CKM_EXT Cryptographic Key Management
FCS_ |
HTTPS_EXT HTTPS Protocol
FCS_IPSEC_EXT IPsec Protocol FCS_ |
SLT_EXT Cryptographic Salt Generation
FCS_STG_EXT Cryptographic Key Storage |
Class: |
Identification and Authentication (FIA) | FIA_AFL_EXT Authentication Failure Handling
FIA_PMG_EXT Password Management FIA_TRT_EXT Authentication Throttling FIA_UIA_EXT Administrator Identification and Authentication |
Class: |
Protection of the TSF (FPT) | FPT_JTA_EXT Debug Port Access
FPT_PPF_EXT Protection of Platform Firmware FPT_ROT_EXT Platform Integrity FPT_RVR_EXT Platform Firmware Recovery FPT_TUD_EXT Platform Firmware Update |
Class: Security Management (FMT) | FMT_CFG_EXT Secure by Default
|
Class: Trusted Path/Channels (FTP) | FTP_ITC_EXT Trusted Channel Communications
FTP_ITE_EXT Encrypted Data Communications FTP_ITP_EXT Physically Protected Channel |
Class: |
FAU_STG_EXT.1, Off-Loading of Audit Data, specifies how audit data may be transmitted or removed from the TOE, which is not covered by any FCS_STG component.
The following actions could be considered for the management functions in FMT:
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
Hierarchical to: No other components.
Dependencies to:
FAU_GEN.1 Audit Data Generation
User Data Protection (FDP) | FDP_ITC_EXT Key Import
FDP_TEE_EXT Trusted Execution Environment |
FCS_CKM_EXT.5, Cryptographic Key Derivation, requires the TSF to perform key derivation using a defined method, which is not addressed by any other FCS_CKM component.
Hierarchical to: No other components.
Dependencies to:
FCS_CKM.4 Cryptographic Key Destruction
Hierarchical to: No other components.
Dependencies to:
[FCS_CKM.1 Cryptographic Key Generation or
FDP_ITC_EXT.1 Key/Credential Import]
Hierarchical to: No other components.
Dependencies to:
FCS_RBG_EXT.1 Cryptographic Operation (Random Bit Generation)
FCS_HTTPS_EXT.1, HTTPS Protocol, defines requirements for the implementation of the HTTPS protocol.
There are no management functions foreseen.
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
Hierarchical to: | No other components. |
Dependencies to: |
[FCS_TLSC_EXT.1 TLS Client Protocol, or FCS_TLSC_EXT.2 TLS Client Protocol with Mutual Authentication, or FCS_TLSS_EXT.1 TLS Server Protocol, or FCS_TLSS_EXT.2 TLS Server Protocol with Mutual Authentication] |
FCS_IPSEC_EXT.1, IPsec Protocol, requires that IPsec be implemented as specified manner.
The following actions could be considered for the management functions in FMT:
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
Random Bit Generation |
FIA_X509_EXT.1 X.509 Certificate Validation |
FCS_RBG_EXT.1, Random Bit Generation, requires random bit generation to be performed in accordance with selected standards and seeded by an entropy source.
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
Hierarchical to: No other components.
Dependencies to:
FCS_COP.1 Cryptographic Operation
FCS_SLT_EXT.1, Cryptographic Salt Generation, requires the TSF to generate salt values in a specified manner.
There are no management functions foreseen.
There are no audit events foreseen.
Hierarchical to: | No other components. |
Dependencies to: |
FCS_RBG |
Random Bit Generation |
FCS_STG_EXT.1, Protected Storage, requires the TSF to enforce protected storage for keys and secrets so that they cannot be accessed or destroyed without authorization.
FCS_STG_EXT.2, Key Storage Encryption, requires the TSF to ensure the confidentiality of stored data using a specified method.
FCS_STG_EXT.3, Key Integrity Protection, requires the TSF to ensure the integrity of stored data using a specified method.
The following actions could be considered for the management functions in FMT:
There are no audit events foreseen.
Hierarchical to: | No other components. |
Dependencies to: |
FCS_CKM. |
6 Timing and Event of Cryptographic Key Destruction |
There are no management functions foreseen.
There are no audit events foreseen.
Hierarchical to: | No other components. |
Dependencies to: |
FCS_COP.1 Cryptographic Operation FCS_STG_EXT.1 Protected Storage |
There are no management functions foreseen.
There are no audit events foreseen.
Hierarchical to: | No other components. |
Dependencies to: |
FCS_COP.1 Cryptographic Operation |
FDP_ITC_EXT.1, Key/Credential Import, requires the TSF to implement one or more means for importing keys and credentials into the TOE, which are not addressed by the FDP_ITC component.
Hierarchical to: No other components.
Dependencies to:
FCS_COP.1 Cryptographic Operation
FCS_STG_EXT.1 Key Storage Encryption
FTP_ITC_EXT.1 Trusted Channel Communications
FTP_ITE_EXT.1 Encrypted Data Communications
FTP_ITP_EXT.1 Physically Protected Channel
FDP_TEE_EXT.1, Trusted Execution Environment for Tenant Software, requires the TSF to implement a trusted execution environment for the use of tenant software.
Hierarchical to: No other components.
Dependencies to: No dependencies.
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.
The following actions could be considered for the management functions in FMT:
If FAU_GEN.1 is included in the ST, then the following audit events should be considered:
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_PMG_EXT.1, Password Management, requires the TSF to support passwords with varying composition and length requirements.
The following actions could be considered for the management functions in FMT:
There are no audit events foreseen.
Hierarchical to: | No other components. |
Dependencies to: | No other components. |
FIA_TRT_EXT.1, Authentication Throttling, requires that the TSF enforce a limit on authentication attempts.
The following actions could be considered for the management functions in FMT:
The following should be considered for auditable events if FAU_GEN.1 is included in the ST:
FIA_UIA_EXT.1, Administrator Identification and Authentication, requires the TSF to ensure that all subjects attempting to perform TSF-mediated actions are identified and authenticated prior to authorizing these actions to be performed.
There are no management functions foreseen.
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
Hierarchical to: | No other components. |
Dependencies to: |
FIA_UAU.5 Multiple Authentication Mechanisms |
FIA_X509_EXT.1, X.509 Certificate Validation, defines how the TSF must validate X.509 certificates that are presented to it.
FIA_X509_EXT.2, X.509 Certificate Authentication, requires the TSF to identify the functions for which it uses X.509 certificates for authentication
The following actions could be considered for the management functions in FMT:
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
Hierarchical to: No other components.
Dependencies to:
FCS_COP.1 Cryptographic Operation
FCS_RBG_EXT.1 Cryptographic Operation (Random Bit Generation)
FPT_STM.1 Reliable Time Stamps
The following actions could be considered for the management functions in FMT:
Hierarchical to: No other components.
Dependencies to:
FIA_X509_EXT.1 X.509 Certificate Validation
FMT_CFG_EXT.1, Secure by Default Configuration, requires that default Administrator credentials be changed immediately after first use.
Hierarchical to: No other components.
Dependencies to:
FIA_UAU.1 Timing of Authentication
FMT_SMR.1 Security Roles
FPT_JTA_EXT.1, JTAG/Debug Port Access, requires that debug ports be accessible only to authorized Administrators.
FPT_JTA_EXT.2, JTAG/Debug Port Disablement, requires that debug ports be disabled.
There are no management functions foreseen.
There are no audit events foreseen.
Hierarchical to: | No other components. |
Dependencies to: | No dependencies. |
There are no management functions foreseen.
There are no audit events foreseen.
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.
FPT_ROT_EXT.3, Hardware component integrity, requires that the TOE support hardware supply chain integrity.
There are no management functions foreseen.
There are no audit events foreseen.
Hierarchical to: | No other components. |
Dependencies to: | No dependencies. |
The following actions could be considered for the management functions in FMT:
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
Hierarchical to: | No other components. |
Dependencies to: |
FPT_ROT_EXT.1 Platform Integrity Root |
The following actions could be considered for the management functions in FMT:
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
Hierarchical to: | No other components. |
Dependencies to: |
FPT_ROT_EXT.1 Platform Integrity Root |
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.
There are no management functions foreseen.
There are no audit events foreseen.
Hierarchical to: | No other components. |
Dependencies to: | No dependencies. |
FPT_RVR_EXT.1, Platform Firmware Recovery, defines mechanisms for recovering from a platform firmware integrity failure.
The following actions could be considered for the management functions in FMT:
There are no audit events foreseen.
Hierarchical to: | No other components. |
Dependencies to: |
FPT_TUD_EXT.4 Secure Local Update Mechanism |
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.
The following actions could be considered for the management functions in FMT:
There are no audit events foreseen.
Hierarchical to: | No other components. |
Dependencies to: |
FPT_TUD_EXT.2 Platform Firmware Authenticated Update Mechanism FPT_TUD_EXT.3 Platform Firmware Delayed-Authentication Update Mechanism FPT_TUD_EXT.4 Secure Local Platform Firmware Update Mechanism |
The following actions could be considered for the management functions in FMT:
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
Hierarchical to: | No other components. |
Dependencies to: |
FCS_COP.1 Cryptographic Operations |
The following actions could be considered for the management functions in FMT:
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
Hierarchical to: | No other components. |
Dependencies to: |
FPT_ROT_EXT.2 Platform Integrity Extension |
There are no management functions foreseen.
There are no audit events foreseen.
Hierarchical to: | No other components. |
Dependencies to: | No dependencies. |
FMT_CFG_EXT.1, Secure by Default Configuration, requires that default Administrator credentials be changed immediately after first use.
There are no management functions foreseen.
There are no audit events foreseen.
Hierarchical to: | No other components. |
Dependencies to: |
FIA_UAU.1 Timing of Authentication FMT_SMR.1 Security Roles |
FTP_ITC_EXT.1, Trusted Channel Communication, requires the TSF to implement one or more cryptographic protocols to secure connectivity between the TSF and various external entities.
The following actions could be considered for the management functions in FMT:
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
Hierarchical to: | No other components. |
Dependencies to: | No dependencies. |
FTP_ITE_EXT.1, Encrypted Data Communications, requires the TSF to encrypt data in the specified manner using key data that is provided to an external entity in the specified manner.
There are no management functions foreseen.
There are no audit events foreseen.
Hierarchical to: | No other components. |
Dependencies to: |
FCS_COP.1 Cryptographic Operation |
FTP_ITP_EXT.1, Physically Protected Channel, requires the TSF to use a physically protected channel for transmission of data to an external entity.
There are no management functions foreseen.
There are no audit events foreseen.
FDP_ITC_EXT.1, Key/Credential Import, requires the TSF to implement one or more means for importing keys and credentials into the TOE, which are not addressed by the FDP_ITC component.
There are no management functions foreseen.
There are no audit events foreseen.
Hierarchical to: | No other components. |
Dependencies to: |
FCS_COP.1 Cryptographic Operation FCS_STG_EXT.1 Key Storage Encryption FTP_ITC_EXT.1 Trusted Channel Communications FTP_ITE_EXT.1 Encrypted Data Communications FTP_ITP_EXT.1 Physically Protected Channel |
FDP_TEE_EXT.1, Trusted Execution Environment for Tenant Software, requires the TSF to implement a trusted execution environment for the use of tenant software.
There are no management functions foreseen.
There are no audit events foreseen.
This appendix lists requirements that should be considered satisfied by products successfully evaluated against this PP. These requirements are not featured explicitly as SFRs and should not be included in the ST. They are not included as standalone SFRs because it would increase the time, cost, and complexity of evaluation. This approach is permitted by [CC] Part 1, 8.2 3 Dependencies between components.
This information benefits systems engineering activities which call for inclusion of particular security controls. Evaluation against the PP provides evidence that these controls are present and have been evaluated.
. Table 16 26: Implicitly Satisfied RequirementsRequirement | Rationale for Satisfaction |
FIA_UAU.1 – Timing of Authentication | FMT_CFG_EXT.1 has a dependency on FIA_UAU.1 because it cannot exist unless the TOE supports an authentication mechanism. |
Factor | Same/Different | Guidance |
Product Type | Different | Products in different product classes are not equivalent. Servers, EUDs, and IoT devices are not equivalent. |
Product Vendors | Different | Products manufactured by different vendors are not equivalent. |
PP-Specified Functionality | Same | If differences between products affect only non-PP-specified functionality, then the models are equivalent. |
Different | If PP-specified security functionality is affected by the differences between products, then the products are not equivalent and must be tested separately. It is necessary to test only the functionality affected by the 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 products are fully tested separately, then there is no need to document the differences. |
Factor | Same/Different/None | Guidance |
Processor Vendors | Different | Functionality implemented through processors manufactured by different vendors is not equivalent. |
Processor/Chipset Architecture | Different | Functionality implemented through processors with different processor and chipset architectures are not equivalent. |
Firmware Versions | Same | Functionality implemented through equivalent processors by the same version of firmware is considered equivalent. |
PP-Specified Functionality | Same | For PP-specified security functionality implemented through equivalent processors and different firmware versions, the platforms are equivalent with respect to the functionality if execution of the functionality follows the same code paths on both platforms. |
PP-Specified Functionality | Different | For PP-specified security functionality implemented through equivalent processors and different firmware versions, the platforms are not equivalent with respect to the functionality if execution of the functionality follows different code paths on both platforms. |
Acronym | Meaning |
---|---|
AES | Advanced Encryption Standard |
AK | Asymmetric Key |
ANSI | American National Standards Institute |
API | Application Programming Interface |
BAF | Biometric Authentication Factor |
BMC | Baseboard Management Controller |
Base-PP | Base Protection Profile |
BMC | Baseboard Management Controller |
CC | Common Criteria |
CEM | Common Evaluation Methodology |
CMAC | Cipher-based Message Authentication Code |
CN | Common Names |
cPP | Collaborative Protection Profile |
CRL | Certificate Revocation List |
CSP | Critical Security Parameters |
CSfC | Commercial Solutions for Classified |
CSP | Critical Security Parameters |
DAR | Data-at-Rest |
DH | Diffie-Hellman Key Exchange |
DN | Distinguished Name |
DRBG | Deterministic Random Bit Generator |
DSS | Digital Signature Standard |
DTLS | Datagram Transport Layer Security |
ECDHE | Elliptic Curve Diffie-Hellman Ephemeral |
ECDSA | Elliptic Curve Digital Signature Algorithm |
ECIES | Elliptic Curve Integrated Encryption Scheme |
EP | Extended Package |
EUD | End-User Device |
FIPS | Federal Information Processing Standards |
FP | Functional Package |
FQDN | Fully Qualified Domain Name |
GPCP | General-Purpose Computing Platform |
HMAC | Hash-based Message Authentication Code |
HTTPS | Hypertext Transfer Protocol Secure |
IEC | International Electrotechnical Commission |
IEEE | Institute of Electrical and Electronics Engineers |
IoT | Internet of Things |
IP | Internet Protocol |
ISO | International Organization for Standardization |
IT | Information Technology |
ITSEF | Information Technology Security Evaluation Facility |
IoT | Internet of Things |
JTAG | Joint Test Action Group |
KDF | Key-Derivation Function |
KMAC | KECCAK Message Authentication Code |
MAC | Message Authentication Code |
MC | Management Controller |
NIST | National Institute of Standards and Technology |
OCSP | Online Certificate Status Protocol |
OE | Operational Environment |
OEM | Original Equipment Manufacturer |
OID | Object Identifier |
OMTP | Open Mobile Terminal Platform |
OS | Operating System |
PBKDF | Password-based Key-Derivation Function |
PKCS | Public Key Cryptography Standards |
PP | Protection Profile |
PP-Configuration | Protection Profile Configuration |
PP-Module | Protection Profile Module |
RBG | Random Bit Generator |
RFC | Request for Comment |
RNG | Random Number Generator |
RoT | Root of Trust |
SA | Security Association |
SAN | Subject Alternative Name |
SAR | Security Assurance Requirement |
SFR | Security Functional Requirement |
SHA | Secure Hash Algorithm |
SK | Symmetric Key |
SPD | Security Policy Database |
SSH | Secure Shell |
ST | Security Target |
SWID | Software Identification |
TEE | Trusted Execution Environment |
TLS | Transport Layer Security |
TOE | Target of Evaluation |
TSF | TOE Security Functionality |
TSFI | TSF Interface |
TSS | TOE Summary Specification |
USB | Universal Serial Bus |
VPN | Virtual Private Network |
VS | Virtualization System |
XCCDF | eXtensible Configuration Checklist Description Format |
XOR | Exclusive Or |
cPP | Collaborative Protection Profile |
Identifier | Title |
---|---|
[CC] | Common Criteria for Information Technology Security Evaluation -
General Model
|
[CEM] | Common Evaluation Methodology for Information Technology Security Evaluation -
Methodology
|
[ERR] | Errata and Interpretation for CC:2022 (Release 1) and CEM:2022 (Release 1), Version 1.1, CCMB-2024-02-002, 22 July 2024. |
[OMB] | Reporting Incidents Involving Personally Identifiable Information and Incorporating the Cost for Security in Agency Information Technology Investments, OMB M-06-19, July 12, 2006. |