Constructing the @ProvideDeviceCertificateFromDevice.CommandPayload and @ProvideDeviceCertificateFromDevice.ResponsePayload
@ProvideDeviceCertificateFromDevice.CommandPayload shall have the structure defined in Section 13.6.6 and the Remote Party constructing the Command shall populate with values according to Table 13.6.7a.
Value (blank cells mean the command specific value is derived by the encoding process)
This Section 13.7 includes the Use Cases related to the Authorisation (and the removal of Authorisation) for pair-wise, secure application layer interaction between two Devices on the same SMHAN. It also covers the related Use Cases for backing up and restoring the GPF Device Log.
The process of authorising two Devices to communicate is referred to as ‘Joining’32. Removal of such authorisation is referred to as ‘Un-joining’. Correspondingly, Remote Party Commands are specified in this Section 13.7 for instructing Devices that they are to ‘Join’ or ‘Unjoin’.
In line with the SMETS and CHTS Device Log requirements, two Devices on a HAN must only be capable of interacting at the application layer if they are currently Joined. They must not be capable of interacting if (1) they have never been Joined or (2) they have been Unjoined.
The application layer interactions between Devices on the same SMHAN must conform to the Device Based Access Controls (DBAC) as defined in Section 13.7.3. For example, an ESME must not be capable of processing an ‘Enable Supply’ Command from an IHD or an HCALCS.
It is a precondition of Joining that both Devices have been ‘White-listed’ on to the HAN (as per Use Case ‘CCS01 Add Device to CHF Device log’) so that they are able to communicate over the HAN at the network layer (and so have network access). The GPF may be configured to be in the CHF’s Device Log at manufacture. A Device on a white-list can be removed from the white-list. It must then be unable to communicate over the HAN, and so unable to interact at the application layer with any Devices to which it was ‘Joined’.
In SMETS terminology:
the CHF’s Device Log holds the list of currently white-listed Devices on the SMHAN; and
the Device Log on an ESME, GSME, GPF or Type 1 Device holds the Entity Identifiers, Device Types and related Security Credentials of other Devices on the HAN to which the Device is currently Joined (and so Authorised to interact with at an application layer).
The process of white-listing a Device and its subsequently obtaining network access establishes a shared secret key between the Device and the Communications Hub. The Gas Proxy Function, which is part of the Communications Hub, uses this shared secret key, combined with a Device being entered in to its Device Log, for application layer authorisation.
IHDs and other Type 2 Devices are not required to have a Device Log (as defined in SMETS). They are required to store security and related details of the Devices to which they are Joined as required by ZSE however (otherwise they would be cryptographically unable to understand the information being sent to them by the Joined Devices).
IHDs and other Type 2 Devices can only read application layer information from Devices to which they are Joined (either by requesting the information from the Device or by receiving information published by the Device). When a PPMID is joined to a GPF the PPMID can only read information from the GPF to which it is Joined.
When other types of Device are Joined (e.g. HCALCS, PPMID), they can also exchange Commands and Responses at the application layer. For example, an ESME that is Joined to an HCALCS can send a Command to the HCALCS to turn its switch on and the HCALCS can send a Response saying whether it has done that. A PPMID can send an ‘enable supply’ Command to an ESME etc.