An Internet of Things smart meter production test system and security protection method

Abstract

The present invention discloses an IoT smart meter production test system and security protection method. The existing meters lack security and confidentiality measures in the production test link, and there is a problem of information leakage. The system includes a meter end, an operation and maintenance server end, and a cloud end connected in sequence through encrypted communication. The meter end is connected to a trusted test tool, and the trusted test tool is connected to the cloud end through encrypted communication. During the production test of the meter end, the content that the operator contacts is encrypted, all the content burned into the MCU controller is verified, and all communications are encrypted communications based on identity authentication, which reduces the risk of leakage from the source.

Description

Technical Field

[0001] The present invention relates to the field of meter safety technology, and in particular to an Internet of Things smart meter production test system and a safety protection method. Background Art

[0002] With the development of Internet of Things technology, the smart meter industry has realized wireless remote monitoring, including data collection and upload, local storage, abnormal monitoring, remote upgrade, valve control, etc. The current mainstream solution uses wireless communication modules to interact with application platforms. Due to cost and operation and maintenance considerations, security is not taken seriously. Most meter devices on the market do not have security protection measures, and their communication links and MCU are exposed to attackers.

[0003] Metering equipment usually uses MCUs without a secure core architecture, executes code on a bare metal basis, has no secure software architecture, and does not have a trusted MCU internal execution environment.

[0004] The most common solution with security protection is the SE solution, which is to add a secure SE module outside the MCU. Its main functions include: secure storage of keys, data encryption and decryption operations, and secure storage of information. The secure storage of keys can establish a relatively complete key management system to ensure that the keys cannot be read. Data encryption and decryption operations include support for common security algorithms, sensitive data ciphertext transmission, and data transmission tamper-proofing. Information security storage includes strict file access permission mechanisms and reliable authentication algorithms and processes.

[0005] However, the prior art also has the following disadvantages:

[0006] 1) The SE solution only ensures relative security within the SE module, but the communication interface with the MCU is exposed. An attacker may also obtain decrypted data by monitoring the communication interface.

[0007] 2) The SE solution cannot guarantee the internal security of the MCU, nor can it guarantee the safe startup and upgrade of the MCU. Once the MCU is cracked, the SE chip becomes useless. External SE chips also increase device costs.

[0008] 3) For devices with unencrypted communication, the MCU exchanges data with the communication module through the interface. The debugging tool can be used to read the interaction data from the device to the cloud to analyze the protocol and forge false data. Without a trusted identity authentication mechanism, it is easy to forge devices and servers. In addition, encryption is also used in device communication, including symmetric encryption and asymmetric encryption. Devices generally use one of these methods.

[0009] 4) For MCUs without secure hardware and software architecture, debugging tools can be used to read and tamper with the MCU internals to forge illegal devices.

[0010] 5) In the existing equipment production and testing process, there are no strict confidentiality measures for the code burning process, which may leak information from the source.

[0011] The existing technology has begun to pay attention to protecting the security of meters in hardware and software, but there is still a lack of security protection in the production test link. Therefore, it is necessary to design a production test security protection system and a corresponding production test security protection method to protect the meter information from the source. Summary of the invention

[0012] The present invention mainly solves the problem of lack of security and confidentiality measures in the production and testing link of meters in the prior art, and the existence of information leakage, and provides an Internet of Things smart meter production and testing system and a security protection method.

