Acquisition of certificate without using an initial certificate

Abstract

A method of establishing secure communication between a device and a server within a network, the method comprising initialising a handshake between the device and the server, generating, by the device, a pre-shared key (PSK) from a device key located at the device, generating, by a network module, the PSK from a device key located at the network module, providing the generated PSK from the network module to the server, and validating the handshake based, at least in part, on the PSK at the device and the PSK at the server.

Description

[0001] ACQUISITION OF CERTIFICATE WITHOUT USING AN INITIAL CERTIFICATE

[0002] FIELD OF INVENTION

[0003] The present disclosure is in the field of secure communication within a network and relates to a method of establishing secure communication between a device and a server within a network. The disclosure relates particularly but not exclusively to methods of acquiring a certificate, which may use enrollment over secure transport (EST), without requiring an initial certificate to be present at the device, such as a birth certificate.

[0004] BACKGROUND TO INVENTION

[0005] Public key infrastructure (PKI) is used in some applications to manage and carry out certificate operations, and makes use of private keys and public keys. PKI can be used within a network of devices and servers to establish trust and to secure communications.

[0006] One example is the use of enrolment over secure transport (EST), which provides an authenticated and authorized channel for PKI requests and responses. An EST server may be located between a certification authority (CA) and a client device, and the EST server may carry out functions typically allocated to a registration authority (RA) role in PKI.

[0007] However, in some examples, the use of PKI to provide certificates to networked devices can increase bandwidth, time and resources, and cost. For example, in a network of many devices, such as a network of end point utility meters geographically spread over a large area, the installation of certificates to the devices through PKI may not be straightforward.

[0008] Some devices in a network may be provided with a “birth certificate” to digitally establish the identity of that device in the network. However, in some cases, devices in a network may have communicated using an existing communication protocol that did not require the device to have a digital certificate or birth certificate. In at least some present cases, there may be a need to provide the device with a digital certificate, which may use PKI, EST, and / or other method, to allow the device to use a newer communication protocol or configuration. For example, when a device is to work on an upgraded form of mesh network, such as the Wi-Sun network method.Therefore, in at least some cases, using PKI or other available methods of certificate management may have one or more drawbacks.

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

[0010] SUMMARY OF INVENTION

[0011] According to a first aspect of the disclosure, there is provided a method of establishing secure communication between a device and a server within a network, the method comprising:

[0012] initialising a handshake between the device and the server;

[0013] generating, by the device, a pre-shared key (PSK) from a device key located at the device;

[0014] generating, by a network module, the PSK from a device key located at the network module;

[0015] providing the generated PSK from the network module to the server; and validating the handshake based, at least in part, on the PSK at the device and the PSK at the server.

[0016] The network may comprise a plurality of devices. The network may be a utility meter network, or an electrical power meter network, or an advanced metering infrastructure (AMI) network.

[0017] The network module may comprise any suitable component parts, such as one or more servers or the like, and in some examples, the network module may be or may comprise a head-end system (HES). The HES 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, such as a utility provider or the like.

[0018] In an 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 headend system may be configured to enable secure communication to the metering infrastructure.

[0019] The method may comprise configuring the device from use with one or more first network communication methods to one or more second network communication methods. The first network communication method may include at least one of: a mesh network, RF method, RF mesh network, and internet protocol (IP)-based method, an RF IP method, an IP mesh network method, an RF mesh IP network, a wired method, awireless method, and / or one or more other methods. The second network communication method may include at least one of: a wireless method, a wired method, a utility network, a field area network, a smart network, a smart utility network, a wireless utility network, a wireless smart utility network, and / or one or more other methods. The communication path between the device and the network module may at least partially include the first network communication method. The method may comprise configuring the device to communicate with the network module at least partially including the second network communication method.

