METHOD AND SYSTEM FOR SECURE RESPONSE TO A COMMAND FROM A SMART METER

Abstract

To transmit (705) a response to a received command that included a descriptor (OP_DESC) of an operation to be performed, a smart meter retrieves output attributes (ATT_O) and metadata (MD_O) associated with the response, to be provided as the results of executing the received command. The smart meter includes (702) in the metadata (MD_O) associated with the response the descriptor (OP_DESC) of the operation to be performed that was provided in the received command, and performs (703) a security measure that generates a signature on a dataset formed by the output attributes (ATT_O) and the metadata (MD_O) associated with the response. Figure to be published with the abbreviation: Fig. 7

Description

Title of the invention: METHOD AND SYSTEM FOR SECURE RESPONSE TO A COMMAND FROM A SMART METER technical field

[0001] At least one embodiment relates to a method and a system for securely responding to a command addressed to a smart meter. The system in question is adapted to allow a management device to ensure that responses to commands transmitted to a smart meter are not manipulated in transit and to know with certainty which operations were performed by the smart meter upon receipt of the commands. STATE OF PRIOR ART

[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. Exchanges can thus take place 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] In order to guard against alteration of command attributes, the COSEM (Companion Specification for Energy Metering) specifications 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 "BluebookDLMS" V16 part 2 §4.4.9) which affixes a signature (asymmetric encryption) to command execution results (output attributes), and to associated metadata (number of transaction, order date, cryptographic identity of the signatory, cryptographic identity of the recipient). As a reminder, the COSEM specifications define an object-based model to formalize 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 model various use cases beyond energy management (water distribution management, for example).

[0004] The protection of output attributes and associated metadata, notably enabled by the COSEM specifications through the "DATA PROTECTION" object type, is an important tool for securing the transmission of responses to commands sent by a management device in an automated (remote) smart meter management system. This prevents altered responses from being taken into account by the management device.

[0005] However, securing the transmission of responses by protecting output attributes is an imperfect solution. Indeed, various commands can return similar output attributes, in terms of their shapes, sizes, etc. And the output attribute protection offered by the "DATA PROTECTION" type object is ineffective against an alteration of the command itself, typically an alteration of the command identifier. For example, if the operation desired by the managing device involves reading a 32-bit register and the smart meter returns the value of a different 32-bit register due to an altered command, the managing device may misinterpret the operational state of the smart meter.

[0006] It is therefore desirable to provide a solution which makes it possible to strengthen the security of responses to commands transmitted in an automated remote management system from a management device to smart meters, so as not to take into account information provided by the smart meters which would not actually correspond to the commands initially transmitted. Description of the invention

[0007] To this end, he proposed a method for transmitting a response to a command received by a smart meter in an automated management system, the command comprising a descriptor of an operation to be performed by said smart meter, the method comprising the following steps executed by said smart meter, after completion of the commanded operation, to provide the response to the received command:

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

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

[0010] - to perform a security measure that generates a signature on a dataset formed by the output attributes and metadata associated with the response;

[0011] - transmit, in response to the received command, the response including the attributes of output, the said associated metadata including the operation descriptor to be performed which had been provided in the received order, and the second generated signature.

[0012] Thus, thanks to the presence in the metadata associated with the response of the descriptor of the operation to be performed that was provided in the received command, as well as the signature, it is possible to know which operation was actually performed by the smart meter and, if an alteration of the command and / or the response has occurred, to detect it. It is therefore possible to disregard information provided by smart meters that does not actually correspond to the commands initially transmitted to them.

[0013] According to a particular embodiment, the command further includes metadata associated with the command, including a copy of the operation descriptor to be performed; the smart meter verifies that the operation descriptor to be performed and its copy in the metadata associated with the received command are identical, and when this is not the case, the smart meter rejects the received command.

[0014] Thus, the command is secure, which prevents the smart meter from carrying out an operation that would not correspond to the command initially transmitted.