[0013] The above technical problems of the present invention are mainly solved by the following technical solutions: a production test system of an Internet of Things smart meter, including a meter end, an operation and maintenance server end and a cloud end connected in sequence through encrypted communication, a trusted test tool connected to the meter end, and the trusted test tool connected to the cloud end through encrypted communication, and the meter end includes an MCU controller, the MCU controller includes a secure world part and a non-secure world part, a trusted execution environment is deployed in the secure world part, and a non-secure environment is deployed in the non-secure world part, and a secure kernel module, a boot loader module, an OTA upgrade module, a security service module, a security driver module and a secure API interface module are arranged in the trusted execution environment, and a user application CA module and a non-secure kernel module are arranged in the non-secure environment. In the present invention, the operation and maintenance server end and the test server end are both in the cloud. All contents burned into the MCU controller are verified, and all communications are encrypted communications based on identity authentication, including encrypted communications between the meter end and the operation and maintenance server end, encrypted communications between the operation and maintenance server end and the cloud end, and encrypted communications between the cloud end and the trusted test tool. The security of the production test link of the meter end is guaranteed. The present invention protects the meter end from both hardware security and software security, solves the security loopholes in the meter end software, prevents the meter end from being manipulated by other hardware devices, and prevents malicious software from being cracked. Even after the meter end is dismantled, it is impossible to read valid information, reducing the risk of cup cracking and counterfeiting by other manufacturers. In the present invention, the MCU controller supports a secure kernel architecture, and the MCU controller is divided into a secure world part and a non-secure world part. The secure world part can access all resources, and the non-secure world part can only access non-secure world resources and is prohibited from accessing secure world resources. When the non-secure world illegally accesses secure world resources, the MCU controller intercepts and generates an exception from the hardware. The secure world part and the non-secure world part can be switched through a secure API interface module and are strictly monitored by the MCU controller. Software security protection is based on the trusted firmware framework of the MCU kernel. A trusted execution environment TEE is deployed in the secure world part, and a non-secure environment NSE is deployed in the non-secure world. Corresponding functional modules are respectively set in the trusted execution environment and the non-secure environment, which plays a role in software security protection and prevents the software from being maliciously cracked.

[0014] Security kernel module: creates, schedules and communicates multi-tasking threads, and creates isolated security partitions;

[0015] Boot loader module: Start application firmware in a fixed order, and perform root of trust, security attribute configuration, application firmware legitimacy and application firmware update detection on the application firmware. The application firmware includes secure application firmware and non-secure application firmware.

[0016] Trust root detection ensures the security of the boot loader module. After the meter is powered on, the boot loader module is started first and then the application firmware.

[0017] The startup loading module detects the security-related registers of the MCU controller to determine whether the security attribute configuration meets the requirements and ensure a secure hardware environment.

[0018] Before the boot loader module starts the application firmware, it verifies the signature carried by the application firmware online to determine its legitimacy. Only then will the application firmware start. The application firmware will be verified every time it starts.

[0019] Before the boot loader module starts the application firmware, it detects new application firmware information, verifies the legitimacy of the application firmware through the signature, and replaces the old application firmware if the new application firmware is legitimate, and then starts the new application firmware.

[0020] OTA upgrade module: remotely upgrade the application firmware; first use the signature algorithm to sign the original application firmware, and then encrypt it. The meter end downloads the encrypted application firmware, and after the meter end decrypts the application firmware, it verifies the signature. If the signature is legal, the meter end is restarted to update the firmware.

[0021] Security service module: including secure storage, encryption and decryption library, and security function module; different function modules use different security partitions and do not interfere with each other.

[0022] Secure storage is used to encrypt sensitive information and save it in the secure storage area of ​​the trusted execution environment TEE. Sensitive information includes device ID, cloud authentication information, keys, metering data, amount, etc. The encryption and decryption library provides the encryption and decryption functions required by the system.

[0023] Security driver module: including hardware random number generator and hardware encryption and decryption module in a trusted execution environment; specifically including hardware random number generator RNG, hardware encryption and decryption module Crypto and other necessary drivers. The hardware random number generator is used to generate true random numbers, and the hardware encryption and decryption module is used to increase the speed of the encryption and decryption algorithm.

[0024] Security API interface module: Provides a resource calling interface between the trusted execution environment and the non-secure environment. Realizes the switching of the MCU controller between the secure world and the non-secure world. The non-secure environment NSE can call the security services on the trusted execution environment TEE side through the security API interface, and the trusted execution environment TEE can also call the non-secure functions on the NSE side.

[0025] A method for protecting the production test safety of an IoT smart meter comprises the following steps:

[0026] S1. Based on the MCU controller trust root verification, burn the boot loader module, key pair and user certificate; all the contents burned into the MCU controller are verified, and the boot loader module, key pair and user certificate are verified by the MCU controller trust root. The boot loader module adopts a fixed order boot mechanism to prevent the application firmware from bypassing a series of security checks of the boot loader module and entering the application area.

[0027] S2. The boot loader module manages the flash partitions and initializes the security configuration registers. Different partitions in the partition management store different data and codes, initialize the security configuration registers, and configure a trusted hardware environment.

[0028] S3. Burn the encrypted application firmware and decrypt the application firmware and write it into the application area; since the key pair has been imported into the MCU controller before, the encrypted application firmware cannot be decrypted and run after being burned into other MCU controllers, thus ensuring the security of the application firmware after burning.

