Registration authority

Abstract

A method of updating a certificate at an end-point of a network is disclosed. The method comprises: verifying, by a registration authority, an authenticity of a head-end system in the network; verifying, by the registration authority, an authenticity of at least one end-point communicatively coupled to the head-end system; receiving, by the registration authority and after verification of the authenticity of the head-end system and the at least one end-point, at least one certificate signing request from the at least one end-point, via the head-end system; brokering, by the registration authority, a new certificate from a certificate authority for each at least one end-point based on the respective at least one certificate signing request; and providing, by the registration authority, each new certificate to the head-end system for transmission to the respective at least one end-point.

Description

[0001] REGISTRATION AUTHORITY

[0002] FIELD OF INVENTION

[0003] The present disclosure is in the field of updating certificates, e.g. digital certificates, at end-points of a network, and in particular where end-point are Internet- of-things (loT) devices such as smart meters.

[0004] BACKGROUND TO INVENTION

[0005] Internet-of-Things (loT) devices may commonly be provided with a unique certificate, generally known as a ‘birth certificate”, ‘boot strap certificate’, ‘manufacturer’s certificate’ or the like. Such a certificate may typically be associated with each device during a manufacturing process, and may form part of a Public Key Infrastructure (PKI), e.g. a system comprising digital certificates and a certificate authority that may verify and / or authenticate a validity of loT devices. Herein after, a PKI may be referred to more generally as a “PKI hierarchy” or a “trust hierarchy”.

[0006] The principles of PKI and public key based cryptography are well known in the art, and therefore are only described in high-level at this juncture. In brief, the concept of PKI is that each loT device may have an associated pair of keys: a private key and a public key, wherein the private key is kept secret while public key may be available to other devices. In an example use-case, the loT device may digitally sign data using its private key and transmit said data to another party. By using the public key, the other party will be able to verify that the signature was really made by the loT device, without the other party having access to the private key.

[0007] The unique certificate, e.g. the birth certificate, of an loT device may typically be implemented as an immutable certificate stored in a non-volatile memory and digitally signed by a trusted Certificate Authority. In an example, the Certificate Authority may be operated by a manufacturer of the loT device.

[0008] Signing of the unique certificate by the Certificate Authority effectively ensures a digital identity is linked to the loT device. Such a unique certificate may, for example, comprise information about the loT device, such as information relating to an identification number / serial number of the device, manufacturer timestamps, details pertaining to the manufacturer and / or details of the Certificate Authority. Typically, such a unique certificate comprises cryptographic information for use in verification of the device.

[0009] Such unique certificates may be used for authenticating an identity of the loT device and / or securing data transactions in which the loT device may participate. Typically, such a unique certificate may be based on the public-private key pair that is associated with each loT device. For example, such unique certificates may comprise a public key in addition to a signature of that public key, wherein the signature may be generated using a private key of the Certificate Authority. Thus, the private key may be used whenever the loT device needs to verify its identity or to sign data, to ensure security of said data.

[0010] There may be instances where updating the birth certificate of an loT device is desirable. There may also be instances where installing a birth certificate is desirable in instances where no birth certificate existed before. Such updates may involve updating a PKI, e.g. installing new public and private keys in the loT device. Such updates may be referred to in the art as “re-rooting” of the device, i.e. updating / changing the root of trust of the PKI.

[0011] While re-rooting of loT devices is not expected to be carried out frequently for any particular loT device, there are various scenarios that may necessitate infrequent re-rooting of such devices. For example, a new owner or administrator of previously deployed devices may require a previous manufacturer’s certificates to be replaced. In another loT device example, transitioning of smart meters that do not currently implement a certificate-based PKI to use Wi-SUN may necessitate re-rooting of said smart meters. In yet another example, it may be necessary to update certificates and or the PKI in response to a security breach, or in attempts to quantum-proof loT devices.

[0012] Currently, there is no reliable, secure and high-integrity process to issue new birth certificates to loT devices such as smart meters already deployed in the field.

