A client whitelist-based DLMS certificate identity authentication enhancement method and system

Abstract

A DLMS certificate identity authentication enhancement method and system based on a client whitelist, a System Title whitelist authorized to access is preset in a meter, after a standard DLMS HLS authentication process is completed, it is verified whether CN (namely System Title) in the client certificate exists in the preset client whitelist of the meter, so that enhanced identity authentication is realized. The technical scheme realizes enhanced identity authentication only by using the attributes of the certificate itself under the DLMS protocol framework, realizes accurate control of the identity of the client without introducing shared symmetric keys, so that the security advantages of the PKI asymmetric key system are fully retained.

Description

Technical Field

[0001] This invention relates to the field of power technology, and in particular to a method and system for enhancing DLMS certificate authentication based on a client whitelist. Background Technology

[0002] IEC 62056 is a data exchange standard for electricity metering developed by the International Electrotechnical Commission (IEC). DLMS / COSEM (Device Language Message Specification / Energy Metering Supporting Specification) is its core protocol suite, widely used in data acquisition and management of smart meters. This standard supports authentication under various communication methods, among which Advanced Security Authentication (HLS) based on the PKI digital certificate system is a commonly used authentication method.

[0003] PKI (Public Key Infrastructure) is a security infrastructure based on asymmetric cryptography. CA (Certificate Authority) is a trusted third party in PKI, responsible for issuing digital certificates and binding public keys to entity identities.

[0004] Digital certificates are core credentials in the PKI system, containing fields such as certificate holder information, public key, validity period, issuer information, and digital signature. In the DLMS system, the System Title is a field used to uniquely identify a communication entity (client or server), with a length of 8 bytes (the first 3 bytes are the vendor code, and the last 5 bytes are the unique serial number), and the Common Name (CN) field of the certificate is specified to be the System Title.

[0005] In the HTTPS / TLS protocol, the client verifies not only the CA signature chain of the server certificate, but also whether the CN or SAN (Subject Alternative Name) field in the certificate matches the target domain name being accessed. This mechanism ensures that even if an attacker holds a legitimate certificate issued by the same CA, they cannot impersonate the target server.

[0006] In the DLMS (Device Language Message Specification) Security Suite 1 / 2 standard, the server (electricity meter) authenticates the client's (such as HES systems, Head End Systems, or power company systems used for remotely collecting and managing meter data) certificate solely by verifying the validity of the certificate signature using the CA root certificate of the PKI (Public Key Infrastructure) system. This means it only confirms that the certificate was issued by a trusted CA (Certificate Authority). This technical solution has the following security vulnerability: any legitimate certificate issued by the same CA, without additional security measures, can pass the meter's authentication and gain access.

[0007] To address this issue, the industry commonly employs a pre-configured shared symmetric key scheme to enhance authentication. This scheme involves pre-configuring a shared symmetric key between the meter and the client, and adding a challenge-response verification step based on this shared key to the DLMS HLS authentication process. A typical workflow is as follows: 1) Before the electricity meter leaves the factory, the manufacturer pre-installs a shared symmetric key into the meter firmware; 2) The manufacturer distributes the shared key to the client through a secure offline channel; 3) During the HLS authentication process, after the meter verifies the CA signature of the client certificate, an additional challenge-response verification based on the shared key is initiated; 4) Only clients that possess both a valid certificate and the correct shared key can pass authentication.

[0008] This scheme suffers from problems such as difficulty in key distribution and reduced security level.

[0009] Patent application CN117544413A, entitled "An Identity Authentication Method and System Based on Whitelist and Identity Blocks," discloses an identity authentication method and system based on whitelists and identity blocks. The method includes the following steps: a remote intelligent terminal device generates authentication request information and sends it to an authentication center; the authentication center determines whether the device ID is in the whitelist; if the device ID exists in the whitelist, the corresponding identity block is found in the identity blockchain; the validity of the identity block is verified; if the identity block is valid, the Hash_auth field in the identity block header is verified; and based on the verification result, a decision is made on whether to allow device access. This invention effectively solves the identity security problem of remote intelligent terminals accessing the Industrial Internet, reducing the security risks that sensitive industrial data in the Industrial Internet may encounter. Although this technical solution is based on whitelists and identity blocks for identity authentication, it does not combine it with the DLMS HLS authentication process for identity authentication enhancement.

