Equipment processing method and device, storage medium and electronic equipment

Abstract

The invention discloses an equipment processing method and device, a storage medium and electronic equipment. Relates to the technical field of device control, and the method comprises the following steps: a first device and a second device realize device discovery based on a target request packet, and the first device performs bidirectional authentication with the second device based on a preset pre-shared key so as to establish communication between the first device and the second device; after communication between the first device and the second device is established, the first device converts collected original data of a detection point into a plaintext engineering value, generates target data according to the plaintext engineering value, a standard field name corresponding to the plaintext engineering value and a device identifier, and sends the target data to the second device. And sending the target data to the second equipment so as to carry out data processing through the second equipment. Through application of the method and the device, the problem that the efficiency of acquiring the monitoring data is relatively low because the configuration of the communication parameters of the monitoring unit accessing the monitoring equipment is tedious in the related technology is solved.

Description

Technical Field

[0001] This application relates to the field of equipment control technology, and more specifically, to a processing method and apparatus for an equipment, a storage medium, and an electronic device. Background Technology

[0002] In the field of power environment monitoring (PEM) technology, especially in complex environments such as communication base stations and data centers, when monitoring units (SUs) connect to various monitoring devices, they mainly rely on wired serial communication such as RS485 (a standard interface for serial communication) and RS232 (a standard interface for serial communication), with a small number using Ethernet communication methods such as RJ45 (a standard interface for network connection). However, these traditional communication access methods have a series of limitations and challenges, which seriously affect the efficiency and reliability of the monitoring system.

[0003] The process of obtaining communication parameters in serial and network communication methods is extremely cumbersome. When performing serial communication, it is necessary to accurately set the baud rate, data bits, stop bits, parity bits, etc. There are many parameter combinations, with more than 70 common combinations. Moreover, there is a lack of intuitive configuration guidance, which leads to a large workload for on-site debugging and maintenance, and the risk of equipment configuration errors is also increased accordingly.

[0004] There is currently no effective solution to the problem that the communication parameter configuration for the monitoring unit to access the monitoring equipment is cumbersome, resulting in low efficiency in obtaining monitoring data. Summary of the Invention

[0005] The main objective of this application is to provide a processing method and apparatus, storage medium and electronic device to solve the problem in the related art where the communication parameter configuration of the monitoring unit to the monitoring device is cumbersome, resulting in low efficiency in obtaining monitoring data.

[0006] To achieve the above objectives, according to one aspect of this application, a device processing method is provided. The method includes: a first device and a second device performing device discovery based on a target request packet, wherein the target request packet includes at least: address information of the first device and first preset identification information; the first device and the second device performing bidirectional authentication based on a preset pre-shared key to establish communication between the first device and the second device; after establishing communication between the first device and the second device, the first device converts the raw data of the collected detection points into plaintext engineered values, generates target data based on the plaintext engineered values, the standard field name corresponding to the plaintext engineered values, and a device identifier, and sends the target data to the second device for data processing by the second device.

[0007] Furthermore, the device discovery mechanism based on the target request packet includes: the first device broadcasting the target request packet to the target network segment; the second device capturing the target request packet in the target network segment and parsing the target request packet to obtain parsed second preset identification information; and verifying based on the parsed second preset identification information. If the verification is successful, the second device sending a unicast probe message to the first device based on the address information of the first device; the first device returning model parameter information based on the received unicast probe message to achieve device discovery.

[0008] Furthermore, before the first device broadcasts the target request packet to the target network segment, the method further includes: generating an initial request packet based on the address information of the first device; adding the first preset identifier information to the end of the frame of the initial request packet to obtain a processed initial request packet; and filling the processed initial request packet with preset characters to obtain the target request packet.

[0009] Furthermore, the first device performs two-way authentication with the second device based on a preset pre-shared key to establish communication between the first device and the second device, including: the first device and the second device performing authentication initialization; after the authentication initialization is completed, the first device and the second device perform key exchange based on the pre-shared key; after the key exchange is completed, the first device and the second device perform two-way authentication to establish communication between the first device and the second device.

[0010] Further, the authentication initialization between the first device and the second device includes: the first device generating a first greeting message based on a list of cipher suites and a first random number, and sending the first greeting message to the second device, wherein the cipher suite specifies the algorithm used to encrypt and decrypt data; the second device generating a second greeting message based on the identifier of the target cipher suite and a second random number, and returning the second greeting message to the first device to complete the authentication initialization, wherein the target cipher suite is selected from the list of cipher suites.

[0011] Further, after authentication initialization is completed, the first device performs key exchange with the second device based on the pre-shared key, including: the first device receiving a first key exchange message sent by the second device, wherein the first key exchange message is obtained by encrypting the first random number, the second random number, and the first key of the second device based on the first private key of the second device; if the first device verifies the first key exchange message, the first device sends second key exchange information to the second device to complete the key exchange, wherein the second key exchange information is obtained by encrypting the second key of the first device and the first binding proof of the pre-shared key based on the second private key of the first device, and the first binding proof of the pre-shared key is obtained through the pre-shared key and the handshake message generated during the authentication initialization phase.

[0012] Further, after the key exchange is completed, the first device and the second device perform two-way authentication to establish communication between the first device and the second device, including: the first device sending first key change specification information to the second device, wherein the first key change specification information is used to notify the second device to start encrypting data using the target encryption suite and the master key, the master key being obtained based on the pre-shared key, the first key, the second key, the first random number, and the second random number; the first device sending a first completion message to the second device, wherein the first completion message is obtained by encrypting the complete information generated during the establishment of communication between the first device and the second device based on the master key; the first device receiving second key change specification information sent by the second device, wherein if the second device passes the first binding proof verification of the pre-shared key in the first completion message and the second key exchange information, the second device sends the second key change specification information to the first device; the first device receiving the second completion message sent by the second device to establish communication between the first device and the second device.

[0013] Further, the second device obtains the device identifier of the first device and obtains the pre-shared key corresponding to the first device based on the device identifier; obtains a second binding proof based on the pre-shared key corresponding to the first device and the handshake message generated during the authentication initialization phase; and verifies the first binding proof of the pre-shared key in the second key exchange information based on the second binding proof.

[0014] Furthermore, the first device converts the raw data collected from the detection points into plaintext engineered values ​​by: acquiring a preset plaintext engineered value conversion rule; and converting the raw data according to the plaintext engineered value conversion rule to obtain plaintext engineered values.

[0015] Furthermore, the method further includes: if the two-way authentication between the first device and the second device fails, then after a preset time interval, two-way authentication is performed again until authentication is successful or the cumulative number of failures equals a preset threshold; if the cumulative number of failures equals the preset threshold, then a target message is triggered to the target object, wherein the target message is used to instruct the target object to perform security detection on the first device and the second device.

[0016] Furthermore, the method further includes: if a pre-shared key update mechanism is triggered, the first device receives a key rotation instruction; the first device updates the pre-shared key based on the key rotation instruction.

[0017] According to another aspect of the embodiments of this application, a device processing apparatus is also provided, comprising: a discovery unit, configured to enable a first device and a second device to discover the device based on a target request packet, wherein the target request packet includes at least: address information of the first device and first preset identification information; a first authentication unit, configured to enable the first device to perform bidirectional authentication with the second device based on a preset pre-shared key to establish communication between the first device and the second device; and a sending unit, configured to, after establishing communication between the first device and the second device, convert the raw data of the collected detection points into plaintext engineered values, generate target data based on the plaintext engineered values, the standard field name corresponding to the plaintext engineered values, and the device identifier, and send the target data to the second device for data processing by the second device.

[0018] Furthermore, the discovery unit includes: a broadcast module, used by the first device to broadcast the target request packet to the target network segment, wherein the second device captures the target request packet in the target network segment, parses the target request packet to obtain parsed second preset identification information; and performs verification based on the parsed second preset identification information. If the verification is successful, the second device sends a unicast probe message to the first device based on the address information of the first device; and a return module, used by the first device to return model parameter information based on the received unicast probe message, so as to realize device discovery.

[0019] Furthermore, the apparatus further includes: a generation unit, configured to generate an initial request packet based on the address information of the first device before the first device broadcasts the target request packet to the target network segment; an adding unit, configured to add the first preset identification information to the end of the frame of the initial request packet to obtain a processed initial request packet; and a filling unit, configured to fill the processed initial request packet according to preset characters to obtain the target request packet.

[0020] Furthermore, the first authentication unit includes: an initialization module for performing authentication initialization between the first device and the second device; an exchange module for exchanging keys between the first device and the second device based on the pre-shared key after the authentication initialization is completed; and an authentication module for performing bidirectional authentication between the first device and the second device after the key exchange is completed, so as to establish communication between the first device and the second device.

[0021] Furthermore, the initialization module includes a generation submodule, used by the first device to generate a first greeting message based on a list of cipher suites and a first random number, and send the first greeting message to the second device, wherein the cipher suite specifies an algorithm for encrypting and decrypting data, the second device generates a second greeting message based on the identifier of a target cipher suite and a second random number, and returns the second greeting message to the first device to complete the authentication initialization, wherein the target cipher suite is selected from the list of cipher suites.

[0022] Further, the exchange module includes: a first receiving submodule, configured to receive a first key exchange message sent by the second device, wherein the first key exchange message is obtained by encrypting the first random number, the second random number, and the first key of the second device based on the first private key of the second device; and a first sending submodule, configured to send second key exchange information to the second device to complete the key exchange if the first device verifies the first key exchange message, wherein the second key exchange information is obtained by encrypting the second key of the first device and the first binding proof of the pre-shared key based on the second private key of the first device, and the first binding proof of the pre-shared key is obtained through the pre-shared key and the handshake message generated during the authentication initialization phase.

[0023] Further, the authentication module includes: a second sending submodule, used by the first device to send first changed key specification information to the second device, wherein the first changed key specification information is used to notify the second device to start encrypting data using the target encryption suite and the master key, the master key being obtained based on the pre-shared key, the first key, the second key, the first random number, and the second random number; a third sending submodule, used by the first device to send a first completion message to the second device, wherein the first completion message is obtained by encrypting complete information generated during the establishment of communication between the first device and the second device based on the master key; a second receiving submodule, used by the first device to receive second changed key specification information sent by the second device, wherein the second device sends the second changed key specification information to the first device if the second device passes the first binding proof verification of the pre-shared key in the first completion message and the second key exchange information; and a third receiving submodule, used by the first device to receive the second completion message sent by the second device to establish communication between the first device and the second device.

