Smart Metering Implementation Programme Communications Hub Technical Specifications (CHTS) Version 1.47: Release Note 18 November 2015 Release Note This release note accompanies, but does not form part of CHTS v1.47. It describes the revision history of CHTS. Summary of main changes This document is CHTS v1.47. There are corrections of minor typographic errors throughout this document. In addition, the sections of this document listed below incorporate specific changes and updates to CHTS v1.46 that have been adopted through a number of Issue Resolution Proposals (IRPs) and following the DECC Technical Specifications Issues Management process. Table of Section Changes The sections of this document listed below incorporate changes and updates to CHTS v1.46 as follows: Section Changes Section 4: Changes at Sections 4.2.3, 4.5.1.9, 4.5.3 and 4.5.4.7 in summary as follows: Glossary Corrected previous wording - GSME credentials are in the CHF device log, not the GPF device log Aligning references to the latest versions of the Security Characteristics documentation Allowing for Payment-based debt payments in the Billing Data Log Addition of definition for SECAS Table of Revision History Version 0.72 0.75 0.8 0.81 Date of Issue 02/08/12 08/08/12 17/08/12 29/08/12 Status Draft Draft Draft Draft 0.86 0.86d 0.86e 7/09/12 10/09/12 11/09/12 Draft Draft Draft 0.90 13/09/12 Draft 1.10 1.12 1.14 1.16 09/01/13 05/02/13 08/02/13 12/02/13 Draft Draft Draft Draft 1.17 25/03/13 Draft 1.18 1.19 27/03/13 15/04/13 Draft Draft 1.20 1.21 1.30 16/04/13 05/06/13 23/08/13 Draft Draft Draft Change Summary Draft for review Updated following preliminary review Updated following issue clarification Updated following SSAG review comments and establishment of new drafting principles Internal Team Review for ISDS issue Restructured as per SMETS Added placeholders for content to cover monitoring, historic gas calculations, buffering, network coordination and routing Draft for issue with ISDS. Included comments from internal review, added missing content, removed placeholders Draft for review Draft for review Draft for review Draft for issue with ISFT. Includes comments from internal review and feedback from BEAMA Includes comments from review with SDAG, CSP bidders and BEAMA Includes comments from internal review Updates following regulatory review. Includes restructuring of the document, and making more explicit the difference between the Communications Hub functionality and the Gas Proxy. For issue with Final ISFT. Pre-Wragge review Incorporating legal review comments, internal work on GBCS and clarifications on security credentials. 1.31 1.32 1.4 06/09/13 13/09/13 23/12/13 Draft Draft Draft 1.41 30/04/14 Draft 1.42 28/05/14 Draft 1.43 25/06/14 Draft 1.44 03/07/14 Draft 1.45 10/07/14 Draft 1.45 1.46 29/07/14 28/11/14 Draft Draft 1.47 18/11/2015 Draft Incorporating further stakeholder comments Baseline draft Draft version incorporating changes made following internal review and previously suggested revisions. Draft version incorporating changes emerging following GBCS review, previous TBDG review and CPA review. Draft version incorporating comments on the changes proposed in 1.41. Draft version for informal TBDG review incorporating changes proposed in email to TBDG members on 10 June. Draft version incorporating comments on the changes proposed in 1.43. Draft version incorporating comments on the changes proposed in 1.43 and 1.44. Draft version clarifying Random Number Generator requirements. Draft version to align with GBCS v0.8.1. Changes include removal of Data Restriction Flag, and specification of number of Devices to be supported by GPF / CHF Uplift incorporating changes and updates to CHTS v1.46 adopted through the DECC Technical Specifications Issues Management process This page is intentionally left blank Smart Metering Implementation Programme Communications Hub Technical Specifications (CHTS) Version 1.47 18 November 2015 DRAFT CHTS © Crown copyright 2015 You may re-use this information (not including logos) free of charge in any format or medium, under the terms of the Open Government Licence. To view this licence, visit www.nationalarchives.gov.uk/doc/open-government-licence/ or write to the Information Policy Team, The National Archives, Kew, London TW9 4DU, or email: psi@nationalarchives.gsi.gov.uk. This document is also available from our website at www.gov.uk/decc. Version: CHTS v1.47 Issued: 18 November 2015 Enquiries to: Smart Metering Implementation Programme Department of Energy & Climate Change 3 Whitehall Place, Area 1C London, SW1A 2AW Telephone: 0300 068 6659 Email: smartmetering@decc.gsi.gov.uk Version 1.47 18 November 2015 Page 6 DRAFT CHTS Table of Contents Note: Sections 1 and 2 of this document are not used. 3 Introduction ................................................................................................................ 8 4 Technical Specifications ........................................................................................... 9 4.1 Overview ................................................................................................................. 9 4.2 Testing and Certification Requirements ................................................................... 9 4.2.1 Conformance with the CHTS .......................................................................... 9 4.2.2 Conformance with the Great Britain Companion Specifications ...................... 9 4.2.3 Conformance with the Commercial Product Assurance Security Characteristic for GB Smart Metering ................................................................................... 9 4.2.4 Interoperability with the Data and Communications Company Systems ......... 9 4.3 Physical Requirements ............................................................................................ 9 4.4 Functional Requirements....................................................................................... 11 4.4.1 Clock ............................................................................................................ 11 4.4.2 Communications .......................................................................................... 11 4.4.3 Data Storage ................................................................................................ 13 4.4.4 Buffering....................................................................................................... 14 4.4.5 Monitoring .................................................................................................... 14 4.4.6 Security ........................................................................................................ 14 4.4.7 Inter-PAN Connection .................................................................................. 17 4.5 Interface Requirements ......................................................................................... 17 4.5.1 CHF Interface Commands ............................................................................ 17 4.5.2 Receipt of Information by the GPF via the HAN Interface ............................. 19 4.5.3 Type 1 Device and Type 2 Device Information Provision from the GPF via the HAN Interface............................................................................................... 19 4.5.4 GPF Interface Commands ............................................................................ 20 4.6 Data Requirements ............................................................................................... 21 4.6.1 Constant Data .............................................................................................. 21 4.6.2 Configuration Data ....................................................................................... 22 4.6.3 Operational Data .......................................................................................... 22 5 Glossary ................................................................................................................... 24 Version 1.47 18 November 2015 Page 7 DRAFT CHTS 1 3 Introduction1 2 3 4 5 6 The requirement on the Data and Communications Company (DCC) to provide Communications Hubs that comply with these Communications Hub Technical Specifications (CHTS) arises from Part E of the Smart Meter Communication Licence (granted pursuant to sections 7AB(2) and (4) of the Gas Act 1986 and sections 6(1A) and (1C) of the Electricity Act 1989). 7 8 9 Section 4 of this document describes the minimum physical, functional, interface, data, testing and certification requirements of a Communications Hub that the DCC is required to provide to comply with these Licence and SEC requirements. 10 11 12 13 14 15 16 17 This document has been brought into force by the Secretary of State on [ ] for the purposes of the relevant licence conditions. CHTS v1.45 was notified to the European Commission in accordance with the requirements of Article 8 of Directive 98/34/EC of the European Parliament and of the Council laying down a procedure for the provision of information in the field of technical standards and regulations (OJ L 204, 21.7.1998, p. 37) as amended by Directive 98/48/EC of the European Parliament and of the Council (OJ L 217, 5.8.1998, p. 18). The Government is currently considering if re-notification is required due to the changes made in this version (v1.47), compared to v1.45. 18 19 20 The Smart Metering technical and security architecture is based on a suite of agreed, open standards, reflecting the UK Government strategy to facilitate the development of third party innovative solutions for consumer devices. 21 22 23 Mutual recognition: Any requirement for a Communications Hub to comply with the CHTS or any of the technical specifications contained or referred to in this document shall be satisfied by compliance with: 24 25 a relevant standard or code of practice of a national standards body or equivalent body of any EEA State or Turkey; or 26 any relevant international standard recognised for use in any EEA State or Turkey; or 27 28 any relevant technical regulation with mandatory or de facto mandatory application for marketing or use in any EEA State or Turkey, 29 30 31 32 in so far as compliance with the standard, code of practice or technical regulation in question enables the equipment to achieve, in an equivalent manner, all of the physical, functional, interface and data capabilities that are achieved by compliance with the requirements of CHTS or any of the technical specifications contained or referred to in this document. 1 Sections 1 and 2 of this document are not used Version 1.47 18 November 2015 Page 8 DRAFT CHTS 33 4 Technical Specifications 34 4.1 Overview 35 36 37 38 Section 4 of this document describes the minimum physical, minimum functional, minimum interface, minimum data and minimum testing and certification requirements of a Communications Hub (CH) that the DCC is required to provide to comply with Part E of the Smart Meter Communication Licence and section [F] of the Smart Energy Code (SEC). 39 This Section 4 includes requirements for: 40 41 i. ii. Communications Hub Function (CHF) of a CH; and Gas Proxy Function (GPF) of a CH. 42 43 44 Where in this Section 4 a requirement is expressed to be a requirement of the CHF or the GPF it shall be construed as a requirement of the CH to be delivered through the CHF or the GPF as the case may be. 45 4.2 Testing and Certification Requirements 46 4.2.1 Conformance with the CHTS 47 48 A CH shall have been tested to ensure that it meets the requirements described in this Section 4, and evidence must be available to confirm such testing and conformance. 49 50 4.2.2 Conformance with the Great Britain Companion Specifications2 51 52 A CH shall meet the requirements described in the current version of the Great Britain Companion Specifications meaning v0.8.2 or later as published on the SECAS website. 53 54 55 A CH shall have been certified by the ZigBee Alliance as compliant with the ZigBee SEP v1.2 requirements described in the current version of the Great Britain Companion Specifications meaning v0.8.2 or later as published on the SECAS website. 56 57 4.2.3 Conformance with the Commercial Product Assurance Security Characteristic for GB Smart Metering3 58 59 60 A CH shall meet the requirements described in the current version of the Commercial Product Assurance Security Characteristic Smart Metering - Communications Hub meaning v1.2 or later as published on CESG’s Website. 61 62 63 A CH shall be certified by CESG as compliant with the current version of the Commercial Product Assurance Security Characteristic Smart Metering - Communications Hub meaning v1.2 or later as published on CESG’s Website. 64 65 4.2.4 Interoperability with the Data and Communications Company Systems 66 67 68 A CH shall be interoperable with DCC systems such that the DCC need not make any adjustments to its systems in order to establish Communications Links (as described in this Section 4) with the CH via its WAN Interface. 69 4.3 Physical Requirements 70 A CH shall as a minimum include the following components: 2 The current version of Great Britain Companion Specification can be found here: https://www.smartenergycodecompany.co.uk/sec/the-developing-sec 3 The current version of CPA Security Characteristics can be found here: https://www.cesg.gov.uk/servicecatalogue/ProductAssurance/CPA/Pages/Security-Characteristics.aspx Version 1.47 18 November 2015 Page 9 DRAFT 71 72 73 74 75 76 i. ii. iii. iv. v. vi. CHTS a Clock; a Data Store; a HAN Interface; a Random Number Generator; a WAN Interface; and an Intimate Physical Interface. 77 78 79 A CH shall operate using DC power and be capable of performing the minimum functional, interface and data requirements described in Sections 4.4, 4.5 and 4.6 respectively without consuming more than an average of 1 watt of electricity under normal operating conditions. 80 81 A CH shall be capable of automatically resuming operation after a power failure in its operating state prior to such failure. 82 The CH shall: 83 84 85 86 87 88 89 90 91 92 93 vii. viii. ix. permanently display the CHF Identifier(4.6.1.1) on the CH; permanently display the GPF Identifier(4.6.1.4) on the CH; and have a Secure Perimeter. The HAN Interface of the CH shall be capable of establishing a ZigBee SEP v1.2 Smart Metering Home Area Network which: x. xi. xii. xiii. operates within the 2400 – 2483.5 MHz harmonised frequency band; supports the routing (as set out in Section 4.4.2.1) of Commands, Responses, and Alerts to and from Devices; supports the Communications Links described in Section 4.5.2 and 4.5.3; and supports Certificate-based Key Establishment Cryptographic Suite 2 as described in ZigBee SEP v1.2. 94 95 On first establishing a ZigBee SEP v1.2 Smart Metering Home Area Network the CH shall be capable of fixing the frequency at which its HAN Interface operates. 96 97 98 The CH shall be designed taking all reasonable steps so as to prevent Unauthorised Physical Access and Unauthorised communications through its Secure Perimeter that could compromise the Confidentiality and / or Data Integrity of: 99 100 101 102 103 104 xiv. xv. xvi. xvii. xviii. xix. 105 stored or executing on the CH. 106 107 108 The CH shall be capable of detecting any attempt at Unauthorised Physical Access through its Secure Perimeter that could compromise such Confidentiality and / or Data Integrity and on such detection shall be capable of: 109 110 xx. Personal Data; Consumption data used for billing; Security Credentials; Random Number Generator; Cryptographic Algorithms; and Firmware and data essential for ensuring its Integrity, providing evidence of such an attempt through the use of tamper evident coatings or seals; 111 and where reasonably practicable: 112 113 xxi. xxii. 114 115 116 The CH shall be designed taking all reasonable steps to ensure that its HAN Interface and WAN Interface do not cause detriment to Communications Links formed with Devices connected to its Intimate Physical Interface. generating an entry to that effect in the CHF Security Log(4.6.3.5); and generating and sending an Alert to that effect via its WAN Interface. Version 1.47 18 November 2015 Page 10 DRAFT CHTS 117 4.4 Functional Requirements 118 This section describes the minimum functions that a CH shall be capable of performing. 119 4.4.1 Clock 120 121 122 The Clock forming part of the CH shall be capable of operating so as to be accurate to within 10 seconds of the UTC date and time under normal operating conditions. The CH shall be capable of maintaining the CHF Date and Time(4.6.3.1) and: 123 124 125 126 127 i. ii. marking this to indicate if its Communications Link via the WAN Interface is not available; and making the CHF Date and Time(4.6.3.1) available to Devices with which the CHF has established a Communications Link (as set out in Section 4.4.2.1) via its HAN interface. 128 4.4.2 Communications 129 4.4.2.1 130 131 132 The CHF shall be capable of establishing and maintaining Communications Links via the HAN interface with a minimum of four ESME, one GSME, one GPF, seven Type 1 Devices (including a minimum of two PPMIDs) and three Type 2 Devices. 133 134 135 The CHF shall be capable of establishing a Communications Link via the HAN Interface with a Device for a minimum of one hour following receipt of that Device’s Security Credentials (as set out in Section 4.5.1.2). 136 137 138 139 The CHF shall only be capable of establishing a Communications Link via the HAN Interface with a Device with Security Credentials in the CHF Device Log(4.6.2.1) and shall not be capable of establishing a Communications Link via the HAN Interface with any other Devices. 140 141 142 On establishing such a Communications Link with a Device, the CHF shall be capable of recording the UTC date and time of such establishment in the relevant part of the CHF Communications Store(4.6.3.2). 143 144 145 146 The CHF shall only be capable of establishing and maintaining a Communications Link via the WAN Interface with the Wide Area Network Provider for the Premises in which the CH is installed and shall not be capable of establishing a Communications Link via the WAN Interface with any other person. 147 148 149 The CHF shall be capable of ensuring that the security characteristics of all Communications Links it establishes meet the requirements described in CHF Secure Communications(4.4.6.6). 150 151 When any Command addressed to the CHF is received by the CHF via any Communications Link, and again when the Command is due to be executed, the CHF shall be capable of: 152 153 154 155 156 i. ii. iii. Communications Links with the CHF using the Security Credentials the CHF holds, Authenticating to a Trusted Source the Command; verifying in accordance with CHF Role-based Access Control(4.4.6.2.3) that the sender of the Command is Authorised to execute the Command; and verifying the integrity of the Command. 157 158 159 160 On failure of any of (i) to (iii) above, the CHF shall be capable of generating an entry in the CHF Security Log(4.6.3.5) to that effect, discarding the Command without execution and without either generating or sending a Response, and generating and sending an Alert to that effect via the WAN Interface. 161 162 Where the Command is not due to be executed immediately, the CHF shall be capable of generating and sending a Response via the WAN Interface to confirm successful receipt. Version 1.47 18 November 2015 Page 11 DRAFT CHTS 163 164 165 166 When executing a Command, the CHF shall be capable of generating and sending a Response via both the WAN Interface and the HAN Interface, which shall either confirm successful execution of the Command or shall detail why it has failed to execute the Command. 167 168 The CHF shall only be capable of addressing a Response to the sender of the relevant Command. 169 The CHF shall be capable of routing Commands, Responses, and Alerts: 170 171 172 173 174 iv. v. vi. from each Device in the CHF Device Log(4.6.2.1) to the Devices in the CHF Device Log(4.6.2.1) that is the intended recipient; from each Device in the CHF Device Log(4.6.2.1) to the WAN Interface; and from the WAN Interface to the Device in the CHF Device Log(4.6.2.1) that is the intended recipient. 175 176 The CHF shall be capable of storing the Security Credentials of a minimum of 16 Devices in the CHF Device Log(4.6.2.1). 177 4.4.2.2 178 179 180 A GPF shall be capable of ensuring that the security characteristics of all Communications Links it establishes meet the requirements described in GPF Secure Communications(4.4.6.7). 181 182 When any Command addressed to the GPF is received by the GPF via any Communications Link, and again when the Command is due to be executed, a GPF shall be capable of: 183 184 185 186 187 i. ii. iii. Communications Links with the GPF using the Security Credentials the GPF holds, Authenticating to a Trusted Source the Command; verifying in accordance with GPF Role-based Access Control(4.4.6.2.6) that the sender of the Command is Authorised to execute the Command; and verifying the integrity of the Command. 188 189 190 191 On failure of any of (i) to (iii) above, the GPF shall be capable of generating an entry in the GPF Security Log(4.6.3.11) to that effect, discarding the Command without execution and without either generating or sending a Response, and generating and sending an Alert to that effect via the WAN Interface. 192 193 Where the Command is not due to be executed immediately, the GPF shall be capable of generating and sending a Response via the WAN Interface to confirm successful receipt. 194 195 196 When executing the Command the GPF shall be capable of generating and sending a Response via the WAN Interface, which shall either confirm successful execution of the Command or shall detail why it has failed to execute the Command. 197 198 The GPF shall only be capable of addressing a Response to the sender of the relevant Command. 199 4.4.2.2.1 Communications Links with GSME over the HAN Interface 200 201 The GPF shall be capable of establishing and maintaining Communications Links via the HAN Interface with GSME. 202 203 The GPF shall be capable of receiving the information defined in Section 4.6.3.9 from GSME. 204 4.4.2.2.2 Communications Links with Type 1 Devices over the HAN Interface 205 206 The GPF shall be capable of establishing and maintaining Communications Links via the HAN Interface with a minimum of one Type 1 Device. Version 1.47 18 November 2015 Page 12 DRAFT CHTS 207 208 209 The GPF shall only be capable of establishing a Communications Link with a Type 1 Device with Security Credentials in the GPF Device Log(4.6.2.3) and shall not be capable of establishing a Communications Link via the HAN Interface with any other Devices. 210 The GPF shall be capable of supporting the following types of Communications Links: 211 212 213 214 215 i. ii. iii. iv. receiving the Commands (set out in Section 4.5.4) from a Type 1 Device; generating and sending the Responses (set out in Section 4.5.4) to a Type 1 Device; generating and sending the information (set out in Section 4.6) to a Type 1 Device; and sending Alerts to a Type 1 Device, including those it has received from GSME. 216 4.4.2.2.3 Communications Links with Type 2 Devices over the HAN Interface 217 218 The GPF shall be capable of establishing and maintaining Communications Links via the HAN Interface with a minimum of four Type 2 Devices. 219 220 221 The GPF shall only be capable of establishing a Communications Link with a Type 2 Device with Security Credentials in the GPF Device Log(4.6.2.3) and shall not be capable of establishing a Communications Link via the HAN Interface with any other Devices. 222 The GPF shall be capable of supporting the following types of Communications Links: 223 224 i. ii. generating and sending information (set out in Section 4.6) to a Type 2 Device; and sending Alerts to a Type 2 Device, including those it has received from the GSME. 225 4.4.3 Data Storage 226 227 A CH shall be capable of retaining all information held in its Data Store at all times, including on loss of power. 228 4.4.3.1 229 4.4.3.1.1 Gas Consumption and Energy Consumption data 230 231 232 The GPF shall be capable of using the GSME Cumulative and Historical Value Store and the GSME Cumulative Current Day Value Store (received from GSME as set out in Section 4.5.2) to calculate and store to: 233 i. 234 235 236 237 238 239 240 241 GSME data the GPF Cumulative and Historical Value Store [INFO](4.6.3.6): a) b) c) d) e) f) ii. Energy Consumption on the Day up to the Local Time; Energy Consumption on each of the eight Days prior to such Day; Energy Consumption in the Week in which the calculation is performed; Energy Consumption in each of the five Weeks prior to such Week; Energy Consumption in the month in which the calculation is performed; Energy Consumption in the thirteen months prior to such month; and the GPF Daily Gas Consumption Log [INFO](4.6.3.7), the Gas Consumption on each of the 731 Days prior to the current Day. 242 4.4.3.1.2 Cost of Gas Consumption data 243 244 245 246 The GPF shall be capable of using the GSME Cumulative and Historical Value Store and the GSME Cumulative Current Day Value Store (received from GSME as set out in Section 4.5.2) to calculate and store to the GPF Cumulative and Historical Value Store [INFO](4.6.3.6) the cost of: 247 248 249 250 251 252 i. ii. iii. iv. v. vi. Energy Consumption on the Day up to the Local Time; Energy Consumption on each of the eight Days prior to such Day; Energy Consumption in the Week in which the calculation is performed; Energy Consumption in each of the five Weeks prior to such Week; Energy Consumption in the month in which the calculation is performed; and Energy Consumption in the thirteen months prior to such month. Version 1.47 18 November 2015 Page 13 DRAFT CHTS 253 4.4.3.1.3 Half hour profile data 254 255 256 257 258 259 The GPF shall be capable of using the GSME Profile Data Log, the GSME Cumulative Current Day Value Store, the GSME Conversion Factor and the GSME Calorific Value (received from GSME as set out in Section 4.5.2) to calculate and store to the GPF Profile Data Log [INFO](4.6.3.10) Gas Consumption in each 30 minute period (commencing at the start of minutes 00 and 30 in each hour) and the UTC date and time at the end of the 30 minute period to which the Gas Consumption relates. 260 4.4.4 Buffering 261 262 A CHF shall be capable of Buffering all Commands intended for GSME with Security Credentials recorded in the CHF Device Log(4.6.2.1). 263 264 A CHF shall be capable of prioritising the forwarding of any GSME Add Credit Commands and GSME Activate Emergency Credit Commands. 265 A CHF shall be capable of Buffering a Command to receive Firmware intended for ESME. 266 267 A CHF shall be capable of Buffering Commands, Responses and Alerts to be sent via the WAN interface. 268 Under normal operating conditions, a CHF shall be capable of Buffering at all times: 269 270 271 272 i. ii. iii. iv. CHF Device Log(4.6.2.1) Alerts; Device Commissioning Alerts; Responses to Critical Commands; and other Critical Alerts. 273 4.4.5 Monitoring 274 275 276 A CH shall be capable of recording the UTC date and time at which the power supply to the CH is interrupted and the UTC date and time at which the power supply to the CH is restored and generating entries to that effect in the CHF Event Log(4.6.3.3). 277 4.4.6 Security 278 4.4.6.1 279 280 281 282 A CH shall be designed taking all reasonable steps so as to ensure that any failure or compromise of its integrity shall not compromise the Security Credentials or Personal Data stored on it or compromise the integrity of any other Device to which it is connected by means of a Communications Link. 283 284 285 The CH shall be capable of verifying its Firmware at power-on and prior to activation of the Firmware, to verify that the Firmware, at that time, is in the form originally received. On failure of verification the CH shall be capable of: 286 287 i. ii. General generating an entry to that effect in the CHF Security Log(4.6.3.5); and generating and sending an Alert to that effect via the WAN Interface. 288 289 A CHF shall be capable of logging in the CHF Security Log(4.6.3.5) the occurrence and type of any Sensitive Event. 290 291 A GPF shall be capable of logging in the GPF Security Log(4.6.3.11) the occurrence and type of any Sensitive Event. 292 293 A CHF shall be capable of securely disabling Critical Commands other than those Commands set out in Section 4.5.1 that are Critical Commands. 294 295 A GPF shall be capable of securely disabling Critical Commands other than those Commands set out in Section 4.5.4 that are Critical Commands. Version 1.47 18 November 2015 Page 14 DRAFT CHTS 296 4.4.6.2 297 4.4.6.2.1 CHF Private Keys 298 299 A CHF shall be capable of generating Public-Private Key Pairs to support the Cryptographic Algorithms set out in Section 4.4.6.3. 300 301 302 The CHF shall be capable of securely storing such Private Keys and shall be capable of formatting and sending via each of the HAN Interface and the WAN Interface a Certificate Signing Request containing the corresponding Public Key and the CHF Identifier(4.6.1.1). 303 The CHF shall be capable of securely storing Key Agreement values. 304 4.4.6.2.2 CHF Public Key Certificates 305 306 A CHF shall be capable of securely storing Security Credentials from Certificates including for use in the Cryptographic Algorithms as set out in Section 4.4.6.3. 307 308 309 During the replacement of any CHF Security Credentials(4.6.2.2) (as set out in Section 4.5.1.10), the CHF shall be capable of ensuring that the CHF Security Credentials(4.6.2.2) being replaced remain usable until the successful completion of the replacement. 310 4.4.6.2.3 CHF Role-based Access Control 311 312 The CHF shall be capable of restricting Authorisation to execute Commands and of issuing Alerts according to Role permissions. 313 4.4.6.2.4 GPF Private Keys 314 315 A GPF shall be capable of generating Public-Private Key Pairs to support the Cryptographic Algorithms set out in Section 4.4.6.4. 316 317 318 The GPF shall be capable of securely storing such Private Keys and shall be capable of formatting and sending via the WAN Interface a Certificate Signing Request containing the corresponding Public Key and the GPF Identifier(4.6.1.4). 319 The GPF shall be capable of securely storing Key Agreement values. 320 4.4.6.2.5 GPF Public Key Certificates 321 322 A GPF shall be capable of securely storing Security Credentials from Certificates including for use in the Cryptographic Algorithms as set out in Section 4.4.6.4. 323 324 325 During the replacement of any GPF Security Credentials(4.6.2.4) (as set out in Section 4.5.4.8) the GPF shall be capable of ensuring that the GPF Security Credentials(4.6.2.4) being replaced remain usable until the successful completion of the replacement. 326 4.4.6.2.6 GPF Role-based Access Control 327 328 The GPF shall be capable of restricting Authorisation to execute Commands and of issuing Alerts according to Role permissions. 329 4.4.6.3 330 The CHF shall be capable of supporting the following Cryptographic Algorithms: 331 332 333 334 335 336 337 338 339 i. ii. iii. Security Credentials CHF Cryptographic Algorithms Elliptic Curve DSA; Elliptic Curve DH; and SHA-256. In executing and creating any Command, Response or Alert, the CHF shall be capable of applying Cryptographic Algorithms (alone or in combination) for: iv. v. vi. vii. Digital Signing; Digital Signature verification; Hashing; Message Authentication; and Version 1.47 18 November 2015 Page 15 DRAFT 340 viii. CHTS Encryption and Decryption. 341 4.4.6.4 342 The GPF shall be capable of supporting the following Cryptographic Algorithms: 343 344 345 346 347 348 349 350 351 352 i. ii. iii. GPF Cryptographic Algorithms Elliptic Curve DSA; Elliptic Curve DH; and SHA-256. In executing and creating any Command, Response or Alert, the GPF shall be capable of applying Cryptographic Algorithms (alone or in combination) for: iv. v. vi. vii. viii. Digital Signing; Digital Signature verification; Hashing; Message Authentication; and Encryption and Decryption. 353 4.4.6.5 354 355 The CH shall only be capable of activating its Firmware on receipt of an Activate CH Firmware Command (as set out in Section 4.5.1.1). 356 4.4.6.6 357 358 The CHF shall be capable of preventing and detecting, on all of its interfaces, Unauthorised access that could compromise the Confidentiality and / or Data Integrity of: 359 360 361 362 363 364 365 366 367 368 369 370 371 i. ii. iii. iv. CH Firmware CHF Secure Communications Personal Data whilst being transferred via an interface; Consumption data used for billing whilst being transferred via an interface; Security Credentials whilst being transferred via an interface; and Firmware and data essential for ensuring its Integrity whilst being transferred via an interface, and any Command that could compromise the Confidentiality and / or Data Integrity of: v. vi. vii. viii. Personal Data; Consumption data used for billing; Security Credentials; and Firmware and data essential for ensuring its Integrity, stored or executing on the CHF, and on such detection shall be capable of: ix. x. generating an entry to that effect in the CHF Security Log(4.6.3.5); and generating and sending an Alert to that effect via the WAN Interface. 372 373 The CHF shall be capable of employing techniques to protect against Replay Attacks relating to Commands received. 374 375 The CHF shall not be capable of executing a Command to modify or delete entries from the CHF Security Log(4.6.3.5) or the GPF Security Log(4.6.3.11). 376 4.4.6.7 377 378 The GPF shall be capable of preventing and detecting, on all of its interfaces, Unauthorised access that could compromise the Confidentiality and / or Data Integrity of: 379 380 381 382 383 384 i. ii. iii. iv. GPF Secure Communications Personal Data whilst being transferred via an interface; Gas Consumption data used for billing whilst being transferred via an interface; Security Credentials whilst being transferred via an interface; and Firmware and data essential for ensuring its Integrity whilst being transferred via an interface, and any Command that could compromise the Confidentiality and / or Data Integrity of: Version 1.47 18 November 2015 Page 16 DRAFT 385 386 387 388 389 390 391 v. vi. vii. viii. CHTS Personal Data; Gas Consumption data used for billing; Security Credentials; and Firmware and data essential for ensuring its Integrity, stored or executing on the GPF, and on such detection shall be capable of: ix. x. generating an entry to that effect in the GPF Security Log(4.6.3.11); and generating and sending an Alert to that effect via the WAN Interface. 392 393 The GPF shall be capable of employing techniques to protect against Replay Attacks relating to Commands received. 394 395 The GPF shall not be capable of executing a Command to modify or delete entries from the GPF Security Log(4.6.3.11). 396 4.4.7 Inter-PAN Connection 397 398 399 The CH shall be capable of permitting devices to establish an Inter-PAN Connection for a period of one hour at CH power-on. Where such a connection has been established, the CH shall be capable of sending: 400 401 i. ii. Responses and Alerts it has generated; and Responses and Alerts it has received from other Devices, 402 to the Inter-PAN connected device. 403 4.5 Interface Requirements 404 405 This section describes the minimum required interactions that a CH shall be capable of undertaking via the HAN Interface and the WAN Interface. 406 4.5.1 CHF Interface Commands 407 408 409 The CHF shall be capable of executing the Commands set out in this Section 4.5.1. The CHF shall be capable of logging all Commands received and Outcomes in the CHF Event Log(4.6.3.3). 410 411 412 413 The CHF shall be capable of executing Commands immediately on receipt (‘immediate Commands’) and where specified in the Great Britain Companion Specification at a future date (‘future dated Commands’). A future dated Command shall include the UTC date and time at which the Command shall be executed by the CHF. 414 415 416 417 418 The CHF shall be capable of cancelling a future dated Command. A future dated Command shall be capable of being cancelled by an Authorised party, subject to CHF Role-based Access Control (as set out in Section 4.4.6.2.3). The CHF shall be capable of generating and sending a Response acknowledging that a future dated Command has been successfully cancelled. 419 4.5.1.1 420 A Command to activate Firmware. 421 422 In executing the Command the CH shall be capable of installing new CH Firmware using a mechanism that is robust against failure and loss of data. 423 424 425 The new Firmware shall include version information. Where new Firmware is successfully installed, the CH shall be capable of recording the version information of that new Firmware in CH Firmware Version(4.6.3.4). 426 4.5.1.2 427 428 A Command to add Security Credentials for a Type 1 Device, Type 2 Device, ESME, GSME or a GPF to the CHF Device Log(4.6.2.1). Activate CH Firmware Add CHF Device Security Credentials Version 1.47 18 November 2015 Page 17 DRAFT 429 CHTS In executing the Command, the CHF shall be capable of: 430 431 432 433 i. ii. verifying the Security Credentials; generating and sending an Alert to this effect, including details of the revised CHF Device Log(4.6.2.1), via the WAN Interface; and recording the Command and Outcome to the CHF Security Log(4.6.3.5). iii. 434 4.5.1.3 435 A Command to clear all entries from the CHF Event Log(4.6.3.3). 436 437 The CHF shall be capable of logging that the Command has been executed in the CHF Security Log(4.6.3.5). 438 4.5.1.4 439 440 A Command to generate a Public–Private Key Pair and issue a corresponding Certificate Signing Request. 441 4.5.1.5 442 443 A Command to read the value of one or more of the CHF configuration data items set out in Section 4.6.2. 444 445 In executing the Command, the CHF shall be capable of sending such value(s) in a Response. 446 4.5.1.6 447 448 A Command to read the value of one or more of the constant data items set out in Section 4.6.1. 449 450 In executing the Command, the CHF shall be capable of sending such value(s) in a Response. 451 4.5.1.7 452 453 A Command to read the value of one or more of the operational data items set out in Section 4.6.3. 454 455 In executing the Command, the CHF shall be capable of sending such value(s) in a Response. 456 4.5.1.8 457 A Command to receive CH Firmware. 458 In executing the Command the CH shall be capable of: Clear CHF Event Log Issue CHF Security Credentials Read CHF Configuration Data Read CHF Constant Data Read CHF Operational Data Receive CH Firmware 459 460 i. ii. 461 4.5.1.9 462 A Command to remove Security Credentials for a Device from the CHF Device Log(4.6.2.1). 463 In executing the Command the CHF shall be capable of: 464 465 466 467 468 469 470 i. ii. only accepting new Firmware from an Authorised and Authenticated source; and verifying the Authenticity and integrity of new Firmware before installation. Remove CHF Device Security Credentials generating and sending an Alert to this effect, including details of the revised CHF Device Log(4.6.2.1), via the WAN interface; and recording the Command and Outcome to the CHF Security Log(4.6.3.5). Where the Device removed is a GSME, the GPF shall be capable of permanently deleting all the data stored in the GPF Cumulative and Historical Value Store [INFO](4.6.3.6), GPF Daily Gas Consumption Log [INFO](4.6.3.7), GPF Profile Data Log [INFO](4.6.3.10) and GPF GSME Proxy Log(4.6.3.9). Version 1.47 18 November 2015 Page 18 DRAFT CHTS 471 4.5.1.10 Replace CHF Security Credentials 472 A Command to replace CHF Security Credentials(4.6.2.2) held within the CHF. 473 In executing the Command the CHF shall be capable of: 474 475 i. ii. maintaining the Command’s Transactional Atomicity; and recording the Command and Outcome to the CHF Security Log(4.6.3.5). 476 4.5.1.11 Restore CHF Device Log 477 A Command to restore the details in the CHF Device Log(4.6.2.1). 478 479 In executing the Command, the CHF shall be capable of recording the Command and Outcome to the CHF Security Log(4.6.3.5). 480 4.5.2 Receipt of Information by the GPF via the HAN Interface 481 482 483 484 A GPF shall be capable, immediately upon establishment of a Communications Link with GSME of receiving GSME Constant Data, GSME Configuration Data, GSME Operational Data and (with the exception of the GSME Cumulative and Historical Value Store and the GSME Profile Data Log) receiving updates of any changes in that data. 485 486 487 488 489 Where changes have been made to the GSME Billing Data Log in accordance with the timetable set out in the GSME Billing Calendar, the GPF shall be capable of generating and sending an Alert containing the most recent entries of the GSME Tariff TOU Register Matrix, the GSME Tariff Block Counter Matrix and the GSME Consumption Register in the GSME Billing Data Log. 490 491 4.5.3 Type 1 Device and Type 2 Device Information Provision from the GPF via the HAN Interface 492 493 494 495 496 The GPF shall be capable, immediately upon establishment of a Communications Link with a Type 1 Device (as set out in Section 4.4.2.2.2) and a Type 2 Device (as set out in Section 4.4.2.2.3), of providing the data annotated [INFO] set out in Section 4.6 and in addition the following data from the GPF GSME Proxy Log(4.6.3.9) to the Type 1 Device or the Type 2 Device as applicable (with timely updates of any changes to all such data): 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 i. ii. iii. iv. v. vi. vii. viii. ix. x. xi. xii. xiii. xiv. xv. xvi. xvii. xviii. xix. xx. xxi. xxii. Accumulated Debt Register; Active Tariff Price; Calorific Value; Consumption Register; Contact Details; Conversion Factor; Currency Units; Customer Identification Number; Debt Recovery per Payment; Debt Recovery Rates [1 … 2]; Debt Recovery Rate Cap; Disablement Threshold; Emergency Credit Balance; Emergency Credit Limit; Emergency Credit Threshold; Low Credit Threshold; Meter Balance; Meter Point Reference Number (MPRN); Non-Disablement Calendar; Payment Debt Register; Payment Mode; Profile Data Log; Version 1.47 18 November 2015 Page 19 DRAFT 519 520 521 522 523 524 525 526 527 528 529 xxiii. xxiv. xxv. xxvi. xxvii. xxviii. xxix. xxx. xxxi. xxxii. xxxiii. CHTS Standing Charge; Supplier Message; Supply State; Tariff Block Counter Matrix; Tariff Block Price Matrix; Tariff Switching Table; Tariff Threshold Matrix; Tariff TOU Price Matrix; Tariff TOU Register Matrix; Time Debt Registers [1 … 2]; and Payment-based debt payments in the Billing Data Log. 530 4.5.4 GPF Interface Commands 531 532 533 The GPF shall be capable of executing the Commands set out in this Section 4.5.4. The GPF shall be capable of logging all Commands received and Outcomes in the GPF Event Log(4.6.3.8). 534 535 536 537 The GPF shall be capable of executing Commands immediately on receipt (‘immediate Commands’) and where specified in the Great Britain Companion Specification at a future date (‘future dated Commands’). A future dated Command shall include the UTC date and time at which the Command shall be executed by the GPF. 538 539 540 541 542 The GPF shall be capable of cancelling a future dated Command. A future dated Command shall be capable of being cancelled by an Authorised party, subject to GPF Role-based Access Control (as set out in Section 4.4.6.2.6). The GPF shall be capable of generating and sending a Response acknowledging that a future-dated Command has been successfully cancelled. 543 4.5.4.1 544 545 A Command to add Security Credentials for a Type 1 Device, Type 2 Device or GSME to the GPF Device Log(4.6.2.3). 546 In executing the Command, the GPF shall be capable of: i. ii. Add GPF Device Security Credentials 547 548 549 550 verifying the Security Credentials; generating and sending an Alert to this effect, including details of the revised GPF Device Log(4.6.2.3), via the WAN Interface; and recording the Command and Outcome to the GPF Security Log(4.6.3.11). iii. 551 4.5.4.2 552 A Command to clear all entries from the GPF Event Log(4.6.3.8). 553 554 The GPF shall be capable of logging that the Command has been executed in the GPF Security Log(4.6.3.11). 555 4.5.4.3 556 557 A Command to generate a Public-Private Key Pair and issue a corresponding Certificate Signing Request. 558 4.5.4.4 559 560 A Command to read the value of one or more of the GPF configuration data items set out in Section 4.6.2. 561 562 In executing the Command, the GPF shall be capable of sending such value(s) in a Response. Clear GPF Event Log Issue GPF Security Credentials Read GPF Configuration Data Version 1.47 18 November 2015 Page 20 DRAFT CHTS 563 4.5.4.5 564 565 A Command to read the value of one or more of the GPF constant data items set out in Section 4.6.1. 566 567 In executing the Command, the GPF shall be capable of sending such value(s) in a Response. 568 4.5.4.6 569 570 A Command to read the value of one or more of the GPF operational data items set out in Section 4.6.3. 571 572 In executing the Command, the GPF shall be capable of sending such value(s) in a Response. 573 4.5.4.7 574 A Command to remove Security Credentials for a Device from the GPF Device Log(4.6.2.3). 575 In executing the Command the GPF shall be capable of: i. Read GPF Constant Data Read GPF Operational Data Remove GPF Device Security Credentials 576 577 578 generating and sending an Alert to this effect, including details of the revised GPF Device Log(4.6.2.3), via the WAN Interface; and recording the Command and Outcome to the GPF Security Log(4.6.3.11). ii. 579 4.5.4.8 580 A Command to replace GPF Security Credentials(4.6.2.4) held within the GPF. 581 In executing the Command the GPF shall be capable of: Replace GPF Security Credentials maintaining the Command’s Transactional Atomicity; and recording the Command and Outcome to the GPF Security Log(4.6.3.11). 582 583 i. ii. 584 4.5.4.9 585 A Command to restore the details in the GPF Device Log(4.6.2.3). 586 587 In executing the Command, the GPF shall be capable of recording the Command and Outcome to the GPF Security Log(4.6.3.11). 588 4.5.4.10 Restrict GPF Data 589 590 591 A Command to restrict provision to Type 1 Devices and Type 2 Devices of all items of Personal Data stored in the GPF which have a UTC date and time stamp prior to the date and time stamp specified in the Restrict GPF Data Command. 592 4.6 Data Requirements 593 594 This section describes the minimum information which the CH shall be capable of holding in its Data Store. 595 4.6.1 Constant Data 596 Describes data that remains constant and unchangeable at all times. 597 4.6.1.1 598 599 A globally unique identifier used to identify the CHF based on the EUI-64 Institute of Electrical and Electronics Engineers (IEEE) standard. 600 4.6.1.2 601 An identifier used to identify the manufacturer of the CH. 602 4.6.1.3 603 An identifier used to identify the model of the CH. Restore GPF Device Log CHF Identifier CH Manufacturer Identifier Model Type Version 1.47 18 November 2015 Page 21 DRAFT CHTS 604 4.6.1.4 605 606 A globally unique identifier used to identify the GPF based on the EUI-64 Institute of Electrical and Electronics Engineers (IEEE) standard. 607 4.6.2 Configuration Data 608 Describes data that configures the operation of various functions of the CH. 609 4.6.2.1 610 611 The Security Credentials for each of the Type 1 Devices, Type 2 Devices, GSME, ESME and GPF with which the CHF can establish Communications Links. 612 4.6.2.2 613 614 The Security Credentials for the CHF and parties Authorised to establish Communications Links with it. 615 4.6.2.3 616 617 The Security Credentials for each of the Type 1 Devices and Type 2 Devices with which the GPF can establish Communications Links. 618 4.6.2.4 619 620 The Security Credentials for the GPF and parties Authorised to establish Communications Links with it. 621 4.6.3 Operational Data 622 Describes data used by the functions of the CHF and GPF for output of information. 623 4.6.3.1 624 The Clock’s date and time (in UTC and Local Time). 625 4.6.3.2 626 627 A store holding, for each Device in the CHF Device Log(4.6.2.1), the UTC date and time of the last Communications Link established with the CHF. 628 4.6.3.3 629 630 631 A log capable of storing one hundred UTC date and time stamped entries of non-security related information for diagnosis and auditing, arranged as a circular Buffer such that when full, further writes shall cause the oldest entry to be overwritten. 632 4.6.3.4 633 The active version of Firmware of the CHF and the GPF. 634 4.6.3.5 635 636 637 A log capable of storing one hundred UTC date and time stamped entries of security related information for diagnosis and auditing, arranged as a circular Buffer such that when full, further writes shall cause the oldest entry to be overwritten. 638 4.6.3.6 639 A store capable of holding the following values: 640 641 642 643 644 645 i. ii. iii. GPF Identifier CHF Device Log CHF Security Credentials GPF Device Log GPF Security Credentials CHF Date and Time CHF Communications Store CHF Event Log CH Firmware Version CHF Security Log GPF Cumulative and Historical Value Store [INFO] 9 Days of Energy Consumption comprising the current Day and the prior 8 Days, in kWh and Currency Units; 6 Weeks of Energy Consumption comprising the current Week and the prior 5 Weeks, in kWh and Currency Units; and 14 months of Energy Consumption comprising the current month and the prior 13 months, in kWh and Currency Units. Version 1.47 18 November 2015 Page 22 DRAFT CHTS 646 4.6.3.7 647 648 649 A log capable of storing 731 date stamped entries of Gas Consumption arranged as a circular Buffer such that when full, further writes shall cause the oldest entry to be overwritten. 650 4.6.3.8 651 652 653 A log capable of storing one hundred UTC date and time stamped entries of non-security related information for diagnosis and auditing, arranged as a circular Buffer such that when full, further writes shall cause the oldest entry to be overwritten. 654 4.6.3.9 655 656 657 A log capable of storing UTC date and time stamped entries of the GSME Constant Data, GSME Configuration Data and GSME Operational Data except for the following SMETS items: 658 659 660 661 662 663 664 665 666 i. ii. iii. iv. v. vi. vii. viii. ix. GPF Daily Gas Consumption Log [INFO] GPF Event Log GPF GSME Proxy Log Alerts Configuration Settings; Device Log; GSME Security Credentials; GSME Identifier; Public Key Security Credentials Store; Supply Depletion State; Supply Tamper State; Uncontrolled Gas Flow Rate; and Network Data Log. 667 4.6.3.10 GPF Profile Data Log [INFO] 668 669 670 A log capable of storing a minimum of 13 months of UTC date and time stamped half hourly Gas Consumption data arranged as a circular Buffer such that when full, further writes shall cause the oldest entry to be overwritten. 671 4.6.3.11 GPF Security Log 672 673 674 A log capable of storing one hundred UTC date and time stamped entries of security related information for diagnosis and auditing, arranged as a circular Buffer such that when full, further writes shall cause the oldest entry to be overwritten. Version 1.47 18 November 2015 Page 23 DRAFT CHTS 675 5 Glossary 676 Accumulated Debt Register 677 678 The information held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 679 Active Tariff Price 680 681 The information held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 682 Alert 683 684 A message generated by a Device including in response to a problem or the risk of a potential problem. 685 Authentication 686 687 The method used to confirm the identity of entities or Devices wishing to communicate and ‘Authenticated’ and ‘Authenticity’ shall be construed accordingly. 688 Authorisation 689 690 The process of granting access to a resource and ‘Authorised’ shall be construed accordingly. 691 Block Pricing 692 693 A pricing scheme used in conjunction with Time-of-use Pricing where Price varies based on Consumption over a given time period. 694 Buffer 695 An area of the CH capable of storing information for Buffering. 696 Buffering 697 Temporary storage of information pending it being forwarded via the HAN or WAN Interface. 698 Calorific Value 699 700 The information held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 701 Certificate 702 703 An electronic document that binds an identity, and possibly other information, to a Public Key. 704 Certificate Signing Request 705 A message requesting the issue of a Certificate by a Certification Authority. 706 Certification Authority (CA) 707 A trusted entity which issues Certificates. 708 CESG 709 The UK Government's national technical authority for information assurance. 710 Clock 711 A timing mechanism that has a minimum resolution of 1 second. 712 Command 713 An instruction to perform a function received or sent via any interface. Version 1.47 18 November 2015 Page 24 DRAFT CHTS 714 Commercial Product Assurance Security Characteristic for GB Smart Metering 715 716 717 The document forming part of the Smart Energy Code describing the requirements for evaluation and certification of Communications Hubs under CESG’s Commercial Product Assurance scheme. 718 Communications Hub Function (CHF) 719 720 The functionality in the CH specific to its operation as a bridge between the WAN Interface and HAN interface. 721 Communications Link 722 723 724 The exchange of Commands, Responses, Alerts and other information between a system or Device and another system or Device which is independent of the transport mechanism used. 725 Confidentiality 726 727 The state of information, in transit or at rest, where there is assurance that it is not accessible by Unauthorised parties through either unintentional means or otherwise. 728 Consumer 729 A person who lawfully resides at the Premises that is being Supplied. 730 Consumption 731 Gas Consumption or Electricity Consumption information. 732 Consumption Register 733 734 The information held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 735 Contact Details 736 737 The information held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 738 Conversion Factor 739 740 The value held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 741 Critical Command 742 743 Those Commands which relate to Supply being affected, financial fraud or the compromise of the security of Devices in Consumer Premises. 744 Cryptographic Algorithm 745 746 747 An algorithm for performing one or more cryptographic functions which may include: Encryption, Decryption, Digital Signing or Hashing of information, data, or messages; or exchange of Security Credentials. 748 Currency Units 749 The units of monetary value in major and minor units. 750 Customer Identification Number 751 752 The information held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 753 Data and Communications Company Version 1.47 18 November 2015 Page 25 DRAFT CHTS 754 755 756 The holder of the licence for the provision of a smart meter communication service granted pursuant to section 6(1)(f) or 6(1A) of the Electricity Act 1989 or section 7AB of the Gas Act 1986. 757 Data Integrity 758 759 The state of data where there is assurance that it has not been altered by Unauthorised parties. 760 Data Store 761 An area of the CH capable of storing information for future retrieval. 762 Day 763 The period commencing 00:00:00 Local Time and ending at the next 00:00:00. 764 Debt Recovery per Payment 765 766 The information held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 767 Debt Recovery Rates [1 … 2] 768 769 The information held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 770 Debt Recovery Rate Cap 771 772 The information held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 773 Debt to Clear 774 775 The information held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 776 Decryption 777 778 The process of converting Encrypted information by an Authorised party to recover the original information and like terms shall be construed accordingly. 779 Device 780 GSME, ESME, a GPF, a CHF, a Type 1 Device or a Type 2 Device. 781 Device Commissioning Alert 782 An Alert sent by a Device as part of the process of bringing that Device into operation. 783 Digital Signature 784 785 786 787 The information appended to a message which is created using the sender’s Private Key, can be verified using the Public Key contained in the sender’s Certificate and provides the receiver with assurance that the sender is who they claim to be, the message is as sent by the sender and that the sender sent the message. 788 Digital Signing 789 The creation of a Digital Signature. 790 Disablement Threshold 791 792 The information held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 793 Electricity Consumption 794 As described at section 5 in the Smart Metering Equipment Technical Specifications. Version 1.47 18 November 2015 Page 26 DRAFT CHTS 795 Elliptic Curve DSA 796 797 The Elliptic Curve Digital Signature Algorithm forming part of the NSA Suite B standard (see http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml). 798 Elliptic Curve DH 799 800 The Elliptic Curve Diffie–Hellman Algorithm forming part of the NSA Suite B standard (see http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml). 801 Emergency Credit Balance 802 803 The information held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 804 Emergency Credit Limit 805 806 The information held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 807 Emergency Credit Threshold 808 809 The information held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 810 Encryption 811 812 The process of converting information in order to make it unintelligible other than to Authorised parties and like terms shall be construed accordingly. 813 Energy Consumption 814 The amount of gas in kWh Supplied to the Premises. 815 ESME 816 Electricity Smart Metering Equipment as described in the SMETS. 817 Firmware 818 The embedded Software programmes and / or data structures that control Devices. 819 Gas Consumption 820 821 The volume of gas in cubic metres (m3) Supplied to the Premises and “Consumed” shall be construed accordingly. 822 Gas Proxy Function (GPF) 823 824 The functionality in the CH specific to its operation as a store of GSME data and associated data. 825 Great Britain Companion Specification 826 827 828 829 The document forming part of the Smart Energy Code describing the nature of Communications Links that the CH must be capable of forming via the HAN Interface and the WAN Interface. The current version of Great Britain Companion Specification can be found here: https://www.smartenergycodecompany.co.uk/sec/the-developing-sec 830 GSME 831 Gas Smart Metering Equipment as described in the SMETS. 832 GSME Activate Emergency Credit Command 833 834 A Command to activate Emergency Credit as described at section 4 in the Smart Metering Equipment Technical Specifications 835 GSME Add Credit Command Version 1.47 18 November 2015 Page 27 DRAFT CHTS 836 837 A Command to accept credit to be applied to GSME as described at section 4 in the Smart Metering Equipment Technical Specifications 838 GSME Billing Data Log 839 840 The data held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 841 GSME Calorific Value 842 843 The data held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 844 GSME Configuration Data 845 846 The data held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 847 GSME Consumption Register 848 849 The data held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications 850 GSME Constant Data 851 852 The data held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 853 GSME Conversion Factor 854 855 The data held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 856 GSME Cumulative and Historical Value Store 857 858 The data held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 859 GSME Cumulative Current Day Value Store 860 861 The data held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 862 GSME Operational Data 863 864 The information held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 865 GSME Profile Data Log 866 867 The information held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 868 GSME Tariff Block Counter Matrix 869 870 The information held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications 871 GSME Tariff TOU Register Matrix 872 873 The information held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications 874 Hashing 875 876 A repeatable process to create a fixed size and condensed representation of a message of any arbitrary data. Hash and like terms shall be construed accordingly. 877 Home Area Network Interface (HAN Interface) Version 1.47 18 November 2015 Page 28 DRAFT CHTS 878 879 A component of the CH that is capable of sending and receiving information to and from other Devices. 880 Inter-PAN 881 A lower-layer communications mechanism. 882 Intimate Physical Interface 883 884 A standardised interface defined by the Data and Communications Company, which includes provision for the DC power supply to the CH. 885 Key 886 Data used to determine the output of a cryptographic operation. 887 Key Agreement 888 A means to calculate a shared Key between two parties. 889 Local Time 890 The UTC date and time adjusted for British Summer Time. 891 Low Credit Threshold 892 893 The information held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 894 Message Authentication 895 896 The process by which the receiver of a message is provided with assurance that the sender is who they claim to be and that the message is in the form originally sent. 897 Meter Balance 898 899 The information held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 900 Meter Point Reference Number (MPRN) 901 902 The information held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 903 Non-Disablement Calendar 904 905 The information held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 906 Outcome 907 The result of executing a Command, expressed as success or failure. 908 Payment Debt Register 909 910 The information held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 911 Payment Mode 912 913 The information held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 914 Personal Data 915 916 Any information comprising Personal Data as such term is defined in the Data Protection Act 1998 at the date the CHTS is brought into force. 917 Premises Version 1.47 18 November 2015 Page 29 DRAFT CHTS 918 The premises which is Supplied. 919 Price 920 921 The value held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 922 Private Key 923 924 The key in a Public-Private Key Pair which must be kept secure by the entity to which it relates. 925 Profile Data Log 926 927 The information held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 928 Public Key 929 The key in a Public-Private Key Pair which can be distributed to other parties. 930 Public-Private Key Pair 931 Two mathematically related numbers that are used in Cryptographic Algorithms. 932 Random Number Generator 933 934 A component used to generate a sequence of numbers or symbols that lack any predictable pattern. 935 Replay Attack 936 937 A form of attack on a Communications Link in which a valid information transmission is repeated through interception and retransmission. 938 Response 939 940 Sent on, or received from the User Interface or HAN Interface or any other interface containing information in response to a Command. 941 Role 942 The entitlement of a party to execute one or more Commands. 943 SECAS 944 The Smart Energy Code Administrator and Secretariat. 945 Secure Perimeter 946 A physical border surrounding the CH. 947 Security Credentials 948 Information used to identify and / or Authenticate a Device, party or system. 949 Sensitive Event 950 Each of the following events: 951 952 i. ii. a failed Authentication or Authorisation; and a change in the executing Firmware version. 953 SHA-256 954 955 The Hashing algorithm of that name approved by the NIST (see http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html). 956 Smart Metering Equipment Technical Specifications (SMETS) Version 1.47 18 November 2015 Page 30 DRAFT CHTS 957 958 The document brought into force by the Secretary of State to describe the minimum capabilities of equipment installed to satisfy the roll-out licence conditions. 959 Smart Metering Home Area Network 960 A communications network allowing the exchange of information between Devices. 961 Software 962 The software programmes and / or data structures that control the GPF. 963 Standing Charge 964 965 The value held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 966 Supplier Message 967 968 The information held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 969 Supply 970 The supply of gas to Premises for GSME and ‘Supplied’ shall be construed accordingly. 971 Supply State 972 973 The information held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 974 Tariff Block Counter Matrix 975 976 The matrix held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 977 Tariff Switching Table 978 979 The information held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 980 Tariff Threshold Matrix 981 982 The information held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 983 Tariff TOU Price Matrix 984 985 The matrix held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 986 Tariff TOU Register Matrix 987 988 The matrix held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 989 Time Debt Registers [1 … 2] 990 991 The information held on GSME as described at section 4 in the Smart Metering Equipment Technical Specifications. 992 Transactional Atomicity 993 The type and order of the constituent parts of a Command. 994 Trusted Source 995 A source whose identity is confidentially and reliably validated. 996 Type 1 Device Version 1.47 18 November 2015 Page 31 DRAFT 997 998 999 CHTS A Device, other than GSME, ESME, Communications Hub Function or Gas Proxy Function, that stores and uses the Security Credentials of other Devices for the purposes of communicating with them via its HAN Interface. 1000 Type 2 Device 1001 1002 A Device that does not store or use the Security Credentials of other Devices for the purposes of communicating with them via its HAN Interface. 1003 Unauthorised 1004 Not Authorised. 1005 Unauthorised Physical Access 1006 Unauthorised access to the internal components of the CH through its Secure Perimeter. 1007 UTC 1008 Coordinated Universal Time. 1009 Wide Area Network (WAN) Interface 1010 1011 A component of CH that is capable of sending and receiving information via the Wide Area Network Provider. 1012 Wide Area Network Provider 1013 The organisation providing communications over the WAN Interface. 1014 Week 1015 1016 The seven day period commencing 00:00:00 Monday Local Time and ending at 00:00:00 on the immediately following Monday. 1017 ZigBee Smart Energy Profile (SEP) Version 1.2 1018 1019 The ZigBee Smart Energy Profile Specification 1.2a v1.0 (reference 07-5356r19: http://zigbee.org/About/GBCSPartner.aspx). 1020 Version 1.47 18 November 2015 Page 32 DRAFT 1021 CHTS This page is intentionally left blank. Version 1.47 18 November 2015 Page 33 Crown copyright 2015 Department of Energy & Climate Change 3 Whitehall Place London SW1A 2AW www.gov.uk/decc URN 15D/502