Secure element for metrology-type terminals, metrology system

Abstract

The application provides a security element for a metering terminal, a metering system, and adopts an integrated modular architecture design, and through sinking a DLMS protocol security processing function to the inside of the security element, sensitive operations are limited in the security element to realize closed-loop processing, and a complete hardware trusted boundary can be constructed in the collaborative work process of each module. All state data is always limited in the hardware boundary of the security element, completely eliminates the security risk of sensitive data exposure, and enables the security element to realize true hardware-level security protection; the DLMS protocol security processing function originally completed through multiple atomic operation combinations is integrated into a single request-response command implementation mode and sunk to the inside of the security element, greatly reduces the communication interaction overhead between the main control MCU and the security element, and effectively optimizes the processing efficiency; the transmission data in the security element all adopts an encoding rule matched with the DLMS protocol, and protocol compatibility and strong adaptation are realized.

Description

Technical Field

[0001] This invention relates to the field of metering terminal security technology, and in particular to security components and metering systems for metering terminals. Background Technology

[0002] Metering terminals (such as electricity meters, water meters, gas meters, heat meters, distributed energy sources, energy storage, and charging piles) are core nodes for metering and two-way communication in smart energy networks. Their functions extend beyond traditional metering, encompassing critical operations such as rate control, load management, billing, data acquisition, and remote control. The proper functioning of these operations relies on the confidentiality of data transmission, the authenticity of operational instructions, and the integrity of stored data. If the security defenses of metering terminals are breached, it could not only lead to user privacy leaks and economic losses for operating companies, but also threaten the stable operation of the smart energy network.

[0003] Metering terminals, with smart meters as a typical example, generally employ the DLMS / COSEM protocol for communication security. This protocol, developed by the DLMS User Association and later adopted by the IEC as part of the IEC 62056 series of international standards, has become the mainstream standard for communication in metering terminals worldwide. The DLMS protocol defines a complete security mechanism at the application layer, including AES-GCM-based authentication and encryption, ECDH-based key negotiation, digital certificate-based entity authentication, and key update mechanisms.

[0004] To meet the security requirements of the DLMS protocol, current high-end metering terminals generally adopt a hardware architecture of "main control MCU + independent security element SE". As a trusted execution environment, the SE is responsible for storing the root key and providing basic cryptographic operation support. Its internal architecture directly determines the overall security level and operating efficiency of the terminal.

[0005] While existing secure elements (SEs) have achieved high-level security certifications such as EAL4+, their instruction sets are geared towards general cryptographic applications and are not deeply optimized for the DLMS protocol. They cannot directly respond to high-level semantics within the DLMS protocol, such as certificate addition / deletion, session key negotiation, and AES-GCM decryption and integrity verification. This gap between protocol semantics and hardware instructions prevents existing SEs from truly functioning as the primary executor of DLMS protocol security; they can only act as passive cryptographic peripherals. Completing a single DLMS security operation requires the MCU to repeatedly call and assemble SE atomic instructions. This not only results in low processing efficiency but also exposes sensitive intermediate data such as plaintext, key components, and authentication intermediate values ​​to the off-chip bus and insecure MCU memory multiple times, creating serious security vulnerabilities for bus sniffing and cache side-channel attacks.

[0006] To address the shortcomings of existing technologies, this invention provides a security element application architecture that can deeply participate in DLMS protocol processing. This architecture enables the security element (SE) to not only provide cryptographic algorithms but also directly understand and execute protocol-layer security instructions. By bringing the DLMS protocol security processing logic down to the hardware trusted boundary, the security capabilities and operational efficiency of metering terminals (typically smart energy meters) are fundamentally improved. Summary of the Invention

[0007] The technical problem to be solved by the present invention is to provide a safety element and metering system for metering terminals, so as to significantly improve the safety and operating efficiency of metering terminals.

[0008] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: The security components for metering terminals include a communication interface module at the physical layer, a protocol processing module at the link layer, and an encryption algorithm module, a DLMS protocol security processing module, a key certificate management module, a data security storage module, and a management module at the application layer. The communication interface module is connected to the main control MCU of the metering terminal via a serial communication protocol. The main control MCU of the metering terminal is used to assemble a request frame according to a first preset frame format and send it to the communication interface module. The first preset frame format includes a function command field, a request description field corresponding to the request frame, and a response description field corresponding to the response frame. The function command field includes a function class and a function subclass. The function class is used to indicate the target application layer module to be called, and the function subclass is used to indicate the specific function to be executed by the target application layer module. The communication interface module is used to receive a request frame sent by the main control MCU of the metering terminal and send it to the link layer; and to receive a response frame sent by the link layer and send the response frame to the main control MCU of the metering terminal according to the current serial communication protocol specification. The protocol processing module is used to parse the request frame sent by the communication interface module, determine the target application layer module based on the function class and function subclass in the parsed function instruction field Command, and send the application layer payload data in the parsed request description field Request Description, together with the function subclass, to the target application layer module; and after receiving the processing result returned by the target application layer data, assemble a response frame according to the first preset frame format and send it to the communication interface module. The target application layer module is used to perform corresponding processing based on the application layer load data and the functional subclass SubClass, and then return the processing result to the protocol processing module.

[0009] Optionally, the communication interface module includes an I²C bus interface and a register; the register defines three logical areas: an instruction writing area, a status feedback area, and a data reading area; When the communication interface module enables the I²C bus interface to connect with the main control MCU: The main control MCU of the metering terminal is used to perform I²C write operation to write the request frame into the instruction write area; then, it polls and performs I²C read operation to read status information from the status feedback area for parsing; and when the parsing result of the status information is ready, it performs I²C read operation to read the response frame from the data read area. The communication interface module is used to detect the request frame written to the instruction writing area, obtain the request frame, and write the response frame to the status feedback area after receiving the response frame.

[0010] Optionally, the communication interface module includes a UART interface; when the communication interface module enables the UART interface to connect with the main control MCU: The main control MCU of the metering terminal is used to send request frames to the communication interface module according to the UART serial communication parameters specified by the DLMS protocol. The communication interface module is used to send the response frame to the main control MCU of the metering terminal according to the UART serial port communication parameters.

[0011] Optionally, the data transmitted between the physical layer and the link layer is assembled according to a second preset frame format; the second preset frame format includes a frame data field Frame, a frame data length field FrameLen, a source module field Src, and a destination module field Dst. When the data is transmitted from the physical layer to the link layer, the communication interface module is further configured to receive the request frame, assemble it into a link layer data frame according to the second preset frame format, and then send it to the protocol processing module; the frame data field Frame in the link layer data frame records the request frame, the source module field Src records the identifier of the communication interface module, and the target module field Dst records the identifier of the protocol processing module. The protocol processing module is further configured to, after receiving the link layer data frame, verify the source module field Src and the target module field Dst therein; if the verification passes, parse the request frame recorded in the frame data field Frame therein; When the data is transmitted from the link layer to the physical layer, the protocol processing module is further configured to assemble the response frame into a physical layer data frame according to the second preset frame format and then send it to the communication interface module; the frame data field Frame in the physical layer data frame records the response frame, the source module field Src records the identifier of the protocol processing module, and the target module field Dst records the identifier of the communication interface module. The communication interface module is also used to receive the physical layer data frame and verify the source module field Src and the target module field Dst therein; if the verification passes, it is sent to the main control MCU of the metering terminal.

[0012] Optionally, the data transmitted between the link layer and the application layer is assembled according to a third preset frame format; the third preset frame format includes the application layer payload field APUD, the payload length field Len, the source module field Src, the target module field Dst, and the functional subclass SubClass; When the data is transmitted from the link layer to the application layer, the protocol processing module is further configured to assemble the parsing result of the request frame into an application layer data frame according to a third preset frame format and then send it to the target application layer module; the application layer payload field APUD in the application layer data frame records the application layer payload data in the request description field Request Description, the source module field Src records the identifier of the protocol processing module, and the target module field Dst records the identifier of the target application layer module; The target application layer module is also used to receive the application layer data frame and then verify the source module field Src, the target module field Dst, and the functional subclass SubClass. If all verifications pass, the application layer payload field APUD in the application layer data frame is parsed. When the data is transmitted from the application layer to the link layer, the target application layer module is further configured to assemble the processing result into a link layer data frame according to a third preset frame format and then send it to the protocol processing module; the application layer payload field APUD in the link layer data frame records the application layer payload data in the response description field Response Description, the source module field Src records the identifier of the target application layer module, and the target module field Dst records the identifier of the protocol processing module; The protocol processing module is further configured to receive the link layer data frame and verify the source module field Src and the target module field Dst therein; if the verification passes, a response frame is assembled based on the application layer payload field APUD therein.

[0013] Optionally, the first preset frame format further includes a processing result field Result corresponding to the response frame; the third preset frame format further includes a frame type field Type and a processing result field Result; the frame type field Type includes a request flag for the corresponding application layer data frame and a response flag for the corresponding link layer data frame; When data is transmitted from the link layer to the application layer, the target application layer module is specifically used to receive the application layer data frame and then verify the frame type field Type, function subclass SubClass, source module field Src, and target module field Dst respectively. If any one of the verifications fails, a processing failure and an empty response description field Response Description are generated. If all verifications pass, the application layer payload field APUD in the application layer data frame is parsed to generate the corresponding processing result.

