当前位置:首页 >> 电力/水利 >>

BSI


1

1 2 3 4 5

Protection Profile for the Gateway of a Smart Metering System
Schutzprofil für die Kommunikationseinheit eines Messsystems
Gateway PP
v0.9.2

2

3 4

Gateway PP Version 0.9.2

6 7 8 9 10 11 12 5

Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: +49 228 99 9582-0 E-Mail: bsi@bsi.bund.de Internet: http://www.bsi.bund.de ? Bundesamt für Sicherheit in der Informationstechnik 2011 Federal Office for Information Security

6 13

Gateway PP Version 0.9.2

Table of content
14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
1. PP introduction..................................................................................................................................6 1.1 1.2 1.3 1.4 Introduction...................................................................................................................................6 PP Reference.................................................................................................................................6 Specific terms................................................................................................................................7 TOE Overview.............................................................................................................................10 Introduction............................................................................................................................10 Description of the Smart Metering System.............................................................................10 TOE in the Smart Metering System........................................................................................13 TOE type................................................................................................................................13 TOE physical boundary..........................................................................................................13 TOE logical boundary.............................................................................................................16 The interfaces of the TOE.......................................................................................................18 The cryptography of the TOE and its Security Module..........................................................19

1.4.1 1.4.2 1.4.3 1.4.4 1.4.5 1.4.6 1.4.7 1.4.8 2.1 2.2 2.3 2.4

2. Conformance Claims.......................................................................................................................22 Conformance statement...............................................................................................................22 CC Conformance Claims.............................................................................................................22 PP Claim......................................................................................................................................22 Package Claim.............................................................................................................................22

3. Security Problem Definition............................................................................................................23 3.1 3.2 3.3 3.4 3.5 External entities...........................................................................................................................23 Assets..........................................................................................................................................24 Assumptions................................................................................................................................26 Threats.........................................................................................................................................27 OSPs............................................................................................................................................28

4. Security Objectives..........................................................................................................................29 4.1 4.2 4.3 Security Objectives for the TOE..................................................................................................29 Security objectives for the operational environment....................................................................31 Security Objectives rationale.......................................................................................................32 Overview................................................................................................................................32 Countering the threats.............................................................................................................33 Coverage of organisational security policies...........................................................................35 Coverage of assumptions........................................................................................................36

4.3.1 4.3.2 4.3.3 4.3.4

5. Extended Component definition......................................................................................................37 5.1.1 FPR_CON.1: Communication Concealing.............................................................................37 5.1.2 Family behaviour: FPR_CON.................................................................................................37

7

Federal Office for Information Security

3

8 9 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89

Gateway PP Version 0.9.2 5.1.3 5.1.4 5.1.5 5.1.6 6.1 Component Levelling:............................................................................................................37 Management...........................................................................................................................37 Audit.......................................................................................................................................37 FPR_CON.1: Communication Concealing.............................................................................37

6. Security Requirements.....................................................................................................................38 Class FAU: Security Audit..........................................................................................................40 6.1.1 Security audit automatic response (FAU_ARP) .....................................................................40 6.1.2 Security audit data generation (FAU_GEN)...........................................................................41 6.1.3 Security audit analysis (FAU_SAA) ......................................................................................44 6.1.4 Security audit event storage (FAU_STG) ..............................................................................44 6.2 Class FCO: Communication........................................................................................................46 6.2.1 Non-repudiation of origin (FCO_NRO).................................................................................46 6.3 Class FCS: Cryptographic Support..............................................................................................47 6.3.1 Cryptographic key management (FCS_CKM)........................................................................47 6.4 Class FDP: User Data Protection.................................................................................................49 6.4.1 Access control policy (FDP_ACC) ........................................................................................49 6.4.2 Information flow control policy (FDP_IFC)...........................................................................50 6.4.3 Information flow control functions (FDP_IFF).......................................................................50 6.4.4 Residual information protection (FDP_RIP)...........................................................................53 6.4.5 Stored data integrity (FDP_SDI).............................................................................................53 6.5 Class FIA: Identification and Authentication...............................................................................54 6.5.1 User Attribute Definition (FIA_ATD)....................................................................................54 6.5.2 User identification (FIA_UID)................................................................................................54 6.5.3 User-subject binding (FIA_USB)...........................................................................................54 6.6 Class FMT: Security Management..............................................................................................55 6.6.1 Management of security attributes (FMT_MSA)....................................................................55 6.6.2 Specification of Management Functions (FMT_SMF)...........................................................57 6.6.3 Security management roles (FMT_SMR)...............................................................................58 6.7 Class FPR: Privacy......................................................................................................................58 6.7.1 Communication Concealing (FPR_CON)...............................................................................58 6.8 Pseudonymity (FPR_PSE)...........................................................................................................59 6.9 Class FPT: Protection of the TSF................................................................................................60 6.9.1 Fail secure (FPT_FLS) ...........................................................................................................60 6.9.2 Time stamps (FPT_STM).......................................................................................................60 6.9.3 TSF self test (FPT_TST).........................................................................................................60 Class FTP: Trusted path/channels.....................................................................................................62 6.9.4 Inter-TSF trusted channel (FTP_ITC).....................................................................................62 6.10 Security Assurance Requirements for the TOE..........................................................................64 6.11 Security Requirements rationale................................................................................................65 6.11.1 Security Functional Requirements rationale.........................................................................65 6.11.2 Security Assurance Requirements rationale..........................................................................73

10

4

Federal Office for Information Security

11 90 91 92 93

Gateway PP Version 0.9.2 7. Appendix.........................................................................................................................................73 7.1 7.2 7.3 Mapping from English to German terms......................................................................................73 Glossary.......................................................................................................................................74 References...................................................................................................................................76

List of Tables
Table 1: Specific Terms..........................................................................................................................9 Table 2: TOE external interfaces..........................................................................................................19 Table 3: Cryptographic support by TOE and its Security Module........................................................20 Table 4: Assets.....................................................................................................................................26 Table 5: Rationale for Security Objectives...........................................................................................33 Table 6: List of Security Functional Requirements...............................................................................40 Table 7: Events for system log.............................................................................................................43 Table 8: Events for consumer log.........................................................................................................43 Table 9: Management Functionalities...................................................................................................58 Table 10: Assurance Requirements......................................................................................................64 Table 11: Fulfilment of Security Objectives.........................................................................................67 Table 12: SFR Dependencies................................................................................................................73

94

List of Figures
Figure 1: The TOE as part of a Smart Metering System.......................................................................10 Figure 2: The interfaces of the TOE.....................................................................................................12 Figure 3: TOE design (physical view)..................................................................................................14 Figure 4: TOE design: One Box Solution.............................................................................................15 Figure 5: TOE design: Minimal implementation..................................................................................15 Figure 6: Cryptographic information flow for distributed Meter and Gateway.....................................20 Figure 7: Cryptographic information flow for integrated Meter and Gateway......................................21

95

12

Federal Office for Information Security

5

13

Gateway PP Version 0.9.2

96

1. PP introduction
1.1 Introduction
The increasing use of green energy and upcoming technologies around e-mobility lead to an increasing demand for functions of a so called smart grid. In its vision such a smart grid would allow to invoke consumer devices to regulate the load and availability of energy in the grid (by using consumer devices to store energy or by triggering the use of energy based upon the current load of the grid1). Simple aspects of such a smart use of energy are already reality today. Providers of electricity in Germany for example have to offer at least one tariff that motivates the customer to save energy. In the past, the production of electricity followed the demand/consumption of the consumers. Considering the strong increase in renewable energy and the production of energy as a side effect in heat generation today, the consumption/demand has to follow the – often externally controlled – production of energy. Similar mechanisms can exist for the gas network to control the feed of bio-gas or hydrogen based on information submitted by consumer devices. An essential aspect for all considerations of a smart grid is the so called Smart Metering System that meters the consumption of certain commodities at the conumsers side and allows to send the information about the consumption to external entities. This Protection Profile defines the security objectives and corresponding requirements for a Gateway that is an important part of such a Smart Metering System (please refer to chapter 1.4.2 for a more detailed overview). It is directed to developers of Smart Metering Systems (or their components) and informs them about the requirements that have to be implemented. It is further directed to stakeholders being responsible for purchasing Smart Metering Systems. The Target of Evaluation (TOE) that is described in this document is an electronic unit comprising hardware and software/firmware used for collection, storage and provision of Meter Data2 of one or multiple commodities from one or more Meters. The Gateway separates a Wide Area Network (WAN) from a Network of Devices of one or more Smart Metering devices (Metrological Area Network, MAN) and Controllable Local Systems (CLS) in a Home Area Network (HAN). The security functionality of the TOE comprises protection of confidentiality, authenticity, integrity of data and information flow control, mainly to protect the privacy of consumers, to ensure a reliable billing process and to protect the Smart Metering System and a corresponding large scale infrastructure of the smart grid. The availability of the Gateway does not fall into the primary focus of this PP.

97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127

14 15 16

1 2

Please note that such a functionality requires a consent respective a contract with the consumer Please refer to chapter 3.2 for an exact definition of the term "Meter Data”

6

Federal Office for Information Security

17

Gateway PP Version 0.9.2

128

1.2 PP Reference
Title: Version Date Authors Registration Certification-ID CC-Version Keywords Protection Profile for the Gateway of a Smart Metering System (Gateway PP) 0.9.2 21.03.11 Dr. Helge Kreutzmann (BSI), Nils Tekampe and Arnold Abromeit (T?V Informationstechnik GmbH) Bundesamt für Sicherheit in der Informationstechnik (BSI) Federal Office for Information Security Germany BSI-CC-PP-0073 3.1 Revision 3 Smart Metering, Protection Profile, Meter, Gateway, PP

129 130 131 132 133 134 135

1.3 Specific terms
Various different vocabularies exist in the area of Smart Grid, Smart Metering and Home Automation. Further, the Common Criteria maintain their own vocabulary. The following table provides an overview over the most prominent terms that are used in this Protection Profile and should serve to avoid any bias. A complete glossary and list of acronyms can be found in chapter 7.2. Term Gateway Definition Device or unit responsible for collecting Meter Data, processing Meter Data, providing communication capabilities for devices in the MAN, protecting devices in the LAN 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. CLS are IT-systems 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 Source (if any)

CLS, Controllable Local Systems

18

Federal Office for Information Security

7

19

Gateway PP Version 0.9.2

Term

Definition home automation.

Source (if any)

Meter

The term Meter is used comparable to the term “Smart [CEN], adopted Meter” as defined in [CEN]. It refers to a meter with additional functionality. It allows the meter to collect usage data and transmit this data to responsible parties, e.g. the Metering Service Provider. However, as not all aspects of a Smart Meter according to [CEN] are implemented in the descriptions around this document, the term “Meter” is used. Please note that the term Meter refers to metering devices for all kind of commodities. Security Module that is utilized by the Gateway for cryptographic support – typically realized in form of a smart card. The complete description of the Security Module can be found in [PP_SM].

Security Module

MAN, Metrological In-house data communication network which interconnects Area Network) metrological equipment and can be used for energy management purposes. HAN, Home Area Network LAN, Local Area Network In-house LAN which interconnects domestic equipment and can be used for energy management purposes. (according to [CEN]) Data communication network, connecting a limited number [CEN], adopted of communication devices (Meters and other items) and covering a moderately sized geographical area. In the context of this PP the term LAN is used as a hyperonym for HAN and WAN. Extended data communication network connecting a large [CEN] number of communication devices over a large geographical area. End user of electricity, gas, water or heat. [CEN]

WAN, Wide Area Network Consumer Meter Data

Meter readings that allow calculation of the quantity of [CEN] electricity, gas, water or heat consumed over a period. Other readings and data may also be included (such as quality data, events and alarms).

User, external entity Human or IT entity possibly interacting with the TOE from [CC] outside of the TOE boundary. In the context of this PP the term user refers to either the consumer who is interacting with the TOE or another entity interacting with the TOE. Commodity
136 137

electricity, gas, water or heat
Table 1: Specific Terms

138 20
8 Federal Office for Information Security

21

Gateway PP Version 0.9.2

139

1.4 TOE Overview
1.4.1 Introduction
The TOE as defined in this Protection Profile is the Gateway in a Smart Metering System. In the following subsections first the overall Smart Metering System and afterwards the Gateway itself will be described.

140 141 142 143 144 145 146

1.4.2 Description of the Smart Metering System
The following figure provides an overview over the TOE as part of a complete Smart Metering System from a purely functional perspective as used in this PP.

Figure 1: The TOE as part of a Smart Metering System

148 149 150 151 152 153

As can be seen in figure 1 a system for smart metering comprises different functional units in the context of the descriptions in this PP: ? The Gateway (as defined in this PP) serves as the communication component between the components in the LAN of the consumer and the outside world. It can be seen as a special kind of firewall dedicated to the smart metering functionality. It collects and stores the records from Meter(s) and ensures that only authorised parties have access to them or derivatives

22

Federal Office for Information Security

9

23 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174