[0020] The device may be an Internet of Things (loT) device. The device may be a constrained device relative to the server, or in some examples a constrained loT device. The device may be configured to communicate with the network, which may include the server and / or network module, using a constrained device communication protocol, such as a Constrained Application Protocol (CoAP), which may include use of transport layer security (TLS), or datagram TLS (DTLS).

[0021] The device may be an end point device. The term end-point will be understood to refer to an end-point of a network. For example, in the AMI network, each endpoint may comprise at least one of: a collector; a gateway node, and / or a metering device such as a smart meter, or “edge-intelligence” or communications module associated with a smart meter. In some examples, an endpoint device may not be the final component at an end point of a network, and one end point device may communicate with a further end point device. The device may be or may comprise at least one of: a collector; a gateway node, a metering device such as a smart meter, a communications module or edge intelligence card / module, or the like. The communications module may be configured for communicating data between at least one end-point device and the HES.

[0022] The device may be a client device to the server.

[0023] The server may be an interface between a relatively constrained part of the network comprising the device, and a relatively unconstrained part of the network comprising the network module or HES.

[0024] The server may be a proxy server. The server may be or may comprise any suitable computing device, and in some examples may be a distributed computing device or system, such as a cloud computing device / system. The server may be operable to provide or exchange any suitable data to / with the device. The server may be remote from the device. The server may be operable to provide or exchange any suitable data to / with the network module.The device and the server may be configured to communicate using any suitable communication protocol, which may include wired and / or wireless communication, which may be over a mesh network.

[0025] The server may be configured as a proxy server, an enrollment over secure transport (EST) server, or EST proxy server.

[0026] The server may be configured as a registration authority configured to manage certificate requests from the device to a certificate authority.

[0027] The handshake may be a transport layer security (TLS) handshake, which in some examples may be a datagram TLS (DTLS) handshake. The handshake may be an EST handshake. The handshake may be carried out without a certificate.

[0028] The handshake may be a PSK-based session, which in some examples may be a PSK-based DTLS handshake session, and in yet further examples may be carried out without the use of a certificate.

[0029] The step of initialising the handshake may be carried out by the device.

[0030] The step of initialising the handshake may comprise transmitting a first introduction message from the device to the server. The first introduction message may be a ClientHello message. The first introduction message may include information on what cryptographic method(s) to be used for the handshake, which in some examples may include one or more algorithms, such as a CipherSuite, to be used.

[0031] The first introduction message may include a first identifier associated with the PSK of the device. In this example, the PSK may yet to have been generated or may have been generated at the device. The first identifier may be or may include a device identifier, such as an ID or LAN ID (Local Area Network ID), or the like.

[0032] The method may include sending, by the server to the device, a first acknowledgement of the first introduction message.

[0033] The first acknowledgement may be a ServerHello message.

[0034] The first acknowledgement may confirm what cryptographic method(s) to be used for the handshake, which in some examples may include the one or more algorithms, such as the CipherSuite, to be used.

[0035] The first acknowledgement message may include the first identifier associated with the PSK of the device. In this example, the PSK may yet to have been generated, or may have been generated at the device.

[0036] The first acknowledgement message may include an acknowledgement completion message. In some examples, the acknowledgement completion message may be a ServerHelloDone message, or the like.The method may comprise sending a key exchange request from the device to the server. The key exchange request may be for establishing secure communication between the device and the server. The key exchange request may be for generating a session key to be used for secure communication.

[0037] The key exchange request may be based, at least in part, on the PSK.

[0038] The session key may be created using, at least in part, the PSK generated from the device key. The device may create the session key. The server may create a corresponding session key. The server may generate the corresponding session key using the PSK received from the network module. The session key can be generated in any suitable manner.

[0039] The key exchange request may be a client key exchange request, which in some examples may be a ClientKeyExchange request.

[0040] The key exchange request may include the first identifier associated with the PSK of the device.

[0041] The method may comprise sending, by the device to the server, a first confirmation that secure communication will now be used. The first confirmation may be a ChangeCipherSpec message, or the like.

