A control method and apparatus for a chain of multiple internet of things devices

Abstract

This application discloses a control method and apparatus for a chain of multiple IoT devices. By combining SM9 identification authentication with SM4 block encryption, it achieves point-to-point dynamic identity access and high-strength communication encryption for multiple IoT devices in the chain collaboration process without the need for complex certificate management. This effectively ensures the immutability and transmission security of control commands in complex execution processes.

Description

Technical Field

[0001] This invention relates to the field of control technology for multiple IoT device chains, and in particular to a control method for multiple IoT device chains, a control device for multiple IoT device chains, an electronic device, and a readable storage medium. Background Technology

[0002] With the rapid development of IoT technology, the demand for multi-device collaborative operation is increasing in fields such as industrial automation, smart manufacturing, and smart homes. This typically requires multiple IoT devices to form a control chain according to a preset logical sequence to execute complex tasks. In multi-device chain control scenarios, ensuring the authenticity of participating nodes and the security of communication between devices is fundamental to the stable operation of the entire system.

[0003] In scenario-based applications involving multiple IoT devices, the centralized architecture of related technologies leads to frequent relays of all control commands and data in the cloud, creating multiple data exposure windows that are vulnerable to eavesdropping, tampering, forgery, and even quantum computing attacks, resulting in serious security risks. Summary of the Invention

[0004] The present invention provides a control method, apparatus, electronic device, and readable storage medium for multiple IoT device chains to overcome or at least partially solve the above-mentioned problems.

[0005] To solve the above-mentioned technical problems, this application is implemented as follows: In a first aspect, embodiments of this application provide a control method for a multi-IoT device chain, the method being applied to a cloud server, comprising: Perform authentication operations on multiple IoT devices, and use multiple certified IoT devices to form a multi-IoT device chain; Determine the adjacent communication nodes of the multi-IoT device chain, and send the user's private key to one or more groups of target devices corresponding to the adjacent communication nodes; The system enables multiple target devices in the same group to perform SM9 two-way authentication using the user's private key. Multiple target devices in the same group that have completed the two-way authentication operation of the SM9 identifier cryptography algorithm negotiate to generate a session key of the SM4 block cipher algorithm for realizing inter-device communication; Determine the execution flow for the multi-IoT device chain, and generate target tasks based on the execution flow; The chain of multiple IoT devices is controlled to perform the target task using the SM4 block cipher session key.

[0006] Optionally, the cloud server and the IoT device are configured with corresponding quantum key management systems, and the step of performing authentication operations on multiple IoT devices includes: Upon receiving a first authentication request for an IoT device, a unique identifier is generated for the IoT device, and the unique identifier is sent to the IoT device. The IoT device is configured to, in response to obtaining the unique identity identifier, authenticate its identity with the quantum key management system to obtain a first quantum key and a session identifier; generate a quantum encryption registration request containing the first quantum key, the session identifier, and the unique identity identifier; and send the quantum encryption registration request to the cloud server. In response to receiving the quantum cryptography registration request, a session identifier is extracted from the quantum cryptography registration request; Based on the session identifier, a key acquisition request is initiated to the quantum key management system, and a second quantum key is returned by the quantum key management system; the first quantum key and the second quantum key are homologous symmetric keys; The first quantum key and the second quantum key are used to perform quantum decryption on the quantum encryption registration request to obtain the decrypted unique identity ID. In response to the verification of the legitimacy of the unique identity ID, the IoT device is identified as an authenticated device.

[0007] Optionally, the step of sending the user's private key to one or more groups of target devices corresponding to the adjacent communication node includes: Generate a user private key for the target device using the master private key; The user's private key is encrypted using the second quantum key to generate a private key encrypted message, and the private key encrypted message is sent to the target device; The target device is configured to receive the private key encrypted message, decrypt it using the pre-stored first quantum key, and obtain and store the user's private key.

[0008] Optionally, the multiple target devices in the same group include an initiating device and a responding device, and the step of driving the multiple target devices in the same group to perform the SM9 two-way authentication operation using the user's private key includes: The device initiating the challenge generates a first temporary random challenge number and calculates challenge parameters based on the first temporary random challenge number. The initiating device is controlled to encrypt its unique identifier using the first quantum key, and then encapsulate the encrypted unique identifier, the challenge parameter, and the session identifier into a second authentication request and send it to the responding device. The control unit requests a third quantum key, which is of the same origin as the first quantum key, from the quantum key management system based on the received session identifier. The responding device is controlled to decrypt the second authentication request using the third quantum key, obtain the unique identity identifier of the initiating device, and generate a second temporary random challenge number; The responding device is controlled to generate a second temporary random challenge number, and a first shared key is calculated based on the challenge parameters, the unique identifier of the initiating device, the second temporary random challenge number, and the pre-stored private key of the responding device user. The control unit calculates response parameters based on the second temporary random challenge number, and sends the unique identifier of the response unit encrypted with the third quantum key and the response parameters to the initiating unit. The initiating device is controlled to decrypt the unique identifier of the responding device using the first quantum key, and to calculate the corresponding second shared key using the response parameters, the unique identifier of the responding device, and its own initiating device user private key; Based on the first shared key and the second shared key, perform two-way authentication operation using the SM9 cryptographic algorithm for multiple target devices in the same group.

[0009] Optionally, the step of controlling multiple target devices in the same group that complete the SM9 bidirectional authentication operation of the identifier cryptography algorithm to negotiate and generate an SM4 block cipher session key for inter-device communication includes: The initiating device is controlled to retrieve the first temporary random challenge number, the second temporary random challenge number, and the first shared key, and input the first temporary random challenge number, the second temporary random challenge number, and the first shared key into a preset key derivation function to calculate and generate the first block cipher algorithm SM4 session key; The control terminal device retrieves the first temporary random challenge number, the second temporary random challenge number, and the second shared key, and inputs the first temporary random challenge number, the second temporary random challenge number, and the second shared key into the key derivation function to calculate and generate the second block cipher algorithm SM4 session key; The initiating device is controlled to encrypt the first handshake confirmation message using the first block cipher algorithm SM4 session key, generate the first key verification ciphertext, and send the first key verification ciphertext to the responding device; The control terminal device decrypts the first key verification ciphertext using the locally generated second block cipher algorithm SM4 session key, and when it is determined that the first handshake confirmation message passes the verification, generates a second key verification ciphertext encrypted with the second block cipher algorithm SM4 session key, and returns the second key verification ciphertext to the initiating terminal device; The initiating device is controlled to decrypt the second key verification ciphertext using the first block cipher algorithm SM4 session key, obtain the decryption result, and store the first block cipher algorithm SM4 session key in response to the decryption result conforming to the preset verification logic.

[0010] Optionally, the step of controlling the multi-IoT device chain to perform the target task through the SM4 block cipher session key includes: The execution order and business logic of each IoT device are determined according to the execution process, and an orchestration instruction containing complete execution path information is generated based on the execution order and the business logic. The SM4 session key, a block cipher algorithm shared with the first target device in the multi-IoT device chain, is retrieved to encrypt the orchestration instructions, generate initial control ciphertext, and send it to the edge layer of the multi-IoT device chain. The first target device is configured to decrypt the initial control ciphertext using the SM4 session key pre-stored in the first target device, and execute the functional action corresponding to the orchestration instruction to generate a first node execution state containing the current action completion status; The first target device encapsulates the execution status of the first node and the remaining instruction information in the orchestration instructions into a first intermediate control instruction, and uses the SM4 session key shared with the next-hop target device to encrypt the first intermediate control instruction, and sends the encrypted first intermediate control instruction to the next-hop target device. The next-hop target device is configured to decrypt the first intermediate control command using the SM4 session key pre-stored in the next-hop target device, and execute the functional actions corresponding to the remaining command information.