[0015] According to a particular embodiment, the smart meter constructs the metadata associated with the response by copying the metadata associated with the received command.

[0016] Thus, the smart meter can easily indicate, in response to the command, what operation has been carried out.

[0017] According to a particular embodiment, the operation descriptor to be performed contains an identifier of the operation to be performed.

[0018] Thus, although a simple identifier of the operation to be performed could easily be altered, the clever copying of the descriptor of the operation to be performed within metadata which benefits from signature protection is sufficient to allow detection that an alteration has occurred.

[0019] According to a particular embodiment, the automated management of smart meters is operated according to an object-oriented modeling, the operation descriptor to be performed contains a class identifier of at least one object manipulated to perform the operation in question.

[0020] Thus, although a simple identifier of object classes manipulated to carry out the desired operation could easily be altered, the clever copying of the descriptor of the operation to be carried out within metadata that benefit from signature protection is sufficient to allow detection that an alteration has occurred.

[0021] According to 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.

[0022] Thus, the clever copying of the descriptor of the operation that was to be carried out, in the metadata of the response, makes it possible to ensure the security sought in the context of the use of a COSEM object of type DATA PROTECTION.

[0023] According to a particular embodiment, the method further comprises the following steps, upon receipt of the response, of verification of the response executed by a management device which transmitted the command to the smart meter:

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

[0025] - retrieve into memory the descriptor of the operation to be performed that had been transmitted in the command to which the response corresponds;

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

[0027] - retrieve the signature from the received response and verify that the signature is conforms 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.

[0028] Thus, the management device is able to detect if an alteration has occurred in the command (bad command executed by the smart meter) and / or in the response.

[0029] According to 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.

[0030] 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).

[0031] A smart meter configured to process a command received in an automated management system is also proposed. comprising a descriptor of an operation to be performed by the smart meter. The smart meter includes electronic circuitry configured to execute the following steps, after completing the commanded operation, to provide the response to the received command:

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

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

[0034] - to perform a security measure that generates a signature on a dataset formed by the output attributes and metadata associated with the response;

[0035] - transmit, in response to the received command, the response including the attributes of output, the said associated metadata including the operation descriptor to be performed which had been provided in the received order, and the second generated signature.

[0036] Also proposed here is a management device comprising electronic circuitry configured to transmit a command in an automated management system, the command comprising an operation descriptor to be performed by a smart meter, the electronic circuitry being configured to execute the following steps, upon receipt of the response, of verifying the response:

[0037] - retrieve, from the received response, output attributes that result from an operation performed by the smart meter upon receipt of the command, as well as the metadata associated with the response;

[0038] - retrieve into memory the descriptor of the operation to be performed which had initially transmitted in the order;

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

[0040] - retrieve the signature from the received response and verify that the signature is conforms 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.

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

[0042] Also proposed here is a method implemented by a management device in an automated management system, in which the management device transmits a command comprising a descriptor of the operation to be performed by a smart meter. The process is such that the management device executes the following steps upon receiving a response to the command:

[0043] - retrieve, from the received response, output attributes that result from an operation performed by the smart meter upon receipt of the command, as well as the metadata associated with the response;

[0044] - retrieve into memory the descriptor of the operation to be performed which had initially transmitted in the order;

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

[0046] - retrieve the signature from the received response and verify that the signature is conforms 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.

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

[0048] 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

[0049] 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:

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

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

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

[0053] [Fig.4] schematically illustrates a principle of generation and apposition of signature ;

[0054] [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, in a particular embodiment;

[0055] [Fig.6] schematically illustrates an organizational chart of a verification process for acceptance or rejection of a received order, in a particular embodiment;

[0056] [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; and

[0057] [Fig.8] schematically illustrates a flowchart of a verification process for acceptance or rejection of a received response.

[0058] DETAILED DESCRIPTION OF IMPROVEMENTS

[0059] 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).

[0060] The remote management of the smart meters 151, 152, 153 is ensured by a management device 111 of an information system IS (“Information System” in English) 110. In many solutions of such automated management systems, the management device 111 is a meter data management system MDMS (“Meter Data Management System” in English).

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

[0062] 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).

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

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

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

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

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

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

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

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