[0024] Further, the second device obtains the device identifier of the first device and obtains the pre-shared key corresponding to the first device based on the device identifier; obtains a second binding proof based on the pre-shared key corresponding to the first device and the handshake message generated during the authentication initialization phase; and verifies the first binding proof of the pre-shared key in the second key exchange information based on the second binding proof.

[0025] Furthermore, the sending unit also includes: an acquisition module for acquiring a preset plaintext engineering value conversion rule; and a conversion module for converting the original data according to the plaintext engineering value conversion rule to obtain a plaintext engineering value.

[0026] Furthermore, the device further includes: a second authentication unit, configured to perform bidirectional authentication again after a preset time interval if the bidirectional authentication between the first device and the second device fails, until authentication is successful or the cumulative number of failures equals a preset threshold; and a triggering unit, configured to trigger a target message to a target object if the cumulative number of failures equals the preset threshold, wherein the target message is used to instruct the target object to perform security detection on the first device and the second device.

[0027] Furthermore, the apparatus further includes: a receiving unit, configured to receive a key rotation instruction if a pre-shared key update mechanism is triggered; and an updating unit, configured to update the pre-shared key based on the key rotation instruction.

[0028] According to another aspect of the present invention, an electronic device is also provided, comprising: a memory storing an executable program; and a processor for running the program, wherein the program executes the device processing method of any of the above-mentioned embodiments during runtime.

[0029] According to another aspect of the present invention, a computer-readable storage medium is also provided, wherein the storage medium stores a program, wherein the processing method of the device where the storage medium is located is executed when the program is running.

[0030] In this embodiment, the following steps are adopted: a first device and a second device discover each other based on a target request packet, wherein the target request packet includes at least: the address information of the first device and the first preset identification information; the first device performs bidirectional authentication with the second device based on a preset pre-shared key to establish communication between the first device and the second device; after establishing communication between the first device and the second device, the first device converts the raw data of the collected detection points into plaintext engineered values, generates target data based on the plaintext engineered values, the standard field names corresponding to the plaintext engineered values, and the device identifier, and sends the target data to the second device for data processing by the second device. This solves the technical problem in related technologies where the communication parameter configuration for the monitoring unit to access the monitoring device is cumbersome, resulting in low efficiency in obtaining monitoring data.

[0031] In this scheme, the first device sends a target request packet containing a first preset identification information, facilitating rapid identification and discovery by the second device. The second device, by monitoring the network, captures and parses the target request packet, extracting the first device's address and identification information, verifying the validity of the identification information, and then sending a unicast probe message to the first device to confirm the device connection and prepare for the next step of security authentication. After automatic device discovery, the first and second devices perform bidirectional authentication based on a pre-shared key, ensuring the legitimacy of both communicating parties, preventing unauthorized devices from impersonating legitimate devices, and establishing a secure data transmission channel. After the secure communication channel is established, the first device can send the collected data to the second device. The first device does not need to manually configure network parameters such as IP address, subnet mask, and gateway, nor does it require complex communication protocol matching. The automatic discovery mechanism and bidirectional authentication mode make the device plug-and-play, reducing the time and manpower costs of device access, thereby achieving the technical effect of improving the efficiency of acquiring monitoring data. Attached Figure Description

[0032] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0033] Figure 1This is a hardware structure block diagram of a computer terminal for implementing a device processing method according to an embodiment of this application;

[0034] Figure 2 This is a flowchart of a processing method for a device provided according to an embodiment of this application;

[0035] Figure 3 This is a schematic diagram of the processing method of the device provided in the embodiments of this application. Figure 1 ;

[0036] Figure 4 This is a schematic diagram of the processing method of the device provided in the embodiments of this application. Figure 2 ;

[0037] Figure 5 This is a schematic diagram of the processing method of the device provided in the embodiments of this application. Figure 3 ;

[0038] Figure 6 This is a schematic diagram of the processing method of the device provided in the embodiments of this application. Figure 4 ;

[0039] Figure 7 This is a schematic diagram of the processing apparatus of the device provided according to the embodiments of this application;

[0040] Figure 8 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0041] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0042] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0043] It should be noted that the information collected in this application (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of this data all comply with relevant laws, regulations, and standards, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding operation entry points are provided for users to choose to authorize or refuse. For example, interfaces are set up between this system and relevant users or organizations, providing users with corresponding operation entry points for them to choose to agree to or refuse automated decision results; if the user chooses to refuse, the process proceeds to the expert decision-making stage.

[0044] Example 1

[0045] According to an embodiment of this application, a method embodiment for processing a device is also provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0046] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware block diagram of a computer terminal (or mobile device) for implementing a processing method of the device is shown. Figure 1As shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0047] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0048] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the processing method of the device in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the above-mentioned device processing method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0049] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0050] The display can be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0051] Under the aforementioned operating environment, this application provides the following: Figure 2 The processing method of the device shown. Figure 2 This is a flowchart of a processing method of the device according to Embodiment 1 of this application. The processing method of the device includes:

[0052] Step S201: The first device and the second device discover the device based on the target request packet, wherein the target request packet includes at least: the address information of the first device and the first preset identification information.

[0053] Optionally, the first device (e.g., monitoring device SM) achieves device discovery with the second device (e.g., monitoring unit SU) by sending a target request packet containing specific information. The target request packet is not only the basis for device discovery but also carries crucial information for identification and configuration. When constructing the target request packet, the first device encapsulates its own address information (such as MAC address and IP address) and a preset first identification information (e.g., the ASCII encoding of "xxtower") into specific fields of the message, such as the padding area of ​​an Ethernet frame or other extensible fields, to ensure that this information does not interfere with the basic functions of standard network communication protocols.

[0054] It should be noted that the primary identification information is key to identifying legitimate devices. It can be a unique string based on the device manufacturer, device type, or security certification, used to highlight the legitimate identity of the monitoring device SM (i.e., the primary device) among multiple devices.

[0055] When a device accesses a network, it can choose to actively broadcast a target request packet to spread its access intent and key identification information within the local network.

[0056] In an optional embodiment, the target request packet may be an ARP (Address Resolution Protocol Message) message. ARP is a protocol used to translate network layer (e.g., IP addresses) into data link layer (e.g., MAC addresses), primarily for communication with devices within a broadcast domain. When a device wants to send data to another device but only knows its IP address and not its MAC address, it sends an ARP request message to inquire which MAC address on the network corresponds to a specific IP address. The receiving device responds with an ARP response message, providing its MAC address, thereby allowing the requesting device to establish direct link layer communication.

[0057] In an optional embodiment, the target request packet can also be a DHCP (Dynamic Host Configuration Protocol) message. DHCP is a network management protocol primarily used for automatically assigning IP addresses and other network configuration parameters. In this embodiment, when the first device starts up, it sends a DHCP request message. Besides requesting an IP address, the message also contains first preset identification information. Upon receiving this DHCP request, the second device or the DHCP server in the network checks the identification information in the request. If the identification information is correct, the DHCP server assigns an IP address and may respond with other network configuration parameters to the first device, while simultaneously informing the second device of the first device's legitimate identity. After receiving the notification from the DHCP server or directly reading the identification information from the DHCP request, the second device can identify the first device as a legitimate monitoring device, and thus establish further communication and data interaction based on the assigned IP address.

[0058] In an optional embodiment, other protocols that can embed preset identification information can also be used to achieve device discovery between the first device and the second device.

[0059] Whether ARP or DHCP is used as the carrier of the target request packet, the goal is to enable the first device to be quickly discovered by the second device with minimal human intervention, and to ensure the legitimacy of the device through preset identification information, thereby building a bridge for subsequent security authentication and data communication.

[0060] In step S202, the first device performs two-way authentication with the second device based on a preset pre-shared key to establish communication between the first device and the second device.

[0061] Optionally, each first device will be assigned a unique device identifier and a corresponding pre-shared key (PSK). This device identifier and PSK can be stored internally by the device for authentication when communicating securely with the monitoring unit (SU) in the future.

[0062] Once the first device is automatically discovered (i.e., after the first and second devices discover each other based on the target request packet), two-way authentication is performed using a pre-shared key. For example, the second device compares its stored PSK with the received PSK to confirm that the first device's PSK matches and its identity is legitimate. Through these steps, the first and second devices can establish a secure communication connection, ensuring the confidentiality and integrity of data transmission. This mechanism not only avoids the complexity of traditional username / password authentication processes but also achieves efficient authentication using a pre-shared key.

[0063] Step S203: After establishing communication between the first device and the second device, the first device converts the raw data of the collected detection points into plaintext engineered values, generates target data based on the plaintext engineered values, the standard field names corresponding to the plaintext engineered values, and the device identifier, and sends the target data to the second device for data processing.

[0064] Optionally, after successfully discovering the device and passing the two-way authentication in step S202, the device performs its monitoring duties and continuously or periodically collects various raw data from the monitored object, which may include, but are not limited to, the device's status parameters, performance indicators, alarm events, etc., depending on the function of the monitoring device and the type of the target device.

[0065] After obtaining the raw data, the first device (SM) performs data conversion, transforming the device-specific encoding into plaintext engineered values ​​with actual physical meaning. For example, a register value is converted to "Phase A voltage = 220 volts". The first device (SM) combines the plaintext engineered values ​​with standard field names to describe the data type and attributes, such as "phase voltage", "humidity", or "temperature". The use of standard field names unifies the representation of data from different devices, facilitating data processing and monitoring by the second device (SU).

[0066] Then, the plaintext engineering values, standard field names, and the device identifier of the first device are combined to form the target data. The device identifier (such as device ID) is used to identify the data source, ensuring that the second device (SU) can trace the specific source of the data. The target data may be in JSON, XML, or other structured data formats, making it easy for machines to read and parse.

[0067] Finally, the first device (SM) sends the target data to the second device (SU) through the previously established PSK-TLS encrypted channel. Upon receiving the target data, the second device (SU) can directly parse and process the data based on the device identifier and standard field names, eliminating the need for further protocol parsing or unit conversion. This simplifies the data processing flow and improves efficiency. Simultaneously, the SU's encryption and decryption capabilities, based on national cryptographic algorithms, ensure the confidentiality and integrity of the data, laying a secure foundation for subsequent data analysis and monitoring.

[0068] It should be noted that the collected data must be processed before being sent to ensure data format standardization and transmission security.

[0069] In an optional embodiment, the first device can send the processed data to the second device via a secure communication channel. Data transmission can employ various mechanisms, such as a custom lightweight interface to the TCP / IP protocol (Transmission Control Protocol / Internet Protocol, the fundamental protocol for computer network communication, supporting the Internet and many of its network services), or efficient protocols like HTTP / 2 (Hypertext Transfer Protocol Version 2, the second major version of the HTTP protocol designed to improve transmission performance, reduce latency, and enhance network connection efficiency). Upon receiving the target data from the first device, the second device can perform functions such as real-time data display, historical data recording, and early warning analysis.

