Security Target
1
2
SMGW Integrationsmodul Version 1.0
3
4
Version Date Author Comments
2.9 29.10.2018 Stefan Dörpinghaus Corrections according to final comments by the
certification body
5
Security Target, SMGW Integrationsmodul Version 1.0
Page 2
Contents
6
Contents .................................................................................................................................................. 2
7
1 Introduction..................................................................................................................................... 7
8
1.1 ST and TOE reference................................................................................................................. 7
9
1.2 TOE reference............................................................................................................................. 7
10
1.3 Introduction.............................................................................................................................. 10
11
1.4 TOE Overview........................................................................................................................... 11
12
1.4.1 Introduction.................................................................................................................... 11
13
1.4.2 Overview of the Gateway in a Smart Metering System................................................. 12
14
1.4.3 TOE description .............................................................................................................. 16
15
1.4.4 TOE Type definition ........................................................................................................ 17
16
1.4.5 TOE logical boundary...................................................................................................... 20
17
1.4.6 The logical interfaces of the TOE.................................................................................... 30
18
1.4.7 The cryptography of the TOE and its Security Module .................................................. 31
19
1.4.8 TOE life-cycle .................................................................................................................. 36
20
2 Conformance Claims ..................................................................................................................... 37
21
2.1 CC Conformance Claim............................................................................................................. 37
22
2.2 PP Claim / Conformance Statement......................................................................................... 37
23
2.3 Package Claim........................................................................................................................... 37
24
2.4 Conformance Claim Rationale.................................................................................................. 37
25
3 Security Problem Definition .......................................................................................................... 38
26
3.1 External entities ....................................................................................................................... 38
27
3.2 Assets ....................................................................................................................................... 38
28
Security Target, SMGW Integrationsmodul Version 1.0
Page 3
3.3 Assumptions............................................................................................................................. 41
29
3.4 Threats...................................................................................................................................... 43
30
3.5 Organizational Security Policies ............................................................................................... 46
31
4 Security Objectives........................................................................................................................ 49
32
4.1 Security Objectives for the TOE................................................................................................ 49
33
4.2 Security Objectives for the Operational Environment............................................................. 55
34
4.3 Security Objective Rationale .................................................................................................... 57
35
4.3.1 Overview......................................................................................................................... 57
36
4.3.2 Countering the threats ................................................................................................... 58
37
4.3.3 Coverage of organisational security policies.................................................................. 62
38
4.3.4 Coverage of assumptions ............................................................................................... 63
39
5 Extended Component definition................................................................................................... 65
40
5.1 Communication concealing (FPR_CON) ................................................................................... 65
41
5.2 Family behaviour...................................................................................................................... 65
42
5.3 Component levelling ................................................................................................................ 65
43
5.4 Management............................................................................................................................ 65
44
5.5 Audit......................................................................................................................................... 65
45
5.6 Communication concealing (FPR_CON.1)................................................................................ 66
46
6 Security Requirements .................................................................................................................. 67
47
6.1 Overview .................................................................................................................................. 67
48
6.2 Class FAU: Security Audit ......................................................................................................... 69
49
6.2.1 Introduction.................................................................................................................... 69
50
6.2.2 Security Requirements for the System Log .................................................................... 71
51
Security Target, SMGW Integrationsmodul Version 1.0
Page 4
6.2.3 Security Requirements for the Consumer Log ............................................................... 73
52
6.2.4 Security Requirements for the Calibration Log .............................................................. 75
53
6.2.5 Security Requirements that apply to all logs.................................................................. 79
54
6.3 Class FCO: Communication....................................................................................................... 81
55
6.3.1 Non-repudiation of origin (FCO_NRO) ........................................................................... 81
56
6.4 Class FCS: Cryptographic Support ............................................................................................ 82
57
6.4.1 Cryptographic support for TLS........................................................................................ 82
58
6.4.2 Cryptographic support for CMS...................................................................................... 83
59
6.4.3 Cryptographic support for Meter communication encryption ...................................... 85
60
6.4.4 General Cryptographic support...................................................................................... 86
61
6.5 Class FDP: User Data Protection............................................................................................... 88
62
6.5.1 Introduction to the Security Functional Policies ............................................................ 88
63
6.5.2 Gateway Access SFP ....................................................................................................... 89
64
6.5.3 Firewall SFP..................................................................................................................... 91
65
6.5.4 Meter SFP ....................................................................................................................... 93
66
6.5.5 General Requirements on user data protection ............................................................ 96
67
6.6 Class FIA: Identification and Authentication............................................................................ 97
68
6.6.1 User Attribute Definition (FIA_ATD)............................................................................... 97
69
6.6.2 Authentication Failures (FIA_AFL).................................................................................. 97
70
6.6.3 User Authentication (FIA_UAU)...................................................................................... 98
71
6.6.4 User identification (FIA_UID).......................................................................................... 99
72
6.6.5 User-subject binding (FIA_USB).................................................................................... 100
73
6.7 Class FMT: Security Management.......................................................................................... 101
74
Security Target, SMGW Integrationsmodul Version 1.0
Page 5
6.7.1 Management of the TSF ............................................................................................... 101
75
6.7.2 Security management roles (FMT_SMR)...................................................................... 105
76
6.7.3 Management of security attributes for Gateway access SFP....................................... 106
77
6.7.4 Management of security attributes for Firewall SFP.................................................... 107
78
6.7.5 Management of security attributes for Meter SFP ...................................................... 108
79
6.8 Class FPR: Privacy ................................................................................................................... 109
80
6.8.1 Communication Concealing (FPR_CON)....................................................................... 109
81
6.8.2 Pseudonymity (FPR_PSE).............................................................................................. 109
82
6.9 Class FPT: Protection of the TSF............................................................................................. 110
83
6.9.1 Fail secure (FPT_FLS) .................................................................................................... 110
84
6.9.2 Replay Detection (FPT_RPL) ......................................................................................... 111
85
6.9.3 Time stamps (FPT_STM)............................................................................................... 111
86
6.9.4 TSF self test (FPT_TST).................................................................................................. 111
87
6.9.5 TSF physical protection (FPT_PHP)............................................................................... 112
88
6.10 Class FTP: Trusted path/channels ....................................................................................... 112
89
6.10.1 Inter-TSF trusted channel (FTP_ITC)............................................................................. 112
90
6.11 Security Assurance Requirements for the TOE................................................................... 114
91
6.12 Security Requirements rationale ........................................................................................ 115
92
6.12.1 Security Functional Requirements rationale................................................................ 115
93
6.12.2 Security Assurance Requirements rationale ................................................................ 125
94
7 TOE Summary Specification ........................................................................................................ 127
95
7.1 SF.1: Authentication of Communication and Role Assignment for external entities ............ 127
96
Security Target, SMGW Integrationsmodul Version 1.0
Page 6
7.2 SF.2: Acceptance and Deposition of Meter Data, Encryption of Meter Data for WAN
97
transmission .................................................................................................................................... 134
98
7.3 SF.3: Administration, Configuration and SW Update............................................................. 137
99
7.4 SF.4: Displaying Consumption Data ....................................................................................... 139
100
7.5 SF.5: Audit and Logging.......................................................................................................... 140
101
7.6 SF.6: TOE Integrity Protection................................................................................................ 143
102
7.7 TSS Rationale.......................................................................................................................... 144
103
8 List of Tables................................................................................................................................ 147
104
9 List of Figures............................................................................................................................... 148
105
10 Appendix.................................................................................................................................... 149
106
10.1 Mapping from English to German terms ............................................................................ 149
107
10.2 Glossary............................................................................................................................... 150
108
11 Literature................................................................................................................................... 153
109
110
Security Target, SMGW Integrationsmodul Version 1.0
Page 7
1 Introduction
111
1.1 ST and TOE reference
112
Title: Security Target, SMGW Integrationsmodul Version 1.0
113
Sponsors: OpenLimit SignCubes AG, Power Plus Communications AG
114
Editors: OpenLimit SignCubes AG, Power Plus Communications AG
115
CC-Version: 3.1 Revision 4
116
Assurance Level: EAL 4+, augmented by AVA_VAN.5 and ALC_FLR.2
117
General Status: Final
118
Document Version: 2.9
119
Document Date: 29.10.2018
120
TOE: SMGW Integrationsmodul Version 1.0
121
Certification ID: BSI-DSZ-CC-0831
122
This document contains the security target of the SMGW Integrationsmodul Version 1.0.
123
This security target claims conformance to the Smart Meter Gateway protection profile
124
[PP_GW].
125
1.2 TOE reference
126
The TOE described in this security target is the SMGW Integrationsmodul Version 1.0.
127
The TOE is part of the device “Smart Meter Gateway” and consists of “SMGW
128
Integrationsmodul Software Version 1.0” and “SMGW Integrationsmodul Hardware Version
129
1.0” where the latter can be identified as “SMGW-B-1A-111-00”, “SMGW-L-1A-111-30”,
130
“SMGW-G-1A-111-30” or “SMGW-E-1A-111-00” according to Table 1.
131
The TOE comprises the following parts:
132
• hardware device “SMGW Integrationsmodul Hardware Version 1.0”, including the
133
TOE’s main circuit board, a carrier board, a power-supply unit and a radio module for
134
Security Target, SMGW Integrationsmodul Version 1.0
Page 8
communication with wireless meter (included in the hardware device “Smart Meter
135
Gateway”)
136
• software application SMGW Integrationsmodul Software Version 1.0” (loaded into
137
the circuit board “SMGW Integrationsmodul Hardware Version 1.0”), identified by
138
the value 26533-26663 which comprises of two revision numbers of the underlying
139
version control system for the TOE, where the first part is for the operating system
140
and the second part is for the SMGW application
141
• manuals
142
o Handbuch für Verbraucher, SMGW Integrationsmodul Version 1.0
143
[AGD_Consumer], identified by the SHA-256 hash value
144
6e0d80bbd3371972434092c86a0878e37bba921a8589871e85cbb7caf085a8
145
b0
146
o Handbuch für Service-Techniker, SMGW Integrationsmodul Version 1.0,
147
[AGD_Techniker], identified by the SHA-256 hash value
148
c23b14ea0a05e381bfe2b3e407d6f9deeddbf1733b720da5f6f13a502a0e4122
149
o Handbuch für Hersteller von Smart-Meter Gateway-Administrations-
150
Software, SMGW Integrationsmodul Version 1.0 [AGD_GWA], identified by
151
the SHA-256 hash value
152
8402082a2d95a8c063919e3e7b776c75434a25dff19450f055e06926e01e170
153
e
154
o Auslieferungs- und Fertigungsprozeduren, Anhang Sichere Auslieferung,
155
SMGW Integrationsmodul Version 1.0 [AGD_SEC], identified by the SHA-256
156
hash value
157
c46746193ead2563064ba4631f185b833a6e37ede6c1485603b78ef2ffa90061
158
The hardware device “Smart Meter Gateway” includes a hard-wired communication adapter
159
which is not part of the TOE but which is always an inseparable part of the delivered entity.
160
This communication adapter can be either a LTE communication adapter, a BPL
161
Security Target, SMGW Integrationsmodul Version 1.0
Page 9
communication adapter, a GPRS communication adapter or an ethernet communication
162
adapter.
163
The following table shows the different TOE product classifications applied on the case of the
164
TOE:
165
# Characteristic Value Description
1 Product family SMGW each classification of a type start with this value
2 - Delimiter
3 Communication
Technology
E Ethernet
B Product Type „BPL Smart Meter Gateway“
G Product Type „GPRS Smart Meter Gateway“
L Product Type „LTE Smart Meter Gateway“
4 - Delimiter
5 Product
generation
1A Identification of product generation; version 1.0 of main
circuit board “SMGW Integrationsmodul Hardware”
6 - Delimiter
7 HAN Interface 1 Ethernet
8 CLS Interface 1 Ethernet
9 LMN Interface 1 Wireless and wired
10 - Delimiter
11 SIM card type 0 none
3 SIM slot only
12 reserved 0
Table 1: TOE product classifications
166
Security Target, SMGW Integrationsmodul Version 1.0
Page 10
1.3 Introduction
167
The increasing use of green energy and upcoming technologies around e-mobility lead to an
168
increasing demand for functions of a so called smart grid. A smart grid hereby refers to a
169
commodity
1
network that intelligently integrates the behaviour and actions of all entities
170
connected to it – suppliers of natural resources and energy, its consumers and those that are
171
both – in order to efficiently ensure a more sustainable, economic and secure supply of a
172
certain commodity (definition adopted from [CEN]).
173
In its vision such a smart grid would allow to invoke consumer devices to regulate the load
174
and availability of resources or energy in the grid, e.g. by using consumer devices to store
175
energy or by triggering the use of energy based upon the current load of the grid2. Basic
176
features of such a smart use of energy or resources are already reality. Providers of electricity
177
in Germany, for example, have to offer at least one tariff that has the purpose to motivate
178
the consumer to save energy.
179
In the past, the production of electricity followed the demand/consumption of the
180
consumers. Considering the strong increase in renewable energy and the production of
181
energy as a side effect in heat generation today, the consumption/demand has to follow the
182
– often externally controlled – production of energy. Similar mechanisms can exist for the gas
183
network to control the feed of biogas or hydrogen based on information submitted by
184
consumer devices.
185
An essential aspect for all considerations of a smart grid is the so called Smart Metering
186
System that meters the consumption or production of certain commodities at the
187
consumers’ side and allows sending the information about the consumption or production to
188
external entities, which is then the basis for e. g. billing the consumption or production.
189
1 Commodities can be electricity, gas, water or heat which is distributed from its generator to the consumer through a grid
(network).
2 Please note that such a functionality requires a consent or a contract between the supplier and the consumer, alternatively a
regulatory requirement.
Security Target, SMGW Integrationsmodul Version 1.0
Page 11
This Security Target defines the security objectives, corresponding requirements and their
190
fulfilment for a Gateway which is the central communication component of such a Smart
191
Metering System (please refer to chapter 1.4.2 for a more detailed overview).
192
The Target of Evaluation (TOE) that is described in this document is an electronic unit
193
comprising hardware and software/firmware3 used for collection, storage and provision of
194
Meter Data4 from one or more Meters of one or multiple commodities.
195
The Gateway connects a Wide Area Network (WAN) with a Network of Devices of one or
196
more Smart Metering devices (Local Metrological Network, LMN) and the consumer Home
197
Area Network (HAN), which hosts Controllable Local Systems (CLS) and visualization devices.
198
The security functionality of the TOE comprises
199
• protection of confidentiality, authenticity, integrity of data and
200
• information flow control
201
mainly to protect the privacy of consumers, to ensure a reliable billing process and to protect
202
the Smart Metering System and a corresponding large scale infrastructure of the smart grid.
203
The availability of the Gateway is not addressed by this ST.
204
1.4 TOE Overview
205
1.4.1 Introduction
206
The TOE as defined in this Security Target is the Gateway in a Smart Metering System. In the
207
following subsections the overall Smart Metering System will be described first and
208
afterwards the Gateway itself.
209
There are various different vocabularies existing in the area of Smart Grid, Smart Metering
210
and Home Automation. Furthermore, the Common Criteria maintain their own vocabulary.
211
3 For the rest of this document the term “firmware” will be used.
4 Please refer to chapter 3.2 for an exact definition of the term "Meter Data”.
Security Target, SMGW Integrationsmodul Version 1.0
Page 12
The Protection Profile [PP_GW, chapter 1.3] provides an overview over the most prominent
212
terms used in this Security Target to avoid any bias which is not fully repeated here.
213
1.4.2 Overview of the Gateway in a Smart Metering System
214
The following figure provides an overview of the TOE as part of a complete Smart Metering
215
System from a purely functional perspective as used in this ST.5
216
217
Figure 1: The TOE and its direct environment
218
219
5 It should be noted that this description purely contains aspects that are relevant to motivate and understand the functionalities of
the Gateway as described in this ST. It does not aim to provide a universal description of a Smart Metering System for all
application cases.
Security Target, SMGW Integrationsmodul Version 1.0
Page 13
As can be seen in Figure 1, a system for smart metering comprises different functional units
220
in the context of the descriptions in this ST:
221
• The Gateway (as defined in this ST) serves as the communication component
222
between the components in the LAN of the consumer and the outside world. It can
223
be seen as a special kind of firewall dedicated to the smart metering functionality. It
224
also collects, processes and stores the records from Meter(s) and ensures that only
225
authorised parties have access to them or derivatives thereof. Before sending meter
226
data6 the information will be encrypted and signed using the services of a Security
227
Module. The Gateway features a mandatory user interface, enabling authorised
228
consumers to access the data relevant to them.
229
• The Meter itself records the consumption or production of one or more commodities
230
(e.g. electricity, gas, water, heat) and submits those records in defined intervals to
231
the Gateway. The Meter Data has to be signed and encrypted before transfer in
232
order to ensure its confidentiality, authenticity, and integrity. The Meter is
233
comparable to a classical meter7 and has comparable security requirements; it will
234
be sealed as classical meters according to the regulations of the calibration authority.
235
The Meter further supports the encryption and integrity protection of its connection
236
to the Gateway8.
237
• The Gateway utilises the services of a Security Module (e.g. a smart card) as a
238
cryptographic service provider and as a secure storage for confidential assets. The
239
Security Module will be evaluated separately according to the requirements in the
240
corresponding Protection Profile (c.f. [SecModPP]).
241
Controllable Local Systems (CLS, as shown in Figure 2) may range from local power
242
generation plants, controllable loads such as air condition and intelligent household
243
6 Please note that readings and data which are not relevant for billing may require an explicit endorsement of the consumer.
7 In this context, a classical meter denotes a meter without a communication channel, i.e. whose values have to be read out locally.
8 It should be noted that this ST does not imply that the connection between the Gateways and external components (specifically
meters and CLS) is cable based. It is also possible that the connections as shown in Figure 1 are realised deploying a wireless
technology. However, the requirements on how the connections shall be secured apply regardless of the realisation.
Security Target, SMGW Integrationsmodul Version 1.0
Page 14
appliances (“white goods”) to applications in home automation. CLS may utilise the services
244
of the Gateway for communication services. However, CLS are not part of the Smart
245
Metering System.
246
The following figure introduces the external interfaces of the TOE and shows the cardinality
247
of the involved entities. Please note that the arrows of the interfaces within the Smart
248
Metering System as shown in Figure 2 indicate the flow of information. However, it does not
249
indicate that a communication flow can be initiated bi-directionally. Indeed, the following
250
chapters of this ST will place dedicated requirements on the way an information flow can be
251
initiated9.
252
9 Please note that the cardinality of the interface to the consumer is 0...n as it cannot be assumed that a consumer is interacting
with the TOE at all.
Security Target, SMGW Integrationsmodul Version 1.0
Page 15
253
Figure 2: The logical interfaces of the TOE
254
The overview of the Smart Metering System as described before is based on a threat model
255
that has been developed for the Smart Metering System and has been motivated by the
256
following considerations:
257
• The Gateway is the central communication unit in the Smart Metering System. It
258
shall be the only unit directly connected to the WAN, to be the first line of defence
259
an attacker located in the WAN would have to conquer.
260
Security Target, SMGW Integrationsmodul Version 1.0
Page 16
• The Gateway is the central component that collects, processes and stores Meter
261
Data. It therewith is the primary point for user interaction in the context of the Smart
262
Metering System.
263
• To conquer a Meter in the LMN or CLS in the HAN (that uses the TOE for
264
communication) a WAN attacker first would have to attack the Gateway successfully.
265
All data transferred between LAN and WAN flows via the Gateway which makes it an
266
ideal unit for implementing significant parts of the system's overall security
267
functionality.
268
• Because a Gateway can be used to connect and protect multiple Meters (while a
269
Meter will always be connected to exactly one Gateway) and CLS with the WAN,
270
there might be more Meters and CLS in a Smart Metering System than there are
271
Gateways.
272
All these arguments motivated the approach to have a Gateway (using a Security Module for
273
cryptographic support), which is rich in security functionality, strong and evaluated in depth,
274
in contrast to a Meter which will only deploy a minimum of security functions. The Security
275
Module will be evaluated separately.
276
1.4.3 TOE description
277
The Smart Metering Gateway (in the following short: Gateway or TOE) may serve as the
278
communication unit between devices of private and commercial consumers and service
279
providers of a commodity industry (e.g. electricity, gas, water, etc.). It also collects, processes
280
and stores Meter Data and is responsible for the distribution of this data to external entities.
281
Typically, the Gateway will be placed in the household or premises of the consumer10 of the
282
commodity and enables access to local Meter(s) (i.e. the unit(s) used for measuring the
283
consumption or production of electric power, gas, water, heat etc.) and may enable access to
284
10 Please note that it is possible that the consumer of the commodity is not the owner of the premises where the Gateway will be
placed. However, this description acknowledges that there is a certain level of control over the physical access to the Gateway.
Security Target, SMGW Integrationsmodul Version 1.0
Page 17
Controllable Local Systems (e.g. power generation plants, controllable loads such as air
285
condition and intelligent household appliances). Service providers in the context of the
286
Gateway are the Gateway Operator, Meter Operator, Grid Operator, Commodity Supplier
287
and others as introduced in chapter 3.1.
288
The TOE has a fail-safe design that specifically ensures that any malfunction can not impact
289
the delivery of a commodity, e.g. energy, gas or water11.
290
1.4.4 TOE Type definition
291
At first, the TOE is a communication Gateway. It provides different external communication
292
interfaces and enables the data communication between these interfaces and connected IT
293
systems. It further collects, processes and stores Meter Data and is responsible for the
294
distribution of this data to external parties.
295
Typically, the Gateway will be placed in the household or premises of the consumer of the
296
commodity and enables access to local Meter(s) (i.e. the unit(s) used for measuring the
297
consumption or production of electric power, gas, water, heat etc.) and may enable access to
298
Controllable Local Systems (e.g. power generation plants, controllable loads such as air
299
condition and intelligent household appliances). Roles respectively External Entities in the
300
context of the TOE are introduced in chapter 3.1.
301
The TOE described in this ST is a product that has been developed in partnership between
302
Power Plus Communication AG and OpenLimit SignCubes AG. It is a communication product
303
which complies with the requirements of the Protection Profile “Protection Profile for the
304
Gateway of a Smart Metering System” [PP_GW]. Moreover, the TOE postulates compliance
305
to the technical guideline [TR-03109] which is not part of this security evaluation and
306
11 Indeed, this Security Target assumes that the Gateway and the Meters have no possibility at all to impact the delivery of a
commodity. Even an intentional stop of the delivery of a certain commodity is Not within the scope of this Security Target. It
should, however, be noted that such a functionality may be realised by a CLS that utilises the services of the TOE for its
communication.
Security Target, SMGW Integrationsmodul Version 1.0
Page 18
certification12. The basis for this conformity check will be the functional and security related
307
tests performed during the security evaluation. The TOE consists of hardware and software
308
including the operating system. The communication with more than one meter is possible.
309
The TOE is implemented as a separate physical module which can be integrated into more
310
complex modular systems. This means that the TOE can be understood as an OEM module
311
which provides all required physical interfaces and protocols on well defined interfaces.
312
Because of this, the module can be integrated into communication devices and directly into
313
meters.
314
The TOE-design includes the following components:
315
• The security relevant components compliant to the Protection Profile.
316
• Components with no security relevance (e.g. communication protocols and
317
interfaces).
318
The TOE evaluation does not include the evaluation of the Security Module. In fact, the TOE
319
relies on the security functionality of the Security Module but it must be security evaluated in
320
a separate security evaluation13.
321
The hardware platform of the TOE mainly consists of a suitable embedded CPU, volatile and
322
non-volatile memory and supporting circuits like Security Module and RTC.
323
The TOE contains mechanisms for the integrity protection for its firmware, operating system
324
and software layers.
325
The TOE supports the following communication protocols:
326
• OBIS according to [IEC-62056-6-1] and [EN 13757-1],
327
• DLMS/COSEM according to [IEC-62056-6-2],
328
• SML according to [IEC-62056-5-3-8],
329
12 The TOE only supports wireless meter in operational mode S1 and T1 and the SML commands SML_PublicOpen.*,
SML_PublicClose.*, SML_GetProcParameter.*, SML_SetProcParameter.Req with parameters serverId, parameterTreePath,
parameterTree only, and SML_Attention.Res.
13 Please note that the Security Module is physically integrated into the Gateway even though it is not part of the TOE.
Security Target, SMGW Integrationsmodul Version 1.0
Page 19
• unidirectional and bidirectional wireless M-Bus according to [EN 13757-3],
330
[EN 13757-4], and [IEC-62056-21].
331
The TOE provides the following physical interfaces for communication
332
• Wireless M-Bus (LMN) according to [EN 13757-3],
333
• RS-485 (LMN) according to [EIA RS-485],
334
• Ethernet (HAN) according to [IEEE 802.3], and
335
• RMII (WAN) according to [IEEE 802.3].
336
The physical interface for the WAN communication is the RMII (Reduced Media Independent
337
Interface) interface. The communication is protected according to [TR-03109].
338
The communication into the HAN is also provided by the Ethernet interface. The protocols
339
HTTPS and TLS proxy are therefore supported.
340
341
Figure 3: The TOE’s protocol stack
342
The TOE provides the following functionality:
343
• Protected handling of Meter Data compliant to [PP_GW, chapter 1.4.6.1 and 1.4.6.2]
344
Security Target, SMGW Integrationsmodul Version 1.0
Page 20
• Integrity and authenticity protection e. g. of Meter Data compliant to [PP_GW,
345
chapter 1.6.4.3]
346
• Protection of LAN devices against access from the WAN compliant to [PP_GW,
347
chapter 1.4.6.4]
348
• Wake-Up Service compliant to [PP_GW, chapter 1.4.6.5]
349
• Privacy protection compliant to [PP_GW, chapter 1.4.6.6]
350
• Management of Security Functions compliant to [PP_GW, chapter 1.4.6.7]
351
• Cryptography of the TOE and its Security Module compliant to [PP_GW, chapter
352
1.4.8]
353
1.4.5 TOE logical boundary
354
The logical boundary of the Gateway can be defined by its security features:
355
• Handling of Meter Data, collection and processing of Meter Data, submission to
356
authorised external entities (e.g. one of the service providers involved) where
357
necessary protected by a digital signature
358
• Protection of authenticity, integrity and confidentiality of data temporarily or
359
persistently stored in the Gateway, transferred locally within the LAN and transferred
360
in the WAN (between Gateway and authorised external entities)
361
• Firewalling of information flows to the WAN and information flow control among
362
Meters, Controllable Local Systems and the WAN
363
• A Wake-Up-Service that allows to contact the TOE from the WAN side
364
• Privacy preservation
365
• Management of Security Functionality
366
• Identification and Authentication of TOE users
367
The following sections introduce the security functionality of the TOE in more detail.
368
Security Target, SMGW Integrationsmodul Version 1.0
Page 21
1.4.5.1 Handling of Meter Data14
369
The Gateway is responsible for handling Meter Data. It receives the Meter Data from the
370
Meter(s), processes it, stores it and submits it to external entities.
371
The TOE utilises Processing Profiles to determine which data shall be sent to which
372
component or external entity. A Processing Profile defines:
373
• how Meter Data must be processed,
374
• which processed Meter Data must be sent in which intervals,
375
• to which component or external entity,
376
• signed using which key material,
377
• encrypted using which key material,
378
• whether processed Meter Data shall be pseudonymised or not, and
379
• which pseudonym shall be used to send the data.
380
The Processing Profiles are not only the basis for the security features of the TOE; they also
381
contain functional aspects as they indicate to the Gateway how the Meter Data shall be
382
processed. More details on the Processing Profiles can be found in [TR-03109-1].
383
The Gateway restricts access to (processed) Meter Data in the following ways:
384
• consumers must be identified and authenticated first before access to any data may
385
be granted,
386
• the Gateway accepts Meter Data from authorised Meters only,
387
• the Gateway sends processed Meter Data to correspondingly authorised external
388
entities only.
389
The Gateway accepts data (e.g. configuration data, firmware updates) from correspondingly
390
authorised Gateway Administrators or correspondingly authorised external entities only. This
391
restriction is a prerequisite for a secure operation and therewith for a secure handling of
392
14 Please refer to chapter 3.2 for an exact definition of the various data types.
Security Target, SMGW Integrationsmodul Version 1.0
Page 22
Meter Data. Further, the Gateway maintains a calibration log with all relevant events that
393
could affect the calibration of the Gateway.
394
These functionalities:
395
• prevent that the Gateway accepts data from or sends data to unauthorised entities,
396
• ensure that only the minimum amount of data leaves the scope of control of the
397
consumer,
398
• preserve the integrity of billing processes and as such serve in the interests of the
399
consumer as well as in the interests of the supplier. Both parties are interested in an
400
billing process that ensures that the value of the consumed amount of a certain
401
commodity (and only the used amount) is transmitted,
402
• preserve the integrity of the system components and their configurations.
403
The TOE offers a local interface to the consumer (see also IF_GW_CON in Figure 2) and allows
404
the consumer to obtain information via this interface. This information comprises the billing-
405
relevant data (to allow the consumer to verify an invoice) and information about which
406
Meter Data has been and will be sent to which external entity. The TOE ensures that the
407
communication to the consumer is protected by using TLS and ensures that consumers only
408
get access to their own data. Therefore, the TOE contains a web server that delivers the
409
content to the web browser after successful authentication of the user.
410
1.4.5.2 Confidentiality protection
411
The TOE protects data from unauthorised disclosure
412
• while received from a Meter via the LMN,
413
• while received from the administrator via the WAN,
414
• while temporarily stored in the volatile memory of the Gateway,
415
• while transmitted to the corresponding external entity via the WAN or HAN.
416
Furthermore, all data, which no longer have to be stored in the Gateway, are securely erased
417
to prevent any form of access to residual data via external interfaces of the TOE. These
418
Security Target, SMGW Integrationsmodul Version 1.0
Page 23
functionalities protect the privacy of the consumer and prevent that an unauthorised party is
419
able to disclose any of the data transferred in and from the Smart Metering System (e.g.
420
Meter Data, configuration settings).
421
The TOE utilises the services of its Security Module for aspects of this functionality.
422
1.4.5.3 Integrity and Authenticity protection
423
The Gateway provides the following authenticity and integrity protection:
424
• Verification of authenticity and integrity when receiving Meter Data from a Meter via
425
the LMN, to verify that the Meter Data have been sent from an authentic Meter and
426
have not been altered during transmission. The TOE utilises the services of its
427
Security Module for aspects of this functionality.
428
• Application of authenticity and integrity protection measures when sending
429
processed Meter Data to an external entity, to enable the external entity to verify
430
that the processed Meter Data have been sent from an authentic Gateway and have
431
not been changed during transmission. The TOE utilises the services of its Security
432
Module for aspects of this functionality.
433
• Verification of authenticity and integrity when receiving data from an external entity
434
(e.g. configuration settings or firmware updates) to verify that the data have been
435
sent from an authentic and authorised external entity and have not been changed
436
during transmission. The TOE utilises the services of its Security Module for aspects
437
of this functionality.
438
These functionalities ensure that:
439
• prevent within the Smart Metering System that data may be sent by a non-authentic
440
component without the possibility that the data recipient can detect this,
441
Security Target, SMGW Integrationsmodul Version 1.0
Page 24
• facilitate the integrity of billing processes and serve for the interests of the consumer
442
as well as for the interest of the supplier. Both parties are interested in the
443
transmission of correct processed Meter Data to be used for billing,
444
• protect the Smart Metering System and a corresponding large scale Smart Grid
445
infrastructure by preventing that data (e.g. Meter Data, configuration settings, or
446
firmware updates) from forged components (with the aim to cause damage to the
447
Smart Grid) will be accepted in the system.
448
1.4.5.4 Information flow control and firewall
449
The Gateway shall separate devices in the LAN of the consumer from the WAN and shall
450
enforce the following information flow control to control the communication between the
451
networks that the Gateway is attached to:
452
• only the Gateway may establish a connection to an external entity in the WAN15;
453
specifically connection establishment by an external entity in the WAN or a Meter in
454
the LMN to the WAN is not possible,
455
• the Gateway can establish connections to devices in the LMN or in the HAN,
456
• Meters in the LMN are only allowed to establish a connection to the Gateway,
457
• the Gateway shall offer a wake-up service that allows external entities in the WAN to
458
trigger a connection establishment by the Gateway,
459
• connections are allowed to pre-configured addresses only,
460
• only cryptographically-protected (i.e. encrypted, integrity protected and mutually
461
authenticated) connections are possible.16
462
15 Please note that this does not affect the functionality for a CLS to establish a secure channel to a party in the WAN. Technically
however, this channel is established by the TOE who acts as a proxy between the CLS and the WAN.
16 To establish an encrypted channel the TOE may use the required protocols such as DHCP or PPP. Beside the establishment of an
encrypted channel no unprotected communication between the TOE and external entities located in the WAN or LAN is allowed.
Security Target, SMGW Integrationsmodul Version 1.0
Page 25
These functionalities shall:
463
• prevent that the Gateway itself or the components behind the Gateway (i.e. Meters
464
or Controllable Local Systems) can be conquered by a WAN attacker (as defined in
465
section 3.4), that processed data are transmitted to the wrong external entity, and
466
that processed data are transmitted without being
467
confidentiality/authenticity/integrity-protected,
468
• protect the Smart Metering System and a corresponding large scale infrastructure in
469
two ways: by preventing that conquered components will send forged Meter Data
470
(with the aim to cause damage to the Smart Grid), and by preventing that widely
471
distributed Smart Metering Systems can be abused as a platform for malicious
472
software to attack other systems in the WAN (e.g. a WAN attacker who would be
473
able to install a botnet on components of the Smart Metering System).
474
The communication flows that are enforced by the Gateway between parties in the HAN,
475
LMN and WAN are summarized in the following table17:
476
17 Please note that this table only addresses the communication flow between devices in the various networks attached to the
Gateway. It does not aim to provide an overview over the services that the Gateway itself offers to those devices nor an overview
over the communication between devices in the same network. This information can be found in the paragraphs following the
table.
18 The channel to the external entity in the WAN is established by the Gateway.
Source(1st column)
Destination (1st row)
WAN LMN HAN
WAN - (see following list) No connection
establishment allowed
No connection
establishment allowed
LMN No connection establishment
allowed
- (see following list) No connection
establishment allowed
HAN Connection establishment is
allowed to trustworthy, pre-
configured endpoints and via
an encrypted channel only18
No connection
establishment allowed
- (see following list)
Security Target, SMGW Integrationsmodul Version 1.0
Page 26
Table 2: Communication flows between devices in different networks
477
For communications within the different networks the following assumptions are defined:
478
1. Communications within the WAN are not restricted. However, the Gateway is not
479
involved in this communication,
480
2. No communications between devices in the LMN are assumed. Devices in the LMN
481
may only communicate to the Gateway and shall not be connected to any other
482
network,
483
3. Devices in the HAN may communicate with each other. However, the Gateway is not
484
involved in this communication. If devices in the HAN have a separate connection to
485
parties in the WAN (beside the Gateway) this connection is assumed to be
486
appropriately protected. It should be noted that for the case that a TOE connects to
487
more than one HAN communications between devices within different HAN via the
488
TOE are only allowed if explicitly configured by a Gateway Administrator.
489
Finally, the Gateway itself offers the following services within the various networks:
490
• the Gateway accepts the submission of Meter Data from the LMN,
491
• the Gateway offers a wake-up service at the WAN side as described in chapter
492
1.4.6.5 of [PP_GW],
493
• the Gateway offers a user interface to the HAN that allows CLS or consumers to
494
connect to the Gateway in order to read relevant information.
495
1.4.5.5 Wake-Up-Service
496
In order to protect the Gateway and the devices in the LAN against threats from the WAN
497
side the Gateway implements a strict firewall policy and enforces that connections with
498
Security Target, SMGW Integrationsmodul Version 1.0
Page 27
external entities in the WAN shall only be established by the Gateway itself (e.g. when the
499
Gateway delivers Meter Data or contacts the Gateway Administrator to check for updates)19.
500
While this policy is the optimal policy from a security perspective, the Gateway Administrator
501
may want to facilitate applications in which an instant communication to the Gateway is
502
required.
503
In order to allow this kind of re-activeness of the Gateway, this ST allows the Gateway to
504
keep existing connections to external entities open (please refer to [TR-03109-3] for more
505
details) and to offer a so called wake-up service.
506
The Gateway is able to receive a wake-up message that is signed by the Gateway
507
Administrator. The following steps are taken:
508
1. The Gateway verifies the wake-up packet. This comprises
509
i. a check if the header identification is correct,
510
ii. the recipient is the Gateway,
511
iii. the wake-up packet has been sent/received within an acceptable period of
512
time in order to prevent replayed messages,
513
iv. the wake-up message has not been received before,
514
2. If the wake-up message could not be verified as described in step #1, the message
515
will be dropped/ignored. No further operations will be initiated and no feedback is
516
provided.
517
3. If the message could be verified as described in step #1, the signature of the wake-up
518
message will be verified. The Gateway shall use the services of its Security Module
519
for signature verification.
520
4. If the signature of the wake-up message cannot be verified as described in step #3
521
the message will be dropped/ignored. No feedback is given to the sending external
522
entity and the wake-up sequence terminates.
523
19 Please note that this does not affect the functionality for a CLS to establish a secure channel to a party in the WAN. Technically
however, this channel is established by the TOE who acts as a proxy between the CLS and the WAN.
Security Target, SMGW Integrationsmodul Version 1.0
Page 28
5. If the signature of the wake-up message could be verified successfully , the Gateway
524
initiates a connection to a pre-configured external entity; however no feedback is
525
given to the sending external entity.
526
More details on the exact implementation of this mechanism can be found in [TR-03109-1,
527
„Wake-Up Service“].
528
1.4.5.6 Privacy Preservation
529
The preservation of the privacy of the consumer is an essential aspect that is implemented by
530
the functionality of the TOE as required by this ST.
531
This contains two aspects:
532
The Processing Profiles that the TOE obeys facilitate an approach in which only a minimum
533
amount of data have to be submitted to external entities and therewith leave the scope of
534
control of the consumer. The mechanisms “encryption” and “pseudonymisation” ensure that
535
the data can only be read by the intended recipient and only contains an association with the
536
identity of the Meter if this is necessary.
537
On the other hand, the TOE provides the consumer with transparent information about the
538
information flows that happen with their data. In order to achieve this, the TOE implements a
539
consumer log that specifically contains the information about the information flows which
540
has been and will be authorised based on the previous and current Processing Profiles. The
541
access to this consumer log is only possible via a local interface from the HAN and after
542
authentication of the consumer. The TOE does only allow a consumer access to the data in
543
the consumer log that is related to their own consumption or production. The following
544
paragraphs provide more details on the information that is included in this log:
545
Security Target, SMGW Integrationsmodul Version 1.0
Page 29
Monitoring of Data Transfers
546
The TOE keeps track of each data transmission in the consumer log and allows the consumer
547
to see details on which information have been and will be sent (based on the previous and
548
current settings) to which external entity.
549
Configuration Reporting
550
The TOE provides detailed and complete reporting in the consumer log of each security and
551
privacy-relevant configuration setting. Additional to device specific configuration settings,
552
the consumer log contains the parameters of each Processing Profile. The consumer log
553
contains the configured addresses for internal and external entities including the CLS.
554
System Status
555
The TOE provides information on the current status of the TOE in the system log. Specifically
556
it shall indicate whether the TOE operates normally or any errors have been detected that
557
are of relevance for the administrator.
558
Audit Log and Monitoring
559
The TOE provides all audit data from the consumer log at the user interface IF_GW_CON.
560
Access to the consumer log is only possible after successful authentication and only to
561
information that the consumer has permission to (i.e. that has been recorded based on
562
events belonging to the consumer).
563
1.4.5.7 Management of Security Functions
564
The Gateway provides authorised Gateway Administrators with functionality to manage the
565
behaviour of the security functions and to update the TOE.
566
Further, it is defined that only authorised Gateway Administrators may be able to use the
567
management functionality of the Gateway (while the Security Module is used for the
568
authentication of the Gateway Administrator) and that the management of the Gateway
569
shall only be possible from the WAN side interface.
570
Security Target, SMGW Integrationsmodul Version 1.0
Page 30
The TOE shall provide information on the current status of the TOE in the system log.
571
Specifically it shall indicate whether the TOE operates normally or any errors have been
572
detected that are of relevance for the administrator.
573
1.4.5.8 Identification and Authentication
574
To protect the TSF as well as User Data and TSF data from unauthorized modification the TOE
575
provides a mechanism that requires each user to be successfully identified and authenticated
576
before allowing any other actions on behalf of that user. This functionality includes the
577
identification and authentication of users who receive data from the Gateway as well as the
578
identification and authentication of CLS located in HAN and Meters located in LMN.
579
The Gateway provides different kinds of identification and authentication mechanisms that
580
depend on the user role and the used interfaces. Most of the mechanisms require the usage
581
of certificates. Only consumers are able to decide whether they use certificates or username
582
and password for identification and authentication.
583
1.4.6 The logical interfaces of the TOE
584
The TOE offers its functionality as outlined before via a set of external interfaces. Figure 2
585
also indicates the cardinality of the interfaces. The following table provides an overview of
586
the mandatory external interfaces of the TOE and provides additional information:
587
20 Please note that this interface allows consumer (or consumer’s CLS) to connect to the gateway in order to read consumer specific
information.
Interface Name Description
IF_GW_CON Via this interface the Gateway provides the consumer20 with the possibility to
review information that is relevant for billing or the privacy of the consumer.
Specifically the access to the consumer log is only allowed via this interface.
Security Target, SMGW Integrationsmodul Version 1.0
Page 31
Table 3: Mandatory TOE external interfaces
588
1.4.7 The cryptography of the TOE and its Security Module
589
Parts of the cryptographic functionality used in the upper mentioned functions is provided by
590
a Security Module. The Security Module provides strong cryptographic functionality, random
591
number generation, secure storage of secrets and supports the authentication of the
592
Gateway Administrator. The Security Module is a different IT product and not part of the TOE
593
as described in this ST. Nevertheless, it is physically embedded into the Gateway and
594
protected by the same level of physical protection. The requirements applicable to the
595
Security Module are specified in a separate PP (see [SecModPP]).
596
The following table provides a more detailed overview on how the cryptographic functions
597
are distributed between the TOE and its Security Module.
598
599
21 Please note that an implementation of this external interface is also required in the case that Meter and Gateway are
implemented within one physical device in order to allow the extension of the system by another Meter.*
IF_GW_MTR Interface between the Meter and the Gateway. The Gateway receives Meter Data
via this interface.21
IF_GW_SM The Gateway invokes the services of its Security Module via this interface.
IF_GW_CLS CLS may use the communication services of the Gateway via this interface. The
implementation of at least one interface for CLS is mandatory.
IF_GW_WAN The Gateway submits information to authorised external entities via this interface.
IF_GW_SRV Local interface via which the service technician has the possibility to review
information that are relevant to maintain the Gateway. Specifically he has read
access to the system log only via this interface. He has also the possibility to view
non-TSF data via this interface.
Security Target, SMGW Integrationsmodul Version 1.0
Page 32
Table 4: Cryptographic support of the TOE and its Security Module
600
601
Aspect TOE Security Module
Communication
with external
entities
• encryption
• decryption
• hashing
• key derivation
• MAC generation
• MAC verification
• secure storage of the TLS
certificates
Key negotiation:
• support of the authentication of the
external entity
• secure storage of the private key
• random number generation
• digital signature verification and
generation
Communication
with the
consumer
• encryption
• decryption
• hashing
• key derivation
• MAC generation
• MAC verification
• secure storage of the TLS
certificates
Key negotiation:
• support of the authentication of the
consumer
• secure storage of the private key
• digital signature verification and
generation
• random number generation
Communication
with the Meter
• encryption
• decryption
• hashing
• key derivation
• MAC generation
• MAC verification
• secure storage of the TLS
certificates
Key negotiation (in case of TLS connection):
• support of the authentication of the
meter
• secure storage of the private key
• digital signature verification and
generation
• random number generation
Signing data
before
submission to an
external entity
• hashing Signature creation
• secure storage of the private key
Content data
encryption and
integrity
protection
• encryption
• decryption
• MAC generation
• key derivation
• secure storage of the public
Key
Key negotiation:
• secure storage of the private key
• random number generation
Security Target, SMGW Integrationsmodul Version 1.0
Page 33
1.4.7.1 Content data encryption vs. an encrypted channel
602
The TOE utilises concepts of the encryption of data on the content level as well as the
603
establishment of a trusted channel to external entities.
604
As a general rule, all processed Meter Data that is prepared to be submitted to external
605
entities is encrypted and integrity protected on a content level using CMS (according to
606
[TR-03109-1-I]).
607
Further, all communication with external entities is enforced to happen via encrypted,
608
integrity protected and mutually authenticated channels.
609
This concept of encryption on two layers facilitates use cases in which the external party
610
that the TOE communicates with is not the final recipient of the Meter Data. In this way,
611
it is for example possible that the Gateway Administrator receives Meter Data that they
612
forward to other parties. In such a case, the Gateway Administrator is the endpoint of
613
the trusted channel but cannot read the Meter Data.
614
Administration data that is transmitted between the Gateway Administrator and the TOE is
615
also encrypted and integrity protected using CMS.
616
The following figure introduces the communication process between the Meter, the TOE and
617
external entities (focussing on billing-relevant Meter Data).
618
The basic information flow for Meter Data is as follows and shown in Figure 4:
619
1. The Meter measures the consumption or production of a certain commodity.
620
2. The Meter Data is prepared for transmission:
621
a. The Meter Data is typically signed (typically using the services of an integrated
622
Security Module).
623
b. If the communication between the Meter and the Gateway is performed
624
bidirectional, the Meter Data is transmitted via an encrypted and mutually
625
authenticated channel to the Gateway. Please note that the submission of this
626
information may be triggered by the Meter or the Gateway.
627
Security Target, SMGW Integrationsmodul Version 1.0
Page 34
or
628
c. If a unidirectional communication is performed between the Meter and the
629
Gateway, the Meter Data is encrypted using a symmetric algorithm (according to
630
[TR-03109-3]) and facilitating a defined data structure to ensure the authenticity
631
and confidentiality.
632
3. The authenticity and integrity of the Meter Data is verified by the Gateway.
633
4. If (and only if) authenticity and integrity have been verified successfully, the Meter
634
Data is further processed by the Gateway according to the rules in the Processing
635
Profile else the cryptographic information flow will be cancelled.
636
5. The processed Meter Data is encrypted and integrity protected using CMS (according
637
to [TR-03109-1-I]) for the final recipient of the data22.
638
6. The processed Meter Data is signed using the services of the Security Module.
639
7. The processed and signed Meter Data may be stored for a certain amount of time.
640
8. The processed and signed Meter Data may be stored for a certain amount of time.
641
9. The processed Meter Data is finally submitted to an authorised external entity in the
642
WAN via an encrypted and mutually authenticated channel.
643
22 Optionally the Meter Data can additionally be signed before any encryption is done.
Security Target, SMGW Integrationsmodul Version 1.0
Page 35
644
Security Target, SMGW Integrationsmodul Version 1.0
Page 36
Figure 4: Cryptographic information flow for distributed Meters and Gateway
645
1.4.8 TOE life-cycle
646
The life-cycle of the TOE can be separated into the following phases:
647
1. Development
648
2. Production
649
3. Pre-personalization at the developer's premises (without Security Module)
650
4. Pre-personalization and integration of Security Module
651
5. Installation and start of operation
652
6. Personalization
653
7. Normal operation
654
A detailed description of the phases #1 to #4 and #6 to #8 is provided in [TR-03109-1-VI].
655
656
The TOE will be delivered after phase “Pre-personalization and integration of Security
657
Module”. The phase “Personalization” will be performed when the TOE is started for the first
658
time after phase “Installation and start of operation”.
659
Security Target, SMGW Integrationsmodul Version 1.0
Page 37
2 Conformance Claims
660
2.1 CC Conformance Claim
661
• This ST has been developed using Version 3.1 Revision 4 of Common Criteria [CC].
662
• This ST is [CC] part 2 extended due to the use of FPR_CON.1.
663
• This ST claims conformance to [CC] part 3; no extended assurance components have
664
been defined.
665
666
2.2 PP Claim / Conformance Statement
667
This Security Target claims strict conformance to Protection Profile [PP_GW].
668
669
2.3 Package Claim
670
This Security Target claims an assurance package EAL4 augmented by AVA_VAN.5 and
671
ALC_FLR.2 as defined in [CC] Part 3 for product certification.
672
673
2.4 Conformance Claim Rationale
674
This Security Target claims strict conformance to only one PP [PP_GW].
675
This Security Target is consistent to the TOE type according to [PP_GW] because the TOE is a
676
communication Gateway that provides different external communication interfaces and
677
enables the data communication between these interfaces and connected IT systems. It
678
further collects processes, and stores Meter Data.
679
This Security Target is consistent to the security problem defined in [PP_GW].
680
This Security Target is consistent to the security objectives stated in [PP_GW], no security
681
objective of the PP is removed, nor added to this Security Target.
682
This Security Target is consistent to the security requirements stated in [PP_GW], no security
683
requirement of the PP is removed, nor added to this Security Target.
684
685
Security Target, SMGW Integrationsmodul Version 1.0
Page 38
3 Security Problem Definition
686
3.1 External entities
687
The following external entities interact with the system consisting of Meter and Gateway.
688
Those roles have been defined for the use in this Security Target. It is possible that a party
689
implements more than one role in practice.
690
Role Description
Consumer The authorised individual or organization that “owns” the Meter Data.
In most cases, this will be tenants or house owners consuming
electricity, water, gas or further commodities. However, it is also
possible that the consumer produces or stores energy (e.g. with their
own solar plant).
Gateway
Administrator
Authority that installs, configures, monitors, and controls the Smart
Meter Gateway.
Service Technician The authorised individual that is responsible for diagnostic purposes.
Authorised External
Entity / User
Human or IT entity possibly interacting with the TOE from outside of the
TOE boundary. In the context of this ST, the term user or external entity
serve as a hypernym for all entities mentioned before.
Table 5: Roles used in the Security Target
691
3.2 Assets
692
The following tables introduces the relevant assets for this Security Target. The tables focus
693
on the assets that are relevant for the Gateway and does not claim to provide an overview
694
over all assets in the Smart Metering System or for other devices in the LMN.
695
The following Table 6 lists all assets typified as “user data”:
696
697
Security Target, SMGW Integrationsmodul Version 1.0
Page 39
23 Please note that these readings and data of the Meter which are not relevant for billing may require an explicit endorsement of
the consumer(s).
Asset Description Need for Protection
Meter Data Meter readings that allow calculation of
the quantity of a commodity, e.g.
electricity, gas, water or heat consumed
over a period.
Meter Data comprise Consumption or
Production Data (billing-relevant) and
grid status data (not billing-relevant).
While billing-relevant data needs to
have a relation to the Consumer, grid
status data do not have to be directly
related to a Consumer.
• According to their specific need (see
below)
System log data Log data from the
• system log.
• Integrity
• Confidentiality (only authorised
SMGW administrators and Service
technicians may read the log data)
Consumer log
data
Log data from the
• consumer log.
• Integrity
• Confidentiality (only authorised
Consumers may read the log data)
Calibration log
data
Log data from the
• calibration log.
• Integrity
• Confidentiality (only authorised
SMGW administrators may read the
log data)
Consumption Data Billing-relevant part of Meter Data.
Please note that the term Consumption
Data implicitly includes Production
Data.
• Integrity and authenticity
(comparable to the classical meter
and its security requirements)
• Confidentiality (due to privacy
concerns)
Status Data Grid status data, subset of Meter Data
that is not billing-relevant23.
• Integrity and authenticity
(comparable to the classical meter
and its security requirements)
• Confidentiality (due to privacy
concerns)
Security Target, SMGW Integrationsmodul Version 1.0
Page 40
Table 6: Assets (User data)
698
Table 7 lists all assets typified as “TSF data”:
699
Supplementary
Data
The Gateway may be used for
communication purposes by devices in
the LMN or HAN. It may be that the
functionality of the Gateway that is
used by such a device is limited to pure
(but secure) communication services.
Data that is transmitted via the Gateway
but that does not belong to one of the
aforementioned data types is named
Supplementary Data.
• According to their specific need
Data The term Data is used as hypernym for
Meter Data and Supplementary Data.
• According to their specific need
Gateway time Date and time of the real-time clock of
the Gateway. Gateway Time is used in
Meter Data records sent to external
entities.
• Integrity
• Authenticity (when time is adjusted
to an external reference time)
Personally
Identifiable
Information (PII)
Personally Identifiable Information
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.
• Confidentiality
Meter config
(secondary asset)
Configuration data of the Meter to
control its behaviour including the
Meter identity. Configuration data is
transmitted to the Meter via the
Gateway.
• Integrity and authenticity
• Confidentiality
Gateway config
(secondary asset)
Configuration data of the Gateway to
control its behaviour including the
Gateway identity, the Processing
Profiles and certificate/key material for
authentication.
• Integrity and authenticity
• Confidentiality
CLS config
(secondary asset)
Configuration data of a CLS to control its
behaviour. Configuration data is
transmitted to the CLS via the Gateway.
• Integrity and authenticity
• Confidentiality
Security Target, SMGW Integrationsmodul Version 1.0
Page 41
Table 7: Assets (TSF data)
700
701
3.3 Assumptions
702
In this threat model the following assumptions about the environment of the components
703
need to be taken into account in order to ensure a secure operation.
704
A.ExternalPrivacy It is assumed that authorised and authenticated external
705
entities receiving any kind of privacy-relevant data or billing-
706
relevant data and the applications that they operate are
707
trustworthy (in the context of the data that they receive) and
708
do not perform unauthorised analyses of this data with
709
respect to the corresponding Consumer(s).
710
A.TrustedAdmins It is assumed that the Gateway Administrator and the Service
711
Technician are trustworthy and well-trained.
712
A.PhysicalProtection It is assumed that the TOE is installed in a non-public
713
environment within the premises of the Consumer which
714
provides a basic level of physical protection. This protection
715
covers the TOE, the Meter(s) that the TOE communicates
716
with and the communication channel between the TOE and
717
its Security Module.
718
A.ProcessProfile The Processing Profiles that are used when handling data are
719
assumed to be trustworthy and correct.
720
Firmware update
(secondary asset)
Firmware update that is downloaded by
the TOE to update the firmware of the
TOE.
• Integrity and authenticity
Ephemeral keys
(secondary asset)
Ephemeral cryptographic material used
by the TOE for cryptographic
operations.
• Integrity and authenticity
• Confidentiality
Security Target, SMGW Integrationsmodul Version 1.0
Page 42
A.Update It is assumed that firmware updates for the Gateway that can
721
be provided by an authorised external entity have undergone
722
a certification process according to this Security Target
723
before they are issued and can therefore be assumed to be
724
correctly implemented. It is further assumed that the
725
external entity that is authorised to provide the update is
726
trustworthy and will not introduce any malware into a
727
firmware update.
728
A.Network It is assumed that
729
• a WAN network connection with a sufficient reliability
730
and bandwidth for the individual situation is available,
731
• one or more trustworthy sources for an update of the
732
system time are available in the WAN,
733
• the Gateway is the only communication gateway for
734
Meters in the LMN24,
735
• if devices in the HAN have a separate connection to
736
parties in the WAN (beside the Gateway) this connection
737
is appropriately protected.
738
A.Keygen It is assumed that the ECC key pair for a Meter (TLS) is
739
generated securely according to [TR-03109-3] and brought
740
into the Gateway in a secure way by the Gateway
741
Administrator.
742
Application Note 1: This ST acknowledges that the Gateway cannot be completely
743
protected against unauthorised physical access by its
744
24 Please note that this assumption holds on a logical level rather than on a physical one. It may be possible that the Meters in the
LMN have a physical connection to other devices that would in theory also allow a communication. This is specifically true for
wireless communication technologies. It is further possible that signals of Meters are amplified by other devices or other Meters
on the physical level without violating this assumption. However, it is assumed that the Meters do only communicate with the TOE
and that only the TOE is able to decrypt the data sent by the Meter.
Security Target, SMGW Integrationsmodul Version 1.0
Page 43
environment. However, it is important for the overall security
745
of the TOE that it is not installed within a public environment.
746
The level of physical protection that is expected to be
747
provided by the environment is the same level of protection
748
that is expected for classical meters that operate according to
749
the regulations of the national calibration authority [TR-
750
03109-1].
751
Application Note 2: The Processing Profiles that are used for information flow
752
control as referred to by A.ProcessProfile are an essential
753
factor for the preservation of the privacy of the Consumer.
754
The Processing Profiles are used to determine which data
755
shall be sent to which entity at which frequency and how
756
data are processed, e.g. whether the data needs to be related
757
to the Consumer (because it is used for billing purposes) or
758
whether the data shall be pseudonymised.
759
The Processing Profiles shall be visible for the Consumer to
760
allow a transparent communication.
761
It is essential that Processing Profiles correctly define the
762
amount of information that must be sent to an external
763
entity. Exact regulations regarding the Processing Profiles and
764
the Gateway Administrator are beyond the scope of this
765
Security Target.
766
767
3.4 Threats
768
The following sections identify the threats that are posed against the assets handled by the
769
Smart Meter System. Those threats are the result of a threat model that has been developed
770
for the whole Smart Metering System first and then has been focussed on the threats against
771
the Gateway. It should be noted that the threats in the following paragraphs consider two
772
different kinds of attackers:
773
• Attackers having physical access to Meter, Gateway, a connection between these
774
components or local logical access to any of the interfaces (local attacker), trying to
775
disclose or alter assets while stored in the Gateway or while transmitted between Meters
776
in the LMN and the Gateway. Please note that the following threat model assumes that
777
the local attacker has less motivation than the WAN attacker as a successful attack of a
778
Security Target, SMGW Integrationsmodul Version 1.0
Page 44
local attacker will always only impact one Gateway. Please further note that the local
779
attacker includes authorised individuals like consumers.
780
• An attacker located in the WAN (WAN attacker) trying to compromise the confidentiality
781
and/or integrity of the processed Meter Data and or configuration data transmitted via
782
the WAN, or attacker trying to conquer a component of the infrastructure (i.e. Meter,
783
Gateway or Controllable Local System) via the WAN to cause damage to a component
784
itself or to the corresponding grid (e.g. by sending forged Meter Data to an external
785
entity).
786
The specific rationale for this situation is given by the expected benefit of a successful attack.
787
An attacker who has to have physical access to the TOE that they are attacking, will only be
788
able to compromise one TOE at a time. So the effect of a successful attack will always be
789
limited to the attacked TOE. A logical attack from the WAN side on the other hand may have
790
the potential to compromise a large amount of TOEs.
791
792
T.DataModificationLocal A local attacker may try to modify (i.e. alter, delete, insert,
793
replay or redirect) Meter Data when transmitted between
794
Meter and Gateway, Gateway and Consumer, or Gateway
795
and external entities. The objective of the attacker may be to
796
alter billing-relevant information or grid status information.
797
The attacker may perform the attack via any interface (LMN,
798
HAN, or WAN).
799
In order to achieve the modification, the attacker may also
800
try to modify secondary assets like the firmware or
801
configuration parameters of the Gateway.
802
T.DataModificationWAN A WAN attacker may try to modify (i.e. alter, delete, insert,
803
replay or redirect) Meter Data, Gateway config data, Meter
804
config data, CLS config data or a firmware update when
805
Security Target, SMGW Integrationsmodul Version 1.0
Page 45
transmitted between the Gateway and an external entity in
806
the WAN.
807
When trying to modify Meter Data, it is the objective of the
808
WAN attacker to modify billing-relevant information or grid
809
status data.
810
When trying to modify config data or a firmware update, the
811
WAN attacker tries to circumvent security mechanisms of the
812
TOE or tries to get control over the TOE or a device in the LAN
813
that is protected by the TOE.
814
T.TimeModification A local attacker or WAN attacker may try to alter the
815
Gateway time. The motivation of the attacker could be e.g. to
816
change the relation between date/time and measured
817
consumption or production values in the Meter Data records
818
(e.g. to influence the balance of the next invoice).
819
T.DisclosureWAN A WAN attacker may try to violate the privacy of the
820
Consumer by disclosing Meter Data or configuration data
821
(Meter config, Gateway config or CLS config) or parts of it
822
when transmitted between Gateway and external entities in
823
the WAN.
824
T.DisclosureLocal A local attacker may try to violate the privacy of the
825
Consumer by disclosing Meter Data transmitted between the
826
TOE and the Meter. This threat is of specific importance if
827
Meters of more than one Consumer are served by one
828
Gateway.
829
T.Infrastructure A WAN attacker may try to obtain control over Gateways,
830
Meters or CLS via the TOE, which enables the WAN attacker
831
to cause damage to Consumers or external entities or the
832
Security Target, SMGW Integrationsmodul Version 1.0
Page 46
grids used for commodity distribution (e.g. by sending wrong
833
data to an external entity).
834
A WAN attacker may also try to conquer a CLS in the HAN
835
first in order to logically attack the TOE from the HAN side.
836
T.ResidualData By physical and/or logical means a local attacker or a WAN
837
attacker may try to read out data from the Gateway, which
838
travelled through the Gateway before and which are no
839
longer needed by the Gateway (i.e. Meter Data, Meter config,
840
or CLS config).
841
T.ResidentData A WAN or local attacker may try to access (i.e. read, alter,
842
delete) information to which they don't have permission to
843
while the information is stored in the TOE.
844
While the WAN attacker only uses the logical interface of the
845
TOE that is provided into the WAN, the local attacker may
846
also physically access the TOE.
847
T.Privacy A WAN attacker may try to obtain more detailed information
848
from the Gateway than actually required to fulfil the tasks
849
defined by its role or the contract with the Consumer. This
850
includes scenarios in which an external entity that is primarily
851
authorised to obtain information from the TOE tries to obtain
852
more information than the information that has been
853
authorised as well as scenarios in which an attacker who is
854
not authorised at all tries to obtain information.
855
3.5 Organizational Security Policies
856
This section lists the organizational security policies (OSP) that the Gateway shall comply
857
with:
858
Security Target, SMGW Integrationsmodul Version 1.0
Page 47
OSP.SM The TOE shall use the services of a certified Security Module
859
for
860
• verification of digital signatures,
861
• generation of digital signatures,
862
• key agreement,
863
• key transport,
864
• key storage,
865
• Random Number Generation,
866
The Security Module shall be certified according to
867
[SecModPP] and shall be used in accordance with its relevant
868
guidance documentation.
869
OSP.Log The TOE shall maintain a set of log files as defined in [TR-
870
03109-1] as follows:
871
1. A system log of relevant events in order to allow an
872
authorised Gateway Administrator to analyse the
873
status of the TOE. The TOE shall also analyse the
874
system log automatically for a cumulation of security
875
relevant events.
876
2. A consumer log that contains information about the
877
information flows that have been initiated to the
878
WAN and information about the Processing Profiles
879
causing this information flow as well as the billing-
880
relevant information.
881
3. A calibration log (as defined in chapter 6.2.1) that
882
provides the Gateway Administrator with a possibility
883
to review calibration relevant events.
884
The TOE shall further limit access to the information in the
885
different log files as follows:
886
Security Target, SMGW Integrationsmodul Version 1.0
Page 48
1. Access to the information in the system log shall only
887
be allowed for an authorised Gateway Administrator
888
via the IF_GW_WAN interface of the TOE and an
889
authorised Service Technician via the IF_GW_SRV
890
interface of the TOE.
891
2. Access to the information in the calibration log shall
892
only be allowed for an authorised Gateway
893
Administrator via the IF_GW_WAN interface of the
894
TOE.
895
3. Access to the information in the consumer log shall
896
only be allowed for an authorised Consumer via the
897
IF_GW_CON interface of the TOE. The Consumer
898
shall only have access to their own information.
899
The system log may overwrite the oldest events in case that
900
the audit trail gets full.
901
For the consumer log the TOE shall ensure that a sufficient
902
amount of events is available (in order to allow a Consumer
903
to verify an invoice) but may overwrite older events in case
904
that the audit trail gets full.
905
For the calibration log, however, the TOE shall ensure the
906
availability of all events over the lifetime of the TOE.
907
Security Target, SMGW Integrationsmodul Version 1.0
Page 49
4 Security Objectives
908
4.1 Security Objectives for the TOE
909
O.Firewall The TOE shall serve as the connection point for the
910
connected devices within the LAN to external entities within
911
the WAN and shall provide firewall functionality in order to
912
protect the devices of the LMN and HAN (as long as they use
913
the Gateway) and itself against threats from the WAN side.
914
The firewall:
915
• shall allow only connections established from HAN or
916
the TOE itself to the WAN (i.e. from devices in the
917
HAN to external entities in the WAN or from the TOE
918
itself to external entities in the WAN),
919
• shall provide a wake-up service on the WAN side
920
interface,
921
• shall not allow connections from the LMN to the
922
WAN,
923
• shall not allow any other services being offered on
924
the WAN side interface,
925
• shall not allow connections from the WAN to the LAN
926
or to the TOE itself,
927
• shall enforce communication flows by allowing traffic
928
from CLS in the HAN to the WAN only if
929
confidentiality-protected and integrity-protected and
930
if endpoints are authenticated.
931
O.SeparateIF The TOE shall have physically separated ports for the LMN,
932
the HAN and the WAN and shall automatically detect during
933
Security Target, SMGW Integrationsmodul Version 1.0
Page 50
its self test whether connections (wired or wireless), if any,
934
are wrongly connected.
935
Application Note 3: O.SeparateIF refers to physical interfaces
936
and must not be fulfilled by a pure logical separation of one
937
physical interface only.
938
O.Conceal To protect the privacy of its Consumers, the TOE shall conceal
939
the communication with external entities in the WAN in
940
order to ensure that no privacy-relevant information may be
941
obtained by analysing the frequency, load, size or the
942
absence of external communication.25
943
O.Meter The TOE receives or polls information about the consumption
944
or production of different commodities from one or multiple
945
Meters and is responsible for handling this Meter Data.
946
This includes that:
947
• The TOE shall ensure that the communication to the
948
Meter(s) is established in an Gateway Administrator-
949
definable interval or an interval as defined by the
950
Meter,
951
• the TOE shall enforce encryption and integrity
952
protection for the communication with the Meter26,
953
• the TOE shall verify the integrity and authenticity of
954
the data received from a Meter before handling it
955
further,
956
25 It should be noted that this requirement only applies to communication flows in the WAN.
26 It is acknowledged that the implementation of a secure channel between the Meter and the Gateway is a security function of both
units. The TOE as defined in this Security Target only has a limited possibility to secure this communication as both sides have to
sign responsible for the quality of a cryptographic connection. However, it should be noted that the encryption of this channel
only needs to protect against the Local Attacker possessing a basic attack potential and that the Meter utilises the services of its
Security Module to negotiate the channel.
Security Target, SMGW Integrationsmodul Version 1.0
Page 51
• the TOE shall process the data according to the
957
definition in the corresponding Processing Profile,
958
• the TOE shall encrypt the processed Meter Data for
959
the final recipient, sign the data and
960
• deliver the encrypted data to authorised external
961
entities as defined in the corresponding Processing
962
Profiles facilitating an encrypted channel,
963
• the TOE shall store processed Meter Data if an
964
external entity cannot be reached and re-try to send
965
the data until a configurable number of unsuccessful
966
retries has been reached,
967
• the TOE shall pseudonymize the data for parties that
968
do not need the relation between the processed
969
Meter Data and the identity of the Consumer.
970
O.Crypt The TOE shall provide cryptographic functionality as follows:
971
• authentication, integrity protection and encryption of
972
the communication and data to external entities in
973
the WAN,
974
• authentication, integrity protection and encryption of
975
the communication to the Meter,
976
• authentication, integrity protection and encryption of
977
the communication to the Consumer,
978
• replay detection for all communications with external
979
entities,
980
• encryption of the persistently stored TSF and user
981
data of the TOE27.
982
27 The encryption of the persistent memory shall support the protection of the TOE against local attacks.
Security Target, SMGW Integrationsmodul Version 1.0
Page 52
In addition, the TOE shall generate the required keys utilising
983
the services of its Security Module28, ensure that the keys are
984
only used for an acceptable amount of time and destroy
985
ephemeral29 keys if not longer needed.30
986
O.Time The TOE shall provide reliable time stamps and update its
987
internal clock in regular intervals by retrieving reliable time
988
information from a dedicated reliable source in the WAN.
989
O.Protect The TOE shall implement functionality to protect its security
990
functions against malfunctions and tampering.
991
Specifically, the TOE shall
992
• encrypt its TSF and user data as long as it is not in
993
use,
994
• overwrite any information that is no longer needed
995
to ensure that it is not longer available via the
996
external interfaces of the TOE31,
997
• monitor user data and the TOE firmware for integrity
998
errors,
999
• contain a test that detects whether the interfaces for
1000
WAN and LAN are separate,
1001
• have a fail-safe design that specifically ensures that
1002
no malfunction can impact the delivery of a
1003
commodity (e.g. energy, gas, heat or water)32,
1004
28 Please refer to chapter 1.4.7 for an overview on how the cryptographic functions are distributed between the TOE and its Security
Module.
29 This objective addresses the destruction of ephemeral keys only because all keys that need to be stored persistently are stored in
the Security Module.
30 Please refer to chapter F.9 of part 2 of [CC] for more detailed information about what kind of information this objective applies to.
31 Please refer to chapter F.9 of part 2 of [CC] for more detailed information about what kind of information this objective applies to.
Security Target, SMGW Integrationsmodul Version 1.0
Page 53
• make any physical manipulation within the scope of
1005
the intended environment detectable for the
1006
Consumer and Gateway Administrator.
1007
O.Management The TOE shall only provide authorised Gateway
1008
Administrators with functions for the management of the
1009
security features.
1010
The TOE shall ensure that any change in the behaviour of the
1011
security functions can only be achieved from the WAN side
1012
interface. Any management activity from a local interface
1013
may only be read only.
1014
Further, the TOE shall implement a secure mechanism to
1015
update the firmware of the TOE that ensures that only
1016
authorised entities are able to provide updates for the TOE
1017
and that only authentic and integrity protected updates are
1018
applied.
1019
O.Log The TOE shall maintain a set of log files as defined in [TR-
1020
03109-1] as follows:
1021
1. A system log of relevant events in order to allow an
1022
authorised Gateway Administrator or an authorised
1023
Service Technician to analyse the status of the TOE.
1024
The TOE shall also analyse the system log
1025
automatically for a cumulation of security relevant
1026
events.
1027
32 Indeed this Security Target acknowledges that the Gateway and the Meters have no possibility at all to impact the delivery of a
commodity. Even an intentional stop of the delivery of a certain commodity is not within the scope of this Security Target. It
should however be noted that such a functionality may be realised by a CLS that utilises the services of the TOE for its
communication.
Security Target, SMGW Integrationsmodul Version 1.0
Page 54
2. A consumer log that contains information about the
1028
information flows that have been initiated to the
1029
WAN and information about the Processing Profiles
1030
causing this information flow as well as the billing-
1031
relevant information and information about the
1032
system status (including relevant error messages).
1033
3. A calibration log that provides the Gateway
1034
Administrator with a possibility to review calibration
1035
relevant events.
1036
The TOE shall further limit access to the information in the
1037
different log files as follows:
1038
1. Access to the information in the system log shall only
1039
be allowed for an authorised Gateway Administrator
1040
via IF_GW_WAN or for an authorised Service
1041
Technician via IF_GW_SRV.
1042
2. Access to the information in the consumer log shall
1043
only be allowed for an authorised Consumer via the
1044
IF_GW_CON interface of the TOE and via a secured
1045
(i.e. confidentiality and integrity protected)
1046
connection. The Consumer shall only have access to
1047
their own information.
1048
3. Read-only access to the information in the calibration
1049
log shall only be allowed for an authorised Gateway
1050
Administrator via the WAN interface of the TOE.
1051
The system log may overwrite the oldest events in case that
1052
the audit trail gets full.
1053
For the consumer log, the TOE shall ensure that a sufficient
1054
amount of events is available (in order to allow a Consumer
1055
Security Target, SMGW Integrationsmodul Version 1.0
Page 55
to verify an invoice) but may overwrite older events in case
1056
that the audit trail gets full.
1057
For the calibration log however, the TOE shall ensure the
1058
availability of all events over the lifetime of the TOE.
1059
O.Access The TOE shall control the access of external entities in WAN,
1060
HAN or LMN to any information that is sent to, from or via
1061
the TOE via its external interfaces33. Access control shall
1062
depend on the destination interface that is used to send that
1063
information.
1064
4.2 Security Objectives for the Operational Environment
1065
OE.ExternalPrivacy Authorised and authenticated external entities receiving any
1066
kind of private or billing-relevant data shall be trustworthy
1067
and shall not perform unauthorised analyses of these data
1068
with respect to the corresponding consumer(s).
1069
OE.TrustedAdmins The Gateway Administrator and the Service Technician shall
1070
be trustworthy and well-trained.
1071
OE.PhysicalProtection The TOE shall be installed in a non-public environment within
1072
the premises of the Consumer that provides a basic level of
1073
physical protection. This protection shall cover the TOE, the
1074
Meters that the TOE communicates with and the
1075
communication channel between the TOE and its Security
1076
Module. Only authorised individuals may physically access
1077
the TOE.
1078
33 While in classical access control mechanisms the Gateway Administrator gets complete access, the TOE also maintains a set of
information (specifically the consumer log) to which Gateway Administrators have restricted access.
Security Target, SMGW Integrationsmodul Version 1.0
Page 56
OE.Profile The Processing Profiles that are used when handling data
1079
shall be obtained from a trustworthy and reliable source only.
1080
OE.SM The environment shall provide the services of a certified
1081
Security Module for
1082
• verification of digital signatures,
1083
• generation of digital signatures,
1084
• key agreement,
1085
• key transport,
1086
• key storage,
1087
• Random Number Generation.
1088
The Security Module used shall be certified according to
1089
[SecModPP] and shall be used in accordance with its relevant
1090
guidance documentation.
1091
OE.Update The firmware updates for the Gateway that can be provided
1092
by an authorised external entity shall undergo a certification
1093
process according to this Security Target before they are
1094
issued to show that the update is implemented correctly. The
1095
external entity that is authorised to provide the update shall
1096
be trustworthy and ensure that no malware is introduced via
1097
a firmware update.
1098
OE.Network It shall be ensured that
1099
• a WAN network connection with a sufficient
1100
reliability and bandwidth for the individual situation
1101
is available,
1102
• one or more trustworthy sources for an update of the
1103
system time are available in the WAN,
1104
Security Target, SMGW Integrationsmodul Version 1.0
Page 57
• the Gateway is the only communication gateway for
1105
Meters in the LMN,
1106
• if devices in the HAN have a separate connection to
1107
parties in the WAN (beside the Gateway) this
1108
connection is appropriately protected.
1109
OE.Keygen It shall be ensured that the ECC key pair for a Meter (TLS) is
1110
generated securely according to the [TR-03109-3]. It shall
1111
also be ensured that the keys are brought into the Gateway
1112
in a secure way by the Gateway Administrator.
1113
4.3 Security Objective Rationale
1114
4.3.1 Overview
1115
The following table gives an overview how the assumptions, threats, and organisational
1116
security policies are addressed by the security objectives. The text of the following sections
1117
justifies this more in detail.
1118
O.Firewall
O.SeparateIF
O.Conceal
O.Meter
O.Crypt
O.Time
O.Protect
O.Management
O.Log
O.Access
OE.SM
OE.ExternalPrivacy
OE.TrustedAdmins
OE.PhysicalProtection
OE.Profile
OE.Update
OE.Network
OE.Keygen
T.DataModificationLocal X X X X X X
T.DataModificationWAN X X X X X
T.TimeModification X X X X X X
T.DisclosureWAN X X X X X X
T.DisclosureLocal X X X X X X
Security Target, SMGW Integrationsmodul Version 1.0
Page 58
Table 8: Rationale for Security Objectives
1119
1120
4.3.2 Countering the threats
1121
The following sections provide more detailed information on how the threats are countered
1122
by the security objectives for the TOE and its operational environment.
1123
1124
4.3.2.1 General objectives
1125
The security objectives O.Protect, O.Management and OE.TrustedAdmins contribute to
1126
counter each threat and contribute to each OSP.
1127
O.Management is indispensable as it defines the requirements around the management of
1128
the Security Functions. Without a secure management no TOE can be secure. Also
1129
OE.TrustedAdmins contributes to this aspect as it provides the requirements on the
1130
T.Infrastructure X X X X X X X
T.ResidualData X X X
T.ResidentData X X X X X X X
T.Privacy X X X X X X X X
OSP.SM X X X X X
OSP.Log X X X X X
A.ExternalPrivacy X
A.TrustedAdmins X
A.PhysicalProtection X
A.ProcessProfile X
A.Update X
A.Network X
A.Keygen X
Security Target, SMGW Integrationsmodul Version 1.0
Page 59
availability of a trustworthy Gateway Administrator and Service Technician. O.Protect is
1131
present to ensure that all security functions are working as specified.
1132
Those general objectives will not be addressed in detail in the following paragraphs.
1133
1134
4.3.2.2 T.DataModificationLocal
1135
The threat T.DataModificationLocal is countered by a combination of the security objectives
1136
O.Meter, O.Crypt, O.Log and OE.PhysicalProtection.
1137
O.Meter defines that the TOE will enforce the encryption of communication when receiving
1138
Meter Data from the Meter. O.Crypt defines the required cryptographic functionality. The
1139
objectives together ensure that the communication between the Meter and the TOE cannot
1140
be modified or released.
1141
OE.PhysicalProtection is of relevance as it ensures that access to the TOE is limited.
1142
4.3.2.3 T.DataModificationWAN
1143
The threat T.DataModificationWAN is countered by a combination of the security objectives
1144
O.Firewall and O.Crypt.
1145
O.Firewall defines the connections for the devices within the LAN to external entities within
1146
the WAN and shall provide firewall functionality in order to protect the devices of the LMN
1147
and HAN (as long as they use the Gateway) and itself against threats from the WAN side.
1148
O.Crypt defines the required cryptographic functionality. Both objectives together ensure
1149
that the data transmitted between the TOE and the WAN cannot be modified by a WAN
1150
attacker.
1151
4.3.2.4 T.TimeModification
1152
The threat T.TimeModification is countered by a combination of the security objectives
1153
O.Time, O.Crypt and OE.PhysicalProtection.
1154
Security Target, SMGW Integrationsmodul Version 1.0
Page 60
O.Time defines that the TOE needs a reliable time stamp mechanism that is also updated
1155
from reliable sources regularly in the WAN. O.Crypt defines the required cryptographic
1156
functionality for the communication to external entities in the WAN. Therewith, O.Time and
1157
O.Crypt are the core objective to counter the threat T.TimeModification.
1158
OE.PhysicalProtection is of relevance as it ensures that access to the TOE is limited.
1159
4.3.2.5 T.DisclosureWAN
1160
The threat T.DisclosureWAN is countered by a combination of the security objectives
1161
O.Firewall, O.Conceal and O.Crypt.
1162
O.Firewall defines the connections for the devices within the LAN to external entities within
1163
the WAN and shall provide firewall functionality in order to protect the devices of the LMN
1164
and HAN (as long as they use the Gateway) and itself against threats from the WAN side.
1165
O.Crypt defines the required cryptographic functionality. Both objectives together ensure
1166
that the communication between the Meter and the TOE cannot be disclosed.
1167
O.Conceal ensures that no information can be disclosed based on additional characteristics
1168
of the communication like frequency, load or the absence of a communication.
1169
4.3.2.6 T.DisclosureLocal
1170
The threat T.DisclosureLocal is countered by a combination of the security objectives
1171
O.Meter, O.Crypt and OE.PhysicalProtection.
1172
O.Meter defines that the TOE will enforce the encryption and integrity protection of
1173
communication when polling or receiving Meter Data from the Meter. O.Crypt defines the
1174
required cryptographic functionality. Both objectives together ensure that the
1175
communication between the Meter and the TOE cannot be disclosed.
1176
OE.PhysicalProtection is of relevance as it ensures that access to the TOE is limited.
1177
Security Target, SMGW Integrationsmodul Version 1.0
Page 61
4.3.2.7 T.Infrastructure
1178
The threat T.Infrastructure is countered by a combination of the security objectives
1179
O.Firewall, O.SeparateIF, O.Meter and O.Crypt.
1180
O.Firewall is the core objective that counters this threat. It ensures that all communication
1181
flows to the WAN are initiated by the TOE. The fact that the TOE does not offer any services
1182
to the WAN side and will not react to any requests (except the wake-up call) from the WAN is
1183
a significant aspect in countering this threat. Further the TOE will only communicate using
1184
encrypted channels to authenticated and trustworthy parties which mitigates the possibility
1185
that an attacker could try to hijack a communication.
1186
O.Meter defines that the TOE will enforce the encryption and integrity protection for the
1187
communication with the Meter.
1188
O.SeparateIF facilitates the disjunction of the WAN from the LMN.
1189
O.Crypt supports the mitigation of this threat by providing the required cryptographic
1190
primitives.
1191
4.3.2.8 T.ResidualData
1192
The threat T.ResidualData is mitigated by the security objective O.Protect as this security
1193
objective defines that the TOE shall delete information as soon as it is not longer used.
1194
Assuming that a TOE follows this requirement an attacker cannot read out any residual
1195
information as it does simply not exist.
1196
4.3.2.9 T.ResidentData
1197
The threat T.ResidentData is countered by a combination of the security objectives O.Access,
1198
O.Firewall, O.Protect and O.Crypt. Further, the environment (OE.PhysicalProtection and
1199
OE.TrustedAdmins) contributes to this.
1200
O.Access defines that the TOE shall control the access of users to information via the external
1201
interfaces.
1202
The aspect of a local attacker with physical access to the TOE is covered by a combination of
1203
O.Protect (defining the detection of physical manipulation) and O.Crypt (requiring the
1204
Security Target, SMGW Integrationsmodul Version 1.0
Page 62
encryption of persistently stored TSF and user data of the TOE). In addition, the physical
1205
protection provided by the environment (OE.PhysicalProtection) and the Gateway
1206
Administrator (OE.TrustedAdmins) who could realise a physical manipulation contribute to
1207
counter this threat.
1208
The aspect of a WAN attacker is covered by O.Firewall as this objective ensures that an
1209
adequate level of protection is realised against attacks from the WAN side.
1210
4.3.2.10 T.Privacy
1211
The threat T.Privacy is primarily addressed by the security objectives O.Meter, O.Crypt and
1212
O.Firewall as these objective ensures that the TOE will only distribute Meter Data to external
1213
parties in the WAN as defined in the corresponding Processing Profiles and that the data will
1214
be protected for the transfer. OE.Profile is present to ensure that the Processing Profiles are
1215
obtained from a trustworthy and reliable source only.
1216
Finally, O.Conceal ensures that an attacker cannot obtain the relevant information for this
1217
threat by observing external characteristics of the information flow.
1218
4.3.3 Coverage of organisational security policies
1219
The following sections provide more detailed information about how the security objectives
1220
for the environment and the TOE cover the organizational security policies.
1221
4.3.3.1 OSP.SM
1222
The Organizational Security Policy OSP.SM that mandates that the TOE utilises the services of
1223
a certified Security Module is directly addressed by the security objectives OE.SM and
1224
O.Crypt. The objective OE.SM addresses the functions that the Security Module shall be
1225
utilised for as defined in OSP.SM and also requires a certified Security Module. O.Crypt
1226
defines the cryptographic functionalities for the TOE itself. In this context, it has to be
1227
Security Target, SMGW Integrationsmodul Version 1.0
Page 63
ensured that the Security Module is operated in accordance with its guidance
1228
documentation.
1229
4.3.3.2 OSP.Log
1230
The Organizational Security Policy OSP.Log that mandates that the TOE maintains an audit
1231
log is directly addressed by the security objective for the TOE O.Log.
1232
O.Access contributes to the implementation of the OSP as it defines that also Gateway
1233
Administrators are not allowed to read/modify all data. This is of specific importance to
1234
ensure the confidentiality and integrity of the log data as is required by the OSP.Log.
1235
4.3.4 Coverage of assumptions
1236
The following sections provide more detailed information about how the security objectives
1237
for the environment cover the assumptions.
1238
4.3.4.1 A.ExternalPrivacy
1239
The assumption A.ExternalPrivacy is directly and completely covered by the security
1240
objective OE.ExternalPrivacy. The assumption and the objective for the environment are
1241
drafted in a way that the correspondence is obvious.
1242
4.3.4.2 A.TrustedAdmins
1243
The assumption A.TrustedAdmins is directly and completely covered by the security
1244
objective OE.TrustedAdmins. The assumption and the objective for the environment are
1245
drafted in a way that the correspondence is obvious.
1246
4.3.4.3 A.PhysicalProtection
1247
The assumption A.PhysicalProtection is directly and completely covered by the security
1248
objective OE.PhysicalProtection. The assumption and the objective for the environment are
1249
drafted in a way that the correspondence is obvious.
1250
Security Target, SMGW Integrationsmodul Version 1.0
Page 64
4.3.4.4 A.ProcessProfile
1251
The assumption A.ProcessProfile is directly and completely covered by the security objective
1252
OE.Profile. The assumption and the objective for the environment are drafted in a way that
1253
the correspondence is obvious.
1254
4.3.4.5 A.Update
1255
The assumption A.Update is directly and completely covered by the security objective
1256
OE.Update. The assumption and the objective for the environment are drafted in a way that
1257
the correspondence is obvious.
1258
4.3.4.6 A.Network
1259
The assumption A.Network is directly and completely covered by the security objective
1260
OE.Network. The assumption and the objective for the environment are drafted in a way
1261
that the correspondence is obvious.
1262
4.3.4.7 A.Keygen
1263
The assumption A.Network is directly and completely covered by the security objective
1264
OE.Network. The assumption and the objective for the environment are drafted in a way
1265
that the correspondence is obvious.
1266
Security Target, SMGW Integrationsmodul Version 1.0
Page 65
5 Extended Component definition
1267
5.1 Communication concealing (FPR_CON)
1268
The additional family Communication concealing (FPR_CON) of the Class FPR (Privacy) is
1269
defined here to describe the specific IT security functional requirements of the TOE. The TOE
1270
shall prevent attacks against Personally Identifiable Information (PII) of the Consumer that
1271
may be obtained by an attacker by observing the encrypted communication of the TOE with
1272
remote entities.
1273
5.2 Family behaviour
1274
This family defines requirements to mitigate attacks against communication channels in
1275
which an attacker tries to obtain privacy relevant information based on characteristics of an
1276
encrypted communication channel. Examples include but are not limited to an analysis of the
1277
frequency of communication or the transmitted workload.
1278
5.3 Component levelling
1279
FPR_CON: Communication concealing ------------1
1280
5.4 Management
1281
The following actions could be considered for the management functions in FMT:
1282
a. Definition of the interval in FPR_CON.1.2 if definable within the operational phase of
1283
the TOE.
1284
5.5 Audit
1285
There are no auditable events foreseen.
1286
Security Target, SMGW Integrationsmodul Version 1.0
Page 66
5.6 Communication concealing (FPR_CON.1)
1287
Hierarchical to: No other components.
1288
Dependencies: No dependencies.
1289
FPR_CON.1.1 The TSF shall enforce the [assignment: information flow
1290
policy] in order to ensure that no personally identifiable
1291
information (PII) can be obtained by an analysis of
1292
[assignment: characteristics of the information flow that
1293
need to be concealed].
1294
FPR_CON.1.2 The TSF shall connect to [assignment: list of external
1295
entities] in intervals as follows [selection: weekly, daily,
1296
hourly, [assignment: other interval]] to conceal the data
1297
flow.
1298
Security Target, SMGW Integrationsmodul Version 1.0
Page 67
6 Security Requirements
1299
6.1 Overview
1300
This chapter describes the security functional and the assurance requirements which have to
1301
be fulfilled by the TOE. Those requirements comprise functional components from part 2 of
1302
[CC] and the assurance components as defined for the Evaluation Assurance Level 4 from
1303
part 3 of [CC].
1304
The following notations are used:
1305
• Refinement operation (denoted by bold text): is used to add details to a
1306
requirement, and thus further restricts a requirement. In case that a word has been
1307
deleted from the original text this refinement is indicated by crossed out bold text.
1308
• Selection operation (denoted by underlined text): is used to select one or more
1309
options provided by the [CC] in stating a requirement.
1310
• Assignment operation (denoted by italicised text): is used to assign a specific value to
1311
an unspecified parameter, such as the length of a password.
1312
• Iteration operation: are identified with a suffix in the name of the SFR (e.g.
1313
FDP_IFC.2/FW).
1314
It should be noted that the requirements in the following chapters are not necessarily be
1315
ordered alphabetically. Where useful the requirements have been grouped.
1316
The following table summarises all TOE security functional requirements of this ST:
1317
Class FAU: Security Audit
FAU_ARP.1/SYS Security alarms for system log
FAU_GEN.1/SYS Audit data generation for system log
FAU_SAA.1/SYS Potential violation analysis for system log
FAU_SAR.1/SYS Audit review for system log
FAU_STG.4/SYS Prevention of audit data loss for the system log
FAU_GEN.1/CON Audit data generation for consumer log
FAU_SAR.1/CON Audit review for consumer log
FAU_STG.4/CON Prevention of audit data loss for the consumer log
FAU_GEN.1/CAL Audit data generation for calibration log
Security Target, SMGW Integrationsmodul Version 1.0
Page 68
FAU_SAR.1/CAL Audit review for calibration log
FAU_STG.4/CAL Prevention of audit data loss for the calibration log
FAU_GEN.2 User identity association
FAU_STG.2 Guarantees of audit data availability
Class FCO: Communication
FCO_NRO.2 Enforced proof of origin
Class FCS: Cryptographic Support
FCS_CKM.1/TLS Cryptographic key generation for TLS
FCS_COP.1/TLS Cryptographic operation for TLS
FCS_CKM.1/CMS Cryptographic key generation for CMS
FCS_COP.1/CMS Cryptographic operation for CMS
FCS_CKM.1/MTR Cryptographic key generation for Meter communication encryption
FCS_COP.1/MTR Cryptographic operation for Meter communication encryption
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1/HASH Cryptographic operation for Signatures
FCS_COP.1/MEM Cryptographic operation for TSF and user data encryption
Class FDP: User Data Protection
FDP_ACC.2 Complete Access Control
FDP_ACF.1 Security attribute based access control
FDP_IFC.2/FW Complete information flow control for firewall
FDP_IFF.1/FW Simple security attributes for Firewall
FDP_IFC.2/MTR Complete information flow control for Meter information flow
FDP_IFF.1/MTR Simple security attributes for Meter information
FDP_RIP.2 Full residual information protection
FDP_SDI.2 Stored data integrity monitoring and action
Class FIA: Identification and Authentication
FIA_ATD.1 User attribute definition
FIA_AFL.1 Authentication failure handling
FIA_UAU.2 User authentication before any action
FIA_UAU.5 Multiple authentication mechanisms
FIA_UAU.6 Re-Authenticating
FIA_UID.2 User identification before any action
FIA_USB.1 User-subject binding
Class FMT: Security Management
FMT_MOF.1 Management of security functions behaviour
FMT_SMF.1 Specification of Management Functions
FMT_SMR.1 Security roles
FMT_MSA.1/AC Management of security attributes for Gateway access policy
FMT_MSA.3/AC Static attribute initialisation for Gateway access policy
FMT_MSA.1/FW Management of security attributes for Firewall policy
Security Target, SMGW Integrationsmodul Version 1.0
Page 69
FMT_MSA.3/FW Static attribute initialisation for Firewall policy
FMT_MSA.1/MTR Management of security attributes for Meter policy
FMT_MSA.3/MTR Static attribute initialisation for Meter policy
Class FPR: Privacy
FPR_CON.1 Communication Concealing
FPR_PSE.1 Pseudonymity
Class FPT: Protection of the TSF
FPT_FLS.1 Failure with preservation of secure state
FPT_RPL.1 Replay Detection
FPT_STM.1 Reliable time stamps
FPT_TST.1 TSF testing
FPT_PHP.1 Passive detection of physical attack
Class FTP: Trusted path/channels
FTP_ITC.1/WAN Inter-TSF trusted channel for WAN
FTP_ITC.1/MTR Inter-TSF trusted channel for Meter
FTP_ITC.1/USR Inter-TSF trusted channel for User
Table 9: List of Security Functional Requirements
1318
6.2 Class FAU: Security Audit
1319
6.2.1 Introduction
1320
The TOE compliant to this Security Target shall implement three different audit logs as
1321
defined in OSP.Log and O.Log. The following table provides an overview over the three audit
1322
logs before the following chapters introduce the SFRs related to those audit logs.
1323
System-Log Consumer-Log Calibration-Log
Purpose
• Inform the Gateway
Administrator about
security relevant events
• Log all events as defined
by Common Criteria [CC]
for the used SFR
• Log all system relevant
events on specific
functionality
• Automated alarms in
case of a cumulation of
• Inform the Consumer about
all information flows to the
WAN
• Inform the Consumer about
the Processing Profiles
• Inform the Consumer about
other metering data (not
billing-relevant)
• Inform the Consumer about
all billing-relevant data
needed to verify an invoice
• Track changes that
are relevant for the
calibration of the
TOE relevant data
needed to verify an
invoice
Security Target, SMGW Integrationsmodul Version 1.0
Page 70
Table 10: Overview over audit processes
1324
certain events
• Inform the Service
Technician about the
status of the Gateway
Data • As defined by CC part 2
• Augmented by specific
events for the security
functions
• Information about all
information flows to the WAN
• Information about the
current and the previous
Processing Profiles
• Non-billing-relevant Meter
Data
• Information about the system
status (including relevant
errors)
• Billing-relevant data needed
to verify an invoice
• Calibration relevant
data only
Access • Access by authorised
Gateway Administrator
and via IF_GW_WAN
only
• Events may only be
deleted by an authorised
Gateway Administrator
via IF_GW_WAN
• Read access by
authorised Service
Technician via
IF_GW_SRV only
• Read access by authorised
Consumer and via
IF_GW_CON only to the data
related to the current
consumer
• Read access by
authorised Gateway
Administrator and
via IF_GW_WAN
only
Deletion • Ring buffer.
• The availability of data
has to be ensured for a
sufficient amount of time
• Overwriting old events is
possible if the memory is
full.
• Ring buffer.
• The availability of data has to
be ensured for a sufficient
amount of time.
• Overwriting old events is
possible if the memory is full
• Retention period is set by
authorised Gateway
Administrator on request by
consumer, data older than
this are deleted.
• The availability of
data has to be
ensured over the
lifetime of the TOE.
Security Target, SMGW Integrationsmodul Version 1.0
Page 71
6.2.2 Security Requirements for the System Log
1325
6.2.2.1 Security audit automatic response (FAU_ARP)
1326
6.2.2.1.1 FAU_ARP.1/SYS: Security Alarms for system log
1327
FAU_ARP.1.1/SYS The TSF shall take inform an authorised Gateway Administrator and
1328
create a log entry in the system log 34 upon detection of a potential
1329
security violation.
1330
Hierarchical to: No other components
1331
Dependencies: FAU_SAA.1 Potential violation analysis
1332
6.2.2.2 Security audit data generation (FAU_GEN)
1333
6.2.2.2.1 FAU_GEN.1/SYS: Audit data generation for system log
1334
FAU_GEN.1.1/SYS The TSF shall be able to generate an audit record of the following
1335
auditable events:
1336
a) Start-up and shutdown of the audit functions;
1337
b) All auditable events for the basic35 level of audit; and
1338
c) other non privacy relevant auditable events: none 36.
1339
FAU_GEN.1.2/SYS The TSF shall record within each audit record at least the following
1340
information:
1341
a) Date and time of the event, type of event, subject identity (if
1342
applicable), and the outcome (success or failure) of the event; and
1343
b) For each audit event type, based on the auditable event definitions
1344
of the functional components included in the PP/ST37, other audit
1345
relevant information: none 38.
1346
Hierarchical to: No other components
1347
Dependencies: FPT_STM.1
1348
34 [assignment: list of actions]
35 [selection, choose one of: minimum, basic, detailed, not specified]
36 [assignment: other specifically defined auditable events]
37 [refinement: PP/ST]
38 [assignment: other audit relevant information]
Security Target, SMGW Integrationsmodul Version 1.0
Page 72
6.2.2.3 Security audit analysis (FAU_SAA)
1349
6.2.2.3.1 FAU_SAA.1/SYS: Potential violation analysis for system log
1350
FAU_SAA.1.1./SYS The TSF shall be able to apply a set of rules in monitoring the audited
1351
events and based upon these rules indicate a potential violation of
1352
the enforcement of the SFRs.
1353
FAU_SAA.1.2/SYS The TSF shall enforce the following rules for monitoring audited
1354
events:
1355
a) Accumulation or combination of
1356
• Start-up and shutdown of the audit functions
1357
• all auditable events for the basic level of audit
1358
• all types of failures in the TSF as listed in FPT_FLS.1 39
1359
known to indicate a potential security violation.
1360
b) any other rules: none 40.
1361
Hierarchical to: No other components
1362
Dependencies: FAU_GEN.1
1363
6.2.2.4 Security audit review (FAU_SAR)
1364
6.2.2.4.1 FAU_SAR.1/SYS: Audit Review for system log
1365
FAU_SAR.1.1/SYS The TSF shall provide only authorised Gateway Administrators via the
1366
IF_GW_WAN interface and authorised Service Technicians via the
1367
IF_GW_SRV interface 41 with the capability to read all information 42
1368
from the system audit records 43.
1369
FAU_SAR.1.2/SYS The TSF shall provide the audit records in a manner suitable for the
1370
user to interpret the information.
1371
Hierarchical to: No other components
1372
Dependencies: FAU_GEN.1
1373
39 [assignment: subset of defined auditable events]
40 [assignment: any other rules]
41 [assignment: authorised users]
42 [assignment: list of audit information]
43 [refinement: audit records]
Security Target, SMGW Integrationsmodul Version 1.0
Page 73
6.2.2.5 Security audit event storage (FAU_STG)
1374
6.2.2.5.1 FAU_STG.4/SYS: Prevention of audit data loss for system log
1375
FAU_STG.4.1/SYS The TSF shall overwrite the oldest stored audit records 44 and other
1376
actions to be taken in case of audit storage failure: none 45 if the
1377
system audit trail 46 is full.
1378
Hierarchical to: FAU_STG.3 Action in case of possible audit data loss
1379
Dependencies: FAU_STG.1 Protected audit trail storage
1380
Application Note 4: The size of the audit trail that is available before the oldest events get
1381
overwritten is configurable for the Gateway Administrator.
1382
6.2.3 Security Requirements for the Consumer Log
1383
6.2.3.1 Security audit data generation (FAU_GEN)
1384
6.2.3.1.1 FAU_GEN.1/CON: Audit data generation for consumer log
1385
FAU_GEN.1.1/CON The TSF shall be able to generate an audit record of the following
1386
auditable events:
1387
a) Start-up and shutdown of the audit functions;
1388
b) All auditable events for the not specified47 level of audit; and
1389
c) all audit events as listed in Table 11 and additional events: none 48.
1390
FAU_GEN.1.2/CON The TSF shall record within each audit record at least the following
1391
information:
1392
a) Date and time of the event, type of event, subject identity (if
1393
applicable), and the outcome (success or failure) of the event; and
1394
b) For each audit event type, based on the auditable event definitions
1395
of the functional components included in the PP/ST49, additional
1396
information as listed in Table 11 and additional events: none 50.
1397
44 [selection, choose one of: “ignore audited events”, “prevent audited events, except those taken by the authorised user with special
rights”, “overwrite the oldest stored audit records”]
45 [assignment: other actions to be taken in case of audit storage failure]
46 [refinement: audit trail]
47 [selection, choose one of: minimum, basic, detailed, not specified]
48 [assignment: other specifically defined auditable events]
49 [refinement: PP/ST]
Security Target, SMGW Integrationsmodul Version 1.0
Page 74
Hierarchical to: No other components
1398
Dependencies: FPT_STM.1
1399
Table 11: Events for consumer log
1400
6.2.3.2 Security audit review (FAU_SAR)
1401
6.2.3.2.1 FAU_SAR.1/CON: Audit Review for consumer log
1402
FAU_SAR.1.1/CON The TSF shall provide only authorised Consumer via the IF_GW_CON
1403
interface 51 with the capability to read all information that are
1404
related to them 52 from the consumer audit records 53.
1405
FAU_SAR.1.2/CON The TSF shall provide the audit records in a manner suitable for the
1406
user to interpret the information.
1407
Hierarchical to: No other components
1408
Dependencies: FAU_GEN.1
1409
Application Note 5: FAU_SAR.1.2/CON shall ensure that the Consumer is able to interpret
1410
the information that is provided to him in a way that allows him to
1411
verify the invoice.
1412
50 [assignment: other audit relevant information]
51 [assignment: authorised users]
52 [assignment: list of audit information]
53 [refinement: audit records]
Event Additional Information
Any change to a Processing Profile The new and the old Processing Profile
Any submission of Meter Data to an external entity The Processing Profile that lead to the
submission
The submitted values
Any submission of Meter Data that is not billing-
relevant
-
Billing-relevant data -
Any administrative action performed -
Relevant system status information including
relevant errors
-
Security Target, SMGW Integrationsmodul Version 1.0
Page 75
6.2.3.3 Security audit event storage (FAU_STG)
1413
6.2.3.3.1 FAU_STG.4/CON: Prevention of audit data loss for the consumer log
1414
FAU_STG.4.1/CON The TSF shall overwrite the oldest stored audit records and interrupt
1415
metrological operation in case that the oldest audit record must still
1416
be kept for billing verification 54 if the consumer audit trail is full.
1417
Hierarchical to: FAU_STG.3 Action in case of possible audit data loss
1418
Dependencies: FAU_STG.1 Protected audit trail storage
1419
Application Note 6: The size of the audit trail that is available before the oldest events get
1420
overwritten is configurable for the Gateway Administrator.
1421
6.2.4 Security Requirements for the Calibration Log
1422
6.2.4.1 Security audit data generation (FAU_GEN)
1423
6.2.4.1.1 FAU_GEN.1/CAL: Audit data generation for calibration log
1424
FAU_GEN.1.1/CAL The TSF shall be able to generate an audit record of the following
1425
auditable events:
1426
a) Start-up and shutdown of the audit functions;
1427
b) All auditable events for the not specified 55 level of audit; and
1428
c) all calibration-relevant information according to Table 1256.
1429
FAU_GEN.1.2/CAL The TSF shall record within each audit record at least the following
1430
information:
1431
a) Date and time of the event, type of event, subject identity (if
1432
applicable), and the outcome (success or failure) of the event; and
1433
b) For each audit event type, based on the auditable event definitions
1434
of the functional components included in the PP/ST 57, other audit
1435
relevant information: none 58.
1436
54 [assignment: other actions to be taken in case of audit storage failure]
55 [selection, choose one of: minimum, basic, detailed, not specified]
56 [assignment: other specifically defined auditable events]
57 [refinement: PP/ST]
58 [assignment: other audit relevant information]
Security Target, SMGW Integrationsmodul Version 1.0
Page 76
Hierarchical to: No other components
1437
Dependencies: FPT_STM.1
1438
Application Note 7: The calibration log serves to fulfil national requirements in the
1439
context of the calibration of the TOE.
1440
Event / Parameter Content
National calibration authority National calibration authority or certification body identifier (in
German ‚Prüfstellenbezeichnung‘), and year of calibration
(‚Eichjahr‘), year number of CE sign, and all changes of these
MUST be logged in calibration log.
Commissioning Commissioning of the SMGW MUST be logged in calibration log.
Calibration, diagnosis-test Cases of (re-)calibration, look-up, or diagnosis-test MUST be
logged in calibration log.
Event of self-test Initiation of self-test MUST be logged in calibration log.
New meter Connection and registration of a new meter MUST be logged in
calibration log.
Meter removal Removal of a meter from SMGW MUST be logged in calibration
log.
Change of tariffication profiles Every change (incl. parameter change) of a tariffication profile
according to [TR-03109-1, 4.4], provided the parameter is
relevant for calibration regulations (see below) as well as new
storage or removal of tariffication profiles MUST be logged in
calibration log.
Parameter relevant for calibration regulations are:
• Device-ID of a meter - Unique identifier of the meter,
which send the input values for a TAF
• OBIS value of the measured variable of the meter -
Unique value for the measured variable of the meter
for the used TAF
• Metering point name - Unique name of the metering
point
• Billing period - Period in which a billing should be done
• Consumer ID
• Validity period - Period for which the TAF is booked
• Definition of tariff stages - Defines different tariff
stages and associated OBIS values. Here it will be
defined which tariff stage is valid at the time of rule
set activation
Security Target, SMGW Integrationsmodul Version 1.0
Page 77
• Tariff switching time - Defines to the split second the
switching of tariff stages. The time points can be
defined as periodic values
• Register period - Time distance of two consecutive
measured value acquisitions for meter readings
Change of meter profiles Every change (incl. parameter change) of a meter profile
according to [TR-03109-1, 4.4], provided the parameter is
relevant for calibration regulations (see below) as well as new
storage or removal of meter profiles MUST be logged in
calibration log.
Parameter relevant for legal metrology are:
• Device-ID - Unique identifier of the meter according to
DIN 43863-5
• Key material - Public key for inner signature
(dependent on the used meter in LMN)
• Register period - Interval during receipt of meter
values
• Displaying interval (‘Anzeigeintervall’) - Interval during
which the actual meter value (only during display)
must be updated in case of bidirectional
communication between meter and SMGW
• Balancing (‘Saldierend’) - Determines if the meter is
balancing (‘saldierend’) and meter values can grow
and fall
• OBIS values - OBIS values according to IEC-62056-6-1
resp. EN 13757-1
• Converter factor (‘Wandlerfaktor’) - Value is 1 in case
of directly connected meter. In usage of converter
counter (‘Wandlerzähler’) the value may be different.
Software update Every update of the code which touches calibration regulations
(serialized COSEM-objects, rules) MUST be logged in calibration
log.
Firmware update Every firmware update (incl. OS update if applicable) MUST be
logged in calibration log.
Error messages of a meter All FATAL messages of a connected meter MUST be logged in
calibration log according to
0 - no error
1 - Warning, no action to be done according to calibration
authority, meter value valid
2 - Temporal error, send meter value will be marked as
Security Target, SMGW Integrationsmodul Version 1.0
Page 78
invalid, the value in meter field (‘Messwertfeld’) could be
used according to the rules of [VDE4400] resp. [G865] as
replacement value (‘Ersatzwert’) in backend.
3 - Temporal error, send meter value is invalid; the value in
the meter field (‘Messwertfeld’) cannot be used as
replacement value in backend.
4 - Fatal error (meter defect), actual send value is invalid
and all future values will be invalid.
including the device-ID.
Error messages of a SMGW All self-test and calibration regulations relevant errors MUST be
logged in calibration log.
Table 12: Content of calibration log
1441
6.2.4.2 Security audit review (FAU_SAR)
1442
6.2.4.2.1 FAU_SAR.1/CAL: Audit Review for the calibration log
1443
FAU_SAR.1.1/CAL The TSF shall provide only authorised Gateway Administrators via the
1444
IF_GW_WAN interface 59 with the capability to read all information 60
1445
from the calibration audit records 61.
1446
FAU_SAR.1.2/CAL The TSF shall provide the audit records in a manner suitable for the
1447
user to interpret the information.
1448
Hierarchical to: No other components
1449
Dependencies: FAU_GEN.1
1450
59 [assignment: authorised users]
60 [assignment: list of audit information]
61 [refinement: audit records]
Security Target, SMGW Integrationsmodul Version 1.0
Page 79
6.2.4.3 Security audit event storage (FAU_STG)
1451
6.2.4.3.1 FAU_STG.4/CAL: Prevention of audit data loss for calibration log
1452
FAU_STG.4.1/CAL The TSF shall ignore audited events 62 and stop the operation of the
1453
TOE and inform a Gateway Administrator 63 if the calibration audit
1454
trail 64 is full.
1455
Hierarchical to: FAU_STG.3 Action in case of possible audit data loss
1456
Dependencies: FAU_STG.1 Protected audit trail storage
1457
Application Note 8: As outlined in the introduction it has to be ensured that the events of
1458
the calibration log are available over the lifetime of the TOE.
1459
6.2.5 Security Requirements that apply to all logs
1460
6.2.5.1 Security audit data generation (FAU_GEN)
1461
6.2.5.1.1 FAU_GEN.2: User identity association
1462
FAU_GEN.2.1 For audit events resulting from actions of identified users, the TSF
1463
shall be able to associate each auditable event with the identity of
1464
the user that caused the event.
1465
Hierarchical to: No other components
1466
Dependencies: FAU_GEN.1
1467
FIA_UID.1
1468
Application Note 9: Please note that FAU_GEN.2 applies to all audit logs, the system log,
1469
the calibration log, and the consumer log.
1470
62 [selection, choose one of: “ignore audited events”, “prevent audited events, except those taken by the authorised user with special
rights”, “overwrite the oldest stored audit records”]
63 [assignment: other actions to be taken in case of audit storage failure]
64 [refinement: audit trail]
Security Target, SMGW Integrationsmodul Version 1.0
Page 80
6.2.5.2 Security audit event storage (FAU_STG)
1471
6.2.5.2.1 FAU_STG.2: Guarantees of audit data availability
1472
FAU_STG.2.1 The TSF shall protect the stored audit records in the all audit trails 65
1473
from unauthorised deletion.
1474
FAU_STG.2.2 The TSF shall be able to prevent 66 unauthorised modifications to the
1475
stored audit records in the all audit trails 67.
1476
FAU_STG.2.3 The TSF shall ensure that all 68 stored audit records will be
1477
maintained when the following conditions occur: audit storage
1478
exhaustion or failure 69.
1479
Hierarchical to: FAU_STG.1 Protected audit trail storage
1480
Dependencies: FAU_GEN.1
1481
Application Note 10: Please note that FAU_STG.2 applies to all audit logs, the system log,
1482
the calibration log, and the consumer log.
1483
65 [refinement: audit trail]
66 [selection, choose one of: prevent, detect]
67 [refinement: audit trail]
68 [assignment: metric for saving audit records]
69 [selection: audit storage exhaustion, failure, attack]
Security Target, SMGW Integrationsmodul Version 1.0
Page 81
6.3 Class FCO: Communication
1484
6.3.1 Non-repudiation of origin (FCO_NRO)
1485
6.3.1.1 FCO_NRO.2: Enforced proof of origin
1486
FCO_NRO.2.1 The TSF shall enforce the generation of evidence of origin for
1487
transmitted Meter Data 70 at all times.
1488
FCO_NRO.2.2 The TSF shall be able to relate the key material used for
1489
signature 71, 72 of the originator of the information, and the
1490
signature 73 of the information to which the evidence applies.
1491
FCO_NRO.2.3 The TSF shall provide a capability to verify the evidence of origin of
1492
information to recipient, Consumer 74 given limitations of the digital
1493
signature according to TR-03109-1 75.
1494
Hierarchical to: FCO_NRO.1 Selective proof of origin
1495
Dependencies: FIA_UID.1 Timing of identification
1496
Application Note 11: FCO_NRO.2 requires that the TOE calculates a signature over Meter
1497
Data that is submitted to external entities.
1498
Therefore, the TOE has to create a hash value over the Data To Be
1499
Signed (DTBS) as defined in FCS_COP.1/HASH. The creation of the
1500
actual signature however is performed by the Security Module.
1501
70 [assignment: list of information types]
71 [assignment: list of attributes]
72 The key material here also represents the identity of the Gateway.
73 [assignment: list of information fields]
74 [selection: originator, recipient, [assignment: list of third parties]]
75 [assignment: limitations on the evidence of origin]
Security Target, SMGW Integrationsmodul Version 1.0
Page 82
6.4 Class FCS: Cryptographic Support
1502
6.4.1 Cryptographic support for TLS
1503
6.4.1.1 Cryptographic key management (FCS_CKM)
1504
6.4.1.1.1 FCS_CKM.1/TLS: Cryptographic key generation for TLS
1505
FCS_CKM.1.1/TLS The TSF shall generate cryptographic keys in accordance with a
1506
specified cryptographic key generation algorithm TLS-PRF with SHA-
1507
256 or SHA-384 76 and specified cryptographic key sizes 128 bit, 256
1508
bit or 384 bit 77 that meet the following: [RFC 5246] in combination
1509
with [FIPS Pub. 180-4] and [RFC 2104] 78.
1510
Hierarchical to: No other components.
1511
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or
1512
FCS_COP.1 Cryptographic operation], fulfilled by FCS_COP .1/TLS
1513
FCS_CKM.4 Cryptographic key destruction
1514
Application Note 12: The Security Module is used for the generation of random numbers
1515
and for all cryptographic operations with the private key of a TLS
1516
certificate.
1517
Application Note 13: The TOE uses only cryptographic specifications and algorithms as
1518
described in [TR-03109-3].
1519
6.4.1.2 Cryptographic operation (FCS_COP)
1520
6.4.1.2.1 FCS_COP.1/TLS: Cryptographic operation for TLS
1521
FCS_COP.1.1/TLS The TSF shall perform TLS encryption, decryption, and integrity
1522
protection 79 in accordance with a specified cryptographic algorithm
1523
TLS cipher suites TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
1524
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
1525
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, and
1526
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 80 and
1527
76 [assignment: key generation algorithm]
77 [assignment: cryptographic key sizes]
78 [assignment: list of standards]
79 [assignment: list of cryptographic operations]
80 [assignment: cryptographic algorithm]
Security Target, SMGW Integrationsmodul Version 1.0
Page 83
cryptographic key sizes 128 bit or 256 bit 81 that meet the following:
1528
[RFC 2104], [RFC 5114], [RFC 5246], [RFC 5289], [RFC 5639],
1529
[NIST 800-38A], and [NIST 800-38D] 82.
1530
Hierarchical to: No other components.
1531
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
1532
FDP_ITC.2 Import of user data with security attributes, or
1533
FCS_CKM.1 Cryptographic key generation], fulfilled by
1534
FCS_CKM.1/TLS
1535
FCS_CKM.4 Cryptographic key destruction
1536
Application Note 14: The TOE uses only cryptographic specifications and algorithms as
1537
described in [TR-03109-3].
1538
6.4.2 Cryptographic support for CMS
1539
6.4.2.1 Cryptographic key management (FCS_CKM)
1540
6.4.2.1.1 FCS_CKM.1/CMS: Cryptographic key generation for CMS
1541
FCS_CKM.1.1/CMS The TSF shall generate cryptographic keys in accordance with a
1542
specified cryptographic key generation algorithm ECKA-EG 83 and
1543
specified cryptographic key sizes 128 bit 84 that meet the following:
1544
[X9.63] in combination with [RFC 3565] 85.
1545
Hierarchical to: No other components.
1546
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or
1547
FCS_COP.1 Cryptographic operation], fulfilled by FCS_COP.1/CMS
1548
FCS_CKM.4 Cryptographic key destruction
1549
Application Note 15: The TOE utilises the services of its Security Module for the generation
1550
of random numbers and for all cryptographic operations with the
1551
private asymmetric key of a CMS certificate.
1552
Application Note 16: The TOE uses only cryptographic specifications and algorithms as
1553
described in [TR-03109-3].
1554
81 [assignment: cryptographic key sizes]
82 [assignment: list of standards]
83 [assignment: cryptographic key generation algorithm]
84 [assignment: cryptographic key sizes]
85 [assignment: list of standards]
Security Target, SMGW Integrationsmodul Version 1.0
Page 84
6.4.2.2 Cryptographic operation (FCS_COP)
1555
6.4.2.2.1 FCS_COP.1/CMS: Cryptographic operation for CMS
1556
FCS_COP.1.1/CMS The TSF shall perform symmetric encryption, decryption and integrity
1557
protection in accordance with a specified cryptographic algorithm
1558
AES-CBC-CMAC or AES-GCM 86 and cryptographic key sizes 128 bit 87
1559
that meet the following: [FIPS Pub. 197], [NIST 800-38D], [RFC 4493],
1560
[RFC 5084], and [RFC 5652] in combination with [NIST 800-38A] 88.
1561
Hierarchical to: No other components.
1562
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
1563
FDP_ITC.2 Import of user data with security attributes, or
1564
FCS_CKM.1 Cryptographic key generation], fulfilled by
1565
FCS_CKM.1/CMS
1566
FCS_CKM.4 Cryptographic key destruction
1567
Application Note 17: The TOE uses only cryptographic specifications and algorithms as
1568
described in [TR-03109-3].
1569
86 [assignment: list of cryptographic operations]
87 [assignment: cryptographic key sizes]
88 [assignment: list of standards]
Security Target, SMGW Integrationsmodul Version 1.0
Page 85
6.4.3 Cryptographic support for Meter communication encryption
1570
6.4.3.1 Cryptographic key management (FCS_CKM)
1571
6.4.3.1.1 FCS_CKM.1/MTR: Cryptographic key generation for Meter
1572
communication (symmetric encryption)
1573
FCS_CKM.1.1/MTR The TSF shall generate cryptographic keys in accordance with a
1574
specified cryptographic key generation algorithm AES-CMAC 89 and
1575
specified cryptographic key sizes 128 bit 90 that meet the following:
1576
[FIPS Pub. 197], and [RFC 4493] 91.
1577
Hierarchical to: No other components.
1578
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or
1579
FCS_COP.1 Cryptographic operation], fulfilled by FCS_COP.1/MTR
1580
FCS_CKM.4 Cryptographic key destruction
1581
Application Note 18: The TOE uses only cryptographic specifications and algorithms as
1582
described in [TR-03109-3].
1583
6.4.3.2 Cryptographic operation (FCS_COP)
1584
6.4.3.2.1 FCS_COP.1/MTR: Cryptographic operation for Meter
1585
communication encryption
1586
FCS_COP.1.1/MTR The TSF shall perform symmetric encryption, decryption, integrity
1587
protection 92 in accordance with a specified cryptographic algorithm
1588
AES-CBC-CMAC 93 and cryptographic key sizes 128 bit 94 that meet
1589
the following: [FIPS Pub. 197] and [RFC 4493] in combination with
1590
[ISO 10116] 95.
1591
89 [assignment: cryptographic key generation algorithm]
90 [assignment: cryptographic key sizes]
91 [assignment: list of standards]
92 [assignment: list of cryptographic operations]
93 [assignment: cryptographic algorithm]
94 [assignment: cryptographic key sizes]
95 [assignment: list of standards]
Security Target, SMGW Integrationsmodul Version 1.0
Page 86
Hierarchical to: No other components.
1592
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
1593
FDP_ITC.2 Import of user data with security attributes, or
1594
FCS_CKM.1 Cryptographic key generation], fulfilled by
1595
FCS_CKM.1/MTR
1596
FCS_CKM.4 Cryptographic key destruction
1597
Application Note 19: The ST allows different scenarios of key generation for Meter
1598
communication encryption. Those are:
1599
1. If a TLS encryption is being used, the key
1600
generation/negotiation is as defined by FCS_CKM.1/TLS.
1601
2. If AES encryption is being used, the key has been brought into
1602
the Gateway via a management function during the pairing
1603
process for the Meter (see FMT_SMF.1) as defined by
1604
FCS_COP.1/MTR.
1605
Application Note 20: If the connection between the Meter and TOE is unidirectional, the
1606
communication between the Meter and the TOE is secured by the
1607
use of a symmetric AES encryption or by a TLS channel. If a
1608
bidirectional connection between the Meter and the TOE is
1609
established, the communication is secured by a TLS channel as
1610
described in chapter 6.4.1. As the TOE shall be interoperable with all
1611
kind of Meters, both kinds of encryption are implemented.
1612
Application Note 21: The TOE uses only cryptographic specifications and algorithms as
1613
described in [TR-03109-3].
1614
6.4.4 General Cryptographic support
1615
6.4.4.1 Cryptographic key management (FCS_CKM)
1616
6.4.4.1.1 FCS_CKM.4: Cryptographic key destruction
1617
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified
1618
cryptographic key destruction method Zeroisation 96 that meets the
1619
following: none 97.
1620
Hierarchical to: No other components.
1621
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
1622
96 [assignment: cryptographic key destruction method]
97 [assignment: list of standards]
Security Target, SMGW Integrationsmodul Version 1.0
Page 87
FDP_ITC.2 Import of user data with security attributes, or
1623
FCS_CKM.1 Cryptographic key generation], fulfilled by FCS_CKM.1/TLS and
1624
FCS_CKM.1/CMS and FCS_CKM.1/MTR
1625
Application Note 22: Please note that as against the requirement FDP_RIP.2, the mechanisms
1626
implementing the requirement from FCS_CKM.4 shall be suitable to avoid
1627
attackers with physical access to the TOE from accessing the keys after they
1628
are no longer used.
1629
6.4.4.2 Cryptographic operation (FCS_COP)
1630
6.4.4.2.1 FCS_COP.1/HASH: Cryptographic operation, hashing for signatures
1631
FCS_COP.1.1/HASH The TSF shall perform hashing for signature creation and verification 98 in
1632
accordance with a specified cryptographic algorithm SHA-256, SHA-384 and
1633
SHA-512 99 and cryptographic key sizes none 100 that meet the following:
1634
[FIPS Pub. 180-4] 101.
1635
Hierarchical to: No other components.
1636
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
1637
FDP_ITC.2 Import of user data with security attributes, or
1638
FCS_CKM.1 Cryptographic key generation 102]
1639
FCS_CKM.4 Cryptographic key destruction
1640
Application Note 23: The TOE is only responsible for hashing of data in the context of digital
1641
signatures. The actual signature operation and the handling (i.e. protection)
1642
of the cryptographic keys in this context is performed by the Security
1643
Module.
1644
Application Note 24: The TOE uses only cryptographic specifications and algorithms as described in
1645
[TR-03109-3].
1646
98 [assignment: list of cryptographic operations]
99 [assignment: cryptographic algorithm]
100 [assignment: cryptographic key sizes]
101 [assignment: list of standards]
102 The justification for the missing dependency FCS_CKM.1 can be found in chapter 6.12.1.3.
Security Target, SMGW Integrationsmodul Version 1.0
Page 88
6.4.4.2.2 FCS_COP.1/MEM: Cryptographic operation, encryption of TSF and user
1647
data
1648
FCS_COP.1.1/MEM The TSF shall perform TSF and user data encryption and decryption 103 in
1649
accordance with a specified cryptographic algorithm AES-XTS 104 and
1650
cryptographic key sizes 128 bit 105 that meet the following: [FIPS Pub. 197]
1651
and [NIST 800-38E] 106.
1652
Hierarchical to: No other components.
1653
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
1654
FDP_ITC.2 Import of user data with security attributes, or
1655
FCS_CKM.1 Cryptographic key generation], fulfilled by FCS_CKM.1/CMS
1656
FCS_CKM.4 Cryptographic key destruction
1657
Application Note 25: Please note that for the key generation process an external security module
1658
is used during TOE production.
1659
Application Note 26: The TOE encrypts its local TSF and user data while it is not in use (i.e. while
1660
stored in a persistent memory).
1661
It shall be noted that this kind of encryption cannot provide an absolute
1662
protection against physical manipulation and does not aim to. It however
1663
contributes to the security concept that considers the protection that is
1664
provided by the environment.
1665
6.5 Class FDP: User Data Protection
1666
6.5.1 Introduction to the Security Functional Policies
1667
The security functional requirements that are used in the following chapters implicitly define a set of
1668
Security Functional Policies (SFP). These policies are introduced in the following paragraphs in more
1669
detail to facilitate the understanding of the SFRs:
1670
103 [assignment: list of cryptographic operations]
104 [assignment: cryptographic algorithm]
105 [assignment: cryptographic key sizes]
106 [assignment: list of standards]
Security Target, SMGW Integrationsmodul Version 1.0
Page 89
• The Gateway access SFP is an access control policy to control the access to objects under the
1671
control of the TOE. The details of this access control policy highly depend on the concrete
1672
application of the TOE. The access control policy is described in more detail in [TR-03109-1].
1673
• The Firewall SFP implements an information flow policy to fulfil the objective O.Firewall. All
1674
requirements around the communication control that the TOE poses on communications
1675
between the different networks are defined in this policy.
1676
• The Meter SFP implements an information flow policy to fulfil the objective O.Meter. It
1677
defines all requirements concerning how the TOE shall handle Meter Data.
1678
6.5.2 Gateway Access SFP
1679
6.5.2.1 Access control policy (FDP_ACC)
1680
6.5.2.1.1 FDP_ACC.2: Complete access control
1681
FDP_ACC.2.1 The TSF shall enforce the Gateway access SFP 107 on
1682
subjects: external entities in WAN, HAN and LMN
1683
objects: any information that is sent to, from or via the TOE and any
1684
information that is stored in the TOE 108 and all operations among
1685
subjects and objects covered by the SFP.
1686
FDP_ACC.2.2 The TSF shall ensure that all operations between any subject controlled by
1687
the TSF and any object controlled by the TSF are covered by an access control
1688
SFP.
1689
Hierarchical to: FDP_ACC.1 Subset access control
1690
Dependencies: FDP_ACF.1 Security attribute based access control
1691
6.5.2.1.2 FDP_ACF.1: Security attribute based access control
1692
FDP_ACF.1.1 The TSF shall enforce the Gateway access SFP 109 to objects based on the
1693
following:
1694
107 [assignment: access control SFP]
108 [assignment: list of subjects and objects]
Security Target, SMGW Integrationsmodul Version 1.0
Page 90
subjects: external entities on the WAN, HAN or LMN side
1695
objects: any information that is sent to, from or via the TOE
1696
attributes: destination interface 110.
1697
FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation among
1698
controlled subjects and controlled objects is allowed:
1699
• an authorised Consumer is only allowed to have read access to his
1700
own User Data via the interface IF_GW_CON,
1701
• an authorised Service Technician is only allowed to have read access
1702
to the system log via the interface IF_GW_SRV, the Service Technician
1703
must not be allowed to read, modify or delete any other TSF data,
1704
• an authorised Gateway Administrator is allowed to interact with the
1705
TOE only via IF_GW_WAN,
1706
• only authorised Gateway Administrators are allowed to establish a
1707
wake-up call,
1708
• additional rules governing access among controlled subjects and
1709
controlled objects using controlled operations on controlled objects or
1710
none: none 111. 112
1711
FDP_ACF.1.3 The TSF shall explicitly authorise access of subjects to objects based on the
1712
following additional rules: none 113.
1713
FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the
1714
following additional rules:
1715
• the Gateway Administrator is not allowed to read consumption data
1716
or the Consumer Log,
1717
• nobody must be allowed to read the symmetric keys used for
1718
encryption 114.
1719
Hierarchical to: No other components
1720
Dependencies: FDP_ACC.1 Subset access control
1721
FMT_MSA.3 Static attribute initialisation
1722
109 [assignment: access control SFP]
110 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or
named groups of SFP-relevant security attributes]
111 [assignment: additional rules governing access among controlled subjects and controlled objects using controlled operations on
controlled objects or none]
112 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled
objects]
113 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects]
114 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]
Security Target, SMGW Integrationsmodul Version 1.0
Page 91
6.5.3 Firewall SFP
1723
6.5.3.1 Information flow control policy (FDP_IFC)
1724
6.5.3.1.1 FDP_IFC.2/FW: Complete information flow control for firewall
1725
FDP_IFC.2.1/FW The TSF shall enforce the Firewall SFP 115 on the TOE, external entities on the
1726
WAN side, external entities on the LAN side and all information flowing
1727
between them 116 and all operations that cause that information to flow to
1728
and from subjects covered by the SFP.
1729
FDP_IFC.2.2/FW The TSF shall ensure that all operations that cause any information in the TOE
1730
to flow to and from any subject in the TOE are covered by an information
1731
flow control SFP.
1732
Hierarchical to: FDP_IFC.1 Subset information flow control
1733
Dependencies: FDP_IFF.1 Simple security attributes
1734
6.5.3.2 Information flow control functions (FDP_IFF)
1735
6.5.3.2.1 FDP_IFF.1/FW: Simple security attributes for Firewall
1736
FDP_IFF.1.1/FW The TSF shall enforce the Firewall SFP 117 based on the following types of
1737
subject and information security attributes:
1738
subjects: The TOE and external entities on the WAN, HAN or LMN side
1739
information: any information that is sent to, from or via the TOE
1740
attributes: destination_interface (TOE, LMN, HAN or WAN),
1741
source_interface (TOE, LMN, HAN or WAN), destination_authenticated,
1742
source_authenticated 118.
1743
FDP_IFF.1.2/FW The TSF shall permit an information flow between a controlled subject and
1744
controlled information via a controlled operation if the following rules hold:
1745
(if source_interface=HAN or source_interface=TOE) and
1746
destination_interface=WAN and
1747
destination_authenticated = true
1748
Connection establishment is allowed
1749
1750
115 [assignment: information flow control SFP]
116 [assignment: list of subjects and information]
117 [assignment: information flow control SFP]
118 [assignment: list of subjects and information controlled under the indicated SFP, and for each, the security attributes]
Security Target, SMGW Integrationsmodul Version 1.0
Page 92
if source_interface=LMN and
1751
destination_interface= TOE and
1752
source_authenticated = true
1753
Connection establishment is allowed
1754
1755
if source_interface=TOE and
1756
destination_interface= LMN and
1757
destination_authenticated = true
1758
Connection establishment is allowed
1759
1760
if source_interface=HAN and
1761
destination_interface= TOE and
1762
source_authenticated = true
1763
Connection establishment is allowed
1764
1765
if source_interface=TOE and
1766
destination_interface= HAN and
1767
destination_authenticated = true
1768
Connection establishment is allowed
1769
else
1770
Connection establishment is denied 119.
1771
FDP_IFF.1.3/FW The TSF shall enforce the establishment of a connection to a configured
1772
external entity in the WAN after having received a wake-up message on the
1773
WAN interface 120.
1774
FDP_IFF.1.4/FW The TSF shall explicitly authorise an information flow based on the following
1775
rules: none 121.
1776
FDP_IFF.1.5/FW The TSF shall explicitly deny an information flow based on the following rules:
1777
none 122.
1778
Hierarchical to: No other components
1779
Dependencies: FDP_IFC.1 Subset information flow control
1780
FMT_MSA.3 Static attribute initialisation
1781
Application Note 27: It should be noted that the FDP_IFF.1.1/FW facilitates different interfaces of
1782
the origin and the destination of an information flow implicitly requires the
1783
TOE to implement physically separate ports for WAN, LMN and HAN.
1784
119 [assignment: for each operation, the security attribute-based relationship that must hold between subject and information security
attributes]
120 [assignment: additional information flow control SFP rules]
121 [assignment: rules, based on security attributes, that explicitly authorise information flows]
122 [assignment: rules, based on security attributes, that explicitly deny information flows]
Security Target, SMGW Integrationsmodul Version 1.0
Page 93
6.5.4 Meter SFP
1785
6.5.4.1 Information flow control policy (FDP_IFC)
1786
6.5.4.1.1 FDP_IFC.2/MTR: Complete information flow control for Meter information
1787
flow
1788
FDP_IFC.2.1/MTR The TSF shall enforce the Meter SFP 123 on the TOE, attached Meters,
1789
authorized External Entities in the WAN and all information flowing between
1790
them 124 and all operations that cause that information to flow to and from
1791
subjects covered by the SFP.
1792
FDP_IFC.2.2/MTR The TSF shall ensure that all operations that cause any information in the TOE
1793
to flow to and from any subject in the TOE are covered by an information
1794
flow control SFP.
1795
Hierarchical to: FDP_IFC.1 Subset information flow control
1796
Dependencies: FDP_IFF.1 Simple security attributes
1797
6.5.4.2 Information flow control functions (FDP_IFF)
1798
6.5.4.2.1 FDP_IFF.1/MTR: Simple security attributes for Meter information
1799
FDP_IFF.1.1/MTR The TSF shall enforce the Meter SFP 125 based on the following types of
1800
subject and information security attributes:
1801
• subjects: TOE, external entities in WAN, Meters located in LMN
1802
• information: any information that is sent via the TOE
1803
• attributes: destination interface, source interface (LMN or WAN),
1804
Processing Profile 126.
1805
FDP_IFF.1.2/MTR The TSF shall permit an information flow between a controlled subject and
1806
controlled information via a controlled operation if the following rules hold:
1807
• an information flow shall only be initiated if allowed by a
1808
corresponding Processing Profile 127.
1809
123 [assignment: information flow control SFP]
124 [assignment: list of subjects and information]
125 [assignment: information flow control SFP]
126 [assignment: list of subjects and information controlled under the indicated SFP, and for each, the security attributes]
Security Target, SMGW Integrationsmodul Version 1.0
Page 94
FDP_IFF.1.3/MTR The TSF shall enforce the following rules:
1810
• Data received from Meters shall be processed as defined in the
1811
corresponding Processing Profiles,
1812
• Results of processing of Meter Data shall be submitted to external
1813
entities as defined in the Processing Profiles,
1814
• The internal system time shall be synchronised as follows:
1815
o The TOE shall compare the system time to a reliable external
1816
time source every 24 hours 128.
1817
o If the deviation between the local time and the remote time is
1818
acceptable 129, the local system time shall be updated
1819
according to the remote time.
1820
o If the deviation is not acceptable the TOE
1821
shall ensure that any following Meter Data is not used,
1822
stop operation 130 and
1823
inform a Gateway Administrator 131.
1824
FDP_IFF.1.4/MTR The TSF shall explicitly authorise an information flow based on the following
1825
rules: none 132.
1826
FDP_IFF.1.5/MTR The TSF shall explicitly deny an information flow based on the following rules:
1827
The TOE shall deny any acceptance of information by external entities in the
1828
LMN unless the authenticity, integrity and confidentiality of the Meter Data
1829
could be verified 133.
1830
Hierarchical to: No other components
1831
Dependencies: FDP_IFC.1 Subset information flow control
1832
FMT_MSA.3 Static attribute initialisation
1833
Application Note 28: FDP_IFF.1.3 defines that the TOE shall update the local system time regularly
1834
with reliable external time sources if the deviation is acceptable. In the
1835
context of this functionality two aspects should be mentioned:
1836
127 [assignment: for each operation, the security attribute-based relationship that must hold between subject and information security
attributes]
128 [assignment: synchronization interval between 1 minute and 24 hours]
129 Please refer to the following application note for a detailed definition of “acceptable”.
130 Please note that this refers to the complete functional operation of the TOE and not only to the update of local time. However, an
administrative access shall still be possible.
131 [assignment: additional information flow control SFP rules]
132 [assignment: rules, based on security attributes, that explicitly authorise information flows]
133 [assignment: rules, based on security attributes, that explicitly deny information flows]
Security Target, SMGW Integrationsmodul Version 1.0
Page 95
Reliability of external source
1837
There are several ways to achieve the reliability of the external source. On
1838
the one hand, there may be a source in the WAN that has an acceptable
1839
reliability on its own (e.g. because it is operated by a very trustworthy
1840
organisation (an official legal time issued by the calibration authority would
1841
be a good example for such a source134)). On the other hand a developer
1842
may choose to maintain multiple external sources that all have a certain level
1843
of reliability but no absolute reliability. When using such sources the TOE
1844
shall contact more than one source and harmonize the results in order to
1845
ensure that no attack happened.
1846
Acceptable deviation
1847
For the question whether a deviation between the time source(s) in the WAN
1848
and the local system time is still acceptable, normative or legislative
1849
regulations shall be considered. If no regulation exists, a maximum deviation
1850
of 3% of the measuring period is allowed to be in conformance with
1851
[PP_GW]. It should be noted that depending on the kind of application a
1852
more accurate system time is needed. For doing so, the intervall for the
1853
comparison of the system time to a reliable external time source is
1854
configurable. But this aspect is not within the scope of this Security Target.
1855
Please further note that – depending on the exactness of the local clock – it
1856
may be required to synchronize the time more often than every 24 hours.
1857
Application Note 29: In FDP_IFF.1.5/MTR the TOE is required to verify the authenticity, integrity
1858
and confidentiality of the Meter Data received from the Meter. The TOE has
1859
two options to do so:
1860
1. To implement a channel between the Meter and the TOE using
1861
the functionality as described in FCS_COP.1/TLS.
1862
2. To accept, decrypt and verify data that has been encrypted by
1863
the Meter as required in FCS_COP.1/MTR if a wireless connection
1864
to the meters is established.
1865
The latter possibility can be used only if a wireless connection between the
1866
Meter and the TOE is established.
1867
134 By the time that this ST is developed however, this time source is not yet available.
Security Target, SMGW Integrationsmodul Version 1.0
Page 96
6.5.5 General Requirements on user data protection
1868
6.5.5.1 Residual information protection (FDP_RIP)
1869
6.5.5.1.1 FDP_RIP.2: Full residual information protection
1870
FDP_RIP.2.1 The TSF shall ensure that any previous information content of a resource is
1871
made unavailable upon the deallocation of the resource from 135 all objects.
1872
Hierarchical to: FDP_RIP.1 Subset residual information protection
1873
Dependencies: No dependencies.
1874
Application Note 30: Please refer to chapter F.9 of part 2 of [CC] for more detailed information
1875
about what kind of information this requirement applies to.
1876
Please further note that this SFR has been used in order to ensure that
1877
information that is no longer used is made unavailable from a logical
1878
perspective. Specifically, it has to be ensured that this information is not
1879
longer available via an external interface (even if an access control or
1880
information flow policy would fail). However, this does not necessarily mean
1881
that the information is overwritten in a way that makes it impossible for an
1882
attacker to get access to is assuming a physical access to the memory of the
1883
TOE.
1884
6.5.5.2 Stored data integrity (FDP_SDI)
1885
6.5.5.2.1 FDP_SDI.2: Stored data integrity monitoring and action
1886
FDP_SDI.2.1 The TSF shall monitor user data stored in containers controlled by the TSF for
1887
integrity errors 136 on all objects, based on the following attributes:
1888
cryptographical check sum 137.
1889
FDP_SDI.2.2 Upon detection of a data integrity error, the TSF shall create a system log
1890
entry138.
1891
Hierarchical to: FDP_SDI.1 Stored data integrity monitoring
1892
Dependencies: No dependencies.
1893
135 [selection: allocation of the resource to, deallocation of the resource from]
136 [assignment: integrity errors]
137 [assignment: user data attributes]
138 [assignment: action to be taken]
Security Target, SMGW Integrationsmodul Version 1.0
Page 97
6.6 Class FIA: Identification and Authentication
1894
6.6.1 User Attribute Definition (FIA_ATD)
1895
6.6.1.1 FIA_ATD.1: User attribute definition
1896
FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to
1897
individual users:
1898
• User Identity
1899
• Status of Identity (Authenticated or not)
1900
• Connecting network (WAN, HAN or LMN)
1901
• Role membership
1902
• none 139.
1903
Hierarchical to: No other components.
1904
Dependencies: No dependencies.
1905
6.6.2 Authentication Failures (FIA_AFL)
1906
6.6.2.1 FIA_AFL.1: Authentication failure handling
1907
FIA_AFL.1.1 The TSF shall detect when 5 140 unsuccessful authentication attempts occur
1908
related to authentication attempts at IF_GW_CON 141.
1909
FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been
1910
met 142, the TSF shall block IF_GW_CON for 5 minutes 143.
1911
Hierarchical to: No other components
1912
Dependencies: FIA_UAU.1 Timing of authentication
1913
139 [assignment: list of security attributes]
140 [selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of
acceptable values]]
141 [assignment: list of authentication events]
142 [selection: met, surpassed]
143 [assignment: list of actions]
Security Target, SMGW Integrationsmodul Version 1.0
Page 98
6.6.3 User Authentication (FIA_UAU)
1914
6.6.3.1 FIA_UAU.2: User authentication before any action
1915
FIA_UAU.2.1 The TSF shall require each user to be successfully authenticated before
1916
allowing any other TSF-mediated actions on behalf of that user.
1917
Hierarchical to: FIA_UAU.1
1918
Dependencies: FIA_UID.1 Timing of identification
1919
Application Note 31: Please refer to [TR-03109-1] for a more detailed overview on the
1920
authentication of TOE users.
1921
6.6.3.2 FIA_UAU.5: Multiple authentication mechanisms
1922
FIA_UAU.5.1 The TSF shall provide
1923
• authentication via certificates at the IF_GW_MTR interface
1924
• TLS-authentication via certificates at the IF_GW_WAN interface
1925
• TLS-authentication via HAN-certificates at the IF_GW_CON interface
1926
• authentication via password at the IF_GW_CON interface
1927
• TLS-authentication via HAN-certificates at the IF_GW_SRV interface
1928
• authentication at the IF_GW_CLS interface
1929
• verification via a commands' signature 144
1930
to support user authentication.
1931
FIA_UAU.5.2 The TSF shall authenticate any user's claimed identity according to the
1932
• meters shall be authenticated via certificates at the IF_GW_MTR
1933
interface only
1934
• Gateway Administrators shall be authenticated via TLS-certificates at the
1935
IF_GW_WAN interface only
1936
• Consumers shall be authenticated via TLS-certificates or via password at
1937
the IF_GW_CON interface only
1938
• Service Technicians shall be authenticated via TLS-certificates at the
1939
IF_GW_SRV interface only
1940
• CLS shall be authenticated at the IF_GW_CLS only
1941
• each command of an Gateway Administrator shall be authenticated by
1942
verification of the commands' signature,
1943
• other external entities shall be authenticated via TLS-certificates at the
1944
IF_GW_WAN interface only 145.
1945
144 [assignment: list of multiple authentication mechanisms]
Security Target, SMGW Integrationsmodul Version 1.0
Page 99
Hierarchical to: No other components.
1946
Dependencies: No dependencies.
1947
Application Note 32: Please refer to [TR-03109-1] for a more detailed overview on the
1948
authentication of TOE users.
1949
6.6.3.3 FIA_UAU.6: Re-authenticating
1950
FIA_UAU.6.1 The TSF shall re-authenticate an external entity 146 under the conditions
1951
• TLS channel to the WAN shall be disconnected after 48 hours,
1952
• TLS channel to the LMN shall be disconnected after 5 MB of transmitted
1953
information,
1954
• other local users shall be re-authenticated after 10 minutes of
1955
inactivity 147.
1956
Hierarchical to: No other components.
1957
Dependencies: No dependencies.
1958
Application Note 33: This requirement on re-authentication for external entities in the WAN and
1959
LMN is addressed by disconnecting the TLS channel even though a re-
1960
authentication is - strictly speaking - only achieved if the TLS channel is build
1961
up again.
1962
6.6.4 User identification (FIA_UID)
1963
6.6.4.1 FIA_UID.2: User identification before any action
1964
FIA_UID.2.1 The TSF shall require each user to be successfully identified before allowing
1965
any other TSF-mediated actions on behalf of that user.
1966
Hierarchical to: FIA_UID.1
1967
Dependencies: No dependencies.
1968
145 [assignment: rules describing how the multiple authentication mechanisms provide authentication]
146 [refinement: the user]
147 [assignment: list of conditions under which re-authentication is required]
Security Target, SMGW Integrationsmodul Version 1.0
Page 100
6.6.5 User-subject binding (FIA_USB)
1969
6.6.5.1 FIA_USB.1: User-subject binding
1970
FIA_USB.1.1 The TSF shall associate the following user security attributes with subjects
1971
acting on the behalf of that user: attributes as defined in FIA_ATD.1 148.
1972
FIA_USB.1.2 The TSF shall enforce the following rules on the initial association of user
1973
security attributes with subjects acting on the behalf of users:
1974
• The initial value of the security attribute ‘connecting network’ is set to
1975
the corresponding physical interface of the TOE (HAN, WAN, or LMN).
1976
• The initial value of the security attribute ‘role membership’ is set to
1977
the user role claimed on basis of the credentials used for
1978
authentication at the connecting network as defined in FIA_UAU.5.2.
1979
For role membership ‘Gateway Administrators’, additionally the
1980
remote network endpoint 149used and configured in the TSF data
1981
must be identical.
1982
• The initial value of the security attribute ‘user identity’ is set to the
1983
identification attribute of the credentials used by the subject. The
1984
security attribute ‘user identity’ is set to the subject key ID of the
1985
certificate in case of a certificate-based authentication, the meter-ID
1986
for wired Meters and the user name owner in case of a password-
1987
based authentication at interface IF_GW_CON.
1988
• The initial value of the security attribute ‘status of identity’ is set to
1989
the authentication status of the claimed identity. If the authentication
1990
is successful on basis of the used credentials, the status of identity is
1991
‘authenticated’, otherwise it is ‘not authenticated’ 150.
1992
FIA_USB.1.3 The TSF shall enforce the following rules governing changes to the user
1993
security attributes associated with subjects acting on the behalf of users:
1994
• security attribute ‘connecting network’ is not changeable.
1995
• security attribute ‘role membership’ is not changeable.
1996
• security attribute ‘user identity’ is not changeable.
1997
• security attribute ‘status of identity’ is not changeable151.
1998
Hierarchical to: No other components.
1999
Dependencies: FIA_ATD.1 User attribute definition
2000
148 [assignment: list of user security attributes]
149 The remote network endpoint can be either the remote IP address or the remote host name.
150 [assignment: rules for the initial association of attributes]
151 [assignment: rules for the changing of attributes]
Security Target, SMGW Integrationsmodul Version 1.0
Page 101
6.7 Class FMT: Security Management
2001
6.7.1 Management of the TSF
2002
6.7.1.1 Management of functions in TSF (FMT_MOF)
2003
6.7.1.1.1 FMT_MOF.1: Management of security functions behaviour
2004
FMT_MOF.1.1 The TSF shall restrict the ability to modify the behaviour of 152 the functions
2005
for management as defined in FMT_SMF.1 153 to roles and criteria as defined
2006
in Table 13 154.
2007
Hierarchical to: No other components.
2008
Dependencies: FMT_SMR.1 Security roles
2009
FMT_SMF.1 Specification of Management Functions
2010
152 [selection: determine the behaviour of, disable, enable, modify the behaviour of]
153 [assignment: list of functions]
154 [assignment: the authorised identified roles]
155 The TOE displays the version number of the TOE and the current time of the TOE also to the authorized service technician via the
interface IF_GW_SRV because the service technician must be able to determine if the current time of the TOE is correct or if the
version number of the TOE is correct.
156 This criterion applies to all management functions. The following entries in this table only augment this restriction further.
Function Limitation
Display the version number of the TOE
Display the current time
The management functions must only be accessible
for an authorised Consumer and only via the interface
IF_GW_CON. An authorized Service Technician is also
able to access the version numer of the TOE and the
current time of the TOE via interface IF_GW_SRV 155.
All other management functions as defined
in FMT_SMF.1
The management functions must only be accessible
for an authorised Gateway Administrator and only via
the interface IF_GW_WAN 156.
Firmware Update The firmware update must only be possible after the
authenticity of the firmware update has been verified
(using the services of the Security Module and the
trust anchor of the Gateway developer) and if the
version number of the new firmware is higher to the
version of the installed firmware.
Deletion or modification of events from the
Calibration Log
A deletion or modification of events from the
calibration log must not be possible.
Security Target, SMGW Integrationsmodul Version 1.0
Page 102
Table 13: Restrictions on Management Functions
2011
6.7.1.2 Specification of Management Functions (FMT_SMF)
2012
6.7.1.2.1 FMT_SMF.1: Specification of Management Functions
2013
FMT_SMF.1.1 The TSF shall be capable of performing the following management functions:
2014
list of management functions as defined in Table 14 and Table 15 and
2015
additional functionalities: none 157.
2016
Hierarchical to: No other components.
2017
Dependencies: No dependencies.
2018
157 [assignment: list of management functions to be provided by the TSF]
158 The TOE does not have the indicated management ability since there exist no standard method calls for the Gateway
Administrator to enforce the such management ability.
159 As the rules for audit review are fixed within [PP_GW], the management functions as defined by [CC, part 2] do not apply.
160 As the actions that shall be performed if the audit trail is full are fixed within [PP_GW], the management functions as defined by
[CC, part 2] do not apply.
SFR Management functionality
FAU_ARP.1/SYS • The management (addition, removal, or modification) of actions158
FAU_GEN.1/SYS
FAU_GEN.1/CON
FAU_GEN.1/CAL
-
FAU_SAA.1/SYS • Maintenance of the rules by (adding, modifying, deletion) of rules from
the set of rules 158
FAU_SAR.1/SYS
FAU_SAR.1/CON
FAU_SAR.1/CAL
- 159
FAU_STG.4/SYS
FAU_STG.4/CON
• Maintenance (deletion, modification, addition) of actions to be taken
in case of audit storage failure 158
• Size configuration of the audit trail that is available before the oldest
events get overwritten158
FAU_STG.4/CAL - 160
FAU_GEN.2 -
FAU_STG.2 • Maintenance of the parameters that control the audit storage capability
for the consumer log and the system log158
FCO_NRO.2 • The management of changes to information types, fields, 158
originator
attributes and recipients of evidence
FCS_CKM.1/TLS -
Security Target, SMGW Integrationsmodul Version 1.0
Page 103
161 In the assignment it is not indicated that the authorized Gateway Administrator might be able to define additional security
attributes for users.
162 As the rules for re-authentication are fixed within [PP_GW], the management functions as defined by [CC, part 2] do not apply.
163 As the rules for re-authentication are fixed within [PP_GW], the management functions as defined by [CC, part 2] do not apply.
FCS_COP.1/TLS • Management of key material including key material stored in the
Security Module
FCS_CKM.1/CMS -
FCS_COP.1/CMS • Management of key material including key material stored in the
Security Module
FCS_CKM.1/MTR -
FCS_COP.1/MTR • Management of key material stored in the Security Module and key
material brought into the gateway during the pairing process
FCS_CKM.4 -
FCS_COP.1/HASH -
FCS_COP.1/MEM • Management of key material
FDP_ACC.2 -
FDP_ACF.1 -
FDP_IFC.2/FW -
FDP_IFF.1/FW • Managing the attributes used to make explicit access based decisions
• Add authorised units for communication (pairing)
• Management of endpoint to be contacted after successful wake-up call
• Management of CLS systems
FDP_IFC.2/MTR -
FDP_IFF.1/MTR • Managing the attributes (including Processing Profiles) used to make
explicit access based decisions
FDP_RIP.2 -
FDP_SDI.2 • The actions to be taken upon the detection of an integrity error shall
be configurable. 158
FIA_ATD.1 • If so indicated in the assignment, the authorised Gateway Administrator
might be able to define additional security attributes for users161.
FIA_AFL.1 • Management of the threshold for unsuccessful authentication
attempts158
• Management of actions to be taken in the event of an authentication
failure158
FIA_UAU.2 • Management of the authentication data by an Gateway Administrator
FIA_UAU.5 - 162
FIA_UAU.6 - 163
FIA_UID.2 • The management of the user identities
Security Target, SMGW Integrationsmodul Version 1.0
Page 104
164 As the role that can interact with the security attributes is restricted to the Gateway Administrator within [PP_GW], not all
management functions as defined by [CC, part 2] do apply.
165 As no role is allowed to specify alternative initial values within [PP_GW], the management functions as defined by [CC, part 2] do
not apply.
166 As the role that can read, modify, delete or add the security attributes is restricted to the Gateway Administrator within [PP_GW],
not all management functions as defined by [CC, part 2] do apply.
167 As no role is allowed to specify alternative initial values within [PP_GW], the management functions as defined by [CC, part 2] do
not apply.
168 As the role that can read, modify, delete or add the security attributes is restricted to the Gateway Administrator within [PP_GW],
not all management functions as defined by [CC, part 2] do apply.
169 As no role is allowed to specify alternative initial values within [PP_GW], the management functions as defined by [CC, part 2] do
not apply.
FIA_USB.1 • An authorised Gateway Administrator can define default subject
security attributes, if so indicated in the assignment of FIA_ATD.1. 158
• An authorised Gateway Administrator can change subject security
attributes, if so indicated in the assignment of FIA_ATD.1. 158
FMT_MOF.1 • Managing the group of roles that can interact with the functions in the
TSF
FMT_SMF.1 -
FMT_SMR.1 • Managing the group of users that are part of a role
FMT_MSA.1/AC • Management of rules by which security attributes inherit specified
values 164 158
FMT_MSA.3/AC - 165
FMT_MSA.1/FW • Management of rules by which security attributes inherit specified
values 166 158
FMT_MSA.3/FW - 167
FMT_MSA.1/MTR • Management of rules by which security attributes inherit specified
values 168 158
FMT_MSA.3/MTR - 169
FPR_CON.1 • Definition of the interval in FPR_CON.1.2 if definable within the
operational phase of the TOE 158
FPR_PSE.1 -
FPT_FLS.1 -
FPT_RPL.1 -
Security Target, SMGW Integrationsmodul Version 1.0
Page 105
Table 14: SFR related Management Functionalities
2019
Table 15: Gateway specific Management Functionalities
2020
6.7.2 Security management roles (FMT_SMR)
2021
6.7.2.1 FMT_SMR.1: Security roles
2022
FMT_SMR.1.1 The TSF shall maintain the roles authorised Consumer, authorised Gateway
2023
Administrator, authorised Service Technician, the authorised identified roles:
2024
authorised external entity, CLS, and Meter 175.
2025
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
2026
Hierarchical to: No other components.
2027
170 As the rules for TSF testing are fixed within [PP_GW], the management functions as defined by [CC, part 2] do not apply.
171 As the configuration of the actions that require a trusted channel is fixed by [PP_GW], the management functions as defined in
[CC, part 2] do not apply.
172 As the configuration of the actions that require a trusted channel is fixed by [PP_GW], the management functions as defined in
[CC, part 2] do not apply.
173 As the configuration of the actions that require a trusted channel is fixed by [PP_GW], the management functions as defined in
[CC, part 2] do not apply.
174 Resetting the TOE will be necessary when the TOE stopped operation due to a critical deviation between local and remote time
(see FDP_IFF.1.3/MTR)or when the calibration log is full.
175 [assignment: the authorised identified roles]
FPT_STM.1 • Management a time source
FPT_TST.1 - 170
FPT_PHP.1 • Management of the user or role that determines whether physical
tampering has occurred 158
FTP_ITC.1/WAN - 171
FTP_ITC.1/MTR - 172
FTP_ITC.1/USR - 173
Gateway specific Management functionality
Pairing of a Meter
Performing a firmware update
Displaying the current version number of the TOE
Displaying the current time
Management of certificates of external entities in the WAN for communication
Resetting of the TOE 174
Security Target, SMGW Integrationsmodul Version 1.0
Page 106
Dependencies: No dependencies.
2028
6.7.3 Management of security attributes for Gateway access SFP
2029
6.7.3.1 Management of security attributes (FMT_MSA)
2030
6.7.3.1.1 FMT_MSA.1/AC: Management of security attributes for Gateway access
2031
SFP
2032
FMT_MSA.1.1/AC The TSF shall enforce the Gateway access SFP 176 to restrict the ability to
2033
query, modify, delete, other operations: none 177 the security attributes all
2034
relevant security attributes 178 to authorised Gateway Administrators 179.
2035
Hierarchical to: No other components.
2036
Dependencies: [FDP_ACC.1 Subset access control, or
2037
FDP_IFC.1 Subset information flow control], fulfilled by FDP_ACC.2
2038
FMT_SMR.1 Security roles
2039
FMT_SMF.1 Specification of Management Functions
2040
6.7.3.1.2 FMT_MSA.3/AC: Static attribute initialisation for Gateway access SFP
2041
FMT_MSA.3.1/AC The TSF shall enforce the Gateway access SFP 180 to provide restrictive 181
2042
default values for security attributes that are used to enforce the SFP.
2043
FMT_MSA.3.2/AC The TSF shall allow the no role 182 to specify alternative initial values to
2044
override the default values when an object or information is created.
2045
Hierarchical to: No other components.
2046
Dependencies: FMT_MSA.1 Management of security attributes
2047
FMT_SMR.1 Security roles
2048
176 [assignment: access control SFP(s), information flow control SFP(s)]
177 [selection: change_default, query, modify, delete, [assignment: other operations]]
178 [assignment: list of security attributes]
179 [assignment: the authorised identified roles]
180 [assignment: access control SFP, information flow control SFP]
181 [selection, choose one of: restrictive, permissive, [assignment: other property]]
182 [assignment: the authorised identified roles]
Security Target, SMGW Integrationsmodul Version 1.0
Page 107
6.7.4 Management of security attributes for Firewall SFP
2049
6.7.4.1 Management of security attributes (FMT_MSA)
2050
6.7.4.1.1 FMT_MSA.1/FW: Management of security attributes for firewall policy
2051
FMT_MSA.1.1/FW The TSF shall enforce the Firewall SFP 183 to restrict the ability to query,
2052
modify, delete, other operations: none 184 the security attributes all relevant
2053
security attributes 185 to authorised Gateway Administrators 186.
2054
Hierarchical to: No other components.
2055
Dependencies: [FDP_ACC.1 Subset access control, or
2056
FDP_IFC.1 Subset information flow control], fulfilled by FDP_IFC.2/FW
2057
FMT_SMR.1 Security roles
2058
FMT_SMF.1 Specification of Management Functions
2059
6.7.4.1.2 FMT_MSA.3/FW: Static attribute initialisation for Firewall policy
2060
FMT_MSA.3.1/FW The TSF shall enforce the Firewall SFP 187 to provide restrictive 188 default
2061
values for security attributes that are used to enforce the SFP.
2062
FMT_MSA.3.2/FW The TSF shall allow the no role 189 to specify alternative initial values to
2063
override the default values when an object or information is created.
2064
Hierarchical to: No other components.
2065
Dependencies: FMT_MSA.1 Management of security attributes
2066
FMT_SMR.1 Security roles
2067
Application Note 34: The definition of restrictive default rules for the firewall information flow
2068
policy refers to the rules as defined in FDP_IFF.1.2/FW and FDP_IFF.1.5/FW.
2069
Those rules apply to all information flows and must not be overwritable by
2070
anybody.
2071
183 [assignment: access control SFP(s), information flow control SFP(s)]
184 [selection: change_default, query, modify, delete, [assignment: other operations]]
185 [assignment: list of security attributes]
186 [assignment: the authorised identified roles]
187 [assignment: access control SFP, information flow control SFP]
188 [selection, choose one of: restrictive, permissive, [assignment: other property]]
189 [assignment: the authorised identified roles]
Security Target, SMGW Integrationsmodul Version 1.0
Page 108
6.7.5 Management of security attributes for Meter SFP
2072
6.7.5.1 Management of security attributes (FMT_MSA)
2073
6.7.5.1.1 FMT_MSA.1/MTR: Management of security attributes for Meter policy
2074
FMT_MSA.1.1/MTR The TSF shall enforce the Meter SFP 190 to restrict the ability to
2075
change_default, query, modify, delete, other operations: none 191 the
2076
security attributes all relevant security attributes 192 to authorised Gateway
2077
Administrators 193.
2078
Hierarchical to: No other components.
2079
Dependencies: [FDP_ACC.1 Subset access control, or
2080
FDP_IFC.1 Subset information flow control], fulfilled by FDP_IFC.2/FW
2081
FMT_SMR.1 Security roles
2082
FMT_SMF.1 Specification of Management Functions
2083
6.7.5.1.2 FMT_MSA.3/MTR: Static attribute initialisation for Meter policy
2084
FMT_MSA.3.1/MTR The TSF shall enforce the Meter SFP 194 to provide restrictive 195 default
2085
values for security attributes that are used to enforce the SFP.
2086
FMT_MSA.3.2/MTR The TSF shall allow the no role 196 to specify alternative initial values to
2087
override the default values when an object or information is created.
2088
Hierarchical to: No other components.
2089
Dependencies: FMT_MSA.1 Management of security attributes
2090
FMT_SMR.1 Security roles
2091
190 [assignment: access control SFP(s), information flow control SFP(s)]
191 [selection: change_default, query, modify, delete, [assignment: other operations]]
192 [assignment: list of security attributes]
193 [assignment: the authorised identified roles]
194 [assignment: access control SFP, information flow control SFP]
195 [selection, choose one of: restrictive, permissive, [assignment: other property]]
196 [assignment: the authorised identified roles]
Security Target, SMGW Integrationsmodul Version 1.0
Page 109
6.8 Class FPR: Privacy
2092
6.8.1 Communication Concealing (FPR_CON)
2093
6.8.1.1 FPR_CON.1: Communication Concealing
2094
FPR_CON.1.1 The TSF shall enforce the Firewall SFP 197 in order to ensure that no
2095
personally identifiable information (PII) can be obtained by an analysis of
2096
frequency, load, size or the absence of external communication 198.
2097
FPR_CON.1.2 The TSF shall connect to the Gateway Administrator, authorized External
2098
Entity in the WAN 199 in intervals as follows daily, other interval: none 200 to
2099
conceal the data flow201.
2100
Hierarchical to: No other components.
2101
Dependencies: No dependencies.
2102
6.8.2 Pseudonymity (FPR_PSE)
2103
6.8.2.1 FPR_PSE.1 Pseudonymity
2104
FPR_PSE.1.1 The TSF shall ensure that external entities in the WAN 202 are unable to
2105
determine the real user name bound to information neither relevant for
2106
billing nor for a secure operation of the Grid sent to parties in the WAN 203.
2107
FPR_PSE.1.2 The TSF shall be able to provide aliases as defined by the Processing
2108
Profiles 204 of the real user name for the Meter and Gateway identity 205 to
2109
external entities in the WAN 206.
2110
FPR_PSE.1.3 The TSF shall determine an alias for a user 207 and verify that it conforms to
2111
the alias given by the Gateway Administrator in the Processing Profile208.
2112
197 [assignment: information flow policy]
198 [assignment: characteristics of the information flow that need to be concealed]
199 [assignment: list of external entities]
200 [selection: weekly, daily, hourly, [assignment: other interval]]
201 The TOE uses a randomized value of about ±50 percent per delivery.
202 [assignment: set of users and/or subjects]
203 [assignment: list of subjects and/or operations and/or objects]
204 [assignment: number of aliases]
205 [refinement: of the real user name]
206 [assignment: list of subjects]
Security Target, SMGW Integrationsmodul Version 1.0
Page 110
Hierarchical to: No other components.
2113
Dependencies: No dependencies.
2114
Application Note 35: When the TOE submits information about the consumption or production of
2115
a certain commodity that is not relevant for the billing process nor for a
2116
secure operation of the Grid, there is no need that this information is sent
2117
with a direct link to the identity of the consumer. In those cases, the TOE
2118
shall replace the identity of the Consumer by a pseudonymous identifier.
2119
Please note that the identity of the Consumer may not be their name but
2120
could also be a number (e.g. consumer ID) used for billing purposes.
2121
A Gateway may use more than one pseudonymous identifier.
2122
A complete anonymisation would be beneficial in terms of the privacy of the
2123
consumer. However, a complete anonymous set of information would not
2124
allow the external entity to ensure that the data comes from a trustworthy
2125
source.
2126
Please note that an information flow shall only be initiated if allowed by a
2127
corresponding Processing Profile.
2128
6.9 Class FPT: Protection of the TSF
2129
6.9.1 Fail secure (FPT_FLS)
2130
6.9.1.1 FPT_FLS.1: Failure with preservation of secure state
2131
FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of failures
2132
occur:
2133
• the deviation between local system time of the TOE and the reliable
2134
external time source is too large,
2135
• TOE hardware / firmware integrity violation or
2136
• TOE software application integrity violation 209.
2137
Hierarchical to: No other components.
2138
Dependencies: No dependencies.
2139
207 [selection, choose one of: determine an alias for a user, accept the alias from the user]
208 [assignment: alias metric]
209 [assignment: list of types of failures in the TSF]
Security Target, SMGW Integrationsmodul Version 1.0
Page 111
Application Note 36: The local clock shall be as exact as required by normative or legislative
2140
regulations. If no regulation exists, a maximum deviation of 3% of the
2141
measuring period is allowed to be in conformance with [PP_GW].
2142
6.9.2 Replay Detection (FPT_RPL)
2143
6.9.2.1 FPT_RPL.1: Replay detection
2144
FPT_RPL.1.1 The TSF shall detect replay for the following entities: all external entities 210.
2145
FPT_RPL.1.2 The TSF shall perform ignore replayed data 211 when replay is detected.
2146
Hierarchical to: No other components.
2147
Dependencies: No dependencies.
2148
6.9.3 Time stamps (FPT_STM)
2149
6.9.3.1 FPT_STM.1: Reliable time stamps
2150
FPT_STM.1.1 The TSF shall be able to provide reliable time stamps.
2151
Hierarchical to: No other components.
2152
Dependencies: No dependencies.
2153
6.9.4 TSF self test (FPT_TST)
2154
6.9.4.1 FPT_TST.1: TSF testing
2155
FPT_TST.1.1 The TSF shall run a suite of self tests during initial startup, at the request of a
2156
user and periodically during normal operation 212 to demonstrate the correct
2157
operation of the TSF 213.
2158
FPT_TST.1.2 The TSF shall provide authorised users with the capability to verify the
2159
integrity of TSF data 214.
2160
210 [assignment: list of identified entities]
211 [assignment: list of specific actions]
212 [selection: during initial start-up, periodically during normal operation, at the request of the authorised user, at the
conditions[assignment: conditions under which self test should occur]]
213 [selection: [assignment: parts of TSF], the TSF]
214 [selection: [assignment: parts of TSF data], TSF data]
Security Target, SMGW Integrationsmodul Version 1.0
Page 112
FPT_TST.1.3 The TSF shall provide authorised users with the capability to verify the
2161
integrity of TSF 215.
2162
Hierarchical to: No other components .
2163
Dependencies: No dependencies.
2164
6.9.5 TSF physical protection (FPT_PHP)
2165
6.9.5.1 FPT_PHP.1: Passive detection of physical attack
2166
FPT_PHP.1.1 The TSF shall provide unambiguous detection of physical tampering that
2167
might compromise the TSF.
2168
FPT_PHP.1.2 The TSF shall provide the capability to determine whether physical tampering
2169
with the TSF's devices or TSF elements has occurred.
2170
Hierarchical to: No other components.
2171
Dependencies: No dependencies.
2172
6.10 Class FTP: Trusted path/channels
2173
6.10.1 Inter-TSF trusted channel (FTP_ITC)
2174
6.10.1.1 FTP_ITC.1/WAN: Inter-TSF trusted channel for WAN
2175
FTP_ITC.1.1/WAN The TSF shall provide a communication channel between itself and another
2176
trusted IT product that is logically distinct from other communication
2177
channels and provides assured identification of its end points and protection
2178
of the channel data from modification or disclosure.
2179
FTP_ITC.1.2/WAN The TSF shall permit the TSF 216 to initiate communication via the trusted
2180
channel.
2181
FTP_ITC.1.3/WAN The TSF shall initiate communication via the trusted channel for all
2182
communications to external entities in the WAN 217.
2183
Hierarchical to: No other components
2184
215 [selection: [assignment: parts of TSF], TSF]
216 [selection: the TSF, another trusted IT product]
217 [assignment: list of functions for which a trusted channel is required]
Security Target, SMGW Integrationsmodul Version 1.0
Page 113
Dependencies: No dependencies.
2185
6.10.1.2 FTP_ITC.1/MTR: Inter-TSF trusted channel for Meter
2186
FTP_ITC.1.1/MTR The TSF shall provide a communication channel between itself and another
2187
trusted IT product that is logically distinct from other communication
2188
channels and provides assured identification of its end points and protection
2189
of the channel data from modification or disclosure.
2190
FTP_ITC.1.2/MTR The TSF shall permit the Meter and the TOE 218 to initiate communication via
2191
the trusted channel.
2192
FTP_ITC.1.3/MTR The TSF shall initiate communication via the trusted channel for any
2193
communication between a Meter and the TOE 219.
2194
Hierarchical to: No other components.
2195
Dependencies: No dependencies.
2196
Application Note 37: The corresponding cryptographic primitives are defined by FCS_COP.1/MTR.
2197
6.10.1.3 FTP_ITC.1/USR: Inter-TSF trusted channel for User
2198
FTP_ITC.1.1/USR The TSF shall provide a communication channel between itself and another
2199
trusted IT product that is logically distinct from other communication
2200
channels and provides assured identification of its end points and protection
2201
of the channel data from modification or disclosure.
2202
FTP_ITC.1.2/USR The TSF shall permit the Consumer, the Service Technician 220 to initiate
2203
communication via the trusted channel.
2204
FTP_ITC.1.3/USR The TSF shall initiate communication via the trusted channel for any
2205
communication between a Consumer and the TOE and the Service Technician
2206
and the TOE 221.
2207
Hierarchical to: No other components.
2208
Dependencies: No dependencies.
2209
218 [selection: the TSF, another trusted IT product]
219 [assignment: list of functions for which a trusted channel is required]
220 [selection: the TSF, another trusted IT product]
221 [assignment: list of functions for which a trusted channel is required]
Security Target, SMGW Integrationsmodul Version 1.0
Page 114
6.11 Security Assurance Requirements for the TOE
2210
The minimum Evaluation Assurance Level for this Security Target is EAL 4 augmented by AVA_VAN.5
2211
and ALC_FLR.2. The following table lists the assurance components which are therefore applicable to
2212
this ST.
2213
Assurance Class Assurance Component
Development ADV_ARC.1
ADV_FSP.4
ADV_IMP.1
ADV_TDS.3
Guidance documents AGD_OPE.1
AGD_PRE.1
Life-cycle support ALC_CMC.4
ALC_CMS.4
ALC_DEL.1
ALC_DVS.1
ALC_LCD.1
ALC_TAT.1
ALC_FLR.2
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.5
Table 16: Assurance Requirements
2214
Security Target, SMGW Integrationsmodul Version 1.0
Page 115
6.12 Security Requirements rationale
2215
6.12.1 Security Functional Requirements rationale
2216
6.12.1.1 Fulfilment of the Security Objectives
2217
This chapter proves that the set of security requirements (TOE) is suited to fulfil the security
2218
objectives described in chapter 4 and that each SFR can be traced back to the security objectives. At
2219
least one security objective exists for each security requirement.
2220
O.Firewall
O.SeparateIF
O.Conceal
O.Meter
O.Crypt
O.Time
O.Protect
O.Management
O.Log
O.Access
FAU_ARP.1/SYS X
FAU_GEN.1/SYS X
FAU_SAA.1/SYS X
FAU_SAR.1/SYS X
FAU_STG.4/SYS X
FAU_GEN.1/CON X
FAU_SAR.1/CON X
FAU_STG.4/CON X
FAU_GEN.1/CAL X
FAU_SAR.1/CAL X
FAU_STG.4/CAL X
FAU_GEN.2 X
FAU_STG.2 X
FCO_NRO.2 X
FCS_CKM.1/TLS X
FCS_COP.1/TLS X
FCS_CKM.1/CMS X
Security Target, SMGW Integrationsmodul Version 1.0
Page 116
O.Firewall
O.SeparateIF
O.Conceal
O.Meter
O.Crypt
O.Time
O.Protect
O.Management
O.Log
O.Access
FCS_COP.1/CMS X
FCS_CKM.1/MTR X
FCS_COP.1/MTR X
FCS_CKM.4 X
FCS_COP.1/HASH X
FCS_COP.1/MEM X X
FDP_ACC.2 X
FDP_ACF.1 X
FDP_IFC.2/FW X X
FDP_IFF.1/FW X X
FDP_IFC.2/MTR X X
FDP_IFF.1/MTR X X
FDP_RIP.2 X
FDP_SDI.2 X
FIA_ATD.1 X
FIA_AFL.1 X
FIA_UAU.2 X
FIA_UAU.5 X
FIA_UAU.6 X
FIA_UID.2 X
FIA_USB.1 X
FMT_MOF.1 X
FMT_SMF.1 X
FMT_SMR.1 X
FMT_MSA.1/AC X
Security Target, SMGW Integrationsmodul Version 1.0
Page 117
O.Firewall
O.SeparateIF
O.Conceal
O.Meter
O.Crypt
O.Time
O.Protect
O.Management
O.Log
O.Access
FMT_MSA.3/AC X
FMT_MSA.1/FW X
FMT_MSA.3/FW X
FMT_MSA.1/MTR X
FMT_MSA.3/MTR X
FPR_CON.1 X
FPR_PSE.1 X
FPT_FLS.1 X
FPT_RPL.1 X
FPT_STM.1 X X
FPT_TST.1 X X
FPT_PHP.1 X
FTP_ITC.1/WAN X
FTP_ITC.1/MTR X
FTP_ITC.1/USR X
Table 17: Fulfilment of Security Objectives
2221
The following paragraphs contain more details on this mapping.
2222
6.12.1.1.1 O.Firewall
2223
O.Firewall is met by a combination of the following SFRs:
2224
• FDP_IFC.2/FW defines that the TOE shall implement an information flow policy for its
2225
firewall functionality.
2226
• FDP_IFF.1/FW defines the concrete rules for the firewall information flow policy.
2227
• FTP_ITC.1/WAN defines the policy around the trusted channel to parties in the WAN.
2228
Security Target, SMGW Integrationsmodul Version 1.0
Page 118
6.12.1.1.2 O.SeparateIF
2229
O.SeparateIF is met by a combination of the following SFRs:
2230
• FDP_IFC.2/FW and FDP_IFF.1/FW implicitly require the TOE to implement physically
2231
separate ports for WAN and LMN.
2232
• FPT_TST.1 implements a self test that also detects whether the ports for WAN and LAN have
2233
been interchanged.
2234
6.12.1.1.3 O.Conceal
2235
O.Conceal is completely met by FPR_CON.1 as directly follows.
2236
6.12.1.1.4 O.Meter
2237
O.Meter is met by a combination of the following SFRs:
2238
• FDP_IFC.2/MTR and FDP_IFF.1/MTR define an information flow policy to introduce how the
2239
Gateway shall handle Meter Data.
2240
• FCO_NRO.2 ensure that all Meter Data will be signed by the Gateway (invoking the services
2241
of its Security Module) before being submitted to external entities.
2242
• FPR_PSE.1 defines requirements around the pseudonymization of Meter identities for Status
2243
data.
2244
• FTP_ITC.1/MTR defines the requirements around the Trusted Channel that shall be
2245
implemented by the Gateway in order to protect information submitted via the Gateway and
2246
external entities in the WAN or the Gateway and a distributed Meter.
2247
6.12.1.1.5 O.Crypt
2248
O.Crypt is met by a combination of the following SFRs:
2249
Security Target, SMGW Integrationsmodul Version 1.0
Page 119
• FCS_CKM.4 defines the requirements around the secure deletion of ephemeral
2250
cryptographic keys.
2251
• FCS_CKM.1/TLS defines the requirements on key negotiation for the TLS protocol.
2252
• FCS_CKM.1/CMS defines the requirements on key generation for symmetric encryption
2253
within CMS.
2254
• FCS_COP.1/TLS defines the requirements around the encryption and decryption capabilities
2255
of the Gateway for communications with external parties and to Meters.
2256
• FCS_COP.1/CMS defines the requirements around the encryption and decryption of content
2257
and administration data.
2258
• FCS_CKM.1/MTR defines the requirements on key negotiation for meter communication
2259
encryption.
2260
• FCS_COP.1/MTR defines the cryptographic primitives for meter communication encryption.
2261
• FCS_COP.1/HASH defines the requirements on hashing that are needed in the context of
2262
digital signatures (which are created and verified by the Security Module).
2263
• FCS_COP.1/MEM defines the requirements around the encryption of TSF data.
2264
• FPT_RPL.1 ensures that a replay attack for communications with external entities is detected.
2265
6.12.1.1.6 O.Time
2266
O.Time is met by a combination of the following SFRs:
2267
• FDP_IFC.2/MTR and FDP_IFF.1/MTR define the required update functionality for the local
2268
time as part of the information flow control policy for handling Meter Data.
2269
• FPT_STM.1 defines that the TOE shall be able to provide reliable time stamps.
2270
6.12.1.1.7 O.Protect
2271
O.Protect is met by a combination of the following SFRs:
2272
Security Target, SMGW Integrationsmodul Version 1.0
Page 120
• FCS_COP.1/MEM defines that the TOE shall encrypt its TSF and user data as long as it is not
2273
in use.
2274
• FDP_RIP.2 defines that the TOE shall make information unavailable as soon as it is no longer
2275
needed.
2276
• FDP_SDI.2 defines requirements around the integrity protection for stored data.
2277
• FPT_FLS.1 defines requirements that the TOE falls back to a safe state for specific error cases.
2278
• FPT_TST.1 defines the self testing functionality to detect whether the interfaces for WAN and
2279
LAN are separate.
2280
• FPT_PHP.1 defines the exact requirements around the physical protection that the TOE has
2281
to provide.
2282
6.12.1.1.8 O.Management
2283
O.Management is met by a combination of the following SFRs:
2284
• FIA_ATD.1 defines the attributes for users.
2285
• FIA_AFL.1 defines the requirements if the authentication of users fails multiple times.
2286
• FIA_UAU.2 defines requirements around the authentication of users.
2287
• FIA_UID.2 defines requirements around the identification of users.
2288
• FIA_USB.1 defines that the TOE must be able to associate users with subjects acting on
2289
behalf of them.
2290
• FMT_MOF.1 defines requirements around the limitations for management of security
2291
functions.
2292
• FMT_MSA.1/AC defines requirements around the limitations for management of attributes
2293
used for the Gateway access SFP.
2294
• FMT_MSA.1/FW defines requirements around the limitations for management of attributes
2295
used for the Firewall SFP.
2296
• FMT_MSA.1/MTR defines requirements around the limitations for management of
2297
attributes used for the Meter SFP.
2298
Security Target, SMGW Integrationsmodul Version 1.0
Page 121
• FMT_MSA.3/AC defines the default values for the Gateway access SFP.
2299
• FMT_MSA.3/FW defines the default values for the Firewall SFP.
2300
• FMT_MSA.3/MTR defines the default values for the Meter SFP.
2301
• FMT_SMF.1 defines the management functionalities that the TOE must offer.
2302
• FMT_SMR.1 defines the role concept for the TOE.
2303
6.12.1.1.9 O.Log
2304
O.Log defines that the TOE shall implement three different audit processes that are covered by the
2305
Security Functional Requirements as follows:
2306
System Log
2307
The implementation of the system log itself is covered by the use of FAU_GEN.1/SYS.
2308
FAU_ARP.1/SYS and FAU_SAA.1/SYS allow to define a set of criteria for automated analysis of the
2309
audit and a corresponding response. FAU_SAR.1/SYS defines the requirements around the audit
2310
review functions and that access to them shall be limited to authorised Gateway Administrators via
2311
the IF_GW_WAN interface and to authorised Service Technicians via the IF_GW_SRV interface.
2312
Finally, FAU_STG.4/SYS defines the requirements on what should happen if the audit log is full.
2313
Consumer Log
2314
The implementation of the consumer log itself is covered by the use of FAU_GEN.1/CON.
2315
FAU_STG.4/CON defines the requirements on what should happen if the audit log is full.
2316
FAU_SAR.1/CON defines the requirements around the audit review functions for the consumer log
2317
and that access to them shall be limited to authorised Consumer via the IF_GW_CON interface.
2318
FTP_ITC.1/USR defines the requirements on the protection of the communication of the Consumer
2319
with the TOE.
2320
Calibration Log
2321
The implementation of the calibration log itself is covered by the use of FAU_GEN.1/CAL.
2322
FAU_STG.4/CAL defines the requirements on what should happen if the audit log is full.
2323
Security Target, SMGW Integrationsmodul Version 1.0
Page 122
FAU_SAR.1/CAL defines the requirements around the audit review functions for the calibration log
2324
and that access to them shall be limited to authorised Gateway Administrators via the IF_GW_WAN
2325
interface.
2326
FAU_GEN.2, FAU_STG.2 and FPT_STM.1 apply to all three audit processes.
2327
6.12.1.1.10 O.Access
2328
FDP_ACC.2 and FDP_ACF.1 define the access control policy as required to address O.Access.
2329
FIA_UAU.5 ensures that entities that would like to communicate with the TOE are authenticated
2330
before any action whereby FIA_UAU.6 ensures that external entities in the WAN are re-
2331
authenticated after the session key has been used for a certain amount of time.
2332
6.12.1.2 Fulfilment of the dependencies
2333
The following table summarises all TOE functional requirements dependencies of this ST and
2334
demonstrates that they are fulfilled.
2335
SFR Dependencies Fulfilled by
FAU_ARP.1/SYS FAU_SAA.1 Potential violation analysis FAU_SAA.1/SYS
FAU_GEN.1/SYS FPT_STM.1 Reliable time stamps FPT_STM.1
FAU_SAA.1/SYS FAU_GEN.1 Audit data generation FAU_GEN.1/SYS
FAU_SAR.1/SYS FAU_GEN.1 Audit data generation FAU_GEN.1/SYS
FAU_STG.4/SYS FAU_STG.1 Protected audit trail storage FAU_STG.2
FAU_GEN.1/CON FPT_STM.1 Reliable time stamps FPT_STM.1
FAU_SAR.1/CON FAU_GEN.1 Audit data generation FAU_GEN.1/CON
FAU_STG.4/CON FAU_STG.1 Protected audit trail storage FAU_STG.2
FAU_GEN.1/CAL FPT_STM.1 Reliable time stamps FPT_STM.1
FAU_SAR.1/CAL FAU_GEN.1 Audit data generation FAU_GEN.1/CAL
FAU_STG.4/CAL FAU_STG.1 Protected audit trail storage FAU_STG.2
FAU_GEN.2 FAU_GEN.1 Audit data generation
FIA_UID.1 Timing of identification
FAU_GEN.1/SYS
FAU_GEN.1/CON
FIA_UID.2
FAU_STG.2 FAU_GEN.1 Audit data generation FAU_GEN.1/SYS
FAU_GEN.1/CON
FAU_GEN.1/CAL
Security Target, SMGW Integrationsmodul Version 1.0
Page 123
222 The key will be generated by secure production environment and not the TOE itself.
FCO_NRO.2 FIA_UID.1 Timing of identification FIA_UID.2
FCS_CKM.1/TLS [FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1/TLS
FCS_CKM.4
FCS_COP.1/TLS [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.4 Cryptographic key destruction
FCS_CKM.1/TLS
FCS_CKM.4
FCS_CKM.1/CMS [FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1/CMS
FCS_CKM.4
FCS_COP.1/CMS [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.4 Cryptographic key destruction
FCS_CKM.1/CMS
FCS_CKM.4
FCS_CKM.1/MTR [FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1/MTR
FCS_CKM.4
FCS_COP.1/MTR [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.4 Cryptographic key destruction
FCS_CKM.1/TLS
FCS_CKM.4
FCS_CKM.4 [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/TLS
FCS_CKM.1/CMS
FCS_CKM.1/MTR
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]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.4
Please refer to
chapter 6.12.1.3 for
missing
dependency
FCS_COP.1/MEM [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.4 Cryptographic key destruction
FCS_CKM.1/CMS
FCS_CKM.4222
Security Target, SMGW Integrationsmodul Version 1.0
Page 124
FDP_ACC.2 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.2
FMT_MSA.3/AC
FDP_IFC.2/FW FDP_IFF.1 Simple security attributes FDP_IFF.1/FW
FDP_IFF.1/FW FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
FDP_IFC.2/FW
FMT_MSA.3/FW
FDP_IFC.2/MTR FDP_IFF.1 Simple security attributes FDP_IFF.1/MTR
FDP_IFF.1/MTR FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
FDP_IFC.2/MTR
FMT_MSA.3/MTR
FDP_RIP.2 - -
FDP_SDI.2 - -
FIA_ATD.1 - -
FIA_AFL.1 FIA_UAU.1 Timing of authentication FIA_UAU.2
FIA_UAU.2 FIA_UID.1 Timing of identification FIA_UID.2
FIA_UAU.5 - -
FIA_UAU.6 - -
FIA_UID.2 - -
FIA_USB.1 FIA_ATD.1 User attribute definition FIA_ATD.1
FMT_MOF.1 FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_SMR.1
FMT_SMF.1
FMT_SMF.1 - -
FMT_SMR.1 FIA_UID.1 Timing of identification FIA_UID.2
FMT_MSA.1/AC [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.2
FMT_SMR.1
FMT_SMF.1
FMT_MSA.3/AC FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
FMT_MSA.1/AC
FMT_SMR.1
FMT_MSA.1/FW [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_IFC.2/WAN
FMT_SMR.1
FMT_SMF.1
FMT_MSA.3/FW FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
FMT_MSA.1/FW
FMT_SMR.1
FMT_MSA.1/MTR [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_IFC.2/MTR
FMT_SMR.1
FMT_SMF.1
FMT_MSA.3/MTR FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
FMT_MSA.1/MTR
FMT_SMR.1
FPR_CON.1 - -
Security Target, SMGW Integrationsmodul Version 1.0
Page 125
Table 18: SFR Dependencies
2336
6.12.1.3 Justification for missing dependencies
2337
The hash algorithm as defined in FCS_COP.1/HASH does not need any key material. As such the
2338
dependency to an import or generation of key material is omitted for this SFR.
2339
6.12.2 Security Assurance Requirements rationale
2340
The decision on the assurance level has been mainly driven by the assumed attack potential. As
2341
outlined in the previous chapters of this Security Target it is assumed that – at least from the WAN
2342
side – a high attack potential is posed against the security functions of the TOE. This leads to the use
2343
of AVA_VAN.5 (Resistance against high attack potential).
2344
In order to keep evaluations according to this Security Target commercially feasible EAL 4 has been
2345
chosen as assurance level as this is the lowest level that provides the prerequisites for the use of
2346
AVA_VAN.5.
2347
Eventually, the augmentation by ALC_FLR.2 has been chosen to emphasize the importance of a
2348
structured process for flaw remediation at the developer’s side, specifically for such a new
2349
technology.
2350
FPR_PSE.1 - -
FPT_FLS.1 - -
FPT_RPL.1 - -
FPT_STM.1 - -
FPT_TST.1 - -
FPT_PHP.1 - -
FTP_ITC.1/WAN - -
FTP_ITC.1/MTR - -
FTP_ITC.1/USR - -
Security Target, SMGW Integrationsmodul Version 1.0
Page 126
6.12.2.1 Dependencies of assurance components
2351
The dependencies of the assurance requirements taken from EAL 4 are fulfilled automatically. The
2352
augmentation by AVA_VAN.5 and ALC_FLR.2 does not introduce additional assurance components
2353
that are not contained in EAL 4.
2354
Security Target, SMGW Integrationsmodul Version 1.0
Page 127
7 TOE Summary Specification
2355
The following paragraph provides a TOE summary specification describing how the TOE meets each
2356
SFR.
2357
7.1 SF.1: Authentication of Communication and Role Assignment for
2358
external entities
2359
The TOE contains a software module that authenticates all communication channels with WAN, HAN
2360
and LMN networks. The authentication is based on the TLS 1.2 protocol compliant to [RFC 5246].
2361
According to [TR-03109], this TLS authentication mechanism is used for all TLS secured
2362
communications channels with external entities. The TOE does always implement the bidirectional
2363
authentication as required by [TR-03109-1] with one exception: if the Consumer requests a
2364
password-based authentication from the GWA according to [TR-03109-1], and the GWA activates this
2365
authentication method for this Consumer, the TOE uses a unidirectional TLS authentication.
2366
[TR-03109-1] requires the TOE to use elliptical curves conforming to [RFC 5289] whereas the
2367
following cipher suites are supported:
2368
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
2369
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
2370
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
2371
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
2372
The following elliptical curve is supported by the TOE in case that
2373
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
2374
is used:
2375
• NIST P-256 (according to [RFC 5114])
2376
In case that
2377
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
2378
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 or
2379
Security Target, SMGW Integrationsmodul Version 1.0
Page 128
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
2380
is used, the following elliptical curves are supported by the TOE:
2381
• BrainpoolP256r1 (according to [RFC 5639]),
2382
• BrainpoolP384r1 (according to [RFC 5639]),
2383
• BrainpoolP512r1 (according to [RFC 5639]), and
2384
• NIST P-384 (according to [RFC 5114]).
2385
Alongside, the TOE supports the case of unidirectional communication with wireless meter (via the
2386
wM-Bus protocol), where the external entity is authenticated via AES with CMAC authentication. In
2387
this case, the AES algorithm is operating in CBC mode with 128-bit symmetric keys. The
2388
authentication is successful in case that the CMAC has been successfully verified by the use of a
2389
cryptographic key Kmac. The cryptographic key for CMAC authentication (Kmac) is derived from the
2390
meter individual key MK conformant to [TR-03116-3, chap. 7.2]. The meter individual key MK
2391
configured by the GWA is selected by the TOE through the MAC-protected but unencrypted meter-id
2392
submitted by the meter.
2393
The generation of the cryptographic key material for TLS secured communication channels utilizes a
2394
Security Module. This Security Module is compliant to [TR-03109-2] and evaluated according to
2395
[SecModPP].
2396
The destruction of cryptographic key material used by the TOE is performed through “zeroisation”.
2397
The TOE stores all ephemeral keys used for TLS secured communication or other cryptographic
2398
operations in the RAM only. For instance, whenever a TLS secured communication is terminated, the
2399
TOE wipes the RAM area used for the cryptographic key material with 0-bytes directly after finishing
2400
the usage of that material.
2401
The TOE receives the authentication certificate of the external entity during the handshake phase of
2402
the TLS protocol. For the establishment of the TLS secured communication channel, the TOE verifies
2403
the correctness of the signed data transmitted during the TLS protocol handshake phase. While
2404
importing a authentication certificate the TOE verifies the certificate chain of the certificate for all
2405
certificates of the SM-PKI according to [TR-03109-4]. Note, that the certificate used for the TLS-based
2406
Security Target, SMGW Integrationsmodul Version 1.0
Page 129
authentication of wired meters is self-signed and not part of the SM-PKI. Additionally, the TOE checks
2407
whether the certificate is configured by the Gateway Administrator for the used interface, and
2408
whether the remote IP address used and configured in the TSF data are identical (FIA_USB.1). The
2409
validity of the certificate (e.g. revocation check or check of the certificates date validity) is not
2410
checked by the TOE according to [TR-03109-4, chap. 3.3.2.2]. In order to authenticate the external
2411
entity, the key material of the TOE’s communication partner must be known and trusted.
2412
The following communication types are known to the TOE 223:
2413
a) WAN communication via IF_GW_WAN
2414
b) LMN communication via IF_GW_MTR (wireless or wired Meter)
2415
c) HAN communication via IF_GW_CON, IF_GW_CLS or IF_GW_SRV
2416
In order to accept a communication connection as being authenticated, the following conditions
2417
must be fulfilled:
2418
a) The TLS channel must have been established successfully with the required cryptographic
2419
mechanisms.
2420
b) The certificate of the external entity must be known and trusted through configuration by
2421
the Gateway Administrator, and associated with the according communication type.
2422
For the successfully authenticated external entity, the TOE performs an internal assignment of the
2423
communication type based on the certificate received at the external interface if applicable. The user
2424
identity is associated with the name of the certificate owner in case of a certificate-based
2425
authentication or with the user name in case of a password-based authentication at interface
2426
IF_GW_CON.
2427
For the LMN communication of the TOE with wireless (a.k.a. wM-Bus-based) meters, the external
2428
entity is authenticated by the use of the AES-CMAC algorithm and the meter-ID for wired Meters is
2429
used for association to the user identity (FIA_USB.1). Any other communication cannot be
2430
authenticated this way.
2431
223 Please note that the TOE additionally offers the interface IF_GW_SM to the certified Security Module
built into the TOE.
Security Target, SMGW Integrationsmodul Version 1.0
Page 130
FCS_CKM.1/TLS is fulfilled by the TOE through the implementation of the pseudorandom function of
2432
the TLS protocol compliant to [RFC 5246] while the Security Module is used by the TOE for the
2433
generation of the cryptographic key material. The use of TLS according to [RFC 5246] and the use of
2434
the postulated cipher suites according to [RFC 5639] fulfill the requirement FCS_COP.1/TLS. The
2435
requirements FCS_CKM.1/MTR and FCS_COP.1/MTR are fulfilled by the use of AES-CMAC-secured
2436
communication for wireless meters. The requirement FCS_CKM.4 is fulfilled by the described method
2437
of “zeroisation” when destroying cryptographic key material. The implementation of the described
2438
mechanisms (especially the use of TLS and AES-CBC with CMAC) fulfills the requirements
2439
FTP_ITC.1/WAN, FTP_ITC.1/MTR, and FTP_ITC.1/USR.
2440
A successfully established connection will be automatically disconnected by the TOE if a TLS channel
2441
to the WAN is established more than 48 hours, if a TLS channel to the LMN has transmitted more
2442
than 5 MB of information or if a channel to a local user is inactive for more than 10 minutes, and a
2443
new connection establishment will require a new full authentication procedure (FIA_UAU.6). In any
2444
case – whether the connection has been successfully established or not – all associated resources
2445
related with the connection or connection attempt are freed. The implementation of this
2446
requirement is done by means of the TOE’s operation system monitoring and limiting the resources
2447
of each process. This means that with each connection (or connection attempt) an internal session is
2448
created that is associated with resources monitored and limited by the TOE. All resources are freed
2449
even before finishing a session if the respective resource is no longer needed so that no previous
2450
information content of a resource is made available. Especially, the associated cryptographic key
2451
material is wiped as soon it is no longer needed. As such, the TOE ensures that during the phase of
2452
connection termination the internal session is also terminated and by this, all internal data
2453
(associated cryptographic key material and volatile data) is wiped by the zeroisation procedure
2454
described. Allocated physical resources are also freed. In case non-volatile data is no longer needed,
2455
the associated resources data are freed, too. The TOE doesn’t reuse any objects after deallocation of
2456
the resource (FDP_RIP.2).
2457
If the external entity can be successfully authenticated on basis of the received certificate and the
2458
acclaimed identity could be approved for the used external interface, the TOE associates the user
2459
Security Target, SMGW Integrationsmodul Version 1.0
Page 131
identity, the authentication status and the connecting network to the role according to the internal
2460
role model (FIA_ATD.1). In order to implement this, the TOE utilizes an internal data model which
2461
supplies the allowed communication network and other restricting properties linked with the
2462
submitted security attribute on the basis of the submitted authentication data providing the multiple
2463
mechanisms for authentication of any user's claimed identity according to the necessary rules
2464
according to [TR-03109-1] (FIA_UAU.5).
2465
In case of wireless meter communication (via the wM-Bus protocol), the security attribute of the
2466
Meter is the meter-id authenticated by the CMAC, where the meter-id is the identity providing
2467
criterion that is used by the TOE. The identity of the Meter is associated to the successfully
2468
authenticated external entity by the TOE and linked to the respective role according to Table 5 and
2469
its active session. In this case, the identity providing criterion is also the meter-id.
2470
The TOE enforces an explicit and complete security policy protecting the data flow for all external
2471
entities (FDP_IFC.2/FW, FDP_IFF.1/FW, FDP_IFC.2/MTR, FDP_IFF.1/MTR). The security policy
2472
defines the accessibility of data for each external entity and additionally the permitted actions for
2473
these data. Moreover, the external entities do also underlie restrictions for the operations which can
2474
be executed with the TOE (FDP_ACF.1). In case that it is not possible to authenticate an external
2475
entity successfully (e.g. caused by unknown authentication credentials), no other action is allowed on
2476
behalf of this user and the concerning connection is terminated (FIA_UAU.2). Any communication is
2477
only possible after successful authentication and identification of the external entity (FIA_UID.2,
2478
FIA_USB.1).
2479
The reception of the wake-up service data package is a special case that requests the TOE to
2480
establish a TLS authenticated and protected connection to the Gateway Administrator. The TOE
2481
validates the data package due to its compliance to the structure described in [TR-03109-1] and
2482
verifies the ECDSA signature with the public key of the Gateway Administrator’s certificate which
2483
must be known and trusted to the TOE. The TOE does not perform a revocation check or any validity
2484
check compliant to the shell model. The TOE verifies the electronic signature successfully when the
2485
certificate is known, trusted and associated to the Gateway Administrator. The TOE establishes the
2486
Security Target, SMGW Integrationsmodul Version 1.0
Page 132
connection to the Gateway Administrator when the package has been validated due to its structural
2487
conformity, the signature has been verified and the integrated timestamp fulfills the requirements of
2488
[TR-03109-1]. Receiving the data package and the successful validation of the wake-up package does
2489
not mean that the Gateway Administrator has successfully been authenticated.
2490
If the Gateway Administrator could be successfully authenticated based on the certificate submitted
2491
during the TLS handshake phase, the role will be assigned by the TOE according to now approved
2492
identity based on the internal role model and the TLS channel will be established.
2493
WAN roles
2494
The TOE assigns the following roles in the WAN communication (FMT_SMR.1):
2495
• authorised Gateway Administrator,
2496
• authorised External Entity.
2497
The role assignment is based on the X.509 certificate used by the external entity during TLS
2498
connection establishment. The TOE has explicit knowledge of the Gateway Administrator’s certificate
2499
and the assignment of the role “Gateway Administrator” requires the successful authentication of
2500
the WAN connection.
2501
The assignment of the role “Authorized External Entity” requires the X.509 certificate that is used
2502
during the TLS handshake to be part of an internal trust list that is under control of the TOE.
2503
The role “Authorized External Entity” can be assigned to more than one external entity.
2504
HAN roles
2505
The TOE differentiates and assigns the following roles in the HAN communication (FMT_SMR.1):
2506
• authorised Consumer
2507
• authorised Service Technician
2508
The role assignment is based on the X.509 certificate used by the external entity for TLS-secured
2509
communication channels or on password-based authentication at interface IF_GW_CON if configured
2510
(FIA_USB.1).
2511
Security Target, SMGW Integrationsmodul Version 1.0
Page 133
The assignment of roles in the HAN communication requires the successful identification of the
2512
external entity as a result of a successful authentication based on the certificate used for the HAN
2513
connection. The certificates used to authenticate the “Consumer” or the “Service Technician” are
2514
explicitly known to the TOE through configuration by the Gateway Administrator.
2515
Multi-client capability in the HAN
2516
The HAN communication might use more than one, parallel and independent authenticated
2517
communication channels. The TOE ensures that the certificates that are used for the authentication
2518
are different from each other.
2519
The role “Consumer” can be assigned to multiple, parallel sessions. The TOE ensures that these
2520
parallel sessions are logically distinct from each other by the use of different authentication
2521
information. This ensures that only the Meter Data associated with the authorized user are provided
2522
and Meter Data of other users are not accessible.
2523
LMN roles
2524
One of the following authentication mechanisms is used for Meters:
2525
a) authentication by the use of TLS according to [RFC 5246] for wired Meters
2526
a) authentication by the use of AES with CMAC authentication according to [RFC 3394] for
2527
wireless Meters.
2528
The TOE explicitly knows the identification credentials needed for authentication (X.509 certificate
2529
when using TLS; meter-id in conjunction with CMAC and known Kmac when using AES) through
2530
configuration by the Gateway Administrator. If the Meter could be successfully authenticated and
2531
the claimed identity could thus be proved, the according role “Authorised External Entity” is assigned
2532
by the TOE for this Meter at IF_GW_MTR based on the internal role model.
2533
LMN multi-client capabilities
2534
The LMN communication can be run via parallel, logically distinct and separately authenticated
2535
communication channels. The TOE ensures that the authentication credentials of each separate
2536
channel are different.
2537
Security Target, SMGW Integrationsmodul Version 1.0
Page 134
The TOE’s internal policy for access to data and objects under control of the TOE is closely linked with
2538
the identity of the external entity at IF_GW_MTR according to the TOE-internal role model. Based on
2539
the successfully verified authentication data, a permission catalogue with security attributes is
2540
internally assigned, which defines the allowed actions and access permissions within a
2541
communication channel.
2542
The encapsulation of the TOE processes run by this user is realized through the mechanisms offered
2543
by the TOE´s operating system and very restrictive user rights for each process. Each role is assigned
2544
to a separate, limited user account in the TOE´s operating system. For all of these accounts, it is only
2545
allowed to read, write or execute the files absolutely necessary for implementing the program logic.
2546
For each identity interacting with the TOE, a separate OS process is started. Especially, the databases
2547
used by the TOE and the logging service are adequately separated for enforcement of the necessary
2548
security domain separation (FDP_ACF.1). The allowed actions and access permissions and associated
2549
objects are assigned to the successfully approved identity of the user based on the used
2550
authentication credentials and the resulting associated role. The current session is unambiguously
2551
associated with this user. No interaction (e.g. access to Meter Data) is possible without an
2552
appropriate permission catalogue (FDP_ACC.2). The freeing of the role assignment and associated
2553
resources are ensured through the monitoring of the current session.
2554
7.2 SF.2: Acceptance and Deposition of Meter Data, Encryption of Meter
2555
Data for WAN transmission
2556
The TOE receives Meter Data from an LMN communication channel and deposits these Meter Data
2557
with the associated data for tariffing in a database especially assigned to this individual Meter
2558
residing in an encrypted file system (FCS_COP.1/MEM). The time interval for receiving or retrieving
2559
Meter Data can be configured individually per meter through a successfully authenticated Gateway
2560
Administrator and are initialized by the TOE during the setup procedure with pre-defined values.
2561
Security Target, SMGW Integrationsmodul Version 1.0
Page 135
The Meter Data are cryptographically protected and their integrity is verified by the TOE before the
2562
tariffing and deposition is performed. In case of a TLS secured communication, the integrity and
2563
confidentiality of the transmitted data is protected by the TLS protocol according to [RFC 5246]. In
2564
case of a unidirectional communication, the integrity is verified by the verification of the CMAC check
2565
sum whereas the protection of the confidentiality is given by the use of AES in CBC mode with 128 bit
2566
key length in combination with the CMAC authentication (FCS_CKM.1/MTR, FCS_COP.1/MTR). The
2567
AES encryption key has been brought into the TOE via a management function during the pairing
2568
process for the Meter. In the TOE’s internal data model, the used cryptographic keys Kmac and Kenc are
2569
associated with the meter-id due to the fact of the unidirectional communication. The TOE contains a
2570
packet monitor for Meter Data to avoid replay attacks based on the re-sending of Meter Data
2571
packages. In case of recognized data packets which have already been received and processed by the
2572
TOE, these data packets are blocked by the packet monitor (FPT_RPL.1).
2573
Concerning the service layers, the TOE detects replay attacks that can occur during authentication
2574
processes against the TOE or for example receiving data from one of the involved communication
2575
networks. This is for instance achieved through the correct interpretation of the strictly increasing
2576
ordering numbers for messages from the meters (in case that a TLS-secured communication channel
2577
is not used), through the enforcement of an appropriate time slot of execution for successfully
2578
authenticated wake-up calls, and of course through the use of the internal means of the TLS protocol
2579
according to [RFC 5246] (FPT_RPL.1).
2580
The deposition of Meter Data is performed in a way that these Meter Data are associated with a
2581
permission profile. This means that all of the operations and actions that can be taken with these
2582
data as described afterwards (e.g. sending via WAN to an Authenticated External Entity) depend on
2583
the permissions which are associated with the Meter Data. For metrological purposes, the
2584
Meter Data’s security attribute - if applicable - will be persisted associated with its corresponding
2585
Meter Data by the TOE. All user associated data stored by the TOE are protected by an AES-128-
2586
CMAC value. Before accessing these data, the TOE verifies the CMAC value that has been applied to
2587
the user data and detects integrity errors on any data and especially on user associated Meter Data
2588
in a reliable manner (FDP_SDI.2).
2589
Security Target, SMGW Integrationsmodul Version 1.0
Page 136
Closely linked with the deposition of the Meter Data is the assignment of an unambiguous and
2590
reliable timestamp on these data. The reliability grounds on the regular use of an external time
2591
source offering a sufficient exactness (FPT_STM.1) which is used to synchronize the operating system
2592
of the TOE. A maximum deviation of 3% of the measuring period is allowed to be in conformance
2593
with [PP_GW]. The data set (Meter Data and tariff data) is associated with the timestamp in an
2594
inseparably manner because each Meter Data entry in the database includes the corresponding time
2595
stamp and the database is cryptographically protected through the encrypted file system.
2596
For transmission of consumption data (tariffed Meter Data) or status data into the WAN, the TOE
2597
ensures that the data are encrypted and digitally signed (FCO_NRO.2, FCS_CKM.1/CMS,
2598
FCS_COP.1/CMS, FCS_COP.1/HASH, FCS_COP.1/MEM). In case of a successful transmission of
2599
consumption data into the WAN, the signature applied by the TOE is logged in the Consumer-Log for
2600
the respective Consumer at IF_GW_CON thus providing the possibility not only for the recipient to
2601
verify the evidence of origin for the transmitted data but to the Consumer at IF_GW_CON, too
2602
(FCO_NRO.2). The encryption is performed with the hybrid encryption as specified in [TR-03109-1-I]
2603
in combination with [TR-03116-3]. The public key of the external entity, the data have to be
2604
encrypted for, is known by the TOE through the authentication data configured by the Gateway
2605
Administrator and its assigned identity. This public key is assumed by the TOE to be valid because the
2606
TOE does not verify the validity of certificates. The public key used for the encryption of the derived
2607
symmetric key used for transmission of consumption data is different from the public key in the TLS
2608
certificate of the external entity used for the TLS secured communication channel. The derivation of
2609
the hybrid key used for transmission of consumption data is done according to [TR-03116-3, chapter
2610
8].
2611
The TOE does also foresee the case that the data is encrypted for an external entity that is not
2612
directly assigned to the external entity holding the active communication channel. The electronic
2613
signature is created through the utilization of the Security Module whereas the TOE is responsible for
2614
the computation of the hash value for the data to be signed. Therefore, the TOE utilizes the SHA-256,
2615
or SHA-512 hash algorithm (FCS_COP.1/HASH). The data to be sent to the external entity are
2616
prepared on basis of the tariffed meter data. The data to be transmitted are removed through
2617
Security Target, SMGW Integrationsmodul Version 1.0
Page 137
zeroisation after the (successful or unsuccessful) transmission attempt so that afterwards no
2618
previous information will be available (FDP_RIP.2). The created temporary session keys which have
2619
been used for encryption of the data are also deleted by the already described zeroisation
2620
mechanism as soon they are not longer needed (FCS_CKM.4).
2621
The time interval for transmission of the data is set for a daily transmission, and can be additionally
2622
configured by the Gateway Administrator. The TOE sends randomly generated messages into the
2623
WAN, so that through this the analysis of frequency, load, size or the absence of external
2624
communication is concealed (FPR_CON.1). Data that are not relevant for accounting are aliased for
2625
transmission so that no personally identifiable information (PII) can be obtained by an analysis of not
2626
billing-relevant information sent to parties in the WAN. Therefore, the TOE utilizes the alias as
2627
defined by the Gateway Administrator in the Processing Profile for the Meter identity to external
2628
parties in the WAN. Thereby, the TOE determines the alias for a user and verifies that it conforms to
2629
the alias given in the Processing Profile (FPR_PSE.1).
2630
7.3 SF.3: Administration, Configuration and SW Update
2631
The TOE includes functionality that allows its administration and configuration as well as updating
2632
the TOE’s software. This functionality is only provided for the authenticated Gateway Administrator
2633
(FMT_MOF.1, FMT_MSA.1/AC, FMT_MSA.1/FW, FMT_MSA.1/MTR).
2634
The following operations can be performed by the successfully authenticated Gateway
2635
Administrator:
2636
a) Definition and deployment of Processing Profiles including user administration, rights
2637
management and setting configuration parameters of the TOE
2638
b) Deployment of tariff information
2639
c) Deployment and installation of software updates
2640
A complete overview of the possible management functions is given in Table 14 and Table 15
2641
(FMT_SMF.1). Beside the possibility for a successfully authenticated Service Technician to view the
2642
Security Target, SMGW Integrationsmodul Version 1.0
Page 138
system log via interface IF_GW_SRV, administrative or configuration measures on the TOE can only
2643
be taken by the successfully authenticated Gateway Administrator.
2644
In order to perform these measures, the TOE has to establish a TLS secured channel to the Gateway
2645
Administrator and must authenticate the Gateway Administrator successfully. There are two
2646
possibilities:
2647
a) The TOE independently contacts the Gateway Administrator at a certain time specified in
2648
advance by the Gateway Administrator.
2649
b) Through a message sent to the wake-up service, the TOE is requested to contact the
2650
Gateway Administrator.
2651
In the second case, the wake-up data packet is received by the TOE from the WAN and checked by
2652
the TOE for structural correctness according to [TR-03109-1]. Afterwards, the TOE verifies the
2653
correctness of the electronic signature applied to the wake-up message data packet using the
2654
certificate of the Gateway Administrator stored in the TSF data. Afterwards, a TLS connection to the
2655
Gateway Administrator is established by the TOE and the above mentioned operations can be
2656
performed.
2657
Each data of the following categories transmitted by the Gateway Administrator to the TOE need to
2658
be signed through an electronic signature:
2659
a) The certificate used for signing transferred data (e. g. Processing Profiles or software
2660
updates) must be different from the certificate used for TLS-secured communication at the
2661
interface IF_GW_WAN to the Gateway Administrator.
2662
b) One certificate for signing data to be transferred can be configured by the Gateway
2663
Administrator.
2664
c) Software updates always have to be signed by the TOE manufacturer and the Gateway
2665
Administrator as well.
2666
d) The Gateway Administrator’s certificate can only be changed if this change request is signed
2667
by the TOE manufacturer and the Gateway Administrator (with his currently valid certificate).
2668
Software updates can be of different content:
2669
Security Target, SMGW Integrationsmodul Version 1.0
Page 139
a) The whole boot image of the TOE is changed.
2670
b) Only individual components of the TOE are changed. These components can be the boot
2671
loader plus the static kernel or the SMGW application.
2672
The software update packet is realized in form of an archive file enveloped into a CMS signature
2673
container according to [RFC 5652]. The electronic signature of the update packet is created using
2674
signature keys from the TOE manufacturer. The verification of this signature is performed by the TOE
2675
using the TOE's Security Module using the trust anchor of the TOE manufacturer. If the signature of
2676
the transferred data could not be successfully verified by the TOE or if the version number of the new
2677
firmware is not higher than the version number of the installed firmware, the received data is
2678
rejected by the TOE and not used for further processing (FMT_MOF.1). Any administrator action is
2679
entered in the System Log of the TOE.
2680
The signature of the update packet is immediately verified after receipt. After successful verification
2681
of the update packet the update process is immediately performed. In each case, the Gateway
2682
Administrator gets notified by the TOE and an entry in the TOE´s system log will be written.
2683
All parameters that can be changed by the Gateway Administrator are preset with restrictive values
2684
by the TOE. No role can specify alternative initial values to override these restrictive default values
2685
(FMT_MSA.3/AC, FMT_MSA.3/FW, FMT_MSA.3/MTR).
2686
This mechanism is supported by the TOE-internal resource monitor that internally monitors existing
2687
connections, assigned roles and operations allowed at a specific time.
2688
7.4 SF.4: Displaying Consumption Data
2689
The TOE offers the possibility of displaying consumption data to authenticated Consumers at
2690
interface IF_GW_CON. Therefore, the TOE contains a web server that implements TLS-based
2691
communication with mutual authentication (FTP_ITC.1/USR). If the Consumer requests a password-
2692
based authentication from the GWA according to [TR-03109-1] and the GWA activates this
2693
authentication method for this Consumer, the TOE uses TLS authentication with server-side
2694
Security Target, SMGW Integrationsmodul Version 1.0
Page 140
authentication and HTTP digest access authentication according to [RFC 7616]. In both cases, the
2695
requirement FCO_NRO.2 is fulfilled through the use of TLS-based communication because the TLS
2696
protocol includes evidence of origin for (tariffed) Meter Data to be displayed.
2697
To additionally display consumption data, a connection at interface IF_GW_CON must be established
2698
and the role “(authorised) Consumer” is assigned to the user with his used display unit by the TOE.
2699
Different Consumer can use different display units. The amount of allowed connection attempts at
2700
IF_GW_CON is set to 5. In case the amount of allowed connection attempts is reached, the TOE
2701
blocks IF_GW_CON (FIA_AFL.1). The display unit has to technically support the applied
2702
authentication mechanism and the HTTP protocol version 1.1 according to [RFC 2616] as
2703
communication protocol. Data is provided as HTML data stream and transferred to the display unit.
2704
In this case, further processing of the transmitted data stream is carried out by the display unit.
2705
According to [TR-03109-1], the TOE exclusively transfers Consumer specific consumption data to the
2706
display unit. Additionally, the TOE displays its version number and the current time to the authorised
2707
Consumer via the interface IF_GW_CON (FMT_MOF.1). The Consumer can be identified in a clear
2708
and unambiguous manner due to the applied authentication mechanism. Moreover, the TOE ensures
2709
that exclusively the data actually assigned to the Consumer is provided at the display unit via
2710
IF_GW_CON (FIA_USB.1).
2711
7.5 SF.5: Audit and Logging
2712
The TOE generates audit data for all actions assigned in the System-Log (FAU_GEN.1/SYS), the
2713
Consumer-Log (FAU_GEN.1/CON), and the Calibration-Log (FAU_GEN.1/CAL) as well. On the one
2714
hand, this applies to the values measured by the Meter (Consumer-Log) and on the other hand to
2715
system data (System-Log) used by the Gateway Administrator of the TOE in order to check the TOE’s
2716
current functional status. In addition, metrological entries are created in the Calibration-Log. The TOE
2717
thus distinguishes between the following log classes:
2718
a) System-Log
2719
Security Target, SMGW Integrationsmodul Version 1.0
Page 141
b) Consumer-Log
2720
c) Calibration-Log
2721
The TOE audits and logs all security functions that are used. Thereby, the TOE component
2722
accomplishing this security audit functionality includes the necessary rules monitoring these audited
2723
events and through this indicating a potential violation of the enforcement of the TOE security
2724
functionality (e. g. in case of an integrity violation, replay attack or an authentication failure). If such
2725
a security breach is detected, it is shown as such in the log entry (FAU_SAA.1/SYS).
2726
The System-Log can only be read by the authorized Gateway Administrator via interface
2727
IF_GW_WAN or by an authorized Service Technician via interface IF_GW_SRV (FAU_SAR.1/SYS).
2728
Potential security breaches are separately indicated and identified as such in the System-Log and the
2729
GWA gets informed about this potential security breach (FAU_ARP.1/SYS). Data of the Consumer-
2730
Log can exclusively be viewed by authenticated Consumers via interface IF_GW_CON designed to
2731
display consumption data (FAU_SAR.1/CON). The data included in the Calibration-Log can only be
2732
read by the authenticated Gateway Administrator via interface IF_GW_WAN (FAU_SAR.1/CAL).
2733
If possible, each log entry is assigned to an identity that is known to the TOE. For audit events
2734
resulting from actions of identified users resp. roles, the TOE associates the generated log
2735
information to the identified users while generating the audit information (FAU_GEN.2).
2736
Generated audit and log data are stored in a cryptographically secured storage. For this purpose, a
2737
file-based SQL database system is used securing its’ data using an AES-XTS-128 encrypted file system
2738
(AES in XTS mode with 128-bit keys) according to [FIPS Pub. 197] and [NIST 800-38E]. This is achieved
2739
by using a device-specific AES key so that the secure environment can only be accessed with the
2740
associated symmetric key available. Using an appropriately limited access of this symmetric, the TOE
2741
implements the necessary rules so that it can be ensured that unauthorised modification or deletion
2742
is prohibited (FAU_STG.2).
2743
Audit and log data are stored in separate locations: One location is used to store Consumer-specific
2744
log data (Consumer-Log) whereas device status data and metrological data are stored in a separate
2745
location: status data are stored in the System-Log and metrological data are stored in the Calibration-
2746
Security Target, SMGW Integrationsmodul Version 1.0
Page 142
Log. Each of these logs is located in physically separate databases secured by different cryptographic
2747
keys. In case of several external meters, a separate database is created for each Meter to store the
2748
respective consumption and log data (FAU_GEN.2).
2749
If the audit trail of the System-Log or the Consumer-Log is full (so that no further data can be added),
2750
the oldest entries in the audit trail are overwritten (FAU_STG.2, FAU_STG.4/SYS, FAU_STG.4/CON).
2751
If the Consumer-Log ‘s oldest audit record must be kept because the period of billing verification (of
2752
usually 15 months) has not beeen reached, the TOE’s metrological activity is paused until the oldest
2753
audit record gets deletable. Thereafter, the TOE’s metrological activity is started again through an
2754
internal timer. Moreover, the mechanism for storing log entries is designed in a way that these
2755
entries are cryptographically protected against unauthorized deletion. This is especially achieved by
2756
assigning cryptographic keys to each of the individual databases for the System-Log, Consumer-Log
2757
and Calibration-Log.
2758
If the Calibration-Log cannot store any further data, the operation of the TOE is stopped through the
2759
termination of its metering services and the TOE informs the Gateway Administrator by creating an
2760
entry in the System-Log, so that additional measures can be taken by the Gateway Administrator.
2761
Calibration-Log entries are never overwritten by the TOE (FAU_STG.2, FAU_STG.4/CAL,
2762
FMT_MOF.1).
2763
The TOE anonymizes the data in a way that no conclusions about a specific person or user can be
2764
drawn from the log or recorded consumption data. Stored consumption data are exclusively
2765
intended for accounting with the energy supplier. The data stored in the System-Log are used for
2766
analysis purposes concerning necessary technical analyses and possible security-related information.
2767
Security Target, SMGW Integrationsmodul Version 1.0
Page 143
7.6 SF.6: TOE Integrity Protection
2768
The TOE makes physical tampering detectable through the TOE's sealed packaging of the device. So if
2769
an attacker opens the case, this can be physically noticed, e. g. by the Service Technician
2770
(FPT_PHP.1).
2771
The TOE provides a secure boot mechanism. Beginning from the AES-128-encrypted bootloader
2772
protected by a digital signature applied by the TOE manufacturer, each subsequent step during the
2773
boot process is based on the previous step establishing a continuous forward-concatenation of
2774
cryptographical verification procedures. Thus, it is ensured that the firmware, the service layers and
2775
the software application in general is tested by the TOE during initial startup. Thereby, a test of the
2776
TSF data being part of the software application is included. During this self-test, it is checked that the
2777
electronic system of the physical device, the firmware components of the TOE included and the
2778
software application are in authentic condition. This self-test can also be run at the request of the
2779
successfully authenticated Gateway Administrator via interface IF_GW_WAN or at the request of the
2780
successfully authenticated Service Technician via interface IF_GW_SRV. At the request of the
2781
successfully authenticated Consumer via interface IF_GW_CON, the TOE will only test the integrity of
2782
the Smart Metering software application (without the firmware) and the completeness of the TSF
2783
data stored in the TOE’s database. Additionally, the TOE itself runs this self-test periodically at least
2784
once a month during normal operation. The integrity of TSF data stored in the TOE’s database is
2785
always tested during read access of that part of TSF data (FPT_TST.1).
2786
If an integrity violation of the TOE’s hardware / firmware or of the TOE’s software application is
2787
detected or if the deviation between local system time of the TOE and the reliable external time
2788
source is too large, further use of the TOE for the purpose of gathering Meter Data is not possible.
2789
Also in this case, the TOE signals the incorrect status via a suitable signal output on the case of the
2790
device, and the further use of the TOE for the purpose of gathering Meter Data is not allowed
2791
(FPT_FLS.1).
2792
Basically, if an integrity violation is detected, the TOE will create an entry in the System Log to
2793
document this status for the authorised Gateway Administrator on interface IF_GW_WAN resp. for
2794
Security Target, SMGW Integrationsmodul Version 1.0
Page 144
the authorised Service Technician on interface IF_GW_SRV (FAU_ARP.1/SYS, FAU_GEN.1/SYS,
2795
FAU_SAR.1/SYS, FPT_TST.1).
2796
7.7 TSS Rationale
2797
The following table shows the correspondence analysis for the described TOE security functionalities
2798
and the security functional requirements.
2799
SF.1
SF.2
SF.3
SF.4
SF.5
SF.6
FAU_ARP.1/SYS X (X)
FAU_GEN.1/SYS X (X)
FAU_SAA.1/SYS X
FAU_SAR.1/SYS X (X)
FAU_STG.4/SYS X
FAU_GEN.1/CON X
FAU_SAR.1/CON X
FAU_STG.4/CON X
FAU_GEN.1/CAL X
FAU_SAR.1/CAL X
FAU_STG.4/CAL X
FAU_GEN.2 X
FAU_STG.2 X
FCO_NRO.2 X X
FCS_CKM.1/TLS X
FCS_COP.1/TLS X
FCS_CKM.1/CMS X
FCS_COP.1/CMS X
FCS_CKM.1/MTR X X
FCS_COP.1/MTR X X
Security Target, SMGW Integrationsmodul Version 1.0
Page 145
SF.1
SF.2
SF.3
SF.4
SF.5
SF.6
FCS_CKM.4 X X
FCS_COP.1/HASH X
FCS_COP.1/MEM X
FDP_ACC.2 X
FDP_ACF.1 X
FDP_IFC.2/FW X
FDP_IFF.1/FW X
FDP_IFC.2/MTR X
FDP_IFF.1/MTR X
FDP_RIP.2 X X
FDP_SDI.2 X
FIA_ATD.1 X
FIA_AFL.1 X
FIA_UAU.2 X
FIA_UAU.5 X
FIA_UAU.6 X
FIA_UID.2 X
FIA_USB.1 X X
FMT_MOF.1 X X X
FMT_SMF.1 X
FMT_SMR.1 X
FMT_MSA.1/AC X
FMT_MSA.3/AC X
FMT_MSA.1/FW X
FMT_MSA.3/FW X
FMT_MSA.1/MTR X
FMT_MSA.3/MTR X
FPR_CON.1 X
Security Target, SMGW Integrationsmodul Version 1.0
Page 146
SF.1
SF.2
SF.3
SF.4
SF.5
SF.6
FPR_PSE.1 X
FPT_FLS.1 X
FPT_RPL.1 X
FPT_STM.1 X
FPT_TST.1 X
FPT_PHP.1 X
FTP_ITC.1/WAN X
FTP_ITC.1/MTR X
FTP_ITC.1/USR X X
Table 19: Rationale for the SFR and the TOE Security Functionalities 224
2800
224 Please note that SFRs marked with “(X)” only have supporting effect on the fulfilment of the TSF.
Security Target, SMGW Integrationsmodul Version 1.0
Page 147
8 List of Tables
2801
Table 1: TOE product classifications ...................................................................................................... 9
2802
Table 2: Communication flows between devices in different networks................................................ 26
2803
Table 3: Mandatory TOE external interfaces........................................................................................ 31
2804
Table 4: Cryptographic support of the TOE and its Security Module................................................... 32
2805
Table 5: Roles used in the Security Target............................................................................................ 38
2806
Table 6: Assets (User data) ................................................................................................................... 40
2807
Table 7: Assets (TSF data).................................................................................................................... 41
2808
Table 8: Rationale for Security Objectives ........................................................................................... 58
2809
Table 9: List of Security Functional Requirements............................................................................... 69
2810
Table 10: Overview over audit processes.............................................................................................. 70
2811
Table 11: Events for consumer log........................................................................................................ 74
2812
Table 12: Content of calibration log...................................................................................................... 78
2813
Table 13: Restrictions on Management Functions.............................................................................. 102
2814
Table 14: SFR related Management Functionalities ........................................................................... 105
2815
Table 15: Gateway specific Management Functionalities................................................................... 105
2816
Table 16: Assurance Requirements..................................................................................................... 114
2817
Table 17: Fulfilment of Security Objectives ....................................................................................... 117
2818
Table 18: SFR Dependencies .............................................................................................................. 125
2819
Table 19: Rationale for the SFR and the TOE Security Functionalities ............................................ 146
2820
2821
Security Target, SMGW Integrationsmodul Version 1.0
Page 148
9 List of Figures
2822
Figure 1: The TOE and its direct environment...................................................................................... 12
2823
Figure 2: The logical interfaces of the TOE.......................................................................................... 15
2824
Figure 3: The TOE’s protocol stack...................................................................................................... 19
2825
Figure 4: Cryptographic information flow for distributed Meters and Gateway................................... 36
2826
2827
Security Target, SMGW Integrationsmodul Version 1.0
Page 149
10 Appendix
2828
10.1 Mapping from English to German terms
2829
English term German term
billing-relevant abrechnungsrelevant
CLS, Controllable Local System dezentral steuerbare Verbraucher- oder Erzeugersysteme
Consumer
Anschlussnutzer; Letztverbraucher (im verbrauchenden
Sinne); u.U. auch Einspeiser
Consumption Data Verbrauchsdaten
Gateway Kommunikationseinheit
Grid Netz (für Strom/Gas/Wasser)
Grid Status Data Zustandsdaten des Versorgungsnetzes
LAN, Local Area Network Lokales Kommunikationsnetz
LMN, Local Metrological Network Lokales Messeinrichtungsnetz
Meter Messeinrichtung (Teil eines Messsystems)
Processing Profiles Konfigurationsprofile
Security Module Sicherheitsmodul (z.B. eine Smart Card)
Service Provider Diensteanbieter
Smart Meter,
Smart Metering System 225
Intelligente, in ein Kommunikationsnetz eingebundene,
elektronische Messeinrichtung (Messsystem)
TOE EVG (Evaluierungsgegenstand)
WAN, Wide Area Network Weitverkehrsnetz (für Kommunikation)
2830
225 Please note that the terms “Smart Meter” and “Smart Metering System” are used synonymously within this document.
Security Target, SMGW Integrationsmodul Version 1.0
Page 150
10.2 Glossary
2831
Term Description
Authenticity property that an entity is what it claims to be (according to [SD_6])
Block Tariff Tariff in which the charge is based on a series of different energy/volume
rates applied to successive usage blocks of given size and supplied during
a specified period. (according to [CEN])
BPL Broadband Over Power Lines, a method of power line communication
CA Certification Authority, an entity that issues digital certificates.
CLS config
CLS config
(secondary asset)
See chapter 3.2
CMS Cryptographic Message Syntax
Confidentiality the property that information is not made available or disclosed to
unauthorised individuals, entities, or processes (according to [SD_6])
Consumer End user of electricity, gas, water or heat (according to [CEN]). See
chapter 3.1
DCP Data Co-Processor; security hardware of the CPU
DLMS Device Language Message Specification
DTBS Data To Be Signed
EAL Evaluation Assurance Level
Energy Service Provider Organisation offering energy related services to the Consumer (according
to [CEN])
ETH Ethernet
external entity See chapter 3.1
firmware update See chapter 3.2
Gateway Administrator
(GWA)
See chapter 3.1
Gateway config
(secondary asset)
See chapter 3.2
Gateway time See chapter 3.2
GPRS General Packet Radio Service, a packet oriented mobile data service
Home Area Network
(HAN)
In-house data communication network which interconnects domestic
equipment and can be used for energy management purposes (adopted
according to [CEN]).
Integrity property that sensitive data has not been modified or deleted in an
unauthorised and undetected manner (according to [SD_6])
IT-System Computersystem
Security Target, SMGW Integrationsmodul Version 1.0
Page 151
Term Description
Local Area Network (LAN) Data communication network, connecting a limited number of
communication devices (Meters and other devices) and covering a
moderately sized geographical area within the premises of the consumer.
In the context of this ST, the term LAN is used as a hypernym for HAN and
LMN (according to [CEN], adopted).
Local attacker See chapter 3.4
LTE Long Term Evolution mobile broadband communication standard
Meter config
(secondary asset)
See chapter 3.2
Local Metrological
Network (LMN)
In-house data communication network which interconnects metrological
equipment.
Meter Data See chapter 3.2
Meter Data Aggregator
(MDA)
Entity which offers services to aggregate metering data by grid supply
point on a contractual basis.
NOTE: The contract is with a supplier. The aggregate is of all that
supplier's consumers connected to that particular grid supply point. The
aggregate may include both metered data and data estimated by
reference to standard load profiles (adopted from [CEN])
Meter Data Collector
(MDC)
Entity which offers services on a contractual basis to collect metering
data related to a supply and provide it in an agreed format to a data
aggregator (that can also be the DNO).
NOTE: The contract is with a supplier or a pool. The collection may be
carried out by manual or automatic means. ([CEN])
Meter Data Management
System (MDMS)
System for validating, storing, processing and analysing large quantities
of Meter Data. ([CEN])
Metrological Area
Network
In-house data communication network which interconnects metrological
equipment (i.e. Meters)
OEM Original Equipment Manufacturer
OMS Open Metering System
OCOTP On-Chip One-time-programmable
Personally Identifiable
Information (PII)
Personally Identifiable Information 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.
RJ45 registered jack #45; a standardized physical network interface
RMII Reduced Media Independent Interface
RTC Real Time Clock
Service Technician Human entity being responsible for diagnostic purposes.
Security Target, SMGW Integrationsmodul Version 1.0
Page 152
Term Description
Smart Metering System The Smart Metering System consists of a Smart Meter Gateway and
connected to one or more meters. In addition, CLS (i.e. generation plants)
may be connected with the gateway for dedicated communication
purposes.
SML Smart Message Language
Tariff Price structure (normally comprising a set of one or more rates of charge)
applied to the consumption or production of a product or service
provided to a Consumer (according to [CEN]).
TCP/IP Transmission Control Protocol / Internet Protocol
TLS Transport Layer Security protocol according to [RFC 5246]
TOE Target of Evaluation - set of software, firmware and/or hardware possibly
accompanied by guidance
TSF TOE security functionality
UART Universal Asynchronous Receiver Transmitter
WAN attacker See chapter 3.4
WLAN Wireless Local Area Network
2832
Security Target, SMGW Integrationsmodul Version 1.0
Page 153
11 Literature
2833
[CC] Common Criteria for Information Technology Security Evaluation –
2834
Part 1: Introduction and general model, September 2012, version 3.1,
2835
Revision 4, CCMB-2012-09-001,
2836
http://www.commoncriteriaportal.org/files/ccfiles/CCPART1V3.1R4.pdf
2837
Part 2: Security functional requirements, September 2012, version 3.1,
2838
Revision 4, CCMB-2012-09-002,
2839
http://www.commoncriteriaportal.org/files/ccfiles/CCPART2V3.1R4.pdf
2840
Part 3: Security assurance requirements, September 2012, version 3.1,
2841
Revision 4, CCMB-2012-09-003,
2842
http://www.commoncriteriaportal.org/files/ccfiles/CCPART3V3.1R4.pdf
2843
[CEN] SMART METERS CO-ORDINATION GROUP (SM-CG) Item 5. M/441 first phase
2844
deliverable – Communication – Annex: Glossary (SMCG/Sec0022/DC)
2845
[PP_GW] Protection Profile for the Gateway of a Smart Metering System (Smart Meter
2846
Gateway PP), Schutzprofil für die Kommunikationseinheit eines intelligenten
2847
Messsystems für Stoff- und Energiemengen, SMGW-PP, v.1.3, Bundesamt für
2848
Sicherheit in der Informationstechnik, 31.03.2014
2849
[SecModPP] Protection Profile for the Security Module of a Smart Meter Gateway
2850
(Security Module PP), Schutzprofil für das Sicherheitsmodul der
2851
Kommunikationseinheit eines intelligenten Messsystems für Stoff- und
2852
Energiemengen, SecMod-PP, Version 1.0.2, Bundesamt für Sicherheit in der
2853
Informationstechnik, 18.10.2013
2854
[SD_6] ISO/IEC JTC 1/SC 27 N7446, Standing Document 6 (SD6): Glossary of IT
2855
Security Terminology 2009-04-29, available at
2856
http://www.teletrust.de/uploads/media/ISOIEC_JTC1_SC27_IT_Security_Glo
2857
ssary_TeleTrusT_Documentation.pdf
2858
Security Target, SMGW Integrationsmodul Version 1.0
Page 154
[TR-02102] Technische Richtlinie BSI TR-02102, Kryptographische Verfahren:
2859
Empfehlungen und Schlüssellängen, Bundesamt für Sicherheit in der
2860
Informationstechnik, Version 2017-01
2861
[TR-03109] Technische Richtlinie BSI TR-03109, Version 1.0, Bundesamt für Sicherheit in
2862
der Informationstechnik, 18.03.2013
2863
[TR-03109-1] Technische Richtlinie BSI TR-03109-1, Anforderungen an die Interoperabilität
2864
der Kommunikationseinheit eines Messsystems, Version 1.0, Bundesamt für
2865
Sicherheit in der Informationstechnik, 18.03.2013
2866
[TR-03109-1-I] BSI TR-03109-1 Anlage I, CMS-Datenformat für die
2867
Inhaltsdatenverschlüsselung und -signatur, Version 1.0, Bundesamt für
2868
Sicherheit in der Informationstechnik, 18.03.2013
2869
[TR-03109-1-II] Technische Richtlinie BSI TR-03109-1 Anlage II, COSEM/http Webservices,
2870
Version 1.0, Bundesamt für Sicherheit in der Informationstechnik, 18.03.2013
2871
[TR-03109-1-IIIa] Technische Richtlinie BSI TR-03109-1 Anlage IIIa, Feinspezifikation „Drahtlose
2872
LMN-Schnittstelle“ Teil 1, Version 1.0, Bundesamt für Sicherheit in der
2873
Informationstechnik, 18.03.2013
2874
[TR-03109-1-IIIb] Technische Richtlinie BSI TR-03109-1 Anlage IIIb, Feinspezifikation „Drahtlose
2875
LMN-Schnittstelle“ Teil 2, Version 1.0, Bundesamt für Sicherheit in der
2876
Informationstechnik, 18.03.2013
2877
[TR-03109-1-IV] Technische Richtlinie BSI TR-03109-1 Anlage IV, Feinspezifikation
2878
„Drahtgebundene LMN-Schnittstelle“, Version 1.0, Bundesamt für Sicherheit
2879
in der Informationstechnik, 18.03.2013
2880
[TR-03109-1-V] Technische Richtlinie BSI TR-03109-1 Anlage V, Anforderungen zum Betrieb
2881
beim Administrator, Version 1.0, Bundesamt für Sicherheit in der
2882
Informationstechnik, 18.03.2013
2883
Security Target, SMGW Integrationsmodul Version 1.0
Page 155
[TR-03109-1-VI] Technische Richtlinie BSI TR-03109-1 Anlage VI, Betriebsprozesse, Version
2884
1.0, Bundesamt für Sicherheit in der Informationstechnik, 18.03.2013
2885
[TR-03109-2] Technische Richtlinie BSI TR-03109-2, Smart Meter Gateway – Anforderungen
2886
an die Funktionalität und Interoperabilität des Sicherheitsmoduls, Version
2887
1.1, Bundesamt für Sicherheit in der Informationstechnik, 15.12.2014
2888
[TR-03109-3] Technische Richtlinie BSI TR-03109-3, Kryptographische Vorgaben für die
2889
Infrastruktur von intelligenten Messsystemen, Version 1.1, Bundesamt für
2890
Sicherheit in der Informationstechnik, 17.04.2014
2891
[TR-03109-4] Technische Richtlinie BSI TR-03109-4, Smart Metering PKI - Public Key
2892
Infrastruktur für Smart Meter Gateways, Version 1.2.1, Bundesamt für
2893
Sicherheit in der Informationstechnik, 09.08.2017
2894
[TR-03111] Technische Richtlinie BSI TR-03111, Elliptic Curve Cryptography (ECC), Version
2895
2.0, 28.06.2012
2896
[TR-03116-3] Technische Richtlinie BSI TR-03116-3, Kryptographische Vorgaben für
2897
Projekte der Bundesregierung, Teil 3 - Intelligente Messsysteme, Stand 2017,
2898
Bundesamt für Sicherheit in der Informationstechnik, 23.01.2017
2899
[ADV_ARC] Beschreibung der Sicherheitsarchitektur, SMGW Integrationsmodul Version
2900
1.0, Version 2.8, 29.10.2018, OpenLimit SignCubes AG, Power Plus
2901
Communications AG
2902
[AGD_Consumer] Handbuch für Verbraucher, SMGW Integrationsmodul Version 1.0, Version
2903
3.5, 02.10.2018
2904
[AGD_Techniker] Handbuch für Service-Techniker, SMGW Integrationsmodul Version 1.0,
2905
Version 3.7, 02.10.2018
2906
[AGD_GWA] Handbuch für Hersteller von Smart-Meter Gateway-Administrations-
2907
Software, SMGW Integrationsmodul Version 1.0, Version 3.3, 02.10.2018
2908
Security Target, SMGW Integrationsmodul Version 1.0
Page 156
[AGD_SEC] Auslieferungs- und Fertigungsprozeduren, Anhang Sichere Auslieferung,
2909
SMGW Integrationsmodul Version 1.0, Version 0.7, 02.10.2018
2910
[FIPS Pub. 140-2] NIST, FIPS 140-2, Security Requirements for cryptographic modules, 2001
2911
[FIPS Pub. 180-4] NIST, FIPS 180-4, Secure Hash Standard, 2012
2912
[FIPS Pub. 197] NIST, FIPS 197, Advances Encryption Standard (AES), 2001
2913
[IEEE 802.3] IEEE Std 802.3-2008, IEEE Standard for Information technology,
2914
Telecommunications and information exchange between systems, Local and
2915
metropolitan area networks, Specific requirements, 2008
2916
[ISO 10116] ISO/IEC 10116:2006, Information technology -- Security techniques -- Modes
2917
of operation for an n-bit block cipher, 2006
2918
[NIST 800-38A] NIST Special Publication 800-38A, Recommendation for Block Cipher Modes
2919
of Operation: Methods and Techniques, December 2001,
2920
http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-
2921
38a.pdf
2922
[NIST 800-38D] NIST Special Publication 800-38D, Recommendation for Block Cipher Modes
2923
of Operation: Galois/Counter Mode (GCM) and GMAC, M. Dworkin,
2924
November 2007, http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-
2925
38D.pdf
2926
[NIST 800-38E] NIST Special Publication 800-38E, Recommendation for Block Cipher Modes
2927
of Operation: The XTS-AES Mode for Confidentiality on Storage Devices, M.
2928
Dworkin, January, 2010, http://csrc.nist.gov/publications/nistpubs/800-
2929
38E/nist-sp-800-38E.pdf
2930
[RFC 2104] RFC 2104, HMAC: Keyed-Hashing for Message Authentication, M. Bellare, R.
2931
Canetti und H. Krawczyk, February 1997, http://rfc-editor.org/rfc/rfc2104.txt
2932
Security Target, SMGW Integrationsmodul Version 1.0
Page 157
[RFC 2616] RFC 2616, Hypertext Transfer Protocol - HTTP/1.1, R. Fielding, J. Gettys, J.
2933
Mogul, H. Frystyk, P. Masinter, P. Leach, T. Berners-Lee, June 1999, http://rfc-
2934
editor.org/rfc/rfc2616.txt
2935
[RFC 7616] RFC 7616, HTTP Digest Access Authentication, R. Shekh-Yusef, D. Ahrens, S.
2936
Bremer, September 2015, http://rfc-editor.org/rfc/rfc7616.txt
2937
[RFC 3394] RFC 3394, Schaad, J. and R. Housley, Advanced Encryption Standard (AES) Key
2938
Wrap Algorithm, September 2002, http://rfc-editor.org/rfc/rfc3394.txt
2939
[RFC 3565] RFC 3565, J. Schaad, Use of the Advanced Encryption Standard (AES)
2940
Encryption Algorithm in Cryptographic Message Syntax (CMS), July 2003,
2941
http://rfc-editor.org/rfc/rfc3565.txt
2942
[RFC 4493] IETF RFC 4493, The AES-CMAC Algorithm, J. H. Song, J. Lee, T. Iwata, June
2943
2006, http://www.rfc-editor.org/rfc/rfc4493.txt
2944
[RFC 5083] RFC 5083, R. Housley, Cryptographic Message Syntax (CMS)
2945
Authenticated-Enveloped-Data Content Type, November 2007,
2946
http://www.ietf.org/rfc/rfc5083.txt
2947
[RFC 5084] RFC 5084, R. Housley, Using AES-CCM and AES-GCM Authenticated
2948
Encryption in the Cryptographic Message Syntax (CMS), November 2007,
2949
http://www.ietf.org/rfc/rfc5084.txt
2950
[RFC 5114] RFC 5114, Additional Diffie-Hellman Groups for Use with IETF Standards, M.
2951
Lepinski, S. Kent, January 2008, http://www.ietf.org/rfc/rfc5114.txt
2952
[RFC 5246] RFC 5246, T. Dierks, E. Rescorla, The Transport Layer Security (TLS) Protocol
2953
Version 1.2, August 2008, http://www.ietf.org/rfc/rfc5246.txt
2954
[RFC 5289] RFC 5289, TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois
2955
Counter Mode (GCM), E. Rescorla, RTFM, Inc., August 2008,
2956
http://www.ietf.org/rfc/rfc5289.txt
2957
Security Target, SMGW Integrationsmodul Version 1.0
Page 158
[RFC 5639] RFC 5639, Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and
2958
Curve Generation, M. Lochter, BSI, J. Merkle, secunet Security Networks,
2959
March 2010, http://www.ietf.org/rfc/rfc5639.txt
2960
[RFC 5652] RFC 5652, Cryptographic Message Syntax (CMS), R. Housley, Vigil Security,
2961
September 2009, http://www.ietf.org/rfc/rfc5652.txt
2962
[EIA RS-485] EIA Standard RS-485, Electrical Characteristics of Generators and Receivers
2963
for Use in Balanced Multipoint Systems, ANSI/TIA/EIA-485-A-98, 1983/R2003
2964
[EN 13757-1] M-Bus DIN EN 13757-1: Kommunikationssysteme für Zähler und deren
2965
Fernablesung Teil 1: Datenaustausch
2966
[EN 13757-3] M-Bus DIN EN 13757-3, Kommunikationssysteme für Zähler und deren
2967
Fernablesung Teil 3: Spezielle Anwendungsschicht
2968
[EN 13757-4] M-Bus DIN EN 13757-4, Kommunikationssysteme für Zähler und deren
2969
Fernablesung Teil 4: Zählerauslesung über Funk, Fernablesung von Zählern im
2970
SRD-Band von 868 MHz bis 870 MHz
2971
[IEC-62056-5-3-8] Electricity metering – Data exchange for meter reading, tariff and load
2972
control – Part 5-3-8: Smart Message Language SML, 2012
2973
[IEC-62056-6-1] IEC-62056-6-1, Datenkommunikation der elektrischen Energiemessung, Teil
2974
6-1: OBIS Object Identification System, 2017, International Electrotechnical
2975
Commission
2976
[IEC-62056-6-2] IEC-62056-6-2, Datenkommunikation der elektrischen Energiemessung -
2977
DLMS/COSEM, Teil 6-2: COSEM Interface classes, 2017, International
2978
Electrotechnical Commission
2979
[IEC-62056-21] IEC-62056-21, Direct local data exchange - Mode C, 2011, International
2980
Electrotechnical Commission
2981
Security Target, SMGW Integrationsmodul Version 1.0
Page 159
[LUKS] LUKS On-Disk Format Specification Version 1.2.1, Clemens Fruhwirth,
2982
October 16th, 2011
2983
[PACE] The PACE-AA Protocol for Machine Readable Travel Documents, and its
2984
Security, Jens Bender, Ozgur Dagdelen, Marc Fischlin and Dennis Kügler,
2985
http://fc12.ifca.ai/pre-proceedings/paper_49.pdf
2986
[X9.63] ANSI X9.63, Public Key Cryptography for the Financial Services Industry: Key
2987
Agreement and Key Transport Using Elliptic Curve Cryptography, 2011
2988
[G865] DVGW-Arbeitsblatt G865 Gasabrechnung, 11/2008
2989
[VDE4400] VDE-AR-N 4400:2011-09, Messwesen Strom, VDE-Anwendungsregel,
2990
01.09.2011
2991
[DIN 43863-5] DIN: Herstellerübergreifende Identifikationsnummer für Messeinrichtungen,
2992
2012
2993
2994