Communication method and device

Abstract

The invention relates to a communication method, equipment, a computer readable storage medium, a computer program product and a computer program. The method comprises the steps that a group request message is sent to a first service node, the group request message carries group parameters, and the group parameters are obtained through calculation based on identifiers of multiple target devices; and receiving a group response message from the first service node, the group response message carrying a private key corresponding to the group parameter.

Description

Communication method and device Technical Field

[0001] The present application relates to the field of communications, and more particularly, to a communication method, device, computer-readable storage medium, computer program product, and computer program. Background Art

[0002] With the development of technology, there is a need for communication between IoT devices (or groups) or zero-power devices (or groups) and network-side devices or other IoT devices (or zero-power devices). In order for IoT devices (or groups) or zero-power devices (or groups) to achieve communication, they need to complete authentication processing. In the authentication process of zero-power or IoT groups, the group-related private key needs to be used, or in the authentication process of a single IoT device (or zero-power device), the private key related to the IoT device or zero-power device also needs to be used. However, how to ensure the efficiency and security of private key generation has become a problem that needs to be solved.

[0003] Summary of the Invention

[0004] Embodiments of the present application provide a communication method, device, computer-readable storage medium, computer program product, and computer program.

[0005] An embodiment of the present application provides a communication method performed by a first device, including:

[0006] Sending a group request message to the first service node, wherein the group request message carries a group parameter, and the group parameter is calculated based on identifiers of multiple target devices;

[0007] A group response message is received from the first service node, wherein the group response message carries a private key corresponding to the group parameter.

[0008] An embodiment of the present application provides a communication method performed by a first service node, including:

[0009] receiving a group request message from the first device, wherein the group request message carries a group parameter;

[0010] Based on the group parameter, calculating a private key corresponding to the group parameter;

[0011] Sending a group response message to the first device, wherein the group response message carries a private key corresponding to the group parameter.

[0012] An embodiment of the present application provides a communication method performed by a second device, including:

[0013] Sending a first request message to the second service node, where the first request message carries an identifier of the second device;

[0014] A first response message is received from the second service node, wherein the first response message carries a private key corresponding to the second device, and the private key corresponding to the second device is obtained based on an identifier of the second device.

[0015] This embodiment of the present application provides a communication method performed by a second service node, including:

[0016] receiving a first request message from a second device, where the first request message carries an identifier of the second device;

[0017] Calculating a private key corresponding to the second device based on the identifier of the second device and the second federation node;

[0018] A first response message is sent to the second device, where the first response message carries a private key corresponding to the second device.

[0019] This embodiment of the present application provides a communication method performed by a second service node, including:

[0020] Sending a second request message to the issuing node;

[0021] Receive a second response message from the issuing node, wherein the second response message carries location information of the certificate of the second service node on the blockchain.

[0022] The present application provides a communication method performed by an issuing node, including:

[0023] receiving a second request message from a second service node;

[0024] Generating a certificate for the second service node;

[0025] Uploading the certificate of the second service node to the blockchain, and obtaining the location information of the certificate of the second service node on the blockchain;

[0026] Send a second response message to the second service node, where the second response message carries location information of the certificate of the second service node on the blockchain.

[0027] An embodiment of the present application provides a first device, including:

[0028] A first communication unit is configured to send a group request message to a first service node, wherein the group request message carries a group parameter, and the group parameter is calculated based on identifiers of multiple target devices; and receive a group response message from the first service node, wherein the group response message carries a private key corresponding to the group parameter.

[0029] An embodiment of the present application provides a first service node, including:

[0030] a second communication unit, configured to receive a group request message from a first device, wherein the group request message carries a group parameter; and send a group response message to the first device, wherein the group response message carries a private key corresponding to the group parameter;

[0031] The second processing unit is configured to calculate a private key corresponding to the group parameter based on the group parameter.

[0032] An embodiment of the present application provides a second device, including:

[0033] The third communication unit is configured to send a first request message to the second service node, where the first request message carries an identifier of the second device; and receive a first response message from the second service node, where the first response message carries a private key corresponding to the second device, and the private key corresponding to the second device is obtained based on the identifier of the second device.

[0034] An embodiment of the present application provides a second service node, including:

[0035] a fourth communication unit, configured to receive a first request message from a second device, the first request message carrying an identifier of the second device; and send a first response message to the second device, wherein the first response message carries a private key corresponding to the second device;

[0036] The fourth processing unit is configured to calculate a private key corresponding to the second device based on the identifier of the second device and the second joint node.

[0037] An embodiment of the present application provides a second service node, including:

[0038] The fourth communication unit is used to send a second request message to the issuing node; and receive a second response message from the issuing node, wherein the second response message carries the location information of the certificate of the second service node on the blockchain.

[0039] This embodiment of the present application provides an issuing node, including:

[0040] a fifth communication unit, configured to receive a second request message from a second service node; upload the certificate of the second service node to the blockchain, obtain location information of the certificate of the second service node on the blockchain; and send a second response message to the second service node, wherein the second response message carries the location information of the certificate of the second service node on the blockchain;

[0041] The fifth processing unit is configured to generate a certificate of the second service node.

[0042] An embodiment of the present application provides a first device, comprising a transceiver, a processor, and a memory. The memory is used to store a computer program, and the processor is used to call and run the computer program stored in the memory, so that the first device performs the above method.

[0043] An embodiment of the present application provides a first service node, comprising a transceiver, a processor, and a memory, wherein the memory is configured to store a computer program, and the processor is configured to call and execute the computer program stored in the memory, so that the first service node executes the above method.

[0044] An embodiment of the present application provides a second device, comprising a transceiver, a processor, and a memory, wherein the memory is used to store a computer program, and the processor is used to call and run the computer program stored in the memory, so that the second device performs the above method.

[0045] An embodiment of the present application provides a second service node, comprising a transceiver, a processor, and a memory, wherein the memory is used to store a computer program, and the processor is used to call and run the computer program stored in the memory, so that the second service node executes the above method.

[0046] An embodiment of the present application provides an issuing node, comprising a transceiver, a processor, and a memory. The memory is used to store a computer program, and the processor is used to call and run the computer program stored in the memory, so that the issuing node executes the above method.

[0047] The embodiment of the present application provides a chip for implementing the above method.

[0048] Specifically, the chip includes: a processor, which is used to call and run a computer program from a memory, so that a device equipped with the chip executes the above method.

[0049] An embodiment of the present application provides a computer-readable storage medium for storing a computer program, which enables a device to perform the above method when the computer program is executed by the device.

[0050] An embodiment of the present application provides a computer program product, including computer program instructions, which enable a computer to execute the above method.

[0051] An embodiment of the present application provides a computer program, which, when executed on a computer, enables the computer to execute the above method.

[0052] By adopting the communication method provided in this embodiment, the first device can send group parameters related to multiple target devices to the service node, so that the service node can calculate private keys based on the group parameters related to the multiple target devices. In this way, the corresponding private keys can be assigned to the groups of multiple target devices at one time through the proxy, thereby improving the efficiency of private key generation and management. In addition, because the private keys are generated or assigned based on the group parameters, the attacker cannot obtain the group parameters and, therefore, the private keys corresponding to the group parameters unless they can obtain the identifiers of each target device, thus ensuring the security of the private keys corresponding to the group parameters. Furthermore, because the target device does not need to increase storage content during the entire processing process, the target device's storage space can be saved, reducing the target device's storage costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] FIG1 is a schematic diagram of an application scenario according to an embodiment of the present application.

[0054] FIG2 is a schematic flowchart of a communication method according to an embodiment of the present application.

[0055] FIG3 is a schematic flowchart of a communication method according to another embodiment of the present application.

[0056] 4a-4b are schematic diagrams of two scenarios of a Merkle tree structure according to an embodiment of the present application.

[0057] FIG5 is a schematic flowchart of a communication method according to an embodiment of the present application.

[0058] FIG6 is a schematic flowchart of a communication method according to another embodiment of the present application.

[0059] FIG7 is a schematic flowchart of a communication method according to yet another embodiment of the present application.

[0060] FIG8 is a schematic flowchart of a communication method according to yet another embodiment of the present application.

[0061] FIG9 is a schematic diagram of a scenario of a two-tier identity architecture of a blockchain according to an embodiment of the present application.

[0062] FIG10 is a schematic flowchart of a communication method according to an embodiment of the present application.

[0063] FIG11 is a schematic flowchart of a communication method according to another embodiment of the present application.

[0064] FIG12 is a schematic flowchart of a communication method according to yet another embodiment of the present application.

[0065] FIG13 is a schematic block diagram of a first device according to an embodiment of the present application.

[0066] FIG14 is a schematic block diagram of a first service node according to an embodiment of the present application.

[0067] FIG15 is a schematic block diagram of a second device according to an embodiment of the present application.

[0068] FIG16 is a schematic block diagram of a second service node according to an embodiment of the present application.

[0069] FIG17 is a schematic block diagram of an issuing node according to an embodiment of the present application.

[0070] FIG18 is a schematic block diagram of a communication device according to an embodiment of the present application.

[0071] FIG19 is a schematic block diagram of a chip according to an embodiment of the present application.

[0072] Figure 20 is a schematic block diagram of a communication system according to an embodiment of the present application. DETAILED DESCRIPTION

[0073] The technical solutions of the embodiments of the present application can be applied to various communication systems, such as LTE, LTE-A, NR, NR evolution, WLAN, WiFi, or other communication systems.

[0074] The embodiments of the present application describe various embodiments in conjunction with network devices and terminals. The terminals can be mobile or fixed, and can also be referred to as mobile stations, user units, etc. The terminal can be a site in a WLAN, and can be a smart terminal, wireless modem, laptop computer, tablet computer, or other terminal. In the embodiments of the present application, the terminal can be a VR terminal / AR terminal, an industrial control terminal, an unmanned driving terminal, a telemedicine terminal, a smart grid terminal, a transportation safety terminal, a smart city terminal, or a wireless terminal for a smart home, etc. As an example and not a limitation, in the embodiments of the present application, the terminal can also be a wearable device.

[0075] In the embodiment of the present application, the network device may be a device for communicating with a terminal, an access point in a WLAN, an evolved base station in LTE, or a relay station, or a network device (gNB) in an in-vehicle device, a wearable device, and an NR network, or a network device in a future evolved PLMN network or a network device in a non-terrestrial network. As an example and not a limitation, in the embodiment of the present application, the network device may have a mobile feature, for example, the network device may be a mobile device.

[0076] It should be understood that the terms "system" and "network" are often used interchangeably in this article. The term "and / or" in this article is merely a description of the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article generally indicates that the objects associated before and after are in an "or" relationship. It should be understood that the "indication" mentioned in the embodiments of this application can be a direct indication, an indirect indication, or an indication of an association relationship. For example, A indicates B, which can mean that A directly indicates B, for example, B can be obtained through A; it can also mean that A indirectly indicates B, for example, A indicates C, and B can be obtained through C; it can also mean that there is an association relationship between A and B. In the description of the embodiments of this application, the term "corresponding" can mean that there is a direct or indirect correspondence between the two, or it can mean that there is an association relationship between the two, or it can mean a relationship between indication and indication, configuration and configuration, etc.

[0077] To facilitate understanding of the technical solutions of the embodiments of the present application, the relevant technologies of the embodiments of the present application are described below. The following relevant technologies can be arbitrarily combined with the technical solutions of the embodiments of the present application as optional solutions, and they all fall within the protection scope of the embodiments of the present application.

[0078] Figure 1 exemplarily illustrates a communication system 100. The communication system includes a network device 110 and two terminals 120. In one possible implementation, the communication system 100 may include multiple network devices 110, and each network device 110 may include a different number of terminals 120 within its coverage area, although this embodiment of the present application does not limit this. In one possible implementation, the communication system 100 may also include a mobility management entity, access and mobility management functions, and other network entities, although this embodiment of the present application does not limit this. The network devices may include access network devices and core network devices. That is, the communication system may also include multiple core networks for communicating with the access network devices. The access network devices may be base stations of LTE, LTE-A, or NR systems. Taking the communication system shown in Figure 1 as an example, the communication devices may include network devices and terminals with communication functions. The communication devices may also include other devices in the communication system, such as network controllers, mobility management entities, and other network entities, although this embodiment of the present application does not limit this.

[0079] Figure 2 is a schematic flow chart of a communication method performed by a first device according to an embodiment of the present application. The method includes at least part of the following contents.

[0080] S210: Send a group request message to the first service node, where the group request message carries a group parameter, and the group parameter is calculated based on identifiers of multiple target devices;

[0081] S220: Receive a group response message from the first service node, where the group response message carries a private key corresponding to the group parameter.

[0082] Figure 3 is a schematic flow chart of a communication method performed by a first service node according to another embodiment of the present application. The method includes at least part of the following contents.

[0083] S310. Receive a group request message from a first device, wherein the group request message carries a group parameter;

[0084] S320. Calculate a private key corresponding to the group parameter based on the group parameter;

[0085] S330: Send a group response message to the first device, where the group response message carries a private key corresponding to the group parameter.

[0086] The first device may be alternatively referred to as a proxy device, a proxy node, or a proxy, etc., and the various possible names of the first device are not exhaustively listed or limited here. The first device includes one of the following: a terminal, an access network device. Optionally, the first device is an access network device, and the access network device may be any one of the following: a base station, a gNB, an eNB, an integrated access backhaul (IAB) node, etc. Optionally, the first device is a terminal, and the terminal may be a terminal with certain computing capabilities. In some possible examples, the terminal may be a normal terminal. In other possible examples, the terminal may also be an IoT device with certain processing capabilities. All possible types of the terminal are not exhaustively listed here.

[0087] The target device includes one of the following: a zero-power device, an Internet of Things device. The number of the multiple target devices is not limited in this embodiment.

[0088] In some embodiments, any target device can be any of the following: an ambient power-enabled IoT (AIoT) device, an active zero-power device, a passive zero-power device, a semi-passive zero-power device, and the like. In some embodiments, any target device can also be a terminal with lower computing power. In some possible embodiments, any target device can be referred to as a tag. This does not exhaustively list all possible names or possible device types for the target device.