[0070] In summary, the first device sends a target request packet containing a first preset identification information, facilitating rapid identification by the second device. The second device, by monitoring the network, captures and parses the target request packet, extracting the first device's address and identification information, verifying the validity of the identification information, and then sends a unicast probe message to the first device to confirm the device connection and prepare for the next step of security authentication. After automatic device discovery, the first and second devices perform two-way authentication based on a pre-shared key, ensuring the legitimacy of both communicating parties, preventing unauthorized devices from impersonating legitimate devices, and establishing a secure data transmission channel. Once the secure communication channel is established, the first device can send the collected data to the second device. The first device does not need to manually configure network parameters such as IP address, subnet mask, and gateway, nor does it require complex communication protocol matching. The automatic discovery mechanism and two-way authentication mode make the device plug-and-play, reducing the time and manpower costs of device access, thereby achieving the technical effect of improving the efficiency of acquiring monitoring data.

[0071] Optionally, in the device processing method provided in this application embodiment, the device discovery based on the target request packet by the first device and the second device includes: the first device broadcasting the target request packet to the target network segment, wherein the second device captures the target request packet in the target network segment and parses the target request packet to obtain the parsed second preset identification information; and performs verification based on the parsed second preset identification information. If the verification is successful, the second device sends a unicast probe message to the first device based on the address information of the first device; the first device returns model parameter information based on the received unicast probe message to realize device discovery.

[0072] In an optional embodiment, when a first device (such as a monitoring device SM) accesses the network, it broadcasts a target request packet to the target network segment. The target request packet contains basic information about the first device (e.g., IP address and MAC address) and first preset identification information for identity verification. The broadcast method ensures that the request packet can be received by all devices within the network segment, thereby increasing the probability of discovery.

[0073] The second device (such as the monitoring unit SU) listens to communications within the target network segment and captures the target request packet broadcast by the first device. The second device parses the target request packet to obtain the parsed second preset identifier information, which is used to verify whether the first device belongs to its list of legitimate devices. After parsing the second preset identifier information from the request packet, the second device verifies whether this identifier exists in its own legitimate device database. If the verification passes, it indicates that the first device is a legitimate monitoring device and can be further processed; if the verification fails, it may be determined to be an unauthorized or malicious device, and corresponding security measures (such as ignoring the request or triggering an alarm) will be taken.

[0074] After successful verification, the second device will send a unicast probe message to the first device based on the first device's address information (such as IP address or MAC address). The unicast probe message can request more detailed model parameter information from the first device. It should be noted that the unicast probe message is a unicast message. Upon receiving the unicast probe message, the first device will return its model parameter information based on the unicast probe message. This may include, for example, the device model, version, and supported functions.

[0075] After the second device is received and returns detailed information (manufacturer, model, etc.), the automatic device discovery process is completed (i.e., device discovery is achieved).

[0076] In an optional embodiment, ARP packets sent by non-target devices (i.e., devices not in the legitimate device database of the second device) lack specific identification information in their padding area. The monitoring unit (SU) will ignore these packets, and they will not affect the normal ARP communication. The monitoring unit (SU) can also check whether the total length of the ARP packet is compliant (≥64 bytes) during parsing to avoid misidentification caused by truncation of the padding area.

[0077] In an optional embodiment, the monitoring unit (SU) records the MAC address of the discovered device. If it receives an ARP extended packet from the same device again within 5 minutes, it will not initiate another probe, thereby reducing network interaction.

[0078] Through the above process, this application provides a plug-and-play access method for devices, which realizes automatic device discovery and secure access by utilizing the broadcast of target request packets and the verification of preset identification information.

[0079] Optionally, in the processing method of the device provided in the embodiments of this application, before the first device broadcasts the target request packet to the target network segment, the method further includes: generating an initial request packet based on the address information of the first device; adding first preset identification information to the end of the frame of the initial request packet to obtain a processed initial request packet; and filling the processed initial request packet with preset characters to obtain a target request packet.

[0080] In an optional embodiment, the first device generates an initial request packet based on its address information (such as IP address and MAC address). The basic structure of the initial request packet may follow the format of standard network protocols such as ARP (Address Resolution Protocol) or DHCP (Dynamic Host Configuration Protocol), but its content will be customized according to subsequently added preset identification information.

[0081] Based on the initial request packet, the first device adds a pre-defined identifier to the end of the frame. This identifier is a predefined character sequence, such as the ASCII encoding of "xxtower," used by the second device to quickly identify that the request comes from a legitimate monitoring device when the request packet is received and parsed. Placing the identifier in the padding area at the end of the frame does not affect the basic structure and function of the packet, nor does it require complex parameter configuration by the device.

[0082] To ensure that the request packet length meets the minimum frame length requirement of the network protocol (such as Ethernet), the first device pads the processed initial request packet with preset padding characters (such as null characters or specific padding characters) until the minimum length required by the protocol is reached. This padding operation allows the packet to be transmitted smoothly in the network without affecting the valid data, avoiding transmission errors or parsing failures due to insufficient length.

[0083] After the above steps, a target request packet is generated. This packet contains not only the address information of the first device, but also a first preset identifier for quick identification, as well as padding characters added to comply with protocol requirements. The generation of the target request packet ensures that the device can be effectively discovered by the second device during broadcasting, while also reducing network overhead and avoiding unnecessary broadcast storms.

[0084] In an optional embodiment, when the monitoring device (SM) accesses the network and sends an ARP request (to obtain the MAC address of the SU), the following operations are performed: Step 1: Construct an ARP request message in the standard format (opcode = 1), filling in necessary fields such as hardware type, protocol type, and sender / destination address. Step 2: Write a specific identifier field, such as "xxtower" (ASCII encoding, each character occupies 1 byte, totaling 10 bytes), starting from the first byte of the 18-byte padding area, and fill the remaining bytes with 0x00 (to avoid random data interference). Step 3: Send an ARP frame containing an extended identifier through the data link layer, ensuring that the message conforms to the Ethernet frame format (total length ≥ 64 bytes).

[0085] Example message structure (paddled area): 63 68 69 6E 61 74 6F 77 65 72 00 00 00 00 0000 00 00 (The first 10 bytes are the ASCII code of "xxtower", and the last 8 bytes are padded with 0).

[0086] In an optional embodiment, the monitoring unit (SU) needs to enable ARP packet listening mode and identify the target device through the following process: Step 1: Capture all ARP packets within the local network segment, parse the frame structure, and extract the 18-byte padding data. Step 2: Check if the first 10 bytes of the padding are the ASCII encoding of "xxtower" (i.e., 0x6368696E61746F776572). Step 3: If a match is successful, it is determined to be the target device, and the device network information is obtained from the "sender IP address" and "sender MAC address" fields of the ARP packet. Step 4: The monitoring unit (SU) actively sends a unicast probe packet (such as a UDP packet, the target port can be preset to the protocol default port) to the device. After receiving it, the device returns detailed information (manufacturer, model, etc.), completing the automatic device discovery process.

[0087] By embedding a custom identifier in the 18-byte padding area of ​​the ARP packet, network storms, cross-segment restrictions, and security vulnerabilities of UDP broadcast / multicast are avoided, enabling automatic discovery without configuration. By combining ARP extensions with "unicast probe packet responses", device discovery is achieved with "no broadcast, cross-segment compatibility, and low network overhead", and the identifier embedding method (specific characters) ensures compatibility with the standard ARP protocol.

[0088] By embedding specific identification fields in the ARP packet padding area, rapid device discovery is achieved, allowing the acquisition of device network information (such as IP address and MAC address). This information is a necessary prerequisite for subsequent two-way authentication and the establishment of secure communication connections. Without accurate device discovery, subsequent secure access and data exchange cannot be performed accurately.

[0089] Optionally, in the processing method of the device provided in the embodiments of this application, the first device performs two-way authentication with the second device based on a preset pre-shared key to establish communication between the first device and the second device, including: the first device and the second device perform authentication initialization; after the authentication initialization is completed, the first device performs key exchange with the second device based on the pre-shared key; after the key exchange is completed, the first device and the second device perform two-way authentication to establish communication between the first device and the second device.

[0090] In an optional embodiment, the first device and the second device perform authentication initialization. For example, the first device, as a client, initiates a TLS (Transport Layer Security) handshake request to the second device to achieve authentication initialization.

[0091] After authentication initialization, the first and second devices enter the key exchange phase. The second device (SU) generates a temporary SM2 key pair for key negotiation in the current session. It digitally signs the key exchange parameters using its private key; the signature data includes the client's random number, the server's random number, and the second device's temporary public key, and sends it to the first device via a ServerKeyExchange message. Upon receiving the signature, the first device (SM) verifies its integrity and authenticity, confirming the server's identity. Subsequently, the first device also generates a temporary SM2 key pair and sends its own temporary public key and PSK binding proof to the second device via a ClientKeyExchange message, thus completing the key exchange.

[0092] After the key exchange phase, the first and second devices enter the mutual authentication phase. The first device sends a ChangeCipherSpec message and a Finished message, indicating that it will begin using the negotiated cryptographic suite for subsequent communication protection. Upon receiving the Finished message, the second device searches for the corresponding PSK in the pre-shared key database based on the first device's device identifier. The matching PSK is used to recalculate the expected value of the PSK binding proof and compare it with the received actual value for verification. If the verification passes, the second device also sends ChangeCipherSpec and Finished messages to complete server-side authentication. At this point, both parties have achieved mutual authentication. After mutual authentication is completed, a secure communication channel is established between the first and second devices based on the negotiated session key.

[0093] Through the above steps, after establishing secure two-way authentication, the first and second devices can ensure data security and device identity credibility during communication, providing a reliable, efficient, and secure communication foundation for the real-time acquisition and processing of monitoring system data.

[0094] Optionally, in the processing method of the device provided in the embodiments of this application, the authentication initialization between the first device and the second device includes: the first device generating a first greeting message based on a list of encryption suites and a first random number, and sending the first greeting message to the second device, wherein the encryption suite specifies the algorithm used to encrypt and decrypt data; the second device generating a second greeting message based on the identifier of the target encryption suite and a second random number, and returning the second greeting message to the first device to complete the authentication initialization, wherein the target encryption suite is selected from the list of encryption suites.