[0042] The step of generating the PSK by the device may be carried out after the first confirmation is sent, or before the handshake, or at any suitable point of the method.

[0043] The device key may be an endpoint device key.

[0044] The device key may take any suitable format. The device key may be preinstalled (pre-shared) at the device prior to carrying out the method or initialising the handshake thereof. The device key may be pre-installed (pre-shared) at the network module prior to carrying out the method or initialising the handshake thereof. The device key may be pre-shared at the device and the network module to generate the PSK used with the method. The device key may be unique for the device. The PSK may be generated from the device key in any suitable manner, such as according to the NIST SP 800-108 standard.

[0045] The method may comprise sending, by the device to the server, a request to end the handshake. The request to end may be a Finished message, or the like. The request to end the handshake may be sent by secure communication, which in some examples may use the session key.

[0046] The method may comprise requesting, by the server to the network module, the PSK. The request for the PSK may be a REST Call, or the like. The REST Call may be GetClientPSK.The step of generating the PSK by the network module may be in response to the request from the server for the PSK, before the handshake, or at any suitable point in time.

[0047] The method may comprise providing a second confirmation, from the server to the device, that secure communication will be used. The second confirmation may take the same format as the first confirmation. The second confirmation may be a ChangeCipherSpec message, or the like.

[0048] The second confirmation may be provided after the PSK has been received from the network module by the server.

[0049] The method may comprise sending, by the server to the device, a request to end the handshake. The request to end the handshake may be a Finished message, or the like. The request to end the handshake may be sent by secure communication, which in some examples may use the session key.

[0050] The step of validating the handshake may be carried out by using the PSK at the device and the PSK at the server in any suitable validation method, which may be any suitable cryptographic validation method.

[0051] The PSK at the device and the PSK at the network module are identical keys. Validating the handshake may establish a level of trust between the device and the server.

[0052] The method may comprise, after validation of the handshake, providing from the device to the server one or more certificate requests. The certificate requests may be EST requests. The server may obtain and provide certificates to the device from any suitable source, such as a certificate authority and / or the network module.

[0053] The method may comprise, after validation of the handshake, providing from the device to the server one or more enrolment requests, which may be EST request(s).

[0054] The method may comprise one or more communication steps between the device and the network module, which may be after the handshake is validated.

[0055] According to a second aspect of the disclosure, there is provided a system for establishing secure communication between a device and a server, the system comprising:

[0056] a device;

[0057] a server; and

[0058] a network module;

[0059] wherein the device is operable to initialise a handshake between the device and the server;wherein the device is operable to generate a pre-shared key (PSK) from a device key located at the device;

[0060] wherein the network module is operable to generate the PSK from a device key located at the network module;

[0061] wherein the network module is operable to provide the generated PSK from the network module to the server; and

[0062] wherein the system is operable to validate the handshake based, at least in part, on the PSK at the device and the PSK at the server.

[0063] According to a third aspect of the disclosure, there is provided a computer program product configured, when run, to cause a system to carry out the method of the first aspect of the disclosure.

[0064] According to a fourth aspect of the disclosure, there is provided a non-transitory computer-readable medium comprising instructions which, when run by a computing system, cause the system to carry out the method of the first aspect of the disclosure.

[0065] The above summary is intended to be merely an example 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.

[0066] BRIEF DESCRIPTION OF DRAWINGS

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

[0068] Figure 1 depicts an enrollment over secure transport (EST) workflow;

[0069] Figure 2 depicts another EST workflow; and

[0070] Figure 3 depicts a method of establishing secure communication between a device and a server within a network, in accordance with embodiments of the invention.DETAILED DESCRIPTION OF DRAWINGS

[0071] Embodiments of the invention will be described, and an embodiment is depicted in Fig. 3, but first a description of two enrollment over secure transport (EST) methods will be described with reference to Figs. 1 and 2.