[0014] Optionally, the first preset frame format specifically includes: a frame start flag field STP, an identifier field Identifier field, a frame length field Length field, a function instruction field Command field Command field Result field Result field Request Description field Request Description field Response Description field Response Description field and a checksum field CRC field; wherein, the identifier field Identifier field includes version number, transmission direction, priority and frame sequence number; Both the Request Description field and the ResponseDescription field use A-XDR encoding.

[0015] Optionally, the encryption algorithm module, DLMS protocol security processing module, key certificate management module, data security storage module, and management module located in the application layer each maintain an independent calling rule table; the calling rule table records the supported functional subclasses and their corresponding callable module identifiers.

[0016] Optionally, the encryption algorithm module is used to implement various cryptographic algorithms and generate the required random numbers using a true random number generator; The DLMS protocol security processing module is used to process the composite security functions of the DLMS protocol, which include at least two of DLMS HLS authentication, DLMS data frame encryption and decryption, and key encapsulation transmission. The key certificate management module, as the security root of trust for the security element, is responsible for the full lifecycle management of keys and certificates; the keys include factory-preset keys and dynamically generated keys at runtime. The data security storage module, as a physically protected security key store, is used to store the keys and certificates, and automatically performs encryption, decryption and integrity verification when reading and writing the keys and certificates; The management module is equipped with functions such as security element status query, self-test, initialization parameters, and reset.

[0017] Another technical solution provided by this invention is: A metering system includes a metering terminal; the metering terminal is equipped with the aforementioned safety element.

[0018] The beneficial effects of this invention are as follows: The security element of this invention adopts an integrated modular architecture design. By sinking the DLMS protocol security processing function into the security element SE, and confining it along with various sensitive operations within the security element SE to achieve closed-loop processing, a complete hardware trust boundary can be built during the collaborative work of various modules. First, all state data is always confined within the hardware boundary of the security element SE, completely eliminating the security risks of sensitive data being exposed to the external bus and the main control MCU memory, enabling the security element SE to achieve true hardware-level security protection. Second, the DLMS protocol security processing function, which originally required multiple atomic operations, is integrated into a single request-response command implementation method and sinked into the security element SE, significantly reducing the communication overhead between the main control MCU and the security element SE, and effectively optimizing processing efficiency. Third, the data transmitted within the security element SE adopts encoding rules that match the DLMS protocol, making it naturally compatible with the common protocols of metering terminals, achieving protocol compatibility and strong adaptability. Attached Figure Description

[0019] Figure 1 A schematic diagram of the architecture of a security element for metering terminals provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the communication process when the communication interface module of the safety element SE in a specific embodiment of the present invention enables the I²C bus interface to connect with the main control MCU; Figure 3 (a)-(b) are schematic diagrams of the frame formats of the request frame and the response frame according to specific embodiments of the present invention; Figure 4 This is a flowchart illustrating an interaction method between a safety element (SE) and a main control MCU for a metering terminal, as provided in an embodiment of the present invention. Detailed Implementation

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

[0021] Explanation of technical terms involved in this invention: DLMS / COSEM protocol: This is a globally recognized application-layer communication standard in the field of public utility metering, corresponding to the IEC 62056 international standard. It is used for data interaction between metering terminals and master stations / devices. It defines a unified data model, message format, and security mechanism, supporting security capabilities such as encryption, authentication, key negotiation, and certificate management. It is widely used in metering terminals such as electricity meters, water meters, gas meters, heat meters, charging piles, and energy storage terminals.

[0022] DLMS Protocol Security Processing: This refers to the entire process of secure communication for metering terminals based on the DLMS / COSEM standard. It includes complex security operations such as DLMS message encryption and decryption, HLS advanced security authentication, ECDH key negotiation, certificate management, key transmission and update, AES-GCM authentication encryption and decryption, and integrity verification. It is the core mechanism to ensure the confidentiality, authenticity, and integrity of metering terminal data.

[0023] A Secure Element (SE) is an independent chip that features physical attack protection, a hardware encryption engine, secure storage, and a trusted execution environment. It securely stores keys and sensitive data, performs cryptographic operations such as encryption, decryption, signing, signature verification, and key management. All sensitive operations and data are completed within the trusted hardware boundary, preventing external access to the plaintext keys. It serves as the core root of trust for terminal hardware security.

[0024] A-XDR encoding is a data encoding method defined by the DLMS / COSEM standard. Its basic format follows the "Type-Length-Value" (TLV) structure, but the specific tags and encoding details are specified by the DLMS standard. It relies on the preset protocol specification to omit redundant type and length fields, adopts big-endian byte arrangement and forced byte alignment, and has a very simple structure and high parsing efficiency. It is designed for low-overhead transmission in embedded systems and carrier communication.

[0025] Please see Figure 1 This invention provides a security element (SE) for metering terminals.

[0026] This invention provides a security element (SE) for metering terminals, which adopts an integrated modular architecture design. For example... Figure 1 As shown, it specifically includes: a communication interface module at the physical layer, a protocol processing module at the link layer, and an encryption algorithm module, a DLMS protocol security processing module, a key certificate management module, a data security storage module, and a management module at the application layer.

[0027] First, define the core functions of each module within the safety element (SE).

[0028] In each application module located in the application layer, (1) the encryption algorithm module is used to implement various cryptographic algorithms (including but not limited to AES, ECC, RSA, SHA, etc.) in hardware and generate the required random numbers through a true random number generator, so as to provide high-performance cryptographic operation support for various security operations of the security element SE.

[0029] (2) The DLMS protocol security processing module is used to process the composite security functions of the DLMS protocol. The composite security functions include, but are not limited to, complex functions such as DLMS HLS (High Level Security) authentication, DLMS data frame encryption / decryption and key encapsulation transmission; it can encapsulate these complex security functions into a single execution process to realize the semantic sinking of the DLMS protocol.

[0030] (3) The key certificate management module, as the security root of the security element SE, is responsible for the full lifecycle management of keys and certificates; the keys include factory-preset keys and dynamically generated keys at runtime (including session keys generated by session negotiation); these keys and certificates are stored and used inside the security element SE and never leave the hardware boundary of the security element SE.

[0031] (4) The data security storage module, as a physically protected security key store, is used to store all sensitive information such as keys and certificates, and automatically performs encryption, decryption and integrity verification when reading and writing this sensitive information; (5) The management module is responsible for functions such as querying the status of the safety element (SE), self-testing, initializing parameters, and resetting.

[0032] The protocol processing module (6) located in the link layer is used to parse / organize link layer data, coordinate the work of each module in the security element (SE), and is responsible for command distribution, exception handling, etc.

[0033] The communication interface module (7) located in the physical layer is equipped with a serial communication interface with an I²C bus interface and / or a UART interface; it is connected to the main control MCU of the metering terminal through a serial communication protocol to complete the sending and receiving and verification of physical layer byte streams.

[0034] Specifically, in this embodiment, when the safety element SE communicates and interacts with the main control MCU of the metering terminal, the specific functions of each module are as follows: The main control MCU of the metering terminal is used to assemble a request frame according to a first preset frame format and send it to the communication interface module. The first preset frame format includes a function command field (Command), a request description field (Request Description) for the corresponding request frame, and a response description field (Response Description) for the corresponding response frame. The function command field (Command) includes a function class (Class) and a function subclass (SubClass). The function class (Class) is used to indicate the target application layer module to be invoked, and the function subclass (SubClass) is used to indicate the specific function to be executed by the target application layer module.

[0035] The communication interface module is used to receive a request frame sent by the main control MCU of the metering terminal and then send it to the protocol processing module of the link layer; and to receive a response frame sent by the protocol processing module of the link layer and then send the response frame to the main control MCU of the metering terminal according to the currently enabled serial communication protocol specification. The protocol processing module is used to parse the request frame sent by the communication interface module, determine the target application layer module based on the function class and function subclass in the parsed function instruction field Command, and send the application layer payload data in the parsed request description field Request Description, together with the function subclass, to the target application layer module; and after receiving the processing result returned by the target application layer data, assemble a response frame according to the first preset frame format and send it to the communication interface module. The target application layer module is used to perform corresponding processing based on the application layer payload data and the functional subclass, and then return the processing result to the protocol processing module. The target application layer module is one of the encryption algorithm module, the DLMS protocol security processing module, the key certificate management module, the data security storage module, and the management module.

[0036] Secondly, the security element (SE) is defined to use a layered communication protocol.

[0037] By dividing the layered communication protocol of the Security Element (SE) into three layers—Physical Layer (serial communication interface), Link Layer (request / response frames), and Application Layer (functional classification and command set)—standardized interaction between the SE and the main control MCU is achieved. The following will provide a detailed explanation of each layer's communication protocol: (I) Communication Protocols at the Physical Layer The physical layer defines the physical electrical connection method, signal transmission rules, and basic read / write methods between the safety element (SE) and the main control MCU. Depending on hardware compatibility, the physical layer can support I²C bus interface connections and UART serial port connections. That is, the communication interface module of the safety element (SE) can be selectively configured with either an I²C bus interface or a UART interface, or both simultaneously.