[0095] In an optional embodiment, the authentication initialization between the first device and the second device includes: the first device (e.g., monitoring device SM), acting as a client, first constructs a TLS ClientHello message (i.e., the first greeting message mentioned above). The first greeting message includes a list of cipher suites supported by the first device and a first random number generated by the first device. The list of cipher suites contains various algorithm options for encrypting and decrypting data, such as a cipher suite combining a pre-shared key with TLS_PSK_SM4_GCM_SM3 or other suites. After constructing the TLS ClientHello message, the first device sends it to the second device (e.g., monitoring unit SU).

[0096] After receiving the first greeting message, the second device checks the list of cipher suites and selects a target cipher suite. The selection may be based on factors such as priority, protocol compatibility, or security policies. It then constructs a TLSServerHello message (the second greeting message mentioned above), containing the selected cipher suite identifier and a second random number. This TLSServerHello message is sent back to the first device, containing the target cipher suite identifier and the second random number. Upon receiving this message, the first device understands that the second device has selected a cipher suite that supports PSK for communication and has also obtained the second random number.

[0097] The authentication initialization phase between the first and second devices is completed through the exchange of a first greeting message and a second greeting message. After the first device receives and understands the second greeting message, both parties have completed the first phase of the TLS handshake, namely authentication initialization, and can then proceed to the key exchange and identity authentication phase.

[0098] In an optional embodiment, the monitoring device (SM) sends a ClientHello message, which, like the standard TLSClientHello message, provides a cipher suite, a client random number (ClientRandom), etc. Upon receiving the ClientHello, the monitoring unit (SU) verifies the legitimacy of the request, selects the cipher suite as the TLS_PSK_SM4_GCM_SM3 suite, generates a server random number (ServerRandom), and responds to the monitoring device (SM) via a ServerHello message.

[0099] It's important to note that TLS_PSK_SM4_GCM_SM3 is a cryptographic suite used to implement Pre-Shared Key (PSK) authentication in the Transport Layer Security (TLS) protocol, and to encrypt and protect data integrity using Chinese national cryptographic algorithms. SM4 is a symmetric encryption algorithm primarily used for data encryption to protect communication content from eavesdropping during transmission. GCM (Galois / Counter Mode) is an encryption mode typically used in conjunction with symmetric encryption algorithms to simultaneously provide data encryption and integrity verification, preventing data tampering during transmission. SM3 is a secure hash algorithm, similar to SHA-256. In the TLS protocol, SM3 is commonly used to generate Message Authentication Codes (MACs) to verify the authenticity and integrity of data.

[0100] The handshake is completed through a rapid exchange of greeting messages (first and second greeting messages), which significantly reduces handshake time and improves connection establishment efficiency compared to a complete certificate exchange and authentication process.

[0101] Optionally, in the processing method of the device provided in the embodiments of this application, after the authentication initialization is completed, the first device performs key exchange with the second device based on the pre-shared key, including: the first device receiving a first key exchange message sent by the second device, wherein the first key exchange message is obtained by encrypting a first random number, a second random number, and the first key of the second device based on the first private key of the second device; if the first device verifies the first key exchange message, the first device sends second key exchange information to the second device to complete the key exchange, wherein the second key exchange information is obtained by encrypting the second key of the first device and the first binding proof of the pre-shared key based on the second private key of the first device, and the first binding proof of the pre-shared key is obtained through the pre-shared key and the handshake message generated during the authentication initialization phase.

