A novel Internet of Things password service system and password component node selection method

Abstract

The present invention discloses a novel Internet of Things password service architecture and a method for selecting password component nodes, including: a General Management Component (GC) for scheduling password components to specifically process password requests of password services; an Encryption Component (EC) for reading operation instructions of password services and performing corresponding encryption operations; the General Management Component (GC) is deployed in the cloud layer, the Encryption Component (EC) is deployed in the fog layer, and the Key Management Component (KC) and the Decryption Component (DC) are both deployed in the cloud layer and the fog layer. The present invention proposes a full cloud-fog password service architecture for the Internet of Things, which can make full use of the computing resources and communication resources of the cloud layer and the fog layer to improve the performance of the EaaS platform.

Description

Technical Field

[0001] The present invention relates to the technical field of cryptographic services, and in particular to a novel Internet of Things (IoT) cryptographic service system and a method for selecting cryptographic component nodes. Background Art

[0002] Encryption as a Service (EaaS) provides precise, efficient, and differentiated cryptographic services to network devices for specific applications and scenarios, such as data encryption and decryption, identity authentication, key management, and access control. Thus, it is not necessary to consume the computing resources of the network devices themselves for complex data processing. For the IoT, IoT devices are typically resource-constrained, with only a small amount of memory space and limited computing power. If the designed cryptographic service architecture cannot fully utilize the cryptographic resources at all levels, it will greatly affect the quality of cryptographic services. Currently, the cryptographic service infrastructure includes four types of cryptographic components, namely General management Component (GC), Key management Component (KC), Encryption Component (EC), and Decryption Component (DC). Different cryptographic devices may be located at different layers, including the cloud layer, fog layer, and device layer. The cryptographic service architectures proposed in the publicly available research results are not sufficient to fully utilize the node resources at all levels to provide high-quality cryptographic services.

[0003] The main purpose of Encryption as a Service (EaaS) is to provide data encryption and decryption services with high computational complexity to resource-constrained IoT devices. Due to the large number of IoT devices and the limited computing and communication resources, problems such as high latency and high rejection rate are likely to occur. Through research on domestic and foreign patent literatures, the current cryptographic service architecture lacks full utilization of the node resources in the cloud layer and fog layer. Summary of the Invention

[0004] In view of the above deficiencies in the prior art, a novel IoT cryptographic service system and a method for selecting cryptographic component nodes provided by the present invention solve the problem of over-allocation of cloud node resources.

[0005] To achieve the above invention objective, the technical solution adopted by the present invention is: A novel IoT cryptographic service system, comprising:

[0006] A General management Component (GC) for scheduling cryptographic components to specifically process cryptographic requests of cryptographic services;

[0007] An Encryption Component (EC) for reading operation instructions of cryptographic services and performing corresponding encryption operations;

[0008] Deploy the General Management Component (GC) in the cloud layer, the Encryption Component (EC) in the fog layer, and deploy the Key Management Component (KC) and Decryption Component (DC) in both the cloud layer and the fog layer.

[0009] Furthermore, the specific encryption process for shared data in the Internet of Things is as follows:

[0010] Step 1: The Internet of Things device connects to a GC and sends the information required for encrypting data, including the Internet of Things device identifier a, the plaintext g to be encrypted, the list h of Internet of Things devices sharing data with the GC, and the password parameters i expected by the device.

[0011] Step 2: When the GC receives the encryption request from the Internet of Things device, it selects appropriate KC and EC nodes to process the current password service request, and sends the Internet of Things device identifier a, the GC identifier b, the selected EC identifier c, the plaintext g to be encrypted, the list h of Internet of Things devices sharing data with the GC, and the password parameters i expected by the device to the selected KC; the GC and EC identifiers help the KC forward the request to the selected EC and help the EC forward the response to the correct GC.

[0012] Step 3: When the KC receives the forwarded password service request, it adds the request identifier d to the password service request, generates one or more keys e based on the requested password parameters, and transmits the requested password information to the database to be stored, including the Internet of Things device identifier a, the request identifier d, the key e, the list h of Internet of Things devices sharing data with the GC, and the password parameters i expected by the device.

[0013] Step 4: After the password information of the current request is stored in the database, it is forwarded to the selected EC together with the plaintext g to be encrypted and the GC identifier b.

[0014] Step 5: When the EC receives the password service instruction, it encrypts the plaintext g based on the received key e and password parameters i to generate the ciphertext f, and the EC forwards the ciphertext f together with the Internet of Things device identifier a and the request identifier d to the GC.

[0015] Step 6: After receiving the request identifier d and the ciphertext f, the GC forwards the request identifier d and the ciphertext f to the Internet of Things device based on the Internet of Things device identifier a.

[0016] Step 7: The Internet of Things device uploads the ciphertext f and the request identifier d to share the encrypted data on the public cloud.

[0017] Furthermore, the IoT device can upload the ciphertext and its related identifier, share the encrypted data on the public cloud, the public cloud stores all the shared data in the IoT, and all IoT devices can access the data from the public cloud, but only the other IoT devices listed by the IoT device that provides the data can decrypt and read the data.

[0018] Furthermore, the process for other IoT devices in the IoT to access and decrypt the shared data is as follows:

[0019] The first step: The IoT device requests the public cloud to obtain data by the request identifier d.

[0020] The second step: The public cloud responds to the ciphertext access request of the IoT device and transmits the request identifier d and the ciphertext f.

[0021] The third step: The IoT device connects to a GC and sends the IoT device identifier a, the ciphertext f, and the request identifier d.

[0022] The fourth step: When the GC receives the IoT device identifier a, the ciphertext f, and the request identifier d, it selects appropriate KC and DC nodes, and sends the device identifier a, the GC identifier b, the DC identifier c, the request identifier d, and the ciphertext f to the selected KC node together.

[0023] The fifth step: When the KC receives the decryption request for the ciphertext f, the KC sends the request identifier d to the database and extracts the entry corresponding to this decryption request in the database.

[0024] The sixth step: The database finds the entry with the request identifier d and forwards the related key e, the IoT device list h, and the password parameter i to the KC.

[0025] The seventh step: The KC checks whether the IoT device accessing the data is in the IoT device list h. If it is not in h, the KC sends a notification of unauthorized access to the GC, the GC sends a denial-of-service response to the IoT device, and this process ends; if it is in h, the KC sends the ciphertext f, the key e, the password parameter i, and the IoT device identifier a, the GC identifier b, and the request identifier d to the DC together.

[0026] The eighth step: The DC decrypts the requested ciphertext based on the received key e and password parameter i, and forwards the decrypted plaintext g, the IoT device identifier a, and the request identifier d to the GC.

[0027] The ninth step: When the GC receives the password service response, it sends the decrypted data to the IoT device that requests to access the data according to the device identifier a.

[0028] A method for selecting password component nodes, which is used to select KC, EC, and DC component nodes in a new type of Internet of Things password service system, includes the following steps:

[0029] S1. The list Q is used to store the queue length of each node. The list Q starts from zero, and its length is equal to the sum of the fog nodes and cloud nodes;

[0030] S2. The GC receives a password service request; if there is a specified KC in the password service request, the queue of KC is reduced by one unit;

[0031] S3. The EC receives a password service request; if there is a specified EC in the password service request, the queue of EC is reduced by one unit, and the password service request is forwarded to the Internet of Things device providing the data;

[0032] S4. The DC receives a password service request; if there is a specified DC in the password service request, the queue of DC is reduced by one unit, and the password service request is forwarded to the Internet of Things device accessing the data;

[0033] S5. If none of the KC, EC, and DC components are selected, let the variable found start from zero, indicating the number of fog nodes with resources to process the current request. The list H records which fog nodes have sufficient resources to process the password service request;

[0034] S6. The list H is filled with "False" flags, indicating that the current fog node does not have sufficient resources to process the request. The flag H(f) and the number of available fog nodes found are updated through a loop over all fog nodes. Two fog nodes with the shortest queue lengths are found, and these fog nodes and their queue lengths are stored in sets f1, f2, m1, and m2 respectively;

[0035] S7. In the loop over all fog nodes, f1, f2, m1, and m2 are updated to find two cloud nodes with the shortest queue lengths, which are stored in c1 and c2;

[0036] S8. If the GC receives an encryption request, always select the EC from the cloud nodes. If there is at least one available fog node, select the KC from the fog nodes, and add one unit to the queue length of the selected node as the EC;

[0037] S9. If the GC receives a decryption request, select the KC and DC based on the number of available fog nodes found, and add one unit to the queue length of the selected node as the DC;

[0038] S10. Add one unit to the queue length of the selected KC, and forward the request to the requested KC node request.kc.

[0039] Furthermore, the GC is responsible for tracking the number of requests α sent to each node and the number of requests β received by each node. The value of α - β represents the number of requests waiting to be completed in each node. To balance the traffic load of the Internet of Things, the GC sends requests to the cryptographic component nodes with the lowest α - β value.

[0040] Furthermore, once the GC receives a cryptographic service request, it checks the status of all nodes to select appropriate KC and DC nodes. If a fog node has sufficient resources and its queue is not full, the GC will forward the cryptographic service request to that fog node; otherwise, the GC will forward the cryptographic service request to the cloud node with the shortest queue length.

[0041] The beneficial effects of the present invention are as follows: The present invention proposes a full cloud and fog cryptographic service system for the Internet of Things, which can make full use of the computing resources and communication resources of the cloud layer and fog layer to improve the performance of the EaaS platform. The cryptographic service system places the most frequently accessed components in the fog layer and then attempts to resolve resources using cloud nodes.

[0042] The beneficial effects and contributions of the present invention are summarized as follows:

[0043] 1. The present invention proposes a new cryptographic service architecture, which deploys the most frequently accessed cryptographic components in the fog layer and hands them over to the cryptographic components in the cloud layer when resources are scarce. This architecture can make full use of the computing resources and communication resources of each layer, achieving high throughput while maintaining low latency and low rejection rate.

[0044] 2. The security of the cryptographic service system proposed by the present invention can effectively reduce the security risks of the Internet of Things while ensuring high cryptographic service quality. The new cryptographic service system has advantages in terms of security. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Figure 1 It is the flowchart of shared data encryption in the Internet of Things cryptographic service system in the embodiment of the present invention;

[0046] Figure 2 It is the flowchart of decrypting access to shared data in the Internet of Things cryptographic service system in the embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0047] The following describes the specific embodiments of the present invention to facilitate those skilled in the art of the present technology to understand the present invention. However, it should be clear that the present invention is not limited to the scope of the specific embodiments. For those of ordinary skill in the art of the present technology, as long as various changes are within the spirit and scope of the present invention defined and determined by the appended claims, these changes are obvious, and all inventions made using the concept of the present invention are within the scope of protection.

[0048] To make full use of cloud and fog nodes in the Internet of Things, the present invention proposes a full cloud-fog cryptographic service system, focusing on the frequency at which Internet of Things devices connect to different cryptographic components. Among them, the General Management Component (GC) is a component that is frequently accessed by Internet of Things devices because the GC is responsible for scheduling which specific cryptographic components handle the cryptographic requests for which cryptographic services. Relatively speaking, the Encryption Component (EC) is not accessed very frequently. This is because the EC mainly reads the operation instructions of the cryptographic service to perform corresponding encryption operations. Relatively speaking, the frequency of downloading cryptographic service instructions is relatively high. Therefore, the GC is deployed in the cloud layer, the EC is deployed in the fog layer, and the Key Management Component (KC) and Decryption Component (DC) are both deployed in the cloud layer and the fog layer.

[0049] As shown in the appendix Figure 1 The specific encryption process of the shared data in the Internet of Things according to the cryptographic service system proposed by the present invention is as follows:

[0050] Step 1: Internet of Things device - [a|g|h|i] → GC

[0051] The Internet of Things device connects to one of the GCs and sends the information required to encrypt the data to it, including: the Internet of Things device identifier (a), the plaintext to be encrypted (g), the list of Internet of Things devices sharing the data with it (h), and the cryptographic parameters desired by the device (i). These are the information that the Internet of Things device must send to the GC. The device identifier helps the GC forward the response back to the correct Internet of Things device.

[0052] Step 2: GC - [a|b|c|g|h|i] → KC

[0053] Once the GC receives the encryption request from the Internet of Things device, it selects appropriate KC and EC nodes to process the current cryptographic service request. The information required, including a, the GC identifier (b), the selected EC identifier (c), g, h, and i, is sent to the selected KC. The GC and EC identifiers help the KC forward the request to the selected EC and help the EC forward the response to the correct GC.

[0054] Step 3: KC - [a|d|e|h|i] → Database

[0055] When the KC receives the forwarded cryptographic service request, the request identifier (d) is added to the request, which helps the KC find the corresponding entry in the database for this request. It should be noted that the database is shared among different KCs, and one or more keys (e) are generated based on the cryptographic parameters of the request. Finally, a, d, e, h, and i are transmitted to the database to be stored.

[0056] Step 4: KC - [a|b|d|g|e|i] → EC

[0057] After the currently requested password information is stored in the database, it is forwarded to the selected EC together with the plaintext and the identifier of the GC. Since c was sent from the previous GC to the KC, the identifier of the EC is available in this step. It should be noted that it is not necessary for the EC to know the IoT devices in the h list.

[0058] Step 5: EC - [a|d|f] → GC

[0059] When the EC receives the password service instruction, it encrypts the plaintext based on the received key and password parameters. In this step, the ciphertext (f) is generated, and the EC forwards it to the GC together with the IoT device identifier (a) and the request identifier (d).

[0060] Step 6: GC - [d|f] → IoT device

[0061] Once the GC receives the request identifier and the ciphertext, it forwards them to the IoT device based on the IoT device identifier.

[0062] Step 7: IoT device - [d|f] → Public cloud

[0063] At this point, the IoT device can upload the ciphertext and its related identifiers to share the encrypted data on the public cloud. The public cloud stores all the shared data in the IoT, and all IoT devices can access the data from the public cloud. However, this data is encrypted, and only other IoT devices listed by the IoT device that provided the data can decrypt and read the data.

[0064] As attached Figure 2 As shown, for the password service system proposed according to the present invention, the process for other IoT devices in the IoT to access and decrypt the shared data is as follows:

[0065] Step 1: IoT device - [d] → Public cloud

[0066] The IoT device applies to the public cloud to obtain data through the request identifier.

[0067] Step 2: Public cloud - [d|f] → IoT device

[0068] The public cloud responds to the ciphertext access request of the IoT device.

[0069] Step 3: IoT device - [a|d|f] → GC

[0070] The IoT device connects to one of the GCs and sends its own device identifier (a), ciphertext (f), and request identifier (d).

[0071] Step 4: GC - [a|b|c|d|f] → KC

[0072] Once the GC receives the above message, it selects appropriate KC and DC nodes. Then, the device identifier (a), GC identifier (b), DC identifier (c), and request identifier (d) are sent to the selected KC together with the ciphertext (f).

[0073] Step 5: KC - [d] → Database

[0074] When the KC receives a decryption request for the ciphertext (f), it must extract the entry corresponding to the request from the database. The relevant entry needs to provide the request identifier (d) sent by the IoT device for the data. Therefore, the KC sends d to the database.

[0075] Step 6: Database - [d|e|h|i] → KC

[0076] The database finds the entry with the requested identifier (d) and then forwards the relevant key (e), the list of IoT devices (h) allowed to read the data, and the password parameter (i) to the KC.

[0077] Step 7: KC → [a|b|d|f|e|i] → DC

[0078] The KC checks whether the IoT device accessing the data is in the list of IoT devices (h). If it is not in h, the KC sends a notification of unauthorized access to the GC, and the GC sends a denial - of - service response to the IoT device and ends the process at this step. If it is in h, the KC sends the ciphertext (f), the extracted key (e), the password parameter (i), and a, b, and d to the DC.

[0079] Step 8: DC - [a|d|g] → GC

[0080] The DC can decrypt the requested ciphertext based on the received key and password parameter. The decrypted plaintext (g), a, and d are forwarded to the GC. It is worth noting that the DC can obtain the correct GC according to the GC identifier (b) it receives in Step 7.

[0081] Step 9: GC - [d|g] → IoT device

[0082] Once the GC receives the password service response, it forwards the decrypted data to the IoT device that requested access to the data according to the device identifier (a).

[0083] The password service system proposed by the present invention uses a combination mode of symmetric cryptography algorithms and asymmetric encryption algorithms to securely share data among password components (GC, KC, EC, and DC). Since Internet of Things (IoT) devices are typically resource-constrained, there is no need for IoT devices to participate in the encryption / decryption process. Therefore, generally, the connection between IoT devices and GC is not protected. In view of this, IoT devices can use secure transmission technologies with low computational overheads, such as splitting data into different sub-packets and adding redundancy thereto. Whether to use such technologies depends only on the security requirements of the IoT devices themselves.

[0084] In the above encryption / decryption process proposed by the present invention, the key method involved is to select appropriate KC, EC, or DC. Password service requests are distributed among different IoT devices and password components (GC, KC, EC, and DC). It is necessary to reduce the end-to-end latency while ensuring the success rate of the response to password service requests. The present invention proposes that GC selects appropriate password component nodes (KC, EC, and DC), with two characteristics of each node being mainly considered: the number of requests waiting to be completed and the available resources. On the one hand, sending password service requests to nodes with crowded queues will cause additional latency. On the other hand, sending password service requests to nodes without sufficient resources will also increase the probability of rejected requests. Therefore, in the password component node (KC, EC, and DC) selection algorithm, GC is responsible for tracking the number of requests sent to each node (α) and the number of requests received by each node (β). "α minus β" represents the number of requests waiting to be completed in each node. For example, if the total numbers of requests sent to and received by node 1 are 30 and 26 respectively, then the number of requests waiting for service at this node is 4. To balance the traffic load of the Internet of Things, GC sends requests to the password component node with the lowest α-β value.

[0085] In addition, for selecting appropriate KC and DC nodes, another factor is also important, and a compromise needs to be found between the number of successfully responded requests and the end-to-end latency. KC and DC in the full cloud-fog architecture can be any nodes in the cloud and fog layers. If a password service request is sent to a fog node, the transmission latency can be effectively reduced, but due to the resource limitations of the fog node, this password service request may also fail. On the other hand, if a password service request is sent to a cloud node, the probability of rejected requests can be effectively reduced, but additional transmission latency is also inevitable. In the password component node selection algorithm proposed by the present invention, once GC receives a password service request, it will check the status of all nodes to select appropriate KC and DC nodes. If there is a fog node with sufficient resources and its queue is not full, the password service request will be forwarded to this fog node; otherwise, GC will forward this password service request to the cloud node with the shortest queue length.

[0086] The cryptographic component node selection algorithm is shown in Algorithm 1. First, a list Q is dedicated to storing the queue length of each node. The list starts with zero and its length is equal to the total number of fog nodes and cloud nodes (line 1). GC receives a cryptographic service request (line 2), and if the request has a specified KC (line 3), one unit is reduced from the KC's queue (line 4). Similar processing is performed for EC (lines 5 to 8) and DC (lines 9 to 12), except that the request is forwarded to the IoT device that provides data (line 7) or the IoT device that accesses data (line 11). If Algorithm 1 runs to line 13, it means that the relevant component has not been selected yet. A variable (found) starts from zero (line 13), which indicates the number of fog nodes that have resources to process the current request. List H records which fog nodes have enough resources to process the request (line 14). List H is full of "False" flags, which means that the current fog node does not have enough resources to process the request. These identifiers H(f) and the number of available fog nodes (found) are updated by a loop over all fog nodes (lines 15 to 18). At this point, two available fog nodes with the shortest queue lengths are found. These fog nodes and their queue lengths will be stored in f1, f2, m1, and m2, respectively (lines 19 and 20). In the loop over all fog nodes, we can update the above variables (line 21). It is worth noting that f1 and f2 are different (line 25). A similar process to the above is to find two cloud nodes with the shortest queue lengths, which are stored in c1 and c2 (lines 28 to 36). If the GC receives an encryption request (line 37), EC is always selected from the cloud node. If there is at least one available fog node (line 38), KC is selected from the fog node. Otherwise, KC is selected from the cloud node (line 40). In this case, one unit must be added to the queue length of the selected node as EC (line 42). If the GC receives a decryption request (line 43), it must select a KC and DC based on the number of available fog nodes (found). In this case, one unit must be added to the queue length of the selected node as the DC (line 50). Finally, the queue length of the selected KC is added by one unit (line 51) and the request is forwarded to the KC node requested to request.kc. It is worth noting that the algorithm complexity of processing each cryptographic service request is O(C+F) for, where C and F are the number of cloud nodes and fog nodes, respectively.

[0087]

[0088]

[0089] The password service system proposed by the present invention can resist various mainstream network attacks. A sniffing attack is an adversary eavesdropping on network traffic. If the channel is not protected, the transmitted data may be eavesdropped. Suppose the connection between KC and EC / DC is sniffed, but due to the additional symmetric encryption protection for the links between password components in the password service structure proposed by the present invention, it is robust against sniffing attacks.

[0090] A man-in-the-middle attack is an adversary located on the middle link between the two ends of the communication, and maliciously attacks by receiving and modifying the forwarded data. The password service system proposed by the present invention is also robust against man-in-the-middle attacks. This is because the transmitted message is encrypted, and the adversary cannot tamper with the transmitted data without the relevant key.

[0091] A distributed denial-of-service attack is an adversary initiating a large number of requests, causing the password component nodes to be busy processing malicious requests, and legitimate requests cannot be effectively served. Each component of the password service system proposed by the present invention is assigned to multiple nodes. Therefore, the harm of a denial-of-service attack is not significant.

[0092] The above network attacks are the main external threats faced by the Internet of Things password service system. In addition to these attacks, there are also some internal threats. An opponent may completely or partially control one of the password components and attempt to perform malicious activities. Even if the adversary controls any of the GC / KC / EC / DC components, the password service structure proposed by the present invention is still robust against internal threats. To address the problem of plaintext leakage caused by the adversary controlling the password service component, an additional encryption layer can be added to the plaintext by the Internet of Things device. In addition, the attacked KC wants to access the encrypted data served by other KCs. However, since the shared data stored in the database is encrypted, the attacked KC cannot obtain the plaintext data.

Claims

1. A novel Internet of Things password service system, characterized in that It includes: A General Management Component (GC) for scheduling password components to specifically handle password requests for password services; An Encryption Component (EC) for reading operation instructions of password services and performing corresponding encryption operations; The General Management Component (GC) is deployed in the cloud layer, the Encryption Component (EC) is deployed in the fog layer, and the Key Management Component (KC) and Decryption Component (DC) are both deployed in the cloud layer and the fog layer; The specific encryption process for shared data in the Internet of Things is as follows: The first step: The Internet of Things device connects to a GC and sends the information required for encrypting data, including the Internet of Things device identifier a, the plaintext g to be encrypted, the list h of Internet of Things devices sharing data with the GC, and the password parameters i expected by the device; The second step: When the GC receives the encryption request from the Internet of Things device, it selects appropriate KC and EC nodes to process the current password service request, and sends the Internet of Things device identifier a, the GC identifier b, the selected EC identifier c, the plaintext g to be encrypted, the list h of Internet of Things devices sharing data with the GC, and the password parameters i expected by the device to the selected KC; The GC and EC identifiers help the KC forward the request to the selected EC and help the EC forward the response to the correct GC; The third step: When the KC receives the forwarded password service request, it adds the request identifier d to the password service request, generates one or more keys e based on the requested password parameters, and transmits the requested password information to the database to be stored, including the Internet of Things device identifier a, the request identifier d, the key e, the list h of Internet of Things devices sharing data with the GC, and the password parameters i expected by the device; The fourth step: After the password information of the current request is stored in the database, it is forwarded to the selected EC together with the plaintext g to be encrypted and the GC identifier b; The fifth step: When the EC receives the password service instruction, it encrypts the plaintext g based on the received key e and password parameters i to generate the ciphertext f, and the EC forwards the ciphertext f together with the Internet of Things device identifier a and the request identifier d to the GC; The sixth step: After the GC receives the request identifier d and the ciphertext f, it forwards the request identifier d and the ciphertext f to the Internet of Things device based on the Internet of Things device identifier a; The seventh step: The Internet of Things device uploads the ciphertext f and the request identifier d to share the encrypted data on the public cloud.

2. The novel Internet of Things password service system according to claim 1, wherein, The Internet of Things device can upload the ciphertext and its related identifiers to share the encrypted data on the public cloud. The public cloud stores all the shared data in the Internet of Things. All Internet of Things devices access data from the public cloud, but only the other Internet of Things devices listed by the Internet of Things device providing the data can decrypt and read the data.

3. The novel Internet of Things password service system according to claim 1, wherein, The process for other Internet of Things devices in the Internet of Things to access and decrypt shared data is as follows: The first step: The Internet of Things device applies to the public cloud for obtaining data through the request identifier d; The second step: The public cloud responds to the ciphertext access request of the Internet of Things device and transmits the request identifier d and the ciphertext f; The third step: The Internet of Things device connects to a GC and sends the Internet of Things device identifier a, the ciphertext f, and the request identifier d; Step 4: After the GC receives the IoT device identifier a, the ciphertext f, and the request identifier d, it selects appropriate KC and DC nodes and sends the device identifier a, the GC identifier b, the DC identifier c, the request identifier d, and the ciphertext f to the selected KC node together; Step 5: When the KC receives a decryption request for the ciphertext f, the KC sends the request identifier d to the database and extracts the entry corresponding to this decryption request in the database; Step 6: The database finds the entry with the request identifier d and forwards the relevant key e, the IoT device list h, and the password parameter i to the KC; Step 7: The KC checks whether the IoT device accessing the data is in the IoT device list h. If it is not in h, the KC sends a notification of unauthorized access to the GC, and the GC sends a denial-of-service response to the IoT device and ends this process; If it is in h, the KC sends the ciphertext f, the key e, the password parameter i, and the IoT device identifier a, the GC identifier b, and the request identifier d to the DC together; Step 8: The DC decrypts the requested ciphertext based on the received key e and password parameter i, and forwards the decrypted plaintext g, the IoT device identifier a, and the request identifier d to the GC; Step 9: When the GC receives the password service response, it sends the decrypted data to the IoT device that requested access to the data according to the device identifier a.

4. A method for selecting cryptographic component nodes, which is used to select KC, EC, and DC component nodes in the novel Internet of Things cryptographic service system described in claim 1 or claim 3, and is characterized in that, Including the following steps: S1. The list Q is used to store the queue lengths of each node. The list Q starts from zero, and its length is equal to the sum of the fog nodes and the cloud nodes; S2. The GC receives a password service request; If there is a specified KC in the password service request, the queue of the KC is reduced by one unit; S3. The EC receives a password service request; if there is a specified EC in the password service request, the queue of the EC is reduced by one unit, and the password service request is forwarded to the IoT device providing the data; S4. The DC receives a password service request; If there is a specified DC in the password service request, the queue of the DC is reduced by one unit, and the password service request is forwarded to the IoT device accessing the data; S5. If none of the KC, EC, and DC components are selected, let the variable found start from zero, representing the number of fog nodes with resources to process the current request. The list H records which fog nodes have sufficient resources to process the password service request; S6. The list H is filled with "False" flags, indicating that the current fog node does not have sufficient resources to process the request. The flag H(f) and the number of available fog nodes found are updated through a loop over all fog nodes. Two fog nodes with the shortest queue lengths are found, and these fog nodes and their queue lengths are stored in f1, f2, m1, and m2 respectively; S7. In the loop over all fog nodes, f1, f2, m1, and m2 are updated to find two cloud nodes with the shortest queue lengths, and these cloud nodes are stored in c1 and c2; S8. If the GC receives an encryption request, it always selects the EC from the cloud nodes. If there is at least one available fog node, it selects the KC from the fog nodes and adds a unit to the queue length of the selected node as the EC. S9. If the GC receives a decryption request, it selects the KC and DC based on the number found of available fog nodes and adds a unit to the queue length of the selected node as the DC. S10. Add a unit to the queue length of the selected KC and forward the request to the requested KC node request.kc.

5. The method for selecting a password component node according to claim 4, wherein The GC is responsible for tracking the number of requests α sent to each node and the number of requests β received by each node. α minus β represents the number of requests waiting to be completed in each node. To balance the traffic load of the Internet of Things, the GC sends requests to the cryptographic component node with the lowest value of α - β.

6. The method for selecting a password component node according to claim 4, characterized in that Once the GC receives a cryptographic service request, it checks the status of all nodes to select appropriate KC and DC nodes. If a fog node has sufficient resources and its queue is not full, the GC will forward the cryptographic service request to that fog node; otherwise, the GC will forward the cryptographic service request to the cloud node with the shortest queue length.

Images