[0038] When the Secure Element (SE) receives data, the communication interface module parses and verifies the physical layer data frames sent by the SE, assembles them into link layer data frames, and delivers them to the protocol processing module located at the link layer. When the SE sends data, the communication interface module transmits the received link layer data to the main control MCU in byte stream format through the corresponding serial communication interface according to the currently enabled physical layer serial communication protocol (I²C or UART) specification.

[0039] In some specific implementations, the device address of the security element (SE) is defined as 0xA0. Preferably, when sending the address, the high-order address bits are sent first, followed by the low-order address bits.

[0040] In some specific embodiments, the communication interface module includes an I²C bus interface and registers.

[0041] The register is defined with three key logical areas: instruction writing area, status feedback area, and data reading area.

[0042] For example, the three key logic regions are accessed through corresponding register addresses, and the specific mapping is shown in Table 1 below.

[0043] Table 1

[0044] When the communication interface module of the safety element SE enables the I²C bus interface to connect with the master control MCU, the master control MCU acts as the master and the safety element SE acts as the slave. All requests are initiated by the master control MCU and responded to by the safety element SE.

[0045] In this specific implementation, the communication interface module and the main control MCU interact using a three-step polling communication mechanism: 1. From the module function level, the main control MCU of the metering terminal is used to perform I²C write operation to write the request frame into the instruction write area; then, it polls and performs I²C read operation to read status information from the status feedback area for parsing; and when the parsing result of the status information is ready, it performs I²C read operation to read the response frame from the data read area.

[0046] The communication interface module is used to detect the request frame written to the instruction writing area, obtain the request frame, and write the response frame to the status feedback area after receiving the response frame.

[0047] 2. From the perspective of communication process, such as Figure 2 As shown, a request-response interaction process between the main control MCU and the communication interface module includes: First, the execution request is issued: the main control MCU performs an I²C write operation, continuously or all at once writing the encapsulated link layer request frame into the instruction writing area (register address 0x0000) of the security element SE; after the writing is completed, the internal state machine of the security element SE starts, begins to parse and execute the task, and the main control MCU waits for the SE to execute the task; Subsequently, status polling is performed: the main control MCU performs an I²C read operation, reading 4 bytes of status information from the status feedback area (register address 0x0A00) of the security element SE, and then parses the data. For example, the status information parsing process is as follows: ① Calculate the CRC16 of the first 2 bytes (status value) in the status information and compare it with the check value of the last 2 bytes to ensure the integrity of the status information; ② When the CRC16 check fails, the main control MCU will re-initiate the status query and record the number of retries. If the number of consecutive retries in the same communication process exceeds a preset threshold, the communication is determined to be abnormal, and the current communication service will be terminated immediately. ③ When the CRC16 check is successful, parse the first 2 bytes (status value) of the status information: If the value is 0x0000, it indicates that there is no response data, communication ends, and the request can be resent. If the value is 0x0001, it means that the safety element SE is busy and you need to wait and try again. If the value is L, it indicates that the response data length is L bytes and the status is "ready"; ④ When the status is "Ready", the main control MCU performs an I²C read operation, continuously or in one go reading L bytes from the data read area (register address 0x1000) to obtain a complete link layer response frame. After the read is completed, the security element SE automatically returns to the idle state, ready to receive the next instruction.

[0048] In some other embodiments, the communication interface module includes a UART interface.

[0049] When the communication interface module of the safety element SE enables the UART interface to connect with the main control MCU, all requests are initiated by the main control MCU and responded to by the safety element SE.

[0050] In this specific implementation, the communication interface module and the main control MCU interact using a question-and-answer communication mechanism: 1. From the module function level, the main control MCU of the metering terminal is used to send request frames to the communication interface module according to the UART serial communication parameters specified by the DLMS protocol.

[0051] The communication interface module is used to send the response frame to the main control MCU of the metering terminal according to the UART serial port communication parameters.

[0052] 2. From a communication process perspective, a request-response interaction process between the main control MCU and the communication interface module includes: The main control MCU sends the encapsulated link layer request frame to the secure element SE with pre-specified UART serial communication parameters; among which, the UART serial communication parameters include, but are not limited to: baud rate, data bits, parity bits, stop bits, etc.

[0053] The communication interface module of the safety element (SE) receives the link layer request frame sent by the main control MCU, processes it, and then returns the corresponding response frame with the same UART serial communication parameters.

[0054] In some preferred embodiments, the communication interface module of the safety element SE is configured with both the I²C bus interface and the UART interface described above as serial communication interfaces. Optionally, which interface is specifically used to communicate with the main control MCU can be selected during the power-on reset phase through specific configuration pin levels of the safety element SE, or software switching between different serial communication interfaces can be achieved through preset specific initialization instructions.

[0055] (II) Communication Protocols at the Link Layer The link layer communication protocol defines the encapsulation method for application function instructions between the Security Element (SE) and the main control MCU. Specifically, it is divided into two types of link layer data frames: Request frames and Response frames. By fixing the frame format of these two types of link layer data frames, functions such as frame version, transmission direction, and data validity verification are indicated to ensure the correct encapsulation and parsing of data packets.

[0056] In this embodiment, the request frame and the response frame are assembled according to a first preset frame format. The request frame is organized by the main control MCU and sent to the security element SE; the response frame is organized by the security element SE and returned to the main control MCU.

[0057] 1. From the module functional level, the protocol processing module is used to parse the request frame sent by the communication interface module (i.e., the physical layer), determine the target application layer module based on the functional class Class and functional subclass SubClass in the function instruction field Command obtained by parsing the request frame, and send the application layer payload data in the request description field RequestDescription obtained by parsing the request frame, together with the functional subclass SubClass, to the target application layer module; and after receiving the processing result returned by the target application layer data, assemble a response frame according to the first preset frame format and send it to the communication interface module.

[0058] 2. From a communication process perspective, when the Secure Element (SE) receives data, the Request frame sent from the Physical Layer reaches the Link Layer. The Protocol Processing Module determines the target Application Layer module based on the Class value in the Command field. It then routes the application layer payload data from the Request Description field, along with the SubClass, to the target Application Layer module, allowing the module to further parse and process the payload data according to the SubClass. When the SE sends data, the processing result returned by the target Application Layer module reaches the Link Layer. The Protocol Processing Module assembles this result into a Response frame according to a first preset frame format and sends it to the Physical Layer (specifically, to the communication interface module).

[0059] In some specific implementations, the frame format of the request frame is as follows: Figure 3 The format of the (a) request frame is shown in the figure; the format of the response frame is shown in the figure. Figure 3 The format of the response frame (b) is shown in Table 2 below. The descriptions of each field in the first preset frame format are as follows.

[0060] Table 2

[0061]

[0062] (III) Application Layer Communication Protocols The application layer communication protocol uses a two-level structure of functional classes (Class) and functional subclasses (SubClass) to encode functional instructions, thus distinguishing each instruction and achieving modular organization and efficient addressing. This two-level structure design has good scalability: if new functions need to be added in the future, only the definition of a new functional subclass (SubClass) needs to be added under the corresponding functional class (Class), or a new functional class (Class) number needs to be added, without modifying the underlying link layer and physical layer protocols.

[0063] In some specific implementations, five functional categories (Class) and corresponding functional subclasses (SubClass) are predefined in the Command field of the aforementioned link layer request frame (Request).

[0064] For example, the functional categories include the five categories shown in Table 3 below.

[0065] Table 3

[0066] Each major functional class (Class) consists of several smaller functional instructions, denoted as subclasses (SubClass). A major functional class (Class) and a subclass (SubClass) together form an instruction that executes a specific function by the target application layer module. In practical applications, it can be expanded as needed. Adding a new subclass instruction only requires assigning a new SubClass number, and adding a major functional instruction only requires assigning a new Class number, without affecting the existing protocol framework.

[0067] For example, taking Class 1 (DLMS security processing) in Table 3 above as an example, it can contain the following sub-function instructions, each sub-function instruction corresponding to a subclass: DLMS Message Decryption (SubClass 1): The ciphertext, security policy, client system title, and frame counter from the DLMS message are transmitted to the SE in a single, specially encoded manner. The SE then uses a pre-stored key to select the appropriate decryption method based on the security policy requirements, completes the decryption verification, and returns the actual plaintext DLMS message. The definition of instructions for other functional classes is similar and will not be elaborated upon here.

[0068] Preferably, to support the complete security functions of the security element (SE), the following functional instructions are defined for each functional module in the application layer. It is understood that in actual product development, the instruction set can be added, deleted, and adapted according to actual application requirements, and the instruction numbers of the functional subclasses (SubClasses) can also be flexibly assigned and defined.

