A method, system, device and medium for distributed authentication and shared dynamic key based on MQTT protocol

Abstract

A distributed authentication and shared dynamic key method, system, device, and medium based on the MQTT protocol are disclosed. The method includes: initializing device information; filling the acquired authentication credentials into a CONNECT protocol frame and connecting to a Broker; the Broker requesting a decision from devices in the same group after receiving the connection request; the devices in the same group participating in the authentication decision and sending the results to the Broker; the Broker making a final decision based on the received response information; and encrypting and decrypting messages on the device side. The system, device, and medium are used to implement a distributed authentication and shared dynamic key method based on the MQTT protocol. This invention eliminates the traditional central authorization entity, distributes policy information and decision-making functions to multiple points, achieves system load balancing and attack resistance, eliminates the Broker's ability to decrypt messages, and utilizes device grouping technology to achieve a state where multiple devices share a session key. While maintaining lightweight operation, it extends the MQTT protocol with a distributed authentication mechanism and dynamic encryption scheme, greatly protecting network security and user privacy.

Description

Technical Field

[0001] This invention belongs to the field of Internet of Things (IoT) technology, specifically relating to a distributed authentication and shared dynamic key method, system, device, and medium based on the MQTT protocol. Background Technology

[0002] MQTT is widely adopted as a communication protocol specifically designed for the Internet of Things (IoT). Based on a publish-subscribe model, this protocol decouples communication between various devices, greatly simplifying the process. It's a centralized structure with two entities: clients and servers. Clients publish messages to the server and subscribe to specific topics. When the server receives a message for a particular topic, it forwards that message to interested clients. Compared to HTTP's request-response model, it's more efficient and has lower overhead, making it suitable for a wide range of constrained IoT devices.

[0003] To ensure MQTT's lightweight nature, the protocol does not provide security measures for device connection and message transmission. As a result, many adversary devices can easily connect to the network and carry out sabotage. Due to the weakness of MQTT's security measures, devices using MQTT are at risk of frequent attacks, and many security incidents occur frequently.

[0004] In 2016, SeongHan Shin combined AugPAKE (Enhanced Cryptographic Authentication Key Exchange) with MQTT to propose the AugMQTT security framework, which provides authentication mechanisms for MQTT devices and servers, as well as confidentiality and integrity of message transmission (Shin SH, Kobara K, Chuang CC, et al. A security framework for MQTT[C] / / 2016IEEE Conference on Communications and Network Security(CNS).IEEE,2016:432-436). This process verifies each other through four authentication information exchanges between the client and server, and each generates an equivalent session key for subsequent encrypted transmission of information. The drawback of this approach is that the broker is overloaded, as it simultaneously handles message transmission and authentication functions.

[0005] In the paper (Bhawiyuga A, Data M, Warda A. Architectural design of token based authentication of MQTT protocol in constrained IoT device[C] / / 2017 11th International Conference on Telecommunication Systems Services and Applications (TSSA). IEEE, 2017: 1-4), Adhitya Bhawiyuga proposed a token authentication mechanism that is implemented by introducing an additional token authentication server. The device first registers with the token server, then requests a token from the token server to authenticate the Broker. The Broker sends the token to the token server for verification, and a successful connection is established upon successful verification. In the literature (Bali RS, Jaafar F, Zavarasky P. Lightweight authentication for MQTT to improve the security of IoT communication[C] / / Proceedings of the 3rd International Conference on Cryptography, Security and Privacy. 2019:6-12), Ranbir Singh Bali et al. used a token-based authentication method between the device and the Broker. Prior to this, the Broker and the device used a chaotic algorithm to generate a constantly changing key stream and used a dynamic key to encrypt the token used for authentication to prevent adversaries from reusing the token. However, to reduce the burden on the Broker and to divide the functionality into multiple modules, an additional server was introduced to handle authentication. In this way, the Broker only handles message transmission, and the authentication server handles authentication. However, such centralized authentication servers are highly vulnerable to targeted attacks by adversaries, which can lead to the downtime of the entire system.