[0011] Optionally, it also includes: When it is determined that the terminal target device has completed the terminal function, the control terminal target device summarizes the execution status information generated by each adjacent communication node, generates a full-process quality inspection report, and uses the SM4 session key shared with the cloud server to encrypt the full-process quality inspection report, and then reports the encrypted full-process quality inspection report to the cloud server.

[0012] Secondly, embodiments of this application provide a control device for a multi-IoT device chain, wherein the method is applied to a cloud server and includes: The IoT device authentication module is used to perform authentication operations on multiple IoT devices, and multiple certified IoT devices are used to form a multi-IoT device chain; The user private key sending module is used to determine the adjacent communication nodes of the multi-IoT device chain and send the user private key to one or more groups of target devices corresponding to the adjacent communication nodes. The two-way authentication operation module is used to drive multiple target devices in the same group to perform two-way authentication operations using the user's private key and the SM9 identifier cryptography algorithm. The session key negotiation module is used to control multiple target devices in the same group that complete the two-way authentication operation of the SM9 identifier cryptography algorithm, and negotiate to generate a session key for the SM4 block cipher algorithm used to realize inter-device communication; The target task generation module is used to determine the execution flow for the multi-IoT device chain and generate target tasks based on the execution flow; The target task execution module is used to control the multi-IoT device chain to execute the target task through the SM4 block cipher session key.

[0013] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0014] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.

[0015] Fifthly, embodiments of this application provide a chip, the chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the method as described in the first aspect.

[0016] The embodiments of the present invention have the following advantages: This invention combines SM9 identifier authentication with SM4 block encryption, enabling point-to-point dynamic identity access and high-strength communication encryption for multiple IoT devices in chain collaboration without the need for complex certificate management. This effectively ensures the immutability and transmission security of control commands in complex execution processes. Attached Figure Description

[0017] Figure 1This is a flowchart of the steps of a control method for a multi-IoT device chain provided in an embodiment of the present invention; Figure 2 This is an overall architecture diagram of a control system for a multi-IoT device chain provided in an embodiment of the present invention; Figure 3 This is a timing diagram provided in an embodiment of the present invention for characterizing the identity registration and authentication process of a terminal device in the cloud; Figure 4 This is a timing diagram provided in an embodiment of the present invention for characterizing the process of establishing a secure session between terminal devices; Figure 5 This is a timing diagram provided in an embodiment of the present invention for characterizing the process of a terminal device executing instructions; Figure 6 This is a structural block diagram of a control device for a multi-IoT device chain provided in an embodiment of the present invention; Figure 7 This is a hardware structure block diagram of an electronic device provided in an embodiment of the present invention; Figure 8 This is a schematic diagram of a computer-readable medium provided in an embodiment of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0020] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0021] Reference Figure 1 The diagram illustrates a flowchart of a control method for a multi-IoT device chain provided in an embodiment of the present invention, which may specifically include the following steps: Step 101: Perform authentication operations on multiple IoT devices, and use multiple certified IoT devices to form a multi-IoT device chain; Step 102: Determine the adjacent communication nodes of the multi-IoT device chain, and send the user's private key to one or more groups of target devices corresponding to the adjacent communication nodes; Step 103: Drive multiple target devices in the same group to perform SM9 two-way authentication operation using the user's private key; Step 104: Control multiple target devices in the same group that have completed the two-way authentication operation of the SM9 identifier cryptography algorithm to negotiate and generate a session key of the SM4 block cipher algorithm for realizing inter-device communication; Step 105: Determine the execution flow for the multi-IoT device chain, and generate a target task based on the execution flow; Step 106: Control the multi-IoT device chain to execute the target task through the SM4 block cipher session key.

[0022] In practical applications, the embodiments of the present invention can be applied to cloud servers; refer to Figure 2 , Figure 2 This is an overall architecture diagram of a control system for a multi-IoT device chain provided in an embodiment of the present invention; The overall architecture of the multi-IoT device chain control method based on quantum-secure encryption is divided into a quantum layer, a distribution layer, a cloud layer, and an edge layer. The quantum layer consists of QKD devices and a quantum physics network, and is responsible for generating quantum keys and synchronizing keys between cross-domain platforms. The distribution layer consists of the Key Management System (QKMS), which is responsible for offline pre-filling of keys and distribution of quantum keys to the cloud and terminal devices. The cloud layer consists of cloud servers, which are responsible for issuing instructions, receiving device feedback information, and forwarding and storing data; The edge layer consists of various IoT terminal devices, which are responsible for receiving, forwarding and responding to instructions, as well as executing the device's own functions.

[0023] In specific implementations, embodiments of the present invention can perform authentication operations on multiple IoT devices, using multiple certified IoT devices to form a multi-IoT device chain to establish a trust foundation for the system, ensuring that only legally authorized devices can enter the control system, and logically connecting the dispersed devices into a "chain" with a sequential collaborative relationship according to business logic.

[0024] Internet of Things (IoT) devices refer to terminal hardware with sensing, communication, and execution capabilities, such as sensors, robotic arms, and cameras.

[0025] Authentication refers to the process of verifying the authenticity of a device's identity.

[0026] A multi-IoT device chain refers to a logical collaborative sequence formed by multiple devices arranged in a specific workflow order.

[0027] In a specific implementation, embodiments of the present invention can determine the adjacent communication nodes of the multi-IoT device chain and send user private keys to one or more groups of target devices corresponding to the adjacent communication nodes to identify pairs of nodes in the chain that have direct data interaction, and assign them key credentials for identity verification, in preparation for subsequent point-to-point secure communication.

[0028] Adjacent communication nodes refer to two devices in the execution chain that physically or logically directly transmit next-hop data.

[0029] The target device refers to the device that is selected to participate in the execution of a specific task and requires the configuration of security parameters.

[0030] The user's private key is a unique private key calculated by the Key Generation Center (KGC) based on the device's identity identifier (ID).

[0031] This invention can drive multiple target devices in the same group to perform two-way authentication using the user's private key. By utilizing the domestically developed identifier cryptography algorithm, adjacent devices can mutually verify each other's identity and legitimacy without relying on complex certificates, thus preventing unauthorized devices from accessing the communication link.

[0032] The SM9 identity-based cryptosystem is an asymmetric cryptosystem that uses the device's ID (such as MAC address or serial number) directly as the public key.

[0033] Two-way authentication refers to the process by which two communicating parties verify each other's identity to ensure that both parties are trustworthy.

[0034] This invention can control multiple target devices in the same group that complete the two-way authentication operation of the SM9 identification cryptography algorithm to negotiate and generate a session key of the SM4 block cipher algorithm for inter-device communication. Based on mutual trust, a temporary high-strength symmetric key is dynamically generated to encrypt specific business instructions and data transmitted subsequently.

[0035] The SM4 block cipher is a symmetric encryption algorithm suitable for high-performance data block encryption and decryption.

[0036] A session key is a temporary key that is only valid for one communication session and expires after that, increasing the difficulty of cracking it.

[0037] The embodiments of the present invention can determine the execution flow for the multi-IoT device chain and generate target tasks based on the execution flow to transform business logic into an executable instruction set, and clarify the specific actions and triggering conditions that each node should perform in the chain collaboration.

[0038] The execution flow refers to the logical sequence in which equipment chains complete specific functions (such as production line testing).

[0039] The target task includes a package of instructions containing specific execution parameters, path information, and encryption requirements.

[0040] The embodiments of the present invention can control the chain of multiple IoT devices to execute the target task through the SM4 block cipher session key, so as to realize the final implementation of business logic, ensure that the instructions are in a fully encrypted state when transmitted between nodes, and ensure the integrity and privacy of the chain control process.