[0069] (1) The following functional subclasses can be configured under the Class 0 encryption algorithm: ECDSASignature—ECDSA digital signature, used to complete functions such as signing ctos parameters when the DLMS security policy is HLS7; ECDSAVerify – ECDSA Digital Verification; ECCGenKeyPair — Generates an ECC key pair (private key + public key); AES Encryption — AES encryption; AESDecryption — AES decryption; AES-GCMEncryption — AES-GCM certified encryption, returns ciphertext and certification tag; AES-GCM Decryption — Decrypts and verifies integrity using AES-GCM; MD5 — MD5 hash operation; SHA1 / 256 / 384 - SHA-1 / SHA-256 / SHA-384 hash calculation; AESWrap—AES key wrapper used for sharing keys; AESUnwrap — Unpacking AES keys.

[0070] (2) The following functional subclasses can be configured under Class 1 DLMS security processing: DLMSEncryptProcess—DLMS message encryption processing, assembling and encrypting APDU according to security policies; DLMSDecryptProcess — DLMS message decryption processing; HLSAuthentication—High-level security authentication (such as HLS5 / 6 / 7) completes the authentication process; KeyTransfer—Secure key transmission, used by the master station to distribute encryption keys; KeyAgreement — Session key negotiation; GenerateKeyPair — Generates a temporary key pair for key negotiation; GenerateCertificateRequest — Generates a Certificate Request (CSR); GetCertificatesMessage—Retrieves current certificate information; (3) The following functional subclasses can be configured under Class 2 key / certificate management: SetKey — Import symmetric key; GetKey—Retrieves the symmetric key. This command is not publicly available and can only be called in a limited manner between application layer modules. KeyUpdate — Updates existing key data; GetPrivateKey—Retrieves the private key. This command is not publicly accessible and can only be called in a limited manner between application layer modules. GetPublicKey—Retrieves the public key of a specified certificate or entity; DeleteKey — Deletes the specified key based on the client ID and key type; DeleteAllKey — Batch delete all keys; ImportKeyPair — Imports asymmetric key pairs; ImportPublicCertificate — Import public key certificate; ExportPublicCertificate — Export public key certificate; DeletePublicCertificate — Delete the certificate.

[0071] (4) The following functional subclasses can be configured under Class 3 data security storage: WriteSecureData — Writes data to the secure storage area; ReadSecureData — Reads data from secure storage; GetSecureAreaSize — Gets the total capacity and remaining space of the secure storage area.

[0072] (5) The following functional subclasses can be configured under Class 4 chip management: GetFirmwareVersion — Gets the chip firmware version number; ChipHotReset—a soft reset chip that does not lose key data; ResetToDefaultParameter — Restores the chip to factory settings; GetChipStatus — Gets the current status of the chip (such as busy / idle, error flag); FirmwareUpdate—a chip firmware upgrade—requires a high-security authentication command for signing.

[0073] In this embodiment, the Security Element (SE) encapsulates the DLMS protocol security processing functions, which originally required multiple atomic operations to complete in the DLMS protocol layer, into a single application layer command and pushes them into the Security Element (SE). This allows various sensitive operations to be confined within the Security Element (SE) to achieve closed-loop processing. It can build a complete hardware trust boundary during the collaborative operation of various modules, effectively avoiding the risk of leakage of sensitive intermediate data from the architectural level.

[0074] Another embodiment of the present invention is a further extension based on the above embodiments.

[0075] This embodiment provides a Security Element (SE) for metering terminals. All request and response data for its commands adopt the A-XDR encoding rules consistent with the DLMS protocol standard, particularly the Request Description and Response Description fields. This ensures that the data exchange format between the main control MCU and the SE is naturally compatible with the DLMS protocol stack. The main control MCU does not need to learn or convert to a new encoding format and can directly reuse its inherent A-XDR processing capabilities.

[0076] A-XDR is a data encoding method defined by the DLMS / COSEM standard. In this embodiment, the application layer of the Security Element (SE) fully reuses the A-XDR encoding of the DLMS standard, ensuring that the data encoding format between the main control MCU and the Security Element SE, as well as the data encoding format for network transmission, remains consistent, effectively eliminating cross-end encoding / decoding conversion overhead. While maintaining complete consistency between the A-XDR encoding rules (TLV structure, data type definition) and the DLMS standard, this embodiment can flexibly construct data structures adapted to specific functional instruction transmissions according to actual application needs, balancing the standard compatibility of core business data with the accuracy of instruction data transmission. The main control MCU is responsible for business logic parsing and parameter packet assembly, while the Security Element SE is uniformly responsible for the secure processing of all sensitive data.

[0077] To illustrate the construction of application layer function instructions and the application of A-XDR encoding, the following section will use the DLMS message decryption function as an example to explain the typical definitions of request and response frame parameters.

[0078] The function instruction corresponding to the DLMS message decryption function belongs to the function subclass 1 (DLMS message decryption) under the function class 1 (DLMS security processing), and is used to decrypt and verify the encrypted DLMS APDU.

[0079] For example, the data structure encoding definitions for the Request Description field and the Response Description field used to implement the above functional instructions are shown in Table 4 below.

[0080] Table 4

[0081] Please see Figure 4 Another embodiment of the present invention is a further extension based on any of the above embodiments.

[0082] This embodiment provides a method for interaction between the safety element (SE) and the main control MCU in metering terminals.

[0083] The following example will be used to illustrate the application scenario of implementing DLMS secure communication in a typical electricity meter. Figure 4 A detailed explanation of the complete data processing flow between the internal safety element (SE) and the main control MCU of the metering terminal is provided: Stp1: The main MCU organizes the local context and issues a decryption request.

[0084] Specifically, it includes the following sub-steps: 1-1. The electricity meter receives encrypted DLMS APDU from the external network (this data is ciphertext, and its internal structure is unreadable before decryption). 1-2. The local context parameters (such as frame counter, security policy, client title, etc.) required for decryption, which are maintained internally by the energy meter, are stored in the security element SE. 1-3. The main control MCU constructs a request frame according to the link layer communication protocol in the aforementioned embodiment. In the request frame, the "Direction indicator" in the Identifier field is 1, indicating a request. The function class in the Command field is 1, and the function subclass is 1, indicating that it is desired to call the DLMS message decryption function of the DLMS protocol security processing module in the security element SE. 1-4. The main control MCU obtains the context parameters required for decryption from the local machine, and assembles the context parameters and ciphertext parameters into the Request Description field of the Request frame using A-XDR encoding; 1-5. Based on the actual requirements, the main control MCU completes the information of the remaining fields (such as Length, CRC, etc.) on the basis of the coded content above, and sends the completed link layer request frame Request to the security element SE.

[0085] Stp2: The Security Element (SE) receives the Link Layer Request frame and completes its decryption.

[0086] Specifically, it includes the following sub-steps: 2-1. The communication interface module inside the security element (SE) receives physical layer I²C interface data and strips out the link layer payload data, delivering it to the protocol processing module located at the link layer. 2-2. The protocol processing module verifies the validity of each field and parses out the contents of the Command field and the Request Description field; 2-3. Based on the values ​​of the major function class (Class) and subclass (SubClass) in the Command field, determine which content of the Request Description field will be delivered to the DLMS protocol security processing module in the application layer; 2-4. The DLMS protocol security processing module determines the encryption method of the ciphertext based on the security policy in the input parameters and starts the corresponding decryption process. The entire processing process runs in a closed loop within the chip hardware security boundary. The decrypted plaintext APDU (in readable A-XDR format at this time) and the encryption service type are returned to the protocol processing module as the processing result. 2-5. The protocol processing module of the link layer encapsulates the received processing result to obtain the response frame; and returns it to the main control MCU through the physical layer I²C interface of the communication interface module.

[0087] During this process, the main control MCU is only responsible for parameter combination and data forwarding. All sensitive operations (including decryption, verification, etc.) are completed inside the security element SE. The intermediate sensitive data (including decryption intermediate values, GMAC intermediate hashes, decryption keys, etc.) never leave the security element SE chip, which can completely block the leakage of sensitive data at the physical layer and software layer from the root.

[0088] Stp3: The main control MCU processes the response frame.

[0089] Specifically, it includes the following sub-steps: 3-1. The main control MCU receives the response frame Response returned by the safety element SE, and the content of the Response Description field is already in A-XDR encoding format conforming to the DLMS standard; 3-2. The main control MCU directly parses the plaintext APDU using its own DLMS protocol stack to obtain the specific service requests from the host computer (such as reading power consumption, updating rates, etc.) without any format conversion.

[0090] Stp4: The main control MCU calls the safety element SE again as needed to perform subsequent safety operations.

[0091] Specifically, it includes the following sub-steps: 4-1. Based on the parsing results of the plaintext APDU, the main control MCU may need to perform new security operations. For example: If it is necessary to obtain the firmware version number of the encryption chip, then call the encryption chip firmware version number reading instruction with Class 4. If a specific public key is still required, the public key retrieval instruction of Class 2 is invoked.

[0092] 4-2. Regardless of which function needs to be called again, the main control MCU will encode the required parameters (which may come from plaintext parsing results, local storage, or data previously returned by the secure element SE) in A-XDR, assemble them into a request frame according to the specified first preset frame format, and send them to the secure element SE for execution again.

