阅读说明：本技术 用于高级计量基础设施的密钥管理 (Key management for advanced metering infrastructure ) 是由 马丁·特兰贝里·汉森 赫尔本·奎吉帕斯 卡连·埃里沙贝特·埃格德·尼尔森 于 2021-05-14 设计创作，主要内容包括：一种用于以安全方式替换布置在仪表通信基础设施中的公用事业仪表中的现有密钥导出密钥的方法。提供了用于交换对称密钥的安全机制,而不需要跨仪表通信基础设施传送密钥。从前端系统向公用事业仪表发射命令数据消息,其包括用于将现有密钥导出密钥替换为新的密钥导出密钥的请求、密钥代信息、和激活密钥或基于激活密钥计算的认证码。接收命令数据消息的公用事业仪表被布置为基于存储在公用事业仪表中的灾难恢复密钥的副本并基于包括在接收的命令数据消息中的密钥代信息来导出新密钥导出密钥。公用事业仪表被布置用于从新密钥导出密钥导出激活密钥。激活密钥用于验证命令数据消息。若命令数据消息被验证,将现有密钥导出密钥替换为新密钥导出密钥。(A method for replacing an existing key-derived key in a utility meter arranged in a meter communication infrastructure in a secure manner. A security mechanism for exchanging symmetric keys is provided without the need to transfer keys across the meter communication infrastructure. A command data message is transmitted from the head-end system to the utility meter that includes a request to replace an existing key-derivation key with a new key-derivation key, key generation information, and an activation key or an authentication code calculated based on the activation key. The utility meter receiving the command data message is arranged to derive a new key derivation key based on a copy of the disaster recovery key stored in the utility meter and based on the key generation information included in the received command data message. The utility meter is arranged for deriving the activation key from the new key. The activation key is used to authenticate the command data message. If the command data message is authenticated, the existing key derivation key is replaced with the new key derivation key.)

1. A method for replacing an existing key derivation key (KDK1) in a utility meter (102) arranged in a Meter Communication Infrastructure (MCI) for communication with a Server Side (SS) comprising a head-end system (HES), the method comprising the steps of:

-deriving a new key derivation key (KDK2) at the Server Side (SS) based on the Disaster Recovery Key (DRK) and Key Generation Information (KGI) stored at the server side;

-deriving an Activation Key (AK) at the server side from the new key derivation key (KDK 2);

-transmitting a Command Data Message (CDM) from the head-end system (HES) to the utility meter, the command data message comprising:

-a request for replacing the existing key derivation key (KDK1) with the new key derivation key (KDK 2);

-the Key Generation Information (KGI); and

-the Activation Key (AK) or an authentication code (CDM-AC) calculated on the basis of the Activation Key (AK);

-receiving the Command Data Message (CDM) in the utility meter;

-deriving the new key derivation key (KDK2) in the utility meter based on a copy of the Disaster Recovery Key (DRK) stored in the utility meter and based on the key generation information comprised in the received Command Data Message (CDM);

-deriving the Activation Key (AK) from the new key derivation key (KDK2) in the utility meter;

-verifying in the utility meter the Activation Key (AK) or the authentication code (CDM-AC) received in the Command Data Message (CDM) based on the derived Activation Key (AK); and

-replacing in the utility meter the existing key derivation key (KDK1) with the new key derivation key (KDK2) when the Activation Key (AK) or the authentication code (CDM-AC) comprised in the received Command Data Message (CDM) is verified.

2. The method according to claim 1, wherein the Server Side (SS) Disaster Recovery Key (DRK) is stored in the Secure Environment (SE).

3. The method according to any one of the preceding claims, wherein the new key derivation key (KDK2) of the Server Side (SS) is derived in the Secure Environment (SE) before being transmitted to the head-end system (HES) or Key Management System (KMS).

4. The method according to any of the preceding claims, wherein the Disaster Recovery Key (DRK) used at the server side is stored in a secure environment in the form of a Hardware Security Module (HSM).

5. A Command Data Message (CDM) for replacing an existing key derivation key (KDK1) in a utility meter with a new key derivation key (KDK2), the Command Data Message (CDM) comprising:

-a request for replacing the existing key derivation key (KDK1) with the new key derivation key (KDK 2);

-Key Generation Information (KGI);

-an Activation Key (AK) or an authentication code (CDM-AC) calculated on the basis of the Activation Key (AK);

characterized in that the Activation Key (AK) is derived based on the new key derivation key (KDK2), and the new key derivation key (KDK2) is derived based on at least the key generation information.

6. Command data message according to claim 5, wherein the new key derivation key (KDK2) is not included in the data command message (CDM).

7. The command data message according to any of claims 5 and 6, wherein the Command Data Message (CDM) is sent as clear text.

8. A utility meter (102) arranged for communicating with a head-end system (HES) in a Meter Communication Infrastructure (MCI), the utility meter comprising:

-a communication interface for interfacing with the meter communication infrastructure;

-a Disaster Recovery Key (DRK) stored in a memory of the meter;

-an existing key derivation key (KDK 1);

-a Key Derivation Function (KDF);

wherein the utility meter is configured to:

-receiving a Command Data Message (CDM) according to any one of claims 5 to 7 via the communication interface;

-deriving a new key derivation key (KDK2) by inputting at least the Disaster Recovery Key (DRK) stored in the utility meter and Key Generation Information (KGI) comprised in the received Command Data Message (CDM) to the Key Derivation Function (KDF);

-deriving an Activation Key (AK) from the new key derivation key (KDK 2);

-verifying an Activation Key (AK) or an authentication code (CDM-AC) received in the Command Data Message (CDM) based on the derived Activation Key (AK); and

-replacing the existing key derivation key (KDK1) with the new key derivation key when the Activation Key (AK) or authentication code comprised in the received Command Data Message (CDM) is verified.

9. The utility meter of claim 8, further arranged for using an application key (APK) derived in the utility meter using key derivation keys (KDK1, KDK2) for secure communication with the head-end system (HES).