[0089] In some embodiments, the first device is a terminal. In such embodiments, the first device and any target device can communicate by transmitting sidelink messages. In some embodiments, the first device is an access network device. In such embodiments, the first device and any target device can communicate by transmitting AS (Access Stratum) messages.

[0090] In some possible implementations, the first device obtains identifiers of multiple target devices, and the identifiers of the multiple target devices are used to generate or calculate group parameters.

[0091] In some embodiments, the multiple target devices are all devices in the same group managed by the first device. In this case, the first device may obtain the identification of each target device in advance. This embodiment does not limit how the first device obtains the identification of each target device in advance.

[0092] The identifier can be expressed as an ID, which may include but is not limited to at least one of the following: a factory identifier, a factory unique identifier, an identifier issued by an operator, an identifier issued by a service provider, SUPI (Subscription Permanent Identifier), SUCI (Subscription Concealed Identifier), PEI (Permanent Equipment Identifier), 5G-GUTI (5G Globally Unique Temporary Identifier), Internal-Group Identifier (IGI), GPSI (Generic Public Subscription Identifier), network identifier, etc.; wherein the network identifier may include at least one of: IP address (Internet Protocol Address), MAC (Media Access Control) address, etc.

[0093] In some embodiments, the identification of each target device in the plurality of target devices is sent by each target device to the first device.

[0094] Specifically, processing each target device may include: sending a registration request to the first device, where the registration request carries its own identifier. Accordingly, before the first device sends a group request message to the first service node, the process may also include: receiving a registration request from each of the multiple target devices, where the registration request from each target device carries the identifier of each target device.

[0095] In this embodiment, each of the multiple target devices in the group may send a registration request to the first device based on a configured registration time. The registration time may alternatively be referred to as a registration request sending time, a registration initiation time, or the like, without limiting the enumeration herein. This embodiment does not limit the manner in which each target device configures the registration time.

[0096] Optionally, the registration time corresponding to each target device may be the same.

[0097] Optionally, the registration time corresponding to each target device may be different; for example, the registration time corresponding to each target device is included in a specified time period, and the registration time corresponding to different target devices may be different, wherein the specified time period can be configured according to actual conditions, for example, it may be within 10 minutes, or within 5 minutes, or within a specified start time and a specified duration (or from a specified start time to a specified end time), etc.

[0098] The first device receiving a registration request from each of the multiple target devices may include receiving a registration request from each of the multiple target devices within a specified time period. In other words, the first device may continuously monitor or receive registration requests from target devices within the specified time period until the end of the specified time period. In this case, the first device performs subsequent registration processing for the target devices that sent registration requests within the specified time period.

[0099] In some possible implementations, the group parameter is calculated based on identifications of multiple target devices.

[0100] In one embodiment, the group parameter is calculated by the first device based on identifiers of multiple target devices.

[0101] In this embodiment, the process of calculating the group parameter by the first device may include: calculating a parameter value of each target device based on an identifier of each target device among the multiple target devices; and calculating the group parameter based on the parameter value of each target device.

[0102] Calculating the parameter value of each target device based on the identifier of each target device among the multiple target devices may include: storing the identifier of each target device among the multiple target devices in each leaf node; calculating the parameter value of each target device based on the identifier of each target device stored in each leaf node, and storing the parameter value of each target device in the parent node of the corresponding leaf node. Calculating the group parameter based on the parameter value of each target device may include: calculating the group parameter based on the parameter value stored in the parent node of each leaf node, and storing the group parameter in the root node.

[0103] That is, a Merkle tree is constructed on the first device side based on the identifier of each target device, each leaf node of the Merkle tree corresponds to or stores the identifier of each target device, and the root node Root of the Merkle tree corresponds to the group parameter.

[0104] Storing the identifier of each target device in the plurality of target devices in each leaf node may refer to storing the identifiers of different target devices in different leaf nodes. For example, if there are K target devices in total, the identifier of the i-th target device in the K target devices is stored in the i-th leaf node in the K leaf nodes, where K is an integer greater than or equal to 2, and i is an integer greater than or equal to 1 and less than or equal to K (or, i is an integer greater than or equal to 0 and less than or equal to K-1).

[0105] It should be noted that in a Merkle tree, as long as any node has a corresponding next-level node, the node can be the parent node of its corresponding next-level node. Correspondingly, as long as any node has a corresponding previous-level node, the node can be the child node of its corresponding previous-level node. Furthermore, a Merkle tree can include multiple intermediate nodes. Any intermediate node refers to a node that has both a parent node and a child node. The number of child nodes corresponding to an intermediate node can be one or more. In the case where the next-level child node of an intermediate node is a leaf node, the intermediate node corresponds to only one child node. In the case where the next-level child node of an intermediate node is not a leaf node, the intermediate node can correspond to multiple child nodes. In other words, in a Merkle tree, only leaf nodes and their corresponding parent nodes have a one-to-one correspondence. Therefore, in order to distinguish intermediate nodes, the intermediate node that only corresponds to a leaf node is fixedly referred to as the parent node of the leaf node, and the intermediate nodes other than the parent node of the leaf node are still referred to as intermediate nodes. That is, the intermediate nodes mentioned below are all intermediate nodes other than the parent node of the leaf node, and the explanation will not be repeated below.

[0106] Calculating a parameter value for each target device based on the identifier of each target device stored in each leaf node, and storing the parameter value for each target device in the parent node of the corresponding leaf node may refer to: performing a hash calculation on the identifier of the i-th target device stored in the i-th leaf node to obtain a hash value of the i-th target device, using the hash value of the i-th target device as the parameter value of the i-th target device; and storing the parameter value of the i-th target device in the parent node of the i-th leaf node. The i-th leaf node is the only child node of its corresponding parent node.

[0107] Calculating the group parameters based on the parameter values ​​stored in the parent node of each leaf node and storing the group parameters in the root node may mean: calculating the parameter values ​​of each target device based on the parent node of each leaf node, obtaining the parameter values ​​of each intermediate node, and so on, until the group parameters are calculated, and storing the group parameters in the root node.

[0108] Specifically, in a Merkle tree, except for the parent node of a leaf node, each intermediate node corresponds to multiple child nodes, and different intermediate nodes correspond to different child nodes. The parameter value can be a hash value. That is, any intermediate node is used to store the hash value of the content of the corresponding child node.

[0109] Taking any intermediate node as intermediate node j as an example, where j is an integer greater than or equal to 0, or j is an integer greater than or equal to 1, calculating the parameter value of each intermediate node based on the parameter value of each target device stored in the parent node of each leaf node may refer to: when each of the multiple child nodes corresponding to intermediate node j is the parent node of each leaf node, obtaining the parameter value stored in the parent node of each leaf node corresponding to intermediate node j, summing the parameter values ​​stored in the parent node of each leaf node to obtain the jth first value, performing a hash calculation on the jth first value to obtain the jth hash value, and using the jth hash value as the parameter value of the intermediate node j; when each of the multiple child nodes corresponding to intermediate node j is not the parent node of the leaf node, obtaining the parameter value stored in each child node corresponding to intermediate node j, summing the parameter values ​​stored in each child node to obtain the jth second value, performing a hash calculation on the jth second value to obtain the jth hash value, and using the jth hash value as the parameter value of the intermediate node j.

[0110] The method for determining the multiple child nodes corresponding to intermediate node j may include determining the multiple adjacent child nodes at the next level below intermediate node j as the multiple child nodes corresponding to intermediate node j. The adjacentness may refer to numbering, logical proximity, or proximity determined based on a default rule, which is not limited in this embodiment. As long as all the child nodes corresponding to intermediate node j are ultimately determined to be different from all the child nodes corresponding to other intermediate nodes, they are within the scope of protection of this embodiment.

[0111] The root node may be a node in the Merkle tree that does not have an upper-level parent node; the root node may correspond to multiple child nodes (i.e., multiple child nodes at the next level of the root node), and each of the multiple child nodes is not a leaf node. In this case, the content of any child node corresponding to the root node is the parameter value stored in the child node (i.e., a hash value); the group parameter stored in the root node may be obtained by performing a hash calculation on the parameter value stored in each child node corresponding to the root node. Specifically, the calculation method of the group parameter may include: obtaining the parameter value stored in each of the multiple child nodes corresponding to the root node; summing the parameter value stored in each child node corresponding to the root node to obtain a third value, performing a hash calculation on the third value to obtain a third hash value; and using the third hash value as the group parameter.

[0112] In one possible example, the Merkle tree structure is a binary tree structure. Therefore, any intermediate node, except the parent node of a leaf node, can correspond to two child nodes. For example, FIG4a includes eight leaf nodes corresponding to eight target devices in a group. These eight leaf nodes are used to store the IDs of each target device. For example, leaf node 41 stores ID 1 of target device 1. The other leaf nodes are not described again. In Figure 4a, leaf node 41 corresponds to a unique parent node 411. Accordingly, the parameter value stored in the parent node 411 of leaf node 41 is the hash value Hash(ID1) calculated based on ID1 of leaf node 41. For example, the hash value stored in the parent node 411 of leaf node 41 can be expressed as N1. The calculation method of the parameter values ​​stored in the parent nodes of other leaf nodes at the same level as the parent node 411 of leaf node 41 (such as node 410, node 412, node 413, etc., which are all parent nodes of a certain leaf node and are not listed here one by one) is the same as that of the parent node 411 of leaf node 41, and will not be repeated one by one. The next level child node of the intermediate node 422 is not a leaf node. The next level of the intermediate node 422 corresponds to two child nodes, namely child node 412 and child node 413. The parameter value stored in the intermediate node 422 is the hash value Hash(N2+N3) obtained by hashing the hash value (N2) of the child node 412 and the hash value (N3) of the child node 413. The hash value (i.e., parameter value) stored in the intermediate node 422 can be expressed as N9. The calculation method of the parameter values ​​stored in all other intermediate nodes in Figure 4a (such as intermediate node 412, intermediate node 431, intermediate node 432, etc., which are not listed one by one) is the same as that of the intermediate node 422 and will not be repeated one by one. The next level of the root node 440 corresponds to two child nodes, namely child node 431 and child node 432. The group parameter stored in the root node 440 (i.e., Root shown in Figure 4a) is equal to the hash value (N 12 ) and the hash value of child node 432 (N 13 ) and the hash value Hash(N 12 +N 13 ). The above is only an exemplary description of some nodes in Figure 4a. In actual processing, the calculation method of the content stored in each node at each level in the Merkle tree is similar to the above example, so it is not repeated one by one.

[0113] In some possible examples, the aforementioned group parameters can also be alternatively referred to as federated identity, or alternatively referred to as federated identity information, or alternatively represented as Root, or alternatively expressed as root node value, or alternatively referred to as root node value Root, etc., and will not be repeated below.

[0114] In some embodiments, the group parameter is calculated based on the identification of the first device and the identifications of the multiple target devices.

[0115] The process of calculating the group parameter by the first device may include: calculating a parameter value of each target device based on an identifier of each target device; and calculating the group parameter based on the parameter value of each target device. Calculating the group parameter based on the parameter value of each target device includes: calculating the group parameter based on the parameter value of each target device and the identifier of the first device.

[0116] That is, in this embodiment, the processing of the first device calculating the group parameters may include: calculating the parameter value of each target device based on the identifier of each target device in the multiple target devices; calculating the group parameters based on the parameter value of each target device and the identifier of the first device.

[0117] In one embodiment, when calculating the group parameters, the identifier of the first device is added.

[0118] In this embodiment, a Merkle tree is constructed on the first device side based on the identifier of the first device and the identifier of each target device. All leaf nodes of the Merkle tree are used to store the identifier of each target device respectively, and the root node Root of the Merkle tree corresponds to the group parameters of the identities of all target devices and the first device (i.e., the joint identity).

[0119] The specific processing manner of calculating the parameter value of each target device based on the identifier of each target device among the multiple target devices is the same as that in the above embodiment.

[0120] Exemplarily, calculating the group parameter based on the parameter value of each target device and the identifier of the first device may include: calculating the parameter value of each intermediate node based on the parameter value of each target device stored in the parent node of each leaf node, and so on, until the parameter value stored in each child node corresponding to the root node is calculated, adding the parameter values ​​stored in each child node corresponding to the root node to obtain a third value, and hashing the third value to obtain a third hash value; hashing the identifier of the first device to obtain a fourth hash value, and summing the third hash value and the fourth hash value to obtain the group parameter; and storing the group parameter in the root node.

[0121] Exemplarily, calculating the group parameter based on the parameter value of each target device and the identifier of the first device may include: calculating the parameter value of each intermediate node based on the parameter value of each target device stored in the parent node of each leaf node, and so on, until the parameter value stored in each child node corresponding to the root node is calculated, and obtaining the parameter value stored in each child node of the multiple child nodes corresponding to the root node; adding the parameter value stored in each child node corresponding to the root node and the identifier of the first device to obtain a fourth value, and performing a hash calculation on the fourth value to obtain the group parameter; and storing the group parameter in the root node.

[0122] In this embodiment, except that the group parameters of the root node are different from those in the previous embodiment, the remaining descriptions about the leaf nodes and intermediate nodes are the same as those in the previous embodiment, and therefore are not repeated here.

[0123] In one embodiment, the identifier of the first device is added to the Merkle tree as a leaf node. That is, the first device constructs a Merkle tree based on the identifier of the first device and the identifier of each target device. All leaf nodes of the Merkle tree are used to store the identifier of each target device and the identifier of the first device, respectively. The root node of the Merkle tree corresponds to the group parameters of all target devices and the first device.