Gateway PP Version 0.9.2 thereof. Before sending relevant information the information will be signed and encrypted using the services of a Security Module. The displays features a mandatory display, enabling authorised users to access the data relevant to them. ? The Meter itself records the consumption of one or more commodities (e.g. electricity, gas, water) in defined intervals and submits those records to the Gateway. The Meter Data has to be signed before submission in order to ensure its authenticity and integrity unless the transmission is physically protected due to the Meter and the Gateway beeing implemented within one device. The Meter is comparable to a classical meter3 and has comparable security requirements; it will be sealed as classical meters are today according to the regulations of [PTB_A50.7]. The Meter further supports the encryption of its connection to the Gateway4. Furthermore, the Meter may support secure administration operations like firmware update operations by authorised parties. ? The Gateway utilises the services of a Security Module (e.g. a smart card) as a cryptographic service provider and as a secure storage for confidential assets. The Security Module will be evaluated separately according to the requirements in the corresponding Protection Profile (see [PP_SM]). The following figure introduces the external interfaces of the TOE and their cardinality. Please note that the arrows of the interfaces within the Smart Metering System as shown in Figure 2 indicate the flow of information (which is bi-directional). It however, does not indicate that a communication flow can be initiated bi-directionally. Indeed, the following chapters of this PP will place dedicated requirements on the way an information flow can be initiated.

24
25

3 4

In this context, a classical meter denotes a meter without a communication channel, i.e. whose values have to be read out locally. It should be noted that this PP does not imply that the connection is cable based. It is also possible that the connections as shown in figure 1 are realized based on a wireless technology. However, the requirements on how the connections shall be secured apply regardless of the realization.

26
27 28

29

10

Federal Office for Information Security

30

Gateway PP Version 0.9.2

Figure 2: The interfaces of the TOE

176 177 178 179 180 181 182 183 184 185 186 187 188 189

The following sections introduce the external entities that the TOE interacts with in more detail: Controllable Local Systems (CLS, as shown in Figure 2) may range from local power generation plants, controllable loads such as air condition and intelligent household appliances (“white goods”) to applications in home automation. CLS may utilize the services of the Gateway for communication services. However, CLS are not part of the Smart Metering System. The definition of the Smart Metering System as described before bases on a threat model that has been developed for the Smart Metering System and has been motivated by the following considerations: ? The Gateway is the central communication unit in the Smart Metering System. It should be the only unit directly connected to the WAN, to be the first line of defence an attacker located in the WAN would have to conquer. ? To conquer a Meter or CLS in the MAN or HAN, a WAN attacker first would have to attack the Gateway successfully. All data transfer between LAN and WAN flows via the Gateway, which makes it an ideal unit for placing significant parts of the systems overall security functionality.

31

Federal Office for Information Security

11

32 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227

Gateway PP Version 0.9.2 Furthermore, a Gateway can be used to connect and protect multiple Meters (while a Meter will always be connected to exactly one Gateway) and CLS to the WAN, there might be more Meters and CLS in a Smart Metering System than there are Gateways. All these arguments motivated the approach to have a Gateway (using a Security Module for cryptographic support), which is rich in security functionality, strong and evaluated in depth, in contrast to a Meter, which will only deploy a minimum of security functions, which shall largely be provided by its built-in Security Module. The Meter and the Security Modules will be evaluated separately. It should be noted that this Protection Profile does not imply any concrete system architecture or product design as long as the security requirements from this Protection Profile are fulfilled. It will also be possible to combine the functionalities of Gateway and Meter into one or more modules and device. To underline this approach this PP will further refer to the term “unit” whenever the TOE or another part of the Smart Metering System is described from a functional perspective and only use the term “component” or “device” when a real physical device is described. Possible form of implementing the units of a Smart Metering System in components are described in chapter 1.4.5.
?

1.4.3 TOE in the Smart Metering System
The Smart Metering Gateway (in the following short: Gateway or TOE) serves as the communication unit between devices of private and commercial consumers and service providers of a commodity industry (i.e. electricity, gas, water, etc.). Typically, the Gateway will be placed in the household or premises of the consumer5 of the commodity and enables access to local Meter(s) (i.e. the unit(s) used for measuring the consumption of electric power, gas, water, heat etc.) and Controllable Local Systems (i.e. power generation plants, controllable loads such as air condition and intelligent household appliances). Service providers in the context of the Gateway are the Gateway Operator, Meter Operator, Metering Service Provider, Grid Operator, Commodity Supplier and others as introduced in chapter 3.1. The role of the Gateway in the overall Smart Metering System and the corresponding interfaces are summarised in Figure 1 and 2 above.

1.4.4 TOE type
The TOE is a communication Gateway. It provides different external communication interfaces and serves the data communication between these interfaces and connected IT systems.

1.4.5 TOE physical boundary
The TOE comprises the hardware and software/firmware that is relevant for the security functionality of the Gateway as defined in this PP. The Security Module that is utilized by the TOE is considered being not part of the TOE6. As mentioned in chapter 1.4.2 this Protection Profile does not want to imply any concrete physical architecture for the components that make up the Smart Metering System. The following sections introduce some examples of physical representations for the different components of the Smart Metering System – focussing on the Gateway.

33
34 35

5

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 access to the Gateway. Please note that the security module may be physically integrated into the Gateway even though it

36 37 38

6

is not part of the TOE 12 Federal Office for Information Security

39 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242

Gateway PP Version 0.9.2 It should be noted that this overview of possible physical implementations does not claim being a complete overview of all possibilities. The Common Criteria allow to combine multiple TOE into one device and have the flexibility to assign functionality that is not relevant for the security functionality of the TOE or the environment. However, when focussing on a system of multiple TOEs it is not possible to move security features from the scope of one TOE to another. 1.4.5.1 Possible TOE design: A Gateway and multiple Meters The following figure provides an example for an implementation of a Gateway as defined in this PP from a physical perspective. It is possible that the Gateway is implemented in one device comprising: ? the security relevant parts (i.e. TSF) of the TOE, ? the non security relevant parts of the TOE (e.g. the unit for communication7), and ? the Security Module that is a target of a separate evaluation but is physically located in the device. The Gateway communicates with one or more Meters (in the MAN), provides an interface to the HAN and provides a local display.

Figure 3: TOE design (physical view)

244 245 246

1.4.5.2 Possible TOE Design: One Box Solution The components Gateway and Meter may also be realised by a single physical device providing functionality of both. Such an One Box Solution is shown in the following figure.

40 41

7

Please note that this refers to the pure communication services excluding encryption functionality

Federal Office for Information Security

13

42

Gateway PP Version 0.9.2

43

14

Federal Office for Information Security

44

Gateway PP Version 0.9.2

Figure 4: TOE design: One Box Solution

248 249 250 251 252 253 254 255 256

This One Box Solution may be the preferred implementation for one family houses. From a security perspective this solution has the advantage that the communication between the Gateway unit and the embedded Meters happens in the protected area of the device and hence the communication does not require encryption. 1.4.5.3 Possible TOE Design: Gateway with n Meters and external communication component The following figure acknowledges that there may be functional aspects in the context of a Gateway that are essential for the overall operation of the Gateway but not required to enforce the security functionality of the Gateway. Those functionalities may also be implemented in form of external components that do not belong to the TOE.

Figure 5: TOE design: Minimal implementation

45

Federal Office for Information Security

15

46 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 47 48
49

Gateway PP Version 0.9.2 A classical example of such a functionality is the communication capability to the WAN, MAN or HAN. As long as the requirements around separate networks, encryption and so forth are implemented within the Gateway TSF it may be possible to utilize an external communication component. A failure of such a component would of course lead to an inoperative Gateway. However – as the availability of the Gateway is not within the focus of the requirements in this PP – this would not violate any security requirement.

1.4.6 TOE logical boundary
The logical boundary of the Gateway can be defined by its security functionality: ? Handling of Meter Data, submission to authorised external entities (e.g. one of the service providers involved), where necessary protected by a digital signature ? Protection of authenticity, integrity and confidentiality of data temporarily or persistently stored in the Gateway, transferred locally within the LAN and transferred in the WAN (between Gateway and authorised external entities). ? Firewalling and information flow control for Meters and Controllable Local Systems (and the Gateway itself) from the WAN ? Management of Security Functionality The following sections introduce the security functionality of the TOE in more detail. 1.4.6.1 Handling of Meter Data8 The Gateway will restrict access to Meter Data in the following ways: ? all relevant users shall be identified and authenticated first, before access to any data may be granted9, ? the Gateway shall accept Meter Data from authorised Meters only, ? the Gateway shall accept data (e.g. configuration data, software/firmware updates) from correspondingly authorised users or correspondingly authorised external entities only, ? the Gateway shall send Meter Data to correspondingly authorised external entities only. The TOE utilizes access control profiles to determine which data shall be sent to which component or external entity. An access control profile defines: ? which Meter Data must be sent in which intervals, ? to which component or external entity, ? signed using which key material, ? encrypted using which key material, ? whether Meter Data shall be pseudonymized or not. These functionalities shall ? prevent that the Gateway accepts data from or sends data to unauthorised entities, ? preserve the integrity of billing processes and as such serve for the interests of the consumer as well as for the interests of the supplier. Both parties are interested in an billing process that ensures that the value of the consumed amount of a certain commodity (and only the used amount) is transmitted10,
8 9 10

Please refer to chapter 3.2 for an exact definition of the various data types. Please note that the TOE enforces that users has been successfully authenticated before allowing access. The actual authentication however, is performed by the Security Module. This statement refers to the standard case and ignores that a consumer may also have an interest to manipulate the Meter Data

50
51

52

16

Federal Office for Information Security

53 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341
?

Gateway PP Version 0.9.2 preserve the integrity of the system components and their configurations. The TOE offers an interface and local to the consumer (see also IF_GW_U in figure 2) and allows the consumer to obtain information via this interface. This information comprises the billing relevant data (to allow the consumer to verify an invoice) and information about which Meter Data has been and will be sent to which external entity. The TOE ensures that the communication to the consumer is protected (e.g. by using SSL/TLS) and ensures that consumers only gets access to their own data. 1.4.6.2 Confidentiality protection The TOE protects data from unauthorised disclosure ? while received from the Meter via the MAN, ? while temporarily stored in the volatile memory of the Gateway, ? while transmitted to the corresponding external entity via the WAN. Furthermore, all data, which no longer have to be stored in the Gateway, are securely erased to prevent any form of access to residual data via external interfaces of the TOE. These functionalities shall protect the privacy of the consumer and shall prevent that an unauthorised party is able to disclose any of the data transferred in and from the Smart Metering System (e.g. Meter Data, configuration settings). 1.4.6.3 Integrity and Authenticity protection The Gateway shall provide the following authenticity and integrity protection: ? Verification of authenticity and integrity when receiving Meter Data from a Meter via the MAN, to verify that the Meter Data have been sent from an authentic Meter and have not been altered during transmission. The TOE utilizes the services of its Security Module for aspects of this functionality. ? Application of authenticity and integrity protection measures when sending Meter Data to an external entity, to enable the external entity to verify that the Meter Data have been sent from an authentic Gateway and have not been changed during transmission. The TOE utilizes the services of its Security Module for aspects of this functionality. ? Verification of authenticity and integrity when receiving data from an external entity (e.g. configuration settings or software/firmware updates) to verify that the data have been sent from an authentic and authorised external entity and have not been changed during transmission. The TOE utilizes the services of its Security Module for aspects of this functionality. These functionalities shall ? prevent that in the Smart Metering System data may be sent by a non-authentic component without the possibility that the data recipient can detect this, ? facilitate the integrity of billing processes and serve for the interests of the consumer as well as for the interest of the supplier. Both parties are interested in the transmission of correct Meter Data to be used for billing, ? protect the Smart Metering System and a corresponding large scale Smart Grid infrastructure by preventing that Meter Data from forged components (with the aim to cause damage to the Smart Grid) will be accepted in the system. 1.4.6.4 Information flow control The Gateway shall enforce the following information flow control: ? only the Gateway or devices in the LAN may establish a connection to an external entity, connection establishment by an external entity in the WAN to the Gateway is not possible, ? connections are allowed to configured addresses only,

54

Federal Office for Information Security

17

55 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368

Gateway PP Version 0.9.2 only cryptographically-protected (i.e. encrypted and mutually authenticated) connections are possible. These functionalities shall ? prevent that the Gateway itself or the components behind the Gateway (i.e. Meters or Controllable Local Systems) can be conquered by a WAN attacker, that data are transmitted to the wrong external entity, and that data are transmitted without being confidentiality/authenticity/integrity-protected, ? protect the Smart Metering System and a corresponding large scale infrastructure in two ways: by preventing that conquered components will send forged Meter Data (with the aim to cause damage to the Smart Grid), and by preventing that the widely spread Smart Metering Systems can be abused as a platform for malicious software to attack other systems in the WAN (e.g. if a WAN attacker would be able to install a botnet on components of the Smart Metering System).
?

1.4.6.5 Management of Security Functions The Gateway provides authorized administrators with functionality to manage the behaviour of the security functions. This Protection Profile defines a minimum set of management functions that must be implemented by each Gateway seeking conformance to this PP. Further, it is defined that only authorized administrators may be able to use the management functionality of the Gateway (while the Security Module is used for the authentication of the administrator). However, this Protection Profile does not define any concrete way the management shall happen. Solutions for local management (e.g. during the installation of a Gateway) are as acceptable as solutions for remote management as long as the security requirements from this PP are met.

1.4.7 The interfaces of the TOE
The TOE offers its functionality as outlined before via a set of external interfaces. As to see in Figure 2 some of the interfaces are mandatory while others are not. The following table provides an overview over the external interfaces of the TOE and provides additional information: Interface Name IF_GW_U Description Mandatory

Interface via which the Gateway provides the consumer no with the possibility to review information that are relevant for billing or the privacy of the consumer. Please further note that the implementation of a local display at the Gateway is mandatory. This display shall be capable to inform the consumer about all information that are relevant for billing and the privacy of the consumer. As the display is a part of the Gateway there is no separate interface for it.

