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