SECURE CONTROL METHOD AND SYSTEM FOR A SMART METER

Abstract

A management device in an automated system remotely managing smart meters transmits a secure command by: performing a security operation (502) that generates a signature on a data set consisting of attributes to be applied as input to an operation to be performed and metadata associated with the command, and transmitting (504) to the smart meter in question the command with a descriptor of the operation to be performed, the attributes to be applied as input to the operation to be performed, the associated metadata, and the first generated signature. The management device includes (501) in the metadata a copy of the descriptor of the operation to be performed, so that the signature also applies to the copy of the descriptor of the operation to be performed in order to allow verification upon receipt that the command has not been altered. Figure to be published with the abbreviation: Fig. 5

Description

Title of the invention: METHOD AND SYSTEM FOR SECURE CONTROL OF A SMART METER technical field

[0001] At least one embodiment relates to a method and a secure control system for a smart meter. The system in question is adapted to allow a management device to ensure that commands transmitted to a smart meter are not manipulated en route and that operations performed by the smart meter actually correspond to the transmitted commands. PRIOR TECHNOLOGY

[0002] It is known that smart meters, such as electricity meters (electricity consumption meters) or fluid meters (fluid consumption meters), include communication interfaces that allow an automated management system to remotely collect consumption data. For example, smart electricity meters include a Power Line Communication (PLC) communication interface. Data can thus be exchanged between the smart meters and an Information System (IS) that manages them centrally.This allows the IS information system to send commands to the smart meters to perform various operations, such as transmitting meter readings, changing operational parameters (e.g., changing the low threshold for energy overconsumption or changing the calendar profile), updating software, clearing event logs, enabling / disabling features (e.g., power cut), etc.

[0003] Some of these operations are considered "critical" because they can have serious and irreversible consequences if triggered incorrectly. Data corruption could occur during the transmission of commands from the IS information system to the smart meters, either through interference or malicious action.

[0004] In order to guard against alteration of command attributes, the COSEM specifications ("Companion Specification for Energy Metering") require that certain commands be accepted only if they use a COSEM data protection object (an object called "DATA PROTECTION"). (as, for example, described in the "Bluebook DLMS" V16, Part 2, §4.4.9), which affix a signature (asymmetric encryption) to attributes and associated metadata (transaction number, order date, cryptographic identity of the signer, cryptographic identity of the recipient). As a reminder, the COSEM specifications define an object-based model for formalizing instructions (commands) and, more generally, data exchanges. These objects can be combined to perform a wide range of operations, from simple ones, such as register reads, to more complex ones, such as load management operations. The COSEM specifications are generic enough to allow for modeling various use cases beyond energy management (water distribution management, for example).

[0005] The protection of attributes and associated metadata, notably enabled by the COSEM specifications through the "DATA PROTECTION" object type, is an important tool for securing command transmissions in an automated (remote) smart meter management system. This prevents operations with altered attributes from being inadvertently performed.

[0006] However, securing command transmission by protecting attributes is an imperfect solution. Indeed, various commands may use identical or compatible attributes. And the attribute protection offered by the "DATA PROTECTION" type object is ineffective against an alteration of the command itself (referred to as the "invoked method" in the COSEM specification terminology), typically an alteration of the command identifier.

[0007] For example, consider that the `remote_connect()` method of a `DISCONNECTOR` class object is invoked using a `DATA PROTECTION` type object to command a power-on. Only the parameter (attribute) of this method (an integer with the value `0`) is protected by the `DATA PROTECTION` type object. If a path alteration changes the identifier of the invoked method to `remote_disconnect()`, a completely reverse power-off operation is performed.

[0008] It is therefore desirable to provide a solution that strengthens the security of commands transmitted remotely from a management device to smart meters in an automated management system, so as to ensure that the smart meter performs the operation that was actually intended. Description of the invention

[0009] To this end, he proposed a method for transmitting a secure command in an automated smart meter management system, the command comprising a descriptor of an operation to be performed by said smart meter and attributes As input to the operation to be performed and the metadata associated with the order, the process includes the following steps executed by a management device of the automated management system remotely managing the smart meters:

[0010] - to perform a security operation that generates an initial signature on a set of data formed by the input attributes of the operation to be performed and the metadata associated with the command;

[0011] - transmit the command with the descriptor of the operation to be performed, the input attributes of the operation to be performed, the metadata associated with the command and the first generated signature;

[0012] - include in the metadata associated with the order a copy of the descriptor of the operation to be carried out, so that the first signature also applies to the copy of the descriptor of the operation to be carried out in order to allow verification upon receipt that the order has not been altered during transmission.

[0013] Thus, the security of commands transmitted remotely from a management device to smart meters within an automated management system is enhanced by the clever copying of the operation descriptor to be performed into metadata protected by a signature. This makes it possible to verify upon receipt that the operation to be performed is indeed the one initially intended (when, upon receipt, the copy is valid and the signature is valid).

[0014] In a particular embodiment, the operation descriptor to be performed and its copy contain an identifier of the operation to be performed.

[0015] Thus, although a simple identifier of the operation to be performed could easily be altered in such a way as to lead to the performance of an operation other than the one initially desired, the clever copying of the descriptor of the operation to be performed within metadata which benefits from signature protection is sufficient to ensure that the operation to be performed is indeed the one initially desired.

