IEEE 2030.5 CA Types

What is IEEE 2030.5

IEEE 2030.5 is a standard developed by the Institute of Electrical and Electronics Engineers (IEEE) to facilitate communication and interoperability in the Smart Grid ecosystem. Originally known as Smart Energy Profile 2.0 (SEP2), this standard provides a framework for secure, end-to-end information exchange between utilities, energy service providers, and customer-premises devices.

Manufacturing PKI

A manufacturing PKI is the set of certificate authorities (CAs) that issue certificates to devices during the manufacturing process. The Manufacturing PKI consists of the following CA types:

Smart Energy Root CA (SERCA)

This is the top level CA for the manufacturing PKI. A SERCA may issue device certificates on behalf of one or more manufacturers. In doing this Manufactures can build a trust chain to a common root ensuring interoperability of trust between manufacturers.

A SERCA may issue MCA certificate and MICA certificates to authorized vendors. A SERCA may also issue device certificates on behalf of one or more manufacturers.

Manufacturers CA (MCA)

An intermediate CA that may be operated by a specific manufacturer for the purpose of issuing (signing) CAs for that manufacturer or can be operated by a Commercial CA on behalf of the Manufacturer.

MCAs may only be used to Issue MICAs

Manufacturing Issuing CA (MICA)

An Issuing CA that issues certificates to devices during the manufacturing process and as such are generally operated by the manufacturer to ensure availability of the service as part of the manufacturing process.

Devices and Certificates

IEEE 2030.5 Devices can only have one SERCA in their certificate path and they should store at least the public keys of all SERCAs and include their certificates where possible. This allows the device to verify the chain of signatures for any device leading up to any one of the roots.

Manufacturing PKI Hierarchy Examples

An example of a full PKI hierarchy is shown in the diagram below. This example shows all the possible CAs within the hierarchy

Figure 1: Manufacturing PKI Heirarchy

The diagram below shows the possible validation paths within the hierarchy. Note that only the SERCA or the MICA can issue device certificates

Figure 2: Valid Certificate Paths

Commercial Model

Option 1:

The commercial model for the management of an MPKI provides two distinct options depending on if the Manufacturer is to manage PKI certification authorities.

Option one, shown in the diagram below, shows the Commercial CA managing and operating both the SERCA and the MCA for the manufacturer.

Where an MCA was not required in this option the MICA would be issued directly from the SERCA.

The benefits of this option to the manufacturer is that they are only required to ensure that the MICA CA is maintained and operational for the issuance of the certificates required as part of the manufacturing process. When the Manufacturer requires a new MICA they only need to establish the new MICAs certificate signing request and submit it to their hosted MCA to sign and they are ready issue certificates from the new MICA.

Figure 3: Boundary Option 1

Option 2:

Boundary option 2 allows the SERCA as the root of trust to be established and maintained for the Manufacturer by a commercial CA provider.

The manufacturer is then responsible for the maintenance and operation of both the MCA and the MICA to ensure their availability as part of the manufacturing process for the issuance of device certificates and to ensure that the MCA is available to sign certificates for a new MICA when there is a requirement to establish a new instance.

Figure 4: Boundary Option 2

Consortium Boundary Option

Where there is a requirement to establish trust between a group of manufacturers a MPKI can be establish that forms a hierarchy similar to the option PKI shown in the diagram below.

Figure 5: Consortium Boundary Options

By establishing a shared SERCA within a commercial CA environment manufacturers are able to manufacture devices that are able to be trust directly other manufactures devices without having to install additional SERCA public keys and certificates to allow that trust to be established.

This option also allows other manufacturers to join and be trusted within the consortium.

Additional benefits are reaped by the customers of the manufacturers from this model in that they do not need to determine the ability for the devices to be trusted by others within their established fleet providing them the ability to recommend devices produced within the trust realm of the MPKI to their customers knowing there will be minimal overheads to manage or trust those devices.

Certificate Classes

IEEE 2030.5

Device Certificates

A device certificate is issued to a “native” IEEE 2030.5 device during manufacture for operational purposes.

Device Test Certificates

Issued to a Device during manufacture for test purposes

Additional certificates for IEEE 2030.5 Devices

One or more OPTIONAL TLS server certificates issued by non-IEEE 2030.5 CAs to IEEE 2030.5 devices such as gateways or Energy Servies Interfaces (ESI) that allow a utility or service provider to communicate with a home, these TLS certificates are normally issued by non-IEE 2030.5 CAs

Non Native Entities

There are three generic Certificate types that may be used or seen in an IEEE 2030.5 environment. These certificates are issued from CAs outside the manufacturing PKI. The three certificate types are below:

Generic Client Certificate

A TLS client certificate issued by a non manufacturing PKI to a non-native entity

Generic Server Certificate

A TLS server certificate issued by a non manufacturing PKI to a non-native entity

Self-signed Certificate

A TLS client certificate self generated and self signed by a customer or software

Certificate Usage

Authentication

Certificates are used to perform authentication.

Authentication using the certificate proves possession of the private key and the certificate chain is checked to ensure that is ends in a known Root of Trust

As the certificates in the Manufacturing PKI are indefinitely valid, a check for validity is limited to only a check of the signatures on the certificate chain.

OCSP may be used for non-IEEE 2030.5 certificate validations for clients and servers.

Indefinite Lifetime Side Effects

The MPKI issued certificates have an indefinite lifespan, including the SERCA. CA certificates may be retired and replaced when required but may still be relied on for validating subordinate or device certificates. As a consequence, these certificates and key once retired are not considered revoked and may be continued to be used for validation but no longer used to issue further certificates

Operationally the operator of the CA will destroy the private key  to ensure no further certificates can be signed by the CA once the CA is retired.

As no certificates within the MPKI can be revoked because they are embedded permanently within devices, CAs within the MPKI are not required to issue CRLs nor provide OSCP services. Whitelist/Blacklist services may be used for authorization purposed to allow or deny access to a resource on a server.

General Certificate Format

RFC5280 Compliance

All certificates issued by an MPKI shall ee compliant with RFC 5280

IEEE 802.1AR Compliance

With the following exceptions the device and test certificates issued by the MPKI are compliant with the IEEE 802.1AR standard.

1. Device certificates and device test certificates thke the general form of an iDevID certificate
2. The SubjectName field of the device certificate is empty. The SubjectAlternativeName (SAN) extension is used to establish the device identity through the use of a GeneralName of type OtherName as a HardwareModuleNane (id-onHardwareModuleName) as defined in RFC 4108. This extension must be marked as critical as defined in RFC 5280 when the subjectName is empty. The hwType field of the HardWareModuleName is assigned by the IEEE 2030.5 manufacturer and should be different for each type of manufactured device.

Public Key Types

The only permitted public key type currently for IEEE 2030.5 certificates is EC public key on the NIST P-256 curve