[0072] EST as defined by the standard RFC7030 describes the use of Transport Layer Security (TLS) and Hypertext Transfer Protocol (HTTP) to provide an authenticated and authorized channel for Simple Public Key Infrastructure (PKI) Requests and Responses. Architecturally, the EST service (EST server in Fig. 1) is located between a Certification Authority (CA) (the Operational CA in Fig. 1) and a client (EST client in Fig. 1). The EST server performs several functions traditionally allocated to a Registration Authority (RA) role in a PKI.

[0073] Fig. 1 shows atypical EST workflow, in which an EST client is loaded with a trust anchor (TA) which verifies the identity of the EST client within the network and establishes the trust of the EST client. The EST client may be any suitable device, such as an endpoint device in an advanced meter infrastructure (AMI) network, but this is purely an example. The TA is typically installed to the client device at a factory (e.g. when the device is manufactured or configured for its purpose). The EST server also has a TA to establish its trust within the network.

[0074] Fig. 1 depicts a datagram TLS (DTLS) handshake between the EST client and EST server, which establishes secure communication to facilitate the acquisition of a certificate at the EST client, via the EST server and the CA. This acquisition of certificates relies on the EST client and EST server having an initial certificate in the form of a TA.

[0075] For brevity, a more detailed description of EST and DTLS will not be provided, as these protocols are well known.

[0076] With reference to Fig. 2, the standard RFC9148 defines a new transport for EST based on the Constrained Application Protocol (CoAP), since constrained devices and networks for the use-case of Internet-of-Things (loT) devices may use CoAP (user datagram protocol (UDP)) & CoAPs (DTLS) instead of HTTP (TCP) & HTTPS (TLS). In at least some examples, DTLS is used to secure CoAP messages. The authentication of the EST-CoAPs server by the EST-CoAPs client is based on certificate authentication in the DTLS handshake. EST-CoAPs clients are provided with an initial certificate or birth certificate during manufacturing.Once devices acquire the operational certificate, they use this certificate to perform network authentication with an AAA server (Radius server) in a typical network deployment, such as a WiSun network deployment as per Fig 2. As shown in Fig. 2, the network device requests to enroll with the EST proxy server or RA (registration authority), the RA obtains an operational certificate from the CA and provides the operational certificate to the network device. The network device can then obtain network authentication from the authentication server (AAA server). Again, this method relies on an initial certificate, or birth certificate at the network device.

[0077] The problem is that, in some cases devices are already installed in the field and there is no pre-installed birth certificate, or other initial certificate, with those devices. One such instance will be when these devices are deployed as part of a first type of network communication protocol, such as an RF Mesh IP network deployment, for example provided by Landis+Gyr, but now those devices are required to be transitioned to a second type of network communication protocol, such as a Wi-Sun Field Area Network (FAN). This creates problems with performing EST handshaking as there is no initial certificate at the device.

[0078] The Wi-SUN communication protocol may rely on EAP-TLS (Extensible Authentication Protocol-TLS authentication). If the EST methods of Figs. 1 and 2 were used to acquire the required certificate for the devices currently on an RF Mesh IP to be able to then use WI-SUN FAN, the devices would need to be provided with an initial certificate. This is one example, and there are many examples of switching from one mode to another.

[0079] Providing certificates to devices, while they are in an RF Mesh IP network, present some challenges, which may include one or more of the following: additional network traffic to download the point-to-point certificate on each device in a large deployment; cost to generate a certificate for each device and this becomes significant in a large deployment; time and resources required to download the certificate on each device at scale level including the management of the Certificate Authority (CA) that will issue the certificate for each device; implementation cost in a network module such as a head end system (HES) to implement certificate download workflow.

[0080] Additionally, the certificate-based EST handshake impacts network bandwidth in a constrained network or part thereof. A constrained network or part thereof, as known in the art, is a network or part thereof that operates under one or more restricted resource conditions, such as reduced power consumption, bandwidth, etc, and a constraineddevice is construed similarly as a device that operates with reduced resource(s) relative to at least a part of the network.