[0016] In a particular embodiment, the automated management of smart meters is operated according to an object-oriented model, the operation descriptor to be performed and its copy contain a class identifier of at least one object manipulated to perform the operation in question.

[0017] Thus, although a simple identifier of object classes manipulated to carry out the desired operation could easily be altered in a way that could lead to carrying out an operation other than the one initially desired, the clever copying of the descriptor of the operation to be carried out within metadata that benefits from signature protection is sufficient to ensure that the operation to be carried out is indeed the one initially desired.

[0018] In a particular embodiment, the object-oriented modeling is of the COSEM type and the security that generates the first signature is obtained by an object of the DATA PROTECTION type.

[0019] Thus, the clever copying of the descriptor of the operation to be carried out makes it possible to ensure the desired security, whereas the COSEM object of type DATA PROTECTION is not designed to protect the identification of the operation to be carried out but only its attributes and associated metadata.

[0020] In a particular embodiment, the method further comprises the following steps, upon receipt of the command, of verification of the command executed by the smart meter in question to which said command was transmitted:

[0021] - retrieve, from the received command, the descriptor of the operation to be performed;

[0022] - retrieve, from the received command, the input attributes to be applied to the input of the operation to be performed, as well as the metadata associated with the command;

[0023] - verify that the copy of the descriptor of the operation to be performed is in the metadata retrieved conforms to the descriptor of the operation to be performed retrieved, and when this is not the case, reject the command;

[0024] - retrieve, in the received order, and verify that the first signature in the command conforms with the input attributes to be applied as input to the operation to be performed and to said metadata including the copy of the descriptor of the operation to be performed, which were retrieved in the command, and when this is not the case, reject the command, and otherwise, accept the command.

[0025] Thus, the smart meter in question, to which the said command was transmitted, is assured that the command has not been altered during transmission.

[0026] In a particular embodiment, the order verification is also performed by a data concentrator acting as a relay between the management device and the smart meter in question in the automated management system.

[0027] Thus, it is verified that the command has not been altered from the management device to the data concentrator, and if this has been the case, this verification avoids unnecessarily stressing the smart meter (and network resources between the data concentrator and the smart meter in question).

[0028] In a particular embodiment, the method further comprises the following steps, after completion of the commanded operation, executed by the smart meter in question to provide a response to the command:

[0029] - retrieve output attributes, and metadata associated with the response, to provide the managing device with the results of the order execution;

[0030] - include, in the metadata associated with the response, the operation descriptor to to carry out what had been provided in the order;

[0031] - to perform a security measure that generates a second signature on a set of data formed by the output attributes and metadata associated with the response;

[0032] - transmit to the managing device a response with the attributes of output, the said metadata including the operation descriptor to be performed which had been provided in the order, and the second generated signature.

[0033] Thus, security is also enhanced for the response to the command.

[0034] In a particular embodiment, the process further comprises the following steps, upon receipt of the response, for verifying the response, performed by the management device:

[0035] - retrieve, from the received response, the output attributes that result from the operation completed, as well as the metadata associated with the response;

[0036] - retrieve from memory the descriptor of the operation to be performed which had initially transmitted in the command to which the response is supposed to correspond;

[0037] - verify that the metadata retrieved in the response corresponds to the operation descriptor to be performed, and when this is not the case, reject the response;

[0038] - retrieve, from the received response, and verify that the second signature is compliant with the output attributes and metadata associated with the response, which were retrieved from the response, and when this is not the case, reject the response, and otherwise, accept the response.

[0039] Thus, the management device is assured that the response to its command has not been altered during transmission, and is particularly assured that the response in question corresponds to its initial command.

[0040] In a particular embodiment, the verification of the response is also performed by a data concentrator acting as a relay between the management device and the smart meter in question in the automated management system.

[0041] Thus, it is verified that the command has not been altered from the smart meter to the data concentrator, and if this has been the case, this verification avoids unnecessarily stressing the management device (and network resources between the data concentrator and the management device).

[0042] Also proposed here is a management device comprising electronic circuitry configured to perform a secure command transmission in an automated smart meter management system where the management device is configured to remotely manage the smart meters, the command comprising a descriptor of an operation to be performed by said smart meter and input attributes of the operation to be performed and metadata associated with the command, the electronic circuitry being configured to execute the following steps:

[0043] - to perform a security operation that generates an initial signature on a set of data formed by the input attributes of the operation to be performed and the metadata associated with the command;

[0044] - transmit the command with the descriptor of the operation to be performed, the input attributes of the operation to be performed, the metadata associated with the command and the first generated signature;

[0045] - include in the metadata associated with the order a copy of the descriptor of the operation to be carried out, so that the first signature also applies to the copy of the descriptor of the operation to be carried out in order to allow verification upon receipt that the order has not been altered during transmission.

[0046] Also proposed here is a smart meter configured to process a command received from a management device in an automated management system where the management device is configured to remotely manage the smart meter. The command comprises a descriptor of an operation to be performed by said smart meter, input attributes of the operation to be performed, and metadata associated with the command. The smart meter includes electronic circuitry configured to perform the following command verification steps upon receipt of the command:

[0047] - retrieve, from the received command, the descriptor of the operation to be performed;

[0048] - retrieve, from the received command, the input attributes to be applied to the input of the operation to be performed, as well as the metadata associated with the command;

[0049] - verify that the copy of the descriptor of the operation to be performed is in the metadata retrieved conforms to the descriptor of the operation to be performed retrieved, and when this is not the case, reject the command;

[0050] - retrieve, in the received order, and verify that the first signature in the command conforms with the input attributes to be applied as input to the operation to be performed and to said metadata including the copy of the descriptor of the operation to be performed, which were retrieved in the command, and when this is not the case, reject the command, and otherwise, accept the command.

[0051] Also proposed here is an automated smart meter management system comprising a management device as described above and smart meters as described above.

[0052] Also proposed here is a method implemented by a smart meter for processing a command received from a management device in an automated management system where the management device is configured to remotely manage the smart meter, the command comprising a descriptor of an operation to be performed by said smart meter and input attributes of the operation to be performed and of metadata associated with the order. The process includes the following steps, upon receipt of the order, for order verification:

[0053] - retrieve, from the received command, the descriptor of the operation to be performed;

[0054] - retrieve, from the received command, the input attributes to be applied to the input of the operation to be performed, as well as the metadata associated with the command;

[0055] - verify that the copy of the descriptor of the operation to be performed is in the metadata retrieved conforms to the descriptor of the operation to be performed retrieved, and when this is not the case, reject the command;

[0056] - retrieve, in the received order, and verify that the first signature in the command conforms with the input attributes to be applied as input to the operation to be performed, and with said metadata including the copy of the descriptor of the operation to be performed, which were retrieved in the command, and when this is not the case, reject the command, and otherwise, accept the command.

[0057] Also proposed here is a computer program product comprising instructions leading to the implementation by a processor of one or the other of the processes described above, in any of their embodiments, when the instructions are executed by the processor.

[0058] Also proposed here is an information storage medium storing instructions leading to the implementation by a processor of one or the other of the processes described above, in any of their embodiments, when the instructions are read from the information storage medium and executed by the processor. Brief description of the drawings

[0059] The features of the invention mentioned above, as well as others, will become clearer upon reading the following description of at least one exemplary embodiment, said description being made in relation to the accompanying drawings, among which:

[0060] [Fig-1] schematically illustrates an automated management system for meters intelligent;

[0061] [Fig.2] shows a logical representation of interactions between a management device and a smart meter of the automated management system;

[0062] [Fig.3] schematically illustrates an example of hardware architecture, which is adapted to implement a device of the automated management system;

[0063] [Fig.4] schematically illustrates a principle of signature generation and application;

[0064] [Fig.5] schematically illustrates a flowchart of a process for formatting and transmitting a command initiated by the management device and destined for the smart meter;

[0065] [Fig.6] schematically illustrates an organizational chart of a verification process for acceptance or rejection of a received order;

[0066] [Fig.7] schematically illustrates a flowchart of a formatting process and the transmission of a response to a command initiated by the management device to the smart meter, in a specific embodiment; and

[0067] [Fig.8] schematically illustrates a flowchart of a verification process for acceptance or rejection of the response formatted in accordance with [Fig.7].

[0068] DETAILED DESCRIPTION OF IMPROVEMENTS

[0069] Figure 1 schematically illustrates an automated management system 100 in which the present invention can be implemented. The automated management system 100 is configured to perform remote management of smart meters 151, 152, 153 (e.g., electricity, water, gas, heat, other fluids).

[0070] The remote management of the smart meters 151, 152, 153 is ensured by a management device 111 of an information system (IS) 110. In many solutions of such automated management systems, the management device 111 is a meter data management system (MDMS).

[0071] The information system 110 typically also includes a Key Management System (KMS), which is configured to store encryption keys required by the smart meters that depend on the information system IS 110 in question. The KMS is configured to provide the management device 111, such as the meter data management system MDMS, with the keys required for the encryption / decryption operations to be performed with respect to the smart meters 151, 152, and 153. Alternatively, the management device 111 has, by pre-configuration, the keys required for the encryption / decryption operations to be performed with respect to the smart meters 151, 152, and 153.

[0072] The management device 111 manages the smart meters 151, 52, 153 through a network infrastructure managed by a data concentrator (DC) 120. The DC data concentrator 120 manages a primary communication network NET1 101 through which communication with the smart meters 151, 152, 153 is established. The DC data concentrator 120 thus acts as a relay between the smart meters 151, 152, 153 and the IS information system 110 (including the management device 111).

[0073] As schematically illustrated in [Fig.1], the DC 120 data concentrator is external to the IS 110 information system and communicates with the IS information system, (including the management device 111) through a second NET2 102 communication network.

[0074] Typically, the IS 110 information system interacts with several DC 120 data concentrators through the second NET2 102 communication network, each of the DC 120 data concentrators managing communications with its own group of smart meters.

[0075] For example, the first NET1 101 communication network is a PLC (Power Line Communications) type network, such as that conforming to the G3-PLC or PRIME specifications. According to another example, the first NET1 101 communication network is a LPWAN (Low-Power Wide Area Network) type wireless network such as that found in the Internet of Things (IoT).