[0006] In 2020, Chintan Patel et al. designed a security framework in a generic IoT model (Patel C, Doshi NA novel MQTT security framework ingeneric IoT model[J]. Procedia Computer Science, 2020, 171: 1399-1408), comprising three phases: user device registration, sensor device registration, and user authentication. The user device registers its own information, the broker confirms and generates user credentials, which are sent to the user and stored by the user device. The sensor device registration process is similar. The user device uses the obtained credentials to authenticate the broker, the broker verifies and generates a session key between the user device and the sensor device, and sends it to both devices for encrypted message transmission. However, the broker needs to store the public keys of the user device and the sensor device, and also needs to calculate the session key between the devices, resulting in significant overhead.

[0007] The paper (Terada K, Ohno S, Mukai H, et al. Proposal of MQTT distributed broker control mechanism[C] / / 2020 International Conference on Information Networking (ICOIN).IEEE,2020:402-404) proposes a distributed broker control mechanism based on the congestion that occurs when a single broker forwards messages. It uses access control blocks and shared memory blocks as interoperability points to share data obtained from IoT devices over a wide area. The literature (Colombo P, Ferrari E, Tümer E D. Regulating datasharing across MQTT environments[J]. Journal of Network and Computer Applications, 2021, 174: 102907) proposes an access control framework that regulates data sharing across bridged MQTT environments based on access control policies and user preferences. The execution monitor that regulates data sharing acts as an intermediary between MQTT brokers, altering the communication flow between bridged environments and regulating data sharing in interconnected IoT environments. However, both of these approaches achieve distributed access through configuring broker clusters, which is relatively coarse-grained and not truly distributed in the strictest sense, and do not provide a solution for local access control decisions.

[0008] In 2020, Gu Zhengchuan, in his paper "Research on Key Security Technologies of MQTT for Zero Trust [D]", published by the Information Engineering University of the Strategic Support Force, proposed a solution from a zero-trust perspective, arguing that the entire network environment is untrustworthy. This solution involves the Broker using a re-encryption algorithm to re-encrypt the ciphertext of messages sent by the client, forwarding the re-encrypted ciphertext to interested clients, and having the receiving client use its private key to decrypt the ciphertext and obtain the plaintext. Throughout this process, the Broker cannot decrypt the message ciphertext, achieving end-to-end encryption. However, this comes at the cost of the server needing to pre-calculate and store the re-encryption key for each device pair, resulting in O(n²) time and space complexity. Although the Broker cannot obtain the plaintext message, the storage of a large number of re-encryption keys and the Broker's encryption operations incur significant overhead, and the keys used for encrypting messages are fixed and unchanging, making them vulnerable to cracking.

[0009] In summary, all existing technologies have the following technical problems:

[0010] 1. Many current authentication mechanisms adopt a centralized approach, which outsources decision-making functions to backend servers or gateways responsible for security tasks. This reduces the burden on message queues handling large amounts of access control information, but it also brings many drawbacks: edge devices need to fully trust the central authorization entity; users have relatively weak control over device information; centralized access control entities have single points of failure; and additional security measures are needed for messages from devices to the access control entity. Therefore, distributed access control mechanisms have become an urgent need.

[0011] 2. Many existing authentication mechanisms are costly. These authentication processes either involve numerous handshakes or use the HTTP protocol for token acquisition and verification. However, most IoT devices are limited in processing power and power consumption, making these mechanisms incompatible. Therefore, a lightweight authentication mechanism suitable for constrained devices is needed.

[0012] 3. Currently, almost all encryption schemes operate using a single key, focusing solely on the encryption method employed while ignoring the fatal flaw of single-key encryption. Even though existing encryption methods are highly complex to crack, once the single key is compromised or stolen, all subsequent information transmitted will be exposed to the adversary, causing incalculable losses. Therefore, we need to research a dynamic key scheme to increase the difficulty of message decryption.