[0010] Patent document CN113098863B, entitled "A Method and System for IoT Dual Authentication Based on TLS+MQTT Protocol," discloses an IoT dual authentication method and system based on the TLS+MQTT protocol. Specifically designed for IoT scenarios, it employs a dual authentication approach based on the TLS+MQTT protocol to ensure the trustworthiness of IoT terminal identities. When an IoT terminal establishes a TLS connection with an IoT cloud platform, they mutually authenticate each other's identities to achieve two-way authentication. After successful authentication, the TLS gateway synchronizes the IoT terminal's authentication information to the MQTT Broker. The MQTT Broker then performs further authentication on the IoT terminal based on the terminal identifier at the MQTT protocol layer, thus achieving an enhanced dual authentication method. Therefore, this invention synchronizes the authentication results of the two protocols through a linkage mechanism, thereby ensuring enhanced authentication of IoT terminal devices by the IoT cloud platform and guaranteeing secure and reliable data transmission. Although this technical solution implements two-way authentication, it relies solely on the validity verification of certificate signatures for identity authentication, which presents a security vulnerability.

[0011] In summary, the existing technology has the following drawbacks: 1) Engineering complexity of key distribution and management: In large-scale deployment scenarios, the entire lifecycle management of shared keys, including generation, secure distribution, periodic rotation, and revocation upon leakage, is extremely complex and has high operation and maintenance costs.

[0012] 2) A fundamental reduction in security level: Shared symmetric key schemes degrade the security anchor from an asymmetric system where "the private key never leaves the holder" to a symmetric system where "multiple people share the same secret." Once the shared key is leaked, attackers can access all the electricity meters using that key.

[0013] Therefore, there is an urgent need to provide a suitable DLMS certificate authentication enhancement method and system that can enhance identity authentication by utilizing only the certificate itself and eliminate symmetric key dependency. Summary of the Invention

[0014] The technical problem this application aims to solve is to achieve enhanced identity authentication within the DLMS protocol framework by utilizing only the attributes of the certificate itself, and to achieve precise control over the client's identity without introducing a shared symmetric key, thereby fully preserving the security advantages of the PKI asymmetric key system.

[0015] One aspect of this application provides a DLMS certificate authentication enhancement method based on a client whitelist, comprising the following steps: S10, Client whitelist registration and certificate issuance: Before applying for a digital certificate for its client, the client must first register the system title used by the client with the Certificate Authority of the Public Key Infrastructure. S20, secure generation, distribution, and burning of client whitelists; S30, enhanced certification for the meter; S40, dynamic management of client whitelists after factory release; Step S30 includes the following enhanced authentication steps performed by the meter when a client attempts to connect to the meter and perform DLMS advanced security authentication: S301: Following the DLMS standard procedure, the meter uses a pre-installed certificate authority root certificate to verify the signature validity of the client certificate. If verification fails, the connection is directly rejected. S302, After the signature verification is successful, the meter extracts the value of the CN field from the client certificate. The value of the CN field is the system title used by the client. S303: The meter matches the system title with the client whitelist stored on the local machine. If the system title exists in the whitelist, it is determined to be an authorized client, and the subsequent DLMS communication process continues; if the system title does not exist in the whitelist, it is determined to be an unauthorized client, the meter actively disconnects the connection, and records the security event log.

[0016] According to some embodiments, the method for registering the system header used by the client with the Certificate Authority of the Public Key Infrastructure (CBI) in step S10 includes any one of the following four methods: Identity binding registration based on existing certificate chains: Use the valid digital certificate that the customer already holds and that is recognized by the public key infrastructure system to prove their identity and complete the unique registration and identity binding of the system title; Email verification: The public key infrastructure system sends an email containing a unique random verification code to the email address submitted by the customer during registration. After receiving the email, the customer sends the verification code back to the public key infrastructure system. The public key infrastructure verifies whether the returned verification code matches the one sent to prove the customer's identity. DNS TXT record verification: The public key infrastructure system provides customers with a unique random token. Customers add a TXT record to the DNS zone of their enterprise domain name with the value of the token. The public key infrastructure verifies the existence of the record and whether the value matches by querying the DNS to prove their identity. HTTP file verification: The client uploads a verification file provided by the public key infrastructure to a specified path on their web server. The public key infrastructure accesses the URL via HTTPS to confirm the existence and correctness of the file, thereby proving the client's identity.