[0041] This invention combines SM9 identifier authentication with SM4 block encryption, enabling point-to-point dynamic identity access and high-strength communication encryption for multiple IoT devices in chain collaboration without the need for complex certificate management. This effectively ensures the immutability and transmission security of control commands in complex execution processes.

[0042] Based on the above embodiments, modified embodiments of the above embodiments are proposed. It should be noted that, in order to keep the description brief, only the differences from the above embodiments are described in the modified embodiments.

[0043] In an optional embodiment of the present invention, the cloud server and the IoT device are configured with corresponding quantum key management systems, and the step of performing authentication operations on multiple IoT devices includes: Upon receiving a first authentication request for an IoT device, a unique identifier is generated for the IoT device, and the unique identifier is sent to the IoT device. The IoT device is configured to, in response to obtaining the unique identity identifier, authenticate its identity with the quantum key management system to obtain a first quantum key and a session identifier; generate a quantum encryption registration request containing the first quantum key, the session identifier, and the unique identity identifier; and send the quantum encryption registration request to the cloud server. In response to receiving the quantum cryptography registration request, a session identifier is extracted from the quantum cryptography registration request; Based on the session identifier, a key acquisition request is initiated to the quantum key management system, and a second quantum key is returned by the quantum key management system; the first quantum key and the second quantum key are homologous symmetric keys; The first quantum key and the second quantum key are used to perform quantum decryption on the quantum encryption registration request to obtain the decrypted unique identity ID. In response to the verification of the legitimacy of the unique identity ID, the IoT device is identified as an authenticated device.

[0044] In this embodiment of the invention, when a first authentication request for an IoT device is received, a unique identity identifier is generated for the IoT device, and the unique identity identifier is sent to the IoT device. Then, the server actively allocates a controlled logical identity to ensure that each access device has a globally unique identity identifier within the system, thus establishing an anchor point for subsequent authentication.

[0045] The first authentication request refers to the initial triggering command initiated by the user or system to request the access of a new device to the current security domain.

[0046] A unique identifier is a string or number generated by the cloud to identify a specific device at the logical level; it is the device's legal identity within the system.

[0047] The IoT device of this embodiment can be configured to, in response to obtaining the unique identity identifier, authenticate its identity with the quantum key management system to obtain a first quantum key and a session identifier; generate a quantum encryption registration request containing the first quantum key, the session identifier, and the unique identity identifier; and send the quantum encryption registration request to the cloud server so that the device can obtain encryption credentials through a physically isolated quantum secure channel and bind the identity assigned by the cloud with the quantum key, thereby feeding back the registration intention to the cloud in a non-eavesdropping manner.

[0048] A quantum key management system is a secure infrastructure that generates and distributes truly random keys based on quantum properties, providing unconditionally secure key support.

[0049] The first quantum key refers to the symmetric key distributed by the quantum system to the terminal device for data encryption during the registration process.

[0050] A session identifier is a unique index used to mark this key distribution action so that the corresponding key can be retrieved in the cloud.

[0051] A quantum cryptography registration request refers to an online application data packet containing identity information and a session index, encrypted using a quantum key.

[0052] In this embodiment of the invention, in response to receiving the quantum encryption registration request, a session identifier can be extracted from the quantum encryption registration request to locate the encryption background corresponding to the request in the cloud, providing a basis for obtaining the corresponding decryption tool (key).

[0053] In this embodiment of the invention, a key acquisition request can be initiated based on the session identifier to the quantum key management system, and a second quantum key returned by the quantum key management system can be received; the first quantum key and the second quantum key are homologous symmetric keys, and the cloud retrieves the quantum key that is completely consistent with the device through an index, so as to achieve synchronization of "one key per device, one key per time".

[0054] The second quantum key is a symmetric key that is sent from the quantum system to the cloud and is paired with the first quantum key held by the device.

[0055] A homogeneous symmetric key refers to a key generated from the same quantum random source, having identical values, and stored at both ends of the communication.

[0056] In this embodiment of the invention, the first quantum key and the second quantum key can be used to perform quantum decryption on the quantum encryption registration request to obtain the decrypted unique identity ID, so as to restore the device identity data using quantum-safe keys and ensure that the identity information cannot be cracked even if it is intercepted during transmission.

[0057] In this embodiment of the invention, in response to the verification of the legality of the unique identity ID, the IoT device can be identified as an authenticated device to complete the closed-loop verification, confirm that the identity reported by the device is consistent with the identity pre-issued in the cloud, and formally accept the device into the trust domain.

[0058] Authentication devices are legitimate terminals that have been verified and have the authority to execute subsequent business logic within the system.

[0059] In this embodiment of the invention, by combining a unique identifier assigned in the cloud with a truly random key generated by the quantum key management system, a quantum-safe encrypted channel is constructed during the device registration stage. This eliminates the risk of identity identifiers being counterfeited or hijacked during plaintext transmission, and achieves extremely high-strength trusted access control for IoT devices.

[0060] In an optional embodiment of the present invention, the step of sending the user's private key to one or more groups of target devices corresponding to the adjacent communication node includes: Generate a user private key for the target device using the master private key; The user's private key is encrypted using the second quantum key to generate a private key encrypted message, and the private key encrypted message is sent to the target device; The target device is configured to receive the private key encrypted message, decrypt it using the pre-stored first quantum key, and obtain and store the user's private key.

[0061] In this embodiment of the invention, a user private key for the target device can be generated using the master private key. Based on an identifier encryption system, a unique decryption credential bound to the identity of each legally accessed device can be generated, thereby achieving lightweight security management of "identity as public key".

[0062] The master private key ks is a core secret parameter strictly controlled by the Key Generation Center (KGC) and is the source for generating private keys for all devices in the entire system.

[0063] A user's private key is a private data item calculated using the master private key and a specific device identity (ID). It is held exclusively by that device and is used for subsequent identity verification and signing.

[0064] In this embodiment of the invention, the user's private key can be encrypted using the second quantum key to generate a private key encryption message, and the private key encryption message can be sent to the target device to ensure that the highly sensitive user's private key is protected at the quantum level during the sending process, preventing the private key from being eavesdropped on or cracked during network transmission.

[0065] The second quantum key is a truly random symmetric key distributed to the server by the cloud-based quantum key management system for strengthening and encrypting sensitive business data.

[0066] Private key encrypted messages are user private key data packets encrypted with quantum key distribution, and appear as unbreakable ciphertext on the transmission line.

[0067] The target device in this embodiment of the invention is configured to receive the private key encrypted message, decrypt it using the pre-stored first quantum key, obtain and store the user private key, so as to realize the secure restoration and compliant storage of the key on the device side, and enable the device to have the technical capability to participate in subsequent identification cryptography algorithm (SM9) authentication.

[0068] The first quantum key is a symmetric key that is pre-filled or distributed to the secure medium at the device end by the quantum key management system and is completely homologous to the second quantum key.

[0069] Storing a user's private key refers to storing the decrypted private key in the device's built-in Hardware Security Module (HSM) or a secure isolation zone to prevent unauthorized access.

[0070] This invention utilizes quantum keys with "unconditional security" to protect the distribution process of the private key of the domestically developed identifier cryptography algorithm (SM9), fundamentally solving the security vulnerability of asymmetric private keys in the distribution stage and ensuring that the underlying root of trust of each pair of communication nodes in the IoT device chain is not leaked.

