Data transmission method of MQTT protocol dynamic message format based on mimicry defense

Abstract

The invention relates to a mimicry defense-based MQTT protocol dynamic message format data transmission method, which comprises the following steps of: establishing connection between a client and a server, and negotiating an initial message format; dynamically switching message formats according to time, the number of messages or other conditions in the communication process; various message formats enhance the security and unpredictability of the messages according to different coding, compression or camouflage rules; meanwhile, through a dynamic and randomized message format, an attacker is difficult to replay or tamper the attack system through traffic analysis; according to the design, a dynamic message format, protocol negotiation and a security policy are combined together, a mimicry defense mechanism is provided for the MQTT, and the security and the anti-attack capability of the protocol can be remarkably enhanced; the problem that when an MQTT protocol is used in Internet of Things communication, safety, cost and efficiency are difficult to balance is solved, the safety and robustness of message transmission are improved, and therefore the attack difficulty of an attacker is increased under the condition that the influence on the transmission efficiency is minimum.

Description

Technical Field

[0001] The present invention relates to the fields of network security technology and Internet of Things technology, and in particular to a data transmission method in a dynamic message format of an MQTT protocol based on a mimicry defense concept. Background Art

[0002] The Internet of Things (IoT) technology is to connect objects to the network, establish connections between objects and between objects and people, and realize information exchange and communication control between different target objects. It is a network that extends and expands on the basis of the Internet. With the rapid development of electronic information and communication technology and the growth of intelligent demand in production and life, the rapid development of IoT technology has been widely used in smart cities, smart medical care, smart homes, smart transportation, smart logistics, smart agriculture, smart industry and other fields. IoT nodes use various sensors and other technologies to fully and intelligently perceive, transmit and process the massive data generated in various industries and fields, and build a bridge between the physical world and the digital world through the Internet or other networks, thereby realizing the intelligent, digital and automated management and control of the physical world. From daily life to industrial control, the IoT reflects its important role in the process of social development at the same level. The types and numbers of IoT devices are increasing, and the application environment they deal with is becoming more and more complex. IoT security faces new risks and challenges. Providing safe, stable and reliable data transmission services is one of the key issues that need to be studied in the field of IoT.

[0003] The communication between IoT devices requires secure, stable and reliable data transmission services, which must rely on IoT protocols. At present, the communication protocol design of IoT control systems mainly includes extensible messaging and presence protocol (XMPP), hypertext transfer protocol (HTTP), constrained application protocol (CoAP), and message queuing telemetry transport (MQTT). These four communication protocols differ in transmission mode, message type, timeliness, transmission efficiency and power consumption. As a universal message queue transmission protocol in IoT environment, MQTT protocol is located in the application layer of TCP / IP protocol stack and can provide connected devices with instant and reliable message services based on publish-subscribe mode with low overhead and low bandwidth occupation. It has the advantages of light weight, openness, simplicity, efficiency and easy implementation, and is very suitable for scenarios with strict restrictions on power consumption and network bandwidth. The advantage of the publish-subscribe model adopted by MQTT is that the client has two identities in the protocol, publisher (Publish) and subscriber (Subscribe). The client can publish messages to other subscribers as a publisher, allowing the data published by a sensor to trigger the actions of multiple subscribers, and can also receive messages published by other publishers as a subscriber. The server side acts as a broker and is responsible for the distribution of messages. However, the MQTT protocol has major security issues: the protocol transmits data between communication networks in plain text, which means that sensitive information may be easily intercepted and stolen by unauthorized attackers; the protocol lacks an efficient and secure identity authentication mechanism, which makes the system vulnerable to man-in-the-middle attacks. Attackers may steal and tamper with the communication content, posing a serious threat to data security and data integrity. Therefore, when using the MQTT protocol, additional security measures must be taken to strengthen the confidentiality of data transmission and the reliability of identity authentication. However, although encrypting the entire message for transmission can improve security, it will also increase processing costs, thereby reducing transmission efficiency.

[0004] The core of the Internet of Things lies in devices with certain computing power, storage capacity and networking capabilities, which can realize data collection and transmission and provide support for decision-making through data analysis technology. Users can also remotely control IoT devices through the Internet to achieve automated operations. Therefore, IoT technology also faces many challenges in terms of security, such as IoT devices are easy targets for hacker attacks and prevent information leakage and abuse. MQTT is a lightweight message transmission protocol widely used in the Internet of Things. It is based on the publish / subscribe model, allowing devices to send messages to topics and allowing other devices to subscribe to these topics to receive messages. It is designed for low-bandwidth and unreliable networks. The protocol is simple and efficient and suitable for resource-constrained devices. However, MQTT itself lacks a built-in security mechanism. No encryption mechanism is provided by default. MQTT messages are transmitted in plain text and are easy to be intercepted; and the authentication mechanism of MQTT is relatively simple, which may not be sufficient to deal with complex network security threats. The MQTT protocol communication model is as follows: Figure 1 shown.

