Version 1: Release Note 28 November 2014

Download 4.8 Mb.
Size4.8 Mb.
1   ...   11   12   13   14   15   16   17   18   ...   258


X || Y shall mean the concatenation of the two octet strings X and Y.

For example:

X = 0xCAFE

Y = 0xBEEF


      1. Encoding and length of variable length unsigned integers

Encoding(X) shall be the encoding of a variable size unsigned integer X as follows:

  • if 0

  • if 128<= X <32,768, then Encoding(X) is a an octet string composed of the concatenation 0x82 || Y, where Y is two octets in length and has a value equal to the two’s complement representation of the value X; or

  • if 32,768<= X <8,388,608, then Encoding(X) is a an octet string composed of the concatenation 0x83 || Y, where Y is three octets in length and has a value equal to the two’s complement representation of the value X.

Len(Encoding(X)) shall be the length in octets of Encoding(X), so shall be either 1 (X<128), 3 (128<= X <32768) or 4 (32,768<= X <8,388,608).
      1. GeneralizedTime

The GeneralizedTime ASN.1 type used in this GBCS shall be a UTC Time with a resolution of one second. See Section 46 of the ASN.1 specification for format.
  1. Security

    1. Introduction – informative

This Section 4.1 is informative and summarises Section 4.

Section 4.2 lays out security provisions that are common across Messages, specifically stating that:

  • at the application layer, all Messages must have integrity and authenticity protections, Critical Messages must have non-repudiation protections and some parts of Messages must have Confidentiality protections applied to specific data content; and

  • ZSE protections will be relied upon when Devices within the same Smart Metering Home Area Network (SMHAN) communicate with each other.

Section 4.3 lays out security provisions that are common across Remote Party Messages, specifically:

  • Identifiers, Counters and Protection Against Replay: lays out requirements in relation to identifiers, counters and their use in Protection Against Replay;

  • Security Credentials: lays out requirements for all Devices, except for Type 2 Devices, to:

        • have Public-Private Key Pairs, and to make their Public Keys available; and

        • have Trust Anchor Cells, including those which are storage areas within a Device, capable of holding Public Key Security Credentials for a number of Remote Parties, with the set of Remote Parties being derived from the functionality the Device supports; and

  • Cryptographic Primitives and their Usage: lays out requirements for Cryptographic Algorithms and their usage, in relation to Remote Party Messages.

Note that the cryptographic protections are intentionally independent of whether a Message Payload is structured according to the ZSE, ASN.1 or DLMS COSEM standards. This means that Suppliers, Network Operators, the Access Control Broker and Other Users who may communicate with Devices need only implement cryptographic requirements in one way, regardless of the type of Device they are communicating with.

The same requirements for security apply regardless of whether a Message is delivered by the Wide Area Network (WAN), SMHAN, Hand Held Terminal (HHT) or local interface. Note that, for Prepayment Top Up, there are a number of different Messages. The content of each particular Message will always be processed in the same way regardless of delivery mechanism. The governance and structures to ensure uniqueness of identifiers are set out in the Smart Energy Code (SEC) and SMETS, and are outside the scope of the GBCS.

A single Originator Counter can be used for the whole of a Remote Party Organisation (e.g. by that Party counting small enough time intervals). A separate counter per Device is not required.

The Supplementary Originator Counter as specified in Section is required where the corresponding Response has to be cryptographically protected (by way of Encryption, a MAC, or both), to the Supplementary Remote Party. In all other cases, the Response is protected back to the Access Control Broker.

Smart Metering entities make extensive use of a range of Counters as part of the unique identification of Smart Metering Messages. Counters are also a key component used to support Protection Against Replay functionality. An overview of each of these counters and their use is included as Section 23.

    1. Directory: government -> uploads -> system -> uploads -> attachment data -> file
      file -> Remove this if sending to pagerunnerr Page Title Light Rail Security Recommended Best Practice
      file -> 8 Section 1 : Sport
      file -> Notice of exercise of additional powers of seizure under Sections 50 or 51 of the Criminal Justice and Police Act 2001
      file -> Home office circular 004/2014 Powers to search for and seize invalid travel documents in Schedule 8 to the Anti-social Behaviour, Crime and Policing Act 2014
      file -> Consultation on the Royal Parks and Other Open Spaces (Amendment) (No. 2) Regulations 2012
      file -> Crown copyright 2012
      file -> This is the Report to Government by the Film Policy Review Panel The brief
      file -> Impact Assessment (IA)
      file -> Dcms/Wolfson Museums and Galleries Improvement Fund a public-Private Partnership (2002-2010)

      Share with your friends:
1   ...   11   12   13   14   15   16   17   18   ...   258

The database is protected by copyright © 2020
send message

    Main page