[0102] In an optional embodiment, after authentication initialization is complete, the first device receives a first key exchange message from the second device. This message is generated by the second device using its first private key (the second device's SM2 private key) to perform SM2 digital signatures on a first random number, a second random number, and the second device's first key (the second device's SM2 public key) (i.e., the first random number, the second random number, and the second device's first key are encrypted using the second device's first private key). After receiving the message, the first device needs to use the second device's public key (i.e., the public key sent by the second device in ServerHello) to decrypt and verify the integrity of the message, thereby confirming that the key exchange parameters come from the legitimate second device SU and have not been tampered with. This step not only verifies the authenticity of the message but also confirms the identity of the second device.

[0103] The first device generates its own temporary SM2 key pair (sm_eph_priv (second private key), sm_eph_pub (second key)). It then uses its second private key (its own SM2 private key) to encrypt the second key exchange information, which includes the first device's second key (its own SM2 public key) and a first binding proof of the pre-shared key. The encrypted information is sent to the second device over the network. The second device can use the first device's second key to decrypt the encrypted information, thereby obtaining the first device's first binding proof, preparing for subsequent key generation and authentication.

[0104] It's important to note that the first binding proof generated by the first device using the pre-shared key (PSK) is obtained by hashing all messages during the TLS handshake process (including the first random number, second random number, and any other handshake messages) using HMAC-SM3 (Hash-based Message Authentication Code using SM3, a message authentication code method based on the SM3 hash function used to ensure data integrity and authenticity) using the pre-shared key (PSK). The generation of the first binding proof ensures the association of the PSK with the current TLS session, preventing replay attacks and man-in-the-middle attacks. It should be noted that the HMAC-SM3 used here is SM3 in the cipher suite TLS_PSK_SM4_GCM_SM3. If the cipher suite is not TLS_PSK_SM4_GCM_SM3, the hash algorithm used to generate the first binding proof will vary depending on the selected suite. In the TLS protocol, different cipher suites specify different hash algorithms for generating HMACs (Hash-based Message Authentication Codes) to verify message integrity and the authenticity of its origin. For example, if the suite TLS_PSK_AES_128_GCM_SHA256 (AES, Advanced Encryption Standard, a symmetric encryption algorithm; GCM, Galois / Counter Mode, a working mode for providing encryption and integrity protection) which includes SHA-256 (a cryptographic hash function, Secure Hash Algorithm 256-bit) is used, then the first binding proof of the pre-shared key (PSK) will be obtained by performing an HMAC-SHA256 hash calculation on the messages during the TLS handshake process using the PSK as the key. This generated first binding proof will be consistent with the hash algorithm in the suite, ensuring the security and integrity of the entire handshake process.

[0105] It's important to note that HMAC-SM3 is a security mechanism based on the SM3 cryptographic algorithm standard, which uses hash-based message authentication codes. The SM3 algorithm is a secure hash algorithm used to generate a fixed-length hash value that ensures data integrity and immutability. HMAC (Hash-based Message Authentication Code) is a technique for verifying message integrity and authentication. It uses a key and a hash function to generate a message authentication code to verify any tampering of data during transmission.

[0106] The key exchange process ensures the security of data transmission, enabling the monitoring unit to accurately receive and process the data sent by the monitoring equipment.

[0107] Optionally, in the processing method of the device provided in the embodiments of this application, after the key exchange is completed, the first device and the second device perform bidirectional authentication to establish communication between the first device and the second device, including: the first device sending first change key specification information to the second device, wherein the first change key specification information is used to notify the second device to start encrypting data using a target encryption suite and a master key, and the master key is obtained based on a pre-shared key, a first key, a second key, a first random number, and a second random number; the first device sending a first completion message to the second device, wherein the first completion message is obtained by encrypting the complete information generated during the process of establishing communication between the first device and the second device based on the master key; the first device receiving second change key specification information sent by the second device, wherein if the second device verifies the first binding proof of the pre-shared key in the first completion message and the second key exchange information, the second device sends the second change key specification information to the first device; the first device receiving the second completion message sent by the second device to establish communication between the first device and the second device.

[0108] In an optional embodiment, the first device (such as the monitoring device SM) sends a ChangeCipherSpec message (i.e., the first change key specification information described above) to the second device (such as the monitoring unit SU), instructing the second device that from now on, all communication will be encrypted using the previously negotiated target encryption suite and master key. Sending this message is the first step in two-way authentication, ensuring that the second device is ready to use the encrypted channel.

[0109] Then, the first device generates and sends a Finished message (i.e., the first completion message mentioned above) to the second device. The Finished message encrypts all information from the entire TLS handshake process based on the master key, serving as authentication evidence for the first device. The master key can be calculated based on the pre-shared key (PSK), a first random number, and a second random number, ensuring the randomness and security of the key.

[0110] It should be noted that the first and second devices can use su_eph_pub and sm_eph_pub (i.e., the first key and the second key mentioned above) to calculate a shared secret value through the SM2 key exchange algorithm. Then, based on the shared secret value, PSK, and two random numbers (i.e., the first random number and the second random number mentioned above), the final master key is derived using SM3 as a pseudo-random function.

[0111] After the second device has successfully verified the PSK in the second key exchange information, it sends a ChangeCipherSpec message (i.e., the second changed key specification information) to the first device, indicating that the second device is also ready to use encrypted communication. This message is a response in the two-way authentication process, ensuring that the first device knows that the second device is ready for encrypted communication. Finally, the second device generates and sends a Finished message (i.e., the second completion message) to the first device, also encrypting all information from the handshake process based on the master key, completing the final step of authentication. After the first device receives and verifies the second completion message, it indicates that both parties have completed the two-way authentication process and can officially enable the encrypted communication channel.

[0112] By performing the above two-way authentication process, a secure, efficient and reliable communication channel is established between the first and second devices, ensuring the confidentiality and integrity of data transmission between the devices, while simplifying the authentication process and reducing development and maintenance costs.

[0113] Optionally, in the device processing method provided in the embodiments of this application, the second device obtains the device identifier of the first device and obtains the pre-shared key corresponding to the first device based on the device identifier; obtains a second binding proof based on the pre-shared key corresponding to the first device and the handshake message generated during the authentication initialization phase; and verifies the first binding proof of the pre-shared key in the second key exchange information based on the second binding proof.

[0114] In an optional embodiment, to improve the security of subsequent data transmission, the second device queries the pre-shared key (PSK) database based on the device identifier of the first device. After finding the first device's PSK, the second device recalculates the PSK binding proof and compares it with the received value for verification. Furthermore, after receiving the first completion message from the first device, the second device recalculates the master key based on the pre-shared key and the previously exchanged random number, and then uses this master key to decrypt and verify the first completion message. The verification includes the integrity and authenticity of the first completion message to ensure that the first device has not been subjected to a man-in-the-middle attack or its data has been tampered with.

[0115] For example, after receiving the ClientKeyExchange (the second exchange message), the SU (i.e., the second device mentioned above) uses its own temporary private key and the SM's temporary public key (i.e., the first private key and the first public key mentioned above) to calculate the same shared secret value. The SU then looks up its own recorded PSK based on the SM's device identifier, recalculates the binding proof of the handshake message using the same HMAC-SM3 algorithm, and compares it with the proof sent by the SM. If they match, the SM's identity is proven legitimate. Afterward, based on the shared secret value, the PSK, and two random numbers, both parties use SM3 as a pseudo-random function to derive the final master key.

[0116] This verification process is a crucial step in two-way authentication. It not only verifies the identity of the first device but also indirectly confirms the identity of the second device because the pre-shared key is generated based on a secret known to both parties. In this way, secure two-way authentication between devices can be achieved even in environments without Public Key Infrastructure (PKI), ensuring the confidentiality and integrity of subsequent data transmissions.

[0117] It should be noted that in this application, device discovery provides device identification and network address for security authentication, ensuring that the SU can quickly query the corresponding PSK during authentication; security authentication provides an encrypted channel for plaintext engineering value transmission to prevent plaintext data from being tampered with or stolen, and plaintext engineering value output allows the SU to achieve plug-and-play without parsing the underlying protocol.

[0118] The two-way authentication mechanism in this application uses a pre-shared key as the core identity credential and integrates temporary key exchange based on the SM2 algorithm to separate identity authentication from key negotiation. This design retains the advantages of lightweight PSK authentication while introducing a one-time SM2 key negotiation to provide an independent forward security key for each session, effectively overcoming the potential key leakage risk inherent in pure PSK mode.

[0119] In an optional embodiment, the monitoring device (SM) and the monitoring unit (SU) establish a secure call using the following steps:

[0120] The monitoring device (SM) sends a ClientHello containing a random number ClientRandom, a list of supported cipher suites (including TLS_PSK_SM4_GCM_SM3), and a PSK identifier (i.e., the first preset identifier information); the monitoring unit (SU) replies with a ServerHello, selects a cipher suite, and sends a random number ServerRandom.

[0121] The SU generates a temporary SM2 key pair (su_eph_priv, su_eph_pub); the SU uses its SM2 private key (i.e., su_eph_priv) to perform SM2 digital signatures on ClientRandom, ServerRandom, and the temporary public key su_eph_pub; the SU sends the temporary public key su_eph_pub and the aforementioned signature via a ServerKeyExchange message. The SM uses the temporary public key su_eph_pub to verify the signature, thereby confirming that the key exchange parameters originate from a legitimate SU and have not been tampered with.

[0122] After the SM verifies the SU's signature, it generates its own temporary SM2 key pair (sm_eph_priv, sm_eph_pub). Both parties use su_eph_pub and sm_eph_pub to calculate a shared secret value using the SM2 key exchange algorithm. The SM then includes its temporary public key sm_eph_pub in the ClientKeyExchange message. The SM must prove that it possesses a valid PSK. Using the PSK and all handshake messages up to this point as input, it calculates a "PSK binding proof (i.e., the first binding proof)" using the HMAC-SM3 algorithm and sends this proof, also in the ClientKeyExchange message, to the SU.

[0123] After receiving the ClientKeyExchange, the SU calculates the same shared secret value using su_eph_pub and sm_eph_pub. The SU then looks up its stored PSK based on the SM's device identifier, recalculates the handshake message's binding proof (i.e., the second binding proof) using the same HMAC-SM3 algorithm, and compares it with the proof sent by the SM. If they match, the SM's identity is proven legitimate. Subsequently, based on the shared secret value, PSK, and two random numbers, both parties derive the final master key using SM3 as a pseudo-random function, thus completing the establishment of the secure channel.

[0124] By employing a two-way authentication mechanism and using a pre-shared key as the core identity credential, along with ephemeral key exchange based on the SM2 algorithm, the design separates identity authentication from key negotiation. While retaining the lightweight advantages of PSK authentication, this design effectively overcomes the potential key leakage risk inherent in pure PSK mode by introducing a one-time SM2 key negotiation to provide an independent forward security key for each session.

[0125] Optionally, in the processing method of the device provided in the embodiments of this application, before the first device converts the raw data of the collected detection points into plaintext engineered values, generates target data based on the plaintext engineered values, the standard field names corresponding to the plaintext engineered values ​​and the device identifier, and sends the target data to the second device, the method further includes: obtaining a preset plaintext engineered value conversion rule; converting the raw data according to the plaintext engineered value conversion rule to obtain the plaintext engineered values.

[0126] In an optional embodiment, after automatic device discovery and secure access, the monitoring device (SM) can parse the complex underlying communication protocol and convert it into plaintext engineered values ​​for output, which are then transmitted to the monitoring unit (SU) through a standardized interface. Thanks to the secure communication channel, the security of the plaintext engineered values ​​during transmission is guaranteed, and the monitoring unit (SU) can accurately receive and process plaintext data from each monitoring device based on the device list obtained through automatic device discovery, enabling real-time monitoring and management of device status.

[0127] In an optional embodiment, the parsing of the underlying communication protocol is transferred from the second device (SU) to the first device (SM). Protocol adaptation is performed in the first device, and standardized plaintext engineered values ​​are output, enabling the second device to achieve universal interoperability without handling protocol differences. Based on its own underlying communication protocol (such as serial port protocol, proprietary protocol, etc.), a protocol parsing program is pre-written and embedded in the first device.

[0128] The first device, SM, performs real-time data acquisition from connected monitoring points. These monitoring points can be various communication power supply devices such as uninterruptible power supplies (UPS), air conditioners, generators, electricity meters, switching power supplies, and battery management systems (BMS). The acquired raw data is typically presented in a device-specific encoding format, consisting of unprocessed sensor readings or register values ​​from communication protocols.

[0129] The acquired raw data is then converted according to the protocol parsing program to obtain plaintext engineered values. The raw device readings are converted into numerical values ​​with actual physical meaning; for example, a register value representing voltage is converted to "220 volts," or a current value is converted to "5 amps." Such plaintext engineered values ​​are more intuitive and easier for the monitoring unit (SU) to identify and process without requiring in-depth understanding of the specific details of the underlying communication protocol.

[0130] Finally, the plaintext engineering values ​​are further encapsulated and combined with the corresponding standard field names and the device identifier of the first device to form the target data. Standard field names are labels used to uniformly describe the status parameters of different devices, such as "phase voltage," "current," and "temperature." This standardized naming method reduces the complexity for the monitoring unit (SU) when processing data from different devices. The device identifier is used to distinguish the data sources of different monitoring devices (SMs), ensuring that the monitoring unit (SU) can accurately associate data with specific monitoring devices.

[0131] After data acquisition, conversion, and encapsulation are completed, the first device SM sends the target data to the second device SU through the communication channel.

[0132] In existing technology, the first device (SM) directly sends the collected raw data to the second device (SU). The second device (SU) then parses the raw data to obtain plaintext data. For example, if the first device (SM) sends the collected "raw register value = 3332" to the second device (SU), the second device (SU), referring to Tables 1 and 2, checks that the communication protocol expiration is ASCII code, which is 0x32 in hexadecimal and 50 in decimal. Without any rate conversion, the AI ​​channel (double-byte 16) = 50 is obtained. In this application, the first device (SM) directly uploads the plaintext engineering value 50, eliminating the need for the aforementioned conversion. The data conversion is directly performed by the monitoring device (SM), simplifying the data processing flow of the monitoring unit (SU) and reducing the complexity of data parsing and conversion.

[0133] Table 1

[0134]

[0135] Table 2

[0136]

[0137] Through the above steps, the first device (SM) effectively processes the raw data collected from the detection points, converting it into plaintext engineered values ​​that the monitoring unit (SU) can directly understand and use. Then, through standardized encapsulation and secure transmission mechanisms, the accuracy, standardization, and security of the data are ensured. This method simplifies the data processing flow of the monitoring unit (SU), reduces the workload of interface development, and also improves the reliability and security of the entire environmental monitoring system, achieving plug-and-play open access.

[0138] Optionally, in the device processing method provided in the embodiments of this application, the method further includes: if the two-way authentication between the first device and the second device fails, then after a preset time interval, perform two-way authentication again until the authentication is successful or the cumulative number of failures equals a preset threshold; if the cumulative number of failures equals the preset threshold, then trigger a target message to the target object, wherein the target message is used to instruct the target object to perform security detection on the first device and the second device.

[0139] In an optional embodiment, when the first device (such as monitoring device SM) and the second device (such as monitoring unit SU) perform bidirectional authentication, if the first attempt fails, the authentication request is re-initiated according to a preset time interval (e.g., 5 seconds, 1 minute, etc., the specific time depending on the network environment and device performance). This mechanism allows the device time to recover and retry authentication when encountering temporary network or system problems, thereby improving the authentication success rate.

[0140] In an optional embodiment, after the first authentication fails, the first device waits for an initial interval (e.g., After that, the first retry will be performed. If consecutive retries fail, the waiting interval for each subsequent retry will increase exponentially according to the backoff principle. until the maximum interval limit is reached. When the interval for index retreat and retry reaches... After that, the waiting time will no longer increase exponentially, but will instead be fixed at a certain value. Retry periodically. When the cumulative number of failures reaches a preset threshold... Next (such as) When this occurs, the first device stops retrying and enters a silent or alarm state, requiring manual intervention for inspection. Simultaneously, the second device should record this abnormal authentication event.

[0141] In an optional embodiment, if the first device fails to pass the two-way authentication within a preset number of retries N (e.g., N=3), the second device simultaneously sends a target message to a preset target object (such as a security operations and maintenance center, network administrator, etc.), instructing the target object to perform security checks on the first and second devices, including but not limited to checking the network connection status, device hardware status, software configuration, and possible security vulnerabilities.

[0142] By employing an exponential backoff retry strategy, authentication can be quickly re-initiated when devices and the network recover, while also avoiding excessive consumption of network resources in the event of serious problems. When the number of authentication failures reaches a preset threshold, a security check is automatically triggered, enabling timely detection and handling of potential security issues and protecting the system from malicious attacks.

[0143] Optionally, in the processing method of the device provided in the embodiments of this application, the method further includes: if the pre-shared key update mechanism is triggered, the first device receives a key rotation instruction; the first device updates the pre-shared key based on the key rotation instruction.

[0144] In an optional embodiment, the communication security status between the first device (e.g., monitoring module SM) and the second device (e.g., monitoring unit SU) is assessed periodically or triggered by specific events (e.g., key usage reaching a preset duration, abnormal increase in authentication failures, etc.). If the assessment results indicate that the current use of the pre-shared key poses a security risk or is about to reach the end of its lifecycle, a key rotation instruction is generated, instructing the first device to update its pre-shared key. To prevent the key rotation instruction from being tampered with or intercepted during transmission, the instruction can be sent through an established secure communication channel and encrypted using an existing session key.

[0145] In an optional embodiment, upon receiving a key rotation instruction, the first device (SM) initiates a pre-shared key update process. The first device generates a new pre-shared key according to a predefined PSK update strategy. For example, it may generate the key using a different algorithm, obtain a new key from a secure key management system, or generate a new key based on some form of transformation of the current key; the specific strategy can be determined according to security requirements and system design. The generated new PSK is stored in the first device's secure storage module, replacing the old pre-shared key. After confirming the secure storage of the new key, the first device can notify the second device (SU) via a secure communication channel to prepare for key rotation. Upon receiving the update confirmation from the first device, the second device (SU) triggers the final step of the PSK update process: renegotiating the TLS session and using the new PSK for mutual authentication.

[0146] Regularly updating the pre-shared key can prevent security vulnerabilities caused by long-term key use. Even if the key is leaked at some point, a new key rotation will ensure its protection for subsequent communications. The device processing method in this application not only ensures secure communication between devices but also improves the system's flexibility and responsiveness, providing strong technical support for the long-term stable operation of the environmental monitoring system.

[0147] In an alternative embodiment, it can be achieved through, as follows: Figure 3The diagram illustrates device discovery between monitoring equipment and monitoring units. When an SM device connects to the network, it broadcasts an ARP request message. In the padding area of ​​the ARP request message, the SM device writes specific identification information, such as "xxtower" (ASCII encoding, occupying 10 bytes), and the remaining portion is padded with 0x00 to comply with the Ethernet minimum frame length requirement of 64 bytes. For example, the ARP request message structure (padding area): 63 68 69 6E61 74 6F 77 65 72 00 00 00 00 00 00 00 00.

[0148] The SU unit operates in ARP listening mode, capturing and parsing all received ARP packets. It pays particular attention to the data in the padding field, checking for pre-defined identification information (such as "xxtower"). If a match is found, the SU unit records the device's IP address and MAC address information.

[0149] The SU unit sends probe messages to the identified SM devices via unicast to obtain more device information, such as manufacturer and model. The target port of the unicast probe message can be a preset dedicated port to avoid conflicts with other network services.

[0150] After receiving the probe message from the SU, the SM device will return detailed device information to the SU unit, including but not limited to the device model, serial number, firmware version, etc., to enable rapid device identification and access.

[0151] In an alternative embodiment, it can be achieved through, as follows: Figure 4 The diagram illustrates the processing of monitoring equipment. The monitoring device (SM) and monitoring unit (SU) are connected to the network. Simultaneously, the monitoring unit (SU) enables ARP listening mode. The monitoring device (SM) sends ARP request packets, and the monitoring unit (SU) sends a list of SM devices based on these ARP request packets. A pre-shared key (PSK) is combined with the Transport Layer Security (TLS) protocol to achieve bidirectional authentication between the monitoring unit (SU) and the monitoring device (SM). After bidirectional authentication, both parties establish a secure communication channel based on the negotiated session key. The monitoring device (SM) transmits the collected plaintext engineering values ​​to the monitoring unit (SU), enabling plug-and-play functionality.

[0152] In an optional embodiment, the device automatically discovers via, for example... Figure 5The diagram illustrates how a monitoring device (SM) connects to the network and sends an ARP request (to obtain the MAC address of the SU) carrying specific fields. The monitoring unit (SU) starts listening for ARP packets and captures all ARP packets within its network segment. It parses the frame structure and checks if it contains specific characters. If not, the packet is discarded. If it does, the monitoring unit (SU) actively sends a unicast probe packet to the device. The monitoring device (SM) returns detailed information (manufacturer, model, etc.), completing the automatic device discovery process.

[0153] In an optional embodiment, two-way authentication and secure communication are achieved through, for example... Figure 6 The diagram illustrates the implementation of the first phase: authentication initialization. The monitoring device (SM) sends a ClientHello message, which includes the cipher suite and the client random number (ClientRandom). Upon receiving the ClientHello, the monitoring unit (SU) verifies the legitimacy of the request, selects the cipher suite as TLS_PSK_SM4_GCM_SM3, generates a server random number (ServerRandom), and responds to the monitoring device (SM) via a ServerHello message.

[0154] Phase Two: Key Exchange. The Monitoring Unit (SU) sends a ServerKeyExchange message (including the ClientRandom, ServerRandom, and the SU's temporary public key) to the Monitoring Device (SM) to ensure the integrity and authenticity of the exchange process. Upon receiving and verifying the ServerKeyExchange message, the Monitoring Device (SM) sends a ClientKeyExchange message (including the temporary public key and PSK binding proof) to the Monitoring Unit (SU). A master key is then generated based on the PSK.

[0155] Phase 3: Authentication and Verification: After key exchange, the Monitoring Device (SM) first sends a ChangeCipherSpec message, indicating that subsequent messages will be protected using the negotiated encryption parameters. Then, the SM sends a Finished message, which contains verification data for all previous handshake messages, encrypted and protected for integrity using the derived master key. Upon receiving the verification message from the Monitoring Device (SM), the Monitoring Unit (SU) performs pre-shared key (PSK) verification. Based on the monitoring device's (SM) device identifier, it queries the corresponding pre-shared key (PSK) in the pre-shared key (PSK) database. After finding the corresponding PSK, the Monitoring Unit (SU) recalculates the expected value of the PSK binding proof and compares it with the received value for verification. Upon successful verification, the Monitoring Unit (SU) also sends ChangeCipherSpec and Finished messages, completing the identity verification of the monitoring unit.

[0156] In an optional embodiment, the parsing of the device's underlying communication protocol is transferred from the monitoring unit (SU) to the monitoring module (SM). The SM performs protocol adaptation and outputs standardized plaintext engineered values ​​before leaving the factory, allowing the SU to achieve universal interoperability without handling protocol differences. This is achieved through a two-layer architecture of "SM protocol pre-installation parsing + SU standard field interaction," specifically involving four core steps:

[0157] Pre-installation and adaptation of protocols for the Monitoring Module (SM) before shipment: During the SM production phase, equipment manufacturers pre-write and solidify protocol parsing programs based on their own equipment's underlying communication protocols (such as serial port protocols, Modbus_TCP, proprietary protocols, etc.). The parsing program needs to complete two core tasks: first, read the device's raw data in real time (such as register values, serial port messages); second, convert the raw data into plaintext engineered values ​​(such as "Phase A voltage = 220V", "Current = 5A", "Overcurrent alarm = 1", and "Overcurrent alarm = 0"), and associate them with standardized field names and meterId (i.e., the ID number of a certain measurement point collected by the first device, or the ID number of the signal, such as a meter that has collected the phase A voltage, and the phase A voltage must have an ID, namely meterID). For example, "meterId": "0406101001", "name": "A-phase voltage", "value": "220". The SM built-in storage module saves a mapping table of "meterId-standard field name-plaintext engineering value" for all monitoring points, ensuring that the data output format is unique.

[0158] Standardized data interaction interface definition: A unified interaction interface protocol between SM and SU (such as a custom lightweight protocol based on TCP / IP). The interface transmits key-value pairs of data: "meterId + standard field name + plaintext engineering value", without containing any raw bytes or register addresses related to the underlying protocol. {"id": "01", "meterId": "0406101001", "name": "A phase voltage", "value": "220", "dataType": "0", meaning: "", "sampleTime": "2024.06.3016:10:10", "state": "0", "unit": "V", "precision": "0.1"}.

[0159] The standardized interface design of the monitoring unit (SU) eliminates the need for the SU to adapt to the communication protocols of different devices. Only a single, universal data receiving program needs to be developed to establish a connection with all monitoring units (SMs) through the standardized interface described above. The SU uses a "standard interface name" to access different data. During data access, it directly retrieves the required monitoring point value. For example, when data from a single monitoring point is needed (a less common scenario), the plaintext value corresponding to its "meterId" is read directly. When data from multiple monitoring points is needed (another less common scenario), the "meterId" is first set to a specific value, such as 999, and the corresponding plaintext value is read directly, without needing to perform the traditional "read register - parse byte - convert unit" operation.

[0160] Precise pre-verification of alarms and abnormal data: During the SM pre-installation stage, alarm logic verification program is simultaneously embedded. SM monitors the device status in real time. When an alarm is triggered, it directly outputs the plain text identifier "alarm field name: 1" without the need for secondary judgment by SU. At the same time, all alarm scenarios are pre-verified through real machine testing before leaving the factory to ensure that the alarm logic and the physical status of the device are completely matched.

[0161] In an alternative embodiment, blockchain-based identity authentication technology can be explored as an alternative to PSK-TLS two-way authentication. Leveraging the decentralized and immutable characteristics of blockchain, unique digital identities are generated for the monitoring module (SM) and monitoring unit (SU), and the identity authentication information is stored on the blockchain. Upon device access, authentication and access control are performed through blockchain smart contracts to ensure the trustworthiness of the accessing device's identity. This approach offers higher security and resistance to attacks, effectively preventing identity information from being tampered with or forged.

[0162] In an alternative embodiment, semantic modeling technology can be used instead of refactoring the underlying communication protocol parsing down to the monitoring module (SM). By establishing a unified semantic model, the communication protocols of different devices are semantically annotated and mapped, enabling the monitoring unit (SU) to directly obtain device data based on semantic understanding.

[0163] In an optional embodiment, during the protocol pre-installation and adaptation phase of the monitoring module (SM), in addition to embedding the protocol parser, containerization technology can be used to encapsulate the protocol parser into an independent container. This allows for easier program upgrades and replacements when devices are updated or protocols are changed, improving system flexibility and maintainability.

[0164] In existing technologies, interfacing with a single SM device requires the SM manufacturer to provide the correct communication protocol to the SU manufacturer (this protocol may not be available, or an incorrect one may be obtained). After obtaining the communication protocol, professional programmers develop a parsing program, while frontline technical engineers test the program. However, the testing work cannot be comprehensive. For analog quantities (such as 220V voltage, 10A current, etc.), it is easy to check whether the parsing is correct. For digital quantities and alarm quantities (such as air conditioner compressor failure, mains power failure, UPS bypass, etc.), these alarms cannot be tested in a normally operating computer room, so the correctness of the parsing cannot be predicted. Once an alarm is actually generated, parsing errors may occur.

[0165] This application eliminates the need for SM manufacturers to provide the correct communication protocol to SU manufacturers, avoiding communication and coordination issues and the risk of protocol errors. Simultaneously, SU manufacturers do not require programming development and testing; only frontline technical engineers need to connect the network cable, reducing workload by 90%. Since SM manufacturers have sufficient testing time before equipment shipment, alarm accuracy can be improved to 100%, avoiding the problem of "incomplete testing coverage" in traditional solutions. This application forms a closed-loop technology of "discovery-authentication-resolution," innovatively utilizing ARP packet filling areas to achieve broadcast-free, configuration-free device discovery; proposes a lightweight PSK-TLS bidirectional authentication scheme adapted to environmental monitoring scenarios; and establishes an architecture of "SM resolution + SU universal integration," achieving protocol-independent plug-and-play functionality, thereby specifically addressing the core pain points in the environmental monitoring field.

[0166] The device processing method provided in this application embodiment achieves device discovery through a target request packet between a first device and a second device. The target request packet includes at least: the address information of the first device and a first preset identifier. The first device performs bidirectional authentication with the second device based on a preset pre-shared key to establish communication between the first and second devices. After establishing communication between the first and second devices, the first device converts the raw data of the collected detection points into plaintext engineered values, generates target data based on the plaintext engineered values, the corresponding standard field names, and the device identifier, and sends the target data to the second device for data processing. This solves the technical problem in related technologies where the communication parameter configuration for monitoring unit access to monitoring equipment is cumbersome, leading to low efficiency in obtaining monitoring data.

[0167] In this scheme, the first device sends a target request packet containing a first preset identification information, facilitating rapid identification and discovery by the second device. The second device, by monitoring the network, captures and parses the target request packet, extracting the first device's address and identification information, verifying the validity of the identification information, and then sending a unicast probe message to the first device to confirm the device connection and prepare for the next step of security authentication. After automatic device discovery, the first and second devices perform bidirectional authentication based on a pre-shared key, ensuring the legitimacy of both communicating parties, preventing unauthorized devices from impersonating legitimate devices, and establishing a secure data transmission channel. After the secure communication channel is established, the first device can send the collected data to the second device. The first device does not need to manually configure network parameters such as IP address, subnet mask, and gateway, nor does it require complex communication protocol matching. The automatic discovery mechanism and bidirectional authentication mode make the device plug-and-play, reducing the time and manpower costs of device access, thereby achieving the technical effect of improving the efficiency of acquiring monitoring data.

[0168] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0169] Example 2

[0170] This application also provides a device processing apparatus. It should be noted that the device processing apparatus of this application can be used to execute the device processing method provided in this application. The device processing apparatus provided in this application will be described below.

[0171] According to an embodiment of this application, an apparatus for implementing the processing method of the above-described device is also provided, such as... Figure 7As shown, the device includes: a discovery unit 701, a first authentication unit 702, and a sending unit 703.

[0172] The discovery unit 701 is used for the first device and the second device to discover each other based on a target request packet, wherein the target request packet includes at least: the address information of the first device and the first preset identification information;

[0173] The first authentication unit 702 is used for the first device to perform two-way authentication with the second device based on a preset pre-shared key, so as to establish communication between the first device and the second device;

[0174] The sending unit 703 is used to, after establishing communication between the first device and the second device, convert the raw data of the collected detection points into plaintext engineered values, generate target data based on the plaintext engineered values, the standard field names corresponding to the plaintext engineered values ​​and the device identifier, and send the target data to the second device for data processing by the second device.

[0175] The device processing apparatus provided in this application embodiment discovers the device by means of a discovery unit 701, which connects the first device and the second device based on a target request packet. The target request packet includes at least the address information and the first preset identification information of the first device. A first authentication unit 702 performs bidirectional authentication between the first device and the second device based on a preset pre-shared key to establish communication between the first device and the second device. After establishing communication between the first device and the second device, a sending unit 703 converts the raw data of the collected detection points into plaintext engineered values, generates target data based on the plaintext engineered values, the standard field names corresponding to the plaintext engineered values, and the device identifier, and sends the target data to the second device for data processing. This solves the technical problem in related technologies where the communication parameter configuration for the monitoring unit to access the monitoring device is cumbersome, resulting in low efficiency in obtaining monitoring data.

[0176] In this scheme, the first device sends a target request packet containing a first preset identification information, facilitating rapid identification and discovery by the second device. The second device, by monitoring the network, captures and parses the target request packet, extracting the first device's address and identification information, verifying the validity of the identification information, and then sending a unicast probe message to the first device to confirm the device connection and prepare for the next step of security authentication. After automatic device discovery, the first and second devices perform bidirectional authentication based on a pre-shared key, ensuring the legitimacy of both communicating parties, preventing unauthorized devices from impersonating legitimate devices, and establishing a secure data transmission channel. After the secure communication channel is established, the first device can send the collected data to the second device. The first device does not need to manually configure network parameters such as IP address, subnet mask, and gateway, nor does it require complex communication protocol matching. The automatic discovery mechanism and bidirectional authentication mode make the device plug-and-play, reducing the time and manpower costs of device access, thereby achieving the technical effect of improving the efficiency of acquiring monitoring data.

[0177] Optionally, in the processing apparatus of the device provided in this application embodiment, the discovery unit includes: a broadcast module, used by the first device to broadcast a target request packet to a target network segment, wherein the second device captures the target request packet in the target network segment, parses the target request packet to obtain parsed second preset identification information; and performs verification based on the parsed second preset identification information, and if the verification is successful, sends a unicast probe message to the first device based on the address information of the first device; and a return module, used by the first device to return model parameter information based on the received unicast probe message, so as to realize device discovery.

[0178] Optionally, in the processing apparatus of the device provided in the embodiments of this application, the apparatus further includes: a generation unit, configured to generate an initial request packet based on the address information of the first device before the first device broadcasts the target request packet to the target network segment; an adding unit, configured to add first preset identification information to the end of the frame of the initial request packet to obtain the processed initial request packet; and a filling unit, configured to fill the processed initial request packet according to preset characters to obtain the target request packet.

[0179] Optionally, in the processing apparatus of the device provided in the embodiments of this application, the first authentication unit includes: an initialization module for performing authentication initialization between the first device and the second device; an exchange module for performing key exchange between the first device and the second device based on a pre-shared key after the authentication initialization is completed; and an authentication module for performing bidirectional authentication between the first device and the second device after the key exchange is completed, so as to establish communication between the first device and the second device.

[0180] Optionally, in the processing apparatus of the device provided in the embodiments of this application, the initialization module includes: a generation submodule, used by the first device to generate a first greeting message based on a list of encryption suites and a first random number, and send the first greeting message to the second device, wherein the encryption suite specifies an algorithm used for encrypting and decrypting data, the second device generates a second greeting message based on the identifier of the target encryption suite and a second random number, and returns the second greeting message to the first device to complete the authentication initialization, wherein the target encryption suite is selected from the list of encryption suites.

[0181] Optionally, in the processing apparatus of the device provided in this application embodiment, the exchange module includes: a first receiving submodule, used for the first device to receive a first key exchange message sent by the second device, wherein the first key exchange message is obtained by encrypting a first random number, a second random number, and a first key of the second device based on the first private key of the second device; and a first sending submodule, used for the first device to send second key exchange information to the second device to complete the key exchange when the first device verifies the first key exchange message, wherein the second key exchange information is obtained by encrypting the second key of the first device and a first binding proof of the pre-shared key based on the second private key of the first device, and the first binding proof of the pre-shared key is obtained through the pre-shared key and the handshake message generated during the authentication initialization phase.

[0182] Optionally, in the processing apparatus of the device provided in this application embodiment, the authentication module includes: a second sending submodule, used by the first device to send first change key specification information to the second device, wherein the first change key specification information is used to notify the second device to start encrypting data using a target encryption suite and a master key, and the master key is obtained based on a pre-shared key, a first key, a second key, a first random number, and a second random number; a third sending submodule, used by the first device to send a first completion message to the second device, wherein the first completion message is obtained by encrypting complete information generated during the establishment of communication between the first device and the second device based on the master key; a second receiving submodule, used by the first device to receive second change key specification information sent by the second device, wherein the second device sends second change key specification information to the first device if the second device verifies the first binding proof of the pre-shared key in the first completion message and the second key exchange information; and a third receiving submodule, used by the first device to receive the second completion message sent by the second device to establish communication between the first device and the second device.

[0183] Optionally, in the processing apparatus of the device provided in the embodiments of this application, the second device obtains the device identifier of the first device and obtains the pre-shared key corresponding to the first device based on the device identifier; obtains a second binding proof based on the pre-shared key corresponding to the first device and the handshake message generated during the authentication initialization phase; and verifies the first binding proof of the pre-shared key in the second key exchange information based on the second binding proof.

[0184] Optionally, in the processing apparatus of the device provided in the embodiments of this application, the sending unit further includes: an acquisition module, used to acquire a preset plaintext engineering value conversion rule; and a conversion module, used to convert the original data according to the plaintext engineering value conversion rule to obtain a plaintext engineering value.

[0185] Optionally, in the processing apparatus of the device provided in the embodiments of this application, the apparatus further includes: a second authentication unit, configured to perform two-way authentication again after a preset time interval if the two-way authentication between the first device and the second device fails, until the authentication is successful or the cumulative number of failures equals a preset threshold; and a triggering unit, configured to trigger a target message to a target object if the cumulative number of failures equals the preset threshold, wherein the target message is used to instruct the target object to perform security detection on the first device and the second device.

[0186] Optionally, in the processing apparatus of the device provided in the embodiments of this application, the apparatus further includes: a receiving unit, configured to receive a key rotation instruction if a pre-shared key update mechanism is triggered; and an updating unit, configured to update the pre-shared key based on the key rotation instruction.

[0187] It should be noted that the discovery unit 701, the first authentication unit 702, and the sending unit 703 mentioned above correspond to steps S201 to S203 in Embodiment 1. The three units and the corresponding steps implement the same instances and application scenarios, but are not limited to the content disclosed in Embodiment 1. It should be noted that the above modules or units can be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above modules can also be part of a device and run in the computer terminal 10 provided in Embodiment 1.

[0188] Example 3

[0189] Embodiments of this application may provide an electronic device. Figure 8 This is a structural block diagram of an electronic device according to an embodiment of this application. Figure 8 As shown, the electronic device may include: one or more ( Figure 8(Only one is shown) processor 802, memory 804, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, network module and display.

[0190] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and apparatus in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the above-described methods. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0191] The processor can invoke information and applications stored in the memory through the transmission device to execute the following steps: the first device and the second device perform device discovery based on a target request packet, wherein the target request packet includes at least: the address information of the first device and the first preset identification information; the first device performs bidirectional authentication with the second device based on a preset pre-shared key to establish communication between the first device and the second device; after establishing communication between the first device and the second device, the first device converts the raw data of the collected detection points into plaintext engineered values, generates target data based on the plaintext engineered values, the standard field names corresponding to the plaintext engineered values, and the device identifier, and sends the target data to the second device for data processing by the second device.

[0192] The processor can invoke information and applications stored in the memory through the transmission device to execute the following steps: Device discovery based on target request packets by the first device and the second device includes: the first device broadcasts a target request packet to the target network segment, wherein the second device captures the target request packet in the target network segment, parses the target request packet to obtain the parsed second preset identification information; and performs verification based on the parsed second preset identification information. If the verification is successful, the second device sends a unicast probe message to the first device based on the address information of the first device; the first device returns model parameter information based on the received unicast probe message to achieve device discovery.

[0193] The processor can call the information and application stored in the memory through the transmission device to perform the following steps: before the first device broadcasts the target request packet to the target network segment, the method further includes: generating an initial request packet based on the address information of the first device; adding first preset identification information to the end of the frame of the initial request packet to obtain a processed initial request packet; and filling the processed initial request packet according to preset characters to obtain a target request packet.

[0194] The processor can invoke information and applications stored in the memory through the transmission device to execute the following steps: the first device performs two-way authentication with the second device based on a preset pre-shared key to establish communication between the first device and the second device, including: the first device and the second device perform authentication initialization; after the authentication initialization is completed, the first device exchanges keys with the second device based on the pre-shared key; after the key exchange is completed, the first device and the second device perform two-way authentication to establish communication between the first device and the second device.

[0195] The processor can invoke information and applications stored in the memory through the transmission device to perform the following steps: the first device and the second device perform authentication initialization, including: the first device generates a first greeting message based on a list of cipher suites and a first random number, and sends the first greeting message to the second device, wherein the cipher suite specifies the algorithm used to encrypt and decrypt data; the second device generates a second greeting message based on the identifier of the target cipher suite and a second random number, and returns the second greeting message to the first device to complete the authentication initialization, wherein the target cipher suite is selected from the list of cipher suites.

[0196] The processor can invoke information and application programs stored in memory via a transmission device to execute the following steps: After authentication initialization is completed, the first device performs key exchange with the second device based on the pre-shared key, including: the first device receiving a first key exchange message sent by the second device, wherein the first key exchange message is obtained by encrypting a first random number, a second random number, and the first key of the second device based on the first private key of the second device; if the first device verifies the first key exchange message, the first device sends second key exchange information to the second device to complete the key exchange, wherein the second key exchange information is obtained by encrypting the second key of the first device and the first binding proof of the pre-shared key based on the second private key of the first device, and the first binding proof of the pre-shared key is obtained through the pre-shared key and the handshake message generated during the authentication initialization phase.

[0197] The processor can invoke information and applications stored in memory via a transmission device to execute the following steps: After key exchange is completed, the first device and the second device perform bidirectional authentication to establish communication between the first device and the second device, including: the first device sending first key change specification information to the second device, wherein the first key change specification information is used to notify the second device to start encrypting data using a target encryption suite and a master key, the master key being obtained based on a pre-shared key, a first key, a second key, a first random number, and a second random number; the first device sending a first completion message to the second device, wherein the first completion message is obtained by encrypting complete information generated during the establishment of communication between the first device and the second device based on the master key; the first device receiving second key change specification information sent by the second device, wherein the second device sends second key change specification information to the first device if the second device verifies the first binding proof of the pre-shared key in the first completion message and the second key exchange information; the first device receiving the second completion message sent by the second device to establish communication between the first device and the second device.

[0198] The processor can invoke information and application programs stored in the memory through the transmission device to perform the following steps: the second device obtains the device identifier of the first device and obtains the pre-shared key corresponding to the first device based on the device identifier; the second binding proof is obtained based on the pre-shared key corresponding to the first device and the handshake message generated during the authentication initialization phase; the first binding proof of the pre-shared key in the second key exchange information is verified based on the second binding proof.

[0199] The processor can call the information and application stored in the memory through the transmission device to perform the following steps: The first device converts the raw data of the collected detection points into plaintext engineered values, including: obtaining the preset plaintext engineered value conversion rules; converting the raw data according to the plaintext engineered value conversion rules to obtain plaintext engineered values.

[0200] The processor can call the information and application stored in the memory through the transmission device to perform the following steps: if the two-way authentication between the first device and the second device fails, then after a preset time interval, the two-way authentication is performed again until the authentication is successful or the cumulative number of failures equals a preset threshold; if the cumulative number of failures equals the preset threshold, then a target message is triggered to the target object, wherein the target message is used to instruct the target object to perform security detection on the first device and the second device.

[0201] The processor can access information and applications stored in memory via a transmission device to perform the following steps: if a pre-shared key update mechanism is triggered, the first device receives a key rotation instruction; the first device updates the pre-shared key based on the key rotation instruction.

[0202] Those skilled in the art will understand that Figure 8 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, handheld computers, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 8 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 8 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 8 The different configurations shown.

[0203] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0204] Example 4

[0205] Embodiments of this application also provide a computer-readable storage medium. Optionally, in this embodiment, the storage medium can be used to store program code executed by the processing method of the device provided in Embodiment 1.

[0206] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0207] This application also provides a computer program product, which, when executed on a data processing device, is a program adapted to perform the processing method steps of the device.

[0208] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0209] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0210] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0211] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0212] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0213] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0214] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A processing method for a device, characterized in that, include: The first device and the second device discover each other based on a target request packet, wherein the target request packet includes at least: the address information of the first device and the first preset identification information; The first device performs two-way authentication with the second device based on a preset pre-shared key to establish communication between the first device and the second device; After establishing communication between the first device and the second device, the first device converts the raw data of the collected detection points into plaintext engineered values, generates target data based on the plaintext engineered values, the standard field names corresponding to the plaintext engineered values, and the device identifier, and sends the target data to the second device for data processing.