10. A Meter Communication Infrastructure (MCI), such as a meter reading system, for replacing an existing key derivation key (KDK1), the communication infrastructure comprising:

-a plurality of site end (FS) utility meters (2);

-a Server Side (SS) front end system (HES) configured for secure communication with the field side utility meters using an application key (APK) derived at the server side and the Field Side (FS) using a Key Derivation Key (KDK); and

-a server side Secure Environment (SE) for storing a Disaster Recovery Key (DRK);

wherein the server side is configured to derive a new key derivation key (KDK2) based on a Disaster Recovery Key (DRK) stored in the secure environment and based on Key Generation Information (KGI); and is

Wherein the site-end utility meters are configured to receive a Command Data Message (CDM) from the head-end system, the command data message instructing the utility meter to use a Disaster Recovery Key (DRK) stored in the utility meter and derive a new key derivation key (KDK2) that is the same as the new key derivation key (KDK2) derived at the server-end based on key generation information received in the Command Data Message (CDM).

11. A meter communications infrastructure according to claim 10, wherein the Server Side (SS) is further configured to obtain existing key generation information about the existing key derivation key (KDK1) from the utility meter, and to derive key generation information for the new key derivation key (KDK2) based at least on the obtained existing key generation information.

12. A meter communication infrastructure according to any of claims 10 and 11, wherein the Server Side (SS) comprises:

-a front-end system (HES) configured for constructing and sending the command data message to the utility meters and/or retrieving existing key generation information about the existing key derivation key (KDK1) from the utility meter; and

-a secure environment configured for deriving the new key derivation key (KDK 2).

13. The meter communication infrastructure according to claim 12, wherein the secure environment is for storing the Disaster Recovery Key (DRK) protected by a Hardware Security Module (HSM).

14. A meter communication infrastructure according to any of claims 10 to 13, wherein the utility meter is a utility meter according to any of claims 8 and 9, and the meter communication infrastructure is arranged to perform the method of any of claims 1 to 4.

Technical Field

The present invention relates to the field of methods for managing cryptographic keys in advanced metering infrastructures, and in particular to methods for recovering and replacing cryptographic keys when they are compromised or lost.

Background

Meter communication infrastructures, such as Advanced Metering Infrastructure (AMI) systems, are well known in the art. Utility companies use such meter communication infrastructure, typically using Radio Frequency (RF) communications, to remotely read and monitor utility meters. The meter communication infrastructure improves the efficiency and accuracy of collecting readings, managing customer bills, and enables data-driven network management.

The meter communication infrastructure is complex and may include many elements and use a variety of technologies, some of which will be mentioned below. Advanced Meter Reading (AMR) systems typically use a mobile RF communications network to collect meter readings and data, while AMI systems typically use a fixed RF communications network or Power Line Communications (PLC). The AMI system may include a plurality of intermediate collectors throughout a larger geographic area, each of which in turn communicates with a head-end system (HES), for example, by using a Wide Area Network (WAN) or other suitable communication infrastructure. AMI systems may also utilize systems with repeaters or relay devices that extend the coverage area of each reader by forwarding meter readings and data. The AMI system may be based on: a common cellular telecommunications infrastructure, such as GSM, LTE, NB-IOT or any generation of telecommunications (such as 3G, 4G, 5G); or other communication infrastructure based on, for example, LORA or Sigfox. In a mobile network AMR environment, a handheld, vehicle-mounted, or other mobile reader device with RF communication capabilities is used to collect data from a utility meter device as the mobile reader moves about.

Meter readings, including consumption data and other meter data (such as flow, temperature, pressure, voltage, current, etc.) are generally considered confidential information and must be protected from unauthorized data access or manipulation. The main purpose of protection is to ensure confidentiality/privacy and authenticity of the transmitted data. Further authentication and authorization may be a purpose in advanced metering infrastructures. One way to protect meter readings, other meter data, and meter functionality is to use a cryptographic method. The cryptographic method uses a cryptographic key of the following keys, by way of example only.

Confidentiality/privacy may be provided by encrypting data using a cryptographic method such as Advanced Encryption Standard (AES). The meter data may be encrypted using a key at the transmitting device (e.g., the meter) and decrypted using the same key at the receiver (e.g., the head-end system HES). When data is encrypted and decrypted using the same key, these keys are referred to as symmetric keys.

The authenticity of the data may be provided through the use of a Message Authentication Code (MAC). The MAC is calculated at the transmitter side based on the data to be protected using a cryptographic method and a key, and the MAC is recalculated at the receiver based on the cryptographic method, the key and the received data.

The use of symmetric key based end-to-end encryption and message authentication provides a relatively simple and very reliable data protection scheme by which the communication link between the utility meter and the head-end system can be protected/ensured. However, if the key used is compromised, the communication link between the head-end system and the utility meter will no longer be secure. The communication link protected by the compromised key can no longer be used to replace the compromised key in the utility meter with a new key in a secure manner. Since systems typically include thousands or even millions of meters, manually replacing keys is also not a viable solution. The keys may be compromised because a third party gains unauthorized access to the keys, or the keys may have been lost (i.e., they are no longer accessible), for example, due to a hacking attack or computer virus.

Therefore, there is a need for a method and support system for securely and efficiently replacing compromised keys in a meter reading system, particularly in a system that uses symmetric keys and end-to-end communication. It is particularly desirable to replace keys in utility meters installed at customers by a meter communication infrastructure that does not require a service visit.

Object of the Invention

It is an object of the present invention to provide a secure, reliable and efficient method and system for replacing keys, including compromised keys in utility meters, through a meter communication infrastructure.

Disclosure of Invention