[0071] For example, refer to Figure 3 , Figure 3This is a timing diagram provided in an embodiment of the present invention for characterizing the identity registration and authentication process of a terminal device in the cloud; Figure 3 This illustrates the identity registration and authentication process using the national cryptographic algorithm SM9 when a new terminal device A first joins the cloud space and becomes a trusted device: 1. Users scan for new devices and configure them via a mobile app, then send a request to the cloud to add the device, which includes the device ID and user identity information.

[0072] 2. The cloud-based KGC begins responding to the device addition request, first generating a unique identity ID_A for device A.

[0073] 3. Device A authenticates itself with QKMS through its built-in secure medium. After successful authentication, it issues a quantum key and session ID.

[0074] 4. Device A sends the session ID and the ID_A of the quantum encryption registration request to the cloud KGC via the Key.

[0075] 5. After receiving the request, the cloud-based KGC first authenticates its trusted identity with QKMS through the session ID, obtains the quantum key Key corresponding to the session ID issued by QKMS, performs quantum decryption, verifies the legality of ID_A, calculates the public key point of device A, and generates the private key d_A of device A using the master private key ks, and sends it to device A after quantum encryption.

[0076] 6. Device A performs quantum decryption and saves its private key d_A.

[0077] 7. The cloud-based KGC notifies user A via mobile phone that the device has been successfully added. After receiving confirmation from the user, it registers ID_A in the list of trusted devices and sends a notification of successful authentication to device A. Device A will then perform functions such as flashing to provide feedback to the user that the authentication was successful.

[0078] In an optional embodiment of the present invention, the plurality of target devices in the same group include an initiating device and a responding device, and the step of driving the plurality of target devices in the same group to perform the SM9 two-way authentication operation using the user's private key includes: The device initiating the challenge generates a first temporary random challenge number and calculates challenge parameters based on the first temporary random challenge number. The initiating device is controlled to encrypt its unique identifier using the first quantum key, and then encapsulate the encrypted unique identifier, the challenge parameter, and the session identifier into a second authentication request and send it to the responding device. The control unit requests a third quantum key, which is of the same origin as the first quantum key, from the quantum key management system based on the received session identifier. The responding device is controlled to decrypt the second authentication request using the third quantum key, obtain the unique identity identifier of the initiating device, and generate a second temporary random challenge number; The responding device is controlled to generate a second temporary random challenge number, and a first shared key is calculated based on the challenge parameters, the unique identifier of the initiating device, the second temporary random challenge number, and the pre-stored private key of the responding device user. The control unit calculates response parameters based on the second temporary random challenge number, and sends the unique identifier of the response unit encrypted with the third quantum key and the response parameters to the initiating unit. The initiating device is controlled to decrypt the unique identifier of the responding device using the first quantum key, and to calculate the corresponding second shared key using the response parameters, the unique identifier of the responding device, and its own initiating device user private key; Based on the first shared key and the second shared key, perform two-way authentication operation using the SM9 cryptographic algorithm for multiple target devices in the same group.

[0079] In this embodiment of the invention, the initiating device can be controlled to generate a first temporary random challenge number and calculate challenge parameters based on the first temporary random challenge number. By introducing random variables, the uniqueness of each authentication process can be ensured, replay attacks can be prevented, and basic parameters can be provided for the subsequent generation of negotiation keys.

[0080] The first temporary random challenge number (rA) is a truly random number generated by the initiator. It has the "one-time pad" property and is used to participate in encryption operations.

[0081] The Challenge Parameter (RA) is a public parameter obtained by multiplying or mapping the generator in the SM9 algorithm with a random number. It is used to pass to the other end for key negotiation.

[0082] In this embodiment of the invention, the initiating device can be controlled to encrypt the unique identity identifier of the initiating device using the first quantum key, and encapsulate the encrypted unique identity identifier of the initiating device, the challenge parameter, and the session identifier into a second authentication request and send it to the responding device, so as to covertly send the identity information of the initiating device under quantum security protection and start the point-to-point authentication process with adjacent nodes.

[0083] The first quantum key is a quantum random key pre-stored locally at the initiator and distributed by the quantum system, used to ensure the initial confidentiality of point-to-point communication.

[0084] The second authentication request is a structured instruction packet containing identity ciphertext and negotiation parameters sent from the initiating end to the responding end.

[0085] In this embodiment of the invention, the responding device can be controlled to apply for a third quantum key that is of the same origin as the first quantum key from the quantum key management system based on the received session identifier, so that the responding device can obtain the symmetric "key" required to decrypt the request message and realize key synchronization between adjacent devices.

[0086] The third quantum key is a homologous key distributed by the quantum system to the responder, and its value is exactly the same as the first quantum key held by the initiator.

[0087] In this embodiment of the invention, the responding device can be controlled to decrypt the second authentication request using the third quantum key, obtain the unique identity identifier of the initiating device, and generate a second temporary random challenge number to restore the true identity of the initiating device for verification. The responding device can also generate its own random variable to initiate two-way confirmation.

[0088] The second temporary random challenge number (rB) is a random variable generated by the responder and is used to build a closed loop for two-way authentication.

[0089] In this embodiment of the invention, the responding device can be controlled to generate a second temporary random challenge number, and calculate a first shared key based on the challenge parameters, the unique identifier of the initiating device, the second temporary random challenge number, and the pre-stored private key of the responding device user. The responding device combines the random numbers of both parties and its own private key to calculate an intermediate variable that only the two communicating parties can deduce, thereby achieving the coupling of "authentication" and "key negotiation".

[0090] The responding device user's private key is a unique SM9 private key used to verify the authenticity of their identity.

[0091] The first shared secret key (SK_B) is an intermediate key result that is symmetrical to the peer's key, calculated by the responding end based on the SM9 algorithm logic.

[0092] In this embodiment of the invention, the responding device can be controlled to calculate response parameters based on the second temporary random challenge number, and send the unique identifier of the responding device encrypted with the third quantum key and the response parameters to the initiating device to provide feedback on its identity to the initiating device, and transmit its own negotiation parameters back under quantum protection.

[0093] Response Parameter (RB) is a public parameter generated by the responder based on its random number and used by the initiator to calculate the key.

[0094] In this embodiment of the invention, the initiating device can be controlled to decrypt the unique identity of the responding device using the first quantum key, and calculate the corresponding second shared key using the response parameters, the unique identity of the responding device, and its own initiating device user private key. This allows the initiating device to complete the decryption of the responding device's identity and derive a shared key consistent with its counterpart, thus achieving logical symmetry.

[0095] The second shared secret key (SK_A) is an intermediate key result calculated by the initiator based on the SM9 algorithm logic, which should be equal to the first shared key.

[0096] In this embodiment of the invention, the SM9 two-way authentication operation of the identification cryptography algorithm can be completed for multiple target devices in the same group based on the first shared key and the second shared key. By verifying the logical consistency of the two shared keys, it is finally determined that the identities of both parties are genuine and legitimate, and a mutual trust relationship is established between adjacent nodes.

[0097] This invention combines "quantum key encrypted transmission" with "SM9 identifier cryptographic two-way authentication" to achieve lightweight identity verification between adjacent IoT nodes without the need for certificates. It not only hides sensitive device identification information during the authentication process, but also ensures high real-time performance and anti-attack capability of node-to-node authentication in chain control through a two-way random number challenge mechanism.