2. The method according to claim 1, characterized in that, The first and second devices perform device discovery based on the target request packet, including: The first device broadcasts the target request packet to the target network segment, wherein the second device captures the target request packet in the target network segment, parses the target request packet to obtain the parsed second preset identification information, and performs verification based on the parsed second preset identification information. If the verification is successful, the second device sends a unicast probe message to the first device based on the address information of the first device. The first device returns model parameter information based on the received unicast probe message to achieve device discovery.

3. The method according to claim 2, characterized in that, Before the first device broadcasts the target request packet to the target network segment, the method further includes: An initial request packet is generated based on the address information of the first device; The first preset identifier information is added to the end of the frame of the initial request packet to obtain the processed initial request packet; The processed initial request packet is filled with preset characters to obtain the target request packet.

4. The method according to claim 1, characterized in that, The first device performs two-way authentication with the second device based on a preset pre-shared key to establish communication between the first device and the second device, including: The first device and the second device perform authentication initialization; After authentication initialization is complete, the first device and the second device exchange keys based on the pre-shared key; After the key exchange is completed, the first device and the second device perform two-way authentication to establish communication between the first device and the second device.

5. The method according to claim 4, characterized in that, The authentication initialization process between the first device and the second device includes: The first device generates a first greeting message based on a list of cipher suites and a first random number, and sends the first greeting message to the second device. The cipher suite specifies the algorithm used to encrypt and decrypt data. The second device generates a second greeting message based on the identifier of the target cipher suite and a second random number, and returns the second greeting message to the first device to complete the authentication initialization. The target cipher suite is selected from the list of cipher suites.