[0017] According to some embodiments, the step of using a valid digital certificate already held by the customer and recognized by the public key infrastructure system to prove their identity and complete the unique registration and identity binding of the system title includes: S101, Generate and sign a registration request. The client generates a system title registration request, which includes a list of system titles to be registered and metadata of the registration request. The client uses the private key corresponding to the certificate to digitally sign the registration request. The certificate is a valid digital certificate that the client already holds and that has been issued by this public key infrastructure system or a trusted certificate authority with which it has a trusted relationship. S102, Submit Registration Request: The client submits the signed registration request and proof certificate or certificate chain to the public key infrastructure system. S103, PKI system verifies signatures and certificate chains; S104, Uniqueness Check and Binding Registration; S105, Ownership verification during certificate application.

[0018] According to some embodiments, step S103, where the PKI system verifies the signature and certificate chain, includes the following verifications performed after the PKI system receives the request: verifying the digital signature of the registration request using the public key in the certificate to ensure that the request content has not been tampered with and was indeed initiated by the certificate holder; verifying the validity of the certificate chain to confirm that the certificate was issued by the root certificate authority of this public key infrastructure or a pre-configured trusted certificate authority, that the certificate chain is complete, and that all intermediate certificates have not been revoked; checking the validity period and revocation status of the certificate; and extracting the customer's identity information from the Subject field of the certificate as the subject identifier for subsequent binding.

[0019] According to some embodiments, the validity period and revocation status of a certificate are checked using a Certificate Revocation List (CRL) or an Online Certificate Status Protocol (OCSP); the identity information includes the organization name and organization code.

[0020] According to some embodiments, the uniqueness check and binding registration in step S104 includes: the public key infrastructure system queries its registration database to check whether the system title to be registered has been registered by other clients; if it has been registered, the registration request is rejected and an error message of system title conflict is returned to the client; if it has not been registered, the system title is bound to the client identity information extracted from the certificate, and the registration status is marked as registered, while the public key infrastructure system records the certificate information on which this registration is based.

[0021] According to some embodiments, the attribution verification during certificate application in step S105 includes: The customer generates a certificate application request, in which the CN field is filled with the registered system title, and the customer signs the application request using the private key corresponding to a valid certificate held by the customer; After the public key infrastructure system verifies the signature, it extracts the customer identity information represented by the signature certificate and compares it with the customer identity information bound to the system title in the registration database; The public key infrastructure system will only consider the certificate application legitimate and issue a client certificate containing the system's header as the CN if the identities of the two parties match; otherwise, it will refuse to issue the certificate.

[0022] According to some embodiments, the secure generation, distribution, and burning of the client whitelist in step S20 includes: S201, The customer determines the system titles of all clients that need to access a certain batch of electricity meters, and generates a whitelist of client system titles; S202, The customer provides the whitelist to the meter manufacturer through a secure channel; S203, during the production process, the manufacturer writes the whitelist into the non-volatile memory of the electricity meter using a secure programming tool, and the whitelist storage area has a hardware or software protection mechanism to prevent tampering.

[0023] According to some embodiments, the dynamic management of the client whitelist after factory release in step S40 is used for permission changes during operation, including: S401, Any client to be added to the whitelist shall complete the unique registration of its system title in step S10 to prevent its system title from being registered by other clients in advance; S402, after a secure connection has been established between an authorized client in the whitelist and the meter, a whitelist update instruction is sent to the meter. The content of the update instruction includes the operation type and the target system title. S403: After receiving the update command, the meter first verifies whether the client that initiated the command is in the whitelist. If the verification is successful, the corresponding command is executed and the local whitelist record is updated.

[0024] Another aspect of this application provides a DLMS certificate authentication enhancement system based on a client whitelist, used to implement the aforementioned DLMS certificate authentication enhancement method based on a client whitelist, including a public key infrastructure system, a client system, a meter manufacturer, and a smart meter; The public key infrastructure system is used to issue digital certificates, maintain the unique registration of system headers, and verify customer identities. The client system registers its client's system title with the public key infrastructure system; The meter manufacturer is responsible for producing the smart meters and securely pre-installs the client whitelist into the smart meters before they leave the factory. The smart meter is a DLMS server. The smart meter stores a whitelist of clients and determines whether to authorize client access based on the whitelist during the authentication phase.