[0029] S4. Generate and burn cloud authentication information, and the meter end verifies the authentication information;

[0030] S5. Set to factory default mode.

[0031] During the production test on the meter side, all content accessed by operators is encrypted, all content burned into the MCU controller is verified, and all communications are encrypted communications based on identity authentication, reducing the risk of leakage at the source.

[0032] As a preferred solution, the specific process of step S3 includes:

[0033] S31. Burn the encrypted application firmware;

[0034] S32. The application firmware is decrypted by the boot loader module in the trusted execution environment;

[0035] S33. Verify whether the application firmware is legal through signature. If so, absorb the application firmware into the application area. If not, report an error. In this solution, the application firmware must be verified by the boot loader module to ensure the security of the burned content.

[0036] As a preferred solution, the specific process of step S4 includes:

[0037] S41 cloud generates cloud authentication information, cloud authentication information includes device ID, cloud application account, cloud application account password;

[0038] S42. The cloud sends the cloud authentication information to the trusted test tooling to burn it into the meter end, and the cloud registers with the operation and maintenance server end according to the cloud authentication information;

[0039] S43. The meter sends a request to access the operation and maintenance server. The operation and maintenance server determines whether the meter is registered. If so, it sends a test command to the meter and proceeds to the next step. If not, it prompts that the test is abnormal. Unregistered meters cannot connect to the operation server.

[0040] S44. The operation and maintenance server determines whether it has received a response from the meter. If so, it indicates that the meter function and communication are normal and proceeds to the next step. If not, it indicates that the test is abnormal.

[0041] As a preferred solution, the specific process of step S5 includes: closing the DEBUG pin at the meter end and activating the hardware read-write protection. After entering the factory settings, the application firmware in the MCU controller cannot be read in any way, except that the OTA upgrade module cannot change the application firmware in the MCU controller in any way.

[0042] As a preferred solution, the specific process of encrypted communication includes:

[0043] a. Both parties in communication hold their own key pair, CA root certificate, and user certificate issued by CA, where the user certificate includes the user's own public key, identity information, and CA certificate signature;

[0044] b. The two communicating parties establish a communication link and exchange their respective certificates;

[0045] c. Both parties in communication authenticate each other's identity;

[0046] d. After identity authentication, the two communicating parties use an asymmetric method to negotiate a symmetric key;

[0047] e. Encrypt and decrypt information in communication based on the calculated symmetric encryption.

[0048] This solution combines the advantages of symmetric and asymmetric encryption methods. The symmetric key is negotiated using the asymmetric method, and then the symmetric key is used for subsequent encrypted communication. It has high security and efficiency, and solves the security risk of eavesdropping in the communication link. The symmetric key is renegotiated regularly, and mutual identity authentication is performed before each negotiation.

[0049] As a preferred solution, the specific process of step c includes:

[0050] c1. One of the communicating parties obtains the CA public key from the CA root certificate;

[0051] c2. Use the CA public key to verify the user certificate of the other party in the communication. If the verification is successful, the user certificate of the other party in the communication is judged to be authentic, and the process goes to step S04. If the verification is not successful, the user certificate of the other party in the communication is judged to be unauthentic, and an error is reported. The two parties in the communication verify the authenticity of each other's user certificates through this method. Identity authentication uses a digital certificate signed and issued by a trusted institution CA. A digital certificate is an electronic file that can be used to verify the identity of the public key holder. The content contains public key related information, user identity information and the signature of the certificate issuer, which can solve the problem of intruders replacing public keys to attack the system.

[0052] As a preferred solution, the specific process of step d includes:

[0053] d1. Both parties reach a consensus in advance and use the same algorithm parameters;

[0054] d2. After the user certificate is verified, the communicating parties obtain each other's public key from the other party's user certificate;

[0055] d3. One party in communication uses hardware to generate true random numbers and generate private parameter A;

[0056] d4. Use the private parameter A to calculate the shared parameter A according to the algorithm;

[0057] d5. One party in communication packages the shared parameter A and the algorithm description information, encrypts it using the public key of the other party in communication, and sends it to the other party in communication;

[0058] d6. The other party in communication uses its own private key to decrypt and obtain the shared parameter A and algorithm description information;

[0059] d7. Repeat steps d3-d6 at the same time, the other party of the communication generates the private parameter B, and the communication party obtains the shared parameter B and algorithm description information;

