collaborative Protection Profile for Dedicated Security Component
collaborative Protection Profile for Dedicated
Security Component
Version 1.0
September 10, 2020
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 2 of 140
Acknowledgments
This collaborative Protection Profile (cPP) was developed by the Dedicated Security Components
(DSC) international Technical Community with representatives from Industry, Information
Technology Security Evaluation Facilities (ITSEFs), and International Common Criteria schemes.
The organizations that directly contributed to the development of this cPP include:
Industry
Apple Inc.
Samsung Electronics Co., Ltd.
Common Criteria Test Laboratories
atsec Information Security
Det Norske Veritas and Germanischer Lloyd (DNV GL)
International Common Criteria Schemes
National Information Assurance Partnership (NIAP)
UK IT Security Evaluation and Certificate Scheme (NCSC)
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 3 of 140
1 Preface
1.1 Objectives of Document
This document presents the Common Criteria (CC) collaborative Protection Profile (cPP) to
express the Security Functional Requirements (SFRs) and Security Assurance Requirements
(SARs) for a Dedicated Security Component (DSC). The Evaluation Activities that specify the
actions an evaluator performs to determine if a product satisfies the SFRs and SARs captured
within this cPP are described in the Evaluation Activities for Dedicated Security Component cPP
Supporting Document [SD].
The DSC international Technical Community (iTC) designed the DSC cPP as a standalone PP so
that vendors may evaluate a DSC once and re-use this evidence across multiple devices that contain
identical DSCs. Vendors may also combine this cPP with a platform solution cPP for CC
consumers.
1.2 Scope of Document
The scope of the cPP within the development and evaluation process is described in the Common
Criteria for Information Technology Security Evaluation [CC]. In particular, a cPP defines the IT
security requirements of a generic type of Target of Evaluation (TOE) and specifies the functional
and assurance security measures that the ITSEF must apply to the TOE to demonstrate that it meets
the cPP’s stated requirements [CC1, Section C.1].
1.3 Intended Readership
The target audiences of this cPP are developers, CC consumers, system integrators, evaluators,
and schemes.
1.4 Related Documents
Common Criteria1
[CC1] Common Criteria for Information Technology Security Evaluation,
Part 1: Introduction and General Model,
CCMB-2017-04-001, Version 3.1 Revision 5, April 2017.
[CC2] Common Criteria for Information Technology Security Evaluation,
Part 2: Security Functional Components,
CCMB-2017-04-002, Version 3.1 Revision 5, April 2017.
1
For details see http://www.commoncriteriaportal.org/
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 4 of 140
[CC3] Common Criteria for Information Technology Security Evaluation,
Part 3: Security Assurance Components,
CCMB-2017-04-003, Version 3.1 Revision 5, April 2017.
[CEM] Common Methodology for Information Technology Security Evaluation,
Evaluation Methodology,
CCMB-2017-04-004, Version 3.1, Revision 5, April 2017.
Other Documents
[SD] Evaluation Activities for Dedicated Security Component cPP, Version 1.0,
September 10, 2020
1.5 Revision History
Version Date Description
1.0 9/10/20 Initial publication
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 5 of 140
Contents
Acknowledgments 2
1 Preface 3
1.1 Objectives of Document 3
1.2 Scope of Document 3
1.3 Intended Readership 3
1.4 Related Documents 3
1.5 Revision History 4
2 PP Introduction 12
2.1 PP Reference Identification 12
2.2 TOE Overview 12
2.2.1 Security Data Objects 13
2.2.2 Services 15
2.2.3 Roots of Trust 16
2.2.4 DSC Characteristics 16
2.3 TOE Use Cases 19
2.4 Key Reference Model 20
2.4.1 Roles 20
2.4.2 Key Usage 21
2.4.3 Sessions 22
2.4.4 Key Hierarchies 22
2.4.5 Protected Storage Locations 25
2.4.6 SDEs and SDOs 25
3 CC Conformance Claims 27
4 Security Problem Definition 28
4.1 Assets 28
4.2 Threats 28
4.3 Assumptions 30
4.4 Organizational Security Policies 30
5 Security Objectives 31
5.1 Security Objectives for the TOE 31
5.2 Security Objectives for the Operational Environment 31
5.3 Security Objectives Rationale 32
6 Security Functional Requirements 35
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 6 of 140
6.1 SFR Architecture 35
6.2 Conventions 38
6.3 Cryptographic Support 40
6.3.1 FCS_CKM.1 Cryptographic Key Generation 40
6.3.2 FCS_CKM.1/KEK Cryptographic Key Generation (Key Encryption Key) 41
6.3.3 FCS_CKM.2 Cryptographic Key Establishment 41
6.3.4 FCS_CKM.4 Cryptographic Key Destruction 42
6.3.5 FCS_CKM_EXT.4 Cryptographic Key and Key Material Destruction Timing 44
6.3.6 FCS_COP.1/Hash Cryptographic Operation (Hashing) 44
6.3.7 FCS_COP.1/HMAC Cryptographic Operation (Keyed Hash) 45
6.3.8 FCS_COP.1/KAT Cryptographic Operation (Key Agreement/Transport) 45
6.3.9 FCS_COP.1/KeyEnc Cryptographic Operation (Key Encryption) 46
6.3.10 FCS_COP.1/SigGen Cryptographic Operation (Signature Generation) 47
6.3.11 FCS_COP.1/SigVer Cryptographic Operation (Signature Verification) 49
6.3.12 FCS_COP.1/SKC Cryptographic Operation (Symmetric Key Cryptography) 50
6.3.13 FCS_RBG_EXT.1 Random Bit Generation 52
6.3.14 FCS_SLT_EXT.1 Cryptographic Salt Generation 53
6.3.15 FCS_STG_EXT.1 Protected Storage 53
6.3.16 FCS_STG_EXT.2 Key Storage Encryption 54
6.3.17 FCS_STG_EXT.3 Key Integrity Protection 54
6.4 User Data Protection 54
6.4.1 FDP_ACC.1 Subset Access Control 54
6.4.2 FDP_ACF.1 Security Attribute Based Access Control 55
6.4.3 FDP_ETC_EXT.2 Propagation of SDOs 57
6.4.4 FDP_FRS_EXT.1 Factory Reset 57
6.4.5 FDP_ITC_EXT.1 Parsing of SDEs 58
6.4.6 FDP_ITC_EXT.2 Parsing of SDOs 58
6.4.7 FDP_MFW_EXT.1 Mutable/Immutable Firmware 59
6.4.8 FDP_RIP.1 Subset Residual Information Protection 59
6.4.9 FDP_SDC_EXT.1 Confidentiality of SDEs 60
6.4.10 FDP_SDI.2 Stored Data Integrity Monitoring and Action 60
6.5 Identification and Authentication 61
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 7 of 140
6.5.1 FIA_AFL_EXT.1 Authorization Failure Handling 61
6.5.2 FIA_SOS.2 TSF Generation of Secrets 62
6.5.3 FIA_UAU.2 User Authentication before Any Action 63
6.5.4 FIA_UAU.5 Multiple Authentication Mechanisms 63
6.5.5 FIA_UAU.6 Re-Authenticating 64
6.6 Security Management 65
6.6.1 FMT_MOF_EXT.1 Management of Security Functions Behavior 65
6.6.2 FMT_MSA.1 Management of Security Attributes 65
6.6.3 FMT_MSA.3 Static Attribute Initialization 66
6.6.4 FMT_SMF.1 Specification of Management Functions 69
6.6.5 FMT_SMR.2 Restrictions on Security Roles 70
6.7 Protection of the TSF 70
6.7.1 FPT_FLS.1/FI Failure with Preservation of Secure State (Fault Injection) 70
6.7.2 FPT_MOD_EXT.1 Debug Modes 71
6.7.3 FPT_PHP.3 Resistance to Physical Attack 71
6.7.4 FPT_PRO_EXT.1 Root of Trust 71
6.7.5 FPT_ROT_EXT.1 Root of Trust Services 72
6.7.6 FPT_ROT_EXT.2 Root of Trust for Storage 72
6.7.7 FPT_RPL_EXT.1 Replay Prevention 73
6.7.8 FPT_STM.1 Reliable Time Stamps 73
6.7.9 FPT_TST.1 TSF Testing 73
6.8 Resource Utilization 74
6.8.1 FRU_FLT.1 Degraded Fault Tolerance 74
6.9 TOE Security Functional Requirements Rationale 74
7 Security Assurance Requirements 83
7.1 ASE: Security Target 84
7.2 ADV: Development 84
7.2.1 Basic Functional Specification (ADV_FSP.1) 84
7.2.2 Specification of DSC Interface for Use in Composite Evaluations 84
7.3 AGD: Guidance Documentation 85
7.3.1 Operational User Guidance (AGD_OPE.1) 85
7.3.2 Preparative Procedures (AGD_PRE.1) 85
7.4 Class ALC: Life-cycle Support 85
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 8 of 140
7.4.1 Labelling of the TOE (ALC_CMC.1) 86
7.4.2 TOE CM Coverage (ALC_CMS.1) 86
7.5 Class ATE: Tests 86
7.5.1 Independent Testing – Conformance (ATE_IND.1) 86
7.6 Class AVA: Vulnerability Assessment 86
7.6.1 Vulnerability Survey (AVA_VAN.1) 86
Appendix A: Optional Requirements 88
A.1 Cryptographic Support 88
A.1.1 FCS_ENT_EXT.1 Entropy for External IT Entities 88
A.1.2 FCS_RBG_EXT.2 External Seeding for Random Bit Generation 88
A.2 Protection of the TSF 88
A.2.1 FPT_ITT.1 Basic Internal TSF Data Transfer Protection 88
A.2.2 FPT_PRO_EXT.2 Data Integrity Measurements 88
A.2.3 FPT_ROT_EXT.3 Root of Trust for Reporting Mechanisms 89
Appendix B: Selection-Based Requirements 91
B.1 Cryptographic Support 91
B.1.1 FCS_CKM.1/AK Cryptographic Key Generation (Asymmetric Keys) 91
B.1.2 FCS_CKM.1/SK Cryptographic Key Generation (Symmetric Encryption Key) 92
B.1.3 FCS_CKM_EXT.5 Cryptographic Key Derivation 93
B.1.4 FCS_COP.1/PBKDF Cryptographic Operation (Password-Based Key Derivation Functions)96
B.2 User Data Protection 97
B.2.1 FDP_DAU.1/Prove Basic Data Authentication (for Use with The Prove Service) 97
B.2.2 FDP_FRS_EXT.2 Factory Reset Behavior 98
B.2.3 FDP_MFW_EXT.2 Basic Firmware Integrity 98
B.2.4 FDP_MFW_EXT.3 Firmware Authentication with Identity of Guarantor 99
B.3 Identification and Authentication 99
B.3.1 FIA_AFL_EXT.2 Authorization Failure Response 99
B.4 Protection of the TSF 100
B.4.1 FPT_FLS.1/FW Failure with Preservation of Secure State (Firmware) 100
B.4.2 FPT_RPL.1/Rollback Replay Detection (Rollback) 100
B.5 Trusted Path/Channels 101
B.5.1 FTP_CCMP_EXT.1 CCM Protocol 101
B.5.2 FTP_GCMP_EXT.1 GCM Protocol 101
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 9 of 140
B.5.3 FTP_ITC_EXT.1 Cryptographically Protected Communications Channels 101
B.5.4 FTP_ITE_EXT.1 Encrypted Data Communications 102
B.5.5 FTP_ITP_EXT.1 Physically Protected Channel 102
Appendix C: Extended Component Definitions 103
C.1 Class FCS: Cryptographic Support 103
C.1.1 FCS_CKM_EXT Cryptographic Key Management 103
C.1.2 FCS_ENT_EXT Entropy for External IT Entities 104
C.1.3 FCS_RBG_EXT Random Bit Generation 105
C.1.4 FCS_SLT_EXT Cryptographic Salt Generation 106
C.1.5 FCS_STG_EXT Cryptographic Key Storage 107
C.2 Class FDP: User Data Protection 108
C.2.1 FDP_ETC_EXT Export from the TOE 108
C.2.2 FDP_FRS_EXT Factory Reset 109
C.2.3 FDP_ITC_EXT Import from Outside of the TOE 110
C.2.4 FDP_MFW_EXT Mutable/Immutable Firmware 112
C.2.5 FDP_SDC_EXT Confidentiality of SDEs 113
C.3 Class FIA: Identification and Authentication 114
C.3.1 FIA_AFL_EXT Authorization Failure Handling 114
C.4 Class FMT: Security Management 115
C.4.1 FMT_MOF_EXT Management of Functions in TSF 115
C.5 Class FPT: Protection of the TSF 116
C.5.1 FPT_MOD_EXT Debug Modes 116
C.5.2 FPT_PRO_EXT Root of Trust 116
C.5.3 FPT_ROT_EXT Root of Trust Services 118
C.5.4 FPT_RPL_EXT Replay Detection 119
C.6 Class FTP: Trusted Path/Channels 120
C.6.1 FTP_CCMP_EXT CCM Protocol 120
C.6.2 FTP_GCMP_EXT GCM Protocol 121
C.6.3 FTP_ITC_EXT Inter-TSF Trusted Channel 121
C.6.4 FTP_ITE_EXT Encrypted Data Communications 122
C.6.5 FTP_ITP_EXT Physically Protected Channel 123
Appendix D: Entropy Documentation and Assessment 124
D.1 Design Description 124
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 10 of 140
D.2 Entropy Justification 124
D.3 Operating Conditions 125
D.4 Health Testing 125
Appendix E: SFR Dependencies Analysis 126
Appendix F: Glossary 132
Appendix G: Acronyms 136
Appendix H: References 139
Figures and Tables
Figure 1: Representation of the Target of Evaluation (TOE) 12
Figure 2: Example of TOE Internal Components 13
Figure 3: Composition of an SDO 13
Figure 4: Services Provided by the TOE 15
Figure 5: Example Key Hierarchy 24
Table 1: Core Security Services 16
Table 2: Security Problem Definition Mapping to Security Objectives 34
Table 3: SFR Architecture 38
Table 4: Sample Cryptographic Table 39
Table 5: Supported Methods for Key Agreement/Transport Operation 46
Table 6: Supported Methods for Key Encryption Operation 47
Table 7: Supported Methods for Signature Generation Operation 48
Table 8: Supported Methods for Signature Verification Operation 50
Table 9: Supported Methods for Symmetric Key Cryptography Operation 52
Table 10: Supported Methods for SDO Attributes 65
Table 11: Supported Methods for SDO Attributes Initialization 67
Table 12: SFR-Objective Rationale 82
Table 13: Security Assurance Requirements 84
Table 14: Supported Methods for Asymmetric Key Generation 91
Table 15: Supported Methods for Symmetric Encryption Key Generation 92
Table 16: Key Derivation Functions 95
Table 17: Extended Components Definitions 103
Table 18: SFR Dependencies Rationale for Mandatory SFRs 129
Table 19: SFR Dependencies Rationale for Optional SFRs 130
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 11 of 140
Table 20: SFR Dependencies Rationale for Selection-Based SFRs 131
Table 21: Glossary 135
Table 22: Acronyms 138
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 12 of 140
2 PP Introduction
2.1 PP Reference Identification
PP Reference: collaborative Protection Profile for Dedicated Security Component
PP Version: 1.0
PP Date: September 10, 2020
2.2 TOE Overview
The Target of Evaluation (TOE) is a Dedicated Security Component (DSC). In the context of this
cPP, a DSC is the combination of a hardware component and its controlling firmware. The
firmware should be dedicated to providing the encompassing platform with services for the
provisioning, protection, and use of Security Data Objects (SDOs), which include keys, identities,
attributes, and other types of Security Data Elements (SDEs). See Figure 1 for an example of a
TOE representation.
Figure 1: Representation of the Target of Evaluation (TOE)
The TOE should be one or more discrete and embedded hardware components that provide well-
scoped security functions that are physically inaccessible directly from the rich operating system.
The DSC TOE would consist of isolated firmware and circuitry capable of executing well-defined
commands against SDEs/SDOs in memory and across restricted interfaces.
Examples of a DSC that could claim conformance to this cPP include Secure Elements (SE),
Trusted Platform Modules (TPM), Hardware Security Modules (HSM), Trusted Execution
Environments (TEE), and Secure Enclave Processors (SEP). In some cases, vendors have already
integrated these dedicated hardware components into a System on Chip (SoC) and as such are
isolated components of a larger physical package. Figure 2 below shows a block diagram of a
typical example of a DSC TOE with all of its internal components.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 13 of 140
Figure 2: Example of TOE Internal Components
2.2.1 Security Data Objects
Figure 3: Composition of an SDO
An SDO is created by combining SDEs with some attributes. Each SDE used to create the SDO
reaches the DSC in one of the following ways:
 By parsing SDEs received via secure channels (see O.PARSE_PROTECTION).
 By generating the SDEs locally on the DSC as part of the Provisioning service.
An SDO may include one or more SDEs from one or both of these sources. In the Provisioning
step, the relevant SDEs are then bound together with a set of attributes resulting in an SDO.
Explicit binding occurs when the DSC includes one or more SDEs along with their attributes in a
formatted structure to form the SDO. An X.509 certificate is just one example of an SDO (where
the signature in the certificate provides the binding of the attributes contained). A DSC protects
the integrity of an SDO with one of the following methods:
 Hash or keyed hash (FCS_COP.1/Hash, FCS_COP.1/HMAC)
 Digital signature (FCS_COP.1/SigGen, FCS_COP.1/SigVer)
Explicit binding may also occur when the DSC wraps an SDO prior to storing it externally. Figure
3 shows an example SDO with binding data used to secure an arbitrary number of SDEs.
Implicit binding may occur by virtue of the location of SDEs within the DSC. An implicit binding
may occur for pre-installed SDEs, in which case the DSC restricts the functionality it allows with
the SDEs. It may also occur when the contents of certain protected storage locations carry with
them implicit attributes simply by existing in these locations.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 14 of 140
Vendors may pre-install keys and other material in the DSC during the manufacturing process, or
the DSC may automatically generate keys or other material upon first boot. Since the user (an
administrator or client application acting on behalf of a human user) provides no input to these
items, the cPP calls these pre-installed SDEs. Pre-installed SDEs have two distinguishing
characteristics:
 These keys may persist over a factory reset; and
 They may not be accessible to administrators.
If the SDOs have been erased (e.g. due to a tamper response), then a factory reset may not be
possible. Following an initial boot (e.g. first boot by end-user, or following a factory reset), a DSC
may generate SDEs unique to an instance of a DSC that are persisted across user sessions. These
are considered to be pre-installed SDEs.
Pre-installed SDOs (i.e., SDEs with implicit binding installed by the vendor at manufacturing time)
are typically not accessible by non-administrative users of the platform (i.e., client applications)
and are reserved for use by the DSC itself to manage its sub-components, keys, and, indirectly,
user content. Pre-installed SDOs typically have implicitly bound attributes. Since pre-installed
SDOs rarely, if ever, leave the DSC, they may have no formal structure containing attributes. That
does not mean these attributes do not exist; only that there exists no structure in which one would
find them all in one place.
The DSC may allow the modification of attributes for pre-installed SDOs. One example would be
the authorization value necessary to use the SDO. Obviously, the vendor may have a strong desire
to keep the users of the DSC from changing the SDE itself, or deleting it. They could allow
administrators to hide the SDO, but not delete it for the sake of factory resets.
Another case of implicit binding occurs when a DSC reserves a bank of user-accessible registers
with common attributes. The bank contains one or more registers, usually all of the same size.
Again, the functionality within the firmware determines the attributes especially when the function
applies only to one or more members of the bank of reserved registers. Without the benefit of a
structure with explicit attributes, the DSC relies on the firmware to enforce the policies inherent
to the attributes associated with a bank of registers; for example, the DSC firmware implicitly
binds the common attributes to the bank of registers.
An SDO held in the DSC may be exported (propagated) only if it is either in a wrapped form (i.e.
with confidentiality and integrity of the SDO protected by a cryptographic key-based operation),
or if it is transmitted over a secure channel (protecting confidentiality, integrity and optionally
authenticity of the receiving endpoint).
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 15 of 140
2.2.2 Services
Figure 4: Services Provided by the TOE
The labels in Figure 4 refer to the following:
 SDE: Security Data Element
 SDO: Security Data Object (component from SDEs and attributes)
 SDO ID: Unique identifier for an SDO
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 16 of 140
 SDO1: SDO that is modified or is a reference to original SDO
 SDO2: SDO that is bound to the DSC but stored outside of it
DSCs provide seven core security services to a platform as illustrated in Table 1.
Service Description
Parse
The DSC shall ingest pre-provisioned keys, credentials, tokens, attributes, etc. from trusted
components or services external to its boundary either across a secured channel or in a manner
that the objects are protected for use only by the DSC.
Provision
The DSC shall create SDOs from parsed or generated SDEs and attributes using binding
mechanisms to apply integrity protection to the SDEs together with their attributes.
Protect
The DSC shall manage protected storage for all SDOs. Platform users (through client
applications) can store SDOs either inside or outside the DSC boundary. A DSC shall maintain
the integrity and confidentiality (if required) of SDOs both inside the boundary and stored
outside the boundary.
Process
The DSC shall modify and use SDOs or their attributes on behalf of authorized entities. The
Process service shall coordinate with the Protect service for storage of the SDOs while not in use
and shall collaborate with the Prove service to authenticate the requesting entity and validate
their authorization for access to the SDO in the requested mode. The Process service shall
submit an SDO to the Purge service when it is no longer needed by the platform.
Prove
The DSC may attest to a remote entity that the DSC is currently in a specific state. During this
process, the DSC shall use the appropriate attributes or authentication tokens (such as nonces,
digital signatures, etc.) to enable the remote entity to verify the authenticity of the source of the
evidence.
Purge
When the platform no longer needs an SDO, the DSC shall execute a mechanism for destroying
the SDO by permanently removing it from the DSC to protect against unauthorized recovery.
Propagate
If an SDO is required by or allowed to be used by a remote peer, the DSC shall ensure that the
SDO is exported only as a protected object or is transmitted over a trusted channel.
Table 1: Core Security Services
2.2.3 Roots of Trust
This collaborative Protection Profile (cPP) assumes a DSC will contain one Root of Trust (RoT)
that is comprised of the compute engine, one set of firmware code, and pre-installed SDOs,
including a unique identity bound to the hardware. The firmware code may be immutable, or it
may be mutable but with controlled, authenticated, and authorized updates allowed. This code may
provide one or more RoT services, such as a RoT for Measurement, Verification, or Reporting.
The unique identity bound to the hardware should be immutable and third parties should be able
to authenticate the manufacturer of the Root of Trust through its unique identity (e.g., the unique
identity may be a credential signed by the manufacturer).
2.2.4 DSC Characteristics
The security functional requirements rely on the following characteristics of the DSC:
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 17 of 140
 Users
 Subjects
 Objects
 Security Attributes
 Operations
Users: The entities using the DSC will be client applications on the platform. They may be acting
as proxies for users or may have identities of their own. The DSC will not be able to distinguish
the difference; therefore, the cPP will recognize an entity known as the Client Application (CA),
as the user presenting authentication tokens and authorization values (collectively known as
authorization data) to the DSC for the purposes of identity verification and authorization to
perform operations. Section 2.4.1 discusses the concept of users in more detail. This cPP also
recognizes a special user called the administrator, which typically has access to DSC objects
normally denied to CAs (see definition of objects below).
Subjects: The following list contains the fundamental actors in the expected operational use cases
of the DSC. The first three are active actors, while the fourth is usually passive but could be active.
 S.DSC – DSC with security attribute DSC.ID, which is the identity of the DSC
 S.Admin – Admin (an authorized administrator with special privileges) security attribute
Admin.ID – See section 2.4.1 for more discussion on Admin.
 S.CA – CA (i.e. an authorized user or an application with a verifiable identity) with security
attribute CA.ID – See section 2.4.1 for more discussion on users.
 S.EPS – External Platform Storage (EPS) (e.g. transient SDE/SDO source and destination,
in the case of data imported and exported for the sole use inside the DSC). In the case of a
passive EPS, the DSC will properly protect the integrity and confidentiality of the objects
it stores and retrieves from there. In the case of an active EPS with security attribute
EPS.ID, the DSC and EPS may choose to create a secure channel through which they will
pass objects back and forth.
Objects: The following list contains objects the DSC expects to use during the expected operational
use cases.
 OB.P_SDO – Pre-provisioned SDOs (e.g. DSC.ID) with security attributes listed in the
next paragraph.
 OB.T_SDO – Transient SDOs or just SDOs (i.e. SDOs in the DSC currently, but are either
ephemeral or are normally stored external to DSC when not in use) with security attributes
listed in the next paragraphs. See sections 2.4.2, 2.4.4, and 2.4.6 for more discussion on
keys, which are the primary use cases for SDOs.
 OB.AuthData – Authorization Data (including authentication data, e.g. PINs, passwords,
tokens)
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 18 of 140
 OB.Pstate – Platform State (e.g. measurements and assertions)
 OB.FAACntr – Failed Authorization Attempt Counters
 OB.AntiReplay – Anti-replay tokens (e.g. counters, nonces, etc.)
 OB.Context – Session Context (The DSC may maintain one or more sessions with a CA
involving one or more of SDOs, Authorization Data, Platform State, Failed Authorization
Counters, and Anti-Replay Tokens. The DSC may represent internally the state of these
objects at any given time in a Session Context) – See section 2.4.3 for more discussion on
sessions.
Security Attributes: The following list contains the minimum security attributes for a DSC.
Individual DSCs may implement additional security attributes beyond this (whether they are
additional standalone attributes or additional attributes that are associated with SDOs); the ST
author is expected to identify these.
 DSC.ID – The DSC identifier. It may also serve as the identifier for the DSC RoT.
 CA.ID – The Client Application identifier.
 EPS.ID – The External Platform Storage (EPS) identifier. This attribute is optional for a
passive EPS (i.e. plain memory that only stores information). If the DSC uses a Client
Application to manage storage, then support for this attribute is required.
 SDO.* – The SDO Security Attributes:
o SDO.ID – SDO Identifier
o SDO.Type – SDO Type
o SDO.AuthData – SDO Reference authorization data
o SDO.Reauth – SDO re-authorization conditions
o SDO.Conf – SDO Confidential SDE list
o SDO.Export – SDO export flag
o SDO.Integrity – SDO integrity protection data
o SDO.Bind – SDO binding data
Operations: The following list contains the expected operations of a DSC.
 OP.Import (See Parse) – The DSC may receive SDOs, SDEs, Authorization Data, Platform
State, Anti-Replay Tokens or Session Contexts from the CA or the EPS. The Admin may
also give the DSC Authorization Data.
 OP.Create (See Provision) – The DSC may create SDOs, SDEs, Authorization Data,
Platform State, Anti-Replay Tokens, or Session Contexts with authorization from a CA or
Admin.
 OP.Use (See Process) – The DSC may use or perform a cryptographic operation on Pre-
Provisioned SDOs, Transient SDOs, SDEs, Authorization Data, Platform State, Anti-
Replay Tokens, or Session Contexts with Create authorization from a CA or Admin.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 19 of 140
Cryptographic operations may include encryption, decryption, hashing, signature
generation, and signature verification.
 OP.Modify (See Process) – The DSC may modify SDOs, SDEs, Authorization Data,
Platform State, Anti-Replay Tokens, or Session Contexts with authorization from a CA or
Admin.
 OP.Attest (See Prove) – The DSC may create an attestation of Platform State using an SDO
or Pre-Provisioned SDO and Anti-Replay Tokens as authorized by a CA or Admin
respectively.
 OP.Store (See Protect) – The DSC may store SDOs, SDEs, Authorization Data, Platform
State, Anti-Replay Tokens, or Session Contexts in protected storage of the DSC. See
section 2.4.5 for more discussion on protected storage.
 OP.Export (See Propagate) – The DSC may export SDOs, SDEs, Authorization Data,
Platform State, or Anti-Replay Tokens to a CA or EPS with the proper authorization from
the owner of each object. In the case of EPS, the DSC will bind the objects to the DSC in
such a way as to deny other DSCs or entities the ability to import, use, modify, attest, store,
export, or destroy them. The DSC may export Session Contexts only to an EPS binding it
in the same way as above.
 OP.Destroy (See Purge) – The DSC may purge SDOs, SDEs, Authorization Data, Platform
State, Anti-Replay Tokens, or Session Contexts in protected storage with proper
authorization from the owner of each object.
2.3 TOE Use Cases
DSCs are used in platforms to support mobile commerce, to manage platform credentials, manage
user access to sensitive resources such as enterprise data centers or entertainment content servers,
to manage and protect data-in-transit such as through secure channels or VPN tunnels, and to
manage and protect keying, authentication, and authorization material for data-at-rest solutions
such as self-encrypting drives.
For the mobile commerce use case, users, merchants, and financial institutions expect and require
that financial transactions between them and their platforms be trusted and secure. For example,
 All peers to a transaction must be able to authenticate each other.
 The integrity of the transaction must be ensured.
To support such transactions, a DSC performs the following:
 Ingests data elements and attributes and exports the data objects associated with these
transactions and the identities of the parties
 Generates data objects to use for these transactions.
 Securely stores data elements bound with their attributes within a protected hardware
boundary.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 20 of 140
 Authenticates and processes these data elements within a protected execution environment
to ensure the authenticity of the parties and the transactions.
 Establishes secure communications channels between the parties to ensure the integrity and
confidentiality of the transactions.
 Securely erases data objects when no longer needed.
 Ensures its own integrity and authenticity prior to execution.
DSCs are implemented to satisfy the following use cases:
[USE CASE 1] Protected Key Store
A platform leveraging DSCs as a hardware-secured Private Key Store facilitates the use of
secure and protected storage of secret symmetric keys and private asymmetric keys for access
to data and services. These DSCs would provide safe use of the private and secret keys inside
the protected hardware boundary.
[USE CASE 2] User / Platform Authentication to Enterprise Managed Resources
A platform leveraging DSCs for a hardware-secured ID facilitates the use of the platform as a
secure and reliable form of authentication for authorized access to highly sensitive local or
remote data and services.
[USE CASE 3] Mobile Commerce
A platform that uses DSCs facilitates secure storage and protected use of credentials for
financial transactions between trusted and authorized users, platforms, merchants and financial
institutions. These DSCs would provide safe use of the credentials inside the protected
hardware boundary. The use of certified hardware-isolated credential stores on smart platforms
and only unlocking their use with authenticated authorization provides confidence that the
transaction was indeed authorized by the approved ‘platform holder’.
2.4 Key Reference Model
The Key Reference Model abstraction draws inspiration from several different DSC products. The
products distinguish themselves from one another in the types of keys supported, how they are
protected, the types of applications supported, the number of layers of key, and the number of keys
at each layer.
The following paragraphs describe the relationships between elements of the DSC.
2.4.1 Roles
There are two main roles that come into play with any platform, including the DSC. These are
administrator and client applications. The DSC is often a component within a larger system or
platform that is referred to as a platform from this point forward. Often the platform supports
different roles as well. At times, these roles may coincide with the roles supported in the DSC,
even on purpose.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 21 of 140
The administrator may, among other things, accept responsibility for providing timely updates to
the DSC, both feature updates and security updates. It may also be responsible for managing the
pre-installed SDOs and the initial configuration of the DSC. Different administrators may have
different authorities to manage the TSF; for example, one administrator may be responsible for
controlling firmware updates while another may take an active part in managing the contents of
the DSC installed post-manufacture.
An administrator may manage the contents of the DSC, including user content. A DSC
administrator is not necessarily the owner of a given SDO. Although the DSC administrator may
possibly own one or more SDOs, not all SDOs allow a DSC administrator direct control of it. In
some cases, a DSC administrator may also be in a position to grant or deny another administrator
access to what it perceives as their content, namely the DSC’s firmware and possibly some keying
material belonging to the manufacturer. A DSC manufacturer’s choice of allowing an
administrator of the DSC this kind of latitude is a feature of its product.
The CA role may also be further divided into multiple users. CAs can include:
 An application vendor acting on its own behalf to update software on the platform.
 A content provider controlling access to its content through an application.
 A human entity using the platform who has an identity that they use to authenticate
