Protection Profile for the Gateway of a Smart Metering
1
System (Smart Meter Gateway PP)
2
Schutzprofil für die Kommunikationseinheit eines intelligenten
3
Messsystems für Stoff- und Energiemengen
4
5
6
7
SMGW-PP
8
Version 1.3 - 31 March 2014
9
(Final Release)
10
Certification-ID: BSI-CC-PP-0073
11
SMGW-PP
Federal Office for Information Security
Bundesamt für Sicherheit in der Informationstechnik
12
Postfach 20 03 63
13
53133 Bonn
14
Tel.: +49 228 99 9582-0
15
E-Mail: SmartMeter@bsi.bund.de
16
Internet: http://www.bsi.bund.de
17
© Bundesamt für Sicherheit in der Informationstechnik 2014
18
SMGW-PP
Federal Office for Information Security 3
Table of content
19
1 PP introduction ..................................................................................................................7
20
1.1 Introduction..............................................................................................................7
21
1.2 PP Reference ............................................................................................................8
22
1.3 Specific terms...........................................................................................................8
23
1.4 TOE Overview .......................................................................................................10
24
1.4.1 Introduction ..................................................................................................10
25
1.4.2 Overview of the Gateway in a Smart Metering System ...............................10
26
1.4.3 TOE description............................................................................................13
27
1.4.4 TOE type.......................................................................................................14
28
1.4.5 TOE physical boundary................................................................................14
29
1.4.6 TOE logical boundary ..................................................................................17
30
1.4.7 The logical interfaces of the TOE.................................................................23
31
1.4.8 The cryptography of the TOE and its Security Module ...............................23
32
1.4.9 TOE life-cycle ..............................................................................................27
33
2 Conformance Claims .......................................................................................................28
34
2.1 Conformance statement..........................................................................................28
35
2.2 CC Conformance Claims .......................................................................................28
36
2.3 PP Claim.................................................................................................................28
37
2.4 Conformance claim rationale.................................................................................28
38
2.5 Package Claim........................................................................................................28
39
3 Security Problem Definition ...........................................................................................29
40
3.1 External entities......................................................................................................29
41
3.2 Assets .....................................................................................................................29
42
3.3 Assumptions...........................................................................................................31
43
3.4 Threats....................................................................................................................33
44
3.5 Organizational Security Policies (OSPs) ...............................................................35
45
4 Security Objectives ..........................................................................................................36
46
4.1 Security Objectives for the TOE............................................................................36
47
4.2 Security objectives for the operational environment .............................................39
48
4.3 Security Objectives rationale .................................................................................41
49
4.3.1 Overview ......................................................................................................41
50
4.3.2 Countering the threats...................................................................................41
51
4.3.3 Coverage of organisational security policies................................................43
52
4.3.4 Coverage of assumptions..............................................................................44
53
5 Extended Component definition.....................................................................................45
54
5.1 Communication concealing (FPR_CON) ..............................................................45
55
5.2 Family behaviour ...................................................................................................45
56
5.3 Component levelling..............................................................................................45
57
5.4 Management...........................................................................................................45
58
5.5 Audit.......................................................................................................................45
59
5.6 Communication concealing (FPR_CON.1) ...........................................................45
60
SMGW-PP
4 Federal Office for Information Security
6 Security Requirements ....................................................................................................46
61
6.1 Overview................................................................................................................46
62
6.2 Class FAU: Security Audit.....................................................................................48
63
6.2.1 Introduction ..................................................................................................48
64
6.2.2 Security Requirements for the System Log..................................................50
65
6.2.3 Security Requirements for the Consumer Log .............................................51
66
6.2.4 Security Requirements for the Calibration Log............................................53
67
6.2.5 Security Requirements that apply to all logs................................................54
68
6.3 Class FCO: Communication ..................................................................................55
69
6.3.1 Non-repudiation of origin (FCO_NRO).......................................................55
70
6.4 Class FCS: Cryptographic Support........................................................................55
71
6.4.1 Cryptographic support for TLS ....................................................................55
72
6.4.2 Cryptographic support for CMS...................................................................56
73
6.4.3 Cryptographic support for Meter communication encryption......................57
74
6.4.4 General Cryptographic support ....................................................................59
75
6.5 Class FDP: User Data Protection...........................................................................60
76
6.5.1 Introduction to the Security Functional Policies ..........................................60
77
6.5.2 Gateway Access SFP ....................................................................................60
78
6.5.3 Firewall SFP .................................................................................................62
79
6.5.4 Meter SFP.....................................................................................................63
80
6.5.5 General Requirements on user data protection.............................................65
81
6.6 Class FIA: Identification and Authentication.........................................................66
82
6.6.1 User Attribute Definition (FIA_ATD) ..........................................................66
83
6.6.2 Authentication Failure handling (FIA_AFL) ...............................................66
84
6.6.3 User Authentication (FIA_UAU) .................................................................66
85
6.6.4 User identification (FIA_UID) .....................................................................68
86
6.6.5 User-subject binding (FIA_USB).................................................................68
87
6.7 Class FMT: Security Management.........................................................................68
88
6.7.1 Management of the TSF ...............................................................................68
89
6.7.2 Security management roles (FMT_SMR) ....................................................73
90
6.7.3 Management of security attributes for Gateway access SFP........................73
91
6.7.4 Management of security attributes for Firewall SFP....................................74
92
6.7.5 Management of security attributes for Meter SFP........................................74
93
6.8 Class FPR: Privacy.................................................................................................75
94
6.8.1 Communication Concealing (FPR_CON)....................................................75
95
6.8.2 Pseudonymity (FPR_PSE)............................................................................75
96
6.9 Class FPT: Protection of the TSF...........................................................................76
97
6.9.1 Fail secure (FPT_FLS) .................................................................................76
98
6.9.2 Replay Detection (FPT_RPL) ......................................................................76
99
6.9.3 Time stamps (FPT_STM).............................................................................76
100
6.9.4 TSF self test (FPT_TST) ..............................................................................77
101
6.10 Class FTP: Trusted path/channels..........................................................................78
102
6.10.1 Inter-TSF trusted channel (FTP_ITC) ..........................................................78
103
6.11 Security Assurance Requirements for the TOE .....................................................79
104
6.12 Security Requirements rationale ............................................................................80
105
SMGW-PP
Federal Office for Information Security 5
6.12.1 Security Functional Requirements rationale.................................................80
106
6.12.2 Security Assurance Requirements rationale .................................................88
107
7 Appendix...........................................................................................................................89
108
7.1 Mapping from English to German terms ...............................................................89
109
7.2 Glossary .................................................................................................................89
110
7.3 References..............................................................................................................91
111
112
SMGW-PP
6 Federal Office for Information Security
List of Tables
Table 1: Specific Terms .........................................................................................................................10
113
Table 2: Communication flows between devices in different networks ................................................20
114
Table 3: Mandatory TOE external interfaces.........................................................................................23
115
Table 4: Cryptographic support of the TOE and its Security Module ...................................................24
116
Table 5: Roles used in the Protection profile.........................................................................................29
117
Table 6: Assets (User data) ....................................................................................................................30
118
Table 7: Assets (TSF data).....................................................................................................................31
119
Table 8: Rationale for Security Objectives ............................................................................................41
120
Table 9: List of Security Functional Requirements ...............................................................................48
121
Table 10: Overview over audit processes ..............................................................................................49
122
Table 11: Events for consumer log ........................................................................................................52
123
Table 12: Restrictions on Management Functions.................................................................................69
124
Table 13: SFR related Management Functionalities..............................................................................72
125
Table 14: Gateway specific Management Functionalities .....................................................................72
126
Table 15: Assurance Requirements........................................................................................................80
127
Table 16: Fulfilment of Security Objectives..........................................................................................82
128
Table 17: SFR Dependencies.................................................................................................................88
129
130
List of Figures
Figure 1: The TOE and its direct environment ......................................................................................11
131
Figure 2: The logical interfaces of the TOE...........................................................................................12
132
Figure 3: TOE design: A Gateway and multiple Meters........................................................................15
133
Figure 4: TOE design: One Box Solution..............................................................................................16
134
Figure 5: TOE design: Minimal implementation...................................................................................17
135
Figure 6: Cryptographic workflow for Meter, Gateway and the Security Module...............................26
136
137
SMGW-PP
Federal Office for Information Security 7
1 PP introduction
138
1.1 Introduction
139
The increasing use of green energy and upcoming technologies around e-mobility lead to an increasing
140
demand for functions of a so called smart grid. A smart grid hereby refers to a commodity1
network
141
that intelligently integrates the behaviour and actions of all entities connected to it – suppliers of
142
natural resources and energy, its consumers and those that are both – in order to efficiently ensure a
143
more sustainable, economic and secure supply of a certain commodity (definition adopted from
144
[CEN]).
145
In its vision such a smart grid would allow to invoke consumer devices to regulate the load and
146
availability of resources or energy in the grid, e.g. by using consumer devices to store energy or by
147
triggering the use of energy based upon the current load of the grid2
. Basic features of such a smart use
148
of energy or resources are already reality. Providers of electricity in Germany, for example, have to
149
offer at least one tariff that has the purpose to motivate the consumer to save energy.
150
In the past, the production of electricity followed the demand/consumption of the consumers.
151
Considering the strong increase in renewable energy and the production of energy as a side effect in
152
heat generation today, the consumption/demand has to follow the – often externally controlled –
153
production of energy. Similar mechanisms can exist for the gas network to control the feed of biogas
154
or hydrogen based on information submitted by consumer devices.
155
An essential aspect for all considerations of a smart grid is the so called Smart Metering System that
156
meters the consumption or production of certain commodities at the consumer’s side and allows
157
sending the information about the consumption or production to external entities, which is then the
158
basis for e.g. billing the consumption or production.
159
This Protection Profile defines the security objectives and corresponding requirements for a Gateway
160
which is the central communication component of such a Smart Metering System (please refer to
161
chapter 1.4.2 for a more detailed overview). The PP is directed to developers of Smart Meter
162
Gateways and informs them about the requirements that have to be implemented. It is further directed
163
to stakeholders being responsible for purchasing Smart Meter Gateways.
164
The Target of Evaluation (TOE) that is described in this document is an electronic unit comprising
165
hardware and software/firmware3
used for collection, storage and provision of Meter Data4
from one
166
or more Meters of one or multiple commodities.
167
The Gateway connects a Wide Area Network (WAN) with a Network of Devices of one or more Smart
168
Metering devices (Local Metrological Network, LMN) and the consumer Home Area Network (HAN),
169
which hosts Controllable Local Systems (CLS). The security functionality of the TOE comprises
170
 protection of confidentiality, authenticity, integrity of data and
171
 information flow control
172
mainly to protect the privacy of consumers, to ensure a reliable billing process and to protect the Smart
173
Metering System and a corresponding large scale infrastructure of the smart grid. The availability of
174
the Gateway is not addressed by this PP.
175
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 functionality requires consent or a contract between the supplier and the consumer,
alternatively a regulatory requirement.
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”.
SMGW-PP
8 Federal Office for Information Security
1.2 PP Reference
176
Title: Protection Profile for the Gateway of a Smart Metering System (Smart Meter
Gateway PP)
Version 1.3 (Final Release)
Date 31.03.2014
Authors Dr. Helge Kreutzmann, M.Sc. Stefan Vollmer (BSI)
Registration Bundesamt für Sicherheit in der Informationstechnik (BSI)
Federal Office for Information Security, Germany
Certification-ID BSI-CC-PP-0073
Evaluation
Assurance Level:
The assurance level for this PP is EAL 4 augmented by AVA_VAN.5 and
ALC_FLR.2.
CC-Version 3.1 Revision 4
Keywords Smart Metering, Protection Profile, Meter, Gateway, PP
1.3 Specific terms
177
Various different vocabularies exist in the area of Smart Grid, Smart Metering, and Home Automation.
178
Further, the Common Criteria maintain their own vocabulary. The following table provides an
179
overview over the most prominent terms that are used in this Protection Profile and should serve to
180
avoid any bias. A complete glossary and list of acronyms can be found in chapter 7.2.
181
Term Definition Source (if any)
CLS, Controllable
Local Systems
CLS are systems containing IT-components in the Home
Area Network (HAN) of the consumer that do not belong to
the Smart Metering System but may use the Gateway for
dedicated communication purposes.
CLS may range from local power generation plants,
controllable loads such as air condition and intelligent
household appliances (“white goods”) to applications in
home automation.
Commodity Electricity, gas, water or heat5
Consumer End user of electricity, gas, water or heat. The consumer
can also generate energy using a Distributed Energy
Resource.
[CEN]
5
Please note that this list does not claim to be complete.
SMGW-PP
Federal Office for Information Security 9
Term Definition Source (if any)
Gateway
Smart Meter
Gateway (SMGW)6
Device or unit responsible for collecting Meter Data,
processing Meter Data, providing communication
capabilities for devices in the LMN, protecting devices in
the LAN (such as Controllable Local Systems) against
attacks from the WAN and providing cryptographic
primitives (in cooperation with a Security Module).
The Gateway is specified in this document and combines
aspects of the following devices according to [CEN]:
 Meter Data Collector
 Meter Data Management System
 Meter Data Aggregator
The Gateway does not aim to be a complete implementation
of those devices but focusses on the required security
functionality.
Gateway
Administrator
Authority that installs, configures, monitors, and controls
the Smart Meter Gateway.
HAN, Home Area
Network
In-house data communication network which interconnects
domestic equipment and can be used for energy
management purposes.
[CEN], adopted
LAN, Local Area
Network
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 PP the term
LAN is used as a hypernym for HAN and LMN.
[CEN], adopted
LMN, Local
Metrological
Network
In-house data communication network which interconnects
metrological equipment.
Meter The term Meter refers to a unit for measuring the
consumption or production of a certain commodity with
additional functionality. It collects consumption or
production data and transmits this data to the Gateway. As
not all aspects of a Smart Meter according to [CEN] are
implemented in the descriptions within this document the
term Meter is used.
The Meter has to be able to encrypt and sign the data it
sends and will typically deploy a Security Module for this.
Please note that the term Meter refers to metering devices
for all kinds of commodities.
[CEN], adopted
6
Please note that the terms “Gateway” and “Smart Meter Gateway” (SMGW) are used synonymously within
this document
SMGW-PP
10 Federal Office for Information Security
Term Definition Source (if any)
Meter Data Meter readings that allow calculation of the quantity of a
commodity, for example electricity, gas, water or heat
consumed or produced over a period.
Other readings and data may also be included7
(such as
quality data, events and alarms).
[CEN]
Security Module A Security device utilised by the Gateway for cryptographic
support – typically realised in form of a smart card. The
complete description of the Security Module can be found
in [SecMod-PP].
Service Technician Human entity that is responsible for diagnostic purposes.
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.
User, external entity Human or IT entity possibly interacting with the TOE from
outside of the TOE boundary.
[CC]
WAN, Wide Area
Network
Extended data communication network connecting a large
number of communication devices over a large
geographical area.
[CEN]
Table 1: Specific Terms
182
1.4 TOE Overview
183
1.4.1 Introduction
184
The TOE as defined in this Protection Profile is the Gateway in a Smart Metering System. In the
185
following subsections the overall Smart Metering System will be described first and afterwards the
186
Gateway itself.
187
1.4.2 Overview of the Gateway in a Smart Metering System
188
The following figure provides an overview of the TOE as part of a complete Smart Metering System
189
from a purely functional perspective as used in this PP.8
190
7
Please note that these readings and data may require an explicit endorsement of the consumer
8
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 PP. It does not aim to provide a universal description of
a Smart Metering System for all application cases.
SMGW-PP
Federal Office for Information Security 11
191
Figure 1: The TOE and its direct environment
192
As can be seen in Figure 1 a system for smart metering comprises different functional units in the
193
context of the descriptions in this PP:
194
 The Gateway (as defined in this PP) serves as the communication component between the
195
components in the LAN of the consumer (such as meters and added generation plants) and the
196
outside world. It can be seen as a special kind of firewall dedicated to the smart metering
197
functionality. It also collects, processes, and stores the records from Meter(s) and ensures that
198
only authorised parties have access to them or derivatives thereof. Before sending Meter Data9
199
the information will be encrypted and signed using the services of a Security Module. The
200
Gateway features a mandatory user interface, enabling authorised consumers to access the
201
data relevant to them.
202
 The Meter itself records the consumption or production of one or more commodities (e.g.
203
electricity, gas, water, heat) and submits those records in defined intervals to the Gateway. The
204
Meter Data has to be signed and encrypted before transfer in order to ensure its confidentiality,
205
authenticity, and integrity. The Meter is comparable to a classical meter10
and has comparable
206
security requirements; it will be sealed as classical meters according to the regulations of the
207
9
Please note that readings and data which are not relevant for billing may require an explicit endorsement of
the consumer.
10
In this context, a classical meter denotes a meter without a communication channel, i.e. whose values have to
be read out locally.
SMGW-PP
12 Federal Office for Information Security
calibration authority. The Meter further supports the encryption and integrity protection of its
208
connection to the Gateway11
.
209
 The Gateway utilises the services of a Security Module (e.g. a smart card) as a cryptographic
210
service provider and as a secure storage for confidential assets. The Security Module will be
211
evaluated separately according to the requirements in the corresponding Protection Profile
212
(c.f. [SecMod-PP]).
213
Controllable Local Systems (CLS, as shown in Figure 2) may range from local power generation
214
plants, controllable loads such as air condition and intelligent household appliances (“white goods”) to
215
applications in home automation. CLS may utilise the services of the Gateway for communication
216
services. However, CLS are not part of the Smart Metering System.
217
The following figure introduces the external interfaces of the TOE and shows the cardinality of the
218
involved entities.
219
Please note that the arrows of the interfaces within the Smart Metering System as shown in Figure 2
220
indicate the flow of information. However, it does not indicate that a communication flow can be
221
initiated bi-directionally. Indeed, the following chapters of this PP will place dedicated requirements
222
on the way an information flow can be initiated12
.
223
224
Figure 2: The logical interfaces of the TOE
225
11
It should be noted that this PP 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.
12
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.
SMGW-PP
Federal Office for Information Security 13
The overview of the Smart Metering System as described before is based on a threat model that has
226
been developed for the Smart Metering System and has been motivated by the following
227
considerations:
228
 The Gateway is the central communication unit in the Smart Metering System. It shall be the
229
only unit directly connected to the WAN, to be the first line of defence an attacker located in
230
the WAN would have to conquer.
231
 The Gateway is the central component that collects, processes, and stores Meter Data. It
232
therewith is the primary point for user interaction in the context of the Smart Metering
233
System.
234
 To conquer a Meter in the LMN or CLS in the HAN (that uses the TOE for communication) a
