This Section 13.1.2 summarises the GBCS requirements in relation to storing, replacing and providing details of Remote Party Security Credentials. The use of such credentials to control access to Device functions is detailed in other sections of the GBCS and in relevant Use Cases.
A Remote Party Security Credential is a Public Key Certificate which securely binds together the Remote Party’s identity with a Public Key along with related information, including what that Public Key can be used for and over what time period it is valid. The corresponding Private Key should be securely controlled solely by the Remote Party and known only to that Remote Party.
The purpose of storing each Remote Party Public Key (and related details) on a Device is so that each Public Key can act as a ‘Trust Anchor’ for the Device. The Device uses these Trust Anchors to check cryptographically whether Remote Party Messages can be trusted or not (and so whether it should act on them or not). Thus, all of a Device’s Trust Anchors must be populated.
Trust Anchors need to be capable of being replaced during a Device’s operational life for a number of reasons including:
the Certificate’s expiry (Organisation Certificates will only be valid for a fixed period of time);
the Known Party transferring control to a different organisation (for example on Change of Supplier);
there being concerns that someone other than the Known Party has use of, or may have use of, the corresponding Private Key.
Thus, an ‘Update Security Credentials Command’ must be supported by all Devices that rely on Remote Party Security Credentials to act as Trust Anchors. Related, all such Devices need to support a ‘Provide Security Credential Details’ Command, so that Remote Parties can be sure which Devices need to have credentials replaced.
However, if these Trust Anchors could be replaced without proper protections, attackers could take over control of Devices or the Devices could be rendered inoperable. Thus, a Device needs to do thorough checks before applying an Update Security Credentials Command. The checks that the Device can and must do vary dependent on the reasons for the change. Thus, Section 13.2.1 lays out a number of different checks and the circumstances in which corresponding Commands may be issued. Broadly the following checks are carried out by the Device:
is the Command properly formed?
is the Command for the Device that it has been delivered to, and is the Command one that it has not processed previously?
are the Remote Parties apparently authorising the Command allowed to authorise it?
was the Command Authorised by the Remote Parties that it appears to be Authorised by?
were the Certificates in the payload of the Command issued by properly Authorised parties, specifically by Certification Authorities Authorised (by ‘root’ under the APKI) to issue GB Smart Metering Certificates?
Only when a Device has successfully undertaken all five sets of checks should it action the Update Security Credentials Command.
Other Critical Commands only have to complete the first four categories of check.