themselves to the content provider through a CA.
 An original equipment manufacturer (OEM) that designed and manufactured a more
complex system with the DSC as a component (assuming that the DSC manufacturer and
the manufacturer of the more complex system using the DSC as a component are different
entities).
In some cases, the DSC may allow the OEM to provision and manage its own content in the DSC
for its own purpose, such as managing their firmware or software installed on the platform. In this
case, the OEM is considered to be another CA under the control of the administrator. The role of
administrator is not ascribed to the OEM since it likely does not control the manufacturer’s
firmware or key material and thus does not control the behavior of the DSC. Nor would the other
CAs on the platform tolerate OEM control of their content stored in the DSC. Even so, there should
be some separation between the administrator-owner and the other roles of the platform in terms
of authorizing use of the contents assigned to each of the roles. For example, administrator-owners
may deny access to contents, either temporarily or permanently (e.g., through cryptographic erase).
However, they cannot themselves access their contents for their own use or to gain access to things
they are not otherwise authorized to access.
2.4.2 Key Usage
One way to categorize keys is by the cryptographic functions they are allowed to participate in.
When one creates a key, one often restricts its use to encryption and decryption, or to signature
generation and verification. There are exceptions to this rule, especially in proof of possession
protocols. However, certification regimes often require strict separation of usage in regards to
encryption/decryption and signature generation/verification: one may use a key for one or the
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 22 of 140
other, but never both. As such, a DSC may have to enforce this separation of usage for keys; this
may mean that an attribute must accompany a key to help the DSC in its enforcement.
2.4.3 Sessions
Users may use their keys multiple times while in the DSC. Because authorization using public key
methods tends to be resource intensive (i.e. uses a fair amount of internal memory and takes a long
time), the DSC can use sessions to enforce authorization and manage access to the key within it.
As an alternative to requiring authorization for each access to a key, the DSC could allow the user
or owner of the key to open a session and provide the authorization when being used for the first
time, then maintain the session and authorization using a series of less resource-intensive
challenges and responses. Alternatively, in some instances, the DSC may require additional
authorization (such as an elevation of privileges) to access keys (or different, related keys). Such
a protocol of challenges and responses may generate and use ephemeral authorization tokens,
which would be one form of critical security parameter (CSP). The DSC may have to switch
session contexts in and out of the DSC to external temporary storage, which necessitates the
protection of these CSPs. Such a session context is one type of SDO, to be discussed later.
2.4.4 Key Hierarchies
Another way to categorize keys is the relationship they have with each other. A DSC may have a
key hierarchy, or key chain, whereby data-at-rest is protected by one or more keys, which are
protected in turn by one or more additional keys, and potentially so on. This model calls out three
categories of keys generally found on typical DSCs. DSCs may contain Root Keys, Intermediate
(or Branch) Keys, and Leaf Keys.
Most DSCs have a concept of Root Keys. These keys are typically provisioned by the DSC
manufacturer and have some permanence in the DSC. Root Keys may be derived from seeds
(which is discussed later), injected at manufacturing time, or provisioned by a user. Root keys
installed by the manufacturers are considered administrator key material. Typically, normal client
applications, including OEMs, should not alter or erase this material unless specifically authorized
to do so. Root keys installed by the administrator should be similarly restricted. Client application-
installed root keys, on the other hand, are not considered as permanent since the client application
or the administrator can remove them at any time without authorization.
Root Keys may either be encryption/decryption keys, signature verification keys, or signature
generation keys. Encryption/decryption keys, or simply Root Encryption Key (REK), usually
anchor a hierarchy of keys stored external to the DSC necessitating both the encrypt key to protect
the key outside the DSC, and the decrypt key to expose its operations within the protected and
secure confines of the DSC. The Signature Verification Keys from public key schemes should
always contain the public portion and never the private portion. Use of Signature Generation keys
as Root Keys is rare.
Most DSCs have a concept of Intermediate Keys. These are sometimes known as Branch Keys,
Key Encryption Keys, and Key Wrapping Keys. In the SFRs of this cPP, these will be referred to
as Key Encryption Keys (KEKs), even if the target of encryption is not a key. Intermediate Keys
must always be encryption keys. Intermediate keys cannot be signing keys.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 23 of 140
Note that although chained certificates (see certificates below) are one form of a sequence of keys,
each of which signs another key, the creation and verification of such a chain of certificates is out
of scope for the core requirements of the cPP; however, it may be added as a package if one or
both of these features (creating the chain and verifying the chain) is indeed present in the DSC.
Nonetheless, the primitives of signing and verification are present due to other cryptographic
operations in scope for this cPP.
Intermediate Keys should always be protected (i.e. wrapped) by either a Root Key or another
Intermediate Key.
Leaf Objects consist of Authorization Data and Leaf Keys. Leaf Keys can be either signing or
encryption keys. Leaf Objects collectively refers to data that should be wrapped by either a Root
Key or a KEK and is not subsequently used as a KEK itself. Encryption Leaf Keys do not wrap
other keys (at least in the context of the DSC; what happens outside the DSC with Leaf Keys is
out of its control). In many contexts, an Encryption Leaf Key is known as a Data Encryption Key
(DEK). In the context of the DSC, this cPP will not assume how the user of the DSC will use the
Leaf Keys it creates, and will refrain from using the term DEK.
Certificates contain either signed public keys, signed encryption/decryption keys, or some sort of
Authorization Data. Signature keys come in several varieties: asymmetric signing keys, which
contain a private key for signing (and maybe also the public key for verification) and verification
keys, which contains only the public verification key and does not contain the private key (and
thus cannot perform a signing function). There are also symmetric signature keys. In this case these
consist of only a single key for both signing and verifying.
Authorization Data may have an arbitrary length of bits or bytes and may contain arbitrary or non-
arbitrary values of bits or bytes.
Seeds have a special place in this Key Reference Model. Manufacturers, owners, and users of the
DSC can use permanent seeds to create root keys. Manufacturers have good reasons to use seeds
to derive Root Keys and other items in the Key Reference Model. These include:
 Seeds take less space to store than certain asymmetric keys for given desired
cryptographic strengths.
 Having seeds that are unique per DSC enhances the chance that the same key derivation
function on different DSCs will yield unique keys.
Figure 5 contains an example of a hierarchy of keys where each lower-level key is wrapped by a
higher-level key that is connected to it. The Firmware Signature Key and the Root Encryption Key
are examples of Root Keys. The Intermediate Wrapping Key is an example of an Intermediate
Key. The Software Signature Key, the File Encryption Key, and the Streaming Movie
Authorization Token are examples of Leaf Objects. Figure 5 serves as an illustration of key
hierarchies; other configurations are possible.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 24 of 140
Figure 5: Example Key Hierarchy
Roles may play an important part in key hierarchies. One of the simplest models enforces a
different hierarchy for each role at the root key level. Another way to put this is each hierarchy at
the root key level supports a different role. However, for more complexity, once intermediate keys
are allowed, then each intermediate key could serve as the root of a hierarchy of keys for a different
role. Here is where the key functions and the roles come together. Roles may further divide into
which role has the right to use a key, which role has the right to move the key from one parent to
another, which role has the right to destroy a key, etc.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 25 of 140
2.4.5 Protected Storage Locations
This cPP covers several different types of storage locations for keys and critical security
parameters (CSPs) such as authentication tokens. Some DSCs may have a generous amount of
protected storage internal to themselves, which allows it to accommodate all keys and CSPs in
operational use, whether the DSC is performing operations to administer itself or operations on
behalf of users. Other DSCs may have a minimal amount of protected storage locations with just
enough to accommodate root keys along with a limited number of operational keys and CSPs for
user authorized sessions.
For those cases in which the DSC relies on storage external to itself to accommodate all the keys
and CSPs on which applications expect it to operate, it will either have to support secure channels
to another DSC with a more generous allocation of protected storage locations, or use a series of
wrapping keys to protect private keys and CSPs while outside of the DSC. Whether the DSC is
powered on or powered off, the DSC is expected to provide support for protected storage locations
for its root keys. If the DSC uses external storage without secure channels, then it should be ready
to wrap both intermediate wrapping keys as well as the Leaf Objects. This implies that there will
be some sort of structure on each of these items stored external to the DSC. The next section
discusses that structure.
A conformant TOE may include “write-once” storage such as single-use eFuses. Since data is
written to any such storage as part of the initial provisioning of the TOE, the data is considered
immutable once the TOE has entered its evaluated configuration. The integrity of this data is
maintained through the physical properties of its storage medium.
2.4.6 SDEs and SDOs
Although there is another section written about SDEs and SDOs, this section is used to map keys
and authentication tokens to SDEs and SDOs. This cPP does not impose a strict structure on the
items in the key hierarchy. An X.509 certificate is one example of a strict structure of a key with
attributes. Collecting attributes of an SDE and composing an SDO structure with an SDE and
attribute fields imposes temporal and storage penalties in all cases. In certain resource-constrained
cases the attributes could be implicit. For example, the root keys are administrative keys, which
requires administrator authentication for use while all other objects are user objects, which require
user authentication. The raw unadorned key or object is the SDE and the SDO may be implied by
virtue of its location within the hierarchy, i.e. it is understood that keys in the root position require
administrator authentication while all other objects, which may or may not be keys, require user
authentication.
In the previous section on protected storage locations, a DSC may have to use storage external to
itself. In these cases, an SDO of a wrapped key may contain a number of important attributes, such
as a pointer to its parent, authorization values, and other indications of the functions allowed
(encrypt vs. sign). Alternatively, some or all attributes may be implied, which means that only the
keys or CSPs themselves exist outside the DSC. In either case, the sensitive values, such as private
keys, secret keys, and CSPs, should be encrypted when outside the DSC. The parent of these
objects are either intermediate wrapping keys, or encrypting root keys.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 26 of 140
Some DSCs may want to distinguish between SDEs created within itself from SDEs ingested from
an external source. Additionally, some DSCs may output SDEs without additional context or
attributes from the DSC. A DSC, in some contexts, will not distinguish an ingested SDO from raw
keys.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 27 of 140
3 CC Conformance Claims
As defined by the references [CC1], [CC2] and [CC3], this cPP:
 conforms to the requirements of Common Criteria v3.1, Release 5
 is Part 2 extended, Part 3 conformant
 does not claim conformance to any other PP or package.
The methodology applied for the cPP evaluation is defined in [CEM] and refined by the Evaluation
Activities in [SD]. This cPP satisfies the following Assurance Families: APE_CCL.1,
APE_ECD.1, APE_INT.1, APE_OBJ.2, APE_REQ.2 and APE_SPD.1.
In order to be conformant to this cPP, a TOE must demonstrate Exact Conformance. Exact
Conformance is defined as the ST containing all of the requirements in section 5 of this cPP (these
are the mandatory SFRs), and potentially requirements from Appendix A (these are optional SFRs)
or Appendix B (these are selection-based SFRs, some of which will be mandatory according to the
selections made in other SFRs) of this cPP. While iteration is allowed, no additional requirements
(from CC Parts 2 or 3, or definitions of extended components not already included in this cPP) are
allowed to be included in the ST. Further, no requirements in section 5 of this cPP are allowed to
be omitted.
The PPs and PP-Modules that are allowed to be specified in a PP-Configuration with this cPP are
specified in the ‘Allowed-With’ list at
https://ccusersforum.onlyoffice.com/Products/Files/doceditor.aspx?fileid=6746219.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 28 of 140
4 Security Problem Definition
4.1 Assets
(R.AUTHDATA) Authorization Data that the TOE manages in support of the authorization
services that it offers, including both user-provided authentication tokens and authorization values
and those created by the TOE. Authorization Data may be special cases of SDEs, or they may be
attributes in an SDO. The TSF may use Authorization Data to manage the use and disposition of
a single SDE, or a broad class of SDEs. The TOE protects the integrity of Authorization Data, and
in some cases, may protect their confidentiality.
(R.CONFKEY) Confidential (or secret) keys used in symmetric cryptographic functions and
private keys used in asymmetric cryptographic functions are managed and used by the TOE in
support of the cryptographic services that it offers. This includes user keys that are owned and
used by a specific user (which are a special case of an SDE), and support keys used in the
implementation and operation of the TOE. The confidentiality and integrity of these keys must be
protected.
(R.PUBKEY) Public keys are managed and used by the TOE in support of the cryptographic
services that it offers (including user keys and support keys). This includes user keys that are
owned and used by a specific user (which are a special case of an SDE), and support keys used in
the implementation and operation of the TOE. The integrity of these keys must be protected.
(R.SDE) An SDE is an item of user data that is held in (and may be stored on) the TOE and that
may be used only by an authorized subject (i.e. a user or process acting on behalf of that user).
Typically the TOE will not know what an SDE represents in terms of the application or service
that it is used for: it will characterize an SDE only in terms of the authorization requirements that
are necessary to access it (i.e. the presentation and possibly processing of authorization data
presented to the TOE), and the operations that can be performed on or with it after authorization
has been achieved. An SDE may require protection of its confidentiality, its integrity, or both.
(R.SDO) An SDO comprises one or more SDEs that are collectively bound to one or more
attributes (e.g. an identifier for the identity that a key or authorization data is associated with).
These attributes may necessarily be used by the TSF to enforce authorization policies concerning
the allowed use and disposition of the subject SDEs. The bindings can either be explicit (e.g. in a
well-formatted standards-based data structure) or implicit (e.g. by virtue of their location within
the TOE which implies privileges of use and disposition by certain users), or a combination of
both.
4.2 Threats
(T.BRUTE_FORCE_AUTH) An unauthorized user may attempt to gain unauthorized access to
the TOE by repeatedly and rapidly supplying a large number of permutations of authorization data,
such as passwords, biometrics, etc. that protect the SDEs, in the hopes that valid authorization data
can be obtained through brute force. A successful brute force attack puts the SDE/SDO data, user
identity, and the TOE’s underlying platform at risk.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 29 of 140
The consequences of risks to SDEs include the loss of confidentiality of the SDE or SDO data,
unauthorized access to and use of this data, destruction of this data, and the ability of the adversary
to impersonate a user or that user’s platform.
(T.HW_ATTACK) An individual with physical access to the TOE may apply hardware attacks
such as probing, physical manipulation, fault-injection, side-channel analysis, environmental
stress, or reactivating blocked test-features or other pre-delivery services to manipulate the
behavior of the TOE to disclose SDOs.
(T.SDE_TRANSIT_COMPROMISE) An attacker with the ability to observe data transmission
into and out of the TOE may access or determine plaintext values of keys, authorization data, and
other SDEs as the TSF transmits them into or out of the TOE. This puts the SDE/SDO data, user
identity, and the TOE’s underlying platform at risk.
The consequences of access to plaintext SDEs in this way include the loss of confidentiality of
SDE/SDO data, unauthorized use of this data, unauthorized modification of this data, and the
ability of the adversary to impersonate a user or their platform.
(T.UNAUTH_UPDATE) An unauthorized user may force the platform to update the TOE with
firmware that compromises its security features. Poorly chosen update protocols, cryptographic
algorithms, and keys sizes may allow adversaries to install software or firmware that bypasses
security features or rolls back to firmware versions with compromised security features and
provides them with unauthorized access to SDEs.
The consequences of risks to firmware include the loss of confidentiality of the SDE/SDO data,
unauthorized access to and use of this data, destruction of this data, and the ability of the adversary
to impersonate a user or that user’s platform.
(T.UNAUTHORIZED_ACCESS) An unauthorized user may gain unauthorized access to one or
more SDEs within the TOE. If an adversary gains access to SDEs/SDOs stored in the TSF, they
may attempt to view, use, or destroy this data as well as impersonate a user or that user’s platform.
The consequences of unauthorized access to SDEs/SDOs include the loss of confidentiality of their
content, unauthorized use of that content, unauthorized modification or destruction of that content,
and the ability of the adversary to impersonate a user or that user’s platform.
(T.WEAK_CRYPTO) An unauthorized user or attacker that observes network traffic transmitted
to and from the TOE may cryptographically exploit poorly chosen cryptographic algorithms,
random bit generators, ciphers or key sizes. Weak cryptography chosen by users or by TSF
protection mechanisms puts the user’s data, identity, and platform at risk of exploitation by
adversaries.
The consequences of risks to SDEs include the loss of confidentiality of the SDE/SDO data,
unauthorized access to and use of this data, destruction of this data, and the ability of the adversary
to impersonate a user or that user’s platform.
(T.WEAK_ELEMENT_BINDING) An unauthorized user may successfully break the association
between SDEs, for example to replace one element with another element.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 30 of 140
The consequences of manipulation of SDEs in this way include the loss of confidentiality of the
data, unauthorized use of the data, destruction of the data, unauthorized modification of
credentials, and the ability of the adversary to impersonate a user or that user’s platform.
(T.WEAK_OWNERSHIP_BINDING) A user may successfully access or manipulate SDEs that
they do not own.
The consequences of manipulation of SDEs in this way include the loss of confidentiality of
SDE/SDO data, unauthorized use of that data, unauthorized modification of that data, and the
ability of the adversary to impersonate a user or that user’s platform.
4.3 Assumptions
This section describes the assumptions made in identification of the threats and security
requirements for dedicated security components. The dedicated security component is not
expected to provide assurance in any of these areas, and as a result, requirements are not included
to mitigate the threats associated.
(A.AUTH_USERS) Authorized users follow all provided guidance regarding the safeguarding of
SDEs held outside the TOE.
(A.CREDENTIAL_REVOCATION) If a platform is lost, stolen, or compromised then there is a
method of revocation of any credentials held (or equivalent method of mitigating the impact of
potential access to the credentials). Credential revocation ensures that the loss of physical custody
does not have significant negative impact on the security of the platform. This implies that an
attacker has only limited access to the device to apply attacks. It further implies that the device
owner is not seen as an attacker.
(A.ROT_INTEGRITY) The vendor provides a RoT that is comprised of the TOE firmware,
hardware, and pre-installed SDOs, free of intentionally malicious capabilities. The platform trusts
the RoT since it cannot verify the integrity and authenticity of the RoT.
If the RoT is immutable, then the platform can have confidence that once delivered, malicious
actors cannot modify the RoT to add malicious capabilities. If the RoT is mutable (e.g. the
firmware and pre-installed SDOs), then it will verify the authenticity and integrity of the updates
before applying them.
(A.TRUSTED_PEER) The remote peer communicating over a secure channel is trustworthy, and
will not abuse the secure channel in order to introduce malware or fraudulent SDEs into the TOE.
4.4 Organizational Security Policies
There are no organizational security policies defined in this cPP.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 31 of 140
5 Security Objectives
5.1 Security Objectives for the TOE
(O.AUTH_FAILURES) The TOE resists repeated attempts to guess authorization data by
responding to consecutive failed attempts in a way that prevents an attacker from exploring a
significant amount of the space of possible authorization data values.
(O.AUTHORIZATION) The TOE authorizes only authenticated subjects to access SDOs stored
by authenticated users of the TOE, pre-installed SDOs stored in the RoT by the manufacturer of
the TOE, and management functions that are used to manipulate the TSF and its stored data.
(O.DATA_PROTECTION) The TOE provides authenticity, confidentiality, and integrity services
for SDOs.
(O.FW_INTEGRITY) The TOE ensures its own integrity has remained intact and attests its
integrity to outside parties on request.
(O.PARSE_PROTECTION) All SDEs are received by the TOE over a secure channel for parsing,
protecting confidentiality and integrity of the SDEs while in transit. The TOE authenticates the
source of all SDEs received, and authenticates itself to the remote peer.
(O.PURGE_PROTECTION) The TOE provides secure destruction of SDEs when they are deleted,
so that the previous value of the SDE can no longer be accessed (and cannot be restored).
(O.SECURE_UPDATE) The TOE software/firmware either does not allow update, or else
implements a mechanism that ensures only authorized updates are applied. If the TOE allows
updating its firmware, it is required to implement a mechanism that ensures only authorized
firmware can be loaded into the TOE. A secure update mechanism ensures the firmware is
authorized through verification of its integrity and authenticity while also preventing rollback to a
previous and potentially vulnerable firmware instance.
(O.STRONG_BINDING) The TOE provides a mechanism for binding data to its attributes
(including the identity of its owner) and prevents unauthorized changes to data attributes.
The protections for pre-installed SDEs/SDOs come through the firmware protections. For
example, only authorized updates to the firmware contains the functionality that determines the
attributes of the pre-installed SDOs. In the same vein, the authorized updates may also affect the
SDEs as well, if the vendor so chooses. The authorized update binds the attributes present in the
functionality of the firmware to the pre-installed SDEs.
(O.STRONG_CRYPTO) The TOE implements strong cryptographic mechanisms and algorithms
according to recognized standards, including support for random bit generation based on
recognized standards and a source of sufficient entropy. The TOE uses key sizes that are
recognized as providing sufficient resistance to current attack capabilities.
5.2 Security Objectives for the Operational Environment
The Operational Environment of the TOE implements technical and procedural measures to assist
the TOE in correctly providing its security functionality. This section defines security objectives
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 32 of 140
for the Operational Environment and consists of a set of statements describing the goals that the
Operational Environment should achieve.
(OE.AUTH_USERS) Authenticated users follow all provided guidance regarding the safeguarding
of SDEs, especially authentication tokens such as passwords, pass-phrases, and biometrics.
(OE.PHYSICAL) The platform holder will ensure that an attacker has no prolonged, unsupervised
physical access to the platform. If a platform is lost or stolen then the platform holder will promptly
initiate revocation of any credentials held (or equivalent method of mitigating the impact of
potential access to the credentials).
This security objective for the operating environment expects an entity to wipe the contents of the
TOE in the event that an attacker has prolonged unsupervised physical access to the platform
containing the TOE. There exists a variety of methods to wipe the contents or render the contents
useless to the attacker. The platform may institute its own signal to wipe the TOE upon reaching
or exceeding a threshold of unsuccessful user authentication or authorization attempts by an
attacker. A remote entity may signal to the platform that it should issue a signal to the TOE to wipe
is contents. The platform user (who has lost physical access to the platform) may contact service
providers and inform them of the loss of credentials in the TOE, who may in turn issue revocation
of those credentials.
(OE.TRUSTED_PEER) Connections using secure channels are made only to trusted peers, in
whom confidence has been established that they will not abuse the secure channel in order to
introduce malware or fraudulent SDEs into the TOE.
5.3 Security Objectives Rationale
Table 2 shows the mapping of Security Objectives for the TOE and for its Operational
Environment to Threats and Assumptions, along with rationale for these mappings.
Objective Threat or Assumption Rationale
O.AUTH_FAILURES T.BRUTE_FORCE_AUTH This objective ensures that the TSF has a
method to thwart brute-force authorization
attempts.
O.AUTHORIZATION T.UNAUTHORIZED_ACCESS This objective defines and enforces policies
that govern access to SDOs.
T.HW_ATTACK This objective ensures that the access
control policy is not thwarted by physical
attacks on the TOE.
O.DATA_PROTECTION T.SDE_TRANSIT_COMPROMISE This objective ensures that the
confidentiality of SDEs is enforced.
T.UNAUTHORIZED_ACCESS This objective ensures that SDOs have
adequate protections.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 33 of 140
Objective Threat or Assumption Rationale
T.WEAK_ELEMENT_BINDING This objective assures the authenticity and
integrity of SDEs.
T.WEAK_OWNERSHIP_BINDIN
G
This objective protects SDEs from
unauthorized access.
O.FW_INTEGRITY A.ROT_INTEGRITY This objective ensures that the RoT’s
attestation of firmware integrity is
sufficient assurance that the attestation is
valid because the RoT is assumed to be
trusted.
T.WEAK_ELEMENT_BINDING This objective ensures that the TOE’s
firmware cannot be corrupted in a way that
allows the unauthorized substitution of
SDEs.
T.WEAK_OWNERSHIP_BINDIN
G
This objective ensures that the TOE’s
firmware cannot be corrupted in a way that
causes ownership bindings not to be
enforced.
O.PARSE_PROTECTION T.SDE_TRANSIT_COMPROMISE This objective ensures that SDEs are not
transmitted into the TOE over an insecure
channel.
O.PURGE_PROTECTION T.HW_ATTACK This objective ensures that a hardware
attack does not expose SDE remnants that
could compromise the TOE or any of its
stored data.
T.SDE_TRANSIT_COMPROMISE This objective ensures that residual data
associated with SDEs do not remain when
the SDEs themselves are deleted.
O.SECURE_UPDATE T.UNAUTH_UPDATE This objective prevents the application of
untrusted firmware updates to the TOE.
O.STRONG_BINDING T.WEAK_OWNERSHIP_BINDIN
G
This objective establishes ownership of
SDEs to determine the users that may
interact with them.
O.STRONG_CRYPTO T.WEAK_CRYPTO This objective ensures that the TOE
implements cryptographic algorithms that
are not subject to compromise.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 34 of 140
Objective Threat or Assumption Rationale
OE.AUTH_USERS A.AUTH_USERS This objective holds that sufficiently
trained and trusted users will follow
instructions as assumed.
OE.PHYSICAL A.CREDENTIAL_REVOCATION This objective ensures that an adversary
will not have sufficient access to the TOE
to exploit the login mechanism if the
assumption holds that credential revocation
is enforced upon a lost or stolen TOE.
T.HW_ATTACK This objective ensures that the adversary
has only a limited window of opportunity to
engage in a hardware attack on the physical
TOE.
OE.TRUSTED_PEER A.TRUSTED_PEER This objective holds that if the TOE’s
Operational Environment is configured
such that the TSF can only communicate
with trusted peer, then this assumption will
be satisfied.
A.ROT_INTEGRITY This objective holds that the vendor’s RoT
can be relied upon if the only entities that
the TSF communicates with are trusted.
Table 2: Security Problem Definition Mapping to Security Objectives
The objectives can map to multiple assumptions or threats to fully define the objectives of the
TOE and the operational environment.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 35 of 140
6 Security Functional Requirements
The individual security functional requirements are specified in the sections below. Based on
selections made in these SFRs it will also be necessary to include some of the selection-based
SFRs in Appendix B. Additional optional SFRs may also be adopted from those listed in Appendix
A for those functions that are provided by the TOE instead of its Operational Environment.
The Evaluation Activities defined in [SD] describe actions that the evaluator shall take in order to
determine compliance of a particular TOE with the SFRs. The content of these Evaluation
Activities will therefore provide more insight into deliverables required from TOE Developers.
6.1 SFR Architecture
A DSC implements all seven services in Table 3 as well as self-protection functionality that
protects against a compromise or degradation of these services.
Service Applicable Requirements
Parse FCS_CKM.1 Cryptographic Key Generation
FCS_CKM.2 Cryptographic Key Establishment
FCS_COP.1/Hash Cryptographic Operation (Hashing)
FCS_COP.1/HMAC Cryptographic Operation (Keyed Hash)
FCS_COP.1/KAT Cryptographic Operation (Key Agreement/Transport)
FCS_COP.1/KeyEnc Cryptographic Operation (Key Encryption)
FCS_COP.1/PBKDF Cryptographic Operation (Password-Based Key Derivation
Functions)
FCS_COP.1/SKC Cryptographic Operation (Symmetric Key Cryptography)
FDP_ACC.1 Subset Access Control
FDP_ACF.1 Security Attribute Based Access Control
FDP_ITC_EXT.1 Parsing of SDEs
FDP_ITC_EXT.2 Parsing of SDOs
FTP_ITP_EXT.1 Physically Protected Channel
FTP_ITC_EXT.1 Cryptographically Protected Communications Channels
FTP_CCMP_EXT.1 CCM Protocol
FTP_GCMP_EXT.1 GCM Protocol
FTP_ITE_EXT.1 Encrypted Data Communications
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 36 of 140
Provision FCS_CKM.1/AK Cryptographic Key Generation (Asymmetric Keys)
FCS_CKM.1/KEK Cryptographic Key Generation Key Encryption Key (KEK)
FCS_CKM_EXT.5 Cryptographic Key Derivation
FCS_COP.1/Hash Cryptographic Operation (Hashing)
FCS_COP.1/HMAC Cryptographic Operation (Keyed Hash)
FCS_COP.1/SKC Cryptographic Operation (Symmetric Key Cryptography)
FCS_RBG_EXT.1 Random Bit Generation
FDP_ACC.1 Subset Access Control
FDP_ACF.1 Security Attribute Based Access Control
FIA_SOS.2 TSF Generation of Secrets
FMT_MSA.3 Static Attribute Initialization
FPT_STM.1 Reliable Time Stamps
FCS_ENT_EXT.1 Entropy for External IT Entities
FCS_RBG_EXT.2 Cryptographic Operation Random Bit Generation
FCS_CKM.1/SK Cryptographic Key Generation (Symmetric Key Encryption)
Protect FCS_COP.1/Hash Cryptographic Operation (Hashing)
FCS_COP.1/HMAC Cryptographic Operation (Keyed Hash)
FCS_COP.1/SKC Cryptographic Operation (Symmetric Key Cryptography)
FCS_STG_EXT.1 Protected Storage
FCS_STG_EXT.2 Key Storage Encryption
FCS_STG_EXT.3 Key Integrity Protection
FDP_SDC_EXT.1 Confidentiality of SDEs
FDP_SDI.2 Stored Data Integrity Monitoring and Action
FMT_SMR.2 Separation of Roles
FPT_FLS.1/FI Failure with Preservation of Secure State (Fault Injection)
FPT_MOD_EXT.1 Debug Modes
FPT_PHP.3 Resistance to Physical Attack
FPT_ROT_EXT.1 Root of Trust Services
FPT_ROT_EXT.2 Root of Trust for Storage
FPT_PRO_EXT.2 Data Integrity Measurements
FDP_FRS_EXT.2 Factory Reset Behavior
FIA_AFL_EXT.2 Authorization Failure Response
FPT_FLS.1/FW Failure with Preservation of Secure State (Firmware)
FPT_ITT.1 Basic Internal TSF Data Transfer Protection
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 37 of 140
Process FCS_COP.1/Hash Cryptographic Operation (Hashing)
FCS_COP.1/HMAC Cryptographic Operation (Keyed Hash)
FCS_COP.1/KeyEnc Cryptographic Operation (Key Encryption)
FCS_COP.1/SigGen Cryptographic Operation (Signature Generation)
FCS_COP.1/SigVer Cryptographic Operation (Signature Verification)
FCS_COP.1/SKC Cryptographic Operation (Symmetric Key Cryptography)
FCS_SLT_EXT.1 Cryptographic Salt Generation
FDP_ACC.1 Subset Access Control
FDP_ACF.1 Security Attribute Based Access Control
FIA_AFL_EXT.1 Authorization Failure Handling
FIA_SOS.2 TSF Generation of Secrets
FIA_UAU.2 User Authentication before any Action
FIA_UAU.5 Multiple Authentication Mechanisms
FIA_UAU.6 Re-Authenticating
FMT_MOF_EXT.1 Management of Security Functions Behavior
FMT_MSA.1 Management of Security Attributes
FMT_SMF.1 Specification of Management Functions
FMT_SMR.2 Separation of Roles
FPT_ROT_EXT.1 Root of Trust Services
FPT_RPL_EXT.1 Replay Prevention
FPT_STM.1 Reliable Time Stamps
FIA_AFL_EXT.2 Authorization Failure Response
Prove FCS_COP.1/Hash Cryptographic Operation (Hashing)
FCS_COP.1/HMAC Cryptographic Operation (Keyed Hash)
FCS_RBG_EXT.1 Random Bit Generation
FCS_SLT_EXT.1 Cryptographic Salt Generation
FDP_ACC.1 Subset Access Control
FDP_ACF.1 Security Attribute Based Access Control
FPT_PRO_EXT.1 Root of Trust
FPT_RPL_EXT.1 Replay Prevention
FPT_STM.1 Reliable Time Stamps
FCS_RBG_EXT.2 Cryptographic Operation Random Bit Generation
FPT_ROT_EXT.3 Root of Trust for Reporting Mechanisms
FDP_DAU.1/Prove Basic Data Authentication (for Use with the Prove Service)
FDP_MFW_EXT.1 Mutable/Immutable Firmware
FDP_MFW_EXT.2 Basic Firmware Integrity
FDP_MFW_EXT.3 Firmware Authentication with Identity of Guarantor
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 38 of 140
Propagate FCS_COP.1/Hash Cryptographic Operation (Hashing)
FCS_COP.1/HMAC Cryptographic Operation (Keyed Hash)
FCS_COP.1/KeyEnc Cryptographic Operation (Key Encryption)
FCS_COP.1/SKC Cryptographic Operation (Symmetric Key Cryptography)
FCS_RBG_EXT.1 Random Bit Generation
FCS_SLT_EXT.1 Cryptographic Salt Generation
FDP_ACC.1 Subset Access Control
FDP_ACF.1 Security Attribute Based Access Control
FDP_ETC_EXT.2 Propagation of SDOs
FCS_RBG_EXT.2 Cryptographic Operation Random Bit Generation
FPT_ITT.1 Basic Internal TSF Data Transfer Protection
FTP_ITP_EXT.1 Physically Protected Channel
FTP_ITC_EXT.1 Cryptographically Protected Communications Channels
FTP_CCMP_EXT.1 CCM Protocol
FTP_GCMP_EXT.1 GCM Protocol
FTP_ITE_EXT.1 Encrypted Data Communications
Purge FCS_CKM.4 Cryptographic Key Destruction
FCS_CKM_EXT.4 Cryptographic Key and Key Material Destruction Timing
FCS_RBG_EXT.1 Random Bit Generation
FDP_RIP.1 Subset Residual Information Protection
FCS_RBG_EXT.2 Cryptographic Operation Random Bit Generation
FDP_FRS_EXT.2 Factory Reset Behavior
TSF Security FDP_FRS_EXT.1 Factory Reset
FDP_MFW_EXT.1 Mutable/Immutable Firmware
FMT_SMF.1 Specification of Management Functions
FPT_FLS.1/FI Failure with Preservation of Secure State (Fault Injection)
FPT_MOD_EXT.1 Debug Modes
FPT_PHP.3 Resistance to Physical Attack
FPT_TST.1 TSF Testing
FRU_FLT.1 Degraded Fault Tolerance
FPT_PRO_EXT.2 Data Integrity Measurements
FDP_MFW_EXT.2 Basic Firmware Integrity
FDP_MFW_EXT.3 Firmware Authentication with Identity of Guarantor
FDP_FRS_EXT.2 Factory Reset Behavior
FPT_FLS.1/FW Failure with Preservation of Secure State (Firmware)
FPT_RPL.1/Rollback Replay Detection (Rollback)
Table 3: SFR Architecture
6.2 Conventions
The conventions used in descriptions of the SFRs are as follows:
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 39 of 140
 Unaltered SFRs are stated in the form used in [CC2] or their extended component definition