[0071] 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).

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

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

[0074] To ensure the integrity of the responses transmitted by the smart meter 150 to commands transmitted by the management device 111, 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”.

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

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

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

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

[0079] Fig. 4 schematically illustrates a principle of securing a response to a command by generating and affixing a signature.

[0080] As proposed by the COSEM specifications, a signature is affixed by asymmetric encryption using a private key on a data set formed from the output attributes ATT_O, results of a commanded operation, as well as MD_0 metadata associated with the response.

[0081] 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). The metadata is typically first provided (MD_I metadata), at least in part, in the order and 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.

[0082] The operation to be performed is presented in the command in an OP_DESC descriptor (e.g., COSEM object(s)). As described below, in a particular embodiment, a copy of this OP_DESC descriptor is included in the MD_I metadata (more specifically in the existing "other-information" metadata or via the addition of a new "object-list" metadata field) provided in the command.

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

[0084] 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 possible copy, in the command, contain a class identifier of at least one object manipulated to perform the operation in question.

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

[0086] It is proposed here to include, in the response, in the MD_0 metadata (more specifically in the existing "other-information" metadata or via the addition of a new "object-list" metadata field), a copy of the descriptor of the operation to be performed, OP_DESC. This copy of the descriptor of the operation to be performed, OP_DESC, according to the received command, is thus included in the area covered by the signature-based security.

[0087] Thus, after generating a SIGN signature from the output attributes ATT_O of the operation to be performed according to the received command and the MD_0 metadata (including the copy of the operation descriptor to be performed OP_DESC), the SIGN signature is affixed along with the output attributes ATT_O and the MD_0 metadata. It is then possible to verify upon receipt of the response, using the public key corresponding to the private key used to generate the signature, that not only have the output attributes not been altered, but also, using the copy of the operation descriptor to be performed OP_DESC included in the MD_0 metadata and the signature, to prevent the managing device from misinterpreting the operation performed by the smart meter 150 and thus determine whether this operation conforms to the one initially required by the managing device 111.The 111 management device is then able to decide whether the ATT_O output attributes received in the response can be taken into account.

[0088] The response security principle presented above is advantageously applied to non-critical operations with respect to the smart meter, more specifically information reading operations (e.g., "GET" type commands). However, it is important that the management device 111 be able to determine how much confidence to place in the ATT_O output attributes contained in the response, and in particular whether these actually correspond to the execution results of the command initially transmitted by the management device 111. For example, within the framework of the DLMS / COSEM specifications, the command security principle presented above is advantageously applied in the context of reading a load curve or event log via a class 7 object “PROFILE GENERIC”.

[0089] 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, in one embodiment.

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

[0091] 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. This particular embodiment allows verification upon reception that the operation descriptor to be performed OP_DESC has not been altered during transmission (the copy corresponds to the operation descriptor to be performed OP_DESC which is located elsewhere in the command).

[0092] Optional ATT_I input attributes may be added to the command, if the command is of a type that requires it.

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

[0094] 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).

[0095] Figure 6 schematically illustrates a flowchart of a verification process for accepting or rejecting a received order, in a particular embodiment. 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).

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

[0097] 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).

[0098] In a step 603, the smart meter 150 retrieves, in the received command, (what is assumed to be) the MD_I metadata associated with the command.

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

[0100] 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 match the descriptor of the operation to be performed, OP_DESC, retrieved in step 602, the smart counter 150 rejects the command in step 606. Otherwise, in step 607, the smart counter 150 accepts the command.

[0101] 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-title" metadata) conform to expected identities.

[0102] The verification process in [Fig. 6] is executed when the managing device 111 is assumed to copy the operation descriptor to be performed OP_DESC into the input metadata MD_I. Otherwise, the smart meter 150 in question can simply perform checks regarding the order date and / or the cryptographic identity of the signatory and / or the cryptographic identity of the recipient.

