Method and system for secure firmware upgrade of an electric energy meter

Abstract

This invention provides a method and system for secure firmware upgrades of electricity meters. At the master station, an upgrade package is constructed, consisting of a structured header, firmware payload, authentication tag, and digital signature. The structured header includes a specially configured extensible flag field to flexibly define the context parameter combinations, security policies, and compression policies involved in encryption operations, improving upgrade compatibility. At the device end, all core security operations, such as signature verification, key derivation, and decryption authentication, are executed independently by a secure element, and the keys are never exposed, fundamentally preventing key leakage and unauthorized tampering. The overall solution, through multiple pre-verification checks combined with encryption authentication, digital signatures, and CRC checks, forms an end-to-end, multi-layered protection system, comprehensively ensuring the confidentiality, integrity, source credibility, and device compatibility of firmware upgrades. It effectively resists various attacks and significantly improves the security, reliability, and operational stability of electricity meter firmware upgrades.

Description

Technical Field

[0001] This invention relates to the field of firmware upgrade technology, and in particular to a method and system for secure firmware upgrade of electricity meters. Background Technology

[0002] Currently, firmware upgrades for electricity meters generally use plaintext transmission or rely on communication layer security mechanisms such as DLMS session encryption for protection. These solutions have significant shortcomings: the firmware data itself is not independently and securely encapsulated, and its confidentiality and integrity cannot be independently verified at the application layer. Even when some devices introduce a Secure Element (SE), it is often limited to key storage or basic encryption / decryption operations, failing to establish an end-to-end verification process where the main control firmware and the SE work together.

[0003] Crucially, existing firmware upgrade packages typically lack structured security metadata, making it impossible for the master firmware to clearly identify key information from the package content: whether the upgrade package is encrypted, whether signature verification is required, which context parameters it depends on (such as region identifier), and what the specific firmware type is (full upgrade package or compressed upgrade package), which poses a significant challenge to the security and standardization of the upgrade process.

[0004] To address the aforementioned deficiencies in existing technologies, this invention proposes a method and system for secure firmware upgrades of electricity meters. By constructing an encrypted upgrade package with self-describing characteristics and establishing a collaborative verification mechanism between the master control firmware and the SE (Security Controller), end-to-end security protection can be achieved at the application layer, while also supporting flexible configuration of security policies and smooth evolution of communication protocols, thus building a solid security defense for electricity meter firmware upgrades. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to provide a method and system for secure firmware upgrade of electricity meters, so as to significantly improve the security of the firmware upgrade process of electricity meters.

[0006] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: Methods for secure firmware upgrades of electricity meters include: The master station constructs a structured header based on the target energy meter's attribute information, security policy, and new firmware parameters. The attribute information includes the upgrade package format version, hardware platform identifier, manufacturer identifier, region identifier, and bootloader version. The security policy includes at least one of manufacturer binding, region isolation, and bootloader verification. The structured header includes the attribute information, the new firmware parameters, and an extensible flag field. The extensible flag field includes a security policy identifier and a combination of context parameters used to identify specific fields in the structured header that participate in encryption operations. The master station calculates the session key based on the preset root key and the context parameters. The main station uses the session key to encrypt the compressed new firmware, generating a firmware payload and an authentication tag; The main station uses the signing private key to digitally sign the structured header and the authentication label together to obtain the corresponding digital signature; The main station assembles the structured header, firmware payload, authentication tag, and digital signature to obtain the upgrade package, and then sends it to the target energy meter. After receiving the upgrade package, the target energy meter parses the structured header in the upgrade package and performs device compatibility verification based on the parsing results, including the security policy. If the device compatibility verification is passed, the digital signature is extracted from the upgrade package and transmitted to the secure element; The secure element verifies the received digital signature based on a pre-set public key; If the digital signature verification is successful, the target energy meter will extract field data from the corresponding specific field in the structured header and pass it to the security element based on the combination of context parameters in the structured header. The security element calculates the session key based on the preset root key and the input field data; The target energy meter will pass the firmware payload and authentication tag extracted from the upgrade package to the security element; The security element decrypts the incoming firmware payload and verifies the incoming authentication tag based on the calculated session key. If the authentication tag passes the verification, the decrypted compressed new firmware is deemed valid.

[0007] Optionally, the structured header may further include an initialization vector; The master station uses the session key to encrypt the compressed new firmware, generating a firmware payload and authentication tag, specifically: The master station uses the session key and the initialization vector to encrypt the compressed new firmware and generate firmware payload and authentication tag; The security element, based on the calculated session key, decrypts the incoming firmware payload and verifies the incoming authentication tag, specifically as follows: The target energy meter parses the initialization vector from the structured header and passes it to the safety element; The security element decrypts the incoming firmware payload and verifies the incoming authentication tag based on the incoming initialization vector and the calculated session key.

[0008] Optionally, the step of parsing the structured header in the upgrade package and performing device compatibility verification based on the parsing result, including the security policy, includes: The extensible flag field in the structured header is parsed, and the configured security policy is determined based on the security policy identifier therein; Parse other fields in the structured header to obtain attribute information and new firmware parameters; Device compatibility verification is performed based on the parsed attribute information and new firmware parameters; the verification items for device compatibility verification include basic verification items and verification items configured in the security policy; the basic verification items include upgrade package format version, hardware platform type, and new firmware version; If any verification item in the device compatibility check fails, the upgrade will be rejected. If all verification items in the device compatibility check pass, the device compatibility check is considered passed.

[0009] Optionally, the verification process for the basic verification items in the device compatibility verification includes: Determine if the parsed upgrade package format version is higher than the highest version supported locally; if not, the verification passes. Determine whether the parsed hardware platform identifier is consistent with the locally stored hardware platform identifier; if so, the verification passes. Determine if the parsed new firmware version is higher than the currently used firmware version; if so, the verification passes.