[0025] The beneficial effects of this application are as follows: This technical solution pre-configures a whitelist of authorized client System Titles within the electricity meter. After the standard DLMS HLS authentication process is completed, it additionally verifies whether the CN (System Title) in the client certificate exists in the pre-configured client whitelist, thereby achieving enhanced identity authentication. PKI registration ensures the global uniqueness and identity binding of the System Title; manufacturer pre-configuration ensures the initial trustworthiness of the client whitelist; on-site matching verification enables precise control over clients—allowing only members on the whitelist to access the meter; and whitelist updates support permission change requirements in actual operation. A valid digital certificate already held by the customer and recognized by the PKI system is used to prove their identity, completing the unique registration and identity binding of the System Title. This mechanism is completed entirely within the closed loop of the PKI trust system, without relying on external channels, offering high security and a high degree of automation. Only currently authorized clients on the whitelist are allowed to modify (add or delete) the whitelist. Before adding, the target System Title must first be registered with the PKI to prevent pre-registration by other customers. The concept of "certificate + domain name verification" dual authentication is introduced into the DLMS communication field of smart meters, using the certificate CN field as the identity anchor for access control. It has the following technical effects: 1) Significantly enhanced security level: It completely eliminates the reliance on shared symmetric keys, fully preserving the core security advantage of the PKI asymmetric key system that "the private key never leaves the holder." Even if an attacker obtains a legitimate certificate issued by a CA, authentication will fail as long as its CN is not on the target meter's client whitelist.

[0026] 2) Significantly reduced management complexity: There is no need to manage complex symmetric key distribution, rotation, and destruction processes. Client whitelist management can be securely completed through message exchanges between authorized clients and the electricity meter, making operation and maintenance simple and efficient.

[0027] 3) Achieve fine-grained access control: Each meter can have an independent whitelist of authorized clients, and different power companies use their own registered System Titles to achieve natural permission isolation, avoiding the problem of a single key leak affecting the entire system, as is the case with shared key schemes.

[0028] 4) Fully compatible with existing standards: This method is an "add-on" enhancement to the standard DLMS HLS certification process. It does not modify the protocol itself or change the certificate format. It only adds a System Title whitelist verification step, which requires minimal changes to the existing system and has low upgrade costs. Attached Figure Description

[0029] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0030] Figure 1 This diagram illustrates an architecture of a DLMS certificate authentication enhancement system based on a client whitelist, according to an example embodiment. Detailed Implementation

[0031] The embodiments of this application will now be described in detail with reference to the accompanying drawings. It should be understood that the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0032] Those skilled in the art should understand that the following specific embodiments or implementation methods are a series of optimized configurations listed in this application to further explain the specific application content. These configuration methods can be combined or used in conjunction with each other, unless this application explicitly states that some or a specific embodiment or implementation method cannot be associated with or used in conjunction with other embodiments or implementation methods. Furthermore, the following specific embodiments or implementation methods are only considered as optimized configurations and are not intended to limit the scope of protection of this application.

[0033] Example 1 Figure 1 This diagram illustrates an architecture of a DLMS certificate authentication enhancement system based on a client whitelist, according to an example embodiment.

[0034] like Figure 1 As shown, a DLMS certificate authentication enhancement system based on a client whitelist includes the following four parts: PKI / CA system: Responsible for issuing digital certificates, maintaining the unique registration of System Titles, and verifying customer identities.

[0035] Client systems: such as client systems owned and operated by power companies (e.g., HES), register their client system titles with the PKI, generate a whitelist, and distribute the whitelist to meter manufacturers.

[0036] Electricity meter manufacturer: Responsible for electricity meter production, and securely pre-installs the client whitelist into the electricity meter before it leaves the factory.

[0037] Smart meter (DLMS server): Stores a whitelist of clients and determines whether to authorize client access based on the whitelist during the authentication phase. It works with the client system to dynamically manage the whitelist.

[0038] Figure 1 In this process, the DLMS certificate authentication enhancement system based on client whitelist operates as follows: ① Registration and certificate issuance for client whitelists; ② Secure generation, distribution, and burning of client whitelists; ③ Enhanced authentication process at the meter end; ④ Dynamic management of the client whitelist after it leaves the factory.