[0076] For example, the second NET2 102 communication network is a 5G (5th Generation) type wireless communication network. According to other examples, the NET2 102 communication network is a GPRS (General Packet Radio Service), UMTS (Universal Mobile Telecommunications System) or LTE (Long-Term Evolution) type wireless communication network.

[0077] Other technologies can be used to implement the first communication network NET1 101 and the second communication network NET2 102.

[0078] A logical representation of the interactions between the management device 111, such as the MDMS system, and a said smart meter 150 via the DC data concentrator 120, is shown in [Fig.2]. These three elements may be from different suppliers (manufacturers) and are typically located in different places.

[0079] An interface II is defined for exchanges between the management device 111 and the DC data concentrator 120, and an interface 12 is defined for the DC data concentrator 120 and the smart meter 150.

[0080] In a DLMS (“Device Language Message Specifications” in English) implementation, the management device 111 has a role of third-party device with respect to the DLMS client - DLMS server pair formed respectively by the DC 120 data concentrator and the smart meter 150.

[0081] Interface II then allows the third party to give commands to the DLMS client and retrieve the results. These commands are typically in a proprietary format (for example, based on XML (Extensible Markup Language), JSON (JavaScript Object Notation), or other) in a transport protocol secure application, type HTTPS (“Hypertext Transfer Protocol Secure” in English) but handles commands and business data in COSEM / A-XDR format (where A-XDR is an encoding format, referenced by the DLMS / COSEM specifications, and defined in the IEC 61334-6 standard).

[0082] Interface 12 enables the DLMS client to connect to the DLMS counter / server, send orders and retrieve results using the DLMS protocol to manage orders and business data in COSEM / A-XDR format.

[0083] The DLMS client performs transport format conversions between the first NET1 101 and second NET2 102 communication networks. In particular, a symmetric encryption security layer can be added for transmissions on the first NET1 101 communication network.

[0084] To ensure the integrity of commands from the management device 111 to the smart meter 150, a generation and affixing of signature is carried out as detailed below in relation to [Fig.4], for example by means of a COSEM object of type “DATA PROTECTION”.

[0085] Figure 3 schematically illustrates an example of a hardware architecture 300, which is suitable for implementing any device controller of the automated management system 100. The example hardware architecture is thus suitable for implementing a controller of the IS information system 110, or of any component of the IS information system 110. The example hardware architecture is also suitable for implementing a controller of the DC data concentrator 120. The example hardware architecture is also suitable for implementing a smart meter controller 150, 151, 152, 153.

[0086] The hardware architecture 300 then comprises, connected by a communication bus 310: a processor or CPU (Central Processing Unit) 301; a RAM (Random Access Memory) 302; a ROM (Read Only Memory) 303, or EEPROM (Electrically Erasable Programmable ROM), or a Flash memory; a DSM (Data Storage Medium) 304, such as a HDD (Hard Disk Drive), or a storage medium reader, such as an SD (Secure Digital) card reader; and at least one COM communication interface 305. Depending on the device considered, the hardware architecture 300 may further comprise I / O (Inputs / Outputs) 306, for example for carrying out consumption measurements (smart meters).

[0087] The processor 301 is capable of executing instructions loaded into RAM 302 from ROM 303, external memory (not shown), storage media such as an SD card, or a communication network. When When the hardware architecture 300 is powered on, the processor 301 is able to read instructions from RAM 302 and execute them. These instructions form a computer program, causing the processor 301 to implement the steps and algorithms described here in relation to the device in question.

[0088] All or part of the steps and algorithms described herein can thus be implemented in software form by executing a set of instructions by a programmable machine, such as a DSP (Digital Signal Processor) or a microcontroller, or be implemented in hardware form by a machine or component (chip) or a set of components (chipset), such as an FPGA (Field-Programmable Gate Array) or an ASIC (Application-Specific Integrated Circuit). Generally, each device of the automated management system 100 comprises electronic circuitry arranged and configured to implement the steps and algorithms described herein in relation to the device in question.

[0089] Figure 4 schematically illustrates a principle of order security by generation and affixing of signature.

[0090] As proposed by the COSEM specifications, a signature is affixed by asymmetric encryption using a private key on a data set consisting of the input attributes ATT_I to be taken as input to an operation to be performed, as well as MD_I metadata associated with the command.

[0091] Commands secured according to the security principle of [Fig.4] are commands which include ATT_I input attributes (e.g., commands of type "SET" to update data (register, table, parameter...) of the smart meter or "ACTION" to make the smart meter perform an action), therefore for which a security mechanism by signature can be applied jointly with metadata associated with the command.

[0092] In the COSEM specifications, this metadata consists of a transaction number (metadata "transaction-id"), the cryptographic identity of the signer (metadata "originator-system-title"), the order date (metadata "date-time"), and the cryptographic identity of the recipient (metadata "recipient-system-title"). Other metadata may be added (existing "other-information" metadata or in an "object-list" metadata field added for this purpose). Metadata is therefore data that is not necessary to perform the operation itself, since the data required to perform the operation is located elsewhere in the order, but which provides supplementary information.

