PP Reference: collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201
collaborative Protection Profile for Full Drive
1
Encryption - Encryption Engine
2
February 1, 2019
3
4
5
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 2 of 75
Acknowledgements
1
This collaborative Protection Profile (cPP) was developed by the Full Drive Encryption
2
international Technical Community with representatives from industry, Government agencies,
3
Common Criteria Test Laboratories, and members of academia.
4
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 3 of 75
0. Preface
1
0.1 Objectives of Document
2
This document presents the Common Criteria (CC) collaborative Protection Profile (cPP) to
3
express the security functional requirements (SFRs) and security assurance requirements
4
(SARs) for a Full Drive Encryption - Encryption Engine. The Evaluation Activities that specify
5
the actions the evaluator performs to determine if a product satisfies the SFRs captured within
6
this cPP are described in Supporting Document (Mandatory Technical Document) Full Drive
7
Encryption: Encryption Engine, February 2019.
8
A complete FDE solution requires both an Authorization Acquisition component and
9
Encryption Engine component. A product may provide the entire solution and claim
10
conformance to this cPP (Full Drive Encryption: Encryption Engine (FDE-EE)), and the Full
11
Drive Encryption: Authorization Acquisition (FDE-AA) cPP.
12
However, because the FDE AA/EE Protection Profile suite is in its infancy, it is not yet possible
13
to mandate that all dependent products will conform to a cPP. Non-validated dependent
14
products (i.e., EE) may be considered to be an acceptable part of the Operational Environment
15
for the AA TOE/product on a case-by-case basis as determined by the relevant national scheme.
16
The FDE iTC intends to develop guidance for developers whose products provide both
17
components (i.e., an AA and EE) to aid them in developing a Security Target (ST) that can
18
claim conformance to both FDE cPPs. One important aspect to note is:
19
Note to ST authors: There is a selection in the ASE_TSS that must be completed. One
20
cannot simply reference the SARs in this cPP.
21
0.2 Scope of Document
22
The scope of the cPP within the development and evaluation process is described in the
23
Common Criteria for Information Technology Security Evaluation. In particular, a cPP defines
24
the IT security requirements of a technology specific type of TOE and specifies the functional
25
and assurance security requirements to be met by a compliant TOE.
26
0.3 Intended Readership
27
The target audiences of this cPP are developers, CC consumers, system integrators, evaluators
28
and schemes.
29
0.4 Related Documents
30
Protection Profiles
31
[FDE – AA] collaborative Protection Profile for Full Drive Encryption – Authorization
32
Acquisition, Version 2.0 + Errata 20190201, February 1, 2019
33
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 4 of 75
Common Criteria1
1
[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.
[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.
[SD] Supporting Document (Mandatory Technical Document), Full Drive
Encryption: Encryption Engine, February 2019.
2
1
For details see http://www.commoncriteriaportal.org/
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 5 of 75
1
0.5 Revision History
2
Version Date Description
0.1 August 26, 2014 Initial Release for iTC review
0.2 September 5, 2014 Draft published for Public review
0.13 October 17, 2014 Incorporated comments received from the Public review
1.0 January 26, 2015 Incorporated comments received from the CCDB review
1.5 September 2, 2015 Revised based on additional use cases developed by iTC
2.0 September 09, 2016 Incorporated comments received from the public review, and also
updated the Key Destruction section and AVA_VAN.
2.0 + Errata
20190201
February 1, 2019 Updated to reflect CC Part 3 evaluation findings and FDE
Interpretation Team [FIT] rulings
3
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 6 of 75
Contents
1
Acknowledgements ................................................................................................................................................ 2
2
0. Preface .............................................................................................................................................................. 3
3
0.1 Objectives of Document ........................................................................................................................ 3
4
0.2 Scope of Document................................................................................................................................ 3
5
0.3 Intended Readership .............................................................................................................................. 3
6
0.4 Related Documents................................................................................................................................ 3
7
Protection Profiles ................................................................................................................................. 3
8
Common Criteria ................................................................................................................................... 4
9
0.5 Revision History.................................................................................................................................... 5
10
1. PP Introduction ............................................................................................................................................... 10
11
1.1 PP Reference Identification ................................................................................................................. 10
12
1.2 Introduction to the FDE Collaborative Protection Profiles (cPPs) Effort............................................ 10
13
1.3 Implementations .................................................................................................................................. 11
14
1.4 Target of Evaluation (TOE) Overview ................................................................................................ 11
15
1.4.1 Encryption Engine Introduction ............................................................................................ 11
16
1.4.2 Encryption Engine Security Capabilities .............................................................................. 12
17
1.4.3 The TOE and the Operational/Pre-Boot Environments......................................................... 13
18
1.5 Functionality Deferred until the Next cPP........................................................................................... 13
19
1.6 TOE Use Case ..................................................................................................................................... 13
20
2. CC Conformance Claims ................................................................................................................................ 15
21
3. Security Problem Definition ........................................................................................................................... 16
22
3.1 Threats ................................................................................................................................................. 16
23
3.2 Assumptions ........................................................................................................................................ 20
24
3.3 Organizational Security Policy ............................................................................................................ 21
25
4. Security Objectives ......................................................................................................................................... 22
26
4.1 Security Objectives for the Operational Environment ......................................................................... 22
27
5. Security Functional Requirements .................................................................................................................. 24
28
5.1 Conventions......................................................................................................................................... 24
29
5.2 SFR Architecture ................................................................................................................................. 24
30
5.3 Class: Cryptographic Support (FCS) ................................................................................................... 25
31
FCS_CKM.1(c) Cryptographic Key Generation (Data Encryption Key) ............................................ 25
32
FCS_CKM.4(a) Cryptographic Key Destruction (Power Management) ............................................. 25
33
FCS_CKM_EXT.4(a) Cryptographic Key and Key Material Destruction (Destruction Timing) ....... 26
34
FCS_CKM_EXT.4(b) Cryptographic Key and Key Material Destruction (Power Management) ...... 26
35
FCS_CKM_EXT.6 Cryptographic Key Destruction Types................................................................. 26
36
FCS_KYC_EXT.2 Key Chaining (Recipient)..................................................................................... 27
37
FCS_SNI_EXT.1 Cryptographic Operation (Salt, Nonce, and Initialization Vector Generation)....... 27
38
FCS_VAL_EXT.1 Validation ............................................................................................................. 28
39
5.4 Class: User Data Protection (FDP) ...................................................................................................... 29
40
FDP_DSK_EXT.1 Protection of Data on Disk.................................................................................... 29
41
5.5 Class: Security Management (FMT).................................................................................................... 29
42
FMT_SMF.1 Specification of Management Functions ....................................................................... 29
43
5.6 Class: Protection of the TSF (FPT)...................................................................................................... 30
44
FPT_KYP_EXT.1 Protection of Key and Key Material...................................................................... 30
45
FPT_PWR_EXT.1 Power Saving States ............................................................................................. 31
46
FPT_PWR_EXT.2 Timing of Power Saving States ............................................................................ 31
47
FPT_TST_EXT.1 TSF Testing............................................................................................................ 31
48
FPT_TUD_EXT.1 Trusted Update...................................................................................................... 32
49
6. Security Assurance Requirements................................................................................................................... 33
50
6.1 ASE: Security Target........................................................................................................................... 33
51
6.2 ADV: Development............................................................................................................................. 34
52
6.2.1 Basic Functional Specification (ADV_FSP.1)...................................................................... 34
53
6.3 AGD: Guidance Documentation.......................................................................................................... 34
54
6.3.1 Operational User Guidance (AGD_OPE.1) .......................................................................... 35
55
6.3.2 Preparative Procedures (AGD_PRE.1) ................................................................................. 35
56
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 7 of 75
6.4 Class ALC: Life-cycle Support............................................................................................................ 35
1
6.4.1 Labelling of the TOE (ALC_CMC.1) ................................................................................... 35
2
6.4.2 TOE CM Coverage (ALC_CMS.1)....................................................................................... 35
3
6.5 Class ATE: Tests ................................................................................................................................. 35
4
6.5.1 Independent Testing – Conformance (ATE_IND.1) ............................................................. 36
5
6.6 Class AVA: Vulnerability Assessment................................................................................................ 36
6
6.6.1 Vulnerability Survey (AVA_VAN.1) ................................................................................... 36
7
Appendix A: Optional Requirements ................................................................................................................... 37
8
A.1 Internal Cryptographic Implementation............................................................................................... 37
9
A.2 Firmware Update Validation ............................................................................................................... 37
10
FPT_FAC_EXT.1 Firmware Access Control ...................................................................................... 37
11
FPT_RBP_EXT.1 Rollback Protection ............................................................................................... 38
12
A.3 Cryptographic Key Destruction........................................................................................................... 38
13
FCS_CKM.4(e) Cryptographic Key Destruction (Key Cryptographic Erase)..................................... 38
14
Appendix B: Selection-Based Requirements........................................................................................................ 39
15
B.1 Class: Cryptographic Support (FCS) ................................................................................................... 39
16
FCS_CKM.1(a) Cryptographic Key Generation (Asymmetric Keys)................................................. 39
17
FCS_CKM.1(b) Cryptographic Key Generation (Symmetric Keys) ................................................... 40
18
FCS_CKM.4(b) Cryptographic Key Destruction (TOE-Controlled Hardware).................................. 40
19
FCS_CKM.4(c) Cryptographic Key Destruction (General Hardware)................................................ 41
20
FCS_CKM.4(d) Cryptographic Key Destruction (Software TOE, 3rd
Party Storage)......................... 42
21
FCS_COP.1(a) Cryptographic Operation (Signature Verification) ..................................................... 43
22
FCS_COP.1(b) Cryptographic Operation (Hash Algorithm)............................................................... 44
23
FCS_COP.1(c) Cryptographic Operation (Message Authentication) .................................................. 44
24
FCS_COP.1(d) Cryptographic Operation (Key Wrapping)................................................................. 44
25
FCS_COP.1(e) Cryptographic Operation (Key Transport) ................................................................. 44
26
FCS_COP.1(f) Cryptographic Operation (AES Data Encryption/Decryption) ................................... 45
27
FCS_COP.1(g) Cryptographic Operation (Key Encryption)............................................................... 45
28
FCS_KDF_EXT.1 Cryptographic Key Derivation.............................................................................. 45
29
FCS_RBG_EXT.1 Random Bit Generation ........................................................................................ 46
30
FCS_SMC_EXT.1 Submask Combining............................................................................................. 47
31
B.2 Class: Protection of the TSF (FPT)...................................................................................................... 47
32
FPT_FUA_EXT.1 Firmware Update Authentication .......................................................................... 47
33
Appendix C: Extended Component Definitions ................................................................................................... 49
34
C.1 Background and Scope............................................................................................................................. 49
35
C.2 Extended Component Definitions ............................................................................................................ 49
36
FCS_CKM_EXT Cryptographic Key Management ............................................................................ 49
37
FCS_KDF_EXT Cryptographic Key Derivation................................................................................. 51
38
FCS_KYC_EXT Key Chaining........................................................................................................... 51
39
FCS_RBG_EXT Random Bit Generation ........................................................................................... 54
40
FCS_SMC_EXT Submask Combining................................................................................................ 55
41
FCS_SNI_EXT Cryptographic Operation (Salt, Nonce, and Initialization Vector Generation).......... 55
42
FCS_VAL_EXT Validation of Cryptographic Elements .................................................................... 56
43
FDP_DSK_EXT Protection of Data on Disk....................................................................................... 57
44
FPT_FAC_EXT Firmware Access Control......................................................................................... 58
45
FPT_FUA_EXT Firmware Update Authentication ............................................................................. 59
46
FPT_KYP_EXT Key and Key Material Protection............................................................................. 60
47
FPT_PWR_EXT Power Management ................................................................................................. 61
48
FPT_RBP_EXT Rollback Protection .................................................................................................. 62
49
FPT_TST_EXT TSF Testing............................................................................................................... 63
50
FPT_TUD_EXT Trusted Update......................................................................................................... 64
51
Appendix D: Entropy Documentation and Assessment........................................................................................ 66
52
D.1 Design Description................................................................................................................................... 66
53
D.2 Entropy Justification ................................................................................................................................ 66
54
D.3 Operating Conditions ............................................................................................................................... 67
55
D.4 Health Testing.......................................................................................................................................... 67
56
Appendix E: Key Management Description......................................................................................................... 68
57
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 8 of 75
Appendix F: Glossary........................................................................................................................................... 70
1
Appendix G: Acronyms........................................................................................................................................ 72
2
Appendix H: References....................................................................................................................................... 74
3
4
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 9 of 75
Figures / Tables
1
Figure 1: FDE Components..................................................................................................................................10
2
Table 1: Examples of cPP Implementations .........................................................................................................11
3
Figure 2: Encryption Engine Details ....................................................................................................................12
4
Figure 3: Operational Environment ......................................................................................................................13
5
Table 2 TOE Security Functional Requirements..................................................................................................25
6
Table 3: Security Assurance Requirements ..........................................................................................................33
7
Table 4: Extended Components............................................................................................................................49
8
9
10
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 10 of 75
1. PP Introduction
1
1.1 PP Reference Identification
2
PP Reference: collaborative Protection Profile for Full Drive Encryption - Encryption Engine
3
PP Version: 2.0 + Errata 20190201
4
PP Date: February 1, 2019
5
1.2 Introduction to the FDE Collaborative Protection Profiles (cPPs)
6
Effort
7
The purpose of the first set of Collaborative Protection Profiles (cPPs) for Full Drive
8
Encryption (FDE): Authorization Acquisition (AA) and Encryption Engine (EE) is to provide
9
requirements for Data-at-Rest protection for a lost device that contains storage. These cPPs
10
allow FDE solutions based in software and/or hardware to meet the requirements. The form
11
factor for a storage device may vary, but could include: system hard drives/solid state drives in
12
servers, workstations, laptops, mobile devices, tablets, and external media. A hardware solution
13
could be a Self-Encrypting Drive or other hardware-based solutions; the interface (USB,
14
SATA, etc.) used to connect the storage device to the host machine is outside the scope.
15
Full Drive Encryption encrypts all data (with certain exceptions) on the storage device and
16
permits access to the data only after successful authorization to the FDE solution. The
17
exceptions include the necessity to leave a portion of the storage device (the size may vary
18
based on implementation) unencrypted for such things as the Master Boot Record (MBR) or
19
other AA/EE pre-authentication software. These FDE cPPs interpret the term “full drive
20
encryption” to allow FDE solutions to leave a portion of the storage device unencrypted so
21
long as it contains no user or authorization data.
22
Since the FDE cPPs support a variety of solutions, two cPPs describe the requirements for the
23
FDE components shown in Figure 1.
24
25
The FDE cPP - Authorization Acquisition describes the requirements for the Authorization
26
Acquisition piece and details the necessary security requirements and assurance activities
27
necessary to interact with a user and result in the availability of a Border Encryption Value
28
(BEV).
29
The FDE cPP - Encryption Engine describes the requirements for the Encryption Engine piece
30
and details the necessary security requirements and assurance activities for the actual
31
encryption/decryption of the data by the DEK. Each cPP will also have a set of core
32
Authorization
Acquisition
Encryption
Engine
Figure 1: FDE Components
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 11 of 75
requirements for management functions, proper handling of cryptographic keys, updates
1
performed in a trusted manner, audit and self-tests.
2
This TOE description defines the scope and functionality of the Encryption Engine, and the
3
Security Problem Definition describes the assumptions made about the operating environment
4
and the threats to the EE that the cPP requirements address.
5
1.3 Implementations
6
Full Disk Encryption solutions vary with implementation and vendor combinations.
7
Therefore, vendors will evaluate products that provide both components of the Full Disk
8
Encryption Solution (AA and EE) against both cPPs – could be done in a single evaluation
9
with one ST. A vendor that provides a single component of a FDE solution would only evaluate
10
against the applicable cPP. The FDE cPP is divided into two documents to allow labs to
11
independently evaluate solutions tailored to one cPP or the other. When a customer acquires
12
an FDE solution, they will either obtain a single vendor product that meets the AA + EE cPPs
13
or two products, one of which meets the AA and the other of which meets the EE cPPs.
14
The table below illustrates a few examples for certification.
15
Table 1: Examples of cPP Implementations
16
Implementation cPP Description
Host AA Host software provides the interface to a self-encrypting drive
Self-Encrypting Drive
(SED)
EE
A self-encrypting drive used in combination with separate host
software
Software FDE AA + EE A software full drive encryption solution
Hybrid AA + EE
A single vendor’s combination of hardware (e.g. hardware encryption
engine or cryptographic co-processor) and software
1.4 Target of Evaluation (TOE) Overview
17
The target of evaluation for this cPP is either the Encryption Engine or a combined evaluation
18
of the set of cPP’s for FDE (Authorization Acquisition and Encryption Engine).
19
The following sections provide an overview of the functionality of the FDE EE cPP as well as
20
the security capabilities.
21
1.4.1 Encryption Engine Introduction
22
The Encryption Engine cPP objectives focus on data encryption, policy enforcement, and key
23
management. The EE is responsible for the generation, update, archival, recovery, protection,
24
and destruction of the DEK and other intermediate keys under its control. The EE receives a
25
BEV from the AA. The EE uses that BEV for the decryption of the DEK although other
26
intermediate keys may exist in between those two points. Key encryption keys (KEKs) wrap
27
other keys, notably the DEK or other intermediary keys which chain to the DEK. Key releasing
28
keys (KRKs) authorize the EE to release either the DEK or other intermediary keys which chain
29
to the DEK. These keys only differ in the functional use.
30
The EE determines whether to allow or deny a requested action based on the KEK or KRK
31
provided by the AA. Possible requested actions include but are not limited to changing of
32
encryption keys, decryption of data, and key sanitization of encryption keys (including the
33
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 12 of 75
DEK). The EE may offer additional policy enforcement to prevent access to ciphertext or the
1
unencrypted portion of the storage device. Additionally the EE may provide encryption support
2
for multiple users on an individual basis.
3
Figure 2 illustrates the components within EE and its relationship with AA.
4
5
1.4.2 Encryption Engine Security Capabilities
6
The Encryption Engine is ultimately responsible for ensuring that the data is encrypted using a
7
prescribed set of algorithms. The EE manages the decryption of the data on the storage device
8
through decryption of the DEK based on the validity of the BEV provided by the AA. It also
9
manages administrative functions, such as changing the DEK, managing the BEVs required for
10
decrypting or releasing the DEK, managing the intermediate wrapping keys under its control,
11
and performing a key sanitization.
12
The EE may provide key archiving and recovery functionality. The EE may manage the
13
archiving and recovery itself, or interface with the AA to perform this function. It may also
14
offer configurable features, which restricts the movement of keying material and disables
15
recovery functionality.
16
The foremost security objective of encrypting storage devices is to force an adversary to
17
perform an exhaustive search against a prohibitively large key space in order to recover the
18
DEK or other intermediate keys. The EE uses approved cryptography to generate, handle, and
19
protect keys to force an adversary who obtains an unpowered lost or stolen platform without
20
the authorization factors or intermediate keys to exhaust the encryption key space of
21
intermediate keys or DEK to obtain the data. The EE randomly generates DEKs and – in some
22
cases - intermediate keys. The EE uses DEKs in a symmetric encryption algorithm in an
23
appropriate mode along with appropriate initialization vectors for that mode to encrypt storage
24
units (e.g. sectors or blocks) on the storage device. The EE either encrypts the DEK with a
25
KEK or an intermediate key.
26
Encryption Engine
Data Encryption and Decryption
Key
Management
Authorization
Acquisition
Authorization
Checks and
Policy
Enforcement
Cryptographic
Erase
Figure 2: Encryption Engine Details
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 13 of 75
This version of the cPP includes additional security features, included advanced power saving
1
requirements and firmware signing requirements.
2
1.4.3 The TOE and the Operational/Pre-Boot Environments
3
The environment in which the EE functions may differ depending on the boot stage of the
4
platform in which it operates; see Figure 3. Aspects of initialization, and perhaps authorization
5
may be performed in the Pre-Boot environment, while provisioning, encryption, decryption
6
and management functionality are likely performed in the Operating System environment.
7
Some of these aspects may occur in both envrioments.
8
The Operating System environment may make a full range of services available to the
9
Encryption Engine, including hardware drivers, cryptographic libraries, and perhaps other
10
services external to the TOE.
11
The Pre-Boot environment is much more constrained with limited capabilities. This
12
environment turns on the minimum number of peripherals and loads only those drivers
13
necessary to bring the platform from a cold start to executing a fully functional operating
14
system with running applications.
15
The EE TOE may include or leverage features and functions within the operational
16
environment.
17
18
1.5 Functionality Deferred until the Next cPP
19
Due to time constraints, this cPP defers requirements for some important functionality until the
20
next version of the cPP. These include requirements for partition/volume management.
21
1.6 TOE Use Case
22
The use case for a product conforming to the FDE cPPs is to protect data at rest on a device
23
that is lost or stolen while powered off without any prior access by an adversary. The use case
24
where an adversary obtains a device that is in a powered state and is able to make modifications
25
Applications
Figure 3: Operational Environment
Operating System
Device Drivers
Hardware
Platform
Firmware
Run
Time
Boot
Operating
System
Environment
Pre-Boot
Environment
Operational
Environment
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 14 of 75
to the environment or the TOE itself (e.g., evil maid attacks) is not addressed by these cPPs
1
(i.e., FDE-AA and FDE- EE).
2
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 15 of 75
2. CC Conformance Claims
1
As defined by the references [CC1], [CC2], and [CC3], this cPP conforms to the requirements
2
of Common Criteria v3.1, Release 5. This cPP is CC Part 2 extended and CC Part 3 conformant.
3
Extended component definitions can be found in Appendix C.
4
The methodology applied for the cPP evaluation is defined in [CEM].
5
This cPP satisfies the following Assurance Families: APE_CCL.1, APE_ECD.1, APE_INT.1,
6
APE_OBJ.1, APE_REQ.1 and APE_SPD.1.
7
This cPP does not claim conformance to another cPP.
8
In order to be conformant to this cPP, a TOE must demonstrate Exact Conformance. Exact
9
Conformance is defined as the ST containing all of the requirements in section 5 of this cPP,
10
and potentially requirements from Appendix A or Appendix B of this cPP. While iteration is
11
allowed, no additional requirements (from the CC parts 2 or 3) are allowed to be included in
12
the ST. Further, no requirements in section 5 of this cPP are allowed to be omitted.
13
An ST can claim conformance with the FDE-AA in combination with the FDE-EE and still
14
maintain exact conformance.
15
The FDE Enterprise Management (EM) PP-Module can specify the FDE-AA and FDE-EE as
16
a set of Base-PPs for use with the FDE-EM in a PP-configuration.
17
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 16 of 75
3. Security Problem Definition
1
3.1 Threats
2
This section provides a narrative that describes how the requirements mitigate the mapped
3
threats. A requirement may mitigate aspects of multiple threats. A requirement may only
4
mitigate a threat in a limited way. Some requirements are optional, either because the TSF fully
5
mitigates the threat without the additional requirement(s) being claimed or because the TSF
6
relies on its Operational Environment to provide the functionality that is described by the
7
optional requirement(s).
8
A threat consists of a threat agent, an asset and an adverse action of that threat agent on that
9
asset. The threat agents are the entities that put the assets at risk if an adversary obtains a lost
10
or stolen storage device. Threats drive the functional requirements for the target of evaluation
11
(TOE). For instance, one threat below is T.UNAUTHORIZED_DATA_ACCESS. The threat
12
agent is the possessor (unauthorized user) of a lost or stolen storage device. The asset is the
13
data on the storage device, while the adverse action is to attempt to obtain those data from the
14
storage device. This threat drives the functional requirements for the encrypted storage device
15
(TOE) to authorize who can use the TOE to access the hard disk and encrypt/decrypt the data.
16
Since possession of the KEK, DEK, intermediate keys, authorization factors, submasks, and
17
random numbers or any other values that contribute to the creation of keys or authorization
18
factors could allow an unauthorized user to defeat the encryption, this SPD considers keying
19
material equivalent to the data in importance and they appear among the other assets addressed
20
below.
21
It is important to reemphasize at this point that this collaborative Protection Profile does not
22
expect the product (TOE) to defend against the possessor of the lost or stolen hard disk who
23
can introduce malicious code or exploitable hardware components into the Target of Evaluation
24
(TOE) or the Operational Environment. It assumes that the user physically protects the TOE
25
and that the Operational Environment provides sufficient protection against logical attacks.
26
One specific area where a conformant TOE offers some protection is in providing updates to
27
the TOE; other than this area, though, this cPP mandates no other countermeasures. Similarly,
28
these requirements do not address the “lost and found” hard disk problem, where an adversary
29
may have taken the hard disk, compromised the unencrypted portions of the boot device (e.g.,
30
MBR, boot partition), and then made it available to be recovered by the original user so that
31
they would execute the compromised code.
32
(T.UNAUTHORIZED_DATA_ACCESS) The cPP addresses the primary threat of
33
unauthorized disclosure of protected data stored on a storage device. If an adversary obtains a
34
lost or stolen storage device (e.g., a storage device contained in a laptop or a portable external
35
storage device), they may attempt to connect a targeted storage device to a host of which they
36
have complete control and have raw access to the storage device (e.g., to specified disk sectors,
37
to specified blocks).
38
[FMT_SMF.1, FPT_PWR_EXT.1, FPT_PWR_EXT.2, FCS_SNI_EXT.1,
39
FCS_VAL_EXT.1, FDP_DSK_EXT.1, FPT_TST_EXT.1, FCS_COP.1(f)]
40
Rationale: FDP_DSK_EXT.1 ensures the TOE performs full drive encryption, which
41
includes all protected data. “Full Drive Encryption” defined in Appendix F refers to
42
“partitions of logical blocks of user accessible data as defined by the file system that
43
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 17 of 75
indexes and partitions and an operating system that maps authorization to read or write
1
data to blocks in these partitions,” with the exception of the MBR and other AA/EE pre-
2
authentication software. This ensures that protected data is unexposed even if the device
3
is lost.
4
FPT_PWR_EXT.1 defines what power states are compliant for the TOE.
5
FPT_PWR_EXT.2 defines conditions in which the TOE will enter a compliant power
6
state. These requirements ensure the device is secure if lost in a compliant power state.
7
FMT_SMF.1 ensures the TSF provides the functions necessary to manage important
8
aspects of the TOE including requests to change and erase the DEK. The correct
9
behaviour of all cryptographic functionality is verified through the use of self-tests
10
[FPT_TST_EXT.1]. FCS_VAL_EXT.1 verifies correct authentication and limits
11
attempts to decrypt the data. FCS_SNI_EXT.1 ensures proper nonces and IVs are used
12
in the encryption of the data. FCS_COP.1(f) defines proper AES encryption.
13
(T.KEYING_MATERIAL_COMPROMISE) Possession of any of the keys, authorization
14
factors, submasks, and random numbers or any other values that contribute to the creation of
15
keys or authorization factors could allow an unauthorized user to defeat the encryption. The
16
cPP considers possession of keying material of equal importance to the data itself. Threat
17
agents may look for keying material in unencrypted sectors of the storage device and on other
18
peripherals in the operating environment (OE), e.g. BIOS configuration, SPI flash, or TPMs.
19
[FCS_CKM.4(a), FCS_CKM.4(b), FCS_CKM_EXT.4(a), FCS_CKM_EXT.4(b),
20
FCS_KYC_EXT.2, FMT_SMF.1, FPT_KYP_EXT.1, FPT_PWR_EXT.1,
21
FPT_PWR_EXT.2, FCS_CKM.1(c), FCS_SNI_EXT.1, FCS_VAL_EXT.1,
22
FPT_TST_EXT.1, FCS_CKM.1(a), FCS_CKM.1(b), FCS_COP.1(b), FCS_COP.1(c),
23
FCS_COP.1(d), FCS_COP.1(e), FCS_COP.1(f), FCS_COP.1(g), FCS_KDF_EXT.1,
24
FCS_RBG_EXT.1, FCS_SMC_EXT.1]
25
Rationale: The keying material that threat agents may attempt to compromise are
26
generated as specified by FCS_CKM.1(a), (b), and FCS_CKM.1(c), all of which are
27
generated properly via FCS_RBG_EXT.1. One or more submasks may be combined
28
[FCS_SMC_EXT.1] and/or chained [FCS_KYC_EXT.2] to protect the DEK. The key
29
chain can be maintained by several methods, including:
30
 Key derivation [FCS_KDF_EXT.1]
31
 Key wrapping [FCS_COP.1(d)]
32
 Key combining [FCS_SMC_EXT.1]
33
 Key transport [FCS_COP.1(e)]
34
 Key encryption [FCS_COP.1(g)]
35
These requirements ensure the BEV is properly protected. Proper generation of salts,
36
nonces, and IVs [FCS_SNI_EXT.1] is performed to support cryptographic functions
37
requiring their use (such as symmetric key generation and AES encryption and decryption
38
using Galois/Counter Mode [GCM]). This may involve the use of a random bit generator
39
[FCS_RBG_EXT.1]. FCS_VAL_EXT.1 defines methods for validation of the BEV such
40
as hashing [FCS_COP.1(b)], keyed-hash message authentication [FCS_COP.1(c)], and
41
decrypting a known value with the keying material [FCS_COP.1(f)]. Key data can also
42
be protected using submask combining [FCS_SMC_EXT.1] which can also be done
43
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 18 of 75
using a hash function. The correct behavior of all cryptographic functionality is verified
1
through the use of self-tests [FPT_TST_EXT.1].
2
FPT_KYP_EXT.1 ensures unwrapped key material is not stored in non-volatile memory
3
and FCS_CKM_EXT.4(a) along with FCS_CKM.4(a) ensures proper key material
4
destruction; minimizing the exposure of plaintext keys and key material.
5
Secure power management is essential to ensuring that power saving states cannot be
6
used by an attacker to access plaintext keying material. The TSF defines Compliant power
7
saving states [FPT_PWR_EXT.1] that encrypt or destroy [FCS_CKM.4(b),
8
FCS_CKM_EXT.4(b)] all keying material when entered by various conditions
9
[FPT_PWR_EXT.2]. This material is not decrypted until the BEV is validated
10
[FCS_VAL_EXT.1].
11
FMT_SMF.1 ensures the TSF provides the functions necessary to manage important
12
aspects of the TOE including modifying and erasing cryptographic data.
13
(T.AUTHORIZATION_GUESSING) Threat agents may exercise host software to repeatedly
14
guess authorization factors, such as passwords and PINs. Successful guessing of the
15
authorization factors may cause the TOE to release DEKs or otherwise put it in a state in which
16
it discloses protected data to unauthorized users.
17
[FCS_SNI_EXT.1, FCS_VAL_EXT.1]
18
Rationale: [FCS_VAL_EXT.1] requires several options for enforcing validation, such as
19
key sanitization of the DEK or when a configurable number of failed validation attempts
20
is reached within a 24 hour period. This mitigates brute force attacks against authorization
21
factors such as passwords and pins. Salts according to [FCS_SNI_EXT.1] may be used
22
which will prevent pre-computed attacks.
23
(T.KEYSPACE_EXHAUST) Threat agents may perform a cryptographic exhaust against the
24
key space. Poorly chosen encryption algorithms and/or parameters allow attackers to exhaust
25
the key space through brute force and give them unauthorized access to the data.
26
[FCS_KYC_EXT.2, FCS_CKM.1(a), FCS_CKM.1(b), FCS_CKM.1(c),
27
FCS_RBG_EXT.1]
28
Rationale: [FCS_CKM.1(a), (b), and (c)] and [FCS_RBG_EXT.1] ensure cryptographic
29
keys are random and of an appropriate strength/length to make exhaustion attempts
30
cryptographically difficult and cost prohibitive. [FCS_KYC_EXT.2] ensures all keys
31
protecting the DEK are of the same strength.
32
(T.KNOWN_PLAINTEXT) Threat agents know plaintext in regions of storage devices,
33
especially in uninitialized regions (all zeroes) as well as regions that contain well known
34
software such as operating systems. A poor choice of encryption algorithms, encryption modes,
35
and initialization vectors along with known plaintext could allow an attacker to recover the
36
effective DEK, thus providing unauthorized access to the previously unknown plaintext on the
37
storage device.
38
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 19 of 75
[FCS_COP.1(f) (optional), FCS_SNI_EXT.1]
1
Rationale: FCS_COP.1(f) ensures the proper choice of encryption algorithm and mode.
2
FCS_SNI_EXT.1 ensures proper handling of salts, nonces and initialization vectors.
3
(T.CHOSEN_PLAINTEXT) Threat agents may trick authorized users into storing chosen
4
plaintext on the encrypted storage device in the form of an image, document, or some other
5
file. A poor choice of encryption algorithms, encryption modes, and initialization vectors along
6
with the chosen plaintext could allow attackers to recover the effective DEK, thus providing
7
unauthorized access to the previously unknown plaintext on the storage device.
8
[FCS_COP.1(f) (optional), FCS_SNI_EXT.1]
9
Rationale: FCS_COP.1(f) ensures the proper choice of encryption algorithm and mode.
10
FCS_SNI_EXT.1 ensures proper handling of salts, nonces and initialization vectors.
11
(T.UNAUTHORIZED_UPDATE) Threat agents may attempt to perform an update of the
12
product which compromises the security features of the TOE. Poorly chosen update protocols,
13
signature generation and verification algorithms, and parameters may allow attackers to install
14
software that bypasses the intended security features and provides them unauthorized access to
15
data.
16
[FCS_COP.1(a) (optional), FMT_SMF.1, FPT_TUD_EXT.1]
17
Rationale: FPT_TUD_EXT.1 provides authorized users the ability to query the current
18
version of the TOE software, initiate updates, and verify updates prior to installation
19
using a manufacturer digital signature. FCS_COP.1(a) defines the signature function that
20
is used to verify updates.
21
FMT_SMF.1 ensures the TSF provides the functions necessary to manage important
22
behaviour of the TOE which includes the initiation of system software updates.
23
(T.UNAUTHORIZED_FIRMWARE_UPDATE) An attacker attempts to replace the firmware
24
on the SED via a command from the AA or from the host platform with a malicious firmware
25
update that may compromise the security features of the TOE.
26
[FCS_COP.1(a) (optional), FCS_COP.1(b) (optional), FMT_SMF.1,
27
FPT_FUA_EXT.1(optional), FPT_TUD_EXT.1, FPT_FAC_EXT.1(optional),
28
FPT_RBP_EXT.1(optional)]
29
Rationale: FPT_TUD_EXT.1 defines a secure mechanism for updating the TOE
30
firmware, initiated by a management function provided by FMT_SMF.1. FCS_COP.1(a)
31
and FCS_COP.1(b) define the cryptographic functions that can be used to validate the
32
authenticity and integrity of firmware updates as defined by FPT_FUA_EXT.1.
33
FPT_FAC_EXT.1 provides additional security by only allowing an update to be initiated
34
if the initiator can provide information that would only be known to a trusted
35
administrator. FPT_RBP_EXT.1 protects against a malicious or inadvertent downgrade
36
of the firmware to an earlier version that may have security flaws not present in the more
37
recent version.
38
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 20 of 75
(T.UNAUTHORIZED_FIRMWARE_MODIFY) An attacker attempts to modify the firmware
1
in the SED via a command from the AA or from the host platform that may compromise the
2
security features of the TOE.
3
[FPT_FUA_EXT.1 (optional), FPT_TUD_EXT.1]
4
Rationale: FPT_FUA_EXT.1 ensures that the existing firmware cannot be modified
5
unless it is to replace it with a valid update that was initiated as part of FPT_TUD_EXT.1.
6
3.2 Assumptions
7
Assumptions that must remain true in order to mitigate the threats appear below:
8
(A.TRUSTED_CHANNEL) Communication among and between product components (e.g.,
9
AA and EE) is sufficiently protected to prevent information disclosure. In cases in which a
10
single product fulfils both cPPs, then the communication between the components does not
11
extend beyond the boundary of the TOE (e.g., communication path is within the TOE
12
boundary). In cases in which independent products satisfy the requirements of the AA and EE,
13
the physically close proximity of the two products during their operation means that the threat
14
agent has very little opportunity to interpose itself in the channel between the two without the
15
user noticing and taking appropriate actions.
16
[OE.TRUSTED_CHANNEL]
17
(A.INITIAL_DRIVE_STATE) Users enable Full Drive Encryption on a newly provisioned
18
storage device free of protected data in areas not targeted for encryption. It is also assumed that
19
data intended for protection should not be on the targeted storage media until after provisioning.
20
The cPP does not intend to include requirements to find all the areas on storage devices that
21
potentially contain protected data. In some cases, it may not be possible - for example, data
22
contained in “bad” sectors. While inadvertent exposure to data contained in bad sectors or un-
23
partitioned space is unlikely, one may use forensics tools to recover data from such areas of the
24
storage device. Consequently, the cPP assumes bad sectors, un-partitioned space, and areas that
25
must contain unencrypted code (e.g., MBR and AA/EE pre-authentication software) contain
26
no protected data.
27
[OE.INITIAL_DRIVE_STATE]
28
(A.TRAINED_USER) Users follow the provided guidance for securing the TOE and
29
authorization factors. This includes conformance with authorization factor strength, using
30
external token authentication factors for no other purpose and ensuring external token
31
authorization factors are securely stored separately from the storage device and/or platform.
32
The user should also be trained on how to power off their system.
33
[OE.PASSPHRASE_STRENGTH, OE. POWER_DOWN, OE.SINGLE_USE_ET,
34
OE.TRAINED_USERS]
35
(A.PLATFORM_STATE) The platform in which the storage device resides (or an external
36
storage device is connected) is free of malware that could interfere with the correct operation
37
of the product.
38
[OE.PLATFORM_STATE]
39
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 21 of 75
(A.POWER_DOWN) The user does not leave the platform and/or storage device unattended
1
until the device is in a Compliant power saving state or has fully powered off. This properly
2
clears memories and locks down the device. Authorized users do not leave the platform and/or
3
storage device in a mode where sensitive information persists in non-volatile storage (e.g., lock
4
screen or sleep state). Users power the platform and/or storage device down or place it into a
5
power managed state, such as a “hibernation mode”.
6
[OE.POWER_DOWN]
7
(A.STRONG_CRYPTO) All cryptography implemented in the Operational Environment and
8
used by the product meets the requirements listed in the cPP. This includes generation of
9
external token authorization factors by a RBG.
10
[OE.STRONG_ENVIRONMENT_CRYPTO]
11
(A.PHYSICAL) The platform is assumed to be physically protected in its Operational
12
Environment and not subject to physical attacks that compromise the security and/or interfere
13
with the platform’s correct operation.
14
[OE.PHYSICAL]
15
3.3 Organizational Security Policy
16
There are no organizational security policies addressed by this cPP.
17
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 22 of 75
4. Security Objectives
1
4.1 Security Objectives for the Operational Environment
2
The Operational Environment of the TOE implements technical and procedural measures to
3
assist the TOE in correctly providing its security functionality. This part wise solution forms
4
the security objectives for the Operational Environment and consists of a set of statements
5
describing the goals that the Operational Environment should achieve.
6
(OE.TRUSTED_CHANNEL) Communication among and between product components (e.g.,
7
AA and EE) is sufficiently protected to prevent information disclosure.
8
Rationale: In situations where there is an opportunity for an adversary to interpose
9
themselves in the channel between the AA and the EE, a trusted channel should be
10
established to prevent exploitation. [A.TRUSTED_CHANNEL] assumes the existence
11
of a trusted channel between the AA and EE, except for when the boundary is within
12
and does not breach the TOE or is in such close proximity that a breach is not possible
13
without detection.
14
(OE.INITIAL_DRIVE_STATE) The OE provides a newly provisioned or initialized storage
15
device free of protected data in areas not targeted for encryption.
16
Rationale: Since the cPP requires all protected data be encrypted, A.
17
INITIAL_DRIVE_STATE assumes that the initial state of the device targeted for FDE
18
is free of protected data in those areas of the drive where encryption will not be invoked
19
(e.g., MBR and AA/EE pre-authentication software). Given this known start state, the
20
product (once installed and operational) ensures partitions of logical blocks of user
21
accessible data is protected.
22
(OE.PASSPHRASE_STRENGTH) An authorized administrator will be responsible for
23
ensuring that the passphrase authorization factor conforms to guidance from the Enterprise
24
using the TOE.
25
Rationale: Users are properly trained [A.TRAINED_USER] to create authorization
26
factors that conform to administrative guidance.
27
(OE.POWER_DOWN) Volatile memory is cleared after entering a Compliant power saving
28
state or turned off so memory remnant attacks are infeasible.
29
Rationale: Users are properly trained [A_TRAINED_USER] to not leave the storage
30
device unattended until it is in a Compliant power saving state or fully turned off.
31
(OE.SINGLE_USE_ET) External tokens that contain authorization factors will be used for no
32
other purpose than to store the external token authorization factor.
33
Rationale: Users are properly trained [A.TRAINED_USER] to use external token
34
authorization factors as intended and for no other purpose.
35
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 23 of 75
(OE.STRONG_ENVIRONMENT_CRYPTO) The Operating Environment will provide a
1
cryptographic function capability that is commensurate with the requirements and capabilities
2
of the TOE and Appendix A.
3
Rationale: All cryptography implemented in the Operational Environment and used by
4
the product meets the requirements listed in this cPP [A.STRONG_CRYPTO].
5
(OE.TRAINED_USERS) Authorized users will be properly trained and follow all guidance for
6
securing the TOE and authorization factors.
7
Rationale: Users are properly trained [A.TRAINED_USER] to create authorization
8
factors that conform to guidance, not store external token authorization factors with the
9
device, and power down the TOE when required (OE.PLATFORM_STATE). The
10
platform in which the storage device resides (or an external storage device is connected)
11
is free of malware that could interfere with the correct operation of the product.
12
A platform free of malware [A.PLATFORM_STATE] prevents an attack vector that
13
could potentially interfere with the correct operation of the product.
14
(OE.PHYSICAL) The Operational Environment will provide a secure physical computing
15
space such that an adversary is not able to make modifications to the environment or to the
16
TOE itself.
17
Rationale: As stated in section 1.6, the use case for this cPP is to protect data at rest on a
18
device where the adversary receives it in a powered off state and has no prior access.
19
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 24 of 75
5. Security Functional Requirements
1
The individual security functional requirements are specified in the sections below. Based on
2
selections made in these SFRs it will also be necessary to include some of the selection-based
3
SFRs in Appendix B. Additional optional SFRs may also be adopted from those listed in
4
Appendix A for those functions that are provided by the TOE instead of its Operational
5
Environment.
6
The Evaluation Activities defined in [SD] describe actions that the evaluator will take in order
7
to determine compliance of a particular TOE with the SFRs. The content of these Evaluation
8
Activities will therefore provide more insight into deliverables required from TOE Developers.
9
5.1 Conventions
10
The conventions used in descriptions of the SFRs are as follows:
11
 Assignment: Indicated with italicized text;
12
 Refinement made by PP author: Indicated with bold text or strikethroughs for text that
13
is added to or removed from the original SFR—when the refinement operation
14
substitutes text, only the added text is included;
15
 Selection: Indicated with underlined text;
16
 Assignment within a Selection: Indicated with italicized and underlined text;
17
 Iteration: Indicated by appending the SFR with parentheses that contain a letter that is
18
unique for each iteration, e.g. (a), (b), (c) and/or with a slash (/) followed by a
19
descriptive string for the SFR’s purpose, e.g. /Server.
20
SFR text that is bold, italicized, and underlined indicates that the original SFR defined an
21
assignment operation but the PP author completed that assignment by redefining it as a
22
selection operation, which is also considered to be a refinement of the original SFR.
23
If the selection or assignment is to be completed by the ST author, it is preceded by ‘selection:’
24
or ‘assignment:’. If the selection or assignment has been completed by the PP author and the
25
ST author does not have the ability to modify it, the proper formatting convention is applied
26
but the preceding word is not included. The exception to this is if the SFR definition includes
27
multiple options in a selection or assignment and the PP has excluded certain options but at
28
least two remain. In this case, the selection or assignment operations that are not permitted by
29
this PP were removed without applying additional formatting and the ‘selection:’ or
30
‘assignment:’ text is preserved to show that the ST author still has the ability to choose from
31
the reduced set of options.
32
Extended SFRs (i.e. those SFRs that are not defined in CC Part 2) are identified by having a
33
label ‘_EXT’ at the end of the SFR name.
34
5.2 SFR Architecture
35
The following table lists the SFRs that are mandated by this cPP.
36
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 25 of 75
Table 2 TOE Security Functional Requirements
1
Functional Class Functional Components
Cryptographic Support (FCS)
FCS_CKM.1(c) Cryptographic Key Generation (Data Encryption Key)
FCS_CKM.4(a) Cryptographic Key Destruction (Power Management)
FCS_CKM_EXT.4(a) Cryptographic Key and Key Material Destruction
(Destruction Timing)
FCS_CKM_EXT.4(b) Cryptographic Key and Key Material Destruction
(Power Management)
FCS_CKM_EXT.6 Cryptographic Key Destruction Types
FCS_KYC_EXT.2 Key Chaining (Recipient)
FCS_SNI_EXT.1 Cryptographic Operation (Salt, Nonce, and Initialization
Vector Generation)
FCS_VAL_EXT.1 Validation
User Data Protection (FDP) FDP_DSK_EXT.1 Protection of Data on Disk
Security Management (FMT) FMT_SMF.1 Specification of Management Functions
Protection of the TSF (FPT)
FPT_KYP_EXT.1 Protection of Key and Key Material
FPT_PWR_EXT.1 Power Saving States
FPT_PWR_EXT.2 Timing of Power Saving States
FPT_TST_EXT.1 TSF Testing
FPT_TUD_EXT.1 Trusted Update
5.3 Class: Cryptographic Support (FCS)
2
FCS_CKM.1(c) Cryptographic Key Generation (Data Encryption Key)
3
FCS_CKM.1.1(c) Refinement: The TSF shall generate cryptographic keys in accordance
4
with a specified cryptographic key generation algorithm method [selection:
5
 generate a DEK using the RBG as specified in FCS_RBG_EXT.1,
6
 accept a DEK that is generated by the RBG provided by the host platform,
7
 accept a DEK that is wrapped as specified in FCS_COP.1(d)]
8
and specified cryptographic key sizes [selection: 128 bits, 256 bits] that meet the following:
9
[assignment: list of standards].
10
Application Note: This SFR is iterated because additional iterations are defined as optional
11
requirements in Appendix A. Iteration (c) was chosen specifically to ensure consistency
12
between the FDE cPPs.
13
The purpose of this requirement is to explain DEK generation during provisioning.
14
If the TOE can be configured to obtain a DEK through more than one method, the ST author
15
chooses the applicable options within the selection. For example, the TOE may generate
16
random numbers with an approved RBG to create a DEK, as well as provide an interface to
17
accept a DEK from the environment.
18
If the ST author chooses the first and/or third option in the selection, the corresponding
19
requirement is pulled from Appendix A and included in the body of the ST.
20
FCS_CKM.4(a) Cryptographic Key Destruction (Power Management)
21
FCS_CKM.4.1(a) Refinement: The TSF shall [selection: instruct the Operational
22
Environment to clear, erase] cryptographic keys and key material from volatile memory
23
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 26 of 75
when transitioning to a Compliant power saving state as defined by FPT_PWR_EXT.1
1
that meets the following: [a key destruction method specified in FCS_CKM_EXT.6].
2
Application Note: In some cases, erasure of keys from volatile memory is only supported by
3
the Operational Environment, in which case the Operational Environment must expose a well-
4
documented mechanism or interface to invoke the memory clearing operation.
5
Self-encrypting drives do not store keys in the Operational Environment and cannot instruct
6
the Operational Environment to perform functionality so they are not expected to select
7
“instruct the Operational Environment to clear”.
8
FCS_CKM_EXT.4(a) Cryptographic Key and Key Material Destruction (Destruction
9
Timing)
10
FCS_CKM_EXT.4.1(a) The TSF shall destroy all keys and keying material when no longer
11
needed.
12
Application Note: Keys, including intermediate keys and key material that are no longer
13
needed are destroyed by using an approved method, FCS_CKM_EXT.6. Examples of keys are
14
intermediate keys, submasks, and BEV. There may be instances where keys or key material that
15
are contained in persistent storage are no longer needed and require destruction. Based on
16
their implementation, vendors will explain when certain keys are no longer needed. There are
17
multiple situations in which key material is no longer necessary, for example, a wrapped key
18
may need to be destroyed when a password is changed. However, there are instances when
19
keys are allowed to remain in memory, for example, a device identification key.
20
FCS_CKM_EXT.4(b) Cryptographic Key and Key Material Destruction (Power
21
Management)
22
FCS_CKM_EXT.4.1(b) The TSF shall destroy all key material, BEV, and authentication
23
factors stored in plaintext when transitioning to a Compliant power saving state as defined by
24
FPT_PWR_EXT.1.
25
Application Note: The TOE may end up in a non-Compliant power saving state
26
indistinguishable from a Compliant power state (e.g. as result of sudden and/or unexpected
27
power loss). Guidance documentation must state what conditions may result in clear text keys
28
or key materials to stay in volatile memory and identify mitigation measures that result in
29
clearing of volatile memory.
30
FCS_CKM_EXT.6 Cryptographic Key Destruction Types
31
FCS_CKM_EXT.6.1 The TSF shall use [selection: FCS_CKM.4(b), FCS_CKM.4(c),
32
FCS_CKM.4(d)] key destruction methods.
33
Application Note: If multiple selections are made, the TSS should identify which keys are
34
destroyed according to which selections.
35
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 27 of 75
FCS_KYC_EXT.2 Key Chaining (Recipient)
1
FCS_KYC_EXT.2.1 The TSF shall accept a BEV of at least [selection: 128 bits, 256 bits]
2
from [the AA].
3
FCS_KYC_EXT.2.2 The TSF shall maintain a chain of intermediary keys originating from
4
the BEV to the DEK using the following method(s): [selection:
5
 asymmetric key generation as specified in FCS_CKM.1(a),
6
 symmetric key generation as specified in FCS_CKM.1(b),
7
 key derivation as specified in FCS_KDF_EXT.1,
8
 key wrapping as specified in FCS_COP.1(d),
9
 key combining as specified in FCS_SMC_EXT.1,
10
 key transport as specified in FCS_COP.1(e),
11
 key encryption as specified in FCS_COP.1(g)]
12
while maintaining an effective strength of [selection: 128 bits, 256 bits] for symmetric keys
13
and an effective strength of [selection: not applicable, 112 bits, 128 bits, 192 bits, 256 bits]
14
for asymmetric keys.
15
Application Note: Key Chaining is the method of using multiple layers of encryption keys to
16
ultimately secure the protected data encrypted on the drive. The number of intermediate keys
17
will vary – from two (e.g., using the BEV as an intermediary key to wrap the DEK) to many.
18
This applies to all keys that contribute to the ultimate wrapping or derivation of the DEK;
19
including those in areas of protected storage (e.g. TPM stored keys, comparison values).
20
The BEV is considered to be equivalent to keying material and therefore additional checksums
21
or similar values are not the BEV, even if they are sent with the BEV.
22
Once the ST author has selected a method to create the chain (either by deriving keys or
23
unwrapping them), they pull the appropriate requirement out of Appendix B. It is allowable for
24
an implementation to use both methods.
25
The method the TOE uses to chain keys and manage/protect them is described in the Key
26
Management Description; see Appendix E for more information.
27
FCS_SNI_EXT.1 Cryptographic Operation (Salt, Nonce, and Initialization Vector
28
Generation)
29
FCS_SNI_EXT.1.1 The TSF shall use [selection: use no salts, use salts that are generated by
30
a [selection: DRBG as specified in FCS_RBG_EXT.1, DRBG provided by the host
31
platform].
32
FCS_SNI_EXT.1.2 The TSF shall use [selection: no nonces, unique nonces with a minimum
33
size of [64] bits].
34
FCS_SNI_EXT.1.3 The TSF shall create IVs in the following manner [selection:
35
 CBC: IVs shall be non-repeating and unpredictable;
36
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 28 of 75
 CCM: Nonce shall be non-repeating and unpredictable;
1
 XTS: No IV. Tweak values shall be non-negative integers, assigned consecutively,
2
and starting at an arbitrary non-negative integer;
3
 GCM: IV shall be non-repeating. The number of invocations of GCM shall not exceed
4
2^32 for a given secret key].
5
Application Note: This SFR does not prescribe when salts, nonces, and IVs must be used, only
6
that when they are used they must be generated in a certain manner. The ST author is expected
7
to document each claimed SFR that requires the use of salts, nonces, and/or IVs (such as
8
symmetric key generation as defined by FCS_CKM.1(b) and AES encryption/decryption as
9
defined by FCS_COP.1(f)). If the TSF does not use salts, nonces, or IVs for any function, then
10
this SFR is considered to be vacuously satisfied.
11
This requirement covers several important factors – the salt must be random, but the nonces
12
only have to be unique. FCS_SNI_EXT.1.3 specifies how the IV should be handled for each
13
encryption mode. Assigned consecutively could mean using a one-up counter. Additionally,
14
nonce is referred to as Starting Variable (SV) in ISO/IEC 19772.
15
Tweak values should be non-negative numbers, starting at an arbitrary non-negative number,
16
and all subsequent tweak values should be incremented from the initial value.
17
FCS_VAL_EXT.1 Validation
18
FCS_VAL_EXT.1.1 The TSF shall perform validation of the [BEV] using the following
19
method(s): [selection:
20
 key wrap as specified in FCS_COP.1(d);
21
 hash the [BEV] as specified in [selection: FCS_COP.1(b), FCS_COP.1(c)] and
22
compare it to a stored hashed [value];
23
 decrypt a known value using the [selection: intermediate key, BEV] as specified in
24
FCS_COP.1(f) and compare it against a stored known value]
25
FCS_VAL_EXT.1.2 The TSF shall require the validation of the [BEV] prior to [allowing
26
access to TSF data after exiting a Compliant power saving state].
27
FCS_VAL_EXT.1.3 The TSF shall [selection:
28
 perform a key sanitization of the DEK upon a [selection: configurable number,
29
[assignment: ST author specified number]] of consecutive failed validation attempts,
30
 institute a delay such that only [assignment: ST author specified number of attempts]
31
can be made within a 24 hour period,
32
 block validation after [assignment: ST author specified number of attempts] of
33
consecutive failed validation attempts,
34
 require power cycle/reset the TOE after [assignment: ST author specified number of
35
attempts] of consecutive failed validation attempts].
36
Application Note: “Validation” of the BEV can occur at any point in the key chain, including
37
when the DEK is decrypted. For the purposes of this requirement, validating a key derived
38
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 29 of 75
from the BEV equates to “validating” the BEV. The purpose of performing secure validation
1
is to not expose any material that might compromise the submask(s).
2
The TOE validates the BEV prior to allowing the user access to the data stored on the drive.
3
When the key wrap in FCS_COP.1(d) is used, the validation is performed inherently.
4
The delay must be enforced by the TOE, but this requirement is not intended to address attacks
5
that bypass the product (e.g. attacker obtains hash value or “known” crypto value and mounts
6
attacks outside of the TOE, such as a third party password cracker). The cryptographic
7
functions (i.e., hash, decryption) performed are those specified in FCS_COP.1(b) and
8
FCS_COP.1(f).
9
5.4 Class: User Data Protection (FDP)
10
This family is used to mandate the encryption of all protected data written to a drive.
11
FDP_DSK_EXT.1 Protection of Data on Disk
12
FDP_DSK_EXT.1.1 The TSF shall perform Full Drive Encryption in accordance with
13
FCS_COP.1(f), such that the drive contains no plaintext protected data.
14
FDP_DSK_EXT.1.2 The TSF shall encrypt all protected data without user intervention.
15
Application Note: The intent of this requirement is to specify that encryption of any protected
16
data will not depend on a user electing to protect that data. The drive encryption specified in
17
FDP_DSK_EXT.1 occurs transparently to the user and the decision to protect the data is
18
outside the discretion of the user, which is a characteristic that distinguishes it from file
19
encryption. The definition of protected data can be found in the glossary.
20
The cryptographic functions that perform the encryption/decryption of the data may be
21
provided by the Operational Environment. Note that if this is the case, it is assumed that the
22
environmental implementation of AES is consistent with the behavior described in
23
FCS_COP.1(f). If the TOE provides the cryptographic functions to encrypt/decrypt the data,
24
the ST author includes FCS_COP.1(f) as defined in Appendix A in the main body of the ST.
25
5.5 Class: Security Management (FMT)
26
FMT_SMF.1 Specification of Management Functions
27
FMT_SMF.1.1 Refinement: The TSF shall be capable of performing the following
28
management functions: [
29
a) change the DEK, as specified in FCS_CKM.1, when re-provisioning or when
30
commanded,
31
b) erase the DEK, as specified in FCS_CKM.4(a),
32
c) initiate TOE firmware/software updates,
33
d) [selection: no other functions, configure a password for firmware update, import a
34
wrapped DEK, configure cryptographic functionality, disable key recovery
35
functionality, securely update the public key needed for trusted update, configure
36
the number of failed validation attempts required to trigger corrective behavior,
37
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 30 of 75
configure the corrective behavior to issue in the event of an excessive number of
1
failed validation attempts, [assignment: other management functions provided by
2
the TSF]].
3
Application Note: The intent of this requirement is to express the management capabilities that
4
the TOE possesses. This means that the TOE must be able to perform the listed functions. Item
5
(d) is used to specify functionality that may be included in the TOE, but is not required to
6
conform to the cPP. “Configure cryptographic functionality” could include key management
7
functions, for example, the BEV will be wrapped or encrypted, and the EE will need to unwrap
8
or decrypt the BEV. In item (d), if no other management functions are provided (or claimed),
9
then “no other functions” should be selected. Default Authorization factors are the initial
10
values that are used to manipulate the drive.
11
For the purposes of this document, key sanitization means to destroy the DEK, using one of the
12
approved destruction methods. This applies to instances of the protected key that exist in non-
13
volatile storage.
14
5.6 Class: Protection of the TSF (FPT)
15
FPT_KYP_EXT.1 Protection of Key and Key Material
16
FPT_KYP_EXT.1.1 The TSF shall [selection:
17
 not store keys in non-volatile memory
18
 only store keys in non-volatile memory when wrapped, as specified in
19
FCS_COP.1(d), or encrypted, as specified in FCS_COP.1(g) or FCS_COP.1(e)
20
 only store plaintext keys that meet any one of the following criteria [selection:
21
o the plaintext key is not part of the key chain as specified in
22
FCS_KYC_EXT.2,
23
o the plaintext key will no longer provide access to the encrypted data after
24
initial provisioning,
25
o the plaintext key is a key split that is combined as specified in
26
FCS_SMC_EXT.1, and the other half of the key split is [selection:
27
 wrapped as specified in FCS_COP.1(d),
28
 encrypted as specified in FCS_COP.1(g) or FCS_COP.1(e),
29
 derived and not stored in non-volatile memory],
30
o the non-volatile memory the key is stored on is located in an external storage
31
device for use as an authorization factor,
32
o the plaintext key is [selection:
33
 used to wrap a key as specified in FCS_COP.1(d),
34
 used to encrypt a key as specified in FCS_COP.1(g) or FCS_COP.1(e)]
35
that is already [selection:
36
 wrapped as specified in FCS_COP.1(d),
37
 encrypted as specified in FCS_COP.1(g) or FCS_COP.1(e)]]].