[0010] Optionally, the verification process for the verification items configured in the security policy during the device compatibility verification includes: If the security policy includes Bootloader verification, it determines whether the parsed Bootloader version is lower than or equal to the local Bootloader version. If so, the verification passes. If the security policy is configured with vendor binding, then it is determined whether the parsed vendor identifier is consistent with the vendor identifier stored locally. If so, the verification passes. If the security policy is configured with region isolation, it is determined whether the parsed region identifier is consistent with the locally stored region identifier. If so, the verification passes.

[0011] Optionally, the master station calculates a session key based on a preset root key and the context parameters, including: The main station extracts field data from the corresponding specific field in the structured header based on the combination of context parameters; Based on the preset root key and the extracted field data, the session key is calculated using a pre-configured encryption algorithm.

[0012] Optionally, the context parameter combination is composed of the identifiers corresponding to at least two specific fields in the structured header that participate in the encryption operation.

[0013] Optionally, the new firmware parameters include a new firmware checksum; the structured header is constructed based on a pre-configured new firmware compression strategy; and the extensible flag field includes a compression strategy identifier for identifying the new firmware compression strategy. The security upgrade method further includes: The main station compresses the plaintext new firmware according to the compression strategy identifier in the extensible flag field and obtains the compressed new firmware; After the security element determines that the compressed new firmware obtained by decryption is valid, the target energy meter decompresses the compressed new firmware according to the compression strategy identifier to obtain the plaintext new firmware and calculates the corresponding check value. Determine whether the new firmware checksum obtained by parsing the structured header is consistent with the calculated checksum. If not, reject the upgrade; if so, write the plaintext new firmware into the main area of ​​the application.

[0014] Optionally, it also includes: The root key and the public / private key pair used for digital signatures are issued by a trusted certificate authority. The main station securely stores the root key and the signing private key from the public-private key pair; Before the target electricity meter leaves the factory or during the grid connection phase, the root key and the public key in the public-private key pair are injected into the secure storage area of ​​the security element through a trusted process; the secure storage area restricts access by the master control firmware.

[0015] Another technical solution provided by this invention is: A firmware security upgrade system for an electricity meter includes a master station and a target electricity meter connected by communication; the target electricity meter includes a security element. The master station is configured to execute the steps performed by the master station in the above-mentioned electricity meter firmware security upgrade method; The target energy meter is configured to perform the steps executed by the target energy meter in the above-described energy meter firmware security upgrade method.

[0016] The beneficial effects of this invention are as follows: The electricity meter firmware security upgrade method and system provided by this invention construct an upgrade package assembled from a structured header, firmware payload, authentication tag, and digital signature at the master station. The structured header is specially configured with an extensible flag field to flexibly define the combination of context parameters, security policies, and compression policies participating in encryption operations, enabling the upgrade process to flexibly adapt to the differentiated policies of different manufacturers, hardware platforms, and regions, supporting smooth protocol evolution and improving upgrade compatibility. At the device end, all core security operations such as signature verification, key derivation, and decryption authentication are executed independently by a secure element, and the key is never exposed, fundamentally blocking the risk of key leakage and illegal tampering. The overall solution, through multiple pre-verifications combined with encryption authentication, digital signature, and CRC verification, forms an end-to-end, multi-layered protection system, comprehensively ensuring the confidentiality, integrity, source credibility, and device compatibility of firmware upgrades, effectively resisting various attacks, and significantly improving the security, reliability, and operational stability of electricity meter firmware upgrades. Attached Figure Description

[0017] Figure 1 The method for secure firmware upgrade of electricity meters provided in this embodiment of the invention and the interaction diagram between the master station and the target electricity meter in the system are illustrated. Figure 2 This is a flowchart illustrating the first stage of the firmware security upgrade method for electricity meters provided in this embodiment of the invention, executed by the main station. Figure 3 This is a schematic diagram of the second stage of the electricity meter firmware security upgrade method provided in the embodiments of the present invention, executed by the electricity meter. Detailed Implementation

[0018] To explain in detail the technical principles, specific implementable solutions, possible application scenarios, and achievable objectives and effects of the present invention, exemplary embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. It is understood that the embodiments described herein and the embodiments shown in the accompanying drawings are only used to more clearly illustrate the technical solutions of the present invention, and are therefore only examples intended to explain the present invention, and should not be construed as limiting the present invention. It should be understood that the present invention can be implemented in various forms and should not be limited to the embodiments set forth herein.

[0019] Explanation of technical terms involved in this invention: A secure element (SE) is a dedicated hardware component that exists in the form of a chip. It protects sensitive data from unauthorized access through physical isolation and tamper-proof design, and has built-in encryption / decryption logic circuitry that operates in isolation from the main processor.

[0020] The bootloader, or bootloader program, is the first piece of software code that runs after the electricity meter is powered on. It is the bridge connecting the hardware and the operating system, responsible for initializing the hardware, loading the kernel, and transferring control.

[0021] The firmware payload is a continuous piece of encrypted data generated by compressing the original plaintext of the new firmware and then encrypting it using an authentication encryption algorithm (such as AES-GCM). Its length is the same as the compressed new firmware and it does not contain any header data. The confidentiality of the payload is guaranteed by the session key SK, and its integrity is verified by the subsequent authentication tag. Its binding to the upgrade policy is achieved by a digital signature that covers the structured header.