[0005] Under the new situation, network security issues have begun to attract widespread attention. In order to deal with unknown attacks and threats in cyberspace, the theory of mimetic security has been widely used. Mimetic technology performs mimetic transformation on the MQTT protocol, including but not limited to the connection mode and message format of the sender and receiver, and changes the behavior mode of the sender to enhance its security. Mimetic technology increases the difficulty of attackers' prediction by dynamically changing the behavior mode of the system, making it difficult for attackers to predict the operation mode of the client, thereby improving the security of the protocol. Summary of the invention

[0006] Aiming at the problem that it is difficult to balance security, cost and efficiency when using the MQTT protocol in IoT communications, a data transmission method of the dynamic message format of the MQTT protocol based on mimicry defense is proposed. The method aims to improve the security and robustness of the transmitted message by dynamically changing the format and behavior mode of the transmitted message, making it difficult for attackers to predict its behavior. It involves a dynamically changing strategy so that the operation mode of MQTT is not easy for attackers to grasp. Even if the message is intercepted, it is difficult to correctly decode and obtain the correct information, thereby increasing the difficulty of the attacker's attack with minimal impact on the transmission efficiency.

[0007] The technical solution of the present invention is:

[0008] A data transmission method for the dynamic message format of the MQTT protocol based on mimicry defense, wherein the client establishes a connection with the server and negotiates an initial message format; during the communication process, the message format is dynamically switched according to time, number of messages or other conditions; various message formats enhance the security and unpredictability of messages according to different encoding, compression or disguise rules; at the same time, through the dynamic and randomized message format, it is difficult for attackers to attack the system through traffic analysis, replay or tampering; this design combines dynamic message format, protocol negotiation and security strategy, provides a mimicry defense mechanism for MQTT, and can significantly enhance the security and anti-attack capability of the protocol; the specific steps are as follows:

[0009] Step 1: The client and server establish a connection and negotiate a key

[0010] First, the client sends a CONNECT message to initiate a connection with the MQTT server and negotiate the exchange of dynamic security keys;

[0011] Step 1.1: The client sends a topic SECURE via a PUBLISH message, which contains a large prime number P and a primitive root G. The server receives the message and parses P and G.

[0012] Step 1.2: The client generates a private key a, and then uses G and P to perform a modulo exponentiation calculation on a to obtain a public key A. The client then uses a PUBLISH message to send its own public key A, with the subject PUBKEYA. The server subscribes to this subject to receive the client's public key.

[0013] Step 1.3: At the same time, the server generates a private key b, and the same operation is performed to obtain a public key B. Then the server sends its own public key B using a PUBLISH message, and the subject can be PUBKEYB. The client subscribes to this subject to receive the server's public key.

[0014] Step 1.4: The client uses the server's public key B and its own private key a, while the server uses the client's public key A and its own private key b, and uses a large prime number P to calculate the same shared key S. This shared key S is the key that both parties can use to encrypt and decrypt subsequent communications; both parties send a PUBLISH message to a common topic CONFIRM, with the content being GETKEY to confirm the shared key, thereby notifying each other to ensure that both parties confirm the successful generation of the shared key;

[0015] Step 2: Message format negotiation

[0016] After the client and the server have negotiated the key, the key can be used in subsequent MQTT messages to encrypt the key information of the message; to achieve dynamic message format, in the interaction with the server, the client needs to add an additional field in the message sent to the server and encrypt it with the key to indicate the list of message formats it supports; then after the server receives the client message, it uses the corresponding key to decrypt it to obtain the message format supported by the client, and also returns the message format it supports in the message response sent to the client, which is encrypted with the corresponding key before sending. Similarly, after receiving the server's response, the client will use the key to decrypt it and obtain all message formats supported by the server;

[0017] Based on the message format lists supported by the client and the server when establishing a connection, the two parties negotiate the initial message format used in the current session. The negotiation mechanism includes the two parties selecting the intersection of the supported lists and determining based on priority to determine whether the server will randomly decide or decide in order. After encryption, the message is sent to the client, and the client decrypts it to obtain the format specified by the server, and the message format is negotiated.

[0018] Step 3: Initialize Communication

[0019] After the message format is determined, the client and server start communicating and use the negotiated message format for data transmission. The message sent by the client will be encoded according to the rules of the message format, that is, the client will fill pseudo-random data in the real message to hide the actual payload in the disguised data. After the server receives it, it will identify the format_id field and use the security key to decrypt it. The corresponding parser will be used to strip the disguised data and extract the payload, thereby restoring the message content to obtain the real message content. In the process, the two parties do not need additional handshake and communication processes, and the transmission overhead will not be increased.

[0020] Step 4: Dynamic format switching trigger

[0021] During the communication process, the dynamic switching of the message format needs to be triggered according to the following conditions: time trigger, message count trigger, special condition trigger. Once the trigger condition is met, the client sends an encrypted CONTROL message to notify the server to switch the message format.