[0093] 4-3. Finally, the main control MCU will call the DLMS message encryption instruction to encrypt the organized DLMS application layer data after A-XDR encoding into the specified ciphertext according to the security policy and encryption service type, construct the DLMS APDU and return it to the external network.

[0094] Another embodiment of the present invention further extends any of the above embodiments, and provides a detailed description of the data interaction method between the physical layer, the data link layer, and the application layer.

[0095] This embodiment provides a security element (SE) for metering terminals. Within its layered model, data interaction will follow the following rules: The physical layer module only interacts with the link layer module, and the interaction data is assembled according to the second preset frame format; the link layer module can interact with the physical layer module and the application layer module, and the interaction data is assembled according to the third preset frame format; the application layer modules interact with each other at the functional level according to the instruction processing flow, without being constrained by the physical layer and the link layer, and will not directly interact with the physical layer module.

[0096] The following section will provide a detailed explanation of the data interaction methods between different layers: (1) Data interaction between physical layer and data link layer The interactive data between the physical layer communication interface module and the link layer protocol processing module is assembled according to the second preset frame format. The frame parameters included in the second preset frame format are shown in Table 5 below.

[0097] Table 5

[0098] For example, the identifiers for each module are defined as shown in Table 6 below.

[0099] Table 6

[0100] 1) Physical layer → Data link layer: The communication interface module is used to receive the request frame sent by the main control MCU, assemble it into a link layer data frame according to the second preset frame format, and then send it to the protocol processing module; the frame data field Frame in the link layer data frame records the request frame, the source module field Src records the identifier of the communication interface module, and the target module field Dst records the identifier of the protocol processing module. The protocol processing module is used to receive the link layer data frame and verify whether the source module field Src and the target module field Dst match (i.e., Src is the communication interface module and Dst is itself). If the verification fails, the frame is discarded. If the verification passes, the CRC16 (CRC16 of the link layer data frame) is further verified, and the validity of its STP field (0xE7), Identifier, and other fields is checked. If any parameter verification fails, an error is determined. If all verifications pass, the request frame recorded in the Frame data field is further parsed.

[0101] In some specific implementations, if the data sent from the physical layer to the link layer is determined to be erroneous by the link layer, the link layer will reply with an error to the physical layer. Specifically, the protocol processing module is further configured to construct an error response frame according to a first preset frame format, set the content of the processing result field Result to the corresponding error code, fill the function instruction field Command and the identifier field Identifier according to the request frame, set the content of the response description field Response Description to empty, calculate CRC16 and encapsulate it to obtain the response frame Response, and send it to the communication interface module.

[0102] 2) Link Layer → Physical Layer: The protocol processing module is used to assemble the response frame sent by the application layer module into a physical layer data frame according to a second preset frame format and then send it to the communication interface module; the frame data field Frame in the physical layer data frame records the response frame, the source module field Src records the identifier of the protocol processing module, and the target module field Dst records the identifier of the communication interface module. The communication interface module is also used to receive the physical layer data frame and verify whether the source module field Src and the target module field Dst match (i.e., Src is the protocol processing module and Dst is itself); if the verification fails, it is discarded; if the verification passes, it is sent to the main control MCU of the metering terminal.

[0103] In a specific implementation where the communication interface module enables the I²C bus interface to connect with the main control MCU, the communication interface module is used to copy the content of the frame data field Frame in the physical layer data frame to the data reading area of ​​the register after the verification is passed, and at the same time calculate the CRC check value CRC16 of the frame data length FrameLen, and copy the frame data length FrameLen and CRC16 to the status query area of ​​the register, waiting for the main control MCU to read them.

[0104] (1) Data interaction between the link layer and the application layer The data exchanged between the protocol processing module of the link layer and the modules of the application layer is assembled according to the third preset frame format to achieve a unified parameter interface; the frame parameters included in the third preset frame format are shown in Table 7 below.

[0105] Table 7

[0106] 1) Link layer → Application layer: The protocol processing module is used to parse the request frame, assemble the parsing result into an application layer data frame according to a third preset frame format, and then send it to the target application layer module. Specifically, the protocol processing module extracts the application layer payload data recorded in the Request Description field from the parsing result as the "Application Layer Payload Field APUD" of the application layer data frame; obtains the length of the "Application Layer Payload Data" from the Frame Length field as the "Payload Length Len" of the application layer data frame; extracts the value of the functional subclass SubClass and writes it into the "Functional Subclass SubClass" of the application layer data frame; sets the source module field Src to its own identifier and sets the target module field Dst to the identifier of the application layer module corresponding to the functional class Class in the parsing result; and packages all parameters to obtain the application layer data frame.

[0107] The target application layer module is used to receive the application layer data frame and then verify the source module field Src, the target module field Dst, and the functional subclass SubClass. If all parameters pass the verification, the application layer payload field APUD in the application layer data frame is parsed; if any parameter fails the verification, the data frame is discarded.

[0108] 2) Application Layer → Data Link Layer: The target application layer module processes the application layer payload field APUD in the application layer data frame, assembles the processing result into a link layer data frame according to a third preset frame format, and sends it to the protocol processing module of the link layer. The application layer payload field APUD in the link layer data frame records the application layer payload data in the response description field, which is A-XDR encoded; the source module field Src records its own identifier; the target module field Dst records the identifier of the protocol processing module; the request / response flag field Type records the RSP; and the processing result field Result records the execution result of this instruction, with specific values ​​referring to Table 2 in the aforementioned embodiments.

[0109] The protocol processing module is used to receive the link layer data frame and verify the validity of various parameters therein, including: verifying whether the source module field Src and the target module field Dst match; verifying the processing result field Result, etc.; if all verifications pass, then assembling a response frame Response according to the link layer data frame in a first preset frame format. Specifically, this includes: filling the application layer payload field APUD from the link layer data frame into the response description field Response Description of the response frame Response, and filling the processing result field Result from the link layer data frame into the processing result field Result of the response frame Response. Optionally, if the processing result field Result in the link layer data frame corresponds to an error code, then the response description field Response Description of the response frame Response is set to empty.

[0110] (3) Data interaction between modules in the application layer The modules in the application layer also use a unified parameter interface for internal calls to achieve functional collaboration and access control.

[0111] 1) Call flow between modules in the application layer: ① After receiving request data from other application layer modules, the application layer module will check the validity of the parameters: The value of Type is REQ; the functional instructions indicated by SubClass are supported by this module; Src should be the source of the callable module, and Dst represents this module; If any of the above parameters are invalid, the same data will be returned according to the input parameters, but the APDU will be empty, and the Result value will be 5 to indicate a type mismatch; if the parameters are valid, the corresponding function will be called and executed according to the SubClass, and the result will be encapsulated as an answer and returned. In the returned data parameters, the Type value is RSP, the Src and Dst values ​​are swapped, and the Result depends on the internal execution situation.

[0112] ② After receiving the response data, the application layer module will also check the validity of the parameters: The value of Type is RSP; Dst is this module; SubClass and Src determine which request this response came from.

[0113] 2) Inter-module access control mechanism: To achieve secure isolation and reasonable access between application layer functional modules within the Security Element (SE), this embodiment defines a permission control mechanism based on module identifiers and sub-functional levels. Except for the physical layer communication interface module, other modules will not be able to establish direct data interaction with the application layer.

[0114] The specific implementation method of the access control mechanism is as follows: Each functional module within the application layer maintains its own independent call rule table. This table records the supported functional subclasses (SubClasses) and their corresponding callable module identifiers, collectively referred to as allowed call combinations. Calls not within these allowed combinations will be rejected.

[0115] For example, the calling rule table is shown in Table 8 below.

[0116] Table 8

[0117] For example, the permission verification process when application layer module A initiates a call request to application layer module B is as follows: Module B extracts the source module Src and functional subclass SubClass from the request; it then queries the locally stored call rule table. Determine if the (Src, SubClass) mapping exists in the table. If it exists, execute the requested function normally; otherwise, return "Permission denied".

[0118] In some specific implementations, calls between application function modules may involve instructions to obtain sensitive keys.

[0119] Within the Secure Element (SE), sensitive keys (including symmetric keys and asymmetric private keys) are obtained through the GetKey and GetPrivateKey commands. Since the SE itself is a complete secure and trusted environment, all embodiments of this invention further ensure that all data interactions between internal modules occur within physical protection boundaries. Therefore, even if the key is transmitted in plaintext within the SE, it is secure and there is no risk of leakage.

[0120] Taking the above two instructions as examples, the security protection mechanism of the security element SE in this embodiment is shown in Table 9 below.

[0121] Table 9

[0122] For example, the call flow of the DLMS protocol security processing module obtaining the symmetric key for AES-GCM decryption will be used for further explanation: The parameters involved in calling GetKey by the DLMS protocol security processing module are as follows: APDU parameters: {client_id=0x01, key_type=global unicast encryption key}; Len parameter: Actual length of APDU parameter; Src: DLMS protocol security processing module; Dst: Key and Certificate Management Module; SubClass: 1; Type: REQ.