235
WAN attacker first would have to attack the Gateway successfully. All data transferred
236
between LAN and WAN flows via the Gateway which makes it an ideal unit for implementing
237
significant parts of the system's overall security functionality.
238
 Because a Gateway can be used to connect and protect multiple Meters (while a Meter will
239
always be connected to exactly one Gateway) and CLS with the WAN there might be more
240
Meters and CLS in a Smart Metering System than there are Gateways.
241
All these arguments motivated the approach to have a Gateway (using a Security Module for
242
cryptographic support), which is rich in security functionality, strong and evaluated in depth, in
243
contrast to a Meter which will only deploy a minimum of security functions. The Security Module will
244
be evaluated separately.
245
It should be noted that this Protection Profile does not aim to imply any concrete system architecture
246
or product design as long as the security requirements from this Protection Profile are fulfilled. Only
247
in cases where the implementation of the Security Functional Requirements will definitely requires a
248
certain architecture, this architecture is described in this PP in a mandatory way. It will also be
249
possible to combine the functionalities of Gateway and Meter into one or more modules and devices.
250
To underline this approach this PP will further refer to the term “unit” whenever the TOE or another
251
part of the Smart Metering System is described from a functional perspective and only use the term
252
“component” or “device” when a real physical device is described. Possible forms of implementing
253
the units of a Smart Metering System in components are described in chapter 1.4.5.
254
1.4.3 TOE description
255
The Smart Meter Gateway (in the following short: Gateway or TOE) may serve as the communication
256
unit between devices of private and commercial consumers and service providers of a commodity
257
industry (e.g. electricity, gas, water, etc.). It also collects, processes, and stores Meter Data and is
258
responsible for the distribution of this data to external entities.
259
Typically, the Gateway will be placed in the household or premises of the consumer13
of the
260
commodity and enables access to local Meter(s) (i.e. the unit(s) used for measuring the consumption
261
or production of electric power, gas, water, heat etc.) and may enable access to Controllable Local
262
Systems (e.g. power generation plants, controllable loads such as air condition and intelligent
263
household appliances). Roles respectively External Entities in the context of the Gateway are
264
introduced in chapter 3.1.
265
The TOE has a fail-safe design that specifically ensures that any malfunction cannot impact the
266
delivery of a commodity, e.g. energy, gas or water14
.
267
13
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.
14
Indeed, this Protection Profile 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 Protection Profile. 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.
SMGW-PP
14 Federal Office for Information Security
1.4.4 TOE type
268
The TOE is a communication Gateway. It provides different external communication interfaces and
269
enables the data communication between these interfaces and connected IT systems. It further collects,
270
processes, and stores Meter Data.
271
1.4.5 TOE physical boundary
272
1.4.5.1 Introduction
273
The TOE comprises the hardware and firmware that is relevant for the security functionality of the
274
Gateway as defined in this PP. The Security Module that is utilised by the TOE is considered being not
275
part of the TOE15
.
276
As mentioned in chapter 1.4.2 this Protection Profile does not want to imply any concrete physical
277
architecture for the components that make up the Smart Metering System. The following sections
278
introduce some examples of physical representations for the different components of the Smart
279
Metering System – focussing on the Gateway.
280
It should be noted that this overview of possible physical implementations does not claim being a
281
complete overview of all possibilities. The Common Criteria allow to combine multiple TOE into one
282
device and have the flexibility to identify functionality that is not relevant for the security functionality
283
of the TOE or the environment. However, when focussing on a system of multiple TOEs, it is not
284
possible to move security features from the scope of one TOE to another.
285
15
Please note that the security module is physically integrated into the Gateway even though it is not part of the
TOE.
SMGW-PP
Federal Office for Information Security 15
1.4.5.2 Possible TOE design: A Gateway and multiple Meters
286
The following figure provides an example for an implementation of a Gateway as defined in this PP
287
from a physical perspective.
288
It is possible that the Gateway is implemented in one device comprising:
289
 the security relevant parts (i.e. TOE security functionality (TSF)) of the TOE,
290
 the non-security relevant parts of the TOE (e.g. the unit for communication16
), and
291
 the Security Module that is a target of a separate evaluation but is physically located in the
292
device.
293
The Gateway communicates with one or more Meters (in the LMN), provides an interface to the WAN
294
and provides interfaces to the HAN.
295
296
Figure 3: TOE design: A Gateway and multiple Meters
297
16
Please note that this refers to the pure communication services excluding encryption functionality.
SMGW-PP
16 Federal Office for Information Security
1.4.5.3 Possible TOE Design: One Box Solution
298
The components Gateway and Meter may also be realised by a single physical device providing
299
functionality of both. Such a One Box Solution is shown in the following figure. This One Box
300
Solution may be the preferred implementation for one family houses or large houses with several flats
301
where all electricity meters are installed in one single cabinet.
302
303
Figure 4: TOE design: One Box Solution
304
However, also in this case this PP requires the implementation of an external interface for additional
305
meters outside the box that is protected by cryptographic functionality.
306
SMGW-PP
Federal Office for Information Security 17
1.4.5.4 Possible TOE Design: Gateway with external communication components
307
The following figure acknowledges that there may be functional aspects in the context of a Gateway
308
that are essential for the overall operation of the Gateway but not required to enforce the security
309
functionality of the Gateway. Those functionalities may also be implemented in form of external
310
components that do not belong to the TOE.
311
312
Figure 5: TOE design: Minimal implementation
313
Classic examples of such functionality are the communication capabilities to the WAN, LMN or HAN.
314
As long as the requirements for separate networks, encryption and so forth are implemented within the
315
Gateway TSF it may be possible to utilise an external communication component. A failure of such a
316
component would of course lead to an inoperative Gateway. However – as the availability of the
317
Gateway is not within the focus of the requirements in this PP – this would not violate any security
318
requirement.
319
Please note that the requirements around physically separated interfaces for different networks (see
320
also O.SeparateIF) also apply to this configuration as indicated by the multiple arrows between the
321
TOE and its external communication components.
322
1.4.6 TOE logical boundary
323
The logical boundary of the Gateway can be defined by its security features:
324
 Handling of Meter Data, collection and processing of Meter Data, submission to authorised
325
external entities (e.g. one of the service providers involved) where necessary protected by a
326
digital signature
327
 Protection of authenticity, integrity and confidentiality of data temporarily or persistently
328
stored in the Gateway, transferred locally within the LAN and transferred in the WAN
329
(between Gateway and authorised external entities)
330
 Firewalling of information flows to the WAN and information flow control among Meters,
331
Controllable Local Systems and the WAN
332
 A Wake-Up-Service that allows to contact the TOE from the WAN side
333
 Privacy preservation
334
SMGW-PP
18 Federal Office for Information Security
 Management of Security Functionality
335
 Identification and Authentication of TOE users
336
Please note that it is possible that a Gateway provides more functionality than required by this PP. In
337
those cases however, it is essential that the additional functionality is separated from the evaluated
338
functionality in a way that it cannot impact the security functionality.
339
The following sections introduce the security functionality of the TOE in more detail.
340
1.4.6.1 Handling of Meter Data17
341
The Gateway is responsible for handling Meter Data. It receives the Meter Data from the Meter(s),
342
processes it, stores it and submits it to external entities.
343
The TOE utilises Processing Profiles to determine which data shall be sent to which component or
344
external entity. A Processing Profile defines:
345
 how Meter Data must be processed,
346
 which processed Meter Data must be sent in which intervals,
347
 to which component or external entity,
348
 signed using which key material,
349
 encrypted using which key material,
350
 whether processed Meter Data shall be pseudonymised or not, and
351
 which pseudonym shall be used to send the data.
352
The Processing Profiles are not only the basis for the security features of the TOE; they also contain
353
functional aspects as they indicate to the Gateway how the Meter Data shall be processed. More
354
details on the Processing Profiles can be found in [BSI-TR-03109-1].
355
Please note that it is possible that a TOE enforces more than one Processing Profile, specifically if the
356
communication and the contractual requirement for multiple external entities have to be handled.
357
The Gateway will restrict access to (processed) Meter Data in the following ways:
358
 consumers shall be identified and authenticated first before access to any data may be granted,
359
 the Gateway shall accept Meter Data from authorised Meters only,
360
 the Gateway shall send processed Meter Data to correspondingly authorised external entities
361
only.
362
The Gateway shall accept data (e.g. configuration data, firmware updates) from correspondingly
363
authorised Gateway Administrators or correspondingly authorised external entities only. This
364
restriction is a prerequisite for a secure operation and therewith for a secure handling of Meter Data.
365
Further, the Gateway shall maintain a calibration log with all relevant events that could affect the
366
calibration of the Gateway.
367
These functionalities shall
368
 prevent that the Gateway accepts data from or sends data to unauthorised entities,
369
 ensure that only the minimum amount of data leaves the scope of control of the consumer18
,
370
 preserve the integrity of billing processes and as such serve in the interests of the consumer as
371
well as in the interests of the supplier. Both parties are interested in an billing process that
372
ensures that the value of the consumed amount of a certain commodity (and only the used
373
amount) is transmitted19
,
374
 preserve the integrity of the system components and their configurations.
375
17
Please refer to chapter 3.2 for an exact definition of the various data types.
18
This PP does not define the standard on the minimum amount that is acceptable to be submitted. The decision
about the frequency and content of information has to be considered in the context of the contractual situation
between the consumer and the external entities.
19
This statement refers to the standard case and ignores that a consumer may also have an interest to
manipulate the Meter Data.
SMGW-PP
Federal Office for Information Security 19
The TOE offers a local interface to the consumer (see also IF_GW_CON in Figure 2) and allows the
376
consumer to obtain information via this interface. This information comprises the billing-relevant data
377
(to allow the consumer to verify an invoice) and information about which Meter Data has been and
378
will be sent to which external entity. The TOE ensures that the communication to the consumer is
379
protected (e.g. by using SSL/TLS) and ensures that consumers only get access to their own data.
380
Please note that accessing of this interface by the consumer may happen via different technologies as
381
long as the security requirements are fulfilled. The interface IF_GW_CON may be used by a remote
382
display dedicated to this purpose or may be accessed by standard technologies (e.g. via a PC-based
383
web browser)20
.
384
1.4.6.2 Confidentiality protection
385
The TOE protects data from unauthorised disclosure
386
 while received from a Meter via the LMN,
387
 while received from the administrator via the WAN,
388
 while temporarily stored in the volatile memory of the Gateway,
389
 while transmitted to the corresponding external entity via the WAN or HAN.
390
Furthermore, all data, which no longer have to be stored in the Gateway, are securely erased to prevent
391
any form of access to residual data via external interfaces of the TOE.
392
These functionalities shall protect the privacy of the consumer and shall prevent that an unauthorised
393
party is able to disclose any of the data transferred in and from the Smart Metering System (e.g. Meter
394
Data, configuration settings).
395
The TOE utilises the services of its Security Module for aspects of this functionality.
396
1.4.6.3 Integrity and Authenticity protection
397
The Gateway shall provide the following authenticity and integrity protection:
398
 Verification of authenticity and integrity when receiving Meter Data from a Meter via the
399
LMN, to verify that the Meter Data have been sent from an authentic Meter and have not been
400
altered during transmission. The TOE utilises the services of its Security Module for aspects
401
of this functionality.
402
 Application of authenticity and integrity protection measures when sending processed Meter
403
Data to an external entity, to enable the external entity to verify that the processed Meter Data
404
have been sent from an authentic Gateway and have not been changed during transmission.
405
The TOE utilises the services of its Security Module for aspects of this functionality.
406
 Verification of authenticity and integrity when receiving data from an external entity (e.g.
407
configuration settings or firmware updates) to verify that the data have been sent from an
408
authentic and authorised external entity and have not been changed during transmission. The
409
TOE utilises the services of its Security Module for aspects of this functionality.
410
These functionalities shall:
411
 prevent within the Smart Metering System that data may be sent by a non-authentic
412
component without the possibility that the data recipient can detect this,
413
 facilitate the integrity of billing processes and serve for the interests of the consumer as well
414
as for the interest of the supplier. Both parties are interested in the transmission of correct
415
processed Meter Data to be used for billing,
416
 protect the Smart Metering System and a corresponding large scale Smart Grid infrastructure
417
by preventing that data (e.g. Meter Data, configuration settings, or firmware updates) from
418
forged components (with the aim to cause damage to the Smart Grid) will be accepted in the
419
system.
420
20
Please note that the access to the Gateway via a device (e.g. a laptop) that is connected to the WAN may
incur a scenario for data leakage if that device is not adequately protected. The Technical Guideline [BSI-TR-
03109] therefore may pose additional requirements on the way the consumer can access this interface.
SMGW-PP
20 Federal Office for Information Security
1.4.6.4 Information flow control and firewall
421
The Gateway shall separate devices in the LAN of the consumer from the WAN and shall enforce the
422
following information flow control to control the communication between the networks that the
423
Gateway is attached to:
424
 only the Gateway may establish a connection to an external entity in the WAN21
; specifically
425
connection establishment by an external entity in the WAN or a Meter in the LMN to the
426
WAN is not possible,
427
 the Gateway can establish connections to devices in the LMN or in the HAN,
428
 Meters in the LMN are only allowed to establish a connection to the Gateway,
429
 the Gateway shall offer a wake-up service that allows external entities in the WAN to trigger a
430
connection establishment by the Gateway,
431
 connections are allowed to pre-configured addresses only,
432
 only cryptographically-protected (i.e. encrypted, integrity protected and mutually
433
authenticated) connections are possible.22
434
These functionalities shall:
435
 prevent that the Gateway itself or the components behind the Gateway (i.e. Meters or
436
Controllable Local Systems) can be conquered by a WAN attacker (as defined in section 3.4),
437
that processed data are transmitted to the wrong external entity, and that processed data are
438
transmitted without being confidentiality/authenticity/integrity-protected,
439
 protect the Smart Metering System and a corresponding large scale infrastructure in two ways:
440
by preventing that conquered components will send forged Meter Data (with the aim to cause
441
damage to the Smart Grid), and by preventing that widely distributed Smart Metering Systems
442
can be abused as a platform for malicious software to attack other systems in the WAN (e.g. a
443
WAN attacker who would be able to install a botnet on components of the Smart Metering
444
System).
445
The communication flows that are enforced by the Gateway between parties in the HAN, LMN and
446
WAN are summarized in the following table23
:
447
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 only24
No connection
establishment allowed
- (see following list)
Table 2: Communication flows between devices in different networks
448
21
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.
22
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.
23
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.
24
The channel to the external entity in the WAN is established by the Gateway.
SMGW-PP
Federal Office for Information Security 21
For communications within the different networks the following assumptions are defined:
449
1. Communications within the WAN are not restricted. However, the Gateway is not involved in
450
this communication,
451
2. No communications between devices in the LMN are assumed. Devices in the LMN may only
452
communicate to the Gateway and shall not be connected to any other network,
453
3. Devices in the HAN may communicate with each other. However, the Gateway is not
454
involved in this communication. If devices in the HAN have a separate connection to parties
455
in the WAN (beside the Gateway) this connection is assumed to be appropriately protected. It
456
should be noted that for the case that a TOE connects to more than one HAN communications
457
between devices within different HAN via the TOE are only allowed if explicitly configured
458
by a Gateway Administrator.
459
Finally, the Gateway itself shall offer the following services within the various networks:
460
1. The Gateway shall accept the submission of Meter Data from the LMN,
461
2. the Gateway shall offer a wake-up service at the WAN side as described in chapter 1.4.6.5,
462
3. the Gateway shall offer a user interface to the HAN that allows CLS or consumers25
to connect
463
to the Gateway in order to read relevant information.
464
It shall be noted that this concept deliberately accepts that devices in the LMN or HAN of the
465
consumer cannot directly be contacted from the WAN side. However, the Gateway may implement
466
additional functionality (as long as it does not contradict a SFP from this PP) that sets the Gateway as
467
a broker into the communication between an external authorised entity in the WAN and the CLS. As
468
long as a Gateway has a TLS connection to an external entity (please refer to chapter 1.4.6.5 for details
469
how to reach the Gateway from the WAN) it may be technically possible to negotiate a connection
470
between an external entity and a CLS upon the request of the external entity without violating the
471
information flow policies from this PP.
472
1.4.6.5 Wake-Up-Service
473
In order to protect the Gateway and the devices in the LAN against threats from the WAN side the
474
Gateway implements a strict firewall policy and enforces that connections with external entities in the
475
WAN shall only be established by the Gateway itself (e.g. when the Gateway delivers Meter Data or
476
contacts the Gateway Administrator to check for updates)26
.
477
While this policy is the optimal policy from a security perspective the Gateway Administrator may
478
want to facilitate applications in which an instant communication to the Gateway is required.
479
In order to allow this kind of re-activeness of the Gateway this PP allows the Gateway to keep existing
480
connections to external entities open (please refer to [BSI-TR-03109-3] for more details) and to offer a
481
so called wake-up service.
482
The Gateway shall be able to receive a wake-up message that is signed by the Gateway Administrator.
483
The following steps are taken:
484
1. The Gateway verifies the wake-up packet. This comprises
485
a) a check if the header identification is correct,
486
b) the recipient is the Gateway,
487
c) the wake-up packet has been sent/received within an acceptable period of time in order to
488
prevent replayed messages,
489
d) the wake-up message has not been received before,
490
2. If the wake-up message could not be verified as described in step #1 the message will be
491
dropped/ignored. No further operations will be initiated and no feedback is provided.
492
25
Please note that [BSI-TR-03109] may pose additional requirements on the interaction with the Gateway in
this context.
26
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.
SMGW-PP
22 Federal Office for Information Security
3. If the message could be verified as described in step #1 the signature of the wake-up message
493
will be verified. The Gateway shall use the services of its Security Module for signature
494
verification.
495
4. If the signature of the wake-up message cannot be verified as described in step #3 the message
496
will be dropped/ignored. No feedback is given to the sending external entity and the wake-up
497
sequence terminates.
498
5. If the signature of the wake-up message could be verified successfully, the Gateway initiates a
499
connection to a pre-configured external entity; however no feedback is given to the sending
500
external entity.
501
More details on the exact implementation of this mechanism can be found in [BSI-TR-03109-1,
502
“Wake-Up-Service”].
503
1.4.6.6 Privacy Preservation
504
The preservation of the privacy of the consumer is an essential aspect that is implemented by the
505
functionality of the TOE as required by this PP.
506
This contains two aspects:
507
The Processing Profiles that the TOE obeys facilitate an approach in which only a minimum amount
508
of data have to be submitted to external entities and therewith leave the scope of control of the
509
consumer. The mechanisms “encryption” and “pseudonymisation” ensure that the data can only be
510
read by the intended recipient and only contains an association with the identity of the Meter if this is
511
necessary.
512
On the other hand, the TOE shall provide the consumer with transparent information about the
513
information flows that happen with their data. In order to achieve this, the TOE shall implement a
514
consumer log that specifically contains the information about the information flows which have been
515
and will be authorised based on the previous and current Processing Profiles. The access to this
516
consumer log is only possible via a local interface from the HAN and after authentication of the
517
consumer. The TOE shall only allow a consumer access to the data in the consumer log that is related
518
to their own consumption or production. The following paragraphs provide more details on the
519
information that shall be included in this log:
520
Monitoring of Data Transfers
521
The TOE shall be able to keep track of each data transmission in the consumer log and allow the
522
consumer to see details on which information have been and will be sent (based on the previous and
523
current settings) to which external entity.
524
Configuration Reporting
525
The TOE shall provide detailed and complete reporting in the consumer log of each security and
526
privacy-relevant configuration setting. Additional to device specific configuration settings the
527
consumer log shall contain the parameters of each Processing Profile. The consumer log shall contain
528
the configured addresses for internal and external entities including the CLS.
529
Audit Log and Monitoring
530
The TOE shall provide all audit data from the consumer log at the user interface IF_GW_CON. Access
531
to the consumer log shall only be possible after successful authentication and only to information that
532
the consumer has permission to (i.e. that has been recorded based on events belonging to the
533
consumer).
534
1.4.6.7 Management of Security Functions
535
The Gateway provides authorised Gateway Administrators with functionality to manage the behaviour
536
of the security functions and to update the TOE. This Protection Profile defines a minimum set of
537
management functions that must be implemented by each Gateway seeking conformance to this PP.
538
Further, it is defined that only authorised Gateway Administrators may be able to use the management
539
functionality of the Gateway (while the Security Module is used for the authentication of the Gateway
540
Administrator) and that the management of the Gateway shall only be possible from the WAN side
541
interface.
542
SMGW-PP
Federal Office for Information Security 23
The TOE shall provide information on the current status of the TOE in the system log. Specifically it
543
shall indicate whether the TOE operates normally or any errors have been detected that are of
544
relevance for the administrator.
545
1.4.6.8 Identification and Authentication
546
To protect the TSF as well as User Data and TSF data from unauthorized modification the TOE
547
provides a mechanism that requires each user to be successfully identified and authenticated before
548
allowing any other actions on behalf of that user. This functionality includes the identification and
549
authentication of users who receive data from the Gateway as well as the identification and
550
authentication of CLS located in HAN and Meters located in LMN.
551
The Gateway provides different kinds of identification and authentication mechanisms that depend on
552
the user role and the used interfaces. Most of the mechanisms require the usage of certificates. Only
553
consumers are able to decide whether they use certificates or username and password for identification
554
and authentication.
555
1.4.7 The logical interfaces of the TOE
556
The TOE offers its functionality as outlined before via a set of external interfaces. Figure 2 also
557
indicates the cardinality of the interfaces. The following table provides an overview of the mandatory
558
external interfaces of the TOE and provides additional information:
559
Interface Name Description
IF_GW_CON Via this interface the Gateway provides the consumer27
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.
IF_GW_MTR Interface between the Meter and the Gateway. The Gateway receives Meter Data
via this interface.28
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.
Table 3: Mandatory TOE external interfaces
560
1.4.8 The cryptography of the TOE and its Security Module
561
Parts of the cryptographic functionality used in the upper mentioned functions shall be provided by a
562
Security Module. The Security Module provides strong cryptographic functionality, random number
563
generation, secure storage of secrets and supports the authentication of the Gateway Administrator.
564
The Security Module is a different IT product and not part of the TOE as described in this PP.
565
Nevertheless it is physically embedded into the Gateway and protected by the same level of physical
566
protection. The requirements applicable to the Security Module are specified in a separate PP (see
567
[SecMod-PP]).
568
27
Please note that this interface allows consumer (or consumer’s CLS) to connect to the Gateway in order to
read consumer specific information.
28
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.
SMGW-PP
24 Federal Office for Information Security
The following table provides a more detailed overview on how the cryptographic functions are
569
distributed between the TOE and its Security Module.
570
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
Table 4: Cryptographic support of the TOE and its Security Module
571
The distribution of cryptographic functionality among the TOE and its Security Module has not only
572
been decided from a security perspective but also considered aspects of performance. A significant
573
part of the complex functionality is implemented by the Gateway. A state of the art Security Module
574
in form of a smart card should be able to perform approx. 10 connection establishments per minute. As
575
the calculated session keys are valid for a longer period this should be sufficient for most of the
576
applications. In cases where this speed is not sufficient the developer should consider alternative
577
approaches, e.g. the use of multiple Security Modules.
578
SMGW-PP
Federal Office for Information Security 25
1.4.8.1 Content data encryption vs. an encrypted channel
579
The TOE utilises concepts of the encryption of data on the content level as well as the establishment of
580
a trusted channel to external entities.
581
As a general rule all processed Meter Data that is prepared to be submitted to external entities is
582
encrypted and integrity protected on a content level using CMS (according to [BSI-TR-03109-1-I]).
583
Further, all communication with external entities is enforced to happen via encrypted, integrity
584
protected and mutually authenticated channels.
585
This concept of encryption on two layers facilitates use cases in which the external entity that the TOE
586
communicates with is not the final recipient of the Meter Data. In this way it is for example possible
587
that the Gateway Administrator receives Meter Data that they forward to other parties. In such a case
588
the Gateway Administrator is the endpoint of the trusted channel but cannot read the Meter Data.
589
Administration data that is transmitted between the Gateway administrator and the TOE is also
590
encrypted and integrity protected using CMS.
591
The following figure introduces the communication process between the Meter, the TOE and external
592
entities (focussing on billing-relevant Meter Data).
593
The basic information flow for Meter Data is as follows and shown in Figure 6:
594
1. The Meter measures the consumption or production of a certain commodity.
595
2. The Meter Data is prepared for transmission:
596
a) The Meter Data is typically signed (typically using the services of an integrated
597
Security Module).
598
b) If the communication between the Meter and the Gateway is performed bidirectional,
599
the Meter Data is transmitted via an encrypted and mutually authenticated channel to
600
the Gateway. Please note that the submission of this information may be triggered by
601
the Meter or the Gateway.
602
Or
603
c) If a unidirectional communication is performed between the Meter and the Gateway
604
the Meter Data is encrypted using a symmetric algorithm (according to [BSI-TR-
605
03109-3]) and facilitating a defined data structure to ensure the authenticity and
606
confidentiality.
607
3. The authenticity and integrity of the Meter Data is verified by the Gateway
608
4. If (and only if) authenticity and integrity have been verified successfully the Meter Data is
609
further processed by the Gateway according to the rules in the Processing Profile else the
610
cryptographic information flow will be cancelled.
611
5. The processed Meter Data is encrypted and integrity protected using CMS (according to [BSI-
612
TR-03109-1-I]) for the final recipient of the data29
.
613
6. The processed Meter Data is signed using the services of the Security Module.
614
7. The processed and signed Meter Data may be stored for a certain amount of time.
615
8. The processed Meter Data is finally submitted to an authorised external entity in the WAN via
616
an encrypted and mutually authenticated channel.
617
29
Optionally the Meter Data can additionally be signed before any encryption is done.
SMGW-PP
26 Federal Office for Information Security
618
Figure 6: Cryptographic workflow for Meter, Gateway and the Security Module
619
SMGW-PP
Federal Office for Information Security 27
1.4.9 TOE life-cycle
620
The life-cycle of the Gateway can be separated into the following phases:
621
1. Development
622
2. Production
623
3. Pre-personalization at the developer's premises (without Security Module)
624
4. Pre-personalization and integration of Security Module
625
5. Installation and start of operation
626
6. Personalization
627
7. Normal operation
628
A detailed description of the different phases is provided in [BSI-TR-03109-1-VI].
629
For the Protection Profile it is important to know that the certified configuration of the TOE will be
630
established after phase “Personalization”. It has to be ensured that previous phases are performed by
631
trusted personal in secure environments. Since the realization of the phases depend on the concrete
632
TOE it is important that the TOE developer considers and enforces appropriate security measures
633
during the life-cycle phases. The TOE life-cycle will be examined during evaluation of assurance
634
aspect ALC.
635
SMGW-PP
28 Federal Office for Information Security
2 Conformance Claims
636
2.1 Conformance statement
637
This PP requires strict conformance of any PP/ST to this PP.
638
2.2 CC Conformance Claims
639
This PP has been developed using Version 3.1 Revision 4 of Common Criteria [CC].
640
This PP is [CC] part 2 extended due to the use of FPR_CON.1.
641
This PP claims conformance to [CC] part 3; no extended assurance components have been defined.
642
2.3 PP Claim
643
This PP does not claim conformance to any other PP.
644
2.4 Conformance claim rationale
645
Since this PP does not claim conformance to any Protection Profile, this section is not applicable.
646
2.5 Package Claim
647
This PP claims an assurance package EAL4 augmented by AVA_VAN.5 and ALC_FLR.2 as defined in
648
[CC] Part 3 for product certification.
649
SMGW-PP
Federal Office for Information Security 29
3 Security Problem Definition
650
3.1 External entities
651
The following external entities interact with the system consisting of Meter and Gateway. Those roles
652
have been defined for the use in this Protection Profile. It is possible that a party implements more
653
than one role in practice.
654
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 PP the term user or external
entity serve as a hypernym for all entities mentioned before.
Table 5: Roles used in the Protection profile
655
3.2 Assets
656
The following tables introduce the relevant assets for this Protection Profile. The tables focus on the
657
assets that are relevant for the Gateway and do not claim to provide an overview over all assets in the
658
Smart Metering System or for other devices in the LMN.
659
The following Table 6 lists all assets typified as “user data”:
660
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)
SMGW-PP
30 Federal Office for Information Security
Asset Description Need for Protection
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-relevant30
.
 Integrity and authenticity
(comparable to the classical
meter and its security
requirements)
 Confidentiality (due to privacy
concerns)
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 a 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
Table 6: Assets (User data)
661
30
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).
SMGW-PP
Federal Office for Information Security 31
Table 7 lists all assets typified as “TSF data”:
662
Asset Description Need for Protection
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
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
Table 7: Assets (TSF data)
663
3.3 Assumptions
664
In this threat model the following assumptions about the environment of the components need to be
665
taken into account in order to ensure a secure operation.
666
A.ExternalPrivacy It is assumed that authorised and authenticated external entities
receiving any kind of privacy-relevant data or billing-relevant data and
the applications that they operate are trustworthy (in the context of the
data that they receive) and do not perform unauthorised analyses of this
data with respect to the corresponding consumer(s).
A.TrustedAdmins It is assumed that the Gateway Administrator and the Service
Technician are trustworthy and well-trained.
A.PhysicalProtection It is assumed that the TOE is installed in a non-public environment
within the premises of the consumer which provides a basic level of
physical protection. This protection covers the TOE, the Meter(s) that
the TOE communicates with and the communication channel between
the TOE and its Security Module.
A.ProcessProfile The Processing Profiles that are used when handling data are assumed
to be trustworthy and correct.
SMGW-PP
32 Federal Office for Information Security
A.Update It is assumed that firmware updates for the Gateway that can be
provided by an authorised external entity have undergone a certification
process according to this Protection Profile before they are issued and
can therefore be assumed to be correctly implemented. It is further
assumed that the external entity that is authorised to provide the update
is trustworthy and will not introduce any malware into a firmware
update.
A.Network It is assumed that
 a WAN network connection with a sufficient reliability and
bandwidth for the individual situation is available,
 one or more trustworthy sources for an update of the system
time are available in the WAN,
 the Gateway is the only communication gateway for Meters in
the LMN31
,
 if devices in the HAN have a separate connection to parties in
the WAN (beside the Gateway) this connection is appropriately
protected.
A.Keygen It is assumed that the ECC key pair for a Meter (TLS) is generated
securely according to the [BSI-TR-03109-3] and brought into the
Gateway in a secure way by the Gateway Administrator.
Application Note 1: This PP acknowledges that the Gateway cannot be completely protected
against unauthorised physical access by its environment. However, it is
important for the overall security of the TOE that it is not installed
within a public environment.
The level of physical protection that is expected to be provided by the
environment is the same level of protection that is expected for classical
meters that operate according to the regulations of the national
calibration authority [TR-03109-1].
Application Note 2: The Processing Profiles that are used for information flow control as
referred to by A.ProcessProfile are an essential factor for the
preservation of the privacy of the consumer. The Processing Profiles are
used to determine which data shall be sent to which entity at which
frequency and how data are processed, e.g. whether the data needs to be
related to the consumer (because it is used for billing purposes) or
whether the data shall be pseudonymised.
The Processing Profiles shall be visible for the consumer to allow a
transparent communication.
It is essential that Processing Profiles correctly define the amount of
information that must be sent to an external entity. Exact regulations
regarding the Processing Profiles and the Gateway Administrator are
beyond the scope of this Protection Profile.
31
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.
SMGW-PP
Federal Office for Information Security 33
Application Note 3: When the ECC key pair generation is done by the SMGW, the ST
author has to model this with an appropriate SFR.
3.4 Threats
667
The following sections identify the threats that are posed against the assets handled by the Smart
668
Meter Gateway. Those threats are the result of a threat model that has been developed for the whole
669
Smart Metering System first and then has been focussed on the threats against the Gateway.
670
It should be noted that the threats in the following paragraphs consider two different kinds of
671
attackers:
672
 Attackers having physical access to Meter, Gateway, a connection between these components,
673
or local logical access to any of the interfaces (local attacker), trying to disclose or alter assets
674
while stored in the Gateway or while transmitted between meters in the LMN and the
675
Gateway. Please note that the following threat model assumes that the local attacker has less
676
motivation than the WAN attacker as a successful attack of a local attacker will always only
677
impact one Gateway. Please further note that the local attacker includes the authorised
678
individuals like consumers.
679
 An attacker located in the WAN (WAN attacker) trying to compromise the confidentiality
680
and/or integrity of the processed Meter Data and or configuration data transmitted via the
681
WAN, or attacker trying to conquer a component of the infrastructure (i.e. Meter, Gateway or
682
Controllable Local System) via the WAN to cause damage to a component itself or to the
683
corresponding grid (e.g. by sending forged Meter Data to an external entity).
684
The specific rationale for this situation is given by the expected benefit of a successful attack. An
685
attacker who has to have physical access to the TOE that they are attacking, will only be able to
686
compromise one TOE at a time. So the effect of a successful attack will always be limited to the
687
attacked TOE. A logical attack from the WAN side on the other hand may have the potential to
688
compromise a large amount of TOEs.
689
T.DataModificationLocal A local attacker may try to modify (i.e. alter, delete, insert, replay or
redirect) Meter Data when transmitted between Meter and Gateway,
Gateway and consumer, or Gateway and external entities. The objective
of the attacker may be to alter billing-relevant information or grid status
information. The attacker may perform the attack via any interface (e.g.
LMN, HAN, or WAN).
In order to achieve the modification, the attacker may also try to modify
secondary assets like the firmware or configuration parameters of the
Gateway.
T.DataModificationWAN A WAN attacker may try to modify (i.e. alter, delete, insert, replay or
redirect) Meter Data, Gateway config data, Meter config data, CLS
config data or a firmware update when transmitted between the
Gateway and an external entity in the WAN.
When trying to modify Meter Data it is the objective of the WAN
attacker to modify billing-relevant information or grid status data.
When trying to modify config data or a firmware update the WAN
attacker tries to circumvent security mechanisms of the TOE or tries to
get control over the TOE or a device in the LAN that is protected by the
TOE.
T.TimeModification A local attacker or WAN attacker may try to alter the Gateway time. The
motivation of the attacker could be e.g. to change the relation between
date/time and measured consumption or production values in the Meter
Data records (e.g. to influence the balance of the next invoice).
SMGW-PP
34 Federal Office for Information Security
T.DisclosureWAN A WAN attacker may try to violate the privacy of the consumer by
disclosing Meter Data or configuration data (Meter config, Gateway
config or CLS config) or parts of it when transmitted between Gateway
and external entities in the WAN.
T.DisclosureLocal A Local Attacker may try to violate the privacy of the consumer by
disclosing Meter Data transmitted between the TOE and the Meter. This
threat is of specific importance if Meters of more than one consumer are
served by one Gateway.
T.Infrastructure A WAN attacker may try to obtain control over Gateways, Meters or
CLS via the TOE, which enables the WAN Attacker to cause damage to
consumers or external entities or the grids used for commodity
distribution (e.g. by sending wrong data to an external entity).
A WAN attacker may also try to conquer a CLS in the HAN first in
order to logically attack the TOE from the HAN side.
T.ResidualData By physical and/or logical means a local attacker or a WAN attacker
may try to read out data from the Gateway, which travelled through the
Gateway before and which are no longer needed by the Gateway (i.e.
Meter Data, Meter config, or CLS config).
T.ResidentData A WAN or local attacker may try to access (i.e. read, alter, delete)
information to which they don't have permission to while the
information is stored in the TOE.
While the WAN attacker only uses the logical interface of the TOE that
is provided into the WAN the local attacker may also physically access
the TOE.
T.Privacy A WAN attacker may try to obtain more detailed information from the
Gateway than actually required to fulfil the tasks defined by its role or
the contract with the consumer. This includes scenarios in which an
external entity that is primarily authorised to obtain information from
the TOE tries to obtain more information than the information that has
been authorised as well as scenarios in which an attacker who is not
authorised at all tries to obtain information.
SMGW-PP
Federal Office for Information Security 35
3.5 Organizational Security Policies (OSPs)
690
This section lists the organizational security policies (OSP) that the Gateway shall comply with:
691
OSP.SM The TOE shall use the services of a certified Security Module for
 verification of digital signatures,
 generation of digital signatures,
 key agreement,
 key transport,
 key storage,
 Random Number Generation.