[0013] It is therefore desirable to provide a low-cost, secure and reliable means to issue new birth certificates and / or re-root new loT devices (such as smart meters) already deployed in the field.

[0014] It is therefore an aim of at least one embodiment of at least one aspect of the present disclosure to obviate or at least mitigate at least one of the above identified shortcomings of the prior art. SUMMARY OF INVENTION

[0015] The present disclosure is in the field of updating certificates, e.g. digital certificates, at end-points of a network, and in particular where end-point are Internet- of-things (loT) devices such as smart meters. According to a first aspect of the disclosure, there is provided a method of updating a certificate at an end-point of a network. The method comprises: verifying, by a registration authority, an authenticity of a head-end system in the network; verifying, by the registration authority, an authenticity of at least one end-point communicatively coupled to the head-end system; receiving, by the registration authority and after verification of the authenticity of the head-end system and the at least one end-point, at least one certificate signing request from the at least one end-point, via the head-end system; brokering, by the registration authority, a new certificate from a certificate authority for each at least one end-point based on the respective at least one certificate signing request; and providing, by the registration authority, each new certificate (e.g. each new certificate received from the certificate authority) to the head-end system for transmission to the respective at least one end-point.

[0016] Advantageously, by verifying an authenticity of the head-end system and also of the at least one end point, a mutual trust may be established between the head-end system and each of the registration authority and the at least one end point before any certificate generation requests can be made. Thus, a more secure and reliable means of providing a new certificate, i.e. a birth certificate, to the at least one device from a certificate authority, e.g. a manufacture, is provided.

[0017] Such a method may enable issuing a new birth certificate to be issued to the at least one device post-manufacture and assembly.

[0018] The term head-end system may be understood to be a device or service configured to collect data, such as measurement data and meter events, from a plurality of devices, for transmission to an application.

[0019] The term end-point will be understood to refer to an end-point of a network. For example, in the instance of an Advanced Metering Infrastructure (AMI) network, each endpoint comprise at least one of: a collector; a gateway node, and / or a metering device such as a smart meter, or “edge-intelligence” or communication module associated with a smart meter. In an Advanced Metering Infrastructure (AMI) network, the head-end system may provide a communication and data collection layer between a smart meter infrastructure and a utility’s IT systems. The head-end system may be configured to enable secure communication to the metering infrastructure.

[0020] The registration authority may be provided on a device or system that is remote from the head-end system.

[0021] The registration authority may be provided on a device or system that is remote from the certificate authority.

[0022] The registration authority may be provided as a cloud-based service.

[0023] The method may comprise transmitting, by the head-end system, the / each new certificate to the respective at least one end-point.

[0024] The / each new certificate may be transmitted by the head-end system to the respective at least one end-point over a previously-established secure channel established between head-end system and the at least one end-point.

[0025] Verifying the authenticity of the head-end system may comprise establishing a mutually trusted secure channel of communication between the registration authority and head-end system for transmittal of the / each certificate signing request.

[0026] The mutually trusted secure channel of communication between the registration authority and head-end system may be a channel secured using PKI.

[0027] Verifying the authenticity of the at least one end point system may comprise establishing a mutually trusted secure channel of communication between the headend system and the at least one end point for transmittal of the / each certificate signing request.

[0028] That is, before a certificate signing request may be transmitted from any endpoint to the registration authority via the head-end system, at least some verification of the authenticity of said end-point, such as through an existing certificate (i.e. birth certificate) of the end-point may be performed. That is, in some examples only an endpoint that has been authenticated to the head-end system may be enabled to transmit a CSR to the registration authority (and ultimately to the certificate authority) via the head-end system. In some examples only an end-point that has had an identification verified and / or validated by the head-end system may be enabled to transmit a CSR to the registration authority (and ultimately to the certificate authority) via the head-end system. By means of non-limiting example, the mutually trusted secure channel of communication between the head-end system and the at least one end point may be a channel secured using PKI. Brokering a new certificate from a certificate authority may comprise establishing a mutually trusted secure channel of communication between the registration authority and the certificate authority for transmission of the certificate signing request and / or new certificate.