Thus, in a first aspect of the present invention, the above object and several other objects are intended to be achieved by providing a method for replacing an existing key-derived key in a utility meter arranged in a meter communication infrastructure for communicating with a server side comprising a head-end system, the method comprising the steps of: -deriving a new key derivation key at the server based on the disaster recovery key stored at the server and key generation information; -deriving an activation key from the new key derivation key at the server side; -transmitting a command data message from the head-end system to the utility meter, the command data message comprising: a request for replacing the existing key-derivation key with the new key-derivation key; the key represents information; and the activation key or an authentication code calculated based on the activation key; -receiving the command data message in the utility meter; -deriving the new key derivation key in the utility meter based on a copy of the disaster recovery key stored in the utility meter and based on the key generation information included in the received command data message; -deriving, in the utility meter, the activation key from the new key derivation key; -verifying in the utility meter the activation key or the authentication code received in the command data message based on the derived activation key; and-replacing the existing key derivation key with the new key derivation key in the utility meter when the activation key or the authentication code included in the received command data message is verified.

An advantage of this approach is that the request to replace an existing key derivation key can be generated independently of the state or current/existing key derivation key in the utility meter. This means that a request to replace an existing key derivation key can be generated and executed by the method even if the server-side/front-end system does not know the existing key derivation key. Further, the advantage of this approach is that a third party gaining unauthorized access to the key derivation key will not be able to replace the existing key derivation key and take over control of the utility meter. Yet another advantage is the self-authentication effect of the command data message caused by the activation key derived from the new key derivation key, thereby proving possession of the new key derivation key and possession of the new key derivation key is necessary to generate the command data message. A further advantage is that the key derivation key does not have to be transmitted over the meter communication infrastructure and the command data message can actually be transmitted in clear text, which has the effect that no secure channel between the utility meter and the head-end system/server end and the field end is required to replace the key derivation key.

Verifying the activation key or authentication code should be understood as the utility meter approving the activation key or authentication code. Thus, if the activation key or authentication code is approved, it is verified. As an example, approving/verifying the activation key or authentication code may be done by comparing the received activation key or authentication code with the derived activation key or authentication code, and if they are the same, the received activation key or authentication code is verified/approved. If the activation key or authentication code included in the received command data message is verified, the existing key derivation key in the utility meter is replaced with the new key derivation key. If the activation key or authentication code included in the received command data message is not verified, the existing key derivation key in the utility meter is not replaced with the new key derivation key. In other words, the method may comprise the steps of: -deriving, in the utility meter, an activation key and/or an authentication code from the new key; -using the derived activation key and/or authentication code in the utility meter to verify the correctness of the activation key and/or authentication code received in the command data message; -if the correctness of the received activation key and/or the certification code can be verified, replacing the existing key derivation key with the new key derivation key in the utility meter, and if the correctness of the received activation key and/or the certification code cannot be verified, discarding the new key derivation key without replacing the existing key derivation key in the utility meter. As an example, if the received activation key and/or authentication code is the same as the derived activation key and/or authentication code, the correctness of the received activation key and/or authentication code can be verified. As an equivalent alternative to all of the above method steps, the derived activation key and/or authentication code may be verified based on the activation key and/or authentication code received in the command data message.

It may be particularly advantageous if the server-side disaster recovery key is stored in a secure environment. A secure environment should be understood as an environment with limited access or an environment separate from the head-end system. Alternatively, the secure environment may be a hardware security module or server and may have a different physical location than other elements on the server side.

The new key derivation key at the server side may be derived in the secure environment before being transmitted to the head-end system or key management system. This has the advantage that the disaster recovery key can be kept in a secure environment. An advantage of the present invention is that a set of disaster recovery keys for all utility meters is maintained in a secure environment. This means that an attacker must gain access to the secure environment or each utility meter in order to gain access to the set of disaster recovery keys. In particular, the disaster recovery key used at the server side may be stored in the secure environment in the form of a hardware security module.

The method according to the first aspect may optionally be seen as a method for replacing an existing key derivation key in a utility meter and in a server-side and/or head-end system, and the method may comprise the further step of storing a new key derivation key in the server-side and/or head-end system.

In a second aspect of the invention, there is provided a command data message for replacing an existing key derivation key in a utility meter with a new key derivation key, the command data message comprising: -a request for replacing the existing key derivation key with the new key derivation key; -key generation information; -an activation key or an authentication code calculated based on the activation key; wherein the activation key is derived based on the new key derivation key, and the new key derivation key is derived based on at least the key generation information. Such a command data message has the advantage of being self-authenticating based on the new key derivation key, the command data message requesting the utility meter to replace an existing key derivation key with the new key derivation key. A further advantage is that the message can be sent in clear text, since no new key derivation key is included in the message. The request for replacement of the key derivation key may be explicitly indicated in the command data message or may be implicitly stated, for example, in the form of a command ID indicating the desired request.

The activation key or authentication code included in the command data message has the purpose of providing a means for verifying one or more of the following: authenticity of the command data message, authorization of the front-end system, authentication of the front-end system. Or in other words, the activation key or authentication code included in the command data message has the purpose of providing proof that the entity generating the command data message possesses the new key derivation key.

The command data message according to the second aspect may be a command data message, wherein the new key derivation key is not included in the data command message. And the command data message according to the second aspect may be a command data message sent as clear text.

The command data message may be a physical message of data transmitted through a transmission channel such as a radio communication channel or a wired communication channel, or a message stored in a memory device for data storage.

In a variant of the second aspect of the invention, a storage device for data storage is provided, the storage device being arranged for storing command data messages. In a further variant of the second aspect, a communication device, such as a radio communication device, arranged for transmitting or receiving command data messages according to the second aspect is provided.

In a third aspect of the invention, there is provided a utility meter arranged for communication with a head-end system in a meter communication infrastructure, the utility meter comprising: -a communication interface for interfacing with the meter communication infrastructure; -a disaster recovery key stored in a memory of the meter; -an existing key derivation key; -a key derivation function; wherein the utility meter is configured to: -receiving a command data message according to the second aspect of the invention via the communication interface; -deriving a new key derivation key by inputting at least the disaster recovery key stored in the utility meter and key generation information included in the received command data message to the key derivation function; -deriving a key-derived activation key from the new key; -verifying the activation key or authentication code received in the command data message based on the derived activation key; and-replacing the existing key derivation key with the new key derivation key when the activation key or authentication code included in the received command data message is verified.

The utility meter has the advantage that even in case the key derivation key has been compromised, the command data message can be verified and the key derivation key replaced in a secure way.