[0124] Specifically, based on the identifier of each target device among the multiple target devices, the parameter value of each target device is calculated; based on the parameter value of each target device and the identifier of the first device, the group parameter is calculated, which may include: storing the identifier of each target device among the multiple target devices to the corresponding leaf node, calculating the parameter value of each target device based on the identifier of each target device, and storing the parameter value of each target device to the parent node of the corresponding leaf node; and storing the identifier of the first device to the corresponding leaf node, calculating the parameter value of the first device based on the identifier of the first device, and storing the parameter value of the first device to the parent node of the corresponding leaf node; calculating the group parameter based on the parameter value stored in the parent node of each leaf node, and storing the group parameter to the root node.

[0125] In this embodiment, with the exception of the addition of a leaf node for storing the identifier of the first device, the calculation method for the parameter values ​​stored by the parent node of any leaf node and the calculation method for the parameter values ​​stored by any intermediate node are the same as those in the previous embodiment and are therefore not repeated here. Similarly, the group parameters of the root node are still calculated by summing the parameter values ​​stored by each child node corresponding to the root node and then performing a hash calculation, and this description is also not repeated here.

[0126] For example, FIG4b includes 8 leaf nodes, wherein 1 leaf node corresponds to the ID of the first device, and the remaining 7 leaf nodes correspond to 7 target devices in a group. The 7 leaf nodes are respectively used to store the ID of each target device in the group. For example, leaf node 40a stores the ID of the first device. A , leaf node 41 stores the ID1 of target device 1. Except for leaf node 40a which is different from FIG4a, the other leaf nodes are similar to the relevant description of FIG4a, so they are not repeated. In FIG4b, leaf node 40a corresponds to a unique parent node 410a. Accordingly, the parameter value stored in the parent node 410a of leaf node 40a is based on the ID of leaf node 40a. A The calculated hash value Hash(ID A ), for example, the hash value stored in the parent node 410a of the leaf node 40a can be expressed as N0; the relevant descriptions about other intermediate nodes and the root node 440 are similar to those in FIG4a, and therefore will not be repeated.

[0127] Taking the first device as the proxy device, any one of the target devices as the zero-power device, and all the target devices forming a zero-power device group as an example, since the zero-power device does not have the computing power to run various cryptographic algorithms, the IoT terminal, or terminal, or access network device with computing power is entrusted (assuming that the proxy device A is entrusted, hereinafter referred to as proxy A) to act as the proxy for the zero-power device group to manage the private key and perform the identity authentication process. At the same time, it is also assumed that the ability of proxy A is not restricted (that is, A has the ability to search for certificates on the blockchain and verify whether the identity of the other party in the communication has been revoked). Since the scale of the zero-power group is too large, the Merkle tree is used to manage the identity of the zero-power device group. By adopting the above solution, the identity ID of proxy A can be A It is bound to the identity ID1...ID7 of each device in the zero-power device group as the leaf node of the Merkle tree, and the final root node Root is used as the joint identity information (i.e., group parameter) of the zero-power device group. After executing the solution provided by this embodiment, the proxy device can obtain the private key corresponding to the joint identity (i.e., Root) used by all zero-power devices (the private key corresponding to the group parameter).

[0128] In one embodiment, the group parameter may be calculated by another device based on the identifiers of multiple target devices. In this case, the first device may obtain the group parameter from the other device. The specific method by which the first device obtains the group parameter is not limited in this embodiment. The other device may have at least computing and communication functions. The process by which the other device calculates the group parameter is the same as described above and is not repeated here.

[0129] In some possible implementations, the first device may carry the group parameters in a group request message and send it to the first service node, so that the first service node generates a private key corresponding to the group parameters after receiving the group registration request message from the first device.

[0130] Here, the function of the group request message may be to request the private key corresponding to the group parameters. The group request message may be any type of message, or the group request message may be a message sent in any process. In some preferred examples, the group request message is a message sent when the first device initiates registration as a group agent. In such examples, the group request message may also be referred to as a registration request, a group registration request, a group registration request message, etc., without limiting or enumerating all possible names.

[0131] The first service node may perform a process of calculating a private key corresponding to the group parameter based on the group parameter. This process may include: the first service node and the first federated node jointly calculating the private key corresponding to the group parameter based on the group parameter. In other words, the first service node and the first federated node may perform a joint calculation based on the group parameter using a joint calculation method to obtain the private key corresponding to the group parameter. This joint calculation method may alternatively be referred to as a joint secure calculation method, a joint secure calculation method, or the like.

[0132] The first service node may be a key generation center (KGC). The first joint node is used to perform joint calculations with the first service node. In some possible examples, the first service node may be an operator (such as an operator server, or an operation server, or an operator's first service node, etc., which are not exhaustive here), and the first joint node may be a business party (such as a business party server, or a business node, or a business party service node, or a business party's first joint node, etc., which are not exhaustive here), that is, the business party and the operator jointly calculate to obtain a private key, and the operator, as the KGC, distributes the private key to the group. In some possible examples, the first service node may be a business party (such as a business party server, or a business node, or a business party service node, or a business party's first service node, etc., which are not exhaustive here), and the first joint node may be an operator (such as an operator server, or an operation server, or an operator's first joint node, etc., which are not exhaustive here), that is, the business party and the operator jointly calculate to obtain a private key, and the business party distributes the private key to the group. It should be understood that this is merely an exemplary description. In actual processing, the first service node and the first joint node may not be limited to the possibilities of the above examples, but this embodiment does not limit or exhaustively list them.

[0133] More specifically, the first service node performs processing based on the group parameter to calculate the private key corresponding to the group parameter, which may specifically include: sending the group parameter to the first joint node; receiving a first group security parameter from the first joint node, wherein the first group security parameter is calculated based on the group parameter; and calculating the private key corresponding to the group parameter based on the first group security parameter and the group parameter.

[0134] The calculating of the private key corresponding to the group parameter based on the first group security parameter and the group parameter includes: calculating the second group security parameter based on the group parameter and the master private key of the first service node; and calculating the private key corresponding to the group parameter based on the first group security parameter and the second group security parameter.

[0135] Accordingly, the processing of the first joint node may include: receiving the group parameter from the first service node; calculating a first group security parameter based on the group parameter and the master private key of the first joint node; and sending the first group security parameter to the first service node.

[0136] The following first introduces the calculation parameters needed for the joint calculation: q: a large prime number; G1, G2: two additive groups on the elliptic curve of order q; P1, P2: arbitrary generators corresponding to G1 and G2 respectively; G T : multiplicative group over a finite field of order q; e: bilinear map G1×G2→G T ; All integers in the finite field [1,q-1]; P pub =s·P2, where s1 is the first service node from Any random number selected from , s2 is the first joint node from Any random number selected from the first service node, and satisfying the relationship s = s1 + s2; r = r1 + r2, where r1 is the random number selected from the first service node Any random number selected from Any random number selected; g = e(P1, P pub );H v : cryptographic hash function; hid: function identifier; master public key MPK = (G1, G2, G T ,e,P1,P2,P pub , g, H v , hid) is public; the master private key MSK = (s1, r1) of the first service node is kept confidential, and the master private key MSK = (s2, r2) of the first unification node is also kept confidential; F, H1, H2 are functional functions supported by the system. The description of the first service node and the first unification node is the same as in the previous embodiment and is not repeated here.

[0137] Furthermore, based on the description of the calculation parameters above, two-party secure calculation can be applied to the key generation algorithm in the SM9 digital signature scheme. In the process of calculating the private key corresponding to the group parameter, the master private keys of the first service node and the first joint node (i.e., the business party and the operator) are required to be used. Therefore, the first service node and the first joint node (i.e., the business party and the operator) need to perform joint calculations based on the group parameter to ultimately obtain the private key corresponding to the group parameter. The following is a detailed description of the method for calculating the private key corresponding to the group parameter:

[0138] The first joint node calculates the first group security parameter based on the group parameter and the master private key of the first joint node, which may include: calculating the first parameter based on a functional function supported by the system, a cryptographic hash function, a function identifier, a large prime number, a group parameter, and the master private key of the first joint node; calculating the second parameter based on the first parameter and the master private key of the first joint node; calculating the third parameter based on the master private key of the first joint node; using MtA to calculate to obtain multiple fourth parameters and multiple fifth parameters; and using the second parameter, the third parameter, the multiple fourth parameters, and the multiple fifth parameters as the first group security parameter.

[0139] The first service node calculates the second group security parameter based on the group parameter and the master private key of the first service node, which may include: calculating a sixth parameter based on a functional function supported by the system, a cryptographic hash function, a function identifier, a large prime number, a group parameter, and the master private key of the first service node; calculating a seventh parameter based on the sixth parameter and the master private key of the first service node; calculating an eighth parameter based on the master private key of the first service node; using MtA to calculate to obtain multiple ninth parameters and multiple tenth parameters; and using the seventh parameter, the eighth parameter, the multiple ninth parameters, and the multiple tenth parameters as the second group security parameter.

[0140] The first service node calculates the private key corresponding to the group parameter based on the first group security parameter and the second group security parameter, which may include: performing a sum calculation based on the second parameter, the sixth parameter, multiple fourth parameters, and multiple ninth parameters to obtain a first calculated value; performing a sum calculation based on the third parameter, the seventh parameter, multiple fifth parameters, and multiple tenth parameters to obtain a second calculated value; and calculating the private key corresponding to the group parameter based on the first calculated value and the second calculated value.

[0141] The derivation process of the above calculation process is as follows: the private key sk corresponding to the group parameter Root The calculation method is expressed as: sk Root =s·t1 -1 P1=s·r·(t1·r) -1 ·P1. Where, t1·r=[s+H1(Hv ,ID Root ||hid,q)]·(r1+r2), ID Root is the group parameter.

[0142] The calculation of the fifth parameter x1 by the first service node can be expressed as: s1+2H1(H v ,ID Root ||hid,q)=x1; The first parameter x2 calculated by the first joint node can be expressed as: s2-H1(H v ,ID Root ||hid,q)=x2. The first parameter and the fifth parameter are stored and kept secret in their respective nodes.

[0143] In the above, t1·r=(x1+x2)·(r1+r2)=x1·r1+x1·r2+x2·r1+x2·r2. s·r=(s1+s2)·(r1+r2)=s1·r1+s1·r2+s2·r1+s2·r2.

[0144] In the process of calculating t1·r, the first service node locally calculates the seventh parameter x1·r1, and the first joint node locally calculates the second parameter x2·r2; for x1·r2, MtA is used to calculate, and the result obtained by the first service node is recorded as α 12 , the result obtained by the first joint node is recorded as β 12 , satisfying x1·r2=α 12 +β 12 For x2·r1, MtA is used for calculation, and the result obtained by the first service node is recorded as α 21 , the result obtained by the first joint node is recorded as β 21 , satisfying x2·r1=α 21 +β 21 .

[0145] In the process of calculating s·r, the first service node locally calculates the eighth parameter s1·r1, and the first joint node locally calculates the third parameter s2·r2; for s1 and r2, MtA is used to calculate, and the result obtained by the first service node is recorded as λ 12 , the result obtained by the first joint node is recorded as δ 12 , satisfying s1·r2=λ 12 +δ 12 For s2 and r1, use MtA to calculate, and the result obtained by the first service node is recorded as λ 21 , the result obtained by the first joint node is recorded as δ 21 , satisfying x2·r1=λ 21 +δ 21 .

[0146] After the above derivation, the second parameter of the first group of security parameters is x2·r2, the third parameter is s2·r2, and the fourth parameters include β 21 , β 12 , multiple fifth parameters include δ 12 , δ 21 The second group security parameters include the seventh parameter x1·r1, the eighth parameter s1·r1, and multiple ninth parameters α 12 , α 21 , multiple tenth parameters are λ 21 ,λ 12 .

[0147] After obtaining all the aforementioned parameters, the first service node can calculate the first calculated value as: t1·r=x1·r1+α 12 +β 12 +α 21 +β 21 +x2·r2. After obtaining t1·r, the first service node can calculate (t1·r) in plain text -1 After obtaining all the aforementioned parameters, the first service node can calculate the second calculated value as follows: s·r=s1·r1+λ 12 +δ 12 +λ 21 +δ 21 +s2·r2. Finally, the first service node uses the following formula to calculate the private key corresponding to the group parameter: sk Root =s·r·(t1·r) -1 ·P1. The meaning and calculation method of each parameter in this formula have been explained above and will not be repeated here. In addition, “·” in the above formula can be a dot product calculation.

[0148] In some possible implementations, after the first service node obtains the private key corresponding to the group parameter through joint calculation, the first service node may carry the private key corresponding to the group parameter in a group response message and send the message to the first device.

[0149] Here, the function of the group response message can be used to respond to the group request message. The group response message can be any type of message. In some preferred examples, the group request message is a message sent when the first device initiates registration as a group agent. In such examples, the group response message can also be used to indicate to the first device that the group registration is complete. The group response message can also be called a registration response, a group registration response, a group registration response message, etc., and all possible names are not limited or exhaustive here.

[0150] In some possible implementations, the group request message may further carry the identifiers of the multiple target devices and the identifier of the first device.

[0151] In some embodiments, after receiving the identifiers of multiple target devices and the identifier of the first device, the first service node may further perform the following processing: reviewing the multiple target devices based on the identifier of each target device, and / or reviewing the first device based on the identifier of the first device.

[0152] Optionally, the first service node's review of the first device based on the first device's identifier may include at least one of: reviewing whether the first device is legitimate based on the first device's identifier; and / or reviewing whether the first device has been revoked based on the first device's identifier being uploaded to the chain; and / or reviewing whether the first device can serve as a proxy device for each target device based on the first device's identifier, etc. This does not exhaustively enumerate or elaborate on all possible processes that may be involved in the first service node's review of the first device.

[0153] Optionally, the process of the first service node reviewing each target device based on the identifier of each target device may include:

[0154] Based on the identification of each target device, at least one of: verifying whether each target device is a legitimate device; and / or verifying whether the proxy device of each target device is the first device based on the identification of each target device. Here, all possible processes that may be included in the first service node's verification of each target device are not exhaustively listed or elaborated.