[0098] In an optional embodiment of the present invention, the step of controlling multiple target devices in the same group that complete the SM9 bidirectional authentication operation of the identifier cryptography algorithm to negotiate and generate an SM4 block cipher session key for realizing inter-device communication includes: The initiating device is controlled to retrieve the first temporary random challenge number, the second temporary random challenge number, and the first shared key, and input the first temporary random challenge number, the second temporary random challenge number, and the first shared key into a preset key derivation function to calculate and generate the first block cipher algorithm SM4 session key; The control terminal device retrieves the first temporary random challenge number, the second temporary random challenge number, and the second shared key, and inputs the first temporary random challenge number, the second temporary random challenge number, and the second shared key into the key derivation function to calculate and generate the second block cipher algorithm SM4 session key; The initiating device is controlled to encrypt the first handshake confirmation message using the first block cipher algorithm SM4 session key, generate the first key verification ciphertext, and send the first key verification ciphertext to the responding device; The control terminal device decrypts the first key verification ciphertext using the locally generated second block cipher algorithm SM4 session key, and when it is determined that the first handshake confirmation message passes the verification, generates a second key verification ciphertext encrypted with the second block cipher algorithm SM4 session key, and returns the second key verification ciphertext to the initiating terminal device; The initiating device is controlled to decrypt the second key verification ciphertext using the first block cipher algorithm SM4 session key, obtain the decryption result, and store the first block cipher algorithm SM4 session key in response to the decryption result conforming to the preset verification logic.

[0099] In this embodiment of the invention, the initiating device can be controlled to retrieve the first temporary random challenge number, the second temporary random challenge number, and the first shared key, and input the first temporary random challenge number, the second temporary random challenge number, and the first shared key into a preset key derivation function to calculate and generate a first block cipher algorithm SM4 session key. The initiating device uses all random factors generated during the convergence authentication phase and core shared information to derive a symmetric key for actual business encryption using irreversible mathematical transformations.

[0100] A key derivation function (KDF) is a cryptographic algorithm used to transform initial key material into one or more working keys with higher security strength.

[0101] The first block cipher algorithm, SM4, uses a session key that is a temporary symmetric key generated locally by the initiating end and used for subsequent block encryption of business data.

[0102] In this embodiment of the invention, the responding device can be controlled to retrieve the first temporary random challenge number, the second temporary random challenge number, and the second shared key, and input the first temporary random challenge number, the second temporary random challenge number, and the first shared key into the key derivation function to calculate and generate a second block cipher algorithm SM4 session key, so that the responding end can execute fully symmetric derivation logic locally to obtain a communication key that is completely consistent with the initiating end.

[0103] The second block cipher algorithm, SM4, uses a symmetric key that is locally computed at the responding end and should theoretically have the same value as the first session key.

[0104] In this embodiment of the invention, the initiating device can be controlled to encrypt the first handshake confirmation message using the first block cipher algorithm SM4 session key, generate a first key verification ciphertext, and send the first key verification ciphertext to the responding device. This allows the initiating device to initiate exploratory communication first to test whether the responding device has successfully generated a matching decryption key, ensuring that the keys of both parties are synchronized.

[0105] The first handshake confirmation message is a pre-defined string of known characteristics used to verify the correctness of the key.

[0106] The first key verification ciphertext is the result of encrypting the handshake message using a derived SM4 key.

[0107] In this embodiment of the invention, the responding device can be controlled to decrypt the first key verification ciphertext using the locally generated second block cipher algorithm SM4 session key. When it is determined that the first handshake confirmation message has passed the verification, a second key verification ciphertext encrypted with the second block cipher algorithm SM4 session key is generated and returned to the initiating device. The responding device proves the consistency of the keys by successfully decrypting the ciphertext and completes the two-way key confirmation through reverse encryption feedback.

[0108] The second key verification ciphertext is the message obtained by the responding end through a second encryption of the handshake response message.

[0109] In this embodiment of the invention, the initiating device can be controlled to decrypt the second key verification ciphertext using the first block cipher algorithm SM4 session key, obtain the decryption result, and in response to the decryption result conforming to the preset verification logic, store the first block cipher algorithm SM4 session key, so that the initiating end can finally confirm that the key held by the responding end is correct, formally activate and securely store the communication key of this session, and complete the negotiation loop.

[0110] In this embodiment of the invention, by injecting the shared key generated by SM9 authentication and the bidirectional random challenge number into the key derivation function, a deep binding between the session key and the identity authentication process is achieved. This ensures that the generated SM4 session key has extremely high randomness and resistance to attacks, and the risk of subsequent service interruption due to key negotiation failure is eliminated through the bidirectional handshake verification mechanism.

[0111] refer to Figure 4 , Figure 4 This is a timing diagram provided in an embodiment of the present invention for characterizing the process of establishing a secure session between terminal devices; Figure 4 This demonstrates the process of establishing a secure session between terminal devices using the Chinese national cryptographic SM9 algorithm and negotiating a session key using the Chinese national cryptographic SM4 algorithm: 1. After generating the master key pair and publishing the master public key in the cloud, KGC distributes the private keys d_A and d_B to devices A and B, respectively, which are to establish a secure session for the first time.

[0112] 2. Device A authenticates itself with QKMS through its built-in secure medium. After successful authentication, QKMS issues a quantum key and a session ID.

[0113] 3. Device A generates a temporary random challenge number rA, and calculates the challenge parameter RA=rA*P1 by multiplying it with the generator. Device A then sends the session ID, the key quantum-encrypted identity ID_A, and the challenge parameter RA to device B.

[0114] 4. Device B first requests the corresponding session key Key from QKMS through the session ID, and quantum decrypts the information sent by device A and generates a temporary random challenge number rB. Based on the received challenge parameter RA, identity ID_A and its own private key d_B, it calculates the shared key SK_B and the response parameter RB=rB*P1. After quantum encryption of identity ID_B and response parameter RB, it sends them to device A, and obtains the session key Session of the SM4 algorithm through the derived function KDF.

[0115] 5. Device A decrypts the information using Key Quantum, calculates the shared key SK_A based on the accepted challenge response RB, identity ID_B, and its own private key d_A, and obtains the session key Session through the derived function KDF.

[0116] 6. Device A calculates the confirmation information S1 and sends it to Device B using Key quantum encryption. S1 is obtained by hashing the session key, random number RA, random number RB, and Device B's identity ID_B.

[0117] 7. Device B decrypts S1 using Key Quantum, verifies the correctness of S1, and calculates the confirmation information S2 after verification. S2 is then encrypted by Key Quantum and sent to Device A. S2 is obtained by hashing the session key, random number RB, random number RA, and Device A's identity ID_A.

[0118] 8. Device A decrypts S2 using quantum decryption and verifies its correctness.

[0119] 9. Authentication successful, both parties will conduct SM4 secure communication through Session.

[0120] In an optional embodiment of the present invention, the step of controlling the multi-IoT device chain to perform the target task through the SM4 block cipher session key includes: The execution order and business logic of each IoT device are determined according to the execution process, and an orchestration instruction containing complete execution path information is generated based on the execution order and the business logic. The SM4 session key, a block cipher algorithm shared with the first target device in the multi-IoT device chain, is retrieved to encrypt the orchestration instructions, generate initial control ciphertext, and send it to the edge layer of the multi-IoT device chain. The first target device is configured to decrypt the initial control ciphertext using the SM4 session key pre-stored in the first target device, and execute the functional action corresponding to the orchestration instruction to generate a first node execution state containing the current action completion status; The first target device encapsulates the execution status of the first node and the remaining instruction information in the orchestration instructions into a first intermediate control instruction, and uses the SM4 session key shared with the next-hop target device to encrypt the first intermediate control instruction, and sends the encrypted first intermediate control instruction to the next-hop target device. The next-hop target device is configured to decrypt the first intermediate control command using the SM4 session key pre-stored in the next-hop target device, and execute the functional actions corresponding to the remaining command information.