[0013] 4. Most existing encryption mechanisms for MQTT extensions do not consider plaintext shielding for the broker. When ciphertext is transmitted from the terminal to the broker, the broker first decrypts the ciphertext and then encrypts the plaintext before transmitting it to the target terminal. This means the broker knows all the plaintext information, and in complex networks, broker security is difficult to guarantee. Therefore, we need to eliminate the decryption process at the broker and implement an end-to-end message encryption scheme. Summary of the Invention

[0014] To overcome the shortcomings of the prior art, the present invention aims to provide a distributed authentication and shared dynamic key method, system, device, and medium based on the MQTT protocol. First, it eliminates the traditional central authorization entity, distributing policy information and decision-making functions to multiple points to achieve system load balancing and attack resistance. Next, it eliminates the Broker's ability to decrypt messages, utilizing device grouping technology to achieve a state where multiple devices share a session key. Furthermore, by introducing timestamps to give the key dynamic change characteristics, it achieves end-to-end encrypted message transmission. This invention extends the MQTT protocol with a distributed authentication mechanism and dynamic encryption scheme while maintaining lightweight design, greatly protecting network security and user privacy.

[0015] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0016] A distributed authentication and shared dynamic key method based on the MQTT protocol includes the following steps:

[0017] Step 1: Device information initialization;

[0018] Step 2: Fill the CONNECT protocol frame with the authentication credentials obtained in Step 1 and connect to the Broker;

[0019] Step 3: After receiving the connection request, the Broker requests a decision from the devices in the same group;

[0020] Step 4: Devices in the same group participate in the authentication decision and send the results to the Broker;

[0021] Step 5: The Broker makes a final decision based on the response information obtained in Step 4.

[0022] Step 6: Encrypt and decrypt messages on the device side.

[0023] The specific method of step 1 is as follows: the user concatenates the family name and the device name and fills them into the client ID, and injects hidden value information into the device to prove the identity of their family as authentication credentials for subsequent connections;

[0024] The specific method of step 2 is as follows: Divide the devices in the home into administrator devices and ordinary devices. The administrator device is the first device to connect to the home, and the ordinary devices are the devices that connect later. The administrator device needs to fill in the username field, which is set to the hash value of the hidden user value. The ordinary device needs to fill in the password field, which is set to the dynamic hash value, that is, the hash value of the hidden value and the timestamp. After the initial operation is completed, the device sends a CONNECT protocol frame to the Broker. The CONNECT protocol frame includes the client ID, username and password. The client ID of the administrator device is the home name concatenated with "admin", and the client ID of the ordinary device is the home name concatenated with the device name.

[0025] In step 2: a hash algorithm module is added inside each device, and the hash algorithm module uses SHA-256, a secure hash algorithm.

[0026] The specific method of step 3 is as follows: When the Broker receives the CONNECT protocol frame, if it is an administrator device, it will directly connect and store the username field. If it is a regular device, it will block the connection request and analyze the family name from the client ID. The Broker will randomly select a connected device from the family and forward the authentication request. Specifically, it will publish a request for authentication information on the topic named family name. This information includes the password field of the device to be authenticated.

[0027] The specific method of step 4 is as follows: the selected device immediately calculates the HASH value of the hidden value & timestamp, and compares the calculation result with the received password field. If the result is consistent, it sends an agreement connection message to the Broker, that is, the encrypted ciphertext of the hidden value &agree; otherwise, it rejects the connection and sends the encrypted ciphertext of the hidden value &deny.

[0028] Before calculating the hash value in step 4, the timestamp is processed as follows: time1 = time2 / 1000, that is, counted in seconds, and the timestamp tail is converted in five-second intervals. When the hash value calculated by the participating authentication device is inconsistent with the hash value sent by the device to be authenticated, the time used for the first time is reduced by 5 seconds, the hash operation is performed again and compared. If they are consistent, the authentication is passed; otherwise, the connection is rejected.

[0029] The specific method of step 5 is as follows: When the Broker receives the decision result from the participating authentication device, it first decrypts the message with its own private key, calculates the hash value of the hidden value, and compares it with the username field stored in step 3 to ensure the legitimacy of the decision-maker, and then responds to the connection request according to the obtained decision result.