(ECD);
 Refinement made in the PP: the added/removed text is indicated with bold
text/strikethroughs. When text is substituted (i.e. some text is added in place of some other
text, which is then deleted), only the added text is included;
Note that a refinement is also used to indicate cases where the PP replaces an assignment
defined for an SFR in [CC2] and replaces it with a selection;
 Selections:
o Wholly or partially completed in the PP: the selection values (i.e. the selection
values adopted in the PP or the remaining selection values available for the ST) are
indicated with underlined text;
e.g. “[selection: disclosure, modification, loss of use]” in [CC2] or an ECD might
become “disclosure” (completion) or “[selection: disclosure, modification]”
(partial completion) in the PP;
o Some SFRs include selections that determine or constrain other assignments or
selections. In these cases, a table follows the requirement in which each row of the
table defines a permitted set of choices. Each row includes a unique identifier
defined solely to provide a label for the selection set. Individual entries in these
tables may also require further selections or assignments.
e.g. for FCS_CKM.1/AK (see Table 4), the ST for a TOE that supports RSA keys
must include the entries for ‘key type’, ‘key sizes’, and ‘list of standards’ as
specified in row 1AK. For ‘key sizes’, the ST author must further select which of
the required key sizes are supported. The row identifiers are merely intended as
quick-reference handles—there is no expectation that the TSF actually refer
internally to RSA keys using this identifier. Likewise, if the TOE supports ECC the
ST must include the entries from row 2AK along with the appropriate selections.
Identifier Key Type Key Sizes List of Standards
1AK RSA [selection: 2048 bit, 3072
bit]
FIPS PUB 186-4 (Section
B.3)
2AK ECC [selection: 256 (P-256),
384 (P-384), 512 (P-521)]
FIPS PUB 186-4 (Section
B.4 & D.1.2)
3AK BPC [selection: 256
(brainpoolP256r1), 384
(brainpoolP384r1), 512
(brainpoolP512r1)]
RFC5639 (Section 3)
[Brainpool Curves]
Table 4: Sample Cryptographic Table
 Assignment wholly or partially completed in the PP: indicated with italicized text;
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 40 of 140
 Assignment completed within a selection in the PP: the completed assignment text is
indicated with italicized and underlined text
e.g. “[selection: change_default, query, modify, delete, [assignment: other operations]]”
in [CC2] or an ECD might become “[change_default, [select_tag]]” (completion of both
selection and assignment) or “[selection: change_default, select_tag, [select_value]]”
(partial completion of selection, and completion of assignment) in the PP;
 Iteration: indicated by adding a string starting with “/” (e.g. “FCS_COP.1/Hash”).
SFR text that is bold, italicized, and underlined indicates that the original SFR defined an
assignment operation but the PP author completed that assignment by redefining it as a selection
operation, which is also considered to be a refinement of the original SFR.
If the selection or assignment is to be completed by the ST author, it is preceded by ‘selection:’ or
‘assignment:’. If the selection or assignment has been completed by the PP author and the ST
author does not have the ability to modify it, the proper formatting convention is applied but the
preceding word is not included. The exception to this is if the SFR definition includes multiple
options in a selection or assignment and the PP has excluded certain options but at least two remain.
In this case, the selection or assignment operations that are not permitted by this PP are removed
without applying additional formatting and the ‘selection:’ or ‘assignment:’ text is preserved to
show that the ST author still has the ability to choose from the reduced set of options.
Extended SFRs (i.e. those SFRs that are not defined in [CC2] are identified by having a label
‘_EXT’ at the end of the SFR name.
6.3 Cryptographic Support
6.3.1 FCS_CKM.1 Cryptographic Key Generation
FCS_CKM.1 Cryptographic Key Generation
FCS_CKM.1.1 The TSF shall generate cryptographic keys by [parsing in accordance with
FDP_ITC_EXT.1 and FDP_ITC_EXT.2, [selection: asymmetric key generation in accordance
with FCS_CKM.1/AK, symmetric key generation in accordance to FCS_CKM.1/SK, no other
methods]] in accordance with a specified cryptographic key generation algorithm [assignment:
cryptographic key generation algorithm] and specified cryptographic key sizes [assignment:
cryptographic key sizes] that meet the following: [assignment: list of standards].
Application Note 1.
Parsing of keys can refer to both the act of importing keys from outside the TOE boundary and to
the act of issuing commands or parameters to the TOE that trigger the TSF to perform a key
generation function.
If asymmetric key generation in accordance with FCS_CKM.1/AK is selected, the selection-based
SFR FCS_CKM.1/AK must be claimed by the TOE.
If symmetric key generation in accordance with FCS_CKM.1/SK is selected, the selection-based
SFR FCS_CKM.1/SK must be claimed by the TOE.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 41 of 140
6.3.2 FCS_CKM.1/KEK Cryptographic Key Generation (Key Encryption Key)
FCS_CKM.1/KEK Cryptographic Key Generation (Key Encryption Key)
FCS_CKM.1.1/KEK The TSF shall generate key encryption keys in accordance with a specified
cryptographic key generation algorithm corresponding to [selection:
 Asymmetric KEKs generated in accordance with FCS_CKM.1/AK identifier AK1,
 Symmetric KEKs generated in accordance with FCS_CKM.1/SK,
 Derived KEKs generated in accordance with FCS_CKM_EXT.5
] and specified cryptographic key sizes [assignment: cryptographic key sizes] that meet the
following: [assignment: list of standards].
Application Note 2.
KEKs protect KEKs and Symmetric Keys (SKs). DSCs should use key strengths commensurate
with protecting the chosen symmetric encryption key strengths.
If Asymmetric KEKs generated in accordance with FCS_CKM.1/AK is selected, the selection-
based SFR FCS_CKM.1/AK must be claimed by the TOE.
If Symmetric KEKs generated in accordance with FCS_CKM.1/SK is selected, the selection-based
SFR FCS_CKM.1/SK must be claimed by the TOE.
If Derived KEKs generated in accordance with FCS_CKM_EXT.5 is selected, the selection-based
SFR FCS_CKM_EXT.5 must be claimed by the TOE.
6.3.3 FCS_CKM.2 Cryptographic Key Establishment
FCS_CKM.2 Cryptographic Key Establishment
FCS_CKM.2.1 The TSF shall establish cryptographic keys in accordance with a specified
cryptographic key establishment method: [selection:
 RSA-based key establishment schemes that meet the following: NIST Special
Publication 800-56B Revision 2, “Recommendation for Pair-Wise Key Establishment
Schemes Using Integer Factorization Cryptography”;
 RSA-based key establishment schemes that meet the following: RSAES-PKCS1-v1_5
as specified in Section 7.2 of RFC 8017, “Public-Key Cryptography Standards
(PKCS) #1: RSA Cryptography Specifications Version 2.2”;
 Elliptic curve-based key establishment schemes that meet the following: [selection:
o NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise
Key Establishment Schemes Using Discrete Logarithm Cryptography”;
o RFC 7748, “Elliptic Curves for Security”]
 Finite field-based key establishment schemes that meet the following: NIST Special
Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key Establishment
Schemes Using Discrete Logarithm Cryptography”;
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 42 of 140
 Elliptic Curve Integrated Encryption Scheme (ECIES) that meets the following:
[selection:
o ANSI X9.63 - Public Key Cryptography for the Financial Services Industry
Key Agreement and Key Transport Using Elliptic Curve Cryptography;
o IEEE 1363a - Standard Specification for Public-Key Cryptography -
Amendment 1: Additional Techniques;
o ISO/IEC 18033-2 - Information Technology - Security Techniques -
Encryption Algorithms - Part 2: Asymmetric Ciphers;
o SECG SEC1 - Standards for Efficient Cryptography Group Elliptic Curve
Cryptography, section 5.1 Elliptic Curve Integrated Encryption Scheme]
] that meets the following: [assignment: list of standards].
Application Note 3.
This is a refinement of the SFR FCS_CKM.2 to deal with key establishment rather than key
distribution.
The ST author selects all key establishment schemes used for the selected cryptographic protocols.
The RSA-based key establishment schemes are described in Section 8 of NIST SP 800-56B Revision
2 [NIST-RSA]; however, Section 8 relies on implementation of other sections in SP 800-56B
Revision 2.
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.
6.3.4 FCS_CKM.4 Cryptographic Key Destruction
FCS_CKM.4 Cryptographic Key Destruction
FCS_CKM.4.1 The TSF shall destroy cryptographic keys and keying material in accordance
with a specified cryptographic key destruction method [selection:
 For volatile memory, the destruction shall be executed by a [selection:
o single overwrite consisting of [selection:
 a pseudo-random pattern using the TSF’s RBG,
 zeroes,
 ones,
 a new value of a key,
 [assignment: some value that does not contain any CSP]],
o removal of power to the memory,
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 43 of 140
o removal of all references to the key directly followed by a request for garbage
collection];
 For non-volatile memory [selection:
o that employs a wear-leveling algorithm, the destruction shall be executed by a
[selection:
 single overwrite consisting of [selection: zeroes, ones, pseudo-random pattern,
a new value of a key of the same size, [assignment: some value that does not
contain any CSP]],
 block erase];
o that does not employ a wear-leveling algorithm, the destruction shall be executed
by a [selection:
 [selection: single, [assignment: ST author defined multi-pass]] overwrite
consisting of [selection: zeros, ones, pseudo-random pattern, a new value of a
key of the same size, [assignment: some value that does not contain any CSP]]
followed by a read-verify. If the read-verification of the overwritten data fails,
the process shall be repeated again up to [assignment: number of times to
attempt overwrite] times, whereupon an error is returned.
 block erase]
]
] that meets the following: [no standard].
Application Note 4.
A DSC must implement mechanisms to destroy cryptographic keys and key material contained in
persistent storage when no longer needed. The term “cryptographic keys” in this SFR includes
the authorization data that is the entry point to a key chain and all other cryptographic keys and
keying material (whether in plaintext or encrypted form). 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).
Guidance documentation for the TOE requires users not to allow the TOE to leave the user’s
control while a session is active (and hence while the DEK is likely to be in plaintext in volatile
memory).
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
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 44 of 140
the mappings of logical addresses to the erased memory locations are erased as well as the data
itself.
Where different destruction methods are used for different data or different destruction situations
then the different methods and the data/situations they apply to (e.g. different points in time, or
power-loss situations) are described in the TSS (and the ST may use separate iterations of the SFR
to aid clarity). The TSS includes a table describing all relevant keys and keying material (including
authorization data) used in the implementation of the SFRs, stating the source of the data, all
memory types in which the data is stored (covering storage both during and outside of a session,
and both plaintext and non-plaintext forms of the data), and the applicable destruction method
and time of destruction in each case.
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_EXT
requirements, and not being any of the particular values listed as other selection options. The point
of the phrase “does not contain any sensitive data” is to ensure that the overwritten data is
carefully selected, and not taken from a general pool that might contain current or residual data
(e.g. SDOs or intermediate key chain values) that itself requires confidentiality protection.
6.3.5 FCS_CKM_EXT.4 Cryptographic Key and Key Material Destruction Timing
FCS_CKM_EXT.4 Cryptographic Key and Key Material Destruction Timing
FCS_CKM_EXT.4.1 The TSF shall destroy all keys and keying material when no longer needed.
Application Note 5.
The DSC will have mechanisms to destroy keys, including intermediate keys and key material, by
using an approved method, FCS_CKM.4. Examples of keys include intermediate keys, leaf keys,
encryption keys, signing keys, verification keys, authentication tokens, and submasks. The DSC
will have mechanisms to destroy keys and key material contained in persistent storage when no
longer needed. Based on their implementation, vendors will explain when certain keys are no
longer needed. An example in which key is no longer necessary includes a wrapped key whose
password has changed. However, there are instances when keys are allowed to remain in memory,
for example, a device identification key.
6.3.6 FCS_COP.1/Hash Cryptographic Operation (Hashing)
FCS_COP.1/Hash Cryptographic Operation (Hashing)
FCS_COP.1.1/Hash The TSF shall perform [cryptographic hashing] in accordance with a
specified cryptographic algorithm [selection: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512,
SHA3-224, SHA3-256, SHA3-384, SHA3-512] that meets the following: [selection: ISO/IEC
10118-3:2018, FIPS 180-4].
Application Note 6.
The hash selection should be consistent with the overall strength of the algorithm used for
signature generation. For example, the DSC should choose SHA-256 for 2048-bit RSA or ECC
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 45 of 140
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 for the following applications: generating and verifying hash-based message
authentication codes (HMACs), key derivation functions (KDFs), and random bit/number
generation2
.
6.3.7 FCS_COP.1/HMAC Cryptographic Operation (Keyed Hash)
FCS_COP.1/HMAC Cryptographic Operation (Keyed Hash)
FCS_COP.1.1/HMAC The TSF shall perform [keyed hash message authentication] in accordance
with a specified cryptographic algorithm [selection: HMAC-SHA-1, HMAC-SHA-256, HMAC-
SHA-384, HMAC-SHA-512, KMAC128, KMAC256] and cryptographic key sizes [assignment:
key size (in bits)] that meet the following: [selection: ISO/IEC 9797-2:2011, Section 7 “MAC
Algorithm 2”; [NIST-KDV] section 4 “KMAC”].
Application Note 7.
The HMAC key size falls into a range between L1 and L2 defined in ISO/IEC 10118 for the
appropriate hash function (for example for SHA-256 L1 = 512, L2 = 256) where L2 ≤ k ≤ L1.
6.3.8 FCS_COP.1/KAT Cryptographic Operation (Key Agreement/Transport)
FCS_COP.1/KAT Cryptographic Operations (Key Agreement/Transport)
FCS_COP.1.1/KAT The TSF shall perform [cryptographic key agreement/transport] using
[selection: identifier from Supported Methods for Key Agreement/Transport Operation
table] in accordance with a specified cryptographic algorithm [cryptographic algorithms as
chosen from Supported Methods for Key Agreement/Transport Operation table for corresponding
identifiers] and cryptographic key sizes [key sizes as chosen from Supported Methods for Key
Agreement/Transport Operation table for corresponding cryptographic algorithms] that meet the
following: [standards as chosen from Supported Methods for Key Agreement/Transport Operation
table for corresponding cryptographic algorithms].
Identifier Cryptographic Algorithm Key Sizes List of Standards
KAS1 RSA-single party [selection: 2048, 3072,
4096, 6144, 8192] bits
NIST SP 800-56Br2
section 8.2
KAS2 RSA-both party [selection: 2048, 3072,
4096, 6144, 8192] bits
NIST SP 800-56Br2
section 8.3
2
In certain cases, SHA-1 may also be used for verifying old digital signatures and time stamps, provided that this is
explicitly allowed by the application domain.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 46 of 140
Identifier Cryptographic Algorithm Key Sizes List of Standards
KTS-OAEP RSA [selection: 2048, 3072,
4096, 6144, 8192] bits
NIST SP 800-56Br2
section 9
RSAES-PKCS1-v1_5 RSA [selection: 2048, 3072,
4096, 6144, 8192] bits
RFC 8017 Section 7.2
ECDH-NIST ECDH with NIST curves [selection: 256 (P-256),
384 (P-384), 512 (P-521)]
NIST SP 800-56Ar3
ECDH-BPC ECDH with Brainpool curves [selection: 256
(brainpoolP256r1), 384
(brainpoolP384r1), 512
(brainpoolP512r1)]
RFC 5639 (Section 3)
DH Diffie-Hellman [selection: 2048, 3072,
4096, 6144, 8192] bits
NIST SP 800-56A rev 3,
[selection: RFC 3526
Section [selection: 3, 4, 5,
6, 7], RFC 7919
Appendices [selection:
A.1, A.2, A.3, A.4, A.5]]
Curve25519 ECDH 256 bits RFC 7748
ECIES ECIES [selection: 256, 384, 512]
bits
[selection:
ANSI X9.63,
IEEE 1363a,
ISO/IEC 18033-2 Part 2,
SECG SEC1 sec 5.1]
Table 5: Supported Methods for Key Agreement/Transport Operation
Application Note 8.
The selections in this SFR should be consistent with the algorithms selected in FCS_CKM.2.
6.3.9 FCS_COP.1/KeyEnc Cryptographic Operation (Key Encryption)
FCS_COP.1/KeyEnc Cryptographic Operation (Key Encryption)
FCS_COP.1.1/KeyEnc The TSF shall perform [key encryption and decryption] using [selection:
identifier from Supported Methods for Key Encryption Operation table] in accordance with
a specified cryptographic algorithm [cryptographic algorithms as chosen from Supported Methods
for Key Encryption Operation table for corresponding identifiers] and cryptographic key size [key
sizes as chosen from Supported Methods for Key Encryption Operation table for corresponding
identifiers] that meet the following: [standards as chosen from Supported Methods for Key
Encryption Operation table for corresponding identifiers].
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 47 of 140
Identifier Cryptographic Algorithm Key Size List of Standards
SE1 Symmetric [selection: AES-
CCM, AES-GCM, AES-CBC,
AES-CTR, AES-KWP, AES-
KW]
[selection: 128, 192, 256]
bits
See FCS_COP.1/SKC
SE2 Symmetric [CAM-CBC,
CAM-CCM, CAM-GCM]
[selection: 128, 256] bits See FCS_COP.1/SKC
AE1 Asymmetric KTS-OAEP [selection: 2048, 3072]
bits
See FCS_COP.1/KAT
XOR Exclusive OR operation [selection: 128, 192, 256]
bits
See FCS_CKM_EXT.5
Table 6: Supported Methods for Key Encryption Operation
Application Note 9.
A TOE will use this requirement to specify how the Key Encryption Key (KEK) wraps a
symmetric encryption key. A TOE will always need this requirement in order to capture the last
stage of the key chain in which the Key Encryption Key (KEK) wraps the symmetric encryption
key.
If XOR is selected, the selection-based SFR FCS_CKM_EXT.5 must be claimed by the TOE.
6.3.10 FCS_COP.1/SigGen Cryptographic Operation (Signature Generation)
FCS_COP.1/SigGen Cryptographic Operation (Signature Generation)
FCS_COP.1.1/SigGen The TSF shall perform [digital signature generation] using [selection:
identifier from Supported Methods for Key Agreement/Transport Operation table] in
accordance with a specified cryptographic algorithm [cryptographic algorithms as chosen from
Supported Methods for Signature Generation Operation table for corresponding identifiers] and
cryptographic key sizes [key sizes as chosen from Supported Methods for Signature Generation
Operation table for corresponding identifiers] that meet the following: [standards as chosen from
Supported Methods for Signature Generation Operation table for corresponding identifiers].
Identifier Cryptographic Algorithm Key sizes List of Standards
SigGen1 RSASSA-PKCS1-v1_5 using
[selection: SHA-256, SHA-
384, SHA-512, SHA3-256,
SHA3-384, SHA3-512]
[selection: 2048 bit, 3072
bit]
[selection: RFC 8017,
PKCS #1 v2.2 (Section
8.2); FIPS186-4, (Section
5.5)] (RSASSA-PKCS1-
v1_5)
[selection: ISO10118-3,
(Clause 10, 11); FIPS180-
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 48 of 140
Identifier Cryptographic Algorithm Key sizes List of Standards
4, (Section 6)] (SHA)
SigGen2 Digital signature scheme 2
using [selection: SHA-256,
SHA-384, SHA-512, SHA3-
256, SHA3-384, SHA3-512]
[selection: 2048 bit, 3072
bit]
ISO9796-2, (Clause 9)
(Digital signature scheme
2)
[selection: ISO10118-3,
(Clause 10, 11); FIPS180-
4, (Section 6)] (SHA)
SigGen3 Digital signature scheme 3
using [selection: SHA-256,
SHA-384, SHA-512, SHA3-
256, SHA3-384, SHA3-512]
[selection: 2048 bit, 3072
bit]
ISO9796-2, (Clause 10)
(Digital signature scheme
3)
[selection: ISO10118-3,
(Clause 10, 11); FIPS180-
4, (Section 6)] (SHA)
SigGen4 RSASSA-PSS using
[selection: SHA-256, SHA-
384, SHA-512, SHA3-256,
SHA3-384, SHA3-512]
[selection: 2048 bit, 3072
bit]
[RFC8017, PKCS#1v2.2
(Section 8.1)] (RSASSA-
PSS)
[selection: ISO10118-3,
(Clause 10, 11); FIPS180-
4, (Section 6)] (SHA)
SigGen5 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: 256 bits, 384
bits, 512 bits, 521 bits]
[selection:
[selection: ISO14888-3;
FIPS186-4 (Section 6)]
(ECDSA);
RFC5639 (Section 3)
(Brainpool Curves);
FIPS186-4 (Appendix
D.1.2) (NIST Curves)]
[selection: ISO10118-3,
(Clause 10, 11); FIPS180-
4, (Section 6)] (SHA)
Table 7: Supported Methods for Signature Generation Operation
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 49 of 140
6.3.11 FCS_COP.1/SigVer Cryptographic Operation (Signature Verification)
FCS_COP.1/SigVer Cryptographic Operation (Signature Verification)
FCS_COP.1.1/SigVer The TSF shall perform [digital signature verification for authenticity]
using [selection: identifier from Supported Methods for Signature Verification Operation
table] in accordance with a specified cryptographic algorithm [cryptographic algorithms as
chosen from Supported Methods for Signature Verification Operation table for corresponding
identifiers] and cryptographic key sizes [key sizes as chosen from Supported Methods for Signature
Verification Operation table for corresponding identifiers] that meet the following: [standards as
chosen from Supported Methods for Signature Verification Operation table for corresponding
identifiers].
Identifier Cryptographic Algorithm Key Sizes List of Standards
SigVer1 RSASSA-PKCS1-v1_5 using
[selection: one or more hash
algorithms selected in
FCS_COP.1.1/Hash]
[selection: 2048 bit, 3072
bit]
[selection: RFC 8017,
PKCS #1 v2.2 (Section
8.2); FIPS186-4, (Section
5.5)] (RSASSA-PKCS1-
v1_5)
[selection: ISO10118-3,
(Clause 10, 11); FIPS180-
4, (Section 6)] (SHA)
SigVer2 Digital signature scheme 2
using [selection: one or more
hash algorithms selected in
FCS_COP.1.1/Hash]
[selection: 2048 bit, 3072
bit]
ISO9796-2, (Clause 9)
(Digital signature scheme
2)
[selection: ISO10118-3,
(Clause 10, 11); FIPS180-
4, (Section 6)] (SHA)
SigVer3 Digital signature scheme 3
using [selection: one or more
hash algorithms selected in
FCS_COP.1.1/Hash]
[selection: 2048 bit, 3072
bit]
ISO9796-2, (Clause 10)
(Digital signature scheme
3)
[selection: ISO10118-3,
(Clause 10, 11); FIPS180-
4, (Section 6)] (SHA)
SigVer4 RSASSA-PSS using
[selection: one or more hash
algorithms selected in
FCS_COP.1.1/Hash]
[selection: 2048 bit, 3072
bit]
[selection: RFC8017,
PKCS#1v2.2 (Section
8.1)] (RSASSA-PSS)
[selection: ISO10118-3,
(Clause 10, 11); FIPS180-
4, (Section 6)] (SHA)
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 50 of 140
Identifier Cryptographic Algorithm Key Sizes List of Standards
SigVer5 ECDSA on [selection:
brainpoolP256r1,
brainpoolP384r1,
brainpoolP512r1, NIST P-256,
NIST P-384, NIST P-521]
using [selection: one or more
hash algorithms selected in
FCS_COP.1.1/Hash]
[selection: 256 bits, 384
bits, 512 bits]
[selection:
[selection: ISO14888-3;
FIPS186-4 (Section 6)]
(ECDSA);
RFC5639 (Section 3)
(Brainpool Curves);
FIPS186-4 (Appendix
D.1.2) (NIST Curves)]
[selection: ISO10118-3,
(Clause 10, 11); FIPS180-
4, (Section 6)] (SHA)
Table 8: Supported Methods for Signature Verification Operation
6.3.12 FCS_COP.1/SKC Cryptographic Operation (Symmetric Key Cryptography)
FCS_COP.1/SKC Cryptographic Operation (Symmetric Key Cryptography)
FCS_COP.1.1/SKC The TSF shall perform [data encryption/decryption] using [selection:
identifier from Supported Methods for Symmetric Key Cryptography Operation table] in
accordance with a specified cryptographic algorithm [cryptographic algorithms as chosen from
Supported Methods for Symmetric Key Cryptography Operation table for corresponding
identifiers] and cryptographic key sizes [key sizes as chosen from Supported Methods for
Symmetric Key Cryptography Operation table for corresponding identifiers] that meet the
following: [standards as chosen from Supported Methods for Symmetric Key Cryptography
Operation table for corresponding identifiers].
Identifier Cryptographic
Algorithm
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]
ISO 18033-3 (AES)
ISO 19772, Clause 8
(CCM)
NIST SP800-38C (CCM)
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 51 of 140
Identifier Cryptographic
Algorithm
Key Sizes List of Standards
AES-GCM AES 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
[selection: 96, 104, 112,
120, 128] bits
[selection: 128 bits, 192
bits, 256 bits]
ISO 18033-3 (AES)
ISO 19772, Clause.11
(GCM)
NIST SP800-38D (GCM)
AES-CBC AES in CBC mode with
non-repeating and
unpredictable IVs
[selection: 128 bits, 192
bits, 256 bits]
ISO 18033-3 (AES)
ISO 10116 (CBC)
NIST SP800-38A (CBC)
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 bits, 192
bits, 256 bits]
ISO 18033-3 (AES)
ISO 10116 (CTR)
NIST SP800-38A (CTR)
XTS-AES AES 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 18033-3 (AES)
[selection: IEEE 1619,
NIST SP800-38E] (XTS)
AES-KWP KWP based on AES [selection: 128 bits, 192
bits, 256 bits]
ISO/IEC 18033-3 (AES),
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 (AES),
NIST SP 800-38F, sec.
6.2 (KW)
ISO/IEC 19772, clause 7
(key wrap)
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 52 of 140
Identifier Cryptographic
Algorithm
Key Sizes List of Standards
CAM-CBC Camellia in CBC mode
with non-repeating and
unpredictable IVs
[selection: 128 bits, 256
bits]
ISO 18033-3 (Camellia)
ISO 10116 (CBC)
CAM-CCM Camellia in CCM mode
with unpredictable, non-
repeating nonce,
minimum size of 64 bits
[selection: 128 bits, 256
bits]
ISO 18033-3 (Camellia)
ISO 19772, Clause 8
(CCM)
SP800-38C
CAM-GCM Camellia in GCM mode
with non-repeating IVs;
the 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
[selection: 96, 104, 112,
120, 128] bits.
[selection: 128 bits, 256
bits]
ISO 18033-3 (Camellia)
ISO 19772, Clause 11
(GCM)
NIST SP800-38D
XTS-CAM Camellia 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 18033-3 (Camellia)
[selection: IEEE 1619,
SP800-38E] (XTS)
Table 9: Supported Methods for Symmetric Key Cryptography Operation
6.3.13 FCS_RBG_EXT.1 Random Bit Generation
FCS_RBG_EXT.1 Random Bit Generation
FCS_RBG_EXT.1.1 The TSF shall perform all deterministic random bit generation services in
accordance with ISO/IEC 18031:2011 using [selection: Hash_DRBG (any), HMAC_DRBG (any),
CTR_DRBG (AES)].
FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded by at least one entropy source in
accordance with NIST SP 800-90B that accumulates entropy from [selection: [assignment: number
of software-based sources] software-based noise source, [assignment: number of hardware-based
sources] hardware-based noise source] with a minimum of [selection: 128, 192, 256] bits of
entropy at least equal to the greatest security strength, according to ISO/IEC 18031:2011, of the
keys and CSPs that it will generate.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 53 of 140
Application Note 10.
ISO/IEC 18031:2011 contains three different methods of generating random numbers. Each of
these in turn depends on underlying cryptographic primitives (hash functions/ciphers). This cPP
allows SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 for Hash_DRBG or HMAC_DRBG
and only AES-based implementations for CTR_DRBG.
6.3.14 FCS_SLT_EXT.1 Cryptographic Salt Generation
FCS_SLT_EXT.1 Cryptographic Salt Generation
FCS_SLT_EXT.1.1 The TSF shall use salts and nonces generated by an RBG as specified in
FCS_RBG_EXT.1.
6.3.15 FCS_STG_EXT.1 Protected Storage
FCS_STG_EXT.1 Protected Storage
FCS_STG_EXT.1.1 The TSF shall provide [selection: mutable hardware-based, immutable
hardware-based, software-based] protected storage for asymmetric private keys and [selection:
symmetric keys, persistent secrets, no other keys].
Application Note 11.
If the protected storage is implemented in software that is protected as required by
FCS_STG_EXT.2, the ST author is expected to select software-based. If software-based is selected,
the ST author is expected to select all software-based key storage in FCS_STG_EXT.2.
Support for protected storage for all symmetric keys and persistent secrets will be required in
future revisions.
FCS_STG_EXT.1.2 The TSF shall support the capability of [selection: importing keys/secrets
into the TOE, causing the TOE to generate keys/secrets] upon request of [selection: a client
application, an administrator].
FCS_STG_EXT.1.3 The TSF shall be capable of destroying keys/secrets in the protected storage
upon request of [selection: a client application, an administrator].
FCS_STG_EXT.1.4 The TSF shall have the capability to allow only the user that [selection:
imported the key/secret, caused the key/secret to be generated] to use the key/secret. Exceptions
may only be explicitly authorized by [selection: the client application, the administrator].
FCS_STG_EXT.1.5 The TSF shall allow only the user that [selection: imported the key/secret,
caused the key/secret to be generated] to request that the key/secret be destroyed. Exceptions may
only be explicitly authorized by [selection: the client application, the administrator].
Application Note 12.
Not all conformant TOEs will have the ability to import pre-generated keys into the TOE. In these
cases, the TOE’s ability to receive commands to perform key generation is considered to be its
implementation of the Parse service. A subject that caused a key to be generated is considered to
be the ‘owner’ of that key in the same manner as they would be if they had imported it directly.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 54 of 140
6.3.16 FCS_STG_EXT.2 Key Storage Encryption
FCS_STG_EXT.2 Key Storage Encryption
FCS_STG_EXT.2.1 The TSF shall encrypt [AKs, SKs, KEKs, and [selection: long-term trusted
channel key material, all software-based key storage, no other keys]] using one of the following
methods: [assignment: key encryption methods as specified in FCS_COP.1/KeyEnc].
6.3.17 FCS_STG_EXT.3 Key Integrity Protection
FCS_STG_EXT.3 Key Integrity Protection
FCS_STG_EXT.3.1 The TSF shall protect the integrity of any encrypted [AKs, SKs, KEKs, and
[selection: long-term trusted channel key material, all software-based key storage, no other
keys]] by using [selection:
 Symmetric encryption in [selection: AES_CCM, AES_GCM, AES_KW, AES_KWP,
CAM_CCM, CAM_GCM] mode in accordance with FCS_COP.1/SKC;
 A hash of the stored key in accordance with FCS_COP.1/Hash;
 A keyed hash of the stored key in accordance with FCS_COP.1/HMAC;
 A digital signature of the stored key in accordance with FCS_COP.1/SigGen using an
asymmetric key that is protected in accordance with FCS_STG_EXT.2;
 An immediate application of the key for decrypting the protected data followed by a
successful verification of the decrypted data with previously known information
].
FCS_STG_EXT.3.2 The TSF shall verify the integrity of the [selection: hash, digital signature,
MAC] of the stored key prior to use of the key.
Application Note 13.
This requirement is not applicable to derived keys that are not stored. It is not expected that a
single key will be protected from corruption by multiple of these methods; however, a product may
use one integrity-protection method for one type of key and a different method for other types of
keys.
The documentation of the product’s encryption key management should be detailed enough that,
after reading, the evaluator will thoroughly understand the product’s key management and how it
meets the requirements to ensure the keys are adequately protected. This documentation should
include an essay and diagrams. This documentation is not required to be part of the TSS – it can
be submitted as a separate document and marked as developer proprietary.
6.4 User Data Protection
6.4.1 FDP_ACC.1 Subset Access Control
FDP_ACC.1 Subset Access Control
FDP_ACC.1.1 The TSF shall enforce the [Access Control SFP] on [
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 55 of 140
 Subjects: S.DSC, S.Admin, S.CA, S.EPS
 Objects: OB.P_SDO, OB.T_SDO, OB.AuthData, OB.Pstate, OB.FAACntr,
OB.AntiReplay, OB.Context
 Operations: OP.Import, OP.Create, OP.Use, OP.Modify, OP.Attest, OP.Store, OP.Export,
OP.Destroy].
Application Note 14.
The set of operations specified in the assignment can be collectively referred to as “access.” Any
subsequent use of the term “access” should be interpreted to refer to one or more of these events.
6.4.2 FDP_ACF.1 Security Attribute Based Access Control
FDP_ACF.1 Security Attribute Based Access Control
FDP_ACF.1.1 The TSF shall enforce the [Access Control SFP] to objects based on the following:
[subjects (defined in FDP_ACC.1.1) attempt to perform operations (defined in FDP_ACC.1.1)
against objects (defined in FDP_ACC.1.1). Subject and object attributes may be used to determine
whether the desired operations are permitted.
The following are the SFP-relevant security attributes that are associated with the subjects and
objects defined in FDP_ACC.1.1, as well as any restrictions on the attribute values:
 S.DSC
o DSC.ID
 S.Admin – none
 S.CA
o CA.ID
 S.EPS
o EPS.ID
 OB.P_SDO
o SDO.ID
o SDO.Type
o SDO.AuthData
o SDO.Reauth
o SDO.Conf
o SDO.Export
o SDO.Integrity
o SDO.Bind
 OB.T_SDO – same as OB.P_SDO
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 56 of 140
 OB.AuthData – none
 OB.Pstate – none
 OB.FAACntr – none
 OB.AntiReplay – none
 OB.Context– none
].
FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation among
controlled subjects and controlled objects is allowed:
 [Any subject that has been authorized to perform any operation against any OB.P_SDO or
OB.T_SDO object can continue to perform this operation if one of the following conditions
is true:
o The object’s SDO.Reauth attribute has a value of ‘none’, indicating that re-
authorization is not required for subsequent interactions with the SDO;
o The object’s SDO.Reauth attribute has a value of ‘each use’, indicating that re-
authorization is required for each interaction with the SDO, and the subject has
supplied valid authorization data to the TOE
 [assignment: rules automatically enforced by the TSF that always prohibit certain subject-
object-operation actions]
 [assignment: rules automatically enforced by the TSF that always permit certain subject-
object-operation actions]
 [assignment: rules automatically enforced by the TSF that conditionally permit certain
subject-object-operation actions based on subject security attributes, object security
attributes, or other conditions]
 [selection: [assignment: any configurable rules or parameters that can be modified to
affect the behavior of the Access Control SFP], no configurable rules]].
FDP_ACF.1.3 The TSF shall explicitly authorize access of subjects to objects based on the
following additional rules: [assignment: rules, based on security attributes, that explicitly
authorize access of subjects to objects].
FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the following
additional rules: [assignment: rules, based on security attributes, that explicitly deny access of
subjects to objects].
Application Note 15.
The expectation of this SFR is that the reader is given sufficient information to determine, for each
object controlled by the TOE, the operations that can be performed on it based on the subject
attempting to perform the operation, and whether this is conditional based on attribute values or
any other circumstances.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 57 of 140
It is expected that many of the subject-object-operation combinations will always be prohibited by
the TSF, either because the target object is not externally modifiable or because the subject lacks
the ability to perform the operation in question.
The ST author is not expected to create an exhaustive list of subject-object-operation
combinations; it is sufficient to list those that are always permitted and those that are conditionally
permitted with the expectation that all remaining combinations are prohibited.
FDP_ACF.1.3 and FDP_ACF.1.4 allow the ST author to optionally specify override conditions to
resolve otherwise contradictory Access Control SFP rules. For example, the rule “S.Admin may
always modify the SDO.Conf attribute of any OB.P_SDO or OB.T_SDO object” may be
overridden by a statement in FDP_ACF.1.4 that identifies any particular SDO objects as non-
modifiable regardless of subject authorizations.
The DSC may contain pre-installed SDOs. The DSC will enforce access control for pre-installed
SDOs like any other SDO it contains or manages.
6.4.3 FDP_ETC_EXT.2 Propagation of SDOs
FDP_ETC_EXT.2 Propagation of SDOs
FDP_ETC_EXT.2.1 The TSF shall propagate only SDO references, wrapped authorization data,
and wrapped SDOs such that only [selection: the TSF, authorized users] can access them.
Application Note 16.
The “SDO reference” is a pointer to an object that resides in the TOE; this can be thought of as
a token to the object. The “only the TSF can unwrap the data” selection refers to data that is
stored outside the TOE boundary (i.e., data that has been propagated).
6.4.4 FDP_FRS_EXT.1 Factory Reset
FDP_FRS_EXT.1 Factory Reset
FDP_FRS_EXT.1.1 The TSF shall permit a factory reset of the TOE upon: [selection: activation
by external interface, presentation of [assignment: types of authorization data required and
reference to their specification], no actions or conditions].
Application Note 17.
If the DSC provides factory reset and requires an authorization to carry out the operation then the
ST author selects either presentation of… and fills in the authorization data accepted (e.g. a PIN
or a cryptographic token based on some specification referenced in the assigned value). If the DSC
provides factory reset external to the DSC without requiring authorization then the ST author
selects activation by external interface. This selection is intended for use when the device
containing the DSC takes responsibility for obtaining and checking the authorization for factory
reset.
If any selection other than no actions or conditions is made in FDP_FRS_EXT.1.1, the selection-
based SFR FDP_FRS_EXT.2 must be claimed.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 58 of 140
6.4.5 FDP_ITC_EXT.1 Parsing of SDEs
FDP_ITC_EXT.1 Parsing of SDEs
FDP_ITC_EXT.1.1 The TSF shall support importing SDEs using [selection: physically protected
channels as specified in FTP_ITP_EXT.1, encrypted data buffers as specified in FTP_ITE_EXT.1,
cryptographically protected data channels as specified in FTP_ITC_EXT.1].
FDP_ITC_EXT.1.2 The TSF shall verify the integrity of the SDE using [selection: cryptographic
hash as specified in FCS_COP.1/Hash, keyed hash as specified in FCS_COP.1/HMAC, integrity-
providing encryption algorithm as specified in FCS_COP.1/KeyEnc [selection: SE1, SE2], digital
signature as specified in FCS_COP.1/SigVer, integrity verification supported by
FDP_ITC_EXT.1.1].
FDP_ITC_EXT.1.3 The TSF shall ignore any security attributes associated with the user data
when imported from outside the TOE.
FDP_ITC_EXT.1.4 The TSF shall bind SDEs to security attributes using [assignment: list of ways
the TSF generates security attributes and binds them to the SDEs].
Application Note 18.
The way the TSF checks the integrity of the SDE depends on the method of importation. For
example, the encrypted data channel may provide data integrity as part of its service.
When a TSF parses an SDE, it should generate security attributes and create an SDO by binding
the security attributes to the SDE.
If physically protected channels as specified in FTP_ITC_EXT.1 is selected, the selection-based
SFR FTP_ITP_EXT.1 must be claimed.
If encrypted data buffers as specified in FTP_ITE_EXT.1 is selected, the selection-based SFR
FTP_ITE_EXT.1 must be claimed.
If cryptographically protected data channels as specified in FTP_ITC_EXT.1 is selected, the
selection-based SFR FTP_ITC_EXT.1 must be claimed.
6.4.6 FDP_ITC_EXT.2 Parsing of SDOs
FDP_ITC_EXT.2 Parsing of SDOs
FDP_ITC_EXT.2.1 The TSF shall support importing SDOs using [selection: physically protected
channels as specified in FTP_ITP_EXT.1, encrypted data buffers as specified in FTP_ITE_EXT.1,
cryptographically protected data channels as specified in FTP_ITC_EXT.1].
FDP_ITC_EXT.2.2 The TSF shall verify the integrity of the SDO using [selection: cryptographic
hash as specified in FCS_COP.1/Hash, keyed hash as specified in FCS_COP.1/HMAC, integrity-
providing encryption algorithm as specified in FCS_COP.1/KeyEnc [selection: SE1, SE2], digital
signature as specified in FCS_COP.1/SigVer, integrity verification supported by
FDP_ITC_EXT.2.1].
FDP_ITC_EXT.2.3 The TSF shall use the security attributes associated with the imported user
data.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 59 of 140
FDP_ITC_EXT.2.4 The TSF shall ensure that the protocol used provides for the unambiguous
association between the security attributes and the user data received.
FDP_ITC_EXT.2.5 The TSF shall ensure that interpretation of the security attributes of the imported
user data is as intended by the source of the user data.
Application Note 19.
The way the TSF checks the integrity of the SDO depends on the method of importation. For
example, the encrypted data channel may provide data integrity as part of its service.
When a TSF parses an SDO, it should already have a set of security attributes. However, the TSF
may modify these attributes, if authorized, to comply with security policies on the TOE.
If physically protected channels as specified in FTP_ITC_EXT.1 is selected, the selection-based
SFR FTP_ITP_EXT.1 must be claimed.
If encrypted data buffers as specified in FTP_ITE_EXT.1 is selected, the selection-based SFR
FTP_ITE_EXT.1 must be claimed.
If cryptographically protected data channels as specified in FTP_ITC_EXT.1 is selected, the
selection-based SFR FTP_ITC_EXT.1 must be claimed.
6.4.7 FDP_MFW_EXT.1 Mutable/Immutable Firmware
FDP_MFW_EXT.1 Mutable/Immutable Firmware
FDP_MFW_EXT.1.1 The TSF shall be maintained as [selection: immutable, mutable]
firmware.
Application Note 20.
The ST author must include FDP_MFW_EXT.2, FDP_MFW_EXT.3, FPT_FLS.1/FW, and
FPT_RPL.1/Rollback if mutable is selected.
6.4.8 FDP_RIP.1 Subset Residual Information Protection
FDP_RIP.1 Subset Residual Information Protection
FDP_RIP.1.1 The TSF shall ensure that any previous information content of a resource is made
unavailable upon the [deallocation of the resource from] the following objects: [
 SDOs
 SDEs].