IF_GW_M IF_GW_SM IF_GW_CLS

Interface between the Meter and the Gateway. The yes Gateway receives Meter Data via this interface. Via this interface the Gateway invokes the services of its yes Security Module CLS may use the communication services of the Gateway yes via this interface. The implementation of at least one interface for CLS is mandatory.

56

18

Federal Office for Information Security

57

Gateway PP Version 0.9.2

IF_GW_WAN

The Gateway submits information to authorized external yes entities via this interface. Table 2: TOE external interfaces

369 370 371 372 373 374 375 376 377 378

1.4.8 The cryptography of the TOE and its Security Module
Parts of the cryptographic functionality used in the upper-mentioned functions shall be provided by a Security Module providing strong cryptographic functionality and secure storage of secrets. The Security Module is a different IT product and not part of the TOE as described in this PP. Nevertheless it may be physically embedded into the Gateway. The requirements applicable to the Security Module are specified in a separate PP (see [PP_SM]). The following table provides a more detailed overview on how the cryptographic functions are distributed between the TOE and its Security Module. Aspect Communication to external entities TOE Encryption Security Module Key Negotiation Authentication of the external entity Secure Storage of the private key Integer and authentic Storage of a public root or CA key Random Number Generation Key Negotiation User authentication Secure Storage of the private key Integer and authentic Storage of a public root or CA key Random Number Generation Key Negotiation Secure Storage of the private key Integer and authentic Storage of a public root or CA key Random Number Generation Verification of signature Secure Storage of the public key Signature creation Secure Storage of the private key

Communication to the consumer Encryption

Communication to the Meter

Encryption Hashing for

Verification of Meter Data received from the Meter Data Signing data before submission to an external entity
379

Hashing Hashing

Table 3: Cryptographic support by TOE and its Security Module

380 381 382

The following figures introduce the communication process between the Meter, the TOE and external entities (focussing on billing relevant Meter Data). Two cases can be distinguished:

58

Federal Office for Information Security

19

59 383

Gateway PP Version 0.9.2 1.4.8.1 Distributed Gateway and Meter

Figure 6: Cryptographic information flow for distributed Meter and Gateway

385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413

In the case that Meter and Gateway are realized in separate physical devices the basic information flow for Meter Data is as follows: 1. The Meter measure the consumption of a certain commodity 2. The Meter Data is signed using the services of the integrated Security Module 3. The Meter Data is transmitted via an encrypted and mutually authenticated channel to the Gateway. Please note that the submission of this information may be triggered by the Meter or the Gateway. 4. The signature of the Meter Data is verified by the Gateway invoking the services of its security module. 5. If (and only if) the signature could be verified successfully the Meter Data is further processed by the Gateway according to the regulations in the access control profiles. 6. The processed Meter Data is signed using the services of the Security Module. 7. The signed Meter Data may be stored for a certain amount of time and 8. is finally submitted to an authorized external entity in the WAN via an encrypted and mutually authenticated channel.

1.4.8.2 Integrated Gateway and Meter In the case that Meter and Gateway are realized in one physical device the basic information flow for Meter Data is as follows: 1. The Meter measure the consumption of a certain commodity 2. The Meter Data is transmitted to the Gateway unit of the device. Please note that the submission of this information may be triggered by the Meter or the Gateway. 3. The Meter Data is further processed by the Gateway according to the regulations in the access control profiles 4. The processed Meter Data is signed using the services of the Security Module. 5. The signed Meter Data may be stored for a certain amount of time and 6. is finally submitted to an authorized external entity in the WAN via an encrypted and mutually authenticated channel.

60

20

Federal Office for Information Security

61

Gateway PP Version 0.9.2

Figure 7: Cryptographic information flow for integrated Meter and Gateway

414 415

This scenario acknowledges the physical protection of the communication between the Meter and the Gateway that is achieved as both units are implemented within one device.

62

Federal Office for Information Security

21

63

Gateway PP Version 0.9.2

416

2. Conformance Claims
2.1 Conformance statement
The PP requires strict conformance of any PPs/STs to this PP.

417 418 419 420 421 422 423 424 425 426 427 428

2.2 CC Conformance Claims
● ● ●

This PP has been developed using Version 3.1 R3 of Common Criteria [CC]. This PP is conformant to [CC] part 2 extended due to the use of FPR_CON.1. This PP is conformant to [CC] part 3; no extended assurance components have been defined.

2.3 PP Claim


This PP does not claim conformance to any other Protection Profile.

2.4 Package Claim


This Protection Profile conforms to assurance package EAL4 augmented by AVA_VAN.5 and ALC_FLR.2 as defined in [CC] Part 3.

64

22

Federal Office for Information Security

65

Gateway PP Version 0.9.2

429

3. Security Problem Definition
3.1 External entities
The following external entities interact with the system consisting of Meter and Gateway. Those roles have been defined for the use in this Protection Profile. It is possible that a party implements more than one role in practice. Consumer: The 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 energy (e.g. with their own solar plant). Operates the grid in which the commodity is distributed. Supplies the commodity to the consumer. Produces the commodity. Responsible for installing and maintaining the Meter.

430 431 432 433 434

Grid Operator: Supplier: Producer: Meter Operator:

Gateway Operator: Responsible for installing and maintaining the Gateway. Metering Service Provider: Meter Admin: Gateway Admin: Profile Provider: Responsible for acquiring Meter Data from the Meter and for providing these data to the corresponding external entities. Administrator of the Meter, may be an agent of the Meter Operator and/or Metering Service Provider. Administrator of the Gateway, may be an agent of the Gateway Operator and/or Metering Service Provider. This party is responsible for issuing the profiles that are used for information flow control. Please refer to A.AccessProfile for more details on those profiles. Under the term external entity all roles shall be summarised which are authorised recipients of Meter Data. This includes, but is not limited to, Metering Service Provider, Grid Operator and Supplier. Attacker having physical access to Meter, Gateway or a connection between these components, trying to disclose or alter assets (including software updates and the firmware of the TOE) while stored in Meter or Gateway or while transmitted between both in the MAN. Attacker located in the WAN trying to compromise the confidentiality and/or integrity of the Meter Data and or configuration data transmitted via a WAN, or attacker trying to conquer a component of the infrastructure (i.e. Meter, Gateway or Controllable Local System) via a WAN to cause damage to a component itself or to the corresponding grid (e.g. by sending forged Meter Data to an external entity).

External entity:

Local attacker:

WAN attacker:

435 436 66
Federal Office for Information Security 23

67 437 438 439 440 441

Gateway PP Version 0.9.2

3.2 Assets
The following table introduces the relevant assets for this Protection Profile. The table focusses on the assets that are relevant for the Gateway and does not claim to provide an overview over all assets in the Smart Metering System or for other devices in the MAN. Asset Meter Data Description Meter readings that allow calculation of the quantity of electricity, gas, water or heat consumed over a period. Meter data comprise consumption data (billing-relevant) and grid status data (not billing-relevant). While billing data needs to have a relation to the consumer grid status data do not have to be directly related to a consumer. Billing relevant part of Meter Data. Need for Protection
?

?

Integrity and authenticity (comparable to the classical meter and its security requirements), confidentiality (due to privacy concerns)

Consumption Data

?

?

Integrity and authenticity (comparable to the classical meter and its security requirements), confidentiality (due to privacy concerns) Integrity and authenticity (comparable to the classical meter and its security requirements) Integrity and authenticity (comparable to the classical meter and its security requirements), confidentiality in the WAN (due to privacy concerns)

Status Data

Grid status data, subset of Meter Data that is not billing relevant

?

Supplementary Data

The Gateway may be used for communication purposes by devices in the MAN 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 The terms Data or User Data are used as a hyperonym for Meter Data and Supplementary Data Date and time of the real-time clock of the Gateway. Gateway Time is used in Meter Data records sent to external entities.

?

?

Data User Data Gateway time

? ?

Integrity, authenticity (when time is adjusted to an external reference time) Integrity and authenticity, confidentiality Integrity and authenticity,

Meter config Configuration data of the Meter to control (secondary asset) its behaviour. Gateway config Configuration data of the Gateway to

? ? ?

68

24

Federal Office for Information Security

69

Gateway PP Version 0.9.2

(secondary asset) control its behaviour. CLS config Configuration data of a CLS to control its (secondary asset) behaviour. software update Software update that is downloaded by the (secondary asset) TOE to update the software of the TOE Firmware The firmware of the TOE (secondary asset)
442 443

? ? ? ?

confidentiality Integrity and authenticity, confidentiality Integrity and Authenticity Integrity Authenticity

? ?

Table 4: Assets

444 445 446 447

3.3 Assumptions
The following table lists assumptions about the environment of the components in this threat model that need to be taken into account in order to ensure a secure operation. A.ExternalPrivacy It is assumed that external entities receiving any kind of private or billing relevant data and the applications that they operate are trustworthy and do not perform unauthorised analyses of this data with respect to the corresponding consumer(s). It is assumed that the Gateway Admin is trustworthy and well-trained. It is assumed that the TOE is installed in a non-public environment that provides a basic level of physical protection. This protection covers the TOE, the Meters that the TOE communicates with and the communication channel between the TOE and its Security Module. The access control profiles that are used when handling data are assumed to be trustworthy and correct. It is assumed that the software updates for the Gateway that can be provided by an authorized 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 authorized to provide the update is trustworthy and will not introduce any malware into a software update. It is assumed that a WAN connection with a sufficient reliability and bandwidth for the individual situation is available. This PP acknowledges that the Gateway cannot be completely protected against unauthorized physical access by its environment. However, it is important for the overall security of the TOE that it is not installed within a completely 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

A.TrustedAdmins A.PhysicalProtection

A.AccessProfile A.Update

A.WAN

448
Application Note:

70

Federal Office for Information Security

25

71

Gateway PP Version 0.9.2

meters that operate according to the requirements of [PTB_A50.7]. Application Note: The profiles that are used for information flow control as referred to by A.AccessProfile are an essential factor for the preservation of the privacy of the consumer. The profiles are used to determine which data shall be sent to which entity at which frequency and whether the data needs to be related to the consumer (because it is used for billing purposes) or whether the data shall be pseudonymized. The profiles shall be visible for the consumer to allow a transparency of the communication. It is essential that profiles correctly define the amount of information that must be sent to an external entity. Exact regulations around the profiles and the Profile Provider are beyond the scope of this Protection Profile.

449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467

3.4 Threats
The following sections identifiy the threats that are posed against the assets handled by the Smart Metering System. Those threats are the result of a threat model that has been developed for the whole Smart Metering System first and then has been focussed on the threats against the Gateway. It should be noted that the threats in the following paragraphs consider two different kinds of attackers: ? Local attackers having physical access to Meter, Gateway or a connection between these components, trying to disclose or alter assets while stored in Meter or Gateway or while transmitted between both in the MAN. ? Remote attacker located in the WAN trying to compromise the confidentiality and/or integrity of the Meter Data and or configuration data transmitted via a WAN, or attacker trying to conquer a component of the infrastructure (i.e. Meter, Gateway or Controllable Local System) via a WAN to cause damage to a component itself or to the corresponding grid (e.g. by sending forged Meter Data to an external entity). Even though in the concept of Common Criteria the attacker with the highest attack potential (which is the WAN attacker with a high attack potential) determines the level for the vulnerability analysis (please also refer to chapter 6.11.2) the definition of following threats acknowledges that the local attacker has less attack potential than the remote attacker. T.DataModificationLocal A consumer or local attacker may try to alter, insert, replay or redirect Meter Data when transmitted between Meter and Gateway. The objective of the attacker may be to alter billing relevant information or grid status information. 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, replay or redirect) Meter Data, Gateway config data, Meter config data, CLS config data or a software 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

72

26

Federal Office for Information Security

73

Gateway PP Version 0.9.2