[0022] Step 5: Switch the message format

[0023] After receiving the CONTROL message from the client, the server uses the key to decrypt the message, parses the switching instruction, and switches the subsequent message format; then the server responds with ACK to confirm that the switching is successful. The switching confirmation message also needs to be encrypted by the server. In this way, after the client receives the switching confirmation instruction, it uses the key to decrypt it and obtains confirmation from the server, and then uses the new message format for communication;

[0024] Step 6: Post-Switch Communication

[0025] After the format switching is successful, both parties continue to communicate using the new message format; the server parses the format after receiving the message and obtains the real message content after decoding;

[0026] Step 7: Session Termination

[0027] At the end of the communication, the client sends a DISCONNECT message to inform the server to terminate the session; after receiving it, the server closes the current session and clears the message format status in the session.

[0028] Furthermore, the MQTT protocol communication includes an MQTT client and an MQTT server. This method introduces a message format template table, a dynamic message format selection mechanism, a format seamless switching mechanism, and an error handling and fallback mechanism to improve the security and robustness of message transmission.

[0029] Message format template table: The MQTT message format consists of 3 fields. The fixed header must exist in all MQTT data packets and occupies 2 bytes. The variable header can be used to store the message format. The data being sent in the packet body is stored in the packet body. Design a variety of alternative message formats for different message types of the MQTT protocol. The sender and the receiver jointly agree to define the message format template table. Each template has different fields and structures, including different message headers, data parts, and checksum parts. Each format contains the following content: Message header: including fixed identifiers, version information, and message types. The order of fields in different message types varies randomly or according to a predetermined algorithm between different formats. Different formats are designed in the same message type to combine more different message formats. Use variable-length fields. Data part: Use different data formats such as JSON, XML, and binary. The data inside the field uses a variety of encoding methods, which are dynamically selected according to security requirements. Checksum part: The checksum field uses timestamps, CRC, and secure hashes.

[0030] Dynamic message format selection mechanism: Dynamic format selection is added to the implementation of the MQTT protocol. This mechanism is responsible for selecting the message format according to the strategy and switching it in real time during the communication process, so that different formats can be selected when the message is transmitted. In the dynamic strategy, the dynamic negotiation mechanism is the key. Here, both the sender and the receiver use a message format negotiation process based on a predefined rule:

[0031] In the connection establishment phase, in order to enhance security, a dynamic security key S is generated through a secure key exchange protocol when connecting. In order to exchange keys securely over an insecure communication channel, the Diffie-Hellman key exchange protocol is used to generate a dynamic security key. Both the client and the server can use the key S for encryption and decryption. The client and the server negotiate the message format, exchange the supported format list, and use the obtained security key S to ensure the security of the negotiated list message. In subsequent communications, a custom extension field is added to the MQTT message to store the supported message format version. The client and the server select the message format according to the preset rules and algorithms each time they exchange data. You can choose to randomly select one from the predefined format templates, or use each format in turn in a polling manner to ensure that all formats are used evenly.

[0032] Seamless format switching mechanism: Before establishing a connection session, the client and server obtain a security key through a negotiation process, and extend a field in the MQTT message to specify the message format. According to the result of the dynamic selection algorithm, the receiver can accurately parse and understand the message format currently used through this version field; it can be dynamically adjusted during the session, and a time interval or message reception interval is set to regularly switch the message format in the session. The other party is notified to switch the message format through a specific control message CONTROL message, and the message format can be switched flexibly and transparently without affecting normal communication; this means that the communicating parties do not need additional handshakes or negotiation processes, and can adjust the message format used in real time according to security requirements or system status;

[0033] Error handling and fallback mechanism: If the receiver does not support or cannot recognize the message format selected by the sender, an error handling mechanism is implemented, such as sending an error response message to request the sender to resend the message using another supported format; if communication cannot be completed after multiple reconnection timeouts, it can fall back to the standard MQTT format to ensure the continuity of communication.

[0034] Furthermore, the technical details of this method are as follows:

[0035] Multiple message format definitions: Design multiple message formats so that the protocol can switch between these formats during communication; each format has different structures and encoding rules;

[0036] Dynamic format switching mechanism: Define a dynamic mechanism to select and switch message formats, which can be based on a variety of factors;

[0037] Format negotiation: When establishing a connection or at the beginning of a session, the client and server decide the message format to use through a negotiation process; that is, a field is extended in the MQTT CONNECT message to specify the message format or format list;

[0038] Dynamic adjustment: During a conversation, a specific control message CONTROL message is used to notify the other party to switch the message format; this control message contains the switching instruction and related parameters;

[0039] Time / session trigger: set a time interval or session interval to regularly switch the message format in the session;

[0040] Message format identification: In order to enable the client and server to correctly read and parse the message, a unique identifier is defined for each message format so that both parties can identify and correctly decode it when parsing the message. This identifier is placed in the message header;

