Data transmission method and device oriented to Internet of Things, electronic equipment and storage medium

Abstract

According to the data transmission method and device oriented to the Internet of Things, the electronic equipment and the storage medium, through a strict authentication mechanism of the data center module, it is ensured that only a user meeting an authorization strategy can access related data, and unauthorized access and data leakage are effectively prevented. Meanwhile, the core network module intelligently monitors and combines service themes, timely synchronization and updating of strategy information are ensured, management overhead brought to the core network due to increase of the number of the service themes is reduced, and an attacker is prevented from initiating unauthorized access to the data center module with the lagged strategy. Besides, in order to resist attackers from the intranet, communication between any two nodes is subjected to bidirectional identity authentication through a two-party authentication protocol between the intranet nodes, and communication content is encrypted by negotiating a session key, so that illegal access of unregistered nodes is effectively identified and prevented, and encryption protection in a data transmission process is also realized; and the confidentiality and integrity of the data are ensured. And the security of the data transmission process of the Internet of Things is obviously improved.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a data transmission method, device, electronic device and storage medium for the Internet of Things. Background Art

[0002] Mobile communication technology (such as B5G / 6G) has brought significant advantages to the development of the Internet of Things. Ultra-high bandwidth supports real-time transmission of large-scale data by IoT devices, and ultra-large connection capacity enables more devices to access the network at the same time, solving the problem of dense deployment of IoT devices. Large-scale terminal devices and sensors have strongly supported the implementation of application scenarios such as smart cities, smart transportation and smart agriculture through large amounts of data transmission. In order to effectively utilize the massive data generated by the Internet of Things, the construction of IoT data centers has become increasingly important. IoT data centers can integrate data from different terminal devices to achieve data standardization and centralized management. With the help of IoT data centers, trends can be predicted, potential problems can be identified, and reliable basis can be provided for intelligent decision-making, which helps to improve the efficiency and benefits of various application scenarios.

[0003] However, the complexity of application scenarios also brings more attack surfaces to malicious attackers. Therefore, how to effectively ensure the security of the data transmission process of the Internet of Things has become an urgent problem to be solved. Summary of the invention

[0004] In view of this, the purpose of this application is to propose a data transmission method, device, electronic device and storage medium for the Internet of Things to solve the above-mentioned technical problems.

[0005] Based on the above purpose, the first aspect of the present application provides a data transmission method for the Internet of Things, which is applied to a data transmission system for a physical network, wherein the system includes a core network module, multiple user devices, multiple data center modules, and multiple Internet of Things device groups corresponding to each data center module, and the method includes:

[0006] Any data center module in the data center modules is used as a target data center module, and the target data center module collects physical network data generated by the corresponding multiple Internet of Things device groups during operation;

[0007] A user equipment that initiates a service request among the multiple user equipments is used as a target user equipment, and the target user equipment sends a service request to the target data center module;

[0008] The target data center module receives authorization policy modification information for a service request of a user device, authenticates the authority of the target user device using the authorization policy modification information, and sends the Internet of Things data of the service subject corresponding to the service request to the target user device in response to the authority of the target user device satisfying the authorization policy modification information; or, in response to the authority of the target user device satisfying the authorization policy modification information, terminates sending the Internet of Things data of the service subject corresponding to the service request to the target user device;

[0009] During the authentication process, the core network module counts the total number of service topics carried by all servers corresponding to the target data center module within the core network module, and in response to the total number of service topics being greater than a preset total number threshold, uses a service topic merging algorithm to merge the service topics carried by the servers to obtain a merged service topic, stores a preset policy synchronization message in the merged service topic, and uses a message synchronization processing algorithm to synchronize the preset policy synchronization message stored in the merged service topic, so that each data center module can synchronize and store the corresponding authorization policy modification information;

[0010] During the authentication process, the target data center module uses the authentication root key generated in the registration phase to perform identity authentication on two transmission nodes that communicate with each other, and obtains an identity authentication result. In response to the identity authentication result that there is an unregistered node among the two transmission nodes, the module denies access to the unregistered node. Alternatively, in response to the identity authentication result that there is no unregistered node among the two transmission nodes, the module uses a certificateless identity-based encryption algorithm to perform session key negotiation on the two transmission nodes that communicate with each other, and obtains a negotiated session key, and uses the negotiated session key to encrypt the data transmission process between the two transmission nodes.

[0011] Based on the same inventive concept, the second aspect of the present application provides a data transmission device for the Internet of Things, the device is arranged in a data transmission system for the physical network, the system includes a core network module, multiple user equipment, multiple data center modules and multiple Internet of Things device groups corresponding to each data center module, the device includes:

[0012] A data center module is configured to use any data center module in the data center module as a target data center module, wherein the target data center module collects physical network data generated by the corresponding multiple Internet of Things device groups during operation; the target data center module receives authorization policy modification information for requesting services for user devices, uses the authorization policy modification information to authenticate the permissions of the target user device, and in response to the permissions of the target user device satisfying the authorization policy modification information, sends the Internet of Things data of the service subject corresponding to the service request to the target user device; or, in response to the permissions of the target user device satisfying the authorization policy modification information, terminates sending the Internet of Things data of the service subject corresponding to the service request to the target user device; the target data center module uses the authentication root key generated in the registration phase during the authentication process to authenticate the two transmission nodes that communicate with each other, obtains the authentication result, and in response to the authentication result that there is an unregistered node in the two transmission nodes, denies access to the unregistered node; or, in response to the authentication result that there is no unregistered node in the two transmission nodes, uses a certificateless identity-based encryption algorithm to negotiate session keys for the two transmission nodes that communicate with each other, obtains a negotiated session key, and uses the negotiated session key to encrypt the data transmission process between the two transmission nodes;

[0013] A user device is configured to use a user device that initiates a service request among the multiple user devices as a target user device, and the target user device sends a service request to the target data center module;

[0014] The core network module is configured to count the total number of service topics carried by all servers corresponding to the target data center module within the core network module during the authentication process, and in response to the total number of service topics being greater than a preset total number threshold, merge the service topics carried by the servers using a service topic merging algorithm to obtain a merged service topic, store a preset policy synchronization message in the merged service topic, and synchronize the preset policy synchronization message stored in the merged service topic using a message synchronization processing algorithm, so that each data center module can synchronize and store the corresponding authorization policy modification information.

[0015] Based on the same inventive concept, the third aspect of the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor implements the method described in the first aspect above when executing the computer program.

[0016] Based on the same inventive concept, the fourth aspect of the present application provides a non-transitory computer-readable storage medium, which stores computer instructions, and the computer instructions are used to enable a computer to execute the method described in the first aspect above.

[0017] From the above, it can be seen that the data transmission method, device, electronic device and storage medium for the Internet of Things provided by this application, through the strict authentication mechanism of the data center module, ensures that only users who meet the authorization policy can access the relevant data, effectively preventing unauthorized access and data leakage. At the same time, the core network module intelligently monitors and merges service topics, ensures the timely synchronization and update of policy information, and reduces the management overhead brought to the core network by the increase in the number of service topics, and prevents attackers from initiating unauthorized access to the data center module with lagging policies. In addition, in order to resist attackers from the intranet, a two-party authentication protocol between intranet nodes is used to perform two-way identity authentication on the communication between any two nodes and negotiate session keys to encrypt the communication content, which not only effectively identifies and prevents illegal access by unregistered nodes, but also realizes encryption protection of the data transmission process, ensuring the confidentiality and integrity of the data. The combined effect of this series of measures significantly improves the security of the Internet of Things data transmission process. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the technical solutions in the present application or related technologies, the drawings required for use in the embodiments or related technical descriptions are briefly introduced below. Obviously, the drawings described below are only embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0019] Figure 1 A schematic diagram of a network model of a physical network-oriented data transmission system according to an embodiment of the present application;

[0020] Figure 2 A schematic diagram of the architecture of the Smart Network Object Middleware (NOS) introduced and optimized in the data center of the embodiment of the present application;

[0021] Figure 3 This is a flow chart of a data transmission method for the Internet of Things according to an embodiment of the present application;

[0022] Figure 4 This is a schematic diagram of a broker cluster topic management model according to an embodiment of the present application;

[0023] Figure 5 A schematic diagram of a policy synchronization message according to an embodiment of the present application;

[0024] Figure 6 This is a schematic diagram of the system initialization phase of an embodiment of the present application;

[0025] Figure 7 This is a schematic diagram of the authentication key negotiation phase of an embodiment of the present application;

[0026] Figure 8 A schematic diagram of the node authentication and session key negotiation phase of an embodiment of the present application;

[0027] Fig. 9 This is a structural block diagram of a data transmission device for the Internet of Things according to an embodiment of the present application;

[0028] Fig.10 A schematic diagram of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0029] In order to make the objectives, technical solutions and advantages of the present application more clearly understood, the present application is further described in detail below in combination with specific embodiments and with reference to the accompanying drawings.

[0030] It should be noted that, unless otherwise defined, the technical terms or scientific terms used in the embodiments of the present application should be the usual meanings understood by people with ordinary skills in the field to which the present application belongs. The "first", "second" and similar words used in the embodiments of the present application do not represent any order, quantity or importance, but are only used to distinguish different components. "Including" or "comprising" and similar words mean that the elements or objects appearing in front of the word cover the elements or objects listed after the word and their equivalents, without excluding other elements or objects. "Connect" or "connected" and similar words are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. "Up", "down", "left", "right" and the like are only used to indicate relative positional relationships. When the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0031] It is understandable that before using the technical solutions of each embodiment of the present application, the type, scope of use, usage scenarios, etc. of the personal information involved will be informed to the user in an appropriate manner, and the user's authorization will be obtained.

