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).
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.
Introduction – informative
This Section 4.1 is informative and summarises Section 4.
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;
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 22.214.171.124 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.