information. When trying to modify config data or a software update the attacker tries to circumvent security mechanisms of the TOE or get control over the TOE or a unit that is protected by the TOE. T.TimeModification A consumer or local attacker or WAN attacker may try to alter the Gateway time to change the relation between date/time and measured consumption values in the Meter Data records (e.g. to influence the balance of the next invoice) 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. 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. A WAN attacker may try to obtain control over Gateways, Meters or CLS, 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). 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). A WAN or local attacker may try to access (i.e. read, modify, 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.DisclosureWAN

T.DisclosureLocal

T.Infrastructure

T.ResidualData

T.ResidentData

468 469 470 471

3.5 OSPs
The following sections lists the organizational security policies that the Gateway shall comply with: OSP.SM The TOE shall use the services of a certified Security Module for – verification of digital signatures – generation of digital signatures – key agreement – Random Number Generation The used Security Module shall be certified according to [PP_SM] and shall be used in accordance with its relevant guidance documentation. The TOE shall maintain a log of relevant events in order to allow an authorized administrator to analyse the status of the TOE.

OSP.Log

74

Federal Office for Information Security

27

75

Gateway PP Version 0.9.2

Further, the TOE shall maintain a consumer log that contains information about the information flow that has been initiated and will be initiated by the Gateway and shall provide this information to the consumer. In the consumer log, the TOE shall also maintain all billing relevant data and shall provide the consumer with a possibility to review this data in a way that allows the consumer to verify their invoice. Access to the information in the consumer log shall be limited to the user who owns the information.

472 473

4. Security Objectives
4.1 Security Objectives for the TOE
O.Firewall The TOE shall serve as the connection point for internal devices or units in the Smart Metering System to external entities and shall provide firewall functionality in order to protect the devices or units of the MAN and HAN against threats from the WAN side. The firewall shall


474

– –



allow only connections established from internal network to external network (e.g. from systems in the MAN or HAN to external entities in the WAN), shall not allow any services being offered on the WAN side interface, enforce communication flows by allowing traffic to the WAN only if confidentiality-protected and integrity-protected and if endpoints are authenticated, provide cryptographic services (authentication, key establishment, encryption/decryption) using a built-in Security Module for key negotiation.

O.SeparateIF

The TOE shall have physically separated ports for the MAN, the HAN and the WAN and shall automatically detect during its self test whether cables, if any, are wrongly connected. To protect the privacy of its consumers, the TOE shall conceal the communication with outside parties in order to ensure that no privacyrelevant information may be obtained by analysing the frequency, load, size or the absence of external communication. The TOE receives or polls information about the consumption of different commodities from one or multiple Meters and is responsible for handling this Meter Data. This includes that


O.Conceal

O.Meter

the TOE shall ensure that the communication to the Meter(s) is established in an administrator-definable interval or an interval as defined by the Meter,

76

28

Federal Office for Information Security

77

Gateway PP Version 0.9.2





– –



the TOE shall enforce encryption for the communication with the Meter11 if the Meter and Gateway are not implemented within a single device, the TOE shall verify the integrity and authenticity of the data received from a Meter if the Meter and Gateway are not implemented within a single device before handling it further, the TOE shall deliver the cumulated data to the authorised external entities as defined in the corresponding access control profiles, the TOE shall store 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 pseudonymize the data for parties that do not need the relation between the Meter Data and the identity of the consumer.

O.Crypt

The TOE shall provide cryptographic functionality as follows: – verification of signatures for data received from the Meter, – authentication and encryption of the communication to external entities, – authentication and encryption of the communication to the Meter. In addition the TOE shall generate the required keys utilizing the services of its Security Module and destroy ephemeral12 keys if not longer needed.1314 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. The TOE shall implement functionality to protect its security functions against malfunctions and tampering. Specifically, the TOE shall
– – –

O.Time

O.Protect



overwrite any information that is not longer needed to ensure that it is not longer available via the external interfaces of the TOE, implement a self test, have a fail-safe design that specifically ensures that any malfunction can not impact the delivery of a commodity, e.g. energy, gas or water15, make any physical manipulation within the scope of the intended

78
79 80 81 82 83

11

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. However, it should be noted that the encryption of this channel only needs to protect against the Local Attacker possessing a basic attack potential and that the Meter utilises the services of it Security Module to negotiate the channel. This objective addresses the destruction of ephemeral keys only because all keys that need to be stored persistently are stored in the Security Module. Please refer to chapter 1.4.8 for an overview on how the cryptographic functions are distributed between the TOE and its Security Module. Please refer to chapter F.9 of part II of [CC] for more detailed information about what kind of information this objective applies to.

84
85

12 13 14

86
87

88
89

90

Federal Office for Information Security

29

91

Gateway PP Version 0.9.2

environment detectable for the consumer or administrator. O.Management The TOE shall only provide authorised administrators with functions for the management of the security features. Further, the TOE shall implement a secure mechanism to update the software of the TOE that ensures that only authorized parties are able to provide updates for the TOE and that only authentic and integer updates are applied. O.Log The TOE shall maintain a log of relevant events in order to allow an authorized administrator to analyse the status of the TOE. Further, the TOE shall maintain a consumer log that contains information about the information flow that has been initiated and will be initiated by the Gateway and shall provide this information to the consumer. In the consumer log, the TOE shall also maintain all billing relevant data and shall provide the consumer with a possibility to review this data in a way that allows the consumer to verify their invoice. The TOE shall control the access of users to information via its external interfaces. While in classical access control mechanisms the administrators gets complete access the TOE also maintains a set of information (specifically billing relevant data) to which administrators only have limited access.

O.Access

475 476
Application Note O.SeparateIF refers to physical interfaces and must not be fulfilled by a pure logical separation of one physical interface.

477

4.2 Security objectives for the operational environment
OE.ExternalPrivacy External entities receiving any kind of privacte or billing relevant data shall be trustworthy and shall not perform unauthorised analyses of these data with respect to the corresponding consumer(s). The Gateway Admin shall be trustworthy and well-trained.

OE.TrustedAdmins

OE.PhysicalProtection The TOE shall be installed in a non-public environment 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. OE.Profile OE.SM The access control profiles that are used when handling data shall be obtained from a trustworthy source only. The TOE shall use the services of a certified Security Module for – verification of digital signatures – generation of digital signatures
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.

92
93 94

15

95

30

Federal Office for Information Security

96

Gateway PP Version 0.9.2

key agreement The Security Module used shall be certified according to [PP_SM] and shall be used in accordance with its relevant guidance documentation.


OE.Update

The software updates for the Gateway that can be provided by an authorized 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 authorized to provide the update shall be trustworthy and ensure that no malware is introduced via a software update. A WAN connection with a sufficient reliability and bandwidth for the individual situation shall be available.

OE.WAN

478 479 480 481 482 483

4.3 Security Objectives rationale
4.3.1 Overview
The following table gives an overview, how the assumptions, threats, and organisational security policies are addressed by the security objectives. The text of the following sections justifies this more detailed.

97

Federal Office for Information Security

31

98 484

Gateway PP Version 0.9.2

O.Firewall T.DataModificationLo cal T.DataModificationW AN T.TimeModification T.DisclosureWAN T.DisclosureLocal T.Infrastructure T.ResidualData T.ResidentData OSP.SM OSP.Log A.ExternalPrivacy A.TrustedAdmins A.PhysicalProtection A.AccessProfile A.Update A.WAN
485 486

O.SeparateIF X

O.Conceal

O.Meter X

O.Crypt X X

O.Time

O.Protect X X

O.Management X X X X X X

O.Log

O.Access

OE.ExternalPrivacy

OE.TrustedAdmins

OE.PhysicalProtection X

OE.Profile

OE.SM

OE.Update

OE.WAN

X

X X X X X X X X

X X X X X

X

X

X X X X X X X X X Table 5: Rationale for Security Objectives X

487 488 489 490 491 492 493 494 99

4.3.2 Countering the threats
The following sections provide more detailed information on how the threats are countered by the security objective for the TOE. 4.3.2.1 T.DataModificationLocal The threat T.DataModificationLocal is countered by a combination of the security objectives O.Meter, O.Crypt, O.Protect, O.Management and OE.PhysicalProtection . O.Meter defines that the TOE will enforce the encryption of communication when receiving consumption data from the Meter. O.Crypt defines the required cryptographic primitives for this

32

Federal Office for Information Security

100 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538

Gateway PP Version 0.9.2 encryption. Both objectives together ensure that the communication between the Meter and the TOE cannot be modified or released. O.Protect supports the mitigation of this threat by ensuring the correct operation of the Security Functions of the TOE (as it requires a self test). O.Management defines the required management functionality for the aforementioned security features. OE.PhysicalProtection is of relevance as it ensures that access to the TOE is limited.

4.3.2.2 T.DataModificationWAN The threat T.DataModificationWAN is countered by a combination of the security objectives O.Firewall, O.Crypt, O.Protect and O.Management. O.Firewall defines that the TOE will enforce the encryption of communication for each communication to the WAN. O.Crypt defines the required cryptographic primitives for this encryption. Both objectives together ensure that the communication between the Meter and the TOE cannot be modified. O.Protect supports the mitigation of this threat by ensuring the correct operation of the Security Functions of the TOE (as it requires a self test). O.Management defines the required management functionality for the aforementioned security features. 4.3.2.3 T.TimeModification The threat T.TimeModification is countered by a combination of the security objectives O.Time, O.Protect, O.Management and OE.PhysicalProtection. O.Time defines that the TOE needs a reliable time stamp mechanism that is also updated from reliable sources regularly. Therewith, O.Time is the core objective to counter the threat T.TimeModification. O.Protect supports the mitigation of this threat by ensuring the correct operation of the Security Functions of the TOE (as it requires a self test). O.Management defines the required management functionality for the aforementioned security features and specifically ensures that only authorized administrators are allowed to perform management. OE.PhysicalProtection is of relevance as it ensures that access to the TOE is limited. 4.3.2.4 T.DisclosureWAN The threat T.DisclosureWAN is countered by a combination of the security objectives O.Firewall. O.Conceal. O.Crypt, O.Protect and O.Management. O.Firewall defines that the TOE will enforce the encryption of communication for each communication to the WAN. O.Crypt defines the required cryptographic primitives for this encryption. Both objectives together ensure that the communication between the Meter and the TOE cannot be disclosed. O.Conceal ensures that no information can be disclosed based on additional characteristics of the communication like frequency, load or the absence of a communication. O.Protect supports the mitigation of this threat by ensuring the correct operation of the Security Functions of the TOE (as it requires a self test). O.Management defines the required management functionality for the aforementioned security features. 4.3.2.5 T.DisclosureLocal The threat T.DisclosureLocal is countered by a combination of the security objectives O.Meter, O.Crypt, O.Protect, O.Management and OE.PhysicalProtection. O.Meter defines that the TOE will enforce the encryption of communication when polling or recieving consumption data from the Meter. O.Crypt defines the required cryptographic primitives for this

101

Federal Office for Information Security

33

102 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578

Gateway PP Version 0.9.2 encryption. Both objectives together ensure that the communication between the Meter and the TOE cannot be disclosed. O.Protect supports the mitigation of this threat by ensuring the correct operation of the Security Functions of the TOE (as it requires a self test). O.Management defines the required management functionality for the aforementioned security features. OE.PhysicalProtection is of relevance as it ensures that access to the TOE is limited. 4.3.2.6 T.Infrastructure The threat T.Infrastructure is countered by a combination of the security objectives O.Firewall, O.SeparateIF, O.Crypt, O.Protect and O.Management. O.Firewall is the core objective that counters this threat. It ensures that all communication flows are initiated by the TOE. The fact that the TOE does not offer any services to the WAN side and will not react to any requests from the WAN is a significant aspect in countering this threat. Further the TOE will only communicate using encrypted channels to authenticated and trustworthy parties which mitigates the possibility that an attacker could try to hijack a communication. O.SeparateIF facilitates the disjunction of the WAN from the MAN. O.Crypt supports the mitigation of this threat by providing the required cryptographic primitives. O.Protect supports the mitigation of this threat by ensuring the correct operation of the Security Functions of the TOE (as it requires a self test). O.Management defines the required management functionality for the aforementioned security features. 4.3.2.7 T.ResidualData The threat T.ResisdualData is mitigated by the security objective O.Protect as this security objective defines that the TOE shall delete information as soon as it is not longer used. Assuming that a TOE follows this requirement an attacker can not read out any residual information as it is simply not existing. 4.3.2.8 T.ResidentData The threat T.ResidentData is directly and completely covered by the access control policy as defined by O.Access.

4.3.3 Coverage of organisational security policies
The following sections provide more detailed information about how the security objectives for the environment and the TOE cover the organizational security policies.

4.3.3.1 OSP.SM The Organizational Security Policy OSP.SM that mandates that the TOE utilizes the services of a certified Security Module is directly addressed by the security objectives OE.SM and O.Crypt. The objective addresses the same functions that the Security Module shall be utilized for as defined in OSP. SM and also requires a certified Security Module. O.Crypt defines the cryptographic requirements for the TOE itself. In this context it has to be ensured that the Security Module is operated in accordance with its guidance documentation. 4.3.3.2 OSP.Log The Organizational Security Policy OSP.Log that mandates that the TOE maintains an audit log is directly addressed by the security objective for the TOE O.Log.

103

34

Federal Office for Information Security

104 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 4.3.4 Coverage of assumptions

Gateway PP Version 0.9.2

The following sections provide more detailed information about how the security objectives for the environment cover the assumptions.

4.3.4.1 A.ExternalPrivacy The assumption A.ExternalPrivacy is directly and completely covered by the security objective OE.ExternalPrivacy. The assumption and the objective for the environment are drafted in a way that the correspondence is obvious. 4.3.4.2 A.TrustedAdmins The assumption A.TrustedAdmins is directly and completely covered by the security objective OE.TrustedAdmins. The assumption and the objective for the environment are drafted in a way that the correspondence is obvious. 4.3.4.3 A.PhysicalProtection The assumption A.PhysicalProtection is directly and completely covered by the security objective OE.PhysicalProtection. The assumption and the objective for the environment are drafted in a way that the correspondence is obvious. 4.3.4.4 A.AccessProfile The assumption A.AccessProfile is directly and completely covered by the security objective OE.Profile. The assumption and the objective for the environment are drafted in a way that the correspondence is obvious. 4.3.4.5 A.Udpate The assumption A.Update is directly and completely covered by the security objective OE.Update. The assumption and the objective for the environment are drafted in a way that the correspondence is obvious. 4.3.4.6 A.WAN The assumption A.WAN is directly and completely covered by the security objective OE.WAN. The assumption and the objective for the environment are drafted in a way that the correspondence is obvious.

105

Federal Office for Information Security

35

106

Gateway PP Version 0.9.2

607 608 609 610 611 612

5. Extended Component definition
The additional family FPR_CON (Concealed communication) of the Class FPR (Privacy) is defined here to describe the IT security functional requirements of the TOE. The TOE shall prevent attacks against PII of the consumer that may be obtained by an attacker by observing the encrypted communication of the TOE with remote entities.

5.1.1 FPR_CON.1: Communication Concealing

613 614 615 616 617 618 619

5.1.2 Family behaviour: FPR_CON
This family defines requirements to mitigate attacks against communication channels in which an attacker tries to obtain privacy relevant information based on characteristics of an encrypted communication channel. Examples include but are not limited to an analysis of the frequency of communication or the transmitted workload.

5.1.3 Component Levelling:

FPR_CON: Communication Concealing

1

620 621 622 623 624 625 626 627 5.1.4 Management
The following actions could be considered for the management functions in FMT: a) Definition of the interval in FAU_CON.1.2 if definable within the operational phase of the TOE