[0022] The authentication tag is a fixed-length binary data block located after the firmware payload and before the digital signature. Its length is determined by the authentication encryption algorithm and can be 12 bytes (e.g., using SM4-GCM or AES-GCM). This authentication tag is generated synchronously by the master station when encrypting the compressed new firmware using the session key SK and initialization vector IV (if any), and is used to verify that the firmware payload has not been tampered with or replaced during transmission. The authentication tag itself is not encrypted and is stored in plaintext, but its integrity is protected by the subsequent digital signature.

[0023] A digital signature, a binary data block located at the end of the upgrade package, is used to ensure the trustworthiness of the upgrade package's origin and the integrity of critical data. This digital signature operates on the byte concatenation result of the structured header and the authentication label; its verification scope explicitly includes the structured header and the authentication label, preventing attackers from tampering with the manufacturer identifier, hardware platform identifier, bootloader version, or replacing the authentication label.

[0024] Please see Figures 1 to 3 This invention provides a method for secure firmware upgrade of an electricity meter.

[0025] This invention provides a method for secure firmware upgrade of an electricity meter, wherein the interaction between the master station and the target electricity meter is as follows: Figure 1 As shown; the method mainly includes two stages: building the upgrade package on the main station and verifying the upgrade package on the target electricity meter. The specific implementation process is as follows: Phase 1: Building and upgrading the main station (the system responsible for remotely managing electricity meters).

[0026] like Figure 2 As shown, after the master station determines to send a firmware upgrade task to the target electricity meter, the master station will perform the following steps to construct an upgrade package in a specific format: 1-1. Obtain the target energy meter's attribute information, security policy, and new firmware parameters.

[0027] The attribute information of the target energy meter is characteristic information that represents the hardware identity, software version and operating environment of the target energy meter, including but not limited to: upgrade package format version, hardware platform identifier, manufacturer identifier, region identifier, and the current bootloader version of the energy meter.

[0028] In some specific implementations, the master station obtains the attribute information of the target electricity meter by querying from the device management database or a similar data platform.

[0029] The security policy is a pre-configured verification rule based on the security verification requirements of the target energy meter. Configurable verification items in the security policy include, but are not limited to, vendor binding, regional isolation, and bootloader verification. The security policy allows confirmation of whether vendor binding, regional isolation, and bootloader version verification are enabled during the pre-verification phase for the target energy meter.

[0030] The new firmware parameters are attribute information that characterizes the application firmware carried in the upgrade package, including but not limited to: new firmware version (i.e., the version of the firmware carried in the upgrade package) and new firmware check value (such as CRC check value).

[0031] 1-2. Construct a structured header.

[0032] The main site will construct the structured header of the upgrade package based on the information obtained in the previous step.

[0033] The structured header contains multiple fields, which serve as the carrier of security policies and the basis for upgrade decisions.

[0034] The following will explain all the fields that may be included in the structured header and their corresponding functions: (1) Field name: Package Format Version; Function Description: This function identifies the structure version number of this upgrade package (e.g., "V0.1" indicates the first-generation format). The target energy meter's main controller compares the upgrade package with the highest locally supported format version to determine if it can correctly parse the upgrade package. If the upgrade package version is too high, it will be rejected to prevent security vulnerabilities or system anomalies caused by incorrect format parsing.

[0035] (2) Field name: Hardware Platform Identifier (hardware Platform ID); Function Description: This identifies the hardware platform type of the target energy meter, typically combining the main control MCU model, safety element SE model, and circuit design version. The target energy meter's main control unit compares the hardware platform signal information stored locally to determine whether the new firmware carried in the upgrade package is compatible with the current hardware platform. If they do not match, the upgrade is rejected to avoid device crashes or malfunctions due to driver incompatibility, memory layout differences, or missing peripherals.

[0036] (3) Field name: New firmware version; Function Description: This function identifies the expected version number of the main control application software for the electricity meter after this upgrade, using a predefined encoding format (e.g., the high byte represents the main version, and the low byte represents the revision number). The main control of the target electricity meter can use this to determine whether the currently running firmware is already the latest version, avoiding repeated upgrades; at the same time, this version number can be used for log recording and upgrade status reporting.

[0037] (4) Field name: New firmware checksum (Firmware CRC32); Function Description: The CRC checksum of the complete plaintext firmware. Optionally, it can be calculated using a standard polynomial. The target energy meter will obtain a checksum using the same calculation method after receiving the complete plaintext firmware, and compare it with the value of this field. If they match, the transmitted firmware is considered complete and reliable.

[0038] (5) Field name: Bootloader version (Boot Version); Function Description: Declares the minimum Bootloader version required to run the new firmware in the upgrade package. The target energy meter's master controller reads the local Bootloader version and compares it with the value of this field; if the local version is lower, the upgrade process is terminated to prevent the system from failing to boot or the security mechanism from malfunctioning due to the Bootloader lacking necessary functions (such as secure boot verification, SE driver).

[0039] (6) Field name: Vendor ID; Function Description: Identifies the manufacturer's unique code (such as company / organization / institution name) of the target electricity meter.

[0040] In some specific implementations, if a manufacturer-bound verification item is configured in the security policy, the target electricity meter will use this field in the multiple pre-verification stage to determine whether it is consistent by comparing the manufacturer identifier stored locally. Only when they are consistent will the upgrade be allowed to continue, effectively preventing unauthorized manufacturer firmware from being flashed into the device and eliminating the risks of mixed flashing, piracy, or malicious replacement.

[0041] In some specific implementations, this field can be used as a specific field participating in encryption operations (i.e., the input factor of the key derivation function KDF) to achieve vendor-level key domain isolation.

[0042] (7) Field name: Region ID; Function Description: Identifies the administrative or operational region (e.g., country / region) to which the target electricity meter belongs. This field can be used to distinguish different geographical locations and implement regional security policies.