[0041] Message format parsing: Define client and server parsers to support all defined message formats. The parsers can dynamically select the appropriate decoding method based on the format_id field of the message.

[0042] The beneficial effects of the present invention are:

[0043] Based on the idea of ​​mimicry defense, the present invention adds a dynamic key mechanism to the basic model of the MQTT protocol, a dynamic message format selection mechanism, and increases the security of MQTT protocol transmission by dynamically changing the transmission message format. This method dynamically changes the message format, making it difficult for attackers to accurately predict the specific structure of the message, reducing the risk of being cracked; since the message format is constantly changing, even if the attacker successfully cracks the message format at a certain moment, it cannot be guaranteed to be still valid in the future time period, reducing the attacker's attack success rate.

[0044] Dynamic message formats can achieve polymorphism, that is, the same message may have different manifestations at different time points or under different conditions, which increases the difficulty of analysis for attackers and improves the MQTT protocol's ability to resist attacks. At the same time, in the process of adding dynamically changing message formats, both parties do not need additional handshakes and communication processes, nor do they need to encrypt message content for ciphertext transmission, which almost does not increase transmission overhead, and improves the security of information exchange in the IoT system with minimal impact on performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Figure 1 This is a diagram of the MQTT protocol communication model of the present invention;

[0046] Figure 2 This is the MQTT message format diagram of the present invention;

[0047] Figure 3 A diagram of a method for generating dynamic security keys between an MQTT client and a server according to the present invention;

[0048] Figure 4 This is a workflow diagram of the dynamic message format method of the present invention. DETAILED DESCRIPTION

[0049] The present invention is described in detail below in conjunction with 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.

[0050] The present invention introduces mimetic security technology and ideas based on the traditional MQTT protocol. MQTT lacks a built-in security mechanism and does not provide an encryption mechanism. Converting MQTT messages into ciphertext transmission will increase overhead and reduce transmission efficiency. Therefore, a dynamic message format is introduced to enhance the security of the protocol, making it less likely to be intercepted, leaked, and tampered with. At the same time, by introducing a dynamic key encryption mechanism and a dynamically changing system behavior pattern, the attacker's prediction difficulty is increased, effectively resisting potential threats during the transmission process. In order to ensure the security of the communication content to the greatest extent without affecting the transmission efficiency, the present invention improves the traditional MQTT message transmission method, aiming to build an MQTT protocol extension based on the idea of ​​mimetic security. The core idea is to increase the diversity and uncertainty of the message format through a dynamic mechanism without changing the MQTT protocol infrastructure, thereby improving the security of the protocol. The specific implementation includes the following aspects:

[0051] MQTT client: a program or device that uses MQTT. In the Internet of Things, it is usually a variety of sensor nodes. There are usually two types, publishers and subscribers. The publisher mainly connects to the cloud proxy server MQTT Broker through WiFi, collects and transmits various sensor data on site to the MQTT Broker, and the subscriber receives and parses the topic messages distributed by the MQTT Broker to measure and control the facilities and equipment on site, and interact with the remote measurement and control end. The client can be both a publisher and a subscriber. It can subscribe to request to receive related application messages; publish information that other clients may subscribe to; publish the working status topic of facilities and equipment, and interact with the remote measurement and control end.

[0052] MQTT server: commonly known as MQTT Broker, is the core component of the MQTT communication architecture, responsible for receiving messages from clients, storing these messages and forwarding them to clients that have subscribed to the corresponding topics. As a central node, the MQTT server manages the connections of all clients, processes the client's subscription requests, and ensures that messages can be transmitted reliably based on the topics subscribed by the client and the preset quality of service (QoS) level. The MQTT server is not only the hub of message transmission, but also a key component to ensure efficient, reliable and secure operation of the system.

[0053] Message format template table: The MQTT message format consists of 3 fields. The fixed header must exist in all MQTT data packets and occupies 2 bytes. The variable header can be used to store the message format. The data being sent is stored in the payload. For different message types of the MQTT protocol (such as CONNECT, PUBLISH, SUBSCRIBE, etc.), multiple alternative message formats are designed. The sender and the receiver jointly agree to define the message format template table. These formats differ in structure, including but not limited to field order, field length, encoding method, etc. Each template has different fields and structures, including different message headers, data parts, checksum parts, etc. Each format contains the following: 1) Message header: including fixed identifiers, version information, and message types. The order of fields in different message types varies randomly or according to a predetermined algorithm in different formats; and different formats are designed in the same message type, such as the subject name following the payload and before the payload, so as to combine more different message formats and increase the difficulty for attackers to parse messages. Using variable length fields, the encoding of the remaining length of the message can vary from one byte to four bytes, depending on the actual length, which increases flexibility. 2) Data part: Use different data formats such as JSON, XML, and binary. The data inside the field uses multiple encoding methods such as UTF-8 and Base64, which are dynamically selected according to security requirements. 3) Checksum part: The checksum field uses timestamps, CRC, and secure hashes to verify the integrity and freshness of the message. The MQTT message format is as follows: Figure 2 .