5.1.5 Audit
There are no auditable events foreseen.

5.1.6 FPR_CON.1: Communication Concealing
FPR_CON.1 FPR_CON.1.1 Communication Concealing The TSF shall enforce the [assignment: Information flow policy] in order to ensure that no PII can be obtained by an analysis of [assignment: characteristics of the information flow that need to be concealed]. 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. No other components No dependencies

FAU_CON.1.2

Hierarchical to: Dependencies:

107

36

Federal Office for Information Security

108

Gateway PP Version 0.9.2

628 629 630 631 632 633 634 635 636 637 638 639 640 641 642

6. Security Requirements
This chapter describes the security functional and the assurance requirements which have to be fulfilled by the TOE. Those requirements comprise functional components from part 2 of [CC] and the assurance components as defined for the Evaluation Assurance Level 2 part 3 of [CC]. The following notations are used: Refinement operation (denoted by bold text): is used to add details to a requirement, and thus further restricts a requirement. ● Selection operation (denoted by underlined text): is used to select one or more options provided by the [CC] in stating a requirement. ● Assignment operation (denoted by italicised text): is used to assign a specific value to an unspecified parameter, such as the length of a password. Showing the value in square brackets indicates assignment. ● Iteration operation: are identified with a suffix in the name of the SFR (e.g. FDP_IFC/FW.2) The following table summarises all TOE functional requirements of this PP:


Class FAU: Security Audit FAU_ARP/SYS.1 FAU_GEN/SYS.1 FAU_GEN/CON.1 FAU_GEN.2 FAU_SAA/SYS.1 FAR_SAR/SYS.1 FAR_SAR/CON.1 FAU_STG.1 FAU_STG.2 FAU_STG.4 Security alarms for system log Audit data generation for system log Audit data generation for consumer log User identity association Potential violation analysis for system log Audit review for system log Audit review for consumer log Protected audit trail storage for system log Guarantees of audit data availability for consumer log Prevention of audit data loss for the system log Class FCO: Communication FCO_NRO.2 Enforced proof of origin Class FCS: Cryptographic Support FCS_CKM.1 FCS_CKM.4 FCS_COP.1 FCS_COP/HASH.1 Cryptographic key generation Cryptographic key destruction Cryptographic operation Cryptographic operation for Signatures Class FDP: User Data Protection FDP_ACC.2 Complete Access Control

109

Federal Office for Information Security

37

110

Gateway PP Version 0.9.2

FDP_ACF.1 FDP_IFC/FW.2 FDP_IFC/MTR.2 FDP_IFF/FW.1 FDP_IFF/MTR.1 FDP_RIP.2 FDP_SDI.2

Security attribute based access control Complete information flow control for firewall Complete information flow control for Meter information flow Simple security attributes for Firewall Simple security attributes for Meter information Full residual information protection Stored data integrity monitoring and action Class FIA: Identification and Authentication

FIA_ATD. FIA_UID.2 FIA_USB.1

User attribute definition User identification before any action User-subject binding Class FMT: Security Management

FMT_MSA/FW.1 FMT_MSA/MTR.1 FMT_MSA/FW.3 FMT_MSA/MTR.3 FMT_SMF.1 FMT_SMR.1

Management of security attributes for firewall policy Management of security attributes for Meter policy Static attribute initialisation for Firewall policy Static attribute initialisation for Meter policy Specification of Management Functions Security roles Class FPR: Privacy

FPR_CON.1 FPR_PSE.1

Communication Concealing Pseudonymity Class FPT: Protection of the TSF

FPT_FLS.1 FPT_STM.1 FPT_TST.1 FPT_PHP.1

Failure with preservation of secure state Reliable time stamps TSF testing Passive detection of physical attack Class FTP: Trusted path/channels

FTP_ITC/WAN.1 FTP_ITC/MTR.1
643

Inter-TSF trusted channel for WAN Inter-TSF trusted channel for Meter
Table 6: List of Security Functional Requirements

111

38

Federal Office for Information Security

112 644

Gateway PP Version 0.9.2

6.1 Class FAU: Security Audit
6.1.1 Security audit automatic response (FAU_ARP)
6.1.1.1 FAU_ARP/SYS.1 FAU_ARP/SYS.1 Hierarchical to: Dependencies: The TSF shall take [inform an authorized administrator and [assignment: list of actions]] upon detection of a potential security violation. No other components FAU_SAA.1 Potential violation analysis

645 646

647 648 649 6.1.2 Security audit data generation (FAU_GEN)
6.1.2.1 FAU_GEN/SYS.1: Audit data generation for system log FAU_GEN/SYS.1.1 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 events as listed in Table 7 and [assignment: other specifically defined auditable events]]. 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, [information as defined in Table 7]. No other components FPT_STM.1

FAU_GEN/SYS.1.2

Hierarchical to: Dependencies:

650 651

113

Federal Office for Information Security

39

114

Gateway PP Version 0.9.2

SFR FAU_ARP/SYS.1 FAU_SAA/SYS.1
? ? ?

Event Actions taken violations. due to potential security

Additional Information

Enabling and disabling of any of the analysis mechanisms; Automated responses performed by the tool. Reading of information from the audit records. Reading of information from the audit records. Actions taken due to the audit storage failure. The invocation of the non-repudiation service. All requests to perform an operation on an object covered by the SFP.
All decisions on requests for information flow. The specific security attributes used in making an information flow enforcement decision. All decisions on requests for information flow. The specific security attributes used in making an information flow enforcement decision. The decision taken by the access control mechanism

FAR_SAR/SYS.1 FAR_SAR/CON.1 FAU_STG.4 FCO_NRO.2 FDP_ACF.1

? ? ? ? ?

FDP_IFF/FW.1

? ?

FDP_IFF/MTR.1

? ?

FIA_UID.2

?

All use of the user identification mechanism, including the user identity provided.
Success and failure of binding of user security attributes to a subject (e.g. success or failure to create a subject).

FIA_USB.1

?

FMT_MSA/AC.1 FMT_MSA/FW.1 FMT_MSA/MTR.1 FMT_SMF.1 FMT_SMR.1 FPT_FLS.1 FPT_STM.1 FPT_TST.1

? ? ? ? ? ? ? ?

All modifications of the values of security attributes. All modifications of the values of security attributes. All modifications of the values of security attributes. Use of the management functions.
modifications to the group of users that are part of a role; Failure of the TSF.

The old and the new value The old and the new value The old and the new value

changes to the time
Execution of the TSF self tests and the results of

115

40

Federal Office for Information Security

116

Gateway PP Version 0.9.2

the tests.
652

Table 7: Events for system log

653 654
6.1.2.2 FAU_GEN.1: Audit data generation for consumer log FAU_GEN/CON.1.1 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 8]. 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 listed in table Table 8]. No other components FPT_STM.1

FAU_GEN/CON.1.2

Hierarchical to: Dependencies:

655
Event Any change to an access control profile Additional Information The new and the old value of the profile

Any submission of Meter Data to an external entity The access control profile that lead to the submission The submitted values

656 657

Table 8: Events for consumer log

Editors Note:

The events for the consumer log are still under discussion with representatives of BfDI and will be updated in future version of this PP.

658 659
6.1.2.3 FAU_GEN.2: User identity association 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. No other components FAU_GEN.1 FIA_UID.1

Hierarchical to: Dependencies:

660

117

Federal Office for Information Security

41

118

Gateway PP Version 0.9.2

Application Note:

Please note that FAR_GEN.2 applies to both audit logs. The system log as well as the consumer log.

661 662

6.1.3 Security audit analysis (FAU_SAA)
6.1.3.1 FAU_SAA/SYS.1: Potential violation analysis for system log FAU_SAA/SYS.1.1 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. 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]. No other components FAU_GEN.1 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 concrete implementation and application case of the TOE. As such the authors of the ST will have to complete the operations in FAU_SAA/SYS.1,

FAU_SAA/SYS.1.2

Hierarchical to: Dependencies:

663
Application Note

664 665

6.1.4 Security audit event storage (FAU_STG)
6.1.4.1 FAU_SAR/SYS.1: Audit Review for system log FAU_SAR/SYS.1.1 FAU_SAR/SYS.1.2 Hierarchical to: Dependencies: The TSF shall provide [ only authorized administrators] with the capability to read [all information from the system log] from the system audit records. The TSF shall provide the audit records in a manner suitable for the user to interpret the information. No other components FAU_GEN.1 FIA_UID.1

666

119

42

Federal Office for Information Security

120 667
6.1.4.2 FAU_SAR/CON.1: Audit Review for consumer log FAU_SAR/CON.1.1

Gateway PP Version 0.9.2

The TSF shall provide [only authorised consumer] with the capability to read [the information that are related to their consumption] from the consumer audit records. The TSF shall provide the audit records in a manner suitable for the user to interpret the information. No other components FAU_GEN.1 FIA_UID.1 FAU_SAR/CON.1.2 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.

FAU_SAR/CON.1.2 Hierarchical to: Dependencies:

668
Application Note:

669 670
6.1.4.3 FAU_STG.1: Protected audit trail storage for system log FAU_STG.1.1 FAU_STG.1.2 Hierarchical to: Dependencies: The TSF shall protect the stored audit records in the system audit trail from unauthorised deletion. The TSF shall be able to [prevent] unauthorised modifications to the stored audit records in the system audit trail. No other components FAU_GEN.1

671

6.1.4.4 FAU_STG.2: Guarantees of audit data availability for the consumer log FAU_STG.2.1 FAU_STG.2.2 FAU_STG.2.3 The TSF shall protect the stored audit records in the consumer audit trail from unauthorised deletion. The TSF shall be able to [prevent] unauthorised modifications to the stored audit records in the consumer audit trail. The TSF shall ensure that [a sufficient amount of16 ] stored consumer audit records will be maintained when the following conditions occur: [audit storage exhaustion or failure] FAU_STG.1 Protected audit trail storage FAU_GEN.1 Audit data generation

Hierarchical to: Dependencies:

672

121 122

16

Please refer to the following application note for a more detailed definition of “sufficient”

Federal Office for Information Security

43

123

Gateway PP Version 0.9.2

Application Note

The audit log for the consumer is an essential aspect in the context of the privacy preservation for the consumer. While it may be possible that the TOE deletes old audit records from this log after the review and approval of the consumer or after a specific period of time the audit trail shall ensure that it always contains a sufficient amount of information for the user.

673

6.1.4.5 FAU_STG.4: Prevention of audit data loss for system log FAU_STG.4.1 The TSF shall [selection, choose one of: “ignore audited events”, “prevent audited events, except those taken by the authorised user with special rights”, “overwrite the oldest stored audit records”] and [assignment: other actions to be taken in case of audit storage failure] if the system audit trail is full. FAU_STG.3 Action in case of possible audit data loss FAU_STG.1 Protected audit trail storage While this PP defines concrete requirements around the prevention of audit data loss for the consumer log (see FAU_STG.2) it is left to the ST author to fulfils the assignments in FAU_STG.4.1 in a suitable manner. Please note that the requirements in FAU_STG.4 only apply to the system log.

Hierarchical to: Dependencies:

674
Application Note

675 676

6.2 Class FCO: Communication
6.2.1 Non-repudiation of origin (FCO_NRO)

677 678

6.2.1.1 FCO_NRO.2: Enforced proof of origin FCO_NRO.2.1 FCO_NRO.2.2 The TSF shall enforce the generation of evidence of origin for transmitted [Meter Data] at all times. The TSF shall be able to relate the [key material used for signature] of the originator of the information, and the [signature] of the information to which the evidence applies. 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-2102]. FCO_NRO.1 Selective proof of origin FIA_UID.1 Timing of identification The requirement in FCO_NRO.2 requires that the TOE enforces that a signature is calculated over Meter Data that is submitted to external parties.

FCO_NRO.2.3

Hierarchical to: Dependencies: Application Note

124

44

Federal Office for Information Security

125

Gateway PP Version 0.9.2

To do so a hash value has to be created by the TOE over the Data To Be Signed (DTBS) as defined in FCS_COP/HASH.1. The creation of the actual signature however is performed by the security module.

679

6.3 Class FCS: Cryptographic Support
6.3.1 Cryptographic key management (FCS_CKM)
6.3.1.1 FCS_CKM.1: Cryptographic key generation FCS_CKM.1.1 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: [BSI TR-2102]. No other components. [FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryptographic operation] FCS_CKM.4 Cryptographic key destruction

680 681

Hierarchical to: Dependencies:

682

6.3.1.2 Application Note: The functionality required by FCS_CKM.1 will in any case be used to generate the ephemeral keys used for encryption and decryption on the WAN side. In cases where a Gateway also needs to provide encryption functionality for Meter(s) the required keys may also be covered by this requirement. If useful the ST author is encouraged to iterate this requirement in those cases. It shall be noted that the key generation relies on functionality of the certified Security Module used by the TOE. Specifically for the required random numbers and the asymmetric cryptographic algorithms involved in key generation the TOE utilizes the services of the Security Module.

683

6.3.1.3 FCS_CKM.4: Cryptographic key destruction 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]. No other components. [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] 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.

