A mimicry-based secure data exchange method based on MQTT
By constructing a redundant MQTT proxy cluster and utilizing a mimetic-safe large number arbitration method, the data merging problem caused by redundant data transmission paths in the MQTT proxy is solved, the high availability of the MQTT proxy and the security of data exchange are achieved, and the security of intelligent converged terminal devices is enhanced.
Patent Information
- Application Number
- CN202411723671.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-28
- Publication Date
- 2025-10-10
- Estimated Expiration
- 2044-11-28
AI Technical Summary
In an MQTT broker, when adding multiple data transmission paths to improve security, the problem becomes how to effectively merge the data into one piece of data rather than multiple copies of the same data before it reaches the user.
Construct a redundant MQTT agent cluster, broadcast data to multiple agents through the distribution component, merge the data on the same topic using the mimetic-safe large number arbitration method, adopt subscription/distribution capabilities, and use the arbitration component to perform consistency comparison and data merging.
It achieves high availability and data exchange security in the event of MQTT agent failure, prevents the failure of a single data center from causing the failure of intelligent converged terminal devices, and improves the security and reliability of the system.
Smart Images

Figure CN119766488B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to a network security technology, and in particular to a data exchange method in the field of Internet of Things. Background Art
[0002] With the application of technologies such as the Internet of Things, cloud computing, big data, and artificial intelligence (AI), intelligent fusion terminals are often used to achieve interconnection between different systems and platforms, integrating multiple communication technologies and computing capabilities to process and exchange data and information from different sources, and provide unified services and user experience in multiple industries such as manufacturing, medical care, transportation, education, and retail. In order to achieve information interaction between the central cloud and terminal sensors, intelligent fusion terminals are deployed at the edge of the Internet to provide uplink and downlink communications. The uplink is responsible for transmitting monitoring data from the intelligent fusion terminal to the upper-level master station, and the downlink is responsible for information interaction between the intelligent fusion terminal and the lower-level terminal equipment control instructions. Intelligent fusion terminal (see Figure 1 ) interacts internally through the message mechanism provided by MQTT (Message Queuing Telemetry Transport), adopts centralized data management, avoids the establishment of private databases for each application, ensures data security, and improves data usage efficiency.
[0003] MQTT is a lightweight message transmission protocol based on the publish / subscribe model. It is suitable for devices with limited connection bandwidth, unstable network or limited resources. It is widely used in the Internet of Things (IoT), remote monitoring, real-time messaging and mobile application systems.
[0004] MQTT uses a client-server model, where clients are responsible for sending and receiving messages, while servers are responsible for routing and delivering messages. Clients can be publishers, subscribers, or both. Publishers send messages to specific topics; subscribers subscribe to topics of interest. Only clients subscribed to a specific topic can receive messages from that topic. The MQTT broker receives messages from publishers and forwards them to subscribers who have subscribed to the corresponding topic. A topic is a string used to categorize messages. Clients publish and subscribe to messages by specifying a topic. A topic can be subscribed to by multiple clients, and a client can subscribe to multiple topics. MQTT defines three Quality of Service (QoS) levels to ensure varying reliability requirements for message delivery.
[0005] The data center in the intelligent fusion terminal realizes the purpose of data aggregation, collects data from various sensors, and transmits it to the central cloud via the Internet for further processing. However, the MQTT agent used by the data center itself does not provide a cluster processing mechanism. When a failure or vulnerability attack occurs in the data center, the intelligent fusion terminal will fail and a large number of devices will become uncontrollable. Therefore, a simple and effective method is needed to implement cluster processing of the MQTT agent.
[0006] The common mimic security framework consists of distribution components, adjudication components, management components and execution bodies, see Figure 2 . In order to protect the data and its processing process, a cluster is built for the application's executors. When a single executor fails or fails, the management component starts the cleaning process and restores the faulty executor. The distribution component distributes external input requests to the executor for calculation and processing, and the arbitration component determines whether an abnormality has occurred based on the output differences of the executor. The MQTT agent is different from ordinary executors. It does not process data directly, but delivers data to designated users. Therefore, a safe way is to add multiple data transmission paths. Even if a single transmission path is destroyed, the entire system will not fail. However, this also brings a problem: when a piece of data is transmitted on multiple paths, how to merge it into one piece of data before delivering it to the user, rather than multiple copies of the same data. Summary of the Invention
[0007] To address the issue of mimetic security frameworks adding multiple data transmission paths for security, which also makes merging difficult, a mimetic security data exchange method based on MQTT is proposed. Building on the existing mimetic security defense architecture, this method leverages the MQTT subscription and data distribution capabilities to redundantly deploy multiple MQTT proxies in parallel, effectively protecting intelligent converged terminal applications at the edge of the internet.
[0008] The technical solution of the present invention is:
[0009] A mimetic secure data exchange method based on MQTT. The method utilizes the subscription / distribution capabilities of the MQTT agent to construct an MQTT agent redundant cluster. The method broadcasts a piece of data to multiple MQTT agents through a distribution component. The method uses a mimetic secure large number arbitration method to merge data on the same topic. The method is based on the mimetic secure data exchange framework of the MQTT agent, and its structure includes a publisher, a distribution component, an MQTT agent cluster, an arbitration component, a subscriber, and a negative feedback component. The method comprises the following steps:
[0010] Step 1: The client publisher connects to the distribution component. The publisher sends a CONNECT message containing connection parameters to the distribution component agent.
[0011] Step 2: Distribution component responds to connection, after receiving the CONNECT message, the distribution component verifies the connection parameters of the client; if the verification is passed, the distribution component sends the CONNACK message to confirm the successful connection;
[0012] Step 3: Publisher publishes messages, the publisher sends the PUBLISH message to the distribution component, specifying the topic and the payload;
[0013] Step 4: Distribution component receives the published message, after receiving the PUBLISH message, the distribution component verifies the publishing request, if the verification is passed, the distribution component modifies the topic, adds path information, constructs multiple messages respectively, and forwards them to the MQTT brokers on multiple paths;
[0014] Step 5: The arbitration component subscribes to the topic data on all MQTT broker paths, receives data by matching rules, respectively compares the topic payload from different paths for consistency, processes the consistent payload data, and publishes the processed data to the final subscriber.
[0015] Further, the quasi-security data exchange framework based on MQTT broker is specifically composed as follows:
[0016] Publisher: MQTT client application, according to the data type and device ID, publishes data to the distribution component in the form of (topic / device ID, payload data);
[0017] Distribution component: The distribution component is a modified MQTT broker service that can both publish topic payload data and subscribe to payload data; it subscribes to the data provided by the publisher, marks the topic path after receiving the data, and then performs one-to-three forwarding processing to forward the data to multiple MQTT brokers;
[0018] MQTT broker cluster: Redundant parallel MQTT brokers are used, which receive topic data published by the distribution component, and the topic data are marked with path branches to provide subsequent arbitration components for data merging processing;
[0019] Arbitration component: The arbitration component is also a modified MQTT broker service that can both publish topic payload data and subscribe to payload data; it subscribes to path data of the same topic from multiple MQTT brokers, uses MQTT topic matching rules path, then removes the minority according to the consistency arbitration method, provides a data to the final subscriber in the form of (topic / device 1, payload data); if an exception is found, the negative feedback component is notified to perform cleaning and replacement on the MQTT broker executor that has occurred an exception;
[0020] Subscriber: MQTT client application, receiving various data from underlying sensor terminals and forming various advanced applications;
[0021] Negative feedback component: Receives notifications from the adjudication component. The negative feedback component can intervene in the execution of the program, stopping the MQTT agent, restoring the binary image, restarting, and providing scheduling services.
[0022] Preferably, the connection parameters in step 1 may be client ID, user name, and password.
[0023] Preferably, the system is built by deploying a docker container on a cloud-native operating system such as Debian or Ubuntu as the deployment environment of the MQTT agent executor.
[0024] Furthermore, the distribution component is modified through the mosquitto agent and plug-ins. It supports plug-ins to extend its functions and is programmed in C language. When the agent receives topic data, it calls the Mosquitto library function mosquitto_publish. The arbitration component is also modified through the mosquitto agent and plug-ins. It is implemented internally using a competitive hierarchical arbitration algorithm. It waits for the same topic payload within a time window. When receiving multiple topic payload data, it starts to compare the payload data with the same topic but different paths. When the payloads are consistent, this payload is selected and returned to the client. When there are inconsistent payloads, the dockerAPI library function is called to schedule the mosquitto agent to implement cleaning and recovery.
[0025] The negative feedback management component is implemented based on the native API of the Docker client. It can stop, delete, and create new containers for running Mosquitto containers, restart containers, and replace failed containers in a timely manner to achieve dynamic recovery of system data upload and download.
[0026] The MQTT broker executor component builds a container based on the mosquitto broker and is deployed on a cloud-native operating system. The container can be stopped / started through the Docker command line.
[0027] The beneficial effects of the present invention are:
[0028] 1) Secure Data Center
[0029] The present invention expands the security protection method in edge-side smart devices and uses an MQTT proxy cluster to prevent the failure of a single data center from causing the failure of smart converged terminal devices.
[0030] 2) Mimic security architecture based on data exchange
[0031] Based on the existing mimetic security defense architecture and according to the characteristics of the MQTT protocol, the present invention realizes a new mimetic security architecture for the purpose of data exchange.
[0032] 3) MQTT High Availability
[0033] Redundant MQTT brokers can provide failover and high availability. When one broker fails, the other brokers can take over its tasks and subscriptions, and initiate an automatic recovery process.
[0034] Through these improvements, the present invention enhances the security protection capability of data exchange and improves the security of intelligent fusion terminal equipment. BRIEF DESCRIPTION OF THE DRAWINGS
[0035] Figure 1 This is a diagram of the deployment of general intelligent converged terminal applications;
[0036] Figure 2 This is a schematic diagram of a typical mimic security framework;
[0037] Figure 3 Schematic diagram of the mimetic secure data exchange method of the present invention;
[0038] Figure 4 This is a schematic diagram of the distribution component of the present invention;
[0039] Figure 5 This is a schematic diagram of the arbitration component of the present invention. DETAILED DESCRIPTION
[0040] The present invention is described in detail below with reference to the accompanying drawings and specific embodiments. This embodiment is implemented based on the technical solution of the present invention, and provides a detailed implementation method and specific operation process, but the protection scope of the present invention is not limited to the following embodiments.
[0041] In response to the above problems, the present invention proposes a mimetic secure data exchange method based on tandem MQTT agent clusters. The solution is to utilize the subscription / distribution capabilities of MQTT agents to construct a redundant MQTT agent cluster, and broadcast a piece of data to multiple MQTT agents through the distribution component. In this way, even if a single agent fails, the data can still reach the subscriber. In order to solve the problem of data duplication, a mimetic secure large number arbitration method is adopted to merge the data of the same topic. Even if the data is tampered with, it will not affect the result. Figure 3 :
[0042] To further illustrate this mimicry secure data exchange method, the following describes the components of the MQTT proxy cluster:
[0043] 1) Publisher
[0044] MQTT client applications publish data to distribution components, such as data collection applications, in the form of (topic / device ID, payload data) based on the data type and device ID.
[0045] 2) Distribution components
[0046] The dispatch component is a modified MQTT proxy service that can both publish and subscribe to topic payload data. It subscribes to data provided by publishers, tags the received data with the topic path, and then performs a one-to-three forwarding process, forwarding the data to multiple MQTT brokers.
[0047] 3)MQTT broker cluster
[0048] Redundant parallel MQTT agents (similar to the redundant executors of the mimicking system) are used to receive topic data published by the distribution components. The topic data are marked with path branches and provide subsequent arbitration components for data merging processing.
[0049] 4) Adjudication Component
[0050] The arbitration component is a modified MQTT proxy service that can both publish and subscribe to topic payload data. It subscribes to path data for the same topic across multiple MQTT brokers, using the MQTT topic matching rule. For example, "topic / device1 / +" matches data from three paths: topic / device1 / 1, topic / device1 / 2, and topic / device1 / 3. It then uses a consensus arbitration method to eliminate the minority and present a single data point, forwarding it to the final subscriber as (topic / device1, payload data). If an anomaly is detected, the negative feedback component is notified to clean and replace the MQTT broker executor that experienced the anomaly.
[0051] 5) Subscribers
[0052] MQTT client applications receive various types of data from underlying sensor terminals and form a variety of advanced applications, such as analysis applications and remote meter reading applications.
[0053] 6) Negative feedback component
[0054] After receiving notifications from the adjudication component, the negative feedback component can intervene in the execution of the program, stopping the MQTT agent, restoring the binary image, restarting it, and providing scheduling services.
[0055] The above is the composition structure of the mimetic security data exchange framework based on MQTT agent. The following introduces the workflow of the system.
[0056] Step 1: Client publisher connects to distribution component, publisher sends CONNECT message to distribution component broker, containing connection parameters such as client ID, username, password, etc.
[0057] Step 2: Distribution component responds to connection, after receiving the CONNECT message, the distribution component verifies the client's connection parameters (such as username and password). If the verification is passed, the distribution component sends a CONNACK message to confirm the successful connection.
[0058] Step 3: Publisher publishes messages, publisher sends PUBLISH message to distribution component, specifying topic and payload. For example: topic sensor / temperature, payload 25.5, QoS level 1.
[0059] Step 4: Distribution component receives published messages, after receiving the PUBLISH message, the distribution component verifies the publishing request, if the verification is passed, the distribution component modifies the topic, adds path information, constructs 3 messages with topic sensor / temperature / 1, sensor / temperature / 2, sensor / temperature / 3, payload 25.5, QoS level 1 respectively, and forwards them to the MQTT broker on the three paths.
[0060] Step 5: Decision component subscribes to all MQTT broker path topics, receives data by matching rules, compares the topic payloads from different paths for consistency, processes the consistent payload data, and publishes the processed data to the final subscriber. For example: topic payload (sensor / temperature / 1, 25.5), (sensor / temperature / 2, 25.5), (sensor / temperature / 3, 25.6), payload 25.5, 25.5, 25.6, consistent 25.5, then send (sensor / temperature / 1, 25.5).
[0061] DETAILED DESCRIPTION The system is built on a deployment environment of docker containers as MQTT broker executors on Debian, Ubuntu cloud-native operating systems.
[0062] 1) The distribution component is modified through mosquitto broker and plug-ins, as shown in Figure 4 It supports plug-in extension of its functions, programmed in C language, and calls Mosquitto library function mosquitto_publish when the broker receives topic data. The following is a code example showing how to forward messages to the target MQTT broker when the broker receives topic messages.
[0063]
[0064]
[0065] 2) The arbitration component is modified through the Mosquitto agent and plug-ins. It is implemented internally using a competitive hierarchical arbitration algorithm. It waits for the same topic payload within a time window. When receiving payload data from multiple topics, it starts to compare payload data with the same topic but different paths. When the payloads are consistent, this payload is selected and returned to the client. If there are inconsistent payloads, the Docker API library function is called to schedule the Mosquitto agent for cleaning and recovery. Figure 5 It is composed of adjudication components.
[0066] 3) The negative feedback management component is implemented based on the native API of the Docker client. It can stop, delete, and create new containers for running Mosquitto containers, restart containers, and replace failed containers in a timely manner to achieve dynamic recovery of system data upload and download.
[0067] 4) The MQTT agent executor component builds a container based on the mosquitto broker and is deployed on a cloud-native operating system. The container can be stopped / started through the Docker command line.
[0068] The above-described embodiment merely represents one embodiment of the present invention. While the description is relatively specific and detailed, it should not be construed as limiting the scope of the patent. It should be noted that a person skilled in the art would be able to make various modifications and improvements without departing from the spirit of the present invention, and these modifications and improvements fall within the scope of protection of the present invention. Therefore, the scope of protection of the patent for this invention shall be determined by the appended claims.
Claims
1. A mimetic secure data exchange method based on MQTT, characterized in that: This method uses the subscription / distribution capabilities of the MQTT proxy to construct an MQTT proxy redundant cluster. It broadcasts a piece of data to multiple MQTT proxies through a distribution component and merges data on the same topic using a mimetic secure large number arbitration method. This method is based on the mimetic secure data exchange framework of the MQTT proxy, which includes a publisher, a distribution component, an MQTT proxy cluster, an arbitration component, a subscriber, and a negative feedback component. The method includes the following steps: Step 1: The client publisher connects to the distribution component. The publisher sends a CONNECT message containing connection parameters to the distribution component agent. Step 2: The distribution component responds to the connection. After receiving the CONNECT message, the distribution component verifies the client's connection parameters. If the verification is successful, the distribution component sends a CONNACK message to confirm the successful connection. Step 3: The publisher publishes the message. The publisher sends a PUBLISH message to the distribution component, specifying the topic and payload. Step 4: The distribution component receives the publish message. After receiving the PUBLISH message, the distribution component verifies the publish request. If the verification passes, the distribution component modifies the topic, adds path information, constructs multiple messages, and forwards them to the MQTT brokers on multiple paths respectively. Step 5: The adjudication component subscribes to topic data on all MQTT agent paths, receives data through matching rules, compares the consistency of topic payloads from different paths, processes them into consistent payload data, and publishes the processed data to the final subscriber.
2. The MQTT-based mimetic secure data exchange method according to claim 1, characterized in that: The specific composition of the mimetic secure data exchange framework based on MQTT agent is as follows: Publisher: An MQTT client application that publishes data to the distribution component in the form of "topic / device ID, payload data" based on the data type and device ID. Distributor: The Distributor is a modified MQTT proxy service that can both publish and subscribe to topic payload data. It subscribes to the data provided by the publisher. After receiving the data, it marks the topic path and then performs a one-to-three forwarding process to forward the data to multiple MQTT brokers. MQTT agent cluster: Using redundant parallel MQTT agents, the MQTT agents receive topic data published by the distribution component. The topic data is marked with path branches and provides data merging processing for subsequent arbitration components. Adjudication component: The adjudication component is also a modified MQTT proxy service that can both publish topic payload data and subscribe to payload data; It subscribes to the path data of the same topic from multiple MQTT brokers, uses the MQTT topic matching rule path, and then eliminates the minority according to the consistency decision method, providing a data and forwarding it to the final subscriber with "topic / device 1, payload data"; If an exception is found, the negative feedback component is notified to clean and replace the MQTT agent execution body where the exception occurred; Subscriber: MQTT client application, receiving various data from the underlying sensor terminals and forming a variety of advanced applications; Negative feedback component: Receives notifications from the adjudication component and performs runtime intervention on the execution program, stopping the MQTT agent, restoring the binary image, restarting, and providing scheduling services.
3. The MQTT-based mimetic secure data exchange method according to claim 1, characterized in that: The connection parameters in step 1 are client ID, user name, and password.
4. The MQTT-based mimetic secure data exchange method according to claim 1, wherein: This system is built by deploying Docker containers on Debian and Ubuntu cloud-native operating systems as the deployment environment for the MQTT broker executor.
5. The MQTT-based mimetic secure data exchange method according to claim 1, wherein: The distribution component is modified through the Mosquitto proxy and plug-ins. It supports plug-ins to extend its functions and is programmed in C language. When the proxy receives topic data, it calls the Mosquitto library function mosquitto_publish. The arbitration component is also modified through the Mosquitto proxy and plug-ins. It is implemented internally using a competitive hierarchical arbitration algorithm. It waits for the same topic payload within a time window. When receiving multiple topic payload data, it starts to compare the payload data with the same topic but different paths. When the payloads are consistent, this payload is selected and returned to the client. If there are inconsistent payloads, the Docker API library function is called to schedule the Mosquitto proxy for cleaning and recovery. The negative feedback management component is implemented based on the native API of the Docker client. It stops, deletes, and creates new containers for running Mosquitto containers, restarts containers, and replaces failed containers in a timely manner to achieve dynamic recovery of system data upload and download. The MQTT broker executor component builds a container based on the mosquitto broker and is deployed on a cloud-native operating system. The container can be stopped / started through the Docker command line.
Citation Information
Patent Citations
Real-time data distribution system with distributed network architecture and working method thereof
CN101848236A
Digital twin virtual-real network information real-time interaction method
CN113608887A