[0093] The operation to be performed is presented in an OP_DESC descriptor (e.g., COSEM object(s)) which is not within the signature coverage area of ​​the command. It is proposed here to also include it in the MD_I metadata (more specifically in the existing "other-information" metadata or via the addition of a new "object-list" metadata field) a copy of this operation descriptor to be performed OP_DESC.

[0094] In a particular embodiment, the operation descriptor to be performed OP_DESC and its copy contain an identifier of the operation to be performed (for example, a method number).

[0095] In a particular embodiment where the automated management of smart meters is operated according to an object-oriented modeling (as in the COSEM specifications), the operation descriptor to be performed OP_DESC and its copy contain a class identifier of at least one object manipulated to perform the operation in question.

[0096] For example, if the operation to be performed is an activation of power supply for an electric smart meter, a suitable operation descriptor to be performed OP_DESC (and its corresponding copy) contains the OBIS code (“Object Identification System” in English) and a method number which correspond, in a predefined manner, to the “Disconnector.remote_connect()” method of the DLMS / COSEM specifications.

[0097] In a particular embodiment where the automated management of smart meters is operated according to an object-oriented modeling (as in the COSEM specifications), the operation descriptor to be performed OP_DESC is a list of COSEM objects representing the operation to be performed.

[0098] Thus, after generating a SIGN signature from the input attributes Att i of the operation to be performed and the MD_I metadata (including the copy of the operation descriptor OP_DESC), the SIGN signature is affixed along with the input attributes ATT_I of the operation to be performed and the MD_I metadata. It is then possible to verify upon receipt, using the public key corresponding to the private key used to generate the signature, that not only have the input attributes not been altered, but also, beyond the metadata other than that of the copy of the operation descriptor OP_DESC, that the requested operation is indeed the one initially required by the management device 111.

[0099] In particular, within the framework of the DLMS / COSEM specifications, the command security principle presented above is advantageously applied to the following operations (with their corresponding class numbers in the specifications):

[0100] - power activation (opening of “breaker”) via a class 70 object DISCONNECT CONTROL » ;

[0101] - configuration of a low threshold for overconsumption detection via a class object 71 “LIMIT”;

[0102] - downloading and activating application software via a class 18 object IMAGE TRANSFER » ;

[0103] - activation of a tariff schedule via a class 20 object "ACTIVITY CALENDAR » ;

[0104] - permanent deletion of event logs (potentially tracing security events) via a class 7 object “GENERIC PROFILE”.

[0105] As described later, this same principle is applicable to the response transmitted by the electric meter 150 in question with output attributes ATT_O and metadata MD_0 associated with the response.

[0106] Fig. 5 schematically illustrates a flowchart of a process for formatting and transmitting a command initiated by the management device 111 and destined for a said smart meter 150.

[0107] In step 501, the management device 111 prepares the command. The command corresponds to an operation to be performed by the smart meter 150 in question (target smart meter). The management device 111 generates an operation descriptor OP_DESC as mentioned above in relation to [Fig. 4].

[0108] The management device 111 prepares the input attributes ATT_I to be applied as input to the operation to be performed. For example, the operation to be performed is an update of a tariff schedule and the input attributes ATT_I include a new tariff schedule to be applied.

[0109] The management device 111 prepares the MD_I metadata associated with the command. The management device 111 includes, in the MD_I metadata, a copy of the operation descriptor to be performed OP_DESC.

[0110] In step 502, the management device 111 secures the input attributes Att i and the metadata MD_I (including the copy of the operation descriptor to be performed OP_DESC) by generating the signature as already described (asymmetric encryption with the private key of the management device 111). Within the framework of the COSEM specifications, this operation is performed using an object of type "DATA PROTECTION".

[0111] In step 503, the management device 111 affixes the generated signature to the command. The command therefore includes the descriptor of the operation to be performed, the ATT_I attributes, the MD_I metadata, and the generated signature, in order to allow verification upon reception that the command has not been altered during transmission.

[0112] In a step 504, the management device 111 transmits the thus secured command to the DC data concentrator 120 for relay to the smart meter 150 in question (target smart meter).

[0113] Preferably, the management device 111 keeps in memory the operation descriptor to be performed OP_DESC as sent, until a response from the smart meter 150 in question is received (or until an expiry time greater than a predefined duration threshold is reached).

[0114] Figure 6 schematically illustrates a flowchart of a verification process for accepting or rejecting a received order. The order was generated and transmitted according to the process described above in relation to Figure 5 to a said smart meter 150 (target smart meter).

[0115] In a step 601, the smart meter 150 in question receives the command.

[0116] In step 602, the smart meter 150 retrieves, from the received command, (which is supposed to be) the descriptor of the operation to be performed OP_DESC (outside of the MD_I metadata part of the command).

[0117] In a step 603, the smart meter 150 retrieves, from the received command, (what is assumed to be) the input attributes ATT_I to be applied as input to the operation to be performed, as well as (what is assumed to be) the metadata MD_I associated with the command.

[0118] In step 604, the smart counter 150 verifies that the MD_I metadata retrieved in step 603 (that is, the metadata that is supposed to include the copy of the operation descriptor OP_DESC) matches the operation descriptor OP_DESC retrieved in step 602. In other words, the smart counter 150 verifies that the copy of the operation to be performed OP_DESC in the MD_I metadata retrieved in step 603 is identical to the operation descriptor OP_DESC retrieved in step 602. This verifies that the operation descriptor OP_DESC has not been altered (only) in either of the two places where it is written or copied in the command.