[0103] Figure 7 schematically illustrates a flowchart of a formatting process and transmission of a response to a command which was initiated by the management device 111 to a said smart meter 150.

[0104] In step 701, the smart meter 150 in question performs the commanded operation. When the management device 111 is assumed to copy the operation descriptor to be performed OP_DESC into the input metadata MD_I, the smart meter 150 in question performs the commanded operation after having executed the verification process of [Fig. 6] and having accepted the command in step 607.

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

[0106] The smart meter 150 retrieves output attributes ATT_O, and associated metadata MD_0, to be provided to the management device 111 as results of command execution.

[0107] The ATT_O output attributes can include a success code or an error code with respect to the results of command execution.

[0108] The ATT_O output attributes may include other information, such as a register value resulting from the execution of the commanded operation. For example, the ATT_O output attributes may include the contents of an event log that was read by the command.

[0109] The smart meter 150 includes, in the MD_0 metadata, the operation descriptor to be performed OP_DESC which had been provided in the order.

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

[0111] In a particular embodiment, the smart meter 150 constructs the MD_0 metadata by copying the MD_I metadata (including the operation descriptor to be performed OP_DESC, if it has been copied there).

[0112] 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).

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

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

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

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

[0117] In step 802, the managing device 111 retrieves, from the response received, (which are assumed to be) the output attributes ATT_O that result from the operation performed, as well as (which are assumed to be) the MD_0 metadata associated with the response.

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

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

[0120] Then, in step 805, the management device 111 tests whether the verification 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 management device 111 rejects the response in step 806, thus terminating the process. This is because it means that the smart meter 150 in question performed a different operation than intended, or that the response was altered in transit. Therefore, the management device 111 cannot trust the received output attributes, ATT_O. Otherwise, step 807 is performed.

[0121] In step 807, the management device 111 retrieves, in 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.

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

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

[0124] For example, using the algorithm in [Fig. 8], the management device 111 can verify that a security event log read command has been executed exactly as originally requested, without alteration. Indeed, a modification along the way to an OBIS code that specifies the operation to be performed could lead to the return of the contents of a different event log, resulting, for example, in the erroneous conclusion that no significant event has occurred.

[0125] Other checks can be carried out by the management device 111, particularly concerning the MD_0 metadata. For example, the management device 111 can verify that the response date (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 (originator-system-title metadata) and / or the cryptographic identity of the recipient (recipient-system-title metadata) conform to expected identities.

[0126] 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 response to a command received by a smart meter (151, 152, 153) in an automated management system (100), the received command comprising a descriptor (OP_DESC) of an operation to be performed by said smart meter (151, 152, 153), the method comprising the following steps executed by said smart meter (151, 152, 153), after execution (701) of the commanded operation, to provide the response to the received command: - retrieve output attributes (ATT_O), and metadata (MD_0) associated with the response, to be provided as results of execution of the received command; - include (702), in the metadata (MD_0) associated with the response, the descriptor (OP_DESC) of the operation to be performed which had been provided in the received command; - perform (703) a security that generates a signature on a set of data formed by the output attributes (ATT_O) and the metadata (MD_0) associated with the response;- transmit (705), in response to the received command, the response including the output attributes (MD_0), the associated metadata (MD_0) including the operation descriptor to be performed which had been provided in the received command, and the second generated signature.;

2. A method according to claim 1, wherein the command further includes metadata (MD_I) associated with the command, including a copy of the descriptor (OP_DESC) of the operation to be performed, and wherein the smart meter (151, 152, 153) verifies (604) that the descriptor (OP_DESC) of the operation to be performed and its copy in the metadata (MD_I) associated with the received command are identical, and when this is not the case, the smart meter (151, 152, 153) rejects the received command.

3. Method according to claim 2, wherein the smart meter (151, 152, 153) constructs the metadata (MD_0) associated with the response by copying the metadata (MD_I) associated with the received command.

4. A method according to any one of claims 1 to 3, wherein the operation descriptor (OP_DESC) to be performed contains an identifier of the operation to be performed.

5. A method according to any one of claims 1 to 4, wherein the automated management of smart meters is operated according to an object-oriented model, the operation descriptor (OP_DESC) to be performed contains a class identifier of at least one object manipulated to perform the operation in question.

6. Method according to claim 5, 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.

7. A method according to any one of claims 1 to 6, further comprising the following steps, upon receipt (801) of the response, of verification of the response performed by a management device (111) which transmitted the command to said smart meter (151, 152, 153): - retrieve (802), in the received response, the output attributes (ATT_O) which result from the operation performed, as well as the metadata (MD_0) associated with the response; - retrieve (803) into memory the descriptor of the operation to be performed which was initially transmitted in the command to which the response corresponds; - verify (804) that the metadata (MD_0) retrieved from the response corresponds to the descriptor (OP_DESC) of the operation to be performed retrieved from memory, and when this is not the case, reject the response;- retrieve (807) the signature, in the received response, and verify that the signature is consistent with the output attributes (ATT_O) and metadata (MD_0) 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.;

8. Method according to claim 7, 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).