[0060] d8. The communicating parties use the same algorithm to calculate the same key based on their own private parameters and the other party's shared parameters. This key is used as the symmetric encryption key for subsequent communications.

[0061] In this scheme, one party in communication uses its own private parameters and the other party's shared parameters to calculate with the same algorithm. Since both contain its own private parameters and the other party's private parameters, the same key can be calculated through the same algorithm. Through the above calculation, the symmetric key is negotiated for subsequent communication encryption and decryption. Since the symmetric encryption and asymmetric encryption methods are integrated, not only the security is improved, but also the speed and efficiency are improved.

[0062] Therefore, the advantages of the present invention are:

[0063] 1. All contents burned into the MCU controller are verified, and all communications are encrypted communications based on identity authentication, which prevents information leakage during the production test and ensures the security of the production test link at the meter end;

[0064] 2. The meter end is protected from both hardware and software security aspects, solving security vulnerabilities in the meter end software, preventing the meter end from being controlled by other hardware devices, and preventing malicious software cracking.

[0065] 3. The security of encryption and decryption is enhanced in communication, and the security risk of eavesdropping in the communication link is solved. The advantages of symmetric and asymmetric encryption methods are combined, and the symmetric key is negotiated in an asymmetric way, and then the symmetric key is used for subsequent encrypted communication, which has high security and high efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0066] Figure 1 It is a structural block diagram of the present invention;

[0067] Figure 2 It is a schematic diagram of the architecture of the MCU controller in the present invention;

[0068] Figure 3 It is a flow chart of the production test safety protection method of the present invention;

[0069] Figure 4 It is a flow chart of encryption and decryption communication in the present invention.

[0070] 1- Meter end 2- Operation and maintenance server end 3- Cloud 4- Trusted test tooling 5- Secure world part 6- Non-secure world part 7- Trusted execution environment 8- Non-secure environment 9- Secure kernel module 10- Boot loading module 11- Security service module 12- Security driver module 13- OTA upgrade module 14- Security API interface module 15- CA module 16- Non-secure kernel module. DETAILED DESCRIPTION

[0071] The technical solution of the present invention is further specifically described below through embodiments and in conjunction with the accompanying drawings.

[0072] Example:

[0073] This embodiment provides an IoT smart meter production test system, such as Figure 1 As shown, it includes the meter end 1, the operation and maintenance server end 2 and the cloud end 3 which are connected in sequence through encrypted communication. The meter end is connected with a trusted test fixture 4, which is connected to the cloud end through encrypted communication. All the contents burned into the MCU controller are verified, and all communications are encrypted communications based on identity authentication, which ensures the security of the production test link of the meter end.

[0074] The meter end includes an MCU controller, such as Figure 2 As shown, the MCU controller includes a secure world part 5 and a non-secure world part 6, a trusted execution environment 7 is deployed in the secure world part, and a non-secure environment 8 is deployed in the non-secure world part. A secure kernel module 9, a boot loader module 10, an OTA upgrade module 13, a security service module 11, a secure driver module 12 and a secure API interface module 14 are set in the trusted execution environment, and a user application CA module 15 and a non-secure kernel module 16 are set in the non-secure environment.

[0075] Security kernel module: creates, schedules and communicates multi-tasking threads, and creates isolated security partitions;

[0076] Boot loader module: Start application firmware in a fixed order, and perform root of trust, security attribute configuration, application firmware legitimacy and application firmware update detection on the application firmware. The application firmware includes secure application firmware and non-secure application firmware.

[0077] Trust root detection ensures the security of the boot loader module. After the meter is powered on, the boot loader module is started first and then the application firmware.

[0078] The startup loading module detects the security-related registers of the MCU controller to determine whether the security attribute configuration meets the requirements and ensure a secure hardware environment.

[0079] Before the boot loader module starts the application firmware, it verifies the signature carried by the application firmware online to determine its legitimacy. Only then will the application firmware start. The application firmware will be verified every time it starts.

[0080] Before the boot loader module starts the application firmware, it detects new application firmware information, verifies the legitimacy of the application firmware through the signature, and replaces the old application firmware if the new application firmware is legitimate, and then starts the new application firmware.

[0081] OTA upgrade module: remotely upgrade the application firmware; first use the signature algorithm to sign the original application firmware, and then encrypt it. The meter end downloads the encrypted application firmware, and after the meter end decrypts the application firmware, it verifies the signature. If the signature is legal, the meter end is restarted to update the firmware.