[0043] In some specific implementations, if a regional isolation verification item is configured in the security policy, the target electricity meter will use this field during the multiple pre-verification stage to verify whether its geographical location is within the legitimate distribution range of the new firmware.

[0044] In some specific implementations, this field can be used as a specific field participating in encryption operations (i.e., the input factor of the key derivation function KDF), allowing the same new firmware to use different session keys in different regions, thereby achieving regional isolation.

[0045] (8) Field name: Initialization Vector (IV); Function Description: This 12-byte random initialization vector (IV) is used for encryption authentication algorithms (such as SM4-GCM or AES-GCM). It ensures that even if the same data stream or the same new firmware is encrypted multiple times, the ciphertext will be completely different, thus preventing replay attacks, pattern analysis, or ciphertext collisions. Specifically, this IV, together with the session key SK, is a necessary input for the master station to generate authentication tags and for the target energy meter to decrypt the firmware.

[0046] (9) Field name: Ext Flags field; This includes: context parameter combinations, security policy identifiers, and compression policy identifiers, etc.

[0047] In some implementations, the field is in bitmap format, where each bit or combination of bits has a specific semantic meaning.

[0048] Function Description: Specific fields in the structured header that participate in the cryptographic operation of the KDF can be specified by combining context parameters.

[0049] For example, the context parameter combination can be a Region ID, or it can be a Vendor ID + hardwarePlatform ID, or other combinations.

[0050] The security policy identifier specifies the verification items configured in this security policy to control whether security policies such as Bootloader version verification are enabled.

[0051] The compression strategy identifier specifies the compression strategy used in this new firmware, including the runtime parameters required for the compression algorithm (such as whether compression is enabled, compression algorithm selection, compression runtime parameters, etc.).

[0052] Indicates the existence of other available information / extended fields.

[0053] Specifically, after the target electricity meter receives the upgrade package, its main controller first parses the field in the structured header and dynamically determines the subsequent parsing path and security processing logic accordingly.

[0054] In a preferred embodiment, the process of the main site constructing the structured header is as follows: Based on the target energy meter's attribute information, security policy, and new firmware parameters obtained in the previous step, the main station fills in the structured header fields: ① The upgrade package format version field is set according to the upgrade package structure specification adopted to ensure that the target energy meter can determine whether to continue parsing by comparing this field with the highest version supported locally, thus ensuring format compatibility; ② Enter the new firmware version number of the upgrade package in the new firmware version field; ③ Enter the CRC checksum of the plaintext new firmware in the new firmware checksum field; ④ Enter the minimum bootloader version that supports updating to new firmware in the Bootloader version field; ⑤ Enter the predefined code of the region where the electricity meter of the project is located in the region identifier field; ⑥ The manufacturer identification field should be filled with relevant information about the power company or related organization / enterprise as needed; ⑦ In the Hardware Platform Identifier field, fill in the relevant information of the hardware platform that supports the new firmware update, such as the version of the electricity meter hardware circuit board, the version of the main control chip, the SE version, etc. ⑧ Fill the initialization vector field with random or pseudo-random data to ensure that different ciphertexts are generated when the same new firmware is upgraded multiple times; ⑨ Based on the new firmware parameters and encryption requirements provided by the upper-layer system, the main station fills the corresponding information into the expandable flag field. Some bits are used as compression policy identifiers to indicate compression policy information; some bits are used as security policy identifiers to indicate security policy information; and some bits are used as context parameter combinations to indicate which fields in the structured header need to participate in the energy meter's KDF encryption operation.

[0055] 1-3. Compress the plaintext new firmware to obtain the compressed new firmware.

[0056] The main station compresses the plaintext new firmware according to the preset new firmware compression strategy to reduce the data stream length and transmission time of the final transmission upgrade package, thereby improving transmission efficiency.

[0057] In some specific implementations, the new firmware parameters include both the new firmware version and the new firmware checksum; furthermore, the structured header is constructed based on a pre-configured new firmware compression strategy; and the structured header constructed accordingly includes a compression strategy identifier in the expandable flag field to identify the new firmware compression strategy. Therefore, when the master station compresses the plaintext new firmware, it can directly perform the corresponding compression operation based on the compression strategy identifier in the expandable flag field to obtain the compressed new firmware.

[0058] In some specific embodiments, the new firmware compression strategy specifically includes: (1) Compression enable flag; (2) Compression algorithm type (including but not limited to LZ4, LZMA, Heatshrink, Bsdiff, etc.); (3) Algorithm running parameters (such as LZMA dictionary size, Heatshrink window length, etc.); (4) Expected firmware length after decompression.

[0059] The compression algorithm type should depend on the compression type supported by the current master control program of the target energy meter; the algorithm running parameters depend on the parameter range supported by the current master control program of the target energy meter; and the expected firmware length after decompression should not exceed the maximum length that the current master control program of the target energy meter can process.

[0060] 1-4. Derived session key SK.

[0061] The master station will calculate the session key for this firmware upgrade based on the preset root key RK and the context parameters in the structured header through the key derivation function KDF.

[0062] The session key SK serves as a temporary symmetric key for this firmware upgrade. It is not stored permanently and is independently derived by the master station and the target energy meter during this upgrade process, and they must be completely identical.

[0063] The derivation process of the session key SK is based on the following three elements: (1) Root key RK; The master station and the target electricity meter share a long-term symmetric key, namely the root key RK, in a secure environment.

[0064] In some implementations, the root key RK is issued by a trusted certificate authority. Optionally, the certificate authority is the root certificate authority (Root-CA) or an intermediate certificate authority authorized by the root-CA.

[0065] In some specific implementations, the master station stores the root key RK in a secure environment or system. The target energy meter, on the other hand, injects the root key RK into the secure storage area of ​​the security element SE through a trusted process before leaving the factory (such as during the production or delivery stage) or during the network access stage; the secure storage area cannot be read or exported by the master control firmware.

