Privacy protection security outsourcing key negotiation method suitable for wireless network

Abstract

The invention discloses a privacy protection security outsourcing key negotiation method suitable for a wireless network, which comprises the following steps: acquiring a first session key share from a first cloud by using a second pseudonym of an initiating device and a response device, and acquiring a second session key share from a second cloud by using the first pseudonym; wherein the first cloud and the second cloud store a mapping relation between the second pseudonym and the first key contribution and a mapping relation between the first pseudonym and the second key contribution respectively, and the first cloud and the second cloud do not communicate with the mapping relation; calculating a session key according to the first session key share and the second session key share; and the first pseudonym is sent to the response device, so that the response device obtains the first session key share and the second session key share from the first cloud and the second cloud according to the second pseudonym and the first pseudonym of the response device, and the session key is obtained. The privacy protection performance is good, and the key generation efficiency is high.

Description

Technical Field

[0001] The present invention belongs to the technical field of encryption, and in particular relates to a privacy protection security outsourcing key negotiation method applicable to wireless networks. Background Art

[0002] A wealth of research has been conducted in the field of key negotiation, but most traditional solutions assume that all devices support a unified key negotiation protocol. This assumption does not hold true in real wireless network environments. Because devices in a wireless network may come from different network domains and are limited by factors such as hardware performance, computing power, and communication environment, they may support different key negotiation protocols. Specifically, some devices may have strong computing capabilities and can handle 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 multiple different devices, it may be difficult to find a compatible protocol. This protocol heterogeneity limits the application of existing solutions in wireless networks.

[0003] While outsourcing key negotiation through a cloud platform combined with trusted hardware is one solution to this problem, the limitations of trusted hardware's memory capacity and computing power make it difficult to meet the real-time demands of wireless network applications. Furthermore, existing research shows that trusted hardware is vulnerable to various side-channel attacks, such as cache timing attacks and page fault attacks. This further limits the practical deployment of this solution, resulting in poor privacy protection for traditional solutions. Summary of the Invention

[0004] The embodiment of the present invention provides a privacy-preserving secure outsourced key negotiation method applicable to a wireless network, which can solve the above technical problems.

[0005] In a first aspect, an embodiment of the present invention provides a privacy-preserving secure outsourced key negotiation method applicable to a wireless network, the method being applied to an initiating device and comprising:

[0006] Obtaining a first session key share from a first cloud using a second pseudonym of the initiating device and the responding device;

[0007] Obtaining a second session key share from a second cloud using the first pseudonyms of the initiating device and the responding device;

[0008] The first cloud and the second cloud store a mapping relationship between the second pseudonym and the first key contribution, respectively, and the mapping relationship between the first pseudonym and the second key contribution is not interoperable between the first cloud and the second cloud; the first / second session key shares are obtained based on the first / second key contributions of the initiating device and the responding device;

[0009] calculating a session key based on the first session key share and the second session key share;

[0010] The first pseudonym is sent to the responding device, so that the responding device obtains the first session key share and the second session key share from the first cloud and the second cloud according to its second pseudonym and first pseudonym, thereby obtaining the session key.

[0011] In a second aspect, an embodiment of the present invention provides a privacy-preserving secure outsourced key negotiation method applicable to a wireless network, the method being applied to a responding device and comprising:

[0012] receiving a latest first pseudonym of the responding device sent by the initiating device;

[0013] Obtaining a first session key share and a second session key share from the first cloud and the second cloud according to the latest second pseudonym of the responding device and the latest first pseudonym, respectively, to obtain a session key;

[0014] The latest second pseudonym and the latest first pseudonym have been used to generate the latest historical session key. The first cloud and the second cloud respectively store a mapping relationship between the second pseudonym and the first key contribution and a mapping relationship between the first pseudonym and the second key contribution, and the first cloud and the second cloud do not communicate with each other in terms of mapping relationships. The first / second session key shares are obtained based on the first / second key contributions of the initiating device and the responding device.

[0015] In a third aspect, an embodiment of the present invention provides an initiating device, the initiating device comprising a transceiver acquisition unit and a processing unit;

[0016] The transceiver acquisition unit is configured to: acquire a first session key share from the first cloud using the second pseudonym of the initiating device and the responding device; and acquire a second session key share from the second cloud using the first pseudonym of the initiating device and the responding device;

[0017] The first cloud and the second cloud store a mapping relationship between the second pseudonym and the first key contribution, respectively, and the mapping relationship between the first pseudonym and the second key contribution is not interoperable between the first cloud and the second cloud; the first / second session key shares are obtained based on the first / second key contributions of the initiating device and the responding device;

[0018] The processing unit is configured to: calculate a session key based on the first session key share and the second session key share;

[0019] The transceiver acquisition unit is further configured to send its first pseudonym to the responding device, so that the responding device obtains the first session key share and the second session key share from the first cloud and the second cloud according to its second pseudonym and first pseudonym, respectively, to obtain the session key.

[0020] The advantageous effects of the embodiments of the present invention compared with the prior art are as follows: since the present invention stores the mapping relationship of the first pseudonym-the second pseudonym-the device identity-the key contribution respectively in two clouds that do not communicate the mapping relationship with each other, and obtains the key contribution from the first cloud using the second pseudonym and the first pseudonym respectively, since there is no mapping relationship between the second pseudonym and the first pseudonym in the first cloud, the identities of the communicating parties cannot be inferred based on the second pseudonym, and there is no mapping relationship between the device identity and the first pseudonym in the second cloud, the identities of the communicating parties cannot be inferred based on the first pseudonym or the second pseudonym. Therefore, the present invention can ensure the privacy of the user; and, the present invention distributes the key generation task to two clouds, which can reduce the computational complexity of each cloud and improve the efficiency of key generation. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 A flowchart of a privacy-preserving secure outsourced key negotiation method applicable to wireless networks provided by an embodiment of the present invention;