[0081] At least some embodiments of the invention solve the above problem by performing a handshake (e.g. an EST handshake) without any certificates or any unique device keys, by using pre-shared keys. In at least some embodiments, the invention saves network bandwidth and / or costs for transitioning from one network technology to another network technology, and / or addresses one or more of the drawbacks detailed above and / or other disadvantages of current methods. For example, in some networks of end point devices, such as AMI, there may be hundreds of thousands, or millions of devices, and therefore avoiding the need for an initial certificate at each device comes with significant benefits, but of course the invention is not limited to such a size of network.

[0082] The description of Wi-SUN and RF Mesh IP, and the comparison between the two, is provided as an example of moving a device from one communication protocol to another and is illustrative in that other communication protocols could be applicable, and there may be other reasons to want to provide a device with a certificate than that described in relation to Figs. 1 and 2. The invention is not limited to the specific communication protocols listed here.

[0083] Turning now to an embodiment of the invention, as shown in Fig. 3, a description of the hardware and network arrangement will be provided, followed by a method of establishing secure communication between a device and a server (labelled EST proxy in Fig. 3) within the network.

[0084] Although not shown in Fig. 3, the network comprises a plurality of devices, and is a utility meter network in the form of an electrical power meter network and specifically an advanced metering infrastructure (AMI) network, but the invention is applicable to various devices, including various types of utility meter such as for electrical power, gas, water, or the like, and various networks, and the use of AMI is merely illustrative.

[0085] In the embodiment of Fig. 3, a network module is present in the form of a headend system (HES) and may comprise any suitable component parts, such as one or more servers or the like. In this embodiment, the HES is 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, such as a utility provider or the like. In the AMI network of Fig. 3, the HES provides a communication and data collection layer between a smart meter infrastructure and a utility’s IT systems. The head-end system is configured toenable secure communication to the metering infrastructure, which includes the device at the left-hand side of Fig. 3.

[0086] The device (labelled Device in Fig. 3) is an endpoint Internet of Things (loT) device. In the embodiment of Fig. 3, the device is a constrained loT device relative to the server and the HES. Using the example of Figs. 2 and 3, before commencing the method of Fig. 3, the device communicates with the HES using a first network communication method, RF Mesh IP, and the method of Fig. 3 will enable the device to communicate with the HES using a second network communication method, Wi-SUN FAN. In other embodiments, the first network communication method may include at least one of: a mesh network, RF method, RF mesh network, and internet protocol (IP)-based method, an RF IP method, an IP mesh network method, an RF mesh IP network, a wired method, a wireless method, and / or one or more other methods, and the second network communication method may include at least one of: a wireless method, a wired method, a utility network, a field area network, a smart network, a smart utility network, a wireless utility network, a wireless smart utility network, and / or one or more other methods. The communication path between the device and the HES may at least partially include the first network communication method, and the method of Fig. 3 may comprise configuring the endpoint device to communicate with the HES at least partially including the second network communication method. For example, the part of the network near to the plurality of devices may use the first and second network communication methods, and the part of the network near to the HES may make use of different communication methods, but this is purely an example illustrating that for constrained end point devices, the network protocols may differ as one progresses from the HES, or network module, to each device.

[0087] For the method of Fig. 3, the endpoint device has been configured to communicate with the network, including the HES and the server using a constrained device communication protocol, which in this embodiment is the Constrained Application Protocol (CoAP) including use of DTLS. It will be appreciated that the device could communicate with the network using one or more other protocols, and the inventive concept may be applicable to other such protocols including other versions of CoAP, TLS, DTLS, or the like. The endpoint device and the EST proxy server may be configured to communicate in the network using any suitable communication protocol, which may include wired and / or wireless communication.