The Security Module shall be certified according to [SecMod-PP] and
shall be used in accordance with its relevant guidance documentation.
OSP.Log The TOE shall maintain a set of log files as defined in [BSI-TR-03109-
1] as follows:
1. A system log of relevant events in order to allow an authorised
Gateway Administrator to analyse the status of the TOE. The
TOE shall also analyse the system log automatically for a
cumulation of security relevant events.
2. A consumer log that contains information about the information
flows that have been initiated to the WAN and information
about the Processing Profiles causing this information flow as
well as the billing-relevant information.
3. A calibration log (as defined in chapter 6.2.1) that provides the
Gateway Administrator with a possibility to review calibration
relevant events.
The TOE shall further limit access to the information in the different log
files as follows:
1. Access to the information in the system log shall only be
allowed for an authorised Gateway Administrator via
IF_GW_WAN of the TOE and an authorised Service Technician
via IF_GW_SRV.
2. Access to the information in the calibration log shall only be
allowed for an authorised Gateway Administrator via the
IF_GW_WAN interface of the TOE.
3. Access to the information in the consumer log shall only be
allowed for an authorised consumer via the IF_GW_CON
interface of the TOE. The consumer shall only have access to
their own information.
The system log may overwrite the oldest events in case that the audit
trail gets full.
For the consumer log the TOE shall ensure that a sufficient amount of
events is available (in order to allow a consumer to verify an invoice)
but may overwrite older events in case that the audit trail gets full.
For the calibration log, however, the TOE shall ensure the availability
of all events over the lifetime of the TOE.
Application Note 4: When the RNG functionality is provided by the Gateway itself, it has to
be appropriately modelled by the ST author using SFR FCS_RNG
according to [AIS20] or [AIS31] and considering [BSI-TR-03109-3].
SMGW-PP
36 Federal Office for Information Security
4 Security Objectives
692
4.1 Security Objectives for the TOE
693
O.Firewall The TOE shall serve as the connection point for the connected devices
within the LAN to external entities within the WAN and shall provide
firewall functionality in order to protect the devices of the LMN and HAN
(as long as they use the Gateway) and itself against threats from the WAN
side.
The firewall:
 shall allow only connections established from HAN or the TOE
itself to the WAN (i.e. from devices in the HAN to external entities
in the WAN or from the TOE itself to external entities in the WAN),
 shall provide a wake-up service on the WAN side interface,
 shall not allow connections from the LMN to the WAN,
 shall not allow any other services being offered on the WAN side
interface,
 shall not allow connections from the WAN to the LAN or to the
TOE itself,
 shall enforce communication flows by allowing traffic from CLS in
the HAN to the WAN only if confidentiality-protected and
integrity-protected and if endpoints are authenticated.
O.SeparateIF The TOE shall have physically separated ports for the LMN, the HAN and
the WAN and shall automatically detect during its self-test whether
connections (wired or wireless), if any, are wrongly connected.
Application Note 5: O.SeparateIF refers to physical interfaces and must not be fulfilled by a
pure logical separation of one physical interface only.
O.Conceal To protect the privacy of its consumers, the TOE shall conceal the
communication with external entities in the WAN in order to ensure that no
privacy-relevant information may be obtained by analysing the frequency,
load, size or the absence of external communication.32
O.Meter The TOE receives or polls information about the consumption or production
of different commodities from one or multiple Meters and is responsible for
handling this Meter Data.
This includes that:
 the TOE shall ensure that the communication to the Meter(s) is
established in an Gateway Administrator-definable interval or an
interval as defined by the Meter,
 the TOE shall enforce encryption and integrity protection for the
communication with the Meter33
,
 the TOE shall verify the integrity and authenticity of the data
received from a Meter before handling it further,
32
It should be noted that this requirement only applies to communication flows in the WAN.
33
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 Protection Profile only has a limited possibility to
secure this communication as both sides have to sign responsible for the quality of a cryptographic
connection.
SMGW-PP
Federal Office for Information Security 37
 the TOE shall process the data according to the definition in the
corresponding Processing Profile,
 the TOE shall encrypt the processed Meter Data for the final
recipient, sign the data and
 deliver the encrypted data to authorised external entities as defined
in the corresponding Processing Profiles facilitating an encrypted
channel,
 the TOE shall store processed Meter Data if an external entity
cannot be reached and re-try to send the data until a configurable
number of unsuccessful retries has been reached,
 the TOE shall pseudonymise the data for parties that do not need
the relation between the processed Meter Data and the identity of
the consumer.
O.Crypt The TOE shall provide cryptographic functionality as follows:
 authentication, integrity protection and encryption of the
communication and data to external entities in the WAN,
 authentication, integrity protection and encryption of the
communication to the Meter,
 authentication, integrity protection and encryption of the
communication to the consumer,
 replay detection for all communications with external entities,
 encryption of the persistently stored TSF and user data of the
TOE34
.
In addition the TOE shall generate the required keys utilising the services of
its Security Module35
, ensure that the keys are only used for an acceptable
amount of time and destroy ephemeral36
keys if not longer needed.
O.Time The TOE shall provide reliable time stamps and update its internal clock in
regular intervals by retrieving reliable time information from a dedicated
reliable source in the WAN.
34
The encryption of the persistent memory shall support the protection of the TOE against local attacks.
35
Please refer to chapter 1.4.8 for an overview on how the cryptographic functions are distributed between the
TOE and its Security Module.
36
This objective addresses the destruction of ephemeral keys only because all keys that need to be stored
persistently are stored in the Security Module.
SMGW-PP
38 Federal Office for Information Security
O.Protect The TOE shall implement functionality to protect its security functions
against malfunctions and tampering.
Specifically, the TOE shall
 encrypt its TSF and user data as long as it is not in use,
 overwrite any information that is no longer needed to ensure that it
is no longer available via the external interfaces of the TOE36
,
 monitor user data and the TOE firmware for integrity errors,
 contain a test that detects whether the interfaces for WAN and LAN
are separate,
 have a fail-safe design that specifically ensures that no malfunction
can impact the delivery of a commodity (e.g. energy, gas, heat or
water)37
,
 make any physical manipulation within the scope of the intended
environment detectable for the consumer and Gateway
Administrator.
O.Management The TOE shall only provide authorised Gateway Administrators with
functions for the management of the security features.
The TOE shall ensure that any change in the behaviour of the security
functions can only be achieved from the WAN side interface. Any
management activity from a local interface may only be read only.
Further, the TOE shall implement a secure mechanism to update the
firmware of the TOE that ensures that only authorised entities are able to
provide updates for the TOE and that only authentic and integrity protected
updates are applied.
O.Log The TOE shall maintain a set of log files as defined in [BSI-TR-03109-1] as
follows:
1. A system log of relevant events in order to allow an authorised
Gateway Administrator or an authorised Service Technician to
analyse the status of the TOE. The TOE shall also analyse the
system log automatically for a cumulation of security relevant
events.
2. A consumer log that contains information about the information
flows that have been initiated to the WAN and information about
the Processing Profiles causing this information flow as well as the
billing-relevant information and information about the system status
(including relevant error messages).
3. A calibration log that provides the Gateway Administrator with a
possibility to review calibration relevant events.
The TOE shall further limit access to the information in the different log
files as follows:
1. Access to the information in the system log shall only be allowed
for an authorised Gateway Administrator via IF_GW_WAN or for
an authorised Service Technician via IF_GW_SRV.
2. Access to the information in the consumer log shall only be allowed
37
Indeed this Protection Profile 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 Protection Profile. 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.
SMGW-PP
Federal Office for Information Security 39
for an authorised consumer via the IF_GW_CON interface of the
TOE and via a secured (i.e. confidentiality and integrity protected)
connection. The consumer shall only have access to their own
information.
3. Read-only access to the information in the calibration log shall only
be allowed for an authorised Gateway Administrator via the WAN
interface of the TOE.
The system log may overwrite the oldest events in case that the audit trail
gets full.
For the consumer log the TOE shall ensure that a sufficient amount of
events is available (in order to allow a consumer to verify an invoice) but
may overwrite older events in case that the audit trail gets full.
For the calibration log however, the TOE shall ensure the availability of all
events over the lifetime of the TOE.
O.Access The TOE shall control the access of external entities in WAN, HAN or
LMN to any information that is sent to, from or via the TOE via its external
interfaces38
. Access control shall depend on the destination interface that is
used to send that information.
4.2 Security objectives for the operational environment
694
OE.ExternalPrivacy Authorised and authenticated external entities receiving any kind of
private or billing-relevant data shall be trustworthy and shall not perform
unauthorised analyses of these data with respect to the corresponding
consumer(s).
OE.TrustedAdmins The Gateway Administrator and the Service Technician shall be
trustworthy and well-trained.
OE.PhysicalProtection The TOE shall be installed in a non-public environment within the
premises of the consumer that provides a basic level of physical
protection. This protection shall cover the TOE, the Meters that the TOE
communicates with and the communication channel between the TOE and
its Security Module. Only authorised individuals may physically access
the TOE.
OE.Profile The Processing Profiles that are used when handling data shall be obtained
from a trustworthy and reliable source only.
OE.SM The environment shall provide the services of a certified Security Module
for
 verification of digital signatures,
 generation of digital signatures,
 key agreement,
 key transport,
 key storage,
 Random Number Generation.
The Security Module used shall be certified according to [SecMod-PP]
38
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.
SMGW-PP
40 Federal Office for Information Security
and shall be used in accordance with its relevant guidance documentation.
OE.Update The firmware updates for the Gateway that can be provided by an
authorised external entity shall undergo a certification process according to
this Protection Profile before they are issued to show that the update is
implemented correctly. The external entity that is authorised to provide the
update shall be trustworthy and ensure that no malware is introduced via a
firmware update.
OE.Network It shall be ensured that
 a WAN network connection with a sufficient reliability and
bandwidth for the individual situation is available,
 one or more trustworthy sources for an update of the system time
are available in the WAN,
 the Gateway is the only communication gateway for Meters in the
LMN,
 if devices in the HAN have a separate connection to parties in the
WAN (beside the Gateway) this connection is appropriately
protected.
OE.Keygen It shall be ensured that the ECC key pair for a Meter (TLS) is generated
securely according to the [BSI-TR-03109-3]. It shall also be ensured that
the keys are brought into the Gateway in a secure way by the Gateway
Administrator.
SMGW-PP
Federal Office for Information Security 41
4.3 Security Objectives rationale
695
4.3.1 Overview
696
The following table gives an overview how the assumptions, threats, and organisational security
697
policies are addressed by the security objectives. The text of the following sections justifies this more
698
in detail.
699
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
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
Table 8: Rationale for Security Objectives
700
4.3.2 Countering the threats
701
The following sections provide more detailed information on how the threats are countered by the
702
security objectives for the TOE and its operational environment.
703
SMGW-PP
42 Federal Office for Information Security
4.3.2.1 General objectives
704
The security objectives O.Protect, O.Management and OE.TrustedAdmins contribute to counter each
705
threat and contribute to each OSP.
706
O.Management is indispensable as it defines the requirements around the management of the Security
707
Functions. Without a secure management no TOE can be secure. Also OE.TrustedAdmins contributes
708
to this aspect as it provides the requirements on the availability of a trustworthy Gateway
709
Administrator and Service Technician. O.Protect is present to ensure that all security functions are
710
working as specified.
711
Those general objectives will not be addressed in detail in the following paragraphs.
712
4.3.2.2 T.DataModificationLocal
713
The threat T.DataModificationLocal is countered by a combination of the security objectives
714
O.Meter, O.Crypt and OE.PhysicalProtection.
715
O.Meter defines that the TOE will enforce the encryption of communication when receiving Meter
716
Data from the Meter. O.Crypt defines the required cryptographic functionality. The objectives
717
together ensure that the communication between the Meter and the TOE cannot be modified or
718
released.
719
OE.PhysicalProtection is of relevance as it ensures that access to the TOE is limited.
720
4.3.2.3 T.DataModificationWAN
721
The threat T.DataModificationWAN is countered by a combination of the security objectives
722
O.Firewall and O.Crypt.
723
O.Firewall defines the connections for the devices within the LAN to external entities within the
724
WAN and shall provide firewall functionality in order to protect the devices of the LMN and HAN (as
725
long as they use the Gateway) and itself against threats from the WAN side. O.Crypt defines the
726
required cryptographic functionality. Both objectives together ensure that the data transmitted between
727
the TOE and the WAN cannot be modified by a WAN attacker.
728
4.3.2.4 T.TimeModification
729
The threat T.TimeModification is countered by a combination of the security objectives O.Time,
730
O.Crypt and OE.PhysicalProtection.
731
O.Time defines that the TOE needs a reliable time stamp mechanism that is also updated from reliable
732
sources regularly in the WAN. O.Crypt defines the required cryptographic functionality for the
733
communication to external entities in the WAN. Therewith, O.Time and O.Crypt are the core
734
objective to counter the threat T.TimeModification.
735
OE.PhysicalProtection is of relevance as it ensures that access to the TOE is limited.
736
4.3.2.5 T.DisclosureWAN
737
The threat T.DisclosureWAN is countered by a combination of the security objectives O.Firewall.
738
O.Conceal and O.Crypt.
739
O.Firewall defines the connections for the devices within the LAN to external entities within the
740
WAN and shall provide firewall functionality in order to protect the devices of the LMN and HAN (as
741
long as they use the Gateway) and itself against threats from the WAN side. O.Crypt defines the
742
required cryptographic functionality. Both objectives together ensure that the communication between
743
the Meter and the TOE cannot be disclosed.
744
O.Conceal ensures that no information can be disclosed based on additional characteristics of the
745
communication like frequency, load or the absence of a communication.
746
4.3.2.6 T.DisclosureLocal
747
The threat T.DisclosureLocal is countered by a combination of the security objectives O.Meter,
748
O.Crypt and OE.PhysicalProtection.
749
O.Meter defines that the TOE will enforce the encryption and integrity protection of communication
750
when polling or receiving Meter Data from the Meter. O.Crypt defines the required cryptographic
751
SMGW-PP
Federal Office for Information Security 43
functionality. Both objectives together ensure that the communication between the Meter and the TOE
752
cannot be disclosed.
753
OE.PhysicalProtection is of relevance as it ensures that access to the TOE is limited.
754
4.3.2.7 T.Infrastructure
755
The threat T.Infrastructure is countered by a combination of the security objectives O.Firewall,
756
O.SeparateIF, O.Meter and O.Crypt.
757
O.Firewall is the core objective that counters this threat. It ensures that all communication flows to
758
the WAN are initiated by the TOE. The fact that the TOE does not offer any services to the WAN side
759
and will not react to any requests (except the wake-up call) from the WAN is a significant aspect in
760
countering this threat. Further the TOE will only communicate using encrypted channels to
761
authenticated and trustworthy parties which mitigates the possibility that an attacker could try to hijack
762
a communication.
763
O.Meter defines that the TOE will enforce the encryption and integrity protection for the
764
communication with the Meter.
765
O.SeparateIF facilitates the disjunction of the WAN from the LMN.
766
O.Crypt supports the mitigation of this threat by providing the required cryptographic primitives.
767
4.3.2.8 T.ResidualData
768
The threat T.ResidualData is mitigated by the security objective O.Protect as this security objective
769
defines that the TOE shall delete information as soon as it is no longer used. Assuming that a TOE
770
follows this requirement an attacker cannot read out any residual information as it does simply not
771
exist.
772
4.3.2.9 T.ResidentData
773
The threat T.ResidentData is countered by a combination of the security objectives O.Access,
774
O.Firewall, O.Protect and O.Crypt. Further, the environment (OE.PhysicalProtection and
775
OE.TrustedAdmins) contributes to this.
776
O.Access defines that the TOE shall control the access of users to information via the external
777
interfaces.
778
The aspect of a local attacker with physical access to the TOE is covered by a combination of
779
O.Protect (defining the detection of physical manipulation) and O.Crypt (requiring the encryption of
780
persistently stored TSF and user data of the TOE). In addition the physical protection provided by the
781
environment (OE.PhysicalProtection) and the Gateway Administrator (OE.TrustedAdmins) who
782
could realise a physical manipulation contribute to counter this threat.
783
The aspect of a WAN attacker is covered by O.Firewall as this objective ensures that an adequate
784
level of protection is realised against attacks from the WAN side.
785
4.3.2.10 T.Privacy
786
The threat T.Privacy is primarily addressed by the security objectives O.Meter, O.Crypt and
787
O.Firewall as these objective ensures that the TOE will only distribute Meter Data to external entities
788
in the WAN as defined in the corresponding Processing Profiles and that the data will be protected for
789
the transfer. OE.Profile is present to ensure that the Processing Profiles are obtained from a
790
trustworthy and reliable source only.
791
Finally, O.Conceal ensures that an attacker cannot obtain the relevant information for this threat by
792
observing external characteristics of the information flow.
793
4.3.3 Coverage of organisational security policies
794
The following sections provide more detailed information about how the security objectives for the
795
environment and the TOE cover the organizational security policies.
796
4.3.3.1 OSP.SM
797
The Organizational Security Policy OSP.SM that mandates that the TOE utilises the services of a
798
certified Security Module is directly addressed by the security objectives OE.SM and O.Crypt. The
799
SMGW-PP
44 Federal Office for Information Security
objective OE.SM addresses the functions that the Security Module shall be utilised for as defined in
800
OSP.SM and also requires a certified Security Module. O.Crypt defines the cryptographic
801
functionalities for the TOE itself. In this context it has to be ensured that the Security Module is
802
operated in accordance with its guidance documentation.
803
4.3.3.2 OSP.Log
804
The Organizational Security Policy OSP.Log that mandates that the TOE maintains an audit log is
805
directly addressed by the security objective for the TOE O.Log.
806
O.Access contributes to the implementation of the OSP as it defines that also Gateway Administrators
807
are not allowed to read/modify all data. This is of specific importance to ensure the confidentiality and
808
integrity of the log data as is required by the OSP.Log.
809
4.3.4 Coverage of assumptions
810
The following sections provide more detailed information about how the security objectives for the
811
environment cover the assumptions.
812
4.3.4.1 A.ExternalPrivacy
813
The assumption A.ExternalPrivacy is directly and completely covered by the security objective
814
OE.ExternalPrivacy. The assumption and the objective for the environment are drafted in a way that
815
the correspondence is obvious.
816
4.3.4.2 A.TrustedAdmins
817
The assumption A.TrustedAdmins is directly and completely covered by the security objective
818
OE.TrustedAdmins. The assumption and the objective for the environment are drafted in a way that
819
the correspondence is obvious.
820
4.3.4.3 A.PhysicalProtection
821
The assumption A.PhysicalProtection is directly and completely covered by the security objective
822
OE.PhysicalProtection. The assumption and the objective for the environment are drafted in a way
823
that the correspondence is obvious.
824
4.3.4.4 A.ProcessProfile
825
The assumption A.ProcessProfile is directly and completely covered by the security objective
826
OE.Profile. The assumption and the objective for the environment are drafted in a way that the
827
correspondence is obvious.
828
4.3.4.5 A.Update
829
The assumption A.Update is directly and completely covered by the security objective OE.Update.
830
The assumption and the objective for the environment are drafted in a way that the correspondence is
831
obvious.
832
4.3.4.6 A.Network
833
The assumption A.Network is directly and completely covered by the security objective
834
OE.Network. The assumption and the objective for the environment are drafted in a way that the
835
correspondence is obvious.
836
4.3.4.7 A.Keygen
837
The assumption A.Keygen is directly and completely covered by the security objective OE.Keygen.
838
The assumption and the objective for the environment are drafted in a way that the correspondence is
839
obvious.
840
SMGW-PP
Federal Office for Information Security 45
5 Extended Component definition
841
5.1 Communication concealing (FPR_CON)
842
The additional family Communication concealing (FPR_CON) of the Class FPR (Privacy) is defined
843
here to describe the specific IT security functional requirements of the TOE. The TOE shall prevent
844
attacks against Personally Identifiable Information (PII) of the consumer that may be obtained by an
845
attacker by observing the encrypted communication of the TOE with remote entities.
846
5.2 Family behaviour
847
This family defines requirements to mitigate attacks against communication channels in which an
848
attacker tries to obtain privacy relevant information based on characteristics of an encrypted
849
communication channel. Examples include but are not limited to an analysis of the frequency of
850
communication or the transmitted workload.
851
5.3 Component levelling
852
FPR_CON: Communication concealing 1
5.4 Management
853
The following actions could be considered for the management functions in FMT:
854
a) Definition of the interval in FPR_CON.1.2 if definable within the operational phase of the
855
TOE.
856
5.5 Audit
857
There are no auditable events foreseen.
858
5.6 Communication concealing (FPR_CON.1)
859
Hierarchical to: No other components.
Dependencies: No dependencies.
FPR_CON.1.1 The TSF shall enforce the [assignment: information flow policy] in
order to ensure that no personally identifiable information (PII) can be
obtained by an analysis of [assignment: characteristics of the
information flow that need to be concealed].
FPR_CON.1.2 The TSF shall connect to [assignment: list of external entities] in
intervals as follows [selection: weekly, daily, hourly, [assignment: other
interval]] to conceal the data flow.
SMGW-PP
46 Federal Office for Information Security
6 Security Requirements
860
6.1 Overview
861
This chapter describes the security functional and the assurance requirements which have to be
862
fulfilled by the TOE. Those requirements comprise functional components from part 2 of [CC] and the
863
assurance components as defined for the Evaluation Assurance Level 4 from part 3 of [CC].
864
The following notations are used:
865
 Refinement operation (denoted by bold text): is used to add details to a requirement, and thus