[0054] Dynamic message format selection mechanism: Dynamic format selection is added to the implementation of the MQTT protocol. This mechanism is responsible for selecting the message format according to the strategy and switching it in real time during the communication process, so that different formats can be selected when the message is transmitted. In the dynamic strategy, the dynamic negotiation mechanism is the key. Here, the sender and the receiver both use a pre-defined rule, such as using the currently generated random number and key to negotiate a new message format. Message format negotiation process: 1) During the connection establishment phase, in order to enhance security, a dynamic security key S is generated through a secure key exchange protocol when the connection is connected, such as Figure 3 In order to exchange keys securely over an insecure communication channel, a dynamic security key is generated using the Diffie-Hellman key exchange protocol. Both the client and the server can use the key S for encryption and decryption. This dynamic key greatly increases the difficulty for attackers to crack and obtain plaintext information, thereby providing security for all subsequent session messages. 2) The client and the server negotiate the message format, exchange the supported format list, and use the obtained security key S to ensure the security of the negotiated list message. In subsequent communications, a custom extension field is added to the MQTT message to store the supported message format version. 3) The client and the server select the message format according to preset rules and algorithms each time they exchange data. You can choose to randomly select one from the predefined format templates, or you can use each format in turn in a polling manner to ensure that all formats are used evenly. This method provides higher security because the attacker does not have the key, even if he can observe the message flow, this dynamic nature makes the message format used in each communication unpredictable, and it is difficult to determine the logic of the format selection.

[0055] Seamless format switching mechanism: Before establishing a connection session, the client and server obtain a security key through a negotiation process, and extend a field in the MQTT message to specify the message format. According to the result of the dynamic selection algorithm, the receiver can accurately parse and understand the message format currently used through this version field; it can be dynamically adjusted during the session, set a time interval or message reception interval, regularly switch the message format in the session, and notify the other party to switch the message format through a specific control message CONTROL message, which can flexibly and transparently switch the message format without affecting normal communication. This means that the communicating parties do not need an additional handshake or negotiation process, and adjust the message format used in real time according to security requirements or system status. In this way, even if attackers can intercept the message format of a communication, they cannot predict the message format of the next communication.

[0056] Error handling and fallback mechanism: If the receiver does not support or cannot recognize the message format selected by the sender, an error handling mechanism is implemented, such as sending an error response message to request the sender to resend the message in another supported format. If communication cannot be completed after multiple reconnection timeouts, it can fall back to the standard MQTT format to ensure the continuity of communication.

[0057] This solution can significantly improve the security of the MQTT protocol in the IoT environment and reduce the security risks caused by message format analysis without the need for additional encrypted messages and without affecting the protocol transmission efficiency. It has strong versatility and scalability and can be widely used in various IoT systems based on the MQTT protocol. The following is the overall working plan:

[0058] 1. Multiple message format definitions

[0059] Design multiple message formats so that the protocol can switch between these formats during communication. Each format has different structures and encoding rules. The following are some specific examples of message formats designed:

[0060] Basic format: standard MQTT message format, including fixed header and payload fields;

[0061] Disguised format: The message content is filled with pseudo-random data, and the actual payload is hidden in the disguised data;

[0062] Encoding format: The message content is encoded using a specific encoding algorithm, Base64;

[0063] ·Compression format: Use the gzip compression algorithm to compress the message body.

[0064] 2. Dynamic format switching mechanism

[0065] After defining multiple message formats, the present invention also defines a dynamic mechanism to select and switch message formats, which can be switched based on multiple factors, such as time, session, data content, etc.;

[0066] Format negotiation: When establishing a connection or at the beginning of a session, the client and server decide the message format to use through a negotiation process, that is, a field is extended in the MQTT CONNECT message to specify the message format or format list.

[0067] Dynamic adjustment: During a session, a specific control message CONTROL message is used to notify the other party to switch the message format. This control message contains the switching instruction and related parameters.

[0068] Time / session trigger: Set a time interval or session interval to switch the message format regularly in a session. For example, switch the format every certain period of time or after every N messages.

[0069] 3. Message format identifier

[0070] In order to allow the client and server to correctly read and parse the message, a unique identifier is defined for each message format so that both parties can identify and correctly decode it when parsing the message. This identifier is placed in the message header. The format example is as follows:

[0071]

[0072] Among them, format_id is the message format identifier, corresponding to 4 different formats:

[0073] {

[0074] 0: encoding format,

[0075] 1: Basic format,

[0076] 2: Compression format,

[0077] 3: Disguise format

[0078] }

[0079] Header is the header information. This definition allows the client and server to know how to parse the message.

[0080] 4. Message format analysis