[0029] The mutually trusted secure channel of communication between the registration authority and the certificate authority be a channel secured using PKI.

[0030] In some examples, following establishment of the mutually trusted secure channel of communication between the registration authority and the certificate authority, the certificate authority may expose an Application Programming Interface to the head-end system. In some examples, following establishment of the mutually trusted secure channel of communication between the registration authority and the certificate authority, the registration authority may expose an Application Programming Interface to the head-end system.

[0031] That is, following establishment of the mutually trusted secure channel of communication between the registration authority and the certificate authority, the certificate authority may be configured to recognize and / or process and / or receive commands and / or data packets from the registration authority. Prior to establishment of the mutually trusted secure channel, the certificate authority may be configured to reject or otherwise not receive or recognize said commands and / or data packets from the registration authority.

[0032] Brokering a new certificate from the certificate authority may comprise an online process, wherein the head-end system sends the / each certificate signing request to the certificate authority and receives the new certificates over a secured network.

[0033] Brokering a new certificate from the certificate authority may comprise an offline process, wherein an operator: retrieves the / each certificate signing request stored in head-end system and provides the / each certificate signing request to the certificate authority; and receives, in response to providing the the / each certificate signing request to the certificate authority, new certificates and provides new certificates to the headend system.

[0034] Each certificate signing request may comprise: a request for a new end-point birth certificate; proof of authenticity of the end-point; and / or proof of head-end system authenticity.

[0035] In addition to issuing the new certificate, the certificate authority may also issue data corresponding to a root certificate and / or the public-key infrastructure hierarchy. The method may comprising verifying, by the at least one end-point, the new certificate against the data corresponding to the root certificate and / or the public-key infrastructure hierarchy before using the new certificate as a new birth-certificate.

[0036] The method may comprise securely storing, by the head-end system, each certificate signing request, client certificates and PKI Admin keys for the process.

[0037] The network may comprise a network of an advanced metering infrastructure, and the at least one endpoint comprises at least one of: a collector; a gateway node, and / or a metering device.

[0038] According to a second aspect of the disclosure, there is provided a computer program comprising instructions which, when the program is executed by a computer, cause the computer to function as a registration authority for carrying out the method according to the first aspect.

[0039] According to a third aspect of the disclosure, there is provided a computer- readable storage medium comprising instructions which, when executed by a computer, cause the computer to carry out the method according to the first aspect.

[0040] According to a fourth aspect of the disclosure, there is provided a system comprising: a head-end system; at least one end-point communicatively coupled to the head-end system; and a processing system communicatively coupled to the head-end system and configured to implement a registration authority and a certificate authority.

[0041] The registration authority is configured to: verify an authenticity of the head-end system; verify an authenticity of at least one end-point; receive, after verifying the authenticity of the head-end system and the at least one end-point, at least one certificate signing request from the at least one end-point, via the head-end system; broker a new certificate from the certificate authority for each at least one endpoint based on the respective at least one certificate signing request; and provide each new certificate to the head-end system for transmission to the respective at least one end-point.

[0042] The processing system may comprise a first processing sub-system implementing the registration authority and a second processing sub-system implementing the certificate authority, wherein the first processing sub-system is remote from and communicatively coupled to the second processing sub-system. The head-end system, the at least one end-point, and the processing system may form an advanced metering infrastructure network. The at least one endpoint may comprise at least one of: a collector; a gateway node, and / or a metering device.

[0043] The above summary is intended to be merely exemplary and non-limiting. The disclosure includes one or more corresponding aspects, embodiments or features in isolation or in various combinations whether or not specifically stated (including claimed) in that combination or in isolation. It should be understood that features defined above in accordance with any aspect of the present disclosure or below relating to any specific embodiment of the disclosure may be utilized, either alone or in combination with any other defined feature, in any other aspect or embodiment or to form a further aspect or embodiment of the disclosure.

