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