[0121] According to the embodiments of the present invention, the execution order and business logic of each IoT device can be determined according to the execution process, and an orchestration instruction containing complete execution path information can be generated based on the execution order and the business logic, so as to transform the abstract business goal into a specific logical path that can be recognized by the machine, clarifying "who does it first, what it does, and who it is sent to" for each node in the device chain, and realizing top-level planning for complex collaborative processes.

[0122] Business logic refers to the specific operational rules and condition judgments that the device chain must follow when executing tasks (e.g., if the test is qualified, it will proceed; if it is unqualified, an error will be reported).

[0123] Orchestration instructions are control messages that contain end-to-end path information and task details, serving as a blueprint to guide the orderly operation of the entire device chain.

[0124] In this embodiment of the invention, the SM4 session key shared with the first target device in the multi-IoT device chain can be retrieved to encrypt the orchestration instructions, generate initial control ciphertext, and send it to the edge layer of the multi-IoT device chain. This allows the instructions to be encrypted at the source of the task distribution using the negotiated SM4 session key, ensuring that the control instructions are not eavesdropped on during the process of being sent from the cloud to the physical layer device.

[0125] The initial control ciphertext is the first control command encrypted using the SM4 algorithm, which can only be decrypted by the first target device.

[0126] The edge layer refers to the computing and communication environment close to IoT devices, and is the entry point for control commands to enter the physical execution area.

[0127] The first target device in this embodiment of the invention can be configured to decrypt the initial control ciphertext using the SM4 session key pre-stored in the first target device, and execute the functional action corresponding to the orchestration instruction, generating the first node execution state containing the current action completion status, so as to realize the first closed loop of chain control. The first node completes the instruction restoration and task execution, and records the execution results in real time for subsequent nodes to refer to.

[0128] The execution status of the first node records the data information of the completion status of the first device task (such as detection values, operation success / failure indicators).

[0129] In this embodiment of the invention, the first target device encapsulates the execution status of the first node and the remaining instruction information in the orchestration instructions into a first intermediate control instruction. This first intermediate control instruction is then encrypted using a shared SM4 session key with the next-hop target device. The encrypted first intermediate control instruction is then sent to the next-hop target device to initiate a relay-style chain transmission. The first device not only transmits the remaining tasks but also includes its own execution results, encrypted using a key unique to the next node, thus achieving secure point-to-point transmission between nodes.

[0130] The next-hop target device is the next cooperating device in the logical chain that immediately follows the currently executing device.

[0131] The first intermediate control instruction refers to a composite instruction package that includes the status of the preceding node and the requirements of the subsequent task.

[0132] The next-hop target device in this embodiment of the invention can be configured to decrypt the first intermediate control instruction using the SM4 session key pre-stored in the next-hop target device, and execute the functional action corresponding to the remaining instruction information, thereby demonstrating the continuity and logical consistency of chain control and ensuring that subsequent nodes can accurately execute the corresponding logical branch tasks based on the feedback results of the preceding nodes.

[0133] In this embodiment of the invention, by applying a pre-generated SM4 session key to the chained transmission process of "orchestration instructions", the control logic is realized through fully encrypted flow and step-by-step decryption and execution in the IoT device chain. This method not only ensures the confidentiality of instruction transmission between nodes, but also realizes complex business logic orchestration and automated collaborative operation under high security by using the execution status of the preceding node as the input of the subsequent node.

[0134] Optionally, it also includes: When it is determined that the terminal target device has completed the terminal function, the control terminal target device summarizes the execution status information generated by each adjacent communication node, generates a full-process quality inspection report, and uses the SM4 session key shared with the cloud server to encrypt the full-process quality inspection report, and then reports the encrypted full-process quality inspection report to the cloud server.

[0135] In this embodiment of the invention, when it is determined that the end target device has completed its end function, the end target device can be controlled to summarize the execution status information generated by each adjacent communication node and generate a full-process quality inspection report. This allows for data aggregation at the end of the chained task, integrating the fragmented execution records scattered across each node during the process into a complete structured document, thereby achieving traceability of the entire production or control process.

[0136] The end target device is the node device that is the last one in the execution sequence in a chain of multiple IoT devices.

[0137] The end function is the last business operation defined in the chained task (such as weighing finished products, labeling upon entry into the warehouse, etc.).

[0138] The full-process quality inspection report is a comprehensive document that summarizes all key execution data, timestamps, and logical judgment results from the first node to the last node.

[0139] In this embodiment of the invention, the SM4 session key, a block cipher algorithm shared with the cloud server, can be used to encrypt the full-process quality inspection report. The encrypted full-process quality inspection report is then reported to the cloud server to ensure that the aggregated core business data is not eavesdropped on or tampered with by third parties during the transmission back to the cloud, thus ensuring the confidentiality and integrity of the data in the public network transmission environment.

[0140] The SM4 session key, a block cipher algorithm shared with the cloud server, is a symmetric key that is negotiated and generated by the end device and the cloud KGC during the device authentication and chain construction phase, and is held only by the two parties.

[0141] Reporting a full-process quality inspection report is the communication behavior of the end device feeding back the business execution results to the management system (such as MES or cloud platform).

[0142] In this embodiment of the invention, by summarizing and encrypting the status at the end of the device chain, a closed-loop data feedback from the physical execution layer to the cloud management layer is achieved; the security of quality inspection data is ensured by using SM4 session keys, which not only provides the cloud with a complete and tamper-proof chain of task execution evidence, but also provides a reliable data foundation for subsequent quality analysis and decision-making.

[0143] refer to Figure 5 , Figure 5 This is a timing diagram provided in an embodiment of the present invention for characterizing the process of a terminal device executing instructions; Figure 5 This illustrates the process by which each device executes its respective function strictly according to a pre-defined chain of steps after the user sends a command: 1. Users issue scene commands via mobile clients.

[0144] 2. Cloud-based KGC verifies client permissions, and upon successful verification, retrieves the pre-arranged execution flow for the corresponding scenario.

[0145] 3. The cloud-based KGC sends the execution command encrypted with the session key Session1 to the first device A in the execution process.

[0146] 4. After device A decrypts the command using session key Session1 and executes its own function, it forwards the command to device B in encrypted form using SM4 session key Session2, according to the arrangement order.

[0147] 5. Device B decrypts the command using the Session2 session key, executes its own functions, and forwards the command to Device C using the Session3 session key.

[0148] 6. Device C decrypts the command using the Session3 session key and executes its own function. Since Device C is the last terminal device in this execution chain, after its execution is complete, QKMS returns the execution result of this process, encrypted with the Session4 session key, and the data that needs to be returned to the cloud KGC.

[0149] 7. The cloud-based KGC uses the session key Session4 to decrypt the execution result and returned data of this command, and then pushes the result and data to the user's end.

[0150] To enable those skilled in the art to better understand the embodiments of the present invention, an example is provided below to illustrate the embodiments of the present invention. Let's take an industrial quality inspection line as an example. This line consists of three intelligent workstations: a visual inspection station (equipment A), an ultrasonic flaw detection station (equipment B), and a weight sorting station (equipment C). Each workstation has independent IoT communication and data processing capabilities. When a product enters the line, it must be strictly inspected in the order of A → B → C. If any workstation detects a defective product, subsequent workstations will perform special processing (such as marking it as a defective product).

[0151] The system implemented in this embodiment includes a production execution system (MES, which serves as a cloud server), a factory local area network, and a visual inspection station (device A), an ultrasonic flaw detection station (device B), and a weight sorting station (device C) as terminal devices. All of these components have built-in security media for quantum encryption and decryption.

[0152] The functions provided by the above components are as follows: (1) Production Execution System (MES): As a cloud-based control center, it is responsible for initializing pipeline tasks, storing quality inspection orchestration strategies, managing equipment identities, and receiving final quality reports.