Application Note 21.
When an SDE is a key then it is also subject to the key destruction requirements in FCS_CKM.4,
depending on where and how it is stored. This SFR applies to authorization data that are SDEs
and security attributes in SDOs.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 60 of 140
6.4.9 FDP_SDC_EXT.1 Confidentiality of SDEs
FDP_SDC_EXT.1 Confidentiality of SDEs
FDP_SDC_EXT.1.1 The TSF shall use [selection: protected storage, symmetric encryption using
[selection: AES-CCM, AES-GCM, AES-CBC, AES-KWP, AES-KW, CAM-CBC, CAM-CCM,
CAM-GCM] as specified in FCS_COP.1/SKC, key wrapping using [selection: KAS1, KAS2,
KTS-OAEP] as specified in FCS_COP.1/KAT] to protect the confidentiality of authorization data
and [assignment: list of internally and externally stored SDEs identified in the Confidential SDE
List attribute of an SDO].
FDP_SDC_EXT.1.2 The TSF shall use FCS_CKM.1/KEK to derive or generate the key to
encrypt the SDEs.
Application Note 22.
This SFR applies to confidential SDEs, especially secret and private keys, Allowed Random
Number Generators’ state data, and vendor verification reference data. This SFR also applies to
all authorization data appearing in the attribute list under SDO.AuthData as well as any
administrator authorization data which may be stored implicitly.
If the TOE stores these parameters outside of its boundary, it must encrypt them according to the
cryptographic requirements for key encryption, as required by FDP_ETC_EXT.2.
Vendor pre-installed SDOs includes both objects installed during manufacturing, and those
provisioned by the vendor before final release to customer. The administrator and no one else
owns and controls these objects.
The confidential-SDE List attribute of the SDO indicates those SDEs that require confidentiality.
If SDEs do not require confidentiality, then its omission from this list indicates that confidentiality
is not required.
6.4.10 FDP_SDI.2 Stored Data Integrity Monitoring and Action
FDP_SDI.2 Stored Data Integrity Monitoring and Action
FDP_SDI.2.1 The TSF shall monitor SDOs and SDEs controlled by the TSF for [integrity errors]
on all objects, based on the following attributes: [selection: [assignment: attribute associated with
presence in protected storage], cryptographic hash, digital signature, integrity-providing
encryption algorithm as specified in FCS_COP.1/KeyEnc [selection: SE1, SE2]].
FDP_SDI.2.2 Upon detection of a data integrity error, the TSF shall [
 prohibit the use of the altered data
 send notification of the error where applicable].
Application Note 23.
This SFR deals with the mechanism that protects the integrity of the SDEs and security attributes
within an SDO. This provides the binding data that ensures the prevention of unauthorized changes
to the SDEs and attributes.
The cryptographic requirements for cryptographic hashes and digital signatures apply here.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 61 of 140
No specific requirement is placed here on the nature of the integrity protection data, but the
Security Target shall describe this protection measure, and shall identify the iteration of
FCS_COP.1/Hash or FCS_COP.1/HMAC that covers any cryptographic algorithm used.
The integrity protection data in FDP_SDI.2.1 is included in the list of attributes identified in
FMT_MSA.1, and protects the value of the SDEs and of the SDO security attributes.
When an SDO is parsed, its integrity is checked when it is imported into the TOE.
6.5 Identification and Authentication
When a platform process requests the ability to create, use, modify, dispose of, etc., an SDE or
SDO within the DSC, as a matter of policy, the DSC may expect or request authorization from the
platform process, which may include authentication of the requester on whose behalf the platform
process is acting. The DSC assumes the requester to be either a person, a process, or a device. The
rules on how the requester formats the request will be outside the scope of this cPP. Upon request
(or as a matter of an established protocol), the interface (on behalf of the user) presents to the DSC
process those authorization values required to authorize execution of the event request. This may
include one or more different types of authentication credentials. The DSC validates these items
before acting upon the requested event. The validation may simply compare the authorization
values to an expected value, or perform a more complex cryptographic protocol to verify the
authenticity of the user. After validation, the DSC may then create and subsequently use an
authorization value to represent the validation of these authorization values in anticipation of future
requests.
Requirements related to the strength, quality, and performance of authorization values supplied to
the DSC, such as X.509 certificates and biometric templates, are all outside the scope of the DSC
and are expected to be met by the platform, where applicable. The DSC is only expected to enforce
quality metrics on any authorization values it generates itself.
6.5.1 FIA_AFL_EXT.1 Authorization Failure Handling
FIA_AFL_EXT.1 Authorization Failure Handling
FIA_AFL_EXT.1.1 The TSF shall maintain [selection: a unique counter for [selection, choose
one of: each SDO, the following SDOs [assignment: list of SDOs]], one global counter covering
[selection, choose one of: all SDOs, the following SDOs [assignment: list of SDOs]]], called the
failed authorization attempt counters, that counts of the number of unsuccessful authorization
attempts that occur related to authorizing access to these SDOs.
FIA_AFL_EXT.1.2 The TSF shall maintain a [selection, choose one of: static, administrator
configurable variable] threshold of the minimal acceptable number of unsuccessful authorization
attempts that occur related to authorizing access to these SDOs.
FIA_AFL_EXT.1.3 When the failed authorization attempt counters [selection, choose one of:
meets, surpasses] the threshold for unsuccessful authorization attempts, the TSF shall [selection,
choose one of:
 prevent future authorization attempts for a static prescribed amount of time;
 prevent future authorization attempts for an administrator configurable amount of time;
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 62 of 140
 prevent all future authorization attempts indefinitely (i.e., lock), as described by
FIA_AFL_EXT.2;
 factory reset the TOE wiping out all non-persistent SDOs, as described by
FDP_FRS_EXT.2
] for these SDOs.
FIA_AFL_EXT.1.4 The TSF shall increment the failed authorization attempt counter before it
verifies the authorization.
Application Note 24.
The product validates the authorization factors prior to determining whether user (administrator
or client application) access to the SDE/SDO is permitted. In cases where validation of the
authorization factors fails, the product will not allow access to SDE/SDO. The product validates
the authorization factors in such a way that it does not allow an attacker to circumvent the other
requirements to gain knowledge about the SDE/SDO or other keying material that protects them
from inadvertent exposure.
It is possible for the TOE to have different rules for the treatment of different SDOs or groups of
SDOs. For example, some SDOs may trigger a factory reset in the event of excessive authorization
failures while others may only temporarily block future authorization attempts. The ST author
should iterate this SFR for each distinct response the TSF can make (as defined by the selections
in FIA_AFL_EXT.1.3) and the SDOs whose authorization failures will trigger these responses.
If prevent all future authorization attempts indefinitely (i.e., lock), as described by
FIA_AFL_EXT.2 is selected in FIA_AFL_EXT.1.3, the selection-based SFR FIA_AFL_EXT.2 must
be claimed.
If factory reset the TOE wiping out all non-persistent SDOs, as described by FDP_FRS_EXT.2 is
selected in FIA_AFL_EXT.1.3, the selection-based SFR FDP_FRS_EXT.2 must be claimed.
6.5.2 FIA_SOS.2 TSF Generation of Secrets
FIA_SOS.2 TSF Generation of Secrets
FIA_SOS.2.1 The TSF shall provide a mechanism to generate authorization data that meet [the
following quality metrics:
 For each authentication attempt, the probability shall be less than one in 1,000,000 that a
random attempt will be successful
 For multiple attempts to authenticate during a one-minute period, the probability shall be
less than one in 100,000 that a series of random attempts will be successful].
FIA_SOS.2.2 The TSF shall be able to enforce the use of TSF generated authorization data for
[assignment: non-empty list of TSF functions].
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 63 of 140
Application Note 25.
This SFR expects the TSF must generate authorization data from a sufficiently large key space to
ensure that users cannot employ random guessing as a statistically plausible method of authorizing
actions within the TOE, both for a single event and over a session.
6.5.3 FIA_UAU.2 User Authentication before Any Action
FIA_UAU.2 User Authentication before Any Action
FIA_UAU.2.1 The TSF shall require each user and SDO owner to be successfully authenticated
before authorizing any other TSF-mediated actions on behalf of that user or SDO owner.
Application Note 26.
This SFR goes with FDP_ACF.1, which authorizes access to SDOs (i.e. authorizes operations with
or on SDOs). The security policies in FDP_ACF.1 may require authentication of the subjects and
owners of the SDOs before the TSF authorizes access to them. An authentication token is critical
data bound to a user. Such data, when presented to the TOE and successfully verified by it,
authenticates the user. The TOE may use the successful authentication of a user as an
authorization to execute an action on its behalf, or to perform a requested operation on or with an
SDO.
This requirement specifies the TSF exercise an authentication mechanism from FIA_UAU.5 by
which the TOE authenticates the identity of the user requesting the operation and the owner of the
SDO which is an object in the operation. Such authentication is necessary to authorize it to operate
with the SDOs. A user could present a unique authentication token. The TSF may accept
authentication tokens with no further conditioning. The TSF validates the authentication token
prior to granting the authorization to perform the requested operation with the SDO. The SDO
security attribute SDO.Reauth determines whether or not the TOE may authenticate the user and
the SDO owner only once or each time each time it operates with the SDO.
The means of validation may vary based on the type of authentication token.
6.5.4 FIA_UAU.5 Multiple Authentication Mechanisms
FIA_UAU.5 Multiple Authentication Mechanisms
FIA_UAU.5.1 The TSF shall provide [selection: none, authentication token mechanism,
cryptographic signature mechanism, [assignment: list of authentication mechanisms]] to
support user authentication.
FIA_UAU.5.2 The TSF shall authenticate any user’s claimed identity according to the [selection:
all subject users and SDO owners shall successfully authenticate themselves using one of the
mechanisms listed in FIA_UAU.5.1, the Prove service shall not accept "none" as an
authentication method, [assignment: rules describing how each authentication mechanism
provides authentication]].
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 64 of 140
Application Note 27.
This SFR describes the authentication mechanisms required for any user of any service as a
precondition for providing authorization to execute the service. This includes the authentication
of the owner of the SDOs of the service.
6.5.5 FIA_UAU.6 Re-Authenticating
FIA_UAU.6 Re-Authenticating
FIA_UAU.6.1 The TSF shall re-authenticate the user for access to an SDO under the conditions:
[
1. Re-authentication and re-authorization by further successful completion of the
authentication and authorization methods in FIA_UAU.2, in accordance with the value of
the SDO.Reauth attribute of the SDO as follows:
a. If SDO.Reauth has the value ‘each access’;
b. if SDO.Reauth has the value 'policy' and the TSF determines that the TOE satisfies
the policy for re-authentication and reauthorization
].
Application Note 28.
The allowed values for the SDO.Reauth attribute of an SDO are defined in FMT_MSA.3 and the
SDO Attributes Initialization Table. The rules in FDP_ACF.1.2 and also ensure that the need for
re-authorization has been checked before access to an SDO.
An SDO.Reauth value of ‘none’ indicates that no authentication of the subject user nor of the SDO
owners is necessary. It also indicates that no reauthorization for operations using the SDO is
necessary.
An SDO.Reauth value of policy indicates that there may be a more complicated set of
circumstances that trigger a re-auth (re-authentication of the users and owners as well as re-
authorization of the operation). This could be a policy of a time limit for which a user can use an
SDO before re-authentication (e.g. 10 minutes or 24 hours). The ST should indicate the policies
allowed, and how the TOE evaluates the policies. The ST should also indicate the location of those
policies, and how the TOE protects the integrity of those policies.
When the TSF binds a user to access an SDO, this means that the TSF has authenticated the user
and that the TSF authorized the user to have the right to exercise one or more of the following
actions: generate the SDO, modify the SDO, including its security attributes, use the SDO in a
TOE operation, propagate or duplicate the SDO for use by a device external to the DSC, or destroy
the SDO. The user may not have exclusive rights to exercise the operations listed.
Policy as represented by the attributes in the SDO dictates whether or not a user must authenticate
itself in order to authorize access to the SDO.
It is possible that the attributes of some SDOs should remain unchanged, and that the attributes
of other SDOs may be changed by authorized users. If this is the case, then the ST author should
iterate this SFR and indicate in the TSS which SDOs apply to each iteration.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 65 of 140
6.6 Security Management
6.6.1 FMT_MOF_EXT.1 Management of Security Functions Behavior
FMT_MOF_EXT.1 Management of Security Functions Behavior
FMT_MOF_EXT.1.1 The TSF shall restrict the ability to perform the functions in FMT_SMF.1
to authenticated administrators.
6.6.2 FMT_MSA.1 Management of Security Attributes
FMT_MSA.1 Management of Security Attributes
FMT_MSA.1.1 The TSF shall enforce the [Access Control SFP] to restrict the ability to [modify]
the security attributes [assignment: list of security attributes, to include attributes as specified in
the Supported Methods for SDO Attributes table] to [the authorized identified roles as specified
in the Supported Methods for SDO Attributes table].
SDO Attribute Modification Constraints
SDO.ID Cannot be modified
SDO.Type Cannot be modified
SDO.AuthData [assignment: list of roles that are authorized to modify SDO reference
authorization data]
SDO.Reauth [assignment: list of roles that are authorized to modify re-authorization
conditions]
SDO.Conf [assignment: list of roles that are authorized to modify confidential SDE-
list]
SDO.Export [assignment: list of roles that are authorized to modify export flag]
SDO.Integrity Cannot be modified by users (maintained automatically by TSF)
SDO.Bind Cannot be modified by users (maintained automatically by TSF)
Table 10: Supported Methods for SDO Attributes
Application Note 29.
The SDO Attributes Modification Table defines the required constraints on security attribute
modification. The Security Target completes the other parts not specified here (along with any
other information for other security attributes relevant to a particular TOE).
The assignments of authorized subjects in the SDO Attributes Modification Table may be defined
by the ST author in terms of roles or in terms of an action such as presentation of a valid
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 66 of 140
authentication token of a particular type (in this case the ST author identifies in an Application
Note the other SFRs that govern the action).
The TSF vendor may pre-install SDOs with default attributes. The Security Target should make
clear which attributes the administrators may change or are prohibited from changing. It should
also make clear between authorization values required to use pre-installed SDOs and
authorization values required to change the attributes of pre-installed SDOs.
The SDO Attributes Modification Table lists SDO ID as “cannot be modified”. In some cases, a
change in the attributes may cause a change in the SDO ID. In these cases, a change in the SDO
ID causes the creation of a new SDO and possibly the loss of the old SDO.
Only authorized subjects can change the attributes of an SDO, and only as permitted in the SDO
Attributes Modification Table.
6.6.3 FMT_MSA.3 Static Attribute Initialization
This SFR deals with the initialization of the attributes of an SDO when it is created by parsing or
provisioning. The generation process includes SDOs created by the TSF (provisioned) and those
imported via FDP_ITC_EXT.2 (parsed).
The TSF is expected to give an SDO a set of security attributes at the time of its creation. This set
is expected to include at least the following attributes:
 SDO identifier
 SDO type
 SDO reference authorization data (i.e. the data that is used when determining whether to
grant access to an SDO, for each relevant mode of access, on the basis of an authorization
token presented to the DSC)
 Re-authorization conditions (i.e. event after which re-authorization is required)
 Confidential-SDE list (each SDE in this list is held encrypted when the SDO is stored)
 Export Flag (indicating whether the SDO is allowed to be propagated)
 Integrity protection data
 Binding Data (created by the TOE to strongly link or associate the SDO with other entities
such as the TOE itself or with other SDOs in a hierarchy such as a child to a parent).
The TSF provides the capability to protect the contents of an SDO (i.e. the set of its SDEs together
with the SDO attributes) from unauthorized modification. The DSC shall check for such
modifications before using the SDO or any of its SDEs.
FMT_MSA.3 Static Attribute Initialization
FMT_MSA.3.1 The TSF shall enforce the [Access Control SFP] to provide [selection, choose one
of: restrictive, permissive, [assignment: other property]] default values for security attributes that
are used to enforce the SFP.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 67 of 140
FMT_MSA.3.2 The TSF shall allow the [authorized identified roles, according to the Supported
Methods for SDO Attributes Initialization table] to specify alternative initial values to override the
default values when an object or information is created.
SDO Attribute Property Authorized Override
Role
Initialization Method Allowed Values
SDO.ID Restrictive None Import and generation
process
[assignment: range of
allowed values]
SDO.Type Restrictive None Import and generation
process
[assignment: list of
allowed types]
SDO.AuthData Permissive [selection: admin, client
application]
Import process [selection: none,
[assignment: list of
types of authentication
tokens allowed],
[assignment: range of
authorization values
allowed]]
Restrictive None Generation process
SDO.Reauth Restrictive None Import and generation
process
[selection: none, each
access, policy]
SDO.Conf Restrictive None Import and generation
process
[assignment: list of
SDEs of which the
TOE must provide a
confidentiality service]
SDO.Export Restrictive None Import and generation
process
[selection: exportable,
non-exportable]
SDO.Integrity Restrictive None Import and generation
process
[assignment: range of
allowed values]
SDO.Bind Restrictive None*
Import and generation
process
[assignment: range of
allowed values]
Table 11: Supported Methods for SDO Attributes Initialization
Application Note 30.
Both admin and client application roles can initiate the import process. The imported object
contains the default values for each attribute, where allowed. The TSF can override default values
for the following attributes of imported objects: SDO.ID, SDO.Type, SDO.Reauth, SDO.Export,
and SDO.Integrity. The TSF may override default values in these cases to force the objects to
comport to established structures within the TOE, or to comply with TOE-wide security policies.
In these cases, the defined roles (i.e. admin and client application) cannot override the default
values. For SDO.AuthData, the TSF shall allow user roles (i.e. admin and client applications) to
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 68 of 140
override authorization data that may arrive with the object. For SDO.Conf the TSF accepts the
imported value for this attribute. SDO.Bind is explained below.
Unless otherwise noted, both admin and client application roles can initiate the generation
process. The admin and client application will provide the default values for the attributes. This
SFR assumes the TSF checks SDO.Type, SDO.AuthData, SDO.Reauth, SDO.Conf, and
SDO.Export for compliance with established security policies and refuses to create objects which
do not comply and thus will not override the value of any of these attributes. In the cases of the
SDO.ID and SDO.Integrity, the TSF generates these values and therefore there is no need to
override.
In the case of SDO.Bind for both import and generation processes, the TSF may override values
that denote a binding to the TOE, but it should not override values that denote a binding to other
keys. In the case of the import process, the defined roles cannot override the default values for any
binding.
The SDO Attributes Initialization Table is referenced from FMT_MSA.3 and matches the attributes
covered by FMT_MSA.1 (which defines controls on the modification of the attributes). The
initialization of these security attributes occurs when an SDO is either parsed by the TOE or
generated on the TOE. The required constraints on security attribute initialization specified in this
PP are shown in Table 11; the Security Target completes the selection and assignments in the SFR
and adds to the table any other information for other security attributes relevant to a particular
TOE.
The SDO.AuthData attribute is data that is required in order to validate authorization of a subject
to access the SDO (in each of the modes relevant to that SDO). The nature of this data will depend
on the authorization mechanism used in the TOE, as described in FIA_UAU.2.
The SDO.Reauth attribute for an individual SDO takes one of the values defined in the selection
in the Allowed Values column of Table 11. Examples of TOE-specified events might be explicit
revocation of authorization by a user, expiry of a time interval, or completion of a fixed number of
uses since the last authorization. The re-authorization conditions are used in FIA_UAU.6 and
FDP_ACF.1. These determine whether a single authorization by the SDO owner will allow any
number of uses of the SDO until the end of the user’s session (value ‘none’), or whether each use
of the SDO must be individually authorized (value ‘each access’), or whether re-authorization
must happen each time one of the TOE-specified events occurs.
The SDO.Conf attribute indicates which SDEs, if any, the TOE should encrypt when not in
operational use. The TOE should use the methods in FCS_COP.1/SKC, FCS_STG_EXT.1, or
FCS_STG_EXT.2 to protect the SDEs in this list.
The SDO.Export attribute takes one of the values ‘exportable’ or ‘non-exportable’.
The SDO.Integrity attribute includes evidence that the TSF can use to protect and verify the
integrity of the SDO.
Attributes assigned by the TOE to any parsed SDOs must be described in the Security Target and
in operational user guidance.
The TOE uses the Binding Data for an SDO to strongly link the SDO to the TOE, a parent SDO in
a hierarchy, or to nothing at all. SDOs bound to nothing may freely travel from one TOE to another
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 69 of 140
without restrictions. If bound to another SDO as a child to a parent in a hierarchy, it may travel
only where the parent SDO travels. If bound to the TOE, it may travel to any other TOE for any
reason, even if the TOE moves its parent to another TOE. Note that vendors will initialize attributes
of pre-installed SDOs with default values. However, authorization values to change the attributes
of pre-installed SDOs may differ from the authorization value required to use the pre-installed
SDO.
The vendor should document the implicit attributes for pre-installed SDOs and SDOs stored in
special locations.
In cases in which the SDO ID is a cryptographic hash of the attributes and SDEs, that value
represents both the ID and projects the integrity of the SDO, including the SDEs. As the TOE
unwraps an incoming SDO, it may automatically check the integrity. For pre-installed SDOs in
protected storage, the hardware plus the TSF projects the integrity of them.
When a remote peer sends an SDO to the TOE, it properly indicates through the SDE-
confidentiality list of any authorization values and authentication tokens present in the SDO,
whether they are present in the SDE or as attributes, which control access to the SDE.
When a TOE generates an SDO internally for the first time, it properly indicates through the SDE-
confidentiality list any SDEs that are authorization values or authentication tokens. Similarly, if
any of the attributes are authorization values or authentication tokens, the TOE will properly
indicate through the SDE-confidentiality list that it will encrypt them prior to storing them.
The TOE may contain pre-installed SDOs or SDOs either provisioned the first time the user turns
on the TOE or provisioned as the result of a “factory reset” event. TSFs may refer to such
persistent SDOs as root keys or trusted anchors. Pre-installed SDOs may reside in immutable
hardware and persist across factory resets. Other persistent SDOs may persist until a user issues
a “factory reset” which either cryptographically erases the SDOs or overwrites them by
provisioning new ones. These SDOs may not contain a confidential SDE list since either these
persistent values serve as a root encryption key for a hierarchy of SDOs, or they serve as a KDF
seed for generating root encryption keys for a hierarchy of SDOs.
It is possible that the default attributes of some SDOs should be restrictive, and that the default
attributes of other SDOs may be permissive. If this is the case, then the ST author should iterate
this SFR and indicate in the TSS what the default attribute properties are for each SDO.
6.6.4 FMT_SMF.1 Specification of Management Functions
FMT_SMF.1 Specification of Management Functions
FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: [
 Set authorization failure parameters for FIA_AFL_EXT.1
 Reset TOE to factory state for FDP_FRS_EXT.1
 Configure authorization policies for TOE resources
[selection:
 update TOE firmware and pre-installed SDOs,
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 70 of 140
 unlock access to SDO following excessive failed authorization attempts,
 no other functions]].