38
Application Note: The plaintext key storage in non-volatile memory is allowed for several
39
reasons. If the keys exist within protected memory that is not user accessible on the TOE or
40
OE, the only methods that allow it to play a security relevant role for protecting the BEV or
41
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 31 of 75
the DEK are if it is a key split or providing additional layers of wrapping or encryption on
1
keys that have already been protected.
2
When stored in non-volatile memory (even in protected storage), the DEK is always encrypted
3
(wrapped) and only exists in plaintext form in volatile memory, when it is being used to encrypt
4
or decrypt data. Provisioning keys may exist in plaintext form in non-volatile memory before
5
provisioning by the drive owner.
6
If the TOE does not store keys in non-volatile memory, a statement in the TSS stating that keys
7
are never stored in non-volatile memory is all that is required and no evaluation activity needs
8
to be performed.
9
This requirement is addressing the keys related to the encryption of user data – specifically
10
keys from within the key chain.
11
FPT_PWR_EXT.1 Power Saving States
12
FPT_PWR_EXT.1.1 The TSF shall define the following Compliant power saving states:
13
[selection: choose at least one of: S3, S4, G2(S5), G3, D0, D1, D2, D3 [assignment: other
14
power saving states]].
15
Application Note: Power saving states S3, S4, G2(S5), G3, D0, D1, D2, D3 are defined by the
16
Advanced Configuration and Power Interface (ACPI) standard.
17
FPT_PWR_EXT.2 Timing of Power Saving States
18
FPT_PWR_EXT.2.1 For each Compliant power saving state defined in FPT_PWR_EXT.1.1,
19
the TSF shall enter the Compliant power saving state when the following conditions occur:
20
user-initiated request, [selection: shutdown, user inactivity, request initiated by remote
21
management system, [assignment: other conditions], no other conditions].
22
Application Note: If volatile memory is not cleared as part of an unexpected power shutdown
23
sequence then guidance documentation must define mitigation activities (e.g. how long users
24
should wait after an unexpected power-down before volatile memory can be considered
25
cleared).
26
FPT_TST_EXT.1 TSF Testing
27
FPT_TST_EXT.1.1 The TSF shall run a suite of the following self-tests [selection: during
28
initial start-up (on power on), at the conditions [before the function is first invoked]] to
29
demonstrate the correct operation of the TSF: [assignment: list of self-tests run by the TSF].
30
Application Note: The tests regarding cryptographic functions implemented in the TOE can
31
be deferred, as long as the tests are performed before the function is invoked.
32
If FCS_RBG_EXT.1 is implemented by the TOE and according to NIST SP 800-90, the
33
evaluator shall verify that the TSS describes health tests that are consistent with section 11.3
34
of NIST SP 800-90.
35
36
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 32 of 75
If any FCS_COP functions are implemented by the TOE, the TSS should describe the known-
1
answer self-tests for those functions.
2
3
The evaluator is expected to verify that the TSS describes, for some set of non-cryptographic
4
functions affecting the correct operation of the TSF, the method by which those functions are
5
tested. The TSS will describe, for each of these functions, the method by which correct
6
operation of the function/component is verified. The evaluator should determine that all of
7
the identified functions/components are adequately tested on start-up.
8
FPT_TUD_EXT.1 Trusted Update
9
FPT_TUD_EXT.1.1 Refinement: The TSF shall provide [authorized users] the ability to
10
query the current version of the TOE [selection: software, firmware] software/firmware.
11
FPT_TUD_EXT.1.2 Refinement: The TSF shall provide [authorized users] the ability to
12
initiate updates to TOE [selection: software, firmware] software/firmware.
13
FPT_TUD_EXT.1.3 Refinement: The TSF shall verify updates to the TOE [selection:
14
software, firmware] using a [selection: digital signature as specified in FCS_COP.1(a),
15
authenticated firmware update mechanism as described in FPT_FUA_EXT.1] by the
16
manufacturer prior to installing those updates.
17
Application Note: “Authorized users” refers to an individual who has rightful physical
18
possession of the device.
19
The digital signature mechanism referenced in the third element is the one specified in
20
FCS_COP.1(a) in Appendix A. While this component requires the TOE to implement the update
21
functionality itself, it is acceptable to perform the cryptographic checks using functionality
22
available in the Operational Environment.
23
If the TOE is a software product, the ST author selects ‘digital signature’. If the TOE is a
24
hardware product, the ST author selects ‘authenticated firmware update mechanism as
25
described in FPT_FUA_EXT.1’.
26
The secure firmware update mechanism is used for verifying the authenticity and integrity of
27
the new update package and for ensuring that it is protected from modification outside of the
28
secure update process. The authenticated firmware update mechanism should be protected
29
from unintended or malicious modification by a mechanism that is at least as strong as that
30
protecting the RTU and the firmware.
31
The intent of this requirement is to ensure that an authenticated firmware update mechanism
32
will be provided. Authentication verifies that the firmware package was generated by an
33
authentic source and is unaltered. All updates to the existing firmware should go through an
34
authenticated update mechanism as described in FPT_FUA_EXT.1.
35
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 33 of 75
6. Security Assurance Requirements
1
This cPP identifies the Security Assurance Requirements (SARs) to frame the extent to which
2
the evaluator assesses the documentation applicable for the evaluation and performs
3
independent testing.
4
Note to ST authors: There is a selection in the ASE_TSS that must be completed. One
5
cannot simply reference the SARs in this cPP.
6
This section lists the set of SARs from CC part 3 that are required in evaluations against this
7
cPP. Individual Evaluation Activities to be performed are specified in Supporting Document
8
(Mandatory Technical Document) Full Drive Encryption: Encryption Engine, February 2019.
9
The general model for evaluation of TOEs against STs written to conform to this cPP is as
10
follows: after the ST has been approved for evaluation, the ITSEF will obtain the TOE,
11
supporting environmental IT (if required), and the administrative/user guides for the TOE. The
12
ITSEF is expected to perform actions mandated by the Common Evaluation Methodology
13
(CEM) for the ASE and ALC SARs. The ITSEF also performs the Evaluation Activities
14
contained within the SD, which are intended to be an interpretation of the other CEM assurance
15
requirements as they apply to the specific technology instantiated in the TOE. The Evaluation
16
Activities that are captured in the SD also provide clarification as to what the developer needs
17
to provide to demonstrate the TOE is compliant with the cPP.
18
Table 3: Security Assurance Requirements
19
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 for the Operational Environment (ASE_OBJ.1)
Stated Security Requirements (ASE_REQ.1)
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) Labeling of the TOE (ALC_CMC.1)
TOE CM Coverage (ALC_CMS.1)
Tests (ATE) Independent Testing – Sample (ATE_IND.1)
Vulnerability Assessment (AVA) Vulnerability Survey (AVA_VAN.1)
6.1 ASE: Security Target
20
The ST is evaluated as per ASE activities defined in the CEM. In addition, there may be
21
Evaluation Activities specified within the SD that call for necessary descriptions to be included
22
in the TSS that are specific to the TOE technology type.
23
The SFRs in this cPP allow for conformant implementations to incorporate a wide range of
24
acceptable key management approaches as long as basic principles are satisfied. Given the
25
criticality of the key management scheme, this cPP requires the developer to provide a detailed
26
description of their key management implementation. This information can be submitted as an
27
appendix to the ST and marked proprietary, as this level of detailed information is not expected
28
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 34 of 75
to be made publicly available. See Appendix E for details on the expectation of the developer’s
1
Key Management Description.
2
In addition, if the TOE includes a random bit generator, Appendix D provides a description of
3
the information expected to be provided regarding the quality of the entropy.
4
ASE_TSS.1.1C Refinement: The TOE summary specification shall describe how the TOE
5
meets each SFR, including a proprietary Key Management Description (Appendix E), and
6
[selection: Entropy Essay, list of all of 3rd party software libraries (including version
7
numbers), 3rd party hardware components (including model/version numbers), no other
8
cPP specified proprietary documentation].
9
6.2 ADV: Development
10
The design information about the TOE is contained in the guidance documentation available
11
to the end user as well as the TSS portion of the ST, and any additional information required
12
by this cPP that is not to be made public (e.g., Entropy Essay).
13
6.2.1 Basic Functional Specification (ADV_FSP.1)
14
The functional specification describes the TOE Security Functions Interfaces (TSFIs). It is not
15
necessary to have a formal or complete specification of these interfaces. Additionally, because
16
TOEs conforming to this cPP may have interfaces to the Operational Environment that are not
17
directly invoked by TOE users, there is little point specifying that such interfaces be described
18
in and of themselves since only indirect testing of such interfaces may be possible. For this
19
cPP, the Evaluation Activities for this family focus on understanding the interfaces presented
20
in the TSS in response to the functional requirements and the interfaces presented in the AGD
21
documentation. No additional “functional specification” documentation is necessary to satisfy
22
the Evaluation Activities specified in the SD.
23
The Evaluation Activities in the SD are associated with the applicable SFRs; since these are
24
directly associated with the SFRs, the tracing in element ADV_FSP.1.2D is implicitly already
25
done and no additional documentation is necessary.
26
6.3 AGD: Guidance Documentation
27
The guidance documents will be provided with the ST. Guidance must include a description of
28
how the IT personnel verify that the Operational Environment can fulfill its role for the security
29
functionality. The documentation should be in an informal style and readable by the IT
30
personnel.
31
Guidance must be provided for every operational environment that the product supports as
32
claimed in the ST. For hardware products, the developer may not be aware of all the platforms
33
an integrator choses to use to deliver the product. A description of the commands the integrator
34
would need to issue to properly configure the TOE (i.e., satisfies the SFRs in the ST) would
35
satisfy the intent of “every operational environment the product supports”. This guidance
36
includes:
37
 instructions to successfully install the TSF in that environment; and