[0088] The term end-point in relation to the endpoint device will be understood to refer to an end-point of the network, but the device need not be the final point of the network. For example, in the AMI network, each endpoint may comprise at least one of: a collector;a gateway node, and / or a metering device such as a smart meter, or “edge-intelligence” or communications module associated with a smart meter. In some examples, an endpoint device may not be the final component at an end point of the network, and one end point device may communicate with a further end point device. The device may be or may comprise at least one of: a collector; a gateway node, a metering device such as a smart meter, a communications module or edge intelligence card / module, or the like. The communications module may be configured for communicating data between at least one end-point device and the HES. In some applications, the endpoint devices may be geographically spread over a large area, such as a municipal or local area, a county, region, state, country, or group of countries or the like, the devices being associated with a HES. Groups of devices may be grouped in a field area network (FAN), and the HES may manage one or more FANs. Architecturally, the endpoints will be generally remote from the HES, but each endpoint may comprise any suitable number of end point devices.

[0089] The method is an EST-based method, and the device is a client device to the EST proxy server. However, the use of EST is an example, as is the use of an EST proxy server, and the inventive concept of acquiring certificates without an initial certificate is applicable to other methods besides EST, and other servers besides an EST and / or proxy server.

[0090] The EST proxy server is an interface between a relatively constrained part of the network comprising the device, and a relatively unconstrained part of the network comprising the HES. In some embodiments, the constrained part of the network uses the constrained communication protocol, and the unconstrained part of the network uses another protocol, or they may use the same protocol.

[0091] The EST proxy server may comprise any suitable computing device, and in some examples may be a distributed computing device or system, such as a cloud computing device / system. The EST proxy server is operable to provide or exchange any suitable data to / with the device. The EST proxy server is remote from the endpoint device. The EST proxy server is operable to provide or exchange any suitable data to / with the HES.

[0092] The EST proxy server is configured to fulfil the function of a registration authority (RA) within the method of Fig. 3, and configured to manage certificate requests from the endpoint device to a certificate authority (GA). In this embodiment, the HES can act as a CA, or can act as a further RA to obtain certificate(s) from a CA for each device that requires a certificate.T urning now to the steps of the method of the embodiment of Fig. 3, the method comprises initialising a handshake between the device and the EST proxy server. The handshake is an EST handshake using DTLS and based on the CoAP protocol. One of the advantages is that the handshake is carried out without a certificate, as the handshake relies on the use of a pre-shared key (PSK) at the device and a PSK at the HES. As will be described later, although the PSKs are not, in Fig. 3, pre-shared themselves, they are derived from a pre-shared endpoint device key, which is also a PSK. However, the term PSK in relation to Fig. 3 will generally refer to the PSKs that are used to validate the handshake. The handshake is a PSK-based DTLS handshake session, carried out without the use of a certificate, and subsequent certificates, such as operational certificates, can be obtained after the validation of the handshake. Establishing secure communication between the device and the EST proxy server and the HES, to then configure the device for compliance with another communication protocol, does not require a certificate at the device, such as an initial certificate or birth certificate, although of course in situations where a certificate does exist at the device, the method of Fig. 3 could still be used. Furthermore, eliminating the need for an initial certificate at the device is beneficial for the reasons outlined above, but also the provision of operational or other certificates over the network may be at least in some examples generally easier than rolling out initial or birth certificates to every device in the network.

[0093] In the embodiment of Fig. 3, the step of initialising the DTLS handshake is carried out by the device, but in other cases it may be initialised in a different manner, and it will be apparent that the handshake could take many different forms, need not use DTLS and / or EST, and one or more of the steps of Fig. 3 could be omitted, re-ordered and / or replaced with a different step as required without departing from the scope of the invention.