6. The method according to claim 5, characterized in that, After authentication initialization is complete, the first device and the second device exchange keys based on the pre-shared key, including: The first device receives a first key exchange message sent by the second device, wherein the first key exchange message is obtained by encrypting the first random number, the second random number and the first key of the second device based on the first private key of the second device; If the first device verifies the first key exchange message, the first device sends second key exchange information to the second device to complete the key exchange. The second key exchange information is obtained by encrypting the second key of the first device and the first binding proof of the pre-shared key based on the second private key of the first device. The first binding proof of the pre-shared key is obtained through the pre-shared key and the handshake message generated during the authentication initialization phase.

7. The method according to claim 6, characterized in that, After the key exchange is completed, the first device and the second device perform two-way authentication to establish communication between the first device and the second device, including: The first device sends first key change specification information to the second device, wherein the first key change specification information is used to notify the second device to start encrypting data using the target encryption suite and the master key, and the master key is obtained based on the pre-shared key, the first key, the second key, the first random number, and the second random number; The first device sends a first completion message to the second device, wherein the first completion message is obtained by encrypting the complete information generated during the establishment of communication between the first device and the second device based on the master key; The first device receives the second change key specification information sent by the second device, wherein, if the second device verifies the first binding proof of the pre-shared key in the first completion message and the second key exchange information, the second device sends the second change key specification information to the first device; The first device receives a second completion message sent by the second device to establish communication between the first device and the second device.