38
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 35 of 75
 instructions to manage the security of the TSF as a product and as a component of
1
the larger operational environment; and
2
 instructions to provide a protected administrative capability.
3
Guidance pertaining to particular security functionality must also be provided; requirements
4
on such guidance are contained in the Evaluation Activities specified in the SD.
5
6.3.1 Operational User Guidance (AGD_OPE.1)
6
The operational user guidance does not have to be contained in a single document. Guidance
7
to users, administrators, and integrators can be spread among documents or web pages.
8
The developer should review the Evaluation Activities contained in the SD to ascertain the
9
specifics of the guidance that the evaluator will be checking for. This will provide the necessary
10
information for the preparation of acceptable guidance.
11
6.3.2 Preparative Procedures (AGD_PRE.1)
12
As with the operational guidance, the developer should look to the Evaluation Activities to
13
determine the required content with respect to preparative procedures.
14
6.4 Class ALC: Life-cycle Support
15
At the assurance level provided for TOEs conformant to this cPP, life-cycle support is limited
16
to end-user-visible aspects of the life-cycle, rather than an examination of the TOE vendor’s
17
development and configuration management process. This is not meant to diminish the critical
18
role that a developer’s practices play in contributing to the overall trustworthiness of a product;
19
rather, it is a reflection on the information to be made available for evaluation at this assurance
20
level.
21
6.4.1 Labelling of the TOE (ALC_CMC.1)
22
This component is targeted at identifying the TOE such that it can be distinguished from other
23
products or versions from the same vendor and can be easily specified when being procured by
24
an end user. A label could consist of a “hard label” (e.g., stamped into the metal, paper label)
25
or a “soft label” (e.g., electronically presented when queried). The evaluator performs the CEM
26
work units associated with ALC_CMC.1.
27
6.4.2 TOE CM Coverage (ALC_CMS.1)
28
Given the scope of the TOE and its associated evaluation evidence requirements, the evaluator
29
performs the CEM work units associated with ALC_CMS.1.
30
6.5 Class ATE: Tests
31
Testing is specified for functional aspects of the system as well as aspects that take advantage
32
of design or implementation weaknesses. The former is done through the ATE_IND family,
33
while the latter is through the AVA_VAN family. For this cPP, testing is based on advertised
34
functionality and interfaces with dependency on the availability of design information. One of
35
the primary outputs of the evaluation process is the test report as specified in the following
36
requirements.
37
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 36 of 75
1
6.5.1 Independent Testing – Conformance (ATE_IND.1)
2
Testing is performed to confirm the functionality described in the TSS as well as the operational
3
guidance (includes “evaluated configuration” instructions). The focus of the testing is to
4
confirm that the requirements specified in Section 5 are being met. The Evaluation Activities
5
in the SD identify the specific testing activities necessary to verify compliance with the SFRs.
6
The evaluator produces a test report documenting the plan for and results of testing, as well as
7
coverage arguments focused on the platform/TOE combinations that are claiming conformance
8
to this cPP.
9
6.6 Class AVA: Vulnerability Assessment
10
For the current generation of this cPP, the iTC is expected to survey open sources to discover
11
what vulnerabilities have been discovered in these types of products and provide that content
12
into the AVA_VAN discussion. In most cases, these vulnerabilities will require sophistication
13
beyond that of a basic attacker. This information will be used in the development of future
14
protection profiles.
15
6.6.1 Vulnerability Survey (AVA_VAN.1)
16
Appendix A in the companion Supporting Document provides a guide to the evaluator in
17
performing a vulnerability analysis.
18
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 37 of 75
Appendix A: Optional Requirements
1
As indicated in the introduction to this cPP, the baseline requirements (those that must be
2
performed by the TOE) are contained in the body of this cPP. Additionally, there are two other
3
sets of requirements specified in Appendices A and B.
4
The first set (in this Appendix) are requirements that can be included in the ST, but do not have
5
to be in order for a TOE to claim conformance to this cPP. The second set (in Appendix B) are
6
requirements based on selections in the body of the cPP: if certain selections are made, then
7
additional requirements in that appendix would need to be included in the body of the ST (e.g.,
8
cryptographic protocols selected in a trusted channel requirement).
9
A.1 Internal Cryptographic Implementation
10
As indicated in the body of this cPP, it is acceptable for the TOE to either directly implement
11
cryptographic functionality that supports the drive encryption/decryption process, or to use that
12
functionality in the Operational Environment (for example, calling an Operating System's
13
cryptographic provider interface; a third-party cryptographic library; or a hardware
14
cryptographic accelerator). However, each one of these SFRs that can optionally be
15
implemented by the Operational Environment are also considered to be ‘selection-based’ SFRs
16
due to the fact that their functionality is contingent on the ST author make certain selections in
17
other SFRs. Because of this, these SFRs have been placed in Appendix B. Note however that
18
there is still an expectation that some of these functions may be provided by the Operational
19
Environment, in which case it is acceptable to omit the SFRs in question so long as the ST
20
author can provide evidence that the Operational Environment will include a cryptographic
21
interface to the TSF that allows for secure usage of these functions, and that the functions have
22
been validated to the same level of rigor as is described in [SD].
23
If all of the cryptographic functionality is implemented by the TSF and the TOE does not rely
24
on its Operational Environment to provide any cryptographic services, the ST author shall omit
25
OE.STRONG_ENVIRONMENT_CRYPTO and its corresponding assumption since the
26
environment does not need to satisfy the objective in this case.
27
A.2 Firmware Update Validation
28
The TOE can either be a software or a hardware product. The ST author will select this through
29
completion of FPT_TUD_EXT.1. If the TOE is a hardware product (i.e. a SED), this cPP
30
defines several selection-based requirements that are intended to provide guarantees of the
31
authenticity and integrity of firmware updates. However, some additional security measures
32
may be provided by a conformant TOE in addition to these mechanisms. If the TSF provides
33
these security measures, the ST author may optionally include one or more of the SFRs
34
described below.
35
FPT_FAC_EXT.1 Firmware Access Control
36
37
FPT_FAC_EXT.1.1 The TSF shall require [selection: a password, a known unique value
38
printed on the device, a privileged user action] before the firmware update proceeds.
39
Application Note: Before an update takes place, the drive owner will authorize the update by
40
providing either a known unique value (for example, a serial number) that is printed on the
41
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 38 of 75
drive, a password (which should be administratively configurable as defined in FMT_SMF.1)
1
or perform the operation as a privileged user. It is assumed that physical presence to the drive
2
is limited to authorized personnel. If the correct value is not provided, the update will not take
3
place. The values are intended to be unique per drive so they cannot be easily exhausted.
4
The same requirements for cleaning up a password still apply.
5
FPT_RBP_EXT.1 Rollback Protection
6
7
FPT_RBP_EXT.1.1 The TSF shall verify that the new firmware package is not downgrading
8
to a lower security version number by [assignment: method of verifying the security version
9
number is the same as or higher than the currently installed version].
10
FPT_RBP_EXT.1.2 The TSF shall generate and return an error code if the attempted firmware
11
update package is detected to be an invalid version.
12
Application Note: This requirement prevents an unauthorized rollback of the firmware to an
13
earlier authentic version. This mitigates against unknowing installation of an earlier authentic
14
firmware version that may have a security weakness. It is expected that vendors will increase
15
security version numbers with each new update package.
16
For FPT_RBP_EXT.1.1 the purpose is to verify that the new package has a security version
17
number equal to or larger than the security version number of currently installed firmware
18
package.
19
The administrator guidance would include instructions for the administrator to configure the
20
rollback prevention mechanism, if appropriate.
21
A.3 Cryptographic Key Destruction
22
The TOE can optionally choose to destroy keys by destroying the parent key through the key
23
destruction requirements. This method of destruction mirrors the data destruction method
24
commonly referred to as Secure Erase. Although the ST author still has to do the traditional
25
key destruction requirements, this is an additional option that expands the methods of key
26
destruction.
27
FCS_CKM.4(e) Cryptographic Key Destruction (Key Cryptographic Erase)
28
29
FCS_CKM.4.1(e) The TSF shall destroy cryptographic keys in accordance with a specified
30
cryptographic key destruction method [by using the appropriate method to destroy all
31
encryption keys encrypting the key intended for destruction] that meets the following: [no
32
standard].
33
34
Application Note: A key can be considered destroyed by destroying the key that protects the
35
key. If a key is wrapped or encrypted it is not necessary to “overwrite” that key, overwriting
36
the key that is used to wrap or encrypt the key used to encrypt/decrypt data, using the
37
appropriate method for the memory type involved, will suffice. For example, if a product uses
38
a Key Encryption Key (KEK) to encrypt a Data Encryption Key (DEK), destroying the KEK
39
using one of the methods in FCS_CKM.EXT.6.1 is sufficient, since the DEK would no longer
40
be usable (of course, presumes the DEK is still encrypted.
41
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 39 of 75
Appendix B: Selection-Based Requirements
1
As indicated in the introduction to this cPP, the baseline requirements (those that must be
2
performed by the TOE or its underlying platform) are contained in the body of this cPP. There
3
are additional requirements based on selections in the body of the cPP: if certain selections are
4
made, then additional requirements below may need to be included.
5
Note that many of these selection-based SFRs could also be implemented by cryptographic
6
services in the TOE’s Operational Environment. If this is the case, it is not necessary to include
7
the SFRs in question so long as the Operational Environment can be shown to provide
8
equivalent functionality.
9
B.1 Class: Cryptographic Support (FCS)
10
FCS_CKM.1(a) Cryptographic Key Generation (Asymmetric Keys)
11
FCS_CKM.1.1(a) Refinement: The TSF shall generate asymmetric cryptographic keys in
12
accordance with a specified cryptographic key generation algorithm: [selection:
13
● RSA schemes using cryptographic key sizes of [selection: 2048-bit, 3072-bit, 4096-
14
bit] that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”,
15
Appendix B.3;
16
● ECC schemes using “NIST curves” of [selection: P-256, P-384, P-521] that meet
17
the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix
18
B.4;
19
● FFC schemes using cryptographic key sizes of [selection: 2048-bit, 3072-bit, 4096-
20
bit] that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”,
21
Appendix B.1
22
] and specified cryptographic key sizes [assignment: cryptographic key sizes] that meet the
23
following: [assignment: list of standards].
24
Application Note: Asymmetric keys may be used to “wrap” a key or submask. This SFR should
25
be included by the ST author when making the appropriate selection in FCS_COP.
26
Asymmetric Keys may also be used for the key chain. Therefore, the ST author should select
27
FCS_CKM.1(a), if Asymmetric key generation is used.
28
If the TOE acts as a receiver in the RSA key establishment scheme, the TOE does not need to
29
implement RSA key generation.
30
For all schemes (RSA schemes, ECC schemes, FFC schemes), a RBG is needed to a) generate
31
seeds for RSA and to b) generate private keys directly for ECC and FFC. So FCS_RBG_EXT.1
32
is used together with this SFR. A hash algorithm is also required when the key pair generation
33
algorithm is selected based on either Appendix B.3.2 or B.3.5 of FIPS 186-4. So in such case,
34
FCS_COP.1(d) is used together with this SFR.
35
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 40 of 75
FCS_CKM.1(b) Cryptographic Key Generation (Symmetric Keys)
1
FCS_CKM.1.1(b) Refinement: The TSF shall generate symmetric cryptographic keys using
2
a Random Bit Generator as specified in FCS_RBG_EXT.1 and specified cryptographic key
3
sizes [selection: 128 bit, 256 bit] that meet the following: [no standard].
4
Application Note: The symmetric key generation function may be used to generate keys along
5
the key chain or a DEK. It may also be used to provide inputs for key combining, key encryption,
6
or key wrapping. Therefore, the ST author should select FCS_CKM.1(b), if Symmetric key
7
generation is used.
8
FCS_CKM.4(b) Cryptographic Key Destruction (TOE-Controlled Hardware)
9
FCS_CKM.4.1(b) Refinement: The TSF shall destroy cryptographic keys in accordance
10
with a specified cryptographic key destruction method [selection:
11
 For volatile memory, the destruction shall be executed by a [selection:
12
o single overwrite consisting of [selection:
13
 a pseudo-random pattern using the TSF’s RBG,
14
 zeroes,
15
 ones,
16
 a new value of a key,
17
 [assignment: some value that does not contain any CSP]],
18
o removal of power to the memory,
19
o destruction of reference to the key directly followed by a request for garbage
20
collection];
21
 For non-volatile memory [selection:
22
o that employs a wear-leveling algorithm, the destruction shall be executed by
23
a [selection:
24
 single overwrite consisting of zeroes,
25
 single overwrite consisting of ones,
26
 overwrite with a new value of a key of the same size,
27
 single overwrite consisting of [assignment: some value that does not
28
contain any CSP],
29
 block erase];
30
o that does not employ a wear-leveling algorithm, the destruction shall be
31
executed by a [selection:
32
 [selection: single, [assignment: ST author defined multi-pass]]
33
overwrite consisting of zeros followed by a read-verify,
34
 [selection: single, [assignment: ST author defined multi-pass]]
35
overwrite consisting of ones followed by a read-verify, overwrite with
36
a new value of a key of the same size followed by a read-verify,
37
 [selection: single, [assignment: ST author defined multi-pass]]
38
overwrite consisting of [assignment: some value that does not contain
39
any CSP] followed by a read-verify,
40
 block erase]
41
and if the read-verification of the overwritten data fails, the process shall
42
be repeated again up to [assignment: number of times to attempt
43
overwrite] times, whereupon an error is returned.
44
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 41 of 75
]
1
] that meets the following: [no standard].
2
3
Application Note: In the first selection, the ST Author is presented options for destroying a
4
key based on the memory or storage technology where keys are stored within the TOE.
5
6
If non-volatile memory is used to store keys, the ST Author selects whether the memory
7
storage algorithm uses wear-leveling or not. Storage technologies or memory types that use
8
wear-leveling are not required to perform a read verify. The selection for destruction
9
includes block erase as an option, and this option applies only to flash memory. A block erase
10
does not require a read verify, since the mappings of logical addresses to the erased memory
11
locations are erased as well as the data itself.
12
13
Within the selections is the option to overwrite a disused key with a new value of a key. The
14
intent is that a new value of a key (as specified in another SFR within the PP) can be used to
15
“replace” an existing key.
16
17
If a selection for read verify is chosen, it should generate an audit record upon failures.
18
19
Several selections allow assignment of a ‘value that does not contain any CSP’. This means
20
that the TOE uses some other specified data not drawn from an RBG meeting
21
FCS_RBG_EXT requirements, and not being any of the particular values listed as other
22
selection options. The point of the phrase ‘does not contain any CSP’ is to ensure that the
23
overwritten data is carefully selected, and not taken from a general ‘pool’ that might contain
24
current or residual data that itself requires confidentiality protection.
25
26
Key destruction does not apply to the public component of asymmetric key pairs.
27
FCS_CKM.4(c) Cryptographic Key Destruction (General Hardware)
28
FCS_CKM.4.1(c) Refinement: The TSF shall destroy cryptographic keys in accordance
29
with a specified cryptographic key destruction method [selection:
30
 For volatile memory, the destruction shall be executed by a [selection:
31
o single overwrite consisting of [selection:
32
 a pseudo-random pattern using the TSF’s RBG,
33
 zeroes,
34
 ones,
35
 a new value of a key,
36
 [assignment: some value that does not contain any CSP]],
37
o removal of power to the memory,
38
o destruction of reference to the key directly followed by a request for garbage
39
collection];
40
 For non-volatile memory the destruction shall be executed by a [selection: single,
41
[assignment: ST author defined multi-pass]] overwrite consisting of [selection:
42
o a pseudo-random pattern using the TSF’s RBG,
43
o zeroes,
44
o ones,
45
o a new value of a key of the same size,
46
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 42 of 75
o [assignment: some value that does not contain any CSP], block erase]
1
]
2
] that meets the following: [no standard].
3
Application Note: In the first selection, the ST Author is presented options for destroying
4
disused cryptographic keys based on whether they are in volatile memory or non-volatile
5
storage within the TOE. The selection of block erase for non-volatile storage applies only to
6
flash memory. A block erase does not require a read-verify, since the reference to the memory
7
location is erased as well as the data itself.
8
Within the selections is the option to overwrite the memory location with a new value of a key.
9
The intent is that a new value of a key (as specified in another SFR within the PP) can be used
10
to “replace” an existing key.
11
Several selections allow assignment of a ‘value that does not contain any CSP’. This means
12
that the TOE uses some other specified data not drawn from an RBG meeting FCS_RBG_EXT
13
requirements, and not being any of the particular values listed as other selection options. The
14
point of the phrase ‘does not contain any CSP’ is to ensure that the overwritten data is carefully
15
selected, and not taken from a general ‘pool’ that might contain current or residual data that
16
itself requires confidentiality protection.
17
Key destruction does not apply to the public component of asymmetric key pairs.
18
FCS_CKM.4(d) Cryptographic Key Destruction (Software TOE, 3rd Party Storage)
19
FCS_CKM.4.1(d) Refinement: The TSF shall destroy cryptographic keys in accordance
20
with a specified cryptographic key destruction method [selection:
21
 For volatile memory, the destruction shall be executed by a [selection:
22
o single overwrite consisting of [selection:
23
 a pseudo-random pattern using the TSF’s RBG,
24
 zeroes,
25
 ones,
26
 a new value of a key,
27
 [assignment: some value that does not contain any CSP]],
28
o removal of power to the memory,
29
o destruction of reference to the key directly followed by a request for garbage
30
collection];
31
 For non-volatile storage that consists of the invocation of an interface provided by
32
the underlying platform that [selection:
33
o logically addresses the storage location of the key and performs a [selection:
34
single, [assignment: ST author defined multi-pass]] overwrite consisting of
35
[selection:
36
 a pseudo-random pattern using the TSF’s RBG,
37
 zeroes,
38
 ones,
39
 a new value of a key,
40
 [assignment: some value that does not contain any CSP];
41
o instructs the underlying platform to destroy the abstraction that represents the
42
key]
43
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 43 of 75
]
1
that meets the following: [no standard].
2
Application Note: The interface referenced in the requirement could take different forms, the
3
most likely of which is an application programming interface to an OS kernel. There may be
4
various levels of abstraction visible. For instance, in a given implementation the application
5
may have access to the file system details and may be able to logically address specific memory
6
locations. In another implementation the application may simply have a handle to a resource
7
and can only ask the platform to delete the resource. The level of detail to which the TOE has
8
access will be reflected in the TSS section of the ST.
9
Several selections allow assignment of a ‘value that does not contain any CSP’. This means
10
that the TOE uses some other specified data not drawn from an RBG meeting FCS_RBG_EXT
11
requirements, and not being any of the particular values listed as other selection options. The
12
point of the phrase ‘does not contain any CSP’ is to ensure that the overwritten data is carefully
13
selected, and not taken from a general ‘pool’ that might contain current or residual data that
14
itself requires confidentiality protection.
15
Key destruction does not apply to the public component of asymmetric key pairs.
16
FCS_COP.1(a) Cryptographic Operation (Signature Verification)
17
FCS_COP.1.1(a) Refinement: The TSF shall perform [cryptographic signature services
18
(verification)] in accordance with a [selection:
19
● RSA Digital Signature Algorithm with a key size (modulus) of [selection: 2048-bit,
20
3072-bit, 4096-bit];
21
● Elliptic Curve Digital Signature Algorithm with a key size of 256 bits or greater
22
]
23
that meet the following: [selection:
24
● FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5.5, using PKCS #1
25
v2.1 Signature Schemes RSASSA-PSS and/or RSASSA-PKCS1-v1_5; ISO/IEC
26
9796-2, Digital signature scheme 2 or Digital Signature scheme 3, for RSA schemes
27
● FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 6 and Appendix D,
28
Implementing “NIST curves” [selection: P-256, P-384, P-521]; ISO/IEC 14888-3,
29
Section 6.4, for ECDSA schemes
30
].
31
Application Note: The selection should be consistent with the overall strength of the algorithm
32
used for FCS_COP.1(a) and quantum resistant recommendations. For example, SHA-256
33
should be chosen for 2048-bit RSA or ECC with P-256, SHA-384 should be chosen for 3072-
34
bit RSA, 4096-bit RSA, or ECC with P-384, and SHA-512 should be chosen for ECC with P-
35
521. The selection of the standard is made based on the algorithms selected.
36
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 44 of 75
FCS_COP.1(b) Cryptographic Operation (Hash Algorithm)
1
FCS_COP.1.1(b) Refinement: The TSF shall perform [cryptographic hashing services] in
2
accordance with a specified cryptographic algorithm [selection: SHA-256, SHA-384, SHA-
3
512] and cryptographic key sizes [assignment: cryptographic key sizes] that meet the
4
following: [ISO/IEC 10118-3:2004].
5
Application Note: The selection should be consistent with the overall strength of the algorithm
6
used for FCS_COP.1(a) and quantum resistant recommendations. For example, SHA-256
7
should be chosen for 2048-bit RSA or ECC with P-256, SHA-384 should be chosen for 3072-
8
bit RSA, 4096-bit RSA, or ECC with P-384, and SHA-512 should be chosen for ECC with P-
9
521. The selection of the standard is made based on the algorithms selected.
10
FCS_COP.1(c) Cryptographic Operation (Message Authentication)
11
FCS_COP.1.1(c) Refinement: The TSF shall perform cryptographic [message
12
authentication] in accordance with a specified cryptographic algorithm [selection: HMAC-
13
SHA-256, HMAC-SHA-384, HMAC-SHA-512, CMAC-AES-128, CMAC-AES-256] and
14
cryptographic key sizes [assignment: key size (in bits) used in [selection: HMAC, AES]]
15
that meet the following: [selection: ISO/IEC 9797-2:2011, Section 7 “MAC Algorithm 2”,
16
NIST SP 800-38B].
17
Application Note: If one or more HMAC algorithms are selected, the ST author selects
18
“HMAC” in the second selection and “ISO/IEC 9797-2:2011, Section 7 ‘MAC Algorithm 2’”
19
in the third selection. For the assignment, the key size [k] falls into a range between L1 and L2
20
(defined in ISO/IEC 10118 for the appropriate hash function). For example, for SHA-256, L1
21
= 512 and L2 = 256 where L2 ≤ k ≤ L1.
22
If one or more CMAC algorithms are selected, the ST author selects “AES” in the second
23
selection and “NIST SP 800-38B” in the third selection. For the assignment, the key size will
24
fall into a range between 128 and 256.
25
FCS_COP.1(d) Cryptographic Operation (Key Wrapping)
26
FCS_COP.1.1(d) Refinement: The TSF shall perform [key wrapping] in accordance with a
27
specified cryptographic algorithm [AES] in the following modes [selection: KW, KWP,
28
GCM, CCM] and the cryptographic key size [selection: 128 bits, 256 bits] that meet the
29
following: [AES as specified in ISO/IEC 18033-3, [selection: NIST SP 800-38F, ISO/IEC
30
19772, no other standards]].
31
Application Note: This requirement is used in the body of the ST if the ST author chooses to
32
use key wrapping in the key chaining approach that is specified in FCS_KYC_EXT.2.
33
FCS_COP.1(e) Cryptographic Operation (Key Transport)
34
FCS_COP.1.1(e) Refinement: The TSF shall perform [key transport] in accordance with a
35
specified cryptographic algorithm [RSA in the following modes [selection: KTS-OAEP, KTS-
36
KEM-KWS]] and the cryptographic key size [selection: 2048 bits, 3072 bits] that meet the
37
following: [NIST SP 800-56B, Revision 1].
38
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 45 of 75
Application Note: This requirement is used in the body of the ST if the ST author chooses to
1
use key transport in the key chaining approach that is specified in FCS_KYC_EXT.2.
2
FCS_COP.1(f) Cryptographic Operation (AES Data Encryption/Decryption)
3
FCS_COP.1.1(f) Refinement: The TSF shall perform [data encryption and decryption] in
4
accordance with a specified cryptographic algorithm [AES used in [selection: CBC, GCM,
5
XTS] mode] and cryptographic key sizes [selection: 128 bits, 256 bits] that meet the
6
following: [AES as specified in ISO /IEC 18033-3, [selection: CBC as specified in ISO/IEC
7
10116, GCM as specified in ISO/IEC 19772, XTS as specified in IEEE 1619]].
8
Application Note: This cPP allows for software encryption or hardware encryption. In
9
software encryption, the TOE can provide the data encryption/decryption or the host platform
10
could provide the encryption/decryption. Conversely, for hardware encryption, the
11
encryption/decryption could be provided by a variety of mechanisms - dedicated hardware
12
within a general purpose controller, the storage device’s SOC, or a dedicated (co-)processor.
13
If XTS Mode is selected, a cryptographic key of 256-bit or of 512-bit is allowed as specified in
14
IEEE 1619. XTS-AES key is divided into two AES keys of equal size - for example, AES-128 is
15
used as the underlying algorithm, when 256-bit key and XTS mode are selected. AES-256 is
16
used when a 512-bit key and XTS mode are selected.
17
The intent of this requirement is to specify the approved AES modes that the ST author may
18
select for AES encryption of the appropriate information on the hard disk. For the first
19
selection, the ST author should indicate the mode or modes supported by the TOE
20
implementation. The second selection indicates the key size to be used, which is identical to
21
that specified for FCS_CKM.1(1). The third selection must agree with the mode or modes
22
chosen in the first selection. If multiple modes are supported, it may be clearer in the ST if this
23
component was iterated.
24
FCS_COP.1(g) Cryptographic Operation (Key Encryption)
25
FCS_COP.1.1(g) Refinement: The TSF shall perform [key encryption and decryption] in
26
accordance with a specified cryptographic algorithm [AES used in [selection: CBC, GCM]
27
mode] and cryptographic key sizes [selection: 128 bits, 256 bits] that meet the following:
28
[AES as specified in ISO /IEC 18033-3, [selection: CBC as specified in ISO/IEC 10116,
29
GCM as specified in ISO/IEC 19772]].
30
Application Note: This requirement is used in the body of the ST if the ST author chooses to
31
use AES encryption/decryption for protecting the keys as part of the key chaining approach
32
that is specified in FCS_KYC_EXT.2.
33
FCS_KDF_EXT.1 Cryptographic Key Derivation
34
FCS_KDF_EXT.1.1 The TSF shall accept [selection: a RNG generated submask as specified
35
in FCS_RBG_EXT.1, a conditioned password submask, imported submask] to derive an
36
intermediate key, as defined in [selection:
37
 NIST SP 800-108 [selection: KDF in Counter Mode, KDF in Feedback Mode, KDF
38
in Double-Pipeline Iteration Mode],
39
 NIST SP 800-132],
40
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 46 of 75
using the keyed-hash functions specified in FCS_COP.1(c), such that the output is at least of
1
equivalent security strength (in number of bits) to the BEV.
2
Application Note: This requirement is used in the body of the ST if the ST author chooses to
3
use key derivation in the key chaining approach that is specified in FCS_KYC_EXT.2.
4
This requirement establishes acceptable methods for generating a new random key or an
5
existing submask to create a new key along the key chain.
6
FCS_RBG_EXT.1 Random Bit Generation
7
FCS_RBG_EXT.1.1 The TSF shall perform all deterministic random bit generation services
8
in accordance with [selection: ISO/IEC 18031:2011, [NIST SP 800-90A]] using [selection:
9
Hash_DRBG (any), HMAC_DRBG (any), CTR_DRBG (AES)].
10
FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded by at least one entropy source
11
that accumulates entropy from [selection:
12
 [assignment: number of software-based sources] software-based noise source(s),
13
 [assignment: number of hardware-based sources] hardware-based noise source(s)]
14
with a minimum of [selection: 128 bits, 256 bits] of entropy at least equal to the greatest
15
security strength, according to ISO/IEC 18031:2011 Table C.1 “Security Strength Table for
16
Hash Functions”, of the keys and hashes that it will generate.
17
Application Note: ISO/IEC 18031:2011 contains different methods of generating random
18
numbers; each of these, in turn, depends on underlying cryptographic primitives (hash
19
functions/ciphers). The ST author will select the function used and include the specific
20
underlying cryptographic primitives used in the requirement. While any of the identified hash
21
functions (SHA-256, SHA-384, SHA-512) are allowed for Hash_DRBG or HMAC_DRBG, only
22
AES-based implementations for CTR_DRBG are allowed. Table C.2 in ISO/IEC 18031:2011
23
provides an identification of Security strengths, Entropy and Seed length requirements for the
24
AES-128 and 256 Block Cipher.
25
The CTR_DRBG in ISO/IEC 18031:2011 requires using derivation function, whereas NIST SP
26
800-90A does not. Either model is acceptable. In the first selection in FCS_RBG_EXT.1.1, the
27
ST author choses the standard to which the TSF is compliant.
28
In the first selection in FCS_RBG_EXT.1.2 the ST author fills in how many entropy sources
29
are used for each type of entropy source they employ. It should be noted that a combination of
30
hardware and software based noise sources is acceptable.
31
It should be noted that the entropy source is considered to be a part of the DRBG and if the
32
DRBG is included in the TOE, the developer is required to provide the entropy description
33
outlined in Appendix D. The documentation *and tests* required in the Evaluation Activity for
34
this element necessarily cover each source indicated in FCS_RBG_EXT.1.2. Individual
35
contributions to the entropy pool may be combined to provide the minimum amount of entropy
36
as long as the Entropy Documentation demonstrates that entropy from each of these individual
37
sources is generated independently.
38
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 47 of 75
FCS_SMC_EXT.1 Submask Combining
1
FCS_SMC_EXT.1.1 The TSF shall combine submasks using the following method
2
[selection: exclusive OR (XOR), SHA-256, SHA-384, SHA-512] to generate an
3
[intermediary key or DEK].
4
Application Note: This requirement specifies the way that a product may combine the
5
various submasks by using either an XOR or an approved SHA-hash. The approved hash
6
functions are captured in FCS_COP.1(b).
7
B.2 Class: Protection of the TSF (FPT)
8
FPT_FUA_EXT.1 Firmware Update Authentication
9
FPT_FUA_EXT.1.1 The TSF shall authenticate the source of the firmware update using the
10
digital signature algorithm specified in FCS_COP.1(a) using the RTU that contains
11
[selection: the public key, hash value of the public key as specified in FCS_COP.1(b)].
12
FPT_FUA_EXT.1.2 The TSF shall only allow installation of update if the digital signature
13
has been successfully verified as specified in FCS_COP.1(a).
14
FPT_FUA_EXT.1.3 The TSF shall only allow modification of the existing firmware after
15
the successful validation of the digital signature, using a mechanism as described in
16
FPT_TUD_EXT.1.2.
17
Application Note: The firmware portion of the TOE (e.g., RTU (key store and the signature
18
verification algorithm)) is expected to be stored in a write protected area on the TOE. It is
19
expected that the firmware only be modifiable in a post-manufacturing state using the
20
authenticated update mechanism described in FPT_FUA_EXT.1. The TSF is modifiable only
21
by using the mechanisms specified in FPT_TUD_EXT.
22
FPT_FUA_EXT.1.4 The TSF shall return an error code if any part of the firmware update
23
process fails.
24
Application Note: These requirements are for a SED in an operational state – not a drive in
25
manufacturing.
26
The authenticated firmware update mechanism employs digital signatures to ensure the
27
authenticity of the firmware update image. The TSF provides a RTU that contains a signature
28
verification algorithm and a key store that includes the public key needed to verify the signature
29
on the update image. The key store in the RTU should include a public key used to verify the
30
signature on an update image or a hash of the public key if a copy of the public key is provided
31
with the update image. In the latter case, the update mechanism should hash the public key
32
provided with the update image, and ensure that it matches a hash which appears in the key
33
store before using the provided public key to verify the signature on the update image. If the
34
hash of the public key is selected, the ST author may iterate the FCS_COP.1(b) requirement -
35
to specify the hashing functions used.
36
The intent of this requirement is to specify that the authenticated update mechanism should
37
ensure that the new image has been digitally signed; and that the digital signature can be
38
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 48 of 75
verified by using a public key before the update takes place. The requirement also specifies
1
that the authenticated update mechanism only allows installation of updates when the digital
2
signature has been successfully verified by the TSF.
3
4
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 49 of 75
Appendix C: Extended Component Definitions
1
This appendix contains the definitions for the extended requirements that are used in the cPP,
2
including those used in Appendices A and B.
3
Note that several of the extended requirements used for this cPP have dependencies on SFRs
4
that are iterated in the cPP (e.g. FCS_COP.1(d)). The reader is advised that the SFR names for
5
these dependencies may differ if the same extended components are used in other Protection
6
Profiles.
7
C.1 Background and Scope
8
This document provides a definition for all of the extended components used in this cPP. These
9
components are identified in the following table:
10
Table 4: Extended Components
11
Functional Class Functional Components
Cryptographic Support (FCS)
FCS_CKM_EXT Cryptographic Key Management
FCS_KDF_EXT Cryptographic Key Derivation
FCS_KYC_EXT Key Chaining
FCS_RBG_EXT Cryptographic Operation (Random Bit Generation)
FCS_SMC_EXT Submask Combining
FCS_SNI_EXT Cryptographic Operation (Salt, Nonce, and Initialization
Vector Generation)
FCS_VAL_EXT Validation of Cryptographic Elements
User Data Protection (FDP) FDP_DSK_EXT Protection of Data on Disk
Protection of the TSF (FPT)
FPT_FAC_EXT Firmware Access Control
FPT_FUA_EXT Firmware Update Authentication
FPT_KYP_EXT Key and Key Material Protection
FPT_PWR_EXT Power Management
FPT_RBP_EXT Rollback Protection
FPT_TST_EXT TSF Testing
FPT_TUD_EXT Trusted Update
Note that several of the extended components define dependencies on iterated Part 2 SFRs that
12
are defined in this cPP. This definition mandates that these dependencies be included in a PP
13
that claims the SFR but it does not mandate that the dependent SFRs are defined using the same
14
iteration identifiers (e.g. inclusion of FCS_KDF_EXT.1 does not require the dependent SFR
15
for keyed-hash message authentication to be identified specifically as FCS_COP.1(c), only that
16
an FCS_COP.1 iteration exists and defines the same behavior as what this cPP defines as
17
FCS_COP.1(c)).
18
C.2 Extended Component Definitions
19
FCS_CKM_EXT Cryptographic Key Management
20
Family Behavior
21
Cryptographic keys must be managed throughout their life cycle. This family is intended to
22
support that lifecycle and consequently defines requirements for the following activities:
23
cryptographic key generation, cryptographic key distribution, cryptographic key access and
24
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 50 of 75
cryptographic key destruction. This family should be included whenever there are functional
1
requirements for the management of cryptographic keys.
2
The creation of this family is necessary because CC Part 2 provides the ability to specify the
3
method of key destruction but does not define SFRs for the timing of key destruction or the
4
ability to implement multiple key destruction methods.
5
Component Leveling
6
FCS_CKM_EXT Cryptographic Key
Management
4
6
7
FCS_CKM_EXT.4, Key and Key Material Destruction, requires the TSF to specify
8
circumstances when keys are destroyed (as opposed to the actual method of destruction, which
9
is defined in CC Part 2 as FCS_CKM.4). The number 4 was chosen to reflect the similarity
10
between the two SFRs.
11
FCS_CKM_EXT.6, Cryptographic Key Destruction Types, provides the TOE with the ability
12
to select between multiple methods of key destruction.
13
Management: FCS_CKM_EXT.4
14
No specific management functions are identified.
15
Audit: FCS_CKM_EXT.4
16
There are no auditable events foreseen.
17
Management: FCS_CKM_EXT.4
18
No specific management functions are identified.
19
Audit: FCS_CKM_EXT.4
20
There are no auditable events foreseen.
21
FCS_CKM_EXT.4 Cryptographic Key and Key Material Destruction
22
Hierarchical to: No other components
23
Dependencies: No dependencies
24
FCS_CKM_EXT.4.1 The TSF shall destroy all keys and key material when no longer
25
needed.
26
FCS_CKM_EXT.6 Cryptographic Key Destruction Types
27
Hierarchical to: No other components
28
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 51 of 75
Dependencies: FCS_CKM.4 Cryptographic Key Destruction
1
FCS_CKM_EXT.6.1 The TSF shall use [assignment: one or more iterations of FCS_CKM.4
2
defined elsewhere in the Security Target] key destruction methods.
3
FCS_KDF_EXT Cryptographic Key Derivation
4
Family Behavior
5
This family specifies the means by which an intermediate key is derived from a specified set
6
of submasks.
7
Component Leveling
8
FCS_KDF_EXT Cryptographic Key
Derivation
1
9
FCS_KDF_EXT.1, Cryptographic Key Derivation, requires the TSF to derive intermediate
10
keys from submasks using the specified hash functions.
11
Management: FCS_KDF_EXT.1
12
No specific management functions are identified.
13
Audit: FCS_KDF_EXT.1
14
There are no auditable events foreseen.
15
FCS_KDF_EXT.1 Cryptographic Key Derivation
16
Hierarchical to: No other components
17
Dependencies: FCS_COP.1(c) Cryptographic Operation (Keyed Hash Algorithm)
18
FCS_KDF_EXT.1.1 The TSF shall accept [selection: a RNG generated submask as specified
19
in FCS_RBG_EXT.1, a conditioned password submask, imported submask] to derive an
20
intermediate key, as defined in [selection:
21
 NIST SP 800-108 [selection: KDF in Counter Mode, KDF in Feedback Mode, KDF
22
in Double-Pipeline Iteration Mode],
23
 NIST SP 800-132],
24
using the keyed-hash functions specified in FCS_COP.1(c), such that the output is at least of
25
equivalent security strength (in number of bits) to the BEV.
26
FCS_KYC_EXT Key Chaining
27
Family Behavior
28
This family provides the specification to be used for using multiple layers of encryption keys
29
to ultimately secure the protected data encrypted on the drive.
30
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 52 of 75
Component Leveling
1
FCS_KYC_EXT Key Chaining
1
2
2
FCS_KYC_EXT.1, Key Chaining (Initiator), requires the TSF to maintain a key chain for a
3
BEV that is provided to a component external to the TOE.
4
FCS_KYC_EXT.2, Key Chaining (Recipient), requires the TSF to be able to accept a BEV
5
that is then chained to a DEK used by the TSF through some method.
6
Note that this cPP does not include FCS_KYC_EXT.1; it is only included here to provide a
7
complete definition of the FCS_KYC_EXT family.
8
Management: FCS_KYC_EXT.1
9
No specific management functions are identified.
10
Audit: FCS_KYC_EXT.1
11
There are no auditable events foreseen.
12
Management: FCS_KYC_EXT.2
13
No specific management functions are identified.
14
Audit: FCS_KYC_EXT.2
15
There are no auditable events foreseen.
16
FCS_KYC_EXT.1 Key Chaining (Initiator)
17
Hierarchical to: No other components
18
Dependencies: FCS_CKM.1(a) Cryptographic Key Generation (Asymmetric Keys),
19
FCS_CKM.1(b) Cryptographic Operation (Symmetric Keys),
20
FCS_COP.1(d) Cryptographic Operation (Key Wrapping),
21
FCS_COP.1(e) Cryptographic Operation (Key Transport),
22
FCS_COP.1(g) Cryptographic Operation (Key Encryption),
23
FCS_SMC_EXT.1 Submask Combining,
24
FCS_VAL_EXT.1 Validation
25
FCS_KYC_EXT.1.1 The TSF shall maintain a key chain of: [selection:
26
 one, using a submask as the BEV;
27
 intermediate keys generated by the TSF using the following method(s): [selection:
28
o asymmetric key generation as specified in FCS_CKM.1(a),
29
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 53 of 75
o symmetric key generation as specified in FCS_CKM.1(b)];
1
 intermediate keys originating from one or more submask(s) to the BEV using the
2
following method(s): [selection:
3
o key derivation as specified in FCS_KDF_EXT.1,
4
o key wrapping as specified in FCS_COP.1(d),
5
o key combining as specified in FCS_SMC_EXT.1,
6
o key transport as specified in FCS_COP.1(e),
7
o key encryption as specified in FCS_COP.1(g)]]
8
while maintaining an effective strength of [selection: 128 bits, 256 bits] for symmetric keys
9
and an effective strength of [selection: not applicable, 112 bits, 128 bits, 192 bits, 256 bits]
10
for asymmetric keys.
11
FCS_KYC_EXT.1.2 The TSF shall provide a [selection: 128 bit, 256 bit] BEV to
12
[assignment: one or more external entities] [selection:
13
 after the TSF has successfully performed the validation process as specified in
14
FCS_VAL_EXT.1,
15
 without validation taking place].
16
Application Note: Key Chaining is the method of using multiple layers of encryption keys to
17
ultimately secure the BEV. The number of intermediate keys will vary – from one (e.g., taking
18
the conditioned password authorization factor and directly using it as the BEV) to many. This
19
applies to all keys that contribute to the ultimate wrapping or derivation of the BEV; including
20
those in areas of protected storage (e.g. TPM stored keys, comparison values).
21
FCS_KYC_EXT.2 Key Chaining (Recipient)
22
Hierarchical to: No other components
23
Dependencies: No other components
24
FCS_KYC_EXT.2.1 The TSF shall accept a BEV of at least [selection: 128 bits, 256 bits]
25
from [assignment: one or more external entities].
26
FCS_KYC_EXT.2.2 The TSF shall maintain a chain of intermediary keys originating from
27
the BEV to the DEK using the following method(s): [selection:
28
 asymmetric key generation as specified in FCS_CKM.1(a),
29
 symmetric key generation as specified in FCS_CKM.1(b),
30
 key derivation as specified in FCS_KDF_EXT.1,
31
 key wrapping as specified in FCS_COP.1(d),
32
 key combining as specified in FCS_SMC_EXT.1,
33
 key transport as specified in FCS_COP.1(e),
34
 key encryption as specified in FCS_COP.1(g)]
35
while maintaining an effective strength of [selection: 128 bits, 256 bits] for symmetric keys
36
and an effective strength of [selection: not applicable, 112 bits, 128 bits, 192 bits, 256 bits]
37
for asymmetric keys.
38
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 54 of 75
Application Note: Key Chaining is the method of using multiple layers of encryption keys to
1
ultimately secure the protected data encrypted on the drive. The number of intermediate keys
2
will vary – from one (e.g., using the BEV as a key encrypting key (KEK)) to many. This applies
3
to all keys that contribute to the ultimate wrapping or derivation of the DEK; including those
4
in areas of protected storage (e.g. TPM stored keys, comparison values).
5
FCS_RBG_EXT Random Bit Generation
6
Family Behavior
7
Components in this family address the requirements for random bit/number generation. This is
8
a new family defined for the FCS class.
9
Component Leveling
10
FCS_RBG_EXT Random Bit Generation 1
11
FCS_RBG_EXT.1, Random Bit Generation, requires random bit generation to be performed
12
in accordance with selected standards and seeded by an entropy source.
13
Management: FCS_RBG_EXT.1
14
No specific management functions are identified.
15
Audit: FCS_RBG_EXT.1
16
The following actions should be auditable if FAU_GEN Security audit data generation is
17
included in the PP/ST:
18
 Failure of the randomization process
19
FCS_RBG_EXT.1 Cryptographic Operation (Random Bit Generation)
20
Hierarchical to: No other components
21
Dependencies: FCS_COP.1(b) Cryptographic Operation (Hash Algorithm),
22
FCS_COP.1(c) Cryptographic Operation (Keyed Hash Algorithm)
23
FCS_RBG_EXT.1.1 The TSF shall perform all deterministic random bit generation services
24
in accordance with [selection: ISO/IEC 18031:2011, [assignment: other RBG standards]] using
25
[selection: Hash_DRBG (any), HMAC_DRBG (any), CTR_DRBG (AES)].
26
FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded by at least one entropy source
27
that accumulates entropy from [selection:
28
 [assignment: number of software-based sources] software-based noise source(s),
29
 [assignment: number of hardware-based sources] hardware-based noise source(s)]
30
with a minimum of [selection: 128 bits, 256 bits] of entropy at least equal to the greatest
31
security strength, according to ISO/IEC 18031:2011 Table C.1 “Security Strength Table for
32
Hash Functions”, of the keys and hashes that it will generate.
33
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 55 of 75
Application Note: ISO/IEC 18031:2011contains three different methods of generating random
1
numbers; each of these, in turn, depends on underlying cryptographic primitives (hash
2
functions/ciphers). The ST author will select the function used, and include the specific
3
underlying cryptographic primitives used in the requirement. While any of the identified hash
4
functions (SHA-256, SHA-384, SHA-512) are allowed for Hash_DRBG or HMAC_DRBG, only
5
AES-based implementations for CTR_DRBG are allowed.
6
FCS_SMC_EXT Submask Combining
7
Family Behavior
8
This family specifies the means by which submasks are combined, if the TOE supports more
9
than one submask being used to derive or protect the BEV.
10
Component Leveling
11
FCS_SMC_EXT Submask Combining 1
12
FCS_SMC_EXT.1, Submask Combining, requires the TSF to combine the submasks in a
13
predictable fashion.
14
Management: FCS_SMC_EXT.1
15
No specific management functions are identified.
16
Audit: FCS_SMC_EXT.1
17
There are no auditable events foreseen.
18
FCS_SMC_EXT.1 Submask Combining
19
Hierarchical to: No other components
20
Dependencies: FCS_COP.1(b) Cryptographic Operation (Hash Algorithm)
21
FCS_SMC_EXT.1.1 The TSF shall combine submasks using the following method
22
[selection: exclusive OR (XOR), SHA-256, SHA-384, SHA-512] to generate an [assignment:
23
types of keys].
24
FCS_SNI_EXT Cryptographic Operation (Salt, Nonce, and Initialization Vector
25
Generation)
26
Family Behavior
27
This family ensures that salts, nonces, and IVs are well formed.
28
Component Leveling
29
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 56 of 75
FCS_SNI_EXT Cryptographic Operation (Salt,
Nonce, and Initialization Vector Generation)
1
1
FCS_SNI_EXT.1, Cryptographic Operation (Salt, Nonce, and Initialization Vector
2
Generation), requires the generation of salts, nonces, and IVs to be used by the cryptographic
3
components of the TOE to be performed in the specified manner.
4
Management: FCS_SNI_EXT.1
5
No specific management functions are identified.
6
Audit: FCS_SNI_EXT.1
7
There are no auditable events foreseen.
8
FCS_SNI_EXT.1 Cryptographic Operation (Salt, Nonce, and Initialization Vector
9
Generation)
10
Hierarchical to: No other components
11
Dependencies: FCS_RBG_EXT.1 Cryptographic Operation (Random Bit Generation)
12
FCS_SNI_EXT.1.1 The TSF shall [selection: use no salts, use salts that are generated by a
13
[selection: DRBG as specified in FCS_RBG_EXT.1, DRBG provided by the host platform]].
14
FCS_SNI_EXT.1.2 The TSF shall use [selection: no nonces, unique nonces with a minimum
15
size of [64] bits].
16
FCS_SNI_EXT.1.3 The TSF shall create IVs in the following manner [selection:
17
 CBC: IVs shall be non-repeating;
18
 CCM: Nonce shall be non-repeating;
19
 XTS: No IV. Tweak values shall be non-negative integers, assigned consecutively,
20
and starting at an arbitrary non-negative integer;
21
 GCM: IV shall be non-repeating. The number of invocations of GCM shall not exceed
22
2^32 for a given secret key].
23
FCS_VAL_EXT Validation of Cryptographic Elements
24
Family Behavior
25
This family specifies the means by which submasks and/or BEVs are determined to be valid
26
prior to their use.
27
Component Leveling
28
FCS_VAL_EXT Validation of
Cryptographic Elements
1
29
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 57 of 75
FCS_VAL_EXT.1, Validation, requires the TSF to validate submasks and BEVs by one or
1
more of the specified methods.
2
Management: FCS_VAL_EXT.1
3
No specific management functions are identified.
4
Audit: FCS_VAL_EXT.1
5
There are no auditable events foreseen.
6
FCS_VAL_EXT.1 Validation
7
Hierarchical to: No other components
8
Dependencies: FCS_COP.1(b) Cryptographic Operation (Hash Algorithm),
9
FCS_COP.1(c) Cryptographic Operation (Keyed Hash Algorithm),
10
FCS_COP.1(d) Cryptographic Operation (Key Wrapping),
11
FCS_COP.1(f) Cryptographic Operation (AES Data
12
Encryption/Decryption)
13
FCS_VAL_EXT.1.1 The TSF shall perform validation of the [selection: submask,
14
intermediate key, BEV] using the following method(s): [selection:
15
 key wrap as specified in FCS_COP.1(d);
16
 hash the [selection: submask, intermediate key, BEV] as specified in [selection:
17
FCS_COP.1(b), FCS_COP.1(c)] and compare it to a stored hashed [selection:
18
submask, intermediate key, BEV];
19
 decrypt a known value using the [selection: submask, intermediate key, BEV] as
20
specified in FCS_COP.1(f) and compare it against a stored known value]
21
FCS_VAL_EXT.1.2 The TSF shall require validation of the [selection: submask,
22
intermediate key, BEV] prior to [assignment: activity requiring validation].
23
FCS_VAL_EXT.1.3 The TSF shall [selection:
24
 perform a key sanitization of the DEK upon a [selection: configurable number,
25
[assignment: ST author specified number]] of consecutive failed validation attempts,
26
 institute a delay such that only [assignment: ST author specified number of attempts]
27
can be made within a 24 hour period,
28
 block validation after [assignment: ST author specified number of attempts] of
29
consecutive failed validation attempts,
30
 require power cycle/reset the TOE after [assignment: ST author specified number of
31
attempts] of consecutive failed validation attempts].
32
FDP_DSK_EXT Protection of Data on Disk
33
Family Behavior
34
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 58 of 75
This family specifies methods for ensuring that data residing in permanent storage on disk is
1
not subject to unauthorized disclosure.
2
Component Leveling
3
FDP_DSK_EXT Protection of Data on
Disk
1
4
FDP_DSK_EXT.1, Validation, requires the TSF to validate submasks and BEVs by one or
5
more of the specified methods.
6
Management: FDP_DSK_EXT.1
7
No specific management functions are identified.
8
Audit: FDP_DSK_EXT.1
9
There are no auditable events foreseen.
10
FDP_DSK_EXT.1 Protection of Data on Disk
11
Hierarchical to: No other components
12
Dependencies: FCS_COP.1(f) Cryptographic Operation (AES Data
13
Encryption/Decryption)
14
FDP_DSK_EXT.1.1 The TSF shall perform Full Drive Encryption in accordance with
15
FCS_COP.1(f), such that the drive contains no plaintext protected data.
16
FDP_DSK_EXT.1.2 The TSF shall encrypt all protected data without user intervention.
17
Application Note: The intent of this requirement is to specify that encryption of any protected
18
data will not depend on a user electing to protect that data. The drive encryption specified in
19
FDP_DSK_EXT.1 occurs transparently to the user and the decision to protect the data is
20
outside the discretion of the user, which is a characteristic that distinguishes it from file
21
encryption. The definition of protected data can be found in the glossary.
22
The cryptographic functions that perform the encryption/decryption of the data may be
23
provided by the Operational Environment. Note that if this is the case, it is assumed that the
24
environmental implementation of AES is consistent with the behavior described in
25
FCS_COP.1(f). If the TOE provides the cryptographic functions to encrypt/decrypt the data,
26
the ST author includes FCS_COP.1(f) as defined in Appendix A in the main body of the ST.
27
FPT_FAC_EXT Firmware Access Control
28
Family Behavior
29
This family requires that a valid authentication factor be provided prior to the TSF authorizing
30
an update of its firmware.
31
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 59 of 75
Component Leveling
1
FPT_FAC_EXT Firmware Access
Control
1
2
FPT_FAC_EXT.1, Firmware Access Control, requires the TSF to require an authentication
3
factor prior to allowing a firmware update to be performed.
4
Management: FPT_FAC_EXT.1
5
The following actions could be considered for the management functions in FMT:
6
a) management of the password used to authorize the firmware update
7
Audit: FPT_FAC_EXT.1
8
There are no auditable events foreseen.
9
FPT_FAC_EXT.1 Firmware Access Control
10
Hierarchical to: No other components
11
Dependencies: No dependencies
12
FPT_FAC_EXT.1.1 The TSF shall require [selection: a password, a known unique value
13
printed on the device, a privileged user action] before the firmware update proceeds.
14
FPT_FUA_EXT Firmware Update Authentication
15
Family Behavior
16
This family requires that firmware updates be authenticated by the TSF prior to being applied.
17
Component Leveling
18
FPT_FUA_EXT Firmware Update
Authentication
1
19
FPT_FUA_EXT.1, Firmware Update Authentication, requires the TSF to authenticate
20
firmware updates using a specified method.
21
Management: FPT_FUA_EXT.1
22
No specific management functions are identified.
23
Audit: FPT_FUA_EXT.1
24
There are no auditable events foreseen.
25
FPT_FUA_EXT.1 Firmware Update Authentication
26
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 60 of 75
Hierarchical to: No other components
1
Dependencies: FCS_COP.1(a) Cryptographic Operation (Signature Verification),
2
FCS_COP.1(b) Cryptographic Operation (Hash Algorithm)
3
FPT_FUA_EXT.1.1 The TSF shall authenticate the source of the firmware update using the
4
digital signature algorithm specified in FCS_COP.1(a) using the RTU that contains
5
[selection: the public key, hash value of the public key as specified in FCS_COP.1(b)].
6
FPT_FUA_EXT.1.2 The TSF shall only allow installation of firmware updates if the digital
7
signature has been successfully verified as specified in FCS_COP.1(a).
8
FPT_FUA_EXT.1.3 The TSF shall only allow modification of the existing firmware after
9
the successful validation of the digital signature, using a mechanism as described in
10
FPT_TUD_EXT.1.2.
11
FPT_FUA_EXT.1.4 The TSF shall return an error code if any part of the firmware update
12
process fails.
13
FPT_KYP_EXT Key and Key Material Protection
14
Family Behavior
15
This family requires that key and key material be protected if and when written to non-volatile
16
storage.
17
Component Leveling
18
FPT_KYP_EXT Key and Key Material
Protection
1
19
FPT_KYP_EXT.1, Protection of Key and Key Material, requires the TSF to ensure that no
20
plaintext key or key material are written to non-volatile storage.
21
Management: FPT_KYP_EXT.1
22
No specific management functions are identified.
23
Audit: FPT_KYP_EXT.1
24
There are no auditable events foreseen.
25
FPT_KYP_EXT.1 Protection of Key and Key Material
26
Hierarchical to: No other components
27
Dependencies: FCS_COP.1(d) Cryptographic Operation (Key Wrapping),
28
FCS_COP.1(e) Cryptographic Operation (Key Transport),
29
FCS_COP.1(g) Cryptographic Operation (Key Encryption),
30
FCS_KYC_EXT.1 Key Chaining (Initiator),
31
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 61 of 75
FCS_KYC_EXT.2 Key Chaining (Recipient),
1
FCS_SMC_EXT.1 Submask Combining
2
FPT_KYP_EXT.1.1 The TSF shall [selection:
3
 not store keys in non-volatile memory
4
 only store keys in non-volatile memory when wrapped, as specified in
5
FCS_COP.1(d), or encrypted, as specified in FCS_COP.1(g) or FCS_COP.1(e)
6
 only store plaintext keys that meet any one of the following criteria [selection:
7
o the plaintext key is not part of the key chain as specified in
8
FCS_KYC_EXT.2,
9
o the plaintext key will no longer provide access to the encrypted data after
10
initial provisioning,
11
o the plaintext key is a key split that is combined as specified in
12
FCS_SMC_EXT.1, and the other half of the key split is [selection:
13
 wrapped as specified in FCS_COP.1(d),
14
 encrypted as specified in FCS_COP.1(g) or FCS_COP.1(e),
15
 derived and not stored in non-volatile memory],
16
o the non-volatile memory the key is stored on is located in an external storage
17
device for use as an authorization factor,
18
o the plaintext key is [selection:
19
 used to wrap a key as specified in FCS_COP.1(d),
20
 used to encrypt a key as specified in FCS_COP.1(g) or FCS_COP.1(e)]
21
that is already [selection:
22
 wrapped as specified in FCS_COP.1(d),
23
 encrypted as specified in FCS_COP.1(g) or FCS_COP.1(e)]]].