[0030] The specific method of step 6 is as follows: When a device needs to publish a message to a certain topic, it first calculates the real-time key using the pre-designed dynamic key generation algorithm, and then encrypts the message using the AES algorithm suitable for restricted devices. After encryption, the publishing end fills the ciphertext into the payload of the PUBLISH protocol frame and sends it to the Broker. The Broker forwards the ciphertext unchanged to the device that has subscribed to the current topic. The receiving device also uses the dynamic key generation algorithm and the AES algorithm to decrypt the ciphertext and finally obtain the message.

[0031] The key generation algorithm in step 6 is as follows: the input of the algorithm is the hidden value and the timestamp after mantissa processing. The algorithm performs cut, flip, expand and XOR operations on the input elements to obtain the real-time key, and the key length is 128 bits.

[0032] This invention also provides a distributed authentication and shared dynamic key system based on the MQTT protocol, comprising:

[0033] Policy edgeification module: It stores policy information, i.e. hidden values ​​used for authentication, on all edge devices through initialization; and transfers the decision-making function, i.e. authentication function, from the central authorization entity to the edge devices. It is used to cancel the central authorization entity. Policy information and decision-making function are distributed to multiple authorization points, and each time only one edge device is randomly selected for decision-making, so as to achieve system load balancing and anti-attack capability, and provide a secure and stable authentication mechanism.

[0034] Device grouping module: By introducing the family name into the client ID, the mechanism of grouping devices by family is realized. On this basis, devices in the same group can make decisions with each other and share session keys. The Broker forwards the decision-making function to devices in the same group by publishing the authentication request information to the family name topic. This module is used for multiple devices in the same family to share session keys.

[0035] Dynamic Key Module: This module uses two input elements, a hidden value and a timestamp, and performs cut, flip, expand, and XOR operations to obtain a real-time key. The key length is 128 bits, and the key generated at different times is different. This module is used to generate session keys that change over time in real time on the device.

[0036] The present invention also provides a device for implementing distributed authentication and shared dynamic keys based on the MQTT protocol, comprising:

[0037] Memory: Used to store computer programs;

[0038] A processor is configured to implement the distributed authentication and shared dynamic key method based on the MQTT protocol when executing the computer program.

[0039] The present invention also provides a computer-readable storage medium, comprising:

[0040] The computer-readable storage medium stores a computer program that, when executed by a processor, enables a distributed authentication and shared dynamic key method based on the MQTT protocol.

[0041] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0042] 1. This invention eliminates the traditional central authorization entity and distributes policy information and decision-making functions to multiple authorization points, thereby achieving system load balancing and attack resistance. It then eliminates the Broker's ability to decrypt messages and uses device grouping technology to achieve a state where multiple devices share a session key. In addition, by introducing timestamps to give the key dynamic change characteristics, it achieves end-to-end encrypted transmission of messages.

[0043] 2. This invention greatly limits the scope of adversary attacks by grouping devices, removes the role of the central authorization entity in the traditional access control system, and distributes decision-making functions to all end-side devices, achieving load balancing and hiding decision points, thus exhibiting high robustness.

[0044] 3. In terms of encryption, this invention allows all devices in the same group to share a constantly changing key using a designed algorithm, and the Broker does not need to hold the corresponding key. The device does not need to store the session key all the time, but only calculates the real-time key when data needs to be decrypted, thus reducing storage overhead.

[0045] 4. This invention balances the system's lightweight nature with compatibility with the standard MQTT protocol, and provides system security by fully adopting the transmission of MQTT protocol frames.

[0046] 5. This invention enables multiple devices in the same group to share the same constantly changing key, which eliminates the overhead of key storage and overcomes the disadvantage of single-key methods being easily stolen. In addition, the Broker only acts as a message forwarder and does not participate in message decryption, which greatly protects the user's privacy.