[0044] BRIEF DESCRIPTION OF DRAWINGS

[0045] These and other aspects of the present disclosure will now be described, by way of example only, with reference to the accompanying drawings, wherein:

[0046] Figure 1 depicts an example of a system comprising a registration authority configured to broker loT device certificates from multiple HES systems, according to an example of the present disclosure;

[0047] Figure 2 depicts an example of an offline process to establish mutual trust between the head-end system and the registration authority, before certificate generation requests can be made, according to an example of the disclosure;

[0048] Figure 3 depicts a sequence diagram of a method of updating certificates at endpoints of a network using an online certificate generation process, according to an example of the present disclosure;

[0049] Figure 4 depicts an example of how a manufacturer may deploy the disclosed registration authority; and

[0050] Figure 5 depicts a further example of a system comprising a registration authority configured to broker loT device certificates from multiple HES systems, according to an example of the present disclosure.

[0051] DETAILED DESCRIPTION OF DRAWINGS Figure 1 depicts an example of a system 100 according to an embodiment of the disclosure.

[0052] The example system 100 is based on an Advanced Metering Infrastructure (AMI) network, although it will be appreciated that the concepts disclosed herein are applicable to other loT device based systems and networks.

[0053] The system 100 comprises a registration authority 105.

[0054] The registration authority 105 may hereafter be referred to in the accompanying drawings and / or ensuing description as a “RA”, “Central loT RA”, or “CIRA”.

[0055] In examples, the registration authority 105 may be hosted by a manufacturer of one or more end-points 115a-d of the system, as described in more detail below.

[0056] The registration authority 105 may comprise a software program, running on one or more devices. In examples, the registration authority may be provided as a cloud-based service, or a service provided on one or networked computers, servers or the like.

[0057] Also depicted is a plurality of head-end systems 110a-d. Although four headend systems 110a-d are depicted, it will be appreciated that in other examples other amounts of head-end systems 110a-d may be implemented.

[0058] Continuing with the example of an AMI network, each head-end system 110a-d may be hosted by a utility provider, i.e. a provider and administrator of a supply of a resource such as electrical power, water or fuel gas, to premises.

[0059] Each head-end system 110a-d may be configured to communicate with an associated plurality of end-points 115a-d. Each end-point 115a-d may, for example, comprise an loT device, e.g. a device having local processing capabilities and capable of reception and / or transmission of data over a network.

[0060] Each end-point 115a-d may, for example, comprise a utility meter such as an electricity meter or the like. In other examples, end-points 115a-d may comprise collectors, gateways or the like. In examples, each plurality of end-points 115a-d associated with a respective head-end system 110a-d may be provided in a network such as a mesh network. For example, each plurality of end-points 115a-d may form a wireless mesh network may comprising a Time Synchronous Channel Flopping (TSCH) network, which optionally may comprise a TSCH network defined by IEEE 802.15.4e.

[0061] Also depicted is a certificate authority 120. In the depicted example, the certificate authority 120 is a certificate authority of a manufacturer of the end-points 115a-d. As such, said manufacturer may be responsible for provision of birth certificates of the end-points 115a-d during an initial assembly and / or programming of the end-points 115a-d and prior to distribution / installation of said end-points 115a-d.

[0062] In some examples, the registration authority 105 may be implemented as a first processing sub-system and the certificate authority 120 may be implemented as a second processing sub-system, wherein the first processing sub-system may be remote from and communicatively coupled to the second processing sub-system.

[0063] As described above, it may be necessary to issue new birth certificates to endpoints 115a-d already deployed in the field. For example, a new owner or administrator of the end-points 115a-d may require the manufacturer’s previous certificates to be replaced. In another example, transitioning of end-points 115a-d that do not currently implement a certificate-based PKI to use Wi-SUN may necessitate re-rooting of endpoints 115a-d. In yet another example, it may be necessary to update certificates and or the PKI in response to a security breach, or in attempts to quantum-proof the endpoints 115a-d.

