Digital certificate update

Abstract

A method of updating a certificate at an end-point of a network, the method comprising authenticating, by at least one end-point device in the network, a certificate signing request, obtaining, by a network module, the authenticated certificate signing request from at least one end-point device in the network, verifying, by a registration authority, an authenticity of the network module in the network, verifying, by the registration authority, an authenticity of the at least one end-point device in the network, receiving, from the network module by the registration authority, after verification of the authenticity of the network module and the at least one end-point device, the authenticated certificate signing request, verifying, by the registration authority, the authenticity of the authenticated certificate signing request, obtaining, by the registration authority, a new certificate from a certificate authority for the, or each certificate signing request, and providing, by the registration authority, the, or each new certificate to the network module for transmission to the respective at least one end-point device.

Description

[0001] DIGITAL CERTIFICATE UPDATE

[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-points 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, in some cases, 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. However, in some examples, the unique certificate may be alterable.

[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-points are Internet- of-things (loT) devices such as smart meters.

[0016] 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 comprising: authenticating, by at least one end-point device in the network, a certificate signing request; obtaining, by a network module, the authenticated certificate signing request from at least one end-point device in the network; verifying, by a registration authority, an authenticity of the network module in the network; verifying, by the registration authority, an authenticity of the at least one end-point device in the network; receiving, from the network module by the registration authority, after verification of the authenticity of the network module and the at least one end-point device, the authenticated certificate signing request; verifying, by the registration authority, the authenticity of the authenticated certificate signing request; obtaining, by the registration authority, a new certificate from a certificate authority for the, or each certificate signing request; and providing, by the registration authority, the, or each new certificate to the network module for transmission to the respective at least one end-point device.

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

[0018] Advantageously, by authenticating the certificate signing request before it is transmitted from the end point device, the certificate signing request can be trusted by the registration authority, and in some examples therefore the end point device, the network module, and the certificate signing request may all be trusted and verified. Such a method may enable issuing a new certificate, e.g. a birth certificate, to be issued to the at least one end point device post-manufacture and assembly.

[0019] The end point device may be configured to create the certificate signing request.

[0020] The step of authenticating the certificate signing request by the end-point device may comprise signing the certificate signing request by the end-point device.

[0021] The step of authenticating the certificate signing request by the end-point device may comprise using PKI.

[0022] The step of authenticating the certificate signing request by the end-point device may comprise using PKI to generate a private-public key pair, or using a stored privatepublic key pair. The step of authenticating the certificate signing request by the end-point device may comprise signing the certificate signing request using the private key at the end-point device. The step of authenticating the certificate signing request by the endpoint device may comprise including the generated public key in the certificate signing request.

[0023] The step of signing the certificate signing request by the end-point device may add integrity to the CSR.

[0024] The step of authenticating the certificate signing request by the end-point device may comprise using a stored legacy private key and may comprise signing the certificate signing request using the legacy private key at the end-point device.

[0025] The legacy private key of the end-point device may be a legacy private key associated with the current (legacy) certificate that is to be updated.

[0026] The step of authenticating the certificate signing request by the end-point device may comprise generating a new private / public key pair, and signing the new generated public key using the legacy private key and the new private key, and including the generated, signed public key in the certificate signing request.

[0027] The legacy private key of the end-point device may be a legacy private key associated with the current (legacy) certificate that is to be updated.

[0028] The / each certificate signing request may comprise: a request for a new end-point birth certificate; and / or proof of authenticity of the end-point device. The / each certificate signing request may comprise a public key associated with the legacy certificate, and the legacy certificate.

[0029] The network module may add further authenticity to the received certificate signing request. The network module may add further authenticity to the received certificate signing request by adding proof of the network module authenticity to the received certificate signing request. The network module may transmit at least some certificate signing requests in batch to the registration authority. The registration authority may validate the authenticity of the network module, and then validate that the / each certificate signing request is from a trusted or verified end-point device.

[0030] The network module may be a head-end system (HES), or any suitable network module for communicating with a plurality of end-point devices.

[0031] The head-end system may 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.

[0032] 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 comprises 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.

[0033] 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.

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

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

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

[0037] The method may comprise transmitting, by the network module, the / each new certificate to the respective at least one end-point device. The / each new certificate may be transmitted by the network module to the respective at least one end-point device over a previously-established secure channel established between the network module and the at least one end-point device.

[0038] Verifying the authenticity of the network module may comprise establishing a mutually trusted secure channel of communication between the registration authority and the network module for transmittal of the / each authenticated certificate signing request.

[0039] The mutually trusted secure channel of communication between the registration authority and the network module may be a channel secured using PKI.

[0040] Verifying the authenticity of the at least one end point device may comprise establishing a mutually trusted secure channel of communication between the network module (or the head-end system) and the at least one end point device for transmittal of the / each authenticated certificate signing request.

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

[0042] The method may comprise verifying, by the network module, the authenticity of the authenticated certificate signing request. The step of verifying, by the registration authority, the authenticity of the authenticated certificate signing request may mean verifying the authenticated certificate signing request that has been verified by the network module. In some examples, the network module may be configured or operable to not provide the certificate signing request to the registration authority unless the GSR has been verified by the network module.

[0043] The step of verifying, by the network module, the authenticity of the authenticated certificate signing request may comprise using PKI. The step of verifying, by the network module, the authenticity of the authenticated certificate signing request may comprise using a private-public key pair of the network module. The private-public key pair may be associated with the legacy device certificate to be updated. The GSR may include the public key from the end point device and the network module may use the private key associated with the legacy certificate, to verify the authenticity of the CSR.

[0044] The step of verifying, by the registration authority, the authenticity of the authenticated certificate signing request may comprise using PKI. The step of verifying, by the registration authority, the authenticity of the authenticated certificate signing request may comprise using a public key of or at the registration authority. The public key may be associated with the legacy device certificate to be updated. The CSR may include the public key from the end point device and the registration authority may use the public key associated with the legacy certificate, to verify the authenticity of the CSR.

[0045] The verification of the CSR by the network module and / or the registration authority may validate that the authenticity applied to the CSR originated at the end point device.

[0046] Obtaining 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 verified and authenticated certificate signing request and / or new certificate.

[0047] The new certificate may include a new public key for use by the end point device in creating a further certificate signing request.

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

[0049] 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 network module.

[0050] 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.

[0051] Obtaining a new certificate from the certificate authority may comprise an online process, wherein the network module sends the / each verified authenticated certificate signing request to the registration authority and receives the new certificates over a secured network.

[0052] Obtaining a new certificate from the certificate authority may comprise an offline process, wherein an operator: retrieves the / each verified and authenticated certificate signing request stored in the network module and provides the / each verified and authenticated certificate signing request to the registration authority; and receives, in response to providing the the / each verified and authenticated certificate signing request to the registration authority, new certificates and provides new certificates to the network module. 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.

[0053] The method may comprising verifying, by the at least one end-point device, the new certificate against the data corresponding to the root certificate and / or the publickey infrastructure hierarchy before using the new certificate as a new birth-certificate.

[0054] The method may comprise, by the registration authority and / or the network module, revoking, discarding, or archiving the legacy certificate of the end point device. The registration authority and / or the network module may create and / or maintain a list of revoked or archived certificates.

[0055] The method may comprise securely storing, by the network module, each certificate signing request, client certificates and PKI Admin keys for the process.

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

[0057] 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 at least some steps of the method according to the first aspect.

[0058] 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.

[0059] According to a fourth aspect of the disclosure, there is provided a system comprising: a network module; at least one end-point device communicatively coupled to the network module; and a processing system communicatively coupled to the network module and configured to implement a registration authority and a certificate authority; wherein the at least one end-point device is operable to create and authenticate a certificate signing request.

[0060] The registration authority may be configured to: verify an authenticity of the network module; verify an authenticity of the at least one end-point device; receive, after verifying the authenticity of the head-end system and the at least one end-point, at least one authenticated certificate signing request from the at least one end-point device, from the network module; obtain a new certificate from the certificate authority for the / each at least one certificate signing request; and provide the / each new certificate to the network module for transmission to the respective at least one end-point device.

[0061] 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.

[0062] The network module, the at least one end-point device, and the processing system may form an advanced metering infrastructure network. The at least one end point device may comprise at least one of: a collector; a gateway node, and / or a metering device.

[0063] The above summary is intended to provide examples and be 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.

[0064] BRIEF DESCRIPTION OF DRAWINGS

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

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

[0067] 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;

[0068] 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;

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

[0070] 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.

[0071] DETAILED DESCRIPTION OF DRAWINGS

[0072] Figure 1 depicts an example of a system 100 according to an embodiment of the disclosure.

[0073] 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.

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

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

[0076] 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.

[0077] 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 cloudbased service, or a service provided on one or networked computers, servers or the like.

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

[0079] 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. Each head-end system 110a-d may be configured to communicate with an associated plurality of end-points 115a-d. Each end-point 1 15a-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.

[0080] 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 1 15a-d may comprise collectors, gateways or the like. In examples, each plurality of end-points 1 15a-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 1 15a-d may form a wireless mesh network which may comprise a Time Synchronous Channel Hopping (TSCH) network, which optionally may comprise a TSCH network defined by IEEE 802.15.4e.

[0081] 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 1 15a-d. As such, said manufacturer may be responsible for provision of birth certificates of the endpoints 1 15a-d during an initial assembly and / or programming of the end-points 1 15a-d and prior to distribution / installation of said end-points 1 15a-d.

[0082] 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.

[0083] As described above, it may be necessary to issue new birth certificates to endpoints 1 15a-d already deployed in the field. For example, a new owner or administrator of the end-points 1 15a-d may require the manufacturer’s previous certificates to be replaced. In another example, transitioning of end-points 1 15a-d that do not currently implement a certificate-based PKI to use Wi-SUN may necessitate re-rooting of endpoints 1 15a-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 end-points 1 15a-d.

[0084] 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 creating and authenticating, by at least one end-point device 1 15a-d, in the network, a certificate signing request.

[0085] The method may comprise verifying, by the registration authority 105, an authenticity of one or more of the head-end systems 1 10a-d in the network. 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 1 10a-d. Said mutually trusted secure channel may subsequently be used for the transmittal of certificate signing requests and then signed certificates.

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

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

[0088] Establishment of the mutually trusted secure channel may comprise use of a public key infrastructure of each head-each system 1 10a-d and the registration authority 105, to verify and / or authenticate packets transmitted between each head-end system 1 10a-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 publicprivate key pair may be used by each head-end system 110a-d to establish secure communications with the registration authority 105.

[0089] 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.

[0090] Following establishment of a secure channel of communication between the registration authority 105 and each head-end system 1 10a-d, in a next step the registration authority 105 may be configured to verify an authenticity of any / all of the endpoints 1 15a-d that may be communicatively coupled to a respective head-end system 1 10a-d. Again, such verification of authenticity of end-points 1 15a-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.

[0091] Once the secure channels have been established, the registration authority 105 may be configured to receive at least one authenticated 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 ‘CSR’ in Figure 1 .

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

[0093] Advantageously, by authenticating the certificate signing request before it is transmitted from the end point device 115a-d, the certificate signing request can be trusted by the registration authority 105, and in some examples therefore the end point device 115a-d, the head-end system 110a-d, and the certificate signing request may all be trusted and verified.

[0094] In some embodiments, the method comprises verifying, by the head-end system 110a-d, the authenticity of the authenticated certificate signing request, and verifying, by the registration authority 105, the authenticity of the authenticated certificate signing request, which means verifying the authenticated certificate signing request that has been verified by the respective head-end system 110a-d. In some examples, each respective head-end system 110a-d is configured or operable to not provide the certificate signing request to the registration authority 105 unless the GSR has been verified by the respective head-end system 110a-d.

[0095] The step of verifying, by the respective head-end system 110a-d, the authenticity of the authenticated certificate signing request comprises using a public key of the respective head-end system 110a-d. The public key is associated with the legacy device certificate to be updated. The GSR includes the public key from the end point device 115a-d and each head-end system 110a-d uses the public key associated with the legacy certificate, to verify the authenticity of the GSR.

[0096] The step of verifying, by the registration authority 105, the authenticity of the authenticated certificate signing request comprises using PKI using a public key of the endpoint legacy certificate. The public key pair is associated with the legacy device certificate to be updated. The GSR includes the public key from the end point device 115a-d and the registration authority 105 uses the public key associated with the legacy certificate, to verify the authenticity of the GSR.

[0097] The verification of the GSR by the respective head-end system 110a-d and the registration authority 105 validates that the authenticity applied to the CSR originated at the end point device 115a-d.

[0098] 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 and authentication of a certificate signing request by one or more associated end-points 115a-d. In response, each end-point 1 15a-d will issue and authenticate a certificate signing request, for transmission to the certificate authority 120 via the associated headend system 110a-d.

[0099] The step of authenticating the certificate signing request by an end-point device 1 15a-d comprises signing the certificate signing request by the end-point device 1 15a-d using PKI. In some embodiments the end-point device 115a-d generates a private-public key pair, or uses a stored private-public key pair, and signs the certificate signing request using the private key at the end-point device 1 15a-d. In some embodiments, the step of authenticating the certificate signing request by the end-point device 115a-d comprises including the generated public key in the certificate signing request.

[0100] The step of signing the certificate signing request by the end-point device 1 15a- d adds integrity to the CSR.

[0101] In some embodiments, the private key of the end-point device 115a-d is a legacy private key associated with the current (legacy) certificate that is to be updated. Therefore, in these embodiments, authenticating the certificate signing request by the end-point device 1 15a-d uses a stored legacy private key and includes signing the certificate signing request using the legacy private key at the end-point device 1 15a-d. Authenticating the certificate signing request by the end-point device 115a-d includes generating a new private / public key pair, and signing the new generated public key using the legacy private key and the new private key, and including the generated, signed public key in the certificate signing request.

[0102] The / each certificate signing request comprises: a request for a new end-point birth certificate; proof of authenticity of the end-point device; proof of the network module authenticity and a public key associated with the legacy certificate. However, these are examples.

[0103] 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 1 10a-d. It will be appreciated that the ensuing examples may be applicable to any / all of the head-end systems 110a- d.

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

[0105] 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 body portion of each certificate signing request may be hashed and / or encrypted using a private key of the end-point. In some examples the certificate signing request is signed by the legacy private key of the end point device 1 15a-d.

[0106] When the first head-end system 110a receives authenticated 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.

[0107] Once the first head-end system 110a has received the certificate signing requests from the first plurality of end-points 1 15a, 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.

[0108] 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.

[0109] 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.

[0110] The registration authority 105 may be configured to store, or buffer, certificate signing requests received from the first plurality of end-points 1 15a via the first head-end system 1 10a, and certificates received from the certificate authority 120 to be issued to the first plurality of end-points 1 15a.

[0111] 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 1 15a. This 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 1 15a start using the new certificates as their new birth certificates. The new certificate includes a new public key for use by the end point device 1 15a-d in creating a further certificate signing request and authenticating the same.

[0112] That is, the above described method may be used not only fortransporting a new certificate to an end-point 1 10a, 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 1 10a 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.

[0113] In some examples, each first end point 1 10a may delete or overwrite any birth certificate that may no longer be required with the newly issued certificates. In some examples, the method comprises, by the registration authority 105 and / or the head-end system 110a, revoking, discarding, or archiving the legacy certificate of the end point device 1 15a-d and creating and / or maintaining a list of revoked or archived certificates.

[0114] 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.

[0115] 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.

[0116] 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 .

[0117] 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 supports 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.

[0118] 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 1 15a-d. For purposes of example only, the registration authority 205 implements a “REST API” (also known in the art as a RESTful API).

[0119] 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.

[0120] 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.

[0121] 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 head-end system 210.

[0122] In some instances, establishing such secure channels 235, 240 may 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.

[0123] 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.

[0124] 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.

[0125] 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.

[0126] 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.

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

[0128] It can be seen that at a step 305, client certificates for establishing secure communication between a head-end system and the registration 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.

[0129] 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 head-end 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.

[0130] 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.

[0131] 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.

[0132] 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.

[0133] 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.

[0134] 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 head-end 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. Although the disclosure has been described in terms of example 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: authenticating, by at least one end-point device in the network, a certificate signing request; obtaining, by a network module, the authenticated certificate signing request from at least one end-point device in the network; verifying, by a registration authority, an authenticity of the network module in the network; verifying, by the registration authority, an authenticity of the at least one end-point device in the network; receiving, from the network module by the registration authority, after verification of the authenticity of the network module and the at least one endpoint device, the authenticated certificate signing request; verifying, by the registration authority, the authenticity of the authenticated certificate signing request; obtaining, by the registration authority, a new certificate from a certificate authority for the, or each certificate signing request; and providing, by the registration authority, the, or each new certificate to the network module for transmission to the respective at least one end-point device.

2. The method of claim 1 , wherein the step of authenticating the certificate signing request by the end-point device comprises signing the certificate signing request by the end-point device.

3. The method of claim 2, wherein the step of authenticating the certificate signing request by the end-point device comprises using public key infrastructure (PKI).

4. The method of claim 3, wherein the step of authenticating the certificate signing request by the end-point device comprises using a stored legacy private key and comprises signing the certificate signing request using the legacy private key at the end-point device.

5. The method of claim 4, wherein the step of authenticating the certificate signing request by the end-point device comprises generating a new private / public key pair, and signing the new generated public key using the legacy private key and the new private key, and including the generated, signed public key in the certificate signing request.

6. The method of claim 4 or claim 5, wherein the legacy private key of the end-point device is a legacy private key associated with the current (legacy) certificate that is to be updated.

7. The method of any of claims 1 to 6, wherein the / each certificate signing request comprises: a request for a new end-point birth certificate; and / or proof of authenticity of the end-point device.

8. The method of any of claims 1 to 7, wherein the network module adds proof of authenticity of the network module to the received certificate signing request.

9. The method of any of claims 1 to 8, wherein the / each certificate signing request comprises a public key associated with the legacy certificate, and the legacy certificate.

10. The method of any of claims 1 to 9, wherein the network module is a head-end system, and wherein the network comprises a network of an advanced metering infrastructure, and the at least one end point device comprises at least one of: a collector; a gateway node, and / or a metering device.1 1 . The method of any of claims 1 to 10, wherein the method comprises transmitting, by the network module, the / each new certificate to the respective at least one end-point device.

12. The method of any preceding claim, wherein verifying the authenticity of the head-end system comprises establishing a mutually trusted secure channel of communication between the registration authority and the network module for transmittal of the / each certificate signing request.

13. 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 network module and / or the registration authority, and the at least one end point for transmittal of the / each certificate signing request.

14. The method of any preceding claim, wherein the step of verifying, by the registration authority, the authenticity of the authenticated certificate signing request comprises using PKI.

15. The method of any preceding claim, wherein the method comprises verifying, by the network module, the authenticity of the authenticated certificate signing request, optionally comprising using PKI.

16. The method of any preceding claim, wherein the new certificate includes a new public key for use by the end point device in creating a further certificate signing request.

17. The method of any preceding claim, wherein the method comprises, by the registration authority and / or the network module, revoking, discarding, or archiving the legacy certificate of the end point device.

18. The method of any preceding claim, wherein obtaining a new certificate from a certificate authority comprises 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.

19. The method of claim 18 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 network module.

20. The method of claim 18 or claim 19, wherein obtaining a new certificate from the certificate authority comprises one of:an online process, wherein the network module 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 the network module 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 network module.21 . 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.

22. The method of claim 21 comprising verifying, by the at least one end-point device, 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.

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

24. 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 at least some steps of the method of claim 1 .

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

26. A system comprising: a network module;at least one end-point device communicatively coupled to the network module; and a processing system communicatively coupled to the network module and configured to implement a registration authority and a certificate authority; wherein the at least one end-point device is operable to create and authenticate a certificate signing request; and wherein the registration authority is configured to: verify an authenticity of the network module; verify an authenticity of the at least one end-point device; receive, after verifying the authenticity of the head-end system and the at least one end-point, at least one authenticated certificate signing request from the at least one end-point device, from the network module; obtain a new certificate from the certificate authority for the / each at least one certificate signing request; and provide the / each new certificate to the network module for transmission to the respective at least one end-point device.

Images