[0119] Then, in step 605, the smart counter 150 tests whether the check in step 604 is successful. When the MD_I metadata retrieved in step 603 does not conform to the descriptor of the operation to be performed, OP_DESC, retrieved in step 602, the smart counter 150 rejects the command in step 606, thus terminating the process. Otherwise, step 607 is performed.

[0120] In step 607, the smart meter 150 retrieves, in the received command, and verifies, using the public key of the manager device 111, that the signature is consistent with the input attributes ATT_I to be applied as input to the operation to be performed and with the metadata MD_I associated with the command, which were retrieved in step 602.

[0121] Then, in step 608, the smart counter 150 tests whether the verification in step 607 is successful. If the signature does not conform to the input attributes ATT_I to be applied as input to the operation to be performed and the metadata MD_I associated with the command, step 606 is performed. Otherwise, step 609 is performed.

[0122] In step 609, the smart meter 150 accepts the command, noting that it has not been altered during its transmission from the management device 111.

[0123] For example, consider that the remote_connect() method of a COSEM object of class "DISCONNECTOR" is invoked using an object of type "DATA PROTECTION" to order a power activation (ACTION) from a said smart meter 150. If an alteration in the path changes the identifier of the method invoked in remote_disconnect(), this alteration is detected on reception and it is thus prevented from carrying out a different operation (here the opposite) of what was initially desired.

[0124] As another example, consider the case of configuring a low threshold for overconsumption detection using an object of type "EIMTTER" (class 71). If an alteration along the way changes the command "SET threshold_normal" to "SET threshold_emergency", this alteration is detected at the receiving end, thus preventing a different operation (here, configuring the threshold for different operational situations) from what was initially intended.

[0125] Other checks can be performed by the smart counter 150, particularly concerning the MD_I metadata. For example, the smart counter 150 can verify that the order date (the "date-time" metadata) is not too old relative to a time limit. Also, the smart counter 150 can verify that the cryptographic identity of the signer (the "originator-system-title" metadata) and / or the cryptographic identity of the recipient (the "recipient-system-tide" metadata) conform to expected identities.

[0126] In a particular embodiment, the process of [Fig. 6] is also implemented by the DC 120 data concentrator, provided that the DC 120 data concentrator is aware of the public key corresponding to the private key used by the management device 111 to generate the signature. Thus, if the DC 120 data concentrator is a trusted device, this makes it possible to verify, before relaying the command to the relevant smart meter 150, that the command has not been altered on interface II and to reject it without forwarding it to said smart meter 150 if necessary.

[0127] Fig. 7 schematically illustrates a flowchart of a process for formatting and transmitting a response to a command which was initiated by the management device 111 to a said smart meter 150, in a particular embodiment.

[0128] In a step 701, the smart meter 150 in question performs the commanded operation, after having performed the verification process of [Fig.6].

[0129] In step 702, the smart counter 150 prepares the response to the command. The smart counter 150 retrieves the operation descriptor to be performed, OP_DESC, which was provided in the command. The smart counter 150 retrieves output attributes, ATT_O, and associated metadata, MD_O, to be provided to the management device 111 as the results of the command execution. The ATT_O output attributes typically include a success code or an error code with respect to the results of the command execution. The ATT_O output attributes may include other information, such as a register value resulting from the execution of the commanded operation.

[0130] The smart meter 150 includes, in the MD_0 metadata, the operation descriptor to be performed OP_DESC, which was provided in the order. This allows the management device 111 to have confirmation that the order verification has been successfully carried out.

[0131] Preferably, the MD_0 metadata of the response includes a transaction number (metadata "transaction-id") which takes up a transaction number that had been included in the MD_I metadata of the corresponding order, in order to allow determination of which order the response corresponds to.

[0132] In a step 703, the smart meter 150 secures the output attributes ATT_O and the metadata MD_0 (including therefore the operation descriptor to be performed OP_DESC) by generating the signature as already described (asymmetric encryption with the private key of the smart meter 150).

[0133] In a step 704, the smart meter 150 affixes the generated signature to the response.

[0134] In a step 705, the smart meter 150 transmits the secure response to the DC data concentrator 120 for relay to the management device 111.

[0135] Figure 8 schematically illustrates a flowchart of a verification process for accepting or rejecting a received response. The response was generated and transmitted according to the process described above in relation to Figure 7.

[0136] In step 801, the managing device 111 receives the response in question.

[0137] In step 802, the management device 111 retrieves, from the response received, (which are assumed to be) the output attributes ATT_O that result from the operation completed, as well as (what is assumed to be) the MD_O metadata associated with the response.

[0138] In step 803, the management device 111 retrieves from memory the operation descriptor OP_DESC that was initially transmitted in the command to which the response is assumed to correspond. For example, the MD_0 metadata of the response includes a transaction number that is equal to a transaction number that was included in the MD_I metadata of the corresponding command, which makes it easy to find the OP_DESC descriptor in question.