[0064] A method of operation of the system 100 to replace or install a certificate, e.g. a new birth certificate, in any one or more of the plurality of end-devices 115a-d may comprise a step of verifying, by the registration authority 105, an authenticity of one or more of the head-end systems 110a-d in the network.

[0065] Verification of the authenticity of each head-end system 110a-d may comprise establishing a mutually trusted secure channel of communication between the registration authority 105 and each head-end system 110a-d. Said mutually trusted secure channel may subsequently be used for the transmittal of certificate signing requests and then signed certificates.

[0066] Establishing mutual trust between each head-end system 110a-d and the registration authority 105 may, in some instances, comprise an offline / manual process, as described below with reference to Figure 2.

[0067] In other examples, establishing mutual trust between each head-end system 110a-d and the registration authority 105 may comprise an online process, i.e. over a network or the internet.

[0068] Establishment of the mutually trusted secure channel may comprise use of a public key infrastructure of each head-each system 110a-d and the registration authority 105, to verify and / or authenticate packets transmitted between each head-end system 110a-d and the registration authority 105. A different PKI may be established between each head-end system 110a-d and the registration authority 105, i.e. a different public-private key pair may be used by each head-end system 110a-d to establish secure communications with the registration authority 105.

[0069] In some examples, the mutually trusted secure channels described herein may be implement using a Transport Layer Security protocol and / or a Secure Socket Layer protocol.

[0070] Following establishment of a secure channel of communication between the registration authority 105 and each head-end system 110a-d, in a next step the registration authority 105 may be configured to verify an authenticity of any / all of the end-points 115a-d that may be communicatively coupled to a respective head-end system 115a-d. Again, such verification of authenticity of end-points 115a-d may comprise establishment of a PKI-based mutually trusted secure channel of communication between said end-points 115a-d and the respective head-end system 110a-d and / or the registration authority 105.

[0071] Once the secure channels have been established, the registration authority 105 may be configured to receive at least one certificate signing request from the at least one end-point 115a-d, via the respective head-end system 110a-d. Certificate signing requests are denoted ‘GSR’ in Figure 1 .

[0072] That is, the registration authority described herein may be configured to carry out a first level of brokering of mutual trust with the head-end system 110a, and then a second level of brokering of mutual trust with the certificate authority, before any certificate signing requests are transported across the network, such as between the end-points 115a-d to the certificate authority 120.

[0073] Each certificate signing request may be triggered by a head-end system 110a- d. That is, a utility may configure a head-end system 110a-d to request generation of a certificate signing request by one or more associated end-points 115a-d.

[0074] In response, each end-point 115a-d will issue a certificate signing request, for transmission to the certificate authority 120 via the associated head-end system 110a- d.

[0075] For purposes of illustration only, examples are now described in relation to a first head-end system 110a of the plurality of head-end systems 110a-d. It will be appreciated that the ensuing examples may be applicable to any / all of the head-end systems 110a-d.

[0076] For example, a first plurality of end-points 115a will send certificate signing requests to the first head-end system 110a. The first head-end system 110a may be configured to store all of the certificate signing requests received from associated endpoints 115a.

[0077] In examples, each certificate signing request may comprise a header portion and a body portion. The certificate signing request header portion may comprise a unique device identity. The certificate signing request body portion may comprise, for example, a public key and / or a digital signature, such as a digital signature of data in the body portion. In some examples, the header portion and / or the body portion of each certificate signing request may be hashed and / or encrypted using a private key of the end-point.

[0078] When the first head-end system 110a receives certificate signing requests from the first plurality of end-points 115a, there may be additional layers of authenticity checking, to ensure said certificate signing requests are authentic. Said certificate signing requests may be received over the above-described mutually secure channel of communication.

[0079] Once the first head-end system 110a has received the certificate signing requests from the first plurality of end-points 115a, the first head-end system 110a will undergo a level of brokering with the certificate authority 120 via the registration authority 105, to receive the new certificates.