Hierarchical to: Dependencies:

Application Note

126

Federal Office for Information Security

45

127 684 685

Gateway PP Version 0.9.2

6.3.1.4 FCS_COP.1: Cryptographic operation FCS_COP.1.1 The TSF shall perform [encryption and decryption] in accordance with a specified cryptographic algorithm [assignment: cryptographic algorithm] and cryptographic key sizes [assignment: cryptographic key sizes] that meet the following: [BSI TR-2102]. No other components. [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

Hierarchical to: Dependencies:

686
Application Note The functionality required by FCS_COP.1 will in any case be used to encrypt/decrypt the traffic the WAN side. In cases where a Gateway also needs to provide encryption functionality for Meter(s) the required functionality may also be covered by this requirement. If useful the ST author is encouraged to iterate this requirement in those cases.

687 688
6.3.1.5 FCS_COP/HASH.1: Cryptographic operation, hashing for signatures FCS_COP.1.1 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: [BSI-TR-2102]. No other components. [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

Hierarchical to: Dependencies:

689

6.4 Class FDP: User Data Protection
6.4.1 Access control policy (FDP_ACC)
6.4.1.1 FDP_ACC.2: Complete access control FDP_ACC.2 .1 The TSF shall enforce the [Gateway access SFP] on [ ? subjects: ? all external entities17

690 691

128

46

Federal Office for Information Security

129

Gateway PP Version 0.9.2

objects: ? Consumption Data ? Status Data ? secondary assets (including time, access control profiles and Meter configuration data) ? any data received by an external entity ] 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. FDP_ACC.1 Subset access control FDP_ACF.1 Security attribute based access control

Hierarchical to: Dependencies:

692

6.4.1.2 Security attribute based access control FDP_ACF.1.1 The TSF shall enforce the [Gateway access SFP] to objects based on the following: [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes]. The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects]. 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]. The TSF shall explicitly deny access of subjects to objects based on the following additional rules: [no subject must be allowed modify Consumption or Status Data]. No other components FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation

FDP_ACF.1.2

FDP_ACF.1.3

FDP_ACF.1.4

Hierarchical to: Dependencies:

693 694 695 6.4.2 Information flow control policy (FDP_IFC)
6.4.2.1 FDP_IFC/FW.2: Complete information flow control for firewall FDP_IFC.2 .1 The TSF shall enforce the [Firewall SFP] on [the TOE, external entities on the WAN side, external entities on the MAN side and all information flowing between them] and all operations that cause that information to flow to and from subjects covered by the SFP.

130 131

17

Or strictly speaking: The subjects acting on behalf of those entities

Federal Office for Information Security

47

132

Gateway PP Version 0.9.2

FDP_IFC.2.2

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. FDP_IFC.1 Subset information flow control FDP_IFF.1 Simple security attributes

Hierarchical to: Dependencies:

696

6.4.2.2 FDP_IFC/MTR.2: Complete information flow control for Meter information flow FDP_IFC.2 .1 The TSF shall enforce the [Meter SFP] on [the TOE, attached Meters and all information flowing between them] and all operations that cause that information to flow to and from subjects covered by the SFP. 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. FDP_IFC.1 Subset information flow control FDP_IFF.1 Simple security attributes

FDP_IFC.2.2

Hierarchical to: Dependencies:

697 698

6.4.3 Information flow control functions (FDP_IFF)
6.4.3.1 FDP_IFF/FW.1: Simple security attributes for Firewall FDP_IFF/FW.1.1 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 or MAN side information: any information that is sent via the TOE attributes: destination interface, source interface (MAN or WAN), access control profile]. The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold: [ ? the information flow shall only be permitted if allowed by the corresponding access control profile ? any information flow may only be initiated from a MAN side interface ]. The TSF shall enforce the [assignment: additional information flow control SFP rules]. The TSF shall explicitly authorise an information flow based on the following rules: [assignment: rules, based on security attributes, that explicitly authorise information flows]. The TSF shall explicitly deny an information flow based on the following rules: [ ? any request for information flow18 from the WAN source interface

FDP_IFF/FW.1.2

FDP_IFF/FW.1.3 FDP_IFF/FW.1.4

FDP_IFF/FW.1.5

133 134

18

This refers to the request to initiate a connection.

48

Federal Office for Information Security

135

Gateway PP Version 0.9.2

shall be dropped]. Hierarchical to: Dependencies: No other components FDP_IFC.1 Subset information flow control FMT_MSA.3 Static attribute initialisation It should be noted that the fact that FDP_IFF/FW.1.1 facilitates different interfaces of the origin and the destination of an information flow implicitly requires the TOE to implement physically separate port for WAN, MAN and HAN.

699
Application Note

700 701
6.4.3.2 FDP_IFF/MTR.1: Simple security attributes for Meter information FDP_IFF/MTR.1.1 The TSF shall enforce the [assignment: information flow control SFP] based on the following types of subject and information security attributes: [ subjects: The TOE and external entities on the WAN or MAN side information: any information that is sent via the TOE attributes: destination interface, source interface (MAN or WAN), access control profile ]. The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold: [ ? the information flow shall only be initiated if allowed by the corresponding access control profile ]. The TSF shall enforce the [following rules ? Data received from Meters shall be processed as defined in the corresponding access control profiles, ? The internal system time shall be synchronized as follows ? The TOE shall compare the system time to a reliable external time source at least every 24 hours ? If the deviation between the local time and the remote time is acceptable19 the local system time shall be updated according to the remote time ? If the deviation is not acceptable the TOE shall stop operation and inform an administrator ]. The TSF shall explicitly authorise an information flow based on the following rules: [assignment: rules, based on security attributes, that explicitly authorise information flows]. 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

FDP_IFF/MTR.1.2

FDP_IFF/MTR.1.3

FDP_IFF/MTR.1.4

FDP_IFF/MTR.1.5

136 137

19

Please refer to the following application note for a detailed definition of “acceptable”

Federal Office for Information Security

49

138

Gateway PP Version 0.9.2

MAN that are not within the physical scope of the TOE unless the data has been signed and received via an encrypted channel]. Hierarchical to: Dependencies: No other components FDP_IFC.1 Subset information flow control FMT_MSA.3 Static attribute initialisation 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 PTB would be a good example for such a source20). 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 The question whether a deviation between the remote time sources and the local system time is still acceptable the regulations from [PTB_A50.7] shall be considered. Those regulations require that the maximum deviations of the local time does not exceed 3% of the measuring period.

702
Application Note

703 704

6.4.4 Residual information protection (FDP_RIP)
6.4.4.1 FDP_RIP.2: Full residual information protection FDP_RIP.2.1 Hierarchical to: Dependencies: The TSF shall ensure that any previous information content of a resource is made unavailable upon the [deallocation of the resource from] all objects. FDP_RIP.1 Subset residual information protection No dependencies. Please refer to chapter F.9 of part II of [CC] for more detailed information about what kind of information this objective applies to. Please further note that this SFR has been used in order to ensure that information that is not longer used is made unavailable from a logical perspective. Specifically, it has to be ensured that this information is not 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.

705
Application Note

706

139 140

20

By the time that this PP is developed however, this time source is not yet available

50

Federal Office for Information Security

141 707 708 6.4.5 Stored data integrity (FDP_SDI)
6.4.5.1 FDP_SDI.2: Stored data integrity monitoring and action FDP_SDI.2.1

Gateway PP Version 0.9.2

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]. Upon detection of a data integrity error, the TSF shall [assignment: action to be taken]. FDP_SDI.1 Stored data integrity monitoring No dependencies. This Protection Profile defines that the TOE shall be capable of detecting integrity errors on all objects. However, the definition of the concrete attributes (e.g. hash values) that are used to implement this functionality are left to the ST author.

FDP_SDI.2.2 Hierarchical to: Dependencies:

709
Application Note

710

6.5 Class FIA: Identification and Authentication
6.5.1 User Attribute Definition (FIA_ATD)
6.5.1.1 FIA_ATD.1: User attribute definition 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 or MAN) ? Role membership ? [assignment: list of security attributes or none]]. No other components No dependencies.

711 712

Hierarchical to: Dependencies:

713 714

6.5.2 User identification (FIA_UID)
6.5.2.1 FIA_UID.2: User identification before any action FIA_UID.2.1 Hierarchical to: Dependencies: The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. FIA_UID.1 No dependencies.

142

Federal Office for Information Security

51

143 715 716 717

Gateway PP Version 0.9.2

6.5.3 User-subject binding (FIA_USB)
6.5.3.1 FIA_USB.1: User-subject binding FIA_USB.1.1 FIA_USB.1.2 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]. 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]. 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]. No other components FIA_ATD.1 User attribute definition

FIA_USB.1.3

Hierarchical to: Dependencies:

718

6.6 Class FMT: Security Management
6.6.1 Management of security attributes (FMT_MSA)
6.6.1.1 FMT_MSA/AC.1: Management of security attributes for Gateway access SFP FMT_MSA.1.1 The TSF shall enforce the [Gateway access SFP] to restrict the ability to [ change_default, query, modify, delete, [assignment: other operations]] the security attributes [all relevant security attributes] to [authorized administrators]. No other components [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

719 720

Hierarchical to: Dependencies:

721 722
6.6.1.2 FMT_MSA/FW.1: Management of security attributes for firewall policy FMT_MSA.1.1 The TSF shall enforce the [Firewall SFP] to restrict the ability to [ change_default, query, modify, delete, [assignment: other operations]] the security attributes [all relevant security attributes] to [authorized administrators]. No other components [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control]

Hierarchical to: Dependencies:

144

52

Federal Office for Information Security

145

Gateway PP Version 0.9.2

FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions

723

6.6.1.3 FMT_MSA/MTR.1: Management of security attributes for Meter policy FMT_MSA.1.1 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 [authorized administrators]. No other components [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

Hierarchical to: Dependencies:

724

6.6.1.4 FMT_MSA/AC.3: Static attribute initialisation for Gateway access SFP FMT_MSA.3.1 FMT_MSA.3.2 Hierarchical to: Dependencies: The TSF shall enforce the [Gateway access SFP] to provide [restrictive] default values for security attributes that are used to enforce the SFP. The TSF shall allow the [no role] to specify alternative initial values to override the default values when an object or information is created. No other components FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles

725 726
6.6.1.5 FMT_MSA/FW.3: Static attribute initialisation for Firewall policy FMT_MSA.3.1 FMT_MSA.3.2 Hierarchical to: Dependencies: The TSF shall enforce the [firewall] to provide [restrictive] default values for security attributes that are used to enforce the SFP. The TSF shall allow the [no role] to specify alternative initial values to override the default values when an object or information is created. No other components FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles The definition of restrictive default rules for the firewall information flow policy refers to the rules as defined in FDP_IFF/FW.1.2 and FDP_IFF/FW.1.5. Those rules apply to all information flows and must not be overwritable by anybody.

727
Application Note

728

6.6.1.6 FMT_MSA/MTR.3: Static attribute initialisation for Meter policy FMT_MSA.3.1 The TSF shall enforce the [Meter SFP] to provide [restrictive] default values for security attributes that are used to enforce the SFP.

146

Federal Office for Information Security

53

147

Gateway PP Version 0.9.2

FMT_MSA.3.2 Hierarchical to: Dependencies:

The TSF shall allow the [no role] to specify alternative initial values to override the default values when an object or information is created. No other components FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles

729 730
Application Note The definition of restrictive default rules for the firewall information flow policy refers to the rules as defined in FDP_IFF/MTR.1.2 and FDP_IFF/MTR.1.5. Those rules apply to all information flows and must not be overwritable by anybody.

731 732

6.6.2 Specification of Management Functions (FMT_SMF)
6.6.2.1 FMT_SMF.1: Specification of Management Functions FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: [list of management functions as defined in Table 9 and [assignment: additional functionalites]]. No other components No dependencies mgt the management (addition, removal, or modification) of actions. maintenance of the rules by (adding, modifying, deletion) of rules from the set of rules.

Hierarchical to: Dependencies:

733
SFR FAU_ARP/SYS.1 FAU_SAA/SYS.1 FAR_SAR/CON.1 FAU_STG.4 FCO_NRO.2: FDP_ACF.1 FDP_IFF/FW.1 FDP_IFF/MTR.1 FDP_SDI.2 FIA_ATD.1

maintenance (deletion, modification, addition) of the group of users with read access right to the audit records. maintenance (deletion, modification, addition) of actions to be taken in case of audit storage failure. The management of changes to information types, fields, originator attributes and recipients of evidence. Managing the attributes used to make explicit access or denial based decisions. Managing the attributes used to make explicit access based decisions. Add authorized units for communication (pairing) Managing the attributes (including access control profiles) used to make explicit access based decisions.
The actions to be taken upon the detection of an integrity error could be configurable.

if so indicated in the assignment, the authorised administrator might be able

148

54

Federal Office for Information Security

149
to define additional security attributes for users.
FIA_UID.2 FIA_USB.1

Gateway PP Version 0.9.2

the management of the user identities. an authorised administrator can define default subject security attributes.
? ?

an authorised administrator can change subject security attributes.

FMT_MSA/AC.1 FMT_MSA/FW.1

managing the group of roles that can interact with the security attributes; b) management of rules by which security attributes inherit specified values. managing the group of roles that can interact with the security attributes; b) management of rules by which security attributes inherit specified values.