[0066] (2) Dynamic context parameters; The context parameter consists of specific fields in the structured header, which are specified by the expandable flag field and can be one or a combination of multiple fields.

[0067] In some specific implementations, the specific field may be one of the following fields in the structured header: New firmware checksum (Firmware CRC32); New firmware version; Bootloader version; Vendor ID; Hardware Platform ID; Region ID.

[0068] In some specific implementations, identifiers corresponding one-to-one with each field in the structured header are pre-configured; when configuring context parameter combinations in the expandable flag field, the identifier corresponding to the selected specific field is directly used to represent the configured context parameter combination. Of course, other specification methods can also be selected according to actual needs.

[0069] Preferably, the context parameter combination is composed of the identifiers corresponding to at least two specific fields in the structured header that participate in the KDF operation.

[0070] For example, if the context parameter combination in the extensible flag field is set to 01, it means that the context parameter of the KDF input is "Vendor ID"; if it is 10, it means that the context parameter combination is "Region ID + Hardware Platform ID".

[0071] (3) Key Derivation Function (KDF); The master station and the target energy meter use the same agreed-upon key derivation function KDF.

[0072] In some specific implementations, the input to the key derivation function KDF is: KDF_Input = RK || Context Parameters || [Other Info] Wherein, "||" indicates byte concatenation or a combination of inputs adapted according to the algorithm; Context Parameters indicates context parameters; [Other Info] is optional content and can include fixed labels (such as "FirmwareUpgrade") to indicate its purpose.

[0073] Depending on the different KDF_Inputs, the key derivation function KDF will generate (output) different session keys SK: SK = KDF(KDF_Input).

[0074] The session key SK is of fixed length (e.g., 128 bits or 256 bits) and is used for subsequent authentication encryption.

[0075] 1-5. Generate firmware payload and authentication label.

[0076] The master station uses the session key SK to encrypt the compressed new firmware, generating firmware payload and authentication tag.

[0077] In some specific implementations, the master station uses an authentication-type symmetric encryption algorithm (such as AES-GCM) to encrypt the compressed new firmware, outputting: the encrypted firmware payload (ciphertext) and the authentication tag.

[0078] Here, the firmware payload is stored in encrypted form as compressed new firmware, ensuring the confidentiality of the firmware content during transmission and storage, and preventing plaintext leakage, eavesdropping, and unauthorized acquisition. The authentication tag is used to verify the integrity and authenticity of the encrypted firmware payload, ensuring that the firmware payload has not been tampered with, replaced, or destroyed. Only when the tag verification passes can the decrypted firmware be deemed valid. The combination of these two methods achieves dual protection of firmware data confidentiality and integrity.

[0079] In some specific implementations, if an initialization vector (IV) is configured in the structured header, the master station will use the session key SK and the initialization vector IV together to encrypt the compressed new firmware, generating a firmware payload and an authentication tag. By introducing the initialization vector IV in conjunction with the session key SK, it can be ensured that even if the new firmware content and the session key SK are completely identical, the encryption results (i.e., the firmware payload and authentication tag) will not be repeated, ensuring the randomness and unpredictability of the encryption process and further improving the security of new firmware upgrade transmission.

[0080] 1-6. Generate digital signature.

[0081] The main station uses a pre-set signing private key to digitally sign the structured header and the authentication label together to obtain the corresponding digital signature.

[0082] In some specific implementations, the public and private key pairs involved in the digital signature are issued by a trusted certificate authority, just like the root key; the signing private key is stored in a secure environment or system by the master station; the designing public key is injected into the secure storage area of ​​the security element SE through a trusted process by the target energy meter before it leaves the factory (such as during the production or delivery stage) or during the network access stage. The secure storage area cannot be read or modified by the energy meter master controller.

[0083] In some specific implementations, the master station and the target electricity meter agree to use the same signature algorithm (such as SM2 or ECDSA).

[0084] 1-7. Assemble the upgrade package.

[0085] The master station assembles the structured header, firmware payload, authentication tag, and digital signature to obtain the upgrade package, and then sends it to the target electricity meter.

[0086] In some specific implementations, the master station assembles the complete upgrade package in the order of "structured header → firmware payload → authentication tag → digital signature" and sends it to the target energy meter through the communication channel.

[0087] Phase Two: Energy Meter Verification Upgrade Package.

[0088] like Figure 3 As shown, after the target electricity meter receives the upgrade package from the master station, it will perform the following steps to verify the upgrade package: 2-1. Parse the structured header in the upgrade package and perform multiple pre-verification checks.

[0089] Specifically, the process of multiple pre-verification includes the following steps: (1) Parse the extensible flag field in the structured header and determine the security policy configured for this upgrade based on the security policy identifier therein.

[0090] (2) Parse the other fields in the structured header to obtain the field names and their corresponding field data. For specific field names and their corresponding field data, please refer to the above description of the structured header. This can be understood as the attribute information of the target energy meter and the parameters of the new firmware.

[0091] (3) Perform device compatibility verification based on the analysis results of (1) and (2) above.

[0092] The device compatibility verification includes basic verification items and security verification items.

[0093] The basic verification items include the upgrade package format version, hardware platform type and new firmware version, which correspond to the attribute information and new firmware parameters obtained by parsing (2) above.

[0094] The security verification item is a verification item configured in the security policy, including at least one of Bootloader verification, vendor binding and regional isolation, which corresponds to the security policy obtained by parsing (1) above.

[0095] Preferably, the basic verification items do not include the security verification items to avoid duplicate verification.