[0047] 6. Although existing technologies also use MQTT protocol frames to achieve system security, they require four information exchanges. In contrast, the device to be authenticated and the Broker in this invention only have two information exchanges, which is consistent with the standard MQTT connection process. The authentication process is completed entirely using MQTT protocol frames, which is compatible with the standard MQTT and is more lightweight.

[0048] 7. Although existing technologies also use dynamic keys to encrypt information, the Broker can decrypt messages, which requires additional assurance that the Broker is trustworthy. However, this is generally impractical or difficult to achieve in complex networks. This invention does not rely on the security of the Broker and can be deployed in insecure networks.

[0049] 8. Although the concept of distributed systems has emerged in existing technologies, they are all implemented by configuring Broker clusters, which is relatively coarse-grained. This invention builds end-side devices distributed in various locations into authorization points, realizing true distributed authentication and policy edge computing.

[0050] 9. Because the present invention uses device grouping technology, multiple devices in the same group can use the same session key, which overcomes the disadvantage of traditional schemes where each device has a key and has a large number of keys and large storage overhead. Attached Figure Description

[0051] Figure 1 This is a flowchart of the method of the present invention.

[0052] Figure 2 This is a diagram of the device grouping model architecture of the present invention.

[0053] Figure 3 This is the distributed authentication process of the present invention.

[0054] Figure 4 This is the framework of the encryption scheme of the present invention.

[0055] Figure 5 This is a schematic diagram of the timestamp tail number processing of the present invention. Detailed Implementation

[0056] The technical solution of the present invention will now be described in detail with reference to the accompanying drawings.

[0057] like Figure 1 As shown, step 1 is to initialize device information.

[0058] In this invention, each device belongs to a specific family. When a device connects to the Broker, it needs to indicate its family affiliation. This information is embedded in the client ID. The user first sets the device's client ID, which is a concatenation of the family name and the device name. In addition, to prove that it belongs to a family, the device needs to provide additional identity information, which is given as a hidden value. When the device is initialized, the user injects the hidden value information into the device, which is used as authentication credentials for subsequent connections. It should be noted that this hidden value is extremely sensitive and cannot be disclosed to any members other than the family.

[0059] Step 2: Fill the CONNECT protocol frame with the authentication credentials obtained in Step 1 and connect to the Broker.

[0060] In this invention, the basis for mutual authentication among devices in the same group lies in the ability to calculate the same hidden value hash at any time. The irreversibility of hash operations makes it difficult to crack within an acceptable timeframe unless these devices have the same initial input data. To prevent adversaries from stealing protocol frames and reusing hash values, a timestamp is introduced to give the hash values ​​dynamism. To ensure compatibility with standard MQTT, the username and password fields in the CONNECT protocol frame are used to fill the authentication hash value. Devices in the home are divided into two types: administrator devices and ordinary devices. The administrator device is the first device to connect to the home; its client ID is a concatenation of the home name and "admin". It needs to fill the username field with a hash value set to the hidden user value. When the broker receives the connection protocol frame, it stores this hash value for subsequent verification of the legitimacy of decision information from other devices in the same group. Ordinary devices are those that connect later; their client ID is a concatenation of the home name and device name. They need to fill the password field with a dynamic hash value, also known as HSAH (Hidden Value & Timestamp). This field is used for real-time authentication between devices in the same group. To transmit the hash value, each device needs to add a hash algorithm module. This invention uses the SHA-256 algorithm, a secure hash algorithm that can convert raw data of any length into a 256-bit digest value. Currently, there are no effective attack methods against SHA-256. Although it adds extra hashing operations, the authentication process is only performed once in a long while, which is not a very frequent operation. Therefore, the overhead is negligible compared to the frequent message publishing. After all the initial operations are completed, the device sends a CONNECT (client ID, username / password) protocol frame to the Broker.

[0061] Step 3: After receiving the connection request, the Broker requests a decision from the devices in the same group.