[0155] Optionally, after receiving the identifiers of multiple target devices and the identifier of the first device, the first service node may also perform the following processing: calculate verification parameters based on the identifiers of multiple target devices, and authenticate the multiple target devices based on the verification parameters and group parameters; or calculate verification parameters based on the identifiers of multiple target devices and the identifier of the first device, and review the multiple target devices based on the verification parameters and group parameters.

[0156] In one case, the process of calculating the verification parameters based on the identifiers of multiple target devices is the same as the method of using only the identifier of each target device as the group parameter of each leaf node in the aforementioned embodiment. The only difference is that since the calculation is performed at the first service node, the result calculated by the first service node is called the verification parameter.

[0157] In another case, the process of calculating the verification parameters based on the identifiers of multiple target devices and the identifier of the first device is the same as the several possible ways of calculating the group parameters by combining the identifier of the first device and the identifier of each target device in the aforementioned embodiment. The only difference is that since the calculation is performed at the first service node, the result calculated by the first service node is called the verification parameter.

[0158] The reviewing of the multiple target devices based on the verification parameters and the group parameters may include: when the verification parameters and the group parameters are the same, determining that the review of the multiple target devices is successful.

[0159] In some embodiments, after the first service node audits the multiple target devices based on the identifier of each target device, and / or audits the first device based on the identifier of the first device, the process may also include: if the first service node successfully audits the multiple target devices, and / or successfully audits the first device, performing processing to calculate the private key corresponding to the group parameter, which will not be described in detail here. Whether the first service node audits multiple target devices, audits both the target device and the first device, or only audits the first device, all fall within the scope of protection of this embodiment, and every possible situation will not be limited or enumerated here.

[0160] In some possible implementations, the first device or the first service node may further perform uplink processing on the group parameters.

[0161] In one example, the first device may also perform the following processing: uploading the group parameters to the blockchain. Specifically, the first device uploads and stores the group parameters on the blockchain. The first device may upload the group parameters to the blockchain at any time after the first device calculates or obtains the group parameters. For example, this may be after the first device calculates or obtains the group parameters and before the first device sends a group request message. Another example may be after the first device receives a group response message. This is not intended to be an exhaustive list or limitation of all possible processing times.

[0162] In one example, the first service node's processing may include uploading the group parameters to the blockchain. Specifically, the first service node uploads the group parameters and saves them on the blockchain. The first service node may upload the group parameters to the blockchain at any time after the first service node obtains the group parameters. For example, this may be after the first service node obtains the group parameters and before the first service node sends a group response message. Another example is after the first service node sends the group response message, and so on. This does not exhaustively list or limit all possible processing times.

[0163] It should also be understood that the status of the group parameters (such as whether they are revoked) can also be maintained by the first device; or, the status of the group parameters can be maintained by the first service node. This embodiment does not exhaustively list and limit all possible maintenance methods.

[0164] In some possible implementations, after receiving the private key corresponding to the group parameters (i.e., a group response message), the first device further includes: if there is a revoked device among the multiple target devices, sending a group update message to the first service node, wherein the group update message carries the updated group parameters, and the updated group parameters are updated based on the identifier of the revoked device; receiving a group update response message from the first service node, wherein the group update response message carries the private key corresponding to the updated group parameters. Accordingly, the processing of the first service node may also include: receiving a group update message from the first device, wherein the group update message carries the updated group parameters; calculating the private key corresponding to the updated group parameters based on the updated group parameters; and sending a group update response message to the first device, wherein the group update response message carries the private key corresponding to the updated group parameters.

[0165] The first device can determine whether there is a revoked device among the multiple target devices by periodically detecting the status of each target device and determining that the target device is a revoked device if any target device is not in the group. Alternatively, the first device can detect whether it has received a revocation notification from any target device and, if so, determine that the target device is a revoked device. The above is merely an example, and the first device can determine a revoked device in many different ways, which are not exhaustive here.

[0166] The method for the first device to calculate the updated group parameters may include: deleting the first parameter value corresponding to the identifier of the revoked device; determining one or more associated parameter values ​​related to the first parameter value; updating the one or more associated parameter values ​​to obtain the updated one or more associated parameter values; and calculating the updated group characteristic value based on the updated one or more associated parameter values. That is, the first device updates the Merkle tree based on the identifier of the revoked device, each leaf node of the updated Merkle tree corresponds to or stores the identifiers of other devices (other target devices other than the revoked device, or other target devices other than the revoked device and the first device) other than the identifier of the revoked device, and the root node Root of the Merkle tree corresponds to the updated group parameters.

[0167] Deleting the first parameter value corresponding to the identifier of the revoked device may include deleting the first leaf node storing the identifier of the revoked device from the Merkle tree, and also deleting the parent node of the first leaf node from the Merkle tree. For example, if there are K target devices, the i-th target device among the K target devices is the revoked device, the identifier of the revoked device is stored in the i-th leaf node among the K leaf nodes, the i-th leaf node is deleted, and the parent node of the i-th leaf node is deleted.

[0168] Determining one or more associated parameter values ​​related to the first parameter value may refer to: taking the parent node of the first leaf node as the current node, searching the upper-level intermediate node corresponding to the current node from the Merkle tree, and judging whether the upper-level intermediate node is the root node; if not, taking the upper-level intermediate node as an associated intermediate node related to the first parameter value, taking the associated intermediate node as the current node, searching the upper-level intermediate node corresponding to the current node from the Merkle tree, and judging whether the upper-level intermediate node is the root node; and so on, until it is determined that the upper-level intermediate node of the current node is the root node, and taking the parameter value stored in each associated intermediate node among all the determined associated intermediate nodes as each associated parameter value.

[0169] Taking any associated intermediate node as associated intermediate node n as an example, where n is an integer greater than or equal to 0, or n is an integer greater than or equal to 1. Updating the one or more associated parameter values ​​to obtain the one or more updated associated parameter values ​​may refer to: when the multiple child nodes corresponding to the associated intermediate node n include the parent node of the first leaf node, obtaining the parameter value stored in the parent node of each leaf node corresponding to the associated intermediate node n except the parent node of the first leaf node, summing the parameter values ​​stored in the parent node of each leaf node to obtain an nth first adjustment value, and performing a hash calculation on the nth first adjustment value to obtain the updated associated parameter value of the associated intermediate node n; and when each child node among the multiple child nodes corresponding to the associated intermediate node n is not the parent node of the leaf node, obtaining the parameter value stored in each child node corresponding to the associated intermediate node n, summing the parameter values ​​stored in each child node to obtain an nth second adjustment value, and performing a hash calculation on the nth second adjustment value to obtain the updated associated parameter value of the associated intermediate node n.

[0170] Calculating the updated group feature value based on the updated one or more associated parameter values ​​may include: obtaining the parameter value stored in each of the multiple child nodes corresponding to the root node, wherein the multiple child nodes include an associated intermediate node; summing up the parameter value stored in each child node corresponding to the root node to obtain a third adjustment value, performing a hash calculation on the third adjustment value to obtain an updated group parameter, and storing the updated group parameter in the root node.

[0171] In a possible example, referring to FIG4a, FIG4a includes 8 leaf nodes corresponding to 8 target devices in a group. The 8 leaf nodes are used to store the ID of each target device, target device 1 is a revoked device, and leaf node 41 stores the ID 1 of target device 1. Leaf node 41 and its corresponding only parent node 411 are deleted from the Merkle tree. Accordingly, all associated intermediate nodes of parent node 411 of leaf node 41 may include associated intermediate nodes 421 and associated intermediate nodes 431 in FIG4a. Therefore, it is necessary to update the associated parameter values ​​stored in nodes 421 and 431. For example, the updated associated parameter value of node 421 is the updated hash value (N8) calculated based on the hash value (N0) of child node 410, and the updated associated parameter value of node 431 is the hash value Hash (N8+N9) obtained by hashing the updated associated parameter of child node 421 and the hash value (N9) of child node 422. The next level of the root node 440 corresponds to two child nodes, namely the associated intermediate node 431 and the child node 432. The updated group parameter of the root node 440 (ie, Root shown in FIG4a ) is equal to the hash value (N 12 ) and the hash value of child node 432

[0172] (N 13 ) and the hash value Hash(N 12 +N 13 ).

[0173] It should be understood that the above is only an exemplary explanation of the calculation method of the updated group parameters in combination with Figure 4a. In actual processing, the Merkle tree can also be calculated based on the identification of the first device and the identifications of all target devices. In this case, the calculation method of the updated group parameters is similar to the above processing, so it will not be repeated.

[0174] After the first service node receives the group update message, the process of calculating the private key corresponding to the updated group parameter based on the updated group parameter may further include: sending the updated group parameter to the first joint node; receiving an updated first group security parameter from the first joint node, wherein the updated first group security parameter is calculated based on the updated group parameter; and calculating the private key corresponding to the updated group parameter based on the updated first group security parameter and the updated group parameter. Calculating the private key corresponding to the updated group parameter based on the updated first group security parameter and the updated group parameter may include: calculating an updated second group security parameter based on the updated group parameter and a master private key of the first service node; and calculating the private key corresponding to the updated group parameter based on the updated first group security parameter and the updated second group security parameter.

[0175] Accordingly, the processing of the first joint node may include: receiving the updated group parameters from the first service node; calculating the updated first group security parameters based on the updated group parameters and the master private key of the first joint node; and sending the updated first group security parameters to the first service node.

[0176] In the above example, the specific processing of calculating the updated first group security parameter, the updated second group security parameter, the private key corresponding to the updated group parameter, etc. is similar to the processing of calculating the private key corresponding to the group parameter in the aforementioned embodiment, except that the group parameter is replaced by the updated group parameter, and therefore will not be repeated.

[0177] It should be pointed out that, in another possible example, the updated group parameters may be obtained by the first device from other devices, and the other devices may have at least computing and communication functions. The processing of the other devices calculating the updated group parameters is similar to the above processing and will not be repeated.

[0178] In some possible implementations, the first device or the first service node may further perform uplink processing on the updated group parameters.

[0179] In one example, the first device may also perform the following process: upload the updated group parameters to the blockchain. Specifically, the first device uploads and stores the updated group parameters on the blockchain. The first device may upload the updated group parameters to the blockchain at any time after the first device calculates or obtains the updated group parameters. This is not intended to be an exhaustive list or limitation of all possible processing times.

[0180] In one example, the first service node's processing may include uploading the updated group parameters to the blockchain. Specifically, the first service node uploads and stores the updated group parameters on the blockchain. The first service node may upload the updated group parameters to the blockchain at any time after the first service node obtains the updated group parameters. This is not intended to be an exhaustive list or limitation of all possible processing times.

[0181] It should also be understood that the status of the updated group parameters (such as whether they are revoked) can also be maintained by the first device; or, the status of the updated group parameters can be maintained by the first service node. This embodiment does not exhaustively enumerate and limit all possible maintenance methods.

[0182] In some possible implementations, the group update message may further carry the identifier of the revoked device, or the group update message may further carry the identifiers of all remaining target devices except the revoked device and the identifier of the first device.

[0183] Optionally, the first service node may update the identity revocation list maintained by itself when the group update message carries the identifier of the revoked device, and upload the updated identity revocation list to the blockchain.

[0184] In which, the identity revocation list may only include the identifiers of all revoked devices. Alternatively, the identity revocation list may include the identifiers of all devices managed by the first service node, but a mark bit or flag or related indication is set for the identifier of each device in the identity revocation list, and the mark bit or flag or related indication corresponding to the identifier of each device is used to indicate whether the device is revoked, or whether the device is a revoked device, etc. For example, when the mark bit or flag or related indication is "yes" or "Y" or "not revoked" or the first indication value, it means that the corresponding device is not revoked. For example, when the mark bit or flag or related indication is "N" or "revoked" or the second indication value, it means that the corresponding device is a revoked device, wherein the first indication value and the second indication value are different. It should be understood that the above are all exemplary descriptions. In actual processing, the content of the mark bit or related indication may be opposite to or different from the above examples, and this embodiment does not make exhaustive and limiting examples.

[0185] Optionally, the first service node may carry the identifiers of all remaining target devices except the revoked device and the identifier of the first device in the group update message, determine the identifier of the revoked device in the group based on the identifiers of all remaining target devices except the revoked device and the identifier of the first device, and then update the identity revocation list maintained by itself based on the identifier of the revoked device, and upload the updated identity revocation list to the blockchain.

[0186] In conjunction with FIG5 , taking the first device as a proxy, the first service node as a KGC, and the multiple target devices as multiple zero-power devices (for the sake of simplicity, only one zero-power device is illustrated in FIG5 , and multiple zero-power devices may be included in the actual processing) as an example, the above communication method is exemplarily described:

[0187] Step 501: Each zero-power device submits a registration request to the agent. The registration request of each zero-power device may include identification materials of each zero-power device. Exemplarily, the identification materials may at least include an identifier. The description of the identifier is the same as that in the previous embodiment and will not be repeated.

[0188] Step 502: The agent sends the received identification materials of the zero-power device group (ie, multiple zero-power devices) and the agent's identity ID A Bind together to generate a Merkle tree.

[0189] Step 503: The agent submits a registration request to the KGC on behalf of the zero-power device group. Specifically, the agent can submit the identity certification materials ID1...ID7 of the zero-power device group (i.e., multiple zero-power devices), the agent's identity ID A The root node value Root (group parameter) of the Merkle tree is carried in the registration request and sent to KGC.

[0190] Step 504: KGC jointly securely calculates and generates the private key sk corresponding to the root node value Root (group parameter) Root .

[0191] Here, KGC can first review the identities of multiple zero-power devices and agents. After the review is passed, the private key sk corresponding to the root node value Root (group parameter) is generated by joint security calculation. Root In this step, the specific processing method of the joint security calculation performed by the KGC and the first joint node (ie, the business party and the operator) is the same as that in the previous embodiment, and thus will not be described in detail.

[0192] Step 505: KGC will be the root node value Root (group parameter) corresponding to the private key sk Root Sent to the agent, who will keep it.