Verifying the activation key or authentication code should be understood as the utility meter approving the activation key or authentication code. Thus, if the activation key or authentication code is approved, it is verified. For example, approving/verifying the activation key or authentication code may be accomplished by the meter comparing the received activation key or authentication code to the derived activation key or authentication code, and if they are the same, the received activation key or authentication code is verified/approved. If the activation key or authentication code included in the received command data message is verified, the existing key derivation key in the utility meter is replaced with the new key derivation key. If the activation key or authentication code included in the received command data message is not verified, the existing key derivation key in the utility meter is not replaced with the new key derivation key. In other words, the utility meter may be arranged to: deriving a key from the new key to derive an activation key and/or an authentication code; verifying the correctness of the activation key and/or the authentication code received in the command data message by using the derived activation key and/or authentication code; and if the correctness of the received activation key and/or authentication code can be verified, replacing the existing key derivation key with the new key derivation key in the utility meter; and if the correctness of the received activation key and/or authentication code cannot be verified, discarding the new key derivation key without replacing the existing key derivation key in the utility meter. As an example, if the received activation key and/or authentication code is the same as the derived activation key and/or authentication code, the correctness of the received activation key and/or authentication code can be verified. As an equivalent alternative to all of the above method steps, the derived activation key and/or authentication code may be verified based on the activation key and/or authentication code received in the command data message.

The utility meter according to the third aspect of the invention may further be arranged for securely communicating with the head-end system using an application key derived in the utility meter using a key derivation key. This has the advantage that the replacement of the key derivation key will further require the replacement of all application keys.

In a fourth aspect of the present invention there is provided a meter communication infrastructure, such as a meter reading system, for replacing an existing key derivation key, the communication infrastructure comprising: -a plurality of field-end utility meters; -a server-side front-end system configured for secure communication with the field-side utility meters using an application key derived at the server-side and the field-side using key-derived keys; -a server-side secure environment for storing a disaster recovery key; wherein the server side is configured to derive a new key derivation key based on disaster recovery keys stored in the secure environment and based on key generation information; and wherein the field-end utility meters are configured to receive a command data message from the head-end system instructing the utility meter to use a disaster recovery key stored in the utility meter and derive a new key derivation key that is the same as the key derivation key derived at the server-end based on key generation information received in the command data message.

The meter communication infrastructure has the advantage that the key derivation key can be replaced in a secure manner even in the event that an existing key derivation key has been lost or is already available to a fraudulent third party.

The server side may be further configured to obtain existing key generation information regarding the existing key derivation key from the utility meter and derive key generation information for the new key derivation key based at least on the obtained existing key generation information.

In the meter communication infrastructure according to the fourth aspect of the present invention, the server side may further include: -a front-end system configured to construct and send command data messages to the utility meters and/or to obtain existing key generation information about the existing key derivation key from the utility meter; and-a secure environment configured for deriving the new key derivation key.

Further, the secure environment of the meter communication infrastructure may be used to store the disaster recovery key protected by a Hardware Security Module (HSM).

In a meter communication infrastructure according to a fourth aspect of the invention, the utility meter may be a utility meter according to the third aspect of the invention and the meter communication infrastructure may be arranged to perform a method according to the first aspect of the invention.

In the first, second, third and fourth aspects of the invention, optionally, at least one of the key derivation key, the disaster recovery key or the activation key is a symmetric key. Optionally, all keys are symmetric keys. The invention is particularly advantageous for symmetric keys, since the replacement of symmetric keys requires a secure method to prevent the keys from being compromised.

Drawings

The meter communication infrastructure and method for replacing keys according to the present invention will now be described in more detail with respect to the accompanying drawings. The drawings illustrate one way of implementing the invention and should not be construed as limited to other possible embodiments falling within the scope of the appended claims.

Figure 1 is a schematic diagram of a meter communication infrastructure,

FIG. 2 illustrates key derivation, an

Fig. 3 illustrates how a new key-derived key is propagated between the server-side and the field-side locations.

Detailed Description

Referring to fig. 1, a meter communication infrastructure MCI is illustrated. Users 102 (such as private, residential, commercial, and industrial users) receive electricity or another utility, such as water, district heating, or gas, from a utility provider 101 via a utility distribution network 105. Depending on the utility, especially in the case of electricity, the user may also generate the utility itself or receive the utility from a production facility located below. The utilities transceived by each user are measured by a utility meter 103 located at the Field Side (FS) of the meter communication infrastructure MCI. The utility meter 103 may be an electricity, water, heat or cold meter, gas meter, heat cost distribution meter, or any other form of utility or consumption meter.

Meter data from each of the utility meters 103 is collected via a meter communication infrastructure MCI, which further comprises a centrally located data collector 104 and a front-end system HES located at a Server Side (SS) of the meter communication infrastructure MCI.

The meter communication infrastructure MCI comprises all elements, devices and equipment comprised in measuring consumption, reading and transmitting metering data and storing, processing, presenting and deriving metering data. The meter communication infrastructure MCI is logically divided into a field side FS and a server side SS.

The site end FS includes one or more of the following: utility meters, sensors, actuators (such as circuit breakers or valves). All these elements can be installed at the customer or in the utility distribution network, both belonging to the site end FS. Devices such as collectors, routers, repeaters, gateways, and base stations may also be considered field-side elements.

The server-side SS may include multiple servers, computers, and cloud solutions, which may be located in different geographic locations and run multiple server-side applications, such as front-end systems, meter management systems, key management systems, and the like.

The meter communication infrastructure MCI may at least partly comprise a public cellular network based on GSM, LTE or other cellular network technologies, including 3G, 4G or 5G cellular telecommunications. Such a cellular network may be part of a communication link between the field side and the server side SS. The utility meter may communicate directly with the public cellular network, thereby eliminating the need for a collector therebetween. The collector or gateway may be connected to the public cellular network and provide an auxiliary communication link between the collector and the utility meter. Other technologies, such as Sigfox, LORA, NB-IOT, or other internet of things infrastructure may be part of the communication link between the meter/field side FS and the server side SS. The meter communication infrastructure creates a communication link between the meter/field side FS and the server side SS that is not limited to one technology and may include a mix of different technologies linked together to establish an end-to-end communication link.