[0096] (4) If any verification item in the device compatibility verification fails, the upgrade will be rejected and treated as an upgrade failure. If all verification items in the device compatibility check pass, the device compatibility check is considered passed.

[0097] In some specific implementations, the specific verification process for the device compatibility check is as follows: First, verify the security check items, that is, the check items configured in the security policy: If the security policy includes Bootloader verification, it determines whether the Bootloader version parsed from the structured header is lower than or equal to the local Bootloader version of the electricity meter. If yes, the verification passes; otherwise, the verification fails, and the upgrade is rejected. This prevents the system from failing to start or the security mechanism from malfunctioning due to the electricity meter's Bootloader version being too low and lacking necessary functions (such as secure startup verification and secure element drivers).

[0098] If the security policy includes vendor binding, it checks whether the vendor identifier parsed from the structured header matches the vendor identifier stored locally on the electricity meter. If yes, the verification passes; otherwise, the verification fails, and the upgrade is rejected. This prevents unauthorized vendor firmware from being flashed onto the device, eliminating the risks of mixed flashing, piracy, or malicious replacement.

[0099] If the security policy includes region isolation, it checks whether the region identifier parsed from the structured header matches the region identifier stored locally on the electricity meter. If yes, the verification passes; otherwise, the verification fails, and the upgrade is rejected. This achieves region-level isolation, ensuring the legitimacy of the new firmware distribution range.

[0100] Subsequently, the basic verification items are verified: Determine whether the upgrade package format version parsed from the structured header is higher than the highest version supported by the electricity meter locally; if not, the verification passes; otherwise, the verification fails and the upgrade is rejected.

[0101] Determine whether the hardware platform identifier parsed from the structured header is consistent with the hardware platform identifier stored locally on the electricity meter; if yes, the verification passes; if no, the verification fails and the upgrade is rejected.

[0102] Determine whether the new firmware version parsed from the structured header is higher than the currently used firmware version; if yes, the verification passes; if no, the verification fails and the upgrade is rejected.

[0103] Through the aforementioned multiple pre-verification checks, device compatibility and legitimacy can be quickly determined before signature verification, decryption, authentication, and firmware writing. This proactively intercepts incompatible, unauthorized, or inapplicable upgrade packages, avoiding invalid password calculations and storage resource consumption. This mechanism effectively prevents issues such as cross-vendor flashing, hardware incompatibility causing driver anomalies, and bootloader version errors leading to security startup failures, reducing the risk of device bricking, functional malfunctions, and security vulnerabilities at the source. Furthermore, the multiple pre-verification checks and subsequent security verifications form a layered protection system, improving the efficiency of the upgrade process and strengthening overall security and reliability, ensuring that the electricity meter only accepts legitimate, compatible, and reliable firmware upgrade requests.

[0104] 2-2. Secure element verification of digital signature.

[0105] If the above multiple pre-verifications pass, the digital signature is extracted from the upgrade package and passed to the security element SE, which then verifies the received digital signature based on a preset public key.

[0106] In some specific implementations, the security element (SE) retrieves the public key bound to the master station's identity from the secure storage area; it then performs digital verification on the incoming digital signature using a signature algorithm agreed upon with the master station; if the verification passes, the digital signature is deemed valid; if the verification fails, the digital signature is deemed invalid.

[0107] Here, the Secure Element (SE) only returns the verification result (success or failure) to the master program, without outputting the public key or any intermediate calculated values. The SE only allows subsequent operations (session key derivation and firmware payload authentication and decryption operations) to be performed when the verification result is successful.

[0108] This embodiment uses digital signatures to ensure that the structured header and authentication label in the upgrade package have not been tampered with and that their source is legitimate and trustworthy; thereby preventing attackers from forging or tampering with key information in the upgrade package and safeguarding the trust foundation of the entire firmware upgrade.

[0109] 2-3. Derivation of session key SK from secure element.

[0110] If the digital signature verification passes, the target energy meter first determines the context parameters required by the Key Derivation Function (KDF) based on the Extensible Flags field in the structured header. For example, the context parameters determined by the Extensible Flags field are combined as: Context Parameters = Vendor ID + Region ID, i.e., "vendor identifier + region identifier".

[0111] Secondly, based on the determined combination of context parameters, field data is extracted from the corresponding specific fields in the structured header and passed to the Security Element (SE). For example, the field data corresponding to the "Vendor ID" and "Region ID" fields are extracted and passed to the Security Element (SE).

[0112] Subsequently, the security element SE calculates the session key SK using the same key derivation function KDF as the master station, based on the preset root key RK and the input field data. This session key SK exists only within the security element SE and cannot be known by the main control program of the energy meter.

[0113] In theory, the session key SK derived from the security element SE should be consistent with the session key SK derived from the master station.

[0114] 2-4. Security element (SE) decrypts and authenticates firmware payload.

[0115] The target energy meter extracts the firmware payload and authentication tag from the upgrade package and passes them to the security element (SE). The security element (SE) decrypts the firmware payload and verifies the authentication tag based on the calculated session key (SK). Only when the firmware payload is successfully decrypted and the authentication tag is verified is the decrypted compressed new firmware deemed valid. If the firmware payload fails to decrypt successfully or the authentication tag fails verification, the upgrade is deemed to have failed.

[0116] In some specific implementations, for scenarios where an initialization vector (IV) is used in conjunction with a session key (SK) to generate firmware payload and authentication tag, the target energy meter will also parse the initialization vector IV from the structured header and pass it to the security element (SE) to prepare for subsequent decryption. During actual decryption and authentication, the security element will decrypt the incoming firmware payload and verify the incoming authentication tag based on the incoming initialization vector IV and the calculated session key (SK).