[0193] It should also be pointed out that the above-mentioned step 501 can also be an optional step. For example, the agent can have obtained the identification (i.e., identity proof material) of each zero-power device in the zero-power device group in advance, and the agent can directly execute step 502 according to its own preset rules or passive triggering.

[0194] Furthermore, the KGC (for example, the operator can act as the KGC) can also maintain an identity revocation list to record the identities of revoked devices, and put the identity revocation list into the blockchain for verification by the verifier. The specific processing method has been detailed in the previous embodiment and will not be repeated here.

[0195] To illustrate the various devices involved in the aforementioned process, the business party can be a customer of the operator, such as a vertical industry with many IoT devices, or a small or medium-sized factory, such as a logistics company, manufacturing, or aquaculture. The operator (or third-party security service provider) provides IBC services and, as a KGC, applies for a certificate from the issuing node in the two-tier architecture. Any zero-power device or IoT device can be any device of the business party (or any device managed or owned by the business party). Multiple zero-power devices or IoT devices can form a group and belong to the same KGC (for example, after registering with the same KGC through a proxy, these zero-power devices or IoT devices belong to the same KGC). The proxy device or agent can be a device of the business party with blockchain capabilities and the computing power to run various cryptographic algorithms, such as a UE, IAB, relay, or repeater.

[0196] By adopting the communication method provided by this embodiment, the first device can act as an agent to send the group parameters related to multiple target devices to the service node, so that the service node can calculate the private key based on the group parameters related to the multiple target devices. In this way, the proxy can be used to distribute the private keys corresponding to the group to multiple target devices at one time, thereby improving the efficiency of private key generation and management. In addition, since the private key is generated or distributed through the group parameters, the attacker cannot obtain the group parameters as long as it cannot obtain the identification of each target device. Even if the attacker can know the calculation method of the private key, it cannot obtain the private key corresponding to the group parameters, thereby ensuring the security of the private key corresponding to the group parameters. Moreover, since the target device does not need to store content during the entire processing process, the storage space of the target device can be saved and the storage cost of the target device can be reduced. Furthermore, when the service node calculates the private key corresponding to the group parameter, it will also perform a joint calculation with the joint node, thereby avoiding the problem of security risks such as the leakage of the private key when any party is maliciously attacked.

[0197] Figure 6 is a schematic flow chart of a communication method performed by a second device according to an embodiment of the present application. The method includes at least part of the following contents.

[0198] S610: Send a first request message to a second service node, where the first request message carries an identifier of the second device.

[0199] S620: Receive a first response message from the second service node, where the first response message carries a private key corresponding to the second device, and the private key corresponding to the second device is obtained based on an identifier of the second device.

[0200] Figure 7 is a schematic flow chart of a communication method performed by a second service node according to another embodiment of the present application. The method includes at least part of the following contents.

[0201] S710. Receive a first request message from a second device, where the first request message carries an identifier of the second device.

[0202] S720: Calculate a private key corresponding to the second device based on the identifier of the second device and the second federation node;

[0203] S730. Send a first response message to the second device, where the first response message carries a private key corresponding to the second device.

[0204] The second device includes one of the following: an Internet of Things device, a zero-power device, a terminal, and an access network device.

[0205] In one embodiment, the second device may be a terminal or an access network device. In this case, the second device may be the same as the first device in the aforementioned embodiment. The second device may be alternatively called a proxy device, or a proxy node, or a proxy, etc. That is to say, the first device in the aforementioned embodiment will also obtain its corresponding private key in advance, and the method of obtaining the private key is the same as that of the second device in this embodiment.

[0206] In one embodiment, the second device may be a zero-power device or an Internet of Things device. The number of the multiple target devices is not limited in this embodiment. Optionally, the second device may be any one of the following: an ambient power-enabled Internet of Things (AIoT) device, an active zero-power device, a passive zero-power device, a semi-passive zero-power device, and the like. Optionally, the second device may also be a terminal with lower computing power. Optionally, the second device may be referred to as a tag. All possible names of target devices or possible device types are not exhaustively listed here.

[0207] In some possible implementations, the function of the first request message may be to request to obtain a private key corresponding to the second device.

[0208] The first request message may be any type of message, or the first request message may be a message sent in any process.

[0209] In some preferred examples, the first request message is a message sent when the second device initiates registration. In this example, the first request message can also be called a first registration request, or a first registration request message, etc., and all possible names are not limited or enumerated here.

[0210] The second service node may be the same as or different from the first service node in the aforementioned embodiment. For example, when the first service node and the second service node are the same, the second service node may also be a key generation center (KGC). For example, when the first service node and the second service node are different, the first service node may be represented as KGC1 and the second service node may be represented as KGC2.

[0211] The second joint node is used to perform joint computing with the second service node. The second joint node may be the same as or different from the first joint node in the aforementioned embodiment. In some possible examples, the second service node may be an operator (such as an operator server, or an operation server, or an operator's second service node, etc., which are not exhaustive here), and the second joint node may be a business party (such as a business party server, or a business node, or a business party service node, or a business party's second joint node, etc., which are not exhaustive here). In other words, the business party and the operator jointly calculate the private key corresponding to the second device, and the operator, as the KGC, assigns the private key to the second device. In some possible examples, the second service node may be a business party (such as a business party server, or a business node, or a business party service node, or a business party's second service node, etc., which are not exhaustive here), and the second joint node may be an operator (such as an operator server, or an operation server, or an operator's second joint node, etc., which are not exhaustive here). In other words, the business party and the operator jointly calculate the private key, and the business party assigns the private key to the second device. It should be understood that this is merely an exemplary description. In actual processing, the second service node and the second joint node may not be limited to the possibilities of the above examples, but this embodiment does not limit or exhaustively list them.

[0212] The private key corresponding to the second device is obtained based on the identifier of the second device, which may mean that the private key corresponding to the second device is obtained by joint calculation based on the identifier of the second device. More specifically, the private key corresponding to the second device is obtained by joint calculation by the second service node and the joint node based on the identifier of the second device.

[0213] The second service node calculates a private key corresponding to the second device based on the identifier of the second device and the second joint node, including: sending the identifier of the second device to the second joint node; receiving a first security parameter from the second joint node, wherein the first security parameter is calculated based on the identifier of the second device; and calculating the private key corresponding to the second device based on the first security parameter and the identifier of the second device.

[0214] The calculating the private key corresponding to the second device based on the first security parameter and the identifier of the second device includes: calculating the second security parameter based on the identifier of the second device and the master private key of the second service node; and calculating the private key corresponding to the second device based on the first security parameter and the second security parameter.

[0215] Accordingly, the processing of the second joint node may include: receiving the identifier of the second device from the second service node; calculating the first security parameter based on the identifier of the second device and the master private key of the second joint node; and sending the first security parameter to the second service node.

[0216] The calculation parameters required for the joint calculation may include: q: a large prime number; G1, G2: two additive groups on the elliptic curve of order q; P1, P2: arbitrary generators corresponding to G1 and G2 respectively; G T : multiplicative group over a finite field of order q; e: bilinear map G1×G2→G T ; All integers in the finite field [1,q-1]; P pub =s·P2, where s3 is the second service node from Any random number selected from , s4 is the second joint node from Any random number selected from the , and satisfying the relationship s = s3 + s4; r = r3 + r4, where r3 is the number of random numbers selected by the second service node from Any random number selected from the Any random number selected; g = e(P1, P pub );H v : cryptographic hash function; hid: function identifier; master public key MPK = (G1, G2, G T ,e,P1,P2,P pub , g, H v , hid) are public; the master private key MSK = (s3, r3) of the second service node is kept confidential, and the master private key MSK = (s4, r4) of the second joint node is also kept confidential; F, H1, H2: functional functions supported by the system.

[0217] For the sake of simplicity, this embodiment describes the calculation parameters used by the second service node and the second joint node using a similar representation method to the calculation parameters used by the first service node and the first joint node in the aforementioned embodiment. In actual processing, as long as the second service node and the second joint node use similar or identical parameters but use other representation methods, they are also within the scope of protection of this embodiment and are therefore not described in detail.

[0218] Furthermore, based on the description of the above calculation parameters, two-party secure calculation can be applied to the key generation algorithm in the SM9 digital signature scheme. In the process of calculating the private key corresponding to the group parameter, the master private keys of the second service node and the second joint node (i.e., the business party and the operator) are required. Therefore, the second service node and the second joint node (i.e., the business party and the operator) need to perform joint calculation based on the identification of the second device to finally obtain the private key corresponding to the second device. The following is a detailed description of the method for calculating the private key corresponding to the second device:

[0219] The second joint node calculates the first security parameter based on the identifier of the second device and the master private key of the second joint node, which may include: calculating the first intermediate parameter based on a functional function supported by the system, a cryptographic hash function, a function identifier, a large prime number, the identifier of the second device, and the master private key of the second joint node; calculating the second intermediate parameter based on the first intermediate parameter and the master private key of the second joint node; calculating the third intermediate parameter based on the master private key of the second joint node; using MtA to calculate multiple fourth intermediate parameters and multiple fifth intermediate parameters; and using the second intermediate parameter, the third intermediate parameter, the multiple fourth intermediate parameters, and the multiple fifth intermediate parameters as the first security parameter.

[0220] The second service node calculates the second security parameter based on the identifier of the second device and the master private key of the second service node, which may include: calculating a sixth intermediate parameter based on a function function supported by the system, a cryptographic hash function, a function identifier, a large prime number, the identifier of the second device, and the master private key of the second service node; calculating a seventh intermediate parameter based on the sixth intermediate parameter and the master private key of the second service node; calculating an eighth intermediate parameter based on the master private key of the second service node; using MtA to calculate multiple ninth intermediate parameters and multiple tenth intermediate parameters; and using the seventh intermediate parameter, the eighth intermediate parameter, the multiple ninth intermediate parameters, and the multiple tenth intermediate parameters as the second security parameter.

[0221] The second service node calculates the private key corresponding to the second device based on the first security parameter and the second security parameter, which may include: performing a sum calculation based on the second intermediate parameter, the sixth intermediate parameter, multiple fourth intermediate parameters and multiple ninth intermediate parameters to obtain a first intermediate calculation value; performing a sum calculation based on the third intermediate parameter, the seventh intermediate parameter, multiple fifth intermediate parameters and multiple tenth intermediate parameters to obtain a second intermediate calculation value; and calculating the private key corresponding to the second device based on the first intermediate calculation value and the second intermediate calculation value.

[0222] The derivation process of the above calculation process is described as follows: the private key sk corresponding to the second device A The calculation method is expressed as: sk A =s·t1 -1 P1=s·r·(t1·r) -1 ·P1. Where, t1·r=[s+H1(H v ,ID A ||hid,q)]·(r3+r4), ID A The identifier of the second device.

[0223] The calculation of the fifth intermediate parameter x3 by the second service node can be expressed as: s3+2H1(H v ,ID A ||hid,q)=x3; The second joint node calculates the first intermediate parameter x4, which can be expressed as: s4-H1(H v ,ID A ||hid,q)=x4. The first intermediate parameter and the fifth intermediate parameter are stored in their respective nodes and kept confidential.

[0224] The above t1·r=(x3+x4)·(r3+r4)=x3·r3+x3·r4+x4·r3+x4·r4. s·r=(s3+s4)·(r3+r4)=s3·r3+s3·r4+s4·r3+s4·r4.

[0225] In the process of calculating t1·r, the second service node locally calculates the seventh intermediate parameter x3·r3 and the second joint node locally calculates the second intermediate parameter x4·r4; for x3·r4, MtA is used to calculate, and the result obtained by the second service node is recorded as α 34 , the result obtained by the second joint node is recorded as β 34 , satisfying x3·r4=α 34 +β 34 For x4·r3, MtA is used for calculation, and the result obtained by the second service node is recorded as α 43 , the result obtained by the second joint node is recorded as β 43 , satisfying x4·r3=α43 +β 43 .

[0226] In the process of calculating s·r, the second service node locally calculates the eighth intermediate parameter s3·r3, and the second joint node locally calculates the third intermediate parameter s4·r4; for s3·r4, MtA is used to calculate, and the result obtained by the second service node is recorded as λ 34 , the result obtained by the second joint node is recorded as δ 34 , satisfying s3·r4=λ 34 +δ 34 For s4·r3, MtA is used for calculation, and the result obtained by the second service node is recorded as λ 43 , the result obtained by the second joint node is recorded as δ 43 , satisfying s4·r3=λ 43 +δ 43 .

[0227] After the above derivation, the second intermediate parameter is x4·r4, the third intermediate parameter is s4·r4, and the fourth intermediate parameters may include β 34 , β 43 , multiple fifth intermediate parameters include δ 34 , δ 43 The second safety parameter includes the seventh intermediate parameter represented by x3·r3, the eighth intermediate parameter represented by s3·r3, and the plurality of ninth intermediate parameters represented by α 34 , α 43 , multiple tenth intermediate parameters are expressed as λ 43 ,λ 34 .

[0228] After obtaining all the aforementioned parameters, the second service node can calculate the first intermediate calculation value as: t1·r=x3·r3+α 34 +β 34 +α 43 +β 43 +x4·r4. After obtaining t1·r, the second service node can calculate (t1·r) in plain text -1 After obtaining all the aforementioned parameters, the second service node can calculate the second intermediate calculation value as follows: s·r=s3·r3+λ 34 +δ 34 +λ 43 +δ 43 +s4·r4. Finally, the second service node uses the following formula to calculate the private key corresponding to the group parameter: sk A =s·r·(t1·r) -1 P1: The meaning and calculation method of each parameter in this formula have been explained above and will not be repeated here.

[0229] In some possible implementations, after the second service node obtains the private key corresponding to the second device through joint calculation, the second service node may carry the private key corresponding to the second device in the first response message and send it to the second device.

[0230] Here, the first response message may be used to respond to the first request message. The first response message may be any type of message. In some preferred examples, the first request message is a message sent when the second device initiates registration. In such examples, the first response message may also be used to indicate to the second device that registration is complete or that the second device has successfully registered. The first response message may also be referred to as a first registration response, a first registration response message, or the like. All possible names are not limited or exhaustive here.

