Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 1
Security Target for BAROC/FISC TSAM 1.0
1
2
File Name: ST_FISCTSAM_1.0.0
3
Version: 1.0.0
4
Date: 2008-05-21
5
Authors: BAROC & FISC
6
TOE / TOE Version: BAROC/FISC TSAM 1.0
7
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 2
Table of Contents
8
TABLE OF CONTENTS................................................................................................................................ 2
9
LIST OF FIGURES AND TABLES............................................................................................................... 4
10
1 ST INTRODUCTION............................................................................................................................ 5
11
1.1 ST IDENTIFICATION......................................................................................................................... 5
12
1.2 ST OVERVIEW ................................................................................................................................ 5
13
1.3 CC CONFORMANCE CLAIMS ............................................................................................................ 6
14
2 TOE DESCRIPTION ............................................................................................................................ 7
15
2.1 OVERVIEW...................................................................................................................................... 7
16
2.2 TOE DEFINITION............................................................................................................................. 7
17
2.3 TOE BOUNDARIES .......................................................................................................................... 8
18
2.3.1 TOE Physical Scope and Boundary ............................................................................................ 8
19
2.3.2 TOE Logical Scope and Boundary.............................................................................................. 8
20
2.4 TOE LIFE CYCLE ............................................................................................................................ 9
21
2.5 ROLES .......................................................................................................................................... 10
22
3 TOE SECURITY ENVIRONMENT................................................................................................... 12
23
3.1 ASSETS......................................................................................................................................... 12
24
3.1.1 GlobalPlatform Keys (GPKs)................................................................................................... 12
25
3.1.2 Management Key (MK)............................................................................................................ 12
26
3.1.3 Working Keys (WKs)................................................................................................................ 12
27
3.1.4 Terminal Management Data (TMD) ......................................................................................... 12
28
3.1.5 Retry Counter (RC).................................................................................................................. 13
29
3.1.6 Life Cycle State (LCS).............................................................................................................. 13
30
3.1.7 Transaction Data (TD)............................................................................................................. 13
31
3.2 ASSUMPTIONS (ABOUT THE ENVIRONMENT) ................................................................................... 13
32
3.3 THREATS ...................................................................................................................................... 14
33
3.3.1 Threats not contained in [JCOP41V231ST].............................................................................. 15
34
3.3.2 Threats from [JCOP41V231ST] ............................................................................................... 15
35
3.4 ORGANISATIONAL SECURITY POLICIES (OSP) ................................................................................ 19
36
3.4.1 OSPs not contained in [JCOP41V231ST]................................................................................. 19
37
3.4.2 OSPs from [JCOP41V231ST] .................................................................................................. 19
38
4 SECURITY OBJECTIVES................................................................................................................. 20
39
4.1 SECURITY OBJECTIVES FOR THE TOE............................................................................................. 20
40
4.1.1 Security Objectives not contained in [JCOP41V231ST]............................................................ 20
41
4.1.2 Security Objectives from [JCOP41V231ST] ............................................................................. 21
42
4.2 SECURITY OBJECTIVES FOR THE ENVIRONMENT ............................................................................. 24
43
4.2.1 Security Objectives for The Environment not contained [JCOP41V231ST] ............................... 24
44
4.2.2 Security Objectives for the Environment from [JCOP41V231ST].............................................. 25
45
5 SECURITY REQUIREMENTS.......................................................................................................... 26
46
5.1 TOE SECURITY FUNCTIONAL REQUIREMENTS NOT CONTAINED IN [JCOP41V231ST]...................... 26
47
5.1.1 Cryptographic support (FCS)................................................................................................... 26
48
5.1.2 User data protection (FDP) ..................................................................................................... 26
49
5.1.3 Identification and authentication (FIA)..................................................................................... 28
50
5.1.4 Security management (FMT).................................................................................................... 30
51
5.1.5 Trusted path/channels (FTP).................................................................................................... 30
52
5.2 TOE SECURITY FUNCTIONAL REQUIREMENTS FROM [JCOP41V231ST].......................................... 31
53
5.3 TOE SECURITY ASSURANCE REQUIREMENTS ................................................................................. 33
54
5.4 IT ENVIRONMENT SECURITY REQUIREMENTS NOT CONTAINED IN [JCOP41V231ST]....................... 33
55
5.4.1 Cryptographic key generation.................................................................................................. 34
56
5.4.2 User data protection ................................................................................................................ 34
57
5.4.3 Trusted path/channels.............................................................................................................. 34
58
5.5 IT ENVIRONMENT SECURITY REQUIREMENTS FROM [JCOP41V231ST]........................................... 35
59
6 TOE SUMMARY SPECIFICATION ................................................................................................. 36
60
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 3
6.1 SECURITY FUNCTIONS................................................................................................................... 36
61
6.2 STRENGTH OF FUNCTION CLAIMS .................................................................................................. 39
62
6.3 ASSURANCE MEASURES ................................................................................................................ 40
63
7 PP CLAIMS......................................................................................................................................... 41
64
7.1 PP REFERENCE.............................................................................................................................. 41
65
7.2 PP ADDITIONS AND REFINEMENTS................................................................................................. 41
66
8 RATIONALE....................................................................................................................................... 42
67
8.1 SECURITY OBJECTIVES RATIONALE ............................................................................................... 42
68
8.1.1 Traceability of the Security Objectives...................................................................................... 42
69
8.1.2 Coverage of the assumptions.................................................................................................... 43
70
8.1.3 Countering of the threats.......................................................................................................... 43
71
8.1.4 Coverage of the Organizational Security Policies..................................................................... 43
72
8.1.5 Security Objectives Rationale from [JCOP41V231ST].............................................................. 44
73
8.2 SECURITY REQUIREMENTS RATIONALE.......................................................................................... 45
74
8.2.1 Fulfilment of security objectives............................................................................................... 45
75
8.2.2 Traceability of the Security Functional Requirements............................................................... 47
76
8.2.3 Suitability of Security Assurance Requirements ........................................................................ 48
77
8.2.4 Fulfillment of dependencies...................................................................................................... 48
78
8.2.5 Suitability of minimum strength of function (SoF) level............................................................. 49
79
8.3 TOE SUMMARY SPECIFICATION RATIONALE .................................................................................. 50
80
8.3.1 Traceability and Satisfaction of the TOE SFRs ......................................................................... 50
81
8.3.2 Mutual Support of the Security Functions................................................................................. 57
82
8.3.3 Validity of SOF-claims............................................................................................................. 58
83
8.3.4 Compliance of assurance measures.......................................................................................... 58
84
8.4 PP CLAIMS RATIONALE................................................................................................................. 58
85
8.4.1 PP Conformance concerning Assumptions................................................................................ 58
86
8.4.2 PP Conformance concerning Threats....................................................................................... 58
87
8.4.3 PP Conformance concerning Organizational Security Policies................................................. 58
88
8.4.4 PP Conformance concerning Security Objectives for the TOE .................................................. 58
89
8.4.5 PP Conformance concerning Security Objectives for the Environment...................................... 59
90
8.4.6 PP Conformance concerning SFRs for the TOE........................................................................ 59
91
8.4.7 PP Conformance concerning SARs........................................................................................... 59
92
8.4.8 PP Conformance concerning SFRs for the IT Environment....................................................... 59
93
9 APPENDIX.......................................................................................................................................... 61
94
9.1 ABBREVIATIONS ........................................................................................................................... 61
95
9.2 REFERENCES................................................................................................................................. 62
96
97
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 4
List of Figures and Tables
98
Figure 2-1: The TOE architecture 8
99
Figure 2-2: TOE life cycle 9
100
Table 3-1: Threats from [JCOP41V231ST] 16
101
Table 4-1: Security objectives from [JCOP41V231ST] 21
102
Table 4-2: Security objectives for the environment from [JCOP41V231ST] 25
103
Table 5-1: Actions on detection of integrity errors 28
104
Table 5-2: TOE SFRs from [JCOP41V231ST] 32
105
Table 5-3: Evaluation Assurance Requirements 33
106
Table 5-4: IT Environment SFRs from [JCOP41V231ST] 35
107
Table 8-1: Security objectives rationale 42
108
Table 8-2: Security objectives rationale from [JCOP41V231ST] 44
109
Table 8-3: Security requirements rationale 45
110
Table 8-4: Fulfillment of TOE SFR dependencies 49
111
Table 8-5: TSS rationale 50
112
Table 8-6: Traceability and Satisfaction of the TOE SFRs 56
113
Table 8-7: Analysis of Mutual Support of the SFs 57
114
Table 8-8: Coverage of Assumptions from [JCSPP] “Minimal Configuration” 58
115
Table 8-9: Coverage of Environment Security Objectives from [JCSPP] 59
116
Table 8-10: Coverage of IT Environment SFRs from [JCSPP] 60
117
118
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 5
1 ST Introduction
119
1.1 ST Identification
120
Title: Security Target for BAROC/FISC TSAM 1.0
121
TOE: BAROC/FISC TSAM 1.0
122
Guidance: Administrator and User Guidance for BAROC/FISC TSAM
123
1.0, version 1.0.0, date: 2008-05-21 BAROC/FISC
124
SHA-1 hash value of the PDF version:
125
94db00658c87902818433487eed82a88d8408114
126
Document Version: 1.0.0
127
Document Date: 2008-05-21
128
Author: BAROC & FISC
129
CC version used: CC V2.3, CEM V2.3, including all corresponding FIs, as
130
applicable
131
CC Conformance: Conformant to CC V2.3 part 2 extended and conformant to
132
CC V2.3 part 3 augmented (EAL4 augmented by
133
ADV_IMP.2 and AVA_VLA.4)
134
Certification ID: BSI-DSZ-CC-0442
135
Evaluation Body: TÜViT GmbH, Germany
136
Certification Body: BSI, Germany
137
1.2 ST Overview
138
After a successful chip migration of ATM cards in 2005 for conventional online
139
transactions of cash withdrawal and fund transfer via ATM in Taiwan, FISC
140
would in addition like to promote the debit solution for point of sales (POS) with
141
the chip ATM cards. For this to be done, the confidentiality and integrity of data
142
transfer between a POS terminal and its acquiring bank must be assured as a
143
prerequisite. FISC therefore comes up with the development of TSAM (Terminal
144
Security Access Module), the TOE, to be used by POS terminals to ensure the
145
confidentiality and integrity of data transfer. The TOE is composed of a
146
JavaCard applet (TSAM applet) and NXP P541G072V0P smart card controller
147
(the latter consists of JCP (JavaCard Platform) and SCP (Smart Card
148
Platform)). This security target is for the composite TSAM TOE.
149
150
The main objectives of this security target are:
151
• To describe the security environment of the TOE including assets to be
152
protected and threats to be countered by the TOE and its environment.
153
• To describe the security objectives of the TOE and its environment.
154
• To specify the security requirements, which include the TOE security
155
functional requirements as of CC part 2 and the assurance requirements as
156
of CC part 3.
157
• To setup the TOE summary specification that includes the TOE security
158
function specifications and the assurance measures.
159
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 6
1.3 CC Conformance Claims
160
This ST is claimed to be conformant with the Common Criteria Version 2.3
161
([CC]):
162
• Security functional requirements are conformant to CC Part 2 extended
163
(extended requirements have been introduced for the underlying platform in
164
[JCOP41V231]).
165
• Security assurance requirements are conformant to CC Part 3 augmented:
166
EAL4 augmented by AVA_VLA.4 (highly resistant) and ADV_IMP.2
167
(implementation of the TSF).
168
The minimum strength level of the TOE security functions is SOF-high.
169
Concerning the use of random numbers additionally conformance to [AIS20],
170
class K3, SOF-high is claimed ([JCOP41V231ST] already does so for the
171
underlying platform).
172
This Security Target claims conformance to [JCSPP], Minimal Configuration
173
([JCOP41V231ST] already does so for the underlying platform).
174
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 7
2 TOE Description
175
2.1 Overview
176
TSAM, the TOE, is short for Terminal Security Access Module and, as its name
177
implies, TSAM helps secure transactions in-between POS terminal and the
178
remote host application in a way that it assures integrity, authenticity and
179
confidentiality of POS transactions by encryption, decryption and MAC
180
generation. The functions of TSAM come as follows.
181
1. TSAM is provisioned with a management key, an encryption key, a
182
decryption key and a MAC generation key.
183
2. POS terminal is equipped with a TSAM in one of its slots. The terminal asks
184
for data encryption from TSAM when it is submitting a transaction to the
185
remote host. The terminal performs encryption of sensitive part of the
186
transaction message by sending it to TSAM via "Data Encryption by
187
Working Key" command and TSAM responds with encrypted datagram. The
188
terminal can also perform decryption of encrypted part of the received
189
transaction message by sending it to TSAM via "Data Decryption by
190
Working Key" command and TSAM responds with decrypted result.
191
3. By using TSAM, the terminal calculates MAC for each transaction. The
192
terminal prepares the transaction representation from the transaction
193
message and sends the transaction representation to TSAM via "Generate
194
MAC by Working Key" command. TSAM responds with a MAC over the
195
data it receives from its interface.
196
4. TSAM is managed by the remote host, which means the management key
197
and working keys (encryption, decryption and MAC) are subject to be
198
changed over time via online transaction. The key management must be
199
secure, and therefore, there is a unique management key for each TSAM
200
so that the remote host can assure the integrity, confidentiality and, of
201
course, authenticity of the key management process.
202
To sum up, the security relevant functions provided by TSAM help the remote
203
host to assure that every transaction comes from a terminal, equipped with an
204
authentic TSAM, is kept confidential and is not modified.
205
2.2 TOE Definition
206
The TOE is composed of a JavaCard applet (TSAM applet) and NXP
207
P541G072V0P smart card controller ([JCOP41V231]), see Figure 2-1. While
208
JCP (JavaCard Platform) resides in ROM, the “TSAM Applet” resides in
209
EEPROM of [JCOP41V231].
210
[JCOP41V231] has been evaluated before as referred to [JCOP41V231ST] and
211
the respective certification report (BSI-DSZ-CC-0426). The TSAM applet is
212
loaded and installed into [JCOP41V231], and therefore, the TOE is a
213
composition of the TSAM applet and [JCOP41V231]. The GlobalPlatform keys
214
necessary for applet management are not delivered together with the TOE,
215
therefore it will not be possible to delete the TSAM applet from or install
216
additional applets into the smart card controller after delivery.
217
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 8
219
221
223
Figure 2-1: The TOE architecture
224
225
More information about the structure of JCP (JavaCard Platform) and SCP
226
(Smart Card Platform) can be found in [JCOP41V231ST].
227
2.3 TOE Boundaries
228
2.3.1 TOE Physical Scope and Boundary
229
The physical boundary of the TOE is represented by the surface of
230
[JCOP41V231]. This surface and the embedded physical interface are
231
compliant to ISO 7816 part 2.
232
While JCP (JavaCard Platform) resides in ROM, the TSAM applet resides in
233
EEPROM of [JCOP41V231].
234
[JCOP41V231] provides different external interfaces and corresponding
235
protocols. In the TOE only the contact interface and only the corresponding
236
protocol T=1 are available. Contactless interface and USB 2.0 interface
237
implementations of [JCOP41V231] are physically present in the TOE, but are
238
not usable, as these interfaces are not contacted and as the corresponding
239
protocols T=CL, MIFARE and USB protocol are disabled in the TOE (disabled
240
MIFARE part physically present in [JCOP41V231] is not shown in Figure
241
2-1.hereinabove).
242
In broadest sense also the guidance documentation can be seen as part of the
243
physical scope of the TOE (see section 1.1 hereinbefore for a detailed
244
reference).
245
2.3.2 TOE Logical Scope and Boundary
246
The TOE logical interface is represented by a set of APDU commands which
247
are compliant to ISO 7816 part 4 (augmented with additional commands). At
248
its logical boundary, the TOE provides functions of encryption, decryption,
249
MAC generation and secure key updates.
250
The TOE provides the following security functionalities:
251
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 9
• encryption, decryption and MAC generation,
252
• user authentication,
253
• confidentiality and integrity protection of communication data,
254
• access control,
255
• life cycle management,
256
• stored data integrity protection, and
257
• increments of serial numbers.
258
2.4 TOE Life Cycle
259
IC Packaging &
Testing
Development of
FISC TSAM Applet
IC Manufacturing &
Testing
TSAM.Phase_1
Usage
(This phase and previous phase together correspond to the Smartcard End-
Usage phase of ST of Phillips P541G072V0P )
Applet Loading & Initializing
(This phase corresponds to the Smartcard Product Finishing Process phase
except embedding in Smartcard Personalization phase of ST of Phillips
P541G072V0P )
Personalization
(This phase and following phase together correspond to the Smartcard End-
Usage phase of ST of Phillips P541G072V0P )
IC Development
Smartcard Embedded
Software Development
Platform.Phase_1
TSAM.Phase_4
TSAM.Phase_3
TSAM.Phase_2
Platform.Phase_4
Platform.Phase_3
Platform.Phase_2
Smartcard Product
Finishing
(embedding only)
Platform.Phase_5
260
Figure 2-2: TOE life cycle
261
Figure 2-2 shows development phases and operation phases of the TSAM TOE.
262
Each of the phases is described as follows:
263
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 10
Platform.Phase_1: This phase corresponds to the Smartcard Embedded
264
Software Development phase of [JCOP41V231ST].
265
Platform.Phase_2: This phase corresponds to the IC Development phase of
266
[JCOP41V231ST].
267
Platform.Phase_3: This phase corresponds to the IC Manufacturing and Test
268
phase of [JCOP41V231ST].
269
Platform.Phase_4: This phase corresponds to the IC Packaging and Test of
270
[JCOP41V231ST].
271
Platform.Phase_5: This phase corresponds to the embedding part of the
272
Smartcard Product Finishing Process phase of [JCOP41V231ST]. Embedded
273
smartcard products, together with the GlobalPlatform keys, are delivered to the
274
TSAM production site in TSAM.Phase_2.
275
TSAM.Phase_1: This phase consists of the development of the TSAM applet
276
which is to be loaded and installed into [JCOP41V231]. GlobalPlatform keys of
277
[JCOP41V231] are needed for performing the loading and installing of the
278
TSAM applet. TSAM applet is delivered to the TSAM production site in
279
TSAM.Phase_2.
280
TSAM.Phase_2: This phase, together with Platform.Phase_5, corresponds to
281
the Smartcard Product Finishing Process phase of [JCOP41V231ST]. It
282
consists of the process for loading, installing and initializing the TSAM applet
283
with GlobalPlatform keys. This is done at the production site. After loading and
284
installation of the TSAM applet, the TOE is completed and its security
285
functionality is operative. During subsequent initialization, which is already
286
under control of TSAM’s security functionality, the initial management key is
287
written, which is necessary for personalization. The initialized TOE and the
288
corresponding initial management key are delivered to the TSAM issuer site
289
(see TSAM.Phase_3).
290
TSAM.Phase_3: This phase, together with TSAM.Phase_4, corresponds to the
291
Smartcard End-usage phase of [JCOP41V231ST]. It consists of personalization
292
process of TSAM by the issuer, which includes doing the mandatory first update
293
of the management key and writing of terminal management data. The process
294
is done at TSAM issuer site.
295
TSAM.Phase_4: This phase, together with TSAM.Phase_3, corresponds to the
296
Smartcard End-usage phase of [JCOP41V231ST]. At this phase, POS terminal
297
uses TSAM for security operations. The TSAM issuer, at this phase, can do
298
update of the management key and writes of working keys.
299
2.5 Roles
300
R.Initializer: This is the role that instantiates and initializes the TSAM TOE.
301
This role belongs to the production environment of the TOE, nevertheless,
302
initialization of the management key is already controlled by TOE functionality.
303
R.Issuer: This is the user who issues TOE and performs management of the
304
management key, working keys and terminal management data.
305
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 11
R.POS_Terminal: This is the device that uses the TOE for data encryption,
306
decryption and MAC generation for POS transactions. The user guidance for
307
this role will be addressed to the developer of the POS terminal.
308
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 12
3 TOE Security Environment
309
3.1 Assets
310
The TSAM applet corresponds to D.APP_CODE asset of the ST of NXP
311
P541G072V0P [JCOP41V231ST].
312
The following assets are corresponding to D.APP_C_DATA (confidential
313
sensitive data of the TSAM applet), D.APP_I_DATA (integrity sensitive data of
314
the TSAM applet) and D.APP_KEYS (cryptographic keys owned by the TSAM
315
applet) of [JCOP41V231ST].
316
3.1.1 GlobalPlatform Keys (GPKs)
317
GlobalPlatform keys are 3/DES keys that are used by R.Initializer to protect
318
loading and installing of the TSAM applet by security functionalities of
319
[JCOP41V231].
320
GPKs also protect initialize of management key (see section 3.1.2 below). This
321
takes place during production; nevertheless, it is already controlled by security
322
functionalities of the TOE.
323
The TOE has to maintain the integrity and confidentiality of GPKs (this is
324
solely provided by functionality of [JCOP41V231]).
325
GPKs are not delivered with the TOE.
326
3.1.2 Management Key (MK)
327
Management key is a 3/DES key that’s used by R.Issuer to protect writes of
328
working keys (see section 3.1.3 below) and key updates of MK itself. It
329
protects key updates and writes in a way that the confidentiality, integrity and
330
authenticity are assured. MK also protects writes of terminal management data
331
(see section 3.1.4 below) of the TOE in a similar way that the integrity and
332
authenticity of the data are assured.
333
MK is written into the EEPROM of [JCOP41V231] in TSAM.Phase_2. It can be
334
updated in TSAM.Phase_3 and TSAM.Phase_4. The TOE has to maintain the
335
integrity and confidentiality of MK.
336
3.1.3 Working Keys (WKs)
337
Working keys are 3/DES keys that are stored in the EEPROM of
338
[JCOP41V231]. There are three WKs in the TOE, which are encryption key,
339
decryption key and MAC generation key. The R.POS_Terminal requests for
340
cryptographic services supported by the TOE to encrypt, decrypt and/or
341
generate MACs over transaction data (see section 3.1.7) by the encryption key,
342
decryption key and/or MAC generation key, respectively.
343
WKs can be written during TSAM.Phase_4. The TOE has to maintain the
344
integrity and confidentiality of any of the WKs.
345
3.1.4 Terminal Management Data (TMD)
346
TMD is composed of a merchant identifier (MID), a terminal identifier (TID), a
347
transaction serial number (TSN) and a batch settlement number (BSN).
348
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 13
TMD is stored in the EEPROM of [JCOP41V231] in TSAM.Phase_3. In
349
TSAM.Phase_4, TMD can be read out of the TOE, and TSN and BSN can be
350
incremented.
351
The TOE has to ensure the integrity of TMD during writes and storage.
352
3.1.5 Retry Counter (RC)
353
This is TSF data which is the counter for accumulative consecutive failure
354
attempts of external authentication with MK. Whenever RC reaches 3, no
355
further attempts of external authentication with MK will be allowed. In this case,
356
there is no way to reset RC. The integrity of RC must be maintained by the
357
TOE.
358
3.1.6 Life Cycle State (LCS)
359
This is TSF data which is used to manage life cycle state of the TOE. The life
360
cycle state of the TOE starts from TSAM.Phase_2, changes to
361
TSAM.Phase_3 and finally changes to TSAM.Phase_4 subsequently. The
362
change of the life cycle state is irreversible. The integrity of LCS must be
363
maintained by the TOE.
364
3.1.7 Transaction Data (TD)
365
This is user data that the TOE receives from its interface. The data can be
366
subject to encryption, decryption, or MAC generation with the corresponding
367
WK. The data is not stored permanently in the TOE.
368
3.2 Assumptions (about the environment)
369
The following set of assumptions incorporates those assumptions made in
370
[JCOP41V231ST], which are still relevant for this composite TOE. Some of the
371
assumptions made in [JCOP41V231ST] are covered by development and
372
production of TSAM and are therefore not listed here. Please see remarks after
373
list of assumptions below and PP claims rationale in section 8.4 hereinafter.
374
A.DLV Delivery of TOE and its guidance documents
375
It is assumed that R.Issuer and the developer of the R.POS_Terminal verify the
376
hash values of their guidance documents to assure a secure delivery of it. It is
377
also assumed that R.Issuer will only issue the TOE after a correct MAC
378
verification of the delivered management key.
379
A.USE_DIAG Use of secure communication protocols
380
It is assumed that the environment supports and uses secure communication
381
protocols offered by the TOE.
382
A.KEYS Key protection and key quality
383
The management key and working keys which are stored and processed
384
outside the TOE during personalization and usage phases are assumed to be
385
protected for confidentiality and integrity.
386
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 14
Cryptographic keys created in the environment to be used within the TOE have
387
to have sufficient quality (e.g. by using a random number generator for key
388
generation).
389
A.DEV Development security
390
It is assumed that no native codes will be loaded into [JCOP41V231] during
391
development and production phases of the TOE. During development, byte
392
code verification will be performed on the TSAM applet. During production, only
393
TSAM applet will be installed. GlobalPlatform keys are not delivered to R.Issuer
394
and R.POS_Terminal.
395
It is also assumed that TOE development and test information during
396
TSAM.Phase_1 and TSAM.Phase_2 is protected in a secure environment for its
397
integrity and confidentiality. In case of delivery between different actors like
398
applet developers and applet installers, this information is also protected in the
399
same manner as aforementioned.
400
Remarks:
401
l A.DLV covers the assumption A.DLV_PROTECT of [JCOP41V231ST]
402
because the procedures addressed in A.DLV_PROTECT are mostly covered
403
by evaluation of development security, configuration management and
404
delivery for the TOE. A.DLV assumes the remaining responsibilities of the
405
users of the TOE to ensure a complete secure delivery process.
406
l A.TEST_OPERATE of [JCOP41V231ST] is completely covered by the
407
evaluation of development security, configuration management and delivery
408
for the TOE because the development and production of the TOE covers
409
phases of 4, 5 and 6 of [JCOP41V231ST].
410
l A.USE_DIAG is a mere re-statement of the assumption A.USE_DIAG of
411
[JCOP41V231ST].
412
l A.KEYS directly covers the assumption A.USE_KEYS of [JCOP41V231ST]
413
with additional refinements and extensions.
414
l A.NATIVE of [JCOP41V231ST] is covered by A.DEV because in the scope of
415
the TSAM production and operation no native code will be loaded into the
416
smart card controller.
417
l A.NO-DELETION and A.NO-INSTALL of [JCOP41V231ST] are covered by
418
A.DEV because the necessary GlobalPlatform keys are not delivered to the
419
R.Issuer and the R.POS_Terminal (or its developer), therefore it will not be
420
possible to delete the TSAM applet from or install additional applets into the
421
smart card controller.
422
l A.VERIFICATION of [JCOP41V231ST] is covered by A.DEV because byte
423
code verification will be performed during the development/production.
424
3.3 Threats
425
This section introduces the threats to the assets against which specific protection
426
within the TOE or its environment is required. It is assumed that all attackers have
427
high level of expertise, opportunity and resources. In [JCOP41V231ST], general
428
threats for smart card native operating systems were defined and supplemented by
429
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 15
Java Card specific threats from [JCSPP] (see section 3.3.2). Additionally in section
430
3.3.1 hereinafter the TSAM-specific threats are listed.
431
3.3.1 Threats not contained in [JCOP41V231ST]
432
T.INTEGRITY Integrity of security relevant data
433
An attacker or memory errors may change MK, WK, TMD, LCS and RC in
434
storage without the TOE being able to detect it, which leads to usage of
435
corrupted data.
436
T.TMD_ACCESS Access to terminal management data
437
An unauthorized user, other than R.Issuer, may perform writes of TMD. One
438
possibility would be that the unauthorized user records authorized update of
439
TMD during communication and resends it to the TOE (replay attack).
440
The TMD of an authorized update may be modified during communication but
441
the TOE does not detect the modification.
442
T.KEY_ACCESS Access to MK and WK
443
An unauthorized user, other than R.Initializer, may perform initialize of MK. An
444
unauthorized user, other than R.Issuer, may perform updates of MK or writes
445
of WKs. One possibility would be that the unauthorized user records
446
authorized initialize and updates of MK or writes of WK during communication
447
and resends them to the TOE (replay attack).
448
The MK or WKs of an authorized initialize, update or write may be modified
449
during communication but the TOE does not detect the modification.
450
An attacker may eavesdrop on the MK or WK during communication to get the
451
key value that’s being used by the TOE. An attacker or a user may try to read
452
the MK or WKs from the TOE’s user visible interfaces. An attacker may also
453
try to gain previous values of MK or WKs from the TOE.
454
3.3.2 Threats from [JCOP41V231ST]
455
The following threats have already been regarded during development and
456
manufacturing of [JCOP41V231] as confirmed by the corresponding
457
evaluation.
458
The threats listed here are just a brief summary. For corresponding
459
explanation and application note, please see [JCOP41V231ST].
460
Table 3-1 identifies the threats that are found in [JCOP41V231ST]. The
461
Source column of the table indicates the source protection profile, if there is
462
any, in which the corresponding threat is specified. The Life-Cycle column of
463
the table indicates the phases of the TOE life cycle in which the corresponding
464
threat can take place. Detailed explanation of the phases can be found in
465
section 2.4.
466
Name Source Life-Cycle
T.DEV_IC - Platform.Phase_2, Platform.Phase_3
T.DEV_NOS - Platform.Phase_1
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 16
Name Source Life-Cycle
T.DEL_IC_NOS - Platform.Phase_1, Platform.Phase_2
T.DEL - Platform.Phase_4, TSAM.Phase_2
T.ACCESS_DATA - TSAM.Phase_3, TSAM.Phase_4
T.OS_OPERATE - TSAM.Phase_3, TSAM.Phase_4
T.OS_DECEIVE - TSAM.Phase_3, TSAM.Phase_4
T.LEAKAGE - TSAM.Phase_3, TSAM.Phase_4
T.FAULT - TSAM.Phase_3, TSAM.Phase_4
T.RND [PP0002] TSAM.Phase_3, TSAM.Phase_4
T.PHYSICAL [JCSPP] TSAM.Phase_3, TSAM.Phase_4
T.CONFID-JCS-CODE [JCSPP] TSAM.Phase_3, TSAM.Phase_4
T.CONFID-APPLI-DATA [JCSPP] TSAM.Phase_3, TSAM.Phase_4
T.CONFID-JCS-DATA [JCSPP] TSAM.Phase_3, TSAM.Phase_4
T.INTEG-APPLI-CODE [JCSPP] TSAM.Phase_3, TSAM.Phase_4
T.INTEG-JCS-CODE [JCSPP] TSAM.Phase_3, TSAM.Phase_4
T.INTEG-APPLI-DATA [JCSPP] TSAM.Phase_3, TSAM.Phase_4
T.INTEG-JCS-DATA [JCSPP] TSAM.Phase_3, TSAM.Phase_4
T.SID.1 [JCSPP] TSAM.Phase_3, TSAM.Phase_4
T.SID.2 [JCSPP] TSAM.Phase_3, TSAM.Phase_4
T.EXE-CODE.1 [JCSPP] TSAM.Phase_3, TSAM.Phase_4
T.EXE-CODE.2 [JCSPP] TSAM.Phase_3, TSAM.Phase_4
T.NATIVE [JCSPP] TSAM.Phase_3, TSAM.Phase_4
T.RESOURCES [JCSPP] TSAM.Phase_3, TSAM.Phase_4
Table 3-1: Threats from [JCOP41V231ST]
467
T.DEV_IC
468
Theft, modification, disclosure of information related to IC development and
469
manufacturing.
470
T.DEV_NOS
471
Theft, modification, or disclosure of NOS related information during NOS
472
development.
473
T.DEL_IC_NOS
474
Theft, modification, disclosure of information related to IC or NOS during
475
delivery between IC manufacturer and NOS Developer.
476
T.DEL
477
Theft, modification, disclosure of information related to TOE during delivery to
478
IC packaging manufacturer or Smart Card manufacturer or personalizer.
479
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 17
T.ACCESS_DATA
480
Unauthorized access to sensitive information stored in memories in order to
481
disclose or to corrupt the TOE data (TSF and user data).
482
T.OS_OPERATE
483
Modification of the correct NOS behavior by unauthorized use of TOE or use
484
of incorrect or unauthorized instructions or commands or sequence of
485
commands, in order to obtain an unauthorized execution of the TOE code.
486
T.OS_DECEIVE
487
Modification of the expected TOE configuration by
488
o unauthorized loading of code,
489
o unauthorized execution of code
490
o unauthorized modification of code behavior
491
T.LEAKAGE
492
An attacker may exploit information which is leaked from the TOE during
493
usage of the Smart Card in order to disclose the confidential primary assets.
494
T.FAULT
495
An attacker may cause a malfunction of TSF or of the Smart Card embedded
496
NOS by applying environmental stress in order to (1) deactivate or modify
497
security features or functions of the TOE or (2) deactivate or modify security
498
functions of the Smart Card embedded NOS. This may be achieved by
499
operating the Smart Card outside the normal operating conditions
500
T.RND
501
Deficiency of Random Numbers: An attacker may predict or obtain information
502
about random numbers generated by the TOE for instance because of a lack
503
of entropy of the random numbers provided.
504
T.PHYSICAL
505
The attacker discloses or modifies the design of the TOE, its sensitive data
506
(TSF and User Data) or application code or disables security features of the
507
TOE using pure invasive, physical (opposed to logical) attacks on the
508
hardware part of the TOE.
509
T.CONFID-JCS-CODE
510
The attacker executes an application without authorization to disclose the Java
511
Card System code.
512
T.CONFID-APPLI-DATA
513
The attacker executes an application without authorization to disclose data
514
belonging to another application.
515
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 18
T.CONFID-JCS-DATA
516
The attacker executes an application without authorization to disclose data
517
belonging to the Java Card System.
518
T.INTEG-APPLI-CODE
519
The attacker executes an application to alter (part of) its own or another
520
application’s code.
521
T.INTEG-JCS-CODE
522
The attacker executes an application to alter (part of) the Java Card System
523
code.
524
T.INTEG-APPLI-DATA
525
The attacker executes an application to alter (part of) another application’s
526
data.
527
T.INTEG-JCS-DATA
528
The attacker executes an application to alter (part of) Java Card System or
529
API data.
530
T.SID.1
531
An applet impersonates another application, or even the JCRE, in order to
532
gain illegal access to some resources of the card or with respect to the end
533
user or the terminal.
534
T.SID.2
535
The attacker modifies the identity of the privileged roles.
536
T.EXE-CODE.1
537
An applet performs an unauthorized execution of a method.
538
T.EXE-CODE.2
539
An applet performs an unauthorized execution of a method fragment or
540
arbitrary data.
541
T.NATIVE
542
An applet tries to execute a native method to bypass some security function
543
such as the firewall.
544
T.RESOURCES
545
An attacker prevents correct operation of the Java Card System through
546
consumption of some resources of the card: RAM or NVRAM.
547
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 19
3.4 Organisational Security Policies (OSP)
548
3.4.1 OSPs not contained in [JCOP41V231ST]
549
OSP.TXN_SECURE
550
The TOE has to provide a function to encrypt, decrypt or generate a MAC over
551
TD with the corresponding WK using 3/DES. No external authentication
552
against the TOE is necessary before the TOE’s performing such function.
553
OSP.SN
554
The TOE has to provide a function to increment TSN and/or BSN of TMD. The
555
increment of TSN and/or BSN shall not exceed specified limits. No external
556
authentication against the TOE is necessary before the TOE’s performing
557
such function.
558
3.4.2 OSPs from [JCOP41V231ST]
559
The following OSP has already been regarded during development and
560
manufacturing of [JCOP41V231] as confirmed by the corresponding
561
evaluation.
562
OSP.IC_ORG
563
Procedures dealing with physical, personnel, organizational, technical
564
measures for the confidentiality and integrity, of Smart Card Native Operating
565
System (e.g. source code mask and any associated documents) and IC
566
Manufacturer proprietary information (tools, software, documentation, dies ...)
567
shall exist and be applied in IC development and manufacturing .
568
Procedures shall also ensure the confidentiality and integrity and information
569
during exchange with the NOS developer.
570
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 20
4 Security Objectives
571
4.1 Security Objectives for the TOE
572
4.1.1 Security Objectives not contained in [JCOP41V231ST]
573
SO.KEY_ACCESS Secure access to MK and WKs
574
The TOE has to provide a secure mechanism for R.Initializer to initialize MK.
575
The TOE has to provide a secure mechanism for R.Issuer to perform updates
576
of MK and writes of WKs. This includes mechanisms to ensure the
577
confidentiality and integrity of the keys transferred to the TOE as well as the
578
authentication of R.Initializer or R.Issuer who sends the keys.
579
Nobody shall be able to read out the MK and WKs. The TOE shall provide
580
safe destruction techniques for the cryptographic keys in case of key updates.
581
SO.TMD_ACCESS Secure access to TMD
582
The TOE has to provide a secure mechanism for R.Issuer to write TMD. This
583
includes mechanisms to ensure the integrity of the TMD transferred to the
584
TOE as well as the authentication of R.Issuer who sends the TMD.
585
SO.REPLAY Replay protection in key access and TMD access
586
The TOE has to provide a secure mechanism to assure the same command
587
data used in MK initialize and update, WK write and TMD write cannot be used
588
successfully at the second time.
589
SO.TXN_SECURE Cryptographic algorithm security for TD
590
On request of R.POS_Terminal, the TOE uses 3/DES to encrypt, decrypt or
591
generate MAC over TD with the corresponding WK.
592
SO.SN Increments of TSN and BSN
593
On request of R.POS_Terminal, the TOE increments TSN and/or BSN of TMD
594
without exceeding specified limits.
595
SO.INTEGRITY Integrity error detection
596
The TOE protects RC, LCS and TMD in its storage against undetected
597
modifications by an attacker or due to memory errors. On detection of integrity
598
errors, the following actions shall be performed:
599
l Prohibit the use of the altered data.
600
l Inform the user about integrity errors.
601
Remark:
602
Integrity protection for MK and WKs is provided by [JCOP41V231] already, as
603
its key objects holding MK and WKs are integrity-protected (this is reflected by
604
O.PROTECT_DATA of [JCOP41V231ST], see following section).
605
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 21
4.1.2 Security Objectives from [JCOP41V231ST]
606
The following security objectives have already been regarded during
607
development and manufacturing of [JCOP41V231] as confirmed by the
608
corresponding evaluation.
609
The security objectives listed here are just a brief summary. For corresponding
610
explanation and application note, please see [JCOP41V231ST].
611
Table 4-1 identifies the security objectives that are found in [JCOP41V231ST].
612
The Source column of the table indicates the source protection profile, if there
613
is any, in which the corresponding security objective is specified.
614
Name Source Name Source
O.PROTECT_DATA - O.SHRD_VAR_CONFID [JCSPP]
O.SIDE_CHANNEL - O.SHRD_VAR_INTEG [JCSPP]
O.OS_DECEIVE - O.ALARM [JCSPP]
O.FAULT_PROTECT - O.TRANSACTION [JCSPP]
O.PHYSICAL - O.CIPHER [JCSPP]
O.RND [PP0002] O.PIN-MNGT [JCSPP]
O.SID [JCSPP] O.KEY-MNGT [JCSPP]
O.OPERATE [JCSPP] O.CARD-MANAGEMENT [JCSPP]
O.RESOURCES [JCSPP] O.SCP.RECOVERY [JCSPP]
O.FIREWALL [JCSPP] O.SCP.SUPPORT [JCSPP]
O.NATIVE [JCSPP] O.SCP.IC [JCSPP]
O.REALLOCATION [JCSPP]
Table 4-1: Security objectives from [JCOP41V231ST]
615
O.PROTECT_DATA
616
The TOE shall ensure that sensitive information stored in memories is
617
protected against unauthorized disclosure and any corruption or unauthorized
618
modification. Moreover, the TOE shall ensure that sensitive information stored
619
in memories is protected against unauthorized access. The TOE has to
620
provide appropriate security mechanisms to avoid fraudulent access to any
621
sensitive data, such as passwords, cryptographic keys or authentication data.
622
O.SIDE_CHANNEL
623
The TOE must provide protection against disclosure of primary assets
624
including confidential data (User Data or TSF data) stored and/or processed in
625
the Smart Card IC by measurement and analysis of the shape and amplitude
626
or by measurement and analysis of the time between events found by
627
measuring signals (for example on the power, clock, or I/O lines).
628
O.OS_DECEIVE
629
The TOE must guarantee that only secure values are used for its management
630
and operations, especially system flags or cryptographic assets.
631
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 22
Moreover, the integrity of the whole TOE including the NOS must be
632
guaranteed to prevent disclosing/bypassing of the NOS mechanisms or
633
modifying the expected NOS behavior (for instance, unauthorized code patch,
634
or rewriting).
635
O.FAULT_PROTECT
636
The TOE must ensure its correct operation even outside the normal operating
637
conditions where reliability and secure operation has not been proven or
638
tested. This is to prevent errors. The environmental conditions may include
639
voltage, clock frequency, temperature, or external energy fields that can be
640
applied on all interfaces of the TOE (physical or electrical).
641
O.PHYSICAL
642
The TOE hardware provides the following protection against physical
643
manipulation of the IC, and prevent reverse-engineering (understanding the
644
design and its properties and functions), physical access to the IC active
645
surface (probing) allowing unauthorized memory content disclosure,
646
manipulation of the hardware security parts (e.g. sensors, cryptographic
647
engine or RNG) or manipulation of the IC, including the embedded NOS and
648
its application data (e.g. lock and life cycle status, authentication flags, etc.).
649
O.RND
650
The TOE will ensure the cryptographic quality of random number generation.
651
For instance random numbers shall not be predictable and shall have
652
sufficient entropy.
653
The TOE will ensure that no information about the produced random numbers
654
is available to an attacker since they might be used for instance to generate
655
cryptographic keys.
656
O.SID
657
The TOE shall uniquely identify every subject (applet, or package) before
658
granting him access to any service.
659
O.OPERATE
660
The TOE must ensure continued correct operation of its security functions.
661
Especially, the TOE must prevent the unauthorized use of TOE or use of
662
incorrect or unauthorized instructions or commands or sequence of
663
commands.
664
O.RESOURCES
665
The TOE shall control the availability of resources for the applications.
666
O.FIREWALL
667
The TOE shall ensure controlled sharing of data containers owned by applets
668
of different packages, and between applets and the TSFs.
669
O.NATIVE
670
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 23
The only means that the JCVM shall provide for an application to execute
671
native code is the invocation of a method of the Java Card API, or any
672
additional API.
673
O.REALLOCATION
674
The TOE shall ensure that the re-allocation of a memory block for the runtime
675
areas of the JCVM does not disclose any information that was previously
676
stored in that block.
677
O.SHRD_VAR_CONFID
678
The TOE shall ensure that any data container that is shared by all applications
679
is always cleaned after the execution of an application. Examples of such
680
shared containers are the APDU buffer, the byte array used for the invocation
681
of the process method of the selected applet, or any public global variable
682
exported by the API.
683
O.SHRD_VAR_INTEG
684
The TOE shall ensure that only the currently selected application may grant
685
write access to a data memory area that is shared by all applications, like the
686
APDU buffer, the byte array used for the invocation of the process method of
687
the selected applet, or any public global variable exported by the API. Even
688
though the memory area is shared by all applications, the TOE shall restrict
689
the possibility of getting a reference to such memory area to the application
690
that has been selected for execution. The selected application may decide to
691
temporarily hand over the reference to other applications at its own risk, but
692
the TOE shall prevent those applications from storing the reference as part of
693
their persistent states.
694
O.ALARM
695
The TOE shall provide appropriate feedback information upon detection of a
696
potential security violation.
697
O.TRANSACTION
698
The TOE must provide a means to execute a set of operations atomically.
699
O.CIPHER
700
The TOE shall provide a means to cipher sensitive data for applications in a
701
secure way. In particular, the TOE must support cryptographic algorithms
702
consistent with cryptographic usage policies and standards.
703
O.PIN-MNGT
704
The TOE shall provide a means to securely manage PIN objects.
705
O.KEY-MNGT
706
The TOE shall provide a means to securely manage cryptographic keys. This
707
concerns the correct generation, distribution, access and destruction of
708
cryptographic keys.
709
O.CARD-MANAGEMENT
710
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 24
The card manager shall control the access to card management functions
711
such as the installation, update or deletion of applets. It shall also implement
712
the card issuer’s policy on the card.
713
O.SCP.RECOVERY
714
If there is a loss of power, or if the smart card is withdrawn from the CAD while
715
an operation is in progress, the SCP must allow the TOE to eventually
716
complete the interrupted operation successfully, or recover to a consistent and
717
secure state.
718
O.SCP.SUPPORT
719
The SCP shall provide functionalities that support the well-functioning of the
720
TSFs of the TOE (avoiding they are bypassed or altered) and by controlling
721
the access to information proper of the TSFs. In addition, the smart card
722
platform should also provide basic services which are required by the runtime
723
environment to implement security mechanisms such as atomic transactions,
724
management of persistent and transient objects and cryptographic functions.
725
These mechanisms are likely to be used by security functions implementing
726
the security requirements defined for the TOE.
727
O.SCP.IC
728
The SCP shall possess IC security features.
729
4.2 Security Objectives for the Environment
730
4.2.1 Security Objectives for The Environment not contained [JCOP41V231ST]
731
SOE.DLV
732
R.Issuer and the developer of the R.POS_Terminal shall verify the hash
733
values of their guidance documents as stated in the ST introduction to assure
734
a secure delivery of it. R.Issuer shall only issue the TOE after he could
735
successfully verify the MAC returned by the TOE during first update of MK with
736
the delivered management key.
737
SOE.USE_DIAG
738
The environment shall support and use secure communication protocols
739
offered by the TOE.
740
SOE.KEYS
741
The management key and working keys which are stored and processed
742
outside the TOE during personalization and usage phases shall be protected
743
for confidentiality and integrity.
744
Cryptographic keys created in the environment to be used within the TOE
745
have to have sufficient quality by using a random number generator for key
746
generation.
747
SOE.DEV
748
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 25
No native codes shall be loaded into [JCOP41V231] during development and
749
production phases of the TOE. During development, byte code verification
750
shall be performed on the TSAM applet. During production, only TSAM applet
751
shall be installed. GlobalPlatform keys shall be not delivered to R.Issuer and
752
R.POS_Terminal.
753
TOE development and test information during TSAM.Phase_1 and
754
TSAM.Phase_2 shall be protected in a secure environment for its integrity and
755
confidentiality. In case of delivery between different actors like applet
756
developers and applet installers, this information shall be also protected in the
757
same manner as aforementioned.
758
4.2.2 Security Objectives for the Environment from [JCOP41V231ST]
759
The following security objectives for the environment either have been
760
regarded during development and manufacturing of [JCOP41V231] as
761
confirmed by the corresponding evaluation or are covered by objectives in
762
section 4.2.1.
763
Table 4-2 identifies the initial security objectives for the environment from
764
[JCOP41V231ST]. For the complete details, please refer to [JCOP41V231ST].
765
Name Source Regards to Remark
OE.DEV_NOS - Platform.Phase_1 Regarded by platform evaluation
OE.DEL_NOS - Platform.Phase_1 Regarded by platform evaluation
OE.IC_ORG - Platform.Phase_2
Platform.Phase_3
Regarded by platform evaluation
OE.DLV_PROTECT - Platform.Phase_3
Platform.Phase_4
TSAM.Phase_2
TSAM.Phase_3
TSAM.Phase_4
Covered by SOE.DLV
OE.DLV_DATA - Platform.Phase_4
TSAM.Phase_2
Covered by SOE.DEV
OE.TEST_OPERATE - Platform.Phase_4
TSAM.Phase_2
Covered by SOE.DEV
OE.USE_DIAG - TSAM.Phase_3
TSAM.Phase_4
Covered by SOE.USE_DIAG
OE.USE_KEYS - TSAM.Phase_3
TSAM.Phase_4
Covered by SOE.KEYS
OE.NATIVE [JCSPP] TSAM_Phase_2 Covered by SOE.DEV
OE.NO-DELETION [JCSPP] TSAM_Phase_2 Covered by SOE.DEV
OE.NO-INSTALL [JCSPP] TSAM_Phase_2 Covered by SOE.DEV
OE.VERIFICATION [JCSPP] TSAM_Phase_1 Covered by SOE.DEV
Table 4-2: Security objectives for the environment from [JCOP41V231ST]
766
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 26
5 Security Requirements
767
The minimum strength of function level for the TOE is claimed to be SOF-high. For
768
random number usage conformance to [AIS20] class K3, SOF-high is claimed.
769
5.1 TOE Security Functional Requirements not contained in [JCOP41V231ST]
770
5.1.1 Cryptographic support (FCS)
771
5.1.1.1 Cryptographic key destruction (FCS_CKM.4/TSAM)
772
FCS_CKM.4.1/TSAM The TSF shall destroy cryptographic keys in accordance with a
773
specified cryptographic key destruction method [previous MK and WKs
774
are physically overwritten by new keys] that meets the following:
775
[none].
776
5.1.1.2 Cryptographic operation (FCS_COP.1/TSAM)
777
FCS_COP.1.1/TSAM The TSF shall perform [encryption, decryption, MAC generation for TD
778
with dedicated keys in TSAM.Phase.4] in accordance with a specified
779
cryptographic algorithm [3/DES in ECB or CBC mode] and
780
cryptographic key sizes [112 bits] that meet the following: [ANSI X 9.52
781
TECB for encryption/decryption, ANSI X 9.9 with ANSI X 9.52 TCBC
782
Encryption for MAC generation].
783
5.1.2 User data protection (FDP)
784
5.1.2.1 Subset access control (FDP_ACC.1/KEY and FDP_ACC.1/TMD)
785
FDP_ACC.1.1/KEY The TSF shall enforce the [Key Access SFP] on [subjects: users,
786
objects: MK, WKs and operation: initialize, first update, update, write,
787
read and use].
788
FDP_ACC.1.1/TMD The TSF shall enforce the [TMD Access SFP] on [subjects: users,
789
objects: TMD and operation: read, write and increment].
790
Application Note:
791
The operation “use” is applicable to WKs. It means encryption, decryption or MAC generation
792
with the corresponding WK. The operation “increment” is applicable to TSN or BSN of TMD.
793
5.1.2.2 Security attribute based access control (FDP_ACF.1/KEY and FDP_ACF.1/TMD)
794
FDP_ACF.1.1/KEY The TSF shall enforce the [Key Access SFP] to objects based on the
795
following: [subject attribute: user role {R.Initializer, R.Issuer,
796
R.POS_Terminal} and object attribute: life cycle state { TSAM.Phase_2,
797
TSAM.Phase_3, TSAM.Phase_4}].
798
FDP_ACF.1.2/KEY The TSF shall enforce the following rules to determine if an operation
799
among controlled subjects and controlled objects is allowed: [
800
1. A user with user role {R.Initializer} is allowed to initialize the MK if
801
the life cycle state is {TSAM.Phase_2}.
802
2. A user with user role {R.Issuer} is allowed to do first update of the
803
MK if the life cycle state is {TSAM.Phase_3}.
804
3. A user with user role {R.Issuer} is allowed to do updates of the MK
805
if the life cycle state is {TSAM.Phase_4}.
806
4. A user with user role {R.Issuer} is allowed to do writes of the WK if
807
the life cycle state is {TSAM.Phase_4}.
808
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 27
5. A user with user role {R.POS_Terminal} is allowed to use the WK if
809
the life cycle state is {TSAM.Phase_4}.
810
]
811
FDP_ACF.1.3/KEY The TSF shall explicitly authorise access of subjects to objects based
812
on the following additional rules: [no other rule].
813
FDP_ACF.1.4/KEY The TSF shall explicitly deny access of subjects to objects based on
814
the [rule that no user can read any of the MK and WKs out of the TOE].
815
816
FDP_ACF.1.1/TMD The TSF shall enforce the [TMD Access SFP] to objects based on the
817
following: [subject attribute: user role {R.Issuer, R.POS_Terminal} and
818
object attribute: life cycle state {TSAM.Phase_3, TSAM.Phase_4}].
819
FDP_ACF.1.2/TMD The TSF shall enforce the following rules to determine if an operation
820
among controlled subjects and controlled objects is allowed: [
821
1. A user with user role {R.Issuer} is allowed to write TMD if the life
822
cycle state is {TSAM.Phase_3}.
823
2. A user with user role {R.POS_Terminal} is allowed to read TMD
824
and increment TSN/BSN of TMD if the life cycle state is
825
{TSAM.Phase_4}.
826
]
827
FDP_ACF.1.3/TMD The TSF shall explicitly authorise access of subjects to objects based
828
on the following additional rules: [no other rule].
829
FDP_ACF.1.4/TMD The TSF shall explicitly deny access of subjects to objects based on
830
the [following rules:
831
1. Increment of TSN is denied if the value of TSN is equal to 999999.
832
2. Increment of BSN is denied if the value of BSN is equal to 9999.
833
].
834
Application Note:
835
R.Initializer and R.Issuer need to be authenticated. R.POS_Terminal doesn’t need
836
authentication, i.e., it is an anonymous user.
837
5.1.2.3 Import of user data without security attributes (FDP_ITC.1/KEY and
838
FDP_ITC.1/TMD)
839
FDP_ITC.1.1/KEY The TSF shall enforce the [Key Access SFP] when importing user data,
840
controlled under the SFP, from outside of the TSC.
841
FDP_ITC.1.2/KEY The TSF shall ignore any security attributes associated with the user
842
data when imported from outside the TSC.
843
FDP_ITC.1.3/KEY The TSF shall enforce the following rules when importing user data
844
controlled under the SFP from outside the TSC: [
845
1. After import of MK by initialize operation, the security attribute life
846
cycle state shall change from TSAM.Phase_2 to TSAM.Phase_3.
847
]
848
FDP_ITC.1.1/TMD The TSF shall enforce the [TMD Access SFP] when importing user
849
data, controlled under the SFP, from outside of the TSC.
850
FDP_ITC.1.2/TMD The TSF shall ignore any security attributes associated with the user
851
data when imported from outside the TSC.
852
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 28
FDP_ITC.1.3/TMD The TSF shall enforce the following rules when importing user data
853
controlled under the SFP from outside the TSC: [
854
1. After import of TMD by write operation, the security attribute life
855
cycle state shall change from TSAM.Phase_3 to TSAM.Phase_4.
856
]
857
5.1.2.4 Stored data integrity monitoring and action (FDP_SDI.2/TSAM)
858
FDP_SDI.2.1/TSAM The TSF shall monitor user data stored within the TSC for [integrity
859
errors] on all objects, based on the following attributes [checksum for
860
TMD, LCS and RC].
861
FDP_SDI.2.2/TSAM Upon detection of a data integrity error, the TSF shall [inform the user
862
and perform the actions in Table 5-1 depending on which object is
863
incurred in the data integrity error].
864
Object Action
RC No more usage of the MK is allowed (e.g. for authentication).
LCS Stop operation of the TOE.
TMD No more read or increment of TMD is allowed.
Table 5-1: Actions on detection of integrity errors
865
Application Note:
866
The integrity status for application keys (MK and WKs) are maintained by [JCOP41V231],
867
which monitors integrity when application keys are accessed and stops operation
868
immediately when detecting a corresponding integrity error (therefore preventing that
869
corrupted MK or WKs can be used).
870
5.1.2.5 Basic data exchange confidentiality (FDP_UCT.1/KEY)
871
FDP_UCT.1.1/KEY The TSF shall enforce the [Key Access SFP] to be able to [receive]
872
objects in a manner protected from unauthorised disclosure.
873
Application Note:
874
This SFR applies to initialize and/or updates of MK and writes of WKs.
875
5.1.2.6 Data exchange integrity (FDP_UIT.1/TSAM)
876
FDP_UIT.1.1/TSAM The TSF shall enforce the [Key Access SFP and TMD Access SFP] to
877
be able to [receive] user data in a manner protected from [modification,
878
insertion, replay] errors.
879
FDP_UIT.1.2/TSAM The TSF shall be able to determine on receipt of user data, whether
880
[modification, insertion, replay] has occurred.
881
Application Note:
882
The TOE can detect modification, insertion or replay, but it is not able to distinguish between
883
them. Concerning Key Access SFP, this SFR applies to initializes and/or updates of MK and
884
writes of WKs. Concerning TMD Access SFP, this SFR applies to writes of TMD.
885
5.1.3 Identification and authentication (FIA)
886
5.1.3.1 Authentication failure handling (FIA_AFL.1/TSAM)
887
FIA_AFL.1.1/TSAM The TSF shall detect when [three consecutive] unsuccessful
888
authentication attempts occur related to [authentication with MK].
889
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 29
FIA_AFL.1.2/TSAM When the defined number of unsuccessful authentication attempts has
890
been met or surpassed, the TSF shall [no longer allow authentication
891
with MK].
892
5.1.3.2 Timing of authentication (FIA_UAU.1/TSAM)
893
FIA_UAU.1.1/TSAM The TSF shall allow [encryption, decryption and MAC generation by
894
corresponding WK, reading TMD, incrementing TSN and/or BSN of
895
TMD] on behalf of the user to be performed before the user is
896
authenticated.
897
FIA_UAU.1.2/TSAM The TSF shall require each user to be successfully authenticated
898
before allowing any other TSF-mediated actions on behalf of that user.
899
5.1.3.3 Single-use authentication mechanisms (FIA_UAU.4/TSAM)
900
FIA_UAU.4.1/TSAM The TSF shall prevent reuse of authentication data related to
901
[GlobalPlatform card manager authentication, authentication with MK].
902
5.1.3.4 Multiple authentication mechanisms (FIA_UAU.5/TSAM)
903
FIA_UAU.5.1/TSAM The TSF shall provide [GlobalPlatform card manager authentication,
904
authentication with MK] to support user authentication.
905
FIA_UAU.5.2/TSAM The TSF shall authenticate any user’s claimed identity according to the
906
[following rules:
907
1. GlobalPlatform card manager authentication is used for
908
authentication of R.Initializer in TSAM.Phase_2.
909
2. Authentication with MK is used for authentication of R.Issuer in
910
TSAM.Phase_3 and TSAM.Phase_4
911
].
912
Application Note:
913
Although GlobalPlatform card manager authentication and authentication with MK are both
914
based on 3/DES-based challenge-response protocols, FIA_UAU.5 was chosen for the
915
following three reasons:
916
1. to explicitly require which authentication mechanism (i.e. based on which key) shall
917
be used for authentication of which user,
918
2. because the two authentication mechanisms use two different dedicated external
919
interfaces of TSAM,
920
3. because the two authentication mechanisms differ in their realization: whereas for
921
authentication of R.Initializer internally card manager authentication (SF.I&A) of
922
[JCOP41V231] according to FIA_UAU.1 of [JCOP41V231ST] is used, authentication
923
of R.Issuer using MK is solely implemented in TSAM applet (only using cryptographic
924
primitives of the platform).
925
5.1.3.5 Timing of identification (FIA_UID.1)
926
FIA_UID.1.1/TSAM The TSF shall allow [encryption, decryption and MAC generation by
927
corresponding WK, reading TMD, incrementing TSN and/or BSN of
928
TMD] on behalf of the user to be performed before the user is
929
identified.
930
FIA_UID.1.2/TSAM The TSF shall require each user to be successfully identified before
931
allowing any other TSF-mediated actions on behalf of that user.
932
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 30
5.1.4 Security management (FMT)
933
5.1.4.1 Management of security attributes (FMT_MSA.1/TSAM)
934
FMT_MSA.1.1/TSAMThe TSF shall enforce the [Key Access SFP and TMD Access SFP] to
935
restrict the ability to [modify] the security attributes [life cycle state] to
936
[R.Initializer and R.Issuer].
937
5.1.4.2 Secure security attributes (FMT_MSA.2/TSAM)
938
FMT_MSA.2.1/TSAMThe TSF shall ensure that only secure values are accepted for security
939
attributes.
940
5.1.4.3 Static attribute initialisation (FMT_MSA.3/TSAM)
941
FMT_MSA.3.1/TSAMThe TSF shall enforce the [Key Access SFP and TMD Access SFP] to
942
provide [restrictive] default values for security attributes that are used
943
to enforce the SFP.
944
FMT_MSA.3.2/TSAMThe TSF shall allow the [nobody] to specify alternative initial values to
945
override the default values when an object or information is created.
946
Application Note:
947
The TSAM TOE operates on one fixed set of objects and can not create additional ones.
948
Therefore, the requirement above is only about the initialization of the security attribute life
949
cycle state. “Restrictive” corresponds to a setting to TSAM.Phase_2, which only allows
950
access by R.Initializer.
951
5.1.4.4 Specification of Management Functions (FMT_SMF.1/TSAM)
952
FMT_SMF.1.1/TSAM The TSF shall be capable of performing the following security
953
management functions: [modification of the life state according to
954
FMT_MSA.1.1/TSAM, FDP_ITC.1.3 /KEY and FDP_ITC.1.3 /TMD].
955
5.1.4.5 Security roles (FMT_SMR.1)
956
FMT_SMR.1.1/TSAMThe TSF shall maintain the roles [R.Initializer, R.Issuer and
957
R.POS_Terminal].
958
FMT_SMR.1.2/TSAMThe TSF shall be able to associate users with roles.
959
Application Note:
960
R.Initializer and R.Issuer need to be authenticated. R.POS_Terminal doesn’t need
961
authentication, i.e., it is an anonymous user.
962
5.1.5 Trusted path/channels (FTP)
963
5.1.5.1 Inter-TSF trusted channel (FTP_ITC.1/TSAM)
964
FTP_ITC.1.1/TSAM The TSF shall provide a communication channel between itself and a
965
remote trusted IT product that is logically distinct from other
966
communication channels and provides assured identification of its end
967
points and protection of the channel data from modification or
968
disclosure.
969
FTP_ITC.1.2/TSAM The TSF shall permit [the remote trusted IT product] to initiate
970
communication via the trusted channel.
971
FTP_ITC.1.3/TSAM The TSF shall initiate communication via the trusted channel for
972
[performing initialize, first update, updates and writes of MK, WKs and
973
TMD, as applicable].
974
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 31
5.2 TOE Security Functional Requirements from [JCOP41V231ST]
975
In the following table the TOE security functional requirements from
976
[JCOP41V231] are referenced. For details, please refer to [JCOP41V231ST]
977
section 5.1.
978
Functional Class Functional Components
FAU_ARP.1 Security alarms
FAU: Security
audit FAU_SAA.1 Potential violation analysis
FCS_CKM.1 Cryptographic key generation
FCS_CKM.2 Cryptographic key distribution
FCS_CKM.3 Cryptographic key access
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1 Cryptographic operation
FCS:
Cryptographic
support
FCS_RND.1 Quality metric for random numbers
FDP_ACC.1 Subset access control
FDP_ACC.2 Complete access control
FDP_ACF.1 Security attribute based access control
FDP_ETC.1 Export of user data without security attributes
FDP_IFC.1 Subset Information flow control
FDP_IFF.1 Simple security attributes
FDP_ITC.1 Import of user data without security attributes
FDP_RIP.1 Subset residual information protection
FDP_ROL.1 Basic rollback
FDP: User data
protection
FDP_SDI.2 Stored data integrity monitoring and action
FIA_AFL.1 Authentication failure handling
FIA_ATD.1 User attribute definition
FIA_UAU.1 Timing of authentication
FIA_UAU.3 Unforgeable authentication
FIA_UAU.4 Single-use authentication mechanisms
FIA_UID.1 Timing of identification
FIA_UID.2 User identification before any action
FIA: Identification
and authentication
FIA_USB.1 User-subject binding
FMT_LIM.1 Limited capabilities
FMT_LIM.2 Limited availability
FMT_MSA.1 Management of security attributes
FMT_MSA.2 Secure security attributes
FMT_MSA.3 Static attribute initialization
FMT: Security
management
FMT_MTD.1 Management of TSF data
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 32
Functional Class Functional Components
FMT_MTD.3 Secure TSF data
FMT_SMF.1 Specification of Management Functions
FMT_SMR.1 Security roles
FPR: Privacy FPR_UNO.1 Unobservability
FPT_AMT.1 Abstract machine testing
FPT_EMSEC.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_RVM.1 Reference mediation
FPT_SEP.1 TSF domain separation
FPT_RCV.3 Trusted Recovery
FPT_RCV.4 Trusted Recovery
FPT_TDC.1 Inter-TSF basic TSF data consistency
FPT: Protection of
the TSF
FPT_TST.1 TSF testing
FRU: Resource
utilization
FRU_FLT.2 Limited fault tolerance
FTP: Trusted
path/channels
FTP_ITC.1 Inter-TSF trusted channel
Table 5-2: TOE SFRs from [JCOP41V231ST]
979
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 33
5.3 TOE Security Assurance Requirements
980
The evaluation assurance package is EAL 4 augmented by AVA_VLA.4 and
981
ADV_IMP.2.
982
Assurance Class Assurance Components
ACM_AUT.1 Partial CM automation
ACM_CAP.4 Generation support and acceptance procedures
ACM:
Configuration
management
ACM_SCP.2 Problem tracking CM coverage
ADO_DEL.2 Detection of modification
ADO: Delivery and
operation ADO_IGS.1 Installation, generation, and start-up procedures
ADV_FSP.2 Fully defined external interfaces
ADV_HLD.2 Security enforcing high-level design
ADV_IMP.2 Implementation of the TSF
ADV_LLD.1 Descriptive low-level design
ADV_RCR.1 Informal correspondence demonstration
ADV: Development
ADV_SPM.1 Informal TOE security policy model
AGD_ADM.1 Administrator guidance
AGD: Guidance
documents AGD_USR.1 User guidance
ALC_DVS.1 Identification of security measures
ALC_LCD.1 Developer defined life-cycle model
ALC: Life cycle
support
ALC_TAT.1 Well-defined development tools
ATE_COV.2 Analysis of coverage
ATE_DPT.1 Testing: high-level design
ATE_FUN.1 Functional testing
ATE: Tests
ATE_IND.2 Independent testing - sample
AVA_MSU.2 Validation of analysis
AVA_SOF.1 Strength of TOE security function evaluation
AVA: Vulnerability
assessment
AVA_VLA.4 Highly resistant
Table 5-3: Evaluation Assurance Requirements
983
Remark: [JCOP41V231] has been evaluated according to EAL4 augmented by
984
AVA_VLA.4, ADV_IMP.2, ALC_DVS.2 and AVA_MSU.3. For TSAM
985
TOE evaluation, the same set of security assurance requirements is
986
used except ALC_DVS.2 and AVA_MSU.3. ALC_DVS.1 and
987
AVA_MSU.2 are taken in this evaluation instead of ALC_DVS.2 and
988
AVA_MSU.3, respectively.
989
990
5.4 IT Environment Security Requirements not contained in [JCOP41V231ST]
991
In this section the term “TSF” inside SFRs has been refined to “environment” for
992
clarification. Furthermore the term “a remote trusted IT product” has been
993
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 34
refined to “the TOE”. Please note that the dependencies of the following SFRs
994
for the IT environment have not been considered.
995
5.4.1 Cryptographic key generation
996
5.4.1.1 Cryptographic key generation (FCS_CKM.1/ENV)
997
FCS_CKM.1.1/ENV The environment shall generate cryptographic keys in accordance with
998
a specified cryptographic key generation algorithm [random number
999
generation] and specified cryptographic key sizes [112 bits] that meet
1000
the following: [none].
1001
Application Note:
1002
FDP_CKM.1/ENV refers to production of the TOE as well as to usage after TOE delivery.
1003
5.4.2 User data protection
1004
5.4.2.1 Basic data exchange confidentiality (FDP_UCT.1/ENV)
1005
FDP_UCT.1.1/ENV The environment shall enforce the [Key Access SFP] to be able to
1006
[transmit] objects in a manner protected from unauthorised disclosure.
1007
5.4.2.2 Data exchange integrity (FDP_UIT.1/ENV)
1008
FDP_UIT.1.1/ENV The environment shall enforce the [Key Access SFP and TMD Access
1009
SFP] to be able to [transmit] user data in a manner protected from
1010
[modification, insertion, replay] errors.
1011
FDP_UIT.1.2/ENV The environment shall be able to determine on receipt of user data,
1012
whether [selection: modification, deletion, insertion, replay] has
1013
occurred.
1014
Application Note:
1015
FDP_UCT.1/ENV and FDP_UIT.1/ENV refer to production of the TOE as well as to usage
1016
after TOE delivery. In both phases the environment is only transmitting user data to the TOE,
1017
therefore FDP_UIT.1.2/ENV is not applicable.
1018
5.4.3 Trusted path/channels
1019
5.4.3.1 Inter-TSF trusted channel (FTP_ITC.1/ENV)
1020
FTP_ITC.1.1/ENV The environment shall provide a communication channel between itself
1021
and the TOE that is logically distinct from other communication
1022
channels and provides assured identification of its end points and
1023
protection of the channel data from modification or disclosure.
1024
FTP_ITC.1.2/ENV The environment shall permit [the environment] to initiate
1025
communication via the trusted channel.
1026
FTP_ITC.1.3/ENV The environment shall initiate communication via the trusted channel
1027
for [loading of D.App_Code, setting the Card Life Cycle State,
1028
initializing MK during TSAM.Phase_2 and first update of MK during
1029
TSAM.Phase_3].
1030
Application Note:
1031
Concerning loading of D.App_Code, setting the Card Life Cycle State and initializing MK
1032
FTP_ITC.1/ENV refers to production of the TOE, concerning first update of MK
1033
FTP_ITC.1/ENV refers to usage after TOE delivery. FTP_ITC.1.1/ENV was already included
1034
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 35
in [JCOP41V231ST] as an SFR for the IT environment, but there its scope was limited to
1035
loading of D.App_Code and setting the Card Life Cycle State.
1036
5.5 IT Environment Security Requirements from [JCOP41V231ST]
1037
In the following table the security functional requirements for the IT environment
1038
from [JCOP41V231] (concerning byte code verification) are referenced. For
1039
details, please refer to [JCOP41V231ST] section 5.3.1. These requirements
1040
refer solely to production of the TOE, not to usage after TOE delivery. Please
1041
note that (1) FTP_ITC.1/ENV, which is also defined as an SFR for the IT
1042
environment in [JCOP41V231ST], is listed in section 5.4 above as its scope has
1043
been extended compared to [JCOP41V231ST], and (2) that all SFRs in the
1044
table below except FMT_SMF.1/BCV are defined by [JCSPP].
1045
Functional Class Functional Components
FDP_IFC.2/BCV Complete information flow control
FDP: User Data
Protection FDP_IFF.2/BCV Hierarchical security attributes
FMT_MSA.1/BCV Management of security attributes
FMT_MSA.2/BCV Secure security attributes
FMT_MSA.3/BCV Static attribute initialization
FMT_SMF.1/BCV Specification of Management
Functions
FMT: Security
Management
FMT_SMR.1/BCV Security roles
FRU: Resource Utilization FRU_RSA.1/BCV Maximum Quotas
Table 5-4: IT Environment SFRs from [JCOP41V231ST]
1046
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 36
6 TOE Summary Specification
1047
6.1 Security Functions
1048
SF.AUT_GP TSAM_GlobalPlatform authentication
1049
SF.AUT_GP will authenticate the user by a challenge-response mechanism
1050
using GlobalPlatform keys. For each authentication attempt, SF.AUT_GP will
1051
present a new random number1
as a challenge. Only if the user provides the
1052
corresponding correct response, the user is authenticated as the initializer
1053
(R.Initializer). In case of a successful authentication, SF.AUT_GP will establish
1054
session keys that are later on used by SF.CP_GP.
1055
SF.AUT_GP is only available in TSAM.Phase_2.
1056
Remark: This security function has to be used by the initializer (R.Initializer)
1057
before the initializer being able to initialize MK in TSAM.Phase_2. The
1058
initializer belongs to the production environment of the TOE,
1059
nevertheless, MK initialize is already access controlled by TOE
1060
functionality.
1061
SF.CP_GP TSAM_GlobalPlatform communication protection
1062
SF.CP_GP provides confidentiality and integrity protection of communication
1063
data between the user and the TOE. This is done by decryption and verification
1064
of cryptographic checksum using session keys. The corresponding session
1065
keys are established after a successful authentication by SF.AUT_GP.
1066
SF.CP_GP is only available in TSAM.Phase_2.
1067
Remark: This security function is used by the initializer (R.Initializer) to protect
1068
the transfer of MK while initializing it in TSAM.Phase_2. The initializer
1069
belongs to the production environment of the TOE, nevertheless, MK
1070
initialize is already access controlled by TOE functionality.
1071
SF.CP_MK Communication protection with MK
1072
SF.CP_MK assures integrity, authenticity and optionally confidentiality of
1073
communication data between the user and the TOE for a single command. This
1074
is done by MAC verification and decryption using session keys which are only
1075
valid for this command. To do so, SF.CP_MK performs the following five steps:
1076
1. For establishing the session keys, a random number RN1
is provided by
1077
SF.CP_MK to the user as the very first step.
1078
2. SF.CP_MK receives the command from the user.
1079
3. SF.CP_MK checks the value of RC. If it is equal to 3, SF.CP_MK returns an
1080
error code and stops processing. Otherwise, it continues with the next step.
1081
1
Used random numbers are taken from [JCOP41V231], which implements a random number
generator conformant to [AIS20], class K3, SOF-high (see SF.EmbeddedSoftware).
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 37
4. SF.CP_MK generates the session key for MAC verification by encrypting
1082
RN with MK. SF.CP_MK verifies the MAC within the command. If
1083
verification fails, it increases RC, returns an error code and stops
1084
processing. Otherwise, the issuer (R.Issuer) is authenticated, and
1085
SF.CP_MK resets RC to zero and continues with the next step.
1086
5. If the command includes encrypted data, SF.CP_MK generates the session
1087
key for decryption by encrypting the inverse of RN with MK and SF.CP_MK
1088
decrypts the encrypted data.
1089
SF.CP_MK is only available in TSAM.Phase_3 and TSAM.Phase_4.
1090
Remark 1: This security function is used to protect confidentiality and integrity
1091
of the MK during first update. It is also used to protect confidentiality
1092
and integrity of MK and WKs during updates and writes,
1093
respectively. This security function protects integrity of TMD during
1094
writes.
1095
Remark 2: The MAC verification assures authentication of the issuer as well as
1096
integrity of the communication data.
1097
SF.AC Access control
1098
SF.AC enforces access control rules based on commands, user roles and life
1099
cycle state. For commands needing authentication, SF.AC identifies user roles
1100
R.Initializer and R.Issuer with SF.AUT_GP and SF.CP_MK, respectively. For
1101
commands not needing authentication, SF.AC identifies the user role as
1102
R.POS_Terminal.
1103
The following is SF.AC-enforced access control rules:
1104
1. The initializer (R.Initializer) is allowed to initialize MK in TSAM.Phase_2.
1105
2. The issuer (R.Issuer) is allowed to perform first update of MK in
1106
TSAM.Phase_3. The issuer is also allowed to perform updates of MK and
1107
writes of WKs in TSAM.Phase_4.
1108
3. No user can read any of the MK and WKs out of the TOE.
1109
4. The issuer (R.Issuer) is allowed to write TMD in TSAM.Phase_3.
1110
5. The user R.POS_Terminal is allowed to read TMD out of the TOE in
1111
TSAM.Phase_4.
1112
6. The user R.POS_Terminal is allowed to increment TSN of TMD in
1113
TSAM.Phase_4 unless the value of TSN is equal to 999999.
1114
7. The user R.POS_Terminal is allowed to increment BSN of TMD in
1115
TSAM.Phase_4 unless the value of BSN is equal to 9999.
1116
8. The user R.POS_Terminal is allowed to use WKs according to SF.USE_WK
1117
in TSAM.Phase_4.
1118
Access attempts not matching any of these rules will be rejected by SF.AC.
1119
SF.LCM Life cycle management
1120
SF.LCM manages life cycle state of the TOE. It does so by the following:
1121
1. SF.LCM automatically initializes the life cycle state to TSAM.Phase_2 during
1122
applet installation in TSAM production.
1123
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 38
2. When MK has been successfully initialized by R.Initializer in TSAM.Phase_2,
1124
SF.LCM will change the life cycle state to TSAM.Phase_3.
1125
3. When TMD has been successfully written by R.Issuer in TSAM.Phase_3,
1126
SF.LCM will change the life cycle state to TSAM.Phase_4.
1127
Life cycle state changes are irreversible. No other life cycle state changes are
1128
performed except the aforementioned ones.
1129
SF.SDP Stored data protection
1130
SF.SDP checks the integrity of RC, LCS and TMD stored in EEPROM. If an
1131
integrity violation is detected, the related command is cancelled and an output
1132
error code is provided to the external user.
1133
1. Every time a value of RC, LCS or TMD is written to EEPROM, SF.SDP will
1134
generate a corresponding checksum in EEPROM.
1135
2. On receipt of a command, SF.SDP will verify the checksum of LCS and
1136
check whether LCS has a valid value. If inconsistent checksum is detected
1137
or the value of LCS is out of range, SF.SDP will block processing of the
1138
command and return the corresponding error code.
1139
3. If RC is accessed internally, SF.SDP will first of all verify the corresponding
1140
checksum. If inconsistent checksum is detected, SF.SDP blocks usage of
1141
RC and responds with a corresponding error code. This also indirectly
1142
blocks the usage of the corresponding MK.
1143
4. If TMD is accessed internally, SF.SDP will first of all verify the corresponding
1144
checksum. If inconsistent checksum is detected, SF.SDP blocks usage of
1145
TMD and responds with a corresponding error code.
1146
Furthermore SF.SDP stores MK and WKs in key objects of [JCOP41V231], and
1147
every time a value of MK or WK is written to EEPROM, the previous value is
1148
physically overwritten in the memory assigned to the corresponding key object.2
1149
SF.USE_WK Use of working keys
1150
SF.USE_WK provides the following cryptographic services applicable to TD
1151
(transaction data):
1152
1. 3/DES encryption in ECB mode with key size of 112 bits according to ANSI
1153
X 9.52 TECB for encryption/decryption.
1154
2. 3/DES decryption in ECB mode with key size of 112 bits according to ANSI
1155
X 9.52 TECB for encryption/decryption
1156
3. 3/DES MAC generation in CBC mode with key size 112 bits according to
1157
ANSI X 9.9 with ANSI X 9.52 TCBC Encryption for MAC generation.
1158
For each of the services there is one dedicated WK in the TOE. SF.USE_WK is
1159
only available in TSAM.Phase_4.
1160
2
Using key objects furthermore provides integrity protection for MK and WKs according to SF.Audit of
[JCOP41V231ST], which locks the card session in case of corruption of check-summed objects.
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 39
SF.Embedded_Software (from [JCOP41V231ST])
1161
The certified JavaCard platform (part of the TOE) features the following TSF.
1162
The exact formulation can be found in [JCOP41V231ST] (SF.Hardware from
1163
[JCOP41V231ST] is restated separately below):
1164
1. Access control (SF.AccessControl)
1165
2. Audit functionality (SF.Audit)
1166
3. Cryptographic key management (SF.CryptoKey)
1167
4. Cryptographic operation (SF.CryptoOperation), including random number
1168
generation according to [AIS 20] class K3 with SOF-high
1169
5. Identification and authentication (SF.I&A)
1170
6. Secure management of TOE resources (SF.SecureManagement)
1171
7. PIN management (SF.PIN)
1172
8. Transaction management (SF.Transaction)
1173
SF.Hardware (from [JCOP41V231ST])
1174
The certified hardware (part of the TOE) features the following TSF. The exact
1175
formulation can be found in [ST0348]:
1176
1. Random Number Generator (F.RNG)
1177
2. Triple-DES Co-processor (F.HW_DES)
1178
3. AES Co-processor (F.HW_AES)
1179
4. Control of Operating Conditions (F.OPC)
1180
5. Protection against Physical Manipulation (F.PHY)
1181
6. Logical Protection (F.LOG)
1182
7. Protection of Mode Control (F.COMP)
1183
8. Memory Access Control (F.MEM_ACC)
1184
9. Special Function Register Access Control (F.SFR_ACC)
1185
6.2 Strength of Function Claims
1186
The minimum strength of function level claimed for this evaluation is SOF-high,
1187
therefore the following SOF-rateable security functions are also claimed to
1188
reach SOF-high. The security functions and corresponding permutational or
1189
probabilistic mechanisms to be SOF-rated are: SF.AUT_GP (Challenge-
1190
response authentication), SF.CP_GP (Cryptographic checksum verification),
1191
SF.CP_MK (Challenge-response authentication) and SF.SDP (Checksum
1192
verification). Any cryptographic algorithms in these functions will not be rated,
1193
but the rating will be performed with respect to protocols (e.g. whether
1194
challenge and response are sufficiently long).
1195
The security functions SF.AC and SF.LCM are not based on any permutational
1196
or probabilistic mechanisms and, therefore, they don’t have to be rated.
1197
SF.USE_WK provides merely cryptographic mechanisms and, therefore, is also
1198
excluded from SOF rating.
1199
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 40
Furthermore SF.AUT_GP and SF.CP_MK (both realizing challenge-response
1200
authentications) use random numbers. These random numbers are claimed to
1201
be conformant to [AIS20], class K3, SOF-high. (This conformance has already
1202
been evaluated for [JCOP41V231], and this composite TOE uses only random
1203
numbers from the corresponding evaluated random number generator).
1204
6.3 Assurance Measures
1205
The TOE is to fulfill the assurance requirements of assessment class ASE and
1206
of evaluation level EAL4 augmented by ADV_IMP.2 and AVA_VLA.4. The
1207
present document "Security Target" serves to fulfill the requirements according
1208
to ASE. Besides provision of the TOE (according to ATE_IND.2), the
1209
manufacturer will apply the following additional assurance measures within the
1210
frame of the evaluation, to evidently prove the fulfilling of the requirements
1211
according to EAL4 augmented by ADV_IMP.2 and AVA_VLA.4:
1212
• Application of a compliant configuration management system and provision of
1213
corresponding documentation (according to ACM_AUT.1 and ACM_CAP.4)
1214
• Application of secure delivery procedures and provision of delivery and operational
1215
documentation (according to ADO_DEL.2 and ADO_IGS.1)
1216
• Provision of functional specification documentation (according to ADV_FSP.2)
1217
• Provision of high-level design documentation (according to ADV_HLD.2)
1218
• Provision of implementation representation (according to ADV_IMP.2)
1219
• Provision of low-level design documentation (according to ADV_LLD.1)
1220
• Provision of representation correspondence documentation (according to
1221
ADV_RCR.1)
1222
• Provision of security policy modeling documentation (according to ADV_SPM.1)
1223
• Provision of guidance documentation (according to AGD_ADM.1 and
1224
AGD_USR.1)
1225
• Application of development security measures and provision of Life cycle support
1226
documentation (according to ALC_DVS.1, ALC_LCD.1, and ALC_TAT.1)
1227
• Performance of functional tests and provision of corresponding test documentation
1228
(according to ATE_COV.2, ATE_DPT.1, and ATE_FUN.1)
1229
• Provision of vulnerability assessment documentation (according to AVA_MSU.2,
1230
AVA_SOF.1, and AVA_VLA.4)
1231
The assignment of the assurance measures to the assurance requirements
1232
(see section 5.3) is straight forward, as for all assurance components (with
1233
exception of the independent testing of the evaluator ATE_IND.2)
1234
corresponding documentation will be is provided.
1235
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 41
7 PP claims
1236
7.1 PP Reference
1237
[JCOP41V231ST] and also this ST claim conformance to the following
1238
protection profile:
1239
• Java Card System – Minimal Configuration Protection Profile, Version: 1.0b,
1240
August 2003 [JCSPP]
1241
7.2 PP Additions and Refinements
1242
See corresponding section of [JCOP41V231ST] and PP claims rationale in
1243
section 8.4 hereinafter.
1244
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 42
8 Rationale
1245
8.1 Security Objectives Rationale
1246
SO.REPLAY
SO.KEY_ACCESS
SO.TMD_ACCESS
SO.INTEGRITY
&
O.PROTECT_DATA
SO.TXN_SECURE
SO.SN
SOE.DLV
SOE.USE_DIAG
SOE.KEYS
SOE.DEV
T.KEY_ACCESS X X
T.TMD_ACCESS X X
T.INTEGRITY X
OSP.TXN_SECURE X
OSP.SN X
A.DLV X
A.USE_DIAG X
A.KEYS X
A.DEV X
Table 8-1: Security objectives rationale
1247
8.1.1 Traceability of the Security Objectives
1248
SO.REPLAY directly traces back to the replay attack aspect of
1249
T.TMD_ACCESS and T.KEY_ACCESS concerning TMD writes and key
1250
initialization/updates/writes.
1251
SO.TMD_ACCESS directly traces back to the authentication and integrity
1252
protection aspects of T.TMD_ACCESS.
1253
SO.KEY_ACCESS directly traces back to the authentication, integrity
1254
protection and confidentiality protection aspects of T.KEY_ACCESS.
1255
SO.TXN_SECURE directly traces back to OSP.TXN_SECURE, where
1256
introduction of R.POS_Terminal in SO.TXN_SECURE corresponds to no need
1257
for authentication as expressed in OSP.TXN_SECURE.
1258
SO.SN directly traces back to OSP.SN, where introduction of R.POS_Terminal
1259
in SO.SN corresponds to no need for authentication as expressed in OSP.SN.
1260
SO.INTEGRITY directly traces back to T.INTEGRITY concerning RC, LCS
1261
and TMD. Integrity protection for MK and WKs was already expressed by
1262
O.PROTECT_DATA of the platform, which traces back to T.INTEGRITY
1263
concerning MK and WKs.
1264
SOE.DLV directly traces back to A.DLV (it is a re-statement of A.DLV).
1265
SOE.USE_DIAG directly traces back to A.USE_DIAG (it is a re-statement of
1266
A.USE_DIAG).
1267
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 43
SOE.KEYS directly traces back to A.KEYS (it is a re-statement of A.KEYS).
1268
SOE.DEV directly traces back to A.DEV (it is a re-statement of A.DEV).
1269
8.1.2 Coverage of the assumptions
1270
A.DLV is covered by SOE.DLV, as SOE.DLV is a re-statement of A.DLV.
1271
A.USE_DIAG is covered by SOE.USE_DIAG, as SOE.USE_DIAG is a re-
1272
statement of A.USE_DIAG.
1273
A.DLV is covered by SOE.DLV, as SOE.DLV is a re-statement of A.DLV.
1274
A.KEYS is covered by SOE.KEYS, as SOE.KEYS is a re-statement of
1275
A.KEYS.
1276
8.1.3 Countering of the threats
1277
T.INTEGRITY breaks down in two different aspects: (1) undetected integrity
1278
errors concerning MK, WKs, TMD, LCS and RC in storage, and (2) usage of
1279
corresponding corrupted data. Concerning TMD, LCS and RC both aspects
1280
are countered by SO.INTEGRITY, which defines as well integrity error
1281
detection concerning MK, WKs, TMD, LCS and RC in storage as the
1282
corresponding error response (prohibit use of corrupted data and give back
1283
error message). For MK and WKs, T.INTEGRITY is countered by
1284
O.PROTECT_DATA of the platform, which ensures integrity of any application
1285
keys (and other application data).
1286
T.TMD_ACCESS is about (1) writes of TMD by roles other than R.Issuer, (2)
1287
undetected modification of TMD during authorized writes of TMD, and (3)
1288
replay of a TMD write. SO.TMD_ACCESS counters the first two of these
1289
aspects, as it defines (1) a secure mechanism for TMD writes that provides
1290
authentication of the R.Issuer and (2) integrity protection for the transferred
1291
TMD. The third aspect is countered by SO.REPLAY, which – among others –
1292
defines protection against replay attacks concerning TMD writes.
1293
T.KEY_ACCESS is about (1) initialization and updates/writes of keys by roles
1294
other than R.Initializer and R.Issuer, respectively, (2) undetected modification
1295
of keys during transfer, (3) eavesdropping of keys during transfer, (4) reading
1296
out current keys from the TOE, (4) reading out previous key values from the
1297
TOE, and (5) replay of a key initialization/update/write. SO.KEY_ACCESS
1298
counters the first four of these aspects, as it defines (1) a secure mechanism
1299
for key initialization/updates/writes that provides authentication of the
1300
corresponding user, (2) integrity protection for the transferred keys, (3)
1301
confidentiality protection for the transferred keys, and (4) non-readability of
1302
keys. The fifth aspect is countered by SO.REPLAY, which – among others –
1303
defines protection against replay attacks concerning key
1304
initialization/updates/writes.
1305
8.1.4 Coverage of the Organizational Security Policies
1306
OSP.TXN_SECURE is covered by SO.TXN_SECURE, as SO.TXN_SECURE
1307
just defines the cryptographic functionalities as requested by
1308
OSP.TXN.SECURE. The aspect of OSP.TXN_SECURE that no authentication
1309
is needed is covered in SO.TXN_SECURE by the fact that the cryptographic
1310
functionalities shall be provided to R.POS_Terminal, which is an
1311
unauthenticated role.
1312
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 44
OSP.SN is covered by SO.SN, as SO.SN just defines the serial number
1313
increment functionalities as requested by OSP.SN. The aspect of OSP.SN that
1314
no authentication is needed is covered in SO.SN by the fact that the increment
1315
functionalities shall be provided to R.POS_Terminal, which is an
1316
unauthenticated role.
1317
8.1.5 Security Objectives Rationale from [JCOP41V231ST]
1318
The following table is reproduced from [JCOP41V231ST] to illustrate the
1319
coverage of the threats by the security objectives concerning [JCOP41V231].
1320
The corresponding justification text has not been reproduced here, please
1321
consult [JCOP41V231ST] if needed.
1322
O.PROTECT_DATA
O.OS_DECEIVE
O.SIDE_CHANNEL
O.FAULT_PROTECT
O.PHYSICAL
O.CARD-MANAGEMENT
O.SHRD_VAR_INTEG
O.SHRD_VAR_CONFID
O.FIREWALL
O.NATIVE
O.OPERATE
O.ALARM
O.RESOURCES
O.REALLOCATION
O.SID
O.SCP.IC
O.SCP.RECOVERY
O.SCP.SUPPORT
O.CIPHER
O.PIN-MNGT
O.KEY-MNGT
O.TRANSACTION
O.RND
T.ACCESS_DATA X
T.OS_OPERATE X X
T.OS_DECEIVE X
T.LEAKAGE X
T.FAULT X
T.PHYSICAL X X
T.CONFID-JCS-DATA
T.INTEG-JCS-DATA
X X X X X X X
T.CONFID-APPLI-DATA X X X X X X X X X X X X X
T.INTEG-APPLI-DATA X X X X X X X X X X X X X
T.SID.1 X X X
T.SID.2 X X X X X
T.NATIVE X
T.RESOURCES X X X X
T.RND X
Table 8-2: Security objectives rationale from [JCOP41V231ST]
1323
1324
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 45
8.2 Security Requirements Rationale
1325
SO.REPLAY
SO.KEY_ACCESS
SO.TMD_ACCESS
SO.INTEGRITY
SO.TXN_SECURE
SOE.DLV
SOE.USE_DIAG
SOE.KEYS
SOE.DEV
FCS_CKM.4/TSAM X
FCS_COP.1/TSAM X
FDP_ACC.1/KEY X
FDP_ACC.1/TMD X
FDP_ACF.1/KEY X
FDP_ACF.1/TMD X
FDP_ITC.1/KEY X
FDP_ITC.1/TMD X
FDP_SDI.2/TSAM X
FDP_UCT.1/KEY X
FDP_UIT.1/TSAM X X X
FIA_AFL.1/TSAM X X
FIA_UAU.1/TSAM X X
FIA_UAU.4/TSAM X X
FIA_UAU.5/TSAM X X
FIA_UID.1/TSAM X X
FMT_MSA.1/TSAM X X
FMT_MSA.2/TSAM X X
FMT_MSA.3/TSAM X X
FMT_SMF.1/TSAM X X
FMT_SMR.1/TSAM X X
FTP_ITC.1/TSAM X X
FCS_CKM.1/ENV X
FDP_UCT.1/ENV X
FDP_UIT.1/ENV X
FTP_ITC.1/ENV X
FDP_IFC.2/BCV X
FDP_IFF.2/BCV X
FMT_MSA.1/BCV X
FMT_MSA.2/BCV X
FMT_MSA.3/BCV X
FMT_SMF.1/BCV X
FMT_SMR.1/BCV X
FRU_RSA.1/BCV X
Table 8-3: Security requirements rationale
1326
8.2.1 Fulfilment of security objectives
1327
SO.REPLAY is met by FDP_UIT.1/TSAM, as this requires replay protection
1328
concerning key initialization/updates/writes as defined in SO.REPLAY.
1329
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 46
SO.KEY_ACCESS defines (1) access control for key initialization, writes and
1330
updates, and (2) confidentiality protection and (3) integrity protection during
1331
those operations.
1332
The first aspect is met by the access control requirements FDP_ACC.1/KEY
1333
and FDP_ACF.1/KEY. Management for the governing security attribute life-
1334
cycle state is provided by FMT_MSA.1/TSAM, FMT_MSA.2/TSAM,
1335
FMT_MSA.3/TSAM and FMT_SMF.1/TSAM. The identification and
1336
authentication and ability to distinguish roles, which are a precondition for
1337
performing the access control, are provided by FIA_AFL.1/TSAM,
1338
FIA_UAU.1/TSAM, FIA_UAU.4/TSAM, FIA_UAU.5/TSAM and
1339
FIA_UID.1/TSAM and FMT_SMR.1/TSAM.
1340
The second aspect, key confidentiality, is met by FDP_UCT.1/KEY and
1341
FTP_ITC.1/TSAM, furthermore FCS_CKM.4/TSAM supports it by ensuring
1342
that values of previous keys are no longer physically available after a key
1343
update/write.
1344
The third aspect, key integrity, is provided by FDP_UIT.1/TSAM and
1345
FTP_ITC.1/TSAM.
1346
Finally, the key import operations are defined by FDP_ITC.1/KEY.
1347
SO.TMD_ACCESS defines (1) access control for TMD writes, and (2) integrity
1348
protection during those operations.
1349
The first aspect is met by the access control requirements FDP_ACC.1/TMD
1350
and FDP_ACF.1/TMD. Management for the governing security attribute life-
1351
cycle state is provided by FMT_MSA.1/TSAM, FMT_MSA.2/TSAM,
1352
FMT_MSA.3/TSAM and FMT_SMF.1/TSAM. The identification and
1353
authentication and ability to distinguish roles, which are a precondition for
1354
performing the access control, are provided by FIA_AFL.1/TSAM,
1355
FIA_UAU.1/TSAM, FIA_UAU.5/TSAM, FIA_UID.1/TSAM and
1356
FMT_SMF.1/TSAM.
1357
The second aspect, TMD integrity, is provided by FDP_UIT.1/TSAM and
1358
FTP_ITC.1/TSAM.
1359
Finally, the TMD import operation is defined by FDP_ITC.1/TMD.
1360
SO.INTEGRITY defines (1) integrity detection concerning RC, LCS and TMD
1361
in storage and (2) prevention to use corrupted data and provision of an error
1362
message.
1363
The first aspect is met by FDP_SDI.2.1/TSAM, which requests the
1364
corresponding stored data integrity monitoring. The second aspect is met by
1365
FDP_SDI.2.2/TSAM, which requests a message to the user and dedicated
1366
response actions that prevent usage of the corrupted data.
1367
SO.TXN_SECURE defines cryptographic services of encryption, decryption
1368
and MAC generation using 3/DES. This is directly met by FCS_COP.1/TSAM.
1369
SOE.DLV is purely related to non-IT environmental aspects (organizational
1370
measures concerning verification of delivered items), therefore there are no
1371
related SFRs.
1372
SOE.USE_DIAG defines the capabilities of the IT environment concerning
1373
integrity and confidentiality protection during data transfer. This is directly met
1374
by FDP_UCT.1/ENV, FDP_UIT.1/ENV and FTP_ITC.1/ENV.
1375
SOE.KEYS defines random number generation as the method to generate
1376
keys. This is directly met by FCS_CKM.1/ENV. The remaining aspects of
1377
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 47
SOE.KEYS (confidentiality and integrity protection of keys in the environment)
1378
may be solely related to non-IT measures, therefore there are no related SFRs.
1379
SOE.DEV defines performance of byte code verification during development.
1380
This is met by the FDP_IFC.2/BCV, FDP_IFF.2/BCV, FMT_MSA.1/BCV,
1381
FMT_MSA.2/BCV, FMT_MSA.3/BCV, FMT_SMF.1/BCV, FMT_SMR.1/BCV,
1382
FRU_RSA.1/BCV concerning byte code verification. The remaining aspects of
1383
SOE.DEV (no native code loading, no delivery of GlobalPlatform keys and
1384
general development security aspects) may be solely related to non-IT
1385
measures, therefore there are no related SFRs.
1386
8.2.2 Traceability of the Security Functional Requirements
1387
FCS_CKM.4/TSAM requires physical overwriting of previous key values keys
1388
during updates/writes and therefore traces back to the aspect of
1389
SO.KEY_ACCESS that previous key values shall not be accessible.
1390
FCS_COP.1/TSAM requires the cryptographic functions needed to secure
1391
transactions and therefore traces back to SO.TXN_SECURE.
1392
FDP_ACC.1/KEY and FDP_ACF.1/KEY define access control concerning
1393
keys and therefore trace back to SO.KEY_ACCESS.
1394
FDP_ACC.1/TMD and FDP_ACF.1/TMD define access control concerning
1395
TMD and therefore trace back to SO.TMD_ACCESS.
1396
FDP_ITC.1/KEY defines details about the key import operation and therefore
1397
traces back to SO.KEY_ACCESS.
1398
FDP_ITC.1/TMD defines details about the TMD import operation and therefore
1399
traces back to SO.TMD_ACCESS.
1400
FDP_SDI.2/TSAM requires integrity protection concerning stored RC, LCS
1401
and TMD, and therefore traces back to SO.INTEGRITY.
1402
FDP_UCT.1/KEY requires confidentiality protection concerning transfer of
1403
keys and therefore traces back to SO.KEY_ACCESS.
1404
FDP_UIT.1/TSAM requires integrity and replay protection concerning transfer
1405
of keys and TMD and therefore traces back to SO.KEY_ACCESS,
1406
SO.TMD_ACCESS and SO.REPLAY.
1407
FIA_AFL.1/TSAM, FIA_UAU.1/TSAM, FIA_UAU.4/TSAM, FIA_UAU.5/TSAM
1408
and FIA_UID.1/TSAM define requirements about identification and
1409
authentication necessary as a precondition for the access control about keys
1410
and TMD, and therefore trace back to SO.KEY_ACCESS and
1411
SO.TMD_ACCESS.
1412
FMT_MSA.1/TSAM, FMT_MSA.2/TSAM, FMT_MSA.3/TSAM and
1413
FMT_SMF.1/TSAM define requirements about the management of the life-
1414
cycle state, which is the governing security attribute for access control for keys
1415
and TMD, and therefore traces back to SO.KEY_ACCESS and
1416
SO.TMD_ACCESS.
1417
FMT_SMR.1/TSAM requires the ability to distinguish roles, which is a
1418
precondition for access control for keys and TMD, and therefore traces back to
1419
SO.KEY_ACCESS and SO.TMD_ACCESS
1420
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 48
FTP_ITC.1/TSAM defines a trusted channel that provides confidentiality
1421
and/or integrity protection for key/TMD transfer, and therefore traces back to
1422
SO.KEY_ACCESS and SO.TMD_ACCESS.
1423
FCS_CKM.1/ENV defines random number generation as key generation
1424
algorithm to be used, and therefore traces back to the corresponding aspect of
1425
SOE.KEYS.
1426
FDP_UCT.1/ENV, FDP_UIT.1/ENV and FTP_ITC.1/ENV define requirements
1427
for remote IT products in the environment concerning confidentiality and
1428
integrity protection during data transfer to the TOE, and therefore trace back to
1429
SOE.USE_DIAG.
1430
FDP_IFC.2/BCV, FDP_IFF.2/BCV, FMT_MSA.1/BCV, FMT_MSA.2/BCV,
1431
FMT_MSA.3/BCV, FMT_SMF.1/BCV, FMT_SMR.1/BCV, FRU_RSA.1/BCV
1432
define requirements concerning byte code verification, and therefore trace
1433
back to the corresponding aspect of SOE.DEV.
1434
8.2.3 Suitability of Security Assurance Requirements
1435
As the TOE shall be used in a financial context and its assets will have high financial
1436
value, a corresponding high level of robustness of and confidence in the TOE is
1437
required. Therefore as assurance requirements EAL4 augmented by ADV_IMP.2 and
1438
AVA_VLA.4 have been chosen.
1439
Confidence will be provided, as EAL4 requires a thorough evaluation, in particular of
1440
the design of the TOE (which even has been extended by the augmentation of
1441
ADV_IMP.2).
1442
Sufficient robustness of the TOE against penetration attacks shall be provided by
1443
application of AVA_VLA.4, which provides for a systematic vulnerability analysis and
1444
finally for a TOE being resistant even to attackers owing a high attack potential.
1445
8.2.4 Fulfillment of dependencies
1446
SFR used Dependencies acc. to CC Fulfilled by
FCS_CKM.4/TSAM [FDP_ITC.1 or FCS_CKM.1]
FMT_MSA.2
FDP_ITC.1/KEY
FMT_MSA.2/TSAM
FCS_COP.1/TSAM [FDP_ITC.1 or FCS_CKM.1]
FCS_CKM.4
FMT_MSA.2
FDP_ITC.1/KEY
FCS_CKM.4/TSAM
FMT_MSA.2/TSAM
FDP_ACC.1/KEY FDP_ACF.1 FDP_ACF.1/KEY
FDP_ACC.1/TMD FDP_ACF.1 FDP_ACF.1/TMD
FDP_ACF.1/KEY FDP_ACC.1
FMT_MSA.3
FDP_ACC.1/KEY
FMT_MSA.3/TSAM
FDP_ACF.1/TMD FDP_ACC.1
FMT_MSA.3
FDP_ACC.1/TMD
FMT_MSA.3/TSAM
FDP_ITC.1/KEY [FDP_ACC.1 or FDP_IFC.1]
FMT_MSA.3
FDP_ACC.1/KEY
FMT_MSA.3/TSAM
FDP_ITC.1/TMD [FDP_ACC.1 or FDP_IFC.1]
FMT_MSA.3
FDP_ACC.1/TMD
FMT_MSA.3/TSAM
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 49
SFR used Dependencies acc. to CC Fulfilled by
FDP_SDI.2/TSAM No dependencies Not applicable
FDP_UCT.1/KEY [FTP_ITC.1 or FTP_TRP.1]
[FDP_ACC.1 or FDP_IFC.1]
FTP_ITC.1/TSAM
FDP_ACC.1/KEY
FDP_UIT.1/TSAM [FDP_ACC.1 or FDP_IFC.1]
[FTP_ITC.1 or FTP_TRP.1]
FDP_ACC.1/KEY, FDP_ACC.1/TMD
FTP_ITC.1/TSAM
FIA_AFL.1/TSAM FIA_UAU.1 FIA_UAU.1/TSAM
FIA_UAU.1/TSAM FIA_UID.1 FIA_UID.1/TSAM
FIA_UAU.4/TSAM No dependencies Not applicable
FIA_UAU.5/TSAM No dependencies Not applicable
FIA_UID.1/TSAM No dependencies Not applicable
FMT_MSA.1/TSAM [FDP_ACC.1 or FDP_IFC.1]
FMT_SMR.1
FMT_SMF.1
FDP_ACC.1/KEY, FDP_ACC.1/TMD
FMT_SMR.1/TSAM
FMT_SMF.1/TSAM
FMT_MSA.2/TSAM ADV_SPM.1
[FDP_ACC.1 or FDP_IFC.1]
FMT_MSA.1
FMT_SMR.1
ADV_SPM.1
FDP_ACC.1/KEY, FDP_ACC.1/TMD
FMT_SMR.1/TSAM
FMT_SMF.1/TSAM
FMT_MSA.3/TSAM FMT_MSA.1
FMT_SMR.1
FMT_MSA.1/TSAM
FMT_SMR.1/TSAM
FMT_SMF.1/TSAM No dependencies Not applicable
FMT_SMR.1/TSAM FIA_UID.1 FIA_UID.1/TSAM
FTP_ITC.1/TSAM No dependencies Not applicable
Table 8-4: Fulfillment of TOE SFR dependencies
1447
Concerning the security assurance requirements all dependencies are fulfilled, as
1448
• all dependencies within an evaluation assurance level (here: EAL4) are
1449
automatically fulfilled,
1450
• the dependencies of the augmented component ADV_IMP.2 (i.e. ADV_LLD.1,
1451
ADV_RCR.1 and ALC_TAT.1) are already satisfied within EAL4,
1452
• and the dependencies of the augmented component AVA_VLA.4 (i.e.
1453
ADV_FSP.1, ADV_HLD.2, ADV_IMP.1, ADV_LLD.1, AGD_ADM.1 and
1454
AGD_USR.1) are already satisfied within EAL4.
1455
8.2.5 Suitability of minimum strength of function (SoF) level
1456
As the TOE shall be used in a financial context and its assets will have high financial
1457
value, the TOE also shall be highly resistant against attacks on its functions. The
1458
protection against attacks with a high attack potential dictates a strength of function
1459
rating of “high”.
1460
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 50
8.3 TOE Summary Specification Rationale
1461
SF.AUT_GP
SF.CP_GP
SF.CP_MK
SF.AC
SF.LCM
SF.SDP
SF.USE_WK
FCS_CKM.4/TSAM X
FCS_COP.1/TSAM X
FDP_ACC.1/KEY X
FDP_ACC.1/TMD X
FDP_ACF.1/KEY X
FDP_ACF.1/TMD X
FDP_ITC.1/KEY X X
FDP_ITC.1/TMD X X
FDP_SDI.2/TSAM X
FDP_UCT.1/KEY X X
FDP_UIT.1/TSAM X X
FIA_AFL.1/TSAM X
FIA_UAU.1/TSAM X
FIA_UAU.4/TSAM X
FIA_UAU.5/TSAM X X X
FIA_UID.1/TSAM X
FMT_MSA.1/TSAM X
FMT_MSA.2/TSAM X
FMT_MSA.3/TSAM X
FMT_SMF.1/TSAM X
FMT_SMR.1/TSAM X
FTP_ITC.1/TSAM X X
Table 8-5: TSS rationale
1462
8.3.1 Traceability and Satisfaction of the TOE SFRs
1463
The following table shows that the TOE security functions satisfy the
1464
corresponding SFRs, that all SFRs are addressed and that there is no aspect
1465
of a security function that cannot be traced back to an SFR. This is achieved
1466
by breaking down the security functions in individual statements and mapping
1467
each statement to the corresponding SFR(s).
1468
Statements of Security Function Fulfilled SFR(s)
SF.AUT_GP: SF.AUT_GP will authenticate the
user by a challenge-response mechanism using
GlobalPlatform keys. …
FIA_UAU.5.1/TSAM: The TSF shall provide
[GlobalPlatform card manager authentication, …]
to support user authentication.
SF.AUT_GP: … For each authentication attempt,
SF.AUT_GP will present a new random number
as a challenge. …
FIA_UAU.4.1/TSAM: The TSF shall prevent
reuse of authentication data related to
[GlobalPlatform card manager
authentication, …].
SF.AUT_GP: … Only if the user provides the
corresponding correct response, the user is
authenticated as the initializer (R.Initializer). …
FIA_UAU.5.2/TSAM: The TSF shall authenticate
any user’s claimed identity according to the
[following rules: … GlobalPlatform card manager
authentication is used for authentication of
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 51
Statements of Security Function Fulfilled SFR(s)
R.Initializer …]
SF.AUT_GP: … In case of a successful
authentication, SF.AUT_GP will establish session
keys that are later on used by SF.CP_GP. …
FTP_ITC.1.1/TSAM The TSF shall provide a
communication channel between itself and a
remote trusted IT product that is logically distinct
from other communication channels and
provides assured identification of its end points
and protection of the channel data from
modification or disclosure.
FTP_ITC.1.2/TSAM The TSF shall permit [the
remote trusted IT product] to initiate
communication via the trusted channel.
FTP_ITC.1.3/TSAM The TSF shall initiate
communication via the trusted channel for
[performing initialize, … of MK …].
SF.AUT_GP: … SF.AUT_GP is only available in
TSAM.Phase_2.
FIA_UAU.5.2/TSAM: The TSF shall authenticate
any user’s claimed identity according to the
[following rules: … GlobalPlatform card manager
authentication is used for authentication … in
TSAM.Phase_2. …]
SF.CP_GP: SF.CP_GP provides
confidentiality … protection of communication
data between the user and the TOE. This is done
by decryption … using session keys. The
corresponding session keys are established after
a successful authentication by SF.AUT_GP. …
FDP_UCT.1.1/KEY The TSF shall enforce the
[Key Access SFP] to be able to [receive] objects
in a manner protected from unauthorised
disclosure.
FTP_ITC.1.1/TSAM The TSF shall provide a
communication channel between itself and a
remote trusted IT product that is logically distinct
from other communication channels and
provides assured identification of its end points
and protection of the channel data from …
disclosure.
FTP_ITC.1.2/TSAM The TSF shall permit [the
remote trusted IT product] to initiate
communication via the trusted channel.
FTP_ITC.1.3/TSAM The TSF shall initiate
communication via the trusted channel for
[performing initialize, … of MK …].
SF.CP_GP: SF.CP_GP provides … integrity
protection of communication data between the
user and the TOE. This is done by … verification
of cryptographic checksum using session keys.
The corresponding session keys are established
after a successful authentication by
SF.AUT_GP. …
FDP_UIT.1.1/TSAM The TSF shall enforce the
[Key Access SFP and TMD Access SFP] to be
able to [receive] user data in a manner protected
from [modification, insertion, replay] errors.
FDP_UIT.1.2/TSAM The TSF shall be able to
determine on receipt of user data, whether
[modification, insertion, replay] has occurred.
FTP_ITC.1.1/TSAM The TSF shall provide a
communication channel between itself and a
remote trusted IT product that is logically distinct
from other communication channels and
provides assured identification of its end points
and protection of the channel data from
modification ...
FTP_ITC.1.2/TSAM The TSF shall permit [the
remote trusted IT product] to initiate
communication via the trusted channel.
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 52
Statements of Security Function Fulfilled SFR(s)
FTP_ITC.1.3/TSAM The TSF shall initiate
communication via the trusted channel for
[performing initialize, … of MK …].
SF.CP_GP: … SF.CP_GP is only available in
TSAM.Phase_2.
FIA_UAU.5.2/TSAM The TSF shall authenticate
any user’s claimed identity according to the
[following rules:
1. GlobalPlatform card manager
authentication is used for authentication of
R.Initializer in TSAM.Phase_2. …].
(Remark: SF.CP_GP uses the same
GlobalPlatform functionality as SF.AUT_GP.)
SF.CP_MK: SF.CP_MK assures integrity,
authenticity … confidentiality of communication
data between the user and the TOE for a single
command. This is done by MAC verification …
using session keys which are only valid for this
command. To do so, SF.CP_MK performs the
following … steps:
1. For establishing the session keys, a
random number RN is provided by SF.CP_MK to
the user as the very first step.
2. SF.CP_MK receives the command from
the user.
… 4. SF.CP_MK generates the session key for
MAC verification by encrypting RN with MK.
SF.CP_MK verifies the MAC within the command.
If verification fails, it … returns an error code and
stops processing. Otherwise, the issuer (R.Issuer)
is authenticated, and SF.CP_MK … continues
with the next step. …
FDP_UIT.1.1/TSAM The TSF shall enforce the
[Key Access SFP and TMD Access SFP] to be
able to [receive] user data in a manner protected
from [modification, insertion, replay] errors.
FDP_UIT.1.2/TSAM The TSF shall be able to
determine on receipt of user data, whether
[modification, insertion, replay] has occurred.
SF.CP_MK: SF.CP_MK assures … optionally
confidentiality of communication data between the
user and the TOE for a single command. This is
done by … decryption using session keys which
are only valid for this command. To do so,
SF.CP_MK performs the following … steps:
1. For establishing the session keys, a
random number RN is provided by SF.CP_MK to
the user as the very first step.
2. SF.CP_MK receives the command from
the user.
... 5. If the command includes encrypted data,
SF.CP_MK generates the session key for
decryption by encrypting the inverse of RN with
MK and SF.CP_MK decrypts the encrypted
data. …
FDP_UCT.1.1/KEY The TSF shall enforce the
[Key Access SFP] to be able to [receive] objects
in a manner protected from unauthorised
disclosure.
SF.CP_MK: … 3. SF.CP_MK checks the
value of RC. If it is equal to 3, SF.CP_MK returns
an error code and stops processing. Otherwise, it
continues with the next step.
4. … If verification fails, it increases RC,
returns an error code and stops processing.
Otherwise, … SF.CP_MK resets RC to zero and
FIA_AFL.1.1/TSAM The TSF shall detect when
[three consecutive] unsuccessful authentication
attempts occur related to [authentication with
MK].
FIA_AFL.1.2/TSAM When the defined number
of unsuccessful authentication attempts has
been met or surpassed, the TSF shall [no longer
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 53
Statements of Security Function Fulfilled SFR(s)
continues with the next step. … allow authentication with MK].
SF.CP_MK: …SF.CP_MK is only available in
TSAM.Phase_3 and TSAM.Phase_4.
FIA_UAU.5.2/TSAM The TSF shall authenticate
any user’s claimed identity according to the
[following rules:
… 2. Authentication with MK is used for
authentication of R.Issuer in TSAM.Phase_3 and
TSAM.Phase_4].
SF.AC: SF.AC enforces access control rules
based on commands, user roles and life cycle
state. …
FDP_ACC.1.1/KEY The TSF shall enforce the
[Key Access SFP] on [subjects: users, objects:
MK, WKs and operation: initialize, first update,
update, write, read and use].
FDP_ACC.1.1/TMD The TSF shall enforce the
[TMD Access SFP] on [subjects: users, objects:
TMD and operation: read, write and increment].
SF.AC: … For commands needing
authentication, SF.AC identifies user roles
R.Initializer and R.Issuer with SF.AUT_GP and
SF.CP_MK, respectively. For commands not
needing authentication, SF.AC identifies the user
role as R.POS_Terminal. …
FMT_SMR.1.1/TSAM The TSF shall maintain
the roles [R.Initializer, R.Issuer and
R.POS_Terminal].
FMT_SMR.1.2/TSAM The TSF shall be able to
associate users with roles.
FIA_UAU.1.1/TSAM The TSF shall allow
[encryption, decryption and MAC generation by
corresponding WK, reading TMD, incrementing
TSN and/or BSN of TMD] on behalf of the user
to be performed before the user is authenticated.
FIA_UAU.1.2/TSAM The TSF shall require each
user to be successfully authenticated before
allowing any other TSF-mediated actions on
behalf of that user.
FIA_UID.1.1/TSAM The TSF shall allow
[encryption, decryption and MAC generation by
corresponding WK, reading TMD, incrementing
TSN and/or BSN of TMD] on behalf of the user
to be performed before the user is identified.
FIA_UID.1.2/TSAM The TSF shall require each
user to be successfully identified before allowing
any other TSF-mediated actions on behalf of that
user.
(see also SF.AUT_GP and SF.CP_MK)
SF.AC: … The following is SF.AC-enforced
access control rules:
1. The initializer (R.Initializer) is allowed to
initialize MK in TSAM.Phase_2.
2. The issuer (R.Issuer) is allowed to
perform first update of MK in TSAM.Phase_3.
The issuer is also allowed to perform updates of
MK and writes of WKs in TSAM.Phase_4.
3. No user can read any of the MK and WKs
out of the TOE.
4. The issuer (R.Issuer) is allowed to write
TMD in TSAM.Phase_3.
5. The user R.POS_Terminal is allowed to
FDP_ACF.1.1/KEY The TSF shall enforce the
[Key Access SFP] to objects based on the
following: [subject attribute: user role
{R.Initializer, R.Issuer, R.POS_Terminal} and
object attribute: life cycle state { TSAM.Phase_2,
TSAM.Phase_3, TSAM.Phase_4}].
FDP_ACF.1.2/KEY The TSF shall enforce the
following rules to determine if an operation
among controlled subjects and controlled objects
is allowed: [
1. A user with user role {R.Initializer} is
allowed to initialize the MK if the life cycle state
is {TSAM.Phase_2}.
2. A user with user role {R.Issuer} is
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 54
Statements of Security Function Fulfilled SFR(s)
read TMD out of the TOE in TSAM.Phase_4.
6. The user R.POS_Terminal is allowed to
increment TSN of TMD in TSAM.Phase_4 unless
the value of TSN is equal to 999999.
7. The user R.POS_Terminal is allowed to
increment BSN of TMD in TSAM.Phase_4 unless
the value of BSN is equal to 9999.
8. The user R.POS_Terminal is allowed to
use WKs according to SF.USE_WK in
TSAM.Phase_4.
Access attempts not matching any of these rules
will be rejected by SF.AC.
allowed to do first update of the MK if the life
cycle state is {TSAM.Phase_3}.
3. A user with user role {R.Issuer} is
allowed to do updates of the MK if the life cycle
state is {TSAM.Phase_4}.
4. A user with user role {R.Issuer} is
allowed to do writes of the WK if the life cycle
state is {TSAM.Phase_4}.
5. A user with user role {R.POS_Terminal}
is allowed to use the WK if the life cycle state is
{TSAM.Phase_4}.]
FDP_ACF.1.3/KEY The TSF shall explicitly
authorise access of subjects to objects based on
the following additional rules: [no other rule].
FDP_ACF.1.4/KEY The TSF shall explicitly deny
access of subjects to objects based on the [rule
that no user can read any of the MK and WKs
out of the TOE].
FDP_ACF.1.1/TMD The TSF shall enforce the
[TMD Access SFP] to objects based on the
following: [subject attribute: user role {R.Issuer,
R.POS_Terminal} and object attribute: life cycle
state {TSAM.Phase_3, TSAM.Phase_4}].
FDP_ACF.1.2/TMD The TSF shall enforce the
following rules to determine if an operation
among controlled subjects and controlled objects
is allowed: [
1. A user with user role {R.Issuer} is
allowed to write TMD if the life cycle state is
{TSAM.Phase_3}.
2. A user with user role {R.POS_Terminal}
is allowed to read TMD and increment TSN/BSN
of TMD if the life cycle state is
{TSAM.Phase_4}.]
FDP_ACF.1.3/TMD The TSF shall explicitly
authorise access of subjects to objects based on
the following additional rules: [no other rule].
FDP_ACF.1.4/TMD The TSF shall explicitly deny
access of subjects to objects based on the
[following rules:
1. Increment of TSN is denied if the value
of TSN is equal to 999999.
2. Increment of BSN is denied if the value
of BSN is equal to 9999.].
SF.AC: … 1. The initializer (R.Initializer) is
allowed to initialize MK ...
2. The issuer (R.Issuer) is allowed to
perform first update of MK ... The issuer is also
allowed to perform updates of MK and writes of
WKs …
FDP_ITC.1.1/KEY The TSF shall enforce the
[Key Access SFP] when importing user data,
controlled under the SFP, from outside of the
TSC.
FDP_ITC.1.2/KEY The TSF shall ignore any
security attributes associated with the user data
when imported from outside the TSC.
SF.AC: … 4. The issuer (R.Issuer) is allowed FDP_ITC.1.1/TMD The TSF shall enforce the
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 55
Statements of Security Function Fulfilled SFR(s)
to write TMD … [TMD Access SFP] when importing user data,
controlled under the SFP, from outside of the
TSC.
FDP_ITC.1.2/TMD The TSF shall ignore any
security attributes associated with the user data
when imported from outside the TSC.
SF.LCM: SF.LCM provides management of the
life cycle state of the TOE, … Life cycle state
changes are irreversible. No other life cycle state
changes are performed except the
aforementioned ones.
FMT_SMF.1.1/TSAM The TSF shall be capable
of performing the following security management
functions: [modification of the life state according
to FMT_MSA.1.1/TSAM, FDP_ITC.1.3 /KEY and
FDP_ITC.1.3 /TMD].
SF.LCM: … It does so by the following:
1. SF.LCM automatically initializes the life
cycle state to TSAM.Phase_2 during applet
installation in TSAM production. …
FMT_MSA.3.1/TSAM The TSF shall enforce the
[Key Access SFP and TMD Access SFP] to
provide [restrictive] default values for security
attributes that are used to enforce the SFP.
FMT_MSA.3.2/TSAM The TSF shall allow the
[nobody] to specify alternative initial values to
override the default values when an object or
information is created.
FMT_MSA.2.1/TSAM The TSF shall ensure that
only secure values are accepted for security
attributes.
SF.LCM: … 2. When MK has been successfully
initialized by R.Initializer in TSAM.Phase_2,
SF.LCM will change the life cycle state to
TSAM.Phase_3. …
FDP_ITC.1.3/KEY The TSF shall enforce the
following rules when importing user data
controlled under the SFP from outside the TSC: [
1. After import of MK by initialize operation,
the security attribute life cycle state shall change
from TSAM.Phase_2 to TSAM.Phase_3.]
FMT_MSA.1.1/TSAM The TSF shall enforce the
[Key Access SFP and TMD Access SFP] to
restrict the ability to [modify] the security
attributes [life cycle state] to [R.Initializer and …].
(Remark: SF.AC enforces that initialization can
only be done by R.Initializer, and SF.LCM links
the LCS transition to initialization operation.)
FMT_MSA.2.1/TSAM The TSF shall ensure that
only secure values are accepted for security
attributes.
SF.LCM: … 3. When TMD has been success-
fully written by R.Issuer in TSAM.Phase_3,
SF.LCM will change the life cycle state to
TSAM.Phase_4. …
FDP_ITC.1.3/TMD The TSF shall enforce the
following rules when importing user data
controlled under the SFP from outside the TSC: [
1. After import of TMD by write operation,
the security attribute life cycle state shall change
from TSAM.Phase_3 to TSAM.Phase_4.]
FMT_MSA.1.1/TSAM The TSF shall enforce the
[Key Access SFP and TMD Access SFP] to
restrict the ability to [modify] the security
attributes [life cycle state] to [R.Initializer and
R.Issuer].
(Remark: SF.AC enforces that TMD writing can
only be done by R.Issuer, and SF.LCM links the
LCS transition to the TMD writing operation.)
FMT_MSA.2.1/TSAM The TSF shall ensure that
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 56
Statements of Security Function Fulfilled SFR(s)
only secure values are accepted for security
attributes.
SF.SDP: SF.SDP checks the integrity of RC, LCS
and TMD stored in EEPROM. If an integrity
violation is detected, the related command is
cancelled and an output error code is provided to
the external user.
1. Every time a value of RC, LCS or TMD is
written to EEPROM, SF.SDP will generate a
corresponding checksum in EEPROM.
2. On receipt of a command, SF.SDP will
verify the checksum of LCS and check whether
LCS has a valid value. If inconsistent checksum is
detected or the value of LCS is out of range,
SF.SDP will block processing of the command
and return the corresponding error code.
3. If RC is accessed internally, SF.SDP will
first of all verify the corresponding checksum. If
inconsistent checksum is detected, SF.SDP
blocks usage of RC and responds with a
corresponding error code. This also indirectly
blocks the usage of the corresponding MK.
4. If TMD is accessed internally, SF.SDP
will first of all verify the corresponding checksum.
If inconsistent checksum is detected, SF.SDP
blocks usage of TMD and responds with a
corresponding error code. …
FDP_SDI.2.1/TSAM The TSF shall monitor user
data stored within the TSC for [integrity errors]
on all objects, based on the following attributes
[checksum for TMD, LCS and RC].
FDP_SDI.2.2/TSAM Upon detection of a data
integrity error, the TSF shall [inform the user and
perform the actions in Table 5 1 depending on
which object is incurred in the data integrity
error].
SF.SDP: … Furthermore SF.SDP stores MK and
WKs in key objects of [JCOP41V231], and every
time a value of MK or WK is written to EEPROM,
the previous value is physically overwritten in the
memory assigned to the corresponding key
object.
FCS_CKM.4.1/TSAM The TSF shall destroy
cryptographic keys in accordance with a
specified cryptographic key destruction method
[previous MK and WKs are physically overwritten
by new keys] that meets the following: [none].
SF.USE_WK: SF.USE_WK provides the following
cryptographic services applicable to TD
(transaction data):
1. 3/DES encryption in ECB mode with key
size of 112 bits according to ANSI X 9.52 TECB
for encryption/decryption.
2. 3/DES decryption in ECB mode with key
size of 112 bits according to ANSI X 9.52 TECB
for encryption/decryption
3. 3/DES MAC generation in CBC mode
with key size 112 bits according to ANSI X 9.9
with ANSI X 9.52 TCBC Encryption for MAC
generation.
For each of the services there is one dedicated
WK in the TOE. SF.USE_WK is only available in
TSAM.Phase_4.
FCS_COP.1.1/TSAM The TSF shall perform
[encryption, decryption, MAC generation for TD
with dedicated keys in TSAM.Phase.4] in
accordance with a specified cryptographic
algorithm [3/DES in ECB or CBC mode] and
cryptographic key sizes [112 bits] that meet the
following: [ANSI X 9.52 TECB for
encryption/decryption, ANSI X 9.9 with ANSI X
9.52 TCBC Encryption for MAC generation].
Table 8-6: Traceability and Satisfaction of the TOE SFRs
1469
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 57
8.3.2 Mutual Support of the Security Functions
1470
Based on the results of the security requirements rationale, which has shown
1471
that the set of TOE SFRs forms a mutually supportive whole to fulfil the TOE
1472
security objectives, according to [CEM] § 491 the remaining question here is
1473
whether the additional information included in the security functions introduces
1474
no potential security weakness, such as possibilities to bypass tamper with, or
1475
deactivate other IT security functions. Based on the mapping of security
1476
functions and TOE SFRs in section 8.3.1 above, in the following this additional
1477
information in the security functions is listed, and its impact on the mutual
1478
support is discussed:
1479
Security
Function
Additional Information in SF
compared to corresponding
SFR(s)
Impact on Mutual Support of
Security Functions
Mechanism challenge-response
authentication (with a new
random number for each
authentication attempt)
introduced.
Only impact on SF_AUT_GP
itself; not in conflict with any
other SF.
SF.AUT_GP
Mechanism session key
generation introduced; link to
SF.CP_GP introduced.
Impact on SF.AUT_GP itself; is
a precondition to support
SF_CP_GP; not in conflict with
any other SF.
Mechanism decryption using
session keys introduced; link to
SF.AUT_GP introduced.
Impact on SF_CP_GP itself; is
supported by session key
generation of SF.AUT_GP; not
in conflict with any other SF.
SF.CP_GP
Mechanism verification of
cryptographic checksum using
session keys introduced; link to
SF.AUT_GP introduced.
Impact on SF_CP_GP itself; is
supported by session key
generation of SF.AUT_GP; not
in conflict with any other SF.
Mechanism command-wise
MAC verification using session
keys introduced.
Only impact on SF_CP_MK
itself; not in conflict with any
other SF.
SF.CP_MK
Mechanism command- wise
decryption using session keys
introduced.
Only impact on SF_CP_MK
itself; not in conflict with any
other SF.
SF.AC None. N/A
SF.LCM None. N/A
SF.SDP Details concerning kind and time
of checksum verification
introduced.
Impact on SF.SDP and all other
SFs, as the TOE will stop a
running session in case of a
detected integrity error, but not
in conflict with the other SFs or
the corresponding security
objectives.
SF.USE_WK None. N/A.
Table 8-7: Analysis of Mutual Support of the SFs
1480
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 58
8.3.3 Validity of SOF-claims
1481
In section 5 the minimum strength of function level for this TOE is claimed to
1482
be SOF-high. This is consistent to the strength of function claims in section
1483
6.2, which is also SOF-high for all the rateable functions.
1484
8.3.4 Compliance of assurance measures
1485
The assurance measures as stated in section 6.3 address all aspects of the
1486
assurance requirements of the chosen set EAL4+ and are therefore compliant
1487
in principle. Whether this is actually the case will be inspected during
1488
evaluation of the corresponding evidence.
1489
8.4 PP Claims Rationale
1490
This security target claims conformance to the protection profile [JCSPP],
1491
“Minimal Configuration”, as the security target of the underlying platform,
1492
[JCOP41V231ST], does. The following subsections show that this ST is in fact
1493
comformant to [JCSPP], “Minimal Configuration”
1494
8.4.1 PP Conformance concerning Assumptions
1495
All assumptions from [JCSPP] “Minimal Configuration” (which are restated in
1496
[JCOP41V231ST]) are covered by this ST the following way:
1497
Assumption from [JCSPP] (and
[JCOP41V231ST])
Coverage in this ST
A.NATIVE (native code
APIs/applications ensure that
security policies/objectives are not
violated)
by A.DEV (during TSAM production/operation
no native code will be loaded into the smart
card controller)
A.NO-DELETION (no deletion of
installed applets/packages
possible)
A.NO-INSTALL (no post-issuance
installation of applets)
by A.DEV (GlobalPlatform keys are not
delivered, therefore no applet management
possible)
A.VERIFICATION (byte code is
verified to ensure its validity at
execution time)
by A.DEV (byte code verification will be
performed during TSAM
development/production)
Table 8-8: Coverage of Assumptions from [JCSPP] “Minimal Configuration”
1498
8.4.2 PP Conformance concerning Threats
1499
All threats from [JCSPP] “Minimal Configuration” (regarding the Java Card
1500
platform level) are contained in [JCOP41V231ST] and also this ST, see Table
1501
3-1 hereinbefore. The additional threats in this ST regard the TSAM application
1502
level and are not in contradiction to the ones from [JCSPP].
1503
8.4.3 PP Conformance concerning Organizational Security Policies
1504
There is no OSP in [JCSPP] “Minimal Configuration”.
1505
8.4.4 PP Conformance concerning Security Objectives for the TOE
1506
The security objectives for the TOE from [JCSPP] Minimal Configuration, all
1507
regarding the Java Card platform level, are contained in [JCOP41V231ST] and
1508
also this ST, see section 4.1.2 hereinbefore. The additional security objectives
1509
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 59
for the TOE in this ST regard the TSAM application level and are not in
1510
contradiction to the ones from [JCSPP].
1511
8.4.5 PP Conformance concerning Security Objectives for the Environment
1512
All security objectives for the environment from [JCSPP] “Minimal Configuration”
1513
(which are restated in [JCOP41V231ST]) are covered by this ST the following
1514
way:
1515
Security Objective from [JCSPP]
(and [JCOP41V231ST])
Coverage in this ST
OE.NATIVE (native code
APIs/applications ensure that
security policies/objectives are not
violated)
by SOE.DEV (during TSAM
production/operation no native code will be
loaded into the smart card controller)
OE.NO-DELETION (no deletion of
installed applets/packages
possible)
OE.NO-INSTALL (no post-
issuance installation of applets)
by SOE.DEV (GlobalPlatform keys are not
delivered, therefore no applet management
possible)
OE.VERIFICATION (byte code is
verified to ensure its validity at
execution time)
by SOE.DEV (byte code verification will be
performed during TSAM
development/production)
Table 8-9: Coverage of Environment Security Objectives from [JCSPP]
1516
8.4.6 PP Conformance concerning SFRs for the TOE
1517
The SFRs for the TOE from [JCSPP] Minimal Configuration, all regarding the
1518
Java Card platform level, are contained in [JCOP41V231ST] and also this ST,
1519
see section 5.2 hereinbefore. The additional SFRs for the TOE in this ST regard
1520
the TSAM application level and are not in contradiction to the ones from
1521
[JCSPP].
1522
Furthermore [JCSPP] defines the minimum strength of function level to be SoF-
1523
medium. Here this claim is exceeded by using SoF-high, therefore this ST is
1524
conformant to [JCSPP] concerning the minimum SoF-claim.
1525
8.4.7 PP Conformance concerning SARs
1526
[JCSPP] claims conformance to EAL4 augmented by AVA_VLA.3 and
1527
ADV_IMP.2. In this ST conformance to EAL4 augmented by AVA_VLA.4 and
1528
ADV_IMP.2 is claimed. As AVA_VLA.4 is hierarchical to AVA_VLA.3, this ST is
1529
conformant to [JCSPP] concerning the security assurance requirements.
1530
8.4.8 PP Conformance concerning SFRs for the IT Environment
1531
Environment SFRs from [JCSPP] Coverage in this ST
[JCSPP] section 5.1.3, “BCVG”
SFRs (for byte code verification)
Included in section 5.5 of this ST; will be
regarded during production of the composite
TSAM TOE
[JCSPP] section 5.1.9, “SCPG”
SFRs (for smart card platform, i.e.
operating system and chip)
Already regarded in terms of SFRs for
[JCOP41V231] during the corresponding
evaluation, not relevant for the IT environment
of the composite TSAM TOE
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 60
Environment SFRs from [JCSPP] Coverage in this ST
[JCSPP] section 5.1.10, “CMGRG”
SFRs (for card manager)
Already regarded in terms of SFRs for
[JCOP41V231] during the corresponding
evaluation, not relevant for the IT environment
of the composite TSAM TOE
Table 8-10: Coverage of IT Environment SFRs from [JCSPP]
1532
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 61
9 Appendix
1533
9.1 Abbreviations
1534
3/DES Triple Data Encryption Standard
1535
APDU Application Protocol Data Unit
1536
BCV Byte Code Verification
1537
BSN Batch Settlement Number
1538
DES Data Encryption Standard
1539
EEPROM Electrically Erasable Programmable Read Only Memory
1540
GP GlobalPlatform
1541
GPK GlobalPlatform Key
1542
IC Integrated Circuit
1543
JC JavaCard
1544
JCP JavaCard Platform
1545
LCS Life Cycle State
1546
MAC Message Authentication Code
1547
MID Merchant Identifier
1548
MK Management Key
1549
OSP Organizational Security Policy
1550
POS Point Of Sales
1551
PP Protection Profile
1552
RC Retry Counter
1553
ROM Read Only Memory
1554
SAR Security Assurance Requirement
1555
SCP Smart Card Platform
1556
SF Security Function
1557
SFP Security Function Policy
1558
SFR Security Functional Requirement
1559
SO Security Objective
1560
SOE Security Objective for the Environment
1561
ST Security Target
1562
TD Transaction Data
1563
TID Terminal Identifier
1564
TMD Terminal Management Data
1565
TOE Target of evaluation
1566
TSAM Terminal Security Access Module
1567
TSN Transaction Serial Number
1568
TSF TOE Security Functions
1569
TSP TOE Security Policy
1570
WK Working Key
1571
Security Target for BAROC/FISC TSAM 1.0 Version: 1.0.0 page 62
9.2 References
1572
[3/DES] Federal Information Processing Standard Publication, FIPS
1573
PUB 46-3 October 1999.
1574
[AIS20] Anwendungshinweise und Interpretationen zum Schema,
1575
AIS 20: Funktionalitätsklassen und
1576
Evaluationsmethodologie für deterministische
1577
Zufallszahlengeneratoren, Version 1, 02.12.1999,
1578
Bundesamt für Sicherheit in der Informationstechnik
1579
[ANSI X9.52] Triple Data Encryption Algorithm Modes of Operation
1580
[ANSI X9.9] Financial Institution Message Authentication
1581
[CC] Common Criteria for Information Technology Security
1582
Evaluation, August 2005, Version 2.3
1583
[CEM] Common Evaluation Methodology for Information
1584
Technology Security Evaluation, August 2005, Version 2.3
1585
[ISO7816-4] ISO/IEC 7816-4, Information technology - Identification
1586
cards - Integrated circuit(s) cards with contacts - Part 4:
1587
Interindustry commands for interchange
1588
[JCOP41V231] NXP P541G072V0P (JCOP 41 v2.3.1), Secure Smart Card
1589
Controller
1590
[JCOP41V231ST] SECURITY TARGET, NXP P541G072V0P (JCOP 41
1591
v2.3.1), Secure Smart Card Controller, version 2.13, date
1592
2007-06-01, IBM Deutschland Entwicklung GmbH
1593
[JCSPP] Java Card System Protection Profile Collection, Version:
1594
1.0b, August 2003. This Document contains 4 protection
1595
profile, whereas “Java Card System – Minimal
1596
Configuration Protection Profile” (registered at DCSSI under
1597
Registration number PP/0303) is relevant for this ST
1598
[PP0002] Smartcard IC Platform Protection Profile, Version 1.0, July
1599
2001 (registered at BSI under Registration number BSI-PP-
1600
0002)
1601
[ST0348] Security Target Lite, BSI-DSZ-CC-0348, Version 1.2,
1602
17.01.2006, Evaluation of the Philips P5CT072V0P,
1603
P5CC072V0P, P5CD072V0P and P5CD036V0P Secure
1604
Smart Card Controllers
1605