[0123] The key certificate management module verifies the validity of parameters and the caller's permissions; after successful verification, it transmits the plaintext decryption key and remaining communication parameters such as Len and Src within a secure memory domain; DLMS protocol security. The processing module uses this key to perform further decryption operations.

[0124] Another embodiment of the present invention is a further extension based on any of the above embodiments.

[0125] This embodiment provides a Security Element (SE) for metering terminals. Its key certificate management module, located at the application layer, implements closed-loop management of the entire key lifecycle, from generation to destruction, through application layer protocol instructions. All key-related operations are completed within the chip hardware boundaries of the Security Element (SE). Specifically, operations such as key generation, import, and destruction require the execution of corresponding application layer function instructions, such as Class 1 or 2, with SubClass determined according to requirements.

[0126] Specifically, the key / certificate lifecycle management process of the key certificate management module is as follows: (1) Key generation: 1) Factory preset: During the production stage, the device master key, key pair, etc. are written by calling the SetKey and ImportKeyPair functions through security injection, and directly stored in the key certificate management module of the security element SE; 2) Runtime Key Negotiation and Generation: The main control MCU calls the GenerateKeyPair instruction to generate a temporary key pair, obtains the public key through the GetPublicKey instruction and sends it to the remote management system, then receives and enters the remotely issued public key through the SetKey instruction, and finally calls the KeyAgreement instruction to negotiate and generate a shared key and store it securely. This process conforms to the DLMS standard, and the corresponding application layer data structure is consistent with the DLMS standard.

[0127] (2) Key storage: All keys are stored uniformly in a physically protected secure key vault, managed by partition according to type and purpose, and indexed by client ID and key type. No external interface can directly read the plaintext private key; it can only obtain certificate and public key data.

[0128] (3) Key usage: If some security function commands require the use of internally stored keys, the client ID and key type parameters are used to specify the acquisition of the corresponding key.

[0129] (4) Key update: The main control MCU calls the KeyUpdate instruction to import a new key to replace the old key, or calls the key generation related function instruction to overwrite the original key by specifying the same client ID and key type.

[0130] (5) Key destruction: 1) Soft command destruction: The main control MCU issues a key destruction command to clear the specified key storage area according to the client ID and key type (such as calling the DeleteKey command), or clears all stored key data at once through a batch destruction command (such as DeleteAllKey); 2) Hardware anomaly triggered destruction: When the chip’s built-in security monitoring module detects an abnormal working environment (such as sudden voltage changes, temperature exceeding the safe range, etc.), the key certificate management module automatically triggers a security response and performs a fast zeroing operation on the key store to prevent key leakage under potential physical attacks.

[0131] Through the aforementioned closed-loop mechanism, this embodiment ensures that regardless of whether the key comes from factory preset, master station distribution, or session negotiation, the plaintext of sensitive keys such as the root key, authentication key, and asymmetric private key never leaves the security element SE, thus ensuring the security of the key system throughout its entire lifecycle.

[0132] Another embodiment of the present invention is a further extension based on any of the above embodiments.

[0133] This embodiment provides a method for interaction between the internal safety element (SE) of a metering terminal and the main control MCU, including: Phase 1: Physical layer reception and frame assembly.

[0134] 1. Signal capture and byte synchronization; 1.1 Trigger: The communication interface module of the Security Element (SE) detects a write operation on the physical bus (such as I²C) pointing to the instruction write area (register 0x0000).

[0135] 2. Initial frame integrity check; 2.1 Assembly: The communication interface module assembles the buffer data into a complete data frame object (containing the original byte array, length information, etc.). 2.2 Source and Destination Labeling: The communication interface module automatically adds an internal label to this data frame: Source module = Communication interface module; Destination module = Link layer protocol processing module; 2.3 Transmission: The data frame object is sent to the input queue of the protocol processing module in the link layer via the internal bus.

[0136] 3. Link layer verification and filtering; 3.1 Frame header verification: The protocol processing module parses the start of frame flag (STP) and confirms it is 0xE7; it parses the version and direction identifier (Identifier) ​​to confirm that the protocol version is compatible and the direction is correct (request frame). 3.2 CRC check: Extract the CRC16 value from the frame tail and recalculate the CRC16 for the frame body; 3.3 Exception Handling: If the verification fails, directly construct a "verification error" response frame, skip the subsequent steps, and proceed to "Phase Four"; 3.4 Length verification: Check whether the length declared in the frame header is consistent with the actual received length.

[0137] 4. Application layer decision-making; 4.1 Command parsing: Extract the Command field from the validated frame and separate the functional class (Class) and functional subclass (SubClass). 4.2 Payload Extraction: Strip the frame header and frame trailer, extract the middle Request Description as the Application Layer Protocol Data Unit (APDU), and record its length; 4.3 Module Mapping: Querying the internal mapping table based on the Class value: Class 0 → Mapped to the encryption algorithm module; Class 1 → Mapped to the DLMS protocol security processing module; Class 2 → Mapped to the key certificate management module; etc. 4.4 Internal Call Construction: Construct an internal call package, including: payload (APDU), length (LEN), source module (Src) = link layer protocol processing module, target module (Dst) = mapped application module, functional subclass (SubClass), and type (Type) = request (REQ); 4.5 Dispatch: Send the call packet to the message queue of the target application layer module.

[0138] Phase 3: In-depth processing and internal collaboration of target application layer modules.

[0139] 5. Pre-check of permissions and security policies; 5.1 Receiving Confirmation: The target application layer module retrieves the call packet from the queue, with confirmation type = REQ and source = link protocol processing module (or other allowed internal modules). 5.2 Restricted Rule Check: The module queries its internal call rule table; 5.2.1 Logic: Check whether the operation requested in the current request (defined by the SubClass) is allowed to be initiated by the calling source module; 5.2.2 Blocking: If permissions are insufficient, immediately construct an "Access Denied" error code Result, encapsulate a response packet and return it to the link layer to terminate the process.

[0140] 6. Business logic execution and cross-module collaboration; 6.1 Request Decoding (A-XDR Parsing): The target application layer module first performs A-XDR decoding on the received application layer payload (APDU), strips off the encoding format, and restores the most original business parameters (such as key index, security policy, ciphertext data, etc.). 6.1 Business Logic Processing: The target application layer module executes business logic based on the SubClass's call to the actual function instructions; 6.2 Response Encoding (A-XDR Encapsulation): After the service processing is completed, the module will re-encode the generated original response data using A-XDR to generate APDU, which will then be encapsulated into a standard response payload (Response Description). 6.3 The target application layer module constructs the return packet: payload = Response Description, source module = current module, target module = request initiating module, type = response (RSP), result code = Result, and sends the packet back to the request initiating module; 6.4 Cross-module collaborative invocation: If the business logic requires support from other modules (for example, the DLMS protocol security processing module needs to decrypt ciphertext), then follow the process 4.4-6.3. The source module and the target module are set according to the actual settings. The initiating module summarizes the results of all collaborative processing, generates the final business response data (Response Description) according to the business logic, and executes process 6.3.

[0141] Phase 4: Response assembly and physical layer readiness.

[0142] 7. Link layer response frame reconstruction; 7.1 Reception and Verification: The link layer module receives the return packet from the application layer, and the verification target = link layer and type = RSP; 7.2 Frame Construction: Enter the start flag (STP=0xE7); Enter the version number and direction indicator (flip the direction bit to "response"); Enter the result code (Result); Enter the response payload (Response Description); Update the Length field; 7.3 CRC Calculation: Calculate the CRC16 check value for the newly constructed frame body and append it to the frame tail; 7.4 Complete Frame Generation: Forming the final link layer response frame.

[0143] 8. Data writing and status updating; 8.1 Data Transfer: The link layer protocol processing module passes the complete response frame to the application layer communication interface module; 8.2 Write to Read Area: After the communication interface module verifies the source and destination match, it writes the response frame data into the data read area (register address 0x1000) inside the security element SE. 8.3 Status Register Update: Calculate the CRC16 of the data length and write the [status word (indicating data length)] and [length CRC] into the status feedback area (register address 0x0A00). 8.4 Suspension: The internal state machine of the safety element SE enters the "waiting to read" state, keeping the data in the data reading area unchanged until the main control MCU completes the reading operation; 8.5 Read Detection: The communication interface module detects that the main control MCU has initiated a read operation on the data reading area and has read a specified length of bytes, and is ready to receive the next communication request from the main control MCU.

[0144] The interaction process provided in this embodiment adopts the following data flow: physical interface → link layer (verification / routing) → application layer (permissions / services) → internal collaboration module (key / algorithm) → link layer (encapsulation) → physical interface. This enables the construction of a security boundary during the interaction process: the plaintext key only flows through the internal secure channel, never passing through the link layer for framing, and never appearing on external pins. This significantly improves the security of metering terminals.

[0145] The following section will take the electricity meter, a highly representative metering terminal, as an example. It will detail the complete interaction process between the electricity meter's security element SE and the main control MCU in a specific application scenario where the main control MCU of the electricity meter needs to decrypt and authenticate the DLMS APDU message it receives.