[0062] When the broker receives a CONNECT protocol frame, if it's an administrator device, it directly connects and stores the username field. If it's a regular device, it blocks the connection request and parses the home name from the client ID. The broker then randomly selects a connected device from that home and forwards an authentication request. Specifically, it publishes an authentication request message to a topic named "Home Name," which includes the password field of the device to be authenticated. It's important to note that each authenticated and connected device is subscribed to by the broker on the "Home Name" topic, allowing the broker to select clients for authentication within that topic.

[0063] Step 4: Devices in the same group participate in the authentication decision and send the results to the Broker.

[0064] The selected device immediately calculates the hash (hidden value & timestamp) and compares the result with the received password field. If they match, it sends an agreement message (enc(hidden value & agree)) to the Broker; otherwise, it rejects the connection and sends enc(hidden value & deny). The hidden value in the message is used by the Broker to verify the identity of the participating authentication device, ensuring that the two devices belong to the same group. enc represents encryption using the Broker's public key to prevent the hidden value from being leaked. This invention processes the timestamp, which is responsible for dynamic elements. The timestamp is originally counted in milliseconds. Due to a slight delay in the time it takes for the device to be authenticated and the participating authentication devices to calculate the hash value, the number of milliseconds will deviate significantly, resulting in inconsistent hash values. Before performing the hash calculation, this paper processes the timestamp as follows: time1 = time2 / 1000, that is, counted in seconds, and converts the timestamp tail in five-second intervals. The specific method is as follows: Figure 5 As shown, when the hash value calculated by the device participating in the authentication is inconsistent with the hash value sent by the device to be authenticated, it is considered that the last two timestamps may be separated by 0s and 5s. Therefore, we try to subtract 5s from the time used the first time, perform the hash operation again and compare. If they match, the authentication is successful; otherwise, the connection is rejected.

[0065] Step 5: The Broker makes a final decision based on the response information obtained in Step 4.

[0066] When the Broker receives the decision result from the participating authentication device, it first decrypts the message with its own private key, calculates the hash value of the hidden value, and compares it with the username field stored in step 3 to ensure the legitimacy of the decision-maker. Then, it responds to the connection request according to the obtained decision result.

[0067] Step 6: Encrypt and decrypt messages on the device side.

[0068] When a device needs to publish a message to a topic, it first calculates a real-time key using a pre-designed dynamic key generation algorithm, as shown in Algorithm 1. The algorithm's input consists of a hidden value and a timestamp processed by mantissa. The algorithm performs cut, flip, expansion, and XOR operations on the input elements to obtain the real-time key, which is 128 bits long. Next, the message is encrypted using the AES algorithm, suitable for restricted devices. This algorithm is fast and consumes very little memory. After encryption, the publishing end fills the ciphertext into the payload of the PUBLISH protocol frame and sends it to the Broker. The Broker forwards the ciphertext unchanged to devices subscribed to the current topic. The receiving device also uses the dynamic key generation algorithm and the AES algorithm to decrypt the ciphertext, finally obtaining the message.

[0069]

[0070] This invention also provides a distributed authentication and shared dynamic key system based on the MQTT protocol, comprising:

[0071] Policy Edge Module: This module is used to eliminate the traditional central authorization entity. It implements the function of storing policy information, i.e., the hidden value used for authentication, on all edge devices through initialization in step 1; and implements the function of transferring the decision-making function, i.e. the authentication function, from the traditional central authorization entity to the edge devices in steps 3, 4, and 5. The policy information and decision-making function are distributed to multiple authorization points, and each time only one edge device is randomly selected for decision-making, thereby achieving system load balancing and anti-attack capabilities, and providing a secure and stable authentication mechanism.

[0072] Device Grouping Module: This module is used to implement the mechanism in step 1 of grouping devices by household by introducing the household name into the client ID. Based on this, devices in the same group can make decisions with each other and share session keys. It also implements the function in step 3 where the Broker forwards the decision-making function to devices in the same group by publishing a request for authentication information on the household name topic. At the same time, since devices in the same group have the same hidden value and key generation algorithm, they can generate the same session key. This module is used to implement the function in step 6 for multiple devices in the same household to share session keys.

[0073] Dynamic Key Module: This module is used to implement the function in step 6 of obtaining a real-time key by using two input elements, a hidden value and a timestamp, and performing cut, flip, expand, and XOR operations. The key length is 128 bits. Since the input elements of the algorithm are dynamic, the keys generated at different times are different. This module is used to generate session keys that change over time in real time on the device side, which fundamentally prevents brute-force attacks by adversaries and greatly improves the security of information transmission.

[0074] The present invention also provides a device for implementing distributed authentication and shared dynamic keys based on the MQTT protocol, comprising:

[0075] Memory: Used to store computer programs;

[0076] A processor is configured to implement the distributed authentication and shared dynamic key method based on the MQTT protocol when executing the computer program.

[0077] The present invention also provides a computer-readable storage medium, comprising:

[0078] The computer-readable storage medium stores a computer program that, when executed by a processor, enables a distributed authentication and shared dynamic key method based on the MQTT protocol.

[0079] The design concept of this invention:

[0080] like Figure 2 As shown, an MQTT network contains numerous users, each owning a set of devices. Many users are connected and belong to the same household, which is a typical smart home environment. We group all devices belonging to the same household into one group, and only devices within the same group can exchange information indirectly; devices in different groups are isolated from each other. The resulting MQTT network structure is shown in the appendix. Figure 2 After dividing the MQTT network, compared to the original situation where clients were scattered and each ruled independently, the clients now form a cluster, and the architecture is clearer. Based on the above grouping model, we further designed the authentication and encryption processes.

[0081] like Figure 3 As shown, regarding authentication, once a device wants to connect to the Broker, the Broker first blocks the connection request, then forwards the request to other devices in the same group. These other devices analyze the connection information and make a decision. The process is detailed in the appendix. Figure 3 This model leverages the interconnectedness of devices within the same group: they belong to the same family, share consistent connection information, and work together to maintain the security of the entire device group, preventing intrusion from external devices. This model closely resembles real-world scenarios, similar to family members helping and monitoring each other, greatly ensuring home security.

[0082] like Figure 4 As shown, in terms of encryption, all devices within the same group share a constantly changing key using a designed algorithm, and the broker does not need to hold the corresponding key. Devices also do not need to continuously store session keys; they only calculate the real-time key when data needs to be decrypted, reducing storage overhead. Because the key generation algorithm has very low complexity, the cost to devices in calculating keys can also be kept low. This constantly changing key means that even if an adversary cracks a key, it is useless for subsequent ciphertext, requiring further key cracking, which incurs huge overhead and is not worthwhile. The framework of this encryption scheme is attached. Figure 4 .

Claims

1. A distributed authentication and shared dynamic key method based on the MQTT protocol, characterized in that: Includes the following steps: Step 1: Device information initialization; The specific method of step 1 is as follows: the user concatenates the family name and the device name and fills them into the client ID, and injects hidden value information into the device to prove the identity of their family as authentication credentials for subsequent connections; Step 2: Fill the CONNECT protocol frame with the authentication credentials obtained in Step 1 and connect to the Broker; Step 3: After receiving the connection request, the Broker requests a decision from the devices in the same group; The specific method of step 3 is as follows: When the Broker receives the CONNECT protocol frame, if it is an administrator device, it will directly connect and store the username field. If it is a regular device, it will block the connection request and analyze the family name from the client ID. The Broker will randomly select a connected device from the family and forward the authentication request. Specifically, it will publish a request for authentication information on the topic named family name. This information includes the password field of the device to be authenticated. Step 4: Devices in the same group participate in the authentication decision and send the results to the Broker; The specific method of step 4 is as follows: the selected device immediately calculates the HASH value of the hidden value & timestamp, and compares the calculation result with the received password field. If the result is consistent, it sends an agreement message to the Broker, that is, the encrypted ciphertext of the hidden value &agree; otherwise, it rejects the connection and sends the encrypted ciphertext of the hidden value &deny. Before calculating the hash value, step 4 processes the timestamp as follows: That is, it counts in seconds and converts the last digit of the time in five-second intervals. When the hash value calculated by the participating authentication device is inconsistent with the hash value sent by the device to be authenticated, the time used for the first time is reduced by 5 seconds, the hash operation is performed again and compared. If they match, the authentication is passed; otherwise, the connection is rejected. Step 5: The Broker makes a final decision based on the response information obtained in Step 4. The specific method of step 5 is as follows: When the Broker receives the decision result from the participating authentication device, it first decrypts the message with its own private key, calculates the hash value of the hidden value, and compares it with the username field stored in step 3 to ensure the legitimacy of the decision-maker, and then responds to the connection request according to the obtained decision result. Step 6: Encrypt and decrypt messages on the device side; The specific method of step 6 is as follows: When a device needs to publish a message to a certain topic, it first calculates the real-time key using the pre-designed dynamic key generation algorithm, and then encrypts the message using the AES algorithm suitable for restricted devices. After encryption, the publishing end fills the ciphertext into the payload of the PUBLISH protocol frame and sends it to the Broker. The Broker forwards the ciphertext unchanged to the device that has subscribed to the current topic. The receiving device also uses the dynamic key generation algorithm and the AES algorithm to decrypt the ciphertext and finally obtain the message. The key generation algorithm in step 6 is as follows: the input of the algorithm is the hidden value and the timestamp after mantissa processing. The algorithm performs cut, flip, expand and XOR operations on the input elements to obtain the real-time key, and the key length is 128 bits.