[0082] Security service module: including secure storage, encryption and decryption library, and security function module; different function modules use different security partitions and do not interfere with each other.

[0083] Secure storage is used to encrypt sensitive information and save it in the secure storage area of ​​the trusted execution environment TEE. Sensitive information includes device ID, cloud authentication information, keys, metering data, amount, etc. The encryption and decryption library provides the encryption and decryption functions required by the system.

[0084] Security driver module: including hardware random number generator and hardware encryption and decryption module in a trusted execution environment; specifically including hardware random number generator RNG, hardware encryption and decryption module Crypto and other necessary drivers. The hardware random number generator is used to generate true random numbers, and the hardware encryption and decryption module is used to increase the speed of the encryption and decryption algorithm.

[0085] Security API interface module: Provides a resource calling interface between the trusted execution environment and the non-secure environment. Realizes the switching of the MCU controller between the secure world and the non-secure world. The non-secure environment NSE can call the security services on the trusted execution environment TEE side through the security API interface, and the trusted execution environment TEE can also call the non-secure functions on the NSE side.

[0086] A safety protection method for production test of smart meters in the Internet of Things, such as Figure 3 As shown, the following steps are included:

[0087] S1. Based on the MCU controller trust root verification, burn the boot loader module, key pair and user certificate; all the contents burned into the MCU controller are verified, and the boot loader module, key pair and user certificate are verified by the MCU controller trust root. The boot loader module adopts a fixed order boot mechanism to prevent the application firmware from bypassing a series of security checks of the boot loader module and entering the application area.

[0088] S2. The boot loader module manages the flash partitions, stores different data and codes in different partitions, initializes the security configuration registers, and configures a trusted hardware environment;

[0089] S3. Burn the encrypted application firmware and decrypt the application firmware and write it into the application area; the specific process includes:

[0090] S31. Burn the encrypted application firmware;

[0091] S32. The application firmware is decrypted by the boot loader module in the trusted execution environment;

[0092] S33. Verify whether the application firmware is legitimate through signature. If yes, absorb the application firmware into the application area. If no, report an error. Since the key pair has been imported into the MCU controller before, the encrypted application firmware cannot be decrypted and run after being burned into other MCU controllers, ensuring the security of the application firmware after burning.

[0093] S4. Generate and burn cloud authentication information, and the meter end verifies the authentication information; the specific process includes:

[0094] S41 cloud generates cloud authentication information, cloud authentication information includes device ID, cloud application account, cloud application account password;

[0095] S42. The cloud sends the cloud authentication information to the trusted test tooling to burn it into the meter end, and the cloud registers with the operation and maintenance server end according to the cloud authentication information;

[0096] S43. The meter sends a request to access the operation and maintenance server. The operation and maintenance server determines whether the meter is registered. If so, it sends a test command to the meter and proceeds to the next step. If not, it prompts that the test is abnormal. Unregistered meters cannot connect to the operation server.

[0097] S44. The operation and maintenance server determines whether it has received a response from the meter. If so, it indicates that the meter function and communication are normal and proceeds to the next step. If not, it indicates that the test is abnormal.

[0098] S5. Set the factory mode, including closing the DEBUG pin on the meter end and activating the hardware read-write protection. After entering the factory settings, the application firmware in the MCU controller cannot be read by any means, except that the OTA upgrade module cannot change the application firmware in the MCU controller by any means.

[0099] All communications during the above review and testing security protection method are encrypted communications based on identity authentication. The specific process includes:

[0100] a. Both parties in communication hold their own key pair, CA root certificate, and user certificate issued by CA, where the user certificate includes the user's own public key, identity information, and CA certificate signature;

[0101] b. The two communicating parties establish a communication link and exchange their respective certificates;

[0102] c. Both parties in communication authenticate each other's identity. The specific process includes:

[0103] c1. One of the communicating parties obtains the CA public key from the CA root certificate;

[0104] c2. Use the CA public key to verify the user certificate of the other party in the communication. If the verification is successful, the user certificate of the other party in the communication is determined to be authentic, and the process proceeds to step S04. If the verification fails, the user certificate of the other party in the communication is determined to be non-authentic, and an error is reported.

[0105] d. After identity authentication, the two communicating parties use an asymmetric method to negotiate a symmetric key. The specific process includes:

[0106] d1. The two communicating parties reach a consensus in advance and use the same algorithm parameters;

[0107] d2. After the user certificate is verified, the communicating parties obtain each other's public key from the other party's user certificate;

[0108] d3. One party in communication uses hardware to generate true random numbers and generate private parameter A;

[0109] d4. Use the private parameter A to calculate the shared parameter A according to the algorithm;

[0110] d5. One party in communication packages the shared parameter A and the algorithm description information, encrypts it using the public key of the other party in communication, and sends it to the other party in communication;

[0111] d6. The other party in communication uses its own private key to decrypt and obtain the shared parameter A and algorithm description information;

[0112] d7. Repeat steps d3-d6 at the same time, the other party of the communication generates the private parameter B, and the communication party obtains the shared parameter B and algorithm description information;

[0113] d8. The communicating parties use the same algorithm to calculate the same key based on their own private parameters and the other party's shared parameters. This key is used as the symmetric encryption key for subsequent communications.

[0114] e. Encrypt and decrypt information in communication based on the calculated symmetric encryption.

[0115] like Figure 4 As shown, the following is a specific description using the example of user A and user B.

[0116] User A includes CA root certificate, user certificate A and key pair, and the key pair includes public key A and key A. User B includes CA root certificate, user certificate B and key pair, and the key pair includes public key B and key B. In addition, user A and user B reach a consensus in advance and use the same algorithm parameters.

[0117] User A and user B establish a communication link and send their respective user certificates to each other, that is, exchange their respective user certificates.

[0118] The communicating parties perform identity authentication. User A obtains the CA public key from the CA root certificate; uses the CA public key to verify the user certificate of communicating user B. If the verification is successful, the user certificate of user B is judged to be authentic. If the verification fails, the user certificate of user B is judged to be inauthentic and an error is reported. Similarly, user B obtains the CA public key from the CA root certificate; uses the CA public key to verify the user certificate of communicating user A. If the verification is successful, the user certificate of user A is judged to be authentic. If the verification fails, the user certificate of user A is judged to be inauthentic and an error is reported.

[0119] After passing identity authentication, user A obtains public key B from user B's user certificate, and user B obtains public key A from user A's user certificate.

[0120] User A uses hardware to generate true random numbers, generates private parameter A, and uses private parameter A to calculate shared parameter A according to the algorithm.

[0121] User A packages the shared parameter A and algorithm description information, encrypts it using user B's public key B, and sends it to user B.

[0122] User B uses his own private key to decrypt and obtain the shared parameter A and algorithm description information.

[0123] Similarly, using the above steps, user B generates private parameter B, and user A obtains shared parameter B and algorithm description information.

[0124] User A and user B use the same algorithm to calculate the same key based on their own private parameters and the other party's shared parameters. This key is used as the symmetric encryption key for subsequent communications.

[0125] This method combines the advantages of symmetric encryption and asymmetric encryption. The symmetric key is negotiated through asymmetric encryption, and subsequent communication encryption and decryption is performed, which not only improves security, but also improves speed and efficiency.

[0126] The specific embodiments described herein are merely examples of the spirit of the present invention. Those skilled in the art may make various modifications or additions to the specific embodiments described or replace them in similar ways, but they will not deviate from the spirit of the present invention or exceed the scope defined by the appended claims.

[0127] Although this article uses more terms such as meter end, operation and maintenance server end, cloud, trusted test tool 5-safe world part, it does not exclude the possibility of using other terms. These terms are used only to more conveniently describe and explain the essence of the present invention; interpreting them as any additional restrictions is contrary to the spirit of the present invention.

Claims

1. An IoT smart meter production test system, characterized by: The invention comprises a meter end (1), an operation and maintenance server end (2) and a cloud end (3) which are connected in sequence through encrypted communication, a trusted test fixture (4) being connected to the meter end, and the trusted test fixture being connected to the cloud end through encrypted communication, and the meter end comprises an MCU controller, the MCU controller comprising a secure world part (5) and a non-secure world part (6), a trusted execution environment (7) being deployed in the secure world part, and a non-secure environment (8) being deployed in the non-secure world part, a secure kernel module (9), a boot loader module (10), an OTA upgrade module (13), a secure service module (11), a secure driver module (12) and a secure API interface module (14) being arranged in the non-secure environment, and a user application CA module (15) and a non-secure kernel module (16) being arranged in the non-secure environment; MCU controller: Based on the MCU controller trust root verification, burn the boot loader module, key pair and user certificate; The boot loader module manages the flash partitions and initializes the security configuration registers; burns the encrypted application firmware, decrypts the application firmware in the trusted execution environment by the boot loader module, verifies whether the application firmware is legitimate through the signature, and if so, writes the application firmware into the application area; Cloud: Generate cloud authentication information; Trusted test tooling: burn cloud authentication information; Meter end: perform authentication information verification.

