BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 1
BAROC CC 3.1 Smart Card Protection Profile
1
2
Version: 1.0
3
Date: 2007-12-06
4
Authors: BAROC & FISC
5
6
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 2
Table of contents
7
Table of contents................................................................................................................. 2
8
List of tables........................................................................................................................ 4
9
List of figures ...................................................................................................................... 5
10
1 PP Introduction............................................................................................................ 6
11
1.1 PP Reference ............................................................................................................................ 6
12
1.2 TOE Overview ........................................................................................................................... 7
13
1.2.1 TOE Application Overview................................................................................................. 7
14
1.2.2 TOE Definition.................................................................................................................... 8
15
1.2.3 TOE Boundaries ................................................................................................................ 8
16
1.2.3.1 Physical Boundary...................................................................................................................... 8
17
1.2.3.2 Logical Boundary....................................................................................................................... 8
18
1.2.4 TOE Life Cycle................................................................................................................... 9
19
1.2.5 Roles.................................................................................................................................. 9
20
1.2.6 Description of TOE Security Functionality....................................................................... 10
21
1.2.6.1 TAC Generation ........................................................................................................................10
22
1.2.6.2 Secure Key Update....................................................................................................................10
23
1.2.6.3 Protection of TSF and User Data...............................................................................................10
24
2 Conformance Claims..................................................................................................11
25
2.1 CC Conformance Claim ......................................................................................................... 11
26
2.2 PP Claim .................................................................................................................................. 11
27
2.3 Package Claim ........................................................................................................................ 11
28
3 Security Problem Definition.......................................................................................12
29
3.1 Assets...................................................................................................................................... 12
30
3.1.1 TAC Key........................................................................................................................... 12
31
3.1.2 Perso and Pre-perso Data............................................................................................... 12
32
3.1.3 Retry Counter................................................................................................................... 12
33
3.1.4 Retry Limit........................................................................................................................ 12
34
3.1.5 Serial Number for Transactions....................................................................................... 12
35
3.1.6 DTBT (Data-to-be-TAC’ed).............................................................................................. 12
36
3.1.7 PIN ................................................................................................................................... 13
37
3.2 Threats..................................................................................................................................... 13
38
3.3 OSPs ........................................................................................................................................ 14
39
3.4 Assumptions (about the operational environment)............................................................ 14
40
4 Security Objectives ....................................................................................................16
41
4.1 Security Objectives for the TOE ........................................................................................... 16
42
4.2 Security Objectives for the Operational Environment........................................................ 17
43
4.3 Security Objectives Rationale............................................................................................... 17
44
4.3.1 Coverage of the Security Objectives ............................................................................... 18
45
4.3.2 Coverage of the Assumptions.......................................................................................... 18
46
4.3.3 Countering the Threats .................................................................................................... 19
47
4.3.4 Coverage of the Organisational Security Policies ........................................................... 19
48
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 3
5 Extended Components Definition .............................................................................20
49
5.1 FPT_EMAN TOE Emanation .................................................................................................. 20
50
5.1.1 TOE Emanation (FPT_EMAN.1)...................................................................................... 20
51
6 Security Requirements...............................................................................................21
52
6.1 TOE Security Functional Requirements............................................................................... 22
53
6.1.1 Cryptographic support (FCS)........................................................................................... 23
54
6.1.1.1 Cryptographic key destruction (FCS_CKM.4)..........................................................................23
55
6.1.1.2 Cryptographic operation (FCS_COP.1).....................................................................................23
56
6.1.2 User data protection (FDP).............................................................................................. 23
57
6.1.2.1 Subset access control (FDP_ACC.1).........................................................................................23
58
6.1.2.2 Security attribute based access control (FDP_ACF.1) ..............................................................23
59
6.1.2.3 Import of user data without security attributes (FDP_ITC.1)....................................................24
60
6.1.2.4 Subset residual information protection (FDP_RIP.1)................................................................24
61
6.1.2.5 Stored data integrity monitoring and action (FDP_SDI.2) ........................................................24
62
6.1.2.6 Basic data exchange confidentiality (FDP_UCT.1) ..................................................................24
63
6.1.2.7 Data exchange integrity (FDP_UIT.1) ......................................................................................24
64
6.1.3 Identification and authentication (FIA) ............................................................................. 24
65
6.1.3.1 Authentication failure handling (FIA_AFL.1) ..........................................................................24
66
6.1.3.2 User attribute definition (FIA_ATD.1)......................................................................................25
67
6.1.3.3 Timing of authentication (FIA_UAU.1)....................................................................................25
68
6.1.3.4 Multiple authentication mechanisms (FIA_UAU.5) .................................................................25
69
6.1.3.5 Timing of identification (FIA_UID.1).......................................................................................25
70
6.1.4 Security management (FMT)........................................................................................... 25
71
6.1.4.1 Management of security attributes (FMT_MSA.1) ...................................................................25
72
6.1.4.2 Secure security attributes (FMT_MSA.2) .................................................................................25
73
6.1.4.3 Static attribute initialisation (FMT_MSA.3) .............................................................................26
74
6.1.4.4 Management of TSF data (FMT_MTD.1).................................................................................26
75
6.1.4.5 Specification of Management Functions (FMT_SMF.1)...........................................................26
76
6.1.4.6 Security roles (FMT_SMR.1)....................................................................................................26
77
6.1.5 Protection of the TSF (FPT)............................................................................................. 26
78
6.1.5.1 TOE Emanation (FPT_EMAN.1)..............................................................................................26
79
6.1.5.2 Failure with preservation of secure state (FPT_FLS.1).............................................................27
80
6.1.5.3 Passive detection of physical attack (FPT_PHP.1)....................................................................27
81
6.1.5.4 Resistance to physical attack (FPT_PHP.3) ..............................................................................27
82
6.1.5.5 TSF testing (FPT_TST.1)..........................................................................................................27
83
6.1.6 Trusted path/channels (FTP)........................................................................................... 27
84
6.1.6.1 Inter-TSF trusted channel (FTP_ITC.1) ....................................................................................27
85
6.2 TOE Security Assurance Requirements .............................................................................. 28
86
6.3 Security Requirements Rationale......................................................................................... 29
87
6.3.1 Fulfilment of TOE objectives by the TOE functional requirements.................................. 29
88
6.3.2 Mutual support and internal consistency of security requirements.................................. 31
89
6.3.3 Fulfilment of TOE SFR dependencies ............................................................................. 31
90
6.3.4 Appropriateness of TOE assurance requirements .......................................................... 32
91
7 Appendix.....................................................................................................................34
92
7.1 Abbreviations.......................................................................................................................... 34
93
7.1.1 TOE related abbreviations............................................................................................... 34
94
7.1.2 CC related abbreviations ................................................................................................. 35
95
7.2 Glossary .................................................................................................................................. 36
96
7.3 References .............................................................................................................................. 36
97
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 4
List of tables
98
99
Table 1: Threats ..........................................................................................13
100
Table 2: Organisational Security Policies....................................................14
101
Table 3: Assumptions..................................................................................15
102
Table 4: Security Objectives for the TOE ....................................................17
103
Table 5: Security Objectives for the environment........................................17
104
Table 6: Security Objectives Rationale........................................................18
105
Table 7: TOE related abbreviations.............................................................34
106
Table 8: CC related abbreviations...............................................................35
107
108
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 5
List of figures
109
110
Figure 1: FISC Inter-bank-System................................................................ 7
111
Figure 2: Financial Smart Card Application Life Cycle ................................. 9
112
113
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 6
1 PP Introduction
114
1.1 PP Reference
115
Title: BAROC CC 3.1 Smart Card Protection Profile
116
TOE class: Financial Smart Card for the Taiwanese Market
117
Document name: PP_BAROC_SMARTCARD_V1.0
118
Version: 1.0
119
Document date: 2007-12-06
120
Author: BAROC & FISC
121
CC version 3.1
122
EAL: 4+ augmented by AVA_VAN.5
123
Certification ID: BSI-CC-PP-0038-2007
124
Evaluation body: TÜViT GmbH, Germany
125
Certification body: BSI, Germany
126
Keywords: Smart card, TAC, BAROC, financial transaction, FISC, Taiwan
127
Banking System, Common Criteria, Protection Profile
128
Because of serious circumstances of counterfeiting and skimming, and because of the
129
functional limitations of magnetic stripe cards, the Bankers Association of the Republic
130
of China (BAROC) initiated the Chip Migration Task Force Team in Feb. 2001, to
131
evaluate the feasibility of Chip Migration Project and to develop related specifications.
132
BAROC developed this Protection Profile to serve as a baseline for the security
133
requirements of smart cards developed by different vendors. These smart cards will be
134
used for financial transactions within the FISC Inter-bank System.
135
This Protection Profile focuses on a financial smart card which consists of embedded
136
software and a secure IC controller. The TOE is used as a security token for inter-bank
137
financial transactions, such as cash withdrawal, fund transfer, tax payment and online
138
sale.
139
The main objectives of this Protection Profile are:
140
• To describe the security environment of the TOE including assets to be protected and
141
threats to be countered by the TOE and its operational environment.
142
• To describe the security objectives of the TOE and its supporting environment.
143
• To specify the security requirements, which include the TOE security functional
144
requirements and security assurance requirements.
145
Remark: Regarding the content this PP is identical to the PP already certified according
146
to Common Criteria version 2.1 by BSI under certification ID BSI-PP-0021. Solely the
147
structure of this PP is adapted in order to be consistent with the new requirements of
148
Common Criteria version 3.1 [CC]. In addition some editorial changes have been
149
applied in order to improve readability and comprehensibility of the PP. Regarding the
150
augmentation of ADV_IMP.2 in BSI-PP-0021 there is no necessity to retain it within
151
this PP because in new CC version 3.1 the implementation representation for the entire
152
TSF has even to be provided by the developer in case of ADV_IMP.1.
153
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 7
Acknowledgement: The authors would like to highlight the significant impact of
154
[SSCD] to the development of this Protection Profile. Many of the requirements for this
155
PP and especially the extension of CC part II with FPT_EMAN.1 have been taken from
156
or inspired by the requirements in [SSCD].
157
1.2 TOE Overview
158
1.2.1 TOE Application Overview
159
The TOE is a smart card which consists of embedded software and a secure IC
160
controller. The main purpose of the TOE is to act as a token in the FISC Inter-bank
161
System (see Figure 1) in which a cardholder can do financial transactions such as cash
162
withdrawal, fund transfer, tax payment and purchase with it. The FISC Inter-bank
163
System is a general-purpose platform for switching financial transactions between
164
banks.
165
166
Figure 1: FISC Inter-bank-System
167
The FISC Inter-bank System includes Issuer Bank, FISC, Acquire Bank and its Card
168
Accepted Devices (CAD), all of which are explained individually in the following:
169
1. The Issuer Bank issues financial smart cards (the TOE) to customers and
170
authorizes online transactions done with the TOE from customers.
171
2. The Acquire Bank installs and manages its CADs or so-called application
172
channels, e.g. the ATM, and acquires online transactions from these application
173
channels.
174
3. FISC performs switching, clearing and settlement of inter-bank financial
175
transactions. The Issuer Bank and Acquire Bank shall be recognized by FISC.
176
Furthermore, the following example concerning transaction flow of inter-bank fund
177
transfer is taken as for more detailed overview of the application of the TOE:
178
1. A cardholder inserts its financial smart card into the CAD and enters its PIN.
179
2. The cardholder selects the “fund transfer” function.
180
3. The cardholder confirms the transaction. The CAD prepares transaction data and
181
sends it to the TOE via APDU command (following [ISO7816] part 4, augmented
182
with TAC generation).
183
4. The TOE generates a serial number and a TAC in response to the CAD request.
184
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 8
5. The serial number and the TAC, together with transaction data, are transmitted to
185
Issuer Bank via the FISC inter-bank system. The Issuer Bank approves the
186
transaction by verifying the TAC.
187
6. When after the transaction is approved by Issuer Bank, the amount of fund
188
specified in transaction data is transferred.
189
Application Note:
190
In its application environment of the FISC Inter-bank System, it is strictly required
191
that the security of the TOE be decoupled from the security of application channels of
192
the Acquire Bank. Nevertheless, in the minimum for PIN entry, no trusted channels
193
would be provided in-between the TOE and the CAD of the Acquire Bank as this
194
would violate the application environmental requirement. Therefore, disclosure of the
195
PIN during entry by the CAD is not considered as a threat to the TOE in this
196
Protection Profile.
197
1.2.2 TOE Definition
198
The TOE is a smart card which consists of embedded software and a secure IC
199
controller. Within the Taiwanese banking system as aforementioned, the TOE is used
200
to secure financial transactions.
201
Nevertheless, the TOE is able to generate a transaction authentication code (TAC) for
202
a transaction record (also called DTBT, see section 3.1.6). The TAC is representing a
203
kind of digital signature to secure the authenticity and integrity of the transaction.
204
Within this system, the major scope of the TOE is to protect the key which is used to
205
generate a TAC. For this key a secure cryptographic key creation device generating
206
keys with sufficient quality in accordance with FCS_COP (cf. chapter 6.1) is required
207
in the TOE operational environment.
208
In addition a secure CAD (Card Accepted Devices) for the key update process
209
providing authentication and encryption mechanism is required in the TOE operational
210
environment.
211
1.2.3 TOE Boundaries
212
TOE boundaries are described in terms of physical boundary and logical boundary
213
respectively in the following subsections.
214
1.2.3.1 Physical Boundary
215
The TOE consists of a smart card with a physical interface compliant to ISO 7816
216
part 2 with its dedicated software as well as the smart card embedded software and
217
the related guidance documentation.
218
1.2.3.2 Logical Boundary
219
The TOE logical interface is represented by a set of APDU commands which is
220
compliant to ISO 7816 part 4 (augmented with additional commands).
221
At its logical boundary, the TOE provides functions to generate a TAC for DTBT
222
received by the TOE. The TOE provides no possibility to read out any cryptographic
223
key but only to update it with a new one. This in particular applies to the key for
224
TAC generation.
225
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 9
The TOE is acting as a kind of signature token. It produces a TAC for every DTBT
226
which is sent to the TOE. Before TAC generation, the cardholder has to enter a PIN.
227
However as already described in the application notes of section 1.2.1, disclosure of
228
the PIN during entry by the CAD is not considered as a threat, and therefore, no
229
trusted channels have to be provided by the TOE.
230
1.2.4 TOE Life Cycle
231
The TOE life cycle (LC) is shown in the following figure.
232
233
Figure 2: Financial Smart Card Application Life Cycle
234
The stages shown are listed below:
235
Phase 1: This phase covers the development and production process of the hardware
236
and software the TOE is consisting of.
237
Phase 2: During the Pre-personalization process, the TOE is initialized. This is
238
typically done at the site of card manufacturer. The delivery is done in a
239
secure manner after this phase.
240
Phase 3: This phase includes provisioning all user data into the TOE which is
241
necessary for the usage. This process is typically done at the site of issuing
242
bank.
243
Phase 4: The cardholder can use the TOE to secure financial transactions via the
244
FISC Inter-bank System.
245
1.2.5 Roles
246
The TOE maintains the following roles:
247
• Administrator An administrator is the only role which is allowed to use the
248
key update functionality of the TOE provided during the phases
249
3 and 4.
250
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 10
• Cardholder A cardholder is a person who handles the TOE in usage phase.
251
The person who holds the TOE is allowed to use it to generate a
252
TAC in phase 4 (see TOE Life Cycle).
253
1.2.6 Description of TOE Security Functionality
254
The TOE security functionality consists of TAC generation, secure key update, and
255
protection of TSF and user data.
256
1.2.6.1 TAC Generation
257
The TOE calculates a TAC (Transaction Authentication Code) on transaction data.
258
The TAC ensures authenticity and integrity of the transaction data. In addition to the
259
TAC, the TOE also generates a transaction S/N (serial number) which participated in
260
the calculation of the TAC. In order to generate a TAC, the cardholder has to enter a
261
PIN.
262
1.2.6.2 Secure Key Update
263
The TOE is providing a secure means to update cryptographic keys (especially the
264
key which is used for TAC generation) that will be stored in the TOE.
265
1.2.6.3 Protection of TSF and User Data
266
The TOE protects its TSF and user data from unauthorized modification and
267
disclosure.
268
269
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 11
2 Conformance Claims
270
Conformance statement: The PP requires strict conformance of any PPs/STs to this PP.
271
2.1 CC Conformance Claim
272
This Protection Profile claims to be conformant with the Common Criteria version 3.1
273
[CC].
274
This Protection Profile claims to be Common Criteria Part 2 extended (FPT_EMAN.1)
275
and to Common Criteria Part 3 conformant.
276
2.2 PP Claim
277
This Protection Profile does not claim conformance to any other PP.
278
2.3 Package Claim
279
This Protection Profile conforms to assurance package EAL4 augmented by
280
AVA_VAN.5 defined in Common Criteria Part 3.
281
282
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 12
3 Security Problem Definition
283
3.1 Assets
284
Assets are security relevant elements of the TOE. Generally speaking, the following
285
groups of assets are available:
286
• Embedded software including specifications, implementation and related
287
documentation
288
• Application data of the TOE (e.g. IC and software specific data, Initialisation
289
data, Personalisation data)
290
Nevertheless, assets that are mostly concerned with this Protection Profile are identified
291
and described in the following subsections.
292
3.1.1 TAC Key
293
The TAC (Transaction Authentication Code) Key is a cryptographic key. It is used by
294
the “TAC Generation” functionality within the TOE. The TAC key is stored in the
295
EEPROM of the IC controller during Phase 3. The TOE has to ensure the integrity and
296
confidentiality of the TAC Key.
297
3.1.2 Perso and Pre-perso Data
298
This data consists of user data and cryptographic keys.
299
3.1.3 Retry Counter
300
There are retry counters stored in the EEPROM of IC Controller during Phase 2-4.
301
They are for accumulating consecutive failure attempts of key based authentication
302
and PIN based authentication. The status is blocked as a Retry Counter reaches its
303
associated Retry Limit. The TOE has to ensure the integrity of the Retry Counters
304
(Phase 2-4).
305
3.1.4 Retry Limit
306
An upper bound of the Retry Counter stored in the EEPROM of IC Controller by
307
Issuer Bank during Phase 3 to prohibit further attempts of authentication when the
308
Retry Counter reaches its associated Retry Limit. The TOE has to ensure the integrity
309
of the retry limit (Phase 3-4).
310
3.1.5 Serial Number for Transactions
311
A number which is incremented automatically by the TOE during TAC generation. It
312
participates in TAC generation to ensure that the TAC calculation is not only based on
313
DTBT but also based on the serial number.
314
3.1.6 DTBT (Data-to-be-TAC’ed)
315
This is the data which is received by the TOE to generate a TAC over. In the case of
316
this TOE the DTBT is a transaction record which is used to secure a financial
317
transaction.
318
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 13
3.1.7 PIN
319
The PIN (Personal Identification Number) of the TOE is used to authenticate the
320
cardholder of the TOE. The PIN length shall be at least 6 digits and can be up to 12
321
digits. The PIN is initially generated and stored in the EEPROM of IC controller by
322
the administrator during Phase 3, and can be changed by Cardholder and
323
Administrator during Phase 4. The TOE has to ensure the integrity and confidentiality
324
of the PIN when stored on the card.
325
3.2 Threats
326
The threats in this chapter have been developed based on the following definition of an
327
attacker:
328
An attacker is a person who is trying to access sensitive information. His motivation is
329
to get able to copy or clone the TOE to compromise the whole financial system which is
330
secured by the TOE. However misuse of one single TOE in the way of generating a
331
TAC without the authorization of the owner of the card is not considered as an attack.
332
To perform his attack, the attacker has access to nearly unlimited resources in terms of
333
money and time. Therefore the attacker has a high attack potential in terms of CC.
334
Threat name Description
T.HACK_PHYS
Physical attacks through
the TOE interfaces
An attacker may obtain knowledge of cryptographic keys
via physical attacks such as probing.
T.LEAKAGE
Leakage of information
from the TOE
An attacker may obtain TSF-data which is leaked from the
TOE during normal usage. Leakage of information may
occur through emanations, variations in power
consumption, I/O characteristics, clock frequency, or by
changes in processing time requirements.
T.KEY_COMPROMISE
Copying, releasing or
unauthorized modification
of the cryptographic keys
An attacker may try to compromise the secret
cryptographic key of the TOE.
He may try to copy secret keys from the TOE using the
user visible interfaces of the TOE.
He may also try to use a brute force attack against the
authentication mechanism of the administrator to
overwrite or delete the key.
An attacker may try to perform this attack during the
usage phase of the TOE or during the key update process.
T.KEY_DERIVE
Derive the TAC key
An attacker derives the TAC key from public known data,
such as a TAC created by means of the TAC key or any
other data communicated outside the TOE, which is a
threat against the secrecy of the TAC key.
T.INTEGRITY
Integrity of security
relevant data
An attacker may change security relevant data in the
storage of the TOE. Security relevant data includes
cryptographic keys, TAC and DTBT.
Table 1: Threats
335
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 14
3.3 OSPs
336
OSP Name Description
OSP.TAC The TOE has to provide a function to generate a TAC over a
DTBT. The TOE has to use a cryptographic operation to
generate the TAC with the TAC key. The TAC is
comparable to a digital signature while as the DTBT to the
data to be signed.
The TAC generation has to include an automatically
incremented unique serial number. The serial number
participates in the TAC generation process to achieve that
TAC calculation is not only based on DTBT but also the
serial number.
OSP.KEY_UPDATE The TOE has to provide a secure communication channel
and authentication to update cryptographic keys in a secure
manner.
OSP.PIN In order to use the “TAC Generation” function of the TOE,
the cardholder of the TOE has to enter a PIN beforehand
according to [BAROC_CARD_SPEC chapter 5]. To
perform more than one transaction the cardholder has to
enter the PIN only one time. In accordance with
[BAROC_CARD_SPEC chapter 3 and 5], the PIN is entered
and transmitted in plain text. The PIN length shall be at least
6 digits and can be up to 12 digits, [BAROC_LETTER
chapter 5]. Moreover for PIN entry, a retry counter with
retry limit is used. The retry limit is an administrator
configurable positive integer within 1 to 15 according to
[BAROC_CARD_SPEC chapter 3.2.(3).i].
The TOE shall not provide any possibility to leak out the
PIN when it is stored in the TOE. In particular, the TOE
shall not provide any function to read out the PIN.
Table 2: Organisational Security Policies
337
3.4 Assumptions (about the operational environment)
338
Assumption name Description
A.PERSO The Personalization and Pre-Personalization process is
assumed to take place in an environment providing adequate
physical security and performed by trustworthy personnel.
Any data which is handled during these processes must be
kept confidential.
During key update, a secure CAD which is able to provide
authentication and encryption has to be used.
339
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 15
A.KEY All cryptographic keys which are created in the environment
to be used within the TOE have to be created and handled in
a secure manner and must have sufficient quality.
Table 3: Assumptions
340
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 16
4 Security Objectives
341
4.1 Security Objectives for the TOE
342
Objective Name Description
SO.EMAN_DESIGN
Provide physical emanations
security
The TOE has to be designed and built in such a way as
to control the production of intelligible emanations
within specified limits.
SO.SELF_TEST
Self Testing
The TOE shall provide self-testing functionality for all
TOE security functions which can detect flaws during
pre-personalisation, personalisation and operational
usage phases.
SO.KEY_SECRECY
Secrecy of the cryptographic
keys
The secrecy of cryptographic keys (e.g. the TAC key
that is used for TAC generation) is reasonably assured
against attacks with a high attack potential.
SO.TAMPER_ID
Tamper detection
The TOE provides system features that detect physical
tampering of a system component.
SO.TAMPER_RESISTANCE
Tamper resistance
The TOE prevents or resists physical tampering with
specified system devices and components.
SO.KEY_UPDATE
Secure updates of the
cryptographic keys
The TOE has to provide a secure mechanism to update
cryptographic keys. This includes mechanisms to
ensure the confidentiality and integrity of
cryptographic keys transferred to the TOE as well as
the key based authentication of the terminal which is
sending the keys. The TOE shall provide safe
destruction techniques for the cryptographic keys in
case of key updates.
SO.TAC_SECURE
Cryptographic security of the
TAC
The TOE generates a TAC that cannot be forged
without access to the TAC key through robust
encryption techniques. The TAC key must not be
reconstructible from publicly available data, such as a
TAC or its DTBT.
The TAC generation includes an automatically
incremented unique serial number. The serial number
participates in the TAC generation process to achieve
that TAC calculation is not only based on DTBT but
also based on this serial number.
SO.INTEGRITY
Integrity Protection
The TOE protects data in its storage against any
unauthorized modification.
SO.PIN_ENTRY
TAC generation function after
PIN entry only
The TOE provides the TAC generation function only
after the cardholder has entered his PIN beforehand
according to [BAROC_CARD_SPEC chapter 5].. For
multiple TAC generations the cardholder has to enter
the PIN only one time. In accordance with
[BAROC_CARD_SPEC chapter 3 and 5], the PIN is
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 17
entered and transmitted in plain text. The PIN length
has to be at least 6 digits and can be up to 12 digits,
[BAROC_LETTER chapter 5]. Moreover for PIN
entry, a retry counter with retry limit is used. The retry
limit is an administrator configurable positive integer
within 1 to 15 according to [BAROC_CARD_SPEC
chapter 3.2.(3).i].
The TOE must not provide any possibility to leak out
the PIN when it is stored in the TOE. In particular, the
TOE must not provide any function which would allow
anybody to read out the PIN.
Table 4: Security Objectives for the TOE
343
4.2 Security Objectives for the Operational Environment
344
Objective name Description
SOE.PERSO The Personalization and Pre-Personalization process
must take place in an environment providing adequate
physical security and performed by trustworthy
personnel.
Any data which is handled during these processes must
be kept confidential.
During key update, a secure CAD which is able to
provide authentication and encryption has to be used.
SOE.KEY All cryptographic keys which are created in the
environment to be used within the TOE have to be
created and handled in a secure manner and have to
have sufficient quality.
Table 5: Security Objectives for the environment
345
4.3 Security Objectives Rationale
346
Threats,
Assumptions, OSP /
Security Objectives
SO.EMAN_DESIGN
SO.SELF_TEST
SO.KEY_SECRECY
SO.TAMPER_ID
SO.TAMPER_RESISTANCE
SO.KEY_UPDATE
SO.PIN_ENTRY
SO.TAC_SECURE
SO.INTEGRITY
SOE.PERSO
SOE.
KEY
T.HACK_PHYS X X
T.LEAKAGE X
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 18
T.KEY_COMPROMIS
E
X X X X
T.KEY_DERIVE X X
T.INTEGRITY X X
OSP.TAC X X
OSP.PIN X X
OSP.KEY_UPDATE X X
A.PERSO X
A.KEY X
Table 6: Security Objectives Rationale
347
4.3.1 Coverage of the Security Objectives
348
SO.EMAN_DESIGN can be traced back to the threats T.LEAKAGE as the design
349
which is described in SO.EMAN_DESIGN prevents any emanations which could be
350
used to perform T.LEAKAGE.
351
SO.SELF_TEST can be traced back to many threats as it is supporting all security
352
functions which are provided by the TOE because it ensures that these functions are
353
working correctly.
354
SO.KEY_SECRECY can be traced back to the threats T.KEY_COMPROMISE as
355
SO.KEY_SECRECY describes that the confidentiality of the cryptographic keys has
356
to be ensured by the TOE.
357
SO.TAMPER_ID can be traced back to the threats T.HACK_PHYS as one have to
358
identify an attack via physical means before one is able to handle this attack.
359
SO.TAMPER_RESISTANCE can be traced back to the threats T.HACK_PHYS as
360
SO_TAMPER_RESISTANCE defines that the TOE has to prevent or resist physical
361
hacking as described in T.HACK_PHYS.
362
SO.KEY_UPDATE can be traced back to the threats T.KEY_COMPROMISE as it
363
ensures that the confidentiality of the cryptographic key is ensured when transmitted to
364
the TOE and OSP.KEY_UPDATE as this objective describes the functionality as
365
required by the OSP.
366
SO.PIN_ENTRY can directly be traced back to the OSP.PIN.
367
SO.TAC_SECURE can be traced back to OSP.TAC as it describes the requirements
368
from the OSP and to the threat T.KEY_DERIVE as the mechanism as described in
369
SO.TAC_SECURE are used to block the possibility to gain knowledge of the secret
370
keys with public knowledge.
371
SO.INTEGRITY can obviously be traced back to T.INTEGRITY.
372
4.3.2 Coverage of the Assumptions
373
A.PERSO is obviously covered by SOE.PERSO.
374
A.KEY is obviously covered by SOE.KEY.
375
All the security objectives for the environment are stated in a way that it is obvious
376
that they are suitable to fulfil the assumption.
377
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 19
4.3.3 Countering the Threats
378
SO.SELF_TEST is a supportive security objective which is enlisted against many
379
threats. It will therefore not be explicitly mentioned in the following paragraphs. It
380
ensures that the security functions which are provided by the TOE are working
381
correctly and is therefore a supportive objective for all threats which are actively
382
blocked by functions of the TOE.
383
T.HACK_PHYS is covered by SO.TAMPER_ID which detects physical tampering
384
and SO.TAMPER_RESISTANT which requires that the TOE has to be resistant
385
against this kind of attacks.
386
T.LEAKAGE is obviously covered by SO_EMAN_DESIGN.
387
T.KEY_COMPROMISE is covered by SO.KEY_SECRECY which secures the
388
cryptographic keys when stored in the TOE and SO.KEY_UPDATE which protects
389
the key when transmitted to the TOE. Furthermore SOE.PERSO supports the
390
blocking of this threat as it ensures that the confidentiality of the key is ensured during
391
the perso- or update process.
392
T.KEY_DERIVE is directly covered by SO.TAC_SECURE as this objective defines
393
that any algorithm which is used to calculate the TAC has to ensure that it is not
394
feasible to derive the secret key from any publicly available data.
395
T.INTEGRITY is directly covered by SO.INTEGRITY as it is not feasible for an
396
attacker to change any kind of security relevant data as long as the TOE protects its
397
data against unauthorized modification.
398
4.3.4 Coverage of the Organisational Security Policies
399
OSP.TAC is obviously covered by SO.TAC_SECURE.
400
OSP.PIN is obviously covered by SO.PIN_ENTRY.
401
OSP.KEY_UPDATE is obviously covered by SO.KEY_UPDATE.
402
All these security objectives are stated in a way that it is obvious that they are suitable
403
to fulfil the OSP.
404
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 20
5 Extended Components Definition
405
Remarks: Definition of this family is based on the FPT_EMSEC of the SSCD PP [SSCD].
406
The additional family FPT_EMAN (TOE Emanation) of the Class FPT (Protection of the
407
TSF) is defined here to describe the IT security functional requirements of the TOE. The
408
TOE shall prevent attacks against the cryptographic keys and other secret data where the
409
attack is based on external observable physical phenomena of the TOE. Examples of such
410
attacks are evaluation of TOE’s electromagnetic radiation, simple power analysis (SPA),
411
differential power analysis (DPA), timing attacks, etc. This family describes the
412
functional requirements for the limitation of intelligible emanations.
413
5.1 FPT_EMAN TOE Emanation
414
Family behaviour
415
This family defines requirements to mitigate intelligible emanations.
416
Component levelling:
417
418
419
FPT_EMAN.1 TOE Emanation has two constituents:
420
• FPT_EMAN.1.1 Limit of Emissions requires to not emit intelligible emissions enabling
421
access to TSF data or user data.
422
• FPT_EMAN.1.2 Interface Emanation requires not emit interface emanation enabling
423
access to TSF data or user data.
424
425
Management: FPT_EMAN.1
426
There are no management activities foreseen.
427
Audit: FPT_EMAN.1
428
There are no actions identified that should be auditable if FAU_GEN Security audit data
429
generation is included in the PP/ST.
430
5.1.1 TOE Emanation (FPT_EMAN.1)
431
FPT_EMAN.1.1 The TOE shall not emit [assignment: types of emissions] in excess
432
of [assignment: specified limits] enabling access to secret data
433
including cryptographic keys, especially the TAC key.
434
FPT_EMAN.1.2 The TSF shall ensure that nobody is able to use [assignment:
435
types of emissions] to gain access to secret data including
436
cryptographic keys, especially the TAC key.
437
Hierarchical to: No other components.
438
Dependencies: No other components.
439
FPT_EMAN
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 21
6 Security Requirements
440
This chapter gives the security functional requirements, the security assurance
441
requirements and the security requirements rationale for the TOE.
442
Security functional requirements components given in section 6.1 “TOE security
443
functional requirements”, excepting FPT_EMAN.1 which represents an extended
444
component defined in chapter 5, are drawn from Common Criteria part 2 [CC].
445
Operations for assignment and selection have been made. Operations not performed in
446
this PP are identified in order to enable instantiation of the PP to a Security Target (ST).
447
Iterations are marked with /KEY, /TAC, or /PIN, and refinements are marked bold.
448
All operations which have been performed from the original text of part 2 of [CC] are
449
written in italics for assignments and underlined for selections. Furthermore the [brackets]
450
from part 2 of [CC] are kept in the text.
451
All operations which have to be completed by the ST author are marked with the words:
452
"assignment" or "selection" respectively.
453
The TOE security assurance requirements statement given in section 6.2 “TOE Security
454
Assurance Requirement” is drawn from the security assurance components from
455
Common Criteria part 3 [CC].
456
In section 6.3, the security requirements rationale is presented.
457
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 22
6.1 TOE Security Functional Requirements
458
The following table provides an overview about the used SFRs:
459
SFR Description
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1 Cryptographic operation
FDP_ACC.1/KEY Subset access control for cryptographic keys
FDP_ACC.1/TAC Subset access control for the TAC generation
FDP_ACF.1/KEY Security attribute based access control for cryptographic keys
FDP_ACF.1/TAC Security attribute based access control for the TAC generation
FDP_ITC.1 Import of user data without security attributes
FDP_RIP.1 Subset residual information protection
FDP_SDI.2 Stored data integrity monitoring and action
FDP_UCT.1 Basic data exchange confidentiality
FDP_UIT.1 Data exchange integrity
FIA_AFL.1/PIN Authentication failure handling regarding the PIN
FIA_AFL.1/KEY Authentication failure handling regarding the Key
FIA_ATD.1 User attribute definition
FIA_UAU.1 Timing of authentication
FIA_UAU.5 Multiple authentication mechanisms
FIA_UID.1 Timing of identification
FMT_MSA.1/TAC Management of security attributes for TAC
FMT_MSA.1/KEY Management of security attributes for keys
FMT_MSA.2 Secure security attributes
FMT_MSA.3/TAC Static attribute initialisation for TAC
FMT_MSA.3/KEY Static attribute initialisation for keys
FMT_MTD.1 Management of TSF data
FMT_SMF.1/PIN Specification of Management Functions for PIN
FMT_SMF.1/KEY Specification of Management Functions for TAC
FMT_SMR.1 Security roles
FPT_EMAN.1 TOE Emanation
FPT_FLS.1 Failure with preservation of secure state
FPT_PHP.1 Passive detection of physical attack
FPT_PHP.3 Resistance to physical attack
FPT_TST.1 TSF testing
FTP_ITC.1 Inter-TSF trusted channel
460
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 23
6.1.1 Cryptographic support (FCS)
461
6.1.1.1 Cryptographic key destruction (FCS_CKM.4)
462
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified
463
cryptographic key destruction method [assignment: cryptographic key
464
destruction method] that meets the following: [assignment: list of standards].
465
Application Note: It must be assured that cryptographic keys are destroyed securely by, for
466
example, overwriting with new keys.
467
6.1.1.2 Cryptographic operation (FCS_COP.1)
468
FCS_COP.1.1 The TSF shall perform [TAC generation including a unique transaction serial
469
number] in accordance with a specified cryptographic algorithm [assignment:
470
cryptographic algorithm] and cryptographic key sizes [assignment:
471
cryptographic key sizes] that meet the following: [listed in [FIPS_A]].
472
Application Note: TAC shall include an automatically incremented unique serial number. The
473
serial number participates in the TAC generation process to achieve that TAC
474
calculation is not only based on DTBT but also based on the serial number.
475
6.1.2 User data protection (FDP)
476
6.1.2.1 Subset access control (FDP_ACC.1)
477
FDP_ACC.1.1/KEY The TSF shall enforce the [Key Import/export SFP] on [subjects: user, objects:
478
cryptographic keys and operation: import and export of keys].
479
FDP_ACC.1.1/TAC The TSF shall enforce the [TAC Generation SFP] on [subjects: user, objects:
480
DTBT and operation: generate a TAC].
481
6.1.2.2 Security attribute based access control (FDP_ACF.1)
482
FDP_ACF.1.1/KEY The TSF shall enforce the [Key Import/export SFP] to objects based on the
483
following: [subject attribute: Administrator {yes/no} and object attribute:
484
cryptographic key {yes/no}].
485
FDP_ACF.1.2/KEY The TSF shall enforce the following rules to determine if an operation among
486
controlled subjects and controlled objects is allowed: [users with subject
487
attribute administrator set to {yes} are allowed to update objects with
488
attribute cryptographic key set to {yes}].
489
FDP_ACF.1.3/KEY The TSF shall explicitly authorise access of subjects to objects based on the
490
following additional rules: [no other rule].
491
FDP_ACF.1.4/KEY The TSF shall explicitly deny access of subjects to objects based on the [
492
Nobody is allowed to read out objects with attribute secret key set to {yes}].
493
494
FDP_ACF.1.1/TAC The TSF shall enforce the [TAC Generation SFP] to objects based on the
495
following: [subject attribute: Cardholder {yes/no}, object attribute PIN
496
{yes/no}].
497
FDP_ACF.1.2/TAC The TSF shall enforce the following rules to determine if an operation among
498
controlled subjects and controlled objects is allowed: [users with subject
499
attribute Cardholder set to {yes} are allowed to generate a TAC for DTBT
500
sent to the TOE].
501
FDP_ACF.1.3/TAC The TSF shall explicitly authorise access of subjects to objects based on the
502
following additional rules: [none].
503
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 24
FDP_ACF.1.4/TAC The TSF shall explicitly deny access of subjects to objects based on the
504
[nobody is allowed to read out an object with attribute PIN set {yes}].
505
6.1.2.3 Import of user data without security attributes (FDP_ITC.1)
506
FDP_ITC.1.1 The TSF shall enforce the [Key Import/export SFP] when importing user data,
507
controlled under the SFP, from outside of the TOE.
508
FDP_ITC.1.2 The TSF shall ignore any security attributes associated with the user data
509
when imported from outside the TOE.
510
FDP_ITC.1.3 The TSF shall enforce the following rules when importing user data controlled
511
under the SFP from outside the TOE: [The key must only be accepted when
512
sent by an authorized administrator via the trusted channel]
513
6.1.2.4 Subset residual information protection (FDP_RIP.1)
514
FDP_RIP.1.1 The TSF shall ensure that any previous information content of a resource is
515
made unavailable upon the [selection: allocation of the resource to,
516
deallocation of the resource from] the following objects: [cryptographic keys,
517
PIN, [assignment: none or a list of objects]].
518
6.1.2.5 Stored data integrity monitoring and action (FDP_SDI.2)
519
FDP_SDI.2.1 The TSF shall monitor user data stored in containers controlled by the TSF for
520
[assignment: integrity errors] on all objects, based on the following attributes
521
[assignment: user data attributes].
522
FDP_SDI.2.2 Upon detection of a data integrity error, the TSF shall [
523
1. Prohibit the use of the altered data
524
2. Inform the user about integrity errors]
525
6.1.2.6 Basic data exchange confidentiality (FDP_UCT.1)
526
FDP_UCT.1.1 The TSF shall enforce the [Key Import/export SFP] to be able to [receive] user
527
data in a manner protected from unauthorised disclosure.
528
6.1.2.7 Data exchange integrity (FDP_UIT.1)
529
FDP_UIT.1.1 The TSF shall enforce the [Key Import/export SFP] to be able to [receive] user
530
data in a manner protected from [modification, insertion] errors.
531
FDP_UIT.1.2 The TSF shall be able to determine on receipt of user data, whether
532
[modification, insertion] has occurred.
533
6.1.3 Identification and authentication (FIA)
534
6.1.3.1 Authentication failure handling (FIA_AFL.1)
535
FIA_AFL.1.1/PIN The TSF shall detect when [an administrator configurable positive integer
536
within 1 to 15 consecutive] unsuccessful authentication attempts occur related
537
to [PIN based authentication of the Cardholder].
538
FIA_AFL.1.2/PIN When the defined number of unsuccessful authentication attempts has been
539
[met], the TSF shall [block the PIN based authentication of the Cardholder].
540
541
FIA_AFL.1.1/KEY The TSF shall detect when [an administrator configurable positive integer
542
within 1 to 15 consecutive] unsuccessful authentication attempts occur related
543
to [Key based authentication of the Administrator].
544
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 25
FIA_AFL.1.2/KEY When the defined number of unsuccessful authentication attempts has been
545
[met], the TSF shall [block the Key based authentication of the Administrator].
546
Application Note: For the first assignment in FIA_AFL.1.1/PIN and FIA_AFL.1.1/KEY it would
547
also be acceptable if the number of allowed unsuccessful authentication
548
attempts is fixed and not configurable by the admin.
549
6.1.3.2 User attribute definition (FIA_ATD.1)
550
FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to
551
individual users: [PIN, Cardholder {yes/no}, Administrator {yes/no}, number
552
of unsuccessful authentication attempts]
553
6.1.3.3 Timing of authentication (FIA_UAU.1)
554
FIA_UAU.1.1 The TSF shall allow [assignment: list of TSF mediated actions with the
555
exception of i) TAC generation, ii) Key update and iii) Management
556
functions provided by the TOE] on behalf of the user to be performed before
557
the user is authenticated.
558
FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before
559
allowing any other TSF-mediated actions on behalf of that user.
560
6.1.3.4 Multiple authentication mechanisms (FIA_UAU.5)
561
FIA_UAU.5.1 The TSF shall provide [PIN based and Key based authentication mechanisms]
562
to support user authentication.
563
FIA_UAU.5.2 The TSF shall authenticate any user’s claimed identity according to the [PIN
564
based authentication which is used for authenticating a Cardholder and Key
565
based authentication which is used for authenticating an Administrator].
566
6.1.3.5 Timing of identification (FIA_UID.1)
567
FIA_UID.1.1 The TSF shall allow [assignment: list of TSF-mediated actions with the
568
exception of i) TAC generation, ii) Key update and iii) Management
569
functions provided by the TOE] on behalf of the user to be performed before
570
the user is identified.
571
FIA_UID.1.2 The TSF shall require each user to be successfully identified before allowing
572
any other TSF-mediated actions on behalf of that user.
573
6.1.4 Security management (FMT)
574
6.1.4.1 Management of security attributes (FMT_MSA.1)
575
FMT_MSA.1.1/TAC The TSF shall enforce the [TAC generation SFP] to restrict the ability to
576
[modify] the security attributes [Cardholder {yes/no}] to [Cardholder]
577
578
FMT_MSA.1.1/KEY The TSF shall enforce the [Key Import/export SFP] to restrict the ability to
579
[query, [set]] the security attributes [administrator {yes/no}, cryptographic key
580
{yes/no}] to [administrator].
581
6.1.4.2 Secure security attributes (FMT_MSA.2)
582
FMT_MSA.2.1 The TSF shall ensure that only secure values are accepted for [assignment: list
583
of security attributes].
584
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 26
6.1.4.3 Static attribute initialisation (FMT_MSA.3)
585
FMT_MSA.3.1/TAC The TSF shall enforce the [TAC generation SFP] to provide [restrictive]
586
default values for security attributes that are used to enforce the SFP.
587
FMT_MSA.3.2/TAC The TSF shall allow the [no roles] to specify alternative initial values to
588
override the default values when an object or information is created.
589
590
FMT_MSA.3.1/KEY The TSF shall enforce the [Key Import/export SFP] to provide [restrictive]
591
default values for security attributes that are used to enforce the SFP.
592
FMT_MSA.3.2/KEY The TSF shall allow the [no roles] to specify alternative initial values to
593
override the default values when an object or information is created.
594
6.1.4.4 Management of TSF data (FMT_MTD.1)
595
FMT_MTD.1.1 The TSF shall restrict the ability to [modify] the [PIN] to [Cardholder or
596
Administrator].
597
6.1.4.5 Specification of Management Functions (FMT_SMF.1)
598
FMT_SMF.1.1/PIN The TSF shall be capable of performing the following management functions:
599
[Modify the PIN, Set number of unsuccessful authentication attempts].
600
FMT_SMF.1.1/KEY The TSF shall be capable of performing the following management functions:
601
[query and set the security attributes of cryptographic key, start the self test of
602
the TOE].
603
6.1.4.6 Security roles (FMT_SMR.1)
604
FMT_SMR.1.1 The TSF shall maintain the roles [Administrator and Cardholder].
605
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
606
6.1.5 Protection of the TSF (FPT)
607
6.1.5.1 TOE Emanation (FPT_EMAN.1)
608
FPT_EMAN.1.1 The TOE shall not emit [assignment: types of emissions] in excess of
609
[assignment: specified limits] enabling access to secret data including
610
cryptographic keys, especially the TAC key.
611
FPT_EMAN.1.2 The TSF shall ensure that nobody is able to use [assignment: types of
612
emissions] to gain access to secret data including cryptographic keys,
613
especially the TAC key.
614
Application Note: The TOE shall prevent attacks against cryptographic keys and other secret
615
data where the attack is based on external observable physical phenomena of
616
the TOE. Such attacks may be observable at the interfaces of the TOE or may
617
origin from internal operation of the TOE or may origin by an attacker that
618
varies the physical environment under which the TOE operates. The set of
619
measurable physical phenomena is influenced by the technology employed to
620
implement the TOE. Examples of measurable phenomena are variations in the
621
power consumption, the timing of transitions of internal states,
622
electromagnetic radiation due to internal operation, radio emission. Due to the
623
heterogeneous nature of the technologies that may cause such emanations,
624
evaluation against state-of-the-art attacks applicable to the technologies
625
employed by the TOE is assumed. Examples of such attacks are, but are not
626
limited to, evaluation of TOE’s electromagnetic radiation, simple power
627
analysis (SPA), differential power analysis (DPA), timing attacks, etc.
628
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 27
6.1.5.2 Failure with preservation of secure state (FPT_FLS.1)
629
FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of failures
630
occur: [assignment: list of types of failures in the TSF].
631
6.1.5.3 Passive detection of physical attack (FPT_PHP.1)
632
FPT_PHP.1.1 The TSF shall provide unambiguous detection of physical tampering that
633
might compromise the TSF.
634
FPT_PHP.1.2 The TSF shall provide the capability to determine whether physical tampering
635
with the TSF'
s devices or TSF'
s elements has occurred.
636
6.1.5.4 Resistance to physical attack (FPT_PHP.3)
637
FPT_PHP.3.1 The TSF shall resist [assignment: physical tampering scenarios] to the
638
[assignment: list of TSF devices/elements] by responding automatically such
639
that the SFRs are always enforced.
640
6.1.5.5 TSF testing (FPT_TST.1)
641
FPT_TST.1.1 The TSF shall run a suite of self tests [selection: during initial start-up,
642
periodically during normal operation, at the request of the authorised user, at
643
the conditions [assignment: conditions under which self test should occur]] to
644
demonstrate the correct operation of the TSF.
645
FPT_TST.1.2 The TSF shall provide authorised users with the capability to verify the
646
integrity of TSF data.
647
FPT_TST.1.3 The TSF shall provide authorised users with the capability to verify the
648
integrity of stored TSF executable code.
649
Application Note: According to SO.SELF_TEST, TOE self-test should be provided for pre-
650
personalisation, personalisation and operational usage phases.
651
6.1.6 Trusted path/channels (FTP)
652
6.1.6.1 Inter-TSF trusted channel (FTP_ITC.1)
653
FTP_ITC.1.1 The TSF shall provide a communication channel between itself and another
654
trusted IT product that is logically distinct from other communication channels
655
and provides assured identification of its end points and protection of the
656
channel data from modification or disclosure.
657
FTP_ITC.1.2 The TSF shall permit [selection: the TSF, another trusted IT product] to
658
initiate communication via the trusted channel.
659
FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for [import of
660
cryptographic key, [assignment: any other functions for which a trusted
661
channel is required]].
662
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 28
6.2 TOE Security Assurance Requirements
663
The evaluation assurance package is EAL 4 augmented by AVA_VAN.5.
664
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 29
6.3 Security Requirements Rationale
665
6.3.1 Fulfilment of TOE objectives by the TOE functional requirements
666
SO.
EMAN_DESIGN
SO.SELF_TEST
SO.KEY_SECRECY
SO.TAMPER_ID
SO.TAMPER_RESISTANCE
SO.KEY_UPDATE
SO.PIN_ENTRY
SO.TAC_SECURE
SO.INTEGRITY
FCS_CKM.4 X X
FCS_COP.1 X
FDP_ACC.1/KEY X X X
FDP_ACC.1/TAC X X
FDP_ACF.1/KEY X X X
FDP_ACF.1/TAC X X
FDP_ITC.1 X
FDP_RIP.1 X X
FDP_SDI.2 X X X
FDP_UCT.1 X
FDP_UIT.1 X
FIA_AFL.1/PIN X
FIA_AFL.1/KEY X
FIA_ATD.1 X
FIA_UAU.1 X X
FIA_UAU.5 X X
FIA_UID.1 X X
FMT_MSA.1/TAC X X
FMT_MSA.1/KEY X
FMT_MSA.2 X
FMT_MSA.3/TAC X
FMT_MSA.3/KEY X
FMT_MTD.1 X
FMT_SMF.1/PIN X
FMT_SMF.1/KEY X
FMT_SMR.1 X X
FPT_EMAN.1 X X
FPT_FLS.1 X
FPT_PHP.1 X
FPT_PHP.3 X
FPT_TST.1 X
FTP_ITC.1 X
SO.EMAN_DESIGN which requires that the TOE is built in such a way as to control
667
the production of intelligible emanations within specified limits is directly fulfilled by
668
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 30
the SFR FPT_EMAN.1 as this requires that the TOE does not emit intelligible
669
emanations which exceed a certain limit and that it shall not be possible to determine
670
user data of the TOE using these emanations.
671
SO.SELF_TEST which requires that the TOE has to provide self testing functionality
672
for all security functions is fulfilled by FPT_TST.1 which describes that the TOE has
673
to be able to run a suite of tests to ensure the correct operation of the TSF.
674
SO.KEY_SECRECY which describes that the TOE assures the TAC key against
675
attacks is fulfilled by FCS_CKM.4 which ensures the secure destruction of the keys
676
after an update has been performed, FDP_ACC.1/KEY and FDP_ACF.1/KEY which
677
specify that nobody is allowed to read out the key, FDP_RIP.1 which ensures that key
678
in memory which are no longer used are destroyed, FDP_SDI.2 which specifies the
679
integrity protection of the key and FPT_FLS.1 which detects insecure states of the
680
TOE. Furthermore FPT_EMAN.1 contributes to SO.KEY_SECRECY as the design
681
of the TOE which is described in FPT_EMAN.1 is used to protect the key.
682
SO.TAMPER_ID which requires that the TOE detects physical tampering directly
683
and completely covered by FPT_PHP.1.
684
SO.TAMPER_RESISTANCE which requires that the TOE has to be resistant
685
against physical tampering is directly and completely covered by FPT_PHP.3.
686
SO.KEY_UPDATE specifies that the TOE has to provide a secure mechanism to
687
update the key. This includes the secure transmission to the TOE, the key based
688
authentication of the terminal which is sending the key and the secure destruction of
689
old keys.
690
This objective is fulfilled by a combination of FCS_CKM.4 which describes the
691
secure key destruction method after the key update has been performed,
692
FDP_ACC.1/KEY and FDP_ACF.1/KEY which define that only an administrator is
693
allowed to update the keys, FDP_ITC.1 which defines the import policy for the key
694
update, FDP_UCT.1 which describes that the keys have to be kept confidential
695
during key update, FDP_UIT.1 which describes that the TOE has to ensure the
696
integrity of the keys, FIA_AFL.1/KEY which ensures that the process of key update
697
is blocked after a certain number of unsuccessful authentication attempts, FIA_UAU.1
698
and FIA_UAU.5 which describe the authentication mechanisms of the terminal,
699
FIA_UID.1 which requires user identification, FMT_MSA.1/KEY which limits the
700
ability to change security attributes for key update to administrators,
701
FMT_MSA.3/KEY which defines that nobody is allowed to overwrite the initial
702
values for the security attributes, FMT_SMF.1/KEY which defines the management
703
functions for the key update, FMT_SMR.1 which describes the roles, the TOE has to
704
maintain and FTP_ITC.1 which describes the requirements for the trusted channel
705
which also includes key based authentication.
706
SO.PIN_ENTRY describes that the TOE has to provide an authentication mechanism
707
which requires the cardholder to authenticate the TAC generation. In terms of SFRs
708
this mechanism is modelled as follows:
709
FDP_ACC.1/TAC and FDP_ACF.1/TAC describe the rules for access control
710
related to the TAC generation and the PIN, FDP_RIP.1 defines that PINs which are
711
no longer used are securely destroyed from memory, FIA_AFL.1/PIN defines the
712
authentication failure handling for the TAC generation, FIA_ATD.1 defines the user
713
attributes which are used for access control, FIA_UAU.1, FIA_UAU.5 and
714
FIA_UID.1 describe the multiple authentication mechanisms and that each user has to
715
be identified/authenticated before he is allowed to generate the TAC,
716
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 31
FMT_MSA.1/TAC defines that nobody is allowed to change the security attribute
717
regarding the card holder, FMT_MTD.1 defines that only the card holder and an
718
administrator are allowed to change the PIN, FMT_SMF.1/PIN defines the
719
management function to change the PIN and FMT_SMR.1 describes the roles, the
720
TOE has to maintain.
721
SO.TAC_SECURE which requires that the TAC which is generated by the TOE
722
cannot be forged is covered by a combination of FCS_COP.1 which defines the
723
cryptographic operation to generate the TAC, FDP_SDI.2 which is used to ensure the
724
integrity of the data which is used to generate the TAC, FMT_MSA.1/TAC,
725
FMT_MSA.3/TAC and FMT_MSA.2 which describe the handling of the security
726
attributes which are involved in the TAC generation.
727
SO.INTEGRITY which requires that the TOE protects that data in its storage against
728
unauthorized modification is covered by FDP_ACC.1/KEY which describes the
729
access control policy for the cryptographic keys together with FDP_ACF.1/KEY and
730
FDP_ACC.1/TAC which describes the access control policy together with
731
FDP_ACF.1/TAC for the TAC. Beside these requirements which are used to decide
732
whether an access attempt to an asset is authorized, FDP_SDI.2 is used to ensure the
733
integrity of data when stored in the memory of the TOE.
734
6.3.2 Mutual support and internal consistency of security requirements
735
From the details given in this rationale it becomes evident that the functional
736
requirements form an integrated whole and, taken together, are suited to meet all
737
security objectives. Requirements from [CC] part 2 are used to fulfil the security
738
objectives.
739
The core TOE functionality is represented by the requirements for TAC generation,
740
the handling of the key and the mechanisms for key update. (FCS_CKM.4,
741
FCS_COP.1, FTP_ITC.1)
742
Furthermore a set of requirements is used to describe the way these functions should
743
be used and who is allowed to uset them (e.g. FDP_ACC.1/KEY)
744
In the end this PP contains a set of SFRs which deals with the detection and defeating
745
of attacks to the TOE, resp. SFRs which are used to show that the TOE is working
746
correctly (e.g. FPT_PHP.1, FPT_PHP.3, FPT_TST.1)
747
Therefore it becomes clear that the SFRs in this PP mutually support each other and
748
form a consistent whole.
749
6.3.3 Fulfilment of TOE SFR dependencies
750
SFR Dependencies Dependency
fulfilled?
FCS_CKM.4 FDP_ITC.1, FMT_MSA.2 Yes
FCS_COP.1 FDP_ITC.1, FCS_CKM.4, FMT_MSA.2 Yes
FDP_ACC.1/KEY FDP_ACF.1/KEY Yes
FDP_ACC.1/TAC FDP_ACF.1/TAC Yes
FDP_ACF.1/KEY FDP_ACC.1/KEY, FMT_MSA.3/KEY Yes
FDP_ACF.1/TAC FDP_ACC.1/TAC, FMT_MSA.3/TAC Yes
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 32
FDP_ITC.1 FDP_ACC.1/KEY, FMT_MSA.3/KEY Yes
FDP_RIP.1 - -
FDP_SDI.2 - -
FDP_UCT.1 FTP_ITC.1, FDP_ACC.1/KEY Yes
FDP_UIT.1 FTP_ITC.1, FDP_ACC.1/KEY Yes
FIA_AFL.1/PIN FIA_UAU.1 Yes
FIA_AFL.1/KEY FIA_UAU.1 Yes
FIA_ATD.1 - -
FIA_UAU.1 FIA_UID.1 Yes
FIA_UAU.5 - -
FIA_UID.1 - -
FMT_MSA.1/TAC FDP_ACC.1/TAC, FMT_SMF.1/PIN,
FMT_SMR.1
Yes
FMT_MSA.1/KEY FDP_ACC.1/KEY, FMT_SMF.1/KEY,
FMT_SMR.1
Yes
FMT_MSA.2 FDP_ACC.1/TAC, FDP_ACC.1/KEY,
FMT_MSA.1/TAC, FMT_MSA.1/KEY,
FMT_SMR.1
Yes
FMT_MSA.3/TAC FMT_MSA.1/TAC, FMT_SMR.1 Yes
FMT_MSA.3/KEY FMT_MSA.1/KEY, FMT_SMR.1 Yes
FMT_MTD.1 FMT_SMF.1/PIN, FMT_SMR.1 Yes
FMT_SMF.1/PIN - -
FMT_SMF.1/KEY - -
FMT_SMR.1 FIA_UID.1 Yes
FPT_EMAN.1 -
FPT_FLS.1 - -
FPT_PHP.1 - -
FPT_PHP.3 - -
FPT_TST.1 - -
FTP_ITC.1 - -
6.3.4 Appropriateness of TOE assurance requirements
751
The assurance level for this protection profile is EAL4 augmented. EAL4 allows a developer
752
to attain a reasonably high assurance level without the need for highly specialized processes
753
and practices.
754
It is considered to be the highest level that could be applied to an existing product line without
755
undue expense and complexity. As such, EAL4 is appropriate for commercial products that
756
can be applied to moderate to high security functions.
757
The TOE described in this protection profile is just such a product. Augmentation results from
758
the selection of:
759
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 33
AVA_VAN.5 Advanced Methodical Vulnerability Analysis
760
The main function of the TOE is to protect the cryptographic key which is used to generate the
761
TAC. If an attacker would get knowledge of one or more of these keys, the whole financial
762
system in which the TOE is used may become insecure. Therefore it is reasonable to assume a
763
high attack potential for an attacker and to augment EAL 4 by AVA_VAN.5.
764
AVA_VAN.5 has the following dependencies:
765
• ADV_ARC.1 Security architecture description
766
• ADV_FSP.2 Security-enforcing functional specification
767
• ADV_IMP.1 Implementation representation of the TSF
768
• ADV_TDS.3 Basic modular design
769
• AGD_PRE.1 Preparative procedures
770
• AGD_OPE.1 Operational user guidance
771
All of these are met or exceeded in the EAL4 assurance package.
772
773
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 34
7 Appendix
774
7.1 Abbreviations
775
7.1.1 TOE related abbreviations
776
Abbreviation Explanation
AEF Active Elementary File
APDU Application Protocol Data Unit
ATM Automated Teller Machine
CD/ATM Cash Dispenser/Automated Teller Machine
DF Dedicated File
DFA Differential Fault Analysis
DPA Differential Power Attack
ECB Electronic Codebook
EEPROM Electrical Erasable Programmable Read Only Memory
EF Elementary File
ES Embedded Software
FISC Financial Information Services CO., LTD.
ICC Integrated Circuit Controller
ID Identification
ITSEC Information Technology Security Evaluation Criteria
LC Life Cycle
LRC Longitudinal Redundancy Check
MF Master File
NEF Neutral Elementary File
P-Code Process Code
PIN Personal Identification Number
ROM Read-Only Memory
TAC Transaction Authentication Code
SPA Simple Power Analysis
MAC Message Authentication Code
Table 7: TOE related abbreviations
777
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 35
7.1.2 CC related abbreviations
778
Abbreviation Explanation
ST Security Target
TOE Target of evaluation
PP Protection Profile
SFP Security Function Policy
SF Security Function
SOE Security Objectives for the Environment
TSF TOE Security Functionality
Table 8: CC related abbreviations
779
BAROC CC 3.1 Smart Card Protection Profile Version: 1.0 page 36
7.2 Glossary
780
(No glossary is needed for this PP)
781
7.3 References
782
[BAROC_CARD_SPEC] BAROC Smart Card Specification, June 2004, Version
783
2.0 (in Chinese language, original title:
784
, 93 6 , 2.0 )
785
[BAROC_LETTER] BAROC Official Letter No. NBA0917, 21 April 2003 (in
786
Chinese language, original title:
787
, 0917 , 92 4 21
788
)
789
[CC] Common Criteria for Information Technology Security
790
Evaluation, version 3.1, revision 2, September 2007
791
Part 1: Introduction and general model, CCMB-2006-09-
792
001,
793
Part 2: Security functional components, CCMB-2007-09-
794
002,
795
Part 3: Security assurance components, CCMB-2007-09-
796
003.
797
[CEM] Common Methodology for Information Technology
798
Security Evaluation – Evaluation methodology, version
799
3.1, revision 2, September 2007, CCMB-2007-09-004.
800
[SSCD] Secure Signature Creation Device Protection Profile,
801
Type 2, ESIGN Workshop - Expert Group F, Version
802
1.04, July 2001
803
[FIPS_A] FIPS PUB 140-2 Annex A: Approved Security
804
Functions, Draft Version, May 19th 2005
805
806