866
further restricts a requirement. In case that a word has been deleted from the original text this
867
refinement is indicated by crossed out bold text
868
 Selection operation (denoted by underlined text): is used to select one or more options
869
provided by the [CC] in stating a requirement.
870
 Assignment operation (denoted by italicised text): is used to assign a specific value to an
871
unspecified parameter, such as the length of a password.
872
 Iteration operation: are identified with a suffix in the name of the SFR (e.g. FDP_IFC.2/FW).
873
It should be noted that the requirements in the following chapters are not necessarily be ordered
874
alphabetically. Where useful the requirements have been grouped.
875
The following table summarises all TOE security functional requirements of this PP:
876
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
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
SMGW-PP
Federal Office for Information Security 47
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
FMT_MSA.3/FW Static attribute initialisation for Firewall policy
SMGW-PP
48 Federal Office for Information Security
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
877
6.2 Class FAU: Security Audit
878
6.2.1 Introduction
879
A TOE compliant to this Protection Profile shall implement three different audit logs as defined in
880
OSP.Log and O.Log. The following table provides an overview over the three audit logs before the
881
following chapters introduce the SFRs related to those audit logs.
882
System-Log Consumer-Log Calibration-Log
Purpose  Inform the Gateway
Administrator about
security relevant events
 Log all events as
defined by Common
Criteria for the used
SFR
 Log all system relevant
events on specific
functionaltity
 Automated alarms in
case of a cumulation of
certain events
 Inform the service
technician about the
status of the Gateway
 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
SMGW-PP
Federal Office for Information Security 49
System-Log Consumer-Log Calibration-Log
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.
Table 10: Overview over audit processes
883
SMGW-PP
50 Federal Office for Information Security
6.2.2 Security Requirements for the System Log
884
6.2.2.1 Security audit automatic response (FAU_ARP)
885
6.2.2.1.1 FAU_ARP.1/SYS: Security Alarms for system log
886
FAU_ARP.1.1/SYS The TSF shall take [inform an authorised Gateway Administrator and
[assignment: list of actions]] upon detection of a potential security
violation.
Hierarchical to: No other components
Dependencies: FAU_SAA.1 Potential violation analysis
6.2.2.2 Security audit data generation (FAU_GEN)
887
6.2.2.2.1 FAU_GEN.1/SYS: Audit data generation for system log
888
FAU_GEN.1.1/SYS The TSF shall be able to generate an audit record of the following auditable
events:
a) Start-up and shutdown of the audit functions;
b) All auditable events for the [basic] level of audit; and
c) [assignment: other non-privacy relevant auditable events].
FAU_GEN.1.2/SYS The TSF shall record within each audit record at least the following
information:
a) Date and time of the event, type of event, subject identity (if applicable),
and the outcome (success or failure) of the event; and
b) For each audit event type, based on the auditable event definitions of the
functional components included in the PP/ST, [assignment: other audit
relevant information].
Hierarchical to: No other components
Dependencies: FPT_STM.1
6.2.2.3 Security audit analysis (FAU_SAA)
889
6.2.2.3.1 FAU_SAA.1/SYS: Potential violation analysis for system log
890
FAU_SAA.1.1/SYS The TSF shall be able to apply a set of rules in monitoring the audited
events and based upon these rules indicate a potential violation of the
enforcement of the SFRs.
FAU_SAA.1.2/SYS The TSF shall enforce the following rules for monitoring audited events:
a) Accumulation or combination of [assignment: subset of defined
auditable events] known to indicate a potential security violation;
b) [assignment: any other rules].
Hierarchical to: No other components
Dependencies: FAU_GEN.1
SMGW-PP
Federal Office for Information Security 51
Application Note 6: The specific events that shall be analysed in the system audit log in order to
ensure a correct operation of the TOE highly depend on the specific
implementation and application of the TOE; as such the authors of the ST
will have to complete the operations in FAU_SAA.1/SYS.
At least all types of failures in the TSF as listed in FPT_FLS.1 should be
recognised as potential violation by the TOE.
6.2.2.4 Security audit review (FAU_SAR)
891
6.2.2.4.1 FAU_SAR.1/SYS: Audit Review for system log
892
FAU_SAR.1.1/SYS The TSF shall provide [only authorised Gateway Administrators via the
IF_GW_WAN interface and authorised Service Technicians via the
IF_GW_SRV interface] with the capability to read [all information] from
the system audit records.
FAU_SAR.1.2/SYS The TSF shall provide the audit records in a manner suitable for the user to
interpret the information.
Hierarchical to: No other components
Dependencies: FAU_GEN.1
6.2.2.5 Security audit event storage (FAU_STG)
893
6.2.2.5.1 FAU_STG.4/SYS: Prevention of audit data loss for the system log
894
FAU_STG.4.1/SYS The TSF shall [overwrite the oldest stored audit records] and [assignment:
other actions to be taken in case of audit storage failure] if the system
audit trail is full.
Hierarchical to: FAU_STG.3 Action in case of possible audit data loss
Dependencies: FAU_STG.1 Protected audit trail storage
Application Note 7: The size of the audit trail that is available before the oldest events get
overwritten is configurable for the Gateway Administrator.
6.2.3 Security Requirements for the Consumer Log
895
6.2.3.1 Security audit data generation (FAU_GEN)
896
6.2.3.1.1 FAU_GEN.1/CON: Audit data generation for consumer log
897
FAU_GEN.1.1/CON The TSF shall be able to generate an audit record of the following auditable
events:
a) Start-up and shutdown of the audit functions;
b) All auditable events for the [not specified] level of audit; and
c) [all audit events as listed in Table 11 and [assignment: additional events
or none]].
FAU_GEN.1.2/CON The TSF shall record within each audit record at least the following
information:
a) Date and time of the event, type of event, subject identity (if applicable),
and the outcome (success or failure) of the event; and
b) For each audit event type, based on the auditable event definitions of the
functional components included in the PP/ST, [additional information as
SMGW-PP
52 Federal Office for Information Security
listed in Table 11 and [assignment: additional events or none]].
Hierarchical to: No other components
Dependencies: FPT_STM.1
Application Note 8: The possibility for the ST author to specify additional events in
FAU_GEN.1.1/CON has been specifically introduced to allow that a more
detailed set of information about the consumption or production of a certain
commodity is audited (e.g. to allow a consumer to control the consumption
or production on a granular level). Such information shall primarily be
captured in the consumer log as this log has the appropriate permissions
associated to ensure that only the consumer can review the events.
Further, the ST author shall consider the descriptions in chapter 1.4.6.6 to
decide whether additional information needs to be audited for a specific
TOE.
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
-
Table 11: Events for consumer log
898
6.2.3.2 Security audit review (FAU_SAR)
899
6.2.3.2.1 FAU_SAR.1/CON Audit Review for consumer log
900
FAU_SAR.1.1/CON The TSF shall provide [only authorised consumer via the IF_GW_CON
interface] with the capability to read [all information that are related to
them] from the consumer audit records.
FAU_SAR.1.2/CON The TSF shall provide the audit records in a manner suitable for the user to
interpret the information.
Hierarchical to: No other components
Dependencies: FAU_GEN.1
Application Note 9: FAU_SAR.1.2/CON shall ensure that the consumer is able to interpret the
information that is provided to him in a way that allows him to verify the
invoice.
SMGW-PP
Federal Office for Information Security 53
6.2.3.3 Security audit event storage (FAU_STG)
901
6.2.3.3.1 FAU_STG.4/CON: Prevention of audit data loss for the consumer log
902
FAU_STG.4.1/CON The TSF shall [overwrite the oldest stored audit records] and [assignment:
other actions to be taken in case of audit storage failure] if the consumer
audit trail is full.
Hierarchical to: FAU_STG.3 Action in case of possible audit data loss
Dependencies: FAU_STG.1 Protected audit trail storage
Application Note 10: The size of the audit trail that is available before the oldest events get
overwritten is configurable for the Gateway Administrator.
6.2.4 Security Requirements for the Calibration Log
903
6.2.4.1 Security audit data generation (FAU_GEN)
904
6.2.4.1.1 FAU_GEN.1/CAL: Audit data generation for calibration log
905
FAU_GEN.1.1/CAL The TSF shall be able to generate an audit record of the following auditable
events:
a) Start-up and shutdown of the audit functions;
b) All auditable events for the [not specified] level of audit; and
c) [assignment: all calibration-relevant information].
FAU_GEN.1.2/CAL The TSF shall record within each audit record at least the following
information:
a) Date and time of the event, type of event, subject identity (if
applicable), and the outcome (success or failure) of the event; and
b) For each audit event type, based on the auditable event definitions of
the functional components included in the PP/ST, [assignment: other
audit relevant information].
Hierarchical to: No other components
Dependencies: FPT_STM.1
Application Note 11: The calibration log serves to fulfil national requirements in the context of
the calibration of the TOE. The concrete implementation of those
requirements depends on the concrete implementation of the TOE.
Therefore the assignments in FAU_GEN.1.1/CAL and FAU_GEN.1.2/CAL
are left open to the ST author. The ST author shall seek the guidance of the
relevant national authority before deciding about those requirements.
6.2.4.2 Security audit review (FAU_SAR)
906
6.2.4.2.1 FAU_SAR.1/CAL: Audit Review for the calibration log
907
FAU_SAR.1.1/CAL The TSF shall provide [only authorised Gateway Administrators via the
IF_GW_WAN interface] with the capability to read [all information] from
the calibration audit records.
FAU_SAR.1.2/CAL The TSF shall provide the audit records in a manner suitable for the user to
interpret the information.
Hierarchical to: No other components
SMGW-PP
54 Federal Office for Information Security
Dependencies: FAU_GEN.1
6.2.4.3 Security audit event storage (FAU_STG)
908
6.2.4.3.1 FAU_STG.4/CAL: Prevention of audit data loss for calibration log
909
FAU_STG.4.1/CAL The TSF shall [ignore audited events] and [stop the operation of the TOE
and inform a Gateway Administrator] if the calibration audit trail is full.
Hierarchical to: FAU_STG.3 Action in case of possible audit data loss
Dependencies: FAU_STG.1 Protected audit trail storage
Application Note 12: As outlined in the introduction it has to be ensured that the events of the
calibration log are available over the lifetime of the TOE. The developer
shall consider choosing a sufficient size so that the calibration log cannot
become full.
6.2.5 Security Requirements that apply to all logs
910
6.2.5.1 Security audit data generation (FAU_GEN)
911
6.2.5.1.1 FAU_GEN.2: User identity association
912
FAU_GEN.2.1 For audit events resulting from actions of identified users, the TSF shall be
able to associate each auditable event with the identity of the user that
caused the event.
Hierarchical to: No other components
Dependencies: FAU_GEN.1
FIA_UID.1
Application Note 13: Please note that FAU_GEN.2 applies to all audit logs, the system log, the
calibration log, and the consumer log.
6.2.5.2 Security audit event storage (FAU_STG)
913
6.2.5.2.1 FAU_STG.2: Guarantees of audit data availability
914
FAU_STG.2.1 The TSF shall protect the stored audit records in the all audit trails from
unauthorised deletion.
FAU_STG.2.2 The TSF shall be able to [prevent] unauthorised modifications to the stored
audit records in the all audit trails.
FAU_STG.2.3 The TSF shall ensure that [assignment: metric for saving audit records]
stored audit records will be maintained when the following conditions
occur: [audit storage exhaustion or failure].
Hierarchical to: FAU_STG.1 Protected audit trail storage
Dependencies: FAU_GEN.1 Audit data generation
Application Note 14: Please note that FAU_STG.2 applies to all audit logs, the system log, the
calibration log, and the consumer log.
SMGW-PP
Federal Office for Information Security 55
Application Note 15: The ST author shall consider the regulations from the national calibration
authority [TR-03109-1] in order to decide about the amount of information
that needs to be available for the requirement in FAU_STG.2.3 for each
audit log.
6.3 Class FCO: Communication
915
6.3.1 Non-repudiation of origin (FCO_NRO)
916
6.3.1.1 FCO_NRO.2: Enforced proof of origin
917
FCO_NRO.2.1 The TSF shall enforce the generation of evidence of origin for transmitted
[Meter Data] at all times.
FCO_NRO.2.2 The TSF shall be able to relate the [key material used for signature39
] of the
originator of the information, and the [signature] of the information to
which the evidence applies.
FCO_NRO.2.3 The TSF shall provide a capability to verify the evidence of origin of
information to [recipient, [consumer]] given [limitations of the digital
signature according to BSI TR-03109-1].
Hierarchical to: FCO_NRO.1 Selective proof of origin
Dependencies: FIA_UID.1 Timing of identification
Application Note 16: FCO_NRO.2 requires that the TOE calculates a signature over Meter Data
that is submitted to external entities.
Therefore the TOE has to create a hash value over the Data To Be Signed
(DTBS) as defined in FCS_COP.1/HASH. The creation of the actual
signature however is performed by the Security Module.
6.4 Class FCS: Cryptographic Support
918
6.4.1 Cryptographic support for TLS
919
6.4.1.1 Cryptographic key management (FCS_CKM)
920
6.4.1.1.1 FCS_CKM.1/TLS: Cryptographic key generation for TLS
921
FCS_CKM.1.1/TLS The TSF shall generate cryptographic keys in accordance with a specified
cryptographic key generation algorithm [assignment: cryptographic key
generation algorithm] and specified cryptographic key sizes [assignment:
cryptographic key sizes] that meet the following: [assignment: list of
standards].
Hierarchical to: No other components.
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation], fulfilled by FCS_COP.1/TLS
FCS_CKM.4 Cryptographic key destruction
Application Note 17: The Security Module is used for parts of the TLS key negotiation.
39
The key material here also represents the identity of the Gateway
SMGW-PP
56 Federal Office for Information Security
Application Note 18: The TOE shall only use cryptographic specifications and algorithms as
described in [BSI-TR-03109-3].
Application Note 19: Based on [BSI-TR-03109-3] the ST author shall exactly reference the
applied cryptographic key generation algorithm for TLS.
6.4.1.2 Cryptographic operation (FCS_COP)
922
6.4.1.2.1 FCS_COP.1/TLS: Cryptographic operation for TLS
923
FCS_COP.1.1/TLS The TSF shall perform [TLS encryption, decryption, and integrity
protection] in accordance with a specified cryptographic algorithm
[assignment: cryptographic algorithm] and cryptographic key sizes
[assignment: cryptographic key sizes] that meet the following: [assignment:
list of standards].
Hierarchical to: No other components.
Dependencies: [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], fulfilled by
FCS_CKM.1/TLS
FCS_CKM.4 Cryptographic key destruction
Application Note 20: The TOE shall only use cryptographic specifications and algorithms as
described in [BSI-TR-03109-3].
Application Note 21: Based on [BSI-TR-03109-3] the ST author shall exactly reference the
applied cryptographic algorithm.
6.4.2 Cryptographic support for CMS
924
6.4.2.1 Cryptographic key management (FCS_CKM)
925
6.4.2.1.1 FCS_CKM.1/CMS: Cryptographic key generation for CMS
926
FCS_CKM.1.1/CMS The TSF shall generate cryptographic keys in accordance with a specified
cryptographic key generation algorithm [assignment: cryptographic key
generation algorithm] and specified cryptographic key sizes [assignment:
cryptographic key sizes] that meet the following: [assignment: list of
standards].
Hierarchical to: No other components.
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation], fulfilled by FCS_COP.1/CMS
FCS_CKM.4 Cryptographic key destruction
Application Note 22: The TOE utilises the services of its Security Module for parts of the key
generation procedure.
Application Note 23: Based on [BSI-TR-03109-3] and [BSI-TR-03109-1-I] the ST author shall
exactly reference the applied cryptographic key generation algorithm for
CMS.
SMGW-PP
Federal Office for Information Security 57
Application Note 24: The TOE shall only use cryptographic specifications and algorithms as
described in [BSI-TR-03109-3].
6.4.2.2 Cryptographic operation (FCS_COP)
927
6.4.2.2.1 FCS_COP.1/CMS: Cryptographic operation for CMS
928
FCS_COP.1.1/CMS The TSF shall perform [symmetric encryption, decryption and integrity
protection] in accordance with a specified cryptographic algorithm
[assignment: cryptographic algorithm] and cryptographic key sizes
[assignment: cryptographic key sizes] that meet the following: [assignment:
list of standards].
Hierarchical to: No other components.
Dependencies: [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], fulfilled by
FCS_CKM.1/CMS
FCS_CKM.4 Cryptographic key destruction
Application Note 25: The TOE shall only use cryptographic specifications and algorithms as
described in [BSI-TR-03109-3].
Application Note 26: Based on [BSI-TR-03109-3] and [BSI-TR-03109-1-I] the ST author shall
exactly reference the applied cryptographic algorithm for CMS.
6.4.3 Cryptographic support for Meter communication encryption
929
6.4.3.1 Cryptographic key management (FCS_CKM)
930
6.4.3.1.1 FCS_CKM.1/MTR: Cryptographic key generation for Meter communication
931
(symmetric encryption)
932
FCS_CKM.1.1/MTR The TSF shall generate cryptographic keys in accordance with a specified
cryptographic key generation algorithm [assignment: cryptographic key
generation algorithm] and specified cryptographic key sizes [assignment:
cryptographic key sizes] that meet the following: [assignment: list of
standards].
Hierarchical to: No other components.
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation], fulfilled by FCS_COP.1/MTR
FCS_CKM.4 Cryptographic key destruction
Application Note 27: Based on [BSI-TR-03109-3] the ST author shall exactly reference the
applied cryptographic key generation algorithm for Meter communication
encryption.
Application Note 28: The TOE shall only use cryptographic specifications and algorithms as
described in [BSI-TR-03109-3].
SMGW-PP
58 Federal Office for Information Security
6.4.3.2 Cryptographic operation (FCS_COP)
933
6.4.3.2.1 FCS_COP.1/MTR: Cryptographic operation for Meter communication encryption
934
FCS_COP.1.1/MTR The TSF shall perform [symmetric encryption, decryption, integrity
protection] in accordance with a specified cryptographic algorithm
[assignment: cryptographic algorithm] and cryptographic key sizes
[assignment: cryptographic key sizes] that meet the following: [assignment:
list of standards].
Hierarchical to: No other components.
Dependencies: [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], fulfilled by
FCS_CKM.1/MTR
FCS_CKM.4 Cryptographic key destruction
Application Note 29: The PP allows different scenarios of key generation for Meter
communication encryption. Those are:
1. If a TLS encryption is being used the key generation/negotiation is
as defined by FCS_CKM.1/TLS
2. If AES encryption is being used
a. the key is being generated by the Gateway periodically
according to [BSI-TR-03109-3] as defined by
FCS_CKM.1/MTR and sent to the Meter via encrypted
TLS-channel as defined by FCS_COP.1/TLS or
b. the key has been brought into the Gateway via a
management function during the pairing process for the
Meter (see FMT_SMF.1) and defined by
FCS_COP.1/MTR.
Application Note 30: If the connection between the Meter and TOE is unidirectional, the
communication between the Meter and the TOE shall be secured by the use
of a symmetric AES encryption. If a bidirectional connection between the
Meter and the TOE is established, the communication shall be secured by a
TLS channel as described in chapter 6.4.1. As the TOE shall be
interoperable with all kind of Meters it requires the implementation of both
kinds of encryption.
Application Note 31: Based on [BSI-TR-03109-3] the ST author shall exactly reference the
applied cryptographic algorithm.
Application Note 32: The TOE shall only use cryptographic specifications and algorithms as
described in [BSI-TR-03109-3].
SMGW-PP
Federal Office for Information Security 59
6.4.4 General Cryptographic support
935
6.4.4.1 Cryptographic key management (FCS_CKM)
936
6.4.4.1.1 FCS_CKM.4: Cryptographic key destruction
937
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified
cryptographic key destruction method [assignment: cryptographic key
destruction method] that meets the following: [assignment: list of
standards].
Hierarchical to: No other components.
Dependencies: [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], fulfilled by
FCS_CKM.1/TLS and FCS_CKM.1/CMS and FCS_CKM.1/MTR
Application Note 33: Please note that as against the requirement FDP_RIP.2 the mechanisms
implementing the requirement from FCS_CKM.4 shall be suitable to avoid
attackers with physical access to the TOE from accessing the keys after
they are no longer used.
6.4.4.2 Cryptographic operation (FCS_COP)
938
6.4.4.2.1 FCS_COP.1/HASH: Cryptographic operation, hashing for signatures
939
FCS_COP.1.1/HASH The TSF shall perform [hashing for signature creation and verification] in
accordance with a specified cryptographic algorithm [assignment:
cryptographic algorithm] and cryptographic key sizes [none] that meet the
following: [assignment: list of standards]
Hierarchical to: No other components.
Dependencies: [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 generation40
]
FCS_CKM.4 Cryptographic key destruction
Application Note 34: The TOE is only responsible for hashing of data in the context of digital
signatures. The actual signature operation and the handling (i.e. protection)
of the cryptographic keys in this context is performed by the Security
Module.
Application Note 35: The TOE shall only use cryptographic specifications and algorithms as
described in [BSI-TR-03109-3].
Application Note 36: Based on [BSI-TR-03109-3] the ST author shall exactly reference the
applied cryptographic algorithm.
40
The justification for the missing dependency FCS_CKM.1 can be found in chapter 6.12.1.3.
SMGW-PP
60 Federal Office for Information Security
6.4.4.2.2 FCS_COP.1/MEM: Cryptographic operation, encryption of TSF and user data
940
FCS_COP.1.1/MEM The TSF shall perform [TSF and user data encryption] in accordance with
a specified cryptographic algorithm [assignment: cryptographic algorithm]
and cryptographic key sizes [assignment: cryptographic key sizes] that
meet the following: [assignment: list of standards]
Hierarchical to: No other components.
Dependencies: [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], fulfilled by
FCS_CKM.1/CMS
FCS_CKM.4 Cryptographic key destruction
Application Note 37: Please note that the key generation functionality as defined by
FCS_CKM.1/CMS can be used for this functionality as well.
Application Note 38: The TOE shall encrypt its local TSF and user data while it is not in use (i.e.
while stored in a persistent memory). The exact approach to handle the key
that is used for this functionality is left to the ST author. However, the ST
author is motivated to consider the use of the build in Security Module to
store the symmetric key that is used for the encryption of TSF and user
data.
It shall be noted that this kind of encryption cannot provide an absolute
protection against physical manipulation and does not aim to. It however
contributes to the security concept that considers the protection that is
provided by the environment.
Application Note 39: [BSI-TR-02102] should be considered when a cryptographic algorithm is
chosen.
6.5 Class FDP: User Data Protection
941
6.5.1 Introduction to the Security Functional Policies
942
The security functional requirements that are used in the following chapters implicitly define a set of
943
Security Functional Policies (SFP). These policies are introduced in the following paragraphs in more
944
detail to facilitate the understanding of the SFRs:
945
 The Gateway access SFP is an access control policy to control the access to objects under the