[0231] In some possible implementations, the first response message also carries the location information of the second service node's certificate on the blockchain. That is, after the second service node jointly calculates and obtains the private key corresponding to the second device, the second service node may include the private key corresponding to the second device and the location information of the second service node's certificate on the blockchain in the first response message and send it to the second device.

[0232] It should also be pointed out that, in some possible examples, the location information of the certificate of the second service node on the blockchain, in addition to being carried in the first response message, can also be sent by the second service node to the second device through other messages, that is, the location information of the certificate of the second service node on the blockchain and the private key corresponding to the second device can be sent to the second device through different messages.

[0233] In some possible implementations, after receiving the identifier of the second device carried in the first request message, the second service node may further perform the following processing: reviewing the second device based on the identifier of the second device.

[0234] In some embodiments, the second service node reviews the processing of the second device based on the identification of the second device, which may include: reviewing whether the second device is a legal device based on the identification of the second device, etc. This embodiment does not enumerate or elaborate on all the processing that may be included in the review of the first device by the first service node.

[0235] In some embodiments, after the second service node audits the second device, the process may further include: if the second service node successfully audits the second device, the second service node performs a process of calculating a private key corresponding to the second device, which will not be repeated here.

[0236] In some possible implementations, the second service node may further perform uplink processing on the identifier of the second device.

[0237] The second service node's processing may include uploading the second device's identifier to the blockchain. Specifically, the second service node uploads and stores the second device's identifier on the blockchain. The second service node may upload the second device's identifier to the blockchain at any time after the second service node obtains the second device's identifier. For example, this may be after the second service node obtains the second device's identifier and before the second service node sends the first response message. Another example is after the second service node sends the first response message, and so on. Another example is after the second service node successfully (or passes) the second device's review, and so on. This does not exhaustively enumerate or limit all possible processing times.

[0238] In some possible implementations, the second service node may maintain an identity revocation list. The second service node's processing may include: upon determining that the second device is revoked, updating the identity revocation list maintained by the second service node based on an identifier of the revoked second device, and uploading the updated identity revocation list to the blockchain.

[0239] Optionally, the identity revocation list may only include identifiers of all revoked devices. For example, when the second device is revoked, the second service node may add the identifier of the second device to the identity revocation list.

[0240] Optionally, the identity revocation list may include the identifiers of all devices managed by the second service node, but a flag or related indication is set for the identifier of each device in the identity revocation list. The flag or flag or related indication corresponding to the identifier of each device is used to indicate whether the device is revoked, or whether the device is a revoked device, etc. For example, when the flag or flag or related indication is "yes" or "Y" or "not revoked" or a first indication value, it indicates that the corresponding device is not revoked. For example, when the flag or flag or related indication is "N" or "revoked" or a second indication value, it indicates that the corresponding device is a revoked device. For example, when it is determined that the second device is revoked, the flag corresponding to the identifier of the second device can be set to "revoked" or "N", where the first indication value and the second indication value are different. It should be understood that the above are all exemplary descriptions. In actual processing, the content of the flag or related indication may be opposite to or different from the above examples, and this embodiment does not provide an exhaustive list or limitation.

[0241] 8 , taking the second device as an IoT device and the second service node as a KGC (that is, assuming that the second service node and the first service node are the same KGC) as an example, the above communication method is exemplarily described:

[0242] Step 801: Registration request. The IoT device sends a registration request to KGC. The registration request may carry the IoT device's ID. A , ID A It is the unique identifier of the device when it leaves the factory, or the identifier issued by the operator, or the identifier issued by the service provider, or a combination of two or more of the above identifiers.

[0243] Step 802: KGC reviews the identity of the IoT device. After the KGC passes the review, KGC uses its own master private key to generate the private key sk corresponding to the identity of the IoT device using the key generation algorithm. A The KGC can be calculated with the second joint node to obtain the private key corresponding to the IoT device. The specific calculation method has been detailed in the previous embodiment and will not be repeated here. The relevant descriptions of the KGC and the second joint node are also the same as those in the previous embodiment and will not be repeated here.

[0244] Step 803: The KGC sends the private key of the corresponding identity (i.e., the private key corresponding to the IoT device) and the address (or location information) of the KGC certificate to which the IoT device belongs on the blockchain to the IoT device. At this point, the IoT device is successfully registered.

[0245] Furthermore, the operator as KGC can also maintain an identity revocation list to record the identities of revoked devices, and put the identity revocation list into the blockchain for verification by the verifier. The specific processing method has been detailed in the previous embodiment and will not be repeated here.

[0246] By adopting the communication method provided in this embodiment, the second device can send its own identification to the service node, so that the service node can perform joint calculation based on the identification of the second device to obtain the private key corresponding to the second device. In this way, it is possible to avoid security risks such as the leakage of private keys when either party is attacked maliciously. In addition, for the second device, it is not necessary for the second device to carry its own certificate at all times to prove its identity. Instead, it only needs to obtain the address of the certificate of its corresponding service node to prove its identity, thereby avoiding the problem of increased storage space pressure on the device due to the need for the second device to carry certificates of various public information such as identity.

[0247] The basic principle of the PKI (Public Key Infrastructure) described in the previous example is explained below: a third-party authority, a certification authority (CA), combines a user's public key with their identity information (such as name and phone number). Before the two are combined, the CA verifies the authenticity of the user's identity and then signs a certificate that combines the user and their public key.

[0248] Identity-based cryptography (IBC), another branch of public-key cryptography, directly uses unique user information as the user's public key (i.e., user identifier), such as email address or mobile phone number. This eliminates the need for users to apply for and exchange certificates, significantly simplifying the complexity of certificate management in cryptographic systems. The user's private key is generated by a trusted key generation center (KGC) in the system using a private key generation algorithm. This algorithm can be the SM9 algorithm, which includes the SM9 digital signature algorithm, the SM9-IBE identity encryption algorithm, and the SM9-KA key agreement protocol.

[0249] A blockchain-based two-tier identity architecture: The identity management architecture for the integrated synaesthesia and zero-power scenarios is designed as a two-tier architecture, as shown in Figure 9. The entire protocol framework consists of two parts: a CA model (with the committee acting as a trusted center) for communication between committee nodes and issuing nodes, and a blockchain model for communication between issuing nodes and their corresponding IoT devices (i.e., light nodes). Due to the small number of issuing nodes, the CA model facilitates authorization and management. The IoT device data authorized by the issuing nodes is enormous, making blockchain a better solution. Combining these two models makes the system more compatible with current market trends and provides a more cohesive and clearer hierarchy.

[0250] Blockchain model: The issuing node uses a blockchain model to connect its corresponding IoT device. This model stores the IoT device's certificate on the blockchain. When a certificate is needed, it is searched for in the blockchain. The IoT device's certificate is signed by the issuing node and then applied for on-chain verification. After verification by multiple on-chain nodes, it is added to the blockchain through a consensus algorithm. The on-chain node first verifies the issuing node's certificate using the joint committee's public key. Once verification is successful, the node then verifies the IoT device's certificate using the corresponding issuing node's public key. Once verification is successful, the IoT device's certificate is added to the blockchain and the certificate's location is returned to the issuing node. The issuing node then returns this location to the IoT device. In this scenario, the IoT device only needs to store the certificate's on-chain location, not the certificate itself. The verifier simply searches for the certificate in the chain based on the location information sent by the sender. If the certificate is found in the corresponding location, the certificate's authenticity and validity are guaranteed, eliminating the need for the verifier to repeatedly verify the certificate's authenticity and validity. This significantly reduces communication and computational overhead.

[0251] However, in the aforementioned related technologies, zero-power IoT devices must always carry their own certificates to prove their identity. Certificates, which contain various public information such as identity, are too long, and carrying them places a heavy burden on device storage space. For a massive IoT network, if each device requires a certificate, this places a heavy burden on storage servers. Consider the scenario where 6G carriers' 2B services require 2B service providers to purchase terminal identity services from the carriers or third-party security service providers' KGCs. Operators and / or third-party security service providers offer even less control to service providers. If carriers or third-party security service providers provide IoT terminal identity services to more than one service provider, ensuring the security of the private keys generated for the devices becomes a more serious security issue.

[0252] The solution provided in the embodiments of this application uses the key generation algorithm, signature algorithm, and verification algorithm in the digital signature scheme. The innovation lies in improving the key generation algorithm using two-party secure computing technology, thereby ensuring the security of the private key of the terminal device when the business party entrusts the operator or third-party security service provider as the KGC mode.

[0253] Figure 10 is a schematic flow chart of a communication method performed by a second service node according to an embodiment of the present application. The method includes at least part of the following contents.

[0254] S1010. Send a second request message to the issuing node;

[0255] S1020. Receive a second response message from the issuing node, wherein the second response message carries location information of the certificate of the second service node on the blockchain.

[0256] Figure 11 is a schematic flow chart of a communication method performed by an issuing node according to another embodiment of the present application. The method includes at least part of the following contents.

[0257] S1110. Receive a second request message from the second service node;

[0258] S1120. Generate a certificate for the second service node;

[0259] S1130: Upload the certificate of the second service node to the blockchain, and obtain the location information of the certificate of the second service node on the blockchain;

[0260] S1140: Send a second response message to the second service node, where the second response message carries location information of the certificate of the second service node on the blockchain.

[0261] In some possible implementations, the second request message may carry at least one of the following: an identifier of the second service node, a master public key of the second service node, other public information of the second service node, signature information, etc.; wherein the signature information may be calculated based on a signature algorithm on at least one of the identifier of the second service node, the master public key of the second service node, and other public information of the second service node. This embodiment does not limit the signature algorithm.

[0262] The function of the second request message may be to request or apply for a certificate for the second service node. The second request message may be any type of message, or the second request message may be a message sent during any process. In some preferred examples, the second request message is sent when the second service node initiates registration. In such examples, the second request message may also be referred to as a second registration request, a second registration request message, etc., without limiting or enumerating all possible names.

[0263] In some possible implementations, after receiving the second request message from the second service node, the issuing node may first verify the second service node.

[0264] Optionally, the issuing node may verify the second service node by verifying the signature based on at least one of the second service node's identifier, the second service node's master public key, and other public information of the second service node carried in the second request message; if the verification is successful, the second service node may be determined to have been successfully verified. The signature verification methods are not intended to be exhaustive or limited.

[0265] Optionally, the manner in which the issuing node verifies the second service node may include: verifying whether the second service node is a legitimate device based on an identifier of the second service node carried in the second request message, and the like.

[0266] The above is merely an example. In actual processing, the issuing node may also use the above methods and other methods alone or in combination to verify the second service node. The above methods and other methods are not exhaustive or limited here.

[0267] The issuing node generating the certificate of the second service node may refer to: after generating the certificate of the second service node, the issuing node uses its own private key to sign the certificate of the second service node. This embodiment does not limit the specific processing method for generating the certificate.

[0268] The issuing node uploads the certificate of the second service node to the blockchain and obtains the location information of the certificate of the second service node on the blockchain. Specifically, this may include uploading and saving the certificate of the second service node to the blockchain and obtaining the location information of the certificate of the second service node on the blockchain. This location information may alternatively be referred to as storage location information, address information, storage address, etc., which are not limited or exhaustive here. Here, the processing by the on-chain node of the blockchain may include: the on-chain node verifies the authenticity of the certificate, and if the certificate is authentic, obtains the public key of the issuing node; the on-chain node verifies the certificate using the issuing node's public key, and if the verification succeeds, determines that the certificate verification is successful and completes the on-chain. Accordingly, after the on-chain node successfully verifies the certificate, the issuing node obtains the location information of the certificate on the blockchain returned by the on-chain node.

[0269] In some possible implementations, the issuing node uploads the certificate of the second service node to the blockchain, and after obtaining the location information of the certificate of the second service node on the blockchain, the location information of the certificate of the second service node on the blockchain can be carried in the second response message and sent to the second service node.

[0270] Here, the second response message may be used to respond to the second request message. The second response message may be any type of message. In some preferred examples, the second response message may also be called a second registration response, or a second registration response message, etc., and all possible names are not limited or exhaustive here.

[0271] In some possible implementations, the second response message also carries the certificate of the second service node. That is, after the issuing node uploads the certificate of the second service node to the blockchain and obtains the location information of the certificate of the second service node on the blockchain, the issuing node may include the certificate of the second service node and the location information of the certificate of the second service node on the blockchain in the second response message and send it to the second service node.

[0272] It should be noted that the second service node may be the same as or different from the first service node in the aforementioned embodiment. If the first service node is different from the second service node, the first service node can also perform the same processing as the second service node. That is, the first service node can also obtain its own certificate and its certificate location information on the blockchain from the issuing node. The specific processing between the first service node and the issuing node is the same as the processing between the second service node and the issuing node. Therefore, this embodiment does not repeat the processing of the first service node.

[0273] In conjunction with FIG12 , taking the second service node as a KGC (that is, assuming that the second service node and the first service node are the same KGC) as an example, the above communication method is exemplarily described:

[0274] Step 1201: The KGC applies for a certificate from the issuing node. Specifically, the KGC may submit its ID, master public key MPK, other public information, and a signature of the above information to the issuing node.

[0275] Step 1202: After verifying the identity and other information of the KGC, the issuing node signs it with its own private key to generate a KGC certificate.

[0276] Step 1203: The issuing node uploads the generated certificate to the blockchain and obtains the certificate's location information on the blockchain. Here, after the on-chain node receives the certificate, step 1103' can be executed: the on-chain node verifies the authenticity of the certificate. If the certificate is authentic, it obtains the issuing node's public key. The on-chain node verifies the certificate using the issuing node's public key. If the verification passes, the certificate verification is determined to be successful and the certificate is uploaded to the blockchain. Accordingly, after the on-chain node successfully verifies the certificate, the issuing node obtains the certificate's location information on the blockchain returned by the on-chain node.

