Security Objective Rationale
5 Extended Components Definition
116 This protection profile uses components defined as extensions to CC part 2. All components are drawn from [6].
these extended
5.1 e Family FAU_SAS
117 To d
FAU is family describes the functional requirements for the storage of audit data. It has a more general approach than FAU_GEN, because it does not n ta to be generated by the TOE itself and because it does not give specific details of the content of the audit records.
118 The family ‘Audit data storage (FAU_SAS)’ is specified as follows:
dit da
This family defines fu
Definition of th
escribe the security functional requirements of the TOE, the family FAU_SAS of the class (Security audit) is defined here. Th
ecessarily require the da
FAU_SAS Au ta storage Family behaviour
nctional requirements for the storage of audit data.
Component levelling
1 FAU_SAS Audit data storage
lity to store audit data.
M
udit:
There are no actions defined to be auditable.
e the IT security functional requirements of the TOE, the family FCS_RND of the class
FCS (Cry mily describes the functional requirements
fo raphic purposes. The component FCS_RND.1 is
FAU_SAS.1 Requires the TOE to provide the possibi anagement: FAU_SAS.1
There are no management activities foreseen.
A FAU_SAS.1
FAU_SAS.1 Audit storage Hierarchical to: No other components Dependencies: No dependencies
FAU_SAS.1.1 The TSF shall provide [assignment: authorised users] with the capability to store [assignment: list of audit information] in the audit records.
5.2 Definition of the Family FCS_RND
119 To describ
ptographic support) is defined here. This fa r random number generation used for cryptog
n tion of cryptographic keys unlike the component FCS_CKM.1. The similar component FIA_SOS.2 is intended for non-cryptographic use.
120 The ND)’ is specified as follows:
of random numbers Family behaviour
ily defines quality requirements for th ration of random numbers intended to ot limited to genera
family ‘Generation of random numbers (FCS_R FCS_RND Generation
This fam e gene
be used for cryptographic purposes.
Component levelling:
FCS_RND Generation of random numbers 1
FCS_RND.1 Generation of random numbers requires that random numbers meet a
Management: FC
es foreseen.
tions defined to be FCS_RND.1
Hierarchical to: No other components
chanism to generate random numbers that meet [assignment: a defined quality metric].
f the class FIA (Identification and authentication) is defined here. This family describes the functional
re e authentication verification by an external
entity, where the other families of the class FIA address the verification of the identity of an e
122 App of u its o
Crit (cf. [3], chapter ‘Extended components definition (APE_ECD)’) from a TOE point of view.
FIA_API Authentication Proof of Identity defined quality metric.
S_RND.1
There are no management activiti Audit: FCS_RND.1
There are no ac auditable.
Quality metric for random numbers
Dependencies: No dependencies FCS_RND.1.1 The TSF shall provide a me
5.3 Definition of the Family FIA_API
121 To describe the IT security functional requirements of the TOE, the family FIA_API o quirements for proof of the claimed identity for th
xternal entity.
lication note 32: Other families of the class FIA describe only the authentication verification ser’s identity performed by the TOE and do not describe the functionality of the TOE to prove wn identity. The following paragraph defines the family FIA_API in the style of the Common eria part 2
Family behaviour
This family defines functions provided by the TOE to prove its identity and to be verified by an external entity in the TOE IT environment.
elling Component lev :
1 FIA_API Authentication Proof of Identity
Management:
The following actions could be considered for the management of authentication information used to prove the claimed identity.
There are no actions defined to be auditable.
FIA_API.1 Authentication Proof of Identity Hierarchical to: No other components
nt: authentication mechanism] to
5.4 efinition of the Family FMT_LIM
123 The fa ments for the test features of the TOE. The
ne uir n the class FMT because this class addresses the
ma ctio mechanism used in the TOE
sh r cl specific issues of preventing abuse of
fu ng th
124 The family ‘Limited ca
MT_LIM Limited capabilities and availability
s in a combined manner. Note, that FDP_ACF restricts access to functions whereas the Limited m
FIA_API.1 Authentication Proof of Identity.
FIA_API.1
functions in FMT: Management
Audit: FIA_API.1
Dependencies: No dependencies
FIA_API.1.1 The TSF shall provide a [assignme
prove the identity of the [assignment: authorised user or role].
D
mily FMT_LIM describes the functional require w functional req
nagement of fun
ements were defined i
ns of the TSF. The examples of the technical ass is appropriate to address the
ow that no othe
nctions by limiti e capabilities of the functions and by limiting their availability.
pabilities and availability (FMT_LIM)’ is specified as follows:
F
Family behaviour
This family defines requirements that limit the capabilities and availability of function capability of this family requires the functions themselves to be designed in a specific
anner.
Component levelling:
1 FMT_LIM Limited capabilities and availability
2
SF is built to provide only the ther information) necessary for its genuine purpose.
FM
o other components
Dependencies: FMT_LIM.2 Limited availability
FMT_LIM.1.1 The TSF shall be designed in a manner that limits their capabilities so that in conjunction with ‘Limited availability (FMT_LIM.2)’ the
t: Limited capability and availability policy].
FMT_LIM.2 Limited availability Hierarchical to:
abilities
in a manner that limits their availability so that
in IM.1)’ the following
polic availability
125 Application note 33: The functional requirements FMT_LIM.1 and FMT_LIM.2 assume
e capabilities and limited availability) which
together shall provide protection in order to enforce the related policy. This also allows that
(i) the product in its user environment, but its
re so licy is enforced
or conversely
FMT_LIM.1 Limited capabilities requires that the T capabilities (perform action, ga
FMT_LIM.2 Limited availability requires that the TSF restrict the use of functions (refer to Limited capabilities (FMT_LIM.1)). This can be achieved, for instance, by removing or by disabling functions in a specific phase of the TOE’s life-cycle.
Management: FMT_LIM.1, FMT_LIM.2
There are no management activities foreseen.
1, FMT_LIM.2
There are no actions defined to be auditable.
Audit: FMT_LIM.
T_LIM.1 Limited capabilities Hierarchical to: N
following policy is enforced [assignmen
No other components Dependencies: FMT_LIM.1 Limited cap FMT_LIM.2.1 The TSF shall be designed
conjunction with ‘Limited capabilities (FMT_L y is enforced [assignment: Limited capability and policy].
xistence of two types of mechanisms (limited
the TSF is provided without restrictions in capabilities a limited that the po
( n its nt
The combination of both the require
5.5 Definition of the Family FPT_EMSEC
126 The family FPT_EMSEC (TOE Emanation) of the class FPT (Protection of the TSF) is defined here to describe the IT security functional requirements of the TOE. The TOE shall prevent attacks against secret data stored in and used by the TOE where the attack is based on external observable physical phenomena of the TOE. Examples of such attacks are evaluation of TOE’s electromagnetic radiation, simple power analysis (SPA), differential power analysis (DPA), timing attacks, etc. This family describes the functional requirements for the limitation of intelligible emanations being not directly addressed by any other component of CC part 2 [2].
127 The family ‘TOE Emanation (FPT_EMSEC)’ is specified as follows:
FPT_EMSEC TOE emanation Family behaviour
This family defines requirements to mitigate intelligible emanations.
Component levelling:
ii) the TSF is desig user environme
ed with high functionality, but is removed or disabled in the product in .
ments shall enforce the related policy.
1 FPT_EMSEC TOE emanation
FPT_EMSEC.1 TOE emanation has two constituents:
FPT_EMSEC.1.1 Limit of Emissions requires to not emit intelligible emissions enabling access to TSF data or user data.
FPT_EMSEC.1.2 Interface Emanation requires to not emit interface emanation enabling access to TSF data or user data.
Management: FPT_EMSEC.1
Audit: FPT_EMSEC.1
There are no actions defined to be auditable.
FPT_EMSEC.1 TOE Emanation Hierarchical to: No other components Dependencies: No dependencies
FPT_EMSEC.1.1 The TOE shall not emit [assignment: types of emissions] in excess of [assignment: specified limits] enabling access to [assignment: list of types of TSF data] and [assignment: list of types of user data].
There are no management activities foreseen.
FPT_EMSEC.1.2 The TSF shall following inte
ensure [assignment: type of users] are unable to use the rface [assignment: type of connection] to gain access to [assignment: list of types of TSF data] and [assignment: list of types of user data].
6 Secur
128 This part of the PP defines the detailed security requirements that shall be satisfied by the TOE.
The statement of TOE security requirements y
requirements that the TOE needs to satisfy in o .
129 T the component
l ent and iteration are defined in sec. 8.1 of Part 1 [1] of the CC. Each of these operations is used in this PP
130 The refinement operation is used to add det a
requirement. Refinements of security requirem ay that added words are in bold text and removed words are crosse