946
control of the TOE. The details of this access control policy highly depend on the concrete
947
application of the TOE. The access control policy is described in more detail in [BSI-TR-
948
03109-1].
949
 The Firewall SFP implements an information flow policy to fulfil the objective O.Firewall. All
950
requirements around the communication control that the TOE poses on communications
951
between the different networks are defined in this policy.
952
 The Meter SFP implements an information flow policy to fulfil the objective O.Meter. It
953
defines all requirements concerning how the TOE shall handle Meter Data.
954
6.5.2 Gateway Access SFP
955
6.5.2.1 Access control policy (FDP_ACC)
956
6.5.2.1.1 FDP_ACC.2: Complete access control
957
FDP_ACC.2.1 The TSF shall enforce the [Gateway access SFP] on [
SMGW-PP
Federal Office for Information Security 61
subjects: external entities in WAN, HAN and LMN
objects: any information that is sent to, from or via the TOE and any
information that is stored in the TOE] and all operations among subjects
and objects covered by the SFP.
FDP_ACC.2.2 The TSF shall ensure that all operations between any subject controlled by
the TSF and any object controlled by the TSF are covered by an access
control SFP.
Hierarchical to: FDP_ACC.1 Subset access control
Dependencies: FDP_ACF.1 Security attribute based access control
6.5.2.1.2 FDP_ACF.1 Security attribute based access control
958
FDP_ACF.1.1 The TSF shall enforce the [Gateway access SFP] to objects based on the
following: [
subjects: external entities on the WAN, HAN or LMN side
objects: any information that is sent to, from or via the TOE
attributes: destination interface].
FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation
among controlled subjects and controlled objects is allowed: [
 an authorised Consumer is only allowed to have read access to his
own User Data via the interface IF_GW_CON,
 an authorised Service Technician is only allowed to have read
access to the system log via the interface IF_GW_SRV, the service
technician must not be allowed to read, modify or delete any other
TSF data,
 an authorised Gateway Administrator is allowed to interact with
the TOE only via IF_GW_WAN,
 only authorised Gateway Administrators are allowed to establish a
wake-up call,
 [assignment: additional rules governing access among controlled
subjects and controlled objects using controlled operations on
controlled objects or none]].
FDP_ACF.1.3 The TSF shall explicitly authorise access of subjects to objects based on the
following additional rules: [assignment: rules, based on security attributes
that explicitly authorise access of subjects to objects].
FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the
following additional rules: [
 the Gateway Administrator is not allowed to read consumption
data or the Consumer Log,
 nobody must be allowed to read the symmetric keys used for
encryption].
Hierarchical to: No other components
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialisation
Application Note 40: The ST author shall consider the regulations from [BSI-TR-03109-1] for
additional rules regarding the Gateway access SFP.
SMGW-PP
62 Federal Office for Information Security
6.5.3 Firewall SFP
959
6.5.3.1 Information flow control policy (FDP_IFC)
960
6.5.3.1.1 FDP_IFC.2/FW: Complete information flow control for firewall
961
FDP_IFC.2.1/FW The TSF shall enforce the [Firewall SFP] on [the TOE, external entities on
the WAN side, external entities on the LAN side and all information
flowing between them] and all operations that cause that information to
flow to and from subjects covered by the SFP.
FDP_IFC.2.2/FW The TSF shall ensure that all operations that cause any information in the
TOE to flow to and from any subject in the TOE are covered by an
information flow control SFP.
Hierarchical to: FDP_IFC.1 Subset information flow control
Dependencies: FDP_IFF.1 Simple security attributes
6.5.3.2 Information flow control functions (FDP_IFF)
962
6.5.3.2.1 FDP_IFF.1/FW: Simple security attributes for Firewall
963
FDP_IFF.1.1/FW The TSF shall enforce the [Firewall SFP] based on the following types of
subject and information security attributes: [
subjects: The TOE and external entities on the WAN, HAN or LMN side
information: any information that is sent to, from or via the TOE
attributes: destination_interface (TOE, LMN, HAN or WAN),
source_interface (TOE, LMN, HAN or WAN), destination_authenticated].
FDP_IFF.1.2/FW The TSF shall permit an information flow between a controlled subject and
controlled information via a controlled operation if the following rules
hold: [
(if source_interface=HAN or source_interface=TOE) and
destination_interface=WAN and
destination_authenticated = true
Connection establishment is allowed
[assignment: other rules or none]
else
Connection establishment is denied
].
FDP_IFF.1.3/FW The TSF shall enforce the [establishment of a connection to a configured
external entity in the WAN after having received a wake-up message on the
WAN interface].
FDP_IFF.1.4/FW The TSF shall explicitly authorise an information flow based on the
following rules: [none].
FDP_IFF.1.5/FW The TSF shall explicitly deny an information flow based on the following
rules: [assignment: rules, based on security attributes that explicitly deny
information flows].
Hierarchical to: No other components
SMGW-PP
Federal Office for Information Security 63
Dependencies: FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
Application Note 41: It should be noted that the FDP_IFF.1.1/FW facilitates different interfaces
of the origin and the destination of an information flow implicitly requires
the TOE to implement physically separate ports for WAN, LMN and HAN.
Application Note 42: The assignment in FDP_IFF.1.2/FW may be used by the ST author to
specify additional rules (e.g. connections between devices in different
HANs if the TOE is attached to more than one HAN) as long as those rules
do not contradict the rest of the SFP. Specifically the TOE shall not accept
any connections from the WAN side.
6.5.4 Meter SFP
964
6.5.4.1 Information flow control policy (FDP_IFC)
965
6.5.4.1.1 FDP_IFC.2/MTR: Complete information flow control for Meter information flow
966
FDP_IFC.2.1/MTR The TSF shall enforce the [Meter SFP] on [the TOE, attached Meters,
authorized External Entities in the WAN and all information flowing
between them] and all operations that cause that information to flow to and
from subjects covered by the SFP.
FDP_IFC.2.2/MTR The TSF shall ensure that all operations that cause any information in the
TOE to flow to and from any subject in the TOE are covered by an
information flow control SFP.
Hierarchical to: FDP_IFC.1 Subset information flow control
Dependencies: FDP_IFF.1 Simple security attributes
6.5.4.2 Information flow control functions (FDP_IFF)
967
6.5.4.2.1 FDP_IFF.1/MTR: Simple security attributes for Meter information
968
FDP_IFF.1.1/MTR The TSF shall enforce the [Meter SFP] based on the following types of
subject and information security attributes: [
subjects: TOE, external entities in WAN, Meters located in LMN
information: any information that is sent via the TOE
attributes: destination interface, source interface (LMN or WAN),
Processing Profile
].
FDP_IFF.1.2/MTR The TSF shall permit an information flow between a controlled subject and
controlled information via a controlled operation if the following rules
hold: [
 an information flow shall only be initiated if allowed by a
corresponding Processing Profile].
SMGW-PP
64 Federal Office for Information Security
FDP_IFF.1.3/MTR The TSF shall enforce the [following rules:
 Data received from Meters shall be processed as defined in the
corresponding Processing Profile,
 Results of processing of Meter Data shall be submitted to external
entities as defined in the Processing Profiles,
 The internal system time shall be synchronised as follows:
 The TOE shall compare the system time to a reliable external
time source [assignment: synchronization interval between 1
minute and 24 hours].
 If the deviation between the local time and the remote time is
acceptable41
the local system time shall be updated according
to the remote time.
 If the deviation is not acceptable the TOE
 shall ensure that any following Meter Data is not used,
 stop operation42
and
 inform a Gateway Administrator].
FDP_IFF.1.4/MTR The TSF shall explicitly authorise an information flow based on the
following rules: [assignment: rules, based on security attributes that
explicitly authorise information flows].
FDP_IFF.1.5/MTR The TSF shall explicitly deny an information flow based on the following
rules: [The TOE shall deny any acceptance of information by external
entities in the LMN unless the authenticity, integrity and confidentiality of
the Meter Data could be verified].
Hierarchical to: No other components
Dependencies: FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
Application Note 43: FDP_IFF.1.3 defines that the TOE shall update the local system time
regularly with a reliable external time sources if the deviation is acceptable.
In the context of this functionality two aspects should be mentioned:
Reliability of external source
There are several ways to achieve the reliability of the external source. On
the one hand there may be a source in the WAN that has an acceptable
reliability on its own (e.g. because it is operated by a very trustworthy
organisation (an official legal time issued by the calibration authority
would be a good example for such a source43
)). On the other hand a
developer may choose to maintain multiple external sources that all have a
certain level of reliability but no absolute reliability. When using such
sources the TOE shall contact more than one source and harmonize the
results in order to ensure that no attack happened.
Acceptable deviation
For the question whether a deviation between the time source(s) in the
WAN and the local system time is still acceptable, normative or legislative
41
Please refer to the following application note for a detailed definition of “acceptable”
42
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.
43
By the time that this PP is developed however, this time source is not yet available
SMGW-PP
Federal Office for Information Security 65
regulations shall be considered. If no regulation exists, a maximum
deviation of 3% of the measuring period is allowed to be in conformance
with this Protection Profile. It should be noted that depending on the kind
of application a more accurate system time is needed. But this aspect is not
within the scope of this Protection Profile.
Please further note that – depending on the exactness of the local clock – it
may be required to synchronize the time more often than every 24 hours.
Application Note 44: In FDP_IFF.1.5/MTR the TOE is required to verify the authenticity,
integrity and confidentiality of the Meter Data received from the Meter.
The TOE has two options to do so:
1. To implement a channel between the Meter and the TOE using the
functionality as described in FCS_COP.1/TLS.
2. To accept, decrypt and verify data that has been encrypted by the
Meter as required in FCS_COP.1/MTR if a wireless connection to
the meters is established.
The latter possibility can be used only if a wireless connection between the
Meter and the TOE is established.
6.5.5 General Requirements on user data protection
969
6.5.5.1 Residual information protection (FDP_RIP)
970
6.5.5.1.1 FDP_RIP.2: Full residual information protection
971
FDP_RIP.2.1 The TSF shall ensure that any previous information content of a resource is
made unavailable upon the [deallocation of the resource from] all objects.
Hierarchical to: FDP_RIP.1 Subset residual information protection
Dependencies: No dependencies.
Application Note 45: Please refer to chapter F.9 of part 2 of [CC] for more detailed information
about what kind of information this requirement applies to.
Please further note that this SFR has been used in order to ensure that
information that is no longer used is made unavailable from a logical
perspective. Specifically, it has to be ensured that this information is no
longer available via an external interface (even if an access control or
information flow policy would fail). However, this does not necessarily
mean that the information is overwritten in a way that makes it impossible
for an attacker to get access to is assuming a physical access to the memory
of the TOE.
6.5.5.2 Stored data integrity (FDP_SDI)
972
6.5.5.2.1 FDP_SDI.2: Stored data integrity monitoring and action
973
FDP_SDI.2.1 The TSF shall monitor user data stored in containers controlled by the TSF
for [assignment: integrity errors] on all objects, based on the following
attributes: [assignment: user data attributes].
FDP_SDI.2.2 Upon detection of a data integrity error, the TSF shall [assignment: action
to be taken].
Hierarchical to: FDP_SDI.1 Stored data integrity monitoring
SMGW-PP
66 Federal Office for Information Security
Dependencies: No dependencies.
Application Note 46: This Protection Profile defines that the TOE shall be capable of detecting
integrity errors on all objects. However, the definition of real attributes (e.g.
hash values) that are used to implement this functionality are left to the ST
author.
The developer should further consider the use of the built-in Security
Module as an anchor of trust for this functionality.
6.6 Class FIA: Identification and Authentication
974
6.6.1 User Attribute Definition (FIA_ATD)
975
6.6.1.1 FIA_ATD.1: User attribute definition
976
FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to
individual users: [
 User Identity
 Status of Identity (Authenticated or not)
 Connecting network (WAN, HAN or LMN)
 Role membership
 [assignment: list of security attributes or none]].
