Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 1
on behalf of C-Roads
Protection Profile for a Roadside ITS Station Gateway
1
2
3
4
Roadside ITS Station Gateway PP
5
Version 1.0
6
Certification-ID: BSI-CC-PP-0122
7
8
9
Roadside ITS Station Gateway PP
2 Bundesanstalt für Straßenwesen (BASt)
on behalf of C-Roads
Table of content
10
1 PP Introduction ..............................................................................................................................6
11
1.1 Introduction.........................................................................................................................6
12
1.2 PP Reference .......................................................................................................................6
13
1.3 TOE Overview ....................................................................................................................6
14
1.3.1 Introduction...............................................................................................................6
15
1.3.2 TOE Type..................................................................................................................7
16
1.3.3 System Overview......................................................................................................7
17
1.3.4 Services of the Roadside-ITS-Station.......................................................................7
18
1.3.5 TOE Physical Scope..................................................................................................8
19
1.3.6 TOE Logical Scope...................................................................................................9
20
1.3.7 The Logical Interfaces of the TOE............................................................................9
21
1.4 Secure Element (not Part of the TOE)...............................................................................10
22
1.5 Life Cycle..........................................................................................................................11
23
2 Conformance Claims ...................................................................................................................13
24
2.1 CC Conformance Claims ..................................................................................................13
25
2.2 PP Conformance Claim.....................................................................................................13
26
2.3 Conformance Claim Rationale..........................................................................................13
27
2.4 Package Conformance Claim............................................................................................13
28
2.5 Conformance Statement ....................................................................................................13
29
3 Security Problem Definition........................................................................................................14
30
3.1 External Entities................................................................................................................14
31
3.2 Assets ................................................................................................................................15
32
3.3 Assumptions......................................................................................................................17
33
3.4 Threats...............................................................................................................................18
34
3.4.1 Threat Agents (Attackers).......................................................................................18
35
3.4.2 Threats ....................................................................................................................19
36
3.5 Organisational Security Policies (OSPs)...........................................................................19
37
4 Security Objectives ......................................................................................................................21
38
4.1 Security Objectives for the TOE .......................................................................................21
39
4.2 Security Objectives for the Operational Environment ......................................................23
40
4.3 Security Objectives Rationale ...........................................................................................24
41
4.3.1 Overview.................................................................................................................24
42
4.3.2 Countering the Threats............................................................................................24
43
4.3.3 Coverage of Organisational Security Policies.........................................................26
44
4.3.4 Coverage of Assumptions .......................................................................................27
45
5 Extended Component Definition ................................................................................................28
46
6 Security Requirements.................................................................................................................29
47
6.1 Overview...........................................................................................................................29
48
6.2 Class FAU: Security Audit ................................................................................................31
49
Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 3
on behalf of C-Roads
6.2.1 FAU_GEN.1 Audit data generation ........................................................................31
50
6.2.2 FAU_GEN.2 User identity association ...................................................................31
51
6.2.3 FAU_SAR.1 Audit review ......................................................................................31
52
6.2.4 FAU_STG.2 Protected audit data storage ...............................................................31
53
6.2.5 FAU_STG.5 Prevention of audit data loss..............................................................31
54
6.3 Class FCS: Cryptographic Support ...................................................................................31
55
6.3.1 FCS_COP.1/AES Cryptographic operation of AES-CCM......................................31
56
6.3.2 FCS_COP.1/Backend Cryptographic operation for backend communication ........32
57
6.3.3 FCS_COP.1/Hash Cryptographic operation for hash value generation ..................32
58
6.3.4 FCS_COP.1/SigVer Cryptographic operation for signature verification ................32
59
6.3.5 FCS_COP.1/SigVerFW Cryptographic operation for signature verification of
60
firmware updates 33
61
6.3.6 FCS_CKM.1/AES Cryptographic key generation of AES keys and nonces ..........33
62
6.3.7 FCS_CKM.1/Backend Cryptographic key generation for backend communication
63
33
64
6.3.8 FCS_CKM.5/Backend Cryptographic key derivation for backend communication
65
33
66
6.3.9 FCS_CKM.6 Timing and event of cryptographic key destruction .........................34
67
6.4 Class FDP: User Data Protection ......................................................................................35
68
6.4.1 FDP_ACC.1 Subset access control.........................................................................35
69
6.4.2 FDP_ACF.1 Security attribute-based access control ..............................................35
70
6.4.3 FDP_IFC.2 Complete information flow control.....................................................36
71
6.4.4 FDP_IFF.1 Simple security attributes.....................................................................36
72
6.4.5 FDP_RIP.1 Subset residual information protection ................................................37
73
6.5 Class FIA: Identification and Authentication....................................................................38
74
6.5.1 FIA_ATD.1 User attribute definition......................................................................38
75
6.5.2 FIA_UAU.2 User authentication before any action................................................38
76
6.5.3 FIA_UAU.5 Multiple authentication mechanisms .................................................38
77
6.5.4 FIA_UID.2 User identification before any action...................................................38
78
6.6 Class FMT: Security Management....................................................................................39
79
6.6.1 FMT_MSA.1 Management of security attributes...................................................39
80
6.6.2 FMT_SMF.1 Specification of management functions............................................39
81
6.6.3 FMT_SMR.1 Security roles....................................................................................39
82
6.7 Class FPT: Protection of the TSF......................................................................................40
83
6.7.1 FPT_FLS.1 Fail secure ...........................................................................................40
84
6.7.2 FPT_PHP.1 Passive detection of physical attack....................................................40
85
6.7.3 FPT_RPL.1 Replay detection .................................................................................40
86
6.7.4 FPT_STM.1 Reliable time stamps..........................................................................40
87
6.7.5 FPT_TDC.1 Inter-TSF basic TSF data consistency................................................40
88
Roadside ITS Station Gateway PP
4 Bundesanstalt für Straßenwesen (BASt)
on behalf of C-Roads
6.7.6 FPT_TST.1 TSF self-testing ...................................................................................41
89
6.8 Class FTP: Trusted Path/Channels ....................................................................................42
90
6.8.1 FTP_PRO.1/Backend Trusted channel protocol for the backend communication..42
91
6.8.2 FTP_PRO.1/PKI Trusted channel protocol for the communication with the PKI..42
92
6.8.3 FTP_PRO.2/Backend Trusted channel establishment for the backend
93
communication 43
94
6.8.4 FTP_PRO.3/Backend Trusted channel data protection for the backend
95
communication 43
96
6.8.5 FTP_PRO.3/PKI Trusted channel data protection for the communication with the
97
PKI 44
98
6.9 Security Assurance Requirements for the TOE.................................................................45
99
6.10 Security Requirements Rationale......................................................................................46
100
6.10.1 O.Crypt ...................................................................................................................48
101
6.10.2 O.ReceiveAuthenticatedData..................................................................................48
102
6.10.3 O.SendAuthenticatedData.......................................................................................49
103
6.10.4 O.SecureChannel ....................................................................................................49
104
6.10.5 O.Authentication.....................................................................................................49
105
6.10.6 O.Access .................................................................................................................49
106
6.10.7 O.SecureFirmwareUpdate.......................................................................................50
107
6.10.8 O.Protect .................................................................................................................50
108
6.10.9 O.Management........................................................................................................50
109
6.10.10 O.Log ......................................................................................................................50
110
6.10.11 Fulfilment of the Dependencies..............................................................................50
111
6.10.12 Security Assurance Requirements Rationale ..........................................................55
112
7 Appendix.......................................................................................................................................56
113
7.1 Glossary & Specific Terms................................................................................................56
114
7.2 References.........................................................................................................................60
115
116
Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 5
on behalf of C-Roads
List of Tables
Table 1: TOE external interfaces ...........................................................................................................10
117
Table 2: External entities .......................................................................................................................14
118
Table 3: Assets .......................................................................................................................................17
119
Table 4: Assumptions.............................................................................................................................17
120
Table 5: Threats .....................................................................................................................................19
121
Table 6: Organisational security policies...............................................................................................20
122
Table 7: Security objectives for the TOE...............................................................................................22
123
Table 8: Security objectives for the operational environment ...............................................................23
124
Table 9: Rationale for security objectives..............................................................................................24
125
Table 10: List of Security Functional Requirements (SFRs) .................................................................30
126
Table 11: Assurance requirements .........................................................................................................45
127
Table 12: Security requirements rationale .............................................................................................48
128
Table 13: SFR dependencies..................................................................................................................55
129
Table 14: Glossary & specific terms......................................................................................................59
130
131
List of Figures
Figure 1: TOE and its environment..........................................................................................................7
132
133
Roadside ITS Station Gateway PP
6 Bundesanstalt für Straßenwesen (BASt)
on behalf of C-Roads
1 PP Introduction
134
1.1 Introduction
135
This Protection Profile defines the Security Functional Requirements (SFRs) and the SecurityAssurance
136
Requirements (SARs) for a Roadside ITS Station Gateway.
137
The Roadside ITS Station (R-ITS-S) is an electronic device and part of an Intelligent Transport System
138
(ITS). It exchanges ITS/C-ITS messages with other ITS/C-ITS stations in the context of Infrastructure
139
to Vehicle (I2V) and Vehicle to Infrastructure (V2I) communication.
140
The data exchange includes events, warnings and information related to road traffic. Communication
141
from the Roadside ITS Station to Vehicle ITS Stations can be seen as a digital complement to physical
142
road signs and physical light signals.
143
Hint
144
C-ITS stands for Cooperative ITS, which is a subset of ITS. “C-ITS messages” are also referred to as
145
“ITS messages” in the respective standards. Since this Protection Profile has been developed in the
146
context of [SP] and [CP], where the term “C-ITS message” is used, the term “C-ITS message(s)” is used
147
throughout the document.
148
1.2 PP Reference
149
Title: Protection Profile for a Roadside ITS Station Gateway
Version: 1.0
Date 23.01.2024
Authors: Markus Wagner,
Maximilian Wahner,
Sandro Berndt-Tolzmann,
(TÜVIT),
(TÜVIT),
(BASt),
m.wagner@tuvit.de
m.wahner@tuvit.de
berndt@bast.de
Certification-ID: BSI-CC-PP-0122
Evaluation Assurance Level: EAL3
CC-Version: CC:2022 Revision 1
150
1.3 TOE Overview
151
1.3.1 Introduction
152
The Target of Evaluation (TOE) described in this Protection Profile is a Roadside ITS Station Gateway
153
(RGW) as a part of the corresponding Roadside ITS Station (R-ITS-S), in line with the respective
154
requirements of [SP]. The R-ITS-S is an electronic device, mounted, e.g., at light signals, overhead
155
gantries, or on trailers that warn approaching traffic that road works is carried out.
156
The TOE itself is the part of the R-ITS-S, which is able to transmit C-ITS messages based on input
157
coming from sensors connected to the R-ITS-S or from the Traffic Control Center (TCC) and also to
158
collect C-ITS messages sent by bypassing vehicles.
159
It should be noted that this Protection Profile does not aim to imply any concrete system architecture or
160
product design as long as the security requirements from this Protection Profile are fulfilled. Only in
161
cases where the implementation of the Security Functional Requirements will definitely require a certain
162
architecture, this architecture is described in this Protection Profile in a mandatory way.
163
Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 7
on behalf of C-Roads
1.3.2 TOE Type
164
The TOE is part of the R-ITS-S, controlling the basic functionalities and communication aspects as well
165
as the data aggregation.
166
This Protection Profile is a generalisation of the Road Works Warning Gateway Protection Profile under
167
Certification-ID BSI-CC-PP-0106.
168
1.3.3 System Overview
169
The following figure provides an overview of the TOE with its logical interfaces, its relation to the
170
R-ITS-S and its immediate environment.
171
172
Figure 1: TOE and its environment
173
The R-ITS-S provides the physical enclosure, in other words the R-ITS-S is the technical system in
174
which the TOE is integrated, as well as the Secure Element and an optional GNSS receiver.
175
The TOE is able to send and receive C-ITS messages to/from other C-ITS stations using ITS-G5. It may
176
receive C-ITS messages and/or content from a TCC in order to send C-ITS messages to other C-ITS
177
stations via ITS-G5.
178
The gateway utilises the services of a Secure Element as a cryptographic service provider and as a secure
179
storage for confidential assets.
180
1.3.4 Services of the Roadside-ITS-Station
181
The following paragraphs introduce the overall functionality of the TOE in a more detailed manner but
182
are not representing the covered logical scope of the TOE. The purpose of ITS systems in general is to
183
improve road traffic in various ways, e.g. in terms of increased traffic safety as well as improved traffic
184
flow and efficiency with the following services.
185
1.3.4.1 Local Traffic Information
186
C-ITS Infrastructure-to-Vehicle services are used to inform road users within the communication range
187
of the TOE in a timely manner about the situation on the road, i.e. vehicles in the vicinity of the TOE.
188
These services can be triggered by the TCC/C-ITS-S or by the R-ITS-S. The required information is
189
time sensitive. To realise this objective, the R-ITS-S broadcasts appropriate information towards the
190
vehicles approaching the R-ITS-S location, using C-ITS messages like DENM, IVIM, SPATEM,
191
MAPEM, SSEM.
192
Roadside ITS Station Gateway PP
8 Bundesanstalt für Straßenwesen (BASt)
on behalf of C-Roads
Hint
193
When the R-ITS-S is used in combination with a road works trailer, variable message signs or traffic
194
lights, the services of the RGW will be a service on top of the basic functionality of the physical
195
infrastructure. This means that even in the case when the RGW is temporarily not functioning due to
196
breakdown or maintenance, the physical infrastructure element (road works trailer, variable message
197
signs, traffic light) must remain available.
198
1.3.4.2 Local Traffic Surveillance and Other V2I Services
199
This service receives C-ITS messages being broadcasted by vehicles (e.g. DENM and CAM), potentially
200
aggregates the received data and makes the information available for improved traffic management
201
services. In addition to the potential aggregation on the R-ITS-S, additional processing may be done
202
partly or completely in the TCC and/or may also be used by other services of the road operators and
203
may be re-used by other service providers.
204
1.3.5 TOE Physical Scope
205
The TOE comprises the hardware and software that is relevant for the security functionality of the R-
206
ITS-S as defined in this PP. The Secure Element that is utilised by the TOE is considered being not part
207
of the TOE1
.
208
As mentioned in Section 1.3.1, this PP does not want to imply any concrete physical architecture for the
209
components that make up the R-ITS-S. Specifically, the TOE described in this PP only includes an
210
independent computing system (labelled as “controller” in Figure 1) and a real-time clock, along with
211
the corresponding software parts for monitoring and controlling the functionalities described in Section
212
1.3.4.
213
Furthermore, additional modules that support the TOE without being part of it:
214
• (LAN/WAN) Communication segment(s), at least one mandatory:
215
o Network interface (e.g. Ethernet)
216
o Mobile cellular communication (e.g. GSM, UMTS, LTE, 5G)
217
• (Short-range) Communication segment, mandatory
218
o ETSI ITS-G5 short-range communication based on [ETSI EN 302 663]
219
• Positioning technology, optional
220
o GNSS receiver
221
It should be noted that this overview of possible physical implementations does not claim to be a
222
complete overview of all possibilities. The Common Criteria (CC) allow combining multiple TOEs into
223
one device and have the flexibility to identify functionality that is not relevant for the security
224
functionality of the TOE or the environment. However, when focusing on a system of multiple TOEs, it
225
is not possible to move security features from the scope of one TOE to another.
226
Hint
227
The actual antennas for the communication segments listed above are not part of the TOE.
228
229
Hint
230
In the product evaluation process, also the guidance parts belong to the physical scope of the TOE.
231
232
1
Please note that the Secure Element is physically integrated into the R-ITS-S, even though it is not part of the
TOE.
Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 9
on behalf of C-Roads
1.3.6 TOE Logical Scope
233
The logical boundary of the gateway can be defined by its security features:
234
• Sufficiently encrypted communication to the RA, the TCC and the PKI.
235
• Trusted communication establishment with the PKI (according to [CP]), the R-ITS-S
236
Administrator (RA), the TCC.
237
• Replay detection of messages sent from the TCC and/or the RA.
238
• Detection, definition, generation, and storage of security-relevant events for logging and their
239
mapping to corresponding entities.
240
• Information flow policies and rules.
241
• Authentication and identification mechanisms including the implementation of access rules and
242
policies.
243
• Management functionalities including the management of security attributes for the different
244
entities.
245
• Assurance of authenticity of information content received from or send to mandatory TOE
246
Security Functional Interfaces (TSFIs).
247
• Assurance of secure state in case of error events (incl. initial values).
248
• Secure firmware update.
249
• Self-test possibilities including verifying the authenticity of the Secure Element on start-up.
250
• Secure data deletion.
251
• Reliable time-stamp generation.
252
The services of the Secure Element are not part of this Protection Profile. The necessary service will be
253
outlined in Section 1.4 in more detail.
254
Application Note 1
255
The ST author shall define the protocol to be used for the connections to the RA and the TCC (i.e. TLS
256
[RFC8446], IPsec [RFC4301] or SSH [RFC4254]) and specify it in SFR FTP_PRO.1/Backend
257
(including all dependencies).
258
The protocol chosen by the ST author should have a comparable level of security as the protocols
259
mentioned in the example above.
260
Should different protocols be used for the connection to the TCC and the connection to the RA, it is
261
recommended to iterate the SFR FTP_PRO.1 (including all dependencies) to model the additional
262
protocol.
263
The ST author shall also consider Application Note 27 and OSP.StrongCrypto (see Table 6).
264
265
Application Note 2
266
When requesting new certificates required for the C-ITS communication of the TOE, the message
267
exchange (Authorisation Request/Response and Enrolment Request/Response) with the PKI
268
(Authorisation Authority (AA) and Enrolment Authority (EA)) shall be protected by the cryptographic
269
algorithms AES-CCM and ECIES as described in [ETSI TS 102 941].
270
1.3.7 The Logical Interfaces of the TOE
271
The TOE offers its functionality as outlined before via a set of external interfaces as indicated in Figure
272
1. The following table provides an overview of the external interfaces of the TOE and provides
273
additional information:
274
Interface Name Description
IF_GW_PKI This interface is used for the connection to the PKI for certificate-related
operations.
Roadside ITS Station Gateway PP
10 Bundesanstalt für Straßenwesen (BASt)
on behalf of C-Roads
Interface Name Description
IF_GW_TCC This interface is used for the connection to the TCC to receive or transmit
data to it.
IF_GW_SR This interface is responsible for every short-range communication from and
to other ITS stations, usually in vehicles. This includes the reception of C-
ITS messages such as DENMs or CAMs from the V-ITS-S, and the
potential warning of all V-ITS-S in the direct surrounding if necessary.
IF_GW_ Admin This interface is used for R-ITS-S Administrators only, aiming on allowed
administration tasks. This can be realized as a local and/or remote interface.
IF_GW_GNSS
(optional)
This interface is used for the connection to optional GNSS receivers, and
the provision/estimation of the current position.
IF_GW_SE This interface connects the TOE with the Secure Element.
IF_GW_Modules
(optional)
This interface is used to communicate with other optional local functional
modules linked to the RGW/R-ITS-S. Such modules could be a traffic light
controller, or a roadworks trailer controller, or a gateway that serves the
connection to external equipment (analog-to-digital conversion of sensor
inputs, etc.)
Table 1: TOE external interfaces
275
Application Note 3
276
Within this PP, it is assumed that IF_GW_Modules is wired. Should any Security Target (ST) author
277
prefer wireless connections, this shall be modelled accordingly to ensure the integrity of the received
278
data, e.g. by a corresponding authenticated encryption scheme.
279
280
Application Note 4
281
Table 1 lists mandatory and optional interfaces. Additional interfaces to the TOE are possible and can
282
be defined and modelled by the ST author. For each additional interface, an adequate security level shall
283
be ensured, e.g. by fulfilling FTP_ITC.1 or FTP_PRO.1.
284
1.4 Secure Element (not Part of the TOE)
285
The RGW is linked to a Secure Element that acts as a provider of the required cryptographic operations
286
used in the aforementioned functions. It provides strong cryptographic functionality such as random
287
number generation and secure storage of secrets, and supports the authentication of external entities.
288
The Secure Element is a different sub-module of the R-ITS-S for which separate PP exist (e.g. [SE-PP],
289
[CSP-PP] or comparable); it is therefore not part of the TOE as described in this PP. Nevertheless, it is
290
physically embedded into the R-ITS-S and protected by the same level of physical protection.
291
Following from the SFRs and the defined application scenario the Secure Element shall be used for
292
• generation of random numbers,
293
• management of relevant (cryptographic) keys according to [CP]:
294
o storage of private keys,
295
o generation of ECC asymmetric key pairs for ECDSA,
296
o generation of ephemeral ECC asymmetric key pairs for ECIES encryption, and
297
o secure deletion of keys,
298
• digital signature generation (ECDSA) for data and entity authentication, and
299
• ECIES encryption of secret data encryption keys.
300
301
Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 11
on behalf of C-Roads
Application Note 5
302
In the context of C-ITS messages, a SE needs to be present according to [CP]. If required in the context
303
of backend communication with RA and the TCC, e.g. for TLS, it is allowed to include one or more of
304
the functionalities defined above within the TSF. If done so, the Security Target (ST) author is advised
305
to also model the corresponding SFRs within his/her ST to implement a secure realisation of these
306
functionalities.
307
308
Application Note 6
309
The Secure Element shall be protected against unauthorised removal, replacement, and modification.
310
311
Hint
312
Since it is expected that on some occasions a large number of messages from V-ITS-S arrive at the RGW,
313
it may be necessary that the verification of the corresponding digital signatures (and certificates) is done
314
outside the Secure Element. This operation is less critical as it does not need access to any private key.
315
1.5 Life Cycle
316
The life cycle of the TOE consists of the following consecutive phases:
317
1. Design/Development
318
The development of the TOE.
319
2. Manufacturing/Assembly
320
The production like hardware assembly or software installation. This comprises the initial ITS-
321
S configuration during manufacturing, including the installation of the initial Trust List Manager
322
(TLM) certificate.
323
3. Registration
324
Registration of the R-ITS-S at a PKI.
325
4. Enrolment
326
Initial transfer of certificates from the PKI to the TOE.
327
5. Normal Operation and Maintenance
328
Operational phase of the TOE. All security functions shall be working as specified.
329
6. End of Life
330
In case the TOE comes to an irreparable, defective state or shall be taken out of order for other
331
reasons, it shall be ensured that the key and certificate material that is contained within the TOE
332
is destroyed in a secure manner. This also includes potentially necessary actions to / with the
333
Secure Element as described in the corresponding guidance documentation (e.g. kill command).
334
335
The life cycle is usually a sequential process, however, a re-enrolment at a different PKI is possible. In
336
this case, normal operation ends and can only be resumed after successful enrolment and authorisation.
337
338
Application Note 7
339
If the return of a TOE to the certified state at the process level should be possible (e.g. repair processes),
340
the ST author shall also model this by means of appropriate specifications.
341
342
Hint
343
Roadside ITS Station Gateway PP
12 Bundesanstalt für Straßenwesen (BASt)
on behalf of C-Roads
It is recommended to embed the use of the TOE in an Information Security Management System (ISMS)
344
according to [ISO27001] or similar.
345
Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 13
on behalf of C-Roads
2 Conformance Claims
346
2.1 CC Conformance Claims
347
This Protection Profile has been developed using Common Criteria version CC:2022 Revision 1 [CC],
348
and is
349
• Common Criteria [CC] Part 2 conformant, and
350
• Common Criteria [CC] Part 3 conformant.
351
2.2 PP Conformance Claim
352
This PP does not claim conformance to any other PP.
353
2.3 Conformance Claim Rationale
354
Since this PP does not claim conformance to any PP, this section is not applicable.
355
2.4 Package Conformance Claim
356
This PP is conforming claims assurance package EAL3 as defined in [CC] Part 5.
357
Hint
358
This PP acknowledges that the various components of the TOE may be developed by different
359
companies and that a large amount of the work of the developer of the RGW refers to the integration of
360
those components. However, as the Evaluation Assurance Level (EAL) in this PP has been chosen to be
361
EAL3, this should not introduce intractable problems during the evaluation process.
362
2.5 Conformance Statement
363
This PP requires strict conformance of any PP/ST to this PP.
364
Roadside ITS Station Gateway PP
14 Bundesanstalt für Straßenwesen (BASt)
on behalf of C-Roads
3 Security Problem Definition
365
The Security Problem Definition (SPD) is the part of a PP which describes
366
• the external entities that are envisioned to interact with the TOE,
367
• the assets which the TOE shall protect,
368
• the assumptions on security-relevant properties and behavior of the TOE’s environment,
369
• threats against the assets which shall be averted by the TOE together with its environment, and
370
• operational security policies which describe overall security requirements defined by the
371
organisation in charge of the overall system including the TOE.
372
3.1 External Entities
373
The following external entities are allowed to interact with the TOE:
374
Role Description
R-ITS-S Administrator
(RA)
The R-ITS-S Administrator is responsible for initial setup of the R-ITS-S
including the RGW, installing key and certificate material, firmware
updates, and for the continued operation including the potential data
connection to the TCC.
Traffic Control Center
(TCC)
The Traffic Control Center sends and receives traffic data to / from the
RGW, typically via C-ITS-S. In addition, the TCC is also able to configure
non security-related settings via functional parametrisation.
Vehicles (V-ITS-S) Vehicles sends and receives traffic related data to / from the RGW.
Road Maintenance
Personnel
The Road Maintenance Personnel maintains the road infrastructure and is
responsible for visual inspection of road infrastructure elements including
R-ITS-S. Such personnel is not responsible for maintaining the R-ITS-S and
therefore not accessing maintenance interfaces of the RGW.
PKI The Public Key Infrastructure (PKI) comprises different services, including
issuing certificates, CTLs and CRLs to the RGW as a prerequisite for a
trusted exchange of C-ITS messages between the RGW and V-ITS-S.
EA and AA are part of the PKI.
Table 2: External entities
375
Hint
376
In terms of [CP] and [SP], the RA can be seen as an instantiation of an “operator” and/or
377
“manufacturer”, depending on the actual organisational and contractual setup. Similar considerations
378
apply to the TCC, which might or might not be identical to the “operator” in [CP] and [SP].
379
Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 15
on behalf of C-Roads
3.2 Assets
380
The following table lists the assets that need to be protected by the TOE.
381
Assets Description Protection
Requirements
Comment
In(coming)/
Out(going)
Source/
Destination
Input from external
controller
In External
Controller
- Optional, only for TOE
with a locally
connected external
controller, such as a
traffic light controller
or a trailer controller
that offers manual
switching of the trailer
sign board. Correctness
of data has to be
assumed.
Status information
from external
equipment (e.g.
external sensors or
status of a variable
message sign)
In & Out Various external
equipment
- Optional, only if
gateway to equipment
is used. Correctness of
incoming data has to be
assumed.
Outgoing status
information is out of
evaluation scope.
C-ITS message
reception
In Other ITS-S to
TOE
Integrity,
Authenticity
TOE verifies signature.
C-ITS message
transmission
Out TOE to other
ITS-S
Integrity,
Authenticity
TOE creates C-ITS
messages and utilises
SE to sign them.
In case of message
forwarding, the verified
message is re-
transmitted without
creating a new
signature.
Payload of C-ITS
message
Out TOE to TCC Integrity,
Authenticity
This applies if the TOE
forwards parts of a C-
ITS message to TCC
without the original
signature. The signature
of the C-ITS message
has been verified by the
TOE upon reception.
Payload does not need
to be signed, if TOE
communicates to TCC
via a trusted channel.
Information from In TCC to TOE Integrity, Correctness of
incoming data has to be
Roadside ITS Station Gateway PP
16 Bundesanstalt für Straßenwesen (BASt)
on behalf of C-Roads
Assets Description Protection
Requirements
Comment
In(coming)/
Out(going)
Source/
Destination
TCC Authenticity assumed. Out of
evaluation scope.
Log data Out TOE to RA Integrity TOE generates security
relevant entries for log
data.
RA data In & Out RA to TOE,
TOE to RA
Integrity,
Authenticity
Incoming: admin data
for RA, e.g.
configuration.
Outgoing: admin data
for RA, e.g.
acknowledgements,
configuration, etc.
Firmware update In RA to TOE Integrity,
Authenticity
TOE verifies integrity
and authenticity.
Request of
certificates
In & Out TOE requests,
PKI responds
Integrity,
Authenticity,
and
Confidentiality.
TOE requests a new
certificate from the AA,
which is required to
sign C-ITS messages.
TOE requests a new
certificate from the EA,
which is required to
stay enrolled in the PKI.
Update of Trust
Elements
In PKI provides
information
Integrity,
Authenticity
TOE receives updates
of the CTLs and CRLs
provided by the PKI.
TOE receives updates
of certificates provided
by the PKI (i.e.
certificates of TLM,
Root CA, EA and AA).
Private
cryptographic keys
Ephemeral or long-term
cryptographic material used by
the TOE for cryptographic
operations.
Integrity,
Authenticity,
and
Confidentiality.
According to the [CP],
all private keys used for
the communication in
the C-ITS context (i.e.
for signing of C-ITS
messages) have to be
stored in the Secure
Element.
Private keys used for
communication with
backend systems (i.e.
RA or TCC) must be
adequately secured.
Public
cryptographic keys
Ephemeral or long-term
cryptographic material used by
the TOE for cryptographic
Integrity,
Authenticity
All public keys have to
be adequately secured.
Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 17
on behalf of C-Roads
Assets Description Protection
Requirements
Comment
In(coming)/
Out(going)
Source/
Destination
operations.
Table 3: Assets
382
Hint
383
The integrity and authenticity of the C-ITS messages received via IF_GW_SR is ensured as described
384
in the respective message standards, relying on a PKI and the use of certificates according to [ETSI TS
385
103 097]. Additionally, every communication to the TCC or RAs has to be protected by an encrypted
386
and authenticated communication channel, even if information is just forwarded by the TOE.
387
388
Application Note 8
389
If data aggregation of the defined asset ”Payload of C-ITS messages” is provided by the TOE, the ST
390
author shall include the aggregated data as an additional asset and protect it accordingly against further
391
manipulation (see T.LocalDataManipulation and T.RemoteDataManipulation) within the TOE using the
392
following SFRs or appropriate:
393
• FDP_SDI.2 – Stored data integrity monitoring and action (to protect the stored aggregated and raw
394
data from manipulation)
395
• FCO_NRO.2 – Enforced proof of origin (to prevent data injection from unauthorised entities and
396
enable the evidence of origin of information for further entities)
397
3.3 Assumptions
398
In the following assumptions about the intended operational environment of the TOE are stated.
399
Assumption Description
A.SecureSetup It is assumed that appropriate security measures are taken during the
setup of the TOE to guarantee for the confidentiality, authenticity, and
integrity of the initial cryptographic data.
A.TrustedAdministrator It is assumed that the administrator of the TOE (R-ITS-S Administrator)
is trustworthy, non-hostile and well-trained.
A.PhysicalProtection It is assumed that the TOE is physically protected, or at least that
manipulations can be identified within a manageable timespan.
During the non-monitored phases, unauthorised physical access to the
TOE cannot be completely avoided. Nevertheless, it is assumed that a
theft of the TOE or an intervention that directly influences its telemetry
is recognisable either on-site or by remote monitoring. In addition, it is
assumed that a visual examination by authorised personnel, which have
to be included in the corresponding procedures, can securely ensure an
identification of manipulations within a manageable timespan.
A.CorrectLocation It is assumed that the TOE is able to determine its correct location within
a defined error bound.
A.Information It is assumed that the information that the TOE receives from other
devices and sensors (via IF_GW_Modules) are correct and protected
against manipulation.
Table 4: Assumptions
400
Application Note 9
401
There are various options for mounting the R-ITS-S (including the TOE), e.g.:
402
Roadside ITS Station Gateway PP
18 Bundesanstalt für Straßenwesen (BASt)
on behalf of C-Roads
• Option 1: The R-ITS-S is firmly mounted and not easily accessible.
403
• Option 2: The R-ITS-S is mounted on a movable platform (e.g. road works trailer). It may also be
404
left unobserved for a certain time (e.g. overnight during long-time road works) and hence the
405
environment of the TOE cannot be assumed to provide a continuous and comprehensive level of
406
physical protection.
407
The guidance documentation shall consider how the R-ITS-S (including the TOE) is mounted.
408
Regardless of how the R-ITS-S (including the TOE) is mounted, the assumption A.PhysicalProtection
409
applies.
410
411
Application Note 10
412
There are various options for the determination of the correct location for the TOE, e.g.:
413
• Option 1: The position can be determined externally with a suitable GNSS equipment and
414
configured in the TOE via the maintenance interface. This applies only to fixed installation
415
locations.
416
• Option 2: The position is determined by a GNSS receiver. This applies to fixed and mobile
417
installations.
418
The guidance documentation shall consider the option for the determination of the correct location.
419
Regardless of the method for determination of the location, the assumption A.CorrectLocation applies.
420
3.4 Threats
421
3.4.1 Threat Agents (Attackers)
422
Threat agents can be classified according to various characteristics.
423
Attack paths can be:
424
• The TOE is exposed to local attacks. Local attacks are directly driven against the device of the
425
TOE, i.e. they assume physical access to the TOE.
426
• The TOE may be accessed remotely via one of its network interfaces (mobile cellular networks
427
and other wireless networks).
428
A threat agent can be classified after the target. An attack can be targeted at the TOE (i.e. it can be the
429
target to read out confidential information) or the TOE can be misused in order to attack one of the
430
parties that the TOE is communicating with (specifically the TCC may be of interest for an attacker).
431
Attackers can be, i.e.:
432
• Individuals or organisations outside of the listed external entities (see Section 3.1). They may
433
perform attacks via the Internet, mobile networks, or ITS-G5 network.
434
Attackers can also be characterised by their motivation:
435
• Gaining reputation. By publishing the performed attacks, the person is respected as an expert,
436
e.g. for security within the ITS/C-ITS context.
437
• Gaining traffic priority.
438
• Financial reasons. An attacker could manipulate the functionality for ransom.
439
• Vandalism.
440
• Industrial espionage.
441
• Cyber terrorism and cyber warfare.
442
In the motivation of the attacker lays the main limitation for the attack potential that is considered in
443
this Protection Profile. As outlined in Section 6.10.12.1 the analysis of all assets that are handled by the
444
TOE showed that the value of those assets is limited. Based on the consideration of the limited value of
445
the assets, the motivation of an attacker to attack such assets is limited. Concretely, it can be assumed
446
that an attacker only possesses a basic attack potential.
447
Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 19
on behalf of C-Roads
3.4.2 Threats
448
Threat Description
T.Extraction An attacker tries to extract private key material from the TOE.
The attack might be performed by the use of the external interfaces of
the TOE (i.e. by observing the data that the TOE sends/receives).
As an example, the attack could aim at impersonating the TOE and to
send false traffic status data to the TCC or false road works warnings
to V-ITS-S afterwards.
T.LocalMalfunction An attacker tries to induce faulty behaviour of the TOE by applying
environmental or physical stress, by injecting malformed messages to
local interfaces or by manipulating internal connections of the TOE.
T.LocalDataManipulation An attacker tries to modify the configuration of the TOE or inject false
traffic or status data of his own choice by accessing local interfaces.
The injected data would then be processed by the TOE.
T.SoftwareManipulation An attacker tries to install hostile software or firmware updates on the
TOE. The attacker can try to achieve this either by directly accessing
local interfaces of the TOE or by accessing remote interfaces.
T.RemoteDataManipulation An attacker tries to modify the configuration of the TOE or inject false
traffic data by impersonating a V-ITS-S, a TCC, the RA or the PKI.
(This includes replayed out-dated messages.)
Data could also be injected after accessing the remote maintenance
interface.
T.RemoteMalfunction An attacker tries to induce faulty behaviour of the TOE by sending
malformed messages to the TOE.
T.Interception An attacker tries to intercept traffic data (incl. content of C-ITS
messages), road works data, status data or configuration data sent
between the TOE and the TCC/RA/PKI.
Table 5: Threats
449
Hint
450
Faulty behaviour as stated in T.LocalMalfunction and T.RemoteMalfunction comprises various types,
451
e.g. misinterpretation of certificate lists, start-up errors, connection problems etc. As a consequence,
452
these threats can be directed against different assets.
453
3.5 Organisational Security Policies (OSPs)
454
Organisational Security Policies (OSPs) are means to require functionality from a system that is
455
considered in this Protection Profile even though such functionality is not directly needed to mitigate an
456
attack against the system.
457
The following OSPs shall be implemented by the devices in this system.
458
Roadside ITS Station Gateway PP
20 Bundesanstalt für Straßenwesen (BASt)
on behalf of C-Roads
OSP Description
OSP.SE The TOE shall use the services of a certified Secure Element for2
:
• generation of random numbers,
• management of relevant (cryptographic) keys according to [CP]:
o storage of private keys,
o generation of ECC asymmetric key pairs for ECDSA,
o generation of ephemeral ECC asymmetric key pairs for
ECIES encryption, and
o secure deletion of keys;
• digital signature generation (ECDSA) for data and entity
authentication, and
• ECIES encryption of secret data encryption keys.
The Secure Element shall be certified according to Protection Profiles such as
[SE-PP] or comparable and shall be used only in accordance with its
corresponding guidance documentation and certification report.
OSP.StrongCrypto All cryptographic algorithms used by the security functionality of the TOE
shall provide a cryptographic strength of at least 120 bit.3
OSP.Log The TOE shall maintain a log of relevant events in order to allow an authorised
RA to analyse the status of the TOE.
The TOE may overwrite the oldest log events in case that the audit trail gets
full.
Table 6: Organisational security policies
459
Application Note 11
460
If a Random Number Generation (RNG) functionality is provided by the TOE itself, the ST author shall
461
model it appropriately using the SFR FCS_RNG.1 or FCS_RBG.1.
462
463
Application Note 12
464
The ST author shall consider that the evaluation body has to examine the certification report of the used
465
Secure Element for an appropriate application to the TOE (e.g. in terms of used data formats,
466
implemented interactions as well as storage and disposal of the Secure Element).
467
2
The defined security functionalities may be included within the TOE and thereby excluded from the Secure
Element within the specific TOE. If so, corresponding SFRs have to be modeled by the ST author. Hence, the
PP author highly recommend to realise the mentioned services within a Secure Element.
3
During certification of a specific R-ITS-S, the certification body in charge may impose additional requirements
concerning the choice and minimum strength of cryptographic functions.
Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 21
on behalf of C-Roads
4 Security Objectives
468
In this chapter, the security objectives for the RGW and its environment are described.
469
4.1 Security Objectives for the TOE
470
Objective Description
O.Crypt The TOE shall provide cryptographic functionality as follows:
• authentication, integrity and confidentiality protection
of the communication and data to external entities us-
ing IF_GW_Admin, IF_GW_PKI, or IF_GW_TCC,
• replay detection for communications with the external
entities TCC and RA, and
• authentication and integrity protection by signature
verification of messages sent from V-ITS-S using
IF_GW_SR.
O.ReceiveAuthenticatedData The TOE shall only accept and further process data received
from V-ITS-S, RA, TCC, and PKI if the corresponding
messages comply to the defined message formats and if its
authenticity and integrity can be verified.
O.SendAuthenticatedData The TOE shall only send data to V-ITS-S, RA, TCC and PKI
if the corresponding messages comply with the defined
message formats and if authenticity and integrity are ensured.
O.SecureChannel For communication with the TCC and the RA, the TOE shall
establish a mutually authenticated and confidential channel.
For communication with the PKI, the TOE shall establish an
authenticated message exchange (Authorisation
Request/Response and Enrolment Request/Response)
according to [ETSI TS 102 941].
O.Protect The TOE shall implement functionality to protect its security
functions against malfunctions and tampering. Specifically,
the TOE shall
• overwrite relevant information that is no longer
needed to ensure that it is no longer available,
• implement and conduct a self-test on a regular basis,
• make any physical manipulation within the scope of
the intended environment detectable for Road
Maintenance Personnel,
• ensure that the TOE falls into a secure state in case of
a security-relevant malfunction.
O.Authentication The TOE shall provide authentication mechanisms for the
roles RA, TCC, V-ITS-S, and PKI which are defined in Table
2.
O.Access The TOE shall provide access control mechanisms for its
functionalities and stored data.
O.SecureFirmwareUpdate The TOE shall implement functionality for a secure firmware
update. The TOE shall accept firmware updates only if their
authenticity and integrity can be verified.
O.Management The TOE shall provide the following management of the
security functionality to authorised RA only:
Roadside ITS Station Gateway PP
22 Bundesanstalt für Straßenwesen (BASt)
on behalf of C-Roads
Objective Description
• start firmware update, and
• configuration change.
O.Log The TOE shall maintain a log of relevant security events in
order to allow an authorised RA to analyse the status of the
TOE.
The TOE may overwrite the oldest log events in case that the
audit trail gets full.
Table 7: Security objectives for the TOE
471
Application Note 13
472
Concerning O.Access, the ST author shall only provide access mechanisms for those roles which need
473
to have access to TOE configuration items, i.e. the RA. For all other users and entities, the ST author
474
shall prevent any kind of access.
475
Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 23
on behalf of C-Roads
4.2 Security Objectives for the Operational Environment
476
Objective for environment Description
OE.SE The operational environment shall provide the services of a certified
Secure Element for2
:
• generation of random numbers,
• management of relevant (cryptographic) keys according to
[CP]:
o storage of private keys,
o generation of ECC asymmetric key pairs for ECDSA,
o generation of ephemeral ECC asymmetric key pairs for
ECIES encryption, and
o secure deletion of keys,
• digital signature generation (ECDSA) for data and entity
authentication, and
• ECIES encryption of secret data encryption keys.
The Secure Element shall be certified according to Protection Profiles
like [SE-PP] or comparable and shall be used in accordance with its
relevant guidance documentation.
OE.SecureSetup It shall be ensured that appropriate security measures are taken during
the setup of the TOE to guarantee for the confidentiality, authenticity,
and integrity of the initial cryptographic data.
OE.TrustedAdministrator It shall be ensured that the administrator of the TOE is trustworthy, non-
hostile and well-trained.
OE.PhysicalProtection It shall be ensured that the TOE is physically protected, or at least that
manipulations can be identified within a manageable timespan.
During the non-monitored phases, unauthorised physical access to the
TOE cannot be completely avoided. Nevertheless, it shall be ensured
that a theft of the TOE or an intervention that directly influences its
telemetry is recognisable either on-site or by remote monitoring. In
addition, it shall be ensured that a visual examination by authorised
personnel, which have to be included in the corresponding procedures,
can securely ensure an identification of manipulations within a
manageable timespan.
OE.CorrectLocation It shall be ensured that the TOE is able to determine its correct location
within a defined error bound.
OE.Information It shall be ensured that the information that the TOE receives from other
devices and sensors (via IF_GW_Modules) are correct and protected
against manipulation.
Table 8: Security objectives for the operational environment
477
478
Roadside ITS Station Gateway PP
24 Bundesanstalt für Straßenwesen (BASt)
on behalf of C-Roads
4.3 Security Objectives Rationale
479
4.3.1 Overview
480
Security Objectives for
the TOE
the Operational
Environment
O.Crypt
O.ReceiveAuthenticatedData
O.SendAuthenticatedData
O.SecureChannel
O.Protect
O.Authentication
O.Access
O.SecureFirmwareUpdate
O.Mananagement
O.Log
OE.SE
OE.SecureSetup
OE.TrustedAdinistrator
OE.PhysicalProtection
OE.CorrectLocation
OE.Information
T.Extraction X X X X X X
T.LocalMalfunction X X X X
T.LocalDataManipulation X X X X X X X X X
T.SoftwareManipulation X X X X X X
T.RemoteDataManipulation X X X X X X X X
T.RemoteMalfunction X X X X X X X
T.Interception X X X X X X
OSP.SE X X X X
OSP.StrongCrypto X
OSP.Log X X X X X
A.SecureSetup X
A.TrustedAdministrator X
A.PhysicalProtection X
A.CorrectLocation X
A.Information X
Table 9: Rationale for security objectives
481
482
4.3.2 Countering the Threats
483
The following sections provide more detailed information on how the threats are countered by the
484
security objectives for the TOE and its operational environment.
485
4.3.2.1 General Objectives
486
The security objectives O.Protect counter each threat using self-tests on a regular basis, physical
487
Security
Problem Definition
Security
Objective
Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 25
on behalf of C-Roads
protection against tampering etc., whereby O.Management is needed as it defines the requirements
488
around the management of the security functions and to document whether the TOE works as specified
489
using adequate logging information. Additionally, O.Access ensures that only authorised roles are able
490
to access the TOE parts and also OE.TrustedAdministrator contributes to this aspect as it provides the
491
requirements on the availability of a trustworthy administrator. O.Authentication is needed to ensure
492
authentication for the different roles.
493
O.SecureChannel secures the usage of appropriate communication channels, secured by the
494
corresponding cryptographic algorithms based on O.Crypt (cryptographic operations).
495
O.ReceiveAuthenticatedData and O.SendAuthenticatedData allow import and export of required
496
data, while its integrity and authenticity are ensured by digital signatures.
497
Those general objectives that have been argued in the previous paragraphs will not be addressed in detail
498
in the following paragraphs.
499
500
4.3.2.2 T.Extraction
501
The extraction of secret data is covered by the security objectives O.Crypt, O.SecureChannel,
502
O.Protect, O.Authentication and O.Access.
503
Hereby, O.SecureChannel secures the usage of appropriate communication channels and O.Crypt
504
enforces the usage of reliable signature generation, cryptographic secured communication channels and
505
side-channel resistant cryptographic algorithms. O.Protect protects the TOE’s security functions against
506
malfunctions and tampering, and O.Authentication and O.Access undertake the authentication and
507
access procedures in a way that only the appropriate personnel may access the TOE itself and the user-
508
corresponding functionalities.
509
510
4.3.2.3 T.LocalMalfunction
511
The induction of faulty behaviour of the TOE by injecting malformed messages or manipulations is
512
covered by O.Protect and O.Management.
513
Hereby, O.Protect explicitly implements the necessary functions against malfunctions and tampering
514
by overwriting redundant data, provide self-test functionalities and prevent emitting any information
515
that may be used to obtain secret data. O.Management is hereby also necessary to restrict firmware
516
updates and configuration changes.
517
In addition, the OE.PhysicalProtection contributes to counter this threat by ensuring that manipulations
518
can be identified within a manageable timespan.
519
520
4.3.2.4 T.LocalDataManipulation
521
The injection of false traffic or network/traffic information is countered by O.Crypt, O.Protect,
522
O.ReceiveAuthenticatedData, O.SendAuthenticatedData, O.Authentication, O.Access, and
523
O.Management.
524
O.Crypt enforces the usage of reliable signature verification, cryptographic secured communication
525
channels and side-channel resistant cryptographic algorithms. O.Protect implements the necessary
526
functions against malfunctions and tampering by overwriting redundant data, providing self-test
527
functionalities and prevention against emitting any information that may be used to obtain secret data.
528
O.ReceiveAuthenticatedData and O.SendAuthenticatedData allow import and export of required
529
data, while its integrity and authenticity are ensured by digital signatures. O.Access enables the
530
necessary access control, which provides the rights to the corresponding user whereby
531
O.Authentication provides authentication mechanisms. O.Management also supports the
532
countermeasures against this threat by restricting firmware updates and configuration changes.
533
In addition, the OE.PhysicalProtection contributes to counter this threat by ensuring that manipulations
534
can be identified within a manageable timespan.
535
536
Roadside ITS Station Gateway PP
26 Bundesanstalt für Straßenwesen (BASt)
on behalf of C-Roads
4.3.2.5 T.SoftwareManipulation
537
The installation of hostile software or firmware updates on the TOE using (in-)direct access is countered
538
by O.Crypt, O.Protect, O.Access and O.SecureFirmwareUpdate.
539
This threat is also countered by O.Crypt, O.Protect and O.Access, based on the same explanations like
540
in Section 4.3.2.4. Additionally O.SecureFirmwareUpdate only allows verified updates to be installed.
541
In addition, the OE.PhysicalProtection contributes to counter this threat by ensuring that manipulations
542
can be identified within a manageable timespan.
543
544
4.3.2.6 T.RemoteDataManipulation
545
The injection of false traffic data by impersonating a TCC or an V-ITS-S is countered by O.Crypt,
546
O.SendAuthenticatedData, O.ReceiveAuthenticatedData, O.Protect, O.Authentication, O.Access,
547
and O.Management.
548
This threat is countered by nearly the same objectives like in Section 4.3.2.5 (O.Crypt, O.Protect and
549
O.Access) based on the same reasons and application. Additionally, O.SendAuthenticatedData and
550
O.ReceiveAuthenticatedData ensure, in combination with O.Authentication that only verified
551
messages are accepted at the TOE. O.Management also supports the countermeasures against this threat
552
by restricting firmware updates and configuration changes.
553
554
4.3.2.7 T.RemoteMalfunction
555
The induction of faulty behaviour of the TOE by sending malformed messages to the TOE is countered
556
by O.Crypt, O.SendAuthenticatedData, O.ReceiveAuthenticatedData, O.Protect,
557
O.Authentication and O.Management.
558
O.Protect is used to counter this threat concerning to the explanations in Section 4.3.2.3. Additionally,
559
O.Crypt enforces the usage of reliable signature verification, cryptographic secured communication
560
channels and side-channel resistant cryptographic algorithms. O.SendAuthenticatedData and
561
O.ReceiveAuthenticatedData ensure, in combination with O.Authentication, that only verified
562
messages are accepted at the TOE. O.Management also supports the countermeasures against this threat
563
by restricting firmware updates and configuration changes.
564
565
4.3.2.8 T.Interception
566
The interception of traffic, road works, status data or configuration data sent between the TOE and the
567
TCC/RA/PKI is countered by O.Crypt, O.SecureChannel, O.Protect, O.Authentication and
568
O.Access.
569
O.Crypt enforces the usage of reliable signature verification, cryptographic secured communication
570
channels and side-channel resistant cryptographic algorithms. In combination with O.SecureChannel
571
the TOE can establish a (mutually) authenticated and confidential channel, whereby O.Authentication
572
provides authentication mechanisms. O.Protect implements the necessary functions against
573
malfunctions and tampering by overwriting redundant data, providing self-test functionalities and
574
prevention against emitting any information that may be used to obtain secret data. O.Access enables
575
the necessary access control which provides the rights to the corresponding users.
576
577
4.3.3 Coverage of Organisational Security Policies
578
The following sections provide more detailed information about how the security objectives for the
579
operational environment and the TOE cover the organisational security policies.
580
4.3.3.1 OSP.SE
581
The organisational security policy OSP.SE that mandates that the TOE utilises the services of a certified
582
Secure Element is directly addressed by the security objectives OE.SE and O.Crypt. The objective
583
OE.SE addresses the functions that the Secure Element shall be utilised for as defined in OSP.SE and
584
Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 27
on behalf of C-Roads
also requires a certified Secure Element according to the specified requirements in OE.SE. O.Crypt
585
defines the cryptographic functionalities for the TOE itself. In this context it has to be ensured that the
586
Secure Element is operated in accordance with its guidance documentation.
587
588
4.3.3.2 OSP.StrongCrypto
589
The organisational security policy OSP.StrongCrypto mandates that all cryptographic functions of the
590
TOE shall have a security level of at least 120 bit. O.Crypt ensures that the respective security level is
591
applied by the security functionalities.
592
4.3.3.3 OSP.Log
593
The organisational security policy OSP.Log that mandates that the TOE maintains an audit log is directly
594
addressed by the security objective for the TOE O.Log.
595
O.Log ensures security relevant information is tracked and can be examined by an authorised RA.
596
O.Access contributes to the implementation of the OSP as it defines that authorised RAs are not allowed
597
to modify the log data. This is of specific importance to ensure the integrity of the log data as required
598
by the OSP.Log.
599
600
4.3.4 Coverage of Assumptions
601
The following sections provide more detailed information about how the security objectives for the
602
operational environment cover the assumptions.
603
4.3.4.1 A.SecureSetup
604
The assumption A.SecureSetup is directly and completely covered by the security objective
605
OE.SecureSetup. The assumption and the objective for the operational environment are drafted in a
606
way that the correspondence is obvious.
607
608
4.3.4.2 A.TrustedAdministrator
609
The assumption A.TrustedAdministrator is directly and completely covered by the security objective
610
OE.TrustedAdministrator. The assumption and the objective for the operational environment are
611
drafted in a way that the correspondence is obvious.
612
613
4.3.4.3 A.PhysicalProtection
614
The assumption A.PhysicalProtection is directly and completely covered by the security objective
615
OE.PhysicalProtection. The assumption and the objective for the operational environment are drafted
616
in a way that the correspondence is obvious.
617
618
4.3.4.4 A.CorrectLocation
619
The assumption A.CorrectLocation is directly and completely covered by the security objective
620
OE.CorrectLocation. The assumption and the objective for the operational environment are drafted in
621
a way that the correspondence is obvious.
622
623
4.3.4.5 A.Information
624
The assumption A.Information is directly and completely covered by the security objective
625
OE.Information. The assumption and the objective for the operational environment are drafted in a
626
way that the correspondence is obvious.
627
628
Roadside ITS Station Gateway PP
28 Bundesanstalt für Straßenwesen (BASt)
on behalf of C-Roads
5 Extended Component Definition
629
This Protection Profile uses no components which are not defined in [CC] Part 2.
630
Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 29
on behalf of C-Roads
6 Security Requirements
631
6.1 Overview
632
This chapter describes the security functional and the assurance requirements which have to be fulfilled
633
by the TOE. Those requirements comprise functional components from part 2 of [CC] and the assurance
634
components as defined for the Evaluation Assurance Level 3 from part 3 of [CC].
635
The following notations are used:
636
• Refinement operation (denoted by bold text): is used to add details to a requirement, and thus
637
further restricts a requirement. In case that a word has been deleted from the original text this
638
refinement is indicated by crossed out bold text.
639
• Selection operation (denoted by underlined text): is used to select one or more options provided by
640
the [CC] in stating a requirement.
641
• Assignment operation (denoted by italicised text): is used to assign a specific value to an
642
unspecified parameter, such as the length of a password.
643
• Iteration operation: are identified with a suffix in the name of the SFR (e.g. FMT_MOF.1/Mode).
644
It should be noted that the requirements in the following chapters are not necessarily be ordered
645
alphabetically. Where useful the requirements have been grouped.
646
The following table summarises all TOE security functional requirements of this PP:
647
Class FAU: Security Audit
FAU_GEN.1 Audit data generation
FAU_GEN.2 User identity association
FAU_SAR.1 Audit review
FAU_STG.2 Protected audit data storage
FAU_STG.5 Prevention of audit data loss
Class FCS: Cryptographic Operation
FCS_COP.1/AES Cryptographic operation of AES-CCM
FCS_COP.1/Backend Cryptographic operation for backend communication
FCS_COP.1/Hash Cryptographic operation for hash value generation
FCS_COP.1/SigVer Cryptographic operation for signature verification
FCS_COP.1/SigVerFW Cryptographic operation for signature verification of firmware updates
FCS_CKM.1/AES Cryptographic key generation of AES keys and nonces
FCS_CKM.1/Backend Cryptographic key generation for backend communication
FCS_CKM.5/Backend Cryptographic key derivation for backend communication
FCS_CKM.6 Timing and event of cryptographic key destruction
Class FDP: User Data Protection
Roadside ITS Station Gateway PP
30 Bundesanstalt für Straßenwesen (BASt)
on behalf of C-Roads
FDP_ACC.1 Subset access control
FDP_ACF.1 Security attribute-based access control
FDP_IFC.2 Complete information flow control
FDP_IFF.1 Simple security attributes
FDP_RIP.1 Subset residual information protection
Class FIA: Identification and Authentication
FIA_ATD.1 User attribute definition
FIA_UAU.2 User authentication before any action
FIA_UAU.5 Multiple authentication mechanisms
FIA_UID.2 User identification before any action
Class FMT: Security Management
FMT_MSA.1 Management of security attributes
FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
Class FPT: Protection of the TSF
FPT_FLS.1 Fail secure
FPT_PHP.1 Passive detection of physical attack
FPT_RPL.1 Replay detection
FPT_STM.1 Reliable time stamps
FPT_TDC.1 Inter-TSF basic TSF data consistency
FPT_TST.1 TSF self-testing
Class FTP: Trusted path/channels
FTP_PRO.1/Backend Trusted channel protocol for the backend communication
FTP_PRO.1/PKI Trusted channel protocol for the communication with the PKI
FTP_PRO.2/Backend Trusted channel establishment for the backend communication
FTP_PRO.3/Backend Trusted channel data protection for the backend communication
FTP_PRO.3/PKI Trusted channel data protection for the communication with the PKI
Table 10: List of Security Functional Requirements (SFRs)
648
649
Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 31
on behalf of C-Roads
6.2 Class FAU: Security Audit
650
6.2.1 FAU_GEN.1 Audit data generation
651
FAU_GEN.1.1
652
The TSF shall be able to generate audit data of the following auditable events:
653
a) Start-up and shutdown of the audit functions;
654
b) All auditable events for the [basic] level of audit;
655
c) [assignment: other non-privacy relevant auditable events].
656
FAU_GEN.1.2
657
The TSF shall record within the audit data at least the following information:
658
a) Date and time of the auditable event, type of event, subject identity (if applicable), and the
659
outcome (success or failure) of the event;
660
b) For each auditable event type, based on the auditable event definitions of the functional
661
components included in the PP, PP-Module, functional package or ST, [assignment: other audit
662
relevant information or none].
663
6.2.2 FAU_GEN.2 User identity association
664
FAU_GEN.2.1
665
For audit events resulting from actions of identified users, the TSF shall be able to associate each
666
auditable event with the identity of the user that caused the event.
667
6.2.3 FAU_SAR.1 Audit review
668
FAU_SAR.1.1
669
The TSF shall provide [the RA, [assignment: other authorized users]] with the capability to read
670
[assignment: list of audit information] from the audit data.
671
FAU_SAR.1.2
672
The TSF shall provide the audit data in a manner suitable for the user to interpret the information.
673
6.2.4 FAU_STG.2 Protected audit data storage
674
FAU_STG.2.1
675
The TSF shall protect the stored audit data in the audit trail from unauthorized deletion.
676
FAU_STG.2.2
677
The TSF shall be able to [prevent] unauthorized modifications to the stored audit data in the audit trail.
678
6.2.5 FAU_STG.5 Prevention of audit data loss
679
FAU_STG.5.1
680
The TSF shall [overwrite the oldest stored audit records], [assignment: other actions to be taken in case
681
of audit storage failure and conditions for the actions] if the audit data storage is full.
682
Hint
683
The size of the audit trail that is available before the oldest event is overwritten can either be a static
684
value or dynamically configurable by the RA.
685
6.3 Class FCS: Cryptographic Support
686
6.3.1 FCS_COP.1/AES Cryptographic operation of AES-CCM
687
FCS_COP.1.1/AES
688
The TSF shall perform [authenticated encryption and decryption] in accordance with a specified
689
cryptographic algorithm [AES-CCM] and cryptographic key sizes [128-bit] that meet the following: [
690
Roadside ITS Station Gateway PP
32 Bundesanstalt für Straßenwesen (BASt)
on behalf of C-Roads
AES [FIPS 197],
AES-CCM [NIST SP 800-38C]
].
691
Application Note 14
692
Please note that [NIST SP 800-38C] requires that the nonce shall be unique for each encrypted message
693
protected by the same key.
694
The PP requires that, in addition to the uniqueness of the nonce, it should also be freshly generated at
695
random. Please refer to FCS_CKM.1/AES and Application Note 17.
696
697
Hint
698
AES-CCM is used to encrypt the Authorisation/Enrolment-Request and to decrypt the
699
Authorisation/Enrolment-Response exchanged between the TOE and the PKI (see [ETSI TS 102 941]).
700
Via FCS_CKM.1/AES, the respective AES key and the nonce are generated.
701
6.3.2 FCS_COP.1/Backend Cryptographic operation for backend communication
702
FCS_COP.1.1/Backend
703
The TSF shall perform [assignment: list of cryptographic operations] in accordance with a specified
704
cryptographic algorithm [assignment: cryptographic algorithm] and cryptographic key sizes
705
[assignment: cryptographic key sizes] that meet the following: [assignment: list of standards].
706
Application Note 15
707
Please note that the PP is based on the assumption that all cryptographic keys required for the backend
708
connection are stored inside the TOE. If an ST author include cryptographic key that are stored outside
709
of the TOE, the author also shall model the corresponding cryptographic key access using FCS_CKM.3
710
and adjust the table of SFR dependencies (Table 13).
711
6.3.3 FCS_COP.1/Hash Cryptographic operation for hash value generation
712
FCS_COP.1.1/Hash
713
The TSF shall perform [cryptographic hashing] in accordance with a specified cryptographic algorithm
714
[SHA-256, SHA-384, [assignment: other hash algorithms or none]] and cryptographic key sizes [none]
715
that meet the following: [
716
SHA-256,
SHA-384
[FIPS 180-4],
[assignment: other standards or none]
].
717
6.3.4 FCS_COP.1/SigVer Cryptographic operation for signature verification
718
FCS_COP.1.1/SigVer
719
The TSF shall perform [signature verification] in accordance with a specified cryptographic algorithm
720
[ECDSA with SHA-256 and ECDSA with SHA-384] and cryptographic key sizes [NIST P-256,
721
brainpool256r1, brainpool384r1 and [assignment: curve or none]] that meet the following: [
722
ECDSA [FIPS 186-4],
NIST P-256 [FIPS 186-4],
brainpoolP256r1,
brainpoolP384r1
[RFC5639],
SHA-256,
SHA-384
[FIPS 180-4],
[assignment: other standards or none]
].
723
Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 33
on behalf of C-Roads
Hint
724
The signature generation will always be performed by the built in Secure Element while signature
725
verification of received V-ITS-S transmissions may also be performed in the TOE.
726
6.3.5 FCS_COP.1/SigVerFW Cryptographic operation for signature verification of
727
firmware updates
728
FCS_COP.1.1/SigVerFW
729
The TSF shall perform [signature verification for firmware updates] in accordance with a specified
730
cryptographic algorithm [assignment: cryptographic algorithm] and cryptographic key sizes
731
[assignment: cryptographic key sizes] that meet the following: [assignment: list of standards].
732
Application Note 16
733
The ST author is reminded that the PP author assumes a simple update process, in which a secure
734
implementation is carried out without any security-relevant pre-processing of the update data. If pre-
735
processing of the update data is performed, applicable processing rules should be modelled using
736
FDP_ITC.1 or FDP_ITC.2.
737
6.3.6 FCS_CKM.1/AES Cryptographic key generation of AES keys and nonces
738
FCS_CKM.1.1/AES
739
The TSF shall generate cryptographic AES keys and nonces in accordance with a specified
740
cryptographic key generation algorithm [[selection: utilizing random source of the SE, utilizing random
741
source as specified in FCS_RNG.1, utilizing random source as specified in FCS_RBG.1, [assignment:
742
other source]] and specified cryptographic key sizes [128-bit for AES keys, 96-bit for nonces] that meet
743
the following: [
744
IEEE Std 1609.2 [IEEE 1609.2],
[assignment: other standards or none]
].
745
Application Note 17
746
Please note that [IEEE 1609.2] requires that the nonces shall be freshly generated at random for each
747
invocation of AES-CCM.
748
749
Application Note 18
750
If a random source other than the SE is used for key generation, this must be modelled accordingly by
751
the ST author, including adding new SFRs such as FCS_RNG.1 or FCS_RBG.1 (see Application Note
752
11) and resolving the dependencies of FCS_CKM.1/AES and all new introduced SFRs.
753
6.3.7 FCS_CKM.1/Backend Cryptographic key generation for backend communication
754
FCS_CKM.1.1/Backend
755
The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation
756
algorithm [assignment: cryptographic key generation algorithm] and specified cryptographic key sizes
757
[assignment: cryptographic key sizes] that meet the following: [assignment: list of standards].
758
6.3.8 FCS_CKM.5/Backend Cryptographic key derivation for backend communication
759
FCS_CKM.5.1/Backend
760
The TSF shall derive cryptographic keys [assignment: key type] from [assignment: input parameters] in
761
accordance with a specified key derivation algorithm [assignment: key derivation algorithm] and
762
specified cryptographic key sizes [assignment: list of key sizes] that meet the following: [assignment:
763
list of standards].
764
Roadside ITS Station Gateway PP
34 Bundesanstalt für Straßenwesen (BASt)
on behalf of C-Roads
6.3.9 FCS_CKM.6 Timing and event of cryptographic key destruction
765
FCS_CKM.6.1
766
The TSF shall destroy [assignment: list of cryptographic keys (including keying material)] when [no
767
longer needed, [assignment: other circumstances for key or keying material destruction or none]].
768
FCS_CKM.6.2
769
The TSF shall destroy cryptographic keys and keying material specified by FCS_CKM.6.1 in
770
accordance with a specified cryptographic key destruction method [assignment: cryptographic key
771
destruction method] that meets the following: [assignment: list of standards].
772
Application Note 19
773
Please note that as against the requirement FDP_RIP.1 the mechanisms implementing the requirement
774
from FCS_CKM.6 shall be suitable to avoid attackers with physical access to the TOE from accessing
775
the keys after they are no longer used.
776
777
Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 35
on behalf of C-Roads
6.4 Class FDP: User Data Protection
778
6.4.1 FDP_ACC.1 Subset access control
779
FDP_ACC.1.1
780
The TSF shall enforce the [RGW access SFP] on [
781
• Subjects: external entities using any TSFI;
782
• Objects: any information that is sent to, from or via the TOE and any information that is stored
783
in the TOE;
784
• Operations: all operations among subjects and objects covered by the RGW access SFP.
785
].
786
6.4.2 FDP_ACF.1 Security attribute-based access control
787
FDP_ACF.1.1
788
The TSF shall enforce the [RGW access SFP] to objects based on the following: [
789
• Subjects: external entities using any TSFI;
790
• Objects: any information or data that is sent to, from or via the TOE;
791
• Attributes: destination interface and [assignment: further SFP-relevant security attributes or
792
none].
793
].
794
FDP_ACF.1.2
795
The TSF shall enforce the following rules to determine if an operation among controlled subjects and
796
controlled objects is allowed: [
797
• an authorised RA is allowed to have access via IF_GW_Admin but is not allowed to read, modify
798
or write stored and/or processed assets within the TOE, except reading status, logging, update
799
information and configuration data,
800
• only an authorised RA is allowed to start the firmware update process and change configuration
801
data,
802
• an authorised TCC is only allowed to interact with the TOE via IF_GW_TCC, and
803
• [assignment: rules, based on security attributes, that allow operations among controlled
804
subjects and controlled objects].
805
].
806
FDP_ACF.1.3
807
The TSF shall explicitly authorize access of subjects to objects based on the following additional rules:
808
[assignment: rules, based on security attributes, that explicitly authorize access of subjects to objects].
809
FDP_ACF.1.4
810
The TSF shall explicitly deny access of subjects to objects based on the following additional rules: [
811
• private cryptographic keys must never be readable,
812
• TCC is not allowed to read logging information,
813
• [assignment: rules, based on security attributes, that explicitly deny access of subjects to
814
objects].
815
].
816
Application Note 20
817
Please note that the PP is based on the assumption that only static attributes will be defined in
818
FDP_ACF.1. If an ST author include any dynamic ones, the author also shall model corresponding
819
management functionalities and rules within FMT_MSA.3 and adjust the SFR dependencies table (Table
820
13).
821
Roadside ITS Station Gateway PP
36 Bundesanstalt für Straßenwesen (BASt)
on behalf of C-Roads
6.4.3 FDP_IFC.2 Complete information flow control
822
FDP_IFC.2.1
823
The TSF shall enforce the [RGW information flow control SFP] on [
824
• Subjects: TOE, RA, TCC, V-ITS-S, PKI, and [selection: Gateway to equipment, External
825
Controller, [assignment: other or none]];
826
• Information: messages;
827
• Operation: send, receive.
828
] and all operations that cause that information to flow to and from subjects covered by the SFP.
829
FDP_IFC.2.2
830
The TSF shall ensure that all operations that cause any information in the TOE to flow to and from any
831
subject in the TOE are covered by an information flow control SFP.
832
6.4.4 FDP_IFF.1 Simple security attributes
833
FDP_IFF.1.1
834
The TSF shall enforce the [RGW information flow control SFP] based on the following types of subject
835
and information security attributes: [
836
• Subjects: TOE, RA, TCC, V-ITS-S, PKI, [selection: Gateway to equipment, External Controller,
837
[assignment: other or none]];
838
• Information: messages;
839
• Attributes:
840
o source_interface (TOE, RA, TCC, V-ITS-S, PKI, or [selection: Gateway to equipment,
841
External Controller, none]),
842
o destination_interface (TOE, RA, TCC, V-ITS-S, PKI, or [selection: Gateway to
843
equipment, External Controller, none]),
844
o signatures for ITS-M.
845
].
846
FDP_IFF.1.2
847
The TSF shall permit an information flow between a controlled subject and controlled information via
848
a controlled operation if the following rules hold: [
849
• Connection establishment is only allowed between the introduced destination_interfaces and
850
source_interfaces.
851
• All messages sent to the roles TCC, RA and PKI must only be sent via a cryptographic secured
852
communication channel.
853
• All ITS-M must be signed prior to sending utilising the SE.
854
• The signature of every ITS-M received by
855
o source_interface = TCC
856
o source_interface = V-ITS-S
857
must be verified:
858
o If the signature is found to be invalid, the message must be dropped.
859
o Only messages with a valid signature may be processed.
860
].
861
FDP_IFF.1.3
862
The TSF shall enforce the [assignment: additional information flow control SFP rules].
863
FDP_IFF.1.4
864
The TSF shall explicitly authorize an information flow based on the following rules: [assignment: rules,
865
based on security attributes, that explicitly authorize information flows].
866
Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 37
on behalf of C-Roads
FDP_IFF.1.5
867
The TSF shall explicitly deny an information flow based on the following rules: [
868
• Connection establishment is especially denied in the following cases:
869
o (Source_interface = RA or source_interface = TCC) and
870
destination_interface = V-ITS-S
871
o Source_interface = V-ITS-S and
872
(destination_interface = RA or destination_interface = TCC)
873
o Source_interface = RA and destination_interface = TCC
874
o Source_interface = TCC and destination_interface = RA
875
o Source_interface = PKI and destination_interface = TOE
876
• Received messages from source_interface = V-ITS-S that do not comply to a standard of
877
[assignment: standards or list of standards, based on the implemented set of C-ITS messages]
878
shall be dropped.
879
• [assignment: other rules, based on security attributes, that explicitly deny information flows]
880
].
881
Application Note 21
882
Please note that the PP is based on the assumption that only static firewall rules will be defined in
883
FDP_IFF.1. If an ST author include any dynamic ones, the author also shall model corresponding
884
management functionalities and rules within FMT_MSA.3 and adapt the SFR dependencies table (Table
885
13).
886
6.4.5 FDP_RIP.1 Subset residual information protection
887
FDP_RIP.1.1
888
The TSF shall ensure that any previous information content of a resource is made unavailable upon the
889
[deallocation of the resource from] the following objects: [cryptographic keys (and session keys), all
890
received messages, all sent messages, aggregated information, [assignment: other objects or none]].
891
892
Roadside ITS Station Gateway PP
38 Bundesanstalt für Straßenwesen (BASt)
on behalf of C-Roads
6.5 Class FIA: Identification and Authentication
893
6.5.1 FIA_ATD.1 User attribute definition
894
FIA_ATD.1.1
895
The TSF shall maintain the following list of security attributes belonging to individual users: [
896
• user identity,
897
• connecting network,
898
• role membership, and
899
• [assignment: list of security attributes].
900
].
901
6.5.2 FIA_UAU.2 User authentication before any action
902
FIA_UAU.2.1
903
The TSF shall require each user to be successfully authenticated before allowing any other TSF-
904
mediated actions on behalf of that user
905
6.5.3 FIA_UAU.5 Multiple authentication mechanisms
906
FIA_UAU.5.1
907
The TSF shall provide [
908
• authentication via validation of the authentication tag of AES-CCM at the IF_GW_PKI
909
interface,
910
• [assignment: appropriate authentication mechanism] at the IF_GW_Admin interface,
911
• [assignment: appropriate authentication mechanism] at the IF_GW_TCC interface,
912
• authentication via certificates at IF_GW_SR, and
913
• [assignment: list of multiple authentication mechanisms]
914
] to support user authentication.
915
FIA_UAU.5.2
916
The TSF shall authenticate any user's claimed identity according to the [
917
• RAs shall be authenticated via [assignment: appropriate authentication mechanism] at IF_GW_
918
Admin only,
919
• TCCs shall be authenticated via [assignment: appropriate authentication mechanism] at
920
IF_GW_TCC interface only,
921
• PKIs shall be authenticated via validation of the authentication tag of AES-CCM at
922
IF_GW_PKI only,
923
• V-ITS-S shall be authenticated via certificates at IF_GW_SR only,
924
• [assignment: rules describing how the multiple authentication mechanisms provide
925
authentication].
926
].
927
Application Note 22
928
The ST author is reminded that the assignments in FIA_UAU.5 shall cover the authentication
929
mechanisms for the protected communication channels (FTP_PRO.1/Backend, FTP_PRO.1/PKI, etc)
930
as well as the authentication mechanisms for local maintenance by the RA.
931
6.5.4 FIA_UID.2 User identification before any action
932
FIA_UID.2.1
933
The TSF shall require each user to be successfully identified before allowing any TSF-mediated actions
934
on behalf of that user.
935
Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 39
on behalf of C-Roads
6.6 Class FMT: Security Management
936
6.6.1 FMT_MSA.1 Management of security attributes
937
FMT_MSA.1.1
938
The TSF shall enforce the [RGW access SFP] to restrict the ability to [modify, delete, [assignment: other
939
operations]] the security attributes [all relevant security attributes] to [authorised identified roles].
940
6.6.2 FMT_SMF.1 Specification of management functions
941
FMT_SMF.1.1
942
The TSF shall be capable of performing the following management functions: [
943
• firmware update,
944
• configuration change, and
945
• [assignment: list of additional management functions to be provided by the TSF or none].
946
].
947
Application Note 23
948
The TOE performs a secure firmware update, which requires the TOE to implement the following:
949
• verify firmware update signature to ensure authenticity and integrity prior to installation (acc.
950
FCS_COP.1/SigVerFW), and
951
• RA authentication is required to upload the firmware update data (acc. FIA_UAU.2 and
952
FIA_UID.2).
953
An automatic firmware update is not allowed if the previous points cannot be guaranteed.
954
The term firmware update applies to any security relevant software update in the TOE.
955
6.6.3 FMT_SMR.1 Security roles
956
FMT_SMR.1.1
957
The TSF shall maintain the roles [
958
• PKI,
959
• RA,
960
• TCC,
961
• V-ITS-S, and
962
• [assignment: additional roles or none].
963
].
964
FMT_SMR.1.2
965
The TSF shall be able to associate users with roles.
966
Application Note 24
967
The ST Author can add the additional role SOC for a Security Operations Center (SOC) and model it
968
accordingly in the SFRs (i.e FMT_SMR.1, FDP_IFF.1, FDP_ACF.1, FIA_UAU.5). This additionally
969
specified role is only allowed to have read access to the security-relevant log. All other security
970
requirements regarding connections between the SOC and the TOE shall be the same as those between
971
the RA and the TOE.
972
973
Roadside ITS Station Gateway PP
40 Bundesanstalt für Straßenwesen (BASt)
on behalf of C-Roads
6.7 Class FPT: Protection of the TSF
974
6.7.1 FPT_FLS.1 Fail secure
975
FPT_FLS.1.1
976
The TSF shall preserve a secure state when the following types of failures occur: [
977
• the deviation between local system time of the TOE and the reliable external time source is too
978
large,
979
• [assignment: other of types of failures in the TSF].
980
].
981
6.7.2 FPT_PHP.1 Passive detection of physical attack
982
FPT_PHP.1.1
983
The TSF shall provide unambiguous detection of physical tampering that can compromise the TSF.
984
FPT_PHP.1.2
985
The TSF shall provide the capability to determine whether physical tampering with the TSF's devices
986
or TSF's elements has occurred.
987
6.7.3 FPT_RPL.1 Replay detection
988
FPT_RPL.1.1
989
The TSF shall detect replay for the following entities: [TCC, RA].
990
FPT_RPL.1.2
991
The TSF shall perform [ignore replayed data] when replay is detected.
992
Hint
993
Replay detection for communication with V-ITS-S and PKI is not in the scope of this PP. For the
994
communication to these external entities, the replay detection is not covered by individual SFRs but it
995
is part of the functional specification and the respective communication standards.
996
6.7.4 FPT_STM.1 Reliable time stamps
997
FPT_STM.1.1
998
The TSF shall be able to provide reliable time stamps.
999
Application Note 25
1000
The time stamps as defined by FPT_STM.1 shall be of sufficient exactness.
1001
Therefore, the local system time of the TOE is synchronised regularly with a reliable external time
1002
source. However, the local clock also needs a sufficient exactness as the synchronisation will fail if the
1003
deviation is too large (the TOE will preserve a secure state according to FPT_FLS.1).
1004
Therefore, the local clock shall be able to measure time in a granularity that is appropriate for the
1005
required TSF.
1006
6.7.5 FPT_TDC.1 Inter-TSF basic TSF data consistency
1007
FPT_TDC.1.1
1008
The TSF shall provide the capability to consistently interpret [information about the validity of
1009
certificates and certificate lists (CTLs, CRLs)] when shared between the TSF and another trusted IT
1010
products (V-ITS-S and servers that provide the certificates and/or certificate lists (CTLs, CRLs)).
1011
FPT_TDC.1.2
1012
The TSF shall use [assignment: list of interpretation rules to be applied by the TSF] when interpreting
1013
the TSF data from another trusted IT product.
1014
Application Note 26
1015
Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 41
on behalf of C-Roads
The ST author shall refine the interpretation rules in FPT_TDC.1.2 appropriately, based on the current
1016
version of [SecReq]. These interpretation rules must include verification of the signature of the
1017
certificates and certificate lists (CTLs, CRLs).
1018
6.7.6 FPT_TST.1 TSF self-testing
1019
FPT_TST.1.1
1020
The TSF shall run a suite of the following self-tests [during initial start-up, periodically during normal
1021
operation, at the request of the authorized user, [selection: at the conditions [assignment: conditions
1022
under which self-test should occur], none]] to demonstrate the correct operation of [the TSF]:
1023
[assignment: list of self-tests run by the TSF].
1024
FPT_TST.1.2
1025
The TSF shall provide authorized users with the capability to verify the integrity of [TSF data].
1026
FPT_TST.1.3
1027
The TSF shall provide authorized users with the capability to verify the integrity of [TSF].
1028
1029
Roadside ITS Station Gateway PP
42 Bundesanstalt für Straßenwesen (BASt)
on behalf of C-Roads
6.8 Class FTP: Trusted Path/Channels
1030
6.8.1 FTP_PRO.1/Backend Trusted channel protocol for the backend communication
1031
FTP_PRO.1.1/Backend
1032
The TSF shall implement [assignment: trusted channel protocol] acting as [assignment: defined protocol
1033
role(s)] in accordance with: [assignment: list of standards].
1034
FTP_PRO.1.2/Backend
1035
The TSF shall enforce usage of the trusted channel for [[selection: communication with the TCC,
1036
communication with the RA, [assignment: additional purpose(s) of the trusted channel]]] in accordance
1037
with: [assignment: list of standards].
1038
FTP_PRO.1.3/Backend
1039
The TSF shall permit [selection: itself, its peer] to initiate communication via the trusted channel.
1040
FTP_PRO.1.4/Backend
1041
The TSF shall enforce the following rules for the trusted channel: [assignment: rules governing
1042
operation and use of the trusted channel and/or its protocol].
1043
FTP_PRO.1.5/Backend
1044
The TSF shall enforce the following static protocol options: [assignment: list of options and references
1045
to standards in which each is defined].
1046
FTP_PRO.1.6/Backend
1047
The TSF shall negotiate one of the following protocol configurations with its peer: [assignment: list of
1048
configurations and reference to standards in which each is defined].
1049
Application Note 27
1050
The TOE shall implement a trusted and protected communication channel to the RA and the TCC that
1051
shall be modelled in a variety of SFRs by the ST author. This channel shall be protected by adequate
1052
and state of the art security and cryptographic mechanisms. Suitable communication protocols are e.g.
1053
TLS [RFC8446], IPsec [RFC4301] or SSH [RFC4254]. Should one of these or another protocol be used,
1054
appropriate recommendations for cryptographic mechanisms from e.g. SOGIS or a certification
1055
authority shall be complied with.
1056
For the protocols mentioned as an example, the following recommendations for cryptographic
1057
mechanisms of the BSI can be considered: [TR-02102-1] (general recommendations), [TR-02102-2]
1058
(TLS), [TR-02102-3] (IPsec), and [TR-02102-4] (SSH).
1059
6.8.2 FTP_PRO.1/PKI Trusted channel protocol for the communication with the PKI
1060
FTP_PRO.1.1/PKI
1061
The TSF shall implement [Authorization Requests/Responses and Enrolment Requests/Responses]
1062
acting as [requester] in accordance with: [
1063
ETSI TS 102 941 [ETSI TS 102 941],
[assignment: other standards or none]
].
1064
FTP_PRO.1.2/PKI
1065
The TSF shall enforce usage of the trusted channel for [message exchanges (Authorization
1066
Requests/Responses and Enrolment Requests/Responses) with the PKI (Authorization Authority and
1067
Enrolment Authority)] in accordance with: [
1068
ETSI TS 102 941 [ETSI TS 102 941],
[assignment: other standards or none]
].
1069
FTP_PRO.1.3/PKI
1070
The TSF shall permit [itself] to initiate communication via the trusted channel.
1071
Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 43
on behalf of C-Roads
FTP_PRO.1.4/PKI
1072
The TSF shall enforce the following rules for the trusted channel: [
1073
• Generation of random AES key and random nonce (using FCS_CKM.1/AES).
1074
• Encryption/Decryption of request/response with AES-CCM (using FCS_COP.1/AES).
1075
• The AES key is encrypted with ECIES utilizing the cryptographic functionality of the SE (by
1076
transferring the AES key and public key of the recipient to the SE).
1077
• Transmission of the encrypted AES key, the authentication tag, the nonce, the encrypted request,
1078
and the ephemeral public key to the recipient.
1079
• Reception of the encrypted response and authentication tag from the recipient.
1080
• Validation of authentication by checking the authentication tag (AES-CCM) of the received
1081
respond (using FCS_COP.1/AES).
1082
• [assignment: rules governing operation and use of the trusted channel and/or its protocol].
1083
].
1084
FTP_PRO.1.5/PKI
1085
The TSF shall enforce the following static protocol options: [None specified].
1086
FTP_PRO.1.6/PKI
1087
The TSF shall negotiate one of the following protocol configurations with its peer: [None specified].
1088
Hint
1089
FTP_PRO.2 is not iterated for the PKI connection since the establishment of the AES key is based on
1090
ECIES and the calculation of ECIES is performed by the SE (and not by the TOE itself) (cf.
1091
FTP_PRO.2.1 as defined in [CC] Part 2). Furthermore, no cryptographic keys are derived from a shared
1092
secret (cf. FTP_PRO.2.3 as defined in [CC] Part 2). The primary data encryption key (AES) is encrypted
1093
with ECIES (by the SE) and then transmitted to the PKI as stated in [IEEE 1609.2]. The authentication
1094
is performed on both sides by validating the authentication tag of AES-CCM (cf. FTP_PRO2.2 as
1095
defined in [CC] Part 2).
1096
6.8.3 FTP_PRO.2/Backend Trusted channel establishment for the backend
1097
communication
1098
FTP_PRO.2.1/Backend
1099
The TSF shall establish a shared secret with its peer using one of the following mechanisms:
1100
[assignment: list of key establishment mechanisms].
1101
FTP_PRO.2.2/Backend
1102
The TSF shall authenticate [its peer, itself to its peer] using one of the following mechanisms:
1103
[assignment: list of authentication mechanisms] and according to the following rules: [assignment: list
1104
of rules for carrying out the authentication].
1105
FTP_PRO.2.3/Backend
1106
The TSF shall use [assignment: key derivation function] to derive the following cryptographic keys from
1107
a shared secret: [assignment: list of cryptographic keys].
1108
6.8.4 FTP_PRO.3/Backend Trusted channel data protection for the backend
1109
communication
1110
FTP_PRO.3.1/Backend
1111
The TSF shall protect data in transit from unauthorised disclosure using one of the following
1112
mechanisms: [assignment: list of encryption mechanisms].
1113
FTP_PRO.3.2/Backend
1114
The TSF shall protect data in transit from [modification, deletion, insertion, replay, [selection:
1115
[assignment: other], none]] using one of the following mechanisms: [assignment: list of integrity
1116
protection mechanisms].
1117
Roadside ITS Station Gateway PP
44 Bundesanstalt für Straßenwesen (BASt)
on behalf of C-Roads
6.8.5 FTP_PRO.3/PKI Trusted channel data protection for the communication with the
1118
PKI
1119
FTP_PRO.3.1/PKI
1120
The TSF shall protect data in transit from unauthorised disclosure using one of the following
1121
mechanisms: [AES-CCM].
1122
FTP_PRO.3.2/PKI
1123
The TSF shall protect data in transit from [modification, deletion, insertion, replay] using one of the
1124
following mechanisms: [AES-CCM].
1125
1126
Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 45
on behalf of C-Roads
6.9 Security Assurance Requirements for the TOE
1127
The minimum Evaluation Assurance Level for this Protection Profile is EAL3.
1128
The following table lists the assurance components which are therefore applicable to this PP.
1129
1130
Assurance Class Assurance Component
Development ADV_ARC.1
ADV_FSP.3
ADV_TDS.2
Guidance Documents AGD_OPE.1
AGD_PRE.1
Life-Cycle Support ALC_CMC.3
ALC_CMS.3
ALC_DEL.1
ALC_DVS.1
ALC_LCD.1
Security Target Evaluation ASE_CCL.1
ASE_ECD.1
ASE_INT.1
ASE_OBJ.2
ASE_REQ.2
ASE_SPD.1
ASE_TSS.1
Tests ATE_COV.2
ATE_DPT.1
ATE_FUN.1
ATE_IND.2
Vulnerability Assessment AVA_VAN.2
Table 11: Assurance requirements
1131
1132
Roadside ITS Station Gateway PP
46 Bundesanstalt für Straßenwesen (BASt)
on behalf of C-Roads
6.10 Security Requirements Rationale
1133
This section proves that the set of security requirements (TOE) is suited to fulfil the security objectives
1134
described in Chapter 4 and that each SFR can be traced back to the security objectives. At least one
1135
security objective exists for each security requirement.
1136
O.Crypt
O.ReceiveAuthentificatedData
O.SendAuthenticatedData
O.SecureChannel
O.Protect
O.Authentication
O.Access
O.SecureFirmwareUpdate
O.Management
O.Log
FAU_GEN.1 X
FAU_GEN.2 X
FAU_SAR.1 X
FAU_STG.2 X
FAU_STG.5 X
FCS_COP.1/AES X X X X X
FCS_COP.1/Backend X X X X X
FCS_COP.1/Hash X
FCS_COP.1/SigVer X X X
FCS_COP.1/SigVerFW X X
FCS_CKM.1/AES X X
FCS_CKM.1/Backend X X
FCS_CKM.5/Backend X X
FCS_CKM.6 X
FDP_ACC.1 X
FDP_ACF.1 X
FDP_IFC.2 X X X
Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 47
on behalf of C-Roads
O.Crypt
O.ReceiveAuthentificatedData
O.SendAuthenticatedData
O.SecureChannel
O.Protect
O.Authentication
O.Access
O.SecureFirmwareUpdate
O.Management
O.Log
FDP_IFF.1 X X X
FDP_RIP.1 X
FIA_ATD.1 X X X
FIA_UAU.2 X X
FIA_UAU.5 X X
FIA_UID.2 X X X
FMT_MSA.1 X
FMT_SMF.1 X
FMT_SMR.1 X
FPT_FLS.1 X
FPT_PHP.1 X
FPT_RPL.1 X
FPT_STM.1 X
FPT_TDC.1 X X
FPT_TST.1 X
FTP_PRO.1/Backend X
FTP_PRO.1/PKI X
FTP_PRO.2/Backend X
FTP_PRO.3/Backend X
Roadside ITS Station Gateway PP
48 Bundesanstalt für Straßenwesen (BASt)
on behalf of C-Roads
O.Crypt
O.ReceiveAuthentificatedData
O.SendAuthenticatedData
O.SecureChannel
O.Protect
O.Authentication
O.Access
O.SecureFirmwareUpdate
O.Management
O.Log
FTP_PRO.3/PKI X
Table 12: Security requirements rationale
1137
The following paragraphs contain more details on this mapping.
1138
6.10.1 O.Crypt
1139
O.Crypt is met by a combination of the following SFRs:
1140
• FCS_COP.1/AES defines the requirements for the cryptographic algorithmAES-CCM used for
1141
the communication with the PKI.
1142
• FCS_COP.1/Backend defines the requirements for the protection of the communication with
1143
the RA and the TCC.
1144
• FCS_COP.1/Hash defines the requirements for the hash operations.
1145
• FCS_COP.1/SigVer defines the requirements around the verification of signatures in C-ITS
1146
context.
1147
• FCS_COP.1/SigVerFW defines the requirements on verification of the firmware update
1148
signature to ensure authenticity and integrity prior to installation.
1149
• FCS_CKM.1/AES defines the requirements for the generation of the keys and the nonces used
1150
in the cryptographic algorithm AES-CCM.
1151
• FCS_CKM.1/Backend defines the requirements on key generation for the communication with
1152
the RA and the TCC.
1153
• FCS_CKM.5/Backend defines the requirements on key derivation for the communication with
1154
the RA and the TCC.
1155
• FCS_CKM.6 defines the requirements around the secure deletion of ephemeral cryptographic
1156
keys.
1157
1158
6.10.2 O.ReceiveAuthenticatedData
1159
O.ReceiveAuthenticatedData is met by the following SFR:
1160
• FDP_IFC.2 which defines the complete information flow control.
1161
• FDP_IFF.1 defines the corresponding security attributes.
1162
• FCS_COP.1/SigVer verifies incoming data from V-ITS-S.
1163
• FCS_COP.1/AES verifies incoming data from PKI (with AES-CCM).
1164
• FCS_COP.1/Backend verifies incoming data from RA and TCC.
1165
1166
Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 49
on behalf of C-Roads
6.10.3 O.SendAuthenticatedData
1167
O.SendAuthenticatedData is met by the following SFR:
1168
• FDP_IFC.2 which defines the complete information flow control.
1169
• FDP_IFF.1 defines the corresponding security attributes.
1170
• FCS_COP.1/AES defines a method for providing authentication assurance (AES-CCM).
1171
• FCS_COP.1/Backend defines a method for providing authentication assurance.
1172
1173
6.10.4 O.SecureChannel
1174
O.SecureChannel is met by a combination of the following SFRs:
1175
• FCS_COP.1/AES defines the cryptographic operations for the authenticated encryption and
1176
decryption for the communication with the PKI.
1177
• FCS_COP.1/Backend defines the cryptographic operations for the secured backend channel.
1178
• FCS_CKM.1/AES defines the cryptographic key generation for the secure channel with the
1179
PKI.
1180
• FCS_CKM.1/Backend defines the cryptographic key generation for the secured backend
1181
channel.
1182
• FCS_CKM.5/Backend defines the cryptographic key derivation for the secured backend
1183
channel.
1184
• FTP_PRO.1/Backend defines the protocol for the trusted channel to the RA and TCC.
1185
• FTP_PRO.1/PKI defines the protocol for the trusted channel to the PKI.
1186
• FTP_PRO.2/Backend defines the establishment of the trusted channel to the RA and TCC.
1187
• FTP_PRO.3/Backend defines the data protection mechanisms of the trusted channel to the RA
1188
and TCC.
1189
• FTP_PRO.3/PKI defines the data protection mechanisms of the trusted channel to PKI.
1190
• FDP_IFC.2 defines the information flow control within the given architecture.
1191
• FDP_IFF.1 defines the corresponding security attributes.
1192
• FPT_RPL.1 defines the mechanism for a detected replay.
1193
1194
6.10.5 O.Authentication
1195
O.Authentication is met by a combination of the following SFRs:
1196
• FIA_ATD.1 defines the security attributes for all users.
1197
• FIA_UAU.2 and FIA_UAU.5 define the requirements around the authentication of users.
1198
• FIA_UID.2 defines requirements around the identification of users.
1199
• FCS_COP.1/SigVer ensures authentication of data from V-ITS-S.
1200
• FCS_COP.1/Backend ensures authentication of data from RA or TCC.
1201
• FCS_COP.1/AES ensures authentication of data from PKI.
1202
• FPT_TDC.1 ensures authentication by validation of certificates of V-ITS-S.
1203
1204
6.10.6 O.Access
1205
O.Access is met by a combination of:
1206
• FDP_ACC.2 and FDP_ACF.1, which define the required access control policy.
1207
• FIA_ATD.1 defines the security attributes for all users.
1208
Roadside ITS Station Gateway PP
50 Bundesanstalt für Straßenwesen (BASt)
on behalf of C-Roads
• FIA_UID.2 defines requirements around the identification of users.
1209
1210
6.10.7 O.SecureFirmwareUpdate
1211
O.SecureFirmwareUpdate is met by the following SFR:
1212
• FCS_COP.1/SigVerFW verifies the firmware update signature to ensure authenticity and
1213
integrity prior to installation.
1214
1215
6.10.8 O.Protect
1216
O.Protect is met by a combination of the following SFRs:
1217
• FDP_RIP.1 defines that the TOE shall make information unavailable as soon as it is no longer
1218
needed.
1219
• FPT_FLS.1 ensures that the TOE fails into a secure state in case of a security relevant malfunc-
1220
tion.
1221
• FPT_PHP.1 defines the requirements around the physical protection that the TOE has to pro-
1222
vide.
1223
• FPT_TST.1 defines the self-testing functionality.
1224
• FPT_TDC.1 defines the requirements that the TOE correctly interprets information about the
1225
validity of certificates and certificate lists (CTLs, CRLs).
1226
1227
6.10.9 O.Management
1228
O.Management is met by a combination of the following SFRs:
1229
• FIA_ATD.1 defines how authorised administrator might be able to define additional security
1230
attributes for users.
1231
• FIA_UAU.2 and FIA_UAU.5 define the requirements around the authentication of users.
1232
• FIA_UID.2 defines requirements around the identification of users.
1233
• FMT_MSA.1 defines the management of the security attributes.
1234
• FMT_SMF.1 defines the management functionalities that the TOE must offer.
1235
• FMT_SMR.1 defines the role concept for the TOE.
1236
1237
6.10.10 O.Log
1238
O.Log is met by a combination of the following SFRs:
1239
• FAU_GEN.1 defines the necessary audit data generation.
1240
• FAU_GEN.2 defines the corresponding user identity association.
1241
• FAU_SAR.1 defines the requirements around the audit review functions for the log and that
1242
access to them shall be limited to RAs via IF_GW_Admin only.
1243
• FAU_STG.2 defines the protection of the audit data.
1244
• FAU_STG.5 defines the requirements on what should happen if the audit log is full.
1245
• FPT_STM.1 defines the requirement on reliable time stamps.
1246
1247
6.10.11 Fulfilment of the Dependencies
1248
The following table summarises all TOE functional requirements dependencies of this PP and
1249
demonstrates that they are fulfilled.
1250
SFR Dependencies Fulfilled by
FAU_GEN.1 FPT_STM.1 Reliable Time Stamps FPT_STM.1
Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 51
on behalf of C-Roads
SFR Dependencies Fulfilled by
FAU_GEN.2 FAU_GEN.1 Audit data generation
FIA_UID.1 Timing of identification
FAU_GEN.1
FIA_UID.2
FAU_SAR.1 FAU_GEN.1 Audit data generation FAU_GEN.1
FAU_STG.2 FAU_GEN.1 Audit data generation FAU_GEN.1
FAU_STG.5 FAU_STG.2 Protected audit data storage FAU_STG.2
FCS_COP.1/AES [FDP_ITC.1 Import of user data without
security attributes, or
FDP_ITC.2 Import of user data with security
attributes, or
FCS_CKM.1 Cryptographic key generation,
or
FCS_CKM.5 Cryptographic key derivation]
FCS_CKM.3 Cryptographic key access
FCS_CKM.1/AES
2nd
dependency is not
relevant since the used
cryptographic keys are
not stored outside of the
TOE.
FCS_COP.1/Backend [FDP_ITC.1 Import of user data without
security attributes, or
FDP_ITC.2 Import of user data with security
attributes, or
FCS_CKM.1 Cryptographic key generation,
or
FCS_CKM.5 Cryptographic key derivation]
FCS_CKM.3 Cryptographic key access
FCS_CKM.1/Backend
2nd
dependency is not
relevant since it is
assumed that keys are
not stored outside the
TOE. Should
cryptographic keys be
stored outside the TOE,
it has to be modelled by
the ST author (see
Application Note 15).
FCS_COP.1/Hash [FDP_ITC.1 Import of user data without
security attributes, or
FDP_ITC.2 Import of user data with security
attributes, or
FCS_CKM.1 Cryptographic key generation,
or
FCS_CKM.5 Cryptographic key derivation]
FCS_CKM.3 Cryptographic key access
The hash algorithm
does not need any key
material. Therefore, for
this SFR, there is no
dependency on an
import or generation of
key material and a key
access.
FCS_COP.1/SigVer [FDP_ITC.1 Import of user data without
security attributes, or
FDP_ITC.2 Import of user data with security
attributes, or
FCS_CKM.1 Cryptographic key generation,
or
FCS_CKM.5 Cryptographic key derivation]
FCS_CKM.3 Cryptographic key access
1st
dependency does not
need to be fulfilled, as
there is no direct
import, generation, or
derivation of the public
key of the sender’s
certificate for the
verification of the
corresponding
messages. The
interpretation of the
Roadside ITS Station Gateway PP
52 Bundesanstalt für Straßenwesen (BASt)
on behalf of C-Roads
SFR Dependencies Fulfilled by
certificates is
performed by
FPT_TDC.1.
2nd
dependency is not
relevant since the used
cryptographic keys are
not stored outside of the
TOE.
FCS_COP.1/SigVerFW [FDP_ITC.1 Import of user data without
security attributes, or
FDP_ITC.2 Import of user data with security
attributes, or
FCS_CKM.1 Cryptographic key generation,
or
FCS_CKM.5 Cryptographic key derivation]
FCS_CKM.3 Cryptographic key access
1st
dependency needs to
be fulfilled within the
production phase of the
TOE, during the
implementation of the
corresponding key
value.
2nd
dependency is not
relevant since the used
cryptographic keys are
not stored outside of the
TOE.
FCS_CKM.1/AES [FCS_CKM.2 Cryptographic key
distribution, or
FCS_CKM.5 Cryptographic key derivation,
or
FCS_COP.1 Cryptographic operation]
FCS_CKM.3 Cryptographic key access
[FCS_RBG.1 Random bit generation, or
FCS_RNG.1 Generation of random numbers]
FCS_CKM.6 Timing and event of
cryptographic key destruction
FCS_COP.1/AES
2nd
dependency is not
relevant since the used
cryptographic keys are
not stored outside of the
TOE.
3rd
dependency is not
relevant since it is
assumed that the keys
are generated utilizing
random source of the
SE. Should another
random source be used,
it has to be modelled by
the ST author (see
Application Note 18).
FCS_CKM.6
FCS_CKM.1/Backend [FCS_CKM.2 Cryptographic key
distribution, or
FCS_CKM.5 Cryptographic key derivation,
or
FCS_COP.1 Cryptographic operation]
FCS_CKM.3 Cryptographic key access
[FCS_RBG.1 Random bit generation, or
FCS_RNG.1 Generation of random numbers]
FCS_CKM.6 Timing and event of
cryptographic key destruction
FCS_CKM.5/Backend
FCS_COP.1/Backend
2nd
dependency is not
relevant since it is
assumed that keys are
not stored outside the
TOE. Should
cryptographic keys be
stored outside the TOE,
it has to be modelled by
Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 53
on behalf of C-Roads
SFR Dependencies Fulfilled by
the ST author (see
Application Note 15).
3rd
dependency is not
relevant since it is
assumed that the keys
are generated utilizing
random source of the
SE. Should another
random source be used,
it has to be modelled by
the ST author (see
Application Note 18).
FCS_CKM.6
FCS_CKM.5/Backend [FCS_CKM.2 Cryptographic key
distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.6 Timing and event of
cryptographic key destruction
FCS_COP.1/Backend
FCS_CKM.6
FCS_CKM.6 [FDP_ITC.1 Import of user data without
security attributes, or
FDP_ITC.2 Import of user data with security
attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.1/AES
FCS_CKM.1/Backend
FDP_ACC.1 FDP_ACF.1 Security attribute-based access
control
FDP_ACF.1
FDP_ACF.1 FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialisation
FDP_ACC.1
FMT_MSA.3 does not
have to be fulfilled here
because all the defined
in ACF attributes are
static and
unchangeable. If an ST
author include any
dynamic attributes, the
author also has to model
FMT_MSA.3 (see
Application Note 20).
FDP_IFC.2 FDP_IFF.1 Simple security attributes FDP_IFF.1
Roadside ITS Station Gateway PP
54 Bundesanstalt für Straßenwesen (BASt)
on behalf of C-Roads
SFR Dependencies Fulfilled by
FDP_IFF.1 FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
FDP_IFC.2
FMT_MSA.3 does not
have to be fulfilled here,
because all in IFF
defined attributes are
static and
unchangeable. If an ST
author include any
dynamic rules, the
author also has to model
FMT_MSA.3 (see
Application Note 21).
FDP_RIP.1 - -
FIA_ATD.1 - -
FIA_UAU.2 FIA_UID.1 Timing of identification FIA_UID.2
FIA_UAU.5 - -
FIA_UID.2 - -
FMT_MSA.1 [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management
Functions
FDP_ACC.1
FMT_SMR.1
FMT_SMF.1
FMT_SMF.1 - -
FMT_SMR.1 FIA_UID.1 Timing of identification FIA_UID.2
FPT_FLS.1 - -
FPT_PHP.1 - -
FPT_RPL.1 - -
FPT_STM.1 - -
FPT_TDC.1 - -
FPT_TST.1 - -
FTP_PRO.1/Backend FTP_PRO.2 Trusted channel establishment
FTP_PRO.3 Trusted channel data protection.
FTP_PRO.2/Backend
FTP_PRO.3/Backend
FTP_PRO.1/PKI FTP_PRO.2 Trusted channel establishment
FTP_PRO.3 Trusted channel data protection.
In the defined protocol,
no shared secret is
generated for
Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 55
on behalf of C-Roads
SFR Dependencies Fulfilled by
encryption using a key
derivation function.
Therefore, FTP_PRO.2
is not used. For more
information refer to the
Hint at FTP_PRO.1/
PKI.
FTP_PRO.3/PKI
FTP_PRO.2/Backend FTP_PRO.1 Trusted channel protocol
[FCS_CKM.1 Cryptographic key generation,
or
FCS_CKM.2 Cryptographic key distribution]
FCS_CKM.5 Cryptographic key derivation
FCS_COP.1 Cryptographic operation
FTP_PRO.1/Backend
FCS_CKM.1/Backend
FCS_CKM.5/Backend
FCS_COP.1/Backend
FTP_PRO.3/Backend FTP_PRO.1 Trusted channel protocol
FTP_PRO.2 Trusted channel establishment
FCS_COP.1 Cryptographic operation.
FTP_PRO.1/Backend
FTP_PRO.2/Backend
FCS_COP.1/Backend
FTP_PRO.3/PKI FTP_PRO.1 Trusted channel protocol
FTP_PRO.2 Trusted channel establishment
FCS_COP.1 Cryptographic operation.
FTP_PRO.1/PKI
In the defined protocol,
no shared secret is
generated for
encryption using a key
derivation function.
Therefore, FTP_PRO.2
is not used. For more
information refer to the
Hint at FTP_PRO.1/
PKI.
FCS_COP.1/AES
Table 13: SFR dependencies
1251
1252
6.10.12 Security Assurance Requirements Rationale
1253
6.10.12.1 Justification for Selection of Assurance Level
1254
The main decision about the assurance level has been taken based on the assumed attackers that exist
1255
against the TOE. Many discussions and a structured threat model have shown that one can act on the
1256
assumption that the potential of the assumed attackers is only of basic potential. This lead to the selection
1257
of the component AVA_VAN.2 for vulnerability assessment. This component is contained in two
1258
evaluation assurance levels, namely EAL2 and EAL3.
1259
As the discussions around the threat model further lead to the fact that the security of the development
1260
environment and of the development processes is an important aspect for the security of the TOE, it has
1261
been decided to use EAL3 as the assurance level in this Protection Profile.
1262
6.10.12.2 Dependencies of Assurance Components
1263
The dependencies of the assurance requirements taken from EAL3 are fulfilled automatically.
1264
Roadside ITS Station Gateway PP
56 Bundesanstalt für Straßenwesen (BASt)
on behalf of C-Roads
7 Appendix
1265
7.1 Glossary & Specific Terms
1266
Term Description
AA Authorisation Authority
A CA that provides a C-ITS station with authoritative proof that it may use
specific ITS services (according to [CP]).
AES Advanced Encryption Standard
Application Note Application Note
An application note defines the restrictions and requirements that shall be
performed by the ST author.
CA Certificate Authority or Certification Authority
An entity that issues digital certificates.
CAM Cooperative Awareness Messages
CCM Counter with Cipher Block Chaining-Message Authentication Code
C-ITS Cooperative ITS
C-ITS Station C-ITS Station
A set of hardware and software components required to collect, store,
process, receive and transmit secured and trusted messages in order to
enable the provision of a C-ITS service. This includes personal, central,
vehicle and roadside ITS stations as defined in [ETSI EN 302 665].
C-ITS-S Central ITS Station
Fixed control station with network connection to R-ITS-S, potentially
connecting to further (backend) systems.
CP Certificate Policy, also see [CP]
CRL Certificate Revocation List
CTL Certificate Trust List
DENM Decentralised Environmental Notification Message
EA Enrolment Authority
A CA that authenticates a C-ITS station and grants it access to ITS
communications (according to [CP]).
EAL Evaluation Assurance Level
ECC Elliptic Curve Cryptography
ECDSA Elliptic Curve Digital Signature Algorithm
Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 57
on behalf of C-Roads
Term Description
ECIES Elliptic Curve Integrated Encryption Scheme
GNSS Global Navigation Satellite System
The system can be used for providing position, navigation or for tracking
the position of something fitted with a receiver.
GSM Global System for Mobile Communications
Hint Hint
Hints are intended to help the reader of the PP to gain a further
understanding. In addition, they contain rationales of the PP author.
IEEE Institute of Electrical and Electronics Engineers
IPsec Internet Protocol Security
IPsec extends the Internet Protocol (IP) with encryption and authentication
mechanisms. It is specified in [RFC4301], among others.
ISMS Information Security Management System
ITS Intelligent Transport Systems
Advanced application which, without embodying intelligence as such, aims
to provide innovative services relating to different modes of transport and
traffic management and enable users to be better informed and make safer,
more coordinated, and ‘smarter’ use of transport networks.
ITS-G5 ITS-G5
Intelligent Transport Systems operating in the 5 GHz frequency band.
ITS-M ITS-Messages
Collective term for all messages and message formats used in the C-ITS
context.
ITS-S Intelligent Transportation Systems – Station
Station within the C-ITS context. Covering the following station types:
• C-ITS-S (Central ITS Station),
• P-ITS-S (Personal ITS Station),
• R-ITS-S (Roadside ITS Station), and
• V-ITS-S (Vehicle ITS Station).
IVIM In Vehicle Information Message
LAN Local Area Network
LTE Long Term Evolution
MAPEM MAP Extended Message
NIST National Institute of Standards and Technology
Roadside ITS Station Gateway PP
58 Bundesanstalt für Straßenwesen (BASt)
on behalf of C-Roads
Term Description
PII Personally Identifiable Information
PII refers to information that can be used to uniquely identify, contact, or
locate a single person or can be used with other sources to uniquely identify
a single individual.
PP Protection Profile
PKI Public Key Infrastructure
A PKI is a set of roles, policies, and procedures needed to create, manage,
distribute, use, store & revoke digital certificates and manage public-key
encryption. In the context of this PP, the term refers to a PKI according to
the [CP].
RA Roadside ITS Station Administrator
RGW Roadside ITS Station Gateway
R-ITS-S Roadside ITS Station
ITS computing platform, including the TOE (RGW), a communication and
processing capacity, linked to road infrastructure.
RNG Random Number Generation
RTC Real Time Clock
SE Secure Element
A security device utilised by the gateway for cryptographic operations.
SFP Security Function Policies
SFR Security Functional Requirement
SOC Security Operations Center
A SOC has the task of detecting threats at an early stage and reacting to
them. This can be set up within the organisation itself or be outsourced.
SP Security Policy, also see [SP]
SPD Security Problem Definition
SPATEM Signal Phase And Timing Extended Message
SSEM Signal request Status Extended Message
SSH Secure Shell
SSH is a network protocol for secure remote login and other secure
network services over an insecure network. This protocol is specified in
[RFC4254], among others.
ST Security Target
Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 59
on behalf of C-Roads
Term Description
TCC Traffic Control Center
TLM Trust List Manager
Role according to [CP]
TLS Transport Layer Security
TLS is a protocol used to encrypt, verify and authenticate communication
in a network. This protocol is specified in [RFC8446].
TOE Target of Evaluation
TSF TOE Security Functionality
TSFI TSF Interface
UMTS Universal Mobile Communications System
V-ITS-S Vehicle ITS Station
ITS computing platform, communication, and processing capacity, linked to
a vehicle.
WAN Wide Area Network
Table 14: Glossary & specific terms
1267
1268
Roadside ITS Station Gateway PP
60 Bundesanstalt für Straßenwesen (BASt)
on behalf of C-Roads
7.2 References
1269
[CC] Common Criteria for Information Technology Security Evaluation,
consisting of:
• Part 1: Introduction and general model, November 2022, Version
CC:2022, Revision 1
• Part 2: Security functional requirements, November 2022, Version
CC:2022, Revision 1
• Part 3: Security assurance requirements, November 2022, Version
CC:2022, Revision 1
• Part 4: Framework for the specification of evaluation methods and
activities, November 2022, Version CC:2022, Revision 1
• Part 5: Pre-defined packages of security requirements, November 2022,
Version CC:2022, Revision 1
URL: https://www.commoncriteriaportal.org/cc/
[CP] C-ITS Certificate Policy, current version from
https://cpoc.jrc.ec.europa.eu/Documentation.html
[CSP-PP] Protection Profile “Cryptographic Service Provider (CSP)”, version 0.9.8,
BSI-CC-PP-0104-2020, February 2020
[ETSI EN 302 663] ETSI EN 302 663, Intelligent Transport Systems (ITS); ITS-G5 Access layer
specification for Intelligent Transport Systems operating in the 5 GHz
frequency band, current version
[ETSI EN 302 665] ETSI EN 302 665, Intelligent Transport Systems (ITS); Communications
Architecture, current version
[ETSI TS 102 941] ETSI TS 102 941, Intelligent Transport Systems (ITS); Security; Trust and
Privacy Management, current version
[ETSI TS 103 097] ETSI TS 103 097, Intelligent Transport Systems (ITS); Security; Security
header and certificate formats, current version
[FIPS 180-4] FIPS PUB 180-4, Secure Hash Standard (SHS), August 2015
[FIPS 186-4] FIPS PUB 186-4, Digital Signature Standard (DSS), July 2013
[FIPS 197] FIPS 197, Advanced Encryption Standard (AES), November 2001
[IEEE 1609.2] IEEE Std 1609.2™-2022 IEEE Standard for Wireless Access in Vehicular
Environments - Security Services for Applications and Management
Messages, March 2023
[ISO27001] ISO/IEC 27001:2022: Information security, cybersecurity and privacy
protection – Information security management systems – Requirements,
edition 3, October 2022
[NIST SP 800-38C] NIST Special Publication 800-38C, Recommendation for Block Cipher
Modes of Operation: The CCM Mode forAuthentication and Confidentiality,
July 2007
[RFC4254] RFC 4254, The Secure Shell (SSH) Connection Protocol, January 2006
[RFC4301] RFC 4301, Security Architecture for the Internet Protocol, December 2005
Roadside ITS Station Gateway PP
Bundesanstalt für Straßenwesen (BASt) 61
on behalf of C-Roads
[RFC5639] RFC 5639, Elliptic Curve Cryptography (ECC) Brainpool Standard Curves
and Curve Generation, March 2010
[RFC8446] RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3,
August 2018
[SE-PP] Protection Profile “V2X Hardware Security Module by CAR 2 CAR
Communication Consortium”, version 1.0.1, BSI-CC-PP-0114-2021,
November 2021
[SecReq] “C-ITS Security Requirements & Specifications” issued by C-Roads, current
version, https://www.c-roads.eu
[SP] C-ITS Security Policy, current version from
https://cpoc.jrc.ec.europa.eu/Documentation.html
[TR-02102-1] Technical Guideline TR-02102-1 Cryptographic Mechanisms:
Recommendations and Key Lengths, current version
[TR-02102-2] Technical Guideline TR-02102-2 Cryptographic Mechanisms:
Recommendations and Key Lengths, Part 2 – Use of Transport Layer
Security (TLS), current version
[TR-02102-3] Technical Guideline TR-02102-3 Cryptographic Mechanisms:
Recommendations and Key Lengths, Part 3 – Use of Internet Protocol
Security (IPsec) and Internet Key Exchange (IKEv2), current version
[TR-02103-4] Technical Guideline TR-02102-4 Cryptographic Mechanisms:
Recommendations and Key Lengths, Part 4 – Use of Secure Shell (SSH),
current version
1270