A verifiable outsourcing key agreement method based on privacy protection of internet of things scene

Abstract

The application discloses a verifiable outsourcing key agreement method based on scene privacy protection of Internet of Things, and is applied to a key agreement system, wherein the key agreement system comprises a plurality of Internet of Things device nodes Node, and a cloud service platform composed of trusted execution hardware SGX and a cloud end Cloud, and the whole key agreement process is divided into a node registration stage and a key agreement stage; the application utilizes the SGX to construct a trusted area in the cloud service platform, combines proxy re-encryption, pseudonym transformation and Merkle signature tree and other technologies, fully integrates the advantages of high trustworthiness of the SGX and strong computing power of the cloud server, designs an efficient verifiable outsourcing key agreement method, realizes efficient and trustworthy cooperation of the SGX and the cloud end, ensures the anonymity and unlinkability of the participants, and thus guarantees the privacy protection of the outsourcing key agreement.

Description

TECHNICAL FIELD

[0001] The application belongs to the field of Internet of Things and key agreement, and particularly relates to a verifiable outsourcing key agreement method based on privacy protection of an Internet of Things scene. BACKGROUND

[0002] A large number of researches have been conducted in the field of key agreement, however, the existing schemes generally assume that all devices support a unified key agreement protocol, which is not realistic in actual Internet of Things (IoT) scenes. Devices in the Internet of Things may come from different network domains, and due to differences in hardware performance, computing power and communication environment, the supported key agreement protocols may be different. Specifically, some devices may have high computing power and be able to perform complex key agreement protocols, while other resource-constrained devices may only support lightweight protocols. In this case, when a device needs to perform key agreement with diversified other devices, a compatible protocol cannot always be found, and such protocol heterogeneity makes the existing key agreement schemes have limitations in actual application scenarios of the Internet of Things. SUMMARY

[0003] In order to solve the above problems existing in the prior art, the application provides a verifiable outsourcing key agreement method based on privacy protection of an Internet of Things scene. The technical problem to be solved by the application is solved by the following technical scheme:

[0004] A verifiable outsourcing key agreement method based on privacy protection of an Internet of Things scene, applied to a key agreement system, the key agreement system comprising a plurality of Internet of Things device nodes Node, and a cloud service platform composed of a trusted execution hardware SGX and a cloud Cloud; the method comprising:

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

[0006] In the key agreement phase, an initiating node initiating the key agreement encrypts and signs a set of identity identifiers of the negotiation participants and a negotiation mode, and packs the same together with an unused pseudonym into a key agreement request message, and sends the key agreement request message to the cloud service platform; the SGX performs identity authentication on the key agreement participants by querying the mapping relationship, and after the authentication is passed, the SGX obtains key material from the Cloud, and calculates a session key from the key contribution of each party, packs the session key ciphertext and the session key signature into a message, and sends the message to the Cloud; the Cloud generates, by using a proxy re-encryption technology, a session key ciphertext that can be decrypted only by using a private key of each negotiation participant, so that each negotiation participant decrypts the session key and performs key update.

[0007] In an embodiment of the application, for a Node i as a registered node, in the node registration phase, an initial pseudonym and a key contribution seed are generated locally, and after data encryption based on the generated initial pseudonym and the key contribution seed, the data is sent together with a node certificate of the Node

[0008] Node i According to an input security parameter 1 λ , an initial temporary public-private key pair is generated wherein, represents an initial temporary private key of the Node i , and represents an initial temporary public key of the Node i .

[0009] The Node i randomly samples an initial pseudonym and a key contribution seed Seed.

[0010] The Node i selects a number n of pseudonyms and key contribution materials that need to be derived, and performs asymmetric encryption on using a long-term public key pk SGX of the SGX to obtain a ciphertext message C1; wherein || represents splicing.

[0011] The Node i performs signature on the ciphertext message C1 using a long-term private key of the Node i to obtain a ciphertext message signature sigC1, packs the ciphertext message C1, the ciphertext message signature sigC1, and a node certificate Cert of the Node i together into a registration message Msg1, and sends the registration message Msg1 to the cloud service platform and forwards the registration message Msg1 to the SGX in the cloud service platform.

[0012] The Node iOn the initial temporary private key Do private key hash operation, get new temporary private key Use the initial pseudonym And the temporary private key Generate a new pseudonym through hash operation As a pseudonym material Local storage.

[0013] In an embodiment of the present application, for Node i As a registered node, in the node registration stage, the process of SGX verifying the legitimacy of the node certificate, after verification, deriving multiple pseudonyms and key contribution materials for the registered node and storing, and storing the mapping relationship between the pseudonym and the identity of the registered node, includes:

[0014] SGX verifies the legitimacy of the node certificate Cert i of Node i , after verification, obtains the identity UID i and the long-term public key of Node i from the node certificate Cert i

[0015] SGX verifies the correctness of the ciphertext message signature sigC1 using the long-term public key i of Node , after verification, decrypts the ciphertext message C1 using the long-term private key sk SGX of SGX, and obtains Seed, n;

[0016] For each j in {1,...,n}, SGX executes the following process in turn: randomly sampling secret value k j , deriving key contribution j from k SGX and Seed using the symmetric key Key of SGX to encrypt the key contribution , get key contribution encryption result On the temporary private key Do private key hash operation, get new temporary private key Combine the new temporary private key with the pseudonym Generate a new pseudonym through hash operation Based on the proxy re-encryption private key SK RE of SGX and the temporary private key Generate pseudonym Corresponding proxy re-encryption key The pseudonym Corresponding proxy re-encryption key and contribution material merge into add to Table PID Table

[0017] SGX will add to Table Node Table to complete the registration, where is the UID i pseudonym material for the next key agreement;

[0018] SGX will sign the registration success message with its own long-term private key sk SGX After getting the message Msg2, send it to Node i .

[0019] In an embodiment of the present application, in the node registration phase, every time a node registers, the number of registered nodes NodeCount is incremented by one;

[0020] Every time the number of registered nodes exceeds the set threshold T, SGX constructs a new Merkle signature tree based on the stored pseudonym and key contribution material, and updates it to the Cloud's process, including:

[0021] SGX constructs the jth Merkle signature tree Tree PID as a new Merkle signature tree according to the pseudonym, the corresponding proxy re-encryption key and the contribution material in Table j-1 , and the root node Root j-1 of the (j-1)th Merkle signature tree Tree j .

[0022] SGX signs the root node Root SGX of the jth Merkle signature tree Tree j with its own long-term private key sk j to get the root node signature sigRoot j .

[0023] SGX packs the jth Merkle signature tree Tree j and the root node signature sigRoot j into a message Msg3 and sends it to the Cloud;

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

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

[0026] After receiving message Msg3, Cloud will send the Tree carried within it. j and sigRoot j , with the old Merkle signature tree j-1 Merge, update into a complete Merkle signature tree, and store in the cloud.

[0027] In one embodiment of the present invention, for the Node acting as the initiating node B With another negotiating party, 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 unused pseudonyms into a key negotiation request message, which is then sent to the cloud service platform. This process includes:

[0028] Node B For temporary private keys Perform KDF key derivation functions to obtain the corresponding symmetric key. Among them, Node B An unused alias is its j1st alias, Node A An unused pseudonym is its j2nd pseudonym;

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

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

[0031] In one embodiment of the present invention, during the key negotiation phase, SGX authenticates the participants in the key negotiation by querying the mapping relationship. After successful authentication, SGX obtains key materials from the Cloud, calculates the session key based on the key contributions of each party, and packages and sends the session key ciphertext and session key signature to the Cloud. The process includes:

[0032] Upon receiving the key negotiation request message Msg4, SGX, under a pseudonym... For indexed queries TableNode The table is used to obtain the Node. B Identity identifier UID B and temporary private key

[0033] SGX is based on temporary private keys Calculate the symmetric key Using symmetric keys Decrypt the ciphertext message D1 to obtain the UID' B UID A , Mode, and verify if the UID is satisfied. B =UID' B If the conditions are not met, the key negotiation operation will be terminated.

[0034] SGX with Node A Identity identifier UID A For indexed queries Table Node Table, get Node A kana and temporary private key

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

[0036] SGX uses its own long-term public key to perform a PK. SGX Verify the correctness of the sigRoot signature and Data integrity is ensured to prevent the Cloud from providing incorrect node key contributions.

[0037] SGX uses a symmetric key. SGX Decryption Obtain key contribution

[0038] SGX determines the key negotiation mode selected by the negotiation participants and the key contributions of each participant. 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 compute Node B Node A Next time using kana materials and with UID BUID A Update the table for index Node surface;

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

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

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

[0043] Cloud will C B Package the sigSKey message into a corresponding Msg6 message and send it to the Node. B ,Will C A Package the sigSKey message into a corresponding Msg6 message and send it to the Node. A ;

[0044] Cloud will send key negotiation messages 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 participant in the negotiation, 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 Decryption yields the session key SKey;

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

[0048] Node BUsing a temporary private key Calculating the next temporary private key by hash operation

[0049] Node B Using a pseudonym And a temporary private key Calculating the next pseudonym by hash operation

[0050] Node B Locally storing the next pseudonym And a temporary private key And discarding the used pseudonym And a temporary private key

[0051] In the key agreement phase, for the Node A , the process of session key decryption and key update is carried out, including:

[0052] After receiving the message Msg6, the Node A Uses its own temporary private key To decrypt the ciphertext C A To obtain the session key SKey;

[0053] The Node A Uses the long-term public key pk SGX Of SGX to verify the correctness of the session key SKey;

[0054] The Node A Uses a temporary private key Calculates the next temporary private key by hash operation

[0055] Node A Using a pseudonym And a temporary private key Calculating the next pseudonym by hash operation

[0056] Node A Locally storing the next pseudonym And a temporary private key And discarding the used pseudonym And a temporary private key

[0057] In an embodiment of the present application, in the key agreement phase, if an Internet of Things device node misses multiple key agreement requests, after reconnection, the session key self-recovery process is performed, including the following processes:

[0058] Step a1, for the offline node Node which locally stores pseudonym materials k , obtain the new content Table' Record in the key negotiation record table Table record of the cloud service platform during the offline period

[0059] Step a2, query whether it exists in Table' record

[0060] Step a3, if it does not exist, it means that no node initiates key negotiation with Node k during the offline period, and the session key self-recovery process is exited

[0061] Step a4, if it exists, the temporary private key is used to decrypt the ciphertext C k to obtain the session key SKey, and the correctness of the session key SKey is verified

[0062] Step a5, calculate

[0063] Step a6, repeat the above steps a2-a5 until the self-recovery of all session keys during the offline period is completed; then the node Node k stores the unused pseudonym materials and discards all used pseudonym materials, and completes the session key self-recovery process.

[0064] In an embodiment of the present application, after the node Node B verifies the correctness of the session key SKey using the long-term public key pk SGX of SGX, and after the session key self-recovery process is completed after the offline Internet of Things device node is reconnected online, the method further comprises:

[0065] The Internet of Things device node judges whether its pseudonym and contribution materials reach the exhaustion critical situation, if so, it re-uploads new initial pseudonym and key contribution seed to the cloud service platform, completes the update operation of the pseudonym and contribution materials, and ensures the smooth progress of subsequent key negotiation.

[0066] The beneficial effects of the present application are:

[0067] ​The application embodiment based on outsourcing computing and soft and hard collaborative ideas proposes a verifiable outsourcing key agreement method based on privacy protection of Internet of Things scene, aiming to solve the key agreement problem of Internet of Things devices in an algorithm heterogeneous environment. The application introduces SGX to build a trusted area in a cloud service platform, and fully integrates the advantages of high trustworthiness of SGX and strong computing power of the cloud server, realizes efficient outsourcing key agreement between Internet of Things devices, and ensures the anonymity and unlinkability of the participants.

[0068] In the key agreement process, SGX is responsible for performing session key calculation and generating a signed digest for participants to verify. In addition, in order to reduce the encryption calculation overhead of SGX, proxy re-encryption technology is used, so that the cloud can generate session key ciphertext for each participant which can be decrypted by its private key without touching the key. This design realizes efficient collaboration of SGX and the cloud, ensures the security of key agreement, and significantly improves the verification efficiency of participants and the efficiency of key agreement.

[0069] Furthermore, the application proposes an efficient pseudonym transformation mechanism assisted by SGX. The use of SGX trusted environment realizes one-time signature based on pseudonym certificate, so that participants can hide their real identity in the key agreement process. Further, the application combines Merkle tree technology to reduce the signature calculation overhead of SGX, realizes efficient transformation of the pseudonym certificate of the participant, so that even if an attacker or cloud service provider monitors multiple key agreement sessions, it cannot link them to the same participant, ensuring the anonymity and unlinkability of the participant, and realizing the privacy protection of the verifiable outsourcing key agreement. BRIEF DESCRIPTION OF DRAWINGS

[0070] Figure 1 The structure diagram of the key agreement system provided by the application embodiment;

[0071] Figure 2 The flowchart of the verifiable outsourcing key agreement method based on privacy protection of Internet of Things scene provided by the application embodiment;

[0072] Figure 3 The interaction process diagram of the node registration stage in the verifiable outsourcing key agreement method based on privacy protection of Internet of Things scene provided by the application embodiment;

[0073] Figure 4 The interaction process diagram of the key agreement stage in the verifiable outsourcing key agreement method based on privacy protection of Internet of Things scene provided by the application embodiment. DETAILED DESCRIPTION

[0074] The application will be further described in detail below in combination with specific embodiments, but the implementation of the application is not limited thereto.

[0075] The embodiment of the present application provides a verifiable outsourcing key agreement method based on privacy protection of an Internet of Things scene, and is applied to a key agreement system, such as Figure 1 As shown in the figure, the key agreement system comprises a plurality of Internet of Things device nodes Node, and a cloud service platform composed of a trusted execution hardware SGX and a cloud end Cloud. The trusted execution hardware SGX and the cloud end Cloud work cooperatively to build a cloud service platform of a verifiable outsourcing key agreement. The Node is a main participant of the key agreement, the SGX is a trusted execution environment deployed in the cloud end, and a trusted area is built in the cloud service platform. The Cloud is used for providing powerful computing resources and storage resources.

[0076] For simplification, the following Internet of Things device nodes, trusted execution hardware and cloud end are represented by Node, SGX and Cloud respectively.

[0077] Specifically, referring to Figure 2 , the verifiable outsourcing key agreement method based on privacy protection of an Internet of Things scene can comprise:

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

[0079] S2, in the key agreement stage, an initiating node initiating the key agreement encrypts and signs an identity set of key agreement participants and a negotiation mode, and packs the identity set and the negotiation mode together with an unused pseudonym into a key agreement request message, and sends the key agreement request message to the cloud service platform; the SGX performs identity authentication on the key agreement participants by querying the mapping relationship, and after authentication, the SGX obtains key materials from the Cloud, calculates a session key from the key materials according to the key contribution of each party, packs the session key ciphertext and the session key signature, and sends the session key ciphertext and the session key signature to the Cloud. The Cloud generates a session key ciphertext that can be decrypted only by a private key of each key agreement participant by using a proxy re-encryption technology, so that each key agreement participant decrypts the session key and performs key update.

[0080] In order to facilitate understanding of the embodiment of the present application, the node registration stage and the key agreement stage are described below.

[0081] (I) Node Registration Phase

[0082] Please refer to the interaction process during the node registration phase. Figure 3 As shown. For ease of understanding, Node is used as an example. i To illustrate the processing procedure at this stage, let's take the Node as an example. i The specific content of S1 is as follows:

[0083] (1) In the node registration phase, the process of generating an initial pseudonym and key contribution seed locally, encrypting data based on the generated initial pseudonym and key contribution seed, and sending it along with its own node certificate to the cloud service platform for registration includes:

[0084] ①Node i Based on the input security parameter 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;

[0085] In this step, generating the initial temporary public-private key pair can be represented as follows: KeyGen indicates key generation, based on security parameter 1. λ Generate initial temporary public / private key pair The process can be achieved using existing technologies.

[0086] The left arrow (←) indicates the result; safety parameter 1 λ This is a common term in cryptography, based on security parameter 1. λ Depending on the specific key, public-private key pairs of different lengths can be generated, such as 256 bits, 512 bits, or 1024 bits.

[0087] ②Node i Random sampling of initial kana And the key contribution seed;

[0088] In this step, Node i Random sampling of initial kana The random sampling key contribution seed (Seed) can be represented as follows: in, represents a finite field with q elements; $ represents random sampling.

[0089] ③Node i Choose the pseudonyms to be derived and the number n of key contribution materials, and use the SGX long-term public key pk. SGX right Asymmetric encryption is performed on the plaintext message C1 to obtain a ciphertext message C1;

[0090] Where || represents concatenation; n is a positive integer, and all public keys are public in the key agreement system. This step can be represented as represents the long-term public key pk of the SGX SGX Asymmetric encryption. The process of asymmetric encryption is described in the prior art and will not be described in detail here.

[0091] ④Node i uses its long-term private key Signs the ciphertext message C1 to obtain a ciphertext message signature sigC1, and the ciphertext message C1, the ciphertext message signature sigC1, and the Node i own node certificate Cert i are packaged together into a registration message Msg1, which is sent to the cloud service platform and forwarded to the SGX therein;

[0092] Where SGX is embedded in the cloud service platform.

[0093] Node i uses its long-term private key The process of signing the ciphertext message C1 to obtain a ciphertext message signature sigC1 can be represented as Existing elliptic curve signature algorithms can be used; the process of packaging into a registration message Msg1 can be represented as Msg1←(Cert i ,C1,sigC1).

[0094] ⑤Node i performs private key hashing on the initial temporary private key to obtain a new temporary private key uses the initial pseudonym and the temporary private key to generate a new pseudonym through hashing stores locally as pseudonym material.

[0095] Where the process of obtaining a new temporary private key can be represented as The process of generating a new pseudonym can be represented as SKHash represents private key hashing, and Hash represents hashing. These two operations are described in related technologies and will not be described in detail here. Storing locally as pseudonym material can be represented as

[0096]

[0097] (2) Upon receiving the registration message Msg1, SGX verifies the validity of the node certificate. If the verification is successful, it derives and stores multiple pseudonyms and key contribution materials for the registered node, and stores the mapping relationship between the pseudonyms and identity identifiers of the registered node. This process includes:

[0098] ①SGX Node Verification i Node Certificate Cert i The validity of the certificate is verified by checking the node certificate Cert. i Get Node i Identity identifier UID i and long-term public keys

[0099] As will be understood by those skilled in the art, the node certificate is issued and signed by a trusted authority or CA, and SGX verifies the node. i Node Certificate Cert i The legitimacy of a signature refers to the verification of the signature of a trusted authority or CA.

[0100] After successful verification, the node certificate Cert i Get Node i Identity identifier UID i and long-term public keys It can be represented as `parseCert` means parsing and extracting information from the node certificate. This can be understood as parsing and extracting information from the node certificate. i It stores Nodes i Identity identifier UID i and long-term public keys

[0101] ②SGX uses Node i long-term public key Verify the correctness of the ciphertext message signature sigC1. After successful verification, use the long-term private key sk of SGX. SGX Decrypting ciphertext message C1 yields... Seed, n;

[0102] Using Node i long-term public key Verifying the correctness of the ciphertext message signature sigC1 is to execute... The process of verifying the encrypted message signature and Node.js i Using 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 existing technology.

[0103] After the verification passes, the long-term private key sk SGX The process of decrypting the ciphertext message C1 can be represented as: Seed, denotes the encryption with the long-term private key sk SGX of SGX.

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

[0105] A) Randomly sample a secret value k j from the set {0,...,2 j Derive a key contribution from Seed

[0106] Similarly, the randomly sampled secret value can be represented as from the set {0,...,2 j Derive a key contribution from Seed can be represented as deriveContrib denotes the derivation of a key contribution, and the derivation function used here is not limited to being an XOR, a hash, or a KDF, as long as it can ensure the randomness and security of the derived key contribution.

[0107] B) Encrypt the key contribution with the symmetric key Key SGX of SGX. Obtain the key contribution encryption result

[0108] This step can be represented as denotes the encryption with the symmetric key Key SGX of SGX.

[0109] C) Perform a private key hash operation on the temporary private key to obtain a new temporary private key Combine the new temporary private key with the pseudonym to generate a new pseudonym through a hash operation

[0110] Perform a private key hash operation on the temporary private key to obtain a new temporary private key can be represented as SKHash denotes the private key hash operation.

[0111] Combine the new temporary private key with the pseudonym to generate a new pseudonym through a hash operation can be represented as Hash is a hash operation.

[0112] D) SGX-based proxy re-encryption private key SK RE and temporary private key Generate pseudonym Corresponding proxy re-encryption key

[0113] This step can be represented as

[0114] E) Merge the pseudonym Corresponding proxy re-encryption key And the contribution material Into New to Table PID Table;

[0115] This step can be represented as That is, store the pseudonym and key contribution material.

[0116] IV. SGX adds New to Table Node Table to complete registration, where UID i Pseudonym material for the next key agreement;

[0117] This step can be represented as Where Table Node Embodies the mapping relationship between the pseudonym and the identity of the registered node.

[0118] V. SGX signs the registration success message with its own long-term private key sk SGX After getting the message Msg2, send it to Node i .

[0119] This step can be represented as Where OK is the registration success message, Indicates signed with SGX's long-term private key sk SGX .

[0120] (3) In the node registration phase, every time a node registers, the number of node registrations NodeCount increases by one. To protect the anonymity and unlinkability of the participants, the node Node i Pseudonym material is confused, and the present application adopts a k-anonymous design. Whenever the number of registered nodes reaches a set threshold T, SGX constructs a new Merkle signature tree based on the stored pseudonym and key contribution material, that is, according to the local Table PIDTable builds a new Merkle signature tree and updates it to Cloud to build the jth Merkle signature tree Tree j For example, the above process includes:

[0121] ① SGX builds the jth Merkle signature tree Tree PID from the pseudonyms, corresponding proxy re-encryption keys and contribution materials in Table and the root Root j-1 of the (j-1)th Merkle signature tree Tree j-1 as the new Merkle signature tree; j

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

[0123] ② SGX signs the root Root SGX of the jth Merkle signature tree Tree j with its long-term private key sk j to obtain the root signature sigRoot j ;

[0124] This step can be represented as , which means signing with the long-term private key sk SGX .

[0125] ③ SGX packs the jth Merkle signature tree Tree j and the root signature sigRoot j into a message Msg3 and sends it to Cloud;

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

[0127] ④ SGX sets the number of node registrations NodeCount to 0 and clears Table PID ;

[0128] ⑤ SGX stores the new root Root j locally and discards the old root Root j-1 ;

[0129] ⑥ After receiving the message Msg3, Cloud extracts the Tree j and sigRoot​j , with the old Merkle signature tree j-1 Merge, update into a complete Merkle signature tree, and store in the cloud.

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

[0131] (II) Key Negotiation Phase

[0132] Please refer to the interactive processing procedure during the key negotiation phase. Figure 4 As shown. For ease of understanding, Node is used as an example. B Using the j1st alias and the Node holding the j2nd alias A Taking the initiation of key negotiation as an example, this stage of the process is explained for the Node acting as the initiating node. B With another negotiating party, Node A The specific content of S2 is as follows:

[0133] (1) In the key negotiation phase, the process by which the initiating node 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 includes:

[0134] ①Node B For temporary private keys Perform KDF key derivation functions to obtain the corresponding symmetric key.

[0135] This step can be represented as: Among them, temporary private keys For details on creating KDF key derivation functions, please refer to the relevant technical explanations.

[0136] Among them, Node B An unused alias is its j1st alias, Node A An unused pseudonym is its j2nd pseudonym;

[0137] ②Node Bselecting a key agreement mode Mode, symmetrically encrypting the key agreement mode Mode and the UID set (UID B , UID A ) of the key agreement participant with a symmetric key to obtain a ciphertext message D1; wherein the key agreement mode Mode comprises DH operation and XOR of random numbers;

[0138] The process of obtaining the ciphertext message D1 can be represented as:

[0139] represents symmetric encryption with a symmetric key .

[0140] ③Node B packs the unused pseudonym ciphertext message D1 into a key agreement request message Msg4 and sends it to the SGX in the cloud service platform.

[0141] This step can be represented as

[0142] (2) In the key agreement phase, the SGX performs identity authentication on the key agreement participant by querying the mapping relationship, and after the authentication is passed, the SGX obtains key material from the Cloud, calculates the session key from the key contribution of each party, packs the ciphertext of the session key and the signature of the session key, and sends them to the Cloud.

[0143] ① After receiving the key agreement request message Msg4, the SGX queries the Table Node with the pseudonym as the index, and obtains the identity UID B of the Node B and the temporary private key

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

[0145] ② The SGX calculates the symmetric key based on the temporary private key and decrypts the ciphertext message D1 using the symmetric key to obtain UID' B , UID A , Mode, and verifies whether UID B = UID' B is satisfied, and if not, the key agreement operation is exited.

[0146] The SGX calculates the symmetric key Computing symmetric key may be expressed as:

[0147]

[0148] Using symmetric key Decrypting ciphertext message D1may be expressed as:

[0149]

[0150] Verifying whether UID B satisfies UID B , if not, then exit the key agreement operation, which can be expressed as:

[0151] check if UID B ≠ UID B → Aborts, Aborts represents exiting the key agreement operation.

[0152] ③SGX queries Table A with Node A as the identity of UID Node to obtain the pseudonym and temporary private key of Node A

[0153] This step can be expressed as:

[0154] ④SGX queries the Merkle signature tree from the Cloud through the pseudonym to obtain key material, including key contribution material and data verification material wherein verMrt includes the root node signature sigRoot and other auxiliary verification materials;

[0155] This step can be expressed as:

[0156] ⑤SGX verifies the correctness of the sigRoot signature and the integrity of the data with its own long-term public key pk SGX to prevent the Cloud from providing incorrect node key contributions;

[0157] This step is performed by SGX

[0158] ⑥SGX decrypts the key contribution using the symmetric key Key SGX

[0159] ​This step can be represented as:

[0160] ⑦SGX calculates the session key SKey according to the key agreement mode Mode selected by the negotiation participants and the key contribution of each participant computes the session key SKey; and re-encrypts the session key C using the proxy re-encryption public key PK of the SGX RE encrypts the session key SKey to obtain the session key ciphertext C SKey ;

[0161] The calculation of the session key SKey can be represented as obtains the session key ciphertext C SKey which can be represented as using the proxy re-encryption public key PK of the SGX RE to do encryption.

[0162] ⑧SGX calculates Node B , Node A the pseudonym material for the next use and updates the Table B , Table A with UID Node as the index.

[0163] This step can be represented as:

[0164]

[0165] ⑨SGX uses its own long-term private key sk SGX to sign the session key SKey to obtain the session key signature sigSKey, and packs the session key ciphertext C SKey and the session key signature sigSKey into a message Msg5 and sends it to the Cloud.

[0166] The packed message Msg5 can be represented as: Msg5←(C SKey , sigSKey).

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

[0168] ① After receiving the message Msg5, the Cloud respectively uses the pseudonym corresponding to the proxy re-encryption key to proxy re-encrypt the session key ciphertext C SKey to obtain ciphertext C A and C B ;

[0169] This step can be represented as ReEnc denotes performing proxy re-encryption.

[0170] ②Cloud sends C B and sigSKey to Node B in a corresponding message Msg6. C A and sigSKey to Node A in a corresponding message Msg6.

[0171] For Node B , this step can be represented as For Node A , this step can be represented as

[0172] ③Cloud inserts the key agreement message into the key agreement record table Table Record .

[0173] (4) In the key agreement phase, the process of decrypting the session key and performing key update as a negotiation participant is similar, specifically:

[0174] 1) In the key agreement phase, for Node B , the process of decrypting the session key and performing key update as a negotiation participant includes:

[0175] ① After receiving the message Msg6, Node B uses its own temporary private key to decrypt the ciphertext C B to obtain the session key SKey;

[0176] This step can be represented as

[0177] ② Node B verifies the correctness of the session key SKey using the long-term public key pk SGX of SGX;

[0178] This step can be represented as

[0179] ③ Node B uses the temporary private key to calculate the next temporary private key through a hash operation

[0180] This step can be represented as

[0181] IV. Node B uses a pseudonym and a temporary private key calculates the next pseudonym to be used by a hash operation

[0182] This step can be represented as

[0183] IV. Node B stores the next pseudonym to be used and the temporary private key and discards the used pseudonym and the temporary private key

[0184] This step can be represented as

[0185] 2) In the key agreement phase, the process of session key decryption and key update is carried out for Node A , including:

[0186] ① After receiving the message Msg6, Node A uses its own temporary private key to decrypt the ciphertext C A to obtain the session key SKey;

[0187] ② Node A uses the long-term public key pk SGX of SGX to verify the correctness of the session key SKey;

[0188] ③ Node A uses the temporary private key to calculate the next temporary private key to be used by a hash operation

[0189] IV. Node A uses a pseudonym and a temporary private key calculates the next pseudonym to be used by a hash operation

[0190] V. Node A stores the next pseudonym to be used and the temporary private key and discards the used pseudonym and the temporary private key

[0191] Through the above processing, the Internet of Things device nodes Node B and Node AThe session key can be decrypted and the key is updated, so that the key agreement is completed.

[0192] In the embodiments of the present application, due to the differences in computing power and communication environment of each node, the supported key agreement protocols can be different, and the Node performs key agreement with other nodes with the help of the cloud service platform. In this process, the Node uses a pseudonym to outsource the key agreement, and uses a signature digest generated by SGX to verify the decrypted session key. In the node registration stage, SGX derives the pseudonym material and key contribution material for the node. In the key agreement process, SGX is responsible for performing session key calculation and generating a signature digest for verification by the participants. By working with the cloud, SGX uses proxy re-encryption technology to generate decryptable key ciphertext for each Node without exposing the key. In the key agreement process, Cloud generates session key ciphertext that can be decrypted by each participant using its private key through proxy re-encryption technology without directly accessing the session key. In addition, Cloud is also responsible for the storage and retrieval function of the pseudonym and key contribution material, ensuring that SGX can access efficiently.

[0193] In the embodiments of the present application, if a node misses multiple key agreement requests during offline, the present scheme not only realizes the self-recovery of the offline node session key, but also ensures the anonymity and unlinkability. The following will take a node Node i with local storage of pseudonym material as an example to introduce in detail. k

[0194] In the key agreement stage, if an Internet of Things device node misses multiple key agreement requests, the session key self-recovery process is performed after reconnection, including the following processes:

[0195] Step a1, for an offline node Node Record with local storage of pseudonym material , obtaining the new content Table' record in the key agreement record table Table record of the cloud service platform during offline;

[0196] Step a2, querying whether it is in Table' record ;

[0197] Step a3, if it does not exist, it means that no node initiates key agreement with Node k during offline time, and the session key self-recovery process is exited;

[0198] Step a4, if it exists, a temporary private key Ciphertext C k Decrypting to obtain the session key SKey, and verifying the correctness of the session key SKey;

[0199] Step a5, calculating

[0200] This step is described in the foregoing process.

[0201] Step a6, repeating the above steps a2-a5 until the self-recovery of all session keys during the offline period is completed; then the node Node k Storing the unused pseudonym materials and discarding all used pseudonym materials to complete the session key self-recovery process.

[0202] In addition, in the embodiment of the application, the node Node B Using the long-term public key pk of SGX SGX After verifying the correctness of the session key SKey, and after the completion of the session key self-recovery process after the offline Internet of Things device node is online again, the method further comprises:

[0203] The Internet of Things device node judges whether the pseudonym and the contribution material reach the use-up critical situation, if yes, then the new initial pseudonym and the key contribution seed are re-uploaded to the cloud service platform, the update operation of the pseudonym and the contribution material is completed, so as to ensure the smooth progress of the subsequent key agreement.

[0204] The re-uploading of the new initial pseudonym and the key contribution seed to the cloud service platform to complete the update operation of the pseudonym and the contribution material can be understood in the related content of the node registration phase, which is not repeated here.

[0205] The scheme of the embodiment of the application can be used in the unmanned aerial vehicle key agreement scene, etc. For the unmanned aerial vehicle key agreement, the Internet of Things device node Node is an unmanned aerial vehicle, multiple unmanned aerial vehicle nodes form a cluster for cooperative work, and real-time sharing of position, speed, direction and task information is required between each other. In order to prevent eavesdropping or tampering by malicious attackers, key agreement is needed to ensure secure transmission.

[0206] Based on the outsourcing computing and the soft and hard collaborative idea, the application proposes a verifiable outsourcing key agreement method based on privacy protection of Internet of Things scene, aiming at solving the key agreement problem of Internet of Things devices in algorithm heterogeneous environment. The application introduces SGX to build a trusted area in the cloud service platform, and fully integrates the advantages of high trustworthiness of SGX and strong computing power of the cloud server, realizes efficient outsourcing key agreement between Internet of Things devices, and ensures the anonymity and unlinkability of the agreement participants.

[0207] In the key agreement process, the SGX is responsible for performing the session key calculation and generating a signed digest for the participants to verify. In addition, in order to reduce the encryption calculation overhead of the SGX, the proxy re-encryption technology is used, so that the cloud generates a session key ciphertext for each participant which can be decrypted with the private key of the participant. The design realizes the efficient cooperation of the SGX and the cloud, and significantly improves the verification efficiency of the participants and the efficiency of the key agreement while ensuring the security of the key agreement.

[0208] In addition, the application provides an SGX-assisted efficient pseudonym transformation mechanism. The one-time signature based on the pseudonym certificate is realized by using the SGX trusted environment, so that the participants can hide their real identities in the key agreement process. Further, the application reduces the signature calculation overhead of the SGX by combining the Merkle tree technology, realizes the efficient transformation of the pseudonym certificate of the participants, so that even if an attacker or a cloud service provider monitors multiple key agreement sessions, the attacker or the cloud service provider cannot link the multiple key agreement sessions to the same participant, thereby guaranteeing the anonymity and unlinkability of the participants, and realizing the privacy protection of the verifiable outsourced key agreement.

[0209] It should be noted that in the description of the application, the terms "first", "second" are only used for the purpose of description, 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", "second" can be explicitly or implicitly included one or more of the features. In the description of the application, the meaning of "a plurality of" is two or more, unless otherwise specifically limited.

[0210] In the description of the present application, the description of the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" 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 application. In the present application, the illustrative description of the above terms is not necessarily for the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine different embodiments or examples described in the present application.

[0211] The above only describes the preferred embodiments of the present application, and is not used to limit the protection scope of the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the present application is included in the protection scope of the present application.

Claims

1. A verifiable outsourced key negotiation method for privacy protection in IoT scenarios, characterized in that, The method is applied to a key negotiation system, which includes multiple IoT device nodes (Nodes) and a cloud service platform consisting of trusted execution hardware (SGX) and a cloud platform (Cloud); the method includes: During the node registration phase, each Node, acting as a registration node, generates an initial pseudonym and key contribution seed locally. After encrypting the data based on the generated initial pseudonym and key contribution seed, it sends it along with its own node certificate to the cloud service platform for registration. SGX verifies the validity of the node certificate. Upon successful verification, SGX derives and stores multiple pseudonyms and key contribution materials for the registered node, as well as storing the mapping relationship between the registered node's pseudonym and identity identifier. Furthermore, whenever the number of registered nodes exceeds a set threshold T, SGX constructs a new Merkle signature tree based on the stored pseudonyms and key contribution materials and updates it to the Cloud. During the key negotiation phase, the initiating node encrypts and signs the identity set of the negotiation participants and the negotiation mode, and packages it together with unused pseudonyms into a key negotiation request message, which is then sent to the cloud service platform. SGX authenticates the key negotiation participants by querying the mapping relationship. After successful authentication, SGX obtains key materials from the Cloud, calculates the session key based on the key contributions of each party, packages the session key ciphertext and session key signature, and sends them to the Cloud. The Cloud uses proxy re-encryption technology to generate a session key ciphertext for each negotiation participant that can only be decrypted with their private key, thereby enabling each negotiation participant to decrypt the session key and update their key.

2. The method according to claim 1, characterized in that, For Nodes used as registration nodes i The node registration phase involves generating an initial pseudonym and key contribution seed locally, encrypting data based on the generated initial pseudonym and key contribution seed, and then sending it along with its own node certificate to the cloud service platform for registration. This process includes: Node i Based on the input security parameter 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; Node i Random sampling of initial kana And the key contribution seed; Node i Choose the pseudonyms to be derived and the number n of key contribution materials, and use the SGX long-term public key pk. SGX right Asymmetric encryption yields ciphertext message C1; where || denotes concatenation; Node i Using its own long-term private key sk Nodei Sign the ciphertext message C1 to obtain the ciphertext message signature sigC1. Then, combine the ciphertext message C1, the ciphertext message signature sigC1, and the Node. i Certification of its own node i They are packaged together into a registration message Msg1, sent to the cloud service platform, and then forwarded to the SGX within it; Node i For the initial temporary private key Perform a private key hash operation to obtain a new temporary private key. Using initial kana and temporary private key New pseudonyms are generated through hash operations. Will It is stored locally as pseudonymous material.

3. The method according to claim 2, characterized in that, For Nodes used as registration nodes i In the node registration phase, SGX verifies the legality of the node certificate. After successful verification, it derives and stores multiple pseudonyms and key contribution materials for the registered node, and stores the mapping relationship between the pseudonyms and identity identifiers of the registered node. This process includes: SGX Validation Node i Node Certificate Cert i The validity of the node certificate (Cert) is verified. i Get Node i Identity identifier UID i and long-term public keys SGX uses Node i long-term public key Verify the correctness of the ciphertext message signature sigC1. After successful verification, use the long-term private key sk of SGX. SGX Decrypting ciphertext message C1 yields... Seed, n; For each value of j in {1,...,n}, SGX performs the following process in sequence: randomly sample the secret value k j , with k j Contribution with Seed derived key Using SGX symmetric key SGX cryptographic key contribution Obtain the encryption result of the key contribution For temporary private keys Perform a private key hash operation to obtain a new temporary private key. Use the new temporary private key Combined with kana New pseudonyms are generated through hash operations. SGX-based proxy re-encryption of private key SK RE and temporary private key Generate kana Corresponding proxy re-encryption key kana Corresponding proxy re-encryption key and contributing materials merged into Add to Table PID surface; SGX will Add to Table Node The table has completed registration, among which... It is a UID i Pseudonymized material to be used in the next key negotiation; SGX will use its long-term private key sk to send a registration success message. SGX After signing, the message Msg2 is obtained and sent to the Node. i .

4. The method according to claim 3, characterized in that, During the node registration phase, the node registration count (NodeCount) is incremented by one each time a node registers. Whenever the number of registered nodes exceeds a set threshold T, SGX constructs a new Merkle signature tree based on stored pseudonyms and key contribution materials, and updates it to the Cloud. This process includes: SGX based on Table PID The table contains pseudonyms, corresponding proxy re-encryption keys, and contribution materials, as well as the (j-1)th Merkle signature tree. j-1 Root node j-1 Construct the j-th Merkle signature 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 j Root node j Obtain the root node signature sigRoot by performing the signature. j ; SGX will grow the j-th Merkle signature tree. j and root node signature sigRoot j Package it into a Msg3 message and send it to the Cloud; SGX sets the node registration count (NodeCount) to 0 and clears the Table. PID surface; SGX stores the new root node locally. j and discard the old root node. j-1 ; After receiving message Msg3, Cloud will send the Tree carried within it. j and sigRoot j , with the old Merkle signature tree j-1 Merge, update into a complete Merkle signature tree, and store in the cloud.

5. The method according to claim 4, characterized in that, For the Node that initiates the process B With another negotiating party, 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 unused pseudonyms into a key negotiation request message, which is then sent to the cloud service platform. This process includes: Node B For temporary private keys Perform KDF key derivation functions to obtain the corresponding symmetric key. Among them, Node B An unused alias is its j1st alias, Node A An unused pseudonym is its j2nd pseudonym; Node B Select the key negotiation mode (Mode), and combine the key negotiation mode (Mode) with the set of UIDs of the key negotiation participants (UIDs). B UID A Using a symmetric key Symmetric encryption is performed to obtain the ciphertext message D1; where the key negotiation mode includes DH operation and random number XOR; Node B Unused kana The encrypted message D1 is packaged into a key negotiation request message Msg4 and sent to SGX in the cloud service platform.

6. The method according to claim 5, characterized in that, During the key negotiation phase, SGX authenticates the participants by querying the mapping relationship. After successful authentication, SGX obtains key materials from the Cloud, calculates the session key based on the key contributions of each party, and packages and sends the session key ciphertext and session key signature to the Cloud. This process includes: Upon receiving the key negotiation request message Msg4, SGX, under a pseudonym... For indexed queries Table Node The table is obtained, and the Node is retrieved. B Identity identifier UID B and temporary private key SGX is based on temporary private keys Calculate the symmetric key Using symmetric keys Decrypt the ciphertext message D1 to obtain the UID' B UID A , Mode, and verify if the UID is satisfied. B =UID' B If the conditions are not met, the key negotiation operation will be terminated. SGX with Node A Identity identifier UID A For indexed queries Table Node Table, get Node A kana and temporary private key SGX uses pseudonyms Query the Merkle signature tree from Cloud to obtain the key materials, which include key contribution materials and data verification materials. verMrt includes the root node signature sigRoot and other auxiliary verification materials; SGX uses its own long-term public key to perform a PK. SGX Verify the correctness of the sigRoot signature and Data integrity is ensured to prevent the Cloud from providing incorrect node key contributions. SGX uses a symmetric key. SGX Decryption Obtain key contribution SGX determines the key negotiation mode (Mode) selected by the negotiation participants and the key contributions of each participant. 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 compute Node B Node A Next time using kana materials and with UID B UID A Update the table for index Node surface; SGX uses its own long-term private key sk SGX Sign the session key SKey to obtain the session key signature sigSKey, and then transfer the session key ciphertext C SKey The session key signature sigSKey is packaged into a message Msg5 and sent to the Cloud.

7. The method according to claim 6, characterized in that, During the key negotiation phase, Cloud uses proxy re-encryption technology to generate a session key ciphertext for each negotiation participant that can only be decrypted using their private key. This process includes: After receiving the Msg5 message, Cloud used pseudonyms to... Corresponding proxy re-encryption key ciphertext C of the session key SKey Perform proxy re-encryption to obtain ciphertext C A and C B ; Cloud will C B Package the sigSKey message into a corresponding Msg6 message and send it to the Node. B ,Will C A Package the sigSKey message into a corresponding Msg6 message and send it to the Node. A ; Cloud will send key negotiation messages Insert into the key negotiation record table. Record middle.

8. The method according to claim 7, characterized in that, During the key negotiation phase, for Node B As a participant in the negotiation, the process of decrypting the session key and updating the key includes: After receiving message Msg6, Node B Use your own temporary private key For ciphertext C B Decryption yields the session key SKey; Node B PK using SGX long-term public key SGX Verify the correctness of the session key SKey; Node B Using temporary private keys Calculate the temporary private key for the next use using a hash operation. Node B Using kana and temporary private key The next kana to be used is calculated using a hash operation. Node B Store the kana for the next use locally and temporary private key And discard the used kana. and temporary private key During the key negotiation phase, for Node A The process of decrypting and updating the session key includes: After receiving message Msg6, Node A Use your own temporary private key For ciphertext C A Decryption yields the session key SKey; Node A PK using SGX long-term public key SGX Verify the correctness of the session key SKey; Node A Using temporary private keys Calculate the temporary private key for the next use using a hash operation. Node A Using kana and temporary private key The next kana to be used is calculated using a hash operation. Node A Store the kana for the next use locally and temporary private key And discard the used kana. 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 upon reconnecting to the network, including the following steps: Step a1, for locally stored pseudonymous materials Offline Node k Obtain the key negotiation record table of the cloud service platform during offline periods. Record New content in Table' record ; Step a2, query Is it in Table' record middle; Step a3: If it does not exist, it means that no node or Node existed during the offline period. k If key negotiation is initiated, the session key self-healing process will be terminated. 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 steps a2 to a5 above until the self-healing of all session keys during offline periods is complete; then the Node... k Store unused pseudonym materials and discard all used pseudonym materials to complete session key self-healing.

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

Images