[0277] Step 1204: The issuing node issues a certificate to the KGC and sends the certificate's location information (BlockNum) on the chain to the KGC.

[0278] Furthermore, KGC's certificate verification process: When KGC needs to authenticate other parties, it can send its own certificate or the certificate's location information BlockNum and auxiliary information (used to prove that its own certificate has not been revoked) to the verifier; if the verifier receives the certificate, it can use the public key of the issuing node to verify the authenticity of the certificate; if the verifier receives the location information BlockNum, it only needs to find the certificate at the corresponding location on the chain to verify the authenticity of the certificate; after successful verification, the verifier uses the auxiliary information sent by KGC and the product of all revoked revocation factors maintained by the issuing node that issued the certificate for the KGC to verify whether it has been revoked.

[0279] By adopting the communication method provided in this embodiment, the second service node can obtain the location information of its own certificate on the blockchain from the issuing node, so that the device belonging to the second service node can obtain the certificate location information of the second service node. Then, the device belonging to the second service node only needs to use the certificate of the second service node to complete authentication and other related processing. The device that does not need to belong to the second service node only needs to use the address of the certificate of the second service node to prove its identity, thereby avoiding the problem of increased storage space pressure on the device caused by the need for the device belonging to the second service node to carry certificates of various public information such as identity.

[0280] FIG13 is a schematic diagram of the composition structure of a first device according to an embodiment of the present application, including:

[0281] The first communication unit 1301 is configured to send a group request message to a first service node, wherein the group request message carries a group parameter, and the group parameter is calculated based on the identifiers of multiple target devices; and receive a group response message from the first service node, wherein the group response message carries a private key corresponding to the group parameter.

[0282] As shown in FIG13 , the first device further includes a first processing unit 1302:

[0283] The first processing unit is configured to calculate a parameter value of each target device based on an identifier of each target device among the multiple target devices; and calculate the group parameter based on the parameter value of each target device.

[0284] 28 . The first device according to claim 27 , wherein the first processing unit is configured to calculate the group parameter based on the parameter value of each target device and the identifier of the first device.

[0285] The first communication unit is configured to receive a registration request from each target device among the multiple target devices, wherein the registration request of each target device carries an identifier of each target device.

[0286] The first communication unit is used to upload the group parameters to the blockchain.

[0287] The first communication unit is configured to, when a revoked device exists among the multiple target devices, send a group update message to the first service node, wherein the group update message carries updated group parameters, and the updated group parameters are updated based on the identification of the revoked device; and receive a group update response message from the first service node, wherein the group update response message carries a private key corresponding to the updated group parameters.

[0288] The first device includes one of the following: a terminal, an access network device; the target device includes one of the following: an Internet of Things device, a zero-power device.

[0289] FIG14 is a schematic diagram of the composition structure of a first service node according to an embodiment of the present application, including:

[0290] The second communication unit 1401 is configured to receive a group request message from a first device, wherein the group request message carries a group parameter; and send a group response message to the first device, wherein the group response message carries a private key corresponding to the group parameter;

[0291] The second processing unit 1402 is configured to calculate a private key corresponding to the group parameter based on the group parameter.

[0292] The second communication unit is configured to send the group parameter to the first joint node; and receive a first group security parameter from the first joint node, wherein the first group security parameter is calculated based on the group parameter;

[0293] The second processing unit is configured to calculate a private key corresponding to the group parameter based on the first group security parameter and the group parameter.

[0294] The second processing unit is configured to calculate a second group security parameter based on the group parameter and the master private key of the first service node; and calculate a private key corresponding to the group parameter based on the first group security parameter and the second group security parameter.

[0295] The second communication unit is used to upload the group parameters to the blockchain.

[0296] The second communication unit is configured to receive a group update message from the first device, wherein the group update message carries the updated group parameters; and send a group update response message to the first device, wherein the group update response message carries a private key corresponding to the updated group parameters;

[0297] The second processing unit is configured to calculate a private key corresponding to the updated group parameter based on the updated group parameter.

[0298] The first device includes one of the following: a terminal, an access network device.

[0299] FIG15 is a schematic diagram of the structure of a second device according to an embodiment of the present application, including:

[0300] The third communication unit 1501 is used to send a first request message to the second service node, where the first request message carries the identifier of the second device; and receive a first response message from the second service node, where the first response message carries the private key corresponding to the second device, and the private key corresponding to the second device is obtained based on the identifier of the second device.

[0301] The first response message also carries the location information of the certificate of the second service node on the blockchain.

[0302] The second device includes one of the following: an Internet of Things device, a zero-power device, a terminal, and an access network device.

[0303] FIG16 is a schematic diagram of the structure of a second service node according to an embodiment of the present application, including:

[0304] The fourth communication unit 1601 is configured to receive a first request message from a second device, where the first request message carries an identifier of the second device; and send a first response message to the second device, where the first response message carries a private key corresponding to the second device.

[0305] The fourth processing unit 1602 is configured to calculate a private key corresponding to the second device based on the identifier of the second device and the second joint node.

[0306] The fourth communication unit is configured to send the identifier of the second device to the second united node; and receive a first security parameter from the second united node, wherein the first security parameter is calculated based on the identifier of the second device;

[0307] The fourth processing unit is configured to calculate a private key corresponding to the second device based on the first security parameter and the identifier of the second device.

[0308] The fourth processing unit is configured to calculate a second security parameter based on the identifier of the second device and the master private key of the second service node; and calculate a private key corresponding to the second device based on the first security parameter and the second security parameter.

[0309] The first response message also carries the location information of the certificate of the second service node on the blockchain.

[0310] The second device includes one of the following: an Internet of Things device, a zero-power device, a terminal, and an access network device.

[0311] A schematic diagram of the structure of a second service node according to an embodiment of the present application includes:

[0312] The fourth communication unit is used to send a second request message to the issuing node; and receive a second response message from the issuing node, wherein the second response message carries the location information of the certificate of the second service node on the blockchain.

[0313] The second response message also carries the certificate of the second service node.

[0314] FIG17 is a schematic diagram of the structure of an issuing node according to an embodiment of the present application, including:

[0315] The fifth communication unit 1701 is configured to receive a second request message from the second service node; upload the certificate of the second service node to the blockchain, and obtain the location information of the certificate of the second service node on the blockchain; and send a second response message to the second service node, wherein the second response message carries the location information of the certificate of the second service node on the blockchain.

[0316] The fifth processing unit 1702 is configured to generate a certificate of the second service node.

[0317] The second response message also carries the certificate of the second service node.

[0318] The device of the embodiment of the present application can realize the corresponding functions of each device in the aforementioned communication method embodiment. The processes, functions, implementation methods and beneficial effects corresponding to each module (sub-module, unit or component, etc.) in the device can be found in the corresponding description in the above-mentioned method embodiment, which will not be repeated here. It should be noted that the functions described by each module (sub-module, unit or component, etc.) in the device of the embodiment of the application can be implemented by different modules (sub-module, unit or component, etc.) or by the same module (sub-module, unit or component, etc.).

[0319] Figure 18 is a schematic structural diagram of a communication device 1800 according to an embodiment of the present application. The communication device 1800 includes a processor 1810, which can call and run a computer program from a memory to enable the communication device 1800 to implement the method in the embodiment of the present application.

[0320] In one possible implementation, the communication device 1800 may further include a memory 1820. The processor 1810 may call and execute a computer program from the memory 1820 to enable the communication device 1800 to implement the method in the embodiment of the present application. The memory 1820 may be a separate device independent of the processor 1810 or may be integrated into the processor 1810.

[0321] In one possible implementation, the communication device 1800 may further include a transceiver 1830. The processor 1810 may control the transceiver 1830 to communicate with other devices. Specifically, the transceiver 1830 may send information or data to other devices or receive information or data sent by other devices. The transceiver 1830 may include a transmitter and a receiver. The transceiver 1830 may further include one or more antennas.

[0322] An embodiment of the present application provides a first device, comprising: a processor, and a memory communicating with the processor, the memory being used to store instructions, where when the instructions are executed by the processor, the instructions cause the first device to execute: sending a group request message to a first service node, wherein the group request message carries a group parameter, and the group parameter is calculated based on identifiers of multiple target devices; and receiving a group response message from the first service node, wherein the group response message carries a private key corresponding to the group parameter.

[0323] The instructions further cause the first device to execute: calculating a parameter value of each target device based on an identification of each target device among the multiple target devices; and calculating the group parameter based on the parameter value of each target device.

[0324] The instructions further cause the first device to calculate the group parameter based on the parameter value of each target device and the identifier of the first device.

[0325] The instructions further cause the first device to execute: receiving a registration request from each target device among the multiple target devices, wherein the registration request of each target device carries an identifier of each target device.

[0326] The instructions further cause the first device to perform: uploading the group parameters to a blockchain.

[0327] The instruction further causes the first device to execute: if there is a revoked device among the multiple target devices, sending a group update message to the first service node, wherein the group update message carries updated group parameters, and the updated group parameters are updated based on the identifier of the revoked device; and receiving a group update response message from the first service node, wherein the group update response message carries a private key corresponding to the updated group parameters.

[0328] The first device includes one of the following: a terminal, an access network device; the target device includes one of the following: an Internet of Things device, a zero-power device.

[0329] An embodiment of the present application provides a first service node, including: a processor; a memory in communication with the processor, the memory being configured to store instructions. When the instructions are executed by the processor, the instructions cause the first service node to: receive a group request message from a first device, wherein the group request message carries a group parameter; send a group response message to the first device, wherein the group response message carries a private key corresponding to the group parameter; and calculate, based on the group parameter, the private key corresponding to the group parameter.

[0330] The instruction further causes the first service node to execute: sending the group parameter to the first federated node; receiving a first group security parameter from the first federated node, wherein the first group security parameter is calculated based on the group parameter; and calculating a private key corresponding to the group parameter based on the first group security parameter and the group parameter.

[0331] The instruction further causes the first service node to: calculate a second group security parameter based on the group parameter and a master private key of the first service node; and calculate a private key corresponding to the group parameter based on the first group security parameter and the second group security parameter.

[0332] The instructions further cause the first service node to execute: uploading the group parameters to a blockchain.

[0333] The instruction further causes the first service node to execute: receiving a group update message from the first device, wherein the group update message carries the updated group parameters; sending a group update response message to the first device, wherein the group update response message carries a private key corresponding to the updated group parameters; and calculating, based on the updated group parameters, a private key corresponding to the updated group parameters.

[0334] The first device includes one of the following: a terminal, an access network device.

[0335] An embodiment of the present application provides a second device, including: a processor, and a memory communicating with the processor, the memory being used to store instructions, where when the instructions are executed by the processor, the instructions cause the second device to execute: sending a first request message to a second service node, where the first request message carries an identifier of the second device; and receiving a first response message from the second service node, where the first response message carries a private key corresponding to the second device, and the private key corresponding to the second device is obtained based on the identifier of the second device.

[0336] The first response message also carries the location information of the certificate of the second service node on the blockchain.

[0337] The second device includes one of the following: an Internet of Things device, a zero-power device, a terminal, and an access network device.

[0338] An embodiment of the present application provides a second service node, including: a processor, and a memory in communication with the processor, the memory being used to store instructions, where when the instructions are executed by the processor, the instructions cause the second service node to: receive a first request message from a second device, where the first request message carries an identifier of the second device; send a first response message to the second device, where the first response message carries a private key corresponding to the second device; and calculate the private key corresponding to the second device based on the identifier of the second device and a second joint node.

[0339] The instruction further causes the second service node to execute: sending the identifier of the second device to the second federation node; receiving a first security parameter from the second federation node, wherein the first security parameter is calculated based on the identifier of the second device; and calculating a private key corresponding to the second device based on the first security parameter and the identifier of the second device.

[0340] The instruction further causes the second service node to: calculate a second security parameter based on the identifier of the second device and the master private key of the second service node; and calculate a private key corresponding to the second device based on the first security parameter and the second security parameter.

[0341] The first response message also carries the location information of the certificate of the second service node on the blockchain.

[0342] The second device includes one of the following: an Internet of Things device, a zero-power device, a terminal, and an access network device.

[0343] An embodiment of the present application provides a second service node, comprising: a processor, a memory communicating with the processor, the memory being used to store instructions, wherein when the instructions are executed by the processor, the instructions cause the second service node to execute: sending a second request message to the issuing node; and receiving a second response message from the issuing node, wherein the second response message carries location information of the certificate of the second service node on the blockchain.

[0344] The second response message also carries the certificate of the second service node.

[0345] An embodiment of the present application provides an issuing node, comprising: a processor, a memory communicating with the processor, the memory being used to store instructions, wherein when the instructions are executed by the processor, the instructions cause the issuing node to execute: receiving a second request message from the second service node; generating a certificate of the second service node; uploading the certificate of the second service node to a blockchain, and obtaining location information of the certificate of the second service node on the blockchain; and sending a second response message to the second service node, wherein the second response message carries the location information of the certificate of the second service node on the blockchain.

[0346] The second response message also carries the certificate of the second service node.

[0347] Figure 19 is a schematic block diagram of a chip 1900 according to an embodiment of the present application. Chip 1900 includes a processor 1910, which can access and execute computer programs from a memory to implement the methods according to the embodiments of the present application. In one possible implementation, chip 1900 may also include a memory 1920. Processor 1910 can access and execute computer programs from memory 1920 to implement the methods according to the embodiments of the present application performed by an access network device or a core network device. Memory 1920 may be a separate device independent of processor 1910 or integrated into processor 1910. In one possible implementation, chip 1900 may also include an input interface 1930. Processor 1910 may control input interface 1930 to communicate with other devices or chips, specifically, to obtain information or data sent by other devices or chips. In one possible implementation, chip 1900 may also include an output interface 1940. Among them, the processor 1910 can control the output interface 1940 to communicate with other devices or chips, specifically, it can output information or data to other devices or chips. In one possible implementation, the chip can be applied to each device in the embodiments of the present application, and the chip can implement the corresponding processes implemented by each device in the various methods of the embodiments of the present application. For the sake of brevity, it is not repeated here. It should be understood that the chip mentioned in the embodiments of the present application can also be called a system-level chip, a system chip, a chip system or a system-on-chip chip, etc.