[0080] In some examples, once secure channels of communication are established with the registration authority 105, the registration authority 105 and / or the certificate authority 120 may be configured to expose an Application Programming Interface (API) to enable communications between said registration authority 105 and / or the certificate authority 120.

[0081] The received certificates may be provided in a predefined format, such as PEM, DER, CRT, CER and / or x.509. In the depicted and non-limiting example of Figure 1 , the certificates are in the DER format, e.g. in a binary format.

[0082] The registration authority 105 may be configured to store, or buffer, certificate signing requests received from the first plurality of end-points 115a via the first headend system 110a, and certificates received from the certificate authority 120 to be issued to the first plurality of end-points 115a.

[0083] A new certificate may be accompanied with, or may comprise, a PKI hierarchy to be transported to the end-point. In some examples, a root certificate, e.g. a public key certificate that identifies the certificate authority 120 (which may be a manufacturing CA singed by a Root CA), may be transported with the newly issued certificates to the end points 115a. Thus may allow an initial level of verification of a newly generated certificate against this root, to ensure the received certificate really came from the root certificate authority 120, before the first end-points 115a start using the new certificates as their new birth certificates.

[0084] That is, the above describe method may be used not only for transporting a new certificate to an end-point 110a, but also for transporting the root, e.g. the chain of trust. That is, when an end-point 110a receives a newly generated certificate and a new trust chain, the end-point 110a may first verify the new trust chain (because it is signed by the end-point manufacturer) and, once verified, will then use the new trust chain to verify the newly received certificate that has just been generated and issued by the certificate authority 120.

[0085] In some examples, each first end point 110a may delete or overwrite any birth certificate that may no longer be required with the newly issued certificates.

[0086] Similarly, in some examples each end point 110a may delete or overwrite a public / private key pair issued during a manufacturing process with a newly received public / private key pair issued alongside the certificates.

[0087] Figure 2 depicts an example of an offline process to establish mutual trust between the head-end system 210, the registration authority 205, and the certificate authority 220 before certificate generation requests can be made, according to an embodiment of the disclosure.

[0088] A head-end system 210, a certificate authority 220 and a registration authority 205 are depicted, which may in some examples be those of the example system 100 of Figure 1 .

[0089] In the example of Figure 2, the head-end system 210 is managed by a utility provider. The head-end system 210 may be configured to provide additional layer of security. For example, in the example the utility also support databases (DB), generally termed “Head-End System DB” and accessible by the head-end system 210. Also depicted is a hardware security module, denoted ‘HSM’, for performing encryption and decryption functionality and for use in authenticating and / or verifying certificates and data and of generation, verification of keys. In the example, the utility supports public / private key pairs for client certificates. As such, the utility may be configured to support client certificate authentication. The utility may also store administrator public / private key pairs.

[0090] In this example, the registration authority 205 may be managed / administered by a manufacturer of the end-points, i.e. a manufacturer of pluralities of endpoints 115a-d. For purposes of example only, the registration authority 205 implements a “REST API” (also known in the art as a RESTful API).

[0091] The registration authority 205 is configured to receive public keys that may be specific to each head-end system 210. That is, an operator 245 may load i.e. by provision of a physical data storage device or the like, one or more public keys into the head-end system 210.

[0092] In this example, the certificate authority 220 may also be managed / administered by the manufacturer. The certificate authority 220 may be provided as a ‘Software-as-a-Service’ cloud-based certificate authority.

[0093] As described above, a mutually trusted secure channel 235 of communication between the registration authority 205 and head-end system 210 and a mutually trusted secure channel 240 of communication between the registration authority 205 and certificate authority 220 may be established before: certificate signing requests are transmitted to the certificate authority 220 from endpoints via the registration authority 205 and head-end system 210; and / or before certificates are transmitted from the certificate authority 220 to the end-points via the registration authority 205 and headend system 210.