[0039] Example 2 A DLMS certificate authentication enhancement method based on client whitelist includes the following steps: Step S101, Client whitelist registration and certificate issuance: Before applying for a digital certificate for its client, the client must first register the System Title to be used by the client with the PKI / CA system. This embodiment adopts an identity binding registration mechanism based on an existing certificate chain: it uses a valid digital certificate already held by the client and recognized by the PKI system to prove its identity, completing the unique registration and identity binding of the System Title. Step S101 includes the following sub-steps: S101-1, Generate and sign the registration request: The client generates a System Title registration request, which includes at least a list of System Titles to be registered and metadata of the registration request (such as timestamps, validity periods, etc.).

[0040] The customer uses the private key corresponding to a valid digital certificate issued by this PKI system (or a trusted CA with which it has a trusted relationship) to digitally sign the registration request. In this embodiment, the aforementioned certificate is referred to as a "proof certificate".

[0041] S101-2, Submit registration request: The customer submits the signed registration request and proof certificate (or certificate chain) to the PKI system.

[0042] S101-3, PKI system verification of signature and certificate chain: Upon receiving the request, the PKI system performs the following verification: 1) Use the public key in the certificate to verify the digital signature of the registration request to ensure that the request content has not been tampered with and was indeed initiated by the certificate holder.

[0043] 2) Verify the validity of the certificate chain: Confirm that the certificate was issued by the root CA of this PKI or a pre-configured trusted CA, that the certificate chain is complete, and that none of the intermediate CA certificates have been revoked.

[0044] 3) Check the validity period and revocation status of the certificate (via Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP).

[0045] 4) Extract the customer's identity information (such as organization name, organization code, etc.) from the Subject field of the certificate as the subject identifier for subsequent binding.

[0046] S101-4, Uniqueness Check and Binding Registration: The PKI system queries its registration database to check if the System Title to be registered has already been registered by another customer: If the system title has already been registered, the registration request will be rejected and a "System Title conflict" error message will be returned to the customer. If not registered, the System Title will be bound to the customer identity information extracted from the certificate of authenticity, and the registration status will be marked as "registered". Simultaneously, the PKI system can record the certificate of authenticity used for this registration for future auditing.

[0047] S101-5, Ownership verification during certificate application: When a customer subsequently applies for a client digital certificate for this System Title, the PKI system must verify whether the applicant has the registration right for that System Title. The specific verification method is as follows: 1) The customer generates a certificate request (PKCS#10 or similar format), where the CN field is filled with the registered System Title. The customer signs the request using the private key corresponding to a valid certificate in their possession (which can be the original certificate or another certificate controlled by the same customer identity).

[0048] 2) After the PKI system verifies the signature, it extracts the customer identity information represented by the signature certificate and compares it with the customer identity information bound to the System Title in the registration database.

[0049] 3) The PKI system will only consider the certificate application valid and issue a client certificate containing the SystemTitle as the CN if the identities of the two parties are consistent; otherwise, it will refuse to issue the certificate.

[0050] This mechanism ensures the uniqueness and security of the System Title within the PKI system, laying a foundation of trust for subsequent whitelist verification.

[0051] Step S102, the secure generation, distribution, and burning of the client whitelist, includes the following sub-steps: S102-1, The customer determines the System Title of all clients that need to access a certain batch of electricity meters, and generates a whitelist of client System Titles.

[0052] S102-2, the customer provides this whitelist to the meter manufacturer through a secure channel (such as encrypted communication, dedicated line transmission or a secure offline method agreed upon by both parties).

[0053] S102-3 During the production process, the manufacturer writes the client whitelist into the meter's non-volatile memory (such as secure flash memory) using a secure programming tool. This whitelist storage area should have hardware or software protection against tampering.

[0054] Step S103, Enhanced authentication process at the meter end: When a client attempts to connect to the meter and perform DLMS HLS authentication, the meter performs the following enhanced authentication steps: S103-1, the meter uses a pre-installed CA root certificate to verify the signature validity of the client certificate according to the DLMS standard procedure. If the verification fails, the connection is rejected directly.

[0055] S103-2, After the signature verification is successful, the meter extracts the value of the CN field (i.e., SystemTitle) from the client certificate.

[0056] S103-3, the meter matches the System Title with the client whitelist stored locally: If the System Title exists in the whitelist: it is determined to be an authorized client, and the subsequent DLMS communication process continues; If the System Title is not in the whitelist: it is determined to be an unauthorized client, the meter will actively disconnect and record the security event log.

[0057] This step achieves an effect similar to domain name verification in HTTPS—even if the certificate is issued by a legitimate CA, authentication will fail if its .CN is not on the meter's client whitelist.