[0081] Define client and server parsers to support all defined message formats. The parsers can dynamically select the appropriate decoding method based on the format_id field of the message. As follows:

[0082] Parser 1: Standard decoder.

[0083] Parser 2: strips away the disguised data and extracts the payload.

[0084] Parser 3: Base64 decodes the message.

[0085] Parser 4: decompresses the message using gzip.

[0086] The above are the definitions of the method for switching the dynamic message format of the simulated MQTT. The following describes the overall workflow, such as Figure 4 As shown:

[0087] Step 1: The client and server establish a connection and negotiate a key

[0088] First, the client sends a CONNECT message to initiate a connection with the MQTT server and negotiate the exchange of dynamic security keys.

[0089] 1) The client sends a topic SECURE via a PUBLISH message, which contains a large prime number P and a primitive root G. The server receives the message and parses P and G.

[0090] 2) The client generates a private key a, and then uses G and P to perform a modulo exponentiation calculation on a to obtain a public key A. The client then uses a PUBLISH message to send its own public key A, with the subject PUBKEYA. The server subscribes to this subject to receive the client's public key.

[0091] 3) At the same time, the server generates a private key b, and the same operation is performed to obtain a public key B. The server then uses a PUBLISH message to send its own public key B, and the subject can be PUBKEYB. The client subscribes to this subject to receive the server's public key.

[0092] 4) The client uses the server's public key B and its own private key a, while the server uses the client's public key A and its own private key b, and uses a large prime number P to calculate the same shared key S, which can be used by both parties to encrypt and decrypt subsequent communications. Both parties send a PUBLISH message to a common topic CONFIRM, with the content being GETKEY to confirm the shared key, thereby notifying each other to ensure that both parties confirm the successful generation of the shared key.

[0093] Step 2: Message format negotiation

[0094] After the client and the server have negotiated the key, the key can be used in subsequent MQTT messages to encrypt the key information of the message. To implement dynamic message formats, in the interaction with the server, the client needs to add an additional field to the message sent to the server and encrypt it with a key to indicate the list of message formats it supports. For example: {"message_formats_supported":["0","1","2","3"]}. Then, after the server receives the client message, it uses the corresponding key to decrypt it to obtain the message formats supported by the client. At the same time, it will also return the supported message formats in the message response it sends to the client, for example: {"message_formats_supported":["0","1","3"]}, which is encrypted with the corresponding key before sending. Similarly, after receiving the server's response, the client will decrypt it with the key to obtain all message formats supported by the server.

[0095] Based on the list of message formats supported by the client and server when establishing the connection, the two parties need to negotiate the initial message format used in the current session. The negotiation mechanism includes the intersection of the two parties' selection of supported lists and the determination of which method is determined randomly or in order by the server based on priority. For example, the server may decide to select format 3 as the initial format: {"selected_format":"3"}, encrypt it and send it to the client. After the client decrypts it and obtains the format specified by the server, the message format is negotiated.

[0096] Step 3: Initialize Communication

[0097] After the message format is determined, the client and server start communicating, for example, using the negotiated message format 3 for data transmission. The message sent by the client will be encoded according to the rules of message format 3, that is, the client will fill the real message with pseudo-random data, so that the actual payload is hidden in the disguised data. After the server receives it, it will identify the format_id field and decrypt it as 3 using the security key. The corresponding parser will be used to strip the disguised data and extract the payload, thereby restoring the message content to obtain the real message content. In the process, the two parties do not need additional handshake and communication processes, and the transmission overhead will not be increased.

[0098] Step 4: Dynamic format switching trigger

[0099] During the communication process, the dynamic switching of the message format needs to be triggered according to the following conditions:

[0100] Time trigger: For example, switch the format every 8 minutes.

[0101] Message count trigger: After every 12 messages are sent, switch to the next format.

[0102] Special condition trigger: For example, format switching is triggered after a security warning.

[0103] Once the trigger condition is met, the client sends an encrypted CONTROL message to notify the server to switch the message format. For example: {"control_message":"SWITCH_FORMAT","new_format":"0"}.

[0104] Step 5: Switch the message format

[0105] After receiving the CONTROL message from the client, the server uses the key to decrypt the message, parses the switch command, and switches the subsequent message format to 0. The server then responds with ACK to confirm that the switch is successful: {"control_ack":"SWITCH_FORMAT_SUCCESS","new_format":"0"}. The switch confirmation message also needs to be encrypted by the server. After the client receives the switch confirmation command, it uses the key to decrypt it and obtains confirmation from the server, and then uses the new message format for communication.

[0106] Step 6: Post-Switch Communication

[0107] After the format switching is successful, both parties continue to communicate using the new message format 0. That is, the client encodes the message content using a specific encoding algorithm Base64 and transmits it to the server, such as: {"format_id":"0","header":{...},"payload":"Base64 encoded data"}. After receiving the message, the server parses format 0 and uses parser 3 to Base64 decode the message to obtain the real message content.