[0094] Initialising the handshake comprises transmitting a first introduction message from the device to the EST proxy server, which is a ClientHello message including information on what cryptographic method(s) to be used for the handshake. In this example, a CipherSuite is specified. The first introduction message also includes a first identifier associated with the PSK of the device. In this example, the PSK may yet to have been generated or may have been generated at the device. The first identifier is the Local Area Network ID (LAN ID) of the device, but maybe or may include any suitable device identifier, such as an ID, or the like. The LAN ID is sent within the pskidentity part of the first introduction message.The EST proxy server, in response to the ClientHello, sends a first acknowledgement, which is a ServerHello, of the first introduction message to the device. The first acknowledgement confirms what cryptographic method(s) are to be used for the handshake, which in this example is the CipherSuite sent by the device. The first acknowledgement message also includes the first identifier associated with the PSK of the device. In this example, it does not matter whether the PSK may yet to have been generated, or may have been generated at the device, as the first identifier does not include the PSK. The ServerHello includes the LAN ID of the device as the pskidentity.

[0095] The first acknowledgement message also includes an acknowledgement completion message in the form of a ServerHelloDone message. These commands described in relation to Fig. 3 may be replaced in other protocols, and are in no way intended to limit the scope of the invention.

[0096] Once the device receives the acknowledgment completion message from the EST proxy server, the method comprises sending a key exchange request in the form of a ClientKeyExchange from the device to the EST proxy server for establishing secure communication between the device and the server by generating a session key to be used for secure communication. The session key is created by the endpoint device using the PSK generated from the device key. The session key can be generated in any suitable manner, and for brevity a detailed description of session keys will not be provided.

[0097] The key exchange request includes the first identifier associated with the PSK of the device, specifying again the LAN ID of the device.

[0098] The device then sends to the EST proxy server a first confirmation that secure communication will now be used. The first confirmation is a ChangeCipherSpec message. Secure communication will be established using the PSK.

[0099] In the embodiment of Fig. 3, the device has already been installed with an endpoint device key, and the HES also has a copy of the endpoint device key, and these keys are used to generate PSKs for validating the handshake.

[0100] Once the ChangeCipherSpec message has been sent to the EST proxy server, the device generates a PSK from the endpoint device key located at the device. However, in other embodiments, the PSK could be generated at other stages of the method, or in some cases before the method commences.

[0101] The device key can take any suitable format and may be pre-installed at the device, and pre-installed at the HES or network module prior to carrying out the method. The device key is pre-shared at the device and the HES to generate the PSK used withthe method. The device key is unique for the device within the network. The PSK can be generated from the device key in any suitable manner, such as according to the NIST SP 800-108 standard.

[0102] In the embodiment of Fig. 3, once the PSK is generated at the device, the method comprises sending, by the device to the EST proxy server, a request to end the handshake in the form of a Finished message. This does not end the handshake at this point in the method. The request to end the handshake is encrypted (sent by secure communication) using the session key derived from the PSK.

[0103] Next, the method comprises requesting, by the EST proxy server to the HES, the PSK of the device (a client PSK). The request for the PSK is a REST Call in the form of GetClientPSK. REST commands will not be described in detail for brevity.

[0104] In response, the HES generates the PSK from the pre-shared endpoint device key located at the HES. In other embodiments, the PSK may be generated by the HES or network module in response to the request from the server for the PSK, before the handshake, or at any suitable point in time. The PSK at the device and the PSK at the network module are identical keys.

[0105] The PSK generated at the HES is sent to the EST proxy server.

[0106] The method comprises providing a second confirmation, from the EST proxy server to the endpoint device, that secure communication will be used. The second confirmation takes the same format as the first confirmation in the form of a ChangeCipherSpec message, and is provided after the PSK has been received from the HES by the EST proxy server.

[0107] Next, the method comprises sending, by the EST proxy server to the endpoint device, a request to end the handshake in the form of a Finished message. The request to end the handshake is encrypted to be sent by secure communication using a corresponding session key. The EST proxy server creates the corresponding session key from the PSK received from the HES.

[0108] The handshake has now been validated based, at least in part, on the PSK at the endpoint device and the PSK at the EST proxy server, and this can be carried out in any suitable validation method, which may be any suitable cryptographic validation method.