24
FPT_PWR_EXT Power Management
25
Family Behavior
26
This family defines secure behavior of the TSF when the TOE supports multiple power saving
27
states. The use of Compliant power saving states (i.e. power saving states that purge security-
28
relevant data upon entry) is essential for ensuring that state transitions cannot be used as attack
29
vectors to bypass TOE self-protection mechanisms.
30
Component Leveling
31
FPT_PWR_EXT Power Management
1
2
32
FPT_PWR_EXT.1, Power Saving States, defines the Compliant power saving states that are
33
implemented by the TSF.
34
FPT_PWR_EXT.2, Timing of Power Saving States, describes the situations that cause
35
Compliant power saving states to be entered.
36
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 62 of 75
Management: FPT_PWR_EXT.1
1
The following actions could be considered for the management functions in FMT:
2
 Enable or disable the use of individual power saving states
3
 Specify one or more power saving state configurations
4
Audit: FPT_PWR_EXT.1
5
There are no auditable events foreseen.
6
Management: FPT_PWR_EXT.2
7
There are no management activities foreseen.
8
Audit: FPT_PWR_EXT.2
9
The following actions should be auditable if FAU_GEN Security audit data generation is
10
included in the PP/ST:
11
 Transition of the TSF into different power saving states
12
FPT_PWR_EXT.1 Authorization Factor Acquisition
13
Hierarchical to: No other components
14
Dependencies: No dependencies
15
FPT_PWR_EXT.1.1 The TSF shall define the following Compliant power saving states:
16
[selection: choose at least one of: S3, S4, G2(S5), G3, D0, D1, D2, D3 [assignment: other
17
power saving states]].
18
FPT_PWR_EXT.2 Authorization Factor Acquisition
19
Hierarchical to: No other components
20
Dependencies: FPT_PWR_EXT.1 Power Saving States
21
FPT_PWR_EXT.2.1 For each Compliant power saving state defined in
22
FPT_PWR_EXT.1.1, the TSF shall enter the Compliant power saving state when the
23
following conditions occur: user-initiated request, [selection: shutdown, user inactivity,
24
request initiated by remote management system, [assignment: other conditions], no other
25
conditions].
26
FPT_RBP_EXT Rollback Protection
27
Family Behavior
28
This family requires that the TSF protects against rollbacks or downgrades to its firmware.
29
Component Leveling
30
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 63 of 75
FPT_RBP_EXT Rollback Protection 1
1
FPT_RBP_EXT.1, Rollback Protection, requires the TSF to detect and prevent unauthorized
2
rollback.
3
Management: FPT_KYP_EXT.1
4
No specific management functions are identified.
5
Audit: FPT_KYP_EXT.1
6
There are no auditable events foreseen.
7
FPT_RBP_EXT.1 Rollback Protection
8
Hierarchical to: No other components
9
Dependencies: No dependencies
10
FPT_RBP_EXT.1.1 The TSF shall verify that the new firmware package is not downgrading
11
to a lower security version number by [assignment: method of verifying the security version
12
number is the same as or higher than the currently installed version].
13
FPT_RBP_EXT.1.2 The TSF shall generate and return an error code if the attempted firmware
14
update package is detected to be an invalid version.
15
FPT_TST_EXT TSF Testing
16
Family Behavior
17
Components in this family address the requirements for self-testing the TSF for selected correct
18
operation.
19
Component Leveling
20
FPT_TST_EXT TSF Testing 1
21
FPT_TST_EXT.1, TSF Testing, requires a suite of self-tests to be run during initial start-up in
22
order to demonstrate correct operation of the TSF.
23
Management: FPT_TST_EXT.1
24
No specific management functions are identified.
25
Audit: FPT_TST_EXT.1
26
The following actions should be auditable if FAU_GEN Security audit data generation is
27
included in the PP/ST:
28
 Indication that TSF self-test was completed