[0108] Step 7: Session Termination

[0109] At the end of the communication, the client sends a DISCONNECT message to inform the server to terminate the session. After receiving it, the server closes the current session and clears the message format status in the session.

[0110] The above is the overall process of the dynamic message format switching of the mimetic MQTT, that is, the client establishes a connection with the server and negotiates an initial message format. During the communication process, the message format is dynamically switched according to time, number of messages or other conditions. Various message formats enhance the security and unpredictability of messages according to different encoding, compression or disguise rules. At the same time, through the dynamic and randomized message format, it is difficult for attackers to attack the system through traffic analysis, replay or tampering. This design combines dynamic message format, protocol negotiation and security strategy, providing MQTT with a mimetic defense mechanism, which can significantly enhance the security and anti-attack capabilities of the protocol.

[0111] The above-mentioned embodiment only expresses one implementation mode of the present invention, and its description is relatively specific and detailed, but it cannot be understood as limiting the scope of the invention patent. It should be pointed out that for ordinary technicians in this field, several modifications and improvements can be made without departing from the concept of the present invention, which all belong to the protection scope of the present invention. Therefore, the protection scope of the patent of the present invention shall be based on the attached claims.

Claims

1. A data transmission method in a dynamic message format of an MQTT protocol based on mimicry defense, characterized in that: The client establishes a connection with the server and negotiates an initial message format. During the communication process, the message format is dynamically switched according to time, number of messages or other conditions. Various message formats enhance the security and unpredictability of messages according to different encoding, compression or disguise rules. At the same time, through dynamic and randomized message formats, it is difficult for attackers to attack the system through traffic analysis, replay or tampering. This design combines dynamic message formats, protocol negotiation and security policies, providing a mimicry defense mechanism for MQTT, which can significantly enhance the security and anti-attack capabilities of the protocol. The specific steps are as follows: Step 1: The client and server establish a connection and negotiate a key First, the client sends a CONNECT message to initiate a connection with the MQTT server and negotiate the exchange of dynamic security keys; Step 1.1: The client sends a topic SECURE via a PUBLISH message, which contains a large prime number P and a primitive root G. The server receives the message and parses P and G. Step 1.2: The client generates a private key a, and then uses G and P to perform a modulo exponentiation calculation on a to obtain a public key A. The client then uses a PUBLISH message to send its own public key A, with the subject PUBKEYA. The server subscribes to this subject to receive the client's public key. Step 1.3: At the same time, the server generates a private key b, and the same operation is performed to obtain a public key B. Then the server sends its own public key B using a PUBLISH message, and the subject can be PUBKEYB. The client subscribes to this subject to receive the server's public key. Step 1.4: The client uses the server's public key B and its own private key a, while the server uses the client's public key A and its own private key b, and uses a large prime number P to calculate the same shared key S. This shared key S is the key that both parties can use to encrypt and decrypt subsequent communications; both parties send a PUBLISH message to a common topic CONFIRM, with the content being GETKEY to confirm the shared key, thereby notifying each other to ensure that both parties confirm the successful generation of the shared key; Step 2: Message format negotiation After the client and the server have negotiated the key, they can use the key to encrypt key information in subsequent MQTT messages. To implement dynamic message formats, in the interaction with the server, the client needs to add an additional field to the message sent to the server and encrypt it with the key to indicate the list of message formats it supports. After receiving the client message, the server uses the corresponding key to decrypt it and obtain the message formats supported by the client. At the same time, it will also return the message formats it supports in the message response it sends to the client. It uses the corresponding key to encrypt it before sending it. Similarly, after receiving the server's response, the client will use the key to decrypt it and obtain all the message formats supported by the server. Based on the list of message formats supported by the client and server when establishing a connection, the two parties need to negotiate the initial message format used in the current session; The negotiation mechanism includes the intersection of the supported lists selected by both parties and the priority level, which determines whether the server makes a random decision or a sequential decision. After encryption, the message is sent to the client, and the client decrypts the message to obtain the format specified by the server, and the message format is negotiated. Step 3: Initialize Communication After the message format is determined, the client and server start communicating and use the negotiated message format for data transmission. The message sent by the client will be encoded according to the rules of the message format, that is, the client will fill the real message with pseudo-random data to hide the actual payload in the disguised data. After receiving the message, the server will identify the format_id field and use the security key to decrypt it. The server will use the corresponding parser to strip the disguised data and extract the payload, thereby restoring the message content and obtaining the real message content. In the process, the two parties do not need additional handshake and communication processes, and the transmission overhead will not be increased. Step 4: Dynamic format switching trigger During the communication process, the dynamic switching of the message format needs to be triggered according to the following conditions: time trigger, message count trigger, special condition trigger. Once the trigger condition is met, the client sends an encrypted CONTROL message to notify the server to switch the message format. Step 5: Switch the message format After receiving the CONTROL message from the client, the server uses the key to decrypt the message, parses the switch instruction, and switches the subsequent message format; The server then responds with ACK to confirm that the switch is successful. The switch confirmation message also needs to be encrypted by the server. After the client receives the switch confirmation instruction, it uses the key to decrypt it and obtains confirmation from the server. After that, the new message format will be used for communication. Step 6: Post-Switch Communication After the format switching is successful, both parties continue to communicate using the new message format; the server parses the format after receiving the message and obtains the real message content after decoding; Step 7: Session Termination At the end of the communication, the client sends a DISCONNECT message to inform the server to terminate the session; after receiving it, the server closes the current session and clears the message format status in the session.