[0058] Step S104, Dynamic management of the client whitelist after factory release: To support the need for permission changes in actual operation (such as adding a new authorized client), this embodiment provides a factory-safe update mechanism for the whitelist, including: S104-1, Any client to be added to the whitelist must first complete the PKI unique registration of its System Title according to step S101. This requirement prevents its System Title from being registered by other clients in advance.

[0059] S104-2: After an authorized client in the whitelist has established a secure connection with the meter, a whitelist update instruction is sent to the meter. The instruction includes the operation type (add or delete, but cannot delete itself) and the target SystemTitle.

[0060] S104-3 After receiving an update command, the meter first verifies whether the client that initiated the command is on the whitelist (i.e., only members on the whitelist are allowed to perform modification operations). If the verification is successful, the meter performs the corresponding add or delete operation and updates the local whitelist record.

[0061] Example 3 Replace the use of a valid digital certificate already held by the customer and recognized by the public key infrastructure system to prove their identity in Example 2 with any of the following methods to complete the unique registration and identity binding of the system title.

[0062] Email verification: The public key infrastructure system sends an email containing a unique random verification code to the email address submitted by the customer during registration. After receiving the email, the customer sends the verification code back to the public key infrastructure system. The public key infrastructure verifies whether the returned verification code matches the one sent to prove the customer's identity. DNS TXT record verification: The public key infrastructure system provides customers with a unique random token. Customers add a TXT record to the DNS zone of their enterprise domain name with the value of the token. The public key infrastructure verifies the existence of the record and whether the value matches by querying the DNS to prove their identity. HTTP file verification: The client uploads a verification file provided by the public key infrastructure to a specified path on their web server. The public key infrastructure accesses the URL via HTTPS to confirm the existence and correctness of the file, thereby proving the client's identity.

[0063] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A DLMS certificate authentication enhancement method based on client whitelist, characterized in that, Includes the following steps: S10, Client whitelist registration and certificate issuance: Before applying for a digital certificate for its client, the client must first register the system title used by the client with the Certificate Authority of the Public Key Infrastructure. S20, secure generation, distribution, and burning of client whitelists; S30, enhanced certification for the meter; S40, dynamic management of client whitelists after factory release; The dynamic management of the client whitelist after factory release is used for permission changes during operation, including: S401, Any client to be added to the whitelist shall complete the unique registration of its system title in step S10 to prevent its system title from being registered by other clients in advance; S402, after a secure connection has been established between an authorized client in the whitelist and the meter, a whitelist update instruction is sent to the meter. The content of the update instruction includes the operation type and the target system title. S403: After receiving the update command, the meter first verifies whether the client that initiated the command is in the whitelist. If the verification is successful, the corresponding command is executed and the local whitelist record is updated. Step S30 includes the following enhanced authentication steps performed by the meter when a client attempts to connect to the meter and perform DLMS advanced security authentication: S301: The meter uses a pre-installed certificate authority root certificate to verify the signature validity of the client certificate according to the DLMS standard process; if the verification fails, the connection is directly rejected. S302, After the signature verification is successful, the meter extracts the value of the CN field from the client certificate. The value of the CN field is the system title used by the client. S303: The meter matches the system title with the client whitelist stored on the local machine. If the system title exists in the whitelist, it is determined to be an authorized client, and the subsequent DLMS communication process continues; if the system title does not exist in the whitelist, it is determined to be an unauthorized client, the meter actively disconnects the connection, and records the security event log.

2. The DLMS certificate authentication enhancement method based on client whitelist according to claim 1, characterized in that, The method for registering the system header used by the client with the Certificate Authority of the Public Key Infrastructure (CBI) as described in step S10 includes any one of the following four methods: Identity binding registration based on existing certificate chains: Use the valid digital certificate that the customer already holds and that is recognized by the public key infrastructure system to prove their identity and complete the unique registration and identity binding of the system title; Email verification: The public key infrastructure system sends an email containing a unique random verification code to the email address submitted by the customer during registration. After receiving the email, the customer sends the verification code back to the public key infrastructure system. The public key infrastructure verifies whether the returned verification code matches the one sent to prove the customer's identity. DNS TXT record verification: The public key infrastructure system provides customers with a unique random token. Customers add a TXT record to the DNS zone of their enterprise domain name with the value of the token. The public key infrastructure verifies the existence of the record and whether the value matches by querying the DNS to prove their identity. HTTP File Verification: The client uploads a verification file provided by the public key infrastructure to a specified path on their web server. The public key infrastructure accesses the specified path on the web server via HTTPS to verify the existence and correctness of the file, thus proving the client's identity.