29
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 64 of 75
FPT_TST_EXT.1 TSF Testing
1
Hierarchical to: No other components
2
Dependencies: No dependencies
3
FPT_TST_EXT.1.1 The TSF shall run a suite of the following self-tests [selection: during
4
initial start-up (on power on), periodically during normal operation, at the request of the
5
authorized user, at the conditions [assignment: conditions under which self-tests should
6
occur]] to demonstrate the correct operation of the TSF: [assignment: list of self-tests run by
7
the TSF].
8
FPT_TUD_EXT Trusted Update
9
Family Behavior
10
Components in this family address the requirements for updating the TOE firmware and/or
11
software.
12
Component Leveling
13
FPT_TUD_EXT Trusted Update 1
14
FPT_TUD_EXT.1, Trusted Update, requires the capability to be provided to update the TOE
15
firmware and software, including the ability to verify the updates prior to installation.
16
Management: FPT_TUD_EXT.1
17
The following actions could be considered for the management functions in FMT:
18
 Ability to update the TOE and to verify the updates
19
Audit: FPT_TUD_EXT.1
20
The following actions should be auditable if FAU_GEN Security audit data generation is
21
included in the PP/ST:
22
 Initiation of the update process.
23
 Any failure to verify the integrity of the update
24
FPT_TUD_EXT.1 Trusted Update
25
Hierarchical to: No other components
26
Dependencies: FCS_COP.1(a) Cryptographic Operation (Signature Verification),
27
FCS_COP.1(b) Cryptographic Operation (Hash Algorithm)
28
FPT_TUD_EXT.1.1 The TSF shall provide [assignment: list of subjects] the ability to query
29
the current version of the TOE software/firmware.
30
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 65 of 75
FPT_TUD_EXT.1.2 The TSF shall provide [assignment: list of subjects] the ability to initiate
1
updates to TOE software/firmware.
2
FPT_TUD_EXT.1.3 The TSF shall verify updates to the TOE software/firmware using a
3
[selection: digital signature, published hash] by the manufacturer prior to installing those
4
updates.
5
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 66 of 75
Appendix D: Entropy Documentation and Assessment
1
This is an optional appendix in the cPP, and only applies if the TOE is providing the Random
2
Bit Generator
3
This appendix describes the required supplementary information for each entropy source used
4
by the TOE.
5
The documentation of the entropy source(s) should be detailed enough that, after reading, the
6
evaluator will thoroughly understand the entropy source and why it can be relied upon to
7
provide sufficient entropy. This documentation should include multiple detailed sections:
8
design description, entropy justification, operating conditions, and health testing. This
9
documentation is not required to be part of the TSS in the public facing ST.
10
D.1 Design Description
11
Documentation shall include the design of each entropy source as a whole, including the
12
interaction of all entropy source components. Any information that can be shared regarding the
13
design should also be included for any third-party entropy sources that are included in the
14
product.
15
The documentation will describe the operation of the entropy source to include, how entropy
16
is produced, and how unprocessed (raw) data can be obtained from within the entropy source
17
for testing purposes. The documentation should walk through the entropy source design
18
indicating where the entropy comes from, where the entropy output is passed next, any post-
19
processing of the raw outputs (hash, XOR, etc.), if/where it is stored, and finally, how it is
20
output from the entropy source. Any conditions placed on the process (e.g., blocking) should
21
also be described in the entropy source design. Diagrams and examples are encouraged.
22
This design must also include a description of the content of the security boundary of the
23
entropy source and a description of how the security boundary ensures that an adversary outside
24
the boundary cannot affect the entropy rate.
25
If implemented, the design description shall include a description of how third-party
26
applications can add entropy to the RBG. A description of any RBG state saving between
27
power-off and power-on shall be included.
28
D.2 Entropy Justification
29
There should be a technical argument for where the unpredictability in the source comes from
30
and why there is confidence in the entropy source delivering sufficient entropy for the uses
31
made of the RBG output (by this particular TOE). This argument will include a description of
32
the expected min-entropy rate (i.e. the minimum entropy (in bits) per bit or byte of source data)
33
and explain that sufficient entropy is going into the TOE randomizer seeding process. This
34
discussion will be part of a justification for why the entropy source can be relied upon to
35
produce bits with entropy.
36
The amount of information necessary to justify the expected min-entropy rate depends on the
37
type of entropy source included in the product.
38
39
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 67 of 75
For developer provided entropy sources, in order to justify the min-entropy rate, it is expected
1
that a large number of raw source bits will be collected, statistical tests will be performed, and
2
the min-entropy rate determined from the statistical tests. While no particular statistical tests
3
are required at this time, it is expected that some testing is necessary in order to determine the
4
amount of min-entropy in each output.
5
6
For third party provided entropy sources, in which the TOE vendor has limited access to the
7
design and raw entropy data of the source, the documentation will indicate an estimate of the
8
amount of min-entropy obtained from this third-party source. It is acceptable for the vendor to
9
“assume” an amount of min-entropy, however, this assumption must be clearly stated in the
10
documentation provided. In particular, the min-entropy estimate must be specified and the
11
assumption included in the ST.
12
Regardless of type of entropy source, the justification will also include how the DRBG is
13
initialized with the entropy stated in the ST, for example by verifying that the min-entropy rate
14
is multiplied by the amount of source data used to seed the DRBG or that the rate of entropy
15
expected based on the amount of source data is explicitly stated and compared to the statistical
16
rate. If the amount of source data used to seed the DRBG is not clear or the calculated rate is
17
not explicitly related to the seed, the documentation will not be considered complete.
18
19
The entropy justification shall not include any data added from any third-party application or
20
from any state saving between restarts.
21
D.3 Operating Conditions
22
The entropy rate may be affected by conditions outside the control of the entropy source itself.
23
For example, voltage, frequency, temperature, and elapsed time after power-on are just a few
24
of the factors that may affect the operation of the entropy source. As such, documentation will
25
also include the range of operating conditions under which the entropy source is expected to
26
generate random data. Similarly, documentation shall describe the conditions under which the
27
entropy source is no longer guaranteed to provide sufficient entropy. Methods used to detect
28
failure or degradation of the source shall be included.
29
D.4 Health Testing
30
More specifically, all entropy source health tests and their rationale will be documented. This
31
will include a description of the health tests, the rate and conditions under which each health
32
test is performed (e.g., at startup, continuously, or on-demand), the expected results for each
33
health test, TOE behavior upon entropy source failure, and rationale indicating why each test
34
is believed to be appropriate for detecting one or more failures in the entropy source.
35
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 68 of 75
Appendix E: Key Management Description
1
The documentation of the product’s encryption key management should be detailed enough
2
that, after reading, the evaluator will thoroughly understand the product’s key management and
3
how it meets the requirements to ensure the keys are adequately protected. This documentation
4
should include an essay and diagram(s). This documentation is not required to be part of the
5
TSS - it can be submitted as a separate document and marked as developer proprietary.
6
The following topics may not apply to all products, so a note as to why the details do not apply
7
should be included.
8
Essay:
9
The essay will provide the following information for all keys in the key chain:
10
 The purpose of the key
11
 If the key is stored in non-volatile memory
12
 How and when the key is protected
13
 How and when the key is derived
14
 The strength of the key
15
 When or if the key would be no longer needed, along with a justification.
16
The essay will also describe the following topics:
17
 The process for validation shall be described, noting what value(s) is used for
18
validation and the process used to perform the validation. It shall describe how this
19
process ensures no keys in the key chain are weakened or exposed by this process. It
20
shall describe the method used to limit the number of consecutively failed
21
authorization attempts.
22
 The authorization process that leads to the ultimate release of the DEK. This section
23
shall detail the key chain used by the product. It shall describe which keys are used in
24
the protection of the DEK and how they meet the derivation or key wrap. It shall also
25
include any values that add into that key chain or interact with the key chain and the
26
protections that ensure those values do not weaken or expose the overall strength of
27
the key chain.
28
 The diagram and essay will clearly illustrate the key hierarchy to ensure that at no
29
point the chain could be broken without a cryptographic exhaust or knowledge of the
30
BEV and the effective strength of the DEK is maintained throughout the Key Chain.
31
 A description of the data encryption engine, its components, and details about its
32
implementation (e.g. for hardware: integrated within the device’s main SOC or
33
separate co-processor, for software: initialization of the product, drivers, libraries (if
34
applicable), logical interfaces for encryption/decryption, and areas which are not
35
encrypted (e.g. boot loaders, portions associated with the Master Boot Record
36
(MBRs), partition tables, etc.)). The description should also include the data flow
37
from the device’s host interface to the device’s persistent media storing the data,
38
information on those conditions in which the data bypasses the data encryption engine
39
(e.g. read-write operations to an unencrypted Master Boot Record area). The
40
description should be detailed enough to verify all platforms to ensure that when the
41
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 69 of 75
user enables encryption, the product encrypts all hard storage devices. It should also
1
describe the platform’s boot initialization, the encryption initialization process, and at
2
what moment the product enables the encryption.
3
 The process for destroying keys when they are no longer needed by including the type