2. A method for protecting the production test safety of an IoT smart meter, using the system in claim 1, characterized in that: The following steps are included: S1. Based on the MCU controller trust root verification, burn the boot loader module, key pair and user certificate; S2. The boot loader module manages the flash partitions and initializes the security configuration registers; S3. Burn the encrypted application firmware, decrypt the application firmware by the boot loader module in the trusted execution environment, and write it into the application area after verifying the legitimacy of the application firmware through the signature; S4. Generate and burn cloud authentication information, and the meter end verifies the authentication information; S5. Set to factory default mode.

3. According to claim 2, a method for protecting the production and testing safety of an IoT smart meter is characterized in that The specific process of step S3 includes: S31. Burn the encrypted application firmware; S32. The application firmware is decrypted by the boot loader module in the trusted execution environment; S33. Verify whether the application firmware is legal through signature. If so, absorb the application firmware into the application area. If not, report an error.

4. The IoT smart meter production test safety protection method according to claim 2 is characterized by: The specific process of step S4 includes: S41 cloud generates cloud authentication information, cloud authentication information includes device ID, cloud application account, cloud application account password; S42. The cloud sends the cloud authentication information to the trusted test tooling to burn it into the meter end, and the cloud registers with the operation and maintenance server end according to the cloud authentication information; S43. The meter sends a request to access the operation and maintenance server. The operation and maintenance server determines whether the meter is registered. If so, it sends a test command to the meter and proceeds to the next step. If not, it prompts a test abnormality. S44. The operation and maintenance server determines whether it has received a response from the meter. If so, it indicates that the meter function and communication are normal and proceeds to the next step. If not, it indicates that the test is abnormal.

5. The IoT smart meter production test safety protection method according to claim 2 is characterized by: The specific process of step S5 includes: closing the DEBUG pin at the meter end and activating the hardware read-write protection.

6. A method for protecting the production and testing safety of an IoT smart meter according to any one of claims 2 to 5, characterized in that: The specific process of encrypted communication includes: a. Both parties in communication hold their own key pair, CA root certificate, and user certificate issued by CA, where the user certificate includes the user's own public key, identity information, and CA certificate signature; b. The two communicating parties establish a communication link and exchange their respective certificates; c. Both parties in communication authenticate each other's identity; d. After identity authentication, the two communicating parties use an asymmetric method to negotiate a symmetric key; e. Encrypt and decrypt information in communication based on the calculated symmetric encryption.

7. The IoT smart meter production test safety protection method according to claim 6 is characterized by: The specific process of step c includes: c1. One of the communicating parties obtains the CA public key from the CA root certificate; c2. Use the CA public key to verify the user certificate of the other party in the communication. If the verification is successful, the user certificate of the other party in the communication is determined to be authentic, and the process proceeds to step S04. If the verification fails, the user certificate of the other party in the communication is determined to be non-authentic, and an error is reported.

8. The IoT smart meter production test safety protection method according to claim 6 is characterized by: The specific process of step d includes: d1. Both parties reach a consensus in advance and use the same algorithm parameters; d2. After the user certificate is verified, the communicating parties obtain each other's public key from the other party's user certificate; d3. One party in communication uses hardware to generate true random numbers and generate private parameter A; d4. Use the private parameter A to calculate the shared parameter A according to the algorithm; d5. One party in communication packages the shared parameter A and the algorithm description information, encrypts it using the public key of the other party in communication, and sends it to the other party in communication; d6. The other party in communication uses its own private key to decrypt and obtain the shared parameter A and algorithm description information; d7. Repeat steps d3-d6 at the same time, the other party of the communication generates the private parameter B, and the communication party obtains the shared parameter B and algorithm description information; d8. The communicating parties use the same algorithm to calculate the same key based on their own private parameters and the other party's shared parameters. This key is used as the symmetric encryption key for subsequent communications.

Images