[0022] Figure 2 A session key generation scenario diagram provided by an embodiment of the present invention;

[0023] Figure 3 A flowchart of a system registration method provided in an embodiment of the present invention;

[0024] Figure 4 A flowchart of a privacy-preserving secure outsourced key negotiation method applicable to wireless networks provided by an embodiment of the present invention;

[0025] Figure 5 A flowchart of another system registration method provided by an embodiment of the present invention;

[0026] Figure 6 A flowchart of another implementation method of a privacy-preserving secure outsourced key negotiation method applicable to a wireless network provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0027] In the following description, specific details such as particular system structures and techniques are provided for purposes of illustration, not limitation, to facilitate a thorough understanding of the embodiments of the present invention. However, it will be apparent to those skilled in the art that the present invention may be practiced in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present invention with unnecessary detail.

[0028] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, integers, steps, operations, elements and / or components, but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof.

[0029] It will also be understood that the term "and / or" used in the present description and appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.

[0030] As used in the present specification and the appended claims, the term "if" may be interpreted as "when" or "upon" or "in response to determining" or "in response to detecting," depending on the context. Similarly, the phrase "if it is determined" or "if [described condition or event] is detected" may be interpreted as meaning "upon determination" or "in response to determining" or "upon detection of [described condition or event]" or "in response to detecting [described condition or event]," depending on the context.

[0031] In addition, in the description of the present specification and the appended claims, the terms "first", "second", "third", etc. are only used to distinguish the descriptions and cannot be understood as indicating or implying relative importance.

[0032] References to "one embodiment" or "some embodiments" in the present specification mean that a particular feature, structure, or characteristic described in conjunction with that embodiment is included in one or more embodiments of the present invention. Thus, phrases such as "in one embodiment," "in some embodiments," "in other embodiments," and "in yet other embodiments" appearing in various places in this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "including," "comprising," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

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

[0034] Example 1

[0035] Figure 1 The flowchart shown is a privacy-preserving secure outsourced key agreement method for wireless networks according to an embodiment of the present invention. By way of example and not limitation, the method can be applied to an initiating device and can include steps S101-S104, each of which is described below.

[0036] S101: Obtain a first session key share from a first cloud using a second pseudonym of an initiating device and a responding device.

[0037] Exemplarily, there may be multiple responding devices. The initiating device communicates with the responding device. Before the communication, the initiating device may use the key negotiation method provided by the present invention to obtain the session key of both parties.

[0038] S102: Obtain a second session key share from a second cloud using the first pseudonyms of the initiating device and the responding device.

[0039] Exemplarily, the first pseudonym and the second pseudonym of a device (including an initiating device and a responding device) may both be random data generated by the device.

[0040] Exemplarily, the first cloud may store a mapping relationship between the second pseudonym and the first key contribution, and the second cloud may store a mapping relationship between the first pseudonym and the second key contribution, and the mapping relationship between the two is not interoperable.

[0041] Specifically, the first / second session key shares may be obtained according to the first / second key contributions of the initiating device and the responding device.

[0042] S103: Calculate a session key based on the first session key share and the second session key share.

[0043] Exemplarily, an XOR operation may be performed on the first session key share and the second session key share to obtain the session key.

[0044] S104: Send its first pseudonym to the responding device, so that the responding device obtains the first session key share and the second session key share from the first cloud and the second cloud respectively according to its second pseudonym and the first pseudonym, to obtain the session key.

[0045] For example, after the initiating device obtains the session key share from the first cloud and the second cloud, the first cloud and the second cloud can associate the requested pseudonym and the returned session key share, so that the responding device can obtain the session key share based on the pseudonym it has used, without having to send the pseudonym of the initiating device together, thereby reducing the spread of the pseudonym of the initiating device and improving the level of privacy protection.

[0046] Since the present invention stores the mapping relationship of the first pseudonym-the second pseudonym-the device identity-the key contribution respectively in two clouds that do not communicate the mapping relationship with each other, and obtains the key contribution from the first cloud using the second pseudonym and the first pseudonym respectively, since there is no mapping relationship between the second pseudonym and the first pseudonym in the first cloud, the identities of the communicating parties cannot be inferred based on the second pseudonym, and there is no mapping relationship between the device identity and the first pseudonym in the second cloud, the identities of the communicating parties cannot be inferred based on the first pseudonym or the second pseudonym. Therefore, the present invention can ensure the privacy of the user; and the present invention distributes the key generation task to the two clouds, which can reduce the computing power of each cloud and improve the efficiency of key generation.

[0047] Example 2

[0048] Figure 2 The diagram shows a scenario diagram for generating a session key according to an embodiment of the present invention.

[0049] As an example, see Figure 2 A privacy-preserving secure outsourced key agreement system applicable to wireless networks may include an initiating device, at least one responding device (only one is shown here), a first cloud, and a second cloud.

[0050] Exemplarily, the initiating device sends a message Msg1 (indicating a fuzzy identity set) to the first cloud, the first cloud queries the built-in identity-second pseudonym mapping table, and returns a message Msg2 (indicating a fuzzy pseudonym set). The initiating device sends a message Msg3 (indicating the first pseudonym of itself and the responding device) to the second cloud, the second cloud queries the built-in first pseudonym-key contribution mapping table, and returns a message Msg4 (indicating the second session key share) to the initiating device; and queries the built-in first pseudonym-second pseudonym mapping table, and sends a message Msg5 to the first cloud to indicate the second pseudonym of the initiating device and the responding device. The first cloud queries the built-in second pseudonym-key contribution mapping table, and sends a message Msg6 (indicating the first session key share) to the initiating device. Afterwards, the initiating device calculates the session key based on the first and second session key shares, and sends a message Msg7 (indicating the first pseudonym of the responding device) to the responding device. Finally, the responding device sends messages Msg9 and Msg8 (indicating its second pseudonym and first pseudonym, respectively) to the first cloud and the second cloud, respectively. The first cloud and the second cloud return Msg 11 、Msg 10 (Indicates the first session key share and the second session key share, respectively.) The responding device also calculates a session key based on the first and second session key shares.

[0051] For example, see Figure 1The fuzzy identity set may include the identities of the responding device and unrelated devices. For example, the fuzzy identity set may include the responding device identity UIDb and two unrelated device identities UIDc and UIDd.

[0052] For example, the set of ambiguous pseudonyms may include the first pseudonyms of the responding device and the unrelated devices.

[0053] For example, the first cloud may store an identity identifier-first pseudonym mapping table representing a mapping relationship between a device identity identifier and a first pseudonym. Node , the second pseudonym-key contribution mapping table Table X The second cloud may store a first pseudonym-first pseudonym-second pseudonym mapping table representing the mapping relationship between the first pseudonym and the second key contribution and the second pseudonym. Y .

[0054] Since the present invention stores the mapping relationship of the first pseudonym-the second pseudonym-the device identity-the key contribution respectively in two clouds that do not communicate the mapping relationship with each other, and simultaneously obtains the first pseudonym of an unrelated device when obtaining the first pseudonym of the device participating in the communication using the device identity; therefore, the present invention can disrupt the line of sight of the first cloud, making it difficult to locate the identities of the initiating device and the responding device through Msg1; in addition, the present invention obtains the key contribution from the first cloud using the second pseudonym and the first pseudonym respectively. Since there is no mapping relationship between the second pseudonym and the first pseudonym in the first cloud, the identities of the communicating parties cannot be inferred based on Msg5. There is no mapping relationship between the device identity and the first pseudonym in the second cloud, and the identities of the communicating parties cannot be inferred based on Msg3. Therefore, the present invention can ensure the privacy of the user.

[0055] Figure 3 The following is a flowchart illustrating an implementation of a system registration method provided in an embodiment of the present invention. By way of example and not limitation, this method can be applied to the aforementioned system, where the system's second cloud is a trusted cloud. The method may include steps S301-S307, each of which is described below.

[0056] S301: The device generates N groups of first random data.

[0057] For example, the device here can be any device within the coverage of the first cloud or the second cloud that generates a key using the key agreement method provided by the present invention. The initiating device, the responding device, and the unrelated device can all be one of such devices.

[0058] In one example, each set of first random data may include: in, are the first pseudonym, first key, first key contribution, second pseudonym, second pseudonym, second key, and second key contribution of the i-th device respectively.

[0059] S302: The device sends a first pseudonym to a first cloud.

[0060] In one example, the device can use the public key pk of the first cloud X The N first pseudonyms generated by asymmetric encryption are used to obtain the ciphertext C1′, and then the long-term private key sk i Sign the ciphertext C1′ of the ciphertext message to obtain the signature SigC1′ of the ciphertext C1′, and finally package the ciphertext C1′, signature SigC1′ and its own certificate Cert i The message Msg1′ is sent to the first cloud.

[0061] For example, the generation process of ciphertext C1′ can be expressed as AsymEnc represents encryption. The generation process of the signature SigC1′ can be expressed as: Sign represents the signature. The message Msg1′ generation process can be expressed as: Msg1←(Cert i ,C1′,SigC1′).

[0062] Correspondingly, the first cloud receives the message Msg1′.

[0063] S303: The first cloud storage device identity and the first pseudonym are mapped and the shared credentials are sent to each device.

[0064] In one possible implementation, after receiving the message Msg1′, the first cloud can first verify the device certificate Cert i The legitimacy of the device is then obtained from it, along with the device identity and long-term public key (UID i ,pk i ); execute Verify pki (C1′, SigC1′), using the device’s long-term public key pk i Verify the correctness of the ciphertext C1′ signature SigC1′; then, execute Use your own long-term private key sk X Decrypt the ciphertext C1′ to obtain multiple first pseudonyms corresponding to the device, and store the first pseudonyms and the device identity UID i The corresponding relationship.

[0065] In an example, the first cloud can use the identity identifier-first pseudonym mapping table Table Node The mapping relationship between the two is stored in a way.

[0066] In one possible implementation, the first cloud can use the device's long-term public key pk i Asymmetric encryption of shared credentials Token is performed Get the ciphertext C2′, and then execute, Use your own long-term private key sk X Sign the ciphertext C2′ to obtain the signature SigC2′; finally, execute Msg′2←(C2′,SigC2′), package C2′ and SigC2′, obtain the message Msg′2, and send the message Msg′2 to the i-th device to distribute the shared credential Token to it.

[0067] S304: The device sends its own second pseudonym and first key contribution to the first cloud.

[0068] In one example, after the device receives the message Msg′2, it can first use the long-term public key pk X Verify the correctness of the ciphertext C2′ and the signature SigC2′. After verification, use its own long-term private key sk i Decrypt the ciphertext C2′ to get the shared credential Token; then, you can use the public key pk X A second pseudonym for the shared credential Token and itself First Key First Key Contribution Perform asymmetric encryption to obtain ciphertext Then pack N groups of ciphertext Get message Msg3′ and send message Msg3′ to the first cloud.

[0069] For example, the ciphertext XC i ' j The generation process can be expressed as:

[0070] Correspondingly, the first cloud receives the message Msg3′.

[0071] S305: The first cloud stores a mapping relationship between the second pseudonym and the first key contribution.

[0072] In one example, after receiving the message Msg3′, the first cloud can first use its own long-term private key sk X Decryption Get N groups Afterwards, you can verify the correctness of the shared credential Token and save it after verification. The mapping relationship.

[0073] Optionally, the first cloud can store the mapping relationship of the second pseudonym-first key contribution-first key in the table TableX middle.

[0074] S306 , the device sends the first pseudonym, the second pseudonym, and the first key contribution to the second cloud.

[0075] In one example, the device can use the long-term public key pk Y For N groups Encrypt with the shared credential Token to obtain N groups of ciphertext in, is the second key. Then, the i-th device can package N groups of ciphertext Get message Msg′4 and send message Msg′4 to the second cloud.

[0076] S307: The second cloud stores a mapping relationship between the first pseudonym, the second pseudonym, and the second key contribution.

[0077] In one example, after receiving the message Msg′4, the second cloud can use its own long-term private key to decrypt the ciphertext get Afterwards, the correctness of the shared credential Token is verified, and after successful verification, the mapping relationship between the first pseudonym, the second pseudonym and the second key contribution is saved.

[0078] For example, when the second cloud verifies the Token, if there is no matching shared credential locally, it can perform interactive verification with the first cloud.

[0079] Optionally, the second cloud can store the mapping relationship of the first pseudonym-the second pseudonym-the second key contribution-the second key in the table Table Y middle.

[0080] The present invention can realize anonymous uploading of pseudonyms, keys and key contributions through shared credentials Token, so that the first pseudonym and the second pseudonym are not associated in the first cloud, and the user identity and the first pseudonym are not associated in the second cloud.

[0081] After the system is registered, each device can act as an initiating device / responding device respectively to generate a session key through the following key negotiation method.

[0082] Figure 4 The flowchart shown is a privacy-preserving secure outsourced key agreement method for wireless networks, as provided in an embodiment of the present invention. By way of example and not limitation, the method can be a specific possible implementation of steps S101-S104 described above. The method can include steps S401-S412, each of which is described below.

[0083] S401: The initiating device sends a message Msg1 to the first cloud.

[0084] In a possible implementation, the message Msg1 is used to indicate the blurred identity of the responding device.

[0085] In one example, the identity of the responding device may be obfuscated by packaging the identities of the responding device and unrelated devices into an obfuscated identity set.

[0086] For example, the fuzzy identity set (UID B ||UID C ||UID D ) can include a response device Node B and unrelated device Node C Node D The identity identifier UID.

[0087] For example, the selection of the number t of irrelevant devices may affect the strength of privacy protection.

[0088] Optionally, t may be equal to the number of responding devices.

[0089] In one example, the initiating device can use its own first key Encrypt the fuzzy identity set to obtain the ciphertext C1, and then execute The message verification code SigC1 of the ciphertext C1 is calculated based on an unused second pseudonym of the self, and finally the ciphertext C1, the message verification code SigC1, and the second pseudonym when signing SigC1 are packaged to obtain the message Msg1, and the message Msg1 is sent to the first cloud.

[0090] S402: The first cloud searches for a first pseudonym corresponding to the identity identifier and sends a message Msg2 to the initiating device.

[0091] In a possible implementation, the message Msg2 may be used to indicate the first pseudonym of the responding device after being blurred.

[0092] In one example, corresponding to the fuzzy identity identification set, the identity of the responding device can be obfuscated by packaging the first pseudonyms of the responding device and the unrelated devices into a fuzzy pseudonym set.

[0093] For example, the set of ambiguous pseudonyms may include the first pseudonyms of the responding device and the unrelated device.

[0094] In an example, the message Msg2 includes a ciphertext C2 and a message authentication code SigC2 of the ciphertext C2. When the second cloud is a trusted cloud, the ciphertext C2 can be obtained by directly encrypting the fuzzy pseudonym set.

[0095] For example, the first cloud can execute Use the second pseudonym of the initiating device as the index to query the Table X Table to obtain the first key of the initiating device and execute Verify the integrity of the message. Then use the first key Symmetrically decrypt the ciphertext C1 to obtain a set of fuzzy identities, and use the identities in the set as indexes to query the Table. Node Get the latest unused first pseudonym of each device from the table and get the fuzzy pseudonym set Finally, using the first key Symmetrically encrypted fuzzy pseudonym set Obtain the ciphertext C2, calculate the message verification code SigC2 of the ciphertext C2, package the ciphertext C2 and the message verification code SigC2 into a message Msg2, and send it to the initiating device.

[0096] The initiating device obtains the responding device's pseudonym from the first cloud using the responding device's identity, rather than directly from the responding device. This ensures that subsequent processes can continue even when the responding device is offline, eliminating the need to wait for the responding device to come online. This reduces the time required to generate session keys. Furthermore, the initiating device does not store the mapping between the responding device's pseudonym and identity, reducing the risk of privacy leaks on the responding device.

[0097] S403: The initiating device sends a message Msg3 to the second cloud.

[0098] Exemplarily, the message Msg3 may be used to indicate the first pseudonyms of the initiating device and the responding device.

[0099] In one example, the initiating device may first execute Verify the integrity of message Msg2 and use the first key after verification Symmetrically decrypt the ciphertext C2 to obtain the first pseudonym of the responding device and the irrelevant device. Then use the second key The first pseudonym of the responding device is encrypted to obtain ciphertext C3. The message verification code SigC3 of ciphertext C3 is calculated using the first pseudonym of the initiating device. The ciphertext C3, the first pseudonym of the initiating device, and the message verification code SigC3 are packaged to obtain message Msg3. Finally, message Msg3 is sent to the second cloud.

[0100] Correspondingly, the second cloud receives message Msg3.

[0101] S404: The second cloud searches for the second session key share and sends a message Msg4 to the initiating device.

[0102] Exemplarily, message Msg4 may be used to indicate the second session key share.

[0103] In one example, the second cloud can execute Query the table using the first pseudonym of the initiating device Y Get the second pseudonym of the initiating device Second key and the second key contribution Then execute Verify the integrity of message Msg3 and use the second key after verification Symmetrically decrypt the ciphertext C3 to obtain the first pseudonym of the corresponding device. Query Table for Index Y Table, get the second pseudonym of the responding device Second key and the second key contribution Finally, calculate Obtain the second session key share sumβ.

[0104] Optionally, after obtaining the second session key share, the second cloud can record the key negotiation Save to table RTable Y in order to reply to the device application later.

[0105] In one example, the message Msg4 includes the ciphertext and the ciphertext Signature When the second cloud is a trusted cloud, the ciphertext It can be obtained by directly encrypting the second session key share.

[0106] For example, the second cloud can use the second key of the initiating device Symmetrically encrypt the second session key share to obtain the ciphertext Then calculate the ciphertext Message verification code Finally pack the ciphertext and message verification code Receive message Msg4 and send message Msg4 to the initiating device.

[0107] S405: The second cloud sends a message Msg5 to the first cloud.

[0108] Exemplarily, the message Msg5 is used to indicate the second pseudonyms of the initiating device and the responding device.

[0109] In one example, the second cloud can use the session key Key between the two clouds XYSymmetrically encrypt the second pseudonym of the initiating device and the responding device Get the ciphertext CT X , and calculate the ciphertext CT X Message verification code Packed Ciphertext CT X and message verification code The message Msg5 is sent to the first cloud.

[0110] S406: The first cloud searches for the first session key share and sends a message Msg6 to the initiating device.

[0111] In one example, the first cloud can first verify the integrity of the message Msg5 using the session key Key XY Symmetric decryption ciphertext CT X get Then use the second pseudonym of the initiating device and the responding device as the index from the Table X Query the first keys of two devices in the table and first key contribution Then, calculate Get the first system key contribution.

[0112] Similarly, after obtaining the first session key share, the first cloud can record the key negotiation Save to table RTable X in order to reply to the device application later.

[0113] In one example, the first cloud can initiate the first key of the device Symmetrically encrypt sumλ to obtain ciphertext Then calculate its message verification code Finally pack the ciphertext Message Verification Code Get Msg6 and send it to the initiating device.

[0114] S407: The initiating device calculates a session key according to the first session key share and the second session key share.

[0115] In one example, the initiating device can use its own second key to decrypt the ciphertext in the message Msg4 Obtain the second session key share and use its own first key to decrypt the ciphertext in message Msg6 Get the first session key share, and finally pass Calculate the session key SKey between it and the responding device.

[0116] S408: The initiating device sends a message Msg7 to the responding device.

[0117] For example, the initiating device may use the first pseudonym of the responding device used in the session key generation process. Package it into message Msg7 and send it to the responding device.

[0118] S409, the responding device sends message Msg9 and message Msg8 to the first cloud and the second cloud respectively.

[0119] Exemplarily, the message Msg9 and the message Msg8 may indicate the latest second pseudonym and the latest first pseudonym of the responding device, respectively.

[0120] Exemplarily, the latest first pseudonym and the latest second pseudonym are pseudonyms of the responding device used in the above steps S401 - S408 .

[0121] In one example, the responding device can use its latest first pseudonym Get the latest second pseudonym corresponding to the index Then, use its own second key calculate The message authentication code SigC5, the first pseudonym The message verification code SigC5 is packaged into message Msg8 and sent to the second cloud; using its own first key Calculate the second pseudonym The message authentication code SigC6, the second pseudonym The message verification code SigC6 is packaged into a message Msg9 and sent to the first cloud.

[0122] S410: The second cloud searches for the second session key share and sends a message Msg to the responding device. 10 .

[0123] For example, the message Msg 10 Can be used to indicate the second session key share.

[0124] In one example, the second cloud can be used under the first pseudonym Query RTable for index Y Table to obtain the second session key share sumβ and the second key of the responding device Afterwards, execute Verify the integrity of message Msg8. After verification, you can use the second key Symmetrically encrypt sumβ to obtain ciphertext Calculate ciphertext Message verification code Packed ciphertext Message Verification Code Message 10 Sent to the responding device.

[0125] S411: The first cloud searches for the first session key share and sends a message Msg to the responding device. 11 .

[0126] For example, the message Msg 11 Can be used to indicate the first session key share.

[0127] In one example, the first cloud can use the second type of pseudonym Query RTable for index X Table to obtain the first session key share sumλ and the first key of the responding device Afterwards, execute Verify the integrity of message Msg9; then use the first key Symmetrically encrypt the first session key share to obtain the ciphertext Calculate ciphertext Message verification code And the ciphertext and message verification code Package into message Msg 11 Sent to the responding device.

[0128] S412: The responding device calculates a session key based on the first session key share and the second session key share.

[0129] In one example, the responding device receives the message Msg 10 , Message 11 Afterwards, you can execute and Verify the integrity of the two messages. After verification, you can use the first key Decryption and the second key Decryption Get the first session key share and the second session key share, and then use the formula Calculate the session key.

[0130] Since the present invention stores the mapping relationship of the first pseudonym-the second pseudonym-the device identity-the key contribution respectively in two clouds that do not communicate the mapping relationship with each other, and simultaneously obtains the first pseudonym of an unrelated device when obtaining the first pseudonym of the device participating in the communication using the device identity; therefore, the present invention can disrupt the line of sight of the first cloud, making it difficult to locate the identities of the initiating device and the responding device through Msg1; in addition, the present invention obtains the key contribution from the first cloud using the second pseudonym and the first pseudonym respectively. Since there is no mapping relationship between the second pseudonym and the first pseudonym in the first cloud, the identities of the communicating parties cannot be inferred based on Msg5. There is no mapping relationship between the device identity and the first pseudonym in the second cloud, and the identities of the communicating parties cannot be inferred based on Msg3. Therefore, the present invention can ensure the privacy of the user.

[0131] Example 3

[0132] Figure 5 The flowchart shown is an implementation flowchart of another system registration method provided by an embodiment of the present invention. By way of example and not limitation, this method can be applied to the aforementioned system, where the second cloud of the system is a suspicious cloud. The method can include steps S501-S507, each of which is described below.

[0133] S501: The device generates N groups of second random data.

[0134] In one example, similar to when the second cloud is a trusted cloud, each set of second random data may include Extra They are the temporary private key and temporary public key in the temporary public-private key pair respectively.

[0135] S502: The device sends a first pseudonym and a temporary public key to the first cloud.

[0136] In one example, the device may use the temporary private key in each set of second random data to sign the second key contribution in the set to obtain N sets of signatures Afterwards, the public key of the first cloud can be used to asymmetrically encrypt each set of the first pseudonym and the first public key to obtain the ciphertext C1″. The subsequent process is similar to step S502, and the long-term private key sk i Sign the ciphertext C1″ of the ciphertext message to obtain the signature SigC1″ of the ciphertext C1″, and finally package the ciphertext C1″, the signature SigC1″ and its own certificate Cert i The message Msg1″ is sent to the first cloud.

[0137] S503: A mapping relationship between the first cloud storage device identity, the first pseudonym, and the temporary public key is generated, and a shared credential is sent to each device.

[0138] In a possible implementation, after receiving the message Msg1″, the first cloud can first verify the device certificate Cert i The legitimacy of the device is then obtained from it, along with the device identity and long-term public key (UID i ,pk i );Use the device's long-term public key pk i Verify the correctness of the ciphertext C1 "signature SigC1"; then, you can use your own long-term private key sk X Decrypt the ciphertext C1″ to obtain the concatenation of N first pseudonyms and temporary public keys Finally, the mapping relationship between the device identity, the N first pseudonyms, and the temporary public key may be stored.

[0139] Similarly, the first cloud stores the mapping relationship between the first pseudonym, temporary public key and device identity in the table Table Node middle.

[0140] In one possible implementation, the first cloud can use the long-term public key pk of the i-th device i Asymmetrically encrypt the shared credential Token to obtain the ciphertext C2″, and then use its own long-term private key sk X Sign the ciphertext C2″ to obtain the signature SigC2″; finally, package C2″ and SigC2″ to obtain the message Msg′2′, and send the message Msg′2′ to each device to distribute the shared credential Token to it.

[0141] Optionally, before encrypting the shared credential Token, the first device may first check whether the local shared credential has expired. If expired, a new Token may be randomly generated and a new validity period may be set.

[0142] S504: The device sends its own second pseudonym and first key contribution to the first cloud.

[0143] In one example, after the device receives the message Msg′2′, it can first use the long-term public key pk X Verify the correctness of the ciphertext C2″ and the signature SigC2″. After verification, use its own long-term private key sk i Decrypt the ciphertext C2″ to get the shared credential Token; then, you can use the public key pk X A second pseudonym for the shared credential Token and itself First Key First Key Contribution Perform asymmetric encryption to obtain ciphertext Then pack N groups of ciphertext Get message Msg3″ and send message Msg3″ to the first cloud.

[0144] S505: The first cloud stores a mapping relationship between the second pseudonym and the first key contribution.

[0145] In one example, after receiving the message Msg3″, the first cloud can first use its own long-term private key sk X Decryption Get N groups Afterwards, you can verify the correctness of the shared credential Token and save it after verification. The mapping relationship.

[0146] Optionally, the first cloud can store the mapping relationship of the second pseudonym-first key contribution-first key in the table Table X middle.

[0147] S506 , the device sends the first pseudonym, the second pseudonym, and the first key contribution to the second cloud.

[0148] In one example, the i-th device can use the long-term public key pk Y For N groups Encrypt with the shared credential Token to obtain N groups of ciphertext Then, the i-th device can package N groups of ciphertext YC i ″ j Get message Msg′4′ and send message Msg′4′ to the second cloud.

[0149] S507 , the second cloud stores a mapping relationship between the first pseudonym, the second pseudonym, and the second key contribution.

[0150] In one example, after receiving the message Msg′4′, the second cloud can use its own long-term private key to decrypt the ciphertext YC i ″ j ,get Afterwards, the correctness of the shared credential Token is verified, and after successful verification, the mapping relationship between the first pseudonym, the second pseudonym, the second key contribution, and the second key contribution signature is saved.

[0151] For example, when the second cloud verifies the Token, if there is no matching shared credential locally, it can perform interactive verification with the first cloud.

[0152] Optionally, the second cloud can store the mapping relationship of the first pseudonym-the second pseudonym-the second key contribution-the second key contribution signature-the second key in the table Table Y middle.

[0153] The present invention can realize anonymous uploading of pseudonyms, keys and key contributions through shared credentials Token, so that the first pseudonym and the second pseudonym are not associated in the first cloud, and the user identity and the first pseudonym are not associated in the second cloud.

[0154] After the system is registered, each device can act as an initiating device / responding device respectively to generate a session key through the following key negotiation method.

[0155] Figure 6 The flowchart shown is another implementation flow of a privacy-preserving secure outsourced key agreement method applicable to wireless networks, provided by an embodiment of the present invention. By way of example and not limitation, this method can be a specific possible implementation of steps S101-S104 described above. The method can include steps S601-S613, each of which is described below.

[0156] S601: The initiating device sends a message Msg1 to the first cloud.

[0157] S602: The first cloud searches for a first pseudonym corresponding to the identity identifier and sends a message Msg2 to the initiating device.

[0158] In one example, when the second cloud is a suspicious cloud, the first cloud can use the identity identifier as an index to query the Table X The table obtains the fuzzy temporary public key set while obtaining the fuzzy pseudonym set, and then uses the first key Symmetric encryption fuzzy pseudonym set and fuzzy temporary public key set Get the ciphertext C2.

[0159] For example, the set of obfuscated temporary public keys may include temporary public keys of the responding device and unrelated devices.

[0160] S603: The initiating device sends a message Msg3 to the second cloud.

[0161] Accordingly, when the initiating device decrypts the ciphertext C2, it can obtain the identity and temporary public key of the responding device and the unrelated device.

[0162] S604: The second cloud searches for the second session key share and sends a message Msg4 to the initiating device.

[0163] In one example, when the second cloud is a suspicious cloud, the second cloud can find the second key contribution signature in addition to the second pseudonym, the second key, and the second key contribution when searching with the first pseudonym as an index.

[0164] Accordingly, the second cloud can sign the second session key share and the second session key share Encrypt and generate ciphertext

[0165] S605: The second cloud sends a message Msg5 to the first cloud.

[0166] S606: The first cloud searches for the first session key share and sends a message Msg6 to the initiating device.

[0167] S607: The initiating device calculates a session key according to the first session key share and the second session key share.

[0168] In one example, when the second cloud is a suspicious cloud, the initiating device decrypts the ciphertext Ciphertext After obtaining the session key share, it is necessary to use the batch signature algorithm to verify all key contributions The correctness of the session key can be calculated only after verification to avoid malicious attacks from suspicious clouds.

[0169] For example, when the second cloud is a suspicious cloud (for example, a malicious device), the contents of steps S601-S607 are the same as those of steps S401-S407, except that some contents such as the ciphertext C2 and the ciphertext C3 are obtained. The objects to be encrypted are different, and the same parts can refer to the description of the above embodiment 2 and will not be repeated here.

[0170] S608: The initiating device sends a message Msg to the first cloud 12 .

[0171] In one example, the initiating device can perform a hash operation on the session key SKey to obtain a hashed session key HSKey, and then use its own key Symmetrically encrypt HSKey to obtain ciphertext C4, calculate the message verification code SigC4 of ciphertext C4, and package the ciphertext C4 and message verification code SigC4 into message Msg 12 Send to First Cloud.

[0172] S609: The first cloud stores the hashed session key.

[0173] In one example, the first cloud can first verify the message Msg 12 integrity, then use Symmetrically decrypt the ciphertext C4 to obtain the hash session key and record the ciphertext negotiation Save to table RTable X middle.

[0174] S610: The initiating device sends a message Msg7 to the responding device.

[0175] S611, the responding device sends message Msg9 and message Msg8 to the first cloud and the second cloud respectively.

[0176] S612: The second cloud searches for the second session key share and sends a message Msg to the responding device. 10 .

[0177] Exemplarily, the contents of steps S610-S612 are the same as those of the above-mentioned steps S409-S410. For details, please refer to the above-mentioned steps S409-S410, which will not be repeated here.

[0178] S613: The first cloud searches for the first session key share and sends a message Msg to the responding device. 11 .

[0179] In one example, the first cloud can obtain the ciphertext by a step similar to step S411. The ciphertext is then calculated based on the hashed session key The signature is obtained And the ciphertext and message verification code Package into message Msg 11 Sent to the responding device.

[0180] S614: The responding device calculates a session key based on the first session key share and the second session key share.

[0181] In one example, since the second cloud is a suspicious cloud, the responding device may perform a Verify the correctness of the session key SKey.

[0182] Specifically, the responding device can hash the session key it has calculated and verify the ciphertext based on the hashed session key. and message verification code

[0183] This invention leverages the immense computing power of cloud servers and, by combining pseudonym splitting and transformation, privacy information retrieval, distributed key computation, and batch signature authentication, provides an efficient, privacy-preserving, secure outsourced key negotiation method. This method not only implements distributed key secure computation schemes in dual-cloud semi-trusted and dual-cloud adversarial architectures, but also ensures the anonymity and unlinkability of the initiating device, thereby achieving privacy protection within the outsourced key negotiation method.

[0184] Furthermore, when the second cloud is a suspected malicious cloud, the present invention can effectively restrict and supervise the second cloud's tampering with the session key share by verifying the integrity of the subkey contribution provided by the second cloud.

[0185] An embodiment of the present invention further provides an initiating device, which may include a transceiver acquisition unit and a processing unit.

[0186] Exemplarily, the transceiver acquisition unit is configured to: acquire a first session key share from the first cloud using the second pseudonym of the initiating device and the responding device; acquire a second session key share from the second cloud using the first pseudonym of the initiating device and the responding device;

[0187] The first cloud and the second cloud store a mapping relationship between the second pseudonym and the first key contribution, respectively, and the mapping relationship between the first pseudonym and the second key contribution is not interoperable between the first cloud and the second cloud; the first / second session key shares are obtained based on the first / second key contributions of the initiating device and the responding device;

[0188] The processing unit is configured to: calculate a session key based on the first session key share and the second session key share;

[0189] The transceiver acquisition unit is further configured to send its first pseudonym to the responding device, so that the responding device obtains the first session key share and the second session key share from the first cloud and the second cloud respectively according to its own second pseudonym and first pseudonym to obtain the session key.

[0190] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

Claims

1. A privacy-preserving secure outsourced key negotiation method applicable to wireless networks, characterized in that: The method is applied to an initiating device, and includes: Obtaining a first session key share from a first cloud using a second pseudonym of the initiating device and the responding device; Obtaining a second session key share from a second cloud using the first pseudonyms of the initiating device and the responding device; The first cloud and the second cloud store a mapping relationship between the second pseudonym and the first key contribution, respectively, and the mapping relationship between the first pseudonym and the second key contribution is not interoperable between the first cloud and the second cloud; the first / second session key shares are obtained based on the first / second key contributions of the initiating device and the responding device; calculating a session key based on the first session key share and the second session key share; The first pseudonym is sent to the responding device, so that the responding device obtains the first session key share and the second session key share from the first cloud and the second cloud according to its second pseudonym and first pseudonym, thereby obtaining the session key.

2. The method according to claim 1, characterized in that The first cloud also stores a mapping relationship between the device identity and the second pseudonym, and the second cloud also stores a mapping relationship between the first pseudonym and the second pseudonym; The obtaining of the first session key share from the first cloud using the second pseudonym of the initiating device and the responding device; and obtaining of the second session key share from the second cloud using the first pseudonym of the initiating device and the responding device include: Sending a message Msg1 to the first cloud and receiving a message Msg2 from the first cloud, wherein the message Msg1 is used to indicate the obfuscated identity of the responding device, and the message Msg2 is used to indicate the obfuscated first pseudonym of the responding device; Sending a message Msg3 to the second cloud, and receiving a message Msg4 from the second cloud, wherein the message Msg3 is used to indicate the first pseudonym of the initiating device and the responding device, and the Msg4 is used to indicate the second session key share; Receive a message Msg6 from the first cloud, wherein the message Msg6 is obtained by the first cloud based on the message Msg5, the message Msg6 is used to indicate the first session key share, and the message Msg5 is used to indicate the second pseudonyms of the initiating device and the responding device.

3. The method according to claim 2, characterized in that The message Msg1 includes a ciphertext C1 of a fuzzy identity set and a message verification code SigC1 of the ciphertext C1, wherein the fuzzy identity set includes the identities of the responding device and unrelated devices.

4. The method according to claim 2, characterized in that The message Msg2 includes a ciphertext C2 and a message verification code SigC2 of the ciphertext C2; If the second cloud is a trusted cloud, the ciphertext C2 is obtained by encrypting the fuzzy pseudonym set, wherein the fuzzy pseudonym set includes the first pseudonyms of the responding device and the unrelated device; If the second cloud is a suspicious cloud, the ciphertext C2 is obtained by encrypting a fuzzy pseudonym set and a fuzzy temporary public key set, wherein the fuzzy temporary public key set includes the temporary public keys of the responding device and the irrelevant device.

5. The method according to claim 2, characterized in that The message Msg4 includes the ciphertext and the ciphertext Signature If the second cloud is a trusted cloud, then the ciphertext is obtained by encrypting the second session key share; If the second cloud is a suspicious cloud, the ciphertext The second session key share is obtained by encrypting the second session key share and the second session key share signature, and the second session key share signature is obtained by signing the second session key share using a temporary public key.

6. The method according to claim 5, characterized in that The second cloud is a suspicious cloud; The calculating of the session key according to the first session key share and the second session key share includes: Verifying the second session key share, the temporary public keys of the initiating device and the responding device, and the signature of the second session key share; After verification is successful, the session key is determined based on the first session key share and the second session key share.

7. A privacy-preserving secure outsourced key negotiation method applicable to wireless networks, characterized in that: The method is applied to a responding device, and the method includes: receiving a latest first pseudonym of the responding device sent by the initiating device; Obtaining a first session key share and a second session key share from the first cloud and the second cloud according to the latest second pseudonym of the responding device and the latest first pseudonym, respectively, to obtain a session key; The latest second pseudonym and the latest first pseudonym have been used to generate the latest historical session key. The first cloud and the second cloud respectively store a mapping relationship between the second pseudonym and the first key contribution and a mapping relationship between the first pseudonym and the second key contribution, and the first cloud and the second cloud do not communicate with each other in terms of mapping relationships. The first / second session key shares are obtained based on the first / second key contributions of the initiating device and the responding device.

8. The method according to claim 7, characterized in that The obtaining the first key contribution and the second key contribution from the second cloud and the first cloud according to the first pseudonym and the second pseudonym of the responding device, respectively, to obtain the session key includes: Sending a message Msg8 and a message Msg9 to the second cloud and the first cloud respectively, wherein the message Msg8 and the message Msg9 are used to indicate the latest first pseudonym and the latest second pseudonym of the responding device respectively; Receive messages Msg from the second cloud and the first cloud respectively 11 and message Msg 10 , wherein the message Msg 10 Including ciphertext and the ciphertext Message verification code The message Msg 11 Including ciphertext and the ciphertext Message verification code Verify the ciphertext respectively The message verification code The ciphertext The message verification code After verification, each user passes their own first key and the second key For the ciphertext and the ciphertext Decrypting to obtain the first session key share and the second session key share; The session key is determined based on the first session key share and the second session key share.

9. The method according to claim 8, characterized in that The second cloud is a suspicious cloud, the message verification code The ciphertext is obtained by hashing the session key The hashed session key is obtained by performing hash calculation on the session key; After determining the session key according to the first session key share and the second session key share, the method further includes: Hash the session key and verify the ciphertext based on the hashed session key and the message verification code 10. An initiating device, characterized in that: The initiating device includes a transceiver acquisition unit and a processing unit; The transceiver acquisition unit is configured to: acquire a first session key share from the first cloud using the second pseudonym of the initiating device and the responding device; and acquire a second session key share from the second cloud using the first pseudonym of the initiating device and the responding device; The first cloud and the second cloud store a mapping relationship between the second pseudonym and the first key contribution, respectively, and the mapping relationship between the first pseudonym and the second key contribution is not interoperable between the first cloud and the second cloud; the first / second session key shares are obtained based on the first / second key contributions of the initiating device and the responding device; The processing unit is configured to: calculate a session key based on the first session key share and the second session key share; The transceiver acquisition unit is further configured to send its first pseudonym to the responding device, so that the responding device obtains the first session key share and the second session key share from the first cloud and the second cloud according to its second pseudonym and first pseudonym, respectively, to obtain the session key.

Images