Hierarchical to: No other components.
Dependencies: No dependencies.
6.6.2 Authentication Failure handling (FIA_AFL)
977
6.6.2.1 FIA_AFL.1: User authentication before any action
978
FIA_AFL.1.1 The TSF shall detect when [a Gateway Administrator configurable positive
integer within [3 and 10]] unsuccessful authentication attempts occur
related to [authentication attempts at IF_GW_CON].
FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been
[met], the TSF shall [assignment: list of actions].
Hierarchical to: No other components.
Dependencies: FIA_UAU.1 Timing of authentication
6.6.3 User Authentication (FIA_UAU)
979
6.6.3.1 FIA_UAU.2: User authentication before any action
980
FIA_UAU.2.1 The TSF shall require each user to be successfully authenticated before
allowing any other TSF-mediated actions on behalf of that user.
Hierarchical to: FIA_UAU.1
Dependencies: FIA_UID.1 Timing of identification
Application Note 47: Please refer to [BSI-TR-03109-1] for a more detailed overview on the
authentication of the TOE users.
SMGW-PP
Federal Office for Information Security 67
6.6.3.2 FIA_UAU.5: Multiple authentication mechanisms
981
FIA_UAU.5.1 The TSF shall provide [
 authentication via certificates at the IF_GW_MTR interface
 TLS-authentication via certificates at the IF_GW_WAN interface
 TLS-authentication via HAN-certificates at the IF_GW_CON
interface
 authentication via password at the IF_GW_CON interface
 TLS-authentication via HAN-certificates at the IF_GW_SRV
interface
 authentication at the IF_GW_CLS interface
 verification via a commands' signature
] to support user authentication.
FIA_UAU.5.2 The TSF shall authenticate any user's claimed identity according to the [
 meters shall be authenticated via certificates at the IF_GW_MTR
interface only
 Gateway administrators shall be authenticated via TLS-certificates
at the IF_GW_WAN interface only
 consumers shall be authenticated via TLS-certificates or via
password at the IF_GW_CON interface only
 service technicians shall be authenticated via TLS-certificates at
the IF_GW_SRV interface only
 CLS shall be authenticated at the IF_GW_CLS only
 each command of an Gateway Administrator shall be authenticated
by verification of the commands' signature,
 other external entities shall be authenticated via TLS-certificates at
the IF_GW_WAN interface only
].
Hierarchical to: No other components.
Dependencies: No dependencies.
Application Note 48: Please refer to [BSI-TR-03109-1] for a more detailed overview on the
authentication of the TOE users.
6.6.3.3 FIA_UAU.6: Re-authenticating
982
FIA_UAU.6.1 The TSF shall re-authenticate an external entity under the conditions [
 TLS channel to the WAN shall be disconnected after 48 hours,
 TLS channel to the LMN shall be disconnected after 5 MB of
transmitted information,
 Other local users shall be re-authenticated after 10 minutes of
inactivity
].
Hierarchical to: No other components.
Dependencies: No dependencies.
SMGW-PP
68 Federal Office for Information Security
Application Note 49: This requirement on re-authentication for external entities in the WAN and
LMN is addressed by disconnecting the TLS channel even though a re-
authentication is – strictly speaking - only achieved if the TLS channel is
build up again.
6.6.4 User identification (FIA_UID)
983
6.6.4.1 FIA_UID.2: User identification before any action
984
FIA_UID.2.1 The TSF shall require each user to be successfully identified before
allowing any other TSF-mediated actions on behalf of that user.
Hierarchical to: FIA_UID.1
Dependencies: No dependencies.
6.6.5 User-subject binding (FIA_USB)
985
6.6.5.1 FIA_USB.1: User-subject binding
986
FIA_USB.1.1 The TSF shall associate the following user security attributes with subjects
acting on the behalf of that user: [attributes as defined in FIA_ATD.1].
FIA_USB.1.2 The TSF shall enforce the following rules on the initial association of user
security attributes with subjects acting on the behalf of users: [assignment:
rules for the initial association of attributes].
FIA_USB.1.3 The TSF shall enforce the following rules governing changes to the user
security attributes associated with subjects acting on the behalf of users:
[assignment: rules for the changing of attributes].
Hierarchical to: No other components.
Dependencies: FIA_ATD.1 User attribute definition
6.7 Class FMT: Security Management
987
6.7.1 Management of the TSF
988
6.7.1.1 Management of functions in TSF
989
6.7.1.1.1 FMT_MOF.1: Management of security functions behaviour
990
FMT_MOF.1.1 The TSF shall restrict the ability to [modify the behaviour of] the functions
[for management as defined in FMT_SMF.1] to [roles and criteria as
defined in Table 12].
Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
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.
SMGW-PP
Federal Office for Information Security 69
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_WAN44
.
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.
Table 12: Restrictions on Management Functions
991
6.7.1.2 Specification of Management Functions (FMT_SMF)
992
6.7.1.2.1 FMT_SMF.1: Specification of Management Functions
993
FMT_SMF.1.1 The TSF shall be capable of performing the following management
functions: [list of management functions as defined in Table 13 and Table
14 and [assignment: additional functionalities]].
Hierarchical to: No other components.
Dependencies: No dependencies.
SFR Management functionality
FAU_ARP.1/SYS  The management (addition, removal, or modification) of actions.
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.
FAU_SAR.1/SYS
FAU_SAR.1/CON
FAU_SAR.1/CAL
- 45
FAU_STG.4/SYS
FAU_STG.4/CON
 Maintenance (deletion, modification, addition) of actions to be
taken in case of audit storage failure.
 Size configuration of the audit trail that is available before the
oldest events get overwritten.
FAU_STG.4/CAL - 46
FAU_GEN.2 -
44
This criterion applies to all management functions. The following entries in this table only augment this
restriction further.
45
As the rules for audit review are fixed within this PP the management functions as defined by Common
Criteria part 2 do not apply.
46
As the actions that shall be performed if the audit trail is full are fixed within this PP the management
functions as defined by Common Criteria part 2 do not apply.
SMGW-PP
70 Federal Office for Information Security
FAU_STG.2  Maintenance of the parameters that control the audit storage
capability for the consumer log and the system log.
FCO_NRO.2  The management of changes to information types, fields, originator
attributes and recipients of evidence.
FCS_CKM.1/TLS -
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.
FIA_ATD.1  If so indicated in the assignment, the authorised Gateway
Administrator might be able to define additional security attributes
for users.
FIA_AFL.1  Management of the threshold for unsuccessful authentication
attempts;
 Management of actions to be taken in the event of an authentication
failure.
FIA_UAU.2  Management of the authentication data by an Gateway
SMGW-PP
Federal Office for Information Security 71
Administrator;
FIA_UAU.5 - 47
FIA_UAU.6 - 48
FIA_UID.2  The management of the user identities.
FIA_USB.1  An authorised Gateway Administrator can define default subject
security attributes, if so indicated in the assignment of FIA_ATD.1.
 An authorised Gateway Administrator can change subject security
attributes, if so indicated in the assignment of FIA_ATD.1.
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.49
FMT_MSA.3/AC - 50
FMT_MSA.1/FW  Management of rules by which security attributes inherit specified
values.51
FMT_MSA.3/FW - 52
FMT_MSA.1/MTR  Management of rules by which security attributes inherit specified
values.53
FMT_MSA.3/MTR - 54
FPR_CON.1  Definition of the interval in FAU_CON.1.2 if definable within the
operational phase of the TOE
FPR_PSE.1 -
FPT_FLS.1 -
47
As the rules for re-authentication are fixed within this PP the management functions as defined by Common
Criteria part 2 do not apply.
48
As the rules for re-authentication are fixed within this PP the management functions as defined by Common
Criteria part 2 do not apply.
49
As the role that can interact with the security attributes is restricted to the Gateway Administrator within this
PP not all management functions as defined by Common Criteria part 2 do apply.
50
As no role is allowed to specify alternative initial values within this PP the management functions as defined
by Common Criteria part 2 do not apply.
51
As the role that can read, modify, delete or add the security attributes is restricted to the Gateway
Administrator within this PP not all management functions as defined by Common Criteria part 2 do apply.
52
As no role is allowed to specify alternative initial values within this PP the management functions as defined
by Common Criteria part 2 do not apply.
53
As the role that can read, modify, delete or add the security attributes is restricted to the Gateway
Administrator within this PP not all management functions as defined by Common Criteria part 2 do apply.
54
As no role is allowed to specify alternative initial values within this PP the management functions as defined
by Common Criteria part 2 do not apply.
SMGW-PP
72 Federal Office for Information Security
FPT_RPL.1 -
FPT_STM.1  Management of a time source.
FPT_TST.1 - 55
FPT_PHP.1  Management of the user or role that determines whether physical
tampering has occurred.
FTP_ITC.1/WAN - 56
FTP_ITC.1/MTR - 55
FTP_ITC.1/USR - 55
Table 13: SFR related Management Functionalities
994
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 TOE57
Table 14: Gateway specific Management Functionalities
995
Application Note 50: When it is allowed to change the configuration of non-TSF data of the
communication interface via IF_GW_SRV, this functionality shall be
described within the management functional requirements in the ST.
55
As the rules for TSF testing are fixed within this PP the management functions as defined by Common
Criteria part 2 do not apply.
56
As the configuration of the actions that require a trusted channel is fixed by the PP the management functions
as defined in part 2 of Common Criteria do not apply.
57
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.
SMGW-PP
Federal Office for Information Security 73
6.7.2 Security management roles (FMT_SMR)
996
6.7.2.1 FMT_SMR.1: Security roles
997
FMT_SMR.1.1 The TSF shall maintain the roles [
authorised Consumer,
authorised Gateway Administrator,
authorised Service Technician,
[assignment: the authorised identified roles]].
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
Hierarchical to: No other components.
Dependencies: No dependencies.
Application Note 51: The roles “authorised Gateway Administrator”, “authorised Service
Technician” and “authorised Consumer” are the minimum roles that are
needed for the operation of the TOE. However, the assignment in
FMT_SMR.1 deliberately allows the definition of additional roles.
The ST author is asked to complete the roles that are required for a specific
TOE and introduce a more complex set of roles, if necessary.
6.7.3 Management of security attributes for Gateway access SFP
998
6.7.3.1 Management of security attributes (FMT_MSA)
999
6.7.3.1.1 FMT_MSA.1/AC: Management of security attributes for Gateway access SFP
1000
FMT_MSA.1.1/AC The TSF shall enforce the [Gateway access SFP] to restrict the ability to
[query, modify, delete, [assignment: other operations]] the security
attributes [all relevant security attributes] to [authorised Gateway
Administrators].
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control], fulfilled by FDP_ACC.2
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
6.7.3.1.2 FMT_MSA.3/AC: Static attribute initialisation for Gateway access SFP
1001
FMT_MSA.3.1/AC The TSF shall enforce the [Gateway access SFP] to provide [restrictive]
default values for security attributes that are used to enforce the SFP.
FMT_MSA.3.2/AC The TSF shall allow the [no role] to specify alternative initial values to
override the default values when an object or information is created.
Hierarchical to: No other components.
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
SMGW-PP
74 Federal Office for Information Security
6.7.4 Management of security attributes for Firewall SFP
1002
6.7.4.1 Management of security attributes (FMT_MSA)
1003
6.7.4.1.1 FMT_MSA.1/FW: Management of security attributes for firewall policy
1004
FMT_MSA.1.1/FW The TSF shall enforce the [Firewall SFP] to restrict the ability to [query,
modify, delete, [assignment: other operations]] the security attributes [all
relevant security attributes] to [authorised Gateway Administrators].
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control], fulfilled by FDP_IFC.2/FW
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
6.7.4.1.2 FMT_MSA.3/FW: Static attribute initialisation for Firewall policy
1005
FMT_MSA.3.1/FW The TSF shall enforce the [Firewall SFP] to provide [restrictive] default
values for security attributes that are used to enforce the SFP.
FMT_MSA.3.2/FW The TSF shall allow the [no role] to specify alternative initial values to
override the default values when an object or information is created.
Hierarchical to: No other components.
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
Application Note 52: The definition of restrictive default rules for the firewall information flow
policy refers to the rules as defined in FDP_IFF.1.2/FW and
FDP_IFF.1.5/FW. Those rules apply to all information flows and must not
be overwritable by anybody.
6.7.5 Management of security attributes for Meter SFP
1006
6.7.5.1 Management of security attributes (FMT_MSA)
1007
6.7.5.1.1 FMT_MSA.1/MTR: Management of security attributes for Meter policy
1008
FMT_MSA.1.1/MTR The TSF shall enforce the [Meter SFP] to restrict the ability to
[change_default, query, modify, delete, [assignment: other operations]] the
security attributes [all relevant security attributes] to [authorised Gateway
Administrators].
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control], fulfilled by FDP_IFC.2/FW
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
6.7.5.1.2 FMT_MSA.3/MTR: Static attribute initialisation for Meter policy
1009
FMT_MSA.3.1/MTR The TSF shall enforce the [Meter SFP] to provide [restrictive] default
values for security attributes that are used to enforce the SFP.
FMT_MSA.3.2/MTR The TSF shall allow the [no role] to specify alternative initial values to
SMGW-PP
Federal Office for Information Security 75
override the default values when an object or information is created.
Hierarchical to: No other components.
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
6.8 Class FPR: Privacy
1010
6.8.1 Communication Concealing (FPR_CON)
1011
6.8.1.1 FPR_CON.1: Communication Concealing
1012
FPR_CON.1.1 The TSF shall enforce the [Firewall SFP] in order to ensure that no
personally identifiable information (PII) can be obtained by an analysis of
[assignment: characteristics of the information flow that need to be
concealed].
FPR_CON.1.2 The TSF shall connect to [assignment: list of external entities] in intervals
as follows [selection: weekly, daily, hourly, [assignment: other interval]] to
conceal the data flow.
Hierarchical to: No other components.
Dependencies: No dependencies.
Application Note 53: The interval and the list of external entities that shall be used in
FPR_CON.1.2 highly depends on the actual application case. Therefore,
the assignments in FPR_CON.1.2 are left to the ST author.
6.8.2 Pseudonymity (FPR_PSE)
1013
6.8.2.1 FPR_PSE.1 Pseudonymity
1014
FPR_PSE.1.1 The TSF shall ensure that [external entities in the WAN] are unable to
determine the real user name bound to [information neither relevant for
billing nor for a secure operation of the Grid sent to parties in the WAN].
FPR_PSE.1.2 The TSF shall be able to provide [aliases as defined by the Processing
Profiles] of the real user name for the Meter and Gateway identity to
[external entities in the WAN].
FPR_PSE.1.3 The TSF shall [determine an alias for a user] and verify that it conforms to
the [assignment: alias metric].
Hierarchical to: No other components.
Dependencies: No dependencies.
SMGW-PP
76 Federal Office for Information Security
Application Note 54: When the TOE submits information about the consumption or production
of a certain commodity that is not relevant for the billing process nor for a
secure operation of the Grid, there is no need that this information is sent
with a direct link to the identity of the consumer. In those cases the TOE
shall replace the identity of the consumer by a pseudonymous identifier.
Please note that the identity of the consumer may not be their name but
could also be a number (e.g. consumer ID) used for billing purposes.
A Gateway may use more than one pseudonymous identifier.
A complete anonymisation would be beneficial in terms of the privacy of
the consumer. However, a complete anonymous set of information would
not allow the external entity to ensure that the data comes from a
trustworthy source.
Please note that an information flow shall only be initiated if allowed by a
corresponding Processing Profile.
6.9 Class FPT: Protection of the TSF
1015
6.9.1 Fail secure (FPT_FLS)
1016
6.9.1.1 FPT_FLS.1: Failure with preservation of secure state
1017
FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of failures
occur: [
the deviation between local system time of the TOE and the reliable
external time source is too large,
[assignment: other of types of failures in the TSF]].
Hierarchical to: No other components.
Dependencies: No dependencies.
Application Note 55: The local clock shall be as exact as required by normative or legislative
regulations. If no regulation exists, a maximum deviation of 3% of the
measuring period is allowed to be in conformance with this Protection
Profile.
6.9.2 Replay Detection (FPT_RPL)
1018
6.9.2.1 FPT_RPL.1: Replay detection
1019
FPT_RPL.1.1 The TSF shall detect replay for the following entities: [all external entities].
FPT_RPL.1.2 The TSF shall perform [ignore replayed data] when replay is detected.
Hierarchical to: No other components.
Dependencies: No dependencies.
6.9.3 Time stamps (FPT_STM)
1020
6.9.3.1 FPT_STM.1: Reliable time stamps
1021
FPT_STM.1.1 The TSF shall be able to provide reliable time stamps.
Hierarchical to: No other components.
SMGW-PP
Federal Office for Information Security 77
Dependencies: No dependencies.
Application Note 56: The time stamps as defined by FPT_STM.1 shall be of sufficient exactness.
Therefore, the local system time of the TOE is synchronised regularly with
a reliable external time source. Radio controlled clocks shall not be used.
However, the local clock also needs a sufficient exactness as the
synchronisation will fail if the deviation is too large (the TOE will preserve
a secure state according to FPT_FLS.1).
Therefore the local clock shall be as exact as required by normative or
legislative regulations. If no regulation exists, a maximum deviation of 3%
of the measuring period is allowed to be in conformance with this
Protection Profile.
6.9.4 TSF self test (FPT_TST)
1022
6.9.4.1 FPT_TST.1: TSF testing
1023
FPT_TST.1.1 The TSF shall run a suite of self tests [during initial startup, at the request
of a user and periodically during normal operation] to demonstrate the
correct operation of [the TSF].
FPT_TST.1.2 The TSF shall provide authorised users with the capability to verify the
integrity of [TSF data].
FPT_TST.1.3 The TSF shall provide authorised users with the capability to verify the
integrity of [TSF].
Hierarchical to: No other components.
Dependencies: No dependencies.
Application Note 57: The self-test suite as defined in FPT_TST.1 shall contain a test that detects
whether the interfaces for WAN and LAN are separate. It should be noted
that the possibility of the Gateway to detect such a misconfiguration are
limited. The classical way would be that the Gateway tries to reach a
known source in the WAN via a LAN interface. If such a request succeeds
the test fails. Further, to the test the TSF, the self-test suite shall contain a
test to verify the integrity of the TOE firmware.
SMGW-PP
78 Federal Office for Information Security
6.9.4.2 FPT_PHP.1: Passive detection of physical attack
1024
FPT_PHP.1.1 The TSF shall provide unambiguous detection of physical tampering that
might compromise the TSF.
FPT_PHP.1.2 The TSF shall provide the capability to determine whether physical
tampering with the TSF's devices or TSF's elements has occurred.
Hierarchical to: No other components.
Dependencies: No dependencies.
Application Note 58: A passive detection of a physical attack is classically achieved by a seal and
an appropriate physical design of the TOE that allows the consumer (or any
other party) to verify the physical integrity of the TOE.
The level of protection that is required by FPT_PHP.1 is the same level of
protection that is expected for classical meters. Exact requirements can be
found in the regulations of the national calibration authority [TR-03109-1].
6.10 Class FTP: Trusted path/channels
1025
6.10.1 Inter-TSF trusted channel (FTP_ITC)
1026
6.10.1.1 FTP_ITC.1/WAN: Inter-TSF trusted channel for WAN
1027
FTP_ITC.1.1/WAN The TSF shall provide a communication channel between itself and another
trusted IT product that is logically distinct from other communication
channels and provides assured identification of its end points and
protection of the channel data from modification or disclosure.
FTP_ITC.1.2/WAN The TSF shall permit [the TSF] to initiate communication via the trusted
channel.
FTP_ITC.1.3/WAN The TSF shall initiate communication via the trusted channel for [all
communications to external entities in the WAN].
Hierarchical to: No other components
Dependencies: No dependencies.
6.10.1.2 FTP_ITC.1/MTR: Inter-TSF trusted channel for Meter
1028
FTP_ITC.1.1/MTR The TSF shall provide a communication channel between itself and another
trusted IT product that is logically distinct from other communication
channels and provides assured identification of its end points and
protection of the channel data from modification or disclosure.
FTP_ITC.1.2/MTR The TSF shall permit [selection: the Meter, the TOE] to initiate
communication via the trusted channel.
FTP_ITC.1.3/MTR The TSF shall initiate communication via the trusted channel for [any
communication between a Meter and the TOE].
Hierarchical to: No other components.
Dependencies: No dependencies
Application Note 59: The corresponding cryptographic primitives are defined by
SMGW-PP
Federal Office for Information Security 79
FCS_COP.1/MTR.
6.10.1.3 FTP_ITC.1/USR: Inter-TSF trusted channel for User
1029
FTP_ITC.1.1/USR The TSF shall provide a communication channel between itself and another
trusted IT product that is logically distinct from other communication
channels and provides assured identification of its end points and
protection of the channel data from modification or disclosure.
FTP_ITC.1.2/USR The TSF shall permit [the consumer, the service technician] to initiate
communication via the trusted channel.
FTP_ITC.1.3/USR The TSF shall initiate communication via the trusted channel for [any
communication between a consumer and the TOE and the service
technician and the TOE].
Hierarchical to: No other components.
Dependencies: No dependencies.
Application Note 60: Please note that the requirement on a trusted channel for the consumer
interface is implicitly fulfilled for the case that the user interface is
implemented via a local display at the TOE.
6.11 Security Assurance Requirements for the TOE
1030
The minimum Evaluation Assurance Level for this Protection Profile is EAL 4 augmented by
1031
AVA_VAN.5 and ALC_FLR.2.
1032
The following table lists the assurance components which are therefore applicable to this PP.
1033
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
SMGW-PP
80 Federal Office for Information Security
Assurance Class Assurance Component
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 15: Assurance Requirements
1034
6.12 Security Requirements rationale
1035
6.12.1 Security Functional Requirements rationale
1036
6.12.1.1 Fulfilment of the Security Objectives
1037
This chapter proves that the set of security requirements (TOE) is suited to fulfil the security
1038
objectives described in chapter 4 and that each SFR can be traced back to the security objectives. At
1039
least one security objective exists for each security requirement.
1040
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
SMGW-PP
Federal Office for Information Security 81
O.Firewall
O.SeparateIF
O.Conceal
O.Meter
O.Crypt
O.Time
O.Protect
O.Management
O.Log
O.Access
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
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
SMGW-PP
82 Federal Office for Information Security
O.Firewall
O.SeparateIF
O.Conceal
O.Meter
O.Crypt
O.Time
O.Protect
O.Management
O.Log
O.Access
FMT_MOF.1 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
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 16: Fulfilment of Security Objectives
1041
The following paragraphs contain more details on this mapping.
1042
6.12.1.1.1 O.Firewall
1043
O.Firewall is met by a combination of the following SFRs:
1044
 FDP_IFC.2/FW defines that the TOE shall implement an information flow policy for its