The communication between the field side FS and the server side SS is protected by cryptographic methods, which have one or more of the following effects: fraud, eavesdropping and unauthorized access to data and functions in the utility meter or other elements of the meter communication infrastructure MCI are prevented. Cryptographic methods rely on the fact that the entities involved in the communication have access to the required keys. Cryptographic methods have the above-described effect only if the keys used to protect the communication are not compromised (i.e., unauthorized persons do not have access to these keys). If the key is compromised, it must be replaced in a secure manner. In the following, a method for secure replacement of a compromised key in a utility meter and a meter, system and command data message arranging functions according to the method are disclosed.

In the following description, when data is transmitted from the utility meter and received in the head-end system HES (i.e. from the field end to the server end), this is to be understood as a direct transmission between the two sides or a transmission comprising intermediate devices such as routers, repeaters, collectors, base stations, WIFI routers, cellular network base stations, etc. In some communication steps between the field side and the server side, an additional security layer, such as a secure Transport Layer (TLS), may be used. This additional layer of security is not considered in this specification, but only end-to-end encryption between the site end and the server end (i.e., between the utility meter and the head-end system). The meter communication infrastructure should be understood as a two-way communication infrastructure. When indicating a communication direction, e.g. from the utility meter to the head-end system HES, this should be understood as an example only, the communication direction may also be reversed.

The meter data is encrypted in the field-side utility meter and transmitted via a concentrator or other intermediate device to the head-end system of the server-side SS without being decrypted before being received in the head-end system HES, which is called end-to-end encryption. Encryption and decryption in the utility meter and the headend system, respectively, is accomplished using symmetric keys. As contemplated by those skilled in the art, the data message may also be transmitted in the opposite direction from the head-end system to the utility meter. Such data transmission may be used to transmit any kind of data from the head-end system HES to the utility meter. An example of data transmitted from the head-end system to the utility meter is a command arranged to: controlling operation of the utility meter; changing a configuration parameter of the utility meter; changing the key; provide firmware updates, etc. Data encryption at least ensures confidentiality/privacy of the data, but may also have other purposes, such as playback protection. Further, a particular application or access right may be associated with a key for data encryption. In this way, commands can only be executed after encryption using a particular key or read/write access to different registers and memory areas can be protected by different keys.

Whether data is transmitted to or from a utility meter, it is important that the communication link be secure to prevent manipulation of the transmitted data and unauthorized access or operation of the utility meter. This may be done by data encryption alone or a Message Authentication Code (MAC) may be included in the data message. A suitable cryptographic function, such as C-MAC, CBC-MAC, HMAC or any other MAC function, may be used to calculate the message authentication code based on the data to be transmitted and other data. The MAC has the purpose of ensuring the authenticity of the data and/or the authentication of the transmitting entity. The MAC may also be used for authorization purposes. The MAC is also referred to hereinafter simply as an Authentication Code (AC) and may have one or more of the above-described functions. In the following description, the terms "message authentication code MAC" and "authentication code AC" are used interchangeably.

In the following, when securing a communication by using a key, it is to be understood that the key is used for one or more of the above purposes: ensuring confidentiality/privacy, replay protection, authenticity of data, authentication/authorization of entities participating in the communication. This may include encrypting data by using the key and/or authenticating or authorizing the data or the transmitting entity by a Message Authentication Code (MAC) calculated based on the key.

The keys used are 128 or 256 bit symmetric keys, which are common key lengths used, for example, with the advanced encryption standard (AES128/AES 256). The length of the key may be any suitable length that provides a desired level of security for the application. The length of the key is therefore not critical to the invention and may be any length suitable for the encryption algorithm used. The key length may affect the crypto period, i.e., the period over which the key can be used without replacing the key and still provide the desired level of security. The key may provide a crypto period that exceeds the useful life of the utility meter if operating according to normal usage.

The cryptographic method used is based on the advanced encryption standard (AES128/AES256), but any other symmetric encryption algorithm may be used, such as DES, triple DES. If the cryptographic method used is block cipher, an operation mode such as Cipher Block Chaining (CBC), Counter Mode (CM), or other modes may be used. The cryptographic method and the selection of the operation mode are well known to the person skilled in the art and are not further disclosed. For reference on how to use cryptographic methods and modes of operation, please refer to: NIST publication FIPS 197, 11 months and 26 days 2001; NIST special publication SP 800-67rev.2, 11 months 2017; NIST FIPS PUB 46-3; NIST SP 800-38A, 12 months 2001; NIST SP 800-38B, 2016, 6/10; and NIST SP 800-38C, 12 months and 5 days 2004.

Referring to fig. 2, the use of different keys is described. General operational communication between the head-end system HES and the utility meter 103 is protected using the application key APP. Different application keys APP may provide access to different functions and/or data in the utility meter and different ways of communicating with the meter. For example, one application key may be used to read meter data locally, while another application key may be used to read meter data remotely. Another application key may be used to change settings in the meter or update the meter firmware. Yet another application key may be reserved for data encryption of general or specific types of data. In this way, any particular utility meter data or function can be protected by a particular application key.