Application Note 31.
If FDP_MFW_EXT.1 selects mutable firmware, then FMT_SMF.1 must select Update TOE
firmware and pre-installed SDOs.
Recall that resetting a TOE to factory state also wipes all user data, but may not wipe out pre-
installed SDOs. Configuring authorization policies includes setting policies for allowed access to
SDOs.
Protections for pre-installed SDEs/SDOs come through the firmware, and by extension, through
firmware updates. In the same vein, the authorized updates may also affect the SDEs as well, if the
vendor so chooses. One could say that the authorized update binds the attributes present in the
functionality of the firmware to the pre-installed SDEs.
6.6.5 FMT_SMR.2 Restrictions on Security Roles
FMT_SMR.2 Restrictions on Security Roles
FMT_SMR.2.1 The TSF shall maintain the roles: [administrator, client application].
FMT_SMR.2.2 The TSF shall be able to associate users with roles.
FMT_SMR.2.3 The TSF shall ensure that the conditions [
 Only client applications can access their own encrypted data,
 Only administrators can perform privileged functions]
are satisfied.
Application Note 32.
This cPP uses the term “user” throughout to reference both the administrator and client
application roles simultaneously.
6.7 Protection of the TSF
6.7.1 FPT_FLS.1/FI Failure with Preservation of Secure State (Fault Injection)
FPT_FLS.1/FI Failure with Preservation of Secure State (Fault Injection)
FPT_FLS.1.1/FI The TSF shall preserve a secure state when the following types of failures occur:
[fault injections].
Application Note 33.
Note that a secure state does not imply the uninterrupted enforcement of all claimed security
functionality it is appropriate for the TSF to “fail closed” and block the execution of security-
relevant behavior if a fault injection attempt or other significant glitch occurs.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 71 of 140
6.7.2 FPT_MOD_EXT.1 Debug Modes
FPT_MOD_EXT.1 Debug Modes
FPT_MOD_EXT.1.1 The TSF shall provide no access to debug modes.
Application Note 34.
‘Debug modes’ may include, but are not limited to, any alternate mode of operation, such as
developer mode, test mode, manufacturer mode, or altered boot mode.
6.7.3 FPT_PHP.3 Resistance to Physical Attack
FPT_PHP.3 Resistance to Physical Attack
FPT_PHP.3.1 The TSF shall resist [data extraction via fault injection, extreme temperatures,
abnormal voltage] to the [TSF storage elements that contain [selection: SDEs, SDOs, firmware]]
by responding automatically such that the SFRs are always enforced.
Application Note 35.
Physical protection mechanisms as envisioned by this requirement are mechanisms that protect
communications to the extent that encryption or other logical protections are not required to
ensure confidentiality, integrity, and assured identification of endpoints. Such mechanisms may
include, for example, physically isolated traces, or mechanisms that take advantage of physical
properties of signals to ensure that communications are receivable only by the intended endpoint.
Any physical external casing or potting material of the TOE is considered an ‘external interface’,
not just those interfaces over which data is transmitted. This ensures that the TSF will respond
appropriately if, for example, an attacker penetrates the physical surface of the DSC in an attempt
to access its stored data.
The TOE’s protection against abnormal temperature and voltage can be considered equivalent to
what is required by assertion AS07.77 of [ISO-TR].
6.7.4 FPT_PRO_EXT.1 Root of Trust
FPT_PRO_EXT.1 Root of Trust
FPT_PRO_EXT.1.1 The TSF shall contain an SDO that contains the identity of the Root of Trust.
Application Note 36.
Every DSC is expected to have a single RoT that comprises the DSC hardware and pre-installed
SDOs, from which services (e.g. Storage, Authorization, etc.) can be offered.
Depending on the use case and the way status registers are used, unique identity keys may be
bound to the TOE, the TOE platform, or both.
The sole presence of unique identity keys linking to the RoT does not prove authenticity without
the use of digital signatures.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 72 of 140
FPT_PRO_EXT.1.2 The TSF shall maintain Root of Trust data as [selection: immutable, mutable
if and only if its mutability is controlled by a unique identifiable owner].
Application Note 37.
One expects that only authorized sources can modify the single RoT, such as through a secure
update. A pre-installed SDO may contain the identity of the manufacturer of the RoT.
The process of authenticating the source of a secure update may involve querying the identity of
the manufacturer, contained on a pre-installed SDO. If this identity is in the form of an X.509
certificate containing a signature verification key signed by the manufacturer, then the
authentication process is sufficient.
A unique identifiable owner is assumed to be one with an administrative role; however, there may
be circumstances where the owner does not take on an administrative role, which should be
documented.
6.7.5 FPT_ROT_EXT.1 Root of Trust Services
FPT_ROT_EXT.1 Root of Trust Services
FPT_ROT_EXT.1.1 The TSF shall provide a Root of Trust for Storage, a Root of Trust for
Authorization, and [selection: Root of Trust for Measurement, Root of Trust for Reporting, no
others].
Application Note 38.
This document uses the [GP_ROT] definitions for RoT for Storage (denoted as the combination of
RoT for Confidentiality and RoT for Integrity), Authorization, Measurement, and Reporting. DSCs
use Roots of Trust for Storage to protect SDOs. Section 6.5 has a number of requirements for
ensuring the TSF has functionality to authorize a user in order to access an SDO, including
FIA_UAU.6.
If both Root of Trust for Measurement and Root of Trust for Reporting are selected in
FPT_ROT_EXT.1.1, the selection-based SFR FDP_DAU.1/Prove must also be claimed.
6.7.6 FPT_ROT_EXT.2 Root of Trust for Storage
FPT_ROT_EXT.2 Root of Trust for Storage
FPT_ROT_EXT.2.1 The TSF shall prevent unauthorized access to SDOs associated with the
Root of Trust for Storage.
Application Note 39.
TOEs may use shielded locations or cryptographic protections to prevent unauthorized access to
SDOs. Use FDP_SDI.2 to protect the integrity of SDOs stored in the RoT for Storage.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 73 of 140
6.7.7 FPT_RPL_EXT.1 Replay Prevention
FPT_RPL_EXT.1 Replay Prevention
FPT_RPL_EXT.1.1 The TSF shall have a mechanism for preventing replay of user authorization
of operations on SDOs using the following methods [selection: monotonic counters, random
nonces, [assignment: other methods as specified]].
FPT_RPL_EXT.1.2 The TSF shall detect replay for the following actions: [authorization of
operations on SDOs].
FPT_RPL_EXT.1.3 The TSF shall deny the requested operation on the SDO when it detects a
replay.
Application Note 40.
The TSF receives authorization from an external source to the DSC to perform an operation on
an SDO. If the operation on the SDO is restricted to authorized users, then anyone observing the
communication to the DSC can copy the authorization and replay it. Random nonces and
monotonic counters are but two mechanisms the TSF can use to mitigate replay. In this
requirement, operations on SDOs include generating, using, modifying, propagating, and
destroying. Besides monotonic counters and random nonces, the TSF could employ other methods
to prevent replay of user authorizations, which the Security Target should describe.
This requirement does not specify how TSF detects replays.
6.7.8 FPT_STM.1 Reliable Time Stamps
FPT_STM.1 Reliable Time Stamps
FPT_STM.1.1 The TSF shall be able to provide reliable time stamps.
Application Note 41.
It is acceptable for the TSF to provide timestamp data either through an internal clock or a
counter. It is also permissible for the TSF to obtain time data from a clock contained within the
same physical enclosure as the TOE.
6.7.9 FPT_TST.1 TSF Testing
FPT_TST.1 TSF Testing
FPT_TST.1.1 The TSF shall run a suite of self tests during power-on start-up, [selection:
periodically during normal operation, at the request of the authorized user, at no other condition,
at the conditions [assignment: conditions under which self test should occur]] to demonstrate the
correct operation of [the TSF].
FPT_TST.1.2 The TSF shall provide authorized users with the capability to verify the integrity
of [TSF data].
FPT_TST.1.3 The TSF shall provide authorized users with the capability to verify the integrity of
the [TSF].
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 74 of 140
Application Note 42.
This requirement intends to cover integrity of the TSF functionality (i.e. runtime checks).
TSF integrity testing provides the ability to test the TSF’s correct operation. These tests are
expected to be performed automatically and autonomously at start-up but may also be performed
periodically during operation, at the request of the authorized user, or when other conditions are
met. It also provides the ability to verify the integrity of TSF data and executable code.
All cryptographic functions come with known answer tests (KATs). In addition to verifying the
integrity of the firmware executing the TSF, the DSC should also verify the integrity of any data
associated with the TSF (such as constants for cryptographic algorithms) as well as performing
the KATs.
6.8 Resource Utilization
6.8.1 FRU_FLT.1 Degraded Fault Tolerance
FRU_FLT.1 Degraded Fault Tolerance
FRU_FLT.1.1 The TSF shall ensure the operation of [protection of TSF data] when the following
failures occur: [fault injection].
Application Note 43.
TSF data may be protected in response to a fault injection either by providing a method to ensure
that the data remains protected or by logically destroying the data or any part of a key change
that encrypts it. This behavior may differ based on the type of fault.
6.9 TOE Security Functional Requirements Rationale
The following rationale provides justification for each security objective for the TOE, showing
that the SFRs are suitable to meet and achieve the security objectives:
Objective Addressed by Rationale
O.AUTH_FAILURES FIA_AFL_EXT.1 This requirement enforces authentication
failure handling capabilities to ensure that
brute force attacks on the TSF are not possible.
FIA_SOS.2 This requirement protects against brute force
authentication by generating secrets that are
statistically impossible to guess.
FPT_STM.1 This requirement provides reliable system time
services that may be used to determine when
excessive authentication failure attempts have
been made.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 75 of 140
Objective Addressed by Rationale
FIA_AFL_EXT.2
(selection-based)
This requirement defines how access to an
SDO is restored if excessive authentication
failures trigger a lock on it.
O.AUTHORIZATION FCS_STG_EXT.1 This requirement ensures that key data is
placed into protected storage and cannot be
modified by untrusted subjects.
FDP_ACC.1 This requirement defines an access control
policy that governs the authorization required
to interact with SDOs.
FDP_ACF.1 This requirement defines the rules enforced by
the access control policy defined in
FDP_ACC.1 to control access to SDOs.
FDP_ETC_EXT.2 This requirement ensures that protected data
propagated outside the TOE is not disclosed to
any unauthorized subjects.
FIA_UAU.2 This requirement defines the methods by which
users authenticate to the TOE to prove their
identity prior to interacting with any protected
data.
FIA_UAU.5 This requirement provides the TSF with the
ability to specify the use of multiple
authentication mechanisms as a prerequisite to
granting access to protected functions or data.
FIA_UAU.6 This requirement defines when authorization
checks are performed for user requests to
access SDOs.
FMT_MOF_EXT.1 This requirement enforces access control on
the management functions provided by the
TOE.
FMT_MSA.1 This requirement enforces restrictions on the
subjects that can interact with SDOs and their
attributes.
FMT_MSA.3 This requirement defines the default access
restrictions that are enforced on SDO attributes
if not overridden by specific access control
policy rules.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 76 of 140
Objective Addressed by Rationale
FMT_SMF.1 This requirement defines the management
functions that are provided by the TOE to
authorized subjects.
FMT_SMR.2 This requirement defines the roles used by the
TSF for enforcement of access control to
protected functions and data.
FPT_FLS.1/FI This requirement ensures that fault injections
cannot be used to circumvent access control
policy restrictions preventing a user from
accessing protected functions or data.
FPT_MOD_EXT.1 This requirement ensures that there are no
accessible debug modes that could be used to
circumvent access control policy restrictions
preventing a user from accessing protected
functions or data.
FPT_PHP.3 This requirement ensures that some mechanism
is in place to thwart unauthorized attempts to
access protected functions or data through
physical tampering of the TOE.
FPT_PRO_EXT.1 This requirement defines the RoT for the TOE,
which is used to derive all access control
functionality.
FPT_ROT_EXT.2 This requirement enforces the RoT for Storage
to enforce access control against SDOs.
FRU_FLT.1 This requirement ensures that fault injection
attempts do not interfere with the enforcement
of access control against protected data.
FIA_AFL_EXT.2
(selection-based)
This requirement defines the access control
that is enforced on an SDO if excessive
authentication failures block access to it.
O.DATA_PROTECTION FCS_COP.1/Hash This requirement provides a cryptographic
operation for asserting the integrity of SDOs.
FCS_COP.1/HMAC This requirement provides a cryptographic
operation for asserting the authenticity of
SDOs.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 77 of 140
Objective Addressed by Rationale
FCS_COP.1/SigGen This requirement provides a cryptographic
operation for preserving the authenticity of
SDOs.
FCS_COP.1/SigVer This requirement provides a cryptographic
operation for asserting the authenticity of
SDOs.
FCS_COP.1/SKC This requirement provides a cryptographic
operation for maintaining the confidentiality of
SDOs.
FCS_STG_EXT.1 This requirement ensures that key data is
placed into protected storage and cannot be
modified by untrusted subjects.
FCS_STG_EXT.2 This requirement ensures that confidentiality of
key storage is maintained using strong
cryptography.
FCS_STG_EXT.3 This requirement ensures that integrity of key
storage is maintained using strong
cryptography.
FDP_ETC_EXT.2 This requirement ensures that the
confidentiality of protected data propagated
outside the TOE is maintained.
FDP_ITC_EXT.1 This requirement ensures that all SDEs parsed
by the TOE have verifiable integrity.
FDP_ITC_EXT.2 This requirement ensures that all SDOs parsed
by the TOE have verifiable integrity.
FDP_SDC_EXT.1 This requirement ensures that SDEs/SDOs are
stored with confidentiality and that all
authorization data is protected prior to storage.
FDP_SDI.2 This requirement ensures that SDEs/SDOs are
monitored for integrity violations.
FPT_ROT_EXT.1 This requirement defines the RoT services that
are available for the protection of data.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 78 of 140
Objective Addressed by Rationale
FPT_RPL_EXT.1 This requirement ensures that access control
restrictions cannot be bypassed through replay
of operations.
FPT_ITT.1
(optional)
This requirement ensures that confidentiality
and integrity is maintained in cases where data
is transmitted between physically separate parts
of a distributed TOE.
FPT_PRO_EXT.2
(optional)
This requirement ensures that the TSF can
produce attestation of the integrity of its stored
data.
FPT_ROT_EXT.3
(optional)
This requirement allows the TSF to provide a
RoT for Reporting that can provide assured
information about the stored SDEs.
FDP_DAU.1/Prove
(selection-based)
This requirement defines the Prove service that
can be used to invoke the Roots of Trust for
Measurement and Reporting and provide
affirmation of the validity of stored data.
O.FW_INTEGRITY FDP_MFW_EXT.1 This requirement specifies whether the TOE’s
firmware is mutable or immutable, to
determine the extent to which this is objective
must be satisfied by other SFRs.
FPT_ROT_EXT.1 This requirement defines the RoT services that
are available in the TOE, which can include
Roots of Trust for measurement and reporting.
FPT_TST.1 This requirement defines the mechanisms used
to verify and attest to the integrity of the TSF.
FDP_DAU.1/Prove
(selection-based)
This requirement defines the Prove service that
can be used to invoke the Roots of Trust for
Measurement and Reporting and provide
affirmation of the validity of the TSF.
FDP_MFW_EXT.2
(selection-based)
This requirement ensures that the TSF can
generate evidence that its mutable firmware
integrity remains intact.
FDP_MFW_EXT.3
(selection-based)
This requirement ensures that any firmware
updates to the TSF are genuine.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 79 of 140
Objective Addressed by Rationale
FPT_FLS.1/FW
(selection-based)
This requirement requires the TSF to take
action to preserve its secure operation if any
violations to its firmware integrity are detected.
O.PARSE_PROTECTION FDP_ITC_EXT.1 This requirement ensures that all SDEs parsed
by the TOE are transmitted over a secure
channel.
FDP_ITC_EXT.2 This requirement ensures that all SDOs parsed
by the TOE are transmitted over a secure
channel.
FDP_SDC_EXT.1 This requirement ensures that the
confidentiality of authorization data is
protected prior to storage.
FTP_ITC_EXT.1
(selection-based)
This requirement defines a cryptographically
protected channel that the TSF can use to
securely parse data being imported into it.
FTP_ITE_EXT.1
(selection-based)
This requirement defines the cryptographic
method used to transfer data between the TOE
and external entities.
FTP_ITP_EXT.1
(selection-based)
This requirement defines a physically protected
channel that the TSF can use to securely parse
data being imported into it.
O.PURGE_PROTECTION FCS_CKM.4 This requirement ensures that key data is
destroyed in a manner that prevents its future
recovery.
FCS_CKM_EXT.4 This requirement ensures that key data is not
retained for any longer than necessary for its
intended usage.
FDP_FRS_EXT.1 This requirement defines the condition in
which a factory reset will be initiated, which
triggers a purge of stored SDEs.
FDP_RIP.1 This requirement ensures that any purged
SDEs/SDOs are erased in residual memory so
that their future recovery is prevented.
FDP_FRS_EXT.2
(selection-based)
This requirement ensures that all user-specific
SDOs are purged upon factory reset and may
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 80 of 140
Objective Addressed by Rationale
indicate any factory default SDOs that are reset
to their initial values.
O.SECURE_UPDATE FDP_MFW_EXT.1 This requirement specifies whether the TOE’s
firmware is mutable or immutable.
FPT_FLS.1/FW
(selection-based)
This requirement requires the TSF to take
action to preserve its secure operation if a
rollback attempt or invalid firmware update is
detected.
FPT_RPL.1/Rollback
(selection-based)
This requirement ensures that the TSF will not
permit rollback attempts of its firmware.
O.STRONG_BINDING FDP_ITC_EXT.1 This requirement ensures that all SDEs parsed
by the TOE include appropriate binding
metadata.
O.STRONG_CRYPTO FCS_CKM.1 This requirement specifies the supported
methods of key generation.
FCS_CKM.1/KEK This requirement ensures the generation of
strong key encryption keys.
FCS_CKM.2 This requirement ensures the use of strong key
establishment mechanisms.
FCS_COP.1/Hash This requirement ensures the use of strong hash
mechanisms.
FCS_COP.1/HMAC This requirement ensures the use of string
HMAC mechanisms.
FCS_COP.1/KAT This requirement ensures the use of strong
methods to perform key agreement and key
transport.
FCS_COP.1/KeyEnc This requirement ensures the use of strong
methods to perform key encryption.
FCS_COP.1/SigGen This requirement ensures the use of strong
digital signature services.
FCS_COP.1/SigVer This requirement ensures the use of strong
digital signature services.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 81 of 140
Objective Addressed by Rationale
FCS_COP.1/SKC This requirement ensures the use of strong
methods to encrypt sensitive data.
FCS_RBG_EXT.1 This requirement ensures the use of strong
random bit generation mechanisms.
FCS_SLT_EXT.1 This requirement ensures that salts and nonces
used by the TOE do not negatively impact key
strength.
FCS_STG_EXT.2 This requirement ensures that confidentiality of
key storage is maintained using strong
cryptography.
FCS_STG_EXT.3 This requirement ensures that integrity of key
storage is maintained using strong
cryptography.
FPT_STM.1 This requirement provides reliable system time
services that may be used as inputs to
cryptographic functions.
FCS_ENT_EXT.1
(optional)
This requirement provides an interface to
access entropy data so that the TSF can support
the use of strong cryptography in its
operational environment.
FCS_RBG_EXT.2
(optional)
This requirement provides an external interface
to seed the random bit generator that enforces
strong cryptography by requiring a minimum
amount of input.
FCS_CKM.1/AK
(selection-based)
This requirement ensures the generation of
strong asymmetric keys.
FCS_CKM.1/SK
(selection-based)
This requirement ensures the generation of
strong symmetric keys.
FCS_CKM_EXT.5
(selection-based)
This requirement ensures the use of strong
mechanism to perform key derivation.
FCS_COP.1/PBKDF
(selection-based)
This requirement ensures the use of strong
methods to derive keys from password data.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 82 of 140
Objective Addressed by Rationale
FTP_CCMP_EXT.1
(selection-based)
This requirement defines the implementation of
CCMP (IEEE 802.11i) using strong
cryptography.
FTP_GCMP_EXT.1
(selection-based)
This requirement defines the implementation of
GCMP (IEEE 802.11ad) using strong
cryptography.
FTP_ITE_EXT.1
(selection-based)
This requirement defines the cryptographic
method used to transfer data between the TOE
and external entities.
Table 12: SFR-Objective Rationale
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 83 of 140
7 Security Assurance Requirements
This cPP identifies the Security Assurance Requirements (SARs) to frame the extent to which the
evaluator assesses the documentation applicable for the evaluation and performs independent
testing.
This section lists the set of SARs from CC part 3 that are required in evaluations against this cPP.
Individual Evaluation Activities to be performed are specified in [SD].
The general model for evaluation of TOEs against STs written to conform to this cPP is as follows:
After the ST has been approved for evaluation, the ITSEF will obtain the TOE, supporting
environmental IT (if required), and the administrative/user guides for the TOE. The ITSEF is
expected to perform actions mandated by the Common Evaluation Methodology (CEM) for the
ASE and ALC SARs. The ITSEF also performs the Evaluation Activities contained within the SD,
which are intended to be an interpretation of the other CEM assurance requirements as they apply
to the specific technology instantiated in the TOE. The Evaluation Activities that are captured in
the SD also provide clarification as to what the developer needs to provide to demonstrate the TOE
is compliant with the cPP.
Assurance Class Assurance Components
Security Target (ASE) Conformance Claims (ASE_CCL.1)
Extended Components Definition (ASE_ECD.1)
ST Introduction (ASE_INT.1)
Security Objectives (ASE_OBJ.2)
Derived Security Requirements (ASE_REQ.2)
Security Problem Definition (ASE_SPD.1)
TOE Summary Specification (ASE_TSS.1)
Development (ADV) Basic Functional Specification (ADV_FSP.1)
Guidance Documents (AGD) Operational User Guidance (AGD_OPE.1)
Preparative Procedures (AGD_PRE.1)
Life cycle Support (ALC) Labelling of the TOE (ALC_CMC.1)
TOE CM Coverage (ALC_CMS.1)
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 84 of 140
Assurance Class Assurance Components
Tests (ATE) Independent Testing – Conformance (ATE_IND.1)
Vulnerability Assessment (AVA) Vulnerability Survey (AVA_VAN.1)
Table 13: Security Assurance Requirements
7.1 ASE: Security Target
The ST is evaluated as per ASE activities defined in the CEM. In addition, there may be Evaluation
Activities specified within the SD that call for necessary descriptions to be included in the TSS
that are specific to the TOE technology type.
In addition to using the ST to demonstrate that ASE_TSS.1 has been satisfied, this cPP requires
the creation of supplemental documentation to justify how the TOE satisfies certain SFRs. This
documentation is separated from the ST because the required level of detail may include
information that is proprietary to the developer of the TOE. The required supplemental
documentation includes entropy documentation and key management documentation. The
requirements for the entropy documentation are described in Appendix D of this cPP. The
requirements for the key management documentation are described in the SD under the SFRs that
require a detailed description of the TSF’s key management.
7.2 ADV: Development
The design information about the TOE is contained in the guidance documentation available to the
end user as well as the TSS portion of the ST, and any additional information required by this cPP
that is not to be made public (e.g., Entropy Essay). The DSC cPP requires only basic functional
specification of interfaces presented in the AGD documentation (see 6.2.1) and specification of
interfaces that can be invoked by a dependent component in a composed evaluation where the DSC
is the base component.
7.2.1 Basic Functional Specification (ADV_FSP.1)
The functional specification describes the TOE Security Functions Interfaces (TSFIs). It is not
necessary to have a formal or complete specification of these interfaces. For this cPP, the
Evaluation Activities for this family focus on understanding the interfaces presented in the TSS in
response to the functional requirements and the interfaces presented in the AGD documentation.
The Evaluation Activities in the SD are associated with the applicable SFRs; since these are
directly associated with the SFRs, the tracing in element ADV_FSP.1.2D is implicitly already
done and no additional documentation is necessary.
7.2.2 Specification of DSC Interface for Use in Composite Evaluations
For the DSC to serve as a base component in a composed evaluation, all DSC interfaces that may
be invoked by a dependent component to satisfy dependent component SFRs must be
documented.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 85 of 140
A DSC that complies with this cPP must make services available to a dependent component
through interfaces. The DSC ST author must describe these interfaces in order for a dependent
component evaluation to properly map the DSC-provided services to SFRs within the dependent
component PP, and to ensure that dependent component implementations properly use the
service interfaces.
The Evaluation Activities in the SD require specifying each such interface exported.
7.3 AGD: Guidance Documentation
The guidance documents will be provided with the ST. Guidance must include a description of
how the IT personnel verifies that the Operational Environment can fulfill its role for the security
functionality. The documentation should be in an informal style and readable by the IT personnel.
Guidance must be provided for every operational environment that the product supports as claimed
in the ST. This guidance includes:
 instructions to successfully install the TSF in that environment; and
 instructions to manage the security of the TSF as a product and as a component of the