[0146] Example 1: The security policy is to encrypt requests only (security_policy = Bit3).

[0147] Under this strategy, DLMS APDU messages are only decrypted using AES-GCM and do not involve authentication tag verification.

[0148] Step 1: The main control MCU constructs a request frame; 1.1 Extract the client's client_id, cipher_text_apdu, client's system title, and frame counter from the network; 1.2 Construct the Request Description using A-XDR encoding: client_id = 0x01; security_policy = Bit3 (encrypted requests only); cipher_text_apdu = DLMS APDU message; client_system_title = 0x12 0x34 0x56 0x78; frame_counter = 0x00 0x00 0x00 0x01; 1.3 Encapsulating the link layer frame: STP=0xE7, Identifier=0x10 (Direction indicator = Request), Length=Command length + Response Description length, Command=0x21 (Class=1, SubClass=1 (DLMSDecryptProcess)), CRC=Calculate CRC16 from STP to Request Description; 1.4 The link layer frame is written to the instruction write area (register address 0x0000) inside the security element SE via the I²C interface.

[0149] Step 2: Internal processing of the safety element (SE); 2.1 The communication interface module receives the byte stream as a Frame, calculates the FrameLen, sets Src=MDL_COM and Dst=MDL_LINK, and delivers it to the link layer protocol processing module; 2.2 After the link layer protocol processing module checks that Dst is correct, completes CRC verification and fixed field checks, it parses out Class=1 and SubClass=1, constructs Src=MDL_LINK, Dst=MDL_DLMS, SubClass=1, Type=REQ, Len=APDU length, and delivers the APDU (Request Description), i.e. the structure in 1.2, and the above parameters to the application layer DLMS protocol security processing module. 2.3 After verifying that the parameters and calling permissions (Src, Dst, Type) of the DLMS protocol security processing module are correct, the DLMS message decryption function DLMSDecryptProcess is executed according to SubClass 1, and the input parameter is APDU (Request Description) in 2.2. 2.4 The DLMS protocol security processing module DLMSDecryptProcess decodes APDUs using A-XDR rules. Based on the semantic rules of the DLMS protocol, it determines that the message security policy is to encrypt only the request (security_policy=Bit3) without needing to authenticate or verify the message. Accordingly, it determines that the structure of cipher_text_apdu is {SC (security control byte), IC (call counter), Ciphertext (ciphertext)}. Based on SC, it further determines that only a decryption key with a value of 1 on the client side is needed to complete the decryption. 2.5 Internal call to the key certificate management module: The DLMS protocol security processing module prepares the GetKey request, APDU={client_id=1, key_type=global unicast encryption key}, Len=APDU length, Src=MDL_DLMS, Dst=MDL_KEYMGMT, SubClass=GetKey, Type=REQ and sends it to the key certificate management module. 2.6 The key certificate management module verifies that the parameters and calling permissions are correct. Based on the SubClass, it executes the specific function instruction GetKey, decodes the APDU according to the A-XDR rules, and obtains client_id=1, key_type=global unicastencryption key. Based on this, it extracts the plaintext AES-GCM encryption key EK of the client with client_id=1 from the secure storage area, constructs APDU={get_key_response=EK},Len=...,Src=MDL_KEYMGMT, Dst=MDL_DLMS,SubClass=GetKey, Type=RSP, Result=Success and returns it to the DLMS protocol security processing module. 2.7 After verifying that the parameters (Src, Dst, Type, Result=Success) of the DLMS protocol security processing module are correct, the plaintext key EK is parsed out and the next step of processing is performed. 2.8 Internal Call to Encryption Algorithm Module: The DLMS protocol security processing module prepares an AES-GCMDecryption request, APDU={encryption_key=EK, IV={client_system_title|frame_counter (indicating a combination of client_system_title and frame_counter)}, AAD=empty, cipher_text=Ciphertext}, Len=APDU length, Src=MDL_DLMS, Dst=MDL_CRYPTO, SubClass=AES-GCMDecryption, Type=REQ, and sends it to the encryption algorithm module; where IV and AAD are input parameters of the encryption algorithm, used as necessary conditions for encryption / decryption; Similar to 2.6, the encryption algorithm module calls and executes the AES-GCM decryption function instruction (without authentication) AES-GCMDecryption, obtains the actual plaintext, and returns it to the DLMS protocol security processing module, with the response APDU={plain_text=Plaintext, tag=empty}; 2.10 After verifying that the DLMS protocol security processing module's parameters (Src, Dst, Type, Result=Success) are correct, it parses the plaintext and obtains it according to the DLMS protocol rules: The SC and IC parsed from 2.10.1 and 2.4 are reassembled into plain_text_apdu={SC,IC,Plaintext}; 2.10.2 The specific value of service_type is obtained based on SC.

[0150] Construct APDU={plain_text_apdu={SC,IC,Plaintext}, service_type} and fill in the remaining parameters Len, Src=MDL_DLMS, Dst=MDL_LINK, SubClass=1, Type=RSP, Result=Success to return to the link layer protocol processing module; 2.11 The link layer protocol processing module verifies Result=Success to confirm a normal response to this request, and constructs a response frame Frame: STP=0xE7, Identifier=0x00 (Direction indicator = Response), Length=Command length + Result length + Response Description length, Command=0x21 (Class=1, SubClass=1), CRC=Calculate CRC16 from STP to Response Description, calculate FrameLen=Frame length, and set Src and Dst to deliver to the communication interface module.

[0151] 2.12 After verifying that Src and Dst are correct, the communication interface module fills the internal data reading area with Frame, calculates the CRC16 of FrameLen and fills it together with FrameLen into the status reading area for the main control MCU to read.

[0152] Step 3: The main control MCU receives the response; 3.1 The main control MCU polls the status feedback area (address 0x0A00) to obtain the data length L, reads L bytes from the data reading area (address 0x1000), and obtains the response frame; 3.2 Verify the CRC16 of the link layer response frame, parse the Result and Response Description to obtain the plaintext APDU, and send it to its own DLMS protocol stack for processing.

[0153] Example 2: Security policy is authentication-only (security_policy = Bit2).

[0154] Compared to Example 1, the differences are as follows: Request format: The message sent by the main control MCU is a DLMS APDU structure in the Request Description with the structure {SC,IC,Plaintext,tag (authentication tag)}, without encryption.

[0155] Key type: When the DLMS protocol security processing module calls GetKey, it obtains the authentication key (AK), not the block encryption key (EK).

[0156] Processing logic: When calling the encryption algorithm module, AES-GCMDecryption only calculates the tag. The input parameters are APDU={encryption_key=empty (no decryption required), IV={client_system_title|frame_counter}, AAD={SC|AK|... (AAD content is specified by the DLMS protocol and is based on multiple parameters, omitted here)}, cipher_text=Plaintext}. It calculates GMAC and outputs tag', without performing decryption operation, APDU={plain_text=Plaintext, tag=tag'}.

[0157] Response result: The DLMS protocol security processing module DLMSDecryptProcess command will compare whether tag' is equal to tag. If they are equal, the authentication is considered successful and the final result Result=Success is obtained. If they are not equal, the specific error code Result is returned.

[0158] The remaining processes (physical layer reception, link layer distribution, authorization verification, etc.) are the same as in Example 1.

[0159] Example 3: The security policy is to encrypt authentication requests (security_policy = Bit2 | Bit3).

[0160] This example combines the processing of Examples 1 and 2. AES-GCMDecryption calls GetKey twice, once to obtain EK and once to obtain AK. Then, it calls AES-GCMDecryption again, inputting APDU={encryption_key=EK, IV={client_system_title|frame_counter}, AAD={SC|AK|...}, cipher_text=Ciphertext}. The encryption algorithm module uses EK to decrypt Ciphertext to obtain Plaintext, and simultaneously performs a joint integrity check using IV, AAD, and Ciphertext to calculate the local tag'. AES-GCMDecryption returns APDU={plain_text=Plaintext, tag=tag'}. The remaining operations are consistent with Examples 1 and 2, and will not be elaborated here.

[0161] Another embodiment of the present invention provides a metering system, including a metering terminal; the metering terminal is provided with a safety element SE as described in any of the above embodiments. Here, the internal architecture and functional definition of the safety element SE will not be repeated; please refer to the descriptions in the above embodiments for details.

[0162] In summary, the safety element and metering system for metering terminals provided by this invention have at least the following significant features: 1. Significantly improved security; 1.1 Eliminate intermediate data exposure: By encapsulating the composite security functions of the DLMS protocol layer into a single chip instruction, all sensitive operations (decryption, signing, key negotiation) are completed in a closed loop within the SE. Intermediate state data (such as decryption intermediate value, hash intermediate value) never leaves the hardware boundary of the security element SE, completely eliminating bus eavesdropping and memory side channel attacks. 1.2 Hardware-level key protection: The entire lifecycle management of keys (generation, storage, use, and destruction) is completed within the secure element (SE). Private key materials are never exposed to the off-chip bus and MCU memory, fundamentally preventing key theft.