[0117] In some specific implementations, the master control program of the target energy meter will send the firmware payload to the security element SE in blocks; the security element SE will then perform streaming decryption based on the initialization vector IV (if any) and the calculated session key SK, and verify the integrity using the authentication tag after receiving the data.

[0118] Preferably, during the streaming decryption process, the security element SE outputs the decrypted compressed new firmware data to the main control program block by block, and the main control program writes each data block sequentially into a designated area of ​​the non-volatile memory; only when the security element SE finally verifies the authentication tag and sends the corresponding success indication to the main control program will the main control program consider the received compressed new firmware data to be valid.

[0119] 2-5. Obtain the compressed new firmware.

[0120] The embodiments of the present invention are further extended based on the above embodiments, and the subsequent firmware update stage is described in detail.

[0121] Phase 3: Perform firmware update.

[0122] After receiving notification from the safety element (SE) that the compressed new firmware is valid, the main control program of the target energy meter executes a firmware update. The specific steps are as follows: 3-1. The target energy meter specifies the compression strategy based on the compression strategy identifier in the expandable flag field; 3-2. The target energy meter writes the compression strategy data and firmware upgrade flags into a designated area of ​​the non-volatile memory; 3-3. The main control program of the target energy meter triggers a system-level soft reset; 3-4. After reset, the processor starts execution from the Bootloader entry address. The Bootloader reads the firmware upgrade flag from the designated area of ​​the non-volatile memory mentioned above, and then takes over control and performs the decompression operation. 3-5. The Bootloader reads the data of the compression strategy and compares whether its own function supports the decompression operation in the compression strategy. If it supports it, it decompresses the compressed new firmware according to the compression algorithm and compression runtime parameters specified by the compression strategy to obtain the plaintext new firmware and calculate its check value CRC. 3-6. Compare the calculated CRC checksum with the new firmware checksum obtained from parsing the structured header; if they do not match, reject the upgrade; if they match, accept the new firmware. This ensures that the system always runs on a complete and reliable software version.

[0123] 3-7. The Bootloader writes the decompressed plaintext firmware into the predefined application main area in the chip's internal non-volatile memory, clears the upgrade flag, and completes the update.

[0124] Please see Figure 1 Based on the above embodiments, the present invention also provides a firmware security upgrade system for electricity meters.

[0125] The electricity meter firmware security upgrade system provided in this embodiment, such as Figure 1 As shown, the system includes a master station and a target energy meter connected by communication; the target energy meter includes a safety element SE, a main controller, and a communication module (not shown in the figure). The master station is configured to execute the steps performed by the master station in the energy meter firmware security upgrade method described in the above embodiments; The target energy meter is configured to perform the steps executed by the target energy meter in the energy meter firmware security upgrade method described in the above embodiments.

[0126] The specific steps will not be repeated here; please refer to the description in the above embodiments for details.

[0127] Those skilled in the art will understand that all or part of the processes in the above technical solutions can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the methods described above. After being executed by a processor, the program can also achieve the beneficial effects of the corresponding methods.

[0128] The storage medium can be a disk, optical disc, read-only memory (ROM), or random access memory (RAM), etc.

[0129] In summary, the electricity meter firmware security upgrade method and system provided by this invention ensures the integrity and trustworthiness of upgrade metadata through digital signatures, preventing tampering and forgery; authentication encryption based on session key SK ensures the confidentiality and integrity of the compressed new firmware during transmission and storage, resisting man-in-the-middle attacks and replay attacks; CRC verification after decompression serves as the last line of defense to avoid compression or decompression errors, ensuring that only correct new firmware is activated; and the security element SE provides full lifecycle protection for all keys, eliminating the risk of leakage at the source. The solution, through multiple pre-verification checks combined with encryption authentication, digital signatures, and CRC verification, forms an end-to-end closed-loop multi-layer protection system, significantly improving the security, reliability, and operational stability of electricity meter firmware upgrades.

[0130] Although preferred embodiments of the invention have been described, those skilled in the art, upon understanding the basic inventive concept, can make other changes and modifications to the embodiments. Therefore, the appended claims are intended to cover the preferred embodiments and all equivalent modifications falling within the scope of protection defined by the claims and their equivalents. Clearly, those skilled in the art can make various alterations and variations to the invention without departing from its spirit and scope. If such modifications and variations fall within the scope of protection defined by the claims and their equivalents, the invention also intends to include them.

[0131] It should be noted that any reference signs placed between parentheses in the claims should not be construed as limiting the claims. The word "comprising" does not exclude the presence of components or steps not listed in the claims. The word "a" or "an" preceding a component does not exclude the presence of a plurality of such components. The invention can be implemented by means of hardware comprising several different components and by means of a suitably programmed computer. In a unit claim enumerating several means, several of these means may be embodied by the same item of hardware.

[0132] In this invention, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "multiple" means two or more, unless otherwise explicitly specified. The term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone.