3. The DLMS certificate authentication enhancement method based on client whitelist according to claim 2, characterized in that, The process of using a valid digital certificate already held by the customer and recognized by the public key infrastructure system to prove their identity and complete the unique registration and identity binding of the system title includes: S101, Generate and sign a registration request. The client generates a system title registration request, which includes a list of system titles to be registered and metadata of the registration request. The client uses the private key corresponding to the certificate to digitally sign the registration request. The certificate is a valid digital certificate that the client already holds and that has been issued by this public key infrastructure system or a trusted certificate authority with which it has a trusted relationship. S102, Submit Registration Request: The client submits the signed registration request and proof certificate or certificate chain to the public key infrastructure system. S103, PKI system verifies signatures and certificate chains; S104, Uniqueness Check and Binding Registration; S105, Ownership verification during certificate application.

4. The DLMS certificate authentication enhancement method based on client whitelist according to claim 3, characterized in that, Step S103, which involves the PKI system verifying the signature and certificate chain, includes the following verification performed after the PKI system receives the request: The digital signature of the registration request is verified using the public key in the certificate to ensure that the request content has not been tampered with and was indeed initiated by the certificate holder. Verify the validity of the certificate chain to confirm that the certificate was issued by the root certificate authority of this public key infrastructure or a pre-configured trusted certificate authority, that the certificate chain is complete, and that none of the intermediate certificates have been revoked. Check the validity period and revocation status of the certificate; The customer's identity information is extracted from the Subject field of the certificate and used as the subject identifier for subsequent binding.

5. The DLMS certificate authentication enhancement method based on client whitelist according to claim 4, characterized in that, Check the revocation status of a certificate using a Certificate Revocation List (CRL) or an Online Certificate Status Protocol (OCSP). The identity information includes the organization name and organization code.

6. The DLMS certificate authentication enhancement method based on client whitelist according to claim 4, characterized in that, The uniqueness check and binding registration in step S104 include: The public key infrastructure system queries its registration database to check whether the system title to be registered has already been registered by other clients. If the system has already registered, the registration request will be rejected and a system title conflict error message will be returned to the customer. If not registered, the system title is bound to the customer identity information extracted from the certificate, and the registration status is marked as registered. At the same time, the public key infrastructure system records the certificate information on which this registration is based.

7. The DLMS certificate authentication enhancement method based on client whitelist according to claim 4, characterized in that, The attribution verification during certificate application as described in step S105 includes: The customer generates a certificate application request, in which the CN field is filled with the registered system title, and the customer signs the application request using the private key corresponding to a valid certificate held by the customer; After the public key infrastructure system verifies the signature, it extracts the customer identity information represented by the signature certificate and compares it with the customer identity information bound to the system title in the registration database; The public key infrastructure system will only consider the certificate application legitimate and issue a client certificate containing the system's header as the CN if the identities of the two parties match; otherwise, it will refuse to issue the certificate.

8. The DLMS certificate authentication enhancement method based on client whitelist according to claim 1, characterized in that, The secure generation, distribution, and burning of the client whitelist in step S20 includes: S201, The customer determines the system titles of all clients that need to access a certain batch of electricity meters, and generates a whitelist of client system titles; S202, The customer provides the whitelist to the meter manufacturer through a secure channel; S203, during the production process, the manufacturer writes the whitelist into the non-volatile memory of the electricity meter using a secure programming tool, and the whitelist storage area has a hardware or software protection mechanism to prevent tampering.

9. A DLMS certificate authentication enhancement system based on a client whitelist, used to implement the method of any one of claims 1-8, characterized in that, This includes public key infrastructure systems, client systems, electricity meter manufacturing systems, and smart meters; The public key infrastructure system is used to issue digital certificates, maintain the unique registration of system headers, and verify customer identity. The client system registers its client's system title with the public key infrastructure system; The meter manufacturing system is responsible for the production of the smart meters and securely pre-installs the client whitelist into the smart meters before they leave the factory. The smart meter is a DLMS server. The smart meter stores a whitelist of clients and determines whether to authorize client access based on the whitelist during the authentication phase.

Images