Version 1: Release Note 28 November 2014


Constructing the @ProvideDeviceCertificateFromDevice.CommandPayload and @ProvideDeviceCertificateFromDevice.ResponsePayload



Download 4.8 Mb.
Page188/258
Date03.04.2021
Size4.8 Mb.
1   ...   184   185   186   187   188   189   190   191   ...   258

Constructing the @ProvideDeviceCertificateFromDevice.CommandPayload and @ProvideDeviceCertificateFromDevice.ResponsePayload


  1. @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.

    1. Attribute name

    1. Data Type

    1. Value (blank cells mean the command specific value is derived by the encoding process)

    1. Mandatory, OPTIONAL or DEFAULT value

    1. Notes

    1. @ProvideDeviceCertificateFromDevice.CommandPayload

    1. SEQUENCE







    1. keyUsage

    1. BIT STRING

    1. Either digitalSignature (0) only,

    2. Or keyAgreement (4) only

    1. Mandatory

    1. Only one or the other is valid

  2. Table 13.6.7a: @ProvideDeviceCertificateFromDevice.CommandPayload population

  3. @ProvideDeviceCertificateFromDevice.ResponsePayload shall have the structure defined in Section 13.6.6, and the Device constructing the Response shall populate with values according to Table 13.6.7b.

    1. Attribute name

    1. Data Type

    1. Value (blank cells mean the command specific value is derived by the encoding process)

    1. Mandatory, OPTIONAL or DEFAULT value

    1. Notes

    1. @ProvideDeviceCertificateFromDevice.ResponsePayload

    1. CHOICE







    1. Certificate

    1. See IETF RFC 5912

    1. The Device Certificate provided pursuant to Section 13.6.4

    1. Mandatory

    1. Mandatory if certificate successfully produced

    1. provideDeviceCertResponseCode

    1. INTEGER

    1. Shall be populated according to the processing defined in Section 13.5.4

    1. Mandatory

    1. Mandatory if certificate is not successfully produced

  4. Table 13.6.7b: @ProvideDeviceCertificateFromDevice.ResponsePayload population
    1. Pair-wise Authorisation of Devices

      1. Introduction to pair-wise Authorisation of Devices - informative

        1. The role of pair-wise Authorisation - informative


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.



        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   ...   184   185   186   187   188   189   190   191   ...   258




The database is protected by copyright ©essaydocs.org 2020
send message

    Main page