larger operational environment; and
 Instructions to provide a protected administrative capability.
Guidance pertaining to particular security functionality must also be provided; requirements on
such guidance are contained in the Evaluation Activities specified in the SD.
7.3.1 Operational User Guidance (AGD_OPE.1)
The operational user guidance does not have to be contained in a single document. Guidance to
users, administrators and application developers can be spread among documents or web pages.
The developer should review the Evaluation Activities contained in the SD to ascertain the
specifics of the guidance that the evaluator will be checking for. This will provide the necessary
information for the preparation of acceptable guidance.
7.3.2 Preparative Procedures (AGD_PRE.1)
As with the operational guidance, the developer should look to the Evaluation Activities to
determine the required content with respect to preparative procedures.
7.4 Class ALC: Life-cycle Support
At the assurance level provided for TOEs conformant to this cPP, life-cycle support is limited to
end-user-visible aspects of the life cycle, rather than an examination of the TOE vendor’s
development and configuration management process. This is not meant to diminish the critical role
that a developer’s practices play in contributing to the overall trustworthiness of a product; rather,
it is a reflection on the information to be made available for evaluation at this assurance level.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 86 of 140
7.4.1 Labelling of the TOE (ALC_CMC.1)
This component is targeted at identifying the TOE such that it can be distinguished from other
products or versions from the same vendor and can be easily specified when being procured by an
end user. The evaluator performs the CEM work units associated with ALC_CMC.1
7.4.2 TOE CM Coverage (ALC_CMS.1)
Given the scope of the TOE and its associated evaluation evidence requirements, the evaluator
performs the CEM work units associated with ALC_CMS.1.
7.5 Class ATE: Tests
Testing is specified for functional aspects of the system as well as aspects that take advantage of
design or implementation weaknesses. The former is done through the ATE_IND family, while
the latter is through the AVA_VAN family. For this cPP, testing is based on advertised
functionality and interfaces with dependency on the availability of design information. One of the
primary outputs of the evaluation process is the test report as specified in the following
requirement.
7.5.1 Independent Testing – Conformance (ATE_IND.1)
Testing is performed to confirm the functionality described in the TSS as well as the operational
guidance (includes “evaluated configuration” instructions). The focus of the testing is to confirm
that the requirements specified in Section 5 are being met. The Evaluation Activities in the SD
identify the specific testing activities necessary to verify compliance with the SFRs. The evaluator
produces a test report documenting the plan for and results of testing, as well as coverage
arguments focused on the platform/TOE combinations that are claiming conformance to this cPP.
7.6 Class AVA: Vulnerability Assessment
For the current generation of this cPP, the iTC is expected to survey open sources to discover what
vulnerabilities have been discovered in these types of products and provide that content into the
AVA_VAN discussion. In most cases, these vulnerabilities will require sophistication beyond that
of a basic attacker. This information will be used in the development of future Protection Profiles.
7.6.1 Vulnerability Survey (AVA_VAN.1)
As with ATE_IND, the evaluator shall generate a report to document their findings with respect
to this requirement. This report could physically be part of the overall test report mentioned in
ATE_IND, or a separate document. The evaluator performs a search of public information to
determine the vulnerabilities that have been found in network infrastructure platforms and the
implemented communication protocols in general, as well as those that pertain to the particular
TOE. The evaluator documents the sources consulted and the vulnerabilities found in the report.
For each vulnerability found, the evaluator either provides a rationale with respect to its non-
applicability, or the evaluator formulates a test (using the guidelines provided in ATE_IND) to
confirm the vulnerability, if suitable. Suitability is determined by assessing the attack vector
needed to take advantage of the vulnerability. If exploiting the vulnerability requires expert skills
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 87 of 140
and an electron microscope, for instance, then a test would not be suitable and an appropriate
justification would be formulated.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 88 of 140
Appendix A: Optional Requirements
A.1 Cryptographic Support
A.1.1 FCS_ENT_EXT.1 Entropy for External IT Entities
FCS_ENT_EXT.1 Entropy for External IT Entities
FCS_ENT_EXT.1.1 The TSF shall provide an interface to make entropy that meets
FCS_RBG_EXT.1 available to external IT entities.
A.1.2 FCS_RBG_EXT.2 External Seeding for Random Bit Generation
FCS_RBG_EXT.2 External Seeding for Random Bit Generation
FCS_RBG_EXT.2.1 The TSF shall provide an interface to allow external seeding of the DRBG
with a bit-string of at least the minimum number of bits selected in FCS_RBG_EXT.1.2 before
the DRBG produces any output.
A.2 Protection of the TSF
A.2.1 FPT_ITT.1 Basic Internal TSF Data Transfer Protection
FPT_ITT.1 Basic Internal TSF Data Transfer Protection
FPT_ITT.1.1 The TSF shall protect TSF data from [disclosure] and [selection: modification, no
other actions] when it is transmitted between separate parts of the TOE.
A.2.2 FPT_PRO_EXT.2 Data Integrity Measurements
FPT_PRO_EXT.2 Data Integrity Measurements
FPT_PRO_EXT.2.1 The TSF shall be able to quantify the integrity of the data protected by the
TOE by generating integrity measurements and assertions making them available to authorized
entities.
Application Note 44.
The generation of these integrity measurements and assertions is the creation of OB.Pstate.
Data protected by the TOE includes DSC firmware, DSC configuration data, and user data. DSC
configuration data may include persistent SDEs or SDOs such as immutable or mutable root keys,
authorization values, and authentication tokens (i.e. DSC.ID, OB.P_SDO, OB.FAACntr,
OB.AntiReplay, and OB.Context). User data may include transient SDEs and SDOs as well as
authorization values and authentication tokens bound to these SDEs and SDOs (i.e. OB.T_SDO).
Integrity reporting is the process of attesting to integrity measurements (including those recorded
in status registers in a DSC).
FPT_PRO_EXT.2.2 The TSF shall accumulate platform characteristics using a consistent
[assignment: description of process for accumulating platform characteristics] process in which
verified quantifiable measurements are accumulated to prove the integrity of its SDOs.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 89 of 140
Application Note 45.
Although a platform may enter any state possible—including undesirable or insecure states—it
can use platform characteristics, including integrity measurements and assertions, along with
logging and reporting to accurately report the state derived from data attributing to those states.
In this context, platform characteristics can include, but is not limited to, cryptographic hashes of
binary data, security-critical configurations, register values (including status registers) and
milestones, such as verification of firmware, or transitioning from a boot phase to an operational
phase. A platform characteristic may also represent the state of some entity outside the DSC. A
process independent from the DSC or the host containing the DSC may evaluate the platform
characteristics and determine an appropriate action.
A.2.3 FPT_ROT_EXT.3 Root of Trust for Reporting Mechanisms
FPT_ROT_EXT.3 Root of Trust for Reporting Mechanisms
FPT_ROT_EXT.3.1 The TSF shall be able to attest to a state as represented by platform
characteristics with a Root of Trust for Reporting mechanism that uses for its identity [selection:
a cryptographically verifiable identity in FPT_PRO_EXT.1, an alias key bound to the
cryptographically verifiable identity in FPT_PRO_EXT.1] and using a signature algorithm as
specified in FCS_COP.1/SigGen.
Application Note 46.
While it is possible for a group of components to share a single unique group identifier, it is
important to ensure that individual components have their own unique identifiers relative to each
other.
Resident keys or aliases are designed such that they are never visible outside the subset of DSC
scope containing the RoT services and are only to be used for encryption. Therefore, possession
of such aliases or keys can only be proved indirectly by using it to decrypt a value that has been
encrypted with a corresponding public key. In this way, these resident keys or aliases can provide
for authentication based on decryption operations instead of producing a digital signature.
If non-specialized cryptographic keys used for algorithms in FCS_COP is selected, it is expected
that when used in the context of the RoT for Reporting, these keys are not visible to full DSC scope
as described above. While it is possible for a group of components to share a single unique group
identifier, it is important to ensure that individual components have their own unique identifiers
relative to each other.
The DSC will not expose the private portions of resident keys or aliases outside the subset of DSC
scope containing the RoT services. Therefore, possession of such aliases or keys can only be
proved indirectly by using it to decrypt a value that has been encrypted with a corresponding
public key. In this way, these resident keys or aliases can provide for authentication based on
decryption operations instead of producing a digital signature.
The DSC responds to requests from an external entity to attest to the provenance and integrity of
platform characteristics contained within the DSC.
Integrity reporting is the process of attesting to platform characteristics (including those recorded
in status registers in a DSC). The philosophy behind integrity measurement, logging, and reporting
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 90 of 140
is that a platform may enter any state possible—including undesirable or insecure states—but can
still accurately report measurements derived from data attributing to those states. In this context,
data can include, but is not limited to, code, security-critical configurations, values of registers,
including status registers. An independent process may evaluate the integrity states and determine
an appropriate response.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 91 of 140
Appendix B: Selection-Based Requirements
As indicated in the introduction to this cPP, the baseline requirements (those that must be
performed by the TOE or its underlying platform) are contained in the body of this cPP. There are
additional requirements based on selections in the body of the cPP: if certain selections are made,
then additional requirements below will need to be included.
B.1 Cryptographic Support
B.1.1 FCS_CKM.1/AK Cryptographic Key Generation (Asymmetric Keys)
FCS_CKM.1/AK Cryptographic Key Generation (Asymmetric Keys)
FCS_CKM.1.1/AK The TSF shall generate asymmetric cryptographic keys
[selection: identifier from Supported Methods for Asymmetric Key Generation
table] and specified cryptographic key sizes [key sizes as chosen from Supported Methods for
Asymmetric Key Generation table for corresponding key types] that meet the following: [standards
as chosen from Supported Methods for Asymmetric Key Generation table for corresponding key
types].
Identifier Key Type Key Sizes List of Standards
AK1 RSA [selection: 2048 bit, 3072
bit]
FIPS PUB 186-4 (Section
B.3)
AK2 ECC-N [selection: 256 (P-256),
384 (P-384), 521 (P-
521)]
FIPS PUB 186-4 (Section
B.4 & D.1.2)
AK3 ECC-B [selection: 256
(brainpoolP256r1), 384
(brainpoolP384r1), 512
(brainpoolP512r1)]
RFC5639 (Section 3)
(Brainpool Curves)
AK4 DSA Bit lengths of p and q
respectively (L, N)
[selection: (1024, 160);
(2048, 224); (2048, 256);
(3027, 256)]
FIPS 186-4 Appendix B.1
AK5 Curve25519 256 bits RFC 7748
Table 14: Supported Methods for Asymmetric Key Generation
Application Note 47.
This requirement is included for the purposes of encryption and decryption operations only. To
support ITE protected communications requirement for the transfer of encrypted data, this
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 92 of 140
requirement mandates implementation compliance to FIPS 186-4 only. Implementations
according to FIPS 186-2 or FIPS 186-3 will not be accepted.
This requirement must be claimed by the TOE if at least one of FCS_CKM.1 or FCS_CKM.1/KEK
chooses a selection related to generation of asymmetric keys.
B.1.2 FCS_CKM.1/SK Cryptographic Key Generation (Symmetric Encryption Key)
FCS_CKM.1/SK Cryptographic Key Generation (Symmetric Encryption Key)
FCS_CKM.1.1/SK The TSF shall generate symmetric cryptographic keys [selection: identifier
from Supported Methods for Symmetric Encryption Key Generation table] in accordance
with a specified cryptographic key generation algorithm [selection: cryptographic key
generation algorithm from Supported Methods for Symmetric Encryption Key Generation
table] and specified cryptographic key sizes [selection: key sizes from Supported Methods for
Symmetric Encryption Key Generation table] that meet the following: [selection: list of
standards from Supported Methods for Symmetric Encryption Key Generation table].
Identifier Key Type Cryptographic Key
Generation
Algorithm
Key Sizes List of Standards
RSK [selection:
symmetric key,
submask,
authorization
value]
Direct Generation
from a Random Bit
Generator as specified
in FCS_RBG_EXT.1
[selection: 128,
192, 256, 512] bits
NIST SP 800-133
(Section 7.1) with
ISO 18031 as an
approved RBG in
addition to those in
NIST SP 800-133
(Section 5).
DSK [selection:
identifier from
Table 16: Key
Derivation
Functions]
[selection: Key
Type from Table
16: Key
Derivation
Functions]
Derived from a Key
Derivation Function
as specified in
FCS_CKM_EXT.5
[selection: Key
Derivation Algorithm
from Table 16: Key
Derivation Functions]
[selection: key
sizes from Table
16: Key
Derivation
Functions]
[selection: List of
Standards from
Table 16: Key
Derivation
Functions]
PBK [selection:
submask,
authentication
token,
authorization
value]
Derived from a
Password Based Key
Derivation Function
as specified in
FCS_COP.1/PBKDF
[selection: key
sizes as specified
in FCS_COP.1/
PBKDF]
[selection: standards
as specified in
FCS_COP.1/
PBKDF]
Table 15: Supported Methods for Symmetric Encryption Key Generation
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 93 of 140
Application Note 48.
The intent of this requirement is to ensure that attackers cannot recover SKs with less than a full
exhaust of the key space. This requirement explains SK generation regardless of how the DSC uses
it or when it generates it. The encryption of user data that is not keying material, authentication
tokens, or authorization values is outside the scope of this cPP. This cPP assumes that the DSC
lacks the required resources to perform bulk encryption/decryption services at a suitable rate for
users. The host may use the SK for encrypting user data outside the boundaries of the DSC. On
the other hand, the DSC may use the SK on behalf of the user to perform keyed hashes. In this
case, all the requirements for generating, controlling access and use, and destroying the key while
under the protection of the DSC apply.
The selection of key size 512 bits is for the case of XTS-AES using AES-256. In the case of XTS-
AES for both AES-128 and AES-256, the developer is expected to ensure that the full key is
generated using direct generation from the RBG as in NIST SP 800-133 section.
The ST author selects at least one algorithm from the RSK row if the ST supports creating keys
directly from the output of the RBG without further conditioning, at least one algorithm from the
DSK row should be selected if the ST supports key derivation functions which are usually seeded
from RBG and then further conditioned to the appropriate key size, and at least one algorithm
from the PBK row should be selected if the ST supports keys derived from passwords.
If DSK is selected, the selection-based SFR FCS_CKM_EXT.5 must be claimed by the TOE.
If PBK is selected, the selection-based SFR FCS_COP.1/PBKDF must be claimed by the TOE.
This requirement must be claimed by the TOE if at least one of FCS_CKM.1 or FCS_CKM.1/KEK
chooses a selection related to generation of symmetric keys.
B.1.3 FCS_CKM_EXT.5 Cryptographic Key Derivation
FCS_CKM_EXT.5 Cryptographic Key Derivation
FCS_CKM_EXT.5.1 The TSF shall generate cryptographic keys with [selection: identifier as
chosen from Key Derivation Functions table] using [input parameters as chosen from Key
Derivation Functions table for corresponding key types], key derivation algorithm [assignment:
key derivation algorithms as chosen from Key Derivation Functions table for corresponding key
types], and specified cryptographic key sizes [key sizes as chosen from Key Derivation Functions
table for corresponding key types] that meet the following: [standards as chosen from Key
Derivation Functions table for corresponding key types].
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 94 of 140
Identifier Key Type Input
Parameters
Key Derivation
Algorithm
Key Sizes List of Standards
KeyDrv1 [selection:
symmetric
key,
initialization
vector,
authentication
token,
authorization
value, HMAC
key, KMAC
key]
Direct
Generation
from a Random
Bit Generator
as specified in
FCS_RBG_EX
T.1
KDF in Counter
Mode using
[selection:
CMAC-AES-128;
CMAC-AES-192;
CMAC-AES-256;
HMAC-SHA-1;
HMAC-SHA-256;
HMAC-SHA-512] as
the PRF
[selection: 128,
192, 256] bits
NIST SP 800-108
(Section 5.1) (KDF
in Counter Mode)
[selection:
ISO-CMAC; NIST-
CMAC; ISO-CIPH;
ISO-HMAC; FIPS-
HMAC; ISO-
HASH; FIPS-SHA]
KeyDrv2 [selection:
symmetric
key,
initialization
vector,
authentication
token,
authorization
value, HMAC
key, KMAC
key]
Direct
Generation
from a Random
Bit Generator
as specified in
FCS_RBG_EX
T.1
KDF in Feedback
Mode using
[selection:
CMAC-AES-128;
CMAC-AES-192;
CMAC-AES-256;
HMAC-SHA-1;
HMAC-SHA-256;
HMAC-SHA-512] as
the PRF
[selection: 128,
192, 256] bits
NIST SP 800-108
(Section 5.2) (KDF
in Feedback Mode)
[selection:
ISO-CMAC; NIST-
CMAC; ISO-CIPH;
ISO-HMAC; FIPS-
HMAC; ISO-
HASH; FIPS-SHA]
KeyDrv3 [selection:
symmetric
key,
initialization
vector,
authentication
token,
authorization
value, HMAC
key, KMAC
key]
Direct
Generation
from a Random
Bit Generator
as specified in
FCS_RBG_EX
T.1
KDF in Double-
Pipeline Iteration
Mode using
[selection:
CMAC-AES-128;
CMAC-AES-192;
CMAC-AES-256,
HMAC-SHA-1;
HMAC-SHA-256;
HMAC-SHA-512] as
the PRF
[selection: 128,
192, 256] bits
NIST SP 800-108
(Section 5.3) (KDF
in Double-Pipeline
Iteration Mode)
[selection:
ISO-CMAC; NIST-
CMAC, ISO-CIPH;
ISO-HMAC; FIPS-
HMAC; ISO-
HASH; FIPS-SHA]
KeyDrv4 [selection:
symmetric
key,
initialization
vector,
authentication
token,
authorization
value, HMAC
key, KMAC
key]
Intermediary
keys
[selection: exclusive
OR (XOR); SHA-
256; SHA-512]
[selection: 128,
192, 256] bits
[selection:
ISO-HASH; FIPS-
SHA]
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 95 of 140
Identifier Key Type Input
Parameters
Key Derivation
Algorithm
Key Sizes List of Standards
KeyDrv5 [selection:
symmetric
key,
initialization
vector,
authentication
token,
authorization
value, HMAC
key, KMAC
key]
Concatenated
keys
KDF in [selection:
Counter Mode,
Feedback Mode,
Double-Pipeline
Iteration Mode] using
[selection:
CMAC-AES-128;
CMAC-AES-192;
CMAC-AES-256;
HMAC-SHA-1;
HMAC-SHA-256;
HMAC-SHA-512] as
the PRF
[selection: 128,
192, 256] bits
NIST SP 800-108
[selection: (Section
5.1) (KDF in
Counter Mode);
(Section 5.2) (KDF
in Feedback Mode);
(Section 5.3) (KDF
in Double-Pipeline
Iteration Mode)]
[selection:
ISO-CMAC; NIST-
CMAC; ISO-CIPH;
ISO-HMAC; FIPS-
HMAC; ISO-
HASH; FIPS-SHA]
KeyDrv6 [selection:
symmetric
key,
initialization
vector,
authentication
token,
authorization
value, HMAC
key, KMAC
key]
Two keys [selection: AES-
CCM, AES-GCM,
AES-CBC, AES-
KWP, AES-KW,
CAM-CBC, CAM-
CCM, CAM-GCM]
from
FCS_COP.1/SKC
Symmetric Key table
[selection: 128,
192, 256] bits
[selection: see List
of Standards in
FCS_COP.1/SKC
Symmetric Key
table]
KeyDrv7 [selection:
symmetric
key, secret
IV, seed]
Shared secret,
salt, output
length, fixed
information
[selection: hash
function from
FCS_COP.1/Hash,
keyed hash from
FCS_COP.1/HMAC]
[[selection: 128,
192, 256] bits
(NIST-KDRV) sec 4
[selection: see List
of Standards in
FCS_COP.1/Hash
and
FCS_COP.1/HMAC
]
KeyDrv8 [selection:
symmetric
key, secret
IV, seed]
Shared secret,
salt, IV, output
length, fixed
information
[selection: keyed hash
from
FCS_COP.1/HMAC]
[selection: 128,
192, 256] bits
(NIST-KDRV) sec 5
[selection: see List
of Standards in
FCS_COP.1/HMAC
]
Table 16: Key Derivation Functions
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 96 of 140
Application Note 49.
Note that Camellia algorithms do not support 192-bit key sizes.
The interface referenced in the requirement could take different forms, the most likely of which is
an application programming interface to an OS kernel. There may be various levels of abstraction.
For Authorization Factor Submasks, the key size to be used in the HMAC falls into a range between
L1 and L2 defined in ISO/IEC 10118 for the appropriate hash function (for example for SHA-256
L1 = 512, L2 =256) where L2 ≤ k ≤ L1.
General note: in order to use a NIST SP 800-108 conformant method of key derivation, the TOE
is permitted to implement this with keys as derived as indicated in Key Derivation Functions table
above, and with the algorithms as indicated in the same table.
NIST SP 800-131A Rev 1 allows the use of SHA-1 in these use cases.
KeyDrv5, KeyDrv6, and the XOR option in KeyDrv4 will create an “inverted key hierarchy” in
which the TSF will combine two or more keys to create a third key. These same KDFs may also
use a submask key as input, which could be an authorization factor or derived from a PBKDF. In
these cases the ST author must explicitly declare this option and should present a reasonable
argument that the entropy of the inputs to the KDFs will result in full entropy of the expected
output.
If keys are combined, the ST author shall describe which method of combination is used in order
to justify that the effective entropy of each factor is preserved.
The documentation of the product’s encryption key management should be detailed enough that,
after reading, the evaluator will thoroughly understand the product’s key management and how it
meets the requirements to ensure the keys are adequately protected. This documentation should
include an essay and diagrams. This documentation is not required to be part of the TSS; it can be
submitted as a separate document and marked as developer proprietary.
SP 800-56C specifies a two-step key derivation procedure that employs an extraction-then-
expansion technique for deriving keying material from a shared secret generated during a key
establishment scheme. The Randomness Extraction step as described in Section 5 of SP 800-56C
is followed by Key Expansion using the key derivation functions defined in SP 800-108.
This requirement must be claimed by the TOE if at least one of FCS_CKM.1/KEK,
FCS_CKM.1/SK, or FCS_COP.1/KeyEnc chooses a selection related to key derivation.
If at least one of KeyDrv4, KeyDrv5, or KeyDrv6 is selected AND password-based key derivation
is used to create at least one of the inputs, the selection-based SFR FCS_COP.1/PBKDF must also
be claimed.
B.1.4 FCS_COP.1/PBKDF Cryptographic Operation (Password-Based Key Derivation
Functions)
FCS_COP.1/PBKDF Cryptographic Operation (Password-Based Key Derivation
Functions)
FCS_COP.1.1/PBKDF The TSF shall perform [password-based key derivation functions] in
accordance with a specified cryptographic algorithm [HMAC-[selection: SHA-256, SHA-384,
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 97 of 140
SHA-512]], with [assignment: integer number greater than or equal to 1000] iterations, and
output cryptographic key sizes [selection: 128, 192, 256] bits that meet the following standard:
[NIST SP 800-132].
Application Note 50.
The ST must condition a password into a string of bits prior to using it as input to algorithms that
form SKs and KEKs. The ST can perform conditioning using one of the identified hash functions
or the process described in NIST SP 800-132; the ST author selects the method used. NIST SP
800-132 requires the use of a pseudo-random function (PRF) consisting of HMAC with an
approved hash function.
Appendix A of NIST SP 800-132 recommends setting the iteration count in order to increase the
computation needed to derive a key from a password and, therefore, increase the workload of
performing a dictionary attack.
The TOE must claim this requirement if it claims FCS_CKM.1/SK and selects an algorithm in the
PBK row or claims FCS_CKM_EXT.5 and selects at least one of KeyDrv4, KeyDrv5, or KeyDrv6
AND uses password-based key derivation to create at least one of the inputs.
B.2 User Data Protection
B.2.1 FDP_DAU.1/Prove Basic Data Authentication (for Use with The Prove Service)
FDP_DAU.1/Prove Basic Data Authentication (for Use with the Prove Service)
FDP_DAU.1.1/Prove The TSF shall provide a capability to generate evidence that can be used as
a guarantee of the validity of [selection: [assignment: list of objects or information types] declared
valid by the TSF, [assignment: list of objects or information types] declared valid by an
authenticated user].
FDP_DAU.1.2/Prove The TSF shall provide [assignment: list of subjects] with the ability to
verify evidence of the validity of the indicated information.
Application Note 51.
This SFR describes the output of the Prove service provided by the DSC. The evidence of validity
or authenticity, or other evidence derived, is expected to be processed by the RoT for Measurement.
Additionally, the use of a RoT for Reporting presupposes a logging capability or other means of
generating state information that could be conveyed to external entities. Therefore,
FDP_DAU.1.1/Prove must be selected if-and-only-if the RoT for Measurement and the RoT for
Reporting are both selected in FPT_ROT_EXT.1.1. An ‘authenticated user’ in the sense of the
selection in FDP_DAU.1.1/Prove means a user who has been authenticated by the DSC according
to the mechanisms of FIA_UAU.5.
In FDP_DAU.1.1/Prove, the DSC will issue a validity-stamped or authenticity-stamped piece of
data. In this case, validity-stamped means that the form of the issued data enables an external
entity to verify that the data has been issued via the DSC’s Prove service. The implementation
might be via a DSC cryptographic signature, or a MAC using a symmetric key shared with the
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 98 of 140
receiver, for example. Authenticity-stamped means that the receiver of the data can verify that the
user providing this data is authentic.
Data that would need to be validity-stamped includes data over which the DSC is the authority,
such as the state of its own firmware. Data that would need to be authenticity-stamped includes
data about which the DSC knows nothing, but where it will issue the data with a statement that the
DSC has authenticated the source of this data.
For data that is validity-stamped, the DSC does nothing but respond to a request to issue the data;
thus, authentication of the user issuing the data is not needed and is covered by
FDP_DAU.1/Prove. Otherwise, in the case the DSC has no understanding of this data, a step is
needed via FIA_UAU.5 by which the DSC authenticates the user for this service, and that the DSC
or Prove service will therefore vouch for the user, not the validity of the data itself.
B.2.2 FDP_FRS_EXT.2 Factory Reset Behavior
FDP_FRS_EXT.2 Factory Reset Behavior
FDP_FRS_EXT.2.1 Upon initiation of a factory reset, the TSF shall destroy [all non-persistent
SDOs] and restore the following pre-installed SDOs to their factory settings: [assignment: pre-
installed SDOs to be restored during a factory reset].
Application Note 52.
Not all DSCs permit a factory reset of the TOE, or perform a factory reset in response to excessive
failed authentication or authorization attempts. Those that do are expected to perform a factory
reset in a manner that prevents any inadvertent disclosure of security-relevant data that was
present on the DSC prior to the factory reset. For DSCs that permit factory reset functionality (as
indicated by selection of factory reset the TOE wiping out all non-persistent SDOs, as described
by FDP_FRS_EXT.2 in FIA_AFL_EXT.1.3, or by no actions or conditions NOT being selected in
FDP_FRS_EXT.1.1), this SFR must be included in the TOE boundary.
B.2.3 FDP_MFW_EXT.2 Basic Firmware Integrity
FDP_MFW_EXT.2 Basic Firmware Integrity
FDP_MFW_EXT.2.1 The TSF shall have the ability to verify the integrity of the firmware.
FDP_MFW_EXT.2.2 The TSF shall provide a capability to generate evidence of the integrity of
the firmware.
Application Note 53.
Data and firmware integrity is not a required component of this cPP in all cases because some
DSCs will have immutable firmware. This SFR must be claimed if mutable is selected in
FDP_MFW_EXT.1.1.
The TOE guarantees the integrity of the firmware by verifying its integrity.
Verifying the integrity of the firmware could be accomplished by guaranteeing the validity of
firmware within the TOE prior to execution.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 99 of 140
This requirement covers the case of ensuring the firmware is trustworthy in immutable form or
mutable through any firmware updates, since the integrity and authenticity are checked prior to
execution.
FCS_COP.1/SigVer applies if the TOE provides the capability to update the TOE firmware and
uses digital signatures and MAC verification for update verification. The ST Author should choose
the algorithm implemented to perform digital signatures. For the algorithms chosen, the ST author
should make the appropriate assignments/selections to specify the parameters that are
implemented for that algorithm.
B.2.4 FDP_MFW_EXT.3 Firmware Authentication with Identity of Guarantor
FDP_MFW_EXT.3 Firmware Authentication with Identity of Guarantor
FDP_MFW_EXT.3.1 The TSF shall have the ability to verify the authenticity of the firmware.
FDP_MFW_EXT.3.2 The TSF shall provide a capability to generate evidence of the
authenticity of the firmware.
Application Note 54.
Firmware authentication is not a required component of this cPP in all cases because some DSCs
will have immutable firmware. This SFR must be claimed if mutable is selected in
FDP_MFW_EXT.1.1.
The TOE guarantees the authenticity of the firmware by verifying its signature.
Verifying the authenticity of the firmware could be accomplished by guaranteeing the validity of
firmware within the TOE prior to execution.
This requirement covers the case of ensuring the firmware is trustworthy in immutable form or
mutable through any firmware updates, since the integrity and authenticity are checked prior to
execution.
FCS_COP.1/SigVer applies if the TOE provides the capability to update the TOE firmware and
uses digital signatures and MAC verification for update verification. The ST Author should choose
the algorithm implemented to perform digital signatures. For the algorithms chosen, the ST author
should make the appropriate assignments/selections to specify the parameters that are
implemented for that algorithm.
B.3 Identification and Authentication
B.3.1 FIA_AFL_EXT.2 Authorization Failure Response
FIA_AFL_EXT.2 Authorization Failure Response
FIA_AFL_EXT.2.1 When the TSF locks an SDO (i.e. prevents authorization attempts for an
SDO) due to a user exceeding the allowed threshold for unsuccessful authorization attempts, then
only an administrator may unlock access to the SDO and reset the corresponding failed
authorization attempt counter.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 100 of 140
Application Note 55.
This SFR is applicable only when the TSF’s response to excessive authorization failures selects
prevent all future authorization attempts indefinitely (i.e., lock) as specified by FIA_AFL_EXT.1.3.
B.4 Protection of the TSF
B.4.1 FPT_FLS.1/FW Failure with Preservation of Secure State (Firmware)
FPT_FLS.1/FW Failure with Preservation of Secure State (Firmware)
FPT_FLS.1.1/FW The TSF shall preserve a secure state when the following types of firmware
failures occur: [authenticity violation, integrity violation, rollback violation].
Application Note 56.
A DSC’s ability to handle failures related to authenticity, integrity, and invalid versions of
firmware is not applicable in all cases because some DSCs will have immutable firmware. This
SFR must be claimed if mutable is selected in FDP_MFW_EXT.1.1.
The phrase “secure state” refers to a state in which the TOE has consistent TSF data and a TSF
that can correctly enforce the policy. The TOE must ensure that no further processing of TSF or
user data takes place while in an insecure state. This state may be the initial “boot” of a clean
system, or it might be some check-pointed state. It is expected that in most cases, the TOE will halt
and require a reset or re-initialization to return to a known secure state.
B.4.2 FPT_RPL.1/Rollback Replay Detection (Rollback)
FPT_RPL.1/Rollback Replay Detection (Rollback)
FPT_RPL.1.1/Rollback The TSF shall detect replay for the following entities: [previous
firmware builds].
FPT_RPL.1.2/Rollback The TSF shall prevent the execution of the loaded firmware and
perform [selection, choose one of: [assignment: other actions], no other actions] when replay is
detected.
Application Note 57.
A DSC’s ability to detect an attempted rollback (software/firmware downgrade) is not applicable
in all cases because some DSCs will have immutable firmware that cannot be modified in any way.
This SFR must be claimed if mutable is selected in FDP_MFW_EXT.1.1.
The TSF data is used as a guarantee of the ordinal identifier of the firmware instance. When a
firmware load is requested, the TSF ensures the authenticated firmware ordinal identifier is
greater than or equal to the previously authenticated firmware identifier. For example, this could
be accomplished by ensuring the validated instance of the firmware to be loaded is greater than
or equal to the instance previously validated and loaded into the TOE. By loading a previous
instance of firmware, it potentially opens up the device to known vulnerabilities.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 101 of 140
B.5 Trusted Path/Channels
B.5.1 FTP_CCMP_EXT.1 CCM Protocol
FTP_CCMP_EXT.1 CCM Protocol
FTP_CCMP_EXT.1.1 The TSF shall implement CCMP using [selection: AES, Camellia] in
CCM mode and key size [selection: 128-bits, 256-bits] as defined in [selection: IEEE 802.11i,
IEEE 802.11ac].
FTP_CCMP_EXT.1.2 The TSF shall discard incoming messages if authentication fails.
FTP_CCMP_EXT.1.3 The TSF shall discard incoming messages that are malformed or invalid.
Application Note 58.
This SFR must be claimed if CCMP is selected in FTP_ITC_EXT.1.
Inclusion of this SFR requires inclusion of AES-CCM or CAM-CCM in FCS_COP.1/SKC.
CCMP is defined in IEEE 802.11i. CCMP-256 is defined in IEEE 802.11ac.
B.5.2 FTP_GCMP_EXT.1 GCM Protocol
FTP_GCMP_EXT.1 GCM Mode Protocol
FTP_GCMP_EXT.1.1 The TSF shall implement GCMP using [selection: AES, Camellia] in
GCM mode and key size [selection: 128-bits, 256-bits] as defined in [IEEE 802.11ad].
FTP_GCMP_EXT.1.2 The TSF shall discard incoming messages if authentication fails.
FTP_GCMP_EXT.1.3 The TSF shall discard incoming messages that are malformed or invalid.
Application Note 59.
This SFR must be claimed if GCMP is selected in FTP_ITC_EXT.1.
Inclusion of this SFR requires inclusion of AES-GCM or CAM-GCM in FCS_COP.1/SKC.
B.5.3 FTP_ITC_EXT.1 Cryptographically Protected Communications Channels
FTP_ITC_EXT.1 Cryptographically Protected Communications Channels
FTP_ITC_EXT.1.1 The TSF shall use [selection: CCMP, GCMP] protocol to provide a
communication channel between itself and [assignment: list of entities external to the TOE] that
protects channel data from disclosure and ensures the integrity of channel data.
Application Note 60.
This SFR must be claimed if cryptographically protected data channels as specified in
FTP_ITC_EXT.1 is selected in either FDP_ITC_EXT.1 or FDP_ITC_EXT.2.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 102 of 140
Entities external to the TOE include applications that communicate with the TOE such as
authentication capabilities (e.g. biometrics reader), external storage, and interfaces with an
external DSC.
If CCMP is selected, the ST author must include FTP_CCMP_EXT.1.
If GCMP is selected, the ST author must include FTP_GCMP_EXT.1.
B.5.4 FTP_ITE_EXT.1 Encrypted Data Communications
FTP_ITE_EXT.1 Encrypted Data Communications
FTP_ITE_EXT.1.1 The TSF shall encrypt data for transfer between the TOE and [assignment:
list of entities external to the TOE] using a cryptographic algorithm and key size as specified in
FCS_COP.1/SKC, and using [selection:
 Pre-shared keys;
 Keys established according to FCS_CKM.2;
 Keys exchanged using a physically protected communication mechanism conformant with
FTP_ITP_EXT.1
].
Application Note 61.
This SFR must be claimed if encrypted data buffers as specified in FTP_ITE_EXT.1 is selected in
either FDP_ITC_EXT.1 or FDP_ITC_EXT.2.
This requirement applies to encrypted data communications between the TOE and external entities
that do not use a physically protected mechanism conforming to FTP_ITP_EXT.1, or a
cryptographically protected data channel as conforming to FTP_ITC_EXT.1. For example, if data
is transferred through encrypted buffers (or blobs) then this requirement applies. If data is
transferred through a physically protected channel, then FTP_ITP_EXT.1 applies. This
requirement would apply, for example, for communications implemented through a shared data
buffer.
B.5.5 FTP_ITP_EXT.1 Physically Protected Channel
FTP_ITP_EXT.1 Physically Protected Channel
FTP_ITP_EXT.1.1 The TSF shall provide a physically protected communication channel
between itself and [assignment: list of other IT entities within the same platform].
Application Note 62.
This SFR must be claimed if physically protected channels as specified in FTP_ITP_EXT.1 is
selected in either FDP_ITC_EXT.1 or FDP_ITC_EXT.2.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 103 of 140
Appendix C: Extended Component Definitions
This appendix contains the definitions for the extended requirements that are used in the cPP,
including those used in Appendices A and B.
(Note: formatting conventions for selections and assignments in this Appendix are those in [CC2].)
This Appendix provides a definition for all of the extended components introduced in this PP-
Module. These components are identified in the following table:
Functional Class Functional Components
Cryptographic Support (FCS) FCS_CKM_EXT Cryptographic Key Management
FCS_ENT_EXT Entropy for External IT Entities
FCS_RBG_EXT Random Bit Generation
FCS_SLT_EXT Cryptographic Salt Generation
FCS_STG_EXT Security Audit Event Storage
User Data Protection (FDP) FDP_ETC_EXT Export from the TOE
FDP_FRS_EXT Factory Reset
FDP_ITC_EXT Import from Outside of the TOE
FDP_MFW_EXT Firmware
FDP_SDC_EXT Confidentiality of SDEs
Identification and Authentication (FIA) FIA_AFL_EXT Authorization Failures
Security Management (FMT) FMT_MOF_EXT Management of Functions in TSF
Protection of the TSF (FPT) FPT_MOD_EXT Debug Modes
FPT_PRO_EXT Root of Trust
FPT_ROT_EXT Root of Trust Services
FPT_RPL_EXT Replay Detection
Trusted Path/Channels (FTP) FTP_CCMP_EXT CCM Protocol
FTP_GCMP_EXT GCM Protocol
FTP_ITC_EXT Inter-TSF Trusted Channel
FTP_ITE_EXT Encrypted Data Communications
FTP_ITP_EXT Physically Protected Channel
Table 17: Extended Components Definitions
C.1 Class FCS: Cryptographic Support
C.1.1 FCS_CKM_EXT Cryptographic Key Management
Family Behavior
This family defines requirements for key life cycle operations.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 104 of 140
Component Leveling
FCS_CKM_EXT Cryptographic Key
Management
4
5
FCS_CKM_EXT.4 Cryptographic Key and Key Material Destruction Timing, requires the TSF to
destroy keys when no longer used.
FCS_CKM_EXT.5 Cryptographic Key Derivation, requires the TSF to perform key derivation
using a defined method.
Management: FCS_CKM_EXT.4, FCS_CKM_EXT.5
No specific management functions are identified.
Audit: FCS_CKM_EXT.4, FCS_CKM_EXT.5
There are no auditable events foreseen.
FCS_CKM_EXT.4 Cryptographic Key and Key Material Destruction Timing
Hierarchical to: No other components.
Dependencies: FCS_CKM.4 Cryptographic Key Destruction
FCS_CKM_EXT.4.1The TSF shall destroy all keys and keying material when no longer needed.
FCS_CKM_EXT.5 Cryptographic Key Derivation
Hierarchical to: No other components.
Dependencies: FCS_CKM.1 Cryptographic Key Generation
FCS_COP.1 Cryptographic Operation
FDP_SDC_EXT.1 Confidentiality of SDEs
FCS_CKM_EXT.5.1The TSF shall generate cryptographic keys with [assignment: key types]
using [assignment: input parameters], key derivation algorithm [assignment: key derivation
algorithms], and specified cryptographic key sizes [assignment: key sizes] that meet the
following: [assignment: list of standards].
C.1.2 FCS_ENT_EXT Entropy for External IT Entities
Family Behavior
This family defines requirements for allowing the TSF to supply entropy data to external entities.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 105 of 140
Component Leveling
FCS_ENT_EXT Entropy for External
IT Entities
1
FCS_ENT_EXT.1 Entropy for External IT Entities, requires the TSF to have an external interface
available for external IT entities to retrieve entropy data from it.
Management: FCS_ENT_EXT.1
No specific management functions are identified.
Audit: FCS_ENT_EXT.1
There are no auditable events foreseen.
FCS_ENT_EXT.1 Entropy for External IT Entities
Hierarchical to: No other components.
Dependencies: FCS_RBG_EXT.1 Random Bit Generation
FCS_ENT_EXT.1.1 The TSF shall provide an interface to make entropy that meets
FCS_RBG_EXT.1 available to external IT entities.
C.1.3 FCS_RBG_EXT Random Bit Generation
Family Behavior
This family defines requirements for secure random bit generation.
Component Leveling
FCS_RBG_EXT Random Bit
Generation
1
2
FCS_RBG_EXT.1 Random Bit Generation, requires the TSF to implement a deterministic random
bit generator using a specified method and sufficiently strong entropy sources.
FCS_RBG_EXT.2 External Seeding for Random Bit Generation, requires the TSF to implement
an interface to allow its deterministic random bit generator to be seeded by an external entity.
Management: FCS_RBG_EXT.1, FCS_RBG_EXT.2
No specific management functions are identified.
Audit: FCS_RBG_EXT.1, FCS_RBG_EXT.2
There are no auditable events foreseen.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 106 of 140
FCS_RBG_EXT.1 Random Bit Generation
Hierarchical to: No other components.
Dependencies: FCS_COP.1 Cryptographic Operation
FCS_RBG_EXT.1.1 The TSF shall perform all deterministic random bit generation services in
accordance with ISO/IEC 18031:2011 using [selection: Hash_DRBG (any), HMAC_DRBG (any),
CTR_DRBG (AES)].
FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded by at least one entropy source in
accordance with NIST SP 800-90B that accumulates entropy from [selection: [assignment:
number of software-based sources] software-based noise source, [assignment: number of
hardware-based sources] hardware-based noise source] with a minimum of [selection: 128, 192,
256] bits of entropy at least equal to the greatest security strength, according to ISO/IEC
18031:2011, of the keys and CSPs that it will generate.
FCS_RBG_EXT.2 External Seeding for Random Bit Generation
Hierarchical to: No other components.
Dependencies: FCS_RBG_EXT.1 Random Bit Generation
FCS_RBG_EXT.2.1 The TSF shall provide an interface to allow external seeding of the DRBG
with a bit-string of at least the minimum number of bits selected in FCS_RBG_EXT.1.2 before
the DRBG produces any output.
C.1.4 FCS_SLT_EXT Cryptographic Salt Generation
Family Behavior
This family defines requirements for salt and nonce usage.
Component Leveling
FCS_SLT_EXT Cryptographic Salt
Generation
1
FCS_SLT_EXT.1 Cryptographic Salt Generation, requires the TSF to use salts and nonces that
are created by the TOE’s deterministic random bit generator.
Management: FCS_SLT_EXT.1
No specific management functions are identified.
Audit: FCS_SLT_EXT.1
There are no auditable events foreseen.
FCS_SLT_EXT.1 Cryptographic Salt Generation
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 107 of 140
Hierarchical to: No other components.
Dependencies: FCS_RBG_EXT.1 Random Bit Generation
FCS_SLT_EXT.1.1 The TSF shall use salts and nonces generated by an RBG as specified in
FCS_RBG_EXT.1.
C.1.5 FCS_STG_EXT Cryptographic Key Storage
Family Behavior
This family defines requirements for ensuring the protection of keys and secrets.
Component Leveling
FCS_STG_EXT Cryptographic Key
Storage
2
1
3
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.
Management: FCS_STG_EXT.1, FCS_STG_EXT.2, FCS_STG_EXT.3
No specific management functions are identified.
Audit: FCS_STG_EXT.1, FCS_STG_EXT.2, FCS_STG_EXT.3
There are no auditable events foreseen.
FCS_STG_EXT.1 Protected Storage
Hierarchical to: No other components.
Dependencies: No dependencies.
FCS_STG_EXT.1.1 The TSF shall provide [assignment: protection method] protected storage
for asymmetric private keys and [selection: symmetric keys, persistent secrets, no other keys].
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 108 of 140
FCS_STG_EXT.1.2 The TSF shall support the capability of [selection: importing keys/secrets
into the TOE, causing the TOE to generate keys/secrets] upon request of [assignment: authorized
subject].
FCS_STG_EXT.1.3 The TSF shall be capable of destroying keys/secrets in the protected storage
upon request of [assignment: authorized subject].
FCS_STG_EXT.1.4 The TSF shall have the capability to allow only the user that [selection:
imported the key/secret, caused the key/secret to be generated] to use the key/secret. Exceptions
may only be explicitly authorized by [assignment: authorized subject].
FCS_STG_EXT.1.5 The TSF shall allow only the user that [selection: imported the key/secret,
caused the key/secret to be generated] to request that the key/secret be destroyed. Exceptions may
only be explicitly authorized by [assignment: authorized subject].
FCS_STG_EXT.2 Key Storage Encryption
Hierarchical to: No other components.
Dependencies: FCS_COP.1 Cryptographic Operation
FCS_STG_EXT.2.1 The TSF shall encrypt [assignment: key data] using one of the following
methods: [assignment: key encryption methods as specified in FCS_COP.1].
FCS_STG_EXT.3 Key Integrity Protection
Hierarchical to: No other components.
Dependencies: FCS_CKM.1 Cryptographic Key Generation
FCS_COP.1 Cryptographic Operation
FCS_STG_EXT.2 Key Storage Encryption
FCS_STG_EXT.3.1 The TSF shall protect the integrity of any encrypted [assignment: key data]
by using [assignment: integrity protection method].
FCS_STG_EXT.3.2 The TSF shall verify the integrity of the [assignment: integrity verification
attribute associated with or computed from the stored key] of the stored key prior to use of the
key.
C.2 Class FDP: User Data Protection
C.2.1 FDP_ETC_EXT Export from the TOE
Family Behavior
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 109 of 140
This family defines requirements for export of TSF data outside the TOE boundary that allows
for the security of that data to be maintained.
Component Leveling
FDP_ETC_EXT Export from the TOE 2
FDP_ETC_EXT.2 Propagation of SDOs, requires the TSF to transmit data outside of the TOE
boundary with protections applied so that they cannot be accessed by unauthorized subjects.
Management: FDP_ETC_EXT.2
No specific management functions are identified.
Audit: FDP_ETC_EXT.2
There are no auditable events foreseen.
FDP_ETC_EXT.2 Propagation of SDOs
Hierarchical to: No other components.
Dependencies: FCS_COP.1 Cryptographic Operation
FDP_ETC_EXT.2.1 The TSF shall propagate only SDO references, wrapped authorization data,
and wrapped SDOs such that only [selection: the TSF, authorized users] can access them.
C.2.2 FDP_FRS_EXT Factory Reset
Family Behavior
This family defines requirements for the conditions that may trigger TOE factory reset and for
identifying the data that is destroyed or restored as part of the factory reset operation.
Component Leveling
FDP_FRS_EXT Factory Reset
1
2
FDP_FRS_EXT.1 Factory Reset, requires the TSF to allow factory resets under specified
conditions.
FDP_FRS_EXT.2 Factory Reset Behavior, requires the TSF to destroy certain TSF data and
restore other TSF data after a factory reset is initiated.
Management: FDP_FRS_EXT.1
The following actions could be considered for the management functions in FMT:
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 110 of 140
 Reset TOE to factory state.
Management: FDP_FRS_EXT.2
No specific management functions are identified.
Audit: FDP_FRS_EXT.1, FDP_FRS_EXT.2
There are no auditable events foreseen.
FDP_FRS_EXT.1 Factory Reset
Hierarchical to: No other components.
Dependencies: FDP_FRS_EXT.2 Factory Reset Behavior
FDP_FRS_EXT.1.1 The TSF shall permit a factory reset of the TOE upon: [assignment:
conditions under which a factory reset is authorized].
FDP_FRS_EXT.2 Factory Reset Behavior
Hierarchical to: No other components.
Dependencies: FDP_FRS_EXT.1 Factory Reset
FDP_FRS_EXT.2.1 Upon initiation of a factory reset, the TSF shall destroy [assignment: TSF
data that is destroyed by factory reset] and restore the following TSF data to their factory
settings: [assignment: TSF data that is restored by factory reset].
C.2.3 FDP_ITC_EXT Import from Outside of the TOE
Family Behavior
This family defines requirements for handling data that is imported from outside the TOE.
Component Leveling
FDP_ITC_EXT Import from Outside
of the TOE
1
2
FDP_ITC_EXT.1 Parsing of SDEs, requires the TSF to support the import of SDEs from outside
the TOE and to verify their integrity when imported.
FDP_ITC_EXT.2 Parsing of SDOs, requires the TSF to support the import of SDOs from outside
the TOE and to verify their integrity when imported.
Management: FDP_ITC_EXT.1, FDP_ITC_EXT.2
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 111 of 140
No specific management functions are identified.
Audit: FDP_ITC_EXT.1, FDP_ITC_EXT.2
There are no auditable events foreseen.
FDP_ITC_EXT.1 Parsing of SDEs
Hierarchical to: No other components.
Dependencies: FCS_COP.1 Cryptographic Operation
[FTP_ITC_EXT.1 Cryptographically Protected Communications Channels,
FTP_ITE_EXT.1 Encrypted Data Communications, or
FTP_ITP_EXT.1 Physically Protected Channel]
FDP_ITC_EXT.1.1 The TSF shall support importing SDEs using [assignment: import method
that maintains confidentiality and integrity of imported data].
FDP_ITC_EXT.1.2 The TSF shall verify the integrity of the SDE using [assignment: method of
integrity verification].
FDP_ITC_EXT.1.3 The TSF shall ignore any security attributes associated with the user data
when imported from outside the TOE.
FDP_ITC_EXT.1.4 The TSF shall bind SDEs to security attributes using [assignment: list of
ways the TSF generates security attributes and binds them to the SDEs].
FDP_ITC_EXT.2 Parsing of SDOs
Hierarchical to: No other components.
Dependencies: FCS_COP.1 Cryptographic Operation
[FTP_ITC_EXT.1 Cryptographically Protected Communications Channels,
FTP_ITE_EXT.1 Encrypted Data Communications, or
FTP_ITP_EXT.1 Physically Protected Channel]
FDP_ITC_EXT.2.1 The TSF shall support importing SDOs using [assignment: import method
that maintains confidentiality and integrity of imported data].
FDP_ITC_EXT.2.2 The TSF shall verify the integrity of the SDO using [assignment: method of
integrity verification].
FDP_ITC_EXT.2.3 The TSF shall use the security attributes associated with the imported user
data.
FDP_ITC_EXT.2.4 The TSF shall ensure that the protocol used provides for the unambiguous
association between the security attributes and the user data received.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 112 of 140
FDP_ITC_EXT.2.5 The TSF shall ensure that interpretation of the security attributes of the
imported user data is as intended by the source of the user data.
C.2.4 FDP_MFW_EXT Mutable/Immutable Firmware
Family Behavior
This family defines requirements for specified types of firmware and the management of
integrity and authenticity.
Component Leveling
FDP_MFW_EXT Mutable/Immutable
Firmware
2
1
3
FDP_MFW_EXT.1 Mutable/Immutable Firmware, requires the TSF to identify whether its
firmware resides in mutable or immutable storage.
FDP_MFW_EXT.2 Basic Firmware Integrity, requires the TSF to assert the integrity of the
firmware.
FDP_MFW_EXT.3 Firmware Authentication with Identity of Guarantor, requires the TSF to
assert the authenticity of the firmware.
Management: FDP_MFW_EXT.1
The following actions could be considered for the management functions in FMT:
 Update TOE firmware and pre-installed SDOs.
Management: FDP_MFW_EXT.2, FDP_MFW_EXT.3
No specific management functions are identified.
Audit: FDP_MFW_EXT.1, FDP_MFW_EXT.2, FDP_MFW_EXT.3
There are no auditable events foreseen.
FDP_MFW_EXT.1 Mutable/Immutable Firmware
Hierarchical to: No other components.
Dependencies: No dependencies.
FDP_MFW_EXT.1.1 The TSF shall be maintained as [selection: immutable, mutable] firmware.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 113 of 140
FDP_MFW_EXT.2 Basic Firmware Integrity
Hierarchical to: No other components.
Dependencies: FDP_MFW_EXT.1 Mutable/Immutable Firmware
FCS_COP.1 Cryptographic Operation
FDP_MFW_EXT.2.1 The TSF shall have the ability to verify the integrity of the firmware.
FDP_MFW_EXT.2.2 The TSF shall provide a capability to generate evidence of the integrity of
the firmware.
FDP_MFW_EXT.3 Firmware Authentication with Identity of Guarantor
Hierarchical to: No other components.
Dependencies: FDP_MFW_EXT.1 Mutable/Immutable Firmware
FCS_COP.1 Cryptographic Operation
FDP_MFW_EXT.3.1 The TSF shall have the ability to verify the authenticity of the firmware.
FDP_MFW_EXT.3.2 The TSF shall provide a capability to generate evidence of the authenticity
of the firmware.
C.2.5 FDP_SDC_EXT Confidentiality of SDEs
Family Behavior
This family defines requirements for maintaining the confidentiality of SDEs.
Component Leveling
FDP_SDC_EXT Confidentiality of
SDEs
1
FDP_SDC_EXT.1 Confidentiality of SDEs, requires the TSF to specify the method used to ensure
the confidentiality of stored SDEs.
Management: FDP_SDC_EXT.1
No specific management functions are identified.
Audit: FDP_SDC_EXT.1
There are no auditable events foreseen.
FDP_SDC_EXT.1 Confidentiality of SDEs
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 114 of 140
Hierarchical to: No other components.
Dependencies: FCS_CKM.1 Cryptographic Key Generation
FDP_SDC_EXT.1.1 The TSF shall use [assignment: confidentiality protection mechanism] to
protect the confidentiality of authorization data and [assignment: list of internally and externally
stored SDEs identified in the Confidential SDE List attribute of an SDO].
FDP_SDC_EXT.1.2 The TSF shall use FCS_CKM.1 to derive or generate the key to encrypt the
SDEs.
C.3 Class FIA: Identification and Authentication
C.3.1 FIA_AFL_EXT Authorization Failure Handling
Family Behavior
This family defines requirements for the TOE’s behavior when repeated failed attempts to gain
authorization to access TSF data occur.
Component Leveling
FIA_AFL_EXT Authorization Failure
Handling
1
2
FIA_AFL_EXT.1 Authorization Failure Handling, requires the TSF to monitor authorization
attempts, including counting and limiting the number of attempts at failed or passed authorizations.
FIA_AFL_EXT.2 Authorization Failure Response, requires the TSF to control who is authorized
to unlock failed authorization attempts.
Management: FIA_AFL_EXT.1
The following actions could be considered for the management functions in FMT:
 Set authorization failure parameters.
Management: FIA_AFL_EXT.2
The following actions could be considered for the management functions in FMT:
 Unlock access to SDO following excessive failed authorization attempts.
Audit: FIA_AFL_EXT.1, FIA_AFL_EXT.2
There are no auditable events foreseen.
FIA_AFL_EXT.1 Authorization Failure Handling
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 115 of 140
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_AFL_EXT.1.1 The TSF shall maintain [selection: a unique counter for [assignment:
multiple separate objects each requiring authorization], one global counter covering [assignment:
objects requiring authorization]], called the failed authorization attempt counters, that counts of
the number of unsuccessful authorization attempts that occur related to authorizing access to these
objects.
FIA_AFL_EXT.1.2 The TSF shall maintain a [selection, choose one of: static, administrator
configurable variable] threshold of the minimal acceptable number of unsuccessful authorization
attempts that occur related to authorizing access to these objects.
FIA_AFL_EXT.1.3 When the failed authorization attempt counters [selection, choose one of:
meets, surpasses] the threshold for unsuccessful authorization attempts, the TSF shall [assignment:
perform action that temporarily or permanently prevents access to the object] for these objects.
FIA_AFL_EXT.1.4 The TSF shall increment the failed authorization attempt counter before it
verifies the authorization.
FIA_AFL_EXT.2 Authorization Failure Response
Hierarchical to: No other components.
Dependencies: FIA_AFL_EXT.1 Authorization Failure Handling
FIA_AFL_EXT.2.1 When the TSF locks an object (i.e. prevents authorization attempts for an
object) due to a user exceeding the allowed threshold for unsuccessful authorization attempts, then
only an administrator may unlock access to the object and reset the corresponding failed
authorization attempt counter.
C.4 Class FMT: Security Management
C.4.1 FMT_MOF_EXT Management of Functions in TSF
Family Behavior
This family defines requirements for who is allowed to perform administrative functions.
Component Leveling
FMT_MOF_EXT Management of
Functions in TSF
1
FMT_MOF_EXT.1 Management of Security Functions Behavior, requires the TSF to restrict
management functionality to authorized administrators.
Management: FMT_MOF_EXT.1
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 116 of 140
No specific management functions are identified.
Audit: FMT_MOF_EXT.1
There are no auditable events foreseen.
FMT_MOF_EXT.1 Management of Security Functions Behavior
Hierarchical to: No other components.
Dependencies: FMT_SMF.1 Specification of Management Functions
FMT_MOF_EXT.1.1 The TSF shall restrict the ability to perform the functions in FMT_SMF.1
to authenticated administrators.
C.5 Class FPT: Protection of the TSF
C.5.1 FPT_MOD_EXT Debug Modes
Family Behavior
This family defines requirements for debug modes.
Component Leveling
FPT_MOD_EXT Debug Modes 1
FPT_MOD_EXT.1 Debug Modes, requires the TSF to deny access to debug modes.
Management: FPT_MOD_EXT.1
No specific management functions are identified.
Audit: FPT_MOD_EXT.1
There are no auditable events foreseen.
FPT_MOD_EXT.1 Debug Modes
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_MOD_EXT.1.1The TSF shall provide no access to debug modes.
C.5.2 FPT_PRO_EXT Root of Trust
Family Behavior
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 117 of 140
This family defines requirements for the TOE’s implementation of a Root of Trust and its ability
to use this to assert the integrity of its stored data.
Component Leveling
FPT_PRO_EXT Root of Trust
1
2
FPT_PRO_EXT.1 Root of Trust, requires the TSF to maintain a Root of Trust and identify how it
is stored in memory.
FPT_PRO_EXT.2 Data Integrity Measurements, requires the TSF to generate integrity
measurements to assert its own integrity.
Management: FPT_PRO_EXT.1, FPT_PRO_EXT.2
No specific management functions are identified.
Audit: FPT_PRO_EXT.1, FPT_PRO_EXT.2
There are no auditable events foreseen.
FPT_PRO_EXT.1 Root of Trust
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_PRO_EXT.1.1 The TSF shall contain an SDO that contains the identity of the Root of Trust.
FPT_PRO_EXT.1.2 The TSF shall maintain Root of Trust data as [selection: immutable,
mutable if and only if its mutability is controlled by a unique identifiable owner].
FPT_PRO_EXT.2 Data Integrity Measurements
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_PRO_EXT.2.1 The TSF shall be able to quantify the integrity of the data protected by the
TOE by generating integrity measurements and assertions making them available to authorized
entities.
FPT_PRO_EXT.2.2 The TSF shall accumulate platform characteristics using a consistent
[assignment: description of process for accumulating platform characteristics] process in which
verified quantifiable measurements are accumulated to prove the integrity of its SDOs.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 118 of 140
C.5.3 FPT_ROT_EXT Root of Trust Services
Family Behavior
This family defines requirements for individual Root of Trust services that the TSF may
implement.
Component Leveling
FPT_ROT_EXT Root of Trust
Services
2
1
3
FPT_ROT_EXT.1 Root of Trust Services, requires the TSF to identify the specific Roots of Trust
it provides.
FPT_ROT_EXT.2 Root of Trust for Storage, requires the TSF to prevent unauthorized access to
data associated with its Root of Trust for Storage.
FPT_ROT_EXT.3 Root of Trust for Reporting Mechanisms, requires the TSF to implement a Root
of Trust for Reporting in the specified manner.
Management: FPT_ROT_EXT.1, FPT_ROT_EXT.2, FPT_ROT_EXT.3
No specific management functions are identified.
Audit: FPT_ROT_EXT.1, FPT_ROT_EXT.2, FPT_ROT_EXT.3
There are no auditable events foreseen.
FPT_ROT_EXT.1 Root of Trust Services
Hierarchical to: No other components.
Dependencies: FPT_PRO_EXT.1 Root of Trust
FPT_ROT_EXT.1.1 The TSF shall provide a Root of Trust for Storage, a Root of Trust for
Authorization, and [selection: Root of Trust for Measurement, Root of Trust for Reporting, no
others].
FPT_ROT_EXT.2 Root of Trust for Storage
Hierarchical to: No other components.
Dependencies: FPT_PRO_EXT.1 Root of Trust
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 119 of 140
FPT_ROT_EXT.2.1 The TSF shall prevent unauthorized access to SDOs associated with the
Root of Trust for Storage.
FPT_ROT_EXT.3 Root of Trust for Reporting Mechanisms
Hierarchical to: No other components.
Dependencies: FCS_COP.1 Cryptographic Operation
FPT_PRO_EXT.1 Root of Trust
FPT_ROT_EXT.1 Root of Trust Services
FPT_ROT_EXT.3.1 The TSF shall be able to attest to a state as represented by platform
characteristics with a Root of Trust for Reporting mechanism that uses for its identity [selection:
a cryptographically verifiable identity in FPT_PRO_EXT.1, an alias key bound to the
cryptographically verifiable identity in FPT_PRO_EXT.1] and using a signature algorithm as
specified in FCS_COP.1.
C.5.4 FPT_RPL_EXT Replay Detection
Family Behavior
This family defines requirements for protection of TSF data through detecting and acting upon
replay attempts
Component Leveling
FPT_RPL_EXT Replay Detection 1
FPT_RPL_EXT.1 Replay Prevention, requires the TSF to implement a specific method of replay
detection and use this to prevent unauthorized operations from being performed on TSF data.
Management: FPT_RPL_EXT.1
No specific management functions are identified.
Audit: FPT_RPL_EXT.1
There are no auditable events foreseen.
FPT_RPL_EXT.1 Replay Prevention
Hierarchical to: No other components.
Dependencies: No dependencies.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 120 of 140
FPT_RPL_EXT.1.1 The TSF shall have a mechanism for preventing replay of user authorization
of operations on SDOs using the following methods [selection: monotonic counters, random
nonces, [assignment: other methods as specified]].
FPT_RPL_EXT.1.2 The TSF shall detect replay for the following actions: [authorization of
operations on SDOs].
FPT_RPL_EXT.1.3 The TSF shall deny the requested operation on the SDO when it detects a
replay.
C.6 Class FTP: Trusted Path/Channels
C.6.1 FTP_CCMP_EXT CCM Protocol
Family Behavior
This family defines requirements for the implementation of CCMP.
Component Leveling
FTP_CCMP_EXT CCM Protocol 1
FTP_CCMP_EXT.1 CCM Protocol, requires the TSF to implement CCMP in the specified
manner.
Management: FTP_CCMP_EXT.1
No specific management functions are identified.
Audit: FTP_CCMP_EXT.1
There are no auditable events foreseen.
FTP_CCMP_EXT.1 CCM Protocol
Hierarchical to: No other components.
Dependencies: FCS_COP.1 Cryptographic Operation
FTP_CCMP_EXT.1.1 The TSF shall implement CCMP using [assignment: cryptographic
algorithm] in CCM mode and key size [assignment: key sizes] as defined in [assignment: list of
standards].
FTP_CCMP_EXT.1.2 The TSF shall discard incoming messages if authentication fails.
FTP_CCMP_EXT.1.3 The TSF shall discard incoming messages that are malformed or invalid.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 121 of 140
C.6.2 FTP_GCMP_EXT GCM Protocol
Family Behavior
This family defines requirements for the implementation of GCMP.
Component Leveling
FTP_GCMP_EXT GCM Protocol 1
FTP_GCMP_EXT GCM Protocol, requires the TSF to implement GCMP in the specified manner.
Management: FTP_GCMP_EXT.1
No specific management functions are identified.
Audit: FTP_GCMP_EXT.1
There are no auditable events foreseen.
FTP_GCMP_EXT.1 GCM Protocol
Hierarchical to: No other components.
Dependencies: FCS_COP.1 Cryptographic Operation
FTP_GCMP_EXT.1.1 The TSF shall implement GCMP using [assignment: cryptographic
algorithm] in GCM mode and key size [assignment: key sizes] as defined in [assignment: list of
standards].
FTP_GCMP_EXT.1.2 The TSF shall discard incoming messages if authentication fails.
FTP_GCMP_EXT.1.3 The TSF shall discard incoming messages that are malformed or invalid.
C.6.3 FTP_ITC_EXT Inter-TSF Trusted Channel
Family Behavior
This family defines requirements for the implementation of trusted communications with entities
external to the TOE.
Component Leveling
FTP_ITC_EXT Inter-TSF Trusted
Channel
1
FTP_ITC_EXT.1 Cryptographically Protected Communications Channels, requires the TSF to
implement either CCMP or GCMP as a method of communicating securely with external entities.
Management: FTP_ITC_EXT.1
No specific management functions are identified.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 122 of 140
Audit: FTP_ITC_EXT.1
There are no auditable events foreseen.
FTP_ITC_EXT.1 Cryptographically Protected Communications Channels
Hierarchical to: No other components.
Dependencies: FCS_COP.1 Cryptographic Operation
FTP_ITC_EXT.1.1 The TSF shall use [assignment: cryptographic protocol] protocol to provide
a communication channel between itself and [assignment: list of entities external to the TOE] that
protects channel data from disclosure and ensures the integrity of channel data.
C.6.4 FTP_ITE_EXT Encrypted Data Communications
Family Behavior
This family defines requirements for encryption of TSF data that is transmitted to an external
entity over an insecure channel.
Component Leveling
FTP_ITE_EXT Encrypted Data
Communications
1
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.
Management: FTP_ITE_EXT.1
No specific management functions are identified.
Audit: FTP_ITE_EXT.1
There are no auditable events foreseen.
FTP_ITE_EXT.1 Encrypted Data Communications
Hierarchical to: No other components.
Dependencies: FCS_COP.1 Cryptographic Operation
FTP_ITE_EXT.1.1 The TSF shall encrypt data for transfer between the TOE and [assignment:
list of entities external to the TOE] using a cryptographic algorithm and key size as specified in
FCS_COP.1, and using [assignment: keys, identified by how they are generated by or imported
into the TOE].
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 123 of 140
C.6.5 FTP_ITP_EXT Physically Protected Channel
Family Behavior
This family defines requirements for use of physically protected communications mechanisms.
Component Leveling
FTP_ITP_EXT Physically Protected
Channel
1
FTP_ITP_EXT.1 Physically Protected Channel, requires the TSF to use a physically protected
channel for transmission of data to an external entity.
Management: FTP_ITP_EXT.1
No specific management functions are identified.
Audit: FTP_ITP_EXT.1
There are no auditable events foreseen.
FTP_ITP_EXT.1 Physically Protected Channel
Hierarchical to: No other components.
Dependencies: No dependencies.
FTP_ITP_EXT.1.1 The TSF shall provide a physically protected communication channel
between itself and [assignment: list of other IT entities within the same platform].
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 124 of 140
Appendix D: Entropy Documentation and Assessment
This appendix describes the required supplementary information for each entropy source used by
the TOE.
The documentation of the entropy sources should be detailed enough that, after reading, the
evaluator will thoroughly understand the entropy source and why it can be relied upon to provide
sufficient entropy. This documentation should include multiple detailed sections: design
description, entropy justification, operating conditions, and health testing. This documentation is
not required to be part of the TSS in the public facing ST.
D.1 Design Description
Documentation shall include the design of each entropy source as a whole, including the
interaction of all entropy source components. Any information that can be shared regarding the
design should also be included for any third-party entropy sources that are included in the product.
The documentation will describe the operation of the entropy source to include how entropy is
produced, and how unprocessed (raw) data can be obtained from within the entropy source for
testing purposes. The documentation should walk through the entropy source design indicating
where the entropy comes from, where the entropy output is passed next, any post-processing of
the raw outputs (hash, XOR, etc.), if/where it is stored, and finally, how it is output from the
entropy source. Any conditions placed on the process (e.g., blocking) should also be described in
the entropy source design. Diagrams and examples are encouraged.
This design must also include a description of the content of the security boundary of the entropy
source and a description of how the security boundary ensures that an adversary outside the
boundary cannot affect the entropy rate.
If implemented, the design description shall include a description of how third-party applications
can add entropy to the RBG. A description of any RBG state saving between power-off and power-
on shall be included.
D.2 Entropy Justification
There should be a technical argument for where the unpredictability in the source comes from and
why there is confidence in the entropy source exhibiting probabilistic behavior (an explanation of
the probability distribution and justification for that distribution given the particular source is one
way to describe this). This argument will include a description of the expected entropy rate and
explain how you ensure that sufficient entropy is going into the TOE randomizer seeding process.
This discussion will be part of a justification for why the entropy source can be relied upon to
produce bits with entropy.
The entropy justification shall not include any data added from any third-party application or from
any state saving between restarts.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 125 of 140
D.3 Operating Conditions
Documentation will also include the range of operating conditions under which the entropy source
is expected to generate random data. It will clearly describe the measures that have been taken in
the system design to ensure the entropy source continues to operate under those conditions.
Similarly, documentation shall describe the conditions under which the entropy source is known
to malfunction or become inconsistent. Methods used to detect failure or degradation of the source
shall be included.
D.4 Health Testing
More specifically, all entropy source health tests and their rationale will be documented. This
will include a description of the health tests, the rate and conditions under which each health test
is performed (e.g., at startup, continuously, or on-demand), the expected results for each health
test, TOE behavior upon entropy source failure, and rationale indicating why each test is
believed to be appropriate for detecting one or more failures in the entropy source.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 126 of 140
Appendix E: SFR Dependencies Analysis
The dependencies between SFRs implemented by the TOE are addressed as follows.
SFR Dependencies Rationale Statement
FCS_CKM.1
[FCS_CKM.2 or FCS_COP.1]
FCS_CKM.4
All of FCS_CKM.2, FCS_CKM.4, and
FCS_COP.1 are required by the PP.
FCS_CKM.1/KEK
[FCS_CKM.2 or FCS_COP.1]
FCS_CKM.4
All of FCS_CKM.2, FCS_CKM.4, and
FCS_COP.1 are required by the PP.
FCS_CKM.2
[FDP_ITC.1, FDP_ITC.2, or
FCS_CKM.1]
FCS_CKM.4
FCS_CKM.1 and FCS_CKM.4 are required by
the PP. FDP_ITC_EXT.1 and FDP_ITC_EXT.2
are also required by the PP and equivalent to
FDP_ITC.1 in this case because they all relate to
a mechanism by which key data can be imported
into the TSF.
FCS_CKM.4
[FDP_ITC.1, FDP_ITC.2, or
FCS_CKM.1]
FCS_CKM.1 is required by the PP.
FDP_ITC_EXT.1 and FDP_ITC_EXT.2 are also
required by the PP and equivalent to FDP_ITC.1
in this case because they all relate to a
mechanism by which key data can be imported
into the TSF.
FCS_CKM_EXT.4 FCS_CKM.4 FCS_CKM.4 is required by the PP.
FCS_COP.1/Hash
[FDP_ITC.1, FDP_ITC.2, or
FCS_CKM.1]
FCS_CKM.4
FCS_CKM.1 and FCS_CKM.4 are required by
the PP. FDP_ITC_EXT.1 and FDP_ITC_EXT.2
are also required by the PP and equivalent to
FDP_ITC.1 in this case because they all relate to
a mechanism by which key data can be imported
into the TSF.
FCS_COP.1/HMAC
[FDP_ITC.1, FDP_ITC.2, or
FCS_CKM.1]
FCS_CKM.4
FCS_CKM.1 and FCS_CKM.4 are required by
the PP. FDP_ITC_EXT.1 and FDP_ITC_EXT.2
are also required by the PP and equivalent to
FDP_ITC.1 in this case because they all relate to
a mechanism by which key data can be imported
into the TSF.
FCS_COP.1/KAT
[FDP_ITC.1, FDP_ITC.2, or
FCS_CKM.1]
FCS_CKM.4
FCS_CKM.1 and FCS_CKM.4 are required by
the PP. FDP_ITC_EXT.1 and FDP_ITC_EXT.2
are also required by the PP and equivalent to
FDP_ITC.1 in this case because they all relate to
a mechanism by which key data can be imported
into the TSF.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 127 of 140
SFR Dependencies Rationale Statement
FCS_COP.1/KeyEnc
[FDP_ITC.1, FDP_ITC.2, or
FCS_CKM.1]
FCS_CKM.4
FCS_CKM.1 and FCS_CKM.4 are required by
the PP. FDP_ITC_EXT.1 and FDP_ITC_EXT.2
are also required by the PP and equivalent to
FDP_ITC.1 in this case because they all relate to
a mechanism by which key data can be imported
into the TSF.
FCS_COP.1/SigGen
[FDP_ITC.1, FDP_ITC.2, or
FCS_CKM.1]
FCS_CKM.4
FCS_CKM.1 and FCS_CKM.4 are required by
the PP. FDP_ITC_EXT.1 and FDP_ITC_EXT.2
are also required by the PP and equivalent to
FDP_ITC.1 in this case because they all relate to
a mechanism by which key data can be imported
into the TSF.
FCS_COP.1/SigVer
[FDP_ITC.1, FDP_ITC.2, or
FCS_CKM.1]
FCS_CKM.4
FCS_CKM.1 and FCS_CKM.4 are required by
the PP. FDP_ITC_EXT.1 and FDP_ITC_EXT.2
are also required by the PP and equivalent to
FDP_ITC.1 in this case because they all relate to
a mechanism by which key data can be imported
into the TSF.
FCS_COP.1/SKC
[FDP_ITC.1, FDP_ITC.2, or
FCS_CKM.1]
FCS_CKM.4
FCS_CKM.1 and FCS_CKM.4 are required by
the PP. FDP_ITC_EXT.1 and FDP_ITC_EXT.2
are also required by the PP and equivalent to
FDP_ITC.1 in this case because they all relate to
a mechanism by which key data can be imported
into the TSF.
FCS_RBG_EXT.1 FCS_COP.1 FCS_COP.1 is required by the PP.
FCS_SLT_EXT.1 FCS_RBG_EXT.1 FCS_RBG_EXT.1 is required by the PP.
FCS_STG_EXT.1 No dependencies. N/A
FCS_STG_EXT.2 FCS_COP.1 FCS_COP.1 is required by the PP.
FCS_STG_EXT.3
FCS_CKM.1
FCS_COP.1
FCS_STG_EXT.2
FCS_CKM.1, FCS_COP.1, and
FCS_STG_EXT.2 are all required by the PP.
FDP_ACC.1 FDP_ACF.1 FDP_ACF.1 is required by the PP.
FDP_ACF.1
FDP_ACC.1
FMT_MSA.1
FDP_ACC.1 and FMT_MSA.1 are required by
the PP.
FDP_ETC_EXT.2 FCS_COP.1 FCS_COP.1 is required by the PP.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 128 of 140
SFR Dependencies Rationale Statement
FDP_FRS_EXT.1 FDP_FRS_EXT.2
FDP_FRS_EXT.2 is an optional SFR in the PP. It
does not need to be required because the PP’s
definition of FDP_FRS_EXT.1 allows the ST
author to specify that no factory reset is possible,
in which case the behavior described by
FDP_FRS_EXT.2 is not triggered.
FDP_ITC_EXT.1
FCS_COP.1
[FTP_ITC_EXT.1,
FTP_ITE_EXT.1, or
FTP_ITP_EXT.1]
FCS_COP.1 is required by the PP.
FTP_ITC_EXT.1, FTP_ITE_EXT.1, and
FTP_ITP_EXT.1 are each selection-based SFRs
in the PP but the PP’s definition of
FDP_ITC_EXT.1 requires at least one of them to
be selected so the dependency is always
addressed.
FDP_ITC_EXT.2
FCS_COP.1
[FTP_ITC_EXT.1,
FTP_ITE_EXT.1, or
FTP_ITP_EXT.1]
FCS_COP.1 is required by the PP.
FTP_ITC_EXT.1, FTP_ITE_EXT.1, and
FTP_ITP_EXT.1 are each selection-based SFRs
in the PP but the PP’s definition of
FDP_ITC_EXT.1 requires at least one of them to
be selected so the dependency is always
addressed.
FDP_MFW_EXT.1 No dependencies. N/A
FDP_RIP.1 No dependencies. N/A
FDP_SDC_EXT.1 FCS_CKM.1 FCS_CKM.1 is required by this PP.
FDP_SDI.2 No dependencies. N/A
FIA_AFL_EXT.1 No dependencies. N/A
FIA_SOS.2 No dependencies. N/A
FIA_UAU.2 FIA_UID.1
This dependency is not present in the PP because
all of the methods used to access the TSF
(physically protected channels, encrypted data
buffers, or cryptographically protected data
channels) all implicitly identify the subject that is
attempting to authenticate to the TOE. Therefore,
it is not necessary to include a separate SFR that
requires subjects to be identified.
FIA_UAU.5 No dependencies. N/A
FIA_UAU.6 No dependencies. N/A
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 129 of 140
SFR Dependencies Rationale Statement
FMT_MOF_EXT.1 FMT_SMF.1 FMT_SMF.1 is required by this PP.
FMT_MSA.1
[FDP_ACC.1 or FDP_IFC.1]
FMT_SMR.1
FMT_SMF.1
FDP_ACC.1 and FMT_SMF.1 are required by
the PP. FMT_SMR.2 is hierarchical to
FMT_SMR.1 and is required by the PP.
FMT_MSA.3
FMT_MSA.1
FMT_SMR.1
FMT_MSA.1 is required by the PP.
FMT_SMR.2 is hierarchical to FMT_SMR.1 and
is required by the PP.
FMT_SMF.1 No dependencies. N/A
FMT_SMR.2 FIA_UID.1
This dependency is not present in the PP because
all of the methods used to access the TSF
(physically protected channels, encrypted data
buffers, or cryptographically protected data
channels) all implicitly identify the subject that is
attempting to authenticate to the TOE. Therefore,
it is not necessary to include a separate SFR that
requires subjects to be identified.
FPT_FLS.1/FI No dependencies. N/A
FPT_MOD_EXT.1 No dependencies. N/A
FPT_PHP.3 No dependencies. N/A
FPT_PRO_EXT.1 No dependencies. N/A
FPT_ROT_EXT.1 FPT_PRO_EXT.1 FPT_PRO_EXT.1 is required by this PP.
FPT_ROT_EXT.2 FPT_PRO_EXT.1 FPT_PRO_EXT.1 is required by this PP.
FPT_RPL_EXT.1 No dependencies. N/A
FPT_STM.1 No dependencies. N/A
FPT_TST.1 No dependencies. N/A
FRU_FLT.1 FPT_FLS.1
FPT_FLS.1 (as FPT_FLS.1/FI) is required by the
PP.
Table 18: SFR Dependencies Rationale for Mandatory SFRs
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 130 of 140
SFR Dependencies Rationale Statement
FCS_ENT_EXT.1 FCS_RBG_EXT.1 FCS_RBG_EXT.1 is required by this PP.
FCS_RBG_EXT.2 FCS_RBG_EXT.1 FCS_RBG_EXT.1 is required by this PP.
FPT_ITT.1 No dependencies. N/A
FPT_PRO_EXT.2 No dependencies. N/A
FPT_ROT_EXT.3
FCS_COP.1
FPT_PRO_EXT.1
FPT_ROT_EXT.1
All of FCS_COP.1, FPT_PRO_EXT.1, and
FPT_ROT_EXT.1 are required by this PP.
Table 19: SFR Dependencies Rationale for Optional SFRs
SFR Dependencies Rationale Statement
FCS_CKM.1/AK
[FCS_CKM.2 or FCS_COP.1]
FCS_CKM.4
All of FCS_CKM.2, FCS_CKM.4, and
FCS_COP.1 are required by the PP.
FCS_CKM.1/SK
[FCS_CKM.2 or FCS_COP.1]
FCS_CKM.4
All of FCS_CKM.2, FCS_CKM.4, and
FCS_COP.1 are required by the PP.
FCS_CKM_EXT.5
FCS_CKM.1
FCS_COP.1
FDP_SDC_EXT.1
All of FCS_CKM.1, FCS_COP.1, and
FDP_SDC_EXT.1 are required by the PP.
FCS_COP.1/PBKDF
[FDP_ITC.1, FDP_ITC.2, or
FCS_CKM.1]
FCS_CKM.4
FCS_CKM.1 and FCS_CKM.4 are required by
the PP. FDP_ITC_EXT.1 and FDP_ITC_EXT.2
are also required by the PP and equivalent to
FDP_ITC.1 in this case because they all relate to
a mechanism by which key data can be imported
into the TSF.
FDP_DAU.1/Prove No dependencies. N/A
FDP_FRS_EXT.2 FDP_FRS_EXT.1 FDP_FRS_EXT.1 is required by the PP.
FDP_MFW_EXT.2
FDP_MFW_EXT.1
FCS_COP.1
FDP_MFW_EXT.1 and FCS_COP.1 are required
by the PP.
FDP_MFW_EXT.3
FDP_MFW_EXT.1
FCS_COP.1
FDP_MFW_EXT.1 and FCS_COP.1 are required
by the PP.
FIA_AFL_EXT.2 FIA_AFL_EXT.1 FIA_AFL_EXT.1 is required by the PP.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 131 of 140
SFR Dependencies Rationale Statement
FPT_FLS.1/FW No dependencies. N/A
FPT_RPL.1/Rollback No dependencies. N/A
FTP_CCMP_EXT.1 FCS_COP.1 FCS_COP.1 is required by the PP.
FTP_GCMP_EXT.1 FCS_COP.1 FCS_COP.1 is required by the PP.
FTP_ITC_EXT.1 FCS_COP.1 FCS_COP.1 is required by the PP.
FTP_ITE_EXT.1 FCS_COP.1 FCS_COP.1 is required by the PP.
FTP_ITP_EXT.1 No dependencies. N/A
Table 20: SFR Dependencies Rationale for Selection-Based SFRs
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 132 of 140
Appendix F: Glossary
Term Meaning
Access In the context of SDOs, access to an SDO represents the list of
actions permissible with an SDO, including its generation, use,
modification, propagation, and destruction.
Administrator A type of user that has special privileges to manage the TSF.
Attestation The process of presenting verifiable evidence describing those
characteristics that affect integrity. Examples of these characteristics
are boot firmware and boot critical data which, combined, describe
the way the DSC booted. [SA]
Attributes Indications of characteristics or properties of the SDEs bound in an
SDO.
Authorization Value Critical data bound to an action by itself or to action on a subject.
Such data, when presented to the TOE, authorizes the action by itself
or authorizes the action on or with the subject respectively.
Authorization Data Collective term for authentication tokens and authorization values.
Authentication Token Critical data bound to a user. Such data, when presented to the TOE
and successfully verified by it, authenticates the user. The TOE may
use the successful authentication of a user as an authorization to
execute an action on its behalf.
Authenticator A shortened name for Authentication Token.
Boot Critical Data Critical data that persists across power cycles and determines
characteristics of the DSC. Examples of boot critical data can be DSC
configuration settings, certificates, and the results of measurements
obtained by the RoT for measurement.
Boot Firmware The first firmware that executes during the boot process.
Chain of Trust A Chain of Trust is anchored in a RoT and extends a trust boundary
by verifying the authenticity and integrity of successive components
before passing control to those components. [SA]
Client Application Entity who relies on the services provided by the platform or DSC.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 133 of 140
Term Meaning
Data Encryption Key An encryption key, usually for a symmetric algorithm, that encrypts
data that is not keying material.
Integrity Assurance of trustworthiness and accuracy.
Immutable Unchangeable.
Key Encryption Key An encryption key that encrypts other keying material. This is
sometimes called a key wrapping key. A KEK can be either
symmetric or asymmetric.
Known Answer Tests (KATs) Test vectors or data generated to determine the correctness of an
implementation.
Operator Human being who has physical possession of the platform on which
the DSC is located. [GD]
Owner Human being who controls/manages the platform on which the DSC
is located. May be remote. [GD]
Platform A platform consists of the hardware and firmware of a computing
entity.
Pre-installed SDO An SDO installed on the DSC by the manufacturer. The SDO
consists of an SDE and attributes, which if not explicitly expressed in
a data structure, are implicit based on the functions that have
exclusive access to the SDE.
Privileged Function Functions restricted to the role of administrator, which may include,
but are not limited to, provisioning keys, provisioning user
authorization values, de-provisioning user authorization values,
provisioning administrator authorization values, changing
authorization values, disabling key escrow, and configuring
cryptography.
Protected Data Blob Data in an encrypted structure that protects its confidentiality or
integrity (as required by the context in which it is used).
Protected Storage Protected Storage usually refers to DSC hardware used to store SDEs
or SDOs, and provide integrity protection for all items and
confidentiality for those items that require it. Protected Storage may
also refer to storage external to the DSC, which is usually encrypted
by keys maintained by the DSC’s internal protected storage
capabilities.
Protections Mechanisms that ensure components of a DSC (executable firmware
code and critical data) remain in a state of integrity and are protected
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 134 of 140
Term Meaning
from modification outside of authorized, authenticated processes and
entities. [NIST-ROTM]
Remote Secure Channel Logical channel to the DSC from a remote entity, which
cryptographically protects the confidentiality and integrity of the
channel content.
Root Encryption Key An encryption key that serves as the anchor of a hierarchy of keys.
Root of Trust (RoT) A RoT performs one or more security specific functions; establishing
the foundation on which all trust in a system is placed. [NIST-
ROTM]
RoT for Authorization (As defined by [GP_ROT]) The RoT for Authorization provides
reliable capabilities to assess authorization tokens and determine
whether or not they satisfy policies for access control.
RoT for Confidentiality (As defined by [GP_ROT]) The RoT for Confidentiality maintains
shielded locations for the purpose of storing sensitive data, such as
secret keys and passwords.
RoT for Integrity (As defined by [GP_ROT]) The RoT for Integrity maintains shielded
locations for the purpose of storing and protecting the integrity of
non-secret critical security parameters and platform characteristics.
Critical security parameters include, but are not limited to,
authorization values, public keys, and public key certificates.
RoT for Measurement (As defined by [GP_ROT]) The RoT for Measurement provides the
ability to reliably create platform characteristics.
RoT for Reporting (As defined by [GP_ROT]) The RoT for Reporting reliably reports
platform characteristics. It provides an interface that limits its
services to providing reports on its platform characteristics
authenticated by a platform identity.
RoT for Storage A RoT that acts as the RoT for Confidentiality and the RoT for
Integrity.
RoT for Update A RoT responsible for updating the firmware.
RoT for Verification A RoT responsible for verifying digital signatures.
Security Data Element (SDE) A Critical Security Parameter, such as a cryptographic key or
authorization token.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 135 of 140
Term Meaning
Security Data Object (SDO) An SDO may include one or more SDEs. SDOs bind SDEs with a set
of attributes.
Symmetric Encryption Key A value intend to input as a key to a symmetric encryption algorithm,
such as AES.
System A system consists of the platform hardware and firmware in addition
to the higher-level software running on top of it (kernel, user-space
processes, etc.).
Trusted Local Channel Physical channel to the DSC within the platform of which the DSC is
a part, which is protected by the operational environment to ensure
confidentiality and integrity.
User An administrator or client application.
Table 21: Glossary
See [CC1] for other Common Criteria abbreviations and terminology.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 136 of 140
Appendix G: Acronyms
Acronym Meaning
AES Advanced Encryption Standard
CA Client Application
CBC Cipher Block Chaining
CCM Counter with CBC-Message Authentication Code
CCMP CCM Protocol
CPU Central Processing Unit
CSP Critical Security Parameter
DAR Data-At-Rest
DEK Data Encryption Key
DH Diffie-Hellman
DSA Digital Signature Algorithm
ECDH Elliptic Curve Diffie Hellman
ECDSA Elliptic Curve Digital Signature Algorithm
EEPROM Electrically Erasable Programmable Read-Only Memory
FIPS Federal Information Processing Standards
FQDN Fully Qualified Domain Name
GCM Galois Counter Mode
HMAC Keyed-Hash Message Authentication Code
HTTPS Hypertext Transfer Protocol Secure
IEEE Institute of Electrical and Electronics Engineers
IP Internet Protocol
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 137 of 140
Acronym Meaning
ITSEF Information Technology Security Evaluation Facility
KEK Key Encryption Key
KMAC KECCACK Message Authentication Code
NIST National Institute of Standards and Technology
OS Operating System
PBKDF Password-Based Key Derivation Function
PP Protection Profile
RA Registration Authority
RBG Random Bit Generator
REK Root Encryption Key
ROM Read-only memory
RSA Rivest Shamir Adleman Algorithm
SDE Security Data Element
SDO Security Data Object
SFP Security Function Policy
SFR Security Functional Requirement
SHA Secure Hash Algorithm
SK Symmetric Key or Symmetric Encryption Key
SPI Security Parameter Index
SSH Secure Shell
ST Security Target
TLS Transport Layer Security
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 138 of 140
Acronym Meaning
TOE Target of Evaluation
TSF TOE Security Functionality
TSS TOE Summary Specification
USB Universal Serial Bus
Table 22: Acronyms
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 139 of 140
Appendix H: References
[FIPS-HMAC] National Institute of Standards and Technology. Federal Information Processing
Standard Publication (FIPS-PUB) 198-1, The Keyed-Hash Message Authentication Code
(HMAC), National Institute of Standards and Technology, July 2008
[FIPS-SHA] National Institute of Standards and Technology. Federal Information Processing
Standard Publication (FIPS-PUB) 180-4, Secure Hash Standard (SHS), National Institute
of Standards and Technology, March 2012.
[GD] Grawrock, David. Dynamics of a Trusted Platform: A building block approach. Intel Press,
2009.
[GP_ROT] GlobalPlatform Technology. Root of Trust Definitions and Requirements Version 1.1.
GlobalPlatform, June 2018.
[ISO-CIPH] ISO/IEC. ISO/IEC 18033-3:2010 Information Technology – Security Techniques –
Encryption Algorithms – Part 3: Block Ciphers, ISO/IEC, December 2012
[ISO-CMAC] ISO/IEC. ISO/IEC 9797-1 Information Technology – Security Techniques –
Message Authentication Codes (MACs) – Part 1: Mechanisms Using a Block Cipher,
ISO/IEC, December 1999
[ISO-HASH] ISO/IEC. ISO/IEC 10118-3:2018 IT Security Techniques – Hash-Functions – Part
3: Dedicated Hash-Functions, ISO/IEC, October 2018
[ISO-HMAC] ISO/IEC. ISO/IEC 9797-2:2011 Information Technology – Security Techniques –
Message Authentication Codes (MACs) – Part 2: Mechanisms Using a Dedicated Hash-
Function
[ISO-TR] ISO/IEC. ISO/IEC 24759-3:2017 Information Technology – Security Techniques –
Test Requirements for Cryptographic Modules, ISO/IEC, 2017
[NIST-CMAC] Dworkin, Morris. National Institute of Standards and Technology (NIST) Special
Publication 800-38B, Recommendation for Block Cipher Modes of Operation: The CMAC
Mode for Authentication, National Institute of Standards and Technology, December 2012.
[NIST-KDRV] Barker, Elaine, Lily Chen, and Rich Davis. NIST Special Publication 800-56C,
Recommendation for Key-Derivation Methods in Key-Establishment Schemes, National
Institute of Standards and Technology, April 2018.
[NIST-KDV] Kelsey, John, Shu-jen Chang, and Ray Perlner. NIST Special Publication 800-185
SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash, and ParallelHash, National
Institute of Standards and Technology, December 2016.
[NIST-ROTM] Chen, Lily, Joshua Franklin, and Andrew Regenscheid. National Institute of
Standards and Technology (NIST) Special Publication 800-164 (Draft), Guidelines on
Hardware Rooted Security in Mobile Devices (Draft), National Institute of Standards and
Technology, October 2012.
collaborative Protection Profile for Dedicated Security Components
v1.0, 10-September-2020 Page 140 of 140
[NIST-RSA] Barker, Elaine, Lily Chen, Andrew Regenscheid, and Miles Smid. National Institute
of Standards and Technology (NIST) Special Publication 800-56B Revision 2,
Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization
Cryptography, National Institute of Standards and Technology, March 2019.
[SA] Segall, Ariel. Trusted Platform Modules: Why, When and How to Use Them. The Institution
of Engineering and Technology, 2016.