[0163] 2. Optimized processing efficiency; 2.1 Significantly reduced number of interactions: Atomic operations that originally required multiple round trips are merged into a single request-response, greatly reducing the communication overhead between the main control MCU and the security element SE, and reducing bus usage; 2.2 Hardware Acceleration: The cryptographic algorithm is executed by the hardware engine in the SE encryption algorithm module of the security element, which frees up the MCU computing power and improves the overall system response speed, especially suitable for high-frequency data interaction scenarios.

[0164] 3. Protocol compatibility and ease of use; 3.1 Unified encoding standard: Adopting the DLMS standard A-XDR encoding rule, it is naturally compatible with the existing protocol stack of metering terminals. The MCU does not need additional encoding and decoding conversion and can directly reuse its inherent DLMS processing capabilities. 3.2 Flexible data structure: While maintaining the A-XDR encoding method, it allows for customized data structures as needed, which not only meets industry standards but also adapts to the differentiated needs of different application scenarios; 3.3 Strong interface versatility: The physical layer supports multiple interfaces such as I²C / UART, and the upper layer protocol does not need to be modified, making it easy to adapt to different hardware platforms.

[0165] 4. Value of the industrial chain; 4.1 Lowering the development threshold: Metering terminal manufacturers can quickly implement various DLMS standard security solutions based on the security element SE of this invention, reducing the development and certification cycle of security functions; 4.2 Enhance terminal security: Systematically address the security shortcomings of metering terminals from the chip architecture level, providing a reliable security foundation for the large-scale deployment of metering IoT.

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

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

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

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

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

[0171] 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 safety element for metering terminals, characterized in that, It includes a communication interface module at the physical layer, a protocol processing module at the link layer, and an encryption algorithm module, a DLMS protocol security processing module, a key certificate management module, a data security storage module, and a management module at the application layer; the communication interface module is connected to the main control MCU of the metering terminal via a serial communication protocol; The main control MCU of the metering terminal is used to assemble a request frame according to a first preset frame format and then send it to the communication interface module. The first preset frame format includes a function command field (Command), a request description field (Request Description) for the corresponding request frame, and a response description field (Response Description) for the corresponding response frame; the function command field (Command) includes a function class (Class) and a function subclass (SubClass); the function class (Class) is used to indicate the target application layer module to be called, and the function subclass (SubClass) is used to indicate the specific function to be executed by the target application layer module; The communication interface module is used to receive a request frame sent by the main control MCU of the metering terminal and send it to the link layer; and to receive a response frame sent by the link layer and send the response frame to the main control MCU of the metering terminal according to the current serial communication protocol specification. The protocol processing module is used to parse the request frame sent by the communication interface module, determine the target application layer module based on the functional class and functional subclass in the parsed functional instruction field Command, and send the application layer payload data in the parsed request description field Request Description, together with the functional subclass, to the target application layer module. After receiving the processing result returned by the target application layer data, the response frame is assembled according to the first preset frame format and then sent to the communication interface module; The target application layer module is used to perform corresponding processing based on the application layer load data and the functional subclass SubClass, and then return the processing result to the protocol processing module.

2. The security element for metering terminals as described in claim 1, characterized in that, The communication interface module includes an I²C bus interface and registers; the registers define three logical areas: an instruction writing area, a status feedback area, and a data reading area. When the communication interface module enables the I²C bus interface to connect with the main control MCU: The main control MCU of the metering terminal is used to perform I²C write operation to write the request frame into the instruction write area; then, it polls and performs I²C read operation to read status information from the status feedback area for parsing; and when the parsing result of the status information is ready, it performs I²C read operation to read the response frame from the data read area. The communication interface module is used to detect the request frame written to the instruction writing area, obtain the request frame, and write the response frame to the status feedback area after receiving the response frame.

3. The safety element for metering terminals as described in claim 1, characterized in that, The communication interface module includes a UART interface; when the communication interface module enables the UART interface to connect with the main control MCU: The main control MCU of the metering terminal is used to send request frames to the communication interface module according to the UART serial communication parameters specified by the DLMS protocol. The communication interface module is used to send the response frame to the main control MCU of the metering terminal according to the UART serial port communication parameters.

4. The safety element for metering terminals as described in claim 1, characterized in that, The data transmitted between the physical layer and the link layer is assembled according to a second preset frame format; the second preset frame format includes a frame data field Frame, a frame data length field FrameLen, a source module field Src, and a destination module field Dst; When the data is transmitted from the physical layer to the link layer, the communication interface module is further configured to receive the request frame, assemble it into a link layer data frame according to the second preset frame format, and then send it to the protocol processing module; the frame data field Frame in the link layer data frame records the request frame, the source module field Src records the identifier of the communication interface module, and the target module field Dst records the identifier of the protocol processing module. The protocol processing module is further configured to, after receiving the link layer data frame, verify the source module field Src and the target module field Dst therein; if the verification passes, parse the request frame recorded in the frame data field Frame therein; When the data is transmitted from the link layer to the physical layer, the protocol processing module is further configured to assemble the response frame into a physical layer data frame according to the second preset frame format and then send it to the communication interface module; the frame data field Frame in the physical layer data frame records the response frame, the source module field Src records the identifier of the protocol processing module, and the target module field Dst records the identifier of the communication interface module. The communication interface module is also used to receive the physical layer data frame and verify the source module field Src and the target module field Dst therein; if the verification passes, it is sent to the main control MCU of the metering terminal.

5. The safety element for metering terminals as described in claim 1, characterized in that, The data transmitted between the link layer and the application layer is assembled according to a third preset frame format; the third preset frame format includes the application layer payload field APUD, the payload length field Len, the source module field Src, the target module field Dst, and the functional subclass SubClass; When the data is transmitted from the link layer to the application layer, the protocol processing module is further configured to assemble the parsing result of the request frame into an application layer data frame according to a third preset frame format and then send it to the target application layer module; the application layer payload field APUD in the application layer data frame records the application layer payload data in the request description field Request Description, the source module field Src records the identifier of the protocol processing module, and the target module field Dst records the identifier of the target application layer module; The target application layer module is also used to receive the application layer data frame and then verify the source module field Src, the target module field Dst, and the functional subclass SubClass. If all verifications pass, the application layer payload field APUD in the application layer data frame is parsed. When the data is transmitted from the application layer to the link layer, the target application layer module is further configured to assemble the processing result into a link layer data frame according to a third preset frame format and then send it to the protocol processing module; the application layer payload field APUD in the link layer data frame records the application layer payload data in the response description field Response Description, the source module field Src records the identifier of the target application layer module, and the target module field Dst records the identifier of the protocol processing module; The protocol processing module is further configured to receive the link layer data frame and verify the source module field Src and the target module field Dst therein; if the verification passes, a response frame is assembled based on the application layer payload field APUD therein.

6. The safety element for metering terminals as described in claim 5, characterized in that, The first preset frame format further includes a processing result field Result corresponding to the response frame; the third preset frame format further includes a frame type field Type and a processing result field Result; the frame type field Type includes a request flag for the corresponding application layer data frame and a response flag for the corresponding link layer data frame; When the data is transmitted from the link layer to the application layer, the target application layer module is specifically used to receive the application layer data frame and then verify the frame type field Type, function subclass SubClass, source module field Src, and target module field Dst respectively. If any one of the verifications fails, a processing failure and a response description field Response Description that is empty are generated. If all verifications pass, the application layer payload field APUD in the application layer data frame is parsed to generate the corresponding processing result.

7. The safety element for metering terminals as described in claim 1, characterized in that, The first preset frame format specifically includes: a frame start flag field (STP), an identifier field (Identifier), a frame length field (Length), a function instruction field (Command), a processing result field (Result), a request description field (Request Description), a response description field (Response Description), and a checksum field (CRC); wherein, the identifier field includes a version number, transmission direction, priority, and frame sequence number; Both the Request Description field and the Response Description field use A-XDR encoding.

8. The safety element for metering terminals as described in claim 1, characterized in that, The encryption algorithm module, DLMS protocol security processing module, key certificate management module, data security storage module, and management module located in the application layer each maintain an independent call rule table; the call rule table records the supported functional subclasses and their corresponding callable module identifiers.

9. The safety element for metering terminals as described in claim 1, characterized in that, The encryption algorithm module is used to implement various cryptographic algorithms and generate the required random numbers using a true random number generator; The DLMS protocol security processing module is used to process the composite security functions of the DLMS protocol, which include at least two of DLMS HLS authentication, DLMS data frame encryption and decryption, and key encapsulation transmission. The key certificate management module, as the security root of trust for the security element, is responsible for the full lifecycle management of keys and certificates; the keys include factory-preset keys and dynamically generated keys at runtime. The data security storage module, as a physically protected security key store, is used to store the keys and certificates, and automatically performs encryption, decryption and integrity verification when reading and writing the keys and certificates; The management module is equipped with functions such as security element status query, self-test, initialization parameters, and reset.

10. A metering system, characterized in that, It includes a metering terminal; the metering terminal is equipped with the safety element described in any one of claims 1 to 9.

Images