[0032] For example, in response to receiving an active request from a user, a prompt message is sent to the user to clearly remind the user that the operation requested to be performed will require obtaining and using the user's personal information. Thus, the user can independently choose whether to provide personal information to the electronic device, application, server, storage medium or other software or hardware that performs the operation of the technical solution of the present application according to the prompt message.

[0033] As an optional but non-limiting implementation, in response to receiving the user's active request, the prompt information may be sent to the user in the form of a pop-up window, in which the prompt information may be presented in text form. In addition, the pop-up window may also carry a selection control for the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0034] It is understandable that the above notification and the process of obtaining user authorization are merely illustrative and do not constitute a limitation on the implementation method of this application. Other methods that meet relevant laws and regulations may also be applied to the implementation method of this application.

[0035] Mobile communication technology (such as B5G / 6G) has brought significant advantages to the development of the Internet of Things. Ultra-high bandwidth supports real-time transmission of large-scale data by IoT devices, and ultra-large connection capacity enables more devices to access the network at the same time, solving the problem of dense deployment of IoT devices. Large-scale terminal devices and sensors have strongly supported the implementation of application scenarios such as smart cities, smart transportation and smart agriculture through large amounts of data transmission. In order to effectively utilize the massive data generated by the Internet of Things, the construction of IoT data centers has become increasingly important. IoT data can integrate data from different terminal devices to achieve data standardization and centralized management. With the help of big data analysis, IoT data centers can predict trends, identify potential problems, provide a reliable basis for intelligent decision-making, and help improve the efficiency and benefits of various application scenarios. At the same time, the Internet of Things is also pushing data centers to the edge of the network. Traditional centralized data centers cannot withstand the traffic pressure brought by massive data from the Internet of Things, and users who are far away from the data center will also experience greater delays when using services. Therefore, future IoT data centers will tend to be distributed and distributed at different network edges.

[0036] However, the complexity of application scenarios also brings more attack surfaces to malicious attackers. First, attackers outside the data center domain will try to unauthorize and access data outside their authority when using data services. For this reason, the administrator of the corresponding IoT device group needs to configure authorization rules in the data center to prevent unauthorized access. When the administrator submits an authorization policy change to a data center close to his geographic location, if the changed authorization policy cannot be synchronized to the data center within the administrator's responsibility scope in a timely manner, the attacker may launch an unauthorized access to the data center with lagging rules. Therefore, it is necessary to design an efficient, flexible, and secure policy synchronization method between data centers. In the context of zero trust, attackers may also come from within the data center domain. Attackers will try to disguise themselves as legitimate nodes in the domain to launch active attacks on other nodes, or they can hide themselves and launch eavesdropping attacks on intranet traffic. In order to resist attackers from the intranet, continuous and efficient identity authentication of intranet nodes is an effective and cost-saving method.

[0037] In order to achieve efficient policy synchronization between data center domains, this application introduces and optimizes the Smart Network Object Middleware (NOS) architecture in the data center. NOS is designed to manage heterogeneous data sources and evaluate the security and quality level of information to meet user requirements, and provide lightweight security information exchange capabilities (this application focuses on the exchange of authorization policies). The security information exchange of NOS relies on the Message Queuing Telemetry Transport (MQTT) protocol, which adopts a "publish-subscribe" communication model. The client can publish messages to a "topic" as a "publisher" or subscribe to a topic as a "subscriber" to receive related messages. This model eliminates the need for clients to communicate directly with each other, but instead distributes messages through a central "broker". The broker can be deployed in the core network to provide information synchronization capabilities for data centers distributed in different geographical locations.

[0038] However, there is a problem of topic explosion in the traditional NOS architecture. A large number of IoT devices will generate a large number of topics. The exploded topics bring tremendous pressure to the topic management of the broker cluster. If the authorization policies of different organizations are transmitted on the same topic in order to reduce the number of topics, it will also bring privacy issues such as authorization policy leakage. In addition, the NOS architecture does not define the specific content of the control field in the authorization policy synchronization message, which reduces the flexibility of policy synchronization. For this reason, this application optimizes the authorization synchronization module of the NOS architecture and proposes a topic merging algorithm for brokers. Some topics in the broker cluster process a small amount of data and cannot effectively utilize the bandwidth and storage resources of the running host. When the number of topics is too large, the merging algorithm selects topics with low resource utilization and meet the remaining resource requirements for merging, thereby reducing the number of topics while improving the resource utilization of the host. In order to enhance privacy, this application also uses the kms service deployed in the core network and negotiates session keys to encrypt policy synchronization messages, so that messages transmitted on the same topic will not leak privacy information. In addition, this application embeds information such as timestamp, priority, and effective time in the authorization rule change message to ensure that each NOS can check whether users who use the service during the rule change message propagation time still comply with the authorization rules, and also brings more flexibility to the system of different NOS rules.

[0039] In order to efficiently authenticate nodes within the data center, this application designs a two-party authentication protocol between intranet nodes based on the Certificateless Identity based Encryption (CL-ABE) algorithm to perform two-way identity authentication on the communication between any two nodes and negotiate the session key to encrypt the communication content. Unlike the traditional identity-based encryption technology (IBE) that requires a completely trusted key generation center (KGC), the KGC of this application only generates partial keys for each node, and the keys actually used are generated by the nodes themselves. KGC cannot deduce the complete key actually generated by the user from the partial keys. This makes it impossible for the attacker to know the secret private key used by the user even if the KGC is invaded, ensuring that the attacker cannot crack the key negotiated between nodes through active attacks or obtain valid information from the data leakage of KGC. In addition, this solution separates the authentication key and the session key negotiation private key between the two nodes. The authentication root key between the two nodes is a symmetric key negotiated between each other during the registration phase and is not stored in the KGC. This not only reduces the risk of KGC being invaded and leaking the authentication key, but also reduces the computational overhead of the authentication protocol by using symmetric keys. The session key used between nodes is negotiated by an additional CL-ABE private key. The key isolation of negotiation and authentication can enhance the anti-leakage and adaptability of the protocol. In addition, by setting different security contexts for each NOS domain, the cost of attacking different NOS domains is increased.

[0040] For example, the network isolation and cross-network communication method based on cloud-edge architecture in the related technology includes the following steps: building a message pipeline; edge gateway receiving information; data pushing to the intranet. With the computing and storage capabilities of the edge gateway, a software system architecture for cloud-edge architecture is provided to solve the problems of network isolation and cross-network communication. It can realize data ferrying and data synchronization between the external network and the intranet at the application layer, while ensuring the security isolation of the private network and the intranet; the software system operates the message queue to realize data queuing, storage and push; the data message format is filtered to prevent Transmission Control Protocol (TCP) network attacks to ensure network security; in addition, it supports users to configure the rule engine to realize the private network push of filtered information, thereby improving the data hierarchical governance capabilities of the cloud-edge collaborative architecture. However, the architecture proposed by the related technology does not consider the security authentication problem of the intranet nor the synchronization of security policies of different intranet domains.

[0041] A method for implementing a decentralized network control strategy based on zero trust is also proposed in the related technology. The access control strategy is generated by the management and control platform through calculation and pushed to the cloud controller. After the terminal application (Application, APP) passes the authentication, the corresponding access control strategy is pulled according to the relevant conditions, and finally the back-end business resources are accessed through the access gateway. The request initiated by the access subject is matched with the strategy locally. If the release strategy is hit, the requested data packet is sent, otherwise it is intercepted; and the access object only needs to do a small amount of centralized strategy matching, which can reduce the access pressure and avoid malicious access requests such as distributed denial of service (DDoS); thus solving the problems caused by the current centralized network control. However, the policy synchronization of this method needs to be pulled from the central server, which is less real-time, flexible and efficient than the synchronization using the MQTT protocol.

[0042] In the distributed IoT data center architecture of the existing solutions, there are problems with the authorization policy synchronization method, such as low efficiency, poor privacy, and lack of flexibility. First of all, some existing solutions use the method of distributed nodes pulling authorization policies from the central server to achieve synchronization of authorization policies. The poor real-time performance of this method will also bring great pressure to the central server, which does not meet the original intention of edge computing. Although the existing NOS architecture uses the MQTT protocol to achieve real-time synchronization of policies between nodes, there is also the problem of topic explosion managed by all broker clusters, which may cause low resource utilization of broker clusters and excessive topic management overhead, and may also leak authorization policy privacy information that does not belong to its own jurisdiction. In addition, the existing solutions do not define the specific control flow and algorithm of policy synchronization information, which reduces the flexibility of policy synchronization.

[0043] In addition, the architecture of the existing scheme lacks a domain security authentication mechanism. Once an attacker invades the domain, it will cause a great degree of damage to the intranet. Existing security strategies such as Hypertext Transfer Protocol Secure (HTTPS) based on public key certificates are not suitable in the intranet environment. The overhead of issuing certificates and certificate management in the private network environment is relatively large. Some existing authentication schemes use identity-based encryption as the cryptographic basis of the system. Such schemes require the deployment of a trusted security center in the intranet to generate keys. The key center can master the secret private keys of all nodes. Once the key table is leaked, it will cause great losses.

[0044] This application optimizes the existing NOS architecture, refines the responsibility boundaries within the Internet of Things (IoT) data center, and provides an authorization strategy for synchronizing user access to data services between different data centers. In addition, this application proposes a topic merging algorithm to optimize the number of topics while improving resource utilization, and defines the control field of the authorization policy synchronization message and encrypts the privacy information of the synchronization message, ensuring the flexibility, privacy, and efficiency of the authorization policy synchronization control. In addition, this application also designs a two-party authentication protocol between intranet nodes based on a certificateless attribute-based key negotiation algorithm. The protocol is not based on the assumption that the key management center is completely secure, and can ensure the injective consistency, confidentiality, and forward security of the session key between the two parties to the authentication when the key center leaks security information.

[0045] The present application relates to the design of an inter-node identity authentication protocol within a network domain of an Internet of Things (IoT) data center, and the study of a method for synchronizing user authorization policies between data center domains distributed in different geographical locations. The purpose of the present application is to perform efficient and continuous two-way identity authentication on nodes that communicate with each other in the intranet of an IoT data center to resist malicious attackers that may come from the intranet in a zero-trust context. Another purpose of the present application is to enable system administrators to efficiently submit policy modifications in a data center close to them, and to synchronize policy modifications to other data centers efficiently, flexibly, and securely, to prevent attackers from initiating unauthorized access to data centers with lagging policies. The advantage of the present application is that the authentication protocol is designed based on a certificateless key negotiation algorithm under an elliptic curve, so that the protocol can resist security issues caused by leakage of key tables in traditional key management centers. Another advantage of the present application is that the existing network intelligent object middleware system for policy synchronization is optimized and the policy synchronization message control flow and corresponding control algorithm are defined, thereby realizing efficient and flexible authorization policy synchronization between different data centers.

[0046] The embodiment of the present application provides a data transmission method for the Internet of Things, which is applied to a data transmission system for a physical network. The system includes a core network module, multiple user devices, multiple data center modules, and multiple Internet of Things device groups corresponding to each data center module. The network model of the present application is as follows: Figure 1As shown. The network involves five entities: data source (i.e. IoT device group), device group administrator, data center (i.e. data center module), core network (i.e. core network module), and data user (i.e. user device). The data source IoT group is composed of IoT devices from different organizations, and IoT devices from different organizations are identified by different device groups. Device groups belonging to the same organization may run in IoT groups located in different geographical locations, and the data generated has the same data access policy in the data center (special device groups may have customized policies). The device group administrator of a certain organization will submit the modification of the authorization policy to the data center close to its geographical location. The authorization policy needs to be synchronized to the data center that governs the IoT device data of the organization in a timely manner, and the data termination of the IoT device data that does not manage the organization remains invisible. The data center collects the data generated by the operation of the IoT group it manages and stores it in the database, and then analyzes the runtime data with the help of AI or big data analysis methods and provides data services to users who use the data. When a user uses the runtime data generated by a device group, it will be authenticated according to the authorization policy specified by the device group administrator. The core network is a public service center responsible for running the broker cluster required for the MQTT protocol and for providing the data center with a service for managing encryption keys (Key Management Service, kms).

[0047] This application considers attackers from outside and inside the domain. Attackers from outside the domain will have certain legitimate user permissions to request data services, but will maliciously request data beyond their authority. The device group administrator submits authorization policy modifications in a data center close to its geographic location. If the authorization policy cannot be synchronized to other data centers that govern the organization's devices in a timely manner, the attacker may initiate malicious requests to the data center that lags behind the policy. Therefore, an efficient and flexible authorization policy synchronization mechanism is required between data centers. In addition, for privacy reasons, the data center should not perceive policy change messages for device groups that are not under its jurisdiction to prevent the leakage of authorization policies. In the context of "zero trust", attackers may also come from the intranet. Attackers may disguise themselves as legitimate nodes in the intranet to launch active attacks on the network, or they may eavesdrop on intranet data to infringe on the privacy information of the intranet. In order to prevent active attacks by attackers, strict identity verification of communication nodes is required to prevent access by unregistered users. In order to defend against passive attacks by attackers, it is now necessary to negotiate session keys for communication between intranet nodes to encrypt the communication content.

[0048] like Figure 2As shown, the data center of the present application introduces the Smart Network Object Middleware (NOS) architecture to optimize the authorization policy synchronization process of the data center. NOS is designed to manage heterogeneous data sources and evaluate the security and quality level of information to meet user requirements, and provide lightweight security information exchange capabilities (this application focuses on the exchange of authorization policies). There will be IoT devices from multiple organizations in a data source, and the devices of each organization are identified by a device group, and each device group has a corresponding administrator. NOS collects the runtime data generated by IoT devices through the southbound interface and stores it in the original data database. The original data is stored as standardized data after background standardization. During this process, the data parsing unit will analyze the security and quality of the data. If the data does not meet the standards, it will be discarded. The device group administrator configures the data source information and the authorization rules for data access through the southbound interface, and the authorization rules are stored in the authorization library. The user subscribes to the processed data as a client of the MQTT protocol. MQTT adopts the "publish-subscribe" communication model. The client can publish messages to a "topic" as a "publisher" or subscribe to a topic as a "subscriber" to receive related messages. Different NOSs synchronize authorization policies through the southbound interface, which also uses the MQTT protocol. After the device group administrator modifies the policy, the modified content will be synchronized to the policy synchronization topic corresponding to the device group through the southbound interface.

[0049] NOS clarifies the responsibility boundaries between various functional nodes within the data center, and can perform real-time or offline analysis of the data generated by IoT devices to filter out data that does not meet quality requirements or poses security risks. NOS also provides system administrators with a rich management interface so that administrators can easily control the configuration information within the data center. NOS also provides a northbound MQTT interface for data transmission with NOSs distributed in different geographical locations, allowing efficient information synchronization between different NOSs.

[0050] However, the original NOS architecture does not define the security policy for communication between nodes in the domain. Attackers from within the domain can disguise themselves as legitimate nodes to launch malicious attacks. In this regard, the present invention has made further optimizations based on the original NOS architecture. This application introduces a key management unit in the domain. The key management unit is responsible for generating security parameters for the security domain, and is responsible for generating pre-keys for identity-based private keys for nodes in the domain, and also serves as an intermediary for authentication key negotiation between nodes. After obtaining the key through the key management unit, the nodes can implement two-way authentication and negotiate session keys to encrypt the session content. The specific authentication protocol is given in detail later.

[0051] In addition, in the original NOS architecture, the topic granularity of authorization policy synchronization between NOS nodes is not clear enough. Policy change messages of multiple device groups may be transmitted unencrypted on a topic, which not only makes NOS need to process change messages that do not belong to itself, reducing efficiency, but also may make NOS perceive policy change messages that do not belong to its own jurisdiction, causing privacy leakage. Ideally, each device group should have its own policy synchronization topic to ensure that NOS only needs to subscribe to the topic of the device group within its own jurisdiction, and the authorization policy will not be leaked. However, in the massive Internet of Things scenario, there may be a large number of Internet of Things device groups. If a separate topic is assigned to each device group, the number of topics will explode, which will bring huge topic management pressure to the broker cluster of the core network. Therefore, the present invention optimizes the topic subscription strategy of the NOS architecture, assigns a separate topic to each device group when the total number of topics is small, and when the number of topics exceeds the threshold, the broker cluster runs a topic merging algorithm to merge topics based on resource consumption to reduce the number of topics and improve the resource utilization of the broker cluster. This application also generates a session key based on the kms service provided by the core network to encrypt the policy synchronization messages of several device groups that share the same topic after being merged, so that the NOS architecture can only discard the policy synchronization messages received from device groups that do not belong to its jurisdiction and cannot perceive their content.

[0052] like Figure 3 As shown, the method of this embodiment includes:

[0053] Step 301: any data center module in the data center modules is used as a target data center module, and the target data center module collects physical network data generated by the corresponding multiple Internet of Things device groups during operation.

[0054] In this step, the data center module refers to the system or component responsible for data storage, processing or forwarding. The data center module is usually deployed in a large data center to support the data needs of various applications and services.

[0055] IoT device groups are those devices that can connect to the Internet and exchange data with other devices or systems. The IoT device group mentioned here may refer to a group of IoT devices that are related to each other or perform similar functions. For example, an IoT device group may include multiple temperature sensors used to monitor the temperature of a specific area.

[0056] IoT devices will continuously generate data during operation, that is, IoT data generated during operation, which reflects the status of the device, environmental parameters, user behavior and other information. The corresponding data center module is responsible for collecting the data generated by the IoT device group. This process is usually used for data collection, monitoring, analysis or further data processing.

[0057] Step 302: The user equipment that initiates the service request among the multiple user equipments is taken as the target user equipment, and the target user equipment sends the service request to the target data center module.

[0058] In this step, user devices refer to multiple devices connected to the network, which may be smartphones, computers, tablets or other terminal devices that can access the network. These devices are used by different users to initiate various service requests.

[0059] A service request can be accessing a website, downloading data, performing online transactions, or any other operation that requires a server response.

[0060] The user device that initiates the service request is specially identified as the target user device. In the subsequent processing flow, the system will pay special attention to this device because it is the object that needs to be served.

[0061] A target data center module is a component of a server or server cluster that is responsible for processing a specific service request. In a distributed system, different data center modules may be responsible for processing requests from different jurisdictions or providing different services. The target data center module is determined based on the request type of the target user device or the location of the target resource.

[0062] Once the target user device and target data center module are determined, the target user device will send a specific service request to the target data center module. This request contains all the necessary information to perform the required service, such as request type, user authentication information, requested resource location, etc.

[0063] Step 303, the target data center module receives the authorization policy modification information for the service request of the user device, uses the authorization policy modification information to authenticate the authority of the target user device, and in response to the authority of the target user device satisfying the authorization policy modification information, sends the Internet of Things data of the service subject corresponding to the service request to the target user device; or, in response to the authority of the target user device satisfying the authorization policy modification information, stops sending the Internet of Things data of the service subject corresponding to the service request to the target user device.

[0064] In this step, the target data center module receives authorization policy modification information about the service requested by the user device. This information may include the upgrade or downgrade of user permissions or the granting / revocation of specific permissions, etc., aiming to adjust the user device's access permissions to specific IoT data.

[0065] Using the received authorization policy modification information, the target data center module authenticates the target user device's permissions. This process involves verifying whether the user device currently has the data permissions required to access the requested service.

[0066] If the permissions of the target user device meet the requirements in the authorization policy modification information, that is, the user device is authorized to access the IoT data of the requested service subject, then the target data center module will send the IoT data corresponding to the service request to the target user device.

[0067] On the contrary, if the permissions of the target user device still do not meet the data requirements of the access request service despite the modification of the authorization policy (for example, the permissions are revoked or downgraded), the target data center module will terminate sending the relevant IoT data to the user device.

[0068] This process reflects the importance of data security and access control, ensuring that only properly authorized devices can access specific IoT data, thereby protecting the confidentiality and integrity of the data. By dynamically adjusting the authorization strategy, the system can flexibly adapt to different security requirements and usage scenarios.

[0069] Step 304: During the authentication process, the core network module counts the total number of service topics carried by all servers corresponding to the target data center module within the core network module. In response to the total number of service topics being greater than a preset total number threshold, the service topics carried by the servers are merged using a service topic merging algorithm to obtain a merged service topic, and the preset policy synchronization message is stored in the merged service topic. The preset policy synchronization message stored in the merged service topic is synchronized using a message synchronization processing algorithm, so that each data center module can synchronously store the corresponding authorization policy modification information.

[0070] In this step, during the authentication process, the core network module counts the total number of service topics carried on all servers associated with the target data center module. The service topics here can be understood as different services or applications running on the server, and each service or application has a corresponding topic.

[0071] Next, the core network module checks whether the total number exceeds the preset total number threshold. This threshold is a pre-set standard used to determine whether service topics need to be merged to reduce the number or optimize resource usage.

[0072] If the total number of service topics exceeds the threshold, the core network module will trigger the merging process of the service topics.

[0073] Using the service theme merging algorithm, the core network module will merge these service themes. The specific way of merging may involve integrating service themes with similar or related functions to reduce the overall number or optimize the service structure. It can also be merged based on load conditions.

[0074] After the merging process, merged service themes will be obtained, the number of these service themes will be less than before the merger, or the structure will be more optimized.

[0075] In the merged service topic, the core network module will store preset policy synchronization messages. These messages may contain information about authorization policy modifications to ensure that each data center module can synchronously update its authorization policy.

[0076] Finally, the core network module will use the message synchronization algorithm to synchronize the preset policy synchronization messages stored in the merged service topic. The purpose of this step is to ensure that these policy synchronization messages can be effectively distributed to each data center module so that they can synchronously store and update the corresponding authorization policy modification information.

[0077] In summary, this process involves counting and merging service topics (if there are too many) during the authentication process of the core network module, and storing and synchronizing policy modification information in the merged service topics to ensure that each data center module can synchronously update its authorization policy, ensure timely synchronization and update of policy information, and prevent attackers from launching unauthorized access to data center modules with lagging policies. This process helps optimize resource usage and improve the overall efficiency of the system.

[0078] Step 305: During the authentication process, the target data center module uses the authentication root key generated during the registration phase to perform identity authentication on the two transmission nodes that communicate with each other, and obtains an identity authentication result. In response to the identity authentication result that there is an unregistered node among the two transmission nodes, the module denies access to the unregistered node. Alternatively, in response to the identity authentication result that there is no unregistered node among the two transmission nodes, the module uses a certificateless identity-based encryption algorithm to perform session key negotiation on the two transmission nodes that communicate with each other, and obtains a negotiated session key, and uses the negotiated session key to encrypt the data transmission process between the two transmission nodes.

[0079] In this step, it is confirmed whether the two transmission nodes (which can be regarded as the data sender and receiver) that communicate with each other are both registered and legal nodes.

[0080] The authentication root key pair generated during the registration phase is used for identity authentication. The authentication root key pair here may refer to an asymmetric key pair (such as a public key and a private key), where the private key is held by the node and the public key is recorded or verified by the data center module during registration.

[0081] If the identity authentication result shows that there is an unregistered node among the two transmission nodes (i.e., a node whose identity cannot be verified through the authentication root key pair), the access request of the unregistered node is rejected to prevent unauthorized nodes from accessing the system.

[0082] If both transmission nodes pass the identity authentication (ie, both are registered legal nodes), the next step of session key negotiation is carried out.

[0083] The purpose of the session key negotiation phase is to generate a temporary, session-level key for two legitimate nodes communicating with each other, which is used to encrypt data transmission between them and ensure the security of data transmission.

[0084] The session key negotiation is performed using the Certificateless Identity-based Encryption (CL-ABE) algorithm. IBE is a public key encryption algorithm that can directly use the user's identity information (such as email address, user name, etc.) as the public key without the need to bind the public key and identity information through a certificate. This mechanism simplifies key management and avoids the complexity of certificate issuance and management.

[0085] Through the certificateless identity-based encryption algorithm, two legitimate nodes can negotiate a common session key (negotiated session key). This key is temporary and only valid in this session, which enhances the security of data transmission.

[0086] The data transmission process between the two transmission nodes is encrypted using the negotiated session key. In this way, even if the data is intercepted during transmission, the attacker cannot decrypt the data content because the session key is unknown and is only valid for this session.

[0087] The target data center module ensures that only registered legitimate nodes can access the system through two steps of identity authentication and session key negotiation, and uses a secure encryption mechanism during the data transmission between them, thereby effectively protecting the confidentiality and integrity of the data.

[0088] In summary, the two-party authentication protocol between intranet nodes is used to perform two-way identity authentication on the communication between any two nodes and negotiate the session key to encrypt the communication content. This not only effectively identifies and prevents illegal access by unregistered nodes, but also implements encryption protection during the data transmission process, ensuring the confidentiality and integrity of the data. This series of measures work together to significantly improve the security of the IoT data transmission process.

[0089] Through the above scheme, the strict authentication mechanism of the data center module ensures that only users who meet the authorization policy can access the relevant data, effectively preventing unauthorized access and data leakage. At the same time, the core network module intelligently monitors and merges service topics to ensure the timely synchronization and update of policy information, and reduces the management overhead brought to the core network by the increase in the number of service topics, preventing attackers from launching unauthorized access to the data center module with lagging policies. In addition, in order to resist attackers from the intranet, the two-party authentication protocol between the intranet nodes is used to perform two-way identity authentication on the communication between any two nodes and negotiate the session key to encrypt the communication content. It not only effectively identifies and prevents illegal access by unregistered nodes, but also realizes encryption protection of the data transmission process, ensuring the confidentiality and integrity of the data. Under the joint action of this series of measures, the security of the data transmission process of the Internet of Things has been significantly improved.

[0090] In some embodiments, in step 304, the merging of the service themes carried by the server using a service theme merging algorithm to obtain a merged service theme includes:

[0091] Step A1: the core network module divides all servers into association groups according to a preset number of servers to obtain multiple association groups.

[0092] In step A2, the core network module determines the number of IoT device groups currently accommodated by the server corresponding to each association group, and selects a target association group from each association group whose number of IoT device groups currently accommodated is greater than the maximum number of IoT device groups allowed to be transmitted simultaneously.

[0093] Step A3: the core network module determines the idleness index of each other association group except the target association group in each association group.

[0094] Step A4: the core network module searches for a plurality of target other association groups whose idleness indexes are greater than a preset migration threshold from among the idleness indexes of the other association groups.

[0095] Step A5, the core network module determines the final target other association group from multiple target other association groups, whose idleness index is the largest and whose total load of all corresponding servers is greater than or equal to the total load of the target association group, and merges the service topics carried by the servers corresponding to the target association group into the service topics carried by the servers corresponding to the final target other association group to obtain a merged service topic.

[0096] In the above scheme, the core network module divides all servers into multiple association groups according to the preset number of servers. Each association group contains a certain number of servers, which will process the connection and data transmission of IoT devices as a whole in the subsequent steps.

[0097] Next, the core network module checks the number of IoT device groups that are currently connected in each association group.

[0098] If the number of IoT device groups in a certain association group exceeds the maximum number of IoT device groups allowed to transmit simultaneously in the association group, then this association group is considered a target association group. This means that these target association groups may be currently overloaded or close to overloaded, and measures need to be taken to reduce their load.

[0099] For other association groups that are not the target association group, the core network module calculates their idleness index. The idleness index is an indicator to measure the current remaining processing capacity of the association group, which may be calculated based on multiple factors such as the server's central processing unit (CPU) usage, memory usage, network bandwidth, etc.

[0100] After calculating the idleness indexes of all other association groups, the core network module will select those association groups whose idleness indexes are greater than the preset migration threshold as target other association groups. These target other association groups have sufficient processing capacity to accommodate IoT devices or services migrated from the target association group.

[0101] Among the multiple target other association groups, the core network module will further select the association group with the largest idleness index and the total load of all its servers greater than or equal to the total load of the target association group as the final target other association group.

[0102] Once the final target other association group is determined, the core network module will merge the service topics (which may refer to the data transmission tasks or service applications of IoT devices) carried by the servers in the target association group to the servers corresponding to the final target other association group. In this way, the load of the originally overloaded target association group is dispersed to the final target other association group with higher processing power.

[0103] After the above migration process, the core network module will obtain an updated service topic distribution, in which the service topics originally carried by the target association group are now carried by other association groups of the final target, thereby achieving load balancing and service quality optimization.

[0104] In general, this process ensures efficient data transmission and service continuity of IoT devices by dynamically adjusting the allocation of server resources.

[0105] For example, NOSs in different regions synchronize authorization policies through the MQTT protocol. When the total number of topics does not exceed the threshold, each device group has its own independent topic for policy synchronization, and there is no privacy leakage problem at this time. When the total number of topics exceeds the threshold, the broker cluster merges topics according to the cluster resource usage. After the merger, multiple device groups share a topic. Each device group needs to use the kms service provided by the core network to obtain the root key and generate a session key to encrypt its own policy synchronization information to ensure the privacy of the message.

[0106] First, we introduce the topic management strategy and topic merging algorithm of the core network broker cluster. Figure 4 As shown, it is the broker cluster management model proposed by the present invention. The upper limit of topics that a broker cluster can manage is set to T, which is limited by the physical resources of the broker cluster. In addition, in order to prevent the server where a certain topic is located from failing, the cluster needs to store an additional copy for each topic, and the number of copies of each topic is R. Each association group consists of R servers, and the primary partition of each topic (yellow mark in the figure) is deployed on one of the servers in the association group, and the copy (green mark in the figure) is deployed on the remaining R-1 servers. The design of the association group makes it possible for the remaining copy partitions to be on the same machine when the primary partitions of several topics on a server are merged, thereby reducing the cross-machine synchronization and merging of topics to improve efficiency. When adding a new topic, it will be dynamically allocated according to the load of each association group and the machine in the association group, so that the topic is distributed to each machine as evenly as possible. When the number of topics reaches the upper limit, the broker cluster will use the topic merging algorithm to merge. The merging algorithm gives priority to merging topics within this association group. If the load of this association group is small and the resource utilization is low, the topic merging across association groups will be performed. The specific parameters and processes are shown below.

[0107] 1) Server related:

[0108] S i : The i-th server.

[0109] ServerS i The maximum load bearing capacity (resource-limited bandwidth and storage resources).

[0110] ServerS i The current total load.

[0111] α: Server load safety factor, that is, the ratio of the load that the server is allowed to bear to the maximum load. This parameter reserves a certain amount of resources for the server to cope with sudden traffic, α∈(0,1).

[0112] 2) Related topics:

[0113] T k : The k-th topic.

[0114] topicT k Load of the primary partition.

[0115] topicT k The load of the replica.

[0116] topicT k The maximum number of device groups allowed to transmit simultaneously, and the upper limit of the merged topics after merging multiple device groups, to prevent a topic from being over-merged.

[0117] P k :topicT k The current number of device groups accommodated.

[0118] T: The maximum number of topics that the broker cluster can carry.

[0119] λ: Reduction factor of replica load (usually λ∈(0, 1)). The load consumption of the primary partition of the topic is greater than that of the replica, because the replica only needs to synchronize the messages of the primary partition and does not need to provide services. Therefore, a load factor needs to be multiplied when calculating the load of the replica.

[0120] 3) Server load calculation:

[0121] Each server load is the sum of the loads of its assigned primary and replica partitions:

[0122]

[0123] in, and The server S i The primary partition and replica set on the .

[0124] 4) Total load of associated group:

[0125] G n : The nth association group.

[0126] The total load of all servers in the association group is:

[0127] Association group idleness index:

[0128]

[0129] Migration threshold. If the idleness is higher than the migration threshold, it means that the resources of the association group are very small and can be migrated to other association groups to save resources.

[0130] The topic merging algorithm is shown in Table 1 below:

[0131] Table 1

[0132]

[0133]

[0134] In some embodiments, in step 304, determining the idleness index of other association groups in each association group except the target association group includes:

[0135] Step B1, the core network module determines the current total load of each server corresponding to other association groups except the target association group in each association group, and the maximum bearing load of the corresponding server.

[0136] Step B2: The core network module determines the idleness index of other association groups in each association group except the target association group based on the current total load of each server and the maximum load of the corresponding server by the following formula:

[0137]

[0138] in, represents the idleness index, represents the current total load of the i-th server, Indicates the maximum load of the i-th server.

[0139] In the above scheme, the core network module determines the current total load of the servers in all association groups except the target association group (i.e., the current total load of the i-th server). The total load refers to the total amount of tasks or data currently being processed by the server, which reflects the current working intensity of the server.

[0140] At the same time, the core network module will also determine the maximum load of these servers (the maximum load of the i-th server). The maximum load refers to the maximum task or total amount of data that the server can handle without being damaged or seriously degraded in performance.

[0141] With the above information, the core network module uses a formula to calculate the idleness index (idleness index) of each association group. This index is a dimensionless value used to quantify the idleness of the server.

[0142] The idleness index in the formula is calculated based on the current total load and the maximum load of each server. The idleness index reflects the utilization rate of the server.

[0143] The purpose of calculating the idleness index is to understand the usage of servers in each association group so that more reasonable resource allocation decisions can be made. For example, in a load balancing scenario, new tasks or data can be assigned to the idlest server based on the idleness index to improve resource utilization and overall system performance.

[0144] In summary, this description provides a method for calculating the server idleness index in the core network module. The method evaluates the idleness of the server by comparing the current total load and the maximum load of the server, thereby providing an important basis for subsequent resource allocation or network optimization.

[0145] In some embodiments, in step B1, determining the current total load of each server corresponding to other association groups in each association group except the target association group includes:

[0146] Step C1, the core network module performs the following operations on each of the association groups except the target association group:

[0147] Step C11, the core network module obtains the load of the primary partition of the service theme corresponding to each server in other associated groups, and the load of the replica of the corresponding service theme.

[0148] Step C12, the core network module uses the load of the primary partition of the service theme corresponding to each server in other association groups and the load of the replica of the corresponding service theme to determine the current total load of each server corresponding to other association groups except the target association group in each association group through the following formula:

[0149]

[0150] in, represents the current total load of the i-th server, represents the load of the primary partition of the k-th service topic, represents the load of the replica of the kth service topic, λ represents the reduction factor of the replica load, λ∈(0,1), T k represents the kth service topic, represents the set of primary partitions on the i-th server, Represents the set of replicas on the i-th server.

[0151] In the above scheme, for each server in the other association group, the core network module obtains two main load information:

[0152] Load of the primary partition of the service topic: This is the load of the service topic running as the primary partition on the server. The primary partition is usually responsible for handling read and write requests for data.

[0153] Load of replicas of service topics: This is the load of service topics running as replicas on the server. Replicas are usually used for redundant storage of data and possible read request processing to support high availability and fault tolerance of data.

[0154] The core network module uses the load information obtained above to calculate the current total load of each server through a specific formula. This formula takes into account the load of the primary partition and the load of the replica, but the load of the replica is adjusted by a reduction factor (denoted as λ) when calculating the total load. The reduction factor λ may be used to reflect the lower participation or efficiency of the replica in handling the load relative to the primary partition.

[0155] Through this calculation method, the core network module can evaluate the load of the servers in each associated group, which is crucial for decisions such as load balancing, resource allocation, and fault recovery. Especially in distributed systems or cloud computing environments, understanding the current load of each server helps optimize performance, improve resource utilization, and ensure service availability.

[0156] In some embodiments, in step 304, the preset policy synchronization message is stored in the merged service theme, and the preset policy synchronization message stored in the merged service theme is synchronized by using a message synchronization processing algorithm so that each data center module can synchronize and store the corresponding authorization policy modification information, including:

[0157] Step D1, the core network module uses the session key generated by the key generation algorithm to encrypt other fields in the preset policy synchronization message except the random number generated when each message is sent and the identifier of the Internet of Things device group to obtain encrypted other fields, wherein the other fields include at least the identifier of the data center module initiating synchronization, the list of data center modules that need to be synchronized, and the type of authorization policy change.

[0158] In step D2, the core network module determines whether the identifier of the data center module that initiates the synchronization exists in the list of data center modules that need to be synchronized. In response to determining that it exists, the authorization policy change type corresponding to the identifier of the data center module that initiates the synchronization is transmitted to the corresponding data center module, so that the corresponding data center module can update the initial authorization policy according to the authorization policy change type, generate corresponding authorization policy modification information and synchronize and store it.

[0159] In the above scheme, the core network module uses a key generation algorithm to generate a session key. This session key is used to ensure the security of communication.

[0160] Using this session key, the core network module encrypts certain fields in the preset policy synchronization message. These encrypted fields exclude the random number generated when each message is sent and the identifier of the IoT device group.

[0161] Identification of the data center module that initiated the synchronization: This identifies which data center module requested the policy synchronization.

[0162] List of data center modules that need to be synchronized: This lists which data center modules need to receive updated authorization policies.

[0163] Authorization policy change type: This describes what type of change has occurred in the authorization policy, such as whether it is adding permissions, modifying permissions, or deleting permissions.

[0164] After encrypting and preparing the policy synchronization message, the core network module checks whether the list of data center modules that need to be synchronized contains the identifier of the data center module that initiates the synchronization.

[0165] If the list does contain the identifier of the data center module that initiated the synchronization (which means that the module that initiated the synchronization also expects to receive updated policies), the core network module transmits the authorization policy change type corresponding to the module identifier to the data center module.

[0166] The data center module that receives the authorization policy change type updates its initial authorization policy according to the change type.

[0167] The updated authorization policy is converted into authorization policy modification information and stored synchronously in the data center module. This means that the updated policy information is safely stored in the module for subsequent use or further synchronization.

[0168] The entire process ensures the secure transmission and synchronization of authorization policy changes, prevents data leakage through encrypted communication, and ensures that only the correct modules receive updated policy information through verification mechanisms. This helps maintain the consistency of policies between data center modules in the IoT environment, while also enhancing the security of the system.

[0169] For example, after running the topic merging algorithm, policy synchronization messages of different device groups will be transmitted on a merged topic. In order to ensure that the NOS cannot perceive the synchronization information of device groups that are not under its jurisdiction to ensure privacy, and at the same time ensure the real-time and flexibility of policy synchronization, some control information flows need to be added to the policy synchronization message body.

[0170] Policy synchronization messages such as Figure 5 As shown, nonce is a random number generated when each message is sent, which is used to generate a session key for message encryption. When a device group occupies a topic exclusively, the message does not need to be encrypted, and this field is empty. NOS regularly requests the encryption root key k of the device group corresponding to the groupid (i.e., the unique identity of the device group) from the kms service of the core network, and then uses the key generation algorithm KDF (groupid, nonce, k) to generate a session key to encrypt fields other than nonce and groupid. nosid identifies the NOS that initiates message synchronization, and tnosid identifies the target NOS, which allows each NOS to select the target object it wants to synchronize with, thereby flexibly synchronizing policies. stime allows other NOSs that receive policy synchronization information to perceive the time when other nodes initiate policy synchronization, and then they can check whether the newly connected users still meet the new authorization policy during the period of policy synchronization message propagation. If not, the user's session is interrupted. The type field identifies whether the authorization policy is added, deleted, or modified. model and rule identify the actual changed authorization policy content. other is supplementary information. Different NOSs exchange the above information on different topics through the MQTT protocol to synchronize messages. The message synchronization processing algorithm is shown in Table 2:

[0171] Table 2

[0172]

[0173] In some embodiments, in step 305, the target data center module uses the authentication root key generated in the registration phase to authenticate the two transmission nodes communicating with each other during the authentication process, and obtains the authentication result, including:

[0174] In step E1, the target data center module determines a first challenge value of a first transmission node of two transmission nodes, and transmits a preset identity identifier and the first challenge value of the first transmission node to a second transmission node of the two transmission nodes.

[0175] In step E2, the second transmission node in the target data center module obtains the first authentication root key of the first transmission node from the authentication root key generated in the registration phase, processes the first challenge value of the first transmission node, the preset identity of the second transmission node and the first authentication key of the first transmission node through a hash operation message authentication code algorithm, determines the first response value of the first challenge value, and transmits the preset identity of the second transmission node and the first response value of the first challenge value to the first transmission node.

[0176] Step E3, the first transmission node in the target data center module processes the first challenge value of the first transmission node, the preset identity of the second transmission node and the first authentication key of the first transmission node through a hash operation message authentication code algorithm to determine the second response value of the first challenge value, and compares the first response value and the second response value to obtain a comparison result.

[0177] Step E4, the target data center module determines that the identity authentication result is that there is an unregistered node among the two transmission nodes in response to the comparison result that the first response value and the second response value are not equal; or, the target data center module determines that the identity authentication result is that there is no unregistered node among the two transmission nodes in response to the comparison result that the first response value and the second response value are equal.

[0178] In the above scheme, the identity authentication process between the two transmission nodes in the target data center module mainly relies on the challenge-response mechanism and the hash operation message authentication code (HMAC) algorithm to ensure that both transmission nodes have registered and hold valid authentication keys.

[0179] The target data center module determines a first challenge value of a first transmission node among two transmission nodes (a first transmission node and a second transmission node).

[0180] Then, it transmits the preset identity document (ID) of the first transmission node, the first challenge value, and possible other necessary information to the second transmission node.

[0181] The second transmission node finds the first authentication root key corresponding to the first transmission node from the authentication root key generated by it in the registration phase.

[0182] Using the first authentication root key, the first challenge value of the first transmission node, the second transmission node's own preset identity, and a hash operation message authentication code (HMAC) algorithm, the second transmission node generates a first response value to the first challenge value.

[0183] The second transmission node then transmits its own preset identity and the first response value back to the first transmission node.

[0184] The first transmission node also uses the same hash operation message authentication code (HMAC) algorithm, its own first challenge value, the preset identity of the second transmission node, and the first authentication key of the first transmission node (this key may be derived from the authentication root key) to generate a second response value of the first challenge value.

[0185] The first transmission node then compares the second response value generated by itself with the first response value received from the second transmission node.

[0186] If the first response value and the second response value are not equal, the target data center module determines that the identity authentication result is that there is an unregistered node in the two transmission nodes, or the authentication key of at least one of the nodes is incorrect.

[0187] If the first response value and the second response value are equal, the target data center module determines that the identity authentication result is that there is no unregistered node in the two transmission nodes, that is, both nodes have successfully passed the identity authentication.

[0188] The core of this process lies in the use of the HMAC algorithm, which combines the key and the message (in this scenario, the challenge value and the identity) to generate a fixed-length authentication code (response value). Due to the characteristics of the HMAC algorithm, only the node holding the correct key can generate the same response value as another node, thus ensuring that both nodes have registered and hold a valid authentication key.

[0189] For example, compared with the public network, the intranet has stronger autonomy and resource limitations. The traditional digital certificate authentication scheme suitable for the public network has the problems of difficulty in establishing the public key infrastructure (PKI) in the intranet environment, difficulty in certificate life cycle management, and high performance overhead. In order to solve these problems, the two-way authentication protocol designed by the present invention is based on the certificateless identity-based encryption algorithm CL-IBE. The CL-IBE algorithm does not need to manage digital certificates. Each node can request its own identity-based private key from the key management unit and use its own identity as the public key. This allows the intranet key management unit to only extract the private key for the intranet node when it is initialized or needs to update the key, and does not need to participate in the long-term digital certificate management and digital certificate verification work, which greatly reduces the pressure. In addition, unlike the traditional IBE that requires a completely trusted key generation center (Key Generation Center, KGC), the KGC of this scheme only generates partial keys for each node, and the keys actually used are generated by the user themselves, and the KGC cannot deduce the complete keys actually generated by the user from the partial keys. This makes it impossible for the KGC to know the secret private key used by the user even if the security parameters are accidentally leaked. In addition, this scheme uses the negotiated symmetric key as the authentication root key between nodes and does not store it in the KGC. This not only reduces the risk of KGC being hacked and leaking keys, but also uses symmetric keys to reduce the computational overhead of the authentication protocol.

[0190] The authentication protocol proposed in this application can resist malicious attackers with certain social engineering capabilities in the intranet. Attackers can arbitrarily eavesdrop on the traffic transmitted in the intranet, obtain the security parameters leaked by the key management unit through social engineering means, and initiate sessions or launch active attacks on any node. For such attackers, the protocol can ensure the one-way consistency of authentication between any nodes and the confidentiality of the session key.

[0191] The specific authentication protocol design involves the protocol initialization phase, the protocol authentication key negotiation phase, and the authentication and key negotiation phase.

[0192] System initialization phase:

[0193] The first phase of the protocol is the system initialization phase. Figure 6 The key management unit shown in the figure first selects a set of security parameters for the NOS domain when it is initialized for the first time (different NOS domains select different security parameters, which increases the cost of attack for attackers). Security domain parameters In this case, q is a large prime number, is a finite field of cardinality q, For a finite field The elliptic curve on G is an elliptic curve is a cyclic subgroup of G, P is a generator of the group G, is the master private key randomly selected by the key management unit, P pub =sP is the primary public key. and are two one-way collision-resistant hash functions.

[0194] The identity is NID i When a node in the domain is initialized, it will request its own partial private key from the key management unit. The node first sends its identity NID through the secure channel between the node and the key management unit. i Sent to the key management unit. The key management unit selects a random number And calculate R i =r i P and h i =H1(NID i , R i ). Finally, the key management unit calculates the node's pre-key s i =r i +h i s, and put the pre-key s i Safely sent to the corresponding node.

[0195] After receiving the pre-key, the node randomly selects a random number And calculate h′ i =H1(ID i , X i ),X i =x i P.z i =x i +h′ i s i The node then calculates S i =(R i +h i P pub )=s i P, then the node's identity base private key is SK i =(s i , x i ), the identity base public key is PK i =(R i , S i , X i ).

[0196] In this process, the key management unit is only responsible for calculating the pre-key. The actual node public and private keys are generated by the node itself later. Even the key management unit itself cannot reverse the private key generated by the node using the pre-key only through the pre-key and the corresponding node's public key.

[0197] Authentication key negotiation phase:

[0198] like Figure 7 As shown in the figure, the authentication key negotiation phase is the process of negotiating the root key used for subsequent identity authentication between two legitimate nodes. This process only occurs when the administrator configures the two nodes to access each other for the first time or when the administrator updates the authentication key between the two nodes. In this phase, the two nodes use the identity base key obtained in the previous phase to negotiate keys. Even if the key negotiation parameters pass through the key management unit through a secure channel, the key management unit still cannot calculate the final authentication key generated through the key negotiation parameters. This mechanism makes the authentication key only perceived by the actual node, and the key management unit only saves the intermediate key generation parameters for traceability and cannot generate an authentication key table. This ensures that even if the system administrator of the key management unit accidentally leaks the intermediate parameters, the attacker cannot calculate the authentication key based on these security parameters.

[0199] The specific process of the key negotiation phase is as follows:

[0200] 1) The administrator configures the two nodes to access each other through the northbound interface.

[0201] 2) Node1 is randomly selected Calculate T1 = (az1) P = a(x1 + h′1s1 (mod q)) P. Node1 sends T1 to Node2 via the secure channel between Node1 (ie, the first transmission node) and Node2 (ie, the second transmission node) and the key management unit.

[0202] 3) Node2 is randomly selected Calculate T2=(bz2)P=b(x2+h′2s2(mod q))P.

[0203] 4) Node2 also responds T2 to Node1 via the secure channel between Node1 and Node2 and the key management unit.

[0204] 5) Node1 calculates the pre-authentication key Where h′1=H1(X1, NID1), then generate the session key k=H2(NID1, NID2, T1, T2, K). Node2 calculates the pre-authentication key Where h′2=H1(X2, NID2), and then the session key k=H2(NID1, NID2, T1, T2, K) is generated.

[0205] 6) Finally, Node1 and Node2 use the challenge response mechanism combined with the HMAC function to confirm each other's keys on the unprotected channel.

[0206] Node authentication and session key negotiation phase:

[0207] like Figure 8 As shown, in this stage, the two nodes that the administrator configures to access each other are authenticated through the identity key negotiated in the previous two nodes and the session key is negotiated through the identity base key obtained from the key management unit. The separation of the authentication key and the key negotiation private key makes the key boundary clearer and can also reduce the risk of a single key leak. At the same time, the authentication key is a negotiated symmetric key. The authentication method based on the symmetric key is more efficient and suitable for scenarios where nodes need to communicate frequently. The communications in this stage are all carried out on a normal channel without any additional security assumptions.

[0208] The specific process of this stage is as follows:

[0209] 1) Node1 randomly selects two random numbers r1, Then T1=a(x1+h′1s1(mod q))P is calculated, where h′1=H1(X1, NID1). Finally, Node1 sends the identity NID1 together with r1 and T1 to Node2.

[0210] 2) Node2 randomly selects two random numbers r2, Then, the authentication key k of Node1 is obtained from the authentication key table, and the response value res1 of the challenge value r1 is calculated as HMAC(r1, NID2, k). Then, Node2 calculates T2=b(x2+h2′s2(modq))P, where h′2=H1(X2, NID2). Finally, Node2 calculates the pre-session key K=[b(x2+h 2′ s2(modq))]T1, and generate the final session key k s =H2(NID1, NID2, T1, T2, K).

[0211] 3) Node2 sends the identity NID2, challenge value r2, key exchange parameter T2, and response value res1 to Node1.

[0212] 4) Node1 calculates res′1=HMAC(r1, NID2, j) and checks whether res′1 and res1 are equal. If they are equal, it calculates the pre-session key Final session key k s =H2(NID1, NID2, T1, T2, K), response value res2 = HMAC(r2, NID1, k, k s ).

[0213] 5) After receiving the response value, Node2 calculates res2′=HMAC(r2, NID1, k, k s), if res2 = res′2, the authentication is completed, and the session key is k s .

[0214] In some embodiments, in step 305, the step of performing session key negotiation on two mutually communicating transmission nodes using a certificateless identity-based encryption algorithm to obtain a negotiated session key includes:

[0215] Step F1, the target data center module obtains a pre-session key, a first key exchange parameter of a first transmission node of two transmission nodes communicating with each other, and a second key exchange parameter of a second transmission node of the two transmission nodes communicating with each other.

[0216] In step F2, the target data center module processes the preset first transmission node identity, the preset second transmission node identity, the first key exchange parameter, the second key exchange parameter and the pre-session key through a hash function to obtain a negotiated session key.

[0217] In the above scheme, the pre-session key may be shared in a secure manner before communication, or provided by a trusted third party. The purpose of the pre-session key is to serve as the basis for generating the final session key.

[0218] Key exchange parameters of transmission nodes: In the key exchange protocol, each node generates or selects a parameter, which plays a key role in the subsequent key negotiation process. For the first transmission node and the second transmission node, they have their own first key exchange parameters and second key exchange parameters respectively. These parameters are usually randomly generated to ensure that the session key for each communication is unique.

[0219] Transmission node identity: Each transmission node has a unique identity (such as a public key, certificate, or user name, etc.) that is used to verify the identity of the node during the communication process. Here, the preset first transmission node identity and the preset second transmission node identity are used to ensure that the participants in the key negotiation process are the expected parties.

[0220] Destination Data Center Module: This is an intermediate entity that receives the key exchange parameters and pre-session keys from the two transmission nodes, as well as the identities of the two nodes. The task of the destination data center module is to generate the final session key based on this information using a secure method (such as a hash function).

[0221] Hash function processing: A hash function is a one-way mathematical function that converts input data of any length into output data of a fixed length (called a hash value or digest). In this scenario, the target data center module takes the first transmission node's identity, the second transmission node's identity, the first key exchange parameter, the second key exchange parameter, and the pre-session key as input, processes them through the hash function, and obtains a fixed-length output, namely the negotiated session key.

[0222] In this way, the two transmission nodes can securely negotiate a shared session key for subsequent encrypted communications. Due to the one-way and collision-resistant nature of the hash function, even if an attacker intercepts all the information transmitted during the key negotiation process, it is difficult to calculate the final session key. Therefore, this method provides a secure and reliable key negotiation mechanism.

[0223] It should be noted that the method of the embodiment of the present application can be performed by a single device, such as a computer or server. The method of this embodiment can also be applied to a distributed scenario and completed by multiple devices cooperating with each other. In the case of such a distributed scenario, one of the multiple devices can only perform one or more steps in the method of the embodiment of the present application, and the multiple devices will interact with each other to complete the described method.

[0224] It should be noted that the above describes some embodiments of the present application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the above embodiments and still achieve the desired results. In addition, the processes depicted in the accompanying drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0225] Based on the same inventive concept, corresponding to any of the above-mentioned embodiment methods, the present application also provides a data transmission device for the Internet of Things.

[0226] refer to Fig. 9 , the data transmission device for the Internet of Things, the device is arranged in a data transmission system for the physical network, the system includes a core network module, a plurality of user devices, a plurality of data center modules and a plurality of Internet of Things device groups corresponding to each data center module, the device includes:

[0227] The data center module 901 is configured to use any data center module in the data center module as a target data center module, wherein the target data center module collects physical network data generated by the corresponding multiple IoT device groups during operation; the target data center module receives authorization policy modification information for a request service of a user device, uses the authorization policy modification information to authenticate the authority of the target user device, and in response to the authority of the target user device satisfying the authorization policy modification information, sends the IoT data of the service subject corresponding to the service request to the target user device; or, in response to the authority of the target user device satisfying the authorization policy modification information, terminates the connection with the service The IoT data of the service subject corresponding to the request is sent to the target user device; the target data center module uses the authentication root key generated in the registration phase to authenticate the two transmission nodes that communicate with each other during the authentication process to obtain an authentication result, and in response to the authentication result that there is an unregistered node in the two transmission nodes, the access of the unregistered node is denied; or, in response to the authentication result that there is no unregistered node in the two transmission nodes, the two transmission nodes that communicate with each other are negotiated for session keys using a certificateless identity-based encryption algorithm to obtain a negotiated session key, and the data transmission process between the two transmission nodes is encrypted using the negotiated session key;

[0228] The user equipment 902 is configured to use a user equipment that initiates a service request among the multiple user equipments as a target user equipment, and the target user equipment sends a service request to the target data center module;

[0229] The core network module 903 is configured to count the total number of service topics carried by all servers corresponding to the target data center module within the core network module during the authentication process, and in response to the total number of service topics being greater than a preset total number threshold, merge the service topics carried by the servers using a service topic merging algorithm to obtain a merged service topic, store the preset policy synchronization message in the merged service topic, and synchronize the preset policy synchronization message stored in the merged service topic using a message synchronization processing algorithm, so that each data center module can synchronize and store the corresponding authorization policy modification information.

[0230] For the convenience of description, the above device is described in terms of functions divided into various modules. Of course, when implementing the present application, the functions of each module can be implemented in the same or multiple software and / or hardware.

[0231] The device of the above embodiment is used to implement the corresponding data transmission method for the Internet of Things in any of the above embodiments, and has the beneficial effects of the corresponding method embodiment, which will not be repeated here.

[0232] Based on the same inventive concept, corresponding to any of the above-mentioned embodiments and methods, the present application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the data transmission method for the Internet of Things described in any of the above embodiments is implemented.

[0233] Fig.10 A more specific schematic diagram of the hardware structure of an electronic device provided in this embodiment is shown, and the device may include: a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, the memory 1020, the input / output interface 1030, and the communication interface 1040 are connected to each other through the bus 1050 in the device.

[0234] The processor 1010 can be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0235] The memory 1020 may be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 may store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented by software or firmware, the relevant program codes are stored in the memory 1020 and are called and executed by the processor 1010.

[0236] The input / output interface 1030 is used to connect the input / output module to realize information input and output. The input / output module can be configured in the device as a component (not shown in the figure), or it can be externally connected to the device to provide corresponding functions. The input device may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output device may include a display, a speaker, a vibrator, an indicator light, etc.

[0237] The communication interface 1040 is used to connect a communication module (not shown) to realize communication interaction between the device and other devices. The communication module can realize communication through a wired mode (such as USB, network cable, etc.) or a wireless mode (such as mobile network, WIFI, Bluetooth, etc.).

[0238] The bus 1050 includes a path that transmits information between the various components of the device (eg, the processor 1010, the memory 1020, the input / output interface 1030, and the communication interface 1040).

[0239] It should be noted that, although the above device only shows the processor 1010, the memory 1020, the input / output interface 1030, the communication interface 1040 and the bus 1050, in the specific implementation process, the device may also include other components necessary for normal operation. In addition, it can be understood by those skilled in the art that the above device may also only include the components necessary for implementing the embodiments of the present specification, and does not necessarily include all the components shown in the figure.

[0240] The electronic device of the above-mentioned embodiment is used to implement the corresponding data transmission method for the Internet of Things in any of the above-mentioned embodiments, and has the beneficial effects of the corresponding method embodiment, which will not be repeated here.

[0241] Based on the same inventive concept, corresponding to any of the above-mentioned embodiment methods, the present application also provides a non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores computer instructions, and the computer instructions are used to enable the computer to execute the data transmission method for the Internet of Things as described in any of the above embodiments.

[0242] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, read-only compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device.

[0243] The computer instructions stored in the storage medium of the above embodiment are used to enable the computer to execute the data transmission method for the Internet of Things as described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0244] A person skilled in the art should understand that the discussion of any of the above embodiments is merely illustrative and is not intended to imply that the scope of the present application is limited to these examples. In line with the concept of the present application, the technical features in the above embodiments or different embodiments may be combined, the steps may be implemented in any order, and there are many other variations of the different aspects of the embodiments of the present application as described above, which are not provided in detail for the sake of simplicity.

[0245] In addition, to simplify the description and discussion, and in order not to make the embodiments of the present application difficult to understand, the known power supply / ground connection with the integrated circuit (IC) chip and other components may or may not be shown in the provided drawings. In addition, the device can be shown in the form of a block diagram to avoid making the embodiments of the present application difficult to understand, and this also takes into account the fact that the details of the implementation of these block diagram devices are highly dependent on the platform to be implemented in the embodiments of the present application (that is, these details should be fully within the scope of understanding of those skilled in the art). In the case of elaborating specific details (e.g., circuits) to describe exemplary embodiments of the present application, it is obvious to those skilled in the art that the embodiments of the present application can be implemented without these specific details or when these specific details are changed. Therefore, these descriptions should be considered to be illustrative rather than restrictive.

[0246] Although the present application has been described in conjunction with specific embodiments of the present application, many replacements, modifications and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may use the embodiments discussed.

[0247] The embodiments of the present application are intended to cover all such substitutions, modifications and variations that fall within the broad scope of the present application. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the embodiments of the present application should be included in the protection scope of the present application.

Claims

1. A data transmission method for the Internet of Things, characterized in that: A data transmission system for a physical network is applied, the system comprising a core network module, a plurality of user devices, a plurality of data center modules, and a plurality of IoT device groups corresponding to each data center module, the method comprising: Any data center module in the data center modules is used as a target data center module, and the target data center module collects physical network data generated by the corresponding multiple Internet of Things device groups during operation; A user equipment that initiates a service request among the multiple user equipments is used as a target user equipment, and the target user equipment sends a service request to the target data center module; The target data center module receives authorization policy modification information for a service request of a user device, authenticates the authority of the target user device using the authorization policy modification information, and sends the Internet of Things data of the service subject corresponding to the service request to the target user device in response to the authority of the target user device satisfying the authorization policy modification information; or, in response to the authority of the target user device satisfying the authorization policy modification information, terminates sending the Internet of Things data of the service subject corresponding to the service request to the target user device; During the authentication process, the core network module counts the total number of service topics carried by all servers corresponding to the target data center module within the core network module, and in response to the total number of service topics being greater than a preset total number threshold, uses a service topic merging algorithm to merge the service topics carried by the servers to obtain a merged service topic, stores a preset policy synchronization message in the merged service topic, and uses a message synchronization processing algorithm to synchronize the preset policy synchronization message stored in the merged service topic, so that each data center module can synchronize and store the corresponding authorization policy modification information; During the authentication process, the target data center module uses the authentication root key generated in the registration phase to perform identity authentication on two transmission nodes that communicate with each other, and obtains an identity authentication result. In response to the identity authentication result that there is an unregistered node among the two transmission nodes, the module denies access to the unregistered node. Alternatively, in response to the identity authentication result that there is no unregistered node among the two transmission nodes, the module uses a certificateless identity-based encryption algorithm to perform session key negotiation on the two transmission nodes that communicate with each other, and obtains a negotiated session key, and uses the negotiated session key to encrypt the data transmission process between the two transmission nodes.

2. The method according to claim 1, characterized in that The method of merging the service themes carried by the server using the service theme merging algorithm to obtain the merged service themes includes: The core network module divides all servers into association groups according to a preset number of servers to obtain a plurality of association groups; The core network module determines the number of IoT device groups currently accommodated by the server corresponding to each association group, and selects a target association group whose number of IoT device groups currently accommodated is greater than the maximum number of IoT device groups allowed to be transmitted simultaneously from each association group; The core network module determines the idleness index of each other association group except the target association group in each association group; The core network module searches for a plurality of target other association groups whose idleness indexes are greater than a preset migration threshold from the idleness indexes of the other association groups; The core network module determines a final target other association group from multiple target other association groups, whose idleness index is the largest and whose total load of all corresponding servers is greater than or equal to the total load of the target association group, and merges the service topics carried by the servers corresponding to the target association group into the service topics carried by the servers corresponding to the final target other association group to obtain a merged service topic.

3. The method according to claim 2, characterized in that The determining of the idleness indexes of other association groups except the target association group in each association group includes: The core network module determines the current total load of each server corresponding to other association groups in each association group except the target association group, and the maximum load of the corresponding server; The core network module determines the idleness index of other association groups in each association group except the target association group based on the current total load of each server and the maximum load of the corresponding server by the following formula: in, represents the idleness index, represents the current total load of the i-th server, Indicates the maximum load of the i-th server.

4. The method according to claim 3, characterized in that The determining of the current total load of each server corresponding to other association groups except the target association group in each association group includes: The core network module performs the following operations on each other association group except the target association group in each association group: The core network module obtains the load of the primary partition of the service theme corresponding to each server in other association groups, and the load of the replica of the corresponding service theme; The core network module determines the current total load of each server corresponding to other association groups except the target association group in each association group by using the load of the primary partition of the service theme corresponding to each server in other association groups and the load of the replica of the corresponding service theme through the following formula: in, represents the current total load of the i-th server, represents the load of the primary partition of the k-th service topic, represents the load of the replica of the kth service topic, λ represents the reduction factor of the replica load, λ∈(0,1), T k represents the kth service topic, represents the set of primary partitions on the i-th server, Represents the set of replicas on the i-th server.

5. The method according to claim 1, characterized in that The preset policy synchronization message is stored in the merged service theme, and the preset policy synchronization message stored in the merged service theme is synchronously processed by using a message synchronization processing algorithm so that each data center module can synchronously store the corresponding authorization policy modification information, including: The core network module uses the session key generated by the key generation algorithm to encrypt other fields in the preset policy synchronization message except the random number generated when each message is sent and the identifier of the IoT device group to obtain encrypted other fields, wherein the other fields at least include the identifier of the data center module initiating synchronization, the list of data center modules to be synchronized, and the type of authorization policy change; The core network module determines whether the identifier of the data center module that initiates synchronization exists in the list of data center modules that need to be synchronized. In response to determining that it exists, the authorization policy change type corresponding to the identifier of the data center module that initiates synchronization is transmitted to the corresponding data center module, so that the corresponding data center module can update the initial authorization policy according to the authorization policy change type, generate corresponding authorization policy modification information and synchronize and store it.

6. The method according to claim 1, characterized in that The target data center module uses the authentication root key generated in the registration phase to perform identity authentication on the two transmission nodes communicating with each other during the authentication process, and obtains the identity authentication result, including: The target data center module determines the first challenge value of the first transmission node of the two transmission nodes respectively, and transmits the preset identity identifier and the first challenge value of the first transmission node to the second transmission node of the two transmission nodes; The second transmission node in the target data center module obtains the first authentication root key of the first transmission node from the authentication root key generated in the registration phase, processes the first challenge value of the first transmission node, the preset identity of the second transmission node and the first authentication key of the first transmission node through a hash operation message authentication code algorithm, determines the first response value of the first challenge value, and transmits the preset identity of the second transmission node and the first response value of the first challenge value to the first transmission node; The first transmission node in the target data center module processes the first challenge value of the first transmission node, the preset identity of the second transmission node and the first authentication key of the first transmission node through a hash operation message authentication code algorithm to determine the second response value of the first challenge value, and compares the first response value with the second response value to obtain a comparison result; The target data center module determines, in response to the comparison result that the first response value and the second response value are not equal, that the authentication result is that there is an unregistered node among the two transmission nodes; or, in response to the comparison result that the first response value and the second response value are equal, the target data center module determines, in response to the comparison result that the first response value and the second response value are equal, that the authentication result is that there is no unregistered node among the two transmission nodes.

7. The method according to claim 1, characterized in that The method of using a certificateless identity-based encryption algorithm to negotiate a session key between two transmission nodes communicating with each other to obtain a negotiated session key includes: The target data center module obtains a pre-session key, a first key exchange parameter of a first transmission node of two transmission nodes communicating with each other, and a second key exchange parameter of a second transmission node of the two transmission nodes communicating with each other; The target data center module obtains a negotiated session key by processing through a hash function based on a preset identity of the first transmission node, a preset identity of the second transmission node, a first key exchange parameter, a second key exchange parameter and a pre-session key.

8. A data transmission device for the Internet of Things, characterized in that: The device is arranged in a data transmission system for a physical network, the system comprising a core network module, a plurality of user devices, a plurality of data center modules and a plurality of Internet of Things device groups corresponding to each data center module, the device comprising: A data center module is configured to use any data center module in the data center module as a target data center module, wherein the target data center module collects physical network data generated by the corresponding multiple Internet of Things device groups during operation; the target data center module receives authorization policy modification information for requesting services for user devices, uses the authorization policy modification information to authenticate the permissions of the target user device, and in response to the permissions of the target user device satisfying the authorization policy modification information, sends the Internet of Things data of the service subject corresponding to the service request to the target user device; or, in response to the permissions of the target user device satisfying the authorization policy modification information, terminates sending the Internet of Things data of the service subject corresponding to the service request to the target user device; the target data center module uses the authentication root key generated in the registration phase during the authentication process to authenticate the two transmission nodes that communicate with each other, obtains the authentication result, and in response to the authentication result that there is an unregistered node in the two transmission nodes, denies access to the unregistered node; or, in response to the authentication result that there is no unregistered node in the two transmission nodes, uses a certificateless identity-based encryption algorithm to negotiate session keys for the two transmission nodes that communicate with each other, obtains a negotiated session key, and uses the negotiated session key to encrypt the data transmission process between the two transmission nodes; A user device is configured to use a user device that initiates a service request among the multiple user devices as a target user device, and the target user device sends a service request to the target data center module; The core network module is configured to count the total number of service topics carried by all servers corresponding to the target data center module within the core network module during the authentication process, and in response to the total number of service topics being greater than a preset total number threshold, merge the service topics carried by the servers using a service topic merging algorithm to obtain a merged service topic, store a preset policy synchronization message in the merged service topic, and synchronize the preset policy synchronization message stored in the merged service topic using a message synchronization processing algorithm, so that each data center module can synchronize and store the corresponding authorization policy modification information.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that: When the processor executes the program, the method according to any one of claims 1 to 7 is implemented.

10. A non-transitory computer-readable storage medium storing computer instructions, characterized in that: The computer instructions are used to enable a computer to execute the method according to any one of claims 1 to 7.

Images