[0153] (2) Visual inspection station (equipment A): performs image acquisition and analysis on the product, determines whether the appearance is qualified, and executes instructions based on the results.

[0154] (3) Ultrasonic flaw detection station (equipment B): performs non-destructive testing on the internal structure of the product, determines whether the internal structure is qualified, and executes instructions based on the results.

[0155] (4) Weight sorting station (equipment C): weighs the products, performs final sorting based on whether the weight meets the standard, and reports the full-process quality inspection report of the product to the MES system.

[0156] (5) Security medium: It has a certificate of certification from the State Commercial Cryptography Administration, has key security protection capabilities and encryption and decryption capabilities. The security medium has unique ID information and can be connected to the quantum key management system to realize the pre-filling of quantum keys. S1. The Production Execution System (MES) and devices A, B, and C are guaranteed to have a network connection with QKMS. They have an integrated security medium that is pre-filled with a quantum charging key, which is generated by QKMS.

[0157] Furthermore, devices can be connected via wired or wireless means, and devices can be connected to QKMS, as long as network interoperability is ensured; the security medium is pre-charged with multiple quantum keys by the corresponding QKMS before leaving the factory as charging keys.

[0158] S2. Devices A, B, and C complete registration in the MES system and become trusted devices of the MES.

[0159] Furthermore, the MES first generates unique IDs for devices A, B, and C respectively. Device A selects an unused quantum charging key K1 from its own secure medium and generates a quantum session key request message, carrying the ID of the charging key K1. It then sends a quantum session key request containing the charging key ID to the QKMS. The QKMS receives the quantum session key request message, generates a quantum session key Ks and a corresponding session ID, and uses the charging key ID to encrypt the session key to generate ciphertext EK1(Ks). The ciphertext and session ID are returned to device A. Device A receives the ciphertext EK1(Ks), uses the charging key K1 to decrypt the ciphertext to obtain the quantum session key Ks, and synchronously records the session ID. The process is the same for devices B and C.

[0160] Furthermore, devices A, B, and C each send a registration request containing their own unique device ID, encrypted with the obtained session key and quantum key, to the MES. The MES applies for the corresponding quantum key from the QKMS through a secure medium based on the session ID, and decrypts the registration requests sent by each device based on the obtained quantum key, verifies the legality of the device ID, calculates the public key point of each device, and generates the private key of each device through the master private key (KS). After quantum encryption, the private key is sent to each device, and each device securely stores its own private key.

[0161] Furthermore, MES pushes a message to the client that devices A, B, and C have been successfully added. After the engineer confirms the addition, they are registered as trusted devices in the cloud device list, and a notification of successful authentication is sent to each device.

[0162] S3. Engineers define a strict quality inspection process strategy in the MES system: A (visual inspection) → B (ultrasonic inspection) → C (weight sorting), and set rules: the process will only proceed to the next station if the result of the previous station is "qualified"; if any station is "unqualified", the process will jump to the end point and mark it.

[0163] Furthermore, according to the orchestration strategy, SM9 two-way authentication is performed between MES and device A, device A and device B, device B and device C, and device C and MES, under the protection of a quantum-secure key. An SM4 session key, updated periodically every 24 hours, is then negotiated for subsequent communication. This process ensures that even in the presence of quantum computing threats, the initial trust establishment for communication between devices is absolutely secure.

[0164] S4. When a new product enters the production line and reaches the trigger sensor at the vision inspection station (equipment A), the sensor signal triggers equipment A to send a "ready" signal to the MES system. After verification by the MES, the A→B→C orchestration strategy is retrieved.

[0165] Furthermore, MES generates an orchestration instruction containing the complete quality inspection path, and uses the session key shared with device A and protected by quantum key distribution to encrypt it using the SM4 algorithm to obtain the ciphertext, which is then sent to device A.

[0166] S5. After decrypting the command, Device A performs visual inspection on the product. Device A updates the result status to "Visual Inspection Passed" or "Visual Inspection Failed", and then uses the session key to encrypt a command containing the "Passed" or "Failed" status and the corresponding subsequent process, and forwards it to Device B.

[0167] S6. If device B receives and decrypts device A's instruction as "qualified", then device B performs ultrasonic flaw detection. If device B receives and decrypts device A's instruction as "unqualified", then device B directly encrypts the instruction using the session key and sends it to device C.

[0168] Furthermore, when device B performs ultrasonic flaw detection, it will also update the item status accordingly and send the detected item status to device C using a session key.

[0169] S7. As the execution endpoint of the chain process, after receiving and decrypting the instruction sent by device B, device C first determines whether device A or device B has marked the item with a "non-conforming" label. If a non-conforming label exists, the defective product processing is triggered directly. If no non-conforming label exists, the weight detection function is executed, and the result of this detection determines whether to trigger the defective product processing.

[0170] Furthermore, device C returns a final quality inspection report to the MES, which is then archived by the MES. If the quality inspection report is "qualified," it contains the data results and inspection timestamps of the three devices, and the item is placed in the "qualified area." If it is "unqualified," it records the data results and inspection timestamps of the first "unqualified" item and all previous records, and the item is placed in the "defective area."

[0171] S8. If an error occurs during the chained process, such as device B failing to establish communication with device C after multiple retransmission attempts, device B will no longer rely on the cloud. Instead, it will activate a local fault tolerance strategy: immediately sending an encrypted error signal to device A and the local alarm system, and guiding the product to a "repair buffer." Simultaneously, it will report the error status to the MES via a backup communication path (such as through device A). The MES will then directly send instructions to device C and receive feedback, reverting to the traditional mode where the remaining devices are directly controlled by the cloud. This ensures that a single point of failure will not cause the entire system to block, demonstrating the high robustness of the decentralized architecture.

[0172] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0173] Reference Figure 6 The diagram illustrates a structural block diagram of a control device for a multi-IoT device chain provided in an embodiment of the present invention, which may specifically include the following modules: The IoT device authentication module 601 is used to perform authentication operations on multiple IoT devices, and to form a multi-IoT device chain using multiple certified IoT devices. User private key sending module 602 is used to determine the adjacent communication nodes of the multi-IoT device chain and send the user private key to one or more groups of target devices corresponding to the adjacent communication nodes. The two-way authentication operation module 603 is used to drive multiple target devices in the same group to perform two-way authentication operation of the SM9 identifier cryptography algorithm using the user's private key; The session key negotiation module 604 is used to control multiple target devices in the same group that have completed the two-way authentication operation of the identification cipher algorithm SM9, and to negotiate and generate a session key for the block cipher algorithm SM4 to realize communication between devices. The target task generation module 605 is used to determine the execution flow for the multi-IoT device chain and generate target tasks based on the execution flow; The target task execution module 606 is used to control the multi-IoT device chain to execute the target task through the SM4 block cipher session key.

[0174] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0175] In addition, embodiments of the present invention also provide an electronic device, such as... Figure 7 As shown, it includes a processor 701, a communication interface 702, a memory 703, and a communication bus 704, wherein the processor 701, the communication interface 702, and the memory 703 communicate with each other through the communication bus 704. Memory 703 is used to store computer programs; When the processor 701 executes the program stored in the memory 703, it implements any of the control methods for multiple IoT device chains described in the above embodiments: The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0176] The communication interface is used for communication between the aforementioned terminal and other devices.

[0177] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0178] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0179] like Figure 8 As shown, in another embodiment of the present invention, a computer-readable storage medium 801 is also provided, which stores instructions that, when executed on a computer, cause the computer to perform the control method for multiple IoT device chains described in the above embodiments.