[0133] In this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," "linking," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0134] In this specification, the use of terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refers to a specific feature, structure, material, or characteristic described in connection with that embodiment or example, which is included in at least one embodiment or example of the present invention. The illustrative expressions of the above terms in this specification should not be construed as necessarily referring to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0135] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for secure firmware upgrade of an electricity meter, characterized in that, include: The master station constructs a structured header based on the target energy meter's attribute information, security policy, and new firmware parameters. The attribute information includes the upgrade package format version, hardware platform identifier, manufacturer identifier, region identifier, and bootloader version. The security policy includes at least one of manufacturer binding, region isolation, and bootloader verification. The structured header includes the attribute information, the new firmware parameters, and an extensible flag field. The extensible flag field includes a security policy identifier and a combination of context parameters used to identify specific fields in the structured header that participate in encryption operations. The master station calculates the session key based on the preset root key and the context parameters. The main station uses the session key to encrypt the compressed new firmware, generating a firmware payload and an authentication tag; The main station uses the signing private key to digitally sign the structured header and the authentication label together to obtain the corresponding digital signature; The main station assembles the structured header, firmware payload, authentication tag, and digital signature to obtain the upgrade package, and then sends it to the target energy meter. After receiving the upgrade package, the target energy meter parses the structured header in the upgrade package and performs device compatibility verification based on the parsing results, including the security policy. If the device compatibility verification is passed, the digital signature is extracted from the upgrade package and transmitted to the secure element; The secure element verifies the received digital signature based on a pre-set public key; If the digital signature verification is successful, the target energy meter will extract field data from the corresponding specific field in the structured header and pass it to the security element based on the combination of context parameters in the structured header. The security element calculates the session key based on the preset root key and the input field data; The target energy meter will pass the firmware payload and authentication tag extracted from the upgrade package to the security element; The security element decrypts the incoming firmware payload and verifies the incoming authentication tag based on the calculated session key. If the authentication tag passes the verification, the decrypted compressed new firmware is deemed valid.

2. The method for secure firmware upgrade of an electricity meter as described in claim 1, characterized in that, The structured header also includes an initialization vector; The master station uses the session key to encrypt the compressed new firmware, generating a firmware payload and authentication tag, specifically: The master station uses the session key and the initialization vector to encrypt the compressed new firmware and generate firmware payload and authentication tag; The security element, based on the calculated session key, decrypts the incoming firmware payload and verifies the incoming authentication tag, specifically as follows: The target energy meter parses the initialization vector from the structured header and passes it to the safety element; The security element decrypts the incoming firmware payload and verifies the incoming authentication tag based on the incoming initialization vector and the calculated session key.

3. The method for secure firmware upgrade of an electricity meter as described in claim 1, characterized in that, The process of parsing the structured header in the upgrade package and performing device compatibility verification based on the parsing results, including security policies, includes: The extensible flag field in the structured header is parsed, and the configured security policy is determined based on the security policy identifier therein; Parse other fields in the structured header to obtain attribute information and new firmware parameters; Device compatibility verification is performed based on the parsed attribute information and new firmware parameters; the verification items for device compatibility verification include basic verification items and verification items configured in the security policy; the basic verification items include upgrade package format version, hardware platform type, and new firmware version; If any verification item in the device compatibility check fails, the upgrade will be rejected. If all verification items in the device compatibility check pass, the device compatibility check is considered passed.

4. The method for secure firmware upgrade of an energy meter as described in claim 3, characterized in that, The verification process for the basic verification items in the device compatibility verification includes: Determine if the parsed upgrade package format version is higher than the highest version supported locally; if not, the verification passes. Determine whether the parsed hardware platform identifier is consistent with the locally stored hardware platform identifier; if so, the verification passes. Determine if the parsed new firmware version is higher than the currently used firmware version; if so, the verification passes.

5. The method for secure firmware upgrade of an energy meter as described in claim 3, characterized in that, The verification process for the verification items configured in the security policy during the device compatibility verification includes: If the security policy includes Bootloader verification, it determines whether the parsed Bootloader version is lower than or equal to the local Bootloader version. If so, the verification passes. If the security policy is configured with vendor binding, then it is determined whether the parsed vendor identifier is consistent with the vendor identifier stored locally. If so, the verification passes. If the security policy is configured with region isolation, it is determined whether the parsed region identifier is consistent with the locally stored region identifier. If so, the verification passes.

6. The method for secure firmware upgrade of an energy meter as described in claim 1, characterized in that, The master station calculates the session key based on the preset root key and the context parameters, including: The main station extracts field data from the corresponding specific field in the structured header based on the combination of context parameters; Based on the preset root key and the extracted field data, the session key is calculated using a pre-configured encryption algorithm.

7. The method for secure firmware upgrade of an energy meter as described in claim 1 or 6, characterized in that, The context parameter combination is composed of the identifiers corresponding to at least two specific fields in the structured header that participate in the encryption operation.

8. The method for security upgrade of electricity meter firmware as described in claim 1, characterized in that, The new firmware parameters include new firmware verification values; the construction of the structured header also includes a pre-configured new firmware compression strategy. The expandable flag field also includes a compression strategy identifier for identifying the new firmware compression strategy; The security upgrade method further includes: The main station compresses the plaintext new firmware according to the compression strategy identifier in the extensible flag field and obtains the compressed new firmware; After the security element determines that the compressed new firmware obtained by decryption is valid, the target energy meter decompresses the compressed new firmware according to the compression strategy identifier to obtain the plaintext new firmware and calculates the corresponding check value. Determine whether the new firmware checksum obtained by parsing the structured header is consistent with the calculated checksum. If not, reject the upgrade; if so, write the plaintext new firmware into the main area of ​​the application.

9. The method for security upgrade of electricity meter firmware as described in claim 1, characterized in that, Also includes: The root key and the public / private key pair used for digital signatures are issued by a trusted certificate authority. The main station securely stores the root key and the signing private key from the public-private key pair; Before the target electricity meter leaves the factory or during the grid connection phase, the root key and the public key in the public-private key pair are injected into the secure storage area of ​​the security element through a trusted process; the secure storage area restricts access by the master control firmware.

10. A firmware security upgrade system for electricity meters, characterized in that, It includes a master station with a communication connection and a target energy meter; the target energy meter includes a safety element. The master station is configured to perform the steps executed by the master station in the energy meter firmware security upgrade method according to claims 1 to 9 above. The target energy meter is configured to perform the steps executed by the target energy meter in the energy meter firmware security upgrade method according to claims 1 to 9.

Images