[0139] In a step 804, the management device 111 verifies that the metadata MD_0 retrieved in step 802 corresponds to the operation descriptor to be performed OP_DESC retrieved in step 803.

[0140] Then, in step 805, the managing device 111 tests whether the check in step 804 is successful. When the MD_0 metadata retrieved in step 802 does not conform to the descriptor of the operation to be performed, OP_DESC, retrieved in step 803, the managing device 111 rejects the response in step 806, thus terminating the process. Otherwise, step 807 is performed.

[0141] In step 807, the management device 111 retrieves, from the received response, and verifies, using the public key of the smart meter 150 that transmitted the response, that the signature is consistent with the output attributes ATT_O and the metadata MD_0, which were retrieved in step 803.

[0142] Then, in step 808, the managing device 111 tests whether the verification in step 807 is positive. When the signature conforms to the output attributes ATT_O and the metadata MD_0, step 809 is performed. Otherwise, step 806 is performed.

[0143] In step 809, the management device 111 accepts the response, noting that it has not been altered during its transmission from the smart meter 150 that issued it. The output attributes ATT_O can then be used by the management device 111 since the operation performed by the smart meter 150 corresponds to the command initiated by the management device 111.

[0144] Other checks can be performed by the 111 management device, particularly concerning the MD_0 metadata. For example, the 111 management device can verify that the response date (date-time metadata) is not too old relative to a time limit. Also, the 150 smart meter can verify that the cryptographic identity of the signer (originator-system-title metadata) and / or the cryptographic identity of the recipient (recipient-system-title metadata) conform to expected identities.

[0145] In a particular embodiment, the process of [Fig. 8] is also implemented by the DC 120 data concentrator, provided that the DC 120 data concentrator is aware of the public key corresponding to the private key used by the smart meter 150 in question to generate the signature. Thus, if the DC 120 data concentrator is a trusted device, this makes it possible to verify, before relaying the response to the management device 111, that the response has not been altered on interface 12 and to reject it without forwarding it to the management device 111 if necessary.

Claims

Demands

1. Method of transmitting a secure command in an automated smart meter management system (100) (151, 152, 153), the command comprising a descriptor (OP_DESC) of an operation to be performed by said smart meter (151, 152, 153) and input attributes (ATT_I) of the operation to be performed and metadata (MD_I) associated with the command, the method comprising the following steps executed by a management device (111) of the automated management system (100) remotely managing the smart meters (151, 152, 153): - perform a security (502) which generates (400) a first signature on a set of data formed by the input attributes (ATT_I) of the operation to be performed, and the metadata (MD_I) associated with the command;- transmit (504) to the smart meter in question (151, 152, 153) the command with the descriptor of the operation to be performed (OP_DESC), the input attributes (ATT_I) of the operation to be performed, the metadata (MD_I) associated with the command and the first generated signature; characterized in that the method further comprises: - include (501) in the metadata (MD_I) associated with the command a copy of the descriptor (OP_DESC) of the operation to be performed, so that the first signature also applies to the copy of the descriptor (OP-DESC) of the operation to be performed in order to allow verification upon reception that the command has not been altered during transmission.

2. A method according to claim 1, wherein the operation descriptor (OP_DESC) to be performed and its copy contain an identifier of the operation to be performed.

3. A method according to claim 1 or 2, wherein the automated management of smart meters is operated according to an object-oriented model, the operation descriptor (OP_DESC) to be performed and its copy contain a class identifier of at least one object manipulated to perform the operation in question.

4. Method according to claim 3, wherein the object-oriented modeling is of the COSEM type and the security that generates the first signature is obtained by an object of the DATA PROTECTION type.

5. A method according to any one of claims 1 to 4, further comprising the following steps, upon receipt (601) of the command, of verifying the command executed by the smart meter in question (151, 152, 153) to which said command was transmitted: - retrieving (602), from the received command, the descriptor (OP_DESC) of the operation to be performed; - retrieving (603), from the received command, the input attributes (ATT_I) to be applied as input to the operation to be performed, as well as the metadata (MD_I) associated with the command; - verifying (604) that the copy of the descriptor (OP_DESC) of the operation to be performed in the retrieved metadata is consistent with the retrieved descriptor (OP_DESC) of the operation to be performed, and when this is not the case, rejecting the command;- retrieve (607), in the received command, and verify that the first signature in the command is consistent with the input attributes (ATT_I) to be applied as input to the operation to be performed, and with said metadata (MD_I) including the copy of the descriptor (OP_DESC) of the operation to be performed, which were retrieved in the command, and when this is not the case, reject the command, and otherwise, accept the command.;

6. Method according to claim 5, wherein the order verification is also performed by a data concentrator (120) acting as a relay between the management device (111) and the smart meter in question (151, 152, 153) in the automated management system (100).

7. A method according to any one of claims 1 to 6, further comprising the following steps, after execution (701) of the commanded operation, carried out by the smart meter in question (151, 152, 153) to provide a response to the command: - retrieving output attributes (ATT_O), and metadata (MD_0) associated with the response, to be provided to the management device (111) as results of command execution; - including (702), in the metadata (MD_0) associated with the response, the descriptor (OP_DESC) of the operation to be carried out which had been provided in the command; - perform (703) a security that generates a second signature on a set of data formed by the output attributes (ATT_O) and the metadata (MD_0) associated with the response; - transmit (705) to the managing device (111) the response including the output attributes (MD_0), the said metadata (MD_0) including the descriptor of the operation to be performed which had been provided in the command, and the second generated signature.