9. Smart meter (151, 152, 153) configured to process a command received in an automated management system (100), the command received comprising a descriptor (OP_DESC) of an operation to be performed by the smart meter, characterized in that the smart meter (151, 152, 153) comprises electronic circuitry configured to perform the following steps, after execution (701) of the commanded operation, to provide the response to the received command: - retrieve output attributes (ATT_O), and metadata (MD_0) associated with the response, to be provided as results of execution of the received command; - include (702), in the metadata (MD_0) associated with the response, the descriptor (OP_DESC) of the operation to be performed which had been provided in the received command; - perform (703) a security measure which generates a signature on a set of data formed by the output attributes (ATT_O) and the metadata (MD_0) associated with the response;- transmit (705), in response to the received command, the response including the output attributes (MD_0), the associated metadata (MD_0) including the operation descriptor to be performed which had been provided in the received command, and the second generated signature.;

10. Management device (111) comprising electronic circuitry configured to perform a command transmission in an automated management system (100), the command comprising an operation descriptor (OP_DESC) to be performed by a smart counter (151, 152, 153), the electronic circuitry being configured to perform the following steps, upon receipt (801) of the response, of verifying the response: - retrieve (802), from the received response, output attributes (ATT_O) that result from an operation performed by the smart counter (151, 152, 153) upon receipt of the command, as well as the metadata (MD_0) associated with the response; - retrieve (803) into memory the operation descriptor to be performed that was initially transmitted in the command;- verify (804) that the metadata (MD_0) retrieved in the response corresponds to the operation descriptor (OP_DESC) to be performed retrieved from memory, and when this is not the case, reject the response; - retrieve (807) the signature, in the received response, and verify that the signature is consistent with the output attributes (ATT_O) and metadata (MD_0) 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.

11. System (100) for automated smart meter management comprising a management device (111) according to claim 10 and smart meters (151, 152, 153) according to claim 9.

12. A method implemented by a management device (111) in an automated management system (100), wherein the management device (111) transmits a command containing a descriptor (OP_DESC) of an operation to be performed by a smart counter (151, 152, 153), characterized in that the management device (111) executes the following steps, upon receipt (801) of a response to the command: - retrieve (802), from the received response, output attributes (ATT_O) resulting from an operation performed by the smart counter (151, 152, 153) upon receipt of the command, as well as the metadata (MD_0) associated with the response; - retrieve (803) into memory the descriptor of the operation to be performed that was initially transmitted in the command;- verify (804) that the metadata (MD_0) retrieved from the response corresponds to the operation descriptor (OP_DESC) to be performed retrieved from memory, and when this is not the case, reject the response; - retrieve (807) the signature from the received response, and verify that the signature is consistent with the output attributes (ATT_O) and the metadata (MD_0) 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.

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

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

Images