[0180] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described control method embodiment for multiple IoT device chains, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0181] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0182] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0183] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0184] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A control method for multiple IoT device chains, characterized in that, The method is applied to a cloud server and includes: Perform authentication operations on multiple IoT devices, and use multiple certified IoT devices to form a multi-IoT device chain; Determine the adjacent communication nodes of the multi-IoT device chain, and send the user's private key to one or more groups of target devices corresponding to the adjacent communication nodes; The system enables multiple target devices in the same group to perform SM9 two-way authentication using the user's private key. Multiple target devices in the same group that have completed the two-way authentication operation of the SM9 identifier cryptography algorithm negotiate to generate a session key of the SM4 block cipher algorithm for realizing inter-device communication; Determine the execution flow for the multi-IoT device chain, and generate target tasks based on the execution flow; The chain of multiple IoT devices is controlled to perform the target task using the SM4 block cipher session key.

2. The method according to claim 1, characterized in that, The cloud server and the IoT devices are configured with corresponding quantum key management systems, and the step of performing authentication operations on multiple IoT devices includes: Upon receiving a first authentication request for an IoT device, a unique identifier is generated for the IoT device, and the unique identifier is sent to the IoT device. The IoT device is configured to, in response to obtaining the unique identity identifier, authenticate its identity with the quantum key management system to obtain a first quantum key and a session identifier; generate a quantum encryption registration request containing the first quantum key, the session identifier, and the unique identity identifier; and send the quantum encryption registration request to the cloud server. In response to receiving the quantum cryptography registration request, a session identifier is extracted from the quantum cryptography registration request; Based on the session identifier, a key acquisition request is initiated to the quantum key management system, and a second quantum key is returned by the quantum key management system; the first quantum key and the second quantum key are homologous symmetric keys; The first quantum key and the second quantum key are used to perform quantum decryption on the quantum encryption registration request to obtain the decrypted unique identity ID. In response to the verification of the legitimacy of the unique identity ID, the IoT device is identified as an authenticated device.

3. The method according to claim 2, characterized in that, The step of sending the user's private key to one or more groups of target devices corresponding to the adjacent communication node includes: Generate a user private key for the target device using the master private key; The user's private key is encrypted using the second quantum key to generate a private key encrypted message, and the private key encrypted message is sent to the target device; The target device is configured to receive the private key encrypted message, decrypt it using the pre-stored first quantum key, and obtain and store the user's private key.

4. The method according to claim 3, characterized in that, The group of multiple target devices includes an initiating device and a responding device. The steps for driving the multiple target devices in the same group to perform the SM9 two-way authentication operation using the user's private key include: The device initiating the challenge generates a first temporary random challenge number and calculates challenge parameters based on the first temporary random challenge number. The initiating device is controlled to encrypt its unique identifier using the first quantum key, and then encapsulate the encrypted unique identifier, the challenge parameter, and the session identifier into a second authentication request and send it to the responding device. The control unit requests a third quantum key, which is of the same origin as the first quantum key, from the quantum key management system based on the received session identifier. The responding device is controlled to decrypt the second authentication request using the third quantum key, obtain the unique identity identifier of the initiating device, and generate a second temporary random challenge number; The responding device is controlled to generate a second temporary random challenge number, and a first shared key is calculated based on the challenge parameters, the unique identifier of the initiating device, the second temporary random challenge number, and the pre-stored private key of the responding device user. The control unit calculates response parameters based on the second temporary random challenge number, and sends the unique identifier of the response unit encrypted with the third quantum key and the response parameters to the initiating unit. The initiating device is controlled to decrypt the unique identifier of the responding device using the first quantum key, and to calculate the corresponding second shared key using the response parameters, the unique identifier of the responding device, and its own initiating device user private key; Based on the first shared key and the second shared key, perform two-way authentication operation using the SM9 cryptographic algorithm for multiple target devices in the same group.

5. The method according to claim 4, characterized in that, The step of controlling multiple target devices in the same group that have completed the SM9 two-way authentication operation of the identifier cryptography algorithm to negotiate and generate an SM4 block cipher session key for inter-device communication includes: The initiating device is controlled to retrieve the first temporary random challenge number, the second temporary random challenge number, and the first shared key, and input the first temporary random challenge number, the second temporary random challenge number, and the first shared key into a preset key derivation function to calculate and generate the first block cipher algorithm SM4 session key; The control terminal device retrieves the first temporary random challenge number, the second temporary random challenge number, and the second shared key, and inputs the first temporary random challenge number, the second temporary random challenge number, and the second shared key into the key derivation function to calculate and generate the second block cipher algorithm SM4 session key; The initiating device is controlled to encrypt the first handshake confirmation message using the first block cipher algorithm SM4 session key, generate the first key verification ciphertext, and send the first key verification ciphertext to the responding device; The control terminal device decrypts the first key verification ciphertext using the locally generated second block cipher algorithm SM4 session key, and when it is determined that the first handshake confirmation message passes the verification, generates a second key verification ciphertext encrypted with the second block cipher algorithm SM4 session key, and returns the second key verification ciphertext to the initiating terminal device; The initiating device is controlled to decrypt the second key verification ciphertext using the first block cipher algorithm SM4 session key, obtain the decryption result, and store the first block cipher algorithm SM4 session key in response to the decryption result conforming to the preset verification logic.

6. The method according to claim 5, characterized in that, The step of controlling the multi-IoT device chain to execute the target task using the SM4 block cipher session key includes: The execution order and business logic of each IoT device are determined according to the execution process, and an orchestration instruction containing complete execution path information is generated based on the execution order and the business logic. The SM4 session key, a block cipher algorithm shared with the first target device in the multi-IoT device chain, is retrieved to encrypt the orchestration instructions, generate initial control ciphertext, and send it to the edge layer of the multi-IoT device chain. The first target device is configured to decrypt the initial control ciphertext using the SM4 session key pre-stored in the first target device, and execute the functional action corresponding to the orchestration instruction to generate a first node execution state containing the current action completion status; The first target device encapsulates the execution status of the first node and the remaining instruction information in the orchestration instructions into a first intermediate control instruction, and uses the SM4 session key shared with the next-hop target device to encrypt the first intermediate control instruction, and sends the encrypted first intermediate control instruction to the next-hop target device. The next-hop target device is configured to decrypt the first intermediate control command using the SM4 session key pre-stored in the next-hop target device, and execute the functional actions corresponding to the remaining command information.

7. The method according to claim 5, characterized in that, Also includes: When it is determined that the terminal target device has completed the terminal function, the control terminal target device summarizes the execution status information generated by each adjacent communication node, generates a full-process quality inspection report, and uses the SM4 session key shared with the cloud server to encrypt the full-process quality inspection report, and then reports the encrypted full-process quality inspection report to the cloud server.

8. A control device for a multi-IoT device chain, characterized in that, The method is applied to a cloud server and includes: The IoT device authentication module is used to perform authentication operations on multiple IoT devices, and multiple certified IoT devices are used to form a multi-IoT device chain; The user private key sending module is used to determine the adjacent communication nodes of the multi-IoT device chain and send the user private key to one or more groups of target devices corresponding to the adjacent communication nodes. The two-way authentication operation module is used to drive multiple target devices in the same group to perform two-way authentication operations using the user's private key and the SM9 identifier cryptography algorithm. The session key negotiation module is used to control multiple target devices in the same group that complete the two-way authentication operation of the SM9 identifier cryptography algorithm, and negotiate to generate a session key for the SM4 block cipher algorithm used to realize inter-device communication; The target task generation module is used to determine the execution flow for the multi-IoT device chain and generate target tasks based on the execution flow; The target task execution module is used to control the multi-IoT device chain to execute the target task through the SM4 block cipher session key.

9. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the method as described in claims 1-7.

10. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the method as described in claims 1-7.

Images