8. A method according to claim 7, further comprising the following steps, upon receipt (801) of the response, of verifying the response executed by the management device (111): - retrieving (802), from the received response, the output attributes (ATT_O) that result from the operation performed, as well as the metadata (MD_0) associated with the response; - retrieving (803) into memory the descriptor of the operation to be performed that was initially transmitted in the command to which the response is supposed to correspond; - verifying (804) that the metadata (MD_0) retrieved from the response corresponds to the descriptor (OP_DESC) of the operation to be performed, and when this is not the case, rejecting the response;- retrieve (807) from the received response and verify that the second signature is consistent with the output attributes (ATT_O) and metadata (MD_0) associated with the response, which were retrieved from the response, and if not, reject the response, and otherwise, accept the response.

9. Method according to claim 8, wherein the verification of the response is also performed by a data concentrator (120) acting as a relay between the management device (111) and the smart meter in question (151, 152, 153) in the automated management system (100).

10. A control device (111) comprising electronic circuitry configured to perform secure transmission of a command in an automated smart meter management system (100) (151, 152, 153) where the control device (111) is configured to remotely manage the smart meters (151, 152, 153), the command comprising a descriptor (OP_DESC) of an operation to be performed by said smart meter (151, 152, 153) and input attributes (ATT_I) of the operation to be performed and metadata (MD_I) associated with the command, the

11. electronic circuitry being configured to execute the following steps: - perform a security (502) which generates a first signature on a set of data formed by the attributes (ATT_I) as input of the operation to be performed and the metadata (MD_I) associated with the command; - transmit (504) to the smart meter in question (151, 152, 153) the command with the descriptor (OP_DESC) of the operation to be performed, the input attributes (ATT_I) of the operation to be performed, the metadata (MD_I) associated with the command and the first generated signature; characterized in that the process further comprises: - including (501) in the metadata (MD_I) associated with the command a copy of the descriptor (OP_DESC) of the operation to be performed, so that the first signature also applies to the copy of the descriptor (OP_DESC) of the operation to be performed in order to allow verification upon receipt that the command has not been altered during transmission. Smart meter (151, 152, 153) configured to process a command received from a management device (111) in an automated management system (100) where the management device (111) is configured to remotely manage the smart meter (151, 152, 153), the command comprising a descriptor (OP_DESC) of an operation to be performed by the smart meter and input attributes (ATT_I) of the operation to be performed and metadata (MD_I) associated with the command, characterized in that the smart meter (151, 152, 153) comprises electronic circuitry configured to execute the following steps, upon receipt (601) of the command, of verifying the command: - retrieve (602), in the received command, the descriptor (OP_DESC) of the operation to be performed; - retrieve (603), in the received command, the input attributes (ATT_I) to be applied as input to the operation to be performed, as well as the associated metadata (MD_I); - verify (604) that the copy of the descriptor (OP_DESC) of the operation to be performed in the retrieved metadata is consistent with the descriptor (OP_DESC) of the operation to be performed retrieved, and when this is not the case, reject the command; - retrieve (607), in the received command, and verify that the first signature in the command is consistent with the input attributes (ATT_I) to be applied as input to the operation to be performed and with said metadata (MD_I) including the copy of the descriptor (OP_DESC) of the operation to be performed, which were retrieved in the command, and when this is not the case, reject the command, and otherwise, accept the command.

12. Automated smart meter management system (100) comprising a management device (111) according to claim 10 and smart meters (151, 152, 153) according to claim 11

13. 1 1. A method implemented by a smart meter (151, 152, 153) to process a command received from a management device (111) in an automated management system (100) where the management device (111) is configured to remotely manage the smart meter (151, 152, 153), the command comprising a descriptor of an operation to be performed by said smart meter (151, 152, 153) and input attributes (ATT_I) of the operation to be performed and metadata (MD_I) associated with the command, characterized in that the method comprises the following steps, upon receipt (601) of the command, of verifying the command: - retrieve (602), in the received command, the descriptor (OP_DESC) of the operation to be performed; - retrieve (603), in the received command, the input attributes (ATT_I) to be applied as input to the operation to be performed, as well as the metadata (MD_I) associated with the command;- verify (604) that the copy of the operation descriptor (OP_DESC) in the retrieved metadata (MD_I) matches the retrieved operation descriptor (OP_DESC), and if not, reject the command; - retrieve (607) from the received command and verify that the first signature in the command matches the input attributes (ATT_I) to be applied to the operation and the said metadata (MD_I), including the copy of the operation descriptor (OP_DESC) that was retrieved from the command, and if not, reject the command; otherwise, accept the command.

14. Product computer program comprising instructions resulting in an implementation, by a processor, of the method according to any one of claims 1 to 4 or of the method according to claim 13, when the instructions are executed by the processor.

15. Information storage medium storing instructions leading to an implementation, by a processor, of the method according to any one of claims 1 to 4 or of the method according to claim 13, when the instructions are read from the information storage medium and executed by the processor.

Images