FMT_MSA/MTR.1 managing the group of roles that can interact with the security attributes; b) management of rules by which security attributes inherit specified values. FMT_SMR.1 FPT_STM.1 FPT_TST.1 managing the group of users that are part of a role. a) management of the time. management of the conditions under which TSF self testing occurs, such as during initial start-up, regular interval, or under specified conditions; b) management of the time interval if appropriate. a) management of the user or role that determines whether physical tampering has occurred.

FPT_PHP.1

734 735 736 737

Table 9: Management Functionalities

6.6.3 Security management roles (FMT_SMR)
6.6.3.1 FMT_SMR.1: Security roles FMT_SMR.1.1 The TSF shall maintain the roles [ authorized user authorized administrator [assignment: the authorised identified roles]]. The TSF shall be able to associate users with roles. No other components No dependencies. The roles “authorized administrator” and “authorized user” 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.

FMT_SMR.1.2 Hierarchical to: Dependencies:

738
Application Note

150

Federal Office for Information Security

55

151

Gateway PP Version 0.9.2

It should be noted that the role “authorized administrator” is not limited to an administrator who has either or remote access but may include both.

739 740

6.7 Class FPR: Privacy
6.7.1 Communication Concealing (FPR_CON)
6.7.1.1 FPR_CON.1: Communication Concealing FPR_CON.1.1 The TSF shall enforce the [Firewall SFP] in order to ensure that no PII can be obtained by an analysis of [assignment: characteristics of the information flow that need to be concealed]. 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. No other components No dependencies The interval and the list of external entities that shall be used in FPR_CON.1.2 highly depends on the concrete application case. Therefore, the assignments in FPR_CON.1.2 are left to the ST author.

741 742

FPR_CON.1.2

Hierarchical to: Dependencies:

743
Application Note

744 745 746 747
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 not relevant for billing sent to parties in the WAN]. The TSF shall be able to provide [one] alias per Meter of the Meter identity to [external parties in the WAN ]. The TSF shall [ determine an alias for a user ] and verify that it conforms to the [assignment: alias metric]. No other components No dependencies.

6.8 Pseudonymity (FPR_PSE)
6.8.1.1 FPR_PSE.1 Pseudonymity

FPR_PSE.1.2 FPR_PSE.1.3 Hierarchical to: Dependencies:

748 749
Application Note: When the TOE submits information about the consumption of a certain

152

56

Federal Office for Information Security

153

Gateway PP Version 0.9.2

commodity that are not relevant for the billing process, there is no need that those information are send with a direct link to the identity of the user. In those cases the TOE shall replace the identity of the consumer by a pseudonymous identifier. Please note that the identity of the user may not be their name but could also be a number used for billing purposes. A Gateway may use more than one pseudonymous identifiers. A complete anonymization 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.

750

751

6.9 Class FPT: Protection of the TSF
6.9.1 Fail secure (FPT_FLS)
6.9.1.1 FPT_FLS.1: Failure with preservation of secure state FPT_FLS.1.1 Hierarchical to: Dependencies: The TSF shall preserve a secure state when the following types of failures occur: [assignment: list of types of failures in the TSF]. No other components No dependencies.

752 753

754 755 756 6.9.2 Time stamps (FPT_STM)
6.9.2.1 FPT_STM.1: Reliable time stamps FPT_STM.1.1 Hierarchical to: Dependencies: The TSF shall be able to provide reliable time stamps. No other components No dependencies. The time stamps as defined by FPT_STM.1 shall be of sufficient exactness. Therefore, the local system time of the TOE is synchronized regularly with a reliable external time source. However, the local clock also needs a sufficient exactness as the synchronisation will fail if the deviation is too large. Therefore the local clock shall be as exact as required by [PTB_A50.7].

757
Application Note:

154

Federal Office for Information Security

57

155 758 759

Gateway PP Version 0.9.2

6.9.3 TSF self test (FPT_TST)
6.9.3.1 FPT_TST.1: TSF testing 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]. The TSF shall provide authorised users with the capability to verify the integrity of [TSF data]. The TSF shall provide authorised users with the capability to verify the integrity of [TSF]. No other components No dependencies. The self test suite as defined in FPT_TST.1 shall also contain a test that tries to detect 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 failed.

FPT_TST.1.2 FPT_TST.1.3 Hierarchical to: Dependencies:

760
Application Note

156

58

Federal Office for Information Security

157

Gateway PP Version 0.9.2

761

6.9.3.2 FPT_PHP.1: Passive detection of physical attack FPT_PHP.1.1 FPT_PHP.1.1 Hierarchical to: Dependencies: The TSF shall provide unambiguous detection of physical tampering that might compromise the TSF. The TSF shall provide the capability to determine whether physical tampering with the TSF's devices or TSF's elements has occurred. No other components No dependencies. 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 [PTB_A50.7].

762
Application Note

763

Class FTP: Trusted path/channels
6.9.4 Inter-TSF trusted channel (FTP_ITC)
6.9.4.1 FTP_ITC/WAN.1: Inter-TSF trusted channel for WAN FTP_ITC.1.1 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. The TSF shall permit [the TSF] to initiate communication via the trusted channel. The TSF shall initiate communication via the trusted channel for [all communications to external entities in the WAN]. No other components No dependencies.

764 765

FTP_ITC.1.2 FTP_ITC.1.3 Hierarchical to: Dependencies:

766 767
6.9.4.2 FTP_ITC/MTR.1: Inter-TSF trusted channel for Meter FTP_ITC.1.1 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. The TSF shall permit [selection: the Meter or the TOE] to initiate communication via the trusted channel.

FTP_ITC.1.2

158

Federal Office for Information Security

59

159

Gateway PP Version 0.9.2

FTP_ITC.1.3 Hierarchical to: Dependencies:

The TSF shall initiate communication via the trusted channel for [any communication between a Meter and the TOE]. No other components No dependencies.

768 769
Application Note: It should be noted that the requirement of an Inter-TSF for Meter Data may be also be fulfilled by physical means. The classical example is an implementation in which the Meter and the Gateway are implemented within one physical device. Please also refer to chapter 1.4.5.2..

160

60

Federal Office for Information Security

161

Gateway PP Version 0.9.2

770 771 772 773 774

6.10 Security Assurance Requirements for the TOE
The minimum Evaluation Assurance Level for this Protection Profile is EAL 4 augmented by AVA_VAN.5 and ALC_FLR.2. The following table lists the assurance components which are therefore applicable to this PP.
Assurance Class Development Assurance Component ADV_ARC.1 ADV_FSP.4 ADV_IMP.1 ADV_TDS.3 Guidance documents AGD_OPE.1 AGD_PRE.1 Life-cycle support ALC_CMC.4 ALC_CMS.4 ALC_DEL.1 ALC_DVS.1 ALC_LCD.1 ALC_TAT.1 ALC_FLR.2 Security Target Evaluation ASE_CCL.1 ASE_ECD.1 ASE_INT.1 ASE_OBJ.2 ASE_REQ.2 ASE_SPD.1 ASE_TSS.1 Tests ATE_COV.2 ATE_DPT.1 ATE_FUN.1 ATE_IND.2 Vulnerability Assessment AVA_VAN.5 Table 10: Assurance Requirements

775

162

Federal Office for Information Security

61

163 776 777

Gateway PP Version 0.9.2

6.11 Security Requirements rationale
6.11.1 Security Functional Requirements rationale
6.11.1.1 Fulfilment of the Security Objectives This chapter proves that the set of security requirements (TOE) is suited to fulfil the security objectives described in chapter 4 and that each SFR can be traced back to the security objectives. At least one security objective exists for each security requirement.

778 779 780 781 782 783

O.Firewall

O.SeparateIF

O.Conceal

O.Meter

O.CRYPT

O.Time

O.Protect

O.Management

O.Log X X X X X X X X X X

O.Access

FAU_ARP/SYS.1 FAU_GEN/SYS.1 FAU_GEN/CON.1 FAU_GEN.2 FAU_SAA/SYS.1 FAU_SAR/SYS.1 FAU_SAR/CON.1 FAU_STG.1 FAU_STG.2 FAU_STG.4 FCO_NRO.2 FCS_CKM.1 FCS_CKM.4 FCS_COP.1 FCS_COP/HASH.1 FDP_ACC.2 FDP_ACF.1
X X X X X X

X X

164

62

Federal Office for Information Security

165
O.Firewall X O.SeparateIF X X X X X X X X X O.Conceal O.Meter O.CRYPT O.Time O.Protect O.Management

Gateway PP Version 0.9.2

O.Log

O.Access

FDP_IFC/FW.2 FDP_IFC/MTR.2 FDP_IFF/FW.1 FDP_IFF/MTR.1 FDP_RIP.2 FDP_SDI.2 FIA_ATD. FIA_UID.2 FIA_USB.1 FMT_MSA/AC.1
FMT_MSA/FW.1

X X X X X X X X X X X X X X X X X X X X Table 11: Fulfilment of Security Objectives X

FMT_MSA/MTR.1 FMT_MSA/AC.3 FMT_MSA/FW.3 FMT_MSA/MTR.3 FMT_SMF.1 FMT_SMR.1 FPR_CON.1 FPR_PSE.1 FPT_FLS.1 FPT_STM.1 FPT_TST.1 FPT_PHP.1 FTP_ITC/WAN.1 FTP_ITC/MTR.1
784

166

Federal Office for Information Security

63

167 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824

Gateway PP Version 0.9.2

The following paragraphs contain more details on this mapping.

O.Firewall
O.Firewall ist met by a combination of the following SFRs: ? FDP_IFC/FW.2 defines that the TOE shall implement an information flow policy for its firewall functionality. ? FDP_IFF/FW.1 defines the concrete rules for the firewall information flow policy.

O.SeparateIF
O.SeparateIF is met by a combination of the following SFRs: ? FDP_IFC/FW.2 and FDP_IFF/FW.1 implicitly require the TOE to implement physically separate ports for WAN and MAN ? FPT_TST.1 implements a self test that also tries to detect whether the ports for WAN and MAN have been interchanged.

O.Conceal
O.Conceal is completely met by FPR_CON.1 as directly follows.

O.Meter
O.Meter is met by a combination of the following SFRs: ? FDP_IFC/MTR.2 and FDP_IFF/MTR.1 define an information flow policy to introduce how the Gateway shall handle Meter data. ? FCO_NRO.2 ensure that all Meter data will be signed by the Gateway (invoking the services of its security module) before being submitted to external parties. ? FPR_PSE.1 defines requirements around the pseudonymizsation of Meter identities for Status data. ? FTP_ITC/MTR.1 defines the requirements around the Trusted Channel that shall be implemented by the Gateway in order to protect information submitted via the Gateway and external entities in the WAN or the Gateway and a distributed Meter.

O.Crypt
O.Crypt is met by a combination of the following SFRs: ? FCS_CKM.1 defines the requirements around the secure creation of ephemeral cryptographic keys ? FCS_CKM.4 defines the requirements around the secure deletion of ephemeral cryptographic keys ? FCS_COP.1 defines the requirements around the encryption and decryption capabilities of the Gateway for communications with external parties in the WAN and (if not implemented in one physical device) to Meters. ? FCS_COP/HASH.1defines the requirements on hashing that are needed in the context of digital signatures (which are created and verified by the security module)

168

64

Federal Office for Information Security

169 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866

Gateway PP Version 0.9.2

O.Time
O.Time is met by a combination of the following SFRs: ? FDP_IFC/MTR.2 and FDP_IFF/MTR.1 define the required update functionality for the local time as part of the information flow control policy for handling Meter data. ? FPT_STM.1 defines that the TOE shall be able to provide reliable time stamps.

O.Protect
O.Protect is met by a combination of the following SFRs: ? FDP_RIP.2 defines that the TOE shall make information unavailable as soon as it is not longer needed. ? FDP_SDI.2 defines requirements around the integrity protection for stored data. ? FPT_FLS.1 defines requirements that the TOE falls back to a safe state for specific error cases. ? FPT_TST.1 defines the self testing functionality. ? FPT_PHP.1 defines the exact requirements around the physical protection that the TOE has to provide.

O.Management
O.Management is met by a combination of the following SFRs: ? FIA_ATD.1 defines the attributes for users. ? FIA_UID.2 defines requirements around the identification of users. ? FIA_USB.1 defines that the TOE must be able to associate users with subjects acting on behalf of them. ? FMT_MSA/AC.1 defines requirements around the limitations for management of attributes used for the Gateway access SFP ? FMT_MSA/FW.1 defines requirements around the limitations for management of attributes used for the Firewall SFP ? FMT_MSA/MTR.1 defines requirements around the limitations for management of attributes used for the Meter SFP ? FMT_MSA/AC.3defines the default values for the Gateway access SFP. ? FMT_MSA/FW.3 defines the default values for the Firewall SFP. ? FMT_MSA/MTR.3 defines the default values for the Meter SFP. ? FMT_SMF.1 defines the management functionalities that the TOE must offer. ? FMT_SMR.1 defines the role concept for the TOE.

O.Log
O.Log is met by a combination of the following SFRs: ? FAU_ARP/SYS.1 defines requirements around an automated answer to certain accumulations in the system log. ? FAU_GEN/SYS.1 defines the requirements around the system log ? FAU_GEN/CON.1 defines the requirements around the consumer log ? FAU_SAA/SYS.1 defines the rules for the automated analysis of the system audit log. ? FAU_SAR/SYS.1 defines requirements on providing review capabilities for the system log

170

Federal Office for Information Security

65

171 867 868 869 870 871 872 873 874 875 876 877 878