[0094] In some instances, establishing such secure channels 235, 240 may be comprise an offline process to establish such mutual trust between the head-end system 210 and the registration authority 205 before certificate generation requests can be made

[0095] In an example, the head-end system 210 may generate a certificate signing request for a head-end system client certificate. This certificate signing request may be exported from the head-end system 210 and provided to an operator 250.

[0096] In the example, the operator 250 may retrieve the certificate signing request for the head-end system client certificate and provide this to the certificate authority 220, e.g. over a separate network (e.g. using email, a file transfer protocol or the like) or even by use of a physical data storage device, such as a portable memory.

[0097] An operator 255 may then use the certificate signing request to retrieve a signed client certificate from the certificate authority 220. Said signed client certificate may be provided to the head-end system 210, e.g. over the separate network (e.g. using email, a file transfer protocol or the like) or even by use of a physical data storage device, such as a portable memory.

[0098] The head-end system 210 may be configured to import the signed client certificate. As such, the head-end system may be authenticated to the CA using the signed client certificate, and thus can establish the secure channels 235, 240 of communication.

[0099] Figure 3 depicts a sequence diagram of a method of updating certificates at end-points of a network using an online certificate generation process. The sequence diagram may correspond to operation of the system 100 of Figure 1 .

[0100] It can be seen that at a step 305, client certificates for establishing secure communication between a head-end system and the certificate authority are loaded to a database of the head-end system. Such client certificates may be obtained according to the offline process described above with reference to Figure 2, or by a different online process.

[0101] At a sequence 310, in a first step 315 the head-end system retrieves a certificate signing request, e.g. an endpoint certificate signing request, which may be stored in a database of the head-end system. In some embodiments, in a next step 320 the registration authority may expose an Application Programming Interface, denoted “Cert API”, for exchange of certificates and certificate signing requests with the headend systems. The registration authority may include a step 325 for performing validation, verification and / or authentication of certificate signing requests received from head-end systems.

[0102] At a next step 330, the certificate authority may also expose an API, denoted “Enroll / REST API” to enable the registration authority to issue certificate signing requests to the certificate authority, and to receive signed certificates in response.

[0103] In some instances, validation, verification and / or authentication of certificate signing requests may fail, which may be notified to a requesting head-end system at step 335.

[0104] In a next step 340, signed certificates may then be stored in a database of the head-end system, for later distribution to end-points. At a step 345 a status of the generation of certificates may be updated in any or all of the certificate authority, the registration authority and / or the head-end system.

[0105] The sequence 310 may be repeated in a loop and / or may be performed periodically, until certificates signing requests for all valid end-points have been serviced by the certificate authority.

[0106] Figure 4 depicts an example of how a manufacturer may deploy the disclosed Registration Authority, e.g. the Central loT RA, in a secure and HA configuration. In notable features, the database of the Registration Authority may be accessible via a user interface on a web server. For completeness, Figure 5 depicts a further example of a system comprising a registration authority configured to broker loT device certificates from multiple headend systems, according to an example of the present disclosure. The disclosed registration authority may be used to server manufacturer certificates for devices following the trust verification process at the device and head-end system / software level. This may include a different families of devices, different manufacturer and perhaps a different manufacturer PKI. That is, although the above description relates to use of the disclosed registration authority for re-rooting use cases, the registration authority described herein may be extended to support many different end-points and manufacturers.

[0107] Although the disclosure has been described in terms of preferred embodiments as set forth above, it should be understood that these embodiments are illustrative only and that the claims are not limited to those embodiments. Those skilled in the art will be able to make modifications and alternatives in view of the disclosure, which are contemplated as falling within the scope of the appended claims. Each feature disclosed or illustrated in the present specification may be incorporated in any embodiments, whether alone or in any appropriate combination with any other feature disclosed or illustrated herein.

Claims