[0348] The processor mentioned above may be a general-purpose processor, a digital signal processor, an off-the-shelf programmable gate array, an application-specific integrated circuit, or other programmable logic device, a transistor logic device, a discrete hardware component, or the like. The general-purpose processor mentioned above may be a microprocessor or any conventional processor, or the like. The memory mentioned above may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory may be a read-only memory, a programmable read-only memory, an erasable programmable read-only memory, an electrically erasable programmable read-only memory, or a flash memory. The volatile memory may be a random access memory.

[0349] It should be understood that the above-mentioned memory is exemplary but not restrictive. For example, the memory in the embodiments of the present application may also be static random access memory, dynamic random access memory, etc. In other words, the memory in the embodiments of the present application is intended to include, but is not limited to, these and any other suitable types of memory.

[0350] Figure 20 is a schematic block diagram of a communication system 2000 according to an embodiment of the present application. The communication system 2000 includes a first device 2010, a first service node 2020, a second device 2030, a second service node 2040, and an issuing node 2050. In the above embodiments, all or part of the embodiments can be implemented by software, hardware, firmware, or any combination thereof. When implemented using software, all or part of the embodiments can be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions in accordance with the embodiments of the present application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more available media. The available medium can be a magnetic medium (such as a hard disk) or a semiconductor medium (such as a solid-state drive).

[0351] It should be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0352] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0353] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any modifications or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in the present application should be included within the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A communication method performed by a first device, comprising: Sending a group request message to the first service node, wherein the group request message carries a group parameter, and the group parameter is calculated based on identifiers of multiple target devices; A group response message is received from the first service node, wherein the group response message carries a private key corresponding to the group parameter.

2. The method according to claim 1, wherein: The method further comprises: Calculating a parameter value of each target device based on an identifier of each target device among the multiple target devices; The group parameter is calculated based on the parameter value of each target device.

3. The method according to claim 2, wherein: The calculating the group parameter based on the parameter value of each target device includes: The group parameter is calculated based on the parameter value of each target device and the identifier of the first device.

4. The method according to any one of claims 1 to 3, wherein: The method further comprises: A registration request is received from each target device among the multiple target devices, wherein the registration request of each target device carries an identifier of each target device.

5. The method according to any one of claims 1 to 4, wherein: The method further comprises: The group parameters are uploaded to the blockchain.

6. The method according to any one of claims 1 to 5, wherein: The method further comprises: In the case that there is a revoked device among the multiple target devices, sending a group update message to the first service node, wherein the group update message carries updated group parameters, and the updated group parameters are updated based on the identifier of the revoked device; A group update response message is received from the first service node, wherein the group update response message carries a private key corresponding to the updated group parameter.

7. The method according to any one of claims 1 to 6, wherein: The first device includes one of the following: a terminal, an access network device; the target device includes one of the following: an Internet of Things device, a zero-power consumption device.

8. A communication method performed by a first service node, comprising: Receiving a group request message from a first device, wherein the group request message carries a group parameter; Based on the group parameter, calculating a private key corresponding to the group parameter; Sending a group response message to the first device, wherein the group response message carries a private key corresponding to the group parameter.

9. The method according to claim 8, wherein: The calculating, based on the group parameter, a private key corresponding to the group parameter includes: sending the group parameter to the first joint node; receiving a first group security parameter from the first joint node, wherein the first group security parameter is calculated based on the group parameter; Based on the first group security parameter and the group parameter, a private key corresponding to the group parameter is calculated.

10. The method according to claim 9, wherein: The calculating, based on the first group security parameter and the group parameter, a private key corresponding to the group parameter includes: Calculating a second group security parameter based on the group parameter and a master private key of the first service node; Based on the first group security parameter and the second group security parameter, a private key corresponding to the group parameter is calculated.

11. The method according to any one of claims 8 to 10, wherein: The method further comprises: The group parameters are uploaded to the blockchain.

12. The method according to any one of claims 8 to 11, wherein: The method further comprises: receiving a group update message from the first device, wherein the group update message carries the updated group parameters; Based on the updated group parameter, calculating a private key corresponding to the updated group parameter; Sending a group update response message to the first device, wherein the group update response message carries a private key corresponding to the updated group parameter.

13. The method according to any one of claims 8 to 12, wherein: The first device includes one of the following: a terminal, an access network device.

14. A communication method performed by a second device, comprising: Sending a first request message to a second service node, where the first request message carries an identifier of the second device; A first response message is received from the second service node, wherein the first response message carries a private key corresponding to the second device, and the private key corresponding to the second device is obtained based on an identifier of the second device.

15. The method according to claim 14, wherein: The first response message also carries the location information of the certificate of the second service node on the blockchain.

16. The method according to claim 14 or 15, wherein: The second device includes one of the following: an Internet of Things device, a zero-power device, a terminal, and an access network device.

17. A communication method performed by a second service node, comprising: receiving a first request message from a second device, where the first request message carries an identifier of the second device; Calculate a private key corresponding to the second device based on the identifier of the second device and the second joint node; A first response message is sent to the second device, wherein the first response message carries a private key corresponding to the second device.

18. The method according to claim 17, wherein: The calculating a private key corresponding to the second device based on the identifier of the second device and the second joint node includes: Sending an identifier of the second device to the second joint node; receiving a first security parameter from the second joint node, wherein the first security parameter is calculated based on an identifier of the second device; Based on the first security parameter and the identifier of the second device, a private key corresponding to the second device is calculated.

19. The method according to claim 18, wherein: The calculating, based on the first security parameter and the identifier of the second device, a private key corresponding to the second device includes: Calculating a second security parameter based on the identifier of the second device and the master private key of the second service node; A private key corresponding to the second device is calculated based on the first security parameter and the second security parameter.

20. The method according to any one of claims 17 to 19, wherein: The first response message also carries the location information of the certificate of the second service node on the blockchain.

21. The method according to any one of claims 17 to 20, wherein: The second device includes one of the following: an Internet of Things device, a zero-power device, a terminal, and an access network device.

22. A communication method performed by a second service node, comprising: Sending a second request message to the issuing node; Receive a second response message from the issuing node, wherein the second response message carries location information of the certificate of the second service node on the blockchain.

23. The method according to claim 22, wherein: The second response message also carries the certificate of the second service node.

24. A communication method performed by an issuing node, comprising: receiving a second request message from a second service node; generating a certificate of the second service node; Uploading the certificate of the second service node to the blockchain, and obtaining the location information of the certificate of the second service node on the blockchain; Send a second response message to the second service node, wherein the second response message carries location information of the certificate of the second service node on the blockchain.

25. The method according to claim 24, wherein: The second response message also carries the certificate of the second service node.

26. A first device, comprising: A first communication unit is used to send a group request message to a first service node, wherein the group request message carries a group parameter, and the group parameter is calculated based on the identifiers of multiple target devices; and receive a group response message from the first service node, wherein the group response message carries a private key corresponding to the group parameter.

27. The first device according to claim 26, wherein: The first device also includes a first processing unit: The first processing unit is configured to calculate a parameter value of each target device based on an identifier of each target device among the multiple target devices; The group parameter is calculated based on the parameter value of each target device.

28. The first device according to claim 27, wherein: The first processing unit is configured to calculate the group parameter based on the parameter value of each target device and the identifier of the first device.

29. The first device according to any one of claims 26 to 28, wherein: The first communication unit is configured to receive a registration request from each target device among the multiple target devices, wherein the registration request of each target device carries an identifier of each target device.

30. The first device according to any one of claims 26 to 29, wherein: The first communication unit is used to upload the group parameters to the blockchain.

31. The first device according to any one of claims 26 to 30, wherein: The first communication unit is used to send a group update message to the first service node when there is a revoked device among the multiple target devices, wherein the group update message carries updated group parameters, and the updated group parameters are updated based on the identification of the revoked device; and receive a group update response message from the first service node, wherein the group update response message carries a private key corresponding to the updated group parameters.

32. The first device according to any one of claims 26 to 31, wherein: The first device includes one of the following: a terminal, an access network device; the target device includes one of the following: an Internet of Things device, a zero-power consumption device.

33. A first service node, comprising: A second communication unit is configured to receive a group request message from a first device, wherein the group request message carries a group parameter; and send a group response message to the first device, wherein the group response message carries a private key corresponding to the group parameter; The second processing unit is configured to calculate a private key corresponding to the group parameter based on the group parameter.

34. The first service node according to claim 33, wherein: The second communication unit is configured to send the group parameter to the first joint node; receive a first group security parameter from the first joint node, wherein the first group security parameter is calculated based on the group parameter; The second processing unit is configured to calculate a private key corresponding to the group parameter based on the first group security parameter and the group parameter.

35. The first service node according to claim 34, wherein: The second processing unit is configured to calculate a second group security parameter based on the group parameter and a master private key of the first service node; Based on the first group security parameter and the second group security parameter, a private key corresponding to the group parameter is calculated.

36. The first service node according to any one of claims 33 to 35, wherein: The second communication unit is used to upload the group parameters to the blockchain.

37. The first service node according to any one of claims 33 to 36, wherein: The second communication unit is configured to receive a group update message from the first device, wherein the group update message carries the updated group parameters; and send a group update response message to the first device, wherein the group update response message carries a private key corresponding to the updated group parameters; The second processing unit is configured to calculate a private key corresponding to the updated group parameter based on the updated group parameter.

38. The first service node according to any one of claims 33 to 37, wherein: The first device includes one of the following: a terminal, an access network device.

39. A second device, comprising: A third communication unit, configured to send a first request message to the second service node, where the first request message carries an identifier of the second device; A first response message is received from the second service node, wherein the first response message carries a private key corresponding to the second device, and the private key corresponding to the second device is obtained based on an identifier of the second device.

40. The second device according to claim 39, wherein The first response message also carries the location information of the certificate of the second service node on the blockchain.

41. The second device according to claim 39 or 40, wherein: The second device includes one of the following: an Internet of Things device, a zero-power device, a terminal, and an access network device.

42. A second service node, comprising: A fourth communication unit, configured to receive a first request message from a second device, where the first request message carries an identifier of the second device; Sending a first response message to the second device, wherein the first response message carries a private key corresponding to the second device; The fourth processing unit is configured to calculate a private key corresponding to the second device based on the identifier of the second device and the second joint node.

43. The second service node according to claim 42, wherein: The fourth communication unit is configured to send the identifier of the second device to the second joint node; and receive a first security parameter from the second joint node, wherein the first security parameter is calculated based on the identifier of the second device; The fourth processing unit is configured to calculate a private key corresponding to the second device based on the first security parameter and an identifier of the second device.

44. The second service node according to claim 43, wherein: The fourth processing unit is configured to calculate a second security parameter based on the identifier of the second device and the master private key of the second service node; A private key corresponding to the second device is calculated based on the first security parameter and the second security parameter.

45. The second service node according to any one of claims 42 to 44, wherein: The first response message also carries the location information of the certificate of the second service node on the blockchain.

46. ​​The second service node according to any one of claims 42 to 45, wherein: The second device includes one of the following: an Internet of Things device, a zero-power device, a terminal, and an access network device.

47. A second service node, comprising: A fourth communication unit, configured to send a second request message to the issuing node; Receive a second response message from the issuing node, wherein the second response message carries location information of the certificate of the second service node on the blockchain.

48. The second service node according to claim 47, wherein: The second response message also carries the certificate of the second service node.

49. A signing node, comprising: A fifth communication unit, configured to receive a second request message from a second service node; Uploading the certificate of the second service node to the blockchain, and obtaining the location information of the certificate of the second service node on the blockchain; Sending a second response message to the second service node, wherein the second response message carries location information of the certificate of the second service node on the blockchain; The fifth processing unit is configured to generate a certificate of the second service node.

50. The issuing node according to claim 49, wherein: The second response message also carries the certificate of the second service node.

51. A first device, comprising: A transceiver, a processor and a memory, the memory being used to store a computer program, the processor being used to call and run the computer program stored in the memory so that the first device executes the method as claimed in any one of claims 7 to 7.

52. A first service node, comprising: A transceiver, a processor and a memory, the memory being used to store a computer program, the processor being used to call and run the computer program stored in the memory, so that the first service node executes the method according to any one of claims 8 to 13.

53. A second device, comprising: A transceiver, a processor and a memory, the memory being used to store a computer program, the processor being used to call and run the computer program stored in the memory, so that the second device executes the method as claimed in any one of claims 14 to 16.

54. A second service node, comprising: A transceiver, a processor and a memory, the memory being used to store a computer program, the processor being used to call and run the computer program stored in the memory, so that the second service node performs the method according to any one of claims 17 to 21 or claims 22 to 23.

55. A signing node, comprising: A transceiver, a processor and a memory, the memory being used to store a computer program, the processor being used to call and run the computer program stored in the memory so that the issuing node executes the method as described in any one of claims 24 to 25.

56. A chip, comprising: A processor for calling and running a computer program from a memory so that a device equipped with the chip performs a method as described in any one of claims 1 to 7, or claims 8 to 13, or claims 14 to 16, or claims 17 to 21, or claims 22 to 23, or claims 24 to 25.

57. A computer-readable storage medium for storing a computer program, which, when executed by a device, causes the device to perform the method described in any one of claims 1 to 7, or claims 8 to 13, or claims 14 to 16, or claims 17 to 21, or claims 22 to 23, or claims 24 to 25.

58. A computer program product comprising computer program instructions, the computer program instructions causing a computer to perform the method of any one of claims 1 to 7, or claims 8 to 13, or claims 14 to 16, or claims 17 to 21, or claims 22 to 23, or claims 24 to 25.

59. A computer program causing a computer to perform the method of any one of claims 1 to 7, or claims 8 to 13, or claims 14 to 16, or claims 17 to 21, or claims 22 to 23, or claims 24 to 25.

Images