As shown in fig. 2, the application key APP for the different applications is derived from a key derivation key KDK. The application key is derived from the key derivation key KDK by using a key derivation function KDF, which takes as input the key derivation key and at least one additional parameter PAR identifying the application. Referring to fig. 2, if the first parameter PAR (1) is input to the key derivation function KDK, the first application key APP (1) is output from the key derivation function. If the second parameter PAR (2) is input to the key derivation function, the second application key APP (2) is output from the key derivation function. Preferably, both the first application key APP (1) and the second application key APP (2) and the key derivation key KDK are irrelevant, i.e. one key does not contain information about the other key. To ensure this, a suitable key derivation function must be used. Such a key derivation function KDF may be the HKDF described in IETF RFC5869 (ISSN: 2070-. Other suitable key derivation functions may be used.

When a key is derived based on or based on a specific key, it is to be understood that the key is derived using a key derivation function KDF, to which the specific key and optionally key generation information (such as the parameter PAR) and/or optionally version information related to the key are input and from which the key is then output.

The application key APP is derived independently at the utility meter/site end and at the head-end system/server end using a key derivation function KDF based on at least the key derivation key KDK and the additional parameter PAR. This has the effect that the application key APP does not need to be distributed to the server side SS or the meter/site side FS, thereby reducing the risk of revealing the key.

Since the key derivation key KDK in the utility meter and the head-end system is the same and the same key derivation function is used at the server side and the field side, only the parameter PAR needs to be exchanged to generate the same application key APP or other key in the meter and the head-end system HES. Even if both the key derivation function and the parameter PAR are known, it is not possible to derive the application key APP if the key derivation key KDK is not known. This has the effect that the parameter PAR can be transmitted in clear text between the site end and the server end.

According to best practice, key cleaning should be done periodically as a precaution. During key cleaning, the application key is automatically replaced by a new application key derived from the key derivation key KDK, which is not changed. The utility meter and the front-end system may be configured to automatically replace the application key at certain intervals. To support this, it is beneficial if all keys have versions or generations. The version or generation information may be included in the parameter PAR used for key derivation.

The application key APP is generated independently in the utility meter and head-end system based on a key derivation key KDK, which in turn is generated based on a disaster recovery key DRK. The disaster recovery key DRK is a special key that is only used when the key derivation key KDK is compromised or otherwise needs to be replaced. The purpose of the disaster recovery key DRK is to provide a secure way to replace the key derivation key KDK in the meter communication infrastructure MCI.

The disaster recovery key DRK is never used directly for data encryption or for generating message authentication codes. The disaster recovery key DRK is only used to derive the key derivation key KDK. The key derivation key KDK is never used directly for data encryption or for generating a message authentication code. Key derivation keys are only used to derive other keys.

With reference to fig. 3, disaster recovery based on the disaster recovery key DRK is described in detail. Disaster recovery includes a secure method for replacing an existing key-derivation key KDK with a new key-derivation key at the server side SS as well as at the site side FS (i.e., in the front-end system and in the utility meter as well as in any other components at the server side and the site side). Disaster recovery provides a means to safely replace keys in a utility meter through the meter communication infrastructure, even if an existing key derivation key KDK has been compromised. Disaster recovery as described below includes a method for replacing an existing key-derived key, a utility meter arranged for disaster recovery, a command data message for requesting replacement of the key-derived key in the utility meter or component of the side, and a meter communication infrastructure arranged for disaster recovery.

The disaster recovery key DRK for a given utility meter is generated during manufacture and stored in memory of the utility meter 102. A copy of the disaster recovery key is also transmitted to the secure environment SE of the server side SS. The secure environment SE may be protected by or may be a hardware security module. Furthermore, the secure environment may be an offline facility, i.e. the secure environment may not be connected to the internet or any external communication network. The secure environment SE is part of the server side SS but may be physically located at a separate location or at a different location than the other parts of the server side, such as the head-end system HES. Thus, the same disaster recovery key DRK is stored at the meter/field side FS and the server side SS.

During manufacture, configuration, customization or installation of the utility meter 102, a key derivation function KDF is also used to derive a key derivation key KDK from the disaster recovery key DRK, to which the disaster recovery key DRK and key-generation information (key-generation information) KGI are input. The key-derived key is then transmitted to the head-end system, or to a key management system KMS, from which the key-derived key can be transmitted to the head-end system. The key derivation key KDK is also provided to the utility meter 102 during manufacture or installation by communicating the key derivation key KDK to the utility meter or by instructing the utility meter to itself derive the key derivation key KDK from the disaster recovery key DRK and the same key generation information KGI. In different embodiments, the various keys may be generated at different times and at different locations. The key part is that the disaster recovery key DRK is only stored in the utility meter 102 and the secure environment SE, and that the disaster recovery key is not used directly for encryption, decryption or authentication, but only for the derivation of the new key derivation key. The disaster recovery key DRK is preferably not stored in the head-end system HES. Alternatively, the secure environment may be integrated in the front-end system. The transfer of the keys KDK, DRK to the utility meter during production is considered safe only if the production facility is a secure environment.

In the utility meter and the front-end system or key management system, the application key APP is derived independently from the key derivation key KDK. In one embodiment, the application key may be derived for the first time in the utility meter and the head-end system HES or the key management system KMS when the application key is needed. When someone attempts to access or interact with a utility meter, the key needs to be applied in the meter. In the headend system, a key is required when the headend system must communicate with a utility meter to receive or transmit data. It will be appreciated by those skilled in the art that the key hierarchy may be extended with additional levels, i.e. the key may be derived from the application key APP, which will add one level to the key hierarchy.

The head-end system HES and the key management system KMS are computer implemented systems running on a computer or server for performing various tasks and storing information. The main function of the front-end system is to control, coordinate and enable communication with the utility meters comprised in the meter communication infrastructure MCI, which may also include collecting consumption data from the utility meters. The front-end system may include multiple subsystems running on different computers or servers. Such subsystems may provide different user interfaces and application program interfaces for various system integrations. The key management system KMS has the main function of managing key derivation keys, and the derivation of application keys. The functions of the key management system may be integrated in the head-end system. Alternatively, the key management system may operate as a stand-alone system in communication with the head-end system. The key management system may serve one or more head-end systems.

How to replace the existing key derivation key KDK1 with the new key derivation key KDK2 is described in detail below. The new key derivation key KDK2 is the same in both the server side SS and the field side FS/meter. The existing key derivation key KDK1 in the site-side FS/meter may be the same as or different from the existing key derivation key KDK1 of the server-side SS. The replacement of the key-derived key has the effect that the key-derived key KDK in the field-side FS/meter and the server-side SS becomes the same and the process is secure and reliable, regardless of whether the existing key-derived keys KDK1 on the server-side and the field-side are the same.

If the existing key derivation key KDK1 used by the utility meter or the front-end system is compromised, the key derivation key and all application keys APP derived from it should be replaced. Since the key derivation key can be used to derive a new application key, it is not sufficient to simply change to the new application key (i.e., derive the new application key from the compromised existing key derivation key KDK 1). Instead, a new key derivation key KDK2 must be derived for the utility meter and implemented in the utility meter and head-end system or key management system. The process of implementing one or more new key derivation keys KDK2 may also be referred to as a disaster recovery process.

Fig. 3 illustrates a simplified meter communication infrastructure MCI, with a server side SS separated from a site side FS by a dashed line. Communication between the server side and the field side is provided by any suitable communication link as described above.

The disaster recovery process must be repeated each time the key derivation key is compromised or deemed to be at risk of being compromised. The process is repeated for each utility meter having a compromised key derivation key. The utility meter and/or the front end system and/or the key management system track how many times a key derivation key has been replaced for a given meter and store version information relating to the key derivation key in use. When a given version of the key-derivation key KDKx has been compromised and disaster recovery has been initiated, the server-side front-end system obtains version information relating to the compromised key-derivation key. The version information may be stored in the head-end system, the key management system, or any other system. If the version information is not available, it can be obtained from the utility meter in an alternative, secure manner.

Based on at least the version information, key generation information KGI is generated at the server side SS. If version information is not available, a jump may be made in the version number to ensure that new key generation information is generated. Alternatively, the key generation information KGI may be generated based on other information (such as a random or pseudo-random number) or based on date information. The key generation information is preferably not reused. The checking of unreused key generation information may be included at the server side and at the field side, such as in the secure environment and the utility meter, respectively. If the key generation information is based on time/date information, it may be required that the information is accepted as valid key generation information KGI within a certain actual date and time range.

Based on the key generation information KGI, a new key derivation key KDK2 is derived on the server side using the disaster recovery key DRK and the key derivation function KDF stored in the secure environment SE. The new key derivation key KDK2 is preferably derived in the secure environment SE and then transferred to a new instance of a trusted and clean environment, such as a head-end system or key management system, to ensure that the new key derivation key KDK2 is not compromised. Alternatively, the derivation of the new key derivation key may be performed in a key management system or a head-end system.

To request replacement of an existing key derivation key KDK1 with a new key derivation key KDK2 in the utility meter, a command data message CDM is sent from the server-side/front-end system to the utility meter.

Since the key used to protect the communication between the front-end system and the utility meter is derived from the existing key derivation key KDK1, which may be compromised, the communication link between the server side and the field side may be insecure. Thus, the new key derivation key KDK2 cannot be transmitted to the utility meter itself. To overcome this problem, the head-end system HES transmits a command data message CDM to the utility meter 102 requesting the utility meter to also derive a new key derivation key KDK2 identical to the new key derivation key KDK2 derived at the server side for the utility meter. In general, it is not desirable to transfer any key derivation key KDK or application key APP from the server side to the site side, since there is a risk of revealing the transferred key.

However, there is a real need to protect the command data message CDM to ensure one or more of authenticity of the command data message, authorization and/or authentication of the head-end system. This is needed to ensure that only authorized entities (front-end systems) can initiate the generation of a new key derivation key KDK2 and the replacement of an existing key generation key KDK1 in the utility meter. In particular, the existing key derivation key KDK1 (which may have been compromised) cannot be used to protect the command data message CDM. To overcome this problem, the command data message CDM is protected by using an activation key AK derived from a new key derivation key KDK 2. The activation key is derived using a key derivation function and optionally key generation information or parameters. The command data message CDM may be protected by one or more MAC codes or hash values calculated on the basis of the activation key AK, thereby proving that the sender (front-end system or server-side) possesses the new key-derivation key KDK2 and is authorized to request replacement of the key-derivation key. As an alternative, the activation key AK may be included in the command data message CDM and itself provides proof of possession of the new key derivation key KDK2, in such a way that the activation key becomes a MAC code. In the latter case, the activation key is preferably not used for further security measures.

The command data message CDM for requesting replacement of an existing key derivation key KDK1 with a new key derivation key KDK2 comprises key generation information KGI and an authentication code CDM-AC (or alternatively an activation key AK). The request for replacing the key may be explicit or implicit, e.g. simply an identifier of the command data message CDM or a parameter in the command data message may be interpreted as the request. These data need not be kept secret and can be sent as clear text. The command data message may or may not be encrypted. The key generation information KGI comprised in the command data message CDM is the same key generation information used at the server side SS to derive the new key derivation key KDK2, or at least the same information can be derived from the command data message. As described above, the authentication code CDM-AC is calculated based on the activation key AK, which is derived based on the new key derivation key KDK 2. The authentication code CDM-AC, or alternatively the activation key AK, is used to verify one or more of the authenticity of the command data message CDM, the authorization/authentication of the head-end system HES or the server-side SS. In other words, the authentication code CDM-AC, or alternatively the activation key AK, provides proof that the entity generating the command data message CDM possesses the new key derivation key KDK 2. The authentication code CDM-AC may comprise one or more authentication codes for providing the different security aspects described above. The command data message is indirectly protected based on the disaster recovery key DRK because the authentication code is calculated based on the activation key AK, which is derived based on the new key derivation key KDK2, and the new key derivation key KDK2 is derived based on at least the key generation information. This means that only the entity or set of entities having access to the disaster recovery key can derive the new key derivation key KDK2 and generate a command data message with the correct authentication code CDM-AC requesting that the existing key generation key KDK1 be replaced with the new key generation key KDK 2. Any entity having access to a particular new key derivation key KDK2 and key generation information may generate a command data message CDM requesting replacement of an existing key derivation key KDK1 with the particular new key derivation key KDK 2.

The utility meter is arranged to update the existing key derivation key KDK1 to a new key derivation key KDK2, in which regard the following steps are performed after receiving a command data message CDM requesting to replace the existing key derivation key KDK1 from the head-end system HES over the meter communication infrastructure MCI:

-deriving a new key derivation key KDK2 by inputting at least the disaster recovery key DRK stored in the utility meter and the key generation information KGI comprised in the received command data message CDM to the key derivation function KDF of the meter. The new key derivation key KDK2 derived in the utility meter is the same as the new key derivation key KDK2 derived at the server side because the key derivation function KDF used in the utility meter and at the server side is the same and because the parameters (i.e. the key generation information KGI and the disaster recovery key DRK) input to the key derivation function are the same. Since the command data message has not yet been authenticated, the existing key derivation key KDK1 cannot be replaced with the new key derivation key KDK2 before authentication is performed.

Deriving the activation key AK in the meter from the new key derivation key KDK 2. The activation key can only be correctly derived if the new key derivation key KDK2 has been correctly derived. The activation key AK derived in the utility meter is the same as the activation key AK derived at the server side and included in the command data message or used to calculate the authentication code CDM-AC of the command data message at the server side.

-recalculating, by the utility meter, the authentication code CDM-AC of the received command data message CDM based on the activation key AK derived by the utility meter. If the recalculated authentication code CDM-AC matches the received authentication code, the command data message has been verified/acknowledged. Alternatively, if the command data message CDM comprises an activation key AK and the received activation key AK matches the derived activation key AK', the command data message has been verified/acknowledged.

-replacing the existing key derivation key KDK1 with the new key derivation key KDK2 if the recalculated authentication code matches the authentication code, or alternatively the derived activation key AK' matches the activation key received in the command data message CDM, i.e. the command data message has been verified. If the command data message is not verified by the utility meter as correct, the existing key derivation key KDK1 is not replaced with the new key derivation key KDK2 and the utility meter will continue to use the existing key derivation key KDK1 to derive the application key.

The utility meter may optionally automatically recalculate one or more application keys APP in the utility meter if the existing key derivation key KDK1 is replaced with the new key derivation key KDK 2.

The utility meter may optionally be arranged to respond to the command data message CDM. The response may include information such as: data indicating whether the existing key derivation key KDK1 is replaced with the new key derivation key KDK 2; key generation information KGI related to the existing key derivation key or the new key derivation key; one or more authentication codes or any other relevant data.

In combination with the above elements, a meter communication infrastructure MCI, such as a meter reading system, may be provided for replacing the existing key derivation key KDK 1. The meter communication infrastructure includes: a server side SS, which comprises a front-end system HES and a security environment SE; and a field side FS that includes a plurality of utility meters 102. The site-side FS and the server-side SS are arranged to communicate with each other via the meter communication infrastructure MCI. Meter reading data, sensor data, monitoring data, command data messages, configuration data, firmware updates, etc. may be transmitted over the meter communication infrastructure. The server-side SS front-end system HES is configured for secure communication with the field-side utility meter using application keys APK, which are derived at the server-side and field-side using key-derivation keys KDK. The server side SS, the secure environment SE is arranged for storing a disaster recovery key DRK. Since the server side is typically accessible via the internet and the disaster recovery keys of all meters are stored on the server side, the server side security environment SE preferably comprises a hardware security module. The server-side secure environment SE may be an offline environment not connected to the internet. When a disaster recovery procedure is initiated in the meter communication infrastructure MCI, the server side is configured to derive a new key derivation key KDK2 based on the disaster recovery key DRK stored in the secure environment and based on the key generation information. The new key derivation key KDK2 may be derived in any part of the server side, but is preferably derived in the secure environment SE. The key generation information is preferably stored on the server side, but may be obtained from other sources. Further, as described above, the server side will transmit the command data message CDM over the meter communication infrastructure MCI to one or more of the utility meters. The field side utility meter is configured for receiving a command data message CDM from the server side. The utility meter will execute the command data message by using the disaster recovery key DRK stored in the utility meter and deriving a new key derivation key KDK2 that is identical to the server-side derived new key derivation key KDK2 based on the key generation information received in the command data message. Further, the utility meter will validate the command data message as described above and, if validated, replace the existing key derivation key KDK1 with the new key derivation key KDK 2.

The disaster recovery key may be generated using a standard Windows FIPS 140-21 level authentication random function. More specifically, the Microsoft system security cryptography aes library may be used to generate the disaster recovery key. In one embodiment, the key/disaster recovery key may have an effective entropy amount of app.115 bits at a significance level of 1%.

The key derivation function KDF used to derive the key derivation key KDK from the disaster recovery key may be HKDF described in IETF RFC5869 (ISSN: 2070-. This same key derivation function and technique may be used to derive the application key APP from the key derivation key KDK.

The meter communication infrastructure MCI is to be understood as an entire system comprising HW and SW elements from a meter on the field side FS to a plurality of physical or virtual servers on the server side SS. As mentioned in the introduction, the meter communication infrastructure MCI may also comprise a data relay (not shown) for retransmitting or relaying data. The utility meter itself may also act as a repeater or router to create a mesh network as part of the meter communication infrastructure. A cellular network or other third party network for communication between the server side SS and the field side FS is considered part of the meter communication infrastructure. Data can be transmitted one-way and two-way between the utility meter and the head-end system. In addition, data may be transmitted via a wired or wireless connection.

The invention may be implemented in hardware, software, firmware or any combination of these. The invention or some of its features may also be implemented as software running on one or more data processors and/or digital signal processors. The various elements of an embodiment of the invention may be physically, functionally and logically implemented in any suitable way, such as in a single unit, in multiple units or as part of separate functional units. The invention may be implemented in a single unit or may be physically and functionally distributed between different units and processors.

Although the invention has been described in connection with specific embodiments, it should not be construed as being limited in any way to the examples given. The scope of the invention should be construed in accordance with the attached claims. In the context of the claims, the term "comprising" or "comprises" does not exclude other possible elements or steps. Furthermore, references to "a" or "an" etc. should not be construed as excluding a plurality. The use of reference signs in the claims with respect to elements indicated in the figures shall not be construed as limiting the scope of the invention either. Furthermore, individual features mentioned in different claims may advantageously be combined, and the mentioning of these features in different claims does not exclude that: combinations of features are not possible and advantageous.