8. The method according to claim 7, characterized in that, The second device obtains the device identifier of the first device and obtains the pre-shared key corresponding to the first device based on the device identifier; it obtains the second binding proof based on the pre-shared key corresponding to the first device and the handshake message generated during the authentication initialization phase. The first binding proof of the pre-shared key in the second key exchange information is verified based on the second binding proof.

9. The method according to claim 1, characterized in that, The first device converts the raw data collected from the detection points into plaintext engineered values, including: Obtain the preset plaintext engineering value conversion rules; The original data is converted according to the plaintext engineered value conversion rules to obtain plaintext engineered values.

10. The method according to claim 1, characterized in that, The method further includes: If the two-way authentication between the first device and the second device fails, the two-way authentication will be performed again after a preset time interval until the authentication is successful or the cumulative number of failures equals a preset threshold. If the cumulative number of failures equals the preset threshold, a target message is triggered to the target object, wherein the target message is used to instruct the target object to perform security checks on the first device and the second device.

11. The method according to claim 1, characterized in that, The method further includes: If the pre-shared key update mechanism is triggered, the first device receives a key rotation instruction; The first device updates the pre-shared key based on the key rotation instruction.

12. A processing apparatus for a device, characterized in that, include: The discovery unit is used for the first device and the second device to discover each other based on a target request packet, wherein the target request packet includes at least: the address information of the first device and the first preset identification information; The first authentication unit is used for the first device to perform two-way authentication with the second device based on a preset pre-shared key, so as to establish communication between the first device and the second device; The sending unit is configured to, after establishing communication between the first device and the second device, convert the raw data of the collected detection points into plaintext engineered values, generate target data based on the plaintext engineered values, the standard field names corresponding to the plaintext engineered values ​​and the device identifier, and send the target data to the second device for data processing by the second device.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored executable program, wherein, when the executable program is executed, it controls the device on which the computer-readable storage medium is located to perform the processing method of the device according to any one of claims 1 to 11.

14. An electronic device, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, performs the processing method of the device according to any one of claims 1 to 11.

Images