Gateway PP Version 0.9.2 FAU_SAR/CON.1 defines requirements on providing review capabilities for the consumer log ? FAU_STG.1 defines requirements on protecting the log files ? FAU_STG.2 defines requirements on the availability of audit files ? FAU_STG.4 allow to specify requirements on the prevention of audit data loss for the system log. O.Access FDP_ACC.2 and FDP_ACF.1 define the access control policy as required to address O.Access.
?

6.11.1.2 Fulfilment of the dependencies The following table summarises all TOE functional requirements dependencies of this PP and demonstrates that they are fulfilled. SFR FAU_ARP/SYS.1 FAU_GEN/SYS.1 FAU_GEN/CON.1 FAU_GEN.2 Dependencies FAU_SAA.1 Potential violation analysis FPT_STM.1 Reliable time stamps FPT_STM.1 Reliable time stamps FAU_GEN.1 Audit data generation FIA_UID.1 Timing of identification FAU_GEN.1 Audit data generation FAU_GEN.1 Audit data generation FAU_GEN.1 Audit data generation FAU_GEN.1 Audit data generation FAU_STG.1 Protected audit trail storage FIA_UID.1 Timing of identification Fulfilled by FAU_SAA/SYS.1 FAU_STM.1 FAU_STM.1 FAU_GEN/SYS.1 FAU_GEN/CON.1 FAU_UID.2 FAU_GEN/SYS.1 FAU_GEN/SYS.1 FAU_GEN/CON.1 FAU_GEN/SYS.1 FAU_GEN/CON.1 FAU_STG.1 FIA_UID.2

FAU_SAA/SYS.1 FAU_SAR/SYS.1 FAU_SAR/CON.1 FAU_STG.1 FAU_STG.4 FCO_NRO.2 FCS_CKM.1

[FCS_CKM.2 Cryptographic key FCS_COP.1 distribution, or FCS_CKM.4 FCS_COP.1 Cryptographic operation] FCS_CKM.4 Cryptographic key destruction [FDP_ITC.1 Import of user data without FCS_CKM.1 security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] [FDP_ITC.1 Import of user data without FCS_CKM.1 security attributes, or FCS_CKM.4 FDP_ITC.2 Import of user data with security attributes, or

FCS_CKM.4

FCS_COP.1

172

66

Federal Office for Information Security

173

Gateway PP Version 0.9.2

SFR

Dependencies FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction

Fulfilled by

FCS_COP/HASH.1

[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.11.1.3 for missing dependency

FDP_ACC.2 FDP_ACF.1 FDP_IFC/FW.2 FDP_IFC/MTR.2 FDP_IFF/FW.1 FDP_IFF/MTR.1 FDP_RIP.2 FDP_SDI.2 FIA_ATD. FIA_UID.2 FIA_USB.1 FMT_MSA/AC.1

FDP_ACF.1 Security access control

attribute

based FDP_ACF.1
FMT_MSA/AC.3 FDP_IFF/FW.1 FDP_IFF/MTR.1 FDP_IFC/FW.2 FMT_MSA/FW.3 FDP_IFC/MTR.2 FMT_MSA/MTR.3 FIA_ATD.1

FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation
FDP_IFF.1 Simple security attributes FDP_IFF.1 Simple security attributes FDP_IFC.1 Subset information flow control FMT_MSA.3 Static attribute initialisation FDP_IFC.1 Subset information flow control FMT_MSA.3 Static attribute initialisation FIA_ATD.1 User attribute definition

[FDP_ACC.1 Subset access control, or FDP_ACC.2 FDP_IFC.1 Subset information flow control] FMT_SMR.1 FMT_SMR.1 Security roles FMT_SMF.1 FMT_SMF.1 Specification of Management Functions [FDP_ACC.1 Subset access control, or FDP_IFC/WAN.2 FDP_IFC.1 Subset information flow control] FMT_SMR.1 FMT_SMR.1 Security roles FMT_SMF.1 FMT_SMF.1 Specification of Management Functions [FDP_ACC.1 Subset access control, or FDP_IFC/MTR.2 FDP_IFC.1 Subset information flow control] FMT_SMR.1 FMT_SMR.1 Security roles FMT_SMF.1 FMT_SMF.1 Specification of Management Functions

FMT_MSA/FW.1

FMT_MSA/MTR.1

174

Federal Office for Information Security

67

175

Gateway PP Version 0.9.2

SFR FMT_MSA/AC.3

Dependencies FMT_MSA.1 Management attributes FMT_SMR.1 Security roles FMT_MSA.1 Management attributes FMT_SMR.1 Security roles FMT_MSA.1 Management attributes FMT_SMR.1 Security roles FIA_UID.1 Timing of identification Table 12: SFR Dependencies

Fulfilled by of security FMT_MSA/AC.1 FMT_SMR.1 security FMT_MSA/FW.1 FMT_SMR.1 security FMT_MSA/MTR.1 FMT_SMR.1 FIA_UID.2 -

FMT_MSA/FW.3

of

FMT_MSA/MTR.3

of

FMT_SMF.1 FMT_SMR.1 FPR_CON.1 FPR_PSE.1 FPT_FLS.1 FPT_STM.1 FPT_TST.1 FPT_PHP.1 FTP_ITC/WAN.1 FTP_ITC/MTR.1
879

880 881 882 883 884 885 886 887 888 889 890 891 892

6.11.1.3 Justification for missing dependencies The hash algorithm as defined in FCS_COP/HASH.1 does not need any key material. As such the dependency to an import or generation of key material is omitted for this SFR.

6.11.2 Security Assurance Requirements rationale
The decision on the assurance level has been mainly driven by the assumed attack potential. As oultined in the previous chapters of this Protection Profile it is assumed that - at least from the WAN side - a high attack potential is posed against the security functions of the TOE. This lead to the use of AVA_VAN.5 (Resistance against high attack potential). In order to keep evaluations according to this Protection Profile commercially feasible EAL 4 has been chose as assurance level as this is the lowest level that provides the prerequisites for the use of AVA_VAN.5. Eventually, the augmentation by ALC_FLR.3 has been chosen to emphasize the importance of a structured process for flaw remediation at the developers side, specifically for such a new technology.

176

68

Federal Office for Information Security

177 893 894 895 896 897
6.11.2.1 Dependencies of assurance components

Gateway PP Version 0.9.2

The dependencies of the assurance requirements taken from EAL 4 are fulfilled automatically. The augmentation by AVA_VAN.5 does not introduce additional functionalities that are not contained in EAL 4.

7. Appendix
7.1 Mapping from English to German terms
English term Meter Smart Meter German term Messeinrichtung Messsystem, bestehend aus einer Kommunikationseinheit und mindestens einer Messeinrichtung Kommunikationseinheit Weitverkehrsnetz (für Kommunikation) Lokales Netz (für Kommunikation) Messger?tenetz Diensteanbieter Verbraucher Netz (für Strom/Gas/Wasser)

898

Gateway WAN, Wide Area Network LAN, Local Area Network MAN, Metrological Area Network Service Provider Consumer Grid CLS, Controllable Local System Security Module billing-relevant Gateway Operator Consumption Data Grid Status Data Meter Operator Metering Service Provider TOE Customer

Sicherheitsmodul (z.B. eine Smart Card) abrechnungsrelevant Kommunikationseinheitsbetreiber Verbrauchsdaten (abrechnungsrelevant) Netzzustandsdaten (nicht abrechnungsrelevant) Messstellenbetreiber Messdienstleister EVG Haushaltskunde (gem. EnWG §3 Nr. 22)

899

7.2 Glossary
Term WLAN Description Wireless Local Area Network

178

Federal Office for Information Security

69

179

Gateway PP Version 0.9.2

Term PII

Description 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. Target of Evaluation - set of software, firmware and/or hardware possibly accompanied by guidance Local Area Network See chapter 3.1 See chapter 3.1 See chapter 3.1 See chapter 3.1 See chapter 3.1 See chapter 3.1 See chapter 3.1 See chapter 3.1 See chapter 3.1 See chapter 3.1 See chapter 3.1 See chapter 3.1 See chapter 3.1 See chapter 3.2 See chapter 3.2 See chapter 3.2 See chapter 3.2 See chapter 3.2 See chapter 3.2 Price structure (normally comprising a set of one or more rates of charge) applied to the consumption of a product or service provided to a consumer. (according to [CEN]) 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])

TOE LAN Consumer Grid Operator Supplier Producer Meter Operator Gateway Operator Metering Service Provider Meter Admin Gateway Admin Profile Provider external entity Local attacker WAN attacker Meter Data Gateway time Meter config (secondary asset) Gateway config (secondary asset) CLS config (secondary asset) software update Tariff

Block Tariff

180

70

Federal Office for Information Security

181

Gateway PP Version 0.9.2

Term Consumer Customer

Description End user of electricity, gas, water or heat. (according to [CEN]) Purchaser and/or user of a product or service supplied by an organisation. The "Customer" may be the ultimate consumer, user, beneficiary or purchaser. (according to [CEN]) Organisation offering energy related services to the consumer (according to [CEN]) In-house LAN which interconnects domestic equipment and can be used for energy management purposes. (according to [CEN]) In-house LAN which interconnects metrological equipment (i.e. Meters) and can be used for energy management purposes. (according to [CEN]) Company independent of grid operators, supply companies and metering companies that uses an infrastructure which supports smart metering (according to [CEN]) tbd property that an entity is what it claims to be (according to [SD_6]) property that sensitive data has not been modified or deleted in an unauthorised and undetected manner (according to [SD_6]) the property that information is not made available or disclosed to unauthorized individuals, entities, or processes (according to [SD_6])

Energy Service Provider Home Area Network (HAN) Metrological Area Network Independent Service Provider IT-System Authenticity Integrity Confidentiality

900 901 902

7.3 References
[CC] Common Criteria for Information Technology Security Evaluation – ● Part 1: Introduction and general model, dated July 2009, version 3.1 R3 ● Part 2: Security functional requirements, dated July 2007, version 3.1, R3 ● Part 3: Security assurance requirements, dated July, version 3.1, R3 Common Evaluation Methodology for Information Technology Security – Evaluation Methodology, dated July 2009, version 3.1 R3 Common Criteria Protection Profile for a Security Module for Smart Meter Systems. Common Criteria Protection Profile for a Smart Meter SMART METERS CO-ORDINATION GROUP (SM-CG) Item 5. M/441 first phase deliverable – Communication – Annex: Glossary (SMCG/Sec0022/DC ) Anforderungen an elektronische und software- gesteuerte Messger?te und Zusatzeinrichtungen für Elektrizit?t, Gas, Wasser und W?rme, PTB-A 50.7,

[CEM] [PP_SM] [PP_MTR] [CEN]

[PTB_A50.7]

182

Federal Office for Information Security

71

183

Gateway PP Version 0.9.2

April 2002 [SD_6] ISO/IEC JTC 1/SC 27 N7446 Standing Document 6 (SD6): Glossary of IT Security Terminology 2009-0429 http://www.jtc1sc27.din.de/sce/sd6

903 904 905

184

72

Federal Office for Information Security


相关文章:
BSI外审准备工作任务.doc附件四
BSI 老師的接車住宿由賴經理安排,於 2 月 19 日上午 8:45 準到廠,各部門主管、經理於 9:00 參加首次會議,20 日下午 16:00 參加未次會議;若 BSI 有...
内训流程BSI
内训流程BSI 隐藏>> 内训流程: 1. 客户提出内训设想 企业培训负责人根据自身实际需求提出内训设想 2. 共同讨论并分析需求 BSI 的专业培训顾问直接与企业培训负责...
关于ISSI Lyontek Cypress BSI的SRAM型号归纳
关于ISSI Lyontek Cypress BSI的SRAM型号归纳_电子/电路_工程科技_专业资料。知名品牌的 sram型号归总ISSI(芯成)Lyontek(来扬)Cypress(赛普拉斯)BSI(连邦)的 SRAM...
宝来1.8T换汽车电脑匹配方法
进入发动机电脑和 BSi 的电脑匹配阶段。选择《程序设计配对》 输入程序保密代码, (发动机防盗密码) 确认进入下一步。 选择与 BSI 配对选项中的“是” 匹配完成。...
院感试题
6. 导管相关血流感染(CLBSI) :是指带有血管内导管或者拔除血管内导管 48 小时内的患者出现 菌血症或真菌血症,并伴有发热(>38℃) 、寒战或低血压等感染表现,...
国际金融试卷及答案
25 美元 36 、(1)不用 BSI 的损失: 100 万*(15。8—15。00)=80 万人民币元 (2)用 BSI 后的损失 A 、 人民币借款利息 100*15*5%*1/2...
国际金融期末复习
8.BSI:就是借款一即期合同一投资法(borrow-spot-invest)指有关经济主体通过借款、即期外汇交易和投资的程序,争取消除外汇风险的风险管理办法。 9.次债危机:美国...
土木讲座心得报告
2011 年,英国标准学 会(BSI)发布 BIM 实施战略(BIM Strategy),要求所有政府项目 5 年内全部采用 BIM。 前日本 BIM 应用已扩展到全国范围,并上升到政府推进的...
杜比认证测试表格-ddp_s_test_broadcastresults
Digital Plus Decoder for Consumer Broadcast Products Test Results Report # Additional BSI Bitstreams (Internet Enabled) [2.2.6] Primary Output Result Test...
CR-BSI.SOP
因导管插入、护理等不当,导致导管相关血流 感染(CR-BSI)十分常见,部分病人因此而死亡。根据卫生部医院感染控制项目组的相关要求和我院的具体情况,特制定 预防 CR-...
更多相关标签: