MQTT message security protection method and device based on multilayer protection mechanism, and medium

Abstract

The invention discloses an MQTT message security protection method and device based on a multilayer protection mechanism, and a medium, and relates to the technical field of communication. The method comprises the following steps: establishing MQTT connection between client equipment and a message proxy server, and receiving an MQTT message sent by the message proxy server through the client equipment; the client device reads a pre-configured device key from a secure storage area of the client device and obtains a current time factor so as to generate a local verification code through cryptographic hash operation; and performing consistency comparison verification on the local verification code and a dynamic authentication password extracted from the MQTT message, if verification is consistent, executing a control instruction in the MQTT message through the client device, and if verification is inconsistent, discarding the MQTT message and triggering an exception handling process.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of communication, and in particular to an MQTT message security protection method and device based on a multi-layer protection mechanism and a medium. BACKGROUND

[0002] As a lightweight publish / subscribe message transmission protocol, the MQTT protocol has been widely used in the Internet of Things field due to its low bandwidth consumption and low power consumption characteristics, especially in the communication between resource-constrained terminal devices and cloud services. However, the security mechanism was relatively weak when the protocol was designed, and it does not provide end-to-end security, which makes the MQTT-based communication system face many security threats such as fake instructions, message replay, and data theft.

[0003] At present, the mainstream approach to improving the security of MQTT communication is to rely on the Transport Layer Security protocol (TLS / SSL) to establish an encrypted channel, or to use a two-way authentication mechanism based on digital certificates. Although this kind of scheme can guarantee the confidentiality and integrity of the communication link to a certain extent, its protection boundary stops at the connection level. Once the message broker server itself is compromised, or the encrypted channel is simplified or omitted due to complex configuration and large performance overhead in actual deployment, attackers can easily fake or tamper with the message instructions forwarded through the broker server, posing a direct threat to the client device. The existing technology lacks effective identity verification means at the message payload level, making it difficult for the client device to identify the true source of the instructions.

[0004] The trust root of the existing security mechanism is often concentrated on the server side, and the client device is in a passive verification position. When the server-side trust system is compromised, the client device cannot effectively defend itself. This architectural defect makes it difficult for existing solutions to deal with internal attacks from compromised servers, and also makes it difficult to provide independent message authenticity verification capabilities for devices in scenarios where underlying encryption such as TLS is not enabled. When facing suspicious instructions, the client usually has to choose to trust or completely disconnect, lacking a fine-grained secondary security verification mechanism based on the content of the instructions themselves. SUMMARY

[0005] The embodiments of the present application provide an MQTT message security protection method and device based on a multi-layer protection mechanism to solve the above technical problems.

[0006] In one aspect, the embodiments of the present application provide an MQTT message security protection method based on a multi-layer protection mechanism, comprising: establishing an MQTT connection between a client device and a message broker server, and receiving an MQTT message sent by the message broker server through the client device; wherein the MQTT message comprises a dynamic authentication password generated by a message sender; reading a pre-configured device key from a secure storage area of the client device, and obtaining a current time factor to generate a local verification code through a cryptographic hash operation; comparing the local verification code with the dynamic authentication password extracted from the MQTT message for consistency verification, and if the verification is consistent, executing a control instruction in the MQTT message through the client device, and if the verification is inconsistent, discarding the MQTT message and triggering an exception handling process.

[0007] In an implementation manner of the present application, before receiving the MQTT message sent by the message broker server through the client device, the method further comprises: generating a unique device key corresponding to each client device through a key server; writing the device key into a non-volatile memory of the client device through a secure programming operation in a production test phase of the client device to form a secure storage area; setting the access permission of the secure storage area to a read-only mode to prevent the device key from being tampered with or overwritten, and performing a reading verification operation after writing is completed to confirm that the device key has been correctly stored and the access restriction has been effectively applied.

[0008] In an implementation manner of the present application, the current time factor is obtained to generate the local verification code through a cryptographic hash operation, specifically comprising: adopting a standard time system based on coordinated universal time to divide continuous time into equal-length time window units, and determining a corresponding time window as the current time factor according to the message receiving time; performing a hash operation on the device key and the current time factor through a hash-based message authentication code algorithm to generate a fixed-length cryptographic hash value; starting from a specified starting position in the cryptographic hash value according to a predefined rule, a byte sequence of a corresponding length is intercepted, and the byte sequence is converted into a readable combination format to generate the local verification code.

[0009] In an implementation manner of the present application, the hash operation is performed on the device key and the current time factor through a hash-based message authentication code algorithm to generate a fixed-length cryptographic hash value, specifically comprising: adopting an HMAC-SHA1 algorithm to perform an exclusive or operation on the device key and a predefined fixed padding constant to generate extended key data; The extended key data and the current time factor are combined according to a preset splicing rule, and two rounds of hash calculation are sequentially performed to obtain a final cryptographic hash value.

[0010] In an implementation of the present application, if the verification is consistent, the control instruction in the MQTT message is executed by the client device, specifically including: In the case where the comparison result data indicates that the local verification code is consistent with the dynamic authentication password, the client device parses the control instruction from the payload of the MQTT message and performs a legality check on the control instruction; the legality check includes format check and semantic check; After the legality check passes, the client device delivers the control instruction to an internal corresponding instruction processing module, and the instruction processing module executes the operation logic defined by the control instruction; After successfully executing the control instruction, the client device generates a state log of successful instruction execution, stores the state log in the non-volatile memory of the client device, and publishes a confirmation message to the message broker server.

[0011] In an implementation of the present application, if the verification is inconsistent, the MQTT message is discarded and an exception handling process is triggered, specifically including: In the case where the comparison result data indicates that the local verification code is inconsistent with the dynamic authentication password, the client device updates the exception counter data in the local memory and starts the internal timer data; Before the internal timer data reaches a preset timeout threshold, the client device continuously monitors the MQTT message and repeatedly performs the consistency comparison operation; If the exception counter data accumulates to a preset security threshold within the preset timeout threshold, or until the internal timer data times out without receiving an MQTT message carrying a valid dynamic authentication password, the client device initiates a network connection disconnection instruction to terminate the communication session with the message broker server.

[0012] In an implementation of the present application, the MQTT message sent by the message broker server is received by the client device, specifically including: After the message sender generates the dynamic authentication password, the dynamic authentication password and the control instruction are spliced according to a predefined field order and separator to form structured message payload data; encapsulate the structured message payload data in a payload part of an MQTT protocol publish message, and set target topic information in a header of the publish message to instruct the message broker server to route the MQTT message to a target client device; The target client device receives the MQTT message on a subscribed target topic, and parses the structured message payload data according to the predefined field order and separator to extract the dynamic authentication password and the control instruction.

[0013] In an implementation form of the present application, before the client device receives the MQTT message sent by the message broker server, the method further comprises: When a message sender needs to send an MQTT message to a target device, a secure API request is generated, and the secure API request is sent to a key management server; the secure API request includes a unique identifier corresponding to the target client device; After the key server verifies the identity of the message sender, the device key corresponding to the target client device is retrieved from the encrypted key store, and the device key is returned to the message sender after being encrypted; The message sender obtains the device key corresponding to the target client device by decryption, and obtains a current time factor; wherein the time factor dynamically changes based on a time source; Based on the device key and the time factor, and by performing an operation through a predefined cryptographic algorithm, a dynamically changing authentication password is generated.

[0014] On the other hand, the embodiments of the present application also provide an MQTT message security protection device based on a multi-layer protection mechanism, which comprises: at least one processor; and a memory in communication connection with the at least one processor; The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the MQTT message security protection method based on the multi-layer protection mechanism as described above.

[0015] On the other hand, the embodiments of the present application also provide a non-volatile computer storage medium, which stores computer executable instructions, and the computer executable instructions are executed to implement the MQTT message security protection method based on the multi-layer protection mechanism as described above.

[0016] The embodiments of the present application provide an MQTT message security protection method, device and medium based on a multi-layer protection mechanism, which at least have the following beneficial effects: By increasing the message content security check, even if the transmission encryption is cracked or the message broker server is attacked, the attacker's fake instructions cannot pass the password verification of the client, thereby effectively resisting the fake instruction attack, extending the security protection from the connection level to the instruction level, and greatly improving the overall security of the system; By comparing the locally generated verification code with the password in the message, suspicious messages can be actively identified and discarded, and an abnormal processing procedure including disconnection is triggered, reducing the risk of the client device being controlled by malicious instructions, especially in the case of untrusted server or unreliable network environment, the security of the device itself is guaranteed; The dynamic password is generated by using the cryptographic hash operation based on the device key and the time factor, the algorithm overhead is small, the calculation efficiency is high, and it is suitable for resource-limited Internet of Things terminal devices; The dynamic password is transmitted with the message, and there is no need to establish an additional secure channel for verification information exchange, avoiding complex interaction process; Since the generation and dynamic change of the verification code are closely bound to the time factor, each dynamic password is only valid within a specific time window, and even if the attacker intercepts the valid message and password, he cannot resend the message to deceive the client after the time window expires, which can effectively resist the message replay attack, and ensures the timeliness and uniqueness of the instruction. BRIEF DESCRIPTION OF DRAWINGS

[0017] The accompanying drawings used to provide further understanding of the present application, constitute a part of the present application, the illustrative embodiments of the present application and the description thereof are used to explain the present application, and do not constitute improper limitation to the present application. In the drawings: Figure 1 The flowchart of the MQTT message security protection method based on the multi-layer protection mechanism provided by the embodiment of the present application; Figure 2 The internal structure diagram of the MQTT message security protection device based on the multi-layer protection mechanism provided by the embodiment of the present application. DETAILED DESCRIPTION

[0018] In order to make the purpose, technical scheme and advantages of the present application clearer, the technical scheme of the present application will be described in detail below in combination with the specific embodiments of the present application and the corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor belong to the scope of protection of the present application.

[0019] The technical scheme provided by the embodiments of the present application will be described in detail below in combination with the drawings.

[0020] Figure 1 The flowchart of the MQTT message security protection method based on the multi-layer protection mechanism provided by the embodiment of the present application;

[0021] The implementation of the analysis method related to the embodiments of the present application can be a terminal device or a server, and the present application does not make special limitations thereon. For the convenience of understanding and description, the following embodiments are described in detail taking the server as an example.

[0022] It should be noted that the server can be a single device, or a system composed of multiple devices, i.e., a distributed server, and the present application does not make specific limitations thereon.

[0023] As shown in FIG. 1, the MQTT message security protection method based on the multi-layer protection mechanism provided by the embodiments of the present application comprises the following steps. Figure 1 Step 101, establishing an MQTT connection between a client device and a message broker server, and receiving an MQTT message sent by the message broker server through the client device.

[0024] It should be noted that the MQTT message in the embodiments of the present application includes a dynamic authentication password generated by a message sender.

[0025] In the present embodiment, when an authorized message sender (for example, a business application server in the cloud) needs to send a control instruction to a specific target client device, a one-time valid dynamic authentication password corresponding thereto needs to be generated first. Specifically, the sender will first generate a secure API request. Exemplarily, the request is a structured data packet, which must include the unique identifier of the target client device, such as the device serial number or MAC address, for explicitly asking the key management server for the key of which device. At the same time, the API request itself is usually signed with the sender's credentials (such as API Key / Secret) or transmitted through a TLS channel to ensure the legality and confidentiality of the request. The sender sends the request to the key management server.

[0026] After receiving the request, the key management server will first verify the identity and authority of the message sender, and confirm whether it has the right to obtain the key of the target device. After verification, the server will search in its encrypted key storage database to find the device key corresponding to the unique identifier. It should be noted that the stored key itself is also encrypted for security. Subsequently, the key management server will encrypt the device key using a pre-negotiated encryption method (for example, using the public key of the sender to encrypt), and return it to the message sender through the API response. After receiving the encrypted key, the message sender uses its own private key to decrypt, thereby safely obtaining the plaintext device key corresponding to the target device.

[0027] ​At the same time of obtaining the device key, the message sender needs to obtain the current time factor. It can be understood that the time factor must be synchronized with the time factor used for verification on the client device side, usually based on a standard time source such as coordinated universal time. Exemplarily, the time factor can be the number or identification of the window to which the current time belongs after dividing the time axis into equal length windows.

[0028] Finally, the message sender performs operation based on the decrypted device key and the obtained current time factor through a predefined cryptographic algorithm (such as HMAC-SHA1). Specifically, the time factor is input as a message and the device key is input as a key into the algorithm to generate a fixed length hash value, which is then converted into a dynamic changing authentication password according to the agreed rules (such as intercepting part of the characters). This password is carried by the subsequent MQTT message and sent to the target device. This set of procedures ensures that each password is dynamically changing, bound to a specific device and time window, thereby achieving strong anti-replay and anti-forgery capabilities.

[0029] In the present embodiment, the MQTT connection between the client device and the message broker server is established, which essentially establishes a communication session based on the encryption of the transport layer security protocol and the two-way identity authentication. The client device initiates a TLS handshake request to the preset message broker server address. It should be noted that in this handshake request, the client device does not go empty-handed, but must carry its own digital certificate data. Exemplarily, the certificate is issued by a trusted certificate authority, which contains the public key, identity information, etc. of the client, like the digital identity card of the client. After receiving the handshake request, the primary task of the message broker server is to verify the authenticity and validity of the digital certificate data, including checking whether the issuer of the certificate is trusted, whether the certificate is within the valid period, whether it has been revoked, etc. Only after verification, the server considers that it is communicating with a legal device, and continues to the next step.

[0030] After the client identity is verified, the message broker server returns its own digital certificate data and the public parameter data for key exchange to the client. It can be understood that this is a mutual authentication process, and the client device also needs to verify the validity of the server certificate to ensure that it is connecting to the real and trusted server, rather than a phishing server. Illustratively, the client device checks whether the domain name in the server certificate is consistent with the expected information, etc. After the mutual authentication is successful, the key negotiation phase is entered. The client and the server will perform a series of collaborative calculations based on the exchanged public parameter data, for example, the elliptic curve parameters used in the ECDHE key exchange. It should be noted that although the public parameters are exchanged, through mathematical principles such as the discrete logarithm problem, both parties can independently calculate the same unique and temporary session symmetric key data. This key will be used to encrypt all application layer data, i.e., MQTT messages, during this session. After that, the two parties have really established a secure MQTT connection. This mechanism ensures the confidentiality (content is encrypted), integrity (data is not tampered with) and authenticity of the endpoint of the communication, and builds the first solid defense line for message transmission.

[0031] In this embodiment, after the message sender (such as an application server) generates a dynamic authentication password, the dynamic authentication password needs to be sent together with the actual control instruction. The sender first splices the dynamic authentication password and the control instruction according to a pre-defined field order and separator. Illustratively, a simple agreement can be command={instruction content}&token={dynamic password}, in which & is used as a separator. This splicing operation produces structured message payload data, which makes the instruction and password an ordered and analyzable whole.

[0032] Subsequently, the sender needs to encapsulate this structured payload data into a format that can be recognized and transmitted by the MQTT protocol. Specifically, it is filled into the payload part of the MQTT publish message. After receiving the publish message, the core work of the message broker server is to route the message to all client devices that have subscribed to the target topic according to the topic information. This is a publish / subscribe mode, which realizes the directional distribution of messages.

[0033] Finally, the target client device as a subscriber will receive this MQTT message on the target topic it subscribes to. It can be understood that the client device, after receiving the message, can accurately restore the instruction and password from the message. Therefore, it must parse the received structured message payload data according to the same predefined field order and separator as agreed with the sender. Exemplarily, the client program will split the entire payload string into multiple fields according to the separator (such as &), and then extract the control instruction and dynamic authentication password according to the field name (such as command= and token=) or fixed order. This can ensure that the instruction and password can be accurately and correctly transmitted and identified, providing accurate data input for subsequent local verification by the client.

[0034] Step 102, the client device reads the pre-configured device key from the secure storage area of itself and obtains the current time factor to generate the local verification code through the cryptographic hash operation.

[0035] In this embodiment, the prerequisite for reading the pre-configured device key from the secure storage area of itself is that the key has been securely pre-configured. The key server is a special service in a secure controlled environment, and its core responsibility is to generate a globally unique device key for each client device to be shipped. It should be noted that the randomness and uniqueness of the device key is crucial, which is the basis for ensuring that the identity of each device cannot be confused and the password cannot be cracked in bulk. Exemplarily, the device key is generated by the key server using a random number generator that meets the cryptographic security standard to generate a key data of sufficient length, and a unique key is independently generated for each device during the production stage of the device.

[0036] Subsequently, during the production test stage of the client device, a secure burning operation is performed. Specifically, this is usually done by writing the corresponding device key into the non-volatile memory on the mainboard of the client device, such as the Emmc RPMP partition, through a secure local communication interface on the production line. The burning channel itself is encrypted, and the operation is strictly controlled under production control to prevent the key from being stolen or replaced during injection, and the specific storage area written constitutes the subsequent secure storage area.

[0037] After the write is completed, the access rights to the storage area are immediately set to read-only mode by hardware fusing, software write-protect bits, or secure unit configuration. It is understood that the purpose is to permanently prevent the device from being tampered with or overwritten by malicious software or attackers in subsequent operation, thereby fundamentally ensuring the static security of the key. Finally, a read verification operation is performed, i.e., the device firmware or test system reads the key just written again and compares it with the original value sent by the key server to confirm that the key has been correctly stored and the write protection mechanism has taken effect, ensuring the availability and integrity of the key throughout the life cycle of the device. When verification is required, the client's secure firmware reads the device key from the area through a controlled interface.

[0038] At the same time, the client device needs to obtain the current time factor. It is understood that this time factor must be synchronized with the time factor used by the message sender to generate the dynamic authentication password. In terms of specific implementation, a standard time system based on coordinated universal time is used to divide continuous time into equal-length time window units. The client device determines the specific time window to which it belongs according to the time of receiving the message, and uses the window identifier as the current time factor. Exemplarily, the built-in clock of the client device is usually synchronized with the network time protocol server to ensure the accuracy of the time reference.

[0039] After obtaining the device key and the current time factor, the client device uses a hash-based message authentication code algorithm, uses the device key as the algorithm key, and uses the current time factor as the input message of the algorithm to calculate a fixed-length cryptographic hash value. Subsequently, according to the rules agreed upon by the message sender in advance, such as extracting a byte sequence of a specific length from a specified starting position of the hash value and converting it to a numeric or alphanumeric combination format, the local verification code is finally obtained. It is understood that, due to the use of the same key, the same time factor, and the same algorithm rules, the client locally generated verification code should be completely consistent with the dynamic authentication password generated by the legitimate message sender within the time window validity period.

[0040] Specifically, the hash-based message authentication code algorithm selected by the embodiments of the present application is the HMAC-SHA1 algorithm. The HMAC-SHA1 algorithm first requires a key that matches the block size of the underlying hash function (SHA-1) packet length. If the length of the provided device key is less than the specified length, it is padded to the specified length. If the length of the provided device key is greater than the specified length, it is first hashed to shorten it. Subsequently, the algorithm uses predefined fixed padding constants, specifically including two different padding constants, a first padding constant and a second padding constant.

[0041] It can be understood that this step involves two XOR operations. First, the processed key is XORed with the first padding constant to generate an internally padded key; then, the processed key is XORed with the second padding constant to generate an externally padded key, thereby generating the expanded key data, which can spread the key information throughout the data block and enhance the mixing effect with the message data.

[0042] Then, two rounds of hash calculation are performed. Specifically, the algorithm first combines the internally padded key obtained in the first stage with the current time factor according to a preset splicing rule. Exemplarily, the combination is usually a direct splicing, i.e., the data bytes of the current time factor are appended to the internally padded key to form a data block to be calculated. Then, the first round of SHA-1 hash calculation is performed on the combined data block to obtain an intermediate hash value. Next, the algorithm splices the externally padded key obtained in the first stage with the intermediate hash value just obtained, and performs the second round of SHA-1 hash calculation on the new combined data block. Finally, the result output by the second round of calculation is the fixed-length cryptographic hash value. It can be understood that the nested structure of the two rounds of hash calculation makes it extremely difficult to extend the collision of the SHA-1 function to an attack on the HMAC structure even if the attacker can find a collision, thereby greatly enhancing the cryptographic strength of the overall scheme. The final hash value, as the raw material for generating a readable dynamic verification code, can ensure that each password is a unique and strongly bound cryptographic product of the device key and a specific time window.

[0043] Step 103, compare the local verification code with the dynamic authentication password extracted from the MQTT message for consistency verification. If the verification is consistent, execute the control instruction in the MQTT message through the client device; if the verification is inconsistent, discard the MQTT message and trigger an exception handling process.

[0044] In the present embodiment, when the client device verifies the local generated verification code matches the dynamic authentication password carried in the message through consistent comparison, it only means that the source of the message is authenticated and trusted, but this is not the end of the security process. It can be understood that, in order to further improve the robustness of the system and prevent legitimate sources but abnormal content messages from causing device failure, further checking of the instruction itself is also required. Specifically, the client device extracts the pure control instruction part from the parsed MQTT message payload. Then, the instruction is immediately checked for legality. It should be noted that this check usually includes two levels of format checking and semantic checking. For example, format checking is to check whether the syntax structure of the instruction conforms to the predefined specification, such as whether the instruction keyword is correct, the parameter separator is correct, and the data length is within the allowed range. Semantic checking is more in-depth, checking whether the parameter content of the instruction is reasonable and allowed in business logic, such as checking whether the brightness setting value of a dimmer is within the reasonable range of 0-100, rather than an illegal value outside the range. This set of checking mechanism is like an additional security filter, which intercepts abnormal instructions that may be caused by program errors or other accidents.

[0045] After the legality check is passed, the client device actually starts to execute the instruction. Specifically, it will pass this control instruction, which has been verified as a trusted source and a legal content, to the corresponding instruction processing module in the device firmware through an internal message bus or function call. It can be understood that this module is a hardware abstraction layer or a driver layer responsible for specific function execution in the device firmware. For example, if the instruction is to turn on the fan, the instruction will be passed to the special module that controls the motor drive, and if the instruction is to report the status, it may be passed to the data acquisition module, and the specific operation logic defined by the instruction is finally executed by the special module. After the operation is successfully executed, the client device may publish an acknowledgment message to the message broker server to notify the instruction sender that the instruction has been successfully executed, forming a complete closed loop from instruction issuance to execution confirmation.

[0046] In the present embodiment, when the consistent comparison verification fails, it indicates that the current received MQTT message is most likely a counterfeit, tampered or expired replay message. At this time, the core goal of the system immediately changes from executing instructions to security protection. It can be understood that simply discarding a single invalid message is not enough, and a mechanism is needed to deal with possible continuous attacks. Specifically, the client device first updates the abnormal counter data in the local memory, i.e. counts the abnormal events. At the same time, it starts an internal timer data, which sets a preset timeout threshold to define an observation window.

[0047] Instead of simply blocking or waiting, the client device continuously monitors the MQTT messages and repeats the consistency check operation before the timer expires. It is noted that this design is to distinguish accidental transmission errors from malicious persistent attacks. Exemplarily, if a single password verification error is caused by network transient disturbance, the subsequent correct message can still be processed normally.

[0048] However, if it is indeed an attack, the attacker can send a large number of invalid messages in a short time. Therefore, the system sets two conditions to trigger the complete defense action: first, the abnormal counter data accumulates to a preset security threshold within a preset timeout threshold, corresponding to a high-intensity dense attack; second, until the internal timer data expires, no MQTT message carrying a valid dynamic authentication password is received, corresponding to a persistent low-intensity attack or communication interruption. Once either condition is met, the client device determines that the current connection is not trustworthy or is under attack, and thus initiates a network connection disconnection instruction. It can be understood that this is an ultimate active defense strategy, which terminates the communication session with the message broker server, so that the device enters an offline protection state, thereby completely cutting off the attack path and maximizing the safety of the device itself.

[0049] The above is the method embodiment of the present application. Based on the same inventive concept, the present application also provides an MQTT message security protection device based on a multi-layer protection mechanism, which has a structure as shown in Figure 2 .

[0050] Figure 2 The internal structure of the MQTT message security protection device based on a multi-layer protection mechanism provided by the present application is shown in Figure 2 . The device includes: at least one processor; and a memory in communication connection with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to: establish an MQTT connection between the client device and the message broker server, and receive the MQTT message sent by the message broker server through the client device; wherein the MQTT message includes a dynamic authentication password generated by the message sender; The local verification code is compared with the dynamic authentication password extracted from the MQTT message for consistency verification, if the verification is consistent, the control instruction in the MQTT message is executed through the client device, if the verification is inconsistent, the MQTT message is discarded and an exception handling process is triggered.

[0051] The embodiment of the application further provides a nonvolatile computer storage medium, which stores computer executable instructions, and the computer executable instructions can realize the following when executed: An MQTT connection between the client device and the message broker server is established, and an MQTT message sent by the message broker server is received through the client device; wherein the MQTT message comprises a dynamic authentication password generated by a message sender; The client device reads a pre-configured device key from a secure storage area of the client device, and acquires a current time factor, to generate a local verification code through a cryptographic hash operation; The local verification code is compared with the dynamic authentication password extracted from the MQTT message for consistency verification, if the verification is consistent, the control instruction in the MQTT message is executed through the client device, if the verification is inconsistent, the MQTT message is discarded and an exception handling process is triggered.

[0052] Each of the embodiments in the application is described in a progressive manner, and the same or similar parts of each of the embodiments can be referred to each other, and each of the embodiments mainly describes the difference from other embodiments. Especially, for the device and medium embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the related parts can be referred to the part of the description of the method embodiments.

[0053] The device and medium provided by the embodiment of the application are one-to-one corresponding to the method, therefore, the device and medium also have the similar beneficial technical effects as the method, since the beneficial technical effects of the method have been described in detail above, therefore, the beneficial technical effects of the device and medium will not be described here.

[0054] Those skilled in the art should understand that the embodiments of the application can be provided as a method, a system, or a computer program product. Therefore, the application can adopt a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the application can adopt a computer program product in the form of one or more computer usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer usable program codes.

[0055] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more flowcharts and / or blocks in the flowcharts and / or combination thereof. Figure 1 one or more flowcharts and / or blocks in the flowcharts and / or combination thereof.

[0056] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more flowcharts and / or blocks in the flowcharts and / or combination thereof. Figure 1 one or more flowcharts and / or blocks in the flowcharts and / or combination thereof.

[0057] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more flowcharts and / or blocks in the flowcharts and / or combination thereof. Figure 1 one or more flowcharts and / or blocks in the flowcharts and / or combination thereof.

[0058] In one typical configuration, the computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0059] The memory can include non-persistent memory and / or volatile memory, such as random access memory (RAM) and / or cache memory, non-volatile memory, such as read-only memory (ROM), EPROM, and / or flash memory. The memory is an example of computer-readable media.

[0060] Computer-readable media includes permanent and non-permanent, movable and non-movable media that can implement information storage by any method or technology. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette, magnetic tape disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to a computing device. According to the definition herein, computer-readable media does not include transitory media such as modulated data signals and carriers.

[0061] It should also be noted that the terms "comprising", "containing", or any other variant thereof are intended to cover non-exclusive inclusions, so that a process, method, article or apparatus that includes a list of elements does not only include those elements, but also includes other elements not explicitly listed, or further includes elements inherent in such a process, method, article or apparatus. Without more limitations, the element defined by the statement "comprising a" does not exclude the presence of additional identical elements in the process, method, article or apparatus that includes the element.

[0062] The above only is an embodiment of the present application, and is not used to limit the present application. For those skilled in the art, the present application can have various changes and variations. Any modification, equivalent replacement, improvement, etc. within the spirit and principle of the present application shall be included in the scope of claims of the present application.

Claims

1. A method for MQTT message security protection based on a multi-layered protection mechanism, characterized in that, The method includes: Establish an MQTT connection between the client device and the message broker server, and receive MQTT messages sent by the message broker server through the client device; wherein, the MQTT message includes a dynamic authentication password generated by the message sender; The client device reads the pre-configured device key from its own secure storage area and obtains the current time factor in order to generate a local verification code through cryptographic hashing. The local verification code is compared with the dynamic authentication password extracted from the MQTT message for consistency verification. If the verification matches, the control command in the MQTT message is executed through the client device. If the verification does not match, the MQTT message is discarded and an exception handling process is triggered.

2. The MQTT message security protection method based on a multi-layer protection mechanism according to claim 1, characterized in that, Before receiving the MQTT message sent by the message broker server through the client device, the method further includes: A unique device key is generated for each client device through a key server; During the production testing phase of the client device, the device key is written into the non-volatile memory of the client device through a secure burning operation to form a secure storage area; The access permission of the secure storage area is set to read-only mode to prevent the device key from being tampered with or overwritten. After the write operation is completed, a read verification operation is performed to confirm that the device key has been stored correctly and that the access restriction has been effectively applied.

3. The MQTT message security protection method based on a multi-layer protection mechanism according to claim 1, characterized in that, Obtain the current time factor to generate a local verification code through cryptographic hashing, specifically including: A standard time system based on Coordinated Universal Time is adopted, and continuous time is divided into time window units of equal length. The corresponding time window is determined as the current time factor based on the message reception time. A fixed-length cryptographic hash value is generated by performing a hash operation on the device key and the current time factor using a hash-based message authentication code algorithm. According to predefined rules, a byte sequence of corresponding length is extracted from a specified starting position in the cryptographic hash value, and the byte sequence is converted into a readable combined format to generate a local verification code.

4. The MQTT message security protection method based on a multi-layer protection mechanism according to claim 3, characterized in that, A fixed-length cryptographic hash value is generated by performing a hash operation on the device key and the current time factor using a hash-based message authentication code algorithm, specifically including: The HMAC-SHA1 algorithm is used to perform an XOR operation on the device key and a predefined fixed padding constant to generate the expanded key data; The expanded key data is combined with the current time factor according to a preset concatenation rule, and two rounds of hash calculations are performed sequentially to obtain the final cryptographic hash value.

5. The MQTT message security protection method based on a multi-layer protection mechanism according to claim 1, characterized in that, If the verification is successful, the control instructions in the MQTT message are executed through the client device, specifically including: If the comparison result data indicates that the local verification code matches the dynamic authentication password, the client device parses the control command from the payload of the MQTT message and performs a validity check on the control command; the validity check includes format check and semantic check. After the legality verification is passed, the client device transmits the control command to the corresponding internal command processing module, which then executes the operation logic defined by the control command. After successfully executing the control command, the client device generates a status log indicating successful command execution, stores the status log in the client device's non-volatile memory, and sends an acknowledgment message to the message broker server.

6. The MQTT message security protection method based on a multi-layer protection mechanism according to claim 1, characterized in that, If the verification fails, the MQTT message is discarded and an exception handling process is triggered, which includes: If the comparison result data indicates that the local verification code is inconsistent with the dynamic authentication password, the client device updates the exception counter data in local memory and starts the internal timer data. Before the internal timer data reaches the preset timeout threshold, the client device continuously monitors the MQTT message and repeatedly performs the consistency comparison operation; If the abnormal counter data accumulates to a preset security threshold within the preset timeout threshold, or if no MQTT message carrying a valid dynamic authentication password is received before the internal timer data expires, the client device will proactively initiate a network connection disconnection command to terminate the communication session with the message broker server.

7. The MQTT message security protection method based on a multi-layer protection mechanism according to claim 1, characterized in that, Receiving MQTT messages sent by the message broker server through the client device specifically includes: After the message sender generates a dynamic authentication password, the dynamic authentication password and control instructions are concatenated according to a predefined field order and delimiters to form structured message payload data. The structured message payload data is encapsulated in the payload portion of an MQTT protocol publish message, and target topic information is set in the header of the publish message to instruct the message broker server to route the MQTT message to the target client device. The target client device receives the MQTT message on the subscribed target topic, and parses the structured message payload data according to the predefined field order and delimiter to extract the dynamic authentication password and the control command.

8. The MQTT message security protection method based on a multi-layer protection mechanism according to claim 1, characterized in that, Before receiving the MQTT message sent by the message broker server through the client device, the method further includes: When the message sender needs to send an MQTT message to the target device, a security API request is generated and sent to the key management server; the security API request includes a unique identifier corresponding to the target client device. After the key server verifies the identity of the message sender, it retrieves the device key corresponding to the target client device from the encrypted key storage, encrypts the device key, and returns it to the message sender. The message sender obtains the device key corresponding to the target client device by decryption and acquires the current time factor; wherein, the time factor changes dynamically based on the time source; Based on the device key and the time factor, and through calculation using a predefined cryptographic algorithm, a dynamically changing authentication password is generated.

9. An MQTT message security protection device based on a multi-layered protection mechanism, characterized in that, The device includes: At least one processor; And, a memory communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the MQTT message security protection method based on a multi-layer protection mechanism as described in any one of claims 1-8.

10. A non-volatile computer storage medium storing computer-executable instructions, characterized in that, When the computer-executable instructions are executed, the MQTT message security protection method based on a multi-layer protection mechanism as described in any one of claims 1-8 is implemented.

Images