2. The distributed authentication and shared dynamic key method based on the MQTT protocol according to claim 1, characterized in that: The specific method of step 2 is as follows: Divide the devices in the home into administrator devices and ordinary devices. The administrator device is the first device to connect to the home, and the ordinary devices are the devices that connect later. The administrator device needs to fill in the username field, which is set to the hash value of the hidden user value. The ordinary device needs to fill in the password field, which is set to the dynamic hash value, that is, the hash value of the hidden value and the timestamp. After the initial operation is completed, the device sends a CONNECT protocol frame to the Broker. The CONNECT protocol frame includes the client ID, username and password. The client ID of the administrator device is the home name concatenated with "admin", and the client ID of the ordinary device is the home name concatenated with the device name.

3. The distributed authentication and shared dynamic key method based on the MQTT protocol according to claim 2, characterized in that: In step 2: a hash algorithm module is added inside each device, and the hash algorithm module uses SHA-256, a secure hash algorithm.

4. A distributed authentication and shared dynamic key system based on the MQTT protocol, based on the method of claim 1, characterized in that: include: Policy edgeification module: By initializing, policy information, i.e. hidden values ​​used for authentication, is stored on all edge devices, and the decision-making function, i.e. authentication function, is transferred from the central authorization entity to the edge devices. This is used to cancel the central authorization entity. Policy information and decision-making function are distributed to multiple authorization points, and each time only one edge device is randomly selected for decision-making, thereby achieving system load balancing and anti-attack capabilities, and providing a secure and stable authentication mechanism. Device grouping module: By introducing the family name into the client ID, the mechanism of grouping devices by family is realized. On this basis, devices in the same group can make decisions with each other and share session keys. The Broker forwards the decision-making function to devices in the same group by publishing the authentication request information to the family name topic. This module is used for multiple devices in the same family to share session keys. Dynamic Key Module: This module uses two input elements, a hidden value and a timestamp, and performs cut, flip, expand, and XOR operations to obtain a real-time key. The key length is 128 bits, and the key generated at different times is different. This module is used to generate session keys that change over time in real time on the device.

5. A device for implementing distributed authentication and shared dynamic keys based on the MQTT protocol, characterized in that: include: Memory: Used to store computer programs; A processor, configured to implement, when executing the computer program, a distributed authentication and shared dynamic key method based on the MQTT protocol as described in any one of claims 1-3.

6. A computer-readable storage medium, characterized in that: include: The computer-readable storage medium stores a computer program that, when executed by a processor, can implement the distributed authentication and shared dynamic key method based on the MQTT protocol as described in any one of claims 1-3.

Images