1045
firewall functionality.
1046
 FDP_IFF.1/FW defines the concrete rules for the firewall information flow policy.
1047
 FTP_ITC.1/WAN defines the policy around the trusted channel to parties in the WAN.
1048
6.12.1.1.2 O.SeparateIF
1049
O.SeparateIF is met by a combination of the following SFRs:
1050
 FDP_IFC.2/FW and FDP_IFF.1/FW implicitly require the TOE to implement physically
1051
separate ports for WAN and LMN.
1052
SMGW-PP
Federal Office for Information Security 83
 FPT_TST.1 implements a self-test that also detects whether the ports for WAN and LMN
1053
have been interchanged.
1054
6.12.1.1.3 O.Conceal
1055
O.Conceal is completely met by FPR_CON.1 as directly follows.
1056
6.12.1.1.4 O.Meter
1057
O.Meter is met by a combination of the following SFRs:
1058
 FDP_IFC.2/MTR and FDP_IFF.1/MTR define an information flow policy to introduce how
1059
the Gateway shall handle Meter Data.
1060
 FCO_NRO.2 ensures that all Meter Data will be signed by the Gateway (invoking the
1061
services of its security module) before being submitted to external entities.
1062
 FPR_PSE.1 defines requirements around the pseudonymization of Meter identities for Status
1063
data.
1064
 FTP_ITC.1/MTR defines the requirements around the Trusted Channel that shall be
1065
implemented by the Gateway in order to protect information submitted via the Gateway and
1066
external entities in the WAN or the Gateway and a distributed Meter.
1067
6.12.1.1.5 O.Crypt
1068
O.Crypt is met by a combination of the following SFRs:
1069
 FCS_CKM.4 defines the requirements around the secure deletion of ephemeral cryptographic
1070
keys.
1071
 FCS_CKM.1/TLS defines the requirements on key negotiation for the TLS protocol.
1072
 FCS_CKM.1/CMS defines the requirements on key generation for symmetric encryption
1073
within CMS.
1074
 FCS_COP.1/TLS defines the requirements around the encryption and decryption capabilities
1075
of the Gateway for communications with external parties and to Meters.
1076
 FCS_COP.1/CMS defines the requirements around the encryption and decryption of content
1077
and administration data.
1078
 FCS_CKM.1/MTR defines the requirements on key negotiation for meter communication
1079
encryption.
1080
 FCS_COP.1/MTR defines the cryptographic primitives for meter communication encryption.
1081
 FCS_COP.1/HASH defines the requirements on hashing that are needed in the context of
1082
digital signatures (which are created and verified by the security module).
1083
 FCS_COP.1/MEM defines the requirements around the encryption of TSF data.
1084
 FPT_RPL.1 ensures that a replay attack for communications with external entities is detected.
1085
6.12.1.1.6 O.Time
1086
O.Time is met by a combination of the following SFRs:
1087
 FDP_IFC.2/MTR and FDP_IFF.1/MTR define the required update functionality for the local
1088
time as part of the information flow control policy for handling Meter Data.
1089
 FPT_STM.1 defines that the TOE shall be able to provide reliable time stamps.
1090
6.12.1.1.7 O.Protect
1091
O.Protect is met by a combination of the following SFRs:
1092
 FCS_COP.1/MEM defines that the TOE shall encrypt its TSF and user data as long as it is
1093
not in use.
1094
 FDP_RIP.2 defines that the TOE shall make information unavailable as soon as it is no longer
1095
needed.
1096
 FDP_SDI.2 defines requirements around the integrity protection for stored data.
1097
SMGW-PP
84 Federal Office for Information Security
 FPT_FLS.1 defines requirements that the TOE falls back to a safe state for specific error
1098
cases.
1099
 FPT_TST.1 defines the self-testing functionality to detect whether the interfaces for WAN
1100
and LAN are separate.
1101
 FPT_PHP.1 defines the exact requirements around the physical protection that the TOE has to
1102
provide.
1103
6.12.1.1.8 O.Management
1104
O.Management is met by a combination of the following SFRs:
1105
 FIA_ATD.1 defines the attributes for users.
1106
 FIA_AFL.1 defines the requirements if the authentication of users fails multiple times.
1107
 FIA_UAU.2 defines requirements around the authentication of users.
1108
 FIA_UID.2 defines requirements around the identification of users.
1109
 FIA_USB.1 defines that the TOE must be able to associate users with subjects acting on
1110
behalf of them.
1111
 FMT_MOF.1 defines requirements around the limitations for management of security
1112
functions.
1113
 FMT_MSA.1/AC defines requirements around the limitations for management of attributes
1114
used for the Gateway access SFP.
1115
 FMT_MSA.1/FW defines requirements around the limitations for management of attributes
1116
used for the Firewall SFP.
1117
 FMT_MSA.1/MTR defines requirements around the limitations for management of attributes
1118
used for the Meter SFP.
1119
 FMT_MSA.3/AC defines the default values for the Gateway access SFP.
1120
 FMT_MSA.3/FW defines the default values for the Firewall SFP.
1121
 FMT_MSA.3/MTR defines the default values for the Meter SFP.
1122
 FMT_SMF.1 defines the management functionalities that the TOE must offer.
1123
 FMT_SMR.1 defines the role concept for the TOE.
1124
6.12.1.1.9 O.Log
1125
O.Log defines that the TOE shall implement three different audit processes that are covered by the
1126
Security Functional Requirements as follows:
1127
System Log
1128
The implementation of the system log itself is covered by the use of FAU_GEN.1/SYS.
1129
FAU_ARP.1/SYS and FAU_SAA.1/SYS allow to define a set of criteria for automated analysis of the
1130
audit and a corresponding response. FAU_SAR.1/SYS defines the requirements around the audit
1131
review functions and that access to them shall be limited to authorised Gateway Administrators via the
1132
IF_GW_WAN interface and to authorises Service Technicians via the IF_GW_SRV interface. Finally,
1133
FAU_STG.4/SYS defines the requirements on what should happen if the audit log is full.
1134
Consumer Log
1135
The implementation of the consumer log itself is covered by the use of FAU_GEN.1/CON.
1136
FAU_STG.4/CON defines the requirements on what should happen if the audit log is full.
1137
FAU_SAR.1/CON defines the requirements around the audit review functions for the consumer log
1138
and that access to them shall be limited to authorised consumer via the IF_GW_CON interface.
1139
FTP_ITC.1/USR defines the requirements on the protection of the communication of the consumer
1140
with the TOE.
1141
Calibration Log
1142
The implementation of the calibration log itself is covered by the use of FAU_GEN.1/CAL.
1143
FAU_STG.4/CAL defines the requirements on what should happen if the audit log is full.
1144
FAU_SAR.1/CAL defines the requirements around the audit review functions for the calibration log
1145
SMGW-PP
Federal Office for Information Security 85
and that access to them shall be limited to authorised Gateway Administrator via the IF_GW_WAN
1146
interface.
1147
FAU_GEN.2, FAU_STG.2, and FPT_STM.1 apply to all three audit processes.
1148
6.12.1.1.10 O.Access
1149
FDP_ACC.2 and FDP_ACF.1 define the access control policy as required to address O.Access.
1150
FIA_UAU.5 ensures that entities that would like to communicate with the TOE are authenticated
1151
before any action whereby FIA_UAU.6 ensures that external entities in the WAN are re-authenticated
1152
after the session key has been used for a certain amount of time.
1153
6.12.1.2 Fulfilment of the dependencies
1154
The following table summarises all TOE functional requirements dependencies of this PP and
1155
demonstrates that they are fulfilled.
1156
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.1
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
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.1/TLS
FCS_CKM.4
SMGW-PP
86 Federal Office for Information Security
SFR Dependencies Fulfilled by
FCS_CKM.4 Cryptographic key destruction
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/MTR
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.4
FDP_ACC.2 FDP_ACF.1 Security attribute based access
control
FDP_ACF.1
FDP_ACF.1 FDP_ACC.1 Subset access control FDP_ACC.2
SMGW-PP
Federal Office for Information Security 87
SFR Dependencies Fulfilled by
FMT_MSA.3 Static attribute initialisation 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_SMR1
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/FW
FMT_SMR.1
FMT_SMF.1
FMT_MSA.3/FW FMT_MSA.1 Management of security
attributes
FMT_MSA.1/FW
FMT_SMR.1
SMGW-PP
88 Federal Office for Information Security
SFR Dependencies Fulfilled by
FMT_SMR.1 Security roles
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 - -
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 - -
Table 17: SFR Dependencies
1157
6.12.1.3 Justification for missing dependencies
1158
The hash algorithm as defined in FCS_COP.1/HASH does not need any key material. As such the
1159
dependency to an import or generation of key material is omitted for this SFR.
1160
6.12.2 Security Assurance Requirements rationale
1161
The decision on the assurance level has been mainly driven by the assumed attack potential. As
1162
outlined in the previous chapters of this Protection Profile it is assumed that – at least from the WAN
1163
side – a high attack potential is posed against the security functions of the TOE. This leads to the use
1164
of AVA_VAN.5 (Resistance against high attack potential).
1165
In order to keep evaluations according to this Protection Profile commercially feasible EAL 4 has been
1166
chosen as assurance level as this is the lowest level that provides the prerequisites for the use of
1167
AVA_VAN.5.
1168
Eventually, the augmentation by ALC_FLR.2 has been chosen to emphasize the importance of a
1169
structured process for flaw remediation at the developer’s side, specifically for such a new technology.
1170
6.12.2.1 Dependencies of assurance components
1171
The dependencies of the assurance requirements taken from EAL 4 are fulfilled automatically. The
1172
augmentation by AVA_VAN.5 and ALC_FLR.2 does not introduce additional assurance components
1173
that are not contained in EAL 4.
1174
SMGW-PP
Federal Office for Information Security 89
7 Appendix
1175
7.1 Mapping from English to German terms
1176
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 Netz (für Kommunikation)
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 System58
Intelligente, in ein Kommunikationsnetz eingebundene,
elektronische Messeinrichtung (Messsytem)
TOE EVG (Evaluierungsgegenstand)
WAN, Wide Area Network Weitverkehrsnetz (für Kommunikation)
7.2 Glossary
1177
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])
CA Certificate Authority or Certification Authority, an entity that issues digital
certificates.
CLS config See chapter 3.2
58
Please note that the terms “Smart Meter” and “Smart Metering System” are used synonymously within this
document
SMGW-PP
90 Federal Office for Information Security
Term Description
(secondary asset)
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
DTBS Data To Be Signed
EAL Evaluation Assurance Level
Energy Service Provider Organisation offering energy related services to the consumer (according to
[CEN])
external entity See chapter 3.1
firmware update See chapter 3.2
Gateway Administrator See chapter 3.1
Gateway config
(secondary asset)
See chapter 3.2
Gateway time See chapter 3.2
Home Area Network
(HAN)
In-house LAN which interconnects domestic equipment and can be used
for energy management purposes. (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
LAN Local Area Network
Local attacker See chapter 3.4
Meter config
(secondary asset)
See chapter 3.2
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])
SMGW-PP
Federal Office for Information Security 91
Term Description
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).
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.
Service Technician See chapter 3.1
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])
TLS Transport Layer Security protocol according to RFC5246
TOE Target of Evaluation - set of software, firmware and/or hardware possibly
accompanied by guidance
TSF TOE security functionality
WAN attacker See chapter 3.4
WLAN Wireless Local Area Network
7.3 References
1178
[AIS20] Funktionalitätsklassen und Evaluationsmethodologie für deterministische
Zufallszahlengeneratoren, BSI, current version
[AIS31] Funktionalitätsklassen und Evaluationsmethodologie für physikalische
Zufallszahlengeneratoren, BSI, current version
[BSI-TR-02102] BSI TR-02102-2, BSI, current version,
Kryptographische Verfahren: Empfehlungen und Schlüssellängen
[BSI-TR-03109] BSI TR-03109, BSI, current version
[BSI-TR-03109-1] BSI TR-03109-1, BSI, current version,
Anforderungen an die Interoperabilität der Kommunikationseinheit eines
Messsystems
[BSI-TR-03109-2] BSI TR-03109-2, BSI, current version,
Smart Meter Gateway – Anforderungen an die Funktionalität und
Interoperabilität des Sicherheitsmoduls
SMGW-PP
92 Federal Office for Information Security
[BSI-TR-03109-3] BSI TR-03109-3, BSI, current version,
Kryptographische Vorgaben für die Infrastruktur von intelligenten
Messsystemen
Respective:
BSI TR-03116-3, BSI, current version,
eCard-Projekte der Bundesregierung – Kryptographische Vorgaben für die
Infrastruktur von intelligenten Messsystemen
[BSI-TR-03109-4] BSI TR-03109-4, BSI, current version,
Smart Metering PKI - Public Key Infrastruktur für Smart Meter Gateways
[BSI-TR-03109-1-I] BSI TR-03109-1 Anlage I, BSI, current version,
CMS Datenformat für die Inhaltsdatenverschlüsselung und -signatur
[BSI-TR-03109-1-II] BSI TR-03109-1 Anlage II, BSI, current version,
COSEM/http Webservices
[BSI-TR-03109-1-IIIa] BSI TR-03109-1 Anlage IIIa, BSI, current version,
Feinspezifikation „Drahtlose LMN-Schnittstelle“ Teil 1
[BSI-TR-03109-1-IIIb] BSI TR-03109-1 Anlage IIIb, BSI, current version,
Feinspezifikation „Drahtlose LMN-Schnittstelle“ Teil 2
[BSI-TR-03109-1-IV] BSI TR-03109-1 Anlage IV, BSI, current version,
Feinspezifikation „Drahtgebundene LMN-Schnittstelle“
[BSI-TR-03109-1-V] BSI TR-03109-1 Anlage V, BSI, current version,
Anforderungen zum Betrieb beim Administrator
[BSI-TR-03109-1-VI] BSI TR-03109-1 Anlage VI, BSI, current version,
Betriebsprozesse
[CC] Common Criteria for Information Technology Security Evaluation –
 Part 1: Introduction and general model, dated September 2012,
version 3.1, Revision 4
 Part 2: Security functional requirements, dated September 2012,
version 3.1, Revision 4
 Part 3: Security assurance requirements, dated September 2012,
version 3.1, Revision 4
[CEM] Common Methodology for Information Technology Security Evaluation –
Evaluation Methodology, dated September 2012, version 3.1 Revision 4
[CEN] SMART METERS CO-ORDINATION GROUP (SM-CG) Item 5. M/441
first phase deliverable – Communication – Annex: Glossary
(SMCG/Sec0022/DC)
[RFC5114] IETF RFC 5114, M. Lepinski, S. Kent: Additional Diffie-Hellman Groups
for Use with IETF Standards, 2008
[RFC5639] IETF RFC 5639, M. Lochter, J. Merkle: Elliptic Curve Cryptography
(ECC) Brainpool Standard Curves and Curve Generation, 2010
[SD_6] ISO/IEC JTC 1/SC 27 N7446
Standing Document 6 (SD6): Glossary of IT Security Terminology 2009-
04-29, http://www.jtc1sc27.din.de/sce/sd6
SMGW-PP
Federal Office for Information Security 93
[SecMod-PP] Common Criteria Protection Profile for a Security Module for Smart
Metering Systems (BSI-CC-PP-0077-2013).
1179