CLAIMS:1 . A method of updating a certificate at an end-point of a network, the method comprising: verifying, by a registration authority, an authenticity of a head-end system in the network; verifying, by the registration authority, an authenticity of at least one end-point communicatively coupled to the head-end system; receiving, by the registration authority and after verification of the authenticity of the head-end system and the at least one end-point, at least one certificate signing request from the at least one end-point, via the head-end system; brokering, by the registration authority, a new certificate from a certificate authority for each at least one end-point based on the respective at least one certificate signing request; and providing, by the registration authority, each new certificate to the headend system for transmission to the respective at least one end-point.

2. The method of clam 1 , comprising transmitting, by the head-end system, the / each new certificate to the respective at least one end-point.

3. The method of claim 1 or 2, wherein verifying the authenticity of the head-end system comprises establishing a mutually trusted secure channel of communication between the registration authority and head-end system for transmittal of the / each certificate signing request.

4. The method of claim any preceding claim, wherein verifying the authenticity of the at least one end point system comprises establishing a mutually trusted secure channel of communication between the head-end system and / or the registration authority, and the at least one end point for transmittal of the / each certificate signing request.

5. The method of any preceding claim, wherein brokering a new certificate from a certificate authority comprises establishing a mutually trusted secure channel ofcommunication between the registration authority and the certificate authority for transmission of the certificate signing request and / or new certificate.

6. The method of claim 5 wherein, following establishment of the mutually trusted secure channel of communication between the registration authority and the certificate authority, the registration authority exposes an Application Programming Interface to the head-end system.

7. The method of claim 5 or 6, wherein brokering a new certificate from the certificate authority comprises one of: an online process, wherein the head-end system sends the / each certificate signing request to the certificate authority and receives the new certificates over a secured network; or an offline process, wherein an operator: retrieves the / each certificate signing request stored in head-end system and provides the / each certificate signing request to the certificate authority; and receives, in response to providing the the / each certificate signing request to the certificate authority, new certificates and provides new certificates to the head-end system.

8. The method of any preceding claim, wherein each certificate signing request comprises: a request for a new end-point birth certificate; proof of authenticity of the end-point; and proof of head-end system authenticity.

9. The method of any preceding clam wherein, in addition to issuing the new certificate, the certificate authority also issues data corresponding to a root certificate and / or the public-key infrastructure hierarchy.

10. The method of claim 9 comprising verifying, by the at least one end-point, the new certificate against the data corresponding to the root certificate and / or the public-key infrastructure hierarchy before using the new certificate as a new birth-certificate.

11. The method of any preceding claim, comprising securely storing, by the headend system, each certificate signing request, client certificates and PKI Admin keys for the process.

12. The method of any preceding claim, where the network comprises a network of an advanced metering infrastructure, and the at least one endpoint comprises at least one of: a collector; a gateway node, and / or a metering device.

13. A computer program comprising instructions which, when the program is executed by a computer, cause the computer to function as a registration authority for carrying out the method steps of claim 1 .

14. A computer-readable storage medium comprising instructions which, when executed by a computer, cause the computer to carry out the method of claim 1 .

15. A system comprising: a head-end system; at least one end-point communicatively coupled to the head-end system; and a processing system communicatively coupled to the head-end system and configured to implement a registration authority and a certificate authority, wherein the registration authority is configured to: verify an authenticity of the head-end system; verify an authenticity of at least one end-point; receive, after verifying the authenticity of the head-end system and the at least one end-point, at least one certificate signing request from the at least one end-point, via the head-end system; broker a new certificate from the certificate authority for each at least one end-point based on the respective at least one certificate signing request; andprovide each new certificate to the head-end system for transmission to the respective at least one end-point.

16. The system of claim 15, wherein the processing system comprises a first processing sub-system implementing the registration authority and a second processing sub-system implementing the certificate authority, wherein the first processing sub-system is remote from and communicatively coupled to the second processing sub-system.

17. The network of claim 15 or 16, wherein the head-end system, the at least one end-point, and the processing system form an advanced metering infrastructure network, and wherein the at least one endpoint comprises at least one of: a collector; a gateway node, and / or a metering device.

Images