Verifiable outsourcing key negotiation method based on Internet of Things scene privacy protection

Abstract

The invention discloses a verifiable outsourcing key agreement method based on Internet of Things scene privacy protection, which is applied to a key agreement system, and the key agreement system comprises a plurality of Internet of Things equipment nodes Node and a cloud service platform consisting of trusted execution hardware SGX and a cloud end Cloud. The whole key negotiation process is divided into a node registration stage and a key negotiation stage; according to the method, a trusted area is constructed on a cloud service platform by utilizing the SGX, technologies such as proxy re-encryption, kana transformation and Merkle signature tree are combined, the advantages of high credibility of the SGX and strong computing power of a cloud server are fully fused, an efficient verifiable outsourcing key negotiation method is designed, efficient and trusted cooperation of the SGX and the cloud is realized, and the security of the cloud is improved. And anonymity and non-linkability of the participants are ensured, so that privacy protection of outsourcing key negotiation is ensured.

Description

Technical Field

[0001] The present invention belongs to the field of Internet of Things and key negotiation, and in particular relates to a verifiable outsourced key negotiation method based on privacy protection in Internet of Things scenarios. Background Art

[0002] A lot of research has been done on key negotiation. However, existing solutions generally assume that all devices support a unified key negotiation protocol, which is not realistic in actual Internet of Things (IoT) scenarios. Devices in IoT may come from different network domains, and the supported key negotiation protocols may vary due to differences in hardware performance, computing power, and communication environment. Specifically, some devices may have high computing power and be able to execute complex key negotiation protocols, while other resource-constrained devices may only support lightweight protocols. In this case, when a device needs to negotiate keys with a variety of other devices, it is not always possible to find a compatible protocol. This protocol heterogeneity makes existing key negotiation schemes limited in actual application scenarios of IoT. Summary of the invention

[0003] In order to solve the above problems existing in the prior art, the present invention provides a verifiable outsourced key negotiation method based on privacy protection in IoT scenarios. The technical problem to be solved by the present invention is achieved through the following technical solutions:

[0004] A verifiable outsourced key negotiation method based on privacy protection in an Internet of Things scenario is applied to a key negotiation system, wherein the key negotiation system includes a plurality of Internet of Things device nodes Node, and a cloud service platform composed of trusted execution hardware SGX and a cloud Cloud; the method includes:

[0005] In the node registration phase, the Node as a registered node generates an initial pseudonym and key contribution seed locally, encrypts data based on the generated initial pseudonym and key contribution seed, and sends it together with its own node certificate to the cloud service platform for registration application; SGX verifies the legitimacy of the node certificate, derives and stores multiple pseudonyms and key contribution materials for the registered node after verification, and stores the mapping relationship between the pseudonym and identity of the registered node; and, whenever the number of registered nodes exceeds the set threshold T, SGX builds a new Merkle signature tree based on the stored pseudonym and key contribution materials, and updates it to the Cloud;

[0006] During the key negotiation phase, the initiating node that initiates the key negotiation encrypts and signs the identity set of the negotiation participants and the negotiation mode, and packages them together with unused pseudonyms into a key negotiation request message, and sends it to the cloud service platform; SGX authenticates the key negotiation participants by querying the mapping relationship. After the authentication is passed, SGX obtains key material from the Cloud, calculates the session key based on the key contribution of each party, and packages the session key ciphertext and the session key signature and sends them to the Cloud. The Cloud uses the proxy re-encryption technology to generate a session key ciphertext for each negotiation participant that can only be decrypted by its private key, so that each negotiation participant can decrypt the session key and update the key.

[0007] In one embodiment of the present invention, for Node as a registration node i In the node registration phase, an initial pseudonym and a key contribution seed are generated locally, data is encrypted based on the generated initial pseudonym and key contribution seed, and then sent together with the node certificate to the cloud service platform for registration application, including:

[0008] Node i According to the input safety parameters 1 λ , generate an initial temporary public-private key pair in, Represents Node i The initial temporary private key, Represents Node i The initial temporary public key of

[0009] Node i Randomly sample initial pseudonyms And key contribution seed Seed;

[0010] Node i Select the number of pseudonyms and key contribution materials to be derived, and use the SGX long-term public key pk SGX right Perform asymmetric encryption to obtain the ciphertext message C1; where || represents concatenation;

[0011] Node i Use your own long-term private key Sign the ciphertext message C1 to get the ciphertext message signature sigC1, and add the ciphertext message C1, the ciphertext message signature sigC1 and the Node i Its own node certificate Cert i Pack them together into a registration message Msg1, send it to the cloud service platform and forward it to the SGX therein;

[0012] Node iInitial temporary private key Perform a private key hash operation to obtain a new temporary private key Using initial pseudonym and temporary private key Generate new pseudonyms through hashing Will Stored locally as pseudonymous material.

[0013] In one embodiment of the present invention, for Node as a registration node i In the node registration phase, SGX verifies the legitimacy of the node certificate, derives and stores multiple pseudonyms and key contribution materials for the registered node after verification, and stores the mapping relationship between the pseudonym and identity identifier of the registered node, including:

[0014] SGX Verification Node i Node certificate Cert i The legitimacy of the node certificate is verified. i Get Node i Identity UID i and the long-term public key

[0015] SGX uses Node i The long-term public key Verify the correctness of the ciphertext message signature sigC1. After verification, use SGX's long-term private key sk SGX Decrypt the ciphertext message C1 and get Seed, n;

[0016] For each value of j in j∈{1,...,n}, SGX performs the following steps in sequence: randomly sample the secret value k j , with k j Contribute with Seed-derived key Symmetric key using SGX SGX Cryptographic key contribution Get the key contribution encryption result Temporary private key Perform a private key hash operation to obtain a new temporary private key The new temporary private key Combined with pseudonym Generate new pseudonyms through hashing SGX-based proxy re-encryption of private key SK RE and temporary private key Generate pseudonyms The corresponding proxy re-encryption key The pseudonym The corresponding proxy re-encryption key And contributed materials Merge into Add to Table PID surface;

[0017] SGX will Add to Table Node The table completes the registration, where is the UID i Pseudonym material used for the next key negotiation;

[0018] SGX will register the successful message using its own long-term private key sk SGX After signing, get message Msg2 and send it to Node i .

[0019] In one embodiment of the present invention, in the node registration phase, whenever a node is registered, the node registration number NodeCount is increased by one;

[0020] Whenever the number of registered nodes exceeds the set threshold T, SGX builds a new Merkle signature tree based on the stored pseudonyms and key contribution materials and updates it to the Cloud, including:

[0021] SGX According to Table PID The pseudonyms in the table, the corresponding proxy re-encryption keys and contribution materials, and the j-1th Merkle signature tree Tree j-1 The root node Root j-1 , construct the jth Merkle signature tree Tree j As a new Merkle signature tree;

[0022] SGX uses its own long-term private key sk SGX For the j-th Merkle signature tree Tree j The root node Root j Sign and get the root node signature sigRoot j ;

[0023] SGX will be the jth Merkle signature tree Tree j And the root node signature sigRoot j Package it into message Msg3 and send it to Cloud;

[0024] SGX sets the number of registered nodes NodeCount to 0 and clears the Table PID surface;

[0025] SGX stores the new root node locally j , and discard the old root node Rootj-1 ;

[0026] After Cloud receives the message Msg3, it sends the Tree j and sigRoot j , and the old Merkle signature tree Tree j-1 Merge, update to a complete Merkle signature tree, and store in Cloud.

[0027] In one embodiment of the present invention, for Node as the initiating node B Negotiate with another Node A In the key negotiation phase, the initiating node that initiates the key negotiation encrypts and signs the identity set of the negotiation participants and the negotiation mode, and packages them together with the unused pseudonyms into a key negotiation request message, and sends it to the cloud service platform, including:

[0028] Node B Temporary private key Perform the KDF key derivation function to obtain the corresponding symmetric key Among them, Node B The unused pseudonym is its j1th pseudonym, Node A The unused pseudonym is its j2nd pseudonym;

[0029] Node B Select the key negotiation mode Mode, and set the key negotiation mode Mode to the UID set of the key negotiation participants (UID B , UID A ) using a symmetric key Symmetric encryption is performed to obtain the ciphertext message D1; wherein the key agreement mode Mode includes DH operation and random number XOR;

[0030] Node B Unused pseudonyms The ciphertext message D1 is packaged into a key agreement request message Msg4 and sent to the SGX in the cloud service platform.

[0031] In one embodiment of the present invention, in the key negotiation phase, SGX authenticates the key negotiation participants by querying the mapping relationship. After the authentication is passed, SGX obtains key material from Cloud, calculates the session key according to the key contribution of each party, and packages the session key ciphertext and the session key signature and sends them to Cloud. The process includes:

[0032] After receiving the key negotiation request message Msg4, SGX sends the key negotiation request message to the client in the pseudonym Query Table for IndexNode table, and get the Node B Identity UID B and temporary private key

[0033] SGX is based on temporary private keys Calculate the symmetric key and use a symmetric key Decrypt the ciphertext message D1 and get UID' B , UID A , Mode, and verify whether it satisfies UID B =UID' B If not satisfied, the key negotiation operation is exited;

[0034] SGX is based on Node A Identity UID A Query Table for Index Node Table, get Node A pseudonym and temporary private key

[0035] SGX via pseudonym Query the Merkle signature tree from the Cloud to obtain key materials, which include key contribution materials and data verification materials Among them, verMrt includes the root node signature sigRoot and other auxiliary verification materials;

[0036] SGX uses its own long-term public key pk SGX Verify the correctness of the sigRoot signature and Data integrity to prevent Cloud from providing erroneous node key contributions;

[0037] SGX uses symmetric key SGX Decryption Get key contribution

[0038] SGX selects the key negotiation mode Mode and the key contribution of each party according to the negotiation participants Calculate the session key SKey and re-encrypt the public key PK using the SGX proxy RE Encrypt the session key SKey to obtain the session key ciphertext C SKey ;

[0039] SGX Computing Node B 、Node A Next time you use the pseudonym And UID B、UID A Update Table for Index Node surface;

[0040] SGX uses its own long-term private key sk SGX Sign the session key SKey to get the session key signature sigSKey, and then send the session key ciphertext C SKey The session key signature sigSKey is packaged into message Msg5 and sent to Cloud.

[0041] In one embodiment of the present invention, during the key negotiation phase, the Cloud generates a session key ciphertext for each negotiation participant that can only be decrypted using its private key by using a proxy re-encryption technology, including:

[0042] After receiving message Msg5, Cloud used pseudonyms The corresponding proxy re-encryption key For the session key ciphertext C SKey Perform proxy re-encryption to obtain ciphertext C A and C B ;

[0043] Cloud C B and sigSKey are packaged into the corresponding message Msg6 and sent to the node Node B ,Will C A and sigSKey are packaged into the corresponding message Msg6 and sent to the node Node A ;

[0044] Cloud sends the key negotiation message Insert into the key negotiation record table Record middle.

[0045] In one embodiment of the present invention, during the key negotiation phase, for Node B , as a negotiation participant, the process of decrypting the session key and updating the key includes:

[0046] After receiving message Msg6, Node B Use your own temporary private key For ciphertext C B Decrypt to get the session key SKey;

[0047] Node B Use SGX's long-term public key pk SGX Verify the correctness of the session key SKey;

[0048] Node BUsing temporary private keys Calculate the temporary private key to be used next time through hash operation

[0049]

[0050] Node B Using a pseudonym and temporary private key Calculate the next pseudonym to be used by hashing

[0051] Node B Local storage of pseudonyms for next use And temporary private key and discard the used pseudonyms and temporary private key

[0052] In the key negotiation phase, for Node A , the process of decrypting the session key and updating the key includes:

[0053] After receiving the message Msg6, Node A Use your own temporary private key For ciphertext C A Decrypt to get the session key SKey;

[0054] Node A Use SGX's long-term public key pk SGX Verify the correctness of the session key SKey;

[0055] Node A Using temporary private keys Calculate the temporary private key to be used next time through hash operation

[0056]

[0057] Node A Using a pseudonym and temporary private key Calculate the next pseudonym to be used by hashing

[0058] Node A Local storage of pseudonyms for next use And temporary private key and discard the used pseudonyms and temporary private key

[0059] In one embodiment of the present invention, during the key negotiation phase, if an IoT device node misses multiple key negotiation requests, a session key self-healing process is performed after the node is back online, including the following process:

[0060] Step a1: store pseudonymous materials locally Offline Node k , obtain the key negotiation record table of the cloud service platform during the offline period Record What's new in Table' record ;

[0061] Step a2, query Is it in Table' record middle;

[0062] Step a3, if it does not exist, it means that there is no node and Node k Initiate key negotiation and exit session key self-healing processing;

[0063] Step a4, if it exists, use the temporary private key For ciphertext C k Decrypt to obtain the session key SKey, and verify the correctness of the session key SKey;

[0064] Step a5, calculate

[0065] Step a6: repeat steps a2 to a5 above until all session keys are self-healed during the offline period. Then, node Node k Unused pseudonym materials are stored and all used pseudonym materials are discarded, completing the session key self-healing process.

[0066] In one embodiment of the present invention, in Node B Use SGX's long-term public key pk SGX After verifying the correctness of the session key SKey and after the offline IoT device node is back online and the session key self-healing process is completed, the method further includes:

[0067] The IoT device node determines whether its pseudonym and contribution material have reached the critical situation of exhaustion. If so, it re-uploads a new initial pseudonym and key contribution seed to the cloud service platform to complete the update operation of the pseudonym and contribution material to ensure the smooth progress of subsequent key negotiation.

[0068] Beneficial effects of the present invention:

[0069] Based on the idea of ​​outsourcing computing and software-hardware collaboration, the embodiment of the present invention proposes a verifiable outsourced key negotiation method based on privacy protection in IoT scenarios, aiming to solve the key negotiation problem of IoT devices in a heterogeneous algorithm environment. The present invention introduces SGX to build a trusted zone on the cloud service platform, and fully integrates the advantages of SGX's high trustworthiness and the strong computing power of cloud servers to achieve efficient outsourced key negotiation between IoT devices, while ensuring the anonymity and unlinkability of the negotiation participants.

[0070] During the key negotiation process, SGX is responsible for performing session key calculations and generating signature summaries that can be verified by the participants. In addition, in order to reduce the encryption computing overhead of SGX, the proxy re-encryption technology is used so that the cloud generates session key ciphertext for each participant that can be decrypted with its private key without touching the key. This design achieves efficient collaboration between SGX and the cloud, significantly improving the verification efficiency of the participants and the efficiency of key negotiation while ensuring the security of key negotiation.

[0071] In addition, the present invention proposes an efficient pseudonym transformation mechanism assisted by SGX. The SGX trusted environment is used to implement a one-time signature based on a pseudonym certificate, so that the participants can hide their true identities during the key negotiation process. Furthermore, the present invention combines the Merkle tree technology to reduce the signature calculation overhead of SGX, and realizes the efficient transformation of the pseudonym certificates of the participants, so that even if an attacker or a cloud service provider monitors multiple key negotiation sessions, it cannot be linked to the same participant, thereby ensuring the anonymity and unlinkability of the participants and realizing the privacy protection of verifiable outsourced key negotiation. BRIEF DESCRIPTION OF THE DRAWINGS

[0072] Figure 1 A schematic diagram of the structure of a key agreement system provided by an embodiment of the present invention;

[0073] Figure 2 A flowchart of a verifiable outsourced key negotiation method based on privacy protection in an Internet of Things scenario provided by an embodiment of the present invention;

[0074] Figure 3 A schematic diagram of the interaction process in the node registration phase of the verifiable outsourced key negotiation method based on privacy protection in Internet of Things scenarios provided by an embodiment of the present invention;

[0075] Figure 4 A schematic diagram of the interaction process in the key negotiation phase of the verifiable outsourced key negotiation method based on privacy protection in Internet of Things scenarios provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0076] The present invention is further described in detail below with reference to specific embodiments, but the embodiments of the present invention are not limited thereto.

[0077] The embodiment of the present invention provides a verifiable outsourced key negotiation method based on privacy protection in an Internet of Things scenario, which is applied to a key negotiation system, such as Figure 1 As shown in the figure, the key negotiation system includes multiple IoT device nodes Node, and a cloud service platform composed of trusted execution hardware SGX and cloud Cloud. The trusted execution hardware SGX and cloud Cloud work together to build a cloud service platform that can verify outsourced key negotiation; Node is the main participant in key negotiation, SGX is deployed in the cloud as a trusted execution environment, and a trusted zone is built in the cloud service platform. Cloud is used to provide powerful computing resources and storage resources.

[0078] For simplicity, the following IoT device nodes, trusted execution hardware, and cloud are represented by Node, SGX, and Cloud respectively.

[0079] For details, see Figure 2 The verifiable outsourced key negotiation method based on privacy protection in an Internet of Things scenario may include:

[0080] S1, in the node registration phase, the Node as a registered node generates an initial pseudonym and key contribution seed locally, encrypts the data based on the generated initial pseudonym and key contribution seed, and sends it together with its own node certificate to the cloud service platform for registration application; SGX verifies the legitimacy of the node certificate, derives and stores multiple pseudonyms and key contribution materials for the registered node after verification, and stores the mapping relationship between the pseudonym and identity of the registered node; and, whenever the number of registered nodes exceeds the set threshold T, SGX builds a new Merkle signature tree based on the stored pseudonym and key contribution materials, and updates it to the Cloud;

[0081] S2, in the key negotiation phase, the initiating node that initiates the key negotiation encrypts and signs the identity set of the negotiation participants and the negotiation mode, and packages them together with unused pseudonyms into a key negotiation request message, and sends it to the cloud service platform; SGX authenticates the key negotiation participants by querying the mapping relationship. After the authentication is passed, SGX obtains key material from the Cloud, calculates the session key based on the key contribution of each party, and packages the session key ciphertext and the session key signature and sends them to the Cloud. The Cloud uses the proxy re-encryption technology to generate a session key ciphertext for each negotiation participant that can only be decrypted by its private key, so that each negotiation participant can decrypt the session key and update the key.

[0082] To facilitate understanding of the embodiments of the present invention, the node registration phase and the key agreement phase are described below respectively.

[0083] (I) Node registration phase

[0084] For the interaction process during the node registration phase, please refer to Figure 3 For ease of understanding, we will use the node i Take the following example to illustrate the processing process of this stage, for Node as a registered node i , the specific contents of S1 are as follows:

[0085] (1) In the node registration phase, an initial pseudonym and a key contribution seed are generated locally, data is encrypted based on the generated initial pseudonym and key contribution seed, and then sent together with the node certificate to the cloud service platform for registration application, including:

[0086] ①Node i According to the input safety parameters 1 λ , generate an initial temporary public-private key pair in, Represents Node i The initial temporary private key, Represents Node i The initial temporary public key of

[0087] In this step, the initial temporary public-private key pair generated can be expressed as KeyGen represents key generation, based on security parameters 1 λ Generate an initial temporary public-private key pair The process can be realized using existing technology.

[0088] ←Symbol indicates that safety parameter 1 is obtained λ It is a common term in cryptography. According to the security parameter 1 λ Depending on the length of the key, different lengths of public and private key pairs can be generated, such as 256bit, 512bit or 1024bit.

[0089] ②Node i Randomly sample initial pseudonyms And key contribution seed Seed;

[0090] In this step, Node i Randomly sample initial pseudonyms The random sampling key contribution seed Seed can be expressed as in, represents a finite field with q elements; $ represents random sampling.

[0091] ③Node i Select the number of pseudonyms and key contribution materials to be derived, and use the SGX long-term public key pk SGX right Perform asymmetric encryption to obtain the ciphertext message C1;

[0092] Among them, || represents concatenation; n is a positive integer. In the key agreement system, all public keys are public. This step can be expressed as Indicates the use of SGX's long-term public key pk SGX Asymmetric encryption. Please refer to the prior art for the process of asymmetric encryption, which will not be described in detail here.

[0093] ④Node i Use your own long-term private key Sign the ciphertext message C1 to get the ciphertext message signature sigC1, and add the ciphertext message C1, the ciphertext message signature sigC1 and the Node i Its own node certificate Cert i Pack them together into a registration message Msg1, send it to the cloud service platform and forward it to the SGX therein;

[0094] Among them, SGX is embedded in the cloud service platform.

[0095] Node i Use your own long-term private key The process of signing the ciphertext message C1 to obtain the ciphertext message signature sigC1 can be expressed as The existing elliptic curve signature algorithm can be used to implement it; the process of packaging into a registration message Msg1 can be expressed as Msg1←(Cert i ,C1,sigC1).

[0096] ⑤Node i Initial temporary private key Perform a private key hash operation to obtain a new temporary private key Using initial pseudonym and temporary private key Generate new pseudonyms through hashing Will Stored locally as pseudonymous material.

[0097] Among them, get a new temporary private key The process can be expressed as Generate new pseudonyms The process can be expressed as SKHash means private key hash operation, and Hash means hash operation. Please refer to the relevant technical understanding for these two operations, and we will not explain them in detail here. Local storage as pseudonymous material can be represented as

[0098]

[0099] (2) After receiving the registration message Msg1, SGX verifies the legitimacy of the node certificate, derives and stores multiple pseudonyms and key contribution materials for the registered node after the verification, and stores the mapping relationship between the pseudonym and identity identifier of the registered node, including:

[0100] ①SGX Verification Node i Node certificate Cert i The legitimacy of the node certificate is verified. i Get Node i Identity UID i and the long-term public key

[0101] It is understood by those skilled in the art that the node certificate is issued and signed by a trusted authority or CA. i Node certificate Cert i The legitimacy of a certificate refers to verifying the signature of a trusted authority or CA.

[0102] After verification, the slave node certificate Cert i Get Node i Identity UID i and the long-term public key It can be expressed as parseCert means to parse and extract information from the node certificate. It can be understood that the node certificate Cert i Node is stored in i Identity UID i and the long-term public key

[0103] ②SGX uses Node i The long-term public key Verify the correctness of the ciphertext message signature sigC1. After verification, use SGX's long-term private key sk SGX Decrypt the ciphertext message C1 and get Seed, n;

[0104] Using Node i The long-term public key Verify the correctness of the ciphertext message signature sigC1 by executing Operation, the process of verifying the signature of the ciphertext message and Node i Use your own long-term private key The process of signing the ciphertext message C1 to obtain the ciphertext message signature sigC1 is corresponding, and can be understood by referring to the prior art.

[0105] After verification, use SGX's long-term private key sk SGX The process of decrypting the ciphertext message C1 can be expressed as: Seed, Indicates the use of SGX's long-term private key sk SGX Decryption.

[0106] ③For each value of j in j∈{1,...,n}, SGX performs the following processes in sequence:

[0107] A) Randomly sample the secret value k j , with k j Contribute with Seed-derived key

[0108] Similarly, the randomly sampled secret value can be expressed as k j Contribute with Seed-derived key It can be expressed as deriveContrib represents derived key contribution. The derivation function used here is not restricted and can be XOR, hash, or KDF operations, as long as the randomness and security of the derived key contribution can be ensured.

[0109] B) Using SGX's symmetric key SGX Cryptographic key contribution Get the key contribution encryption result

[0110]

[0111] This step can be expressed as Indicates the use of SGX's symmetric key Key SGX encryption.

[0112] C) For temporary private key Perform a private key hash operation to obtain a new temporary private key The new temporary private key Combined with pseudonym Generate new pseudonyms through hashing

[0113] Temporary private key Perform a private key hash operation to obtain a new temporary private key It can be expressed as SKHash is the private key hash operation.

[0114] The new temporary private key Combined with pseudonym Generate new pseudonyms through hashing It can be expressed as Hash is a hash operation.

[0115] D) SGX-based proxy re-encryption of private key SK RE and temporary private key Generate pseudonyms The corresponding proxy re-encryption key

[0116] This step can be expressed as

[0117] E) Use pseudonym The corresponding proxy re-encryption key and contributed materials Merge into Add to Table PID surface;

[0118] This step can be expressed as That is, storing pseudonymous and key contribution material.

[0119] ④SGX will Add to Table Node The table completes the registration, where is the UID i Pseudonym material used for the next key negotiation;

[0120] This step can be expressed as Among them, Table Node It reflects the mapping relationship between the pseudonym and identity of the registered node.

[0121] ⑤SGX will register the successful message using its own long-term private key sk SGX After signing, get message Msg2 and send it to Node i .

[0122] This step can be expressed as Among them, OK is the registration success message. Indicates the use of SGX's long-term private key sk SGX sign.

[0123] (3) During the node registration phase, each time a node is registered, the number of node registrations NodeCount is increased by one. To ensure the anonymity and unlinkability of the participants, the node NodeCount is realized. i The present invention adopts a k-anonymous design to obfuscate pseudonymous materials. Whenever the number of registered nodes reaches the set threshold T, SGX builds a new Merkle signature tree based on the stored pseudonyms and key contribution materials, that is, according to the local Table PIDThe table constructs a new Merkle signature tree and updates it to Cloud to construct the jth Merkle signature tree Tree j For example, whenever the number of registered nodes exceeds the set threshold T, the above process includes:

[0124] ①SGX according to Table PID The pseudonyms in the table, the corresponding proxy re-encryption keys and contribution materials, and the j-1th Merkle signature tree Tree j-1 The root node Root j-1 , construct the jth Merkle signature tree Tree j As a new Merkle signature tree;

[0125] This step can be represented as Tree j ←buildMerkle(Table PID ,Root j-1 ).

[0126] ②SGX uses its own long-term private key sk SGX For the j-th Merkle signature tree Tree j The root node Root j Sign and get the root node signature sigRoot j ;

[0127] This step can be expressed as Indicates the use of long-term private key sk SGX sign.

[0128] ③SGX will be the jth Merkle signature tree Tree j And the root node signature sigRoot j Package it into message Msg3 and send it to Cloud;

[0129] This step can be expressed as Msg3←(Tree j ,sigRoot j ).

[0130] ④SGX sets the number of registered nodes NodeCount to 0 and clears the Table PID surface;

[0131] ⑤SGX stores the new root node locally j , and discard the old root node Root j-1 ;

[0132] ⑥After receiving the message Msg3, Cloud sends the Tree j and sigRootj , and the old Merkle signature tree Tree j-1 Merge, update to a complete Merkle signature tree, and store in Cloud.

[0133] Specifically, after receiving the SGX message Msg3, Cloud executes Merge (Tree old ,Tree new ,sigRoot new ) operation, where new corresponds to j and old corresponds to j-1; (Tree j ,sigRoot j ) and the old Tree j-1 Merge, update to a complete Merkle signature tree, and store in Cloud.

[0134] (II) Key negotiation phase

[0135] For the interactive process in the key negotiation phase, see Figure 4 For ease of understanding, we will use the node B The node with the j1th pseudonym and the node with the j2th pseudonym A Initiating key negotiation is used as an example to illustrate the processing process of this stage. B Negotiate with another Node A , the specific contents of S2 are as follows:

[0136] (1) In the key negotiation phase, the initiating node that initiates the key negotiation encrypts and signs the identity set of the negotiation participants and the negotiation mode, and packages them together with the unused pseudonyms into a key negotiation request message, and sends it to the cloud service platform, including:

[0137] ①Node B Temporary private key Perform the KDF key derivation function to obtain the corresponding symmetric key

[0138]

[0139] This step can be expressed as Among them, for the temporary private key For the process of making a KDF key derivation function, please refer to the relevant technical understanding.

[0140] Among them, Node B The unused pseudonym is its j1th pseudonym, Node A The unused pseudonym is its j2nd pseudonym;

[0141] ②Node BSelect the key negotiation mode Mode, and set the key negotiation mode Mode to the UID set of the key negotiation participants (UID B , UID A ) using a symmetric key Symmetric encryption is performed to obtain the ciphertext message D1; wherein the key agreement mode Mode includes DH operation and random number XOR;

[0142] The process of obtaining the ciphertext message D1 in this step can be expressed as:

[0143] Indicates the use of symmetric keys Do symmetric encryption.

[0144] ③Node B Unused pseudonyms The ciphertext message D1 is packaged into a key agreement request message Msg4 and sent to the SGX in the cloud service platform.

[0145] This step can be expressed as

[0146] (2) In the key negotiation phase, SGX authenticates the key negotiation participants by querying the mapping relationship. After the authentication is passed, SGX obtains key material from Cloud, calculates the session key based on the key contributions of each party, and packages the session key ciphertext and session key signature and sends them to Cloud. The process includes:

[0147] ① After receiving the key negotiation request message Msg4, SGX uses a pseudonym Query Table for Index Node table, and get the Node B Identity UID B and temporary private key

[0148] This step can be represented as UID B ,

[0149] ②SGX is based on temporary private keys Calculate the symmetric key and use a symmetric key Decrypt the ciphertext message D1 and get UID' B , UID A , Mode, and verify whether it satisfies UID B =UID' B If not satisfied, the key negotiation operation is exited;

[0150] SGX is based on temporary private keys Calculate the symmetric key It can be expressed as:

[0151]

[0152] Using symmetric keys The decrypted ciphertext message D1 can be expressed as:

[0153]

[0154] Verify whether UID is satisfied B =UID' B If not satisfied, the key negotiation operation is exited, which is expressed as:

[0155] check if UID B ≠UID' B →Aborts: Aborts means exiting the key negotiation operation.

[0156] ③SGX is based on Node A Identity UID A Query Table for Index Node Table, get Node A pseudonym and temporary private key

[0157] This step can be expressed as:

[0158] ④SGX through pseudonym Query the Merkle signature tree from the Cloud to obtain key materials, which include key contribution materials and data verification materials Among them, verMrt includes the root node signature sigRoot and other auxiliary verification materials;

[0159] This step can be expressed as:

[0160] ⑤SGX uses its own long-term public key pk SGX Verify the correctness of the sigRoot signature and Data integrity to prevent Cloud from providing erroneous node key contributions;

[0161] This step is performed by SGX

[0162] ⑥SGX uses symmetric key Key SGX Decryption Get key contribution

[0163] This step can be expressed as:

[0164] ⑦SGX selects the key negotiation mode Mode and the key contribution of each participant according to the negotiation participants Calculate the session key SKey and re-encrypt the public key PK using the SGX proxy RE Encrypt the session key SKey to obtain the session key ciphertext C SKey ;

[0165] The calculation of the session key SKey can be expressed as Get the session key ciphertext C SKey It can be expressed as Indicates that the public key PK is re-encrypted using the SGX proxy RE Do encryption.

[0166] ⑧SGX Computing Node B Node A Next time you use the pseudonym And UID B 、UID A Update Table for Index Node surface;

[0167] This step can be expressed as:

[0168]

[0169] ⑨SGX uses its own long-term private key sk SGX Sign the session key SKey to get the session key signature sigSKey, and then send the session key ciphertext C SKey The session key signature sigSKey is packaged into message Msg5 and sent to Cloud.

[0170] The packaged message Msg5 can be expressed as: Msg5←(C SKey ,sigSKey).

[0171] (3) In the key negotiation phase, Cloud generates a session key ciphertext for each negotiation participant that can only be decrypted using its private key through proxy re-encryption technology, including:

[0172] ①After receiving message Msg5, Cloud used pseudonyms The corresponding proxy re-encryption key For the session key ciphertext C SKey Perform proxy re-encryption to obtain ciphertext C A and C B ;

[0173] This step can be expressed as ReEnc indicates proxy re-encryption.

[0174] ②Cloud will C B and sigSKey are packaged into the corresponding message Msg6 and sent to the node Node B ,Will C A and sigSKey are packaged into the corresponding message Msg6 and sent to the node Node A ;

[0175] For Node B , this step can be expressed as For Node A , this step can be expressed as

[0176] ③Cloud sends the key negotiation message Insert into the key negotiation record table Record middle.

[0177] (4) In the key negotiation phase, as a negotiation participant, the process of decrypting the session key and updating the key is similar, specifically:

[0178] 1) In the key negotiation phase, for Node B , as a negotiation participant, the process of decrypting the session key and updating the key includes:

[0179] ①After receiving message Msg6, Node B Use your own temporary private key For ciphertext C B Decrypt to get the session key SKey;

[0180] This step can be expressed as

[0181] ②Node B Use SGX's long-term public key pk SGX Verify the correctness of the session key SKey;

[0182] This step can be expressed as

[0183] ③Node B Using temporary private keys Calculate the temporary private key to be used next time through hash operation

[0184]

[0185] This step can be expressed as

[0186] ④Node B Using a pseudonym and temporary private key Calculate the next pseudonym to be used by hashing

[0187] This step can be expressed as

[0188] ⑤Node B Local storage of pseudonyms for next use And temporary private key and discard the used pseudonyms and temporary private key

[0189] This step can be expressed as

[0190] 2) In the key negotiation phase, for Node A , the process of decrypting the session key and updating the key includes:

[0191] ①After receiving message Msg6, Node A Use your own temporary private key For ciphertext C A Decrypt to get the session key SKey;

[0192] ②Node A Use SGX's long-term public key pk SGX Verify the correctness of the session key SKey;

[0193] ③Node A Using temporary private keys Calculate the temporary private key to be used next time through hash operation

[0194]

[0195] ④Node A Using a pseudonym and temporary private key Calculate the next pseudonym to be used by hashing

[0196] ⑤Node A Local storage of pseudonyms for next use And temporary private key and discard the used pseudonyms and temporary private key

[0197] Through the above processing, the IoT device node Node participating in the key negotiation B and Node A Both can decrypt the session key and update the key, thus completing the key negotiation.

[0198] In the embodiment of the present invention, since each node has differences in computing power and communication environment, the key negotiation protocols supported may be different. The Node uses the cloud service platform to negotiate keys with other nodes. In this process, the Node uses a pseudonym to outsource key negotiation and uses the signature summary generated by SGX to verify the decrypted session key. In the node registration phase, SGX derives pseudonym materials and key contribution materials for the node. During the key negotiation process, SGX is responsible for performing session key calculations and generating signature summaries that can be verified by the participating parties. By working in collaboration with the cloud, SGX uses proxy re-encryption technology to generate decryptable key ciphertext for each Node without exposing the key. During the key negotiation process, Cloud uses proxy re-encryption technology to generate session key ciphertext that can be decrypted by its private key for each participant without direct access to the session key. In addition, Cloud is also responsible for the storage and retrieval functions of pseudonyms and key contribution materials to ensure that SGX can be accessed efficiently.

[0199] In the embodiment of the present invention, if a node misses multiple key negotiation requests during the offline period, the solution of the present invention can not only realize the self-healing of the offline node session key, but also ensure anonymity and unlinkability. Node i This article describes in detail the process of performing session key self-healing after going offline and coming back online.

[0200] During the key negotiation phase, if an IoT device node misses multiple key negotiation requests, it will perform session key self-healing processing after coming back online, including the following process:

[0201] Step a1: store pseudonymous materials locally Offline Node k , obtain the key negotiation record table of the cloud service platform during the offline period Record What's new in Table' record ;

[0202] Step a2, query Is it in Table' record middle;

[0203] Step a3, if it does not exist, it means that there is no node and Node kInitiate key negotiation and exit session key self-healing processing;

[0204] Step a4, if it exists, use the temporary private key For ciphertext C k Decrypt to obtain the session key SKey, and verify the correctness of the session key SKey;

[0205] Step a5, calculate

[0206] Please refer to the previous related process for understanding this step.

[0207] Step a6: repeat steps a2 to a5 above until all session keys are self-healed during the offline period. Then, node Node k Unused pseudonym materials are stored and all used pseudonym materials are discarded, completing the session key self-healing process.

[0208] Furthermore, in the embodiment of the present invention, in Node B Use SGX's long-term public key pk SGX After verifying the correctness of the session key SKey and after the offline IoT device node is back online and the session key self-healing process is completed, the method further includes:

[0209] The IoT device node determines whether its pseudonym and contribution material have reached the critical situation of exhaustion. If so, it re-uploads a new initial pseudonym and key contribution seed to the cloud service platform to complete the update operation of the pseudonym and contribution material to ensure the smooth progress of subsequent key negotiation.

[0210] Re-upload the new initial pseudonym and key contribution seed to the cloud service platform to complete the update operation of the pseudonym and contribution material. Please refer to the relevant content of the node registration stage for understanding, and no repetition will be given here.

[0211] The solution of the embodiment of the present invention can be used in drone key negotiation scenarios, etc. For drone key negotiation, the IoT device node Node is a drone, and multiple drone nodes form a cluster to perform collaborative operations. They need to share information such as location, speed, heading, and mission in real time. In order to prevent malicious attackers from eavesdropping or tampering, key negotiation is required to ensure secure transmission.

[0212] Based on the idea of ​​outsourcing computing and software-hardware collaboration, the embodiment of the present invention proposes a verifiable outsourced key negotiation method based on privacy protection in IoT scenarios, aiming to solve the key negotiation problem of IoT devices in a heterogeneous algorithm environment. The present invention introduces SGX to build a trusted zone on the cloud service platform, and fully integrates the advantages of SGX's high trustworthiness and the strong computing power of cloud servers to achieve efficient outsourced key negotiation between IoT devices, while ensuring the anonymity and unlinkability of the negotiation participants.

[0213] During the key negotiation process, SGX is responsible for performing session key calculations and generating signature summaries that can be verified by the participants. In addition, in order to reduce the encryption computing overhead of SGX, the proxy re-encryption technology is used so that the cloud generates session key ciphertext for each participant that can be decrypted with its private key without touching the key. This design achieves efficient collaboration between SGX and the cloud, significantly improving the verification efficiency of the participants and the efficiency of key negotiation while ensuring the security of key negotiation.

[0214] In addition, the present invention proposes an efficient pseudonym transformation mechanism assisted by SGX. The SGX trusted environment is used to implement a one-time signature based on a pseudonym certificate, so that the participants can hide their true identities during the key negotiation process. Furthermore, the present invention combines the Merkle tree technology to reduce the signature calculation overhead of SGX, and realizes the efficient transformation of the pseudonym certificates of the participants, so that even if an attacker or a cloud service provider monitors multiple key negotiation sessions, it cannot be linked to the same participant, thereby ensuring the anonymity and unlinkability of the participants and realizing the privacy protection of verifiable outsourced key negotiation.

[0215] It should be noted that, in the description of the present invention, the terms "first" and "second" are used for descriptive purposes only and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. In the description of the present invention, the meaning of "plurality" is two or more, unless otherwise clearly and specifically defined.

[0216] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification.

[0217] The above description is only a preferred embodiment of the present invention and is not intended to limit the protection scope of the present invention. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention are included in the protection scope of the present invention.

Claims

1. A verifiable outsourced key negotiation method based on privacy protection in Internet of Things scenarios, characterized in that: Applied to a key negotiation system, the key negotiation system includes a plurality of IoT device nodes Node, and a cloud service platform composed of trusted execution hardware SGX and cloud Cloud; the method includes: In the node registration phase, the Node as a registered node generates an initial pseudonym and key contribution seed locally, encrypts data based on the generated initial pseudonym and key contribution seed, and sends it together with its own node certificate to the cloud service platform for registration application; SGX verifies the legitimacy of the node certificate, derives and stores multiple pseudonyms and key contribution materials for the registered node after verification, and stores the mapping relationship between the pseudonym and identity of the registered node; and, whenever the number of registered nodes exceeds the set threshold T, SGX builds a new Merkle signature tree based on the stored pseudonym and key contribution materials, and updates it to the Cloud; During the key negotiation phase, the initiating node that initiates the key negotiation encrypts and signs the identity set of the negotiation participants and the negotiation mode, and packages them together with unused pseudonyms into a key negotiation request message, and sends it to the cloud service platform; SGX authenticates the key negotiation participants by querying the mapping relationship. After the authentication is passed, SGX obtains key material from the Cloud, calculates the session key based on the key contribution of each party, and packages the session key ciphertext and the session key signature and sends them to the Cloud. The Cloud uses the proxy re-encryption technology to generate a session key ciphertext for each negotiation participant that can only be decrypted by its private key, so that each negotiation participant can decrypt the session key and update the key.

2. The method according to claim 1, characterized in that For Node as a registered node i In the node registration phase, an initial pseudonym and a key contribution seed are generated locally, data is encrypted based on the generated initial pseudonym and key contribution seed, and then sent together with the node certificate to the cloud service platform for registration application, including: Node i According to the input safety parameters 1 λ , generate an initial temporary public-private key pair in, Represents Node i The initial temporary private key, Represents Node i The initial temporary public key of Node i Randomly sample initial pseudonyms And key contribution seed Seed; Node i Select the number of pseudonyms and key contribution materials to be derived, and use the SGX long-term public key pk SGX right Perform asymmetric encryption to obtain the ciphertext message C1; where || represents concatenation; Node i Use your own long-term private key sk Nodei Sign the ciphertext message C1 to get the ciphertext message signature sigC1, and add the ciphertext message C1, the ciphertext message signature sigC1 and the Node i Its own node certificate Cert i Pack them together into a registration message Msg1, send it to the cloud service platform and forward it to the SGX therein; Node i Initial temporary private key Perform a private key hash operation to obtain a new temporary private key Using initial pseudonym and temporary private key Generate new pseudonyms through hashing Will Stored locally as pseudonymous material.

3. The method according to claim 2, characterized in that For Node as a registered node i In the node registration phase, SGX verifies the legitimacy of the node certificate, derives and stores multiple pseudonyms and key contribution materials for the registered node after verification, and stores the mapping relationship between the pseudonym and identity of the registered node, including: SGX Verification Node i Node certificate Cert i The legitimacy of the node certificate is verified. i Get Node i Identity UID i and the long-term public key SGX uses Node i The long-term public key Verify the correctness of the ciphertext message signature sigC1. After verification, use SGX's long-term private key sk SGX Decrypt the ciphertext message C1 and get Seed, n; For each value of j in j∈{1,...,n}, SGX performs the following steps in sequence: randomly sample the secret value k j , with k j Contribute with Seed-derived key Symmetric key using SGX SGX Cryptographic key contribution Get the key contribution encryption result Temporary private key Perform a private key hash operation to obtain a new temporary private key The new temporary private key Combined with pseudonym Generate new pseudonyms through hashing SGX-based proxy re-encryption of private key SK RE and temporary private key Generate pseudonyms The corresponding proxy re-encryption key The pseudonym The corresponding proxy re-encryption key and contributed materials Merge into Add to Table PID surface; SGX will Add to Table Node The table completes the registration, where is the UID i Pseudonym material used for the next key negotiation; SGX will register the successful message using its own long-term private key sk SGX After signing, get message Msg2 and send it to Node i .

4. The method according to claim 3, characterized in that During the node registration phase, whenever a node is registered, the number of node registrations NodeCount increases by one; Whenever the number of registered nodes exceeds the set threshold T, SGX builds a new Merkle signature tree based on the stored pseudonyms and key contribution materials and updates it to the Cloud, including: SGX According to Table PID The pseudonyms in the table, the corresponding proxy re-encryption keys and contribution materials, and the j-1th Merkle signature tree Tree j-1 The root node Root j-1 , construct the jth Merkle signature tree Tree j As a new Merkle signature tree; SGX uses its own long-term private key sk SGX For the j-th Merkle signature tree Tree j The root node Root j Sign and get the root node signature sigRoot j ; SGX will be the jth Merkle signature tree Tree j And the root node signature sigRoot j Package it into message Msg3 and send it to Cloud; SGX sets the number of registered nodes NodeCount to 0 and clears the Table PID surface; SGX stores the new root node locally j , and discard the old root node Root j-1 ; After Cloud receives the message Msg3, it sends the Tree j and sigRoot j , and the old Merkle signature tree Tree j-1 Merge, update to a complete Merkle signature tree, and store in Cloud.

5. The method according to claim 4, characterized in that For the Node that is the initiating node B Negotiate with another Node A In the key negotiation phase, the initiating node that initiates the key negotiation encrypts and signs the identity set of the negotiation participants and the negotiation mode, and packages them together with the unused pseudonyms into a key negotiation request message, and sends it to the cloud service platform, including: Node B Temporary private key Perform the KDF key derivation function to obtain the corresponding symmetric key Among them, Node B The unused pseudonym is its j1th pseudonym, Node A The unused pseudonym is its j2nd pseudonym; Node B Select the key negotiation mode Mode, and set the key negotiation mode Mode to the UID set of the key negotiation participants (UID B , UID A ) using a symmetric key Symmetric encryption is performed to obtain the ciphertext message D1; wherein the key agreement mode Mode includes DH operation and random number XOR; Node B Unused pseudonyms The ciphertext message D1 is packaged into a key agreement request message Msg4 and sent to the SGX in the cloud service platform.

6. The method according to claim 5, characterized in that In the key negotiation phase, SGX authenticates the key negotiation participants by querying the mapping relationship. After the authentication is passed, SGX obtains key materials from Cloud, calculates the session key according to the key contributions of each party, and packages the session key ciphertext and session key signature and sends them to Cloud. The process includes: After receiving the key negotiation request message Msg4, SGX sends the key negotiation request message to the client in the pseudonym Query Table for Index Node table, and get the Node B Identity UID B and temporary private key SGX is based on temporary private keys Calculate the symmetric key and use a symmetric key Decrypt the ciphertext message D1 and get UID' B , UID A , Mode, and verify whether it satisfies UID B =UID' B If not satisfied, the key negotiation operation is exited; SGX is based on Node A Identity UID A Query Table for Index Node Table, get Node A pseudonym and temporary private key SGX via pseudonym Query the Merkle signature tree from the Cloud to obtain key materials, which include key contribution materials and data verification materials Among them, verMrt includes the root node signature sigRoot and other auxiliary verification materials; SGX uses its own long-term public key pk SGX Verify the correctness of the sigRoot signature and Data integrity to prevent Cloud from providing erroneous node key contributions; SGX uses symmetric key SGX Decryption Get key contribution SGX selects the key negotiation mode Mode and the key contribution of each party according to the negotiation participants Calculate the session key SKey and re-encrypt the public key PK using the SGX proxy RE Encrypt the session key SKey to obtain the session key ciphertext C SKey ; SGX Computing Node B Node A Next time you use the pseudonym And UID B 、UID A Update Table for Index Node surface; SGX uses its own long-term private key sk SGX Sign the session key SKey to get the session key signature sigSKey, and then send the session key ciphertext C SKey The session key signature sigSKey is packaged into message Msg5 and sent to Cloud.

7. The method according to claim 6, characterized in that In the key negotiation phase, Cloud generates a session key ciphertext for each negotiation participant that can only be decrypted with its private key through proxy re-encryption technology, including: After receiving Msg5, Cloud used pseudonyms The corresponding proxy re-encryption key For the session key ciphertext C SKey Perform proxy re-encryption to obtain ciphertext C A and C B ; Cloud C B and sigSKey are packaged into the corresponding message Msg6 and sent to the node Node B ,Will C A and sigSKey are packaged into the corresponding message Msg6 and sent to the node Node A ; Cloud sends the key negotiation message Insert into the key negotiation record table Record middle.

8. The method according to claim 7, characterized in that In the key negotiation phase, for Node B , as a negotiation participant, the process of decrypting the session key and updating the key includes: After receiving the message Msg6, Node B Use your own temporary private key For ciphertext C B Decrypt to get the session key SKey; Node B Use SGX's long-term public key pk SGX Verify the correctness of the session key SKey; Node B Using temporary private keys Calculate the temporary private key to be used next time through hash operation Node B Using a pseudonym and temporary private key Calculate the next pseudonym to be used by hashing Node B Local storage of pseudonyms for next use And temporary private key and discard the used pseudonyms and temporary private key In the key negotiation phase, for Node A , the process of decrypting the session key and updating the key includes: After receiving the message Msg6, Node A Use your own temporary private key For ciphertext C A Decrypt to get the session key SKey; Node A Use SGX's long-term public key pk SGX Verify the correctness of the session key SKey; Node A Using temporary private keys Calculate the temporary private key to be used next time through hash operation Node A Using a pseudonym and temporary private key Calculate the next pseudonym to be used by hashing Node A Local storage of pseudonyms for next use And temporary private key and discard the used pseudonyms and temporary private key 9. The method according to claim 8, characterized in that During the key negotiation phase, if an IoT device node misses multiple key negotiation requests, it will perform session key self-healing processing after coming back online, including the following process: Step a1: store pseudonymous materials locally Offline Node k , obtain the key negotiation record table of the cloud service platform during the offline period Record What's new in Table' record ; Step a2, query Is it in Table' record middle; Step a3, if it does not exist, it means that there is no node and Node k Initiate key negotiation and exit session key self-healing processing; Step a4, if it exists, use the temporary private key For ciphertext C k Decrypt to obtain the session key SKey, and verify the correctness of the session key SKey; Step a5, calculate Step a6: repeat the above steps a2 to a5 until all session keys are self-healed during the offline period. Then, the node Node k Unused pseudonym materials are stored and all used pseudonym materials are discarded, completing the session key self-healing process.

10. The method according to claim 9, characterized in that In Node B Use SGX's long-term public key pk SGX After verifying the correctness of the session key SKey and after the offline IoT device node is back online and the session key self-healing process is completed, the method further includes: The IoT device node determines whether its pseudonym and contribution material have reached the critical situation of exhaustion. If so, it re-uploads a new initial pseudonym and key contribution seed to the cloud service platform to complete the update operation of the pseudonym and contribution material to ensure the smooth progress of subsequent key negotiation.

Images