[0109] Validating the handshake establishes a level of trust between the device and the EST proxy server.

[0110] After validation of the handshake, the device may provide to the server one or more certificate requests, which in the embodiment of Fig. 3 are EST requests. The EST proxy server may obtain and provide the certificate(s) to the device from any suitablesource, such as the HES, a certificate authority and / or a network module. The method may also comprise, after validation of the handshake, providing from the device to the EST proxy server one or more enrolment requests, which may be EST request(s). The CACerts command obtains the trust anchors from the EST proxy server and the enroll command will get the device operational certificate from the certificate authority.

[0111] The method may comprise one or more other secure communication steps between the device and the HES after the handshake is validated.

[0112] Although the disclosure has been described in terms of 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 establishing secure communication between a device and a server within a network, the method comprising:initialising a handshake between the device and the server; generating, by the device, a pre-shared key (PSK) from a device key located at the device;generating, by a network module, the PSK from a device key located at the network module;providing the generated PSK from the network module to the server; and validating the handshake based, at least in part, on the PSK at the device and the PSK at the server.

2. The method of claim 1 , wherein the network is a utility meter network, or an electrical power meter network, or an advanced metering infrastructure (AMI) network, and the network module is or comprises a head-end system (HES), and the device is an endpoint device comprising at least one of: a collector; a gateway node, and / or a metering device such as a smart meter, or edge-intelligence or communications module associated with a smart meter.

3. The method of claim 1 or claim 2, wherein the method comprises configuring the device from use with one or more first network communication methods to one or more second network communication methods.

4. The method of any preceding claim, wherein the server is at least one of a proxy server and an enrollment over secure transport (EST) server.

5. The method of any preceding claim, wherein the handshake is an EST handshake using datagram transport layer security (DTLS).

6. The method of any preceding claim, wherein the handshake is carried out without using a certificate.

7. The method of any preceding claim, wherein the step of initialising the handshake comprises transmitting a first introduction message from the device to the server, including a first identifier associated with the PSK of the device.

8. The method of claim 7, wherein the first identifier is or includes a device identifier, such as an ID or LAN ID.

9. The method of any preceding claim, wherein the method comprises sending a key exchange request from the device to the server for establishing secure communication between the device and the server, and wherein the key exchange request is for generating a session key to be used for secure communication, wherein the session key is created based, at least in part, on the PSK.

10. The method of claim 9, wherein the key exchange request includes the first identifier.

11. The method of any preceding claim, wherein the device key is pre-shared at the device and the network module before the handshake is initialised.

12. The method of any preceding claim, wherein the method comprises requesting, by the server to the network module, the PSK.

13. The method of claim 12, wherein the step of generating the PSK by the network module is in response to the request from the server for the PSK.

14. The method of any preceding claim, wherein the method comprises, after validation of the handshake, providing from the device to the server one or more certificate requests.

15. The method of any preceding claim, wherein the device is configured to communicate with the network, including the server and / or network module, using a constrained device communication protocol.

16. The method of claim 15, wherein the constrained device communication protocol is a Constrained Application Protocol (CoAP).

17. The method of any preceding claim, wherein the device is configured to communicate with the network, including the server and / or network module, using transport layer security (TLS), or datagram TLS (DTLS).

18. A system for establishing secure communication between a device and a server, the system comprising:a device;a server; anda network module;wherein the device is operable to initialise a handshake between the device and the server;wherein the device is operable to generate a pre-shared key (PSK) from a device key located at the device;wherein the network module is operable to generate the PSK from a device key located at the network module;wherein the network module is operable to provide the generated PSK from the network module to the server; andwherein the system is operable to validate the handshake based, at least in part, on the PSK at the device and the PSK at the server.

19. A computer program product configured, when run, to cause a system to carry out the method of any of claims 1 to 17.

20. A non-transitory computer-readable medium comprising instructions which, when run by a computing system, cause the system to carry out the method of any of claims 1 to 17.

Images