2. The data transmission method of the MQTT protocol dynamic message format based on mimicry defense according to claim 1 is characterized in that: MQTT protocol communication includes MQTT client and MQTT server. This method introduces message format template table, dynamic message format selection mechanism, seamless format switching mechanism, error handling and fallback mechanism to improve the security and robustness of message transmission. Message format template table: The MQTT message format consists of 3 fields. The fixed header must exist in all MQTT data packets and occupies 2 bytes. The variable header can be used to store the message format. The data being sent in the packet body is stored in the packet body. Design a variety of alternative message formats for different message types of the MQTT protocol. The sender and the receiver jointly agree to define the message format template table. Each template has different fields and structures, including different message headers, data parts, and checksum parts. Each format contains the following content: Message header: including fixed identifiers, version information, and message types. The order of fields in different message types varies randomly or according to a predetermined algorithm between different formats. Different formats are designed in the same message type to combine more different message formats. Use variable-length fields. Data part: Use different data formats such as JSON, XML, and binary. The data inside the field uses a variety of encoding methods, which are dynamically selected according to security requirements. Checksum part: The checksum field uses timestamps, CRC, and secure hashes. Dynamic message format selection mechanism: Dynamic format selection is added to the implementation of the MQTT protocol. This mechanism is responsible for selecting the message format according to the strategy and switching it in real time during the communication process, so that different formats can be selected when the message is transmitted. In the dynamic strategy, the dynamic negotiation mechanism is the key. Here, both the sender and the receiver use a message format negotiation process based on a predefined rule: In the connection establishment phase, in order to enhance security, a dynamic security key S is generated through a secure key exchange protocol when connecting. In order to exchange keys securely over an insecure communication channel, the Diffie-Hellman key exchange protocol is used to generate a dynamic security key. Both the client and the server can use the key S for encryption and decryption. The client and the server negotiate the message format, exchange the supported format list, and use the obtained security key S to ensure the security of the negotiated list message. In subsequent communications, a custom extension field is added to the MQTT message to store the supported message format version. The client and the server select the message format according to the preset rules and algorithms each time they exchange data. You can choose to randomly select one from the predefined format templates, or use each format in turn in a polling manner to ensure that all formats are used evenly. Seamless format switching mechanism: Before establishing a connection session, the client and server obtain a security key through a negotiation process, and extend a field in the MQTT message to specify the message format. According to the result of the dynamic selection algorithm, the receiver can accurately parse and understand the message format currently used through this version field; it can be dynamically adjusted during the session, and a time interval or message reception interval is set to regularly switch the message format in the session. The other party is notified to switch the message format through a specific control message CONTROL message, and the message format can be switched flexibly and transparently without affecting normal communication; this means that the communicating parties do not need additional handshakes or negotiation processes, and can adjust the message format used in real time according to security requirements or system status; Error handling and fallback mechanism: If the receiver does not support or cannot recognize the message format selected by the sender, an error handling mechanism is implemented, such as sending an error response message to request the sender to resend the message using another supported format; if communication cannot be completed after multiple reconnection timeouts, it can fall back to the standard MQTT format to ensure the continuity of communication.

3. The data transmission method of the MQTT protocol dynamic message format based on mimicry defense according to claim 1 is characterized in that: The specific definition of the techniques in this method is: Multiple message format definitions: Design multiple message formats so that the protocol can switch between these formats during communication; each format has different structures and encoding rules; Dynamic format switching mechanism: Define a dynamic mechanism to select and switch message formats, which can be based on a variety of factors; Format negotiation: When establishing a connection or at the beginning of a session, the client and server decide the message format to use through a negotiation process; that is, a field is extended in the MQTT CONNECT message to specify the message format or format list; Dynamic adjustment: During a conversation, a specific control message CONTROL message is used to notify the other party to switch the message format; this control message contains the switching instruction and related parameters; Time / session trigger: set a time interval or session interval to regularly switch the message format in the session; Message format identification: In order to enable the client and server to correctly read and parse the message, a unique identifier is defined for each message format so that both parties can identify and correctly decode it when parsing the message. This identifier is placed in the message header; Message format parsing: Define client and server parsers to support all defined message formats. The parsers can dynamically select the appropriate decoding method based on the format_id field of the message.

Images