4
of storage location of all keys and the destruction method for that storage.
5
Diagram:
6
 The diagram will include all keys from the BEV to the DEK and any keys or values
7
that contribute into the chain. It must list the cryptographic strength of each key and
8
illustrate how each key along the chain is protected with either Key Derivation or Key
9
Wrapping (from the allowed options). The diagram should indicate the input used to
10
derive or unwrap each key in the chain.
11
 A functional (block) diagram showing the main components (such as memories and
12
processors) and the data path between, for hardware, the device’s host interface and
13
the device’s persistent media storing the data, or for software, the initial steps needed
14
for the activities the TOE performs to ensure it encrypts the storage device entirely
15
when a user or administrator first provisions the product. The hardware encryption
16
diagram shall show the location of the data encryption engine within the data path.
17
 The hardware encryption diagram shall show the location of the data encryption
18
engine within the data path. The evaluator shall validate that the hardware encryption
19
diagram contains enough detail showing the main components within the data path
20
and that it clearly identifies the data encryption engine.
21
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 70 of 75
Appendix F: Glossary
1
Term Meaning
Authorization Factor A value that a user knows, has, or is (e.g. password, token, etc.)
submitted to the TOE to establish that the user is in the community
authorized to use the hard disk. This value is used in the derivation or
decryption of the BEV and eventual decryption of the DEK. Note
that these values may or may not be used to establish the particular
identity of the user.
Assurance Grounds for confidence that a TOE meets the SFRs [CC1].
Border Encryption Value A value passed from the AA to the EE intended to link the key chains
of the two components.
Key Sanitization A method of sanitizing encrypted data by securely overwriting the key
that was encrypting the data.
Data Encryption Key (DEK) A key used to encrypt data-at-rest.
Full Drive Encryption Refers to partitions of logical blocks of user accessible data as
managed by the host system that indexes and partitions and an
operating system that maps authorization to read or write data to blocks
in these partitions. For the sake of this Security Program Definition
(SPD) and cPP, FDE performs encryption and authorization on one
partition, so defined and supported by the OS and file system jointly,
under consideration. FDE products encrypt all data (with certain
exceptions) on the partition of the storage device and permits access to
the data only after successful authorization to the FDE solution. The
exceptions include the necessity to leave a portion of the storage device
(the size may vary based on implementation) unencrypted for such
things as the Master Boot Record (MBR) or other AA/EE pre-
authentication software. These FDE cPPs interpret the term “full drive
encryption” to allow FDE solutions to leave a portion of the storage
device unencrypted so long as it contains no protected data.
Intermediate Key A key used in a point between the initial user authorization and the
DEK.
Host Platform The local hardware and software the TOE is running on, this does not
include any peripheral devices (e.g. USB devices) that may be
connected to the local hardware and software.
Key Chaining The method of using multiple layers of encryption keys to protect data.
A top layer key encrypts a lower layer key which encrypts the data;
this method can have any number of layers.
Key Encryption Key (KEK) A key used to encrypt other keys, such as DEKs or storage that
contains keys.
Key Material Key material is commonly known as critical security parameter (CSP)
data, and also includes authorization data, nonces, and metadata.
Key Release Key (KRK) A key used to release another key from storage, it is not used for the
direct derivation or decryption of another key.
Operating System (OS) Software which runs at the highest privilege level and can directly
control hardware resources.
Non-Volatile Memory A type of computer memory that will retain information without
power.
Powered-Off State The device has been shut down.
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 71 of 75
Term Meaning
Protected Data This refers to all data on the storage device with the exception of a
small portion required for the TOE to function correctly. It is all space
on the disk a user could write data to and includes the operating
system, applications, and user data. Protected data does not include the
Master Boot Record or Pre-authentication area of the drive – areas of
the drive that are necessarily unencrypted.
Root of Trust for Update A type of Root of Trust for Verification that verifies the integrity and
authenticity of an update payload before initiating the update process.
Root of Trust for Verification A Root of Trust (RoT) that verifies an integrity measurement against
a policy.
Submask A submask is a bit string that can be generated and stored in a number
of ways.
Target of Evaluation A set of software, firmware and/or hardware possibly accompanied by
guidance. [CC1]
See [CC1] for other Common Criteria abbreviations and terminology.
1
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 72 of 75
Appendix G: Acronyms
1
Acronym Meaning
AA Authorization Acquisition
AES Advanced Encryption Standard
BEV Border Encryption Value
BIOS Basic Input Output System
CBC Cipher Block Chaining
CC Common Criteria
CCM Counter with CBC-Message Authentication Code
CEM Common Evaluation Methodology
CPP Collaborative Protection Profile
DEK Data Encryption Key
DRBG Deterministic Random Bit Generator
DSS Digital Signature Standard
ECC Elliptic Curve Cryptography
ECDSA Elliptic Curve Digital Signature Algorithm
EE Encryption Engine
EEPROM Electrically Erasable Programmable Read-Only Memory
FIPS Federal Information Processing Standards
FDE Full Drive Encryption
FFC Finite Field Cryptography
GCM Galois Counter Mode
HMAC Keyed-Hash Message Authentication Code
IEEE Institute of Electrical and Electronics Engineers
IT Information Technology
ITSEF IT Security Evaluation Facility
ISO/IEC International Organization for Standardization / International Electrotechnical
Commission
IV Initialization Vector
KEK Key Encryption Key
KMD Key Management Description
KRK Key Release Key
MBR Master Boot Record
NIST National Institute of Standards and Technology
OS Operating System
RBG Random Bit Generator
RNG Random Number Generator
RoT Root of Trust
RSA Rivest Shamir Adleman Algorithm
RTU Root of Trust for Update
RTV Root of Trust for Verification
SAR Security Assurance Requirement
SED Self-Encrypting Drive
SHA Secure Hash Algorithm
SFR Security Functional Requirement
SPD Security Problem Definition
SPI Serial Peripheral Interface
ST Security Target
TOE Target of Evaluation
TPM Trusted Platform Module
TSF TOE Security Functionality
TSS TOE Summary Specification
USB Universal Serial Bus
XOR Exclusive or
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 73 of 75
XTS XEX (XOR Encrypt XOR) Tweakable Block Cipher with Ciphertext Stealing
1
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 74 of 75
Appendix H: References
1
National Institute of Standards and Technology (NIST) Special Publication 800-38F,
2
Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping, National
3
Institute of Standards and Technology, December 2012.
4
National Institute of Standards and Technology (NIST) Special Publication 800-56B,
5
Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization
6
Cryptography, National Institute of Standards and Technology, August 2009.
7
National Institute of Standards and Technology (NIST) Special Publication 800-88 Revision
8
1, Guidelines for Media Sanitization, National Institute of Standards and Technology,
9
December 2014.
10
National Institute of Standards and Technology (NIST) Special Publication 800-90A,
11
Recommendation for Random Number Generation Using Deterministic Random Bit
12
Generators, National Institute of Standards and Technology, January 2012.
13
National Institute of Standards and Technology (NIST) Special Publication 800-132,
14
Recommendation for Password-Based Key Derivation Part 1: Storage Applications, National
15
Institute of Standards and Technology, December 2010.
16
Federal Information Processing Standard Publication (FIPS-PUB) 186-4, Digital Signature
17
Standard (DSS), National Institute of Standards and Technology, July 2013.
18
International Organization for Standardization (ISO)/International Electrotechnical
19
Commission (IEC) 9796-2:2010 (3rd
edition), Information technology — Security techniques
20
— Digital signature schemes giving message recovery, International Organization for
21
Standardization/International Electrotechnical Commission, 2010.
22
International Organization for Standardization (ISO)/International Electrotechnical
23
Commission (IEC) 9797-2:2011 (2nd
edition), Information technology — Security techniques
24
— Message Authentication Codes (MACs) – Part 2: Mechanisms using a dedicated hash-
25
function, International Organization for Standardization/International Electrotechnical
26
Commission, 2011.
27
International Organization for Standardization (ISO)/International Electrotechnical
28
Commission (IEC) 10116:2006 (3rd
edition), Information technology — Security techniques
29
— Modes of operation for an n-bit block cipher, International Organization for
30
Standardization/International Electrotechnical Commission, 2006.
31
International Organization for Standardization (ISO)/International Electrotechnical
32
Commission (IEC) 10118-3:2004 (3rd
edition), Information technology — Security techniques
33
— Hash-functions – Part 3: Dedicated hash-functions, International Organization for
34
Standardization/International Electrotechnical Commission, 2004.
35
International Organization for Standardization (ISO)/International Electrotechnical
36
Commission (IEC) 14888-3:2006 (2nd
edition), Information technology — Security techniques
37
—Digital signatures with appendix – Part 3: Discrete logarithm based mechanisms,
38
collaborative Protection Profile for Full Drive Encryption - Encryption Engine
Version 2.0 + Errata 20190201 Page 75 of 75
International Organization for Standardization/International Electrotechnical Commission,
1
2006.
2
International Organization for Standardization (ISO)/International Electrotechnical
3
Commission (IEC) 18031:2011 (2nd
edition), Information technology — Security techniques
4
— Random bit generation, International Organization for Standardization/International
5
Electrotechnical Commission, 2011.
6
International Organization for Standardization (ISO)/International Electrotechnical
7
Commission (IEC) 18033-3:2011 (3rd
edition), Information technology — Security techniques
8
— Encryption algorithms – Part 3: Block ciphers, International Organization for
9
Standardization/International Electrotechnical Commission, 2011.
10
International Organization for Standardization (ISO)/International Electrotechnical
11
Commission (IEC) 19772:2009, Information technology — Security techniques Authenticated
12
encryption, International Organization for Standardization/International Electrotechnical
13
Commission, 2009.
14