PP Reference: collaborative Protection Profile for Dedicated Security Component
PP Version: 1.0
PP Date: September 10, 2020
1.2 Overview
The scope of this Protection Profile (PP) is to
describe the security functionality of QQQQ products in terms of [CC]
and to define functional and assurance requirements for such products.
1.3 Terms
The following sections list Common Criteria and technology terms used in this document.
1.3.1 Common Criteria Terms
Assurance
Grounds for confidence that a TOE meets the SFRs [CC].
Common Criteria for Information Technology Security Evaluation (International Standard ISO/IEC 15408).
Common Criteria Testing Laboratory
Within the context of the Common Criteria Evaluation and Validation Scheme (CCEVS), an IT security evaluation facility, accredited by the National Voluntary Laboratory Accreditation Program (NVLAP) and approved by the NIAP Validation Body to conduct Common Criteria-based evaluations.
An anti-exploitation feature which loads memory mappings into unpredictable
locations. ASLR makes it more difficult for an attacker to redirect control to code
that they have introduced into the address space of a process.
Administrator
An administrator is responsible for management activities, including setting policies that are
applied by the enterprise on the operating system.
This administrator could be acting remotely through a management server, from which the system
receives configuration policies.
An administrator can enforce settings on the system which cannot be overridden by non-administrator users.
A specification of routines, data structures, object classes, and variables
that allows an application to make use of services provided by another software
component, such as a library. APIs are often provided for a set of libraries included
with the platform.
Credential
Data that establishes the identity of a user, e.g. a cryptographic key or
password.
Information that is either user or system defined and
is used to operate a cryptographic module in processing encryption functions including
cryptographic keys and authentication data, such as passwords, the disclosure or modification
of which can compromise the security of a cryptographic module or the security of the
information protected by the module.
Countermeasures that prevent attackers, even those with physical access,
from extracting data from non-volatile storage.
Common techniques include data encryption and wiping.
An anti-exploitation feature of modern operating systems executing on
modern computer hardware, which enforces a non-execute permission on pages of memory.
DEP prevents pages of memory from containing both data and instructions, which makes
it more difficult for an attacker to introduce and execute code.
Developer
An entity that writes OS software. For the purposes of this document,
vendors and developers are the same.
General Purpose Operating System
A class of OSes designed to support a wide-variety of workloads consisting of many concurrent applications or services.
Typical characteristics for OSes in this class include support for third-party applications,
support for multiple users, and security separation between users and their respective resources.
General Purpose Operating Systems also lack the real-time constraint that defines Real Time Operating Systems (RTOS).
RTOSes typically power routers, switches, and embedded devices.
Host-based Firewall
A software-based firewall implementation running on the OS for filtering inbound and
outbound network traffic to and from processes running on the OS.
Software that manages physical and logical resources and provides services
for applications. The terms TOE and OS are interchangeable in this
document.
Any information about an individual maintained by an agency, including, but
not limited to, education, financial transactions, medical history, and criminal or
employment history and information which can be used to distinguish or trace an
individual's identity, such as their name, social security number, date and place of
birth, mother's maiden name, biometric records, etc., including any other personal
information which is linked or linkable to an individual.[OMB]
Sensitive Data
Sensitive data may include all user or enterprise data or may be specific
application data such as PII, emails, messaging, documents, calendar items, and contacts.
Sensitive data must minimally include credentials and keys. Sensitive data shall
be identified in the OS's TSS by the ST author.
User
A user is subject to configuration policies applied
to the operating system by administrators. On some systems under certain
configurations, a normal user can temporarily elevate privileges to that of an administrator.
At that time, such a user should be considered an administrator.
Requirements in this Protection Profile are designed to
address the security problems in at least the following use cases. These use cases are intentionally
very broad, as many specific use cases exist for an operating system. These use cases may also
overlap with one another. An operating system's functionality may even be effectively extended by
privileged applications installed onto it. However, these are out of scope of this PP.
[USE CASE 1] Elephant-own device
This is everything we need to describe in words about this use case.
For a the list of appropriate selections and acceptable assignment
values for this configuration, see F.1 Elephant-own device.
2 Conformance Claims
Conformance Statement
An ST must claim exact conformance to this ,
as defined in the CC and CEM addenda for Exact Conformance, Selection-Based SFRs, and
Optional SFRs (dated May 2017).
CC Conformance Claims
This is conformant to Parts 2 (extended) and 3 (conformant) of Common Criteria Version 3.1, Revision 5.
PP Claim
This does not claim conformance to any Protection Profile.
The security problem is described in terms
of the threats that the OS is expected to address, assumptions about the
operational environment, and any organizational security policies that the OS
is expected to enforce.
3.1 Threats
T.NETWORK_ATTACK
An attacker is positioned on a communications channel or elsewhere on the
network infrastructure. Attackers may engage in communications with applications and
services running on or part of the OS with the intent of compromise. Engagement may
consist of altering existing legitimate communications.
T.NETWORK_EAVESDROP
An attacker is positioned on a communications channel or elsewhere on the
network infrastructure. Attackers may monitor and gain access to data exchanged between
applications and services that are running on or part of the OS.
T.LOCAL_ATTACK
An attacker may compromise applications running on the OS. The
compromised application may provide maliciously formatted input to the OS through a
variety of channels including unprivileged system calls and messaging via the
file system.
T.LIMITED_PHYSICAL_ACCESS
An attacker may attempt to access data on the OS while having a limited
amount of time with the physical device.
3.2 Assumptions
A.PLATFORM
The OS relies upon a trustworthy computing platform for
its execution. This underlying platform is out of scope of this PP.
A.PROPER_USER
The user of the OS is not willfully negligent or hostile, and uses the
software in compliance with the applied enterprise security policy. At the same time,
malicious software could act as the user, so requirements which
confine malicious subjects are still in scope.
A.PROPER_ADMIN
The administrator of the OS is not careless, willfully negligent or hostile,
and administers the OS within compliance of the applied enterprise security policy.
4 Security Objectives
4.1 Security Objectives for the TOE
O.ACCOUNTABILITY
Conformant OSes ensure that information exists that allows
administrators to discover unintentional issues with the configuration and operation of
the operating system and discover its cause. Gathering event information and immediately
transmitting it to another system can also enable incident response in the event
of system compromise.
O.INTEGRITY
Conformant OSes ensure the integrity of their update
packages. OSes are seldom if ever shipped without errors, and the
ability to deploy patches and updates with integrity is critical to enterprise network
security. Conformant OSes provide execution environment-based
mitigations that increase the cost to attackers by adding complexity to the task of
compromising systems.
O.MANAGEMENT
To facilitate management by users and the enterprise, conformant OSes
provide consistent and supported interfaces for their
security-relevant configuration and maintenance. This includes the deployment of
applications and application updates through the use of platform-supported deployment
mechanisms and formats, as well as providing mechanisms for configuration and
application execution control.
O.PROTECTED_STORAGE
To address the issue of loss of confidentiality of credentials in the event of
loss of physical control of the storage medium, conformant OSes
provide data-at-rest protection for credentials.
Conformant OSes also provide access controls which allow users to keep their files private from other
users of the same system.
O.PROTECTED_COMMS
To address both passive (eavesdropping) and active (packet modification)
network attack threats, conformant OSes provide mechanisms to create
trusted channels for CSP and sensitive data. Both CSP and sensitive data
should not be exposed outside of the platform.
4.2 Security Objectives for the Operational Environment
The following security objectives for the operational
environment assist the OS in correctly providing its security functionality.
These track with the assumptions about the environment.
OE.PLATFORM
The OS relies on being installed on trusted
hardware.
OE.PROPER_USER
The user of the OS is not willfully negligent or hostile,
and uses the software within compliance of the applied enterprise security policy.
Standard user accounts are provisioned in accordance with the least privilege model.
Users requiring higher levels of access should have a separate account dedicated for
that use.
OE.PROPER_ADMIN
The administrator of the OS is not careless, willfully
negligent or hostile, and administers the OS within compliance of the applied enterprise
security policy.
4.3 Security Objectives Rationale
This section describes how the assumptions, threats, and organization
security policies map to the security objectives.
The threat T.NETWORK_ATTACK is countered by O.ACCOUNTABILITY as this
provides a mechanism for the OS to report behavior that may indicate a network
attack has occurred.
The threat T.NETWORK_EAVESDROP is countered by O.MANAGEMENT as this provides
for the ability to configure the OS to protect the confidentiality of its transmitted
data.
The objective O.ACCOUNTABILITY protects against local attacks by providing
a mechanism to report behavior that may indicate a local attack is occurring or
has occurred.
This chapter describes the security requirements which have to be fulfilled by the product under evaluation.
Those requirements comprise functional components from Part 2 and assurance components from Part 3 of
[CC].
The following conventions are used for the completion of operations:
Refinement operation (denoted by bold text or strikethrough
text): is used to add details to a requirement (including replacing an assignment
with a more restrictive selection) or to remove part of the requirement that is made irrelevant
through the completion of another operation, and thus further restricts a requirement.
Selection (denoted by italicized text): is used to select one or more options
provided by the [CC] in stating a requirement.
Assignment operation (denoted by italicized text): is used to assign a
specific value to an unspecified parameter, such as the length of a password. Showing the
value in square brackets indicates assignment.
Iteration operation: is indicated by appending the SFR name with a slash and unique identifier
suggesting the purpose of the operation, e.g. "/EXAMPLE1."
The TSF shall generate cryptographic keys by [parsing in accordance with
FDP_ITC_EXT.1 and FDP_ITC_EXT.2,
[selection: asymmetric key generation in accordance with FCS_CKM.1/AK, symmetric key generation in accordance to FCS_CKM.1/SK, no other methods] in accordance with a specified cryptographic key generation algorithm
[assignment: cryptographic key generation algorithm]
and specified cryptographic key sizes
[assignment: cryptographic key sizes]
that meet the following: [assignment: list of standards].
Application Note #1:
Parsing of keys can refer to both the act of importing keys from outside the TOE boundary and to
the act of issuing commands or parameters to the TOE that trigger the TSF to perform a key
generation function.
If asymmetric key generation in accordance with FCS_CKM.1/AK is selected, the selection-based
SFRFCS_CKM.1/AK must be claimed by the TOE.
If symmetric key generation in accordance with FCS_CKM.1/SK is selected, the selection-based
SFRFCS_CKM.1/SK must be claimed by the TOE.
The TSF shall generate asymmetric cryptographic keys using the methods defined by
the following rows in Table 2:
[selection: AK1, AK2, AK3, AK4, AK5].
Table 2: Supported Methods for Asymmetric Key Generation
Application Note #2:
This requirement is included for the purposes of encryption and decryption operations only. To
support ITE protected communications requirement for the transfer of encrypted data, this
requirement mandates implementation compliance to FIPS 186-4 only. Implementations
according to FIPS 186-2 or FIPS 186-3 will not be accepted.
This requirement must be claimed by the TOE if at least one of FCS_CKM.1 or FCS_CKM.1/KEK
chooses a selection related to generation of asymmetric keys.
The TSF shall generate symmetric cryptographic keys using the methods defined by
the following rows in Table 3:
[selection: RSK, DSK, PBK].
Table 3: Supported Methods for Symmetric Key Generation
Application Note #3:
The intent of this requirement is to ensure that attackers cannot recover SKs with less than a full
exhaust of the key space. This requirement explains SK generation regardless of how the DSC uses
it or when it generates it. The encryption of user data that is not keying material, authentication
tokens, or authorization values is outside the scope of this cPP. This cPP assumes that the DSC
lacks the required resources to perform bulk encryption/decryption services at a suitable rate for
users. The host may use the SK for encrypting user data outside the boundaries of the DSC. On
the other hand, the DSC may use the SK on behalf of the user to perform keyed hashes. In this
case, all the requirements for generating, controlling access and use, and destroying the key while
under the protection of the DSC apply.
The selection of key size 512 bits is for the case of XTS-AES using AES-256. In the case of XTSAES
for both AES-128 and AES-256, the developer is expected to ensure that the full key is
generated using direct generation from the RBG as in NIST SP 800-133 section.
The ST author selects at least one algorithm from the RSK row if the ST supports creating keys
directly from the output of the RBG without further conditioning, at least one algorithm from the
DSK row should be selected if the ST supports key derivation functions which are usually seeded
from RBG and then further conditioned to the appropriate key size, and at least one algorithm
from the PBK row should be selected if the ST supports keys derived from passwords.
If DSK is selected, the selection-based SFRFCS_CKM_EXT.5 must be claimed by the TOE.
If PBK is selected, the selection-based SFRFCS_COP.1/PBKDF must be claimed by the TOE.
This requirement must be claimed by the TOE if at least one of FCS_CKM.1 or FCS_CKM.1/KEK
chooses a selection related to generation of symmetric keys.
The TSF shall generate key encryption keys in accordance with a specified
cryptographic key generation algorithm corresponding to
[selection:
Asymmetric KEKs generated in accordance with FCS_CKM.1/AK identifier AK1,
Symmetric KEKs generated in accordance with FCS_CKM.1/SK,
Derived KEKs generated in accordance with FCS_CKM_EXT.5
]
and specified cryptographic key sizes [assignment:
cryptographic key sizes] that meet the
following: [assignment:
list of standards].
Application Note #4:
KEKs protect KEKs and Symmetric Keys (SKs). DSCs should use key strengths commensurate
with protecting the chosen symmetric encryption key strengths.
If Asymmetric KEKs generated in accordance with FCS_CKM.1/AK is selected, the selection-based
SFRFCS_CKM.1/AK must be claimed by the TOE.
If Symmetric KEKs generated in accordance with FCS_CKM.1/SK is selected, the selection-based
SFRFCS_CKM.1/SK must be claimed by the TOE.
If Derived KEKs generated in accordance with FCS_CKM_EXT.5 is selected, the selection-based
SFRFCS_CKM_EXT.5 must be claimed by the TOE.
The TSF shall establish cryptographic keys in accordance with a specified
cryptographic key establishment method:
[selection:
RSA-based key establishment schemes that meet the following: NIST Special
Publication 800-56B Revision 2, “Recommendation for Pair-Wise Key Establishment
Schemes Using Integer Factorization Cryptography”,
RSA-based key establishment schemes that meet the following: RSAES-PKCS1-v1_5
as specified in Section 7.2 of RFC 8017, “Public-Key Cryptography Standards
(PKCS) #1: RSA Cryptography Specifications Version 2.2”,
Elliptic curve-based key establishment schemes that meet the following:
[selection:
NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise
Key Establishment Schemes Using Discrete Logarithm Cryptography”,
Finite field-based key establishment schemes that meet the following: NIST Special
Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key Establishment
Schemes Using Discrete Logarithm Cryptography”,
Elliptic Curve Integrated Encryption Scheme (ECIES) that meets the following:
[selection:
ANSI X9.63 - Public Key Cryptography for the Financial Services Industry
Key Agreement and Key Transport Using Elliptic Curve Cryptography,
IEEE 1363a - Standard Specification for Public-Key Cryptography -
Amendment 1: Additional Techniques,
ISO/IEC 18033-2 - Information Technology - Security Techniques -
Encryption Algorithms - Part 2: Asymmetric Ciphers,
SECG SEC1 - Standards for Efficient Cryptography Group Elliptic Curve
Cryptography, section 5.1 Elliptic Curve Integrated Encryption Scheme
]
] that meets the following: [assignment: list of standards].
Application Note #5:
This is a refinement of the SFRFCS_CKM.2 to deal with key establishment rather than key
distribution.
The ST author selects all key establishment schemes used for the selected cryptographic protocols.
The RSA-based key establishment schemes are described in Section 8 of NIST SP 800-56B Revision
2 [NIST-RSA]; however, Section 8 relies on implementation of other sections in SP 800-56B Revision 2.
The elliptic curves used for the key establishment scheme correlate with the curves specified in
FCS_CKM.1/AK.
The selections in this SFR must be consistent with those for FCS_COP.1/KAT.
The TSF shall destroy cryptographic keys and keying material in accordance
with a specified cryptographic key destruction method
For volatile memory, the destruction shall be executed by a
[selection:
single overwrite consisting of
[selection: a pseudo-random pattern using the TSF’s RBG, zeroes, ones, a new value of a key, [assignment:
some value that does not contain any CSP]],
removal of power to the memory,
removal of all references to the key directly followed by a request for garbage
collection
]
For non-volatile memory
[selection:
that employs a wear-leveling algorithm, the destruction shall be executed by a
[selection:
single overwrite consisting of
[selection: zeroes, ones, pseudo-random pattern, a new value of a key of the same size, [assignment:
some value that does not contain any CSP]],
block erase
],
that does not employ a wear-leveling algorithm, the destruction shall be executed by a
[selection:
[selection: single, [assignment:
ST author-defined multi-pass]] overwrite consisting of
[selection: zeros, ones, pseudo-random pattern, a new value of a key of the same size, [assignment:
some value that does not contain any CSP]] followed by a read-verify. If the read-verification of the overwritten data fails,
the process shall be repeated again up to [assignment:
number of times to attempt overwrite] times,
whereupon an error is returned.,
block erase
]
]
that meets the following: [no standard].
Application Note #6:
A DSC must implement mechanisms to destroy cryptographic keys and key material contained in
persistent storage when no longer needed. The term “cryptographic keys” in this SFR includes
the authorization data that is the entry point to a key chain and all other cryptographic keys and
keying material (whether in plaintext or encrypted form). This SFR does not apply to the public
component of asymmetric key pairs, or to keys that are permitted to remain stored such as device
identification keys.
In the case of volatile memory, the selection “removal of all references to the key directly followed
by a request for garbage collection” is used in a situation where the TSF cannot address the
specific physical memory locations holding the data to be erased and therefore relies on
addressing logical addresses (which frees the relevant physical addresses holding the old data)
and then requesting the platform to ensure that the data in the physical addresses is no longer
available for reading (i.e. the “garbage collection” referred to in the SFR text).
Guidance documentation for the TOE requires users not to allow the TOE to leave the user’s
control while a session is active (and hence while the DEK is likely to be in plaintext in volatile
memory).
The selection for destruction of data in non-volatile memory includes block erase as an option,
and this option applies only to flash memory. A block erase does not require a read verify, since
collaborative Protection Profile for Dedicated Security Components
the mappings of logical addresses to the erased memory locations are erased as well as the data
itself.
Where different destruction methods are used for different data or different destruction situations
then the different methods and the data/situations they apply to (e.g. different points in time, or
power-loss situations) are described in the TSS (and the ST may use separate iterations of the SFR
to aid clarity). The TSS includes a table describing all relevant keys and keying material (including
authorization data) used in the implementation of the SFRs, stating the source of the data, all
memory types in which the data is stored (covering storage both during and outside of a session,
and both plaintext and non-plaintext forms of the data), and the applicable destruction method
and time of destruction in each case.
Some selections allow assignment of “some value that does not contain any CSP.” This means
that the TOE uses some specified data not drawn from an RBG meeting FCS_RBG_EXT
requirements, and not being any of the particular values listed as other selection options. The point
of the phrase “does not contain any sensitive data” is to ensure that the overwritten data is
carefully selected, and not taken from a general pool that might contain current or residual data
(e.g. SDOs or intermediate key chain values) that itself requires confidentiality protection.
FCS_CKM_EXT.4 Cryptographic Key and Key Material Destruction Timing
The TSF shall destroy all keys and keying material when no longer needed.
Application Note #7:
The DSC will have mechanisms to destroy keys, including intermediate keys and key material, by
using an approved method, FCS_CKM.4. Examples of keys include intermediate keys, leaf keys,
encryption keys, signing keys, verification keys, authentication tokens, and submasks. The DSC
will have mechanisms to destroy keys and key material contained in persistent storage when no
longer needed. Based on their implementation, vendors will explain when certain keys are no
longer needed. An example in which key is no longer necessary includes a wrapped key whose
password has changed. However, there are instances when keys are allowed to remain in memory,
for example, a device identification key.
The TSF shall generate cryptographic keys using the Key Derivation Functions defined by the following
rows of Table 4:
[selection: KeyDrv1, KeyDrv2, KeyDrv3, KeyDrv4, KeyDrv5, KeyDrv6, KeyDrv7, KeyDrv8].
Table 4: Key Derivation Functions
Application Note #8:
Note that Camellia algorithms do not support 192-bit key sizes.
The interface referenced in the requirement could take different forms, the most likely of which is
an application programming interface to an OS kernel. There may be various levels of abstraction.
For Authorization Factor Submasks, the key size to be used in the HMAC falls into a range between
L1 and L2 defined in ISO/IEC 10118 for the appropriate hash function (for example for SHA-256
L1 = 512, L2 =256) where L2 = k = L1.
General note: in order to use a NIST SP 800-108 conformant method of key derivation, the TOE
is permitted to implement this with keys as derived as indicated in Key Derivation Functions table
above, and with the algorithms as indicated in the same table.
NIST SP 800-131A Rev 1 allows the use of SHA-1 in these use cases.
KeyDrv5, KeyDrv6, and the XOR option in KeyDrv4 will create an “inverted key hierarchy” in
which the TSF will combine two or more keys to create a third key. These same KDFs may also
use a submask key as input, which could be an authorization factor or derived from a PBKDF. In
these cases the ST author must explicitly declare this option and should present a reasonable
argument that the entropy of the inputs to the KDFs will result in full entropy of the expected
output.
If keys are combined, the ST author shall describe which method of combination is used in order
to justify that the effective entropy of each factor is preserved.
The documentation of the product’s encryption key management should be detailed enough that,
after reading, the evaluator will thoroughly understand the product’s key management and how it
meets the requirements to ensure the keys are adequately protected. This documentation should
include an essay and diagrams. This documentation is not required to be part of the TSS; it can be
submitted as a separate document and marked as developer proprietary.
SP 800-56C specifies a two-step key derivation procedure that employs an extraction-thenexpansion technique for deriving keying material from a shared secret generated during a key
establishment scheme. The Randomness Extraction step as described in Section 5 of SP 800-56C
is followed by Key Expansion using the key derivation functions defined in SP 800-108.
This requirement must be claimed by the TOE if at least one of FCS_CKM.1/KEK,
FCS_CKM.1/SK, or FCS_COP.1/KeyEnc chooses a selection related to key derivation.
If at least one of KeyDrv4, KeyDrv5, or KeyDrv6 is selected AND password-based key derivation
is used to create at least one of the inputs, the selection-based SFRFCS_COP.1/PBKDF must also
be claimed.
The TSF shall perform [cryptographic hashing] in accordance with a
specified cryptographic algorithm
[selection: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA3-224, SHA3-256, SHA3-384, SHA3-512] that meets the following:
[selection: ISO/IEC 10118-3:2018, FIPS 180-4].
Application Note #9:
The hash selection should be consistent with the overall strength of the algorithm used for
signature generation. For example, the DSC should choose SHA-256 for 2048-bit RSA or ECC
with P-256, SHA-384 for 3072-bit RSA, 4096-bit RSA, or ECC with P-384, and SHA-512 for ECC
with P-521. The ST author selects the standard based on the algorithms selected.
SHA-1 may be used for the following applications: generating and verifying hash-based message
authentication codes (HMACs), key derivation functions (KDFs), and random bit/number
generation (In certain cases, SHA-1 may also be used for verifying old digital signatures and time
stamps, provided that this is explicitly allowed by the application domain).
The TSF shall perform [keyed hash message authentication] in accordance
with a specified cryptographic algorithm
[selection: HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512, KMAC128, KMAC256] and cryptographic key sizes [assignment:
key size (in bits)]
that meet the following:
[selection: ISO/IEC 9797-2:2011 Section 7 “MAC Algorithm 2”, [NIST-KDV] section 4 “KMAC”].
Application Note #10:
The HMAC key size falls into a range between L1 and L2 defined in ISO/IEC 10118 for the
appropriate hash function (for example for SHA-256 L1 = 512, L2 = 256) where L2 ≤ k ≤ L1.
The TSF shall perform [cryptographic key agreement/transport] using the supported
methods for key agreement/transport defined by the following rows of Table 5:
[selection: KAS1, KAS2, KTS-OAEP, RSAES-PKCS1-v1_5, ECDH-NIST, ECDH-BPC, DH, Curve25519, ECIES].
Table 5: Supported Methods for Key Agreement/Transport Operation
The TSF shall perform [key encryption and decryption] using the methods defined in the
following rows of Table 6:
[selection: SE1, AE1, SE2, XOR]
Table 6: Supported Methods for Key Encryption Operation
Application Note #12:
A TOE will use this requirement to specify how the Key Encryption Key (KEK) wraps a
symmetric encryption key. A TOE will always need this requirement in order to capture the last
stage of the key chain in which the Key Encryption Key (KEK) wraps the symmetric encryption
key.
If XOR is selected, the selection-based SFRFCS_CKM_EXT.5 must be claimed by the TOE.
The TSF shall perform [password-based key derivation functions] in
accordance with a specified cryptographic algorithm [HMAC-
[selection: SHA-256, SHA-384, SHA-512]], with [assignment:
integer number greater than or equal to 1000]
iterations, and output cryptographic key sizes
[selection: 128, 192, 256]bits that meet the following standard: [NIST SP 800-132].
Application Note #13:
The ST must condition a password into a string of bits prior to using it as input to algorithms that
form SKs and KEKs. The ST can perform conditioning using one of the identified hash functions
or the process described in NIST SP 800-132; the ST author selects the method used. NIST SP
800-132 requires the use of a pseudo-random function (PRF) consisting of HMAC with an
approved hash function.
Appendix A of NIST SP 800-132 recommends setting the iteration count in order to increase the
computation needed to derive a key from a password and, therefore, increase the workload of
performing a dictionary attack.
The TOE must claim this requirement if it claims FCS_CKM.1/SK and selects an algorithm in the
PBK row or claims FCS_CKM_EXT.5 and selects at least one of KeyDrv4, KeyDrv5, or KeyDrv6
AND uses password-based key derivation to create at least one of the inputs.
The TSF shall perform [digital signature generation] using the supported methods
for signature generation defined in the following rows of Table 7
[selection: SigGen1, SigGen2, SigGen3, SigGen4, SigGen5].
Table 7: Supported Methods for Signature Generation Operation
Identifier
Cryptographic Algorithm
Key Sizes
List of Standards
SigGen1
RSASSA-PKCS1-v1_5 using
[selection: SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512]
The TSF shall perform [digital signature verification] using the supported methods
for signature verification defined in the following rows of Table 8
[selection: SigVer1, SigVer2, SigVer3, SigVer4, SigVer5].
Table 8: Supported Methods for Signature Verification Operation
Identifier
Cryptographic Algorithm
Key Sizes
List of Standards
SigVer1
RSASSA-PKCS1-v1_5 using
[selection: SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512]
The TSF shall perform [data encryption/decryption] using the supported symmetric-key cryptography
methods defined in the following rows of Table 9
[selection: AES-CCM, AES-GCM, AES-CBC, AES-CTR, XTS-AES, AES-KWP, AES-KW, CAM-CBC, CAM-CCM, CAM-GCM, XTS-CAM].
Table 9: Supported Methods for Symmetric Key Cryptography Operation
AES in GCM mode with non-repeating IVs; IV length must be equal to 96
bits; the deterministic IV construction method (SP800-38D, Section 8.2.1) must
be used; the MAC length t must be one of the values
[selection: 96, 104, 112, 120, 128]
[selection: 128 bits, 192 bits, 256 bits]
ISO 18033-3 (AES)
ISO 19772, Clause 11 (GCM)
NIST SP800-38D (GCM)
AES in counter mode with a non-repeating initial counter and with no
repeated use of counter values across multiple messages with the same
secret key
[selection: 128 bits, 192 bits, 256 bits]
ISO 18033-3 (AES)
ISO 10116 (CTR)
NIST SP800-38A (CTR)
XTS-AES
AES in XTS mode with unique
[selection: consecutive non-negative integers starting at an
arbitrary non-negative integer, data unit sequence numbers] tweak values
[selection: 256 bits, 512 bits]
ISO 18033-3 (AES)
[selection: IEEE 1619, NIST SP800-38E](XTS)
Camellia in CCM mode with unpredictable, nonrepeating nonce, minimum size of 64 bits
[selection: 128 bits, 256 bits]
ISO 18033-3 (Camellia)
ISO 19772, Clause 8 (CCM)
NIST SP800-38C (CCM)
CAM-GCM
Camellia in GCM mode with non-repeating IVs; IV length must be equal to 96
bits; the deterministic IV construction method (SP800-38D, Section 8.2.1) must
be used; the MAC length t must be one of the values
[selection: 96, 104, 112, 120, 128]
[selection: 128 bits, 256 bits]
ISO 18033-3 (Camellia)
ISO 19772, Clause 11 (GCM)
NIST SP800-38D (GCM)
XTS-CAM
Camellia in XTS mode with unique
[selection: consecutive non-negative integers starting at an
arbitrary non-negative integer, data unit sequence numbers] tweak values
[selection: 256 bits, 512 bits]
ISO 18033-3 (Camellia)
[selection: IEEE 1619, NIST SP800-38E](XTS)
The TSF shall perform all deterministic random bit generation services in
accordance with ISO/IEC 18031:2011 using
[selection: Hash_DRBG (any), HMAC_DRBG (any), CTR_DRBG (AES)].
The deterministic RBG shall be seeded by at least one entropy source in
accordance with NIST SP 800-90B that accumulates entropy from
[selection: [assignment:
number of software-based sources]
software-based noise source, [assignment:
number of hardware-based sources]
hardware-based noise source] with a minimum of
[selection: 128, 192, 256] bits of entropy at least equal to the greatest security strength,
according to ISO/IEC 18031:2011, of the keys and CSPs that it will generate.
Application Note #14: ISO/IEC 18031:2011 contains three different methods of generating random numbers. Each of
these in turn depends on underlying cryptographic primitives (hash functions/ciphers). This cPP
allows SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 for Hash_DRBG or HMAC_DRBG
and only AES-based implementations for CTR_DRBG.
The TSF shall provide
[selection: mutable hardware-based, immutable hardware-based, software-based] protected storage for asymmetric private keys and
[selection: symmetric keys, persistent secrets, no other keys].
Application Note #15:
If the protected storage is implemented in software that is protected as required by
FCS_STG_EXT.2, the ST author is expected to select "software-based." If "software-based" is selected,
the ST author is expected to select all "software-based key storage" in FCS_STG_EXT.2.
Support for protected storage for all symmetric keys and persistent secrets will be required in
future revisions.
FCS_STG_EXT.1.2 The TSF shall support the capability of
[selection: importing keys/secrets into the TOE, causing the TOE to generate keys/secrets] upon request of
[selection: a client application, an administrator].
The TSF shall have the capability to allow only the user that
[selection: imported the key/secret, caused the key/secret to be generated] to use the key/secret. Exceptions
may be explicitly authorized only by
[selection: the client application, the administrator].
The TSF shall allow only the user that
[selection: imported the key/secret, caused the key/secret to be generated] to request that the key/secret be destroyed. Exceptions may
only be explicitly authorized by
[selection: the client application, the administrator].
Application Note #16:
Not all conformant TOEs will have the ability to import pre-generated keys into the TOE. In these
cases, the TOE’s ability to receive commands to perform key generation is considered to be its
implementation of the Parse service. A subject that caused a key to be generated is considered to
be the ‘owner’ of that key in the same manner as they would be if they had imported it directly.
The TSF shall encrypt [AKs, SKs, KEKs, and
[selection: long-term trusted channel key material, all software-based key storage, no other keys]] using one of the following
methods: [assignment:
key encryption methods as specified in FCS_COP.1/KeyEnc].
The TSF shall protect the integrity of any encrypted [AKs, SKs, KEKs, and
[selection: long-term trusted channel key material, all software-based key storage, no other keys]] by using
[selection:
Symmetric encryption in
[selection: AES_CCM, AES_GCM, AES_KW, AES_KWP, CAM_CCM, CAM_GCM] mode in accordance with FCS_COP.1/SKC,
A hash of the stored key in accordance with FCS_COP.1/Hash,
A keyed hash of the stored key in accordance with FCS_COP.1/HMAC,
A digital signature of the stored key in accordance with FCS_COP.1/SigGen
using an asymmetric key that is protected in accordance with FCS_STG_EXT.2,
An immediate application of the key for decrypting the protected data followed
by a successful verification of the decrypted data with previously known information
The TSF shall verify the integrity of the
[selection: hash, digital signature, MAC] of the stored key prior to use of the key.
Application Note #17:
This requirement is not applicable to derived keys that are not stored. It is not expected that a
single key will be protected from corruption by multiple of these methods; however, a product may
use one integrity-protection method for one type of key and a different method for other types of
keys.
The documentation of the product’s encryption key management should be detailed enough that,
after reading, the evaluator will thoroughly understand the product’s key management and how it
meets the requirements to ensure the keys are adequately protected. This documentation should
include an essay and diagrams. This documentation is not required to be part of the TSS – it can
be submitted as a separate document and marked as developer proprietary.
Application Note #18:
The set of operations specified in the assignment can be collectively referred to as “access.” Any
subsequent use of the term “access” should be interpreted to refer to one or more of these events.
The TSF shall enforce the [Access Control SFP] to objects based on the
following:
[subjects (defined in FDP_ACC.1.1) attempt to perform operations (defined in FDP_ACC.1.1)
against objects (defined in FDP_ACC.1.1). Subject and object attributes may be used to determine
whether the desired operations are permitted.
The following are the SFP-relevant security attributes that are associated with the subjects and
objects defined in FDP_ACC.1.1, as well as any restrictions on the attribute values:
The TSF shall enforce the following rules to determine if an operation among
controlled subjects and controlled objects is allowed: [
Any subject that has been authorized to perform any operation against any OB.P_SDO or
OB.T_SDO object can continue to perform this operation if one of the following conditions
is true:
The object’s SDO.Reauth attribute has a value of ‘none’, indicating that
reauthorization is not required for subsequent interactions with the SDO
The object’s SDO.Reauth attribute has a value of ‘each use’, indicating that reauthorization is required for each interaction with the SDO, and the subject has
supplied valid authorization data to the TOE
[assignment: rules automatically enforced by the TSF that always prohibit certain subjectobject-operation actions]
[assignment: rules automatically enforced by the TSF that always permit certain subjectobject-operation actions]
[assignment: rules automatically enforced by the TSF that conditionally permit certain
subject-object-operation actions based on subject security attributes, object security
attributes, or other conditions]
[selection: [assignment: any configurable rules or parameters that can be modified to
affect the behavior of the Access Control SFP], no configurable rules]
The TSF shall explicitly authorize access of subjects to objects based on the
following additional rules: [assignment:
rules, based on security attributes, that explicitly
authorize access of subjects to objects].
Application Note #19:
The expectation of this SFR is that the reader is given sufficient information to determine, for each
object controlled by the TOE, the operations that can be performed on it based on the subject
attempting to perform the operation, and whether this is conditional based on attribute values or
any other circumstances.
It is expected that many of the subject-object-operation combinations will always be prohibited by
the TSF, either because the target object is not externally modifiable or because the subject lacks
the ability to perform the operation in question.
The ST author is not expected to create an exhaustive list of subject-object-operation
combinations; it is sufficient to list those that are always permitted and those that are conditionally
permitted with the expectation that all remaining combinations are prohibited.
FDP_ACF.1.3 and FDP_ACF.1.4 allow the ST author to optionally specify override conditions to
resolve otherwise contradictory Access Control SFP rules. For example, the rule “S.Admin may
always modify the SDO.Conf attribute of any OB.P_SDO or OB.T_SDO object” may be
overridden by a statement in FDP_ACF.1.4 that identifies any particular SDO objects as nonmodifiable
regardless of subject authorizations.
The DSC may contain pre-installed SDOs. The DSC will enforce access control for pre-installed
SDOs like any other SDO it contains or manages.
The TSF shall propagate only SDO references, wrapped authorization data,
and wrapped SDOs such that only
[selection: the TSF, authorized users] can access them.
Application Note #20:
The “SDO reference” is a pointer to an object that resides in the TOE; this can be thought of as
a token to the object. The “only the TSF can unwrap the data” selection refers to data that is
stored outside the TOE boundary (i.e., data that has been propagated).
The TSF shall permit a factory reset of the TOE upon:
[selection: activation by external interface, presentation of [assignment:
types of authorization data
required and reference to their specification], no actions or conditions].
Application Note #21:
If the DSC provides factory reset and requires an authorization to carry out the operation then the
ST author selects either presentation of… and fills in the authorization data accepted (e.g. a PIN
or a cryptographic token based on some specification referenced in the assigned value). If the DSC
provides factory reset external to the DSC without requiring authorization then the ST author
selects activation by external interface. This selection is intended for use when the device
containing the DSC takes responsibility for obtaining and checking the authorization for factory
reset.
If any selection other than no actions or conditions is made in FDP_FRS_EXT.1.1,
the selectionbased SFRFDP_FRS_EXT.2 must be claimed.
The TSF shall support importing SDEs using
[selection: physically protected channels as specified in FTP_ITP_EXT.1, encrypted data buffers as specified in FTP_ITE_EXT.1, cryptographically protected data channels as specified in FTP_ITC_EXT.1].
The TSF shall bind SDEs to security attributes using [assignment:
list of ways
the TSF generates security attributes and binds them to the SDEs].
Application Note #22:
The way the TSF checks the integrity of the SDE depends on the method of importation. For
example, the encrypted data channel may provide data integrity as part of its service.
When a TSF parses an SDE, it should generate security attributes and create an SDO by binding
the security attributes to the SDE.
If physically protected channels as specified in FTP_ITC_EXT.1 is selected, the selection-based
SFRFTP_ITP_EXT.1 must be claimed.
If encrypted data buffers as specified in FTP_ITE_EXT.1 is selected, the selection-based SFRFTP_ITE_EXT.1 must be claimed.
If cryptographically protected data channels as specified in FTP_ITC_EXT.1 is selected, the
selection-based SFRFTP_ITC_EXT.1 must be claimed.
The TSF shall support importing SDOs using
[selection: physically protected channels as specified in FTP_ITP_EXT.1, encrypted data buffers as specified in FTP_ITE_EXT.1, cryptographically protected data channels as specified in FTP_ITC_EXT.1].
The TSF shall ensure that interpretation of the security attributes of the imported
user data is as intended by the source of the user data.
Application Note #23:
The way the TSF checks the integrity of the SDO depends on the method of importation. For
example, the encrypted data channel may provide data integrity as part of its service.
When a TSF parses an SDO, it should already have a set of security attributes. However, the TSF
may modify these attributes, if authorized, to comply with security policies on the TOE.
If physically protected channels as specified in FTP_ITC_EXT.1 is selected, the selection-based
SFRFTP_ITP_EXT.1 must be claimed.
If encrypted data buffers as specified in FTP_ITE_EXT.1 is selected, the selection-based SFRFTP_ITE_EXT.1 must be claimed.
If cryptographically protected data channels as specified in FTP_ITC_EXT.1 is selected, the
selection-based SFRFTP_ITC_EXT.1 must be claimed.
The TSF shall ensure that any previous information content of a resource is made
unavailable upon the [deallocation of the resource from]
the following objects: [
SDOs
SDEs
].
Application Note #25:
When an SDE is a key then it is also subject to the key destruction requirements in FCS_CKM.4,
depending on where and how it is stored. This SFR applies to authorization data that are SDEs
and security attributes in SDOs.
symmetric encryption using
[selection: AES-CCM, AES-GCM, AES-CBC, AES-KWP, AES-KW, CAM-CBC, CAM-CCM, CAM-GCM] as specified in FCS_COP.1/SKC,
key wrapping using
[selection: KAS1, KAS2, KTS-OAEP] as specified in FCS_COP.1/KAT
] to protect the confidentiality of authorization data
and [assignment:
list of internally and externally stored SDEs identified
in the Confidential SDE List attribute of an SDO].
The TSF shall use FCS_CKM.1/KEK to derive or generate the key to
encrypt the SDEs.
Application Note #26:
This SFR applies to confidential SDEs, especially secret and private keys, Allowed Random
Number Generators’ state data, and vendor verification reference data. This SFR also applies to
all authorization data appearing in the attribute list under SDO.AuthData as well as any
administrator authorization data which may be stored implicitly.
If the TOE stores these parameters outside of its boundary, it must encrypt them according to the
cryptographic requirements for key encryption, as required by FDP_ETC_EXT.2.
Vendor pre-installed SDOs includes both objects installed during manufacturing, and those
provisioned by the vendor before final release to customer. The administrator and no one else
owns and controls these objects.
The confidential-SDE List attribute of the SDO indicates those SDEs that require confidentiality.
If SDEs do not require confidentiality, then its omission from this list indicates that confidentiality
is not required.
FDP_SDI.2 Stored Data Integrity Monitoring and Action
Upon detection of a data integrity error, the TSF shall [
prohibit the use of the altered data
send notification of the error where applicable
].
Application Note #27:
This SFR deals with the mechanism that protects the integrity of the SDEs and security attributes
within an SDO. This provides the binding data that ensuresthe prevention of unauthorized changes
to the SDEs and attributes.
The cryptographic requirements for cryptographic hashes and digital signatures apply here.
No specific requirement is placed here on the nature of the integrity protection data, but the
Security Target shall describe this protection measure, and shall identify the iteration of
FCS_COP.1/Hash or FCS_COP.1/HMAC that covers any cryptographic algorithm used.
The integrity protection data in FDP_SDI.2.1 is included in the list of attributes identified in
FMT_MSA.1, and protects the value of the SDEs and of the SDO security attributes.
When an SDO is parsed, its integrity is checked when it is imported into the TOE.
5.1.3 Identification and Authentication
When a platform process requests the ability to create, use, modify, dispose of, etc., an SDE or
SDO within the DSC, as a matter of policy, the DSC may expect or request authorization from the
platform process, which may include authentication of the requester on whose behalf the platform
process is acting. The DSC assumes the requester to be either a person, a process, or a device. The
rules on how the requester formats the request will be outside the scope of this cPP. Upon request
(or as a matter of an established protocol), the interface (on behalf of the user) presents to the DSC
process those authorization values required to authorize execution of the event request. This may
include one or more different types of authentication credentials. The DSC validates these items
before acting upon the requested event. The validation may simply compare the authorization
values to an expected value, or perform a more complex cryptographic protocol to verify the
authenticity of the user. After validation, the DSC may then create and subsequently use an
authorization value to represent the validation of these authorization values in anticipation of future
requests.
Requirements related to the strength, quality, and performance of authorization values supplied to
the DSC, such as X.509 certificates and biometric templates, are all outside the scope of the DSC
and are expected to be met by the platform, where applicable. The DSC is only expected to enforce
quality metrics on any authorization values it generates itself.
a unique counter for
[selection: each SDO, the following SDOs [assignment:
list of SDOs]],
one global counter covering
[selection: all SDOs, the following SDOs [assignment:
list of SDOs]]
], called the failed authorization attempt counters, that counts of the number
of unsuccessful authorization attempts that occur related to authorizing access to these SDOs.
The TSF shall maintain a
[selection: static, administrator configurable variable] threshold of the minimal acceptable number of unsuccessful authorization
attempts that occur related to authorizing access to these SDOs.
When the failed authorization attempt counters
[selection: meets, surpasses] the threshold for unsuccessful authorization attempts, the TSF shall
[selection:
prevent future authorization attempts for a static prescribed amount of time,
prevent future authorization attempts for an administrator configurable amount of time,
collaborative Protection Profile for Dedicated Security Components,
prevent all future authorization attempts indefinitely (i.e., lock), as described by
FIA_AFL_EXT.2,
factory reset the TOE wiping out all non-persistent SDOs, as described by
FDP_FRS_EXT.2
The TSF shall increment the failed authorization attempt counter before it
verifies the authorization.
Application Note #28:
The product validates the authorization factors prior to determining whether user (administrator
or client application) access to the SDE/SDO is permitted. In cases where validation of the
authorization factors fails, the product will not allow access to SDE/SDO. The product validates
the authorization factors in such a way that it does not allow an attacker to circumvent the other
requirements to gain knowledge about the SDE/SDO or other keying material that protects them
from inadvertent exposure.
It is possible for the TOE to have different rules for the treatment of different SDOs or groups of
SDOs. For example, some SDOs may trigger a factory reset in the event of excessive authorization
failures while others may only temporarily block future authorization attempts. The ST author
should iterate this SFR for each distinct response the TSF can make (as defined by the selections
in FIA_AFL_EXT.1.3) and the SDOs whose authorization failures will trigger these responses.
If prevent all future authorization attempts indefinitely (i.e., lock), as described by
FIA_AFL_EXT.2 is selected in FIA_AFL_EXT.1.3, the selection-based SFRFIA_AFL_EXT.2 must
be claimed.
If factory reset the TOE wiping out all non-persistent SDOs, as described by FDP_FRS_EXT.2 is
selected in FIA_AFL_EXT.1.3, the selection-based SFRFDP_FRS_EXT.2 must be claimed.
The TSF shall provide a mechanism to generate authorization data that meet [the
following quality metrics:
For each authentication attempt, the probability shall be less than one
in 1,000,000 that a random attempt will be successful
For multiple attempts to authenticate during a one-minute period, the probability
shall be less than one in 100,000 that a series of random attempts will be successful
The TSF shall be able to enforce the use of TSF generated authorization data for
[assignment:
non-empty list of TSF functions].
Application Note #29:
This SFR expects the TSF must generate authorization data from a sufficiently large key space to
ensure that users cannot employ random guessing as a statistically plausible method of authorizing
actions within the TOE, both for a single event and over a session.
The TSF shall require each user and SDO owner to be successfully authenticated
before authorizing any otherTSF-mediated actions on behalf of that
user or SDO owner.
Application Note #30:
This SFR goes with FDP_ACF.1, which authorizes access to SDOs (i.e. authorizes operations with
or on SDOs). The security policies in FDP_ACF.1 may require authentication of the subjects and
owners of the SDOs before the TSF authorizes access to them. An authentication token is critical
data bound to a user. Such data, when presented to the TOE and successfully verified by it,
authenticates the user. The TOE may use the successful authentication of a user as an
authorization to execute an action on its behalf, or to perform a requested operation on or with an
SDO.
This requirement specifies the TSF exercise an authentication mechanism from FIA_UAU.5 by
which the TOE authenticates the identity of the user requesting the operation and the owner of the
SDO which is an object in the operation. Such authentication is necessary to authorize it to operate
with the SDOs. A user could present a unique authentication token. The TSF may accept
authentication tokens with no further conditioning. The TSF validates the authentication token
prior to granting the authorization to perform the requested operation with the SDO. The SDO
security attribute SDO.Reauth determines whether or not the TOE may authenticate the user and
the SDO owner only once or each time each time it operates with the SDO.
The means of validation may vary based on the type of authentication token.
The TSF shall provide
[selection: none, authentication token mechanism, cryptographic signature mechanism, [assignment:
list of authentication mechanisms]] to support user authentication.
The TSF shall authenticate any user’s claimed identity according to the
[selection: all subject users and SDO owners shall successfully authenticate themselves using one of the
mechanisms listed in FIA_UAU.5.1, the Prove service shall not accept "none" as an authentication method, [assignment:
rules describing how each authentication mechanism
provides authentication]]
Application Note #31:
This SFR describes the authentication mechanisms required for any user of any service as a
precondition for providing authorization to execute the service. This includes the authentication
of the owner of the SDOs of the service.
The TSF shall re-authenticate the user for access to an SDO under the conditions:
[
Re-authentication and re-authorization by further successful completion of the
authentication and authorization methods in FIA_UAU.2, in accordance with the value of
the SDO.Reauth attribute of the SDO as follows:
If SDO.Reauth has the value ‘each access’;
if SDO.Reauth has the value 'policy' and the TSF determines that the TOE satisfies
the policy for re-authentication and reauthorization
]
Application Note #32:
The allowed values for the SDO.Reauth attribute of an SDO are defined in FMT_MSA.3 and the
SDO Attributes Initialization Table. The rules in FDP_ACF.1.2 and also ensure that the need for
re-authorization has been checked before access to an SDO.
An SDO.Reauth value of ‘none’ indicates that no authentication of the subject user nor of the SDO
owners is necessary. It also indicates that no reauthorization for operations using the SDO is
necessary.
An SDO.Reauth value of policy indicates that there may be a more complicated set of
circumstances that trigger a re-auth (re-authentication of the users and owners as well as reauthorization of the operation). This could be a policy of a time limit for which a user can use an
SDO before re-authentication (e.g. 10 minutes or 24 hours). The ST should indicate the policies
allowed, and how the TOE evaluates the policies. The ST should also indicate the location of those
policies, and how the TOE protects the integrity of those policies.
When the TSF binds a user to access an SDO, this means that the TSF has authenticated the user
and that the TSF authorized the user to have the right to exercise one or more of the following
actions: generate the SDO, modify the SDO, including its security attributes, use the SDO in a
TOE operation, propagate or duplicate the SDO for use by a device external to the DSC, or destroy
the SDO. The user may not have exclusive rights to exercise the operations listed.
Policy as represented by the attributes in the SDO dictates whether or not a user must authenticate
itself in order to authorize access to the SDO.
It is possible that the attributes of some SDOs should remain unchanged, and that the attributes
of other SDOs may be changed by authorized users. If this is the case, then the ST author should
iterate this SFR and indicate in the TSS which SDOs apply to each iteration.
5.1.4 Security Management (FMT)
FMT_MOF_EXT.1 Management of Security Functions Behavior
The TSF shall enforce the [Access Control SFP] to restrict the ability to [modify]
the security attributes
[assignment:
list of security attributes, to include attributes as specified in
the Supported Methods for SDO Attributes table] to [the authorized identified roles as specified
in the Supported Methods for SDO Attributes table].
Table 10: Supported Methods for SDO Attributes
SDO Attribute
Modification Contraints
SDO.ID
Cannot be modified
SDO.Type
Cannot be modified
SDO.AuthData
[assignment:
list of roles that are authorized to
modify SDO reference authorization data]
SDO.Reauth
[assignment:
list of roles that are authorized to
` modify re-authorization conditions]
SDO.Conf
[assignment:
assignment: list of roles that are authorized to modify
confidential SDElist]
SDO.Export
[assignment:
list of roles that are authorized to modify export
flag]
SDO.Integrity
Cannot be modified by users (maintained automatically by TSF)
SDO.Bind
Cannot be modified by users (maintained automatically by TSF)
Application Note #33:
The SDO Attributes Modification Table defines the required constraints on security attribute
modification. The Security Target completes the other parts not specified here (along with any
other information for other security attributes relevant to a particular TOE).
The assignments of authorized subjects in the SDO Attributes Modification Table may be defined
by the ST author in terms of roles or in terms of an action such as presentation of a valid
authentication token of a particular type (in this case the ST author identifies in an Application
Note the other SFRs that govern the action).
The TSF vendor may pre-install SDOs with default attributes. The Security Target should make
clear which attributes the administrators may change or are prohibited from changing. It should
also make clear between authorization values required to use pre-installed SDOs and
authorization values required to change the attributes of pre-installed SDOs.
The SDO Attributes Modification Table lists SDO ID as “cannot be modified”. In some cases, a
change in the attributes may cause a change in the SDO ID. In these cases, a change in the SDO
ID causes the creation of a new SDO and possibly the loss of the old SDO.
Only authorized subjects can change the attributes of an SDO, and only as permitted in the SDO
Attributes Modification Table.
FMT_MSA.3 Static Attribute Initialization
This SFR deals with the initialization of the attributes of an SDO when it is created by parsing or
provisioning. The generation process includes SDOs created by the TSF (provisioned) and those
imported via FDP_ITC_EXT.2 (parsed).
The TSF is expected to give an SDO a set of security attributes at the time of its creation. This set
is expected to include at least the following attributes:
SDO identifier
SDO type
SDO reference authorization data (i.e. the data that is used when determining whether to
grant access to an SDO, for each relevant mode of access, on the basis of an authorization
token presented to the DSC)
Re-authorization conditions (i.e. event after which re-authorization is required)
Confidential-SDE list (each SDE in this list is held encrypted when the SDO is stored)
Export Flag (indicating whether the SDO is allowed to be propagated)
Integrity protection data
Binding Data (created by the TOE to strongly link or associate the SDO with other entities
such as the TOE itself or with other SDOs in a hierarchy such as a child to a parent).
The TSF provides the capability to protect the contents of an SDO (i.e. the set of its SDEs together
with the SDO attributes) from unauthorized modification. The DSC shall check for such
modifications before using the SDO or any of its SDEs.
The TSF shall enforce the [Access Control SFP] to provide
[selection: restrictive, permissive, [assignment:
other property]]
default values for security attributes that are used to enforce the SFP.
The TSF shall allow the [authorized identified roles, according to the Supported
Methods for SDO Attributes Initialization table] to specify alternative initial values to override the
default values when an object or information is created.
Table 11: Supported Methods for SDO Attributes Initialization
SDO Attribute
Property
Authorized Override Role
Initialization Method
Allowed Values
SDO.ID
Restrictive
None
Import and generation process
[assignment:
range of allowed values]
SDO.Type
Restrictive
None
Import and generation process
[assignment:
list of allowed types]
SDO.AuthData
Permissive
[selection: admin, client application]
Import process
[selection: none, [assignment:
list of types of authentication tokens allowed], [assignment:
range of authorization values allowed]]
Restrictive
None
Generation process
SDO.Reauth
Restrictive
None
Import and generation process
[selection: none, each access, policy]
SDO.Conf
Restrictive
None
Import and generation process
[assignment:
list of SDEs of which the TOE must provide a confidentiality service]
SDO.Export
Restrictive
None
Import and generation process
[selection: exportable, non-exportable]
SDO.Integrity
Restrictive
None
Import and generation process
[assignment:
range of allowed values]
SDO.Bind
Restrictive
None
Import and generation process
[assignment:
range of allowed values]
Application Note #34:
Both admin and client application roles can initiate the import process. The imported object
contains the default values for each attribute, where allowed. The TSF can override default values
for the following attributes of imported objects: SDO.ID, SDO.Type, SDO.Reauth, SDO.Export,
and SDO.Integrity. The TSF may override default values in these cases to force the objects to
comport to established structures within the TOE, or to comply with TOE-wide security policies.
In these cases, the defined roles (i.e. admin and client application) cannot override the default
values. For SDO.AuthData, the TSF shall allow user roles (i.e. admin and client applications) to
override authorization data that may arrive with the object. For SDO.Conf the TSF accepts the
imported value for this attribute. SDO.Bind is explained below.
Unless otherwise noted, both admin and client application roles can initiate the generation
process. The admin and client application will provide the default values for the attributes. This
SFR assumes the TSF checks SDO.Type, SDO.AuthData, SDO.Reauth, SDO.Conf, and
SDO.Export for compliance with established security policies and refuses to create objects which
do not comply and thus will not override the value of any of these attributes. In the cases of the
SDO.ID and SDO.Integrity, the TSF generates these values and therefore there is no need to
override.
In the case of SDO.Bind for both import and generation processes, the TSF may override values
that denote a binding to the TOE, but it should not override values that denote a binding to other
keys. In the case of the import process, the defined roles cannot override the default values for any
binding.
The SDO Attributes Initialization Table is referenced from FMT_MSA.3 and matches the attributes
covered by FMT_MSA.1 (which defines controls on the modification of the attributes). The
initialization of these security attributes occurs when an SDO is either parsed by the TOE or
generated on the TOE. The required constraints on security attribute initialization specified in this
PP are shown in Table 11; the Security Target completes the selection and assignments in the SFR
and adds to the table any other information for other security attributes relevant to a particular
TOE.
The SDO.AuthData attribute is data that is required in order to validate authorization of a subject
to access the SDO (in each of the modes relevant to that SDO). The nature of this data will depend
on the authorization mechanism used in the TOE, as described in FIA_UAU.2.
The SDO.Reauth attribute for an individual SDO takes one of the values defined in the selection
in the Allowed Values column of Table 11. Examples of TOE-specified events might be explicit
revocation of authorization by a user, expiry of a time interval, or completion of a fixed number of
uses since the last authorization. The re-authorization conditions are used in FIA_UAU.6 and
FDP_ACF.1. These determine whether a single authorization by the SDO owner will allow any
number of uses of the SDO until the end of the user’s session (value ‘none’), or whether each use
of the SDO must be individually authorized (value ‘each access’), or whether re-authorization
must happen each time one of the TOE-specified events occurs.
The SDO.Conf attribute indicates which SDEs, if any, the TOE should encrypt when not in
operational use. The TOE should use the methods in FCS_COP.1/SKC, FCS_STG_EXT.1, or
FCS_STG_EXT.2 to protect the SDEs in this list.
The SDO.Export attribute takes one of the values ‘exportable’ or ‘non-exportable’.
The SDO.Integrity attribute includes evidence that the TSF can use to protect and verify the
integrity of the SDO.
Attributes assigned by the TOE to any parsed SDOs must be described in the Security Target and
in operational user guidance.
The TOE uses the Binding Data for an SDO to strongly link the SDO to the TOE, a parent SDO in
a hierarchy, or to nothing at all. SDOs bound to nothing may freely travel from one TOE to another
without restrictions. If bound to another SDO as a child to a parent in a hierarchy, it may travel
only where the parent SDO travels. If bound to the TOE, it may travel to any other TOE for any
reason, even if the TOE moves its parent to another TOE. Note that vendors will initialize attributes
of pre-installed SDOs with default values. However, authorization values to change the attributes
of pre-installed SDOs may differ from the authorization value required to use the pre-installed
SDO.
The vendor should document the implicit attributes for pre-installed SDOs and SDOs stored in
special locations.
In cases in which the SDO ID is a cryptographic hash of the attributes and SDEs, that value
represents both the ID and projects the integrity of the SDO, including the SDEs. As the TOE
unwraps an incoming SDO, it may automatically check the integrity. For pre-installed SDOs in
protected storage, the hardware plus the TSF projects the integrity of them.
When a remote peer sends an SDO to the TOE, it properly indicates through the SDEconfidentiality list of any authorization values and authentication tokens present in the SDO,
whether they are present in the SDE or as attributes, which control access to the SDE.
When a TOE generates an SDO internally for the first time, it properly indicates through the SDEconfidentiality list any SDEs that are authorization values or authentication tokens. Similarly, if
any of the attributes are authorization values or authentication tokens, the TOE will properly
indicate through the SDE-confidentiality list that it will encrypt them prior to storing them.
The TOE may contain pre-installed SDOs or SDOs either provisioned the first time the user turns
on the TOE or provisioned as the result of a “factory reset” event. TSFs may refer to such
persistent SDOs as root keys or trusted anchors. Pre-installed SDOs may reside in immutable
hardware and persist across factory resets. Other persistent SDOs may persist until a user issues
a “factory reset” which either cryptographically erases the SDOs or overwrites them by
provisioning new ones. These SDOs may not contain a confidential SDE list since either these
persistent values serve as a root encryption key for a hierarchy of SDOs, or they serve as a KDF
seed for generating root encryption keys for a hierarchy of SDOs.
It is possible that the default attributes of some SDOs should be restrictive, and that the default
attributes of other SDOs may be permissive. If this is the case, then the ST author should iterate
this SFR and indicate in the TSS what the default attribute properties are for each SDO.
unlock access to SDO following excessive failed authorization attempts,
no other functions
]
.
Application Note #35:
If FDP_MFW_EXT.1 selects mutable firmware, then FMT_SMF.1 must select
Update TOE firmware and pre-installed SDOs.
Recall that resetting a TOE to factory state also wipes all user data, but may not
wipe out preinstalled SDOs. Configuring authorization policies includes setting policies
for allowed access to SDOs.
Protections for pre-installed SDEs/SDOs come through the firmware, and by extension, through
firmware updates. In the same vein, the authorized updates may also affect the SDEs as well, if the
vendor so chooses. One could say that the authorized update binds the attributes present in the
functionality of the firmware to the pre-installed SDEs.
The TSF shall preserve a secure state when the following types of failures occur:
[fault injections].
Application Note #37:
Note that a secure state does not imply the uninterrupted enforcement of all claimed security
functionality it is appropriate for the TSF to “fail closed” and block the execution of
securityrelevant behavior if a fault injection attempt or other significant glitch occurs.
Application Note #38:
‘Debug modes’ may include, but are not limited to, any alternate mode of operation, such
as developer mode, test mode, manufacturer mode, or altered boot mode.
The TSF shall resist [data extraction via fault injection, extreme temperatures,
abnormal voltage] to the [TSF storage elements that contain
[selection: SDEs, SDOs, firmware]] by responding automatically such that the SFRs are always enforced.
Application Note #39:
Physical protection mechanisms as envisioned by this requirement are mechanisms that protect
communications to the extent that encryption or other logical protections are not required to
ensure confidentiality, integrity, and assured identification of endpoints. Such mechanisms may
include, for example, physically isolated traces, or mechanisms that take advantage of physical
properties of signals to ensure that communications are receivable only by the intended endpoint.
Any physical external casing or potting material of the TOE is considered an ‘external interface’,
not just those interfaces over which data is transmitted. This ensures that the TSF will respond
appropriately if, for example, an attacker penetrates the physical surface of the DSC in an attempt
to access its stored data.
The TOE’s protection against abnormal temperature and voltage can be considered equivalent to
what is required by assertion AS07.77 of [ISO-TR].
The TSF shall contain an SDO that contains the identity of the Root of Trust.
Application Note #40:
Every DSC is expected to have a single RoT that comprises the DSC hardware and pre-installed
SDOs, from which services (e.g. Storage, Authorization, etc.) can be offered.
Depending on the use case and the way status registers are used, unique identity keys may be
bound to the TOE, the TOE platform, or both.
The sole presence of unique identity keys linking to the RoT does not prove authenticity without
the use of digital signatures.
The TSF shall maintain Root of Trust data as
[selection: immutable, mutable if and only if its mutability is controlled by a unique identifiable owner].
Application Note #41:
One expects that only authorized sources can modify the single RoT, such as through a secure
update. A pre-installed SDO may contain the identity of the manufacturer of the RoT.
The process of authenticating the source of a secure update may involve querying the identity of
the manufacturer, contained on a pre-installed SDO. If this identity is in the form of an X.509
certificate containing a signature verification key signed by the manufacturer, then the
authentication process is sufficient.
A unique identifiable owner is assumed to be one with an administrative role; however, there may
be circumstances where the owner does not take on an administrative role, which should be
documented.
The TSF shall provide a Root of Trust for Storage, a Root of Trust for
Authorization, and
[selection: Root of Trust for Measurement, Root of Trust for Reporting, no others].
Application Note #42:
This document uses the [GP_ROT] definitions for RoT for Storage (denoted as the combination of
RoT for Confidentiality and RoT for Integrity), Authorization, Measurement, and Reporting. DSCs
use Roots of Trust for Storage to protect SDOs. Section 6.5 has a number of requirements for
ensuring the TSF has functionality to authorize a user in order to access an SDO, including
FIA_UAU.6.
If both Root of Trust for Measurement and Root of Trust for Reporting are selected in
FPT_ROT_EXT.1.1, the selection-based SFR FDP_DAU.1/Prove must also be claimed.
The TSF shall prevent unauthorized access to SDOs associated with the
Root of Trust for Storage.
Application Note #43:
TOEs may use shielded locations or cryptographic protections to prevent unauthorized access to
SDOs. Use FDP_SDI.2 to protect the integrity of SDOs stored in the RoT for Storage.
The TSF shall have a mechanism for preventing replay of user authorization
of operations on SDOs using the following methods
[selection: monotonic counters, random nonces, [assignment:
other methods as specified]].
The TSF shall deny the requested operation on the SDO when it detects a replay.
Application Note #44:
The TSF receives authorization from an external source to the DSC to perform an operation on
an SDO. If the operation on the SDO is restricted to authorized users, then anyone observing the
communication to the DSC can copy the authorization and replay it. Random nonces and
monotonic counters are but two mechanisms the TSF can use to mitigate replay. In this
requirement, operations on SDOs include generating, using, modifying, propagating, and
destroying. Besides monotonic counters and random nonces, the TSF could employ other methods
to prevent replay of user authorizations, which the Security Target should describe.
This requirement does not specify how TSF detects replays.
The TSF shall be able to provide reliable time stamps.
Application Note #45:
It is acceptable for the TSF to provide timestamp data either through an internal clock or a
counter. It is also permissible for the TSF to obtain time data from a clock contained within the
same physical enclosure as the TOE.
The TSF shall run a suite of self tests during power-on start-up,
[selection: periodically during normal operation, at the request of the authorized user, at no other condition, at the conditions
[assignment:
conditions under which self test should occur]
] to demonstrate the correct operation of [the TSF].
The TSF shall provide authorized users with the capability to verify the integrity of
the [TSF].
Application Note #46:
This requirement intends to cover integrity of the TSF functionality (i.e. runtime checks).
TSF integrity testing provides the ability to test the TSF’s correct operation. These tests are
expected to be performed automatically and autonomously at start-up but may also be performed
periodically during operation, at the request of the authorized user, or when other conditions are
met. It also provides the ability to verify the integrity of TSF data and executable code.
All cryptographic functions come with known answer tests (KATs). In addition to verifying the
integrity of the firmware executing the TSF, the DSC should also verify the integrity of any data
associated with the TSF (such as constants for cryptographic algorithms) as well as performing
the KATs.
The TSF shall ensure the operation of [protection of TSF data] when the following
failures occur: [fault injection].
Application Note #47: TSF data may be protected in response to a fault injection either by providing a method to ensure
that the data remains protected or by logically destroying the data or any part of a key change
that encrypts it. This behavior may differ based on the type of fault.
5.1.7 TOE Security Functional Requirements Rationale
The following rationale provides justification for each security objective for the TOE,
showing that the SFRs are suitable to meet and achieve the security objectives:
The Security Objectives in Section 4 Security Objectives were constructed
to address threats identified in
Section 3.1 Threats. The Security Functional Requirements (SFRs)
in Section 5.1 Security Functional Requirements are a formal instantiation of the Security Objectives. The PP
identifies the Security Assurance Requirements (SARs) to frame the extent to
which the evaluator assesses the documentation applicable for the evaluation and performs
independent testing. This section lists the set of SARs from CC part 3
that are required in evaluations against this PP. Individual Assurance Activities
o be performed are specified both in
Section 5.1 Security Functional Requirements as well as in this section.
The general model for evaluation of OSs against STs written to conform to this PP is as follows:
After the ST has been approved for evaluation, the TSEF will obtain the
OS, supporting environmental IT, and the administrative/user guides for
the OS. The ITSEF is expected to perform actions mandated by the Common Evaluation
Methodology (CEM) for the ASE and ALC SARs. The ITSEF also performs the Assurance Activities
contained within Section 5.1 Security Functional Requirements, which are intended to be an interpretation of the
other CEM assurance requirements as they apply to the specific technology instantiated in the
OS. The Assurance Activities that are captured in Section 5.1 Security Functional Requirements also provide
clarification as to what the developer needs to provide to demonstrate the OS is compliant
with the PP.
The information about the OS is contained in the guidance documentation available to the end user as
well as the TSS portion of the ST. The OS developer must concur with the description of the product that is
contained in the TSS as it relates to the functional requirements. The Assurance Activities
contained in Section 5.1 Security Functional Requirements should provide the ST authors with
sufficient information to determine the appropriate content for the TSS section.
The
functional specification describes the TSFIs. It is not
necessary to have a formal or complete specification of these interfaces. Additionally,
because OSs conforming to this PP will necessarily have interfaces to
the Operational Environment that are not directly invokable by OS
users, there is little point specifying that such interfaces be described in and of
themselves since only indirect testing of such interfaces may be possible. For this PP,
the activities for this family should focus on understanding the interfaces presented in
the TSS in response to the functional requirements and the interfaces
presented in the AGD documentation. No additional “functional specification” documentation
is necessary to satisfy the assurance activities specified. The interfaces that need to be
evaluated are characterized through the information needed to perform the assurance
activities listed, rather than as an independent, abstract list.
The developer shall provide a tracing from the functional specification to the
SFRs.
Application Note #48: As indicated in the introduction to this section, the
functional specification is comprised of the information contained in the AGD_OPE and
AGD_PRE documentation. The developer may reference a website accessible to application
developers and the evaluator. The assurance activities in the functional requirements
point to evidence that should exist in the documentation and TSS
section; since these are directly associated with the SFRs, the tracing in element
ADV_FSP.1.2D is implicitly already done and no additional documentation is
necessary.
There are no specific assurance activities associated with these SARs, except
ensuring the information is provided. The functional specification documentation is
provided to support the evaluation activities described in Section 5.1 Security Functional Requirements, and
other activities described for AGD, ATE, and AVA SARs. The requirements on the content
of the functional specification information is implicitly assessed by virtue of the
other assurance activities being performed; if the evaluator is unable to perform an
activity because there is insufficient interface information, then an adequate
functional specification has not been provided.
5.2.3 Class AGD: Guidance Documentation
The guidance documents will be
provided with the ST. Guidance must include a description of how the IT
personnel verifies that the Operational Environment can fulfill its role for the security
functionality. The documentation should be in an informal style and readable by the IT
personnel. Guidance must be provided for every operational environment that the product
supports as claimed in the ST. This guidance includes instructions to
successfully install the TSF in that environment; and Instructions to
manage the security of the TSF as a product and as a component of the
larger operational environment. Guidance pertaining to particular security functionality is
also provided; requirements on such guidance are contained in the assurance activities
specified with each requirement.
The developer shall provide operational user guidance.
Application Note #49: The operational user guidance does not have to be contained in a
single document. Guidance to users, administrators and application developers can be
spread among documents or web pages.
Rather than repeat information here, the developer should
review the assurance activities for this component to ascertain the specifics of the
guidance that the evaluator will be checking for. This will provide the necessary
information for the preparation of acceptable guidance.
The operational user guidance shall describe, for each user role, the
user-accessible functions and privileges that should be controlled in a secure
processing environment, including appropriate warnings.
Application Note #50: User and administrator are to be considered in the definition
of user role.
The operational user guidance shall describe, for each user role, the available
functions and interfaces, in particular all security parameters under the control of
the user, indicating secure values as appropriate.
Application Note #51:
This portion of the operational user guidance should be presented
in the form of a checklist that can be quickly executed by IT personnel (or end-users,
when necessary) and suitable for use in compliance activities.
When possible, this guidance is to be expressed in the eXtensible Configuration
Checklist Description Format (XCCDF) to
support security automation.
Minimally, it should be presented in a structured
format which includes a title for each configuration item,
instructions for achieving the secure configuration, and any relevant rationale.
The operational user guidance shall, for each user role, clearly present each
type of security-relevant event relative to the user-accessible functions that need to
be performed, including changing the security characteristics of entities under the
control of the TSF.
The operational user guidance shall identify all possible modes of operation of
the OS (including operation following failure or operational
error), their consequences, and implications for maintaining secure operation.
The operational user guidance shall, for each user role, describe the security
measures to be followed in order to fulfill the security objectives for the
operational environment as described in the ST.
Some of the contents of the operational guidance are verified by the
assurance activities in Section 5.1 Security Functional Requirements and evaluation of the OS according to the [CEM]. The following additional
information is also required. If cryptographic functions are provided by the OS, the operational guidance shall contain instructions for configuring
the cryptographic engine associated with the evaluated configuration of the OS. It shall provide a warning to the administrator that use of other
cryptographic engines was not evaluated nor tested during the CC evaluation of the
OS. The documentation must describe the process for verifying
updates to the OS by verifying a digital signature – this may be
done by the OS or the underlying platform. The evaluator will
verify that this process includes the following steps: Instructions for obtaining the
update itself. This should include instructions for making the update accessible to
the OS (e.g., placement in a specific directory). Instructions for
initiating the update process, as well as discerning whether the process was
successful or unsuccessful. This includes generation of the hash/digital signature.
The OS will likely contain security functionality that does not
fall in the scope of evaluation under this PP. The operational guidance shall make it
clear to an administrator which security functionality is covered by the evaluation
activities.
The developer shall provide the OS, including its preparative
procedures.
Application Note #52: As with the operational guidance, the developer should look to
the assurance activities to determine the required content with respect to preparative
procedures.
The preparative procedures shall describe all the steps necessary for secure
acceptance of the delivered OS in accordance with the developer's
delivery procedures.
The preparative procedures shall describe all the steps necessary for secure
installation of the OS and for the secure preparation of the
operational environment in accordance with the security objectives for the operational
environment as described in the ST.
As indicated in the introduction above, there are significant expectations
with respect to the documentation—especially when configuring the operational
environment to support OS functional requirements. The evaluator
shall check to ensure that the guidance provided for the OS
adequately addresses all platforms claimed for the OS in the ST.
5.2.4 Class ALC: Life-cycle Support
At the assurance level provided
for OSs conformant to this PP, life-cycle support is limited to end-user-visible aspects of
the life-cycle, rather than an examination of the OS vendor’s development and configuration
management process. This is not meant to diminish the critical role that a developer’s
practices play in contributing to the overall trustworthiness of a product; rather, it is a
reflection on the information to be made available for evaluation at this assurance level.
ALC_CMC.1 Labeling of the TOE (ALC_CMC.1)
This component is
targeted at identifying the OS such that it can be distinguished from
other products or versions from the same vendor and can be easily specified when being
procured by an end user.
The evaluator will check the ST to ensure that it contains
an identifier (such as a product name/version number) that specifically identifies the
version that meets the requirements of the ST. Further, the
evaluator will check the AGD guidance and OS samples received for
testing to ensure that the version number is consistent with that in the ST. If the vendor maintains a web site advertising the OS, the evaluator will examine the information on the web site to
ensure that the information in the ST is sufficient to distinguish
the product.
ALC_CMS.1 TOE CM Coverage (ALC_CMS.1)
Given the scope of the OS and its associated evaluation
evidence requirements, this component’s assurance activities are covered
by the assurance activities listed for ALC_CMC.1.
The "evaluation evidence required by the SARs" in this PP is limited to the
information in the ST coupled with the guidance provided to
administrators and users under the AGD requirements. By ensuring that the OS is specifically identified and that this identification is
consistent in the ST and in the AGD guidance (as done in the
assurance activity for ALC_CMC.1), the evaluator implicitly confirms the information
required by this component. Life-cycle support is targeted aspects of the developer’s
life-cycle and instructions to providers of applications for the developer’s devices,
rather than an in-depth examination of the TSF manufacturer’s
development and configuration management process. This is not meant to diminish the
critical role that a developer’s practices play in contributing to the overall
trustworthiness of a product; rather, it’s a reflection on the information to be made
available for evaluation. The evaluator will ensure that the developer has
identified (in guidance documentation for application developers concerning the
targeted platform) one or more development environments appropriate for use in
developing applications for the developer’s platform. For each of these development
environments, the developer shall provide information on how to configure the
environment to ensure that buffer overflow protection mechanisms in the environment(s)
are invoked (e.g., compiler and linker flags). The evaluator will ensure that this documentation
also includes an indication of whether such protections are on by default, or have to
be specifically enabled. The evaluator will ensure that the TSF is
uniquely identified (with respect to other products from the TSF
vendor), and that documentation provided by the developer in association with the
requirements in the ST is associated with the TSF
using this unique identification.
ALC_TSU_EXT.1 Timely Security Updates
This component requires the
OS developer, in conjunction with any other necessary parties, to provide information as
to how the end-user devices are updated to address security issues in a timely manner. The
documentation describes the process of providing updates to the public from the time a
security flaw is reported/discovered, to the time an update is released. This description
includes the parties involved (e.g., the developer, carriers(s)) and the steps that are
performed (e.g., developer testing, carrier testing), including worst case time periods,
before an update is made available to the public.
The developer shall provide a description in the TSS of how users are notified
when updates change security properties or the configuration of the product.
The description shall include the mechanisms publicly available for reporting
security issues pertaining to the OS.
Application Note #54: The reporting mechanism could include web sites, email addresses, as well as a
means to protect the sensitive nature of the report (e.g., public keys that could be
used to encrypt the details of a proof-of-concept exploit).
The evaluator will verify that the TSS contains a description of the timely
security update process used by the developer to create and deploy security updates.
The evaluator will verify that this description addresses the entire application. The
evaluator will also verify that, in addition to the OS developer’s process, any
third-party processes are also addressed in the description. The evaluator will also
verify that each mechanism for deployment of security updates is described. The
evaluator will verify that, for each deployment mechanism described for the update
process, the TSS lists a time between public disclosure of a vulnerability and public
availability of the security update to the OS patching this vulnerability, to include
any third-party or carrier delays in deployment. The evaluator will verify that this
time is expressed in a number or range of days. The evaluator will verify that
this description includes the publicly available mechanisms (including either an email
address or website) for reporting security issues related to the OS. The evaluator
shall verify that the description of this mechanism includes a method for protecting
the report either using a public key for encrypting email or a trusted channel for a
website.
5.2.5 Class ATE: Tests
Testing is specified for functional aspects of
the system as well as aspects that take advantage of design or implementation weaknesses.
The former is done through the ATE_IND family, while the latter is through the AVA_VAN
family. At the assurance level specified in this PP, testing is based on advertised
functionality and interfaces with dependency on the availability of design information. One
of the primary outputs of the evaluation process is the test report as specified in the
following requirements.
Testing is performed to confirm the
functionality described in the TSS as well as the administrative
(including configuration and operational) documentation provided. The focus of the testing
is to confirm that the requirements specified in Section 5.1 Security Functional Requirements being met,
although some additional testing is specified for SARs in Section 5.2 Security Assurance Requirements. The
Assurance Activities identify the additional testing activities associated with these
components. The evaluator produces a test report documenting the plan for and results of
testing, as well as coverage arguments focused on the platform/OS
combinations that are claiming conformance to this PP. Given the scope of the OS and its associated evaluation evidence requirements, this component’s
assurance activities are covered by the assurance activities listed for ALC_CMC.1.
The evaluator will prepare a test plan and report documenting the testing
aspects of the system, including any application crashes during testing. The evaluator
shall determine the root cause of any application crashes and include that information
in the report. The test plan covers all of the testing actions contained in the
[CEM] and the body of this PP’s Assurance Activities. While it is
not necessary to have one test case per test listed in an Assurance Activity, the
evaluator must document in the test plan that each applicable testing requirement in
the ST is covered. The test plan identifies the platforms to be
tested, and for those platforms not included in the test plan but included in the
ST, the test plan provides a justification for not testing the
platforms. This justification must address the differences between the tested
platforms and the untested platforms, and make an argument that the differences do not
affect the testing to be performed. It is not sufficient to merely assert that the
differences have no affect; rationale must be provided. If all platforms claimed in
the ST are tested, then no rationale is necessary. The test plan
describes the composition of each platform to be tested, and any setup that is
necessary beyond what is contained in the AGD documentation. It should be noted that
the evaluator is expected to follow the AGD documentation for installation and setup
of each platform either as part of a test or as a standard pre-test condition. This
may include special test drivers or tools. For each driver or tool, an argument (not
just an assertion) should be provided that the driver or tool will not adversely
affect the performance of the functionality by the OS and its
platform. This also includes the configuration of the cryptographic engine to be
used. The cryptographic algorithms implemented by this engine are those specified by
this PP and used by the cryptographic protocols being evaluated (IPsec, TLS). The test
plan identifies high-level test objectives as well as the test procedures to be
followed to achieve those objectives. These procedures include expected results.
The test report (which could just be an annotated version of the test plan) details
the activities that took place when the test procedures were executed, and includes
the actual results of the tests. This shall be a cumulative account, so if there was a
test run that resulted in a failure; a fix installed; and then a successful re-run of
the test, the report would show a “fail” and “pass” result (and the supporting
details), and not just the “pass” result.
5.2.6 Class AVA: Vulnerability Assessment
For the first generation of
this protection profile, the evaluation lab is expected to survey open sources to discover
what vulnerabilities have been discovered in these types of products. In most cases, these
vulnerabilities will require sophistication beyond that of a basic attacker. Until
penetration tools are created and uniformly distributed to the evaluation labs, the
evaluator will not be expected to test for these vulnerabilities in the OS. The labs will be expected to comment on the likelihood of these vulnerabilities given
the documentation provided by the vendor. This information will be used in the development
of penetration testing tools and for the development of future protection profiles.
The evaluator shall perform a search of public domain sources to identify
potential vulnerabilities in the OS.
Application Note #56: Public domain sources include the Common Vulnerabilities
and Exposures (CVE) dictionary for publicly-known vulnerabilities. Public domain
sources also include sites which provide free checking of files for viruses.
The evaluator shall conduct penetration testing, based on the identified
potential vulnerabilities, to determine that the OS is resistant to
attacks performed by an attacker possessing Basic attack potential.
The evaluator will generate a report to document their
findings with respect to this requirement. This report could physically be part of the
overall test report mentioned in ATE_IND, or a separate document. The evaluator
performs a search of public information to find vulnerabilities that have been found
in similar applications with a particular focus on network protocols the application
uses and document formats it parses.
The evaluator documents the sources consulted and
the vulnerabilities found in the report.
For each vulnerability found, the evaluator
either provides a rationale with respect to its non-applicability, or the evaluator
formulates a test (using the guidelines provided in ATE_IND) to confirm the
vulnerability, if suitable. Suitability is determined by assessing the attack vector
needed to take advantage of the vulnerability. If exploiting the vulnerability
requires expert skills and an electron microscope, for instance, then a test would not
be suitable and an appropriate justification would be formulated.
Appendix A - Optional Requirements
As indicated in the introduction to this , the baseline requirements (those that must be
performed by the TOE) are contained in the body of this .
This appendix contains three other types of optional requirements that may be included in the ST, but are not required in order
to conform to this .
However, applied modules, packages and/or use cases may refine specific requirements as mandatory.
The first type ( A.1 Strictly Optional Requirements
) are strictly optional requirements that are independent of the
TOE implementing any function.
If the TOE fulfills any of these requirements or supports a certain functionality, the vendor is encouraged to include the SFRs
in the ST, but are not required in order to conform to this .
The second type ( A.2 Objective Requirements
) are objective requirements that describe security functionality not yet
widely available in commercial technology.
The requirements are not currently mandated in the body of this , but will be included in
the baseline requirements in future versions of this . Adoption by vendors is
encouraged and expected as soon as possible.
The third type ( A.3 Implementation-based Requirements
)
are dependent on the TOE implementing a particular function.
If the TOE fulfills any of these requirements, the vendor must either add the related SFR or disable the functionality for the
evaluated configuration.
The TSF shall provide an interface to allow external seeding of the DRBG
with a bit-string of at least the minimum number of bits selected in FCS_RBG_EXT.1.2 before
the DRBG produces any output.
A.1.2 Protection of the TSF
FPT_ITT.1 Basic Internal TSF Data Transfer Protection
The TSF shall protect TSF data from [disclosure] and
[selection: modification, no other actions] when it is transmitted between separate parts of the TOE.
The TSF shall be able to quantify the integrity of the data protected by the
TOE by generating integrity measurements and assertions making them available to authorized
entities.
Application Note #57:
The generation of these integrity measurements and assertions is the creation of OB.Pstate.
Data protected by the TOE includes DSC firmware, DSC configuration data, and user data. DSC
configuration data may include persistent SDEs or SDOs such as immutable or mutable root keys,
authorization values, and authentication tokens (i.e. DSC.ID, OB.P_SDO, OB.FAACntr,
OB.AntiReplay, and OB.Context). User data may include transient SDEs and SDOs as well as
authorization values and authentication tokens bound to these SDEs and SDOs (i.e. OB.T_SDO).
Integrity reporting is the process of attesting to integrity measurements (including those recorded
in status registers in a DSC).
The TSF shall accumulate platform characteristics using a consistent
[assignment:
description of process for accumulating platform characteristics]
process in which verified quantifiable measurements are accumulated to prove the integrity
of its SDOs.
Application Note #58:
Although a platform may enter any state possible—including undesirable or insecure states—it
can use platform characteristics, including integrity measurements and assertions, along with
logging and reporting to accurately report the state derived from data attributing to those states.
In this context, platform characteristics can include, but is not limited to, cryptographic hashes of
binary data, security-critical configurations, register values (including status registers) and
milestones, such as verification of firmware, or transitioning from a boot phase to an operational
phase. A platform characteristic may also represent the state of some entity outside the DSC. A
process independent from the DSC or the host containing the DSC may evaluate the platform
characteristics and determine an appropriate action.
FPT_ROT_EXT.3 Root of Trust for Reporting Mechanisms
The TSF shall be able to attest to a state as represented by platform
characteristics with a Root of Trust for Reporting mechanism that uses for its identity
[selection: a cryptographically verifiable identity in FPT_PRO_EXT.1, an alias key bound to the cryptographically verifiable identity in FPT_PRO_EXT.1] and using a signature algorithm as specified in FCS_COP.1/SigGen.
Application Note #59:
While it is possible for a group of components to share a single unique group identifier, it is
important to ensure that individual components have their own unique identifiers relative to each
other.
Resident keys or aliases are designed such that they are never visible outside the subset of DSC
scope containing the RoT services and are only to be used for encryption. Therefore, possession
of such aliases or keys can only be proved indirectly by using it to decrypt a value that has been
encrypted with a corresponding public key. In this way, these resident keys or aliases can provide
for authentication based on decryption operations instead of producing a digital signature.
If non-specialized cryptographic keys used for algorithms in FCS_COP is selected, it is expected
that when used in the context of the RoT for Reporting, these keys are not visible to full DSC scope
as described above. While it is possible for a group of components to share a single unique group
identifier, it is important to ensure that individual components have their own unique identifiers
relative to each other.
The DSC will not expose the private portions of resident keys or aliases outside the subset of DSC
scope containing the RoT services. Therefore, possession of such aliases or keys can only be
proved indirectly by using it to decrypt a value that has been encrypted with a corresponding
public key. In this way, these resident keys or aliases can provide for authentication based on
decryption operations instead of producing a digital signature.
The DSC responds to requests from an external entity to attest to the provenance and integrity of
platform characteristics contained within the DSC.
Integrity reporting is the process of attesting to platform characteristics (including those recorded
in status registers in a DSC). The philosophy behind integrity measurement, logging, and reporting
is that a platform may enter any state possible—including undesirable or insecure states—but can
still accurately report measurements derived from data attributing to those states. In this context,
data can include, but is not limited to, code, security-critical configurations, values of registers,
including status registers. An independent process may evaluate the integrity states and determine
an appropriate response.
A.2 Objective Requirements
This does not define any
Objective requirements.
A.3 Implementation-based Requirements
This does not define any
Implementation-based requirements.
Appendix B - Selection-based Requirements
As indicated in the introduction to this ,
the baseline requirements
(those that must be performed by the TOE or its underlying platform)
are contained in the body of this .
There are additional requirements based on selections in the body of
the :
if certain selections are made, then additional requirements below must be included.
B.1 User Data Protection
FDP_DAU.1/prove Basic Data Authentication (for Use with The Prove Service)
The inclusion of this selection-based component depends upon a selection in
.
The TSF shall provide a capability to generate evidence that can be used as
a guarantee of the validity of
[selection: [assignment:
list of objects or information types] declared
valid by the TSF, [assignment:
list of objects or information types]
declared valid by an authenticated user].
The TSF shall provide [assignment:
list of subjects] with the ability to
verify evidence of the validity of the indicated information.
Application Note #60:
This SFR describes the output of the Prove service provided by the DSC. The evidence of validity
or authenticity, or other evidence derived, is expected to be processed by the RoT for Measurement.
Additionally, the use of a RoT for Reporting presupposes a logging capability or other means of
generating state information that could be conveyed to external entities. Therefore,
FDP_DAU.1.1/Prove must be selected if-and-only-if the RoT for Measurement and the RoT for
Reporting are both selected in FPT_ROT_EXT.1.1. An ‘authenticated user’ in the sense of the
selection in FDP_DAU.1.1/Prove means a user who has been authenticated by the DSC according
to the mechanisms of FIA_UAU.5.
In FDP_DAU.1.1/Prove, the DSC will issue a validity-stamped or authenticity-stamped piece of
data. In this case, validity-stamped means that the form of the issued data enables an external
entity to verify that the data has been issued via the DSC’s Prove service. The implementation
might be via a DSC cryptographic signature, or a MAC using a symmetric key shared with the
receiver, for example. Authenticity-stamped means that the receiver of the data can verify that the
user providing this data is authentic.
Data that would need to be validity-stamped includes data over which the DSC is the authority,
such as the state of its own firmware. Data that would need to be authenticity-stamped includes
data about which the DSC knows nothing, but where it will issue the data with a statement that the
DSC has authenticated the source of this data.
For data that is validity-stamped, the DSC does nothing but respond to a request to issue the data;
thus, authentication of the user issuing the data is not needed and is covered by
FDP_DAU.1/Prove. Otherwise, in the case the DSC has no understanding of this data, a step is
needed via FIA_UAU.5 by which the DSC authenticates the user for this service, and that the DSC
or Prove service will therefore vouch for the user, not the validity of the data itself.
FDP_FRS_EXT.2 Factory Reset Behavior
The inclusion of this selection-based component depends upon a selection in
.
Upon initiation of a factory reset, the TSF shall destroy [all non-persistent
SDOs] and restore the following pre-installed SDOs to their factory settings:
[assignment:
preinstalled SDOs to be restored during a factory reset].
Application Note #61:
Not all DSCs permit a factory reset of the TOE, or perform a factory reset in response to excessive
failed authentication or authorization attempts. Those that do are expected to perform a factory
reset in a manner that prevents any inadvertent disclosure of security-relevant data that was
present on the DSC prior to the factory reset. For DSCs that permit factory reset functionality (as
indicated by selection of factory reset the TOE wiping out all non-persistent SDOs, as described
by FDP_FRS_EXT.2 in FIA_AFL_EXT.1.3, or by no actions or conditions NOT being selected in
FDP_FRS_EXT.1.1), this SFR must be included in the TOE boundary.
FDP_MFW_EXT.2 Basic Firmware Integrity
The inclusion of this selection-based component depends upon a selection in
.
The TSF shall provide a capability to generate evidence of the integrity of
the firmware.
Application Note #62:
Data and firmware integrity is not a required component of this cPP in all cases because some
DSCs will have immutable firmware. This SFR must be claimed if mutable is selected in
FDP_MFW_EXT.1.1.
The TOE guarantees the integrity of the firmware by verifying its integrity.
Verifying the integrity of the firmware could be accomplished by guaranteeing the validity of
firmware within the TOE prior to execution.
This requirement covers the case of ensuring the firmware is trustworthy in immutable form or
mutable through any firmware updates, since the integrity and authenticity are checked prior to
execution.
FCS_COP.1/SigVer applies if the TOE provides the capability to update the TOE firmware and
uses digital signatures and MAC verification for update verification. The ST Author should choose
the algorithm implemented to perform digital signatures. For the algorithms chosen, the ST author
should make the appropriate assignments/selections to specify the parameters that are
implemented for that algorithm.
FDP_MFW_EXT.3 Firmware Authentication with Identity of Guarantor
The inclusion of this selection-based component depends upon a selection in
.
The TSF shall provide a capability to generate evidence of the
authenticity of the firmware.
Application Note #63:
Firmware authentication is not a required component of this cPP in all cases because some DSCs
will have immutable firmware. This SFR must be claimed if mutable is selected in
FDP_MFW_EXT.1.1.
The TOE guarantees the authenticity of the firmware by verifying its signature.
Verifying the authenticity of the firmware could be accomplished by guaranteeing the validity of
firmware within the TOE prior to execution.
This requirement covers the case of ensuring the firmware is trustworthy in immutable form or
mutable through any firmware updates, since the integrity and authenticity are checked prior to
execution.
FCS_COP.1/SigVer applies if the TOE provides the capability to update the TOE firmware and
uses digital signatures and MAC verification for update verification. The ST Author should choose
the algorithm implemented to perform digital signatures. For the algorithms chosen, the ST author
should make the appropriate assignments/selections to specify the parameters that are
implemented for that algorithm.
B.2 Identification and Authentication
FIA_AFL_EXT.2 Authorization Failure Response
The inclusion of this selection-based component depends upon a selection in
.
When the TSF locks an SDO (i.e. prevents authorization attempts for an
SDO) due to a user exceeding the allowed threshold for unsuccessful authorization attempts, then
only an administrator may unlock access to the SDO and reset the corresponding failed
authorization attempt counter.
Application Note #64:
This SFR is applicable only when the TSF’s response to excessive authorization failures selects
prevent all future authorization attempts indefinitely (i.e., lock) as specified by FIA_AFL_EXT.1.3.
B.3 Protection of the TSF
FPT_FLS.1/FW Failure with Preservation of Secure State (Firmware)
The inclusion of this selection-based component depends upon a selection in
.
The TSF shall preserve a secure state when the following types of firmware
failures occur: [authenticity violation, integrity violation, rollback violation].
Application Note #65:
A DSC’s ability to handle failures related to authenticity, integrity, and invalid versions of
firmware is not applicable in all cases because some DSCs will have immutable firmware. This
SFR must be claimed if mutable is selected in FDP_MFW_EXT.1.1.
The phrase “secure state” refers to a state in which the TOE has consistent TSF data and a TSF
that can correctly enforce the policy. The TOE must ensure that no further processing of TSF or
user data takes place while in an insecure state. This state may be the initial “boot” of a clean
system, or it might be some check-pointed state. It is expected that in most cases, the TOE will halt
and require a reset or re-initialization to return to a known secure state.
FPT_RPL.1/Rollback Replay Detection (Rollback)
The inclusion of this selection-based component depends upon a selection in
.
The TSF shall prevent the execution of the loaded firmware and perform
[selection: [assignment:
other actions], no other actions] when replay is detected.
Application Note #66:
A DSC’s ability to detect an attempted rollback (software/firmware downgrade) is not applicable
in all cases because some DSCs will have immutable firmware that cannot be modified in any way.
This SFR must be claimed if mutable is selected in FDP_MFW_EXT.1.1.
The TSF data is used as a guarantee of the ordinal identifier of the firmware instance. When a
firmware load is requested, the TSF ensures the authenticated firmware ordinal identifier is
greater than or equal to the previously authenticated firmware identifier. For example, this could
be accomplished by ensuring the validated instance of the firmware to be loaded is greater than
or equal to the instance previously validated and loaded into the TOE. By loading a previous
instance of firmware, it potentially opens up the device to known vulnerabilities.
B.4 Trusted Paths/Channels
FTP_CCMP_EXT.1 CCM Protocol
The inclusion of this selection-based component depends upon a selection in
.
The TSF shall implement CCMP using
[selection: AES, Camellia] in CCM mode and key size
[selection: 128-bits, 256-bits] as defined in
[selection: IEEE 802.11i, IEEE 802.11ac].
The TSF shall discard incoming messages that are malformed or invalid.
Application Note #67:
This SFR must be claimed if CCMP is selected in FTP_ITC_EXT.1.
Inclusion of this SFR requires inclusion of AES-CCM or CAM-CCM in FCS_COP.1/SKC.
CCMP is defined in IEEE 802.11i. CCMP-256 is defined in IEEE 802.11ac.
FTP_GCMP_EXT.1 GCM Protocol
The inclusion of this selection-based component depends upon a selection in
.
The TSF shall discard incoming messages that are malformed or invalid.
Application Note #68:
This SFR must be claimed if GCMP is selected in FTP_ITC_EXT.1.
Inclusion of this SFR requires inclusion of AES-GCM or CAM-GCM in FCS_COP.1/SKC.
The TSF shall use
[selection: CCMP, GCMP] protocol to provide a communication channel between itself and
[assignment:
list of entities external to the TOE]
that protects channel data from disclosure and ensures the integrity of channel data.
Application Note #69:
This SFR must be claimed if cryptographically protected data channels as specified in
FTP_ITC_EXT.1 is selected in either FDP_ITC_EXT.1 or FDP_ITC_EXT.2.
Entities external to the TOE include applications that communicate with the TOE such as
authentication capabilities (e.g. biometrics reader), external storage, and interfaces with an
external DSC.
If CCMP is selected, the ST author must include FTP_CCMP_EXT.1.
If GCMP is selected, the ST author must include FTP_GCMP_EXT.1.
FTP_ITE_EXT.1 Encrypted Data Communications
The inclusion of this selection-based component depends upon a selection in
.
The TSF shall encrypt data for transfer between the TOE and
[assignment:
list of entities external to the TOE]
using a cryptographic algorithm and key size as specified in
FCS_COP.1/SKC, and using
[selection:
Keys exchanged using a physically protected communication mechanism
conformant with FTP_ITP_EXT.1
].
Application Note #70:
This SFR must be claimed if encrypted data buffers as specified in FTP_ITE_EXT.1 is selected in
either FDP_ITC_EXT.1 or FDP_ITC_EXT.2.
This requirement applies to encrypted data communications between the TOE and external entities
that do not use a physically protected mechanism conforming to FTP_ITP_EXT.1, or a
cryptographically protected data channel as conforming to FTP_ITC_EXT.1. For example, if data
is transferred through encrypted buffers (or blobs) then this requirement applies. If data is
transferred through a physically protected channel, then FTP_ITP_EXT.1 applies. This
requirement would apply, for example, for communications implemented through a shared data
buffer.
FTP_ITP_EXT.1 Physically Protected Channel
The inclusion of this selection-based component depends upon a selection in
.
The TSF shall provide a physically protected communication channel
between itself and [assignment:
list of other IT entities within the same platform].
This
appendix lists requirements that should be considered satisfied by products
successfully evaluated against this Protection Profile.
However, these requirements are not featured explicitly as SFRs and should not be
included in the ST.
They are not included as standalone SFRs because it would
increase the time, cost, and complexity of evaluation. This approach is permitted
by [CC] Part 1, 8.2 Dependencies between components.
This information benefits systems engineering activities which call for inclusion of
particular security controls. Evaluation against the Protection Profile
provides evidence that these controls are present and have been evaluated.
Requirement
Rationale for Satisfaction
FIA_UAU.1 - Timing of authentication
FIA_AFL.1 implicitly requires that the OS perform all necessary actions,
including those on behalf of the user who has not been authenticated,
in order to authenticate;
therefore it is duplicative to include these actions as a
separate assignment and test.
FIA_UID.1 - Timing of identification
FIA_AFL.1 implicitly requires that the OS perform all necessary actions,
including those on behalf of the user who has not been identified,
in order to authenticate;
therefore it is duplicative to include these actions as a
separate assignment and test.
FMT_SMR.1 - Security roles
FMT_MOF_EXT.1 specifies role-based management functions that implicitly defines
user and privileged accounts;
therefore, it is duplicative to include separate role requirements.
FAU_GEN.1.2 explicitly requires that the OS associate timestamps with audit records;
therefore it is duplicative to include a separate timestamp requirement.
FMT_MOF_EXT.1 defines requirements for managing session locking;
therefore, it is duplicative to include a separate session locking requirement.
FTA_SSL.2 - User-initiated locking
FMT_MOF_EXT.1 defines requirements for user-initiated session locking;
therefore, it is duplicative to include a separate session locking requirement.
FAU_STG.1 - Protected audit trail storage
FPT_ACF_EXT.1 defines a requirement to protect audit logs;
therefore, it is duplicative to include a separate protection of audit trail requirements.
FAU_GEN.2 - User identity association
FAU_GEN.1.2 explicitly requires that the OS record
any user account associated with each event; therefore, it is duplicative
to include a separate requirement to associate a user account with each
event.
FAU_SAR.1 - Audit review
FPT_ACF_EXT.1.2 requires that audit logs (and other objects)
are protected from reading by unprivileged users; therefore, it is duplicative
to include a separate requirement to protect only the audit information.
Appendix D - Acronyms
Appendix E - Selection Rules
This rules in this appendix define which combinations of selections are considered valid.
An ST is considered conforming only if it satisfies all rules.
