Authentication method and device

Abstract

The application relates to an authentication method, device, computer readable storage medium, computer program product and computer program. The method comprises: obtaining identity information of a plurality of target devices; and sending a first message to a second device, wherein the first message carries the identity information of the plurality of target devices for authentication.

Description

[0001] This application is a divisional application of patent application filed on September 21, 2023, with application number 202380100415.3 and title "Authentication Method and Apparatus". Technical Field

[0002] This application relates to the field of communications, and more specifically, to an authentication method, apparatus, computer-readable storage medium, computer program product, and computer program. Background Technology

[0003] With technological advancements, communication needs arise between IoT devices or zero-power devices and network-side devices or other IoT devices (or zero-power devices). For these devices to communicate, authentication is required. However, network-side devices or other IoT devices (or zero-power devices) may need to initiate communication with multiple IoT devices (or multiple zero-power devices) simultaneously. In such scenarios, network-side devices or other IoT devices (or zero-power devices) need to perform authentication interactions with a large number of zero-power devices within a short period. Ensuring efficient authentication processing becomes a critical issue that needs to be addressed. Summary of the Invention

[0004] This application provides an authentication method, device, computer-readable storage medium, computer program product, and computer program.

[0005] This application provides an authentication method performed by a first device, comprising:

[0006] Obtain the identity information of multiple target devices;

[0007] A first message is sent to a second device, wherein the first message carries the identity information used to authenticate the plurality of target devices.

[0008] This application provides an authentication method performed by a second device, comprising:

[0009] Receive a first message from a first device, wherein the first message carries identity information for authenticating multiple target devices.

[0010] This application provides a first device, including:

[0011] The first processing unit is used to obtain the identity information of multiple target devices;

[0012] A first communication unit is configured to send a first message to a second device, wherein the first message carries the identity information used to authenticate the plurality of target devices.

[0013] This application provides a second device, including:

[0014] The second communication unit is used to receive a first message from the first device, wherein the first message carries identity information for authenticating multiple target devices.

[0015] This application provides a first device, including a transceiver, a processor, and a memory. The memory stores a computer program, and the processor calls and runs the computer program stored in the memory to cause the first device to perform the described method.

[0016] This application provides a second device, including a transceiver, a processor, and a memory. The memory stores a computer program, and the processor calls and runs the computer program stored in the memory to cause the second device to perform the method described above.

[0017] This application provides a chip for implementing the above method.

[0018] Specifically, the chip includes a processor for retrieving and running a computer program from memory, causing a device equipped with the chip to perform the methods described above.

[0019] This application provides a computer-readable storage medium for storing a computer program, which, when run by a device, causes the device to perform the above-described method.

[0020] This application provides a computer program product, including computer program instructions that cause a computer to perform the above-described method.

[0021] This application provides a computer program that, when run on a computer, causes the computer to perform the above-described method.

[0022] By employing the authentication method provided in this embodiment, the first device, acting as a proxy, can obtain the identity information related to multiple target devices, and then send this identity information to the second device, enabling the second device to authenticate the multiple target devices based on this identity information. This allows for simultaneous authentication of multiple target devices, improving authentication efficiency. Furthermore, since the entire authentication process does not require access to the content stored on the target devices, it saves storage space and reduces storage costs. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of an application scenario according to an embodiment of this application.

[0024] Figure 2This is a schematic flowchart of an authentication method according to an embodiment of this application.

[0025] Figure 3 This is a schematic flowchart of an authentication method according to another embodiment of this application.

[0026] Figures 4a-4b These are schematic diagrams of two scenarios of a Merkle tree structure according to an embodiment of this application.

[0027] Figure 5 This is a schematic flowchart of an authentication method according to an embodiment of this application.

[0028] Figure 6 This is a schematic flowchart of an authentication method according to another embodiment of this application.

[0029] Figure 7 This is a schematic flowchart of an authentication method according to another embodiment of this application.

[0030] Figure 8 This is a schematic diagram of a two-layer identity architecture for a blockchain according to an embodiment of this application.

[0031] Figure 9 This is a schematic block diagram of a first device according to an embodiment of the present application.

[0032] Figure 10 This is a schematic block diagram of a second device according to an embodiment of this application.

[0033] Figure 11 This is a schematic block diagram of a communication device according to an embodiment of this application.

[0034] Figure 12 This is a schematic block diagram of a chip according to an embodiment of this application.

[0035] Figure 13 This is a schematic block diagram of a communication system according to an embodiment of this application. Detailed Implementation

[0036] The technical solutions of this application embodiment can be applied to various communication systems, such as LTE, LTE-A, NR, NR evolution, WLAN, WiFi, or other communication systems.

[0037] This application describes various embodiments in conjunction with network devices and terminals. The terminal can be mobile or fixed, and may also be referred to as a mobile station, user unit, etc. The terminal can be a station in a WLAN, or a smart terminal, wireless modem, laptop, tablet, etc. In this application's embodiments, the terminal can be a VR / AR terminal, industrial control terminal, autonomous driving terminal, telemedicine terminal, smart grid terminal, transportation safety terminal, smart city terminal, or smart home wireless terminal, etc. By way of example and not limitation, in this application's embodiments, the terminal can also be a wearable device.

[0038] In this embodiment, the network device can be a device for communicating with a terminal. The network device can be an access point in a WLAN, an evolved base station in LTE, a relay station, a network device (gNB) in a vehicle-mounted device, wearable device, or NR network, or a network device in a future PLMN network, or a network device in a non-terrestrial network, etc. As an example and not a limitation, in this embodiment, the network device can have mobility characteristics; for example, the network device can be a mobile device.

[0039] It should be understood that the terms "system" and "network" are often used interchangeably in this document. The term "and / or" in this document merely describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship. It should be understood that the term "instruction" mentioned in the embodiments of this application can be a direct instruction, an indirect instruction, or an indication of a related relationship. For example, A instructing B can mean that A directly instructs B, for example, B can be obtained through A; it can also mean that A indirectly instructs B, for example, A instructs C, B can be obtained through C; or it can mean that there is a related relationship between A and B. In the description of the embodiments of this application, the term "correspondence" can indicate a direct or indirect correspondence between two things, or an related relationship between two things, or a relationship of instruction and being instructed, configuration and being configured, etc.

[0040] To facilitate understanding of the technical solutions of the embodiments of this application, the relevant technologies of the embodiments of this application are described below. The following relevant technologies are optional solutions and can be combined with the technical solutions of the embodiments of this application in any way, and they all fall within the protection scope of the embodiments of this application.

[0041] Figure 1An exemplary communication system 100 is illustrated. This 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 the coverage area of ​​each network device 110 may include other numbers of terminals 120; this embodiment does not limit this. In one possible implementation, the communication system 100 may also include mobility management entities, access and mobility management functions, and other network entities; this embodiment does not limit this. The network devices may further 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 for LTE, LTE-A, or NR systems. Figure 1 Taking the communication system shown as an example, the communication equipment may include network devices and terminals with communication functions. The communication equipment may also include other devices in the communication system, such as network controllers, mobility management entities and other network entities. This application embodiment does not limit this.

[0042] Figure 2 This is a schematic flowchart illustrating an authentication method performed by a first device according to an embodiment of this application. The method includes at least a portion of the following.

[0043] S210, Obtain the identity information of multiple target devices;

[0044] S220. Send a first message to the second device, wherein the first message carries the identity information used to authenticate the plurality of target devices.

[0045] Figure 3 This is a schematic flowchart illustrating an authentication method performed by a second device according to another embodiment of this application. The method includes at least a portion of the following.

[0046] S310. Receive a first message from a first device, wherein the first message carries identity information for authenticating multiple target devices.

[0047] In this application, the first device can be alternatively referred to as a proxy device, proxy node, etc., and the various possible names for the first device are not exhaustively listed or limited here. The first device is one of the following: a terminal, an access network device. The access network device can be any of the following: a base station, a gNB, an eNB, an Integrated Access Backhaul (IAB) node, etc.

[0048] Each of the plurality of target devices is of one of the following types: zero-power device, Internet of Things (IoT) device. The number of these plurality of target devices is not limited in this embodiment.

[0049] In some embodiments, any target device can be any of the following: an Ambient Powered IoT (AIoT) device, an active zero-power device, a passive zero-power device, a semi-passive zero-power device, etc. In some embodiments, any target device can also be a terminal with low computing power. In some possible embodiments, any target device can be referred to as a tag. A complete list of all possible names or device types for target devices is not provided here.

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

[0051] The identifier of the multiple target devices can specifically refer to the identifier of each target device among the multiple target devices. This identifier can be represented as an ID, and can include, but is not limited to, at least one of the following: factory identifier, factory unique identifier, operator-issued identifier, service provider-issued identifier, 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. Among these, the network identifier can include at least one of the following: IP address (Internet Protocol Address), MAC address (Media Access Control), etc.

[0052] Since different types of second devices may require different processing, the authentication method provided in this application will be described below in conjunction with different types of second devices.

[0053] In some possible implementations, the second device can be an authentication function entity. The authentication function entity can be deployed in at least one of the following: Application Function (AF), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Unified Data Management Function (UDM), Unified Data Repository (UDR), Home Subscriber System (HSS), Authentication Credential Repository and Processing Function (ARPF), Bootstrapping Server Function (BSF), Security Anchor Function (SEAF), core network dedicated network elements, access network devices, and edge configuration servers. Here, when the second device is an authentication function entity, if it is specifically deployed in an access network device, then this access network device is a different access network device from the first device described above. For example, the first device can be a first access network device, and the second device can be a second access network device.

[0054] The authentication function entity can refer to a network element with authentication capabilities. The authentication function may at least include AIoT group authentication and / or group authentication functions. In some possible examples, A-NF can be used to represent A-IoT group authentication function (NF) and / or group authentication function. In other possible examples, the authentication function may also include at least one of the following: zero-power group authentication and / or group authentication functions, IoT device group authentication and / or group authentication functions, etc.

[0055] For example, the authentication function entity may be composed of an authentication function added to the application server's AF.

[0056] For example, the authentication function entity can be a newly added core network dedicated network element, which has, is set up, or is configured with authentication functionality. In this example, the core network dedicated network element can be called an AIoT authentication function entity, a zero-power function dedicated authentication function entity, a zero-power dedicated network element, or a zero-power device dedicated network element, etc. That is, the core network dedicated network element can refer to a network element that has at least zero-power related functions (such as having AIoT authentication functionality), or a core network element that can at least serve AIoT (or serve zero-power devices). It should be understood that the core network dedicated network element can be set up separately, or it can be an existing core network element with added zero-power authentication related functions (such as having AIoT or tag authentication functionality). This embodiment does not exhaustively list all possible cases.

[0057] For example, the authentication function entity can be an existing core network element, and the core network element has added, possesses, or newly configured authentication functions. For instance, the core network element may have added authentication functions based on at least one of the following functions: AMF, SMF, AUSF, UDM, UDR, HSS, ARPF, BSF, SEAF, etc.

[0058] In some embodiments, the second device (i.e., the authentication function entity) is the device that initiates authentication. The second device may send a third message to the first device when it needs to communicate with multiple target devices.

[0059] In one embodiment, the third message may carry at least the identifiers of multiple target devices. Further, the third message may implicitly indicate that the second device needs to authenticate the multiple target devices, or implicitly indicate that the second device needs to authenticate and communicate with the multiple target devices, by carrying the identifier of each of the multiple target devices; alternatively, the third message may also carry explicit indication information, which may be used to indicate any one of the following: the second device needs to authenticate the multiple target devices, or the second device needs to authenticate and communicate with the multiple target devices.

[0060] It should be understood that before the second device sends the third message, at least some devices can be identified from all devices in a group as the multiple target devices, and then the third message is sent. Here, each device in a group can be of the same type, such as all being zero-power devices or IoT devices. This embodiment does not limit the method by which the second device determines all devices included in a group, or the method by which the second device selects multiple target devices from a group.

[0061] After receiving the third message sent by the second device, the first device obtains the identity information of multiple target devices.

[0062] In some possible embodiments, obtaining the identity information of multiple target devices can be achieved by the first device itself.

[0063] The identity information includes the identifier of each target device among the plurality of target devices and one or more parameter values ​​corresponding to each target device. The one or more parameter values ​​corresponding to each target device are determined based on group information. In this embodiment, for any device without powerful computing capabilities (i.e., a zero-power device), a first device with computing capabilities can be found as a proxy device to receive various services from the zero-power device in the Internet of Things. The first device is an ordinary device with computing capabilities, which can be a device under a first service node (for example, this service node can also be called a key generation center (KGC)), and belongs to the same trust domain as the multiple devices it proxies.

[0064] The first message also carries a group parameter, which is calculated based on the identifiers of the plurality of target devices. Specifically, the group parameter can be calculated based on the identifier of each of the plurality of target devices.

[0065] Furthermore, the group parameter is calculated based on the identifiers of multiple devices, including the multiple target devices; specifically, the group parameter can be calculated based on the identifier of each of the multiple devices.

[0066] In other words, the first message sent by the first device can carry the identity information of multiple target devices and the group parameters. The identity information of these multiple target devices may be simply referred to as identity information in the following text. Unless otherwise specified, the concept of identity information in the following text is the same as the identity information of multiple target devices.

[0067] In this embodiment, the process by which the first device obtains the identity information of multiple target devices may include: generating identity information for multiple target devices based on the identifier of each target device. Furthermore, the first device's processing may also include: obtaining group parameters corresponding to the groups to which the multiple target devices belong.

[0068] In one embodiment, the first device pre-stores group information. The group information includes: the identifier of each device in the group, and group parameters, wherein the group parameters are calculated based on the identifier of each device; the group information also includes parameter values ​​used to verify each device. Specifically, the group information is stored based on a Merkle tree structure, that is, the first device locally stores a Merkle tree, where each leaf node of the tree corresponds to the ID of each device in the group, and the root node of the tree corresponds to the hash value (group parameter) of the identities of all the proxied devices. Further, the Merkle tree includes: a root node, multiple leaf nodes, and multiple intermediate nodes, wherein the multiple leaf nodes are used to store the identifiers of multiple devices, each of the multiple intermediate nodes is used to store the parameter value of the content of its corresponding child node, the root node is used to store the group parameters, the multiple devices belong to the same group, the multiple devices include the multiple target devices, and the multiple devices and the first device belong to the first service node.

[0069] The aforementioned multiple devices and the first device belong to the first service node, meaning that the first device and the multiple devices belong to the same trust domain.

[0070] The aforementioned multiple devices include the multiple target devices, meaning that the multiple target devices are at least a portion of all devices in the same group. This embodiment does not limit the number of multiple devices; as long as the number of multiple target devices is less than or equal to the number of multiple devices, and the number of multiple target devices is greater than or equal to 2, it is within the protection scope of this embodiment.

[0071] The multiple leaf nodes used to store the identifiers of multiple devices can refer to the fact that different leaf nodes among the multiple leaf nodes are used to store the identifiers of different devices.

[0072] Each of the plurality of intermediate nodes corresponds to one or more child nodes, and different intermediate nodes correspond to different child nodes. The one or more child nodes corresponding to any intermediate node refer to the one or more child nodes at the next level of that intermediate node; correspondingly, the intermediate node is the parent node of each of its corresponding next-level child nodes. Furthermore, the next-level child node of any intermediate node can be either the next-level leaf node of that intermediate node or the next-level intermediate node of that intermediate node.

[0073] The parameter value can be a hash value. That is, the hash value used by any intermediate node to store the content of its corresponding child node.

[0074] Optionally, taking any intermediate node as intermediate node i as an example, intermediate node i can correspond to a leaf node i, where i is an integer greater than or equal to 1. In this case, the content of the leaf node i is an identifier of device i; correspondingly, the parameter value of the content of the child node corresponding to the intermediate node i can be obtained by hashing the identifier of device i stored in the leaf node i corresponding to the intermediate node i. Specifically, the calculation method of the parameter value of the content of the child node corresponding to the intermediate node i can include: obtaining the identifier of device i stored in the leaf node i corresponding to the intermediate node i; performing a hash calculation on the identifier of device i to obtain the i-th hash value; and using the i-th hash value as the parameter value of the content of the leaf node i corresponding to the intermediate node i. Here, the specific method of hash calculation is not limited in this embodiment. Wherein, i is an integer greater than or equal to 0, or i is an integer greater than or equal to 1.

[0075] Optionally, taking any intermediate node j as an example, intermediate node j can correspond to multiple child nodes, and each of the multiple child nodes is not a leaf node, where j is an integer greater than or equal to 1. In this case, the content of any child node is the parameter value (i.e., a hash value) stored in that child node; correspondingly, the parameter value of the content of the child node corresponding to intermediate node j can be obtained by summing the parameter values ​​stored in each child node corresponding to intermediate node j and then performing a hash calculation. Specifically, the calculation method of the parameter value of the content of the child node corresponding to intermediate node j can include: obtaining the parameter value stored in each of the multiple child nodes corresponding to intermediate node j; summing the parameter values ​​stored in each child node to obtain the j-th first value, performing a hash calculation on the j-th first value to obtain the j-th hash value; and using the j-th hash value as the parameter value of the content of the multiple child nodes corresponding to intermediate node j. Where j is an integer greater than or equal to 0, or j is an integer greater than or equal to 1.

[0076] The root node can be a node in a Merkle tree that has no parent node at the next level. This root node can correspond to multiple child nodes (i.e., multiple child nodes at the next level of the root node), and each of these 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 that child node (i.e., a hash value). The group parameter stored in the root node can be obtained by summing the parameter values ​​stored in each child node corresponding to the root node and then performing a hash calculation. Here, the group parameter can refer to the parameter values ​​of the group to which multiple target devices belong; this group can include multiple devices, meaning the group parameter can be related to the identifiers of all devices in the group to which multiple target devices belong.

[0077] Specifically, the calculation method for the group parameter stored in the root node may include: obtaining the parameter value stored in each of the multiple child nodes corresponding to the root node; summing the parameter values ​​stored in each child node to obtain a second value; performing a hash calculation on the second value to obtain a hash value; and using the hash value as the group parameter corresponding to the root node.

[0078] In one possible example, the Merkle tree structure is a binary tree structure; therefore, any intermediate node can correspond to one or two child nodes. (Combined) Figure 4a For example, in Figure 4a It contains 8 leaf nodes corresponding to all 8 devices in a group. These 8 leaf nodes are used to store the IDs of each device. For example, leaf node 41 stores ID1 of device 1. The other leaf nodes are not described again. Figure 4a In the diagram, the next level child node of intermediate node 411 is a leaf node 41, which stores the content ID1. Correspondingly, intermediate node 411 stores the hash value Hash(ID1) of leaf node 41's ID1. For example, the hash value stored in intermediate node 411 can be represented as N1. The next level child node of intermediate node 422 is not a leaf node. Intermediate node 422 has two child nodes, child node 412 and child node 413. Intermediate node 422 stores the hash value Hash(N2+N3) calculated by adding the hash values ​​(N2) of child node 412 and (N3) of child node 413. For example, the hash value stored in intermediate node 422 can be represented as N9. The next level of root node 440 has two child nodes, child node 431 and child node 432. Root node 440 is used to store group parameters (i.e., ...). Figure 4a (The Root is shown in the diagram), and the group parameter is equal to the hash value (N) of child node 431. 12 ) and the hash value (N) of child node 432 13 The hash value Hash(N) is obtained by performing the summation and subsequent calculations. 12 +N 13 The above is only for... Figure 4a The example of some nodes is provided above. In actual processing, the calculation method of the content stored in each node at each level in this Merkle tree is similar to that of the example nodes, so it will not be described in detail.

[0079] In one embodiment, the group parameter can be calculated based on the parameter values ​​stored in each child node corresponding to the root node and the identifier of the first device.

[0080] For example, the group parameter can be calculated as follows: obtain the parameter value stored in each of the multiple child nodes corresponding to the root node; sum the parameter values ​​stored in each child node to obtain a second value, perform a hash calculation on the second value to obtain a first hash value; perform a hash calculation on the identifier of the first device to obtain a second hash value, and sum the first hash value and the second hash value to obtain the group parameter corresponding to the root node.

[0081] For example, the group parameter can be calculated as follows: obtain the parameter value stored in each of the multiple child nodes corresponding to the root node; sum the parameter value stored in each child node and the identifier of the first device to obtain a second value; perform a hash calculation on the second value to obtain a first hash value; and use the first hash value as the group parameter corresponding to the root node.

[0082] In this embodiment, except for the group parameters of the root node which are different from those in the previous embodiment, the descriptions of the leaf nodes and intermediate nodes are the same as those in the previous embodiment, so they will not be repeated.

[0083] In one embodiment, the group information is stored based on a Merkle tree structure. The group information includes: a root node, multiple leaf nodes, and multiple intermediate nodes. The multiple leaf nodes are used to store the identifiers of multiple devices and the identifier of a first device. Each of the multiple intermediate nodes is used to store the parameter values ​​of the content of the corresponding child node. The root node is used to store the group parameters. The multiple devices belong to the same group. The multiple devices include the multiple target devices. The multiple devices and the first device belong to a first service node.

[0084] In this embodiment, the identifier of the first device is added to the Merkle tree and stored as a leaf node. The calculation method for any intermediate node in this embodiment is the same as in the previous embodiment, and will not be repeated. The group parameter of the root node is still obtained by summing the parameter values ​​stored in each child node corresponding to the root node and then performing a hash calculation, and will not be repeated.

[0085] Combination Figure 4b For example, in Figure 4b It contains 8 leaf nodes, of which 1 leaf node corresponds to the ID of the first device, and the remaining 7 leaf nodes correspond to all 7 devices in a group. These 7 leaf nodes are used to store the IDs of each device in the group. For example, leaf node 40a stores the ID of the first device. A Leaf node 41 stores the ID1 of device 1, except for leaf node 40a and... Figure 4a Aside from the differences, other leaf nodes are similar to Figure 4a The same points will not be repeated. Figure 4bIn the diagram, the next level child node of intermediate node 410a is a leaf node 40a, and intermediate node 410a is used to store the ID of leaf node 40a. A Hash value (ID) A For example, the hash value stored in intermediate node 410a can be represented as N0; related explanations regarding other intermediate nodes and root node 440 are as follows. Figure 4a The relevant explanations are the same, so I will not repeat them here.

[0086] It should be noted that the aforementioned group parameters can be calculated by the first device. The processing of the first device's initial calculation of the group parameters (or any subsequent update of the group parameters) is similar to the above processing and will not be repeated. After the first device initially calculates the group parameters (or any subsequent update of the group parameters), in addition to saving the aforementioned group information locally, the following processing can also be performed: the first device saves the group parameters on the blockchain (i.e., the first device uploads and saves the group parameters on the blockchain); or, the first device sends the group parameters to its own first service node, and the first service node saves the group parameters on the blockchain (i.e., the first device sends the group parameters to the first service node, and the first service node saves the group parameters on the blockchain). It should also be understood that the state of the group parameters (such as whether they have been revoked) can also be maintained and uploaded to the blockchain by the first device; or, the state of the group parameters can be maintained and uploaded to the blockchain by the first service node.

[0087] The first device may obtain the group parameters corresponding to the group to which the multiple target devices belong by extracting the group parameters corresponding to the group to which the multiple target devices belong from the root node of the Merkle tree.

[0088] After receiving the third message, the first device can extract the identifiers of multiple target devices from the third message, and then generate identity information for multiple target devices based on the identifier of each target device. Specifically, the processing to obtain the identity information may include: determining the leaf node corresponding to each target device based on the identifier of each target device; determining one or more parameter values ​​corresponding to each target device based on the leaf node corresponding to each target device; and using the identifier of each target device and the one or more parameter values ​​corresponding to each target device as the identity information.

[0089] Taking any target device as the k-th target device as an example, based on the leaf node corresponding to each target device, determine one or more parameter values ​​corresponding to each target device. This can include: based on the leaf node corresponding to the identifier of the k-th target device, determine the upper-level intermediate node of the leaf node corresponding to the k-th target device, and take the upper-level intermediate node of the leaf node corresponding to the k-th target device as the current node; determine the adjacent nodes that share the same parent node as the current node, and extract the parameter value stored in the adjacent node as the first parameter value corresponding to the k-th target device; determine whether the parent node of the current node is the root node. If it is, then take the first parameter value corresponding to the k-th target device as a parameter value corresponding to the target device; if not, take the parent node of the current node as the new current node, continue to determine the adjacent nodes that share the same parent node as the new current node, extract the parameter value stored in the adjacent node as the second parameter value corresponding to the k-th target device, and so on, until the parent node of the current node is determined to be the root node, thus obtaining one or more parameter values ​​corresponding to the k-th target device. Here, k is an integer greater than or equal to 0, or k is an integer greater than or equal to 1.

[0090] It should be noted that the one or more parameter values ​​corresponding to the kth target device can be in the form of a sequence or an array, and the one or more parameter values ​​corresponding to the kth target device can be arranged in order in the array (or sequence). The order of one or more parameter values ​​corresponding to the k-th target device can be arranged according to the extraction order, such as arranging the first extracted parameter value at the beginning (e.g., the first position in an array or sequence), and so on, arranging the last extracted parameter value at the end (or tail) position (e.g., the last position in an array or sequence); or, the order of one or more parameter values ​​corresponding to the k-th target device can be arranged according to the level of the intermediate nodes corresponding to the parameter values ​​in the Merkle tree, such as sorting the intermediate nodes corresponding to the parameter values ​​from low to high level (where low refers to the closest to the leaf node and high refers to the closest to the root node). For example, the parameter values ​​extracted from the intermediate node closest to the leaf node can be arranged at the beginning (or the first position) (e.g., the first position in an array or sequence), and so on, arranging the parameter values ​​extracted from the intermediate node closest to the root node at the end (or tail) position (e.g., the last position in an array or sequence).

[0091] It should be understood that since the same processing is performed for each target device as for the k-th target device, this example does not elaborate on the processing for each target device.

[0092] Combination Figure 4aFor example, suppose there are multiple target devices, including target device 0 and target device 4. Leaf node 40 stores the ID0 of target device 0. The next-level intermediate node of leaf node 40 is intermediate node 410, and the parent node of intermediate node 410 is node 421. The adjacent node of intermediate node 410 that shares the same parent node 421 is intermediate node 411. Then, the parameter value N1 (specifically equal to Hash(ID1)) in intermediate node 411 is extracted as a parameter value corresponding to target device 0. If the next-level parent node 421 of intermediate node 410 is not the root node, then this parent node 421 is used as the current node 421, and the parameter value N9 (specifically equal to Hash(N2+N3)) in the adjacent node 422 that shares the same parent node 431 with the current node 421 is extracted. If the next-level parent node 431 of the current node 421 is not the root node, then this parent node 431 is used as the current node 431, and the parameter value N9 in the adjacent node 432 that shares the same parent node with the current node 431 is extracted. 13 (Specifically equal to Hash(N)) 10 +N 11 If the parent node of the current node 431 is the root node 440, then the multiple parameter values ​​corresponding to the target device 0 can be obtained, namely N1, N9, N... 13 Leaf node 44 stores the ID4 of target device 4. The same processing as for target device 0 is performed on target device 4, ultimately obtaining multiple parameter values ​​corresponding to target device 4, namely N5, N... 11 N 12 After the above processing, one or more parameter values ​​corresponding to each target device can be obtained; then, the identifier of each target device and the one or more parameter values ​​corresponding to each target device are used together as the identity information. For example, still referring to the above example, the identity information includes: ID0, N1, N9, N... 13 ID4, N5, N 11 N 12 .

[0093] In one embodiment, the group information may be generated by other devices; further, the group information may be generated by other devices and then configured for the first device; correspondingly, the process by which the first device obtains the identity information of multiple target devices may include: the first device may obtain the identity information and group parameters of multiple target devices based on the configured group information.

[0094] In some embodiments, obtaining the identity information of multiple target devices can be achieved by the first device obtaining the identity information of multiple target devices from other devices. That is, the identity information of the multiple target devices can be configured or sent to the first device by other devices. This embodiment does not limit or exhaustively list the specific sending methods. For example, the process of the first device obtaining the identity of multiple target devices may include: the first device can send the identifiers of multiple target devices to other devices and receive the identity information of multiple target devices sent by other devices.

[0095] Optionally, the group parameter can also be obtained by the first device from other devices, and the group parameter is calculated by the other devices based on the identifiers of multiple devices. For example, the processing of the first device may include: the first device can send the identifiers of multiple target devices to other devices, and receive the identity information of multiple target devices and the group parameter sent by other devices.

[0096] In some embodiments, the first message may carry group parameters and identity information of the plurality of target devices. Accordingly, the processing performed by the second device after receiving the first message may include: calculating an authentication value for the plurality of target devices based on the identifier of each target device in the identity information and one or more parameter values ​​corresponding to each target device; and authenticating the plurality of target devices based on the authentication values ​​of the plurality of target devices and the group parameters.

[0097] Taking any one of the multiple target devices as the k-th target device as an example, the aforementioned calculation of the authentication value of the multiple target devices based on the identifier of each target device and one or more parameter values ​​corresponding to each target device contained in the identity information of the multiple target devices may include: extracting the identifier of the k-th target device and each parameter value corresponding to the k-th target device contained in the identity information of the multiple target devices; performing a hash calculation on the identifier of the k-th target device to obtain the hash value of the identifier of the k-th target device; and calculating the authentication value of the k-th target device based on the hash value of the identifier of the k-th target device and each parameter value corresponding to the k-th target device.

[0098] In one embodiment, the identifier of each device in the group is used as a leaf node in the Merkle tree of the group information; or, the identifier of the first device and the identifier of each device in the group are used as leaf nodes in the Merkle tree of the group information.

[0099] As described in the foregoing embodiments, one or more parameter values ​​corresponding to the k-th target device can be in the form of a sequence or an array, and the one or more parameter values ​​corresponding to the k-th target device can be arranged in order in the array (or sequence); correspondingly, the authentication value of the k-th target device is calculated based on the hash value of the identifier of the k-th target device and each parameter value corresponding to the k-th target device, which may include:

[0100] Based on the sorting of each parameter value corresponding to the k-th target device, the first parameter value is extracted. The sum of the hash value of the first parameter value and the identifier of the k-th target device is calculated to obtain the first initial value. The first initial value is then hashed to obtain the first verification value. If there are any remaining unextracted parameter values ​​after the first parameter value, the sorting of each parameter value corresponding to the k-th target device continues. The n-th parameter value is extracted, and the sum of the n-th parameter value and the (n-1)-th verification value is calculated to obtain the n-th initial value. The n-th initial value is then hashed to obtain the n-th verification value. Here, n is greater than or equal to 2. The integer n is used as the first verification value when n equals 2. If there are remaining unextracted parameter values ​​after the nth parameter value, the process continues based on the sorting of each parameter value corresponding to the kth target device, extracting the (n+1)th parameter value, calculating the sum of the (n+1)th parameter value and the nth verification value to obtain the (n+1)th initial value, and performing a hash calculation on the (n+1)th initial value to obtain the (n+1)th verification value. If it is determined that there are no remaining parameter values ​​after the currently extracted (n+1)th parameter value, the last obtained (n+1)th verification value is used as the authentication value of the kth target device. In other words, the process of sorting each parameter value corresponding to the kth target device, extracting the next parameter value, and calculating the verification value is repeated until it is determined that the currently extracted parameter value is the last parameter value corresponding to the kth target device, and the last obtained verification value is used as the authentication value of the kth target device.

[0101] It should be understood that since the kth target device is any one of multiple target devices, the same processing is performed on each target device as on the kth target device to obtain the authentication value of each target device. Therefore, the processing related to each target device will not be described in detail here.

[0102] Taking any target device as the k-th target device as an example, the authentication of the multiple target devices based on their authentication values ​​and the group parameters can include one of the following: if the authentication value and the group parameters of the k-th target device are the same, the authentication of the k-th target device is determined to be successful; if the authentication value and the group parameters of the k-th target device are different, the authentication of the k-th target device is determined to be unsuccessful. Successful authentication of the k-th target device can also be alternatively expressed as: successful authentication of the k-th target device, or successful authentication of the k-th target device, or successful identity authentication of the k-th target device, etc., without exhaustive examples. Unsuccessful authentication of the k-th target device can also be alternatively expressed as: authentication failure of the k-th target device, or failure to authenticate the k-th target device, or failure of identity authentication of the k-th target device, etc., without exhaustive examples.

[0103] Combination Figure 4a For example, suppose the identifier of the kth target device is... Figure 4a In The value of one or more parameters corresponding to the k-th target device is Figure 4a In Correspondingly, the second device, in order to verify the k-th target device, can perform the following processing: calculate Based on the first parameter value corresponding to the k-th target device Calculated Based on the second parameter value corresponding to the k-th target device calculate Based on the third parameter value corresponding to the k-th target device calculate According to group parameters With the calculated In comparison, if ,but That is, if the authentication of the k-th target device is successful, otherwise... This means that the authentication for the kth target device failed.

[0104] Since the k-th target device can be any one of the multiple target devices, the same processing as for the k-th target device is performed on each target device to obtain the authentication result for each target device. Therefore, the processing related to each target device will not be described in detail here. It should be noted that the above authentication process can be performed on each target device on the second device side, thereby obtaining the authentication result for each target device. If the authentication of each target device is successful, it can be determined that the authentication of the multiple target devices is successful.

[0105] In one embodiment, the identifier of each device in the group is used as a leaf node in the Merkle tree of the group information, but the identifier of the first device is included when calculating the group parameters.

[0106] In one example, the group parameter can be calculated as follows: obtain the parameter value stored in each of the multiple child nodes corresponding to the root node; sum the parameter values ​​stored in each child node to obtain a second value, and perform a hash calculation on the second value to obtain a first hash value; perform a hash calculation on the identifier of the first device to obtain a second hash value, and sum the first hash value and the second hash value to obtain the group parameter corresponding to the root node.

[0107] Taking any target device as the kth target device as an example, in this case, based on the hash value of the identifier of the kth target device and each parameter value corresponding to the kth target device, the authentication value of the kth target device is calculated, which may include:

[0108] Based on the sorting of each parameter value corresponding to the k-th target device, the first parameter value is extracted. The sum of the hash value of the first parameter value and the identifier of the k-th target device is calculated to obtain the first initial value. The first initial value is then hashed to obtain the first verification value. If there are any remaining unextracted parameter values ​​after the first parameter value, the n-th parameter value is extracted based on the sorting of each parameter value corresponding to the k-th target device. The sum of the n-th parameter value and the (n-1)-th verification value is calculated to obtain the n-th initial value. The n-th initial value is then hashed to obtain the n-th verification value. Here, n is an integer greater than or equal to 2. When n equals 2, the first parameter value is extracted. The first verification value is n-1. If there are any remaining unextracted parameter values ​​after the nth parameter value, the process continues based on the sorting of each parameter value corresponding to the kth target device, extracting the (n+1)th parameter value, calculating the sum of the (n+1)th parameter value and the nth verification value to obtain the (n+1)th initial value, and performing a hash calculation on the (n+1)th initial value to obtain the (n+1)th verification value. If it is determined that there are no remaining parameter values ​​after the currently extracted (n+1)th parameter value, the identifier of the first device is hashed to obtain the second hash value to be verified, and the (n+1)th verification value and the second hash value to be verified are summed to obtain the authentication value of the kth target device. In other words, the process of sorting each parameter value corresponding to the kth target device, extracting the next parameter value, and calculating the verification value is repeated until it is determined that the currently extracted parameter value is the last parameter value corresponding to the kth target device. The last obtained verification value is then summed with the second hash value to be verified obtained by hashing the identifier of the first device to obtain the authentication value of the kth target device.

[0109] In this example, the description of authenticating the multiple target devices based on the authentication values ​​of the multiple target devices and the group parameters is the same as in the previous embodiment and will not be repeated.

[0110] In one example, the group parameter can be calculated as follows: obtain the parameter value stored in each of the multiple child nodes corresponding to the root node; sum the parameter value stored in each child node and the identifier of the first device to obtain a second value; perform a hash calculation on the second value to obtain a first hash value; and use the first hash value as the group parameter corresponding to the root node.

[0111] In this case, the authentication value of the k-th target device is calculated based on the hash value of the identifier of the k-th target device and each parameter value corresponding to the k-th target device, which may include:

[0112] Based on the sorting of each parameter value corresponding to the k-th target device, the first parameter value is extracted. The sum of the hash value of the first parameter value and the identifier of the k-th target device is calculated to obtain the first initial value. The first initial value is then hashed to obtain the first verification value. If there are any remaining unextracted parameter values ​​after the first parameter value, the process continues based on the sorting of each parameter value corresponding to the k-th target device, extracting the n-th parameter value. The sum of the n-th parameter value and the (n-1)-th verification value is calculated to obtain the n-th initial value. If there are any remaining parameter values ​​after the n-th parameter value, the n-th initial value is hashed to obtain the n-th verification value. Here, n is an integer greater than or equal to 2. In this case, the (n-1)th verification value is the first verification value. If there are remaining unextracted parameter values ​​after the nth parameter value, then continue to extract the (n+1)th parameter value based on the sorting of each parameter value corresponding to the kth target device. Calculate the sum of the (n+1)th parameter value and the nth verification value to obtain the (n+1)th initial value. If it is determined that there are no remaining parameter values ​​after the currently extracted (n+1)th parameter value, then sum the (n+1)th initial value and the identifier of the first device to obtain the (n+1)th pending value. Perform a hash calculation on the (n+1)th pending value to obtain the (n+1)th verification value. Use the last obtained (n+1)th verification value as the authentication value of the kth target device. That is, repeat the process of sorting each parameter value corresponding to the kth target device, extracting the next parameter value, and performing a hash calculation to obtain the verification value until it is determined that the currently extracted parameter value is the last parameter value corresponding to the kth target device. Then, sum the last obtained initial value and the identifier of the first device and perform a hash calculation to obtain the last verification value. Use the last verification value as the authentication value of the kth target device.

[0113] In this example, the description of authenticating the multiple target devices based on the authentication values ​​of the multiple target devices and the group parameters is the same as in the previous embodiment and will not be repeated.

[0114] In one embodiment, after the second device receives the first message, the process may further include: the second device extracting group parameters from the first message; and the second device searching online to determine whether the group parameters have been revoked.

[0115] The second device searching the blockchain to see if the group parameter has been revoked can mean that the second device searches the blockchain for the group parameter and obtains the status of the group parameter. The status of the group parameter can include: the group parameter has been revoked, or the group parameter is normal (or has not been revoked).

[0116] In one example, the process of the second device checking whether the group parameter has been cancelled can be performed before authenticating the multiple target devices based on their authentication values ​​and the group parameter; that is, if the group parameter has not been cancelled, the second device can perform the process of authenticating the multiple target devices based on their authentication values ​​and the group parameter. In another example, the process of the second device checking whether the group parameter has been cancelled can be performed after authenticating the multiple target devices based on their authentication values ​​and the group parameter; that is, after successfully authenticating the multiple target devices based on their authentication values ​​and the group parameter, the second device checks whether the group parameter has been cancelled. If the group parameter has not been cancelled, the second device can determine that the authentication of the multiple target devices is complete.

[0117] Through the above process, authentication can be initiated by the second device, and then the first device can act as an agent to generate the identity information of each target device and report it to the second device. The second device can then complete the authentication process for multiple target devices based on the identity information of each target device. This can improve the efficiency of authenticating at least some of the devices in a group.

[0118] In some possible implementations, certificate-related authentication may also be added between the first device and the second device.

[0119] In the processing of the first device, the method further includes: receiving the address of a second certificate from the second device, wherein the second certificate is a certificate of the second device.

[0120] In this embodiment, the second device can initiate authentication by sending a third message; therefore, the address of the second certificate can be carried in the third message. That is, the third message also carries the address of the second certificate, which is the certificate of the second device. This second certificate is stored in the blockchain; therefore, the address of the second certificate specifically refers to its address on the blockchain, or its location information on the blockchain. In other words, when the second device initiates authentication, it (i.e., the authentication function entity) sends the address of its own second certificate and the identifier of each of the multiple target devices in the third message to the first device.

[0121] The address of the second certificate can be obtained during the registration of the second device. The registration process for the second device may include: the second device storing its identifier (e.g., ID), public key (e.g., PK), and other public information, as well as a signature of the above information (e.g., a signature). The second device submits its certificate to the issuing node; after verifying the identity of the second device (i.e., the identifier and public key of the second device) and other information, the issuing node signs it with the issuing node's private key to complete the generation of the second certificate for the second device; the issuing node uploads the generated second certificate to the blockchain and obtains the location information of the certificate on the blockchain; the issuing node issues the second certificate to the second device and sends the location information of the second certificate on the chain to the second device.

[0122] Accordingly, the processing of the first device may also include: authenticating the identity of the second device based on the address of the second certificate.

[0123] Specifically, authenticating the identity of the second device based on the address of the second certificate may include: the first device searching for the second certificate on the blockchain based on the location information (or address) of the second certificate; if the second certificate is found and it is determined that the second certificate has not been revoked, the authentication of the second device is determined to be successful. Alternatively, it may include: if the second certificate is not found and / or it is determined that the second certificate has been revoked, the authentication of the second device is determined to be unsuccessful.

[0124] Here, in the processing of the first device, the method further includes: receiving auxiliary information related to the second certificate from the second device. This auxiliary information related to the second certificate can also be carried in a third message, meaning the third message can also carry the auxiliary information related to the second certificate. The method by which the first device determines whether the second certificate has been revoked can include: the first device verifying whether the second certificate has been revoked based on the auxiliary information related to the second certificate and the product of all revoked revocation factors maintained by the certificate issuing node corresponding to the second device, thus obtaining a result indicating whether the second certificate has been revoked. The function of the auxiliary information related to the second certificate is to prove that the second certificate has not been revoked (or has been revoked). The specific content of this auxiliary information is not limited in this embodiment.

[0125] In this embodiment, the process of the first device sending a first message to the second device may be that the first device sends a first message to the second device after determining that the identity authentication of the second device is successful based on the address of the second certificate.

[0126] The first message may also carry the address of a third certificate, which is the certificate of the first service node to which the first device belongs. This third certificate is used to authenticate the identity of the first service node. In other words, in addition to carrying group parameters and the identity information of the multiple target devices, the first message may also carry the address of the third certificate.

[0127] The third certificate is stored in the blockchain. Therefore, the address of the third certificate specifically refers to the address of the third certificate on the blockchain, or the location information of the third certificate on the blockchain.

[0128] The address of the third certificate can be obtained during the registration of the first device. The registration process of the first device may include: the first device sending identity verification materials to the first service node (or may also be referred to as the first KGC), which may include at least the identifier of the first device and may be carried in the registration request; upon receiving the identity verification materials of the first device, the first service node reviews the identity verification materials of the first device, and if the review is successful, the first service node generates a private key corresponding to the first device based on its own master private key (e.g., denoted as s) using a key generation algorithm; the first service node sends the private key corresponding to the first device and the address of the third certificate of the first service node to the first device, at which point the registration of the first device is successful.

[0129] Correspondingly, the processing of the second device may also include: authenticating the identity of the first service node based on the address of the third certificate.

[0130] Specifically, authenticating the identity of the first service node based on the address of the third certificate may include: the second device searching for the third certificate on the blockchain based on the location information (or address) of the third certificate; if the third certificate is found and it is determined that the third certificate has not been revoked, the authentication of the first service node is determined to be successful. Alternatively, it may include: if the third certificate is not found and / or it is determined that the third certificate has been revoked, the authentication of the first service node is determined to be unsuccessful.

[0131] Here, the first message may also carry auxiliary information related to the third certificate. The method for determining whether the third certificate has been revoked may include: the second device verifying whether the third certificate has been revoked based on the auxiliary information related to the third certificate and the product of all revoked revocation factors maintained by the certificate issuing node corresponding to the first service node to which the first device belongs, thus obtaining a result indicating whether the third certificate has been revoked. The function of this auxiliary information related to the third certificate is to prove that the third certificate has not been revoked (or has been revoked). The specific content of this auxiliary information is not limited in this embodiment.

[0132] In a preferred example, the timing of the second device authenticating the identity of the first service node based on the address of the third certificate may be before the second device authenticates the multiple target devices based on their authentication values ​​and the group parameters. In an optional example, the timing of the second device authenticating the identity of the first service node based on the address of the third certificate may be after the second device authenticates the multiple target devices based on their authentication values ​​and the group parameters.

[0133] Through the above processing, authentication can be initiated by the second device, and then the first device can act as an agent to generate the identity information of each target device and report it to the second device. The second device can then complete the authentication of multiple target devices based on the identity information of each target device. In the above authentication process, the first device can authenticate the identity of the second device through the address of the second device's second certificate, and the second device can authenticate the identity of the first service node through the address of the third certificate of the first service node to which the first device belongs. This can improve the efficiency of authenticating at least some devices in a group while ensuring the identity authentication of multiple devices and guaranteeing the accuracy of the authentication.

[0134] In some possible implementations, signature-related authentication may also be added between the first device and the second device.

[0135] In this embodiment, the first message also carries a first signature for authenticating the first device. The first signature is calculated based on the private key corresponding to the group parameter.

[0136] The first message may also carry at least one of the following: the identifier of the first device, or the security parameters of the first device. That is, in addition to carrying the first signature, the first message may also carry at least one of the identifier of the first device or the security parameters of the first device.

[0137] The first signature is calculated based on the private key corresponding to the group parameters and at least one of the following parameters: the identifier of the first device, the security parameter of the first device, the identifier of the second device, a first random number, and a second random number. In other words, the first signature is calculated using the private key corresponding to the group parameters and the parameters used to calculate the first signature. The parameters used to calculate the first signature can be at least one of the identifier of the first device, the security parameter of the first device, the identifier of the second device, a first random number, and a second random number.

[0138] The content carried in the first message may be entirely or partially related to the parameters used to calculate the first signature. In one example, the content carried in the first message may be entirely related to the parameters used to calculate the first signature. For instance, the parameters used to calculate the first signature include the identifier of the first device and the security parameters of the first device, and the first message carries both the first signature and the identifier and security parameters of the first device. In another example, the content carried in the first message may be partially related to the parameters used to calculate the first signature. For instance, the parameters used to calculate the first signature may include the identifier of the first device and the security parameters of the first device, but the first message may only carry the security parameters of the first device; or, for example, the parameters used to calculate the first signature may include the security parameters of the first device, but the first message may carry both the identifier and security parameters of the first device. It should be understood that the above are merely illustrative examples. In actual processing, as long as the first message carries at least the security parameters of the first device, and the parameters used to calculate the first signature include at least the security parameters of the first device, it falls within the scope of protection of this embodiment. Not all possible situations are limited or exhaustively listed here.

[0139] Here, the private key corresponding to the group parameter can be pre-configured, meaning the first device can pre-store the private key corresponding to the group parameter. The first device obtains or stores the private key corresponding to the group parameter in the process of acting as a proxy device for multiple devices in the group, assisting each device in the group with registration. For example, the first device's processing may include: the first device receiving the identity verification materials of the m-th device in the group, which may include at least the identifier of the m-th device (e.g., the factory ID of the m-th device); the first device updating the content stored in at least some nodes of the Merkle tree corresponding to the group to which the m-th device belongs, based on the identifier of the m-th device, to obtain an updated Merkle tree; sending the identity verification materials of the m-th device, the identifier of the first device, and the group parameter stored in the root node of the updated Merkle tree to the first service node; and the first device receiving the private key corresponding to the group parameter from the first service node. Here, regarding the method by which the first service node generates the private key corresponding to the group parameters, it can be that the first service node verifies the identity verification materials of the m-th device, the identifier of the first device, and the group parameters stored in the root node of the updated Merkle tree. After the verification is passed, a key generation algorithm is used to generate the private key corresponding to the group parameters. The above describes the registration process for any device in the first device proxy group. The registration process for each device in the same group is the same as that for the m-th device, and will not be elaborated upon. Here, m can be an integer greater than or equal to 1.

[0140] The security parameters of the first device can function as a means to combine with the security parameters of the second device to obtain a session key, which is used for communication between the first and second devices. The security parameters of the first device can also be referred to as key generation parameters, security calculation parameters, etc. In some possible examples, the security parameters of the first device can be represented as the Diffie-Hellman (DH) parameters of the first device.

[0141] The first device calculates the first signature by employing a signature algorithm, based on the private key corresponding to the group parameters and the parameters used to calculate the first signature. The signature algorithm includes at least one of the following: RSA, SM2, JSON Web Signatures (JWS) algorithm, elliptic curve-based signature algorithms, etc. Among them, the SM2 algorithm is a domestically developed algorithm launched by the State Cryptography Administration of China, and is an asymmetric algorithm based on elliptic curves. No exhaustive list or limitation of signature algorithms is provided here.

[0142] The method by which the first device calculates the first signature may include: the first device calculating the first signature based on the private key corresponding to the group parameter and the parameters used to calculate the first signature.

[0143] For example, the parameters used to calculate the first signature may include the identifier of the first device and the DH parameter of the first device; the calculation of the first signature by the first device can be represented as follows: Where Sig() represents the signature algorithm, and Root represents the private key corresponding to the group parameter. Indicates the identifier of the first device. This represents the DH parameters of the first device. In this case, the first signature is generated from the identifier of the first device, and its function is at least to enable the second device to authenticate the first device. Simultaneously, the first signature is generated from the DH parameters of the first device, enabling the second device to authenticate the first device, as well as authenticating the validity and integrity of the DH parameters of the first device. It should be noted that the above is only an illustrative example; with adjustments to actual requirements, in some other possible examples, the parameters used to calculate the first signature may only include the DH parameters of the first device.

[0144] The signature algorithm may include hash calculation and encryption calculation; correspondingly, the first device calculates the first signature based on the private key corresponding to the group parameters using the parameters used to calculate the first signature, which may include: the first device performing a hash calculation on the parameters used to calculate the first signature to obtain a first hash value, and encrypting the first hash value based on the private key corresponding to the group parameters to obtain the first signature. Here, the hash calculation may be SHA (Secure Hash Algorithm), and more specifically, the SHA may be SHA-256. It should be understood that this is only an illustrative example, and in actual processing, any hash calculation algorithm used is within the scope of protection of this embodiment. Not all possible hash calculation algorithms are exhaustively listed or limited here.

[0145] For example, the parameters used to calculate the first signature may include the identifier of the first device and the DH parameter of the first device; the calculation of the first signature by the first device can be represented as follows: Where Sig() represents the signature algorithm, Root represents the private key corresponding to the group parameter, and H() represents the hash calculation. Indicates the identifier of the first device. This indicates the DH parameters of the first device.

[0146] In one embodiment, the processing of the first device may further include receiving at least one of the following from the second device: the first random number, the identifier of the second device.

[0147] When the second device initiates authentication via a third message, at least one of the first random number and the identifier of the second device can be carried in the third message. That is, the third message also carries at least one of the following: the first random number and the identifier of the second device. The first random number can be generated before the second device sends the third message. This embodiment does not limit the method by which the second device generates the first random number.

[0148] In this embodiment, in addition to the identifier of the first device and / or the security parameters of the first device, the parameters used to calculate the first signature may also include at least one of the following: the identifier of the second device, and the first random number.

[0149] For example, the parameters used to calculate the first signature may include the identifier of the first device, the DH parameter of the first device, the identifier of the second device, and the first random number; the calculation of the first signature by the first device can be represented as follows: ,in, Represents the first random number. The identifier for the second device is indicated here. The meanings of the remaining contents in the formula are the same as those in the aforementioned embodiments and will not be repeated.

[0150] For example, the parameters used to calculate the first signature may include the identifier of the first device, the DH parameter of the first device, the identifier of the second device, and the first random number; the calculation of the first signature by the first device can be represented as follows: The meanings of each element in the formula are the same as those in the aforementioned embodiments, and will not be repeated here.

[0151] In one embodiment, the first message may also carry a second random number. This second random number may be generated by the first device before calculating the first signature; however, this embodiment does not limit the method by which the first device generates this second random number.

[0152] In this embodiment, in addition to the identifier and / or security parameters of the first device mentioned above, the parameters used to calculate the first signature may also include the second random number. Alternatively, in addition to the identifier and / or security parameters of the first device mentioned above, the parameters used to calculate the first signature may also include at least one of the following: the identifier of the second device, the first random number, and the second random number.

[0153] For example, the parameters used to calculate the first signature may include the identifier of the first device, the DH parameter of the first device, the identifier of the second device, the first random number, and the second random number; the calculation of the first signature by the first device can be represented as follows: in, The second random number is represented by , and the meaning of the rest of the content in the formula is the same as that in the previous embodiment, and will not be repeated.

[0154] For example, the parameters used to calculate the first signature may include the identifier of the first device, the DH parameter of the first device, the identifier of the second device, the first random number, and the second random number; the calculation of the first signature by the first device can be represented as follows: The meanings of each element in the formula are the same as those in the aforementioned embodiments, and will not be repeated here.

[0155] In this example, by identifying the second device The signature, the identifier of the second device, can serve to enable the second device to determine that the first device has received the third message sent by the second device, or the identifier of the second device can serve to indicate to the second device that the first device has received the third message sent by the second device. The signature ensures that the second device does not perceive the corresponding first message as spam, confirms that the message was sent by the first device, and assures the first device that it has received the third message. When signing the first and second random numbers, these numbers can be fresh values; this freshness ensures the message is not a replay. Signing the security parameters of the first device is to prevent man-in-the-middle attacks inherent in the Diffie-Hellman key exchange protocol itself.

[0156] It should be understood that the above are all exemplary descriptions of calculating the first signature. The calculation method of the first signature is not limited or exhaustively described here, nor are all possible combinations of the parameters used to calculate the first signature. As long as at least one of the parameters used to calculate the first signature is used when actually calculating the first signature, it is within the protection scope of this embodiment.

[0157] After the second device receives the first message carrying the first signature for authenticating the first device, the second device's processing may further include: authenticating the first device based on the group parameters and the first signature.

[0158] The second device's authentication of the first device based on group parameters and the first signature can be performed after the identity authentication of the first service node to which the first device belongs, based on the address of the third certificate, has been successfully completed. Furthermore, the second device's authentication of the first device based on group parameters and the first signature can be performed after the identity authentication of the first service node to which the first device belongs, based on the address of the third certificate, has been successfully completed, and after multiple target devices have been successfully authenticated.

[0159] Specifically, the processing by the second device may include: authenticating the first device based on the group parameter, the first signature, and at least one of the following parameters: the identifier of the first device, the security parameter of the first device, the identifier of the second device, a first random number, and a second random number. Here, the group parameter can be directly used as the public key. At least one of the identifier of the first device, the security parameter of the first device, the identifier of the second device, the first random number, and the second random number can be the parameters used by the second device to verify the first signature. The parameters used to verify the first signature should be the same as the parameters used by the first device to calculate the first signature.

[0160] In one embodiment, the first message further carries at least one of the following: the identifier of the first device, and the security parameters of the first device. The second device can determine the parameters used to verify the first signature based on the first message, and the parameters used to verify the first signature may be wholly or partially related to the first message. In one example, the first message carries only the security parameters of the first device. In this case, the second device may use only the security parameters of the first device as the parameters used to verify the first signature. In another example, the first message carries only the security parameters of the first device. In this case, the second device may have already obtained the identifier of the first device, and then can use both the identifier and the security parameters of the first device as the parameters used to verify the first signature. In another example, the first message carries both the identifier and the security parameters of the first device. The second device may use only the security parameters of the first device as the parameters used to verify the first signature, or the second device may use both the identifier and the security parameters of the first device as the parameters used to verify the first signature. It should be understood that the above is only an illustrative example. In actual processing, as long as the first device and the second device can use the same parameters for verifying the first signature and calculating the parameters for the first signature, it is within the scope of protection of this embodiment. Not all possible situations are limited or exhaustively listed here.

[0161] In one embodiment, the processing before the second device receives the first message further includes: sending a first random number to the first device.

[0162] When the second device initiates authentication via a third message, at least one of the first random number and the identifier of the second device may be carried in the third message. That is, the third message may also carry at least one of the following: the first random number and the identifier of the second device. In this embodiment, the second device can determine the parameters used to verify the first signature based on the third message and the first message. These parameters are wholly or partially related to both the third message and the first message. Specifically, when the third message carries the first random number and the identifier of the second device, the second device, in addition to adding the identifier of the first device and / or the security parameters of the first device to the parameters used to verify the first signature, may also add at least one of the identifier of the second device and the first random number to the parameters used to verify the first signature.

[0163] In one embodiment, the first message may also carry a second random number. In this embodiment, in addition to adding the identifier of the first device and / or the security parameters of the first device to the parameters used to verify the first signature, the second device may also add at least one of the identifier of the second device, the first random number, and the second random number to the parameters used to verify the first signature.

[0164] The authentication of the first device based on the group parameters, the first signature, and at least one of the following parameters: the identifier of the first device, the security parameters of the first device, the identifier of the second device, the first random number, and the second random number, can be: the second device uses a signature verification algorithm to decrypt the first signature based on the group parameters to obtain first decryption information, and authenticates the first device based on the first decryption information and the parameters used to verify the first signature.

[0165] Furthermore, in the above processing, in addition to using the group parameter as a public key to verify the first signature, the master public key of the first service node mentioned in the first device can also be used to verify the first signature together. That is, the second device using the signature verification algorithm to decrypt the first signature based on the group parameter to obtain the first decrypted information can mean that the second device using the signature verification algorithm to decrypt the first signature based on the group parameter and the master public key of the first service node to obtain the first decrypted information. The master public key of the first service node can be stored in the third certificate. In other words, the process of the second device authenticating the first device based on the group parameter and the first signature can be performed after authenticating the identity of the first service node based on the address of the third certificate. The specific processing method for the second device to obtain the third certificate has been described in the foregoing embodiments and will not be repeated here.

[0166] Optionally, the first decryption information may include a first parameter to be verified that has the same content type as the parameters used to verify the first signature; the authentication of the first device based on the first decryption information and the parameters used to verify the first signature may include one of the following: if the first parameter to be verified is the same as the parameters used to verify the first signature, the authentication of the first device is determined to be successful; if the first parameter to be verified is different from the parameters used to verify the first signature, the authentication of the first device is determined to be unsuccessful. In this embodiment, the composition of the parameters used to verify the first signature has been described in detail in the foregoing embodiments and will not be repeated here.

[0167] Optionally, the first decryption information may include a first decryption hash value; authenticating the first device based on the first decryption information and the parameters used to verify the first signature may include: the second device performing a hash calculation on the parameters used to verify the first signature to obtain a first verification hash value; and authenticating the first device based on the first decryption hash value and the first verification hash value.

[0168] Specifically, authenticating the first device based on the first decryption hash value and the first verification hash value may include at least one of the following: if the first decryption hash value and the first verification hash value are the same, the authentication of the first device is determined to be successful; if the first decryption hash value and the first verification hash value are different, the authentication of the first device is determined to be unsuccessful. In this embodiment, the composition of the parameters used to verify the first signature has been detailed in the foregoing embodiments and will not be repeated here.

[0169] In some possible implementations, if the second device successfully authenticates the first device, the processing of the second device may further include: sending a second message to the first device, wherein the second message carries a second signature for authenticating the second device, the second signature being calculated based on the private key of the second device.

[0170] The second signature is calculated based on the private key of the second device and at least one of the following parameters: the identifier of the second device, the security parameter of the second device, the identifier of the first device, a first random number, and a second random number. At least one of the following parameters can also be used to calculate the second signature: the identifier of the second device, the security parameter of the second device, the identifier of the first device, the first random number, and the second random number.

[0171] In this embodiment, the second message also carries at least one of the following: the identifier of the second device, and the security parameters of the second device.

[0172] The content carried in the second message can be entirely or partially related to the parameters used to calculate the second signature. In one example, the content carried in the second message can be entirely related to the parameters used to calculate the second signature. For instance, the parameters for calculating the second signature include the identifier of the second device and the security parameters of the second device. In addition to carrying the second signature, the second message also carries the identifier and security parameters of the second device. In another example, the content carried in the second message can be partially related to the parameters used to calculate the second signature. For instance, the parameters for calculating the second signature may include the identifier of the second device and the security parameters of the second device, but the second message may only carry the security parameters of the second device. Or, the parameters for calculating the second signature may include the security parameters of the first device, but the second message may carry the identifier and security parameters of the second device. It should be understood that the above are merely illustrative examples. In actual processing, as long as the second message carries at least the security parameters of the second device, and the parameters for calculating the second signature include at least the security parameters of the second device, it falls within the protection scope of this embodiment. Not all possible situations are limited or exhaustively listed here.

[0173] Here, the private key of the second device can be pre-configured, that is, the private key of the second device can be stored in advance.

[0174] Optionally, the parameters for calculating the second signature may include security parameters of the second device. These security parameters of the second device are used in conjunction with the security parameters of the first device to obtain a session key, which is used for communication between the first and second devices.

[0175] The process of the second device calculating the second signature may include: the second device using a signature algorithm to calculate the second signature based on the second device's private key and security parameters. The description of this signature algorithm is similar to that of the previous embodiments and will not be repeated. For example, the calculation of the second signature by the second device can be represented as follows: Where Sig() represents the signature algorithm, and D represents the private key of the second device. This indicates the DH parameters of the second device.

[0176] The second device employs a signature algorithm to calculate the second signature based on its private key and the device's security parameters. This calculation may include: the second device using the signature algorithm to perform a hash calculation on its security parameters to obtain a second hash value, and then encrypting the second hash value using its private key to obtain the second signature. For example, the calculation of the second signature by the second device could be represented as follows: In this formula, H() represents hash calculation. The meanings of other contents are the same as in the previous embodiments and will not be repeated.

[0177] Optionally, the parameters for calculating the second signature may include security parameters of the second device and the identifier of the second device.

[0178] The process of the second device calculating the second signature may include: the second device using a signature algorithm to calculate the second signature based on the second device's private key, security parameters, and identifier. The description of this signature algorithm is similar to that of the previous embodiments and will not be repeated. For example, the calculation of the second signature by the second device can be represented as follows: Where Sig() represents the signature algorithm, The identifier for the second device is indicated here. The meanings of other contents in the formula are the same as those in the aforementioned embodiments and will not be repeated here.

[0179] The second device employs a signature algorithm to calculate the second signature based on its private key, security parameters, and identifier. This calculation may include: the second device using the signature algorithm to perform a hash calculation on its security parameters and identifier to obtain a second hash value; and then encrypting the second hash value using its private key to obtain the second signature. For example, the calculation of the second signature by the second device could be represented as follows: The meanings of each item in the formula are the same as those in the aforementioned embodiments, and will not be repeated here.

[0180] In one embodiment, the parameters for calculating the second signature may include, in addition to at least one of the security parameters of the second device and the identifier of the second device, at least one of the following: the identifier of the first device, a first random number, and a second random number. The identifier of the first device and the second random number may be carried in a first message sent by the first device; the first random number is generated by the second device and sent to the first device.

[0181] Optionally, the parameters for calculating the second signature may include security parameters of the second device and the identifier of the first device.

[0182] The process of the second device calculating the second signature may include: the second device using a signature algorithm to calculate the second signature based on the second device's private key, the second device's security parameters, and the first device's identifier. For example, the calculation of the second signature by the second device can be represented as follows: ,in, The identifier of the first device is indicated here. The meanings of other contents in the formula are the same as those in the aforementioned embodiments and will not be repeated here.

[0183] The second device employs a signature algorithm to calculate the second signature based on its private key, using the security parameters of the second device and the identifier of the first device. This can include: the second device using the signature algorithm to perform a hash calculation on the security parameters of the second device and the identifier of the first device to obtain a second hash value, and then encrypting the second hash value based on its private key to obtain the second signature. For example, the calculation of the second signature by the second device can be represented as follows: The meanings of each element in the formula are the same as in the aforementioned embodiments, and will not be repeated here.

[0184] Optionally, the parameters for calculating the second signature may include the security parameters of the second device, the identifier of the second device, the identifier of the first device, and a second random number.

[0185] The process of the second device calculating the second signature may include: the second device using a signature algorithm to calculate the second signature based on the second device's security parameters, the second device's identifier, the first device's identifier, and a second random number using the second device's private key. The description of this signature algorithm is similar to that of the aforementioned embodiments and will not be repeated. For example, the calculation of the second signature by the second device can be represented as follows: Where Sig() represents the signature algorithm, This represents the second random number. The meanings of other contents in the formula are the same as in the aforementioned embodiments, and will not be repeated here.

[0186] The second device employs a signature algorithm to calculate the second signature based on its private key, security parameters, identifier, first device identifier, and a second random number. This can include: the second device using the signature algorithm to perform a hash calculation on the security parameters, identifier, first device identifier, and second random number to obtain a second hash value; and encrypting the second hash value using its private key to obtain the second signature. For example, the calculation of the second signature by the second device can be represented as follows: The meanings of each item in the formula are the same as those in the aforementioned embodiments, and will not be repeated here.

[0187] It should be understood that the above are merely exemplary descriptions of calculating the second signature. The calculation method of the second signature is not limited or exhaustively described here, nor are all possible combinations of the parameters for calculating the second signature limited or exhaustively described. As long as at least one of the parameters for calculating the second signature is used when actually calculating the second signature, it is within the protection scope of this embodiment.

[0188] In some possible implementations, the processing of the first device may include: receiving a second message from the second device, wherein the second message carries a second signature for authenticating the second device; and authenticating the second device based on the public key associated with the second device and the second signature.

[0189] Optionally, the second device can implicitly indicate to the first device that the authentication result for the first device is successful by carrying a second signature for authenticating the second device in the second message. That is, upon receiving the second message carrying the second signature for authenticating the second device, the first device can determine that the authentication result for the first device by the second device is successful.

[0190] Optionally, the second device may indicate to the first device that the authentication result for the first device is successful by indicating in the second message that the authentication result for the first device is successful.

[0191] Additionally, the process may include: if the second device fails to authenticate the first device, the second device's processing may include: sending a group response message to the first device, the group response message carrying an indication that the authentication result for the first device was authentication failure. Correspondingly, the first device's processing may include: receiving a group response message from the second device. Furthermore, the first device's processing may also include: terminating the process if the group response message indicates that the authentication result for the first device was authentication failure.

[0192] Specifically, authenticating the second device based on the public key associated with the second device and the second signature includes: authenticating the second device based on the public key associated with the second device, the second signature, and at least one of the following parameters: the identifier of the second device, the security parameters of the second device, the identifier of the first device, a first random number, and a second random number. On the first device side, the identifier of the second device, the security parameters of the second device, the identifier of the first device, the first random number, and the second random number can be referred to as parameters for verifying the second signature. The parameters for verifying the second signature should be the same as the parameters used by the second device to calculate the second signature.

[0193] Here, the public key associated with the second device refers to the public key of the second device. Specifically, the public key associated with the second device is the public key of the second device stored in the second certificate. The method for obtaining the second certificate has been described in detail in the foregoing embodiments and will not be repeated here.

[0194] In one embodiment, the second message also carries at least one of the following: the identifier of the second device, and security parameters of the second device.

[0195] The first device can determine parameters for verifying the second signature based on the second message. These parameters may be wholly or partially related to the second message. In one example, the second message carries only the security parameters of the second device. In this case, the first device can use only the security parameters of the second device as the parameters for verifying the second signature. In another example, the second message carries only the security parameters of the first device. In this case, the first device may have already obtained the identifier of the second device and can then use both the identifier and the security parameters of the second device as the parameters for verifying the second signature. In yet another example, the second message carries both the identifier and the security parameters of the second device. The first device can use only the security parameters of the second device as the parameters for verifying the second signature, or it can use both the identifier and the security parameters of the second device as the parameters for verifying the second signature. It should be understood that the above are merely illustrative examples. In actual processing, as long as the first device and the second device can use the same parameters for verifying the second signature and calculating the parameters for the second signature, it falls within the scope of protection of this embodiment. Not all possible situations are limited or exhaustively listed here.

[0196] In one embodiment, the parameters for verifying the second signature may include, in addition to at least one of the security parameters of the second device and the identifier of the second device, at least one of the following: the identifier of the first device, a first random number, and a second random number. The identifier of the first device and the second random number may be carried in a first message sent by the first device, and the first random number is sent by the first device to the second device. Therefore, both the first device and the second device can obtain the identifier of the first device, the first random number, and the second random number.

[0197] In one embodiment, the first device uses a signature verification algorithm to decrypt the second signature based on the public key of the second device to obtain second decrypted information, and authenticates the second device based on the second decrypted information and the parameters for verifying the second signature.

[0198] Optionally, the second decryption information may include second parameters to be verified that are of the same content type as those in the parameters for verifying the second signature; the authentication of the second device based on the second decryption information and the parameters for verifying the second signature may include one of the following: if the second parameters to be verified and the parameters for verifying the second signature are the same, the authentication of the second device is determined to be successful; if the second parameters to be verified and the parameters for verifying the second signature are different, the authentication of the second device is determined to be unsuccessful. In this embodiment, the composition of the parameters for verifying the second signature has been described in detail in the foregoing embodiments and will not be repeated here.

[0199] Optionally, the second decryption information may include a second decryption hash value; authenticating the second device based on the second decryption information and the parameters for verifying the second signature may include: the first device performing a hash calculation on the parameters for verifying the second signature to obtain a second verification hash value; and authenticating the second device based on the second decryption hash value and the second verification hash value.

[0200] Specifically, authenticating the second device based on the second decryption hash value and the second verification hash value may include at least one of the following: if the second decryption hash value and the second verification hash value are the same, the authentication of the second device is determined to be successful; if the second decryption hash value and the second verification hash value are different, the authentication of the second device is determined to be unsuccessful. In this embodiment, the composition of the parameters for verifying the second signature has been detailed in the foregoing embodiments and will not be repeated here.

[0201] Optionally, if the first device determines that authentication of the second device has failed, the processing of the first device may further include: the first device ending the processing, or the first device sending an indication to the second device that authentication of the second device has failed.

[0202] Optionally, if the first device determines that the authentication of the second device is successful, the processing of the first device may further include: the first device sending an indication to the second device that the authentication of the second device is successful.

[0203] In some possible implementations, before authenticating the second device based on the public key associated with the second device and the second signature, the processing of the first device may further include: verifying whether the second device has been revoked based on the identifier of the second device carried in the second message.

[0204] Verifying whether the second device has been revoked based on the identifier of the second device carried in the second message can refer to: the first device searching for the status of the identifier of the second device on the blockchain; if the status corresponding to the identifier of the second device stored on the blockchain is "not revoked," then the second device is determined not to have been revoked; otherwise, the second device is determined to have been revoked. Furthermore, if it is determined that the second device has not been revoked, the first device can continue to perform subsequent processing to authenticate the second device based on the public key and the second signature related to the second device, which will not be repeated here.

[0205] In some possible implementations, the first device and the second device may also complete the negotiation of the session key simultaneously during the authentication process.

[0206] If the first device determines that the authentication of the second device is successful, the processing of the first device may further include: calculating a session key based on the security parameters of the second device and the security parameters of the first device, wherein the session key is used for communication between the first device and the second device.

[0207] It should also be noted that, if the second device successfully authenticates the first device, the processing of the second device may further include: calculating a session key based on the security parameters of the second device and the security parameters of the first device, wherein the session key is used for communication between the first device and the second device.

[0208] In some possible implementations, authentication can also be initiated by the first device (i.e., the proxy device) to the second device (i.e., the authentication function entity).

[0209] The first device can determine whether it is necessary to initiate authentication of multiple target devices based on the configuration information. The configuration information may include: one or more authentication times, the identifiers of multiple devices to be authenticated corresponding to each authentication time, etc. The possible contents of the configuration information are not limited or exhaustively listed here. As long as the first device can initiate authentication of multiple target devices at a certain time, it is within the protection scope of this embodiment.

[0210] In one embodiment, the first message sent by the first device can also be used to trigger a process for authenticating multiple target devices.

[0211] The first message may carry group parameters and the identity information of multiple target devices. The descriptions of the group parameters, the identity information of the multiple target devices, and the group information stored by the first device are the same as in the previous embodiments and will not be repeated. Additionally, in this embodiment, the first message may also carry the identifiers of the multiple target devices.

[0212] The processing by the second device after receiving the first message may include: calculating the authentication value of the multiple target devices based on the identifier of each target device and one or more parameter values ​​corresponding to each target device contained in the identity information of the multiple target devices; and authenticating the multiple target devices based on the authentication value of the multiple target devices and the group parameter. The related processing for the second device to authenticate multiple target devices is the same as in the aforementioned embodiments, and therefore will not be described in detail.

[0213] In one embodiment, certificate authentication is still required between the first device and the second device.

[0214] The first device can carry the address of a third certificate in the first message. This third certificate is the certificate of the first service node to which the first device belongs, and it is used to authenticate the identity of the first service node. That is, in addition to carrying group parameters and the identity information of the multiple target devices, the first message can also carry the address of the third certificate. The relevant descriptions of this third certificate are the same as in the previous embodiments and will not be repeated.

[0215] Accordingly, after receiving the first message, the second device can authenticate the identity of the first service node based on the address of the third certificate. The process of the second device authenticating the identity of the first service node is the same as in the previous embodiment and will not be described again.

[0216] In one embodiment, the processing of the second device further includes: sending the address of a second certificate to the first device, wherein the second certificate is a certificate of the second device. In the processing of the first device, the method further includes: receiving the address of a second certificate from the second device, wherein the second certificate is a certificate of the second device.

[0217] Since this embodiment uses the first device as the authentication initiator, it differs from the aforementioned implementations in that, after successfully authenticating the identity of the first service node and the plurality of target devices, the second device can include the address of the second certificate in its second message. The processing of the first device authenticating the identity of the second device based on the address of the second certificate is the same as in the aforementioned embodiments and will not be described again.

[0218] In one embodiment, signature authentication is still required between the first device and the second device.

[0219] Unlike the aforementioned implementation, the first device, as the authentication initiator, first carries a first signature for authenticating the first device in the first message it sends.

[0220] Unlike the aforementioned embodiments, in this embodiment, the parameters used to calculate the first signature may include, in addition to at least one of the identifier of the first device and the security parameters of the first device, a second random number generated by the first device. This is because in this embodiment, authentication is initiated by the first device, and therefore the first random number generated by the second device cannot be obtained before authentication is initiated. Alternatively, in this embodiment, the parameters used to calculate the first signature may include, in addition to the identifier of the first device and the security parameters of the first device, a second random number generated by the first device and the identifier of the second device. This is because in this embodiment, authentication is initiated by the first device, and therefore the first random number generated by the second device cannot be obtained before authentication is initiated. However, the first device needs to initiate authentication with the second device, so it may have already stored the identifier of the second device locally. Therefore, the parameters used to calculate the first signature may include the identifier of the second device.

[0221] Except for the parameters used to calculate the first signature, which may differ from those in the previous embodiments, the specific method by which the first device calculates the first signature is the same as in the previous embodiments and will not be repeated here.

[0222] After the second device receives the first message carrying the first signature for authenticating the first device, the second device's processing may further include: authenticating the first device based on the group parameters and the first signature. The only difference between the second device's processing and the previous embodiment is that the composition of the parameters used to verify the first signature may change. Since the parameters used to verify the first signature should be the same as those used to calculate the first signature, they will not be repeated here. Other processing steps for the second device to verify the first signature (i.e., authenticating the first device based on the first signature) are the same as in the previous embodiment and will not be elaborated upon.

[0223] If the second device successfully authenticates the first device, the second device can perform the following processing: sending a second message to the first device, wherein the second message carries a second signature for authenticating the second device, the second signature being calculated based on the private key of the second device. Correspondingly, the first device's processing can include: receiving a second message from the second device, wherein the second message carries a second signature for authenticating the second device; and authenticating the second device based on the public key associated with the second device and the second signature.

[0224] On the second device side, the calculation method for the second signature is the same as in the aforementioned embodiment. In this embodiment, the parameters for calculating the second signature include, in addition to at least one of the identifier of the second device and the security parameters of the second device, at least one of the following: the identifier of the first device, a first random number, and a second random number.

[0225] Unlike the aforementioned implementation, the processing by the second device after receiving the first message further includes sending at least one of the following to the first device: a first random number and the identifier of the second device. Specifically, when the first device initiates authentication via the first message, at least one of the first random number and the identifier of the second device may be sent to the first device along with the second signature in the second message.

[0226] The specific processing method for the second device to calculate the second signature is the same as in the previous embodiments, and the processing method for the first device to authenticate the second device based on the second signature is also the same as in the previous embodiments, so it will not be described again.

[0227] In this embodiment, the first device and the second device can also complete the negotiation of the session key during the authentication process. The specific processing is the same as in the previous embodiments and will not be described in detail.

[0228] Combination Figure 5 Taking the first device as the proxy device and the second device as the authentication function entity as an example, the above authentication method is illustrated by way of example. Figure 5 The scenario addressed is as follows: Any zero-power device defaults to an IBC (Identity-Based Cryptograph) cryptographic system, while the proxy device defaults to a Public Key Infrastructure (PKI) system (acting as a light node in a two-layer architecture, with registration and credential verification consistent with the KGC). During the bidirectional authentication process between the authentication entity and multiple zero-power devices (i.e., the multiple target devices in the aforementioned embodiments), the multiple zero-power devices fully entrust the proxy device to assist them in completing the authentication process. The proxy device and the multiple zero-power devices it proxies are both within the IBC cryptographic system and belong to the same trust domain. The proxy device can be an ordinary zero-power device with computing power. Therefore, the proxy device needs to provide the authentication entity with its own KGC certificate to prove the legitimacy of its identity and the identity of the zero-power devices it proxies, and the authentication entity needs to provide its own certificate to prove the legitimacy of its identity. Assume the authentication entity wants to authenticate with multiple zero-power devices (e.g., the identifiers of the multiple zero-power devices are...). In communication, multiple zero-power devices entrust an agent device (belonging to the same trust domain as the multiple zero-power devices) to help them complete identity authentication. Figure 5 The processing flow of the authentication method shown may include the following steps:

[0229] Step 501: The authentication entity displays the location information of its second certificate on the blockchain. ), First random number ( ), Identifier of the authentication function entity ( ) and the identifiers of the multiple target devices to be communicated with ( Together they are sent to the agent device in plaintext.

[0230] In this step, the information sent by the authentication entity to the proxy device can be carried by the third message in the aforementioned embodiments; assuming the authentication entity is represented as D and the proxy device as A, the information sent by the authentication entity to the proxy device can be represented as: .

[0231] Step 502: After receiving the information from the authentication entity, the agent device searches for the second certificate on the blockchain and verifies whether the second certificate has been revoked. If the second certificate is found and has not been revoked, the authentication of the authentication entity is considered successful, and then step 503 is executed. Alternatively, if the second certificate is not found and / or has been revoked, the authentication of the authentication entity is considered to have failed, and the process ends.

[0232] Step 503: The proxy device sends the address of the third certificate of the KGC (i.e., the first service node) to which the proxy device belongs on the chain to the authentication function entity. ), the identification of the agency equipment ( ), joint identity (i.e., group parameters), second random number ( Session keys negotiated using the DH protocol (i.e., the DH parameters of the proxy device), first signature Sig Root (H(N D N A ID D ID A ,X A ·P)) Multiple zero-power devices belong to a joint identity The proof message (i.e., identity information).

[0233] The first signature can be obtained using a joint identity. The corresponding private key is used to identify the proxy device. ), second random number ( Session keys negotiated using the DH protocol Identifier of the authentication function entity ( ), First random number ( This is calculated using the first random number (or freshness value). The purpose of the signature is to enable the authentication entity to verify that it has received a message that is not a replay but indeed originates from the proxy device, thus identifying the authentication entity. The signature indicates that the agent device has received the information from step 501 from the authentication function entity.

[0234] In this step, the information sent by the proxy device to the authentication function entity can be carried by the first message in the aforementioned embodiment, combined with... Figure 4a and Figure 4b The identifiers of the multiple zero-power devices in the aforementioned embodiments are as follows: For example, the content carried by this first message can be represented as follows:

[0235] .

[0236] Step 504: After receiving the information from the agent device, the authentication entity searches for the third-party certificate on the blockchain. Verify whether the third-party certificate has been revoked, verify the identity of each zero-power device, and verify the joint identity on the blockchain. Whether it has been revoked, and verify the first signature.

[0237] Specifically, a third certificate is found on the blockchain of the authentication function entity. If the third-party certificate has not been revoked, verify the identity of each zero-power device; if the authentication of each zero-power device is successful, verify the joint identity on the blockchain. Whether it has been revoked; in determining joint status Use without cancellation Verify the authenticity of the first signature. Further, if the first signature verification is successful, i.e., the authentication of the agent device is successful, step 505 can be executed. Additionally, it may also include: the authentication function entity is prepared to perform a search for a third certificate if the link fails. The third certificate was revoked, and joint identity was determined. If at least one of the following conditions is met—revocation or failure to verify the first signature—processing ends.

[0238] Step 505: The authentication function entity will use the identifier of the authentication function entity. Session key negotiated using the DH protocol The second signature is sent to the agent device.

[0239] The second signature can be an identifier of the authentication entity using the private key of the authentication entity. Session key negotiated using the DH protocol Identification of the agency equipment ( ), second random number ( This is calculated. Here, we use... Signing is used to enable the authentication entity and the proxy device to negotiate the session key; the second random number (or fresh value) is used. The purpose of signing is to allow the agent device to verify that it has received a message that is not a replay but indeed from the authentication entity. The signature indicates that the authentication entity has received the first message from the agent device.

[0240] In this step, the information sent by the authentication function entity to the proxy device can be carried by the second message in the aforementioned embodiment; assuming the authentication function entity is represented as D and the proxy device as A, the information sent by the authentication function entity to the proxy device can be represented as: .

[0241] Step 506: After receiving the information from the authentication entity, the agent device verifies whether the identity of the authentication entity has been revoked. If it has not been revoked, it uses the public key in the second certificate of the authentication entity to verify the second signature.

[0242] Step 507: Once the agent device has completed the authentication of the authentication function entity, it begins communication with the authentication function entity.

[0243] exist Figure 5 The example provided addresses a scenario where authentication is initiated by the authentication function entity. To address a scenario where authentication is initiated by a proxy device, the aforementioned... Figure 5 The specific steps can be adaptively replaced or adjusted. For example, steps 501 and 502 can be deleted (i.e., steps 501 and 502 are not executed); in step 503, the proxy device sends the address of the third certificate of the KGC (i.e., the first service node) to which the proxy device belongs (on the chain) to the authentication function entity. ), the identification of the agency equipment ( ), joint identity (i.e., group parameters), second random number ( Session keys negotiated using the DH protocol (i.e., the DH parameters of the proxy device), identifiers of multiple zero-power devices, and the first signature Sig Root (H(N A ID D ID A ,X A ·P)) Multiple zero-power devices belong to a joint identity The authentication message (i.e., identity information). Step 504 remains unchanged. Step 505: The authentication entity will use the authentication entity's identifier. Session key negotiated using the DH protocol The location information of your second certificate on the blockchain ( ), First random number ( ), second signature ( The message is sent to the proxy device. Step 506: After receiving the information from the authentication entity, the proxy device searches for the second certificate on the blockchain and verifies whether it has been revoked. If the second certificate is found and has not been revoked, the authentication of the authentication entity is confirmed as successful. Then, it verifies whether the authentication entity's identity has been revoked. If not, it uses the public key in the authentication entity's second certificate to verify the second signature. Step 507 remains unchanged.

[0244] In some possible implementations, the second device may be one of the following types: a terminal, an Internet of Things (IoT) device, or a zero-power device.

[0245] In this embodiment, the second device and the target device can be of the same type. For example, the second device can be an IoT device, and the multiple target devices can be multiple IoT devices different from the second device. Alternatively, the second device and the target devices can be of different types. For example, the second device can be an IoT device, and the multiple target devices can be multiple zero-power devices. Or, for example, the second device can be a terminal, and the multiple target devices can be multiple zero-power devices (or multiple IoT devices). This embodiment does not exhaustively list or limit all possible types of the second device and the target devices.

[0246] In this situation, there are two possible scenarios: one is that the second device (e.g., an IoT device, or a zero-power device, etc.) belongs to different trust domains as the target devices; the other is that the second device (e.g., an IoT device, or a zero-power device, etc.) belongs to the same trust domain as the target devices. These two scenarios will be explained below.

[0247] In some embodiments, the second device (e.g., an IoT device, or a zero-power device, etc.) belongs to different trust domains as well as multiple target devices, while the multiple target devices belong to the same trust domain as the first device. In this embodiment, multiple target devices belonging to the same trust domain as the first device can mean that the multiple target devices and the first device belong to the same service node, which is the first service node; the second device belonging to different trust domains as the multiple target devices can mean that the second device and the first device (and the multiple target devices) belong to different trust domains, and the service node to which the second device belongs can be the second service node, which is different from the first service node.

[0248] In this embodiment, the second device remains the one initiating authentication. The second device can send a third message to the first device when it needs to communicate with multiple target devices belonging to different trust domains. The method by which the second device selects multiple target devices is the same as in the previous embodiments and will not be repeated.

[0249] In one embodiment, the third message carries at least the identifiers of multiple target devices. Accordingly, after receiving the third message sent by the second device, the first device obtains the group parameters corresponding to the group to which the multiple target devices belong, and obtains the identity information of the multiple target devices based on the identifier of each target device; it then sends a first message to the second device, which carries the group parameters and the identity information of the multiple target devices.

[0250] The identity information of the multiple target devices includes the identifier of each target device and one or more parameter values ​​corresponding to each target device, wherein the one or more parameter values ​​corresponding to each target device are determined based on group information. The relevant explanations regarding group information, group parameters, and the method by which the first device obtains its identity information are the same as in the aforementioned implementation method, and therefore will not be repeated.

[0251] In some embodiments, the first message may carry group parameters and the identity information of the plurality of target devices. Accordingly, the processing performed by the second device after receiving the first message may include: calculating the authentication value of the plurality of target devices based on the identifier of each target device and one or more parameter values ​​corresponding to each target device contained in the identity information of the plurality of target devices; and authenticating the plurality of target devices based on the authentication value of the plurality of target devices and the group parameters.

[0252] The process of the second device calculating the authentication value of the multiple target devices based on the identifier of each target device and one or more parameter values ​​corresponding to each target device contained in the identity information of the multiple target devices, and authenticating the multiple target devices based on the authentication value of the multiple target devices and the group parameter, is the same as the aforementioned implementation method, and therefore will not be described again.

[0253] Optionally, the second device has on-chain capability. After receiving the first message, the second device may further include: extracting group parameters from the first message; and checking whether the group parameters have been revoked on the blockchain. The process of checking whether the group parameters have been revoked on the blockchain is the same as in the aforementioned implementation and will not be repeated.

[0254] Optionally, the second device does not have on-chain capability. After receiving the first message, the second device may further include: extracting group parameters from the first message; sending the group parameters to the third device; correspondingly, the processing of the third device may include: receiving the group parameters from the second device and checking on the chain whether the group parameters have been revoked.

[0255] The third device can be a proxy device corresponding to the second device. The type of the third device can be a terminal or an access network device. The third device can be the same as or different from the first device; this embodiment does not limit its type. The process of the third device checking whether the group parameters have been revoked is similar to the aforementioned implementation and will not be repeated.

[0256] Through the above processing, authentication of multiple target devices across different trust domains can be initiated by a second device (any IoT device or zero-power device). The first device then generates identity information for each target device and reports it to the second device, which completes the authentication process for all target devices based on this identity information. This improves the efficiency of zero-power devices authenticating a group of target devices in cross-domain scenarios.

[0257] In some possible implementations, certificate-related authentication may also be added between the first device and the second device.

[0258] The processing of the second device further includes: sending the address of the first certificate to the first device, wherein the first certificate is the certificate of the second service node to which the second device belongs. The processing of the first device may also include: receiving the address of the first certificate from the second device, wherein the first certificate is the certificate of the second service node to which the second device belongs.

[0259] Since authentication is initiated by the second device in this implementation, the address of the first certificate can be carried in the third message; that is, the third message also carries the address of the first certificate. The first certificate is stored in the blockchain; therefore, the address of the first certificate specifically refers to its address on the blockchain, or its location information on the blockchain. In other words, when the second device initiates the authentication process, the second device (i.e., any IoT device or zero-power device) sends the address of its own second service node's first certificate and the identifier of each of the multiple target devices in the third message to the first device.

[0260] The address of the first certificate can be obtained during the registration of the second device. Taking the second device as an IoT device as an example, the registration process of the IoT device may include: the IoT device sending identity verification materials to its affiliated service node (in this embodiment, it can be the second service node, or the second KGC). The identity verification materials include at least the identifier of the IoT device, which may include at least one of the following: a factory-unique identifier, an identifier issued by the operator, or an identifier issued by the service provider; after receiving the identity verification materials submitted by the IoT device, the service node reviews them. If the review is successful, the service node uses its own master private key s to generate a private key (e.g., represented as sk) corresponding to the identity (i.e., identifier) ​​of the IoT device using a key generation algorithm. A The service node will store the private key (sk) corresponding to the IoT device. A The service node's certificate address on the blockchain is sent to the IoT device, thus successfully registering the IoT device. In other words, through the registration process, the IoT device obtains its own private key and the address of its affiliated service node's certificate.

[0261] Accordingly, the processing of the first device may also include: authenticating the identity of the second service node based on the address of the first certificate.

[0262] Specifically, authenticating the identity of the second service node based on the address of the first certificate may include: the first device searching for the first certificate on the blockchain based on the location information (or address) of the first certificate; if the first certificate is found and it is determined that the first certificate has not been revoked, the identity authentication of the second service node is determined to be successful. Alternatively, it may include: if the first certificate is not found and / or it is determined that the first certificate has been revoked, the identity authentication of the second service node is determined to be unsuccessful.

[0263] Here, in the processing of the first device, the method further includes: receiving auxiliary information related to the first certificate from the second device. This auxiliary information related to the first certificate can also be carried in a third message; that is, the third message can also carry the auxiliary information related to the first certificate. The method for determining whether the first certificate has been revoked can include: the first device verifying whether the first certificate has been revoked based on the auxiliary information related to the first certificate and the product of all revoked revocation factors maintained by the certificate issuing node corresponding to the second service node, thereby obtaining a result indicating whether the first certificate has been revoked.

[0264] In this embodiment, the process of the first device sending a first message to the second device may be that the first device sends a first message to the second device after determining that the identity authentication of the second service node is successful based on the address of the first certificate.

[0265] The first message may also carry the address of a third certificate, which is the certificate of the first service node to which the first device belongs. This third certificate is used to authenticate the identity of the first service node. In other words, in addition to carrying group parameters and the identity information of the multiple target devices, the first message may also carry the address of the third certificate.

[0266] The third certificate is stored in the blockchain. Therefore, the address of the third certificate specifically refers to its address on the blockchain, or its location information on the blockchain. The address of the third certificate can be obtained during the registration of the first device. The registration process for the first device is the same as in the previous embodiments and will not be repeated.

[0267] In one embodiment, the second device has on-chain capability, and the processing after the second device receives the address of the third certificate may further include: authenticating the identity of the first service node based on the address of the third certificate. In this embodiment, the description of the second device authenticating the identity of the first service node based on the address of the third certificate is the same as in the previous embodiments and will not be repeated.

[0268] In one embodiment, the second device does not have on-chain capability. The processing after the second device receives the address of the third certificate may further include: the second device sending the address of the third certificate to the third device, and receiving the authentication result of the first service node sent by the third device. Correspondingly, the processing of the third device may include: receiving the address of the third certificate from the second device; authenticating the identity of the first service node based on the address of the third certificate; and sending the authentication result of the first service node to the second device. Here, the processing of the third device authenticating the identity of the first service node based on the address of the third certificate is similar to the relevant description in the foregoing embodiments, only replaced by execution by the third device, and therefore will not be repeated.

[0269] Through the above processing, authentication can be initiated by a second device (any IoT device or zero-power device), and then the first device can generate identity information for each target device and report it to the second device. The second device can then complete the authentication of multiple target devices based on the identity information of each target device. In the above authentication process, the first device can authenticate the identity of the second service node by using the address of the first certificate of the second service node to which the second device belongs, and the second device can authenticate the identity of the first service node by using the address of the third certificate of the first service node to which the first device belongs. This can improve the efficiency of authenticating at least some devices in a group while ensuring the identity authentication of multiple devices and guaranteeing the accuracy of the authentication.

[0270] In some possible implementations, signature-related authentication can be added between the first device and the second device (either an IoT device or a zero-power device), and session key negotiation can be completed simultaneously.

[0271] In this embodiment, the first message also carries a first signature for authenticating the first device. The calculation method for the first signature is the same as in the previous embodiments.

[0272] The parameters used to calculate the first signature may include at least one of the following: the identifier of the first device, and the security parameters of the first device.

[0273] In one embodiment, the first message may further carry at least one of the following: the identifier of the first device, and the security parameters of the first device. That is, in addition to carrying the first signature, the first message may also carry at least one of the identifier of the first device and the security parameters of the first device. The content carried in the first message may be entirely or partially related to the parameters used to calculate the first signature; the related descriptions are the same as in the previous embodiments and will not be repeated. The descriptions of the security parameters of the first device and the private key corresponding to the group parameters are the same as in the previous embodiments and will not be repeated.

[0274] In one embodiment, the processing of the first device may further include receiving at least one of the following from the second device: the first random number and the identifier of the second device. When the second device initiates authentication via a third message, at least one of the first random number and the identifier of the second device may be carried by the third message; that is, the third message may also carry at least one of the following: the first random number and the identifier of the second device. The first random number may be generated before the second device sends the third message; this embodiment does not limit the method by which the second device generates the first random number. In this embodiment, in addition to the identifier of the first device and / or the security parameters of the first device, the parameters used to calculate the first signature may also include at least one of the following: the identifier of the second device and the first random number.

[0275] In one embodiment, the first message may also carry a second random number. The second random number may be generated by the first device before calculating the first signature or sending the first message. This embodiment does not limit the method by which the first device generates the second random number. In this embodiment, the parameters used to calculate the first signature, in addition to the aforementioned identifier and / or security parameters of the first device, may also include the second random number. Alternatively, the parameters used to calculate the first signature, in addition to the aforementioned identifier and / or security parameters of the first device, may also include at least one of the following: the identifier of the second device, the first random number, and the second random number.

[0276] The descriptions regarding the calculation of the first signature by the first device are the same as those provided in the foregoing embodiments, and will not be repeated here.

[0277] After receiving the first message carrying the first signature for authenticating the first device, the second device's processing may further include: authenticating the first device based on the group parameters and the first signature. The timing and specific processing method of the second device authenticating the first device based on the group parameters and the first signature are the same as in the foregoing embodiments and will not be repeated here.

[0278] In some possible implementations, if the second device successfully authenticates the first device, the processing of the second device may further include: sending a second message to the first device, wherein the second message carries a second signature for authenticating the second device, the second signature being calculated based on the private key of the second device.

[0279] In one embodiment, the parameters for calculating the second signature may include at least one of the following: the identifier of the second device, and the security parameters of the second device. In this embodiment, the second message also carries at least one of the following: the identifier of the second device, and the security parameters of the second device. The descriptions regarding the second message and the parameters for calculating the second signature are the same as in the previous embodiments and will not be repeated here.

[0280] Here, the private key of the second device can be pre-configured, meaning that the private key of the second device can be stored in advance. The private key of the second device can be obtained during the registration of the second device. The registration process of the second device has been described in detail in the foregoing embodiments and will not be repeated here.

[0281] In one embodiment, the parameters for calculating the second signature may include, in addition to at least one of the security parameters of the second device and the identifier of the second device, at least one of the following: the identifier of the first device, a first random number, and a second random number. The identifier of the first device and the second random number may be carried in a first message sent by the first device; the first random number is generated by the second device and sent to the first device.

[0282] The descriptions of various possible examples of the second device calculating the second signature are the same as those of the aforementioned implementation methods, and therefore will not be repeated.

[0283] In some possible implementations, the processing of the first device may include: receiving a second message from the second device, wherein the second message carries a second signature for authenticating the second device; and authenticating the second device based on the public key associated with the second device and the second signature.

[0284] Optionally, the second device can implicitly indicate to the first device that the authentication result for the first device is successful by carrying a second signature for authenticating the second device in the second message. That is, upon receiving the second message carrying the second signature for authenticating the second device, the first device can determine that the authentication result for the first device by the second device is successful.

[0285] Optionally, the second device may indicate to the first device that the authentication result for the first device is successful by indicating in the second message that the authentication result for the first device is successful.

[0286] Additionally, the process may include: if the second device fails to authenticate the first device, the second device's processing may include: sending a group response message to the first device, the group response message carrying an indication that the authentication result for the first device was authentication failure. Correspondingly, the first device's processing may include: receiving a group response message from the second device. Furthermore, the first device's processing may also include: terminating the process if the group response message indicates that the authentication result for the first device was authentication failure.

[0287] Specifically, the authentication process for the second device based on the public key associated with the second device and the second signature is the same as in the previous embodiments and will not be repeated here; the parameters for the first device to verify the second signature are also the same as in the previous embodiments and will not be repeated here.

[0288] Here, the public key associated with the second device includes the public key of the second device, which is the identifier of the second device. That is, the public key associated with the second device may include the identifier of the second device. Furthermore, the public key associated with the second device may also include the master public key of the second service node, which is stored in the first certificate.

[0289] Specifically, the public key associated with the second device refers to the public key used to verify the second signature. This public key needs to include the public key of the second device (i.e., the public key of the second device itself), which is specifically the identifier of the second device. Furthermore, the public key used to verify the second signature also needs to include the master public key of the second service node to which the second device belongs.

[0290] The foregoing embodiments have described that the first device obtains the address of the first certificate and authenticates the identity of the second service node. Therefore, the processing of the first device obtaining the public key related to the second device may include: if the authentication of the second service node is successful, obtaining the master public key of the second service node from the first certificate; using the identifier of the second device as the public key of the second device; and using the public key of the second device and the master public key of the second service node together as the public key related to the second device. Regarding the specific method of using the public key of the second device and the master public key of the second service node together as the public key related to the second device, it can be that the public key of the second device and the master public key of the second service node are directly concatenated to form the public key related to the second device, or other methods may be used. This embodiment does not exhaustively list or limit these methods.

[0291] In one embodiment, the second message further carries at least one of the following: the identifier of the second device, and security parameters of the second device. The first device can determine parameters for verifying the second signature based on the second message, and these parameters may be wholly or partially related to the second message. The explanation regarding the first device determining the parameters for verifying the second signature is the same as in the foregoing embodiments and will not be repeated here.

[0292] In one embodiment, the parameters for verifying the second signature may include, in addition to at least one of the security parameters of the second device and the identifier of the second device, at least one of the following: the identifier of the first device and the second random number. The identifier of the first device and the second random number may be carried in a first message sent by the first device; therefore, both the first device and the second device can obtain the identifier of the first device and the second random number.

[0293] In one embodiment, the first device uses a signature verification algorithm to decrypt the second signature based on the public key associated with the second device to obtain second decrypted information. Based on the second decrypted information and parameters for verifying the second signature, the first device authenticates the second device. The process of authenticating the second device based on the second decrypted information and the second parameters is the same as in the previous embodiments and will not be described again.

[0294] Optionally, if the first device determines that authentication of the second device has failed, the processing of the first device may further include: the first device ending the processing, or the first device sending an indication to the second device that authentication of the second device has failed.

[0295] Optionally, if the first device determines that the authentication of the second device is successful, the processing of the first device may further include: the first device sending an indication to the second device that the authentication of the second device is successful.

[0296] In one embodiment, before authenticating the second device based on the public key associated with the second device and the second signature, the processing of the first device may further include: verifying whether the second device has been revoked based on the identifier of the second device carried in the second message.

[0297] Here, due to the small number of IoT devices under the same trust domain, a traditional revocation list is used to revoke the identity of the IoT device (i.e., the second device). For example, the second service node (e.g., the second KGC) to which the second device belongs needs to maintain a revocation list to record the identity and other information of the revoked device, preventing the unauthorized use of the revoked identity. When the second service node (e.g., the second KGC) receives an identity revocation request, it adds the identity and other information of the IoT device to the revocation list and uploads the updated revocation list to the blockchain for other users to verify. Correspondingly, the first device verifies whether the second device has been revoked based on the identifier of the second device carried in the second message. This can mean that the first device searches the revocation list on the blockchain, obtains the status of the identifier of the second device from the revocation list, and if the status corresponding to the identifier of the second device is "not revoked," it determines that the second device has not been revoked; otherwise, it determines that the second device has been revoked. Furthermore, if it is determined that the second device has not been revoked, the first device can continue to perform subsequent processing to authenticate the second device based on the public key and the second signature related to the second device, which will not be repeated here.

[0298] During the aforementioned authentication process, the first device and the second device can also negotiate a session key. The first device's processing may further include: calculating a session key based on the security parameters of the second device and the security parameters of the first device, wherein the session key is used for communication between the first device and the second device. It should also be noted that if the second device successfully authenticates the first device, the second device's processing may further include: calculating a session key based on the security parameters of the second device and the security parameters of the first device, wherein the session key is used for communication between the first device and the second device.

[0299] In some possible implementations, the second device and multiple target devices belong to different trust domains, while the multiple target devices and the first device belong to the same trust domain. Alternatively, the first device (i.e., a proxy device) can initiate authentication to the second device (such as an IoT device).

[0300] In one embodiment, the first message sent by the first device can also be used to trigger a process for authenticating multiple target devices.

[0301] The first message may carry group parameters and identity information. The descriptions of the group parameters, identity information, and group information stored on the first device are the same as in the previous embodiments and will not be repeated. Additionally, the first message may also carry identifiers of multiple target devices.

[0302] The processing by the second device after receiving the first message may include: calculating the authentication value of the multiple target devices based on the identifier of each target device in the identity information and one or more parameter values ​​corresponding to each target device; and authenticating the multiple target devices based on the authentication values ​​of the multiple target devices and the group parameter. The related processing for the second device to authenticate multiple target devices is the same as in the aforementioned embodiments, and therefore will not be described in detail.

[0303] In one embodiment, certificate authentication is still required between the first device and the second device.

[0304] The first device can carry the address of a third certificate in the first message. The third certificate is the certificate of the first service node to which the first device belongs, and it is used to authenticate the identity of the first service node. The relevant description of the third certificate is the same as in the previous embodiments and will not be repeated. Correspondingly, after receiving the first message, the second device can authenticate the identity of the first service node based on the address of the third certificate. The processing of the second device authenticating the identity of the first service node is also the same as in the previous embodiments and will not be repeated.

[0305] In one embodiment, the processing of the second device further includes: sending the address of a second certificate to the first device, wherein the second certificate is a certificate of the second device. In the processing of the first device, the method further includes: receiving the address of a second certificate from the second device, wherein the second certificate is a certificate of the second device.

[0306] Since this embodiment uses the first device as the authentication initiator, it differs from the aforementioned implementations in that, after the second device successfully authenticates the identity of the first service node and the plurality of target devices, its processing further includes sending the address of the first certificate to the first device. The first certificate is the certificate of the second service node to which the second device belongs. The second device can carry the address of the second certificate in its second message. The processing of the first device authenticating the identity of the second device based on the address of the second certificate is the same as in the aforementioned embodiments and will not be described again.

[0307] In one embodiment, signature authentication is still required between the first device and the second device.

[0308] Unlike the aforementioned implementation, the first device, as the authentication initiator, first carries a first signature for authenticating the first device in the first message it sends.

[0309] The first device can calculate the first signature by employing a signature algorithm, based on the private key corresponding to the group parameters and the parameters used to calculate the first signature. The parameters used to calculate the first signature include at least one of the following: the identifier of the first device and the security parameters of the first device. Unlike the previous implementation, in this implementation, the parameters used to calculate the first signature may include, in addition to the identifier of the first device and at least one of the security parameters of the first device, a second random number generated by the first device. This is because in this implementation, authentication is initiated by the first device, and therefore the first random number generated by the second device cannot be obtained before authentication is initiated. Alternatively, in this implementation, the parameters used to calculate the first signature may include, in addition to the identifier of the first device and at least one of the security parameters of the first device, a second random number generated by the first device and at least one of the identifier of the second device. This is because in this implementation, authentication is initiated by the first device, and therefore the first random number generated by the second device cannot be obtained before authentication is initiated. However, the first device needs to initiate authentication with the second device, so it may have already stored the identifier of the second device locally. Therefore, the parameters used to calculate the first signature may include the identifier of the second device.

[0310] Except for the parameters used to calculate the first signature, which may differ from those in the previous embodiments, the specific method by which the first device calculates the first signature is the same as in the previous embodiments and will not be repeated here.

[0311] After the second device receives the first message carrying the first signature for authenticating the first device, the second device's processing may further include: authenticating the first device based on the group parameters and the first signature. The only difference between the second device's processing and the previous embodiment is that the composition of the parameters used to verify the first signature may change, but the parameters used to verify the first signature are the same as those used by the first device to calculate the first signature. Other processing is the same as in the previous embodiment, and therefore will not be described in detail.

[0312] If the second device successfully authenticates the first device, the second device can perform the following processing: sending a second message to the first device, wherein the second message carries a second signature for authenticating the second device, the second signature being calculated based on the private key of the second device. Correspondingly, the first device's processing can include: receiving a second message from the second device, wherein the second message carries a second signature for authenticating the second device; and authenticating the second device based on the public key associated with the second device and the second signature. Unlike the aforementioned implementation, the processing after the second device receives the first message further includes: sending at least one of the following to the first device: a first random number and the identifier of the second device. Specifically, when the first device initiates authentication via the first message, at least one of the first random number and the identifier of the second device can be sent to the first device along with the second signature in the second message.

[0313] The specific processing method for the second device to calculate the second signature is the same as in the previous embodiments, and the processing method for the first device to authenticate the second device based on the second signature is also the same as in the previous embodiments, so it will not be described again.

[0314] In this embodiment, before (or after) authenticating the second device based on the second signature, the first device will also verify whether the second device has been revoked. The specific processing method is the same as in the previous embodiment and will not be repeated.

[0315] In this embodiment, the first device and the second device can also complete the negotiation of the session key during the authentication process. The specific processing is the same as in the previous embodiments and will not be described in detail.

[0316] Combination Figure 6 Taking the first device as the proxy device and the second device as an IoT device as an example, the above authentication method is illustrated by example. Figure 6The scenario addressed is when a zero-power device (or IoT device) needs to communicate with multiple IoT devices or multiple zero-power devices (i.e., multiple target devices in the aforementioned embodiments) in different trust domains. This requires providing identity verification to IoT devices in different trust domains while simultaneously verifying the other party's identity. Therefore, a proxy device can be delegated to assist in completing inter-domain authentication. Assume IoT device C needs to communicate with multiple zero-power devices (identified as...) In the communication, multiple zero-power devices entrust an agent device (which belongs to the same trust domain as the multiple zero-power devices) to help them complete identity authentication. Among them, IoT device C and the multiple zero-power devices belong to different trust domains. Figure 6 The processing flow of the authentication method shown may include the following steps:

[0317] Step 601: The IoT device stores the location information of its first certificate (i.e., the second service node in the aforementioned embodiment) on the blockchain. ), First random number ( ), Identification of IoT devices ( ) and the identifiers of the multiple target devices to be communicated with ( Together they are sent to the agent device in plaintext.

[0318] In this step, the information sent by the IoT device to the proxy device can be carried by the third message in the aforementioned embodiments; assuming the IoT device is represented as C and the proxy device as A, the information sent by the authentication function entity to the proxy device can be represented as: .

[0319] Step 602: After receiving the information from the IoT device, the agent device searches for the first certificate on the blockchain and verifies whether the first certificate has been revoked. If the first certificate is found and has not been revoked, the authentication of the second service node is considered successful, and then step 603 is executed. Alternatively, if the first certificate is not found and / or has been revoked, the authentication of the second service node is considered to have failed, and the process ends.

[0320] Step 603: The proxy device sends the on-chain address of the third certificate of the KGC (i.e., the first service node) to which the proxy device belongs to the IoT device. ), the identification of the agency equipment ( ), joint identity (i.e., group parameters), second random number ( Session keys negotiated using the DH protocol (i.e., the DH parameters of the proxy device), first signature Sig Root (H(N C N A ID C IDA ,X A ·P)) Multiple zero-power devices belong to a joint identity The proof message (i.e., identity information).

[0321] The first signature can be obtained using a joint identity. The corresponding private key is used to identify the proxy device. ), second random number ( Session keys negotiated using the DH protocol Identification of IoT devices ( ), First random number ( This is calculated using the first random number (or freshness value). The purpose of signing is to enable IoT devices to authenticate that they have received a message that is not a replay but truly originates from the agent device, thus identifying the IoT device. The signature indicates that the agent device has received the information from step 601 from the authentication function entity.

[0322] In this step, the information sent by the agent device to the IoT device can be carried by the first message in the aforementioned embodiment, combined with... Figure 4a and Figure 4b The identifiers of the multiple zero-power devices in the aforementioned embodiments are as follows: For example, the content carried by this first message can be represented as follows:

[0323] .

[0324] Step 604: After receiving the information from the agent device, the IoT device searches for a third-party certificate on the blockchain. Verify whether the third-party certificate has been revoked, verify the identity of each zero-power device, and verify the joint identity on the blockchain. Whether it has been revoked, and verify the first signature.

[0325] Specifically, finding a third-party certificate on the blockchain of an IoT device. If the third-party certificate has not been revoked, verify the identity of each zero-power device; if the authentication of each zero-power device is successful, verify the joint identity on the blockchain. Whether it has been revoked; in determining joint status Use without cancellation Verify the authenticity of the first signature. Further, if the first signature verification is successful, i.e., the authentication of the agent device is successful, step 605 can be executed. Additionally, it may also include: the IoT device finding a third certificate without chain verification... The third certificate was revoked, and joint identity was determined. If at least one of the following conditions is met—revocation or failure to verify the first signature—processing ends.

[0326] It should also be noted that if an IoT device does not have the ability to connect to the blockchain, it can also entrust its corresponding proxy device to find a third-party certificate on the blockchain. On-chain verification of joint identity Whether it has been revoked.

[0327] Step 605: The IoT device identifies itself. Session key negotiated using the DH protocol The second signature is sent to the agent device.

[0328] The second signature can be an identifier for the IoT device using the IoT device's private key. Session key negotiated using the DH protocol Identification of the agency equipment ( ), second random number ( This is calculated. Here, we use... Signing is used to enable IoT devices and agent devices to negotiate session keys; a second random number (or freshness value) is then generated. The purpose of signing is to allow the agent device to verify that it has received a message that is not a replay but indeed comes from an IoT device. The signature indicates that the IoT device has received the first message from the agent device.

[0329] In this step, the information sent by the IoT device to the agent device can be carried by the second message in the aforementioned embodiment; assuming the IoT device is represented as C and the agent device as A, the information sent by the IoT device to the agent device can be represented as: .

[0330] Step 606: After receiving the information from the IoT device, the agent device verifies on the blockchain whether the IoT device's identity has been revoked. If not, it uses the IoT device's identifier as its public key to verify the second signature. Here, in verifying the second signature, besides using the IoT device's identifier as its public key, the agent device can also extract the second service node's master public key from the first certificate, and use both the IoT device's public key and the second service node's master public key to verify the second signature.

[0331] Step 607: Once the agent device has completed the authentication of the IoT device, it begins communication with the IoT device.

[0332] exist Figure 6The example provided addresses a scenario where authentication is initiated by an IoT device. To address a scenario where authentication is initiated by a proxy device, the aforementioned... Figure 6 The specific steps can be adaptively replaced or adjusted. For example, steps 601 and 602 can be deleted (i.e., steps 601 and 602 are not executed); in step 603, the proxy device sends the address of the third certificate of the KGC (i.e., the first service node) to which the proxy device belongs on the chain to the IoT device. ), the identification of the agency equipment ( ), joint identity (i.e., group parameters), second random number ( Session keys negotiated using the DH protocol (i.e., the DH parameters of the proxy device), identifiers of multiple zero-power devices, and the first signature Sig Root (H(N A ID A ,X A ·P)) Multiple zero-power devices belong to a joint identity The verification message (i.e., identity information). Step 604 remains unchanged. Step 605: The IoT device will display the IoT device's identifier. Session key negotiated using the DH protocol The location information of the first certificate of its own KGC (i.e., the second service node in the aforementioned embodiment) on the chain. ), First random number ( ), second signature ( The message is sent to the proxy device. Step 606: The proxy device searches for the first certificate on the blockchain and verifies whether the first certificate has been revoked. If the first certificate is found and has not been revoked, the authentication of the second service node is confirmed to be successful. The proxy device then verifies on the blockchain whether the identity of the IoT device has been revoked. If it has not been revoked, the IoT device's identifier is used as the IoT device's public key to verify the second signature. Step 607 remains unchanged.

[0333] In some embodiments, the second device and multiple target devices belong to the same trust domain, and the multiple target devices and the first device belong to the same trust domain. In this embodiment, multiple target devices and the first device belonging to the same trust domain can mean that the multiple target devices and the first device belong to the same service node, which is the first service node; the second device and multiple target devices belonging to the same trust domain can mean that the second device and the first device (and the multiple target devices) belong to the same trust domain, and the service node to which the second device belongs is the same as the service node to which the first device belongs, which is the first service node.

[0334] In this embodiment, the second device remains the one initiating authentication. The second device can send a third message to the first device when it needs to communicate with multiple target devices belonging to the same trust domain. The method by which the second device selects multiple target devices is the same as in the previous embodiments and will not be repeated.

[0335] In one embodiment, the third message carries at least the identifiers of multiple target devices. Accordingly, after receiving the third message from the second device, the first device obtains the group parameters corresponding to the group to which the multiple target devices belong, and obtains the identity information of the multiple target devices based on the identifier of each target device; it then sends a first message to the second device, carrying the group parameters and the identity information of the multiple target devices. The relevant descriptions of the group information, group parameters, and the method by which the first device generates the identity information are the same as in the aforementioned embodiments, and therefore will not be repeated.

[0336] In some embodiments, the first message may carry group parameters and identity information. Accordingly, the processing by the second device after receiving the first message may include: calculating the authentication value of the plurality of target devices based on the identifier of each target device among the plurality of target devices contained in the identity information and one or more parameter values ​​corresponding to each target device; and authenticating the plurality of target devices based on the authentication values ​​of the plurality of target devices and the group parameters. The processing of the second device authenticating the plurality of target devices is the same as in the aforementioned embodiments, and therefore will not be repeated.

[0337] Optionally, after receiving the first message, the second device may further include: extracting group parameters from the first message; and checking whether the group parameters have been revoked. The process of checking whether the group parameters have been revoked is the same as in the aforementioned embodiments and will not be repeated.

[0338] Through the above processing, authentication of multiple target devices within the same trust domain can be initiated by a second device (any IoT device or zero-power device). The first device then generates identity information and reports it to the second device, which completes the authentication of the multiple target devices based on this identity information. This improves the efficiency of authenticating a group of target devices using a zero-power device within a domain.

[0339] In this embodiment, since the first device, the second device, and the multiple target devices all belong to the same trust domain, certificate-related authentication is not required between the first device and the second device.

[0340] In this embodiment, signature-related authentication can be added between the first device and the second device (any IoT device or zero-power device), and session key negotiation can be completed simultaneously.

[0341] The first message also carries a first signature used to authenticate the first device. The first signature is calculated based on the private key corresponding to the group parameters and the parameters used to calculate the first signature. The parameters used to calculate the first signature include at least one of the following: the identifier of the first device, and the security parameters of the first device. In this embodiment, the various possible components of the first message and the parameters used to calculate the first signature, as well as the related descriptions of the first device calculating the first signature, are the same as the various possible exemplary descriptions provided in the foregoing embodiments, and will not be repeated here.

[0342] After receiving the first message carrying the first signature for authenticating the first device, the second device's processing may further include: authenticating the first device based on the group parameters and the first signature. The timing and specific processing method of the second device authenticating the first device based on the group parameters and the first signature are the same as in the foregoing embodiments and will not be repeated here.

[0343] If the second device successfully authenticates the first device, the processing of the second device may further include: sending a second message to the first device, wherein the second message carries a second signature for authenticating the second device, the second signature being calculated based on the private key of the second device.

[0344] The second signature is calculated based on the private key of the second device and a second parameter, wherein the second parameter includes at least one of the following: the identifier of the second device, and the security parameter of the second device. In this embodiment, the private key of the second device, the second message, the second parameter, and the relevant descriptions of the calculation of the second signature by the second device are the same as in the previous embodiments and will not be repeated.

[0345] The processing of the first device may include: receiving a second message from the second device, wherein the second message carries a second signature for authenticating the second device; and authenticating the second device based on the public key associated with the second device and the second signature.

[0346] Here, the public key associated with the second device includes the public key of the second device, which is the identifier of the second device. That is, the public key associated with the second device can include the identifier of the second device. Furthermore, the service node to which both the second device and the first device belong is the first service node; the public key associated with the second device also includes the master public key of the first service node, wherein the master public key of the first service node is pre-configured.

[0347] Specifically, the public key associated with the second device refers to the public key used to verify the second signature. This public key needs to include the public key of the second device (i.e., the public key of the second device itself), which is specifically the identifier of the second device. Furthermore, the public key used to verify the second signature also needs to include the master public key of the first service node. As explained in the foregoing embodiments, the first device can obtain the address of its own third certificate through registration. Therefore, the first device can directly obtain the master public key of the first service node from the third certificate.

[0348] Furthermore, the authentication process for the second device based on the public key, the second signature, and the second parameters is the same as in the aforementioned embodiments, and therefore will not be described in detail.

[0349] In one embodiment, before authenticating the second device based on the public key associated with the second device and the second signature, the processing of the first device may further include: verifying whether the second device has been revoked based on the identifier of the second device carried in the second message. The method by which the first device verifies whether the second device has been revoked is the same as in the aforementioned embodiments and will not be repeated.

[0350] During the aforementioned authentication process, the first and second devices can also negotiate the session key. The specific processing is the same as in the aforementioned embodiments and will not be repeated here.

[0351] In some possible implementations, the second device and multiple target devices belong to the same trust domain, and the multiple target devices and the first device belong to the same trust domain. Alternatively, the first device (i.e., the proxy device) can initiate authentication to the second device (e.g., an IoT device).

[0352] In one embodiment, the first message sent by the first device can also be used to trigger authentication processing for multiple target devices. The first message may carry group parameters and the identity information of the multiple target devices. The descriptions of the group parameters, the identity information of the multiple target devices, and the group information stored by the first device are the same as in the previous embodiments and will not be repeated. The first message may carry the identifiers of the multiple target devices.

[0353] After receiving the first message, the second device calculates the authentication value of the multiple target devices based on the identifier of each target device in the identity information and one or more parameter values ​​corresponding to each target device; based on the authentication value of the multiple target devices and the group parameter, it authenticates the multiple target devices. The related processing of the second device authenticating multiple target devices is the same as in the previous embodiment, and therefore will not be described in detail.

[0354] In this embodiment, since the first device, the second device, and the multiple target devices all belong to the same trust domain, certificate-related authentication is not required between the first device and the second device.

[0355] In this embodiment, the first device and the second device (any IoT device or zero-power device) need to perform signature-related authentication and simultaneously complete the negotiation of session keys.

[0356] Unlike the aforementioned implementation, the first device, as the authentication initiator, first carries a first signature for authenticating the first device in the first message it sends.

[0357] The first device can calculate the first signature by employing a signature algorithm, based on the private key corresponding to the group parameters and the parameters used to calculate the first signature. The parameters used to calculate the first signature include at least one of the following: the identifier of the first device and the security parameters of the first device. In this embodiment, the parameters used to calculate the first signature may include, in addition to the identifier of the first device and at least one of the security parameters of the first device, a second random number generated by the first device. This is because in this embodiment, authentication is initiated by the first device, and therefore the first random number generated by the second device cannot be obtained before authentication is initiated. Alternatively, in this embodiment, the parameters used to calculate the first signature may include, in addition to the identifier of the first device and at least one of the security parameters of the first device, a second random number generated by the first device and at least one of the identifier of the second device. This is because in this embodiment, authentication is initiated by the first device, and therefore the first random number generated by the second device cannot be obtained before authentication is initiated. However, the first device needs to initiate authentication with the second device, so it may have already stored the identifier of the second device locally. Therefore, the parameters used to calculate the first signature may include the identifier of the second device.

[0358] Except for the parameters used to calculate the first signature, which may differ from those in the previous embodiments, the specific method by which the first device calculates the first signature is the same as in the previous embodiments and will not be repeated here.

[0359] After the second device receives the first message carrying the first signature for authenticating the first device, the second device's processing may further include: authenticating the first device based on the group parameters and the first signature. The only difference between the second device's processing and the previous embodiment is that the composition of the parameters used to calculate the first signature may change; other processing is the same as in the previous embodiment and therefore will not be described in detail.

[0360] If the second device successfully authenticates the first device, the second device can perform the following processing: sending a second message to the first device, wherein the second message carries a second signature for authenticating the second device, the second signature being calculated based on the private key of the second device. Correspondingly, the first device's processing can include: receiving a second message from the second device, wherein the second message carries a second signature for authenticating the second device; and authenticating the second device based on the public key associated with the second device and the second signature. Unlike the aforementioned implementation, the processing after the second device receives the first message further includes: sending at least one of the following to the first device: a first random number and the identifier of the second device. Specifically, when the first device initiates authentication via the first message, at least one of the first random number and the identifier of the second device can be sent to the first device along with the second signature in the second message.

[0361] The specific processing method for the second device to calculate the second signature is the same as in the previous embodiments, and the processing method for the first device to authenticate the second device based on the second signature is also the same as in the previous embodiments, so it will not be described again.

[0362] In this embodiment, before (or after) authenticating the second device based on the second signature, the first device will also verify whether the second device has been revoked. The specific processing method is the same as in the previous embodiment and will not be repeated.

[0363] In this embodiment, the first device and the second device can also complete the negotiation of the session key during the authentication process. The specific processing is the same as in the previous embodiments and will not be described in detail.

[0364] Combination Figure 7 Taking the first device as the proxy device and the second device as an IoT device as an example, the above authentication method is illustrated by example. Figure 7 The scenario addressed is as follows: when a regular device (or IoT device) needs to communicate with multiple IoT devices or multiple zero-power devices (i.e., multiple target devices in the aforementioned embodiments), authentication, i.e., a three-way handshake, is required first. Zero-power devices do not have computing power; during the authentication process, a proxy device is fully responsible for all authentication-related processing. Assume IoT device B, and multiple zero-power devices (identified as...) Agent device A belongs to the same trust domain, and IoT device B needs to communicate with multiple zero-power devices. Figure 7 The processing flow of the authentication method shown may include the following steps:

[0365] Step 701: The IoT device generates the first random number ( ), Identification of IoT devices ( ) and the identifiers of the multiple target devices to be communicated with ( Together they are sent to the agent device in plaintext.

[0366] In this step, the information sent by the IoT device to the proxy device can be carried by the third message in the aforementioned embodiments; assuming the IoT device is represented as B and the proxy device as A, the information sent by the authentication function entity to the proxy device can be represented as: .

[0367] Step 702: The agent device sends its identifier to the IoT device. ), joint identity (i.e., group parameters), second random number ( Session keys negotiated using the DH protocol (i.e., the DH parameters of the proxy device), first signature Sig Root (H(N B N A ID B ID A ,X A ·P)) Multiple zero-power devices belong to a joint identity The proof message (i.e., identity information).

[0368] The first signature can be obtained using a joint identity. The corresponding private key is used to identify the proxy device. ), second random number ( Session keys negotiated using the DH protocol Identification of IoT devices ( ), First random number ( The calculation is as follows. Here, the purpose of signing the first random number is to enable the IoT device to authenticate that it has received a message that is not a replay but truly originates from the agent device, thus identifying the IoT device (…). The signature indicates that the agent device has received the information from step 701 from the authentication function entity.

[0369] In this step, the information sent by the agent device to the IoT device can be carried by the first message in the aforementioned embodiment, combined with... Figure 4a and Figure 4b The identifiers of the multiple zero-power devices in the aforementioned embodiments are as follows: For example, the content carried by this first message can be represented as follows:

[0370] .

[0371] Step 703: After receiving the information from the agent device, the IoT device verifies the identity of each zero-power device and verifies the joint identity on the blockchain. Whether it has been revoked, and verify the first signature.

[0372] Specifically, the IoT devices verify the identity of each zero-power device; and upon successful authentication of each zero-power device, the joint identity is verified on the blockchain. Whether it has been revoked; in determining joint status Use without cancellation Verify the authenticity of the first signature. Further, if the first signature verification is successful, i.e., the proxy device authentication is successful, step 704 can be executed. Additionally, it may also include: the IoT device, upon meeting the requirements for determining the joint identity... If at least one of the following conditions is met—revocation or failure to verify the first signature—processing ends.

[0373] It should also be noted that if an IoT device does not have the capability to go on-chain, it can also entrust its corresponding agent device to verify the joint identity on-chain. Whether it has been revoked.

[0374] Step 704: The IoT device identifies itself ( Session keys negotiated using the DH protocol The second signature is sent to the agent device.

[0375] The second signature can be an identifier for the IoT device using the private key of the IoT device. ), Identification of the agency equipment ( ), second random number ( This is calculated. Here, we use... Signing is used to enable IoT devices and agent devices to negotiate session keys; a second random number (or freshness value) is then generated. The purpose of signing is to allow the agent device to verify that it has received a message that is not a replay but indeed comes from an IoT device. The signature indicates that the IoT device has received the first message from the agent device.

[0376] In this step, the information sent by the IoT device to the agent device can be carried by the second message in the aforementioned embodiment; assuming the IoT device is represented as B and the agent device as A, the information sent by the IoT device to the agent device can be represented as: .

[0377] Step 705: After receiving the information from the IoT device, the agent device verifies on the blockchain whether the IoT device's identity has been revoked. If not, it uses the IoT device's identifier as its public key to verify the second signature. Here, the verification of the second signature can be performed using both the IoT device's public key and the primary public key of the first service node.

[0378] Step 706: Once the agent device has completed the authentication of the IoT device, it begins communication with the IoT device.

[0379] exist Figure 7 The example provided addresses a scenario where authentication is initiated by an IoT device. To address a scenario where authentication is initiated by a proxy device, the aforementioned... Figure 7 The specific steps can be adaptively replaced or adjusted. For example, step 701 can be deleted (i.e., step 701 is not executed); in step 702, the agent device sends the agent device's identifier to the IoT device. ), joint identity (i.e., group parameters), second random number ( Session keys negotiated using the DH protocol (i.e., the DH parameters of the proxy device), identifiers of multiple zero-power devices, and the first signature Sig Root (H(N A ID A ,X A ·P)) Multiple zero-power devices belong to a joint identity The proof message (i.e., identity information). Step 703 remains unchanged. Step 704: The IoT device will generate the first random number ( ), Identification of IoT devices ( Session keys negotiated using the DH protocol The second signature is sent to the agent device. Steps 705-706 remain unchanged.

[0380] By employing the authentication method provided in this embodiment, the first device, acting as a proxy, can obtain the identity information and group parameters related to multiple target devices, and then send this information to the second device. The second device then authenticates the multiple target devices based on this information. This allows for simultaneous authentication of multiple target devices, improving authentication efficiency. Furthermore, since the entire authentication process does not require access to the content stored on the target devices, storage space is saved, reducing storage costs.

[0381] The basic principle of PKI (Public Key Infrastructure) in the aforementioned embodiments is explained as follows: A third-party authoritative authority, namely the Certificate Authority (CA), combines the public key held by the user with their identity information (such as name, telephone number, etc.). Before the combination, the CA verifies the authenticity of the user's identity, and then the CA signs the certificate bound to the user and their public key.

[0382] Identity-based cryptography (IBC) is another branch of public-key cryptography. It directly uses a user's unique characteristic information as their public key (i.e., user identifier), such as an email address or mobile phone number. Users do not need to apply for and exchange certificates, thus greatly 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. Here, the private key generation algorithm can be the SM9 national cryptographic algorithm, specifically including the SM9 digital signature algorithm, the SM9-IBE identifier encryption algorithm, and the SM9-KA key negotiation protocol.

[0383] A blockchain-based two-layer identity architecture: The identity management architecture for both integrated sensor scenarios and zero-power consumption scenarios is designed as a two-layer architecture, such as... Figure 8 As shown, the entire protocol framework consists of two parts: a CA (Certificate Authority) model is used from committee nodes to issuing nodes (the committee jointly acts as a trusted center), and a blockchain model is used from issuing nodes to their corresponding IoT devices (i.e., light nodes). Since the number of issuing nodes is relatively small, the CA model facilitates authorization and management. However, the data of IoT devices authorized by the issuing nodes is enormous, making blockchain a better solution. Combining these two models makes the system more in line with current mainstream market usage and allows for a more tightly integrated and clearly defined system hierarchy.

[0384] Blockchain Model: The issuing node uses a blockchain model to connect with its corresponding IoT device. The IoT device's certificate is stored on the blockchain. When a certificate is needed, it is located at the corresponding position on the chain. After the issuing node issues the certificate, it applies to be added to the chain. Multiple on-chain nodes verify the certificate, and then it is added to the blockchain through a consensus algorithm. On-chain nodes first verify the issuing node's certificate using the joint committee's public key. After successful verification, they verify the IoT device's certificate using the corresponding issuing node's public key. Upon successful verification, the IoT device's certificate is added to the chain, and its location information is returned to the issuing node. The issuing node then returns this location information to the IoT device. In this scenario, the IoT device itself only needs to store the certificate's location information on the chain, not the certificate itself. The verifier only needs to search for the certificate at the corresponding position on the chain based on the location information sent by the sender. If the certificate is found at the correct position, its authenticity and validity are guaranteed. The verifier does not need to repeatedly verify the certificate's authenticity and validity, which greatly reduces communication and computational load.

[0385] However, in the above process, users (i.e., any device) must carry their own certificate at all times to prove their identity. The certificate content, which contains various public information such as identity, is too long and inconvenient to carry. Especially for massive IoT devices, if each device has a certificate, it will put a high burden on the storage server.

[0386] The underlying concept of the solution provided in this application embodiment is as follows: Under the IBC system, after purchasing equipment and servers from the vendor, the business can build its own KGC. The business can then independently manage and serve IoT devices within the same trust domain through the KGC. The KGC must be registered in a two-tier architecture (e.g., ...). Figure 8 In the two-layer architecture shown, the device acts as an IoT device, requiring it to submit public materials such as its identity and public key to the issuing node in order to obtain a certificate issued by the issuing node. In the IoT, two types of devices need to be considered: those with computing power and those with zero power consumption.

[0387] The possible device definitions in the scheme provided in this application embodiment are as follows: The issuing node can be a business party, i.e., a vertical industry with many devices, such as small and medium-sized factories, logistics companies, manufacturing companies, and aquaculture companies; each of the multiple target devices can be any IoT device (or any zero-power device) of the business party, and the multiple target devices belong to the same KGC (i.e., the same service node); the second device can be an IoT device, i.e., any IoT device of the business party, which can belong to different KGCs or the same KGC as the multiple target devices; or, the second device can also be an authentication function entity (i.e., a network device), which can be deployed on operator equipment (such as: base stations, AMF, SEAF, NWDF, PCF, NEF, etc.) or the authentication server of a third-party security service provider. In this case, the authentication function entity belongs to a different trust domain than the multiple target devices; the first device can be a proxy device, which is a device of the business party with computing power and permission to go online, and is fully responsible for the identity authentication of the zero-power device. It belongs to the same trust domain as the multiple target devices. For example, the type of proxy device can be any one of: UE, IAB, relay, repeater, etc.

[0388] The SM9 national cryptographic algorithm can implement an identity-based cryptosystem, involving key encapsulation, signature, session key, security parameters, and public key encryption algorithms, etc. The scheme provided in this application uses the key generation algorithm, signature algorithm, and verification algorithm in the signature scheme.

[0389] The solution provided in this embodiment takes into account the limited capabilities of AIoT devices or zero-power devices in the communication network. It can complete the security management and authentication of these groups of AIoT devices or groups of zero-power devices through a proxy, thereby ensuring the authentication of groups of zero-power devices while improving the authentication processing efficiency. Furthermore, it uses an identity-based cryptographic system to manage business nodes, which reduces the terminal storage burden and improves authentication efficiency compared to using terminal certificates. This solves the problems of identity management for devices in the Internet of Things, as well as intra-domain and inter-domain authentication during specific use. Furthermore, the solution provided in this embodiment uses IBC (Identity-Based Cryptography) to implement secure credential management for zero-power IoT devices or AIoT devices. Each IoT device's identity is its own public key. Specifically: since each IoT device's identity is its own public key, the device itself does not need to store the public key separately, nor does it need to store certificates recording its public key information. For the certificate management server, the adoption of IBC technology simplifies the certificate issuance mechanism; only the private key needs to be generated, eliminating the need to generate certificates for a large number of IoT devices. Since the identity of each IoT device must be stored, the use of identity-based cryptography only requires storing its own identity, eliminating the need to store the public key separately. Using a blockchain architecture, the KGC certificate is stored on the blockchain, eliminating the need to store certificates recording the public key information, fully utilizing the value of information, and reducing storage costs for zero-power IoT terminals or AIoT terminals.

[0390] Figure 9 This is a schematic diagram of the composition structure of a first device according to an embodiment of this application, including:

[0391] The first processing unit 902 is used to obtain the identity information of multiple target devices;

[0392] The first communication unit 901 is used to send a first message to the second device, wherein the first message carries the identity information used to authenticate the plurality of target devices.

[0393] The first message also carries group parameters, which are calculated based on the identifiers of the multiple target devices.

[0394] The identity information includes the identifier of each of the multiple target devices and one or more parameter values ​​corresponding to each target device.

[0395] The first message also carries a first signature for authenticating the first device, wherein the first signature is calculated based on the private key corresponding to the group parameter.

[0396] The first message also carries at least one of the following: the identifier of the first device, and the security parameters of the first device.

[0397] The first signature is calculated based on the private key corresponding to the group parameter and at least one of the following parameters: the identifier of the first device, the security parameter of the first device, the identifier of the second device, the first random number, and the second random number.

[0398] The first communication unit is configured to receive a second message from the second device, wherein the second message carries a second signature for authenticating the second device;

[0399] The first processing unit is used to authenticate the second device based on the public key associated with the second device and the second signature.

[0400] The second message also carries at least one of the following: the identifier of the second device, and the security parameters of the second device.

[0401] The first processing unit is configured to authenticate the second device based on the public key associated with the second device, the second signature, and at least one of the following parameters: the identifier of the second device, the security parameters of the second device, the identifier of the first device, a first random number, and a second random number.

[0402] The first communication unit is configured to receive the first random number from the second device.

[0403] The first message also carries the second random number.

[0404] The first processing unit is configured to calculate a session key based on the security parameters of the second device and the security parameters of the first device, wherein the session key is used for communication between the first device and the second device.

[0405] The public key associated with the second device includes the identifier of the second device.

[0406] The service node to which the second device and the first device belong is the first service node; the public key related to the second device also includes the master public key of the first service node, wherein the master public key of the first service node is pre-configured.

[0407] The first communication unit is configured to receive the address of a first certificate from the second device, wherein the first certificate is the certificate of the second service node to which the second device belongs.

[0408] The first processing unit is used to authenticate the identity of the second service node based on the address of the first certificate.

[0409] The public key associated with the second device also includes the master public key of the second service node, which is stored in the first certificate.

[0410] The second device is one of the following types: terminal, Internet of Things device, zero-power device.

[0411] The first communication unit is configured to receive the address of a second certificate from the second device, wherein the second certificate is a certificate of the second device.

[0412] The first processing unit is used to authenticate the identity of the second device based on the address of the second certificate.

[0413] The public key associated with the second device includes the public key of the second device stored in the second certificate.

[0414] The second device is an authentication function entity, which is deployed in at least one of the following: Application Function (AF), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Service Function (AUSF), Unified Data Management Function (UDM), Unified Data Storage (UDR), Home Subscription System (HSS), Authentication Credential Storage and Processing Function (ARPF), Bootstrapping Service Function (BSF), Security Anchor Function (SEAF), core network dedicated network elements, access network equipment, and network edge nodes.

[0415] The first message also carries the address of a third certificate, which is the certificate of the first service node to which the first device belongs, and the third certificate is used to authenticate the identity of the first service node.

[0416] The first communication unit is configured to receive a third message from the second device, wherein the third message carries the identifiers of multiple target devices.

[0417] The first message also carries the identifiers of multiple target devices.

[0418] The first device may be of one of the following types: terminal, access network device.

[0419] Each of the multiple target devices is of one of the following types: zero-power device, Internet of Things device.

[0420] Figure 10 This is a schematic diagram of the composition structure of a second device according to an embodiment of this application, including:

[0421] The second communication unit 1001 is used to receive a first message from the first device, wherein the first message carries identity information for authenticating multiple target devices.

[0422] The first message also carries group parameters, which are calculated based on the identifiers of the multiple target devices.

[0423] The identity information includes the identifier of each of the multiple target devices and one or more parameter values ​​corresponding to each target device.

[0424] like Figure 10 As shown, the second device further includes:

[0425] The second processing unit 1002 is configured to calculate the authentication value of the plurality of target devices based on the identifier of each target device in the identity information and one or more parameter values ​​corresponding to each target device; and to authenticate the plurality of target devices based on the authentication value of the plurality of target devices and the group parameter.

[0426] The first message also carries a first signature for authenticating the first device.

[0427] The second device further includes a second processing unit for authenticating the first device based on the group parameters and the first signature.

[0428] The first message also carries at least one of the following: the identifier of the first device, and the security parameters of the first device.

[0429] The second processing unit is configured to authenticate the first device based on the group parameters, the first signature, and at least one of the following parameters: the identifier of the first device, the security parameters of the first device, the identifier of the second device, a first random number, and a second random number.

[0430] The second communication unit is configured to send a second message to the first device, wherein the second message carries a second signature for authenticating the second device, the second signature being calculated based on the private key of the second device.

[0431] The second message also carries at least one of the following: the identifier of the second device, and the security parameters of the second device.

[0432] The second signature is calculated based on the private key of the second device and at least one of the following parameters: the identifier of the second device, the security parameter of the second device, the identifier of the first device, a first random number, and a second random number.

[0433] The second communication unit is used to send the first random number to the first device.

[0434] The first message also carries a second random number.

[0435] The second processing unit is configured to calculate a session key based on the security parameters of the second device and the security parameters of the first device, wherein the session key is used for communication between the first device and the second device.

[0436] The second communication unit is used to send the address of the first certificate to the first device, wherein the first certificate is the certificate of the second service node to which the second device belongs.

[0437] The second device is one of the following types: terminal, Internet of Things device, zero-power device.

[0438] The second communication unit is used to send the address of the second certificate to the first device, wherein the second certificate is the certificate of the second device.

[0439] The second device is an authentication function entity, which is deployed in at least one of the following: Application Function (AF), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Service Function (AUSF), Unified Data Management Function (UDM), Unified Data Storage (UDR), Home Subscription System (HSS), Authentication Credential Storage and Processing Function (ARPF), Bootstrapping Service Function (BSF), Security Anchor Function (SEAF), core network dedicated network elements, access network equipment, and network edge nodes.

[0440] The first message also carries the address of a third certificate, which is the certificate of the first service node to which the first device belongs.

[0441] The second processing unit is used to authenticate the identity of the first service node based on the address of the third certificate.

[0442] The second communication unit is used to send a third message to the first device, wherein the third message carries the identifiers of multiple target devices.

[0443] The first message also carries the identifiers of multiple target devices.

[0444] The first device may be of one of the following types: terminal, access network device.

[0445] The device in this application embodiment can realize the corresponding functions of the devices in the foregoing authentication method embodiments. The processes, functions, implementation methods, and beneficial effects of each module (sub-module, unit, or component, etc.) in this device can be found in the corresponding descriptions in the above method embodiments, and will not be repeated here. It should be noted that the functions described for each module (sub-module, unit, or component, etc.) in the device of this application embodiment can be implemented by different modules (sub-modules, units, or components, etc.) or by the same module (sub-module, unit, or component, etc.).

[0446] Figure 11This is a schematic structural diagram of a communication device 1100 according to an embodiment of this application. The communication device 1100 includes a processor 1110, which can call and run computer programs from memory to enable the communication device 1100 to implement the methods in the embodiments of this application.

[0447] In one possible implementation, the communication device 1100 may further include a memory 1120. The processor 1110 can retrieve and run computer programs from the memory 1120 to enable the communication device 1100 to implement the methods described in this embodiment. The memory 1120 may be a separate device independent of the processor 1110, or it may be integrated into the processor 1110.

[0448] In one possible implementation, the communication device 1100 may further include a transceiver 1130, which the processor 1110 can control to communicate with other devices. Specifically, it can send information or data to other devices or receive information or data sent by other devices. The transceiver 1130 may include a transmitter and a receiver. The transceiver 1130 may further include antennas, and the number of antennas may be one or more.

[0449] This application provides a first device, including: a processor, and a memory communicating with the processor, the memory being used to store instructions, which, when executed by the processor, cause the first device to perform: obtaining identity information of a plurality of target devices; and sending a first message to a second device, wherein the first message carries the identity information for authenticating the plurality of target devices.

[0450] The first message also carries group parameters, which are calculated based on the identifiers of the multiple target devices.

[0451] The identity information includes the identifier of each of the multiple target devices and one or more parameter values ​​corresponding to each target device.

[0452] The first message also carries a first signature for authenticating the first device, wherein the first signature is calculated based on the private key corresponding to the group parameter.

[0453] The first message also carries at least one of the following: the identifier of the first device, and the security parameters of the first device.

[0454] The first signature is calculated based on the private key corresponding to the group parameter and at least one of the following parameters: the identifier of the first device, the security parameter of the first device, the identifier of the second device, the first random number, and the second random number.

[0455] The instructions also cause the first device to perform: receiving a second message from the second device, wherein the second message carries a second signature for authenticating the second device; and authenticating the second device based on the public key associated with the second device and the second signature.

[0456] The second message also carries at least one of the following: the identifier of the second device, and the security parameters of the second device.

[0457] The instruction also causes the first device to perform the following: authenticate the second device based on the public key associated with the second device, the second signature, and at least one of the following parameters: the identifier of the second device, the security parameters of the second device, the identifier of the first device, a first random number, and a second random number.

[0458] The instruction also causes the first device to perform: receiving the first random number from the second device.

[0459] The first message also carries the second random number.

[0460] The instruction also causes the first device to perform: calculating a session key based on the security parameters of the second device and the security parameters of the first device, wherein the session key is used for communication between the first device and the second device.

[0461] The public key associated with the second device includes the identifier of the second device.

[0462] The service node to which the second device and the first device belong is the first service node; the public key related to the second device also includes the master public key of the first service node, wherein the master public key of the first service node is pre-configured.

[0463] The instruction also causes the first device to perform the following: receive the address of a first certificate from the second device, wherein the first certificate is the certificate of the second service node to which the second device belongs.

[0464] The instruction also causes the first device to perform the following: authenticate the identity of the second service node based on the address of the first certificate.

[0465] The public key associated with the second device also includes the master public key of the second service node, which is stored in the first certificate.

[0466] The second device is one of the following types: terminal, Internet of Things device, zero-power device.

[0467] The instruction also causes the first device to: receive the address of a second certificate from the second device, the second certificate being a certificate of the second device.

[0468] The instruction also causes the first device to perform the following: authenticate the identity of the second device based on the address of the second certificate.

[0469] The public key associated with the second device includes the public key of the second device stored in the second certificate.

[0470] The second device is an authentication function entity, which is deployed in at least one of the following: Application Function (AF), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Service Function (AUSF), Unified Data Management Function (UDM), Unified Data Storage (UDR), Home Subscription System (HSS), Authentication Credential Storage and Processing Function (ARPF), Bootstrapping Service Function (BSF), Security Anchor Function (SEAF), core network dedicated network elements, access network equipment, and network edge nodes.

[0471] The first message also carries the address of a third certificate, which is the certificate of the first service node to which the first device belongs, and the third certificate is used to authenticate the identity of the first service node.

[0472] The instruction also causes the first device to perform: receiving a third message from the second device, wherein the third message carries the identifiers of a plurality of target devices.

[0473] The first message also carries the identifiers of multiple target devices.

[0474] The first device may be of one of the following types: terminal, access network device.

[0475] Each of the multiple target devices is of one of the following types: zero-power device, Internet of Things device.

[0476] This application provides a second device, including: a processor, and a memory communicating with the processor, the memory being used to store instructions, which, when executed by the processor, cause the second device to perform: receiving a first message from a first device, wherein the first message carries identity information for authenticating multiple target devices.

[0477] The first message also carries group parameters, which are calculated based on the identifiers of the multiple target devices.

[0478] The identity information includes the identifier of each of the multiple target devices and one or more parameter values ​​corresponding to each target device.

[0479] The instruction also causes the second device to perform: calculating the authentication value of the plurality of target devices based on the identifier of each target device in the identity information and one or more parameter values ​​corresponding to each target device; and authenticating the plurality of target devices based on the authentication value of the plurality of target devices and the group parameter.

[0480] The first message also carries a first signature for authenticating the first device.

[0481] The instruction causes the second device to perform the following: authenticate the first device based on the group parameters and the first signature.

[0482] The first message also carries at least one of the following: the identifier of the first device, and the security parameters of the first device.

[0483] The instruction also causes the second device to perform the following: authenticate the first device based on the group parameter, the first signature, and at least one of the following parameters: the identifier of the first device, the security parameter of the first device, the identifier of the second device, a first random number, and a second random number.

[0484] The instruction also causes the second device to: send a second message to the first device, wherein the second message carries a second signature for authenticating the second device, the second signature being calculated based on the private key of the second device.

[0485] The second message also carries at least one of the following: the identifier of the second device, and the security parameters of the second device.

[0486] The second signature is calculated based on the private key of the second device and at least one of the following parameters: the identifier of the second device, the security parameter of the second device, the identifier of the first device, a first random number, and a second random number.

[0487] The instruction also causes the second device to: send the first random number to the first device.

[0488] The first message also carries a second random number.

[0489] The instruction also causes the second device to perform a calculation of a session key based on the security parameters of the second device and the security parameters of the first device, wherein the session key is used for communication between the first device and the second device.

[0490] The instruction also causes the second device to: send the address of the first certificate to the first device, wherein the first certificate is the certificate of the second service node to which the second device belongs.

[0491] The second device is one of the following types: terminal, Internet of Things device, zero-power device.

[0492] The instruction also causes the second device to: send the address of the second certificate to the first device, wherein the second certificate is the certificate of the second device.

[0493] The second device is an authentication function entity, which is deployed in at least one of the following: Application Function (AF), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Service Function (AUSF), Unified Data Management Function (UDM), Unified Data Storage (UDR), Home Subscription System (HSS), Authentication Credential Storage and Processing Function (ARPF), Bootstrapping Service Function (BSF), Security Anchor Function (SEAF), core network dedicated network elements, access network equipment, and network edge nodes.

[0494] The first message also carries the address of a third certificate, which is the certificate of the first service node to which the first device belongs.

[0495] The instruction also causes the second device to perform the following: authenticate the identity of the first service node based on the address of the third certificate.

[0496] The instruction also causes the second device to: send a third message to the first device, wherein the third message carries the identifiers of multiple target devices.

[0497] The first message also carries the identifiers of multiple target devices.

[0498] The first device may be of one of the following types: terminal, access network device.

[0499] Figure 12This is a schematic structural diagram of a chip 1200 according to an embodiment of this application. The chip 1200 includes a processor 1210, which can call and run computer programs from memory to implement the methods in the embodiments of this application. In one possible implementation, the chip 1200 may further include a memory 1220. The processor 1210 can call and run computer programs from the memory 1220 to implement the methods executed by the access network device or the core network side device in the embodiments of this application. The memory 1220 may be a separate device independent of the processor 1210, or it may be integrated into the processor 1210. In one possible implementation, the chip 1200 may further include an input interface 1230. The processor 1210 can control the input interface 1230 to communicate with other devices or chips; specifically, it can acquire information or data sent by other devices or chips. In one possible implementation, the chip 1200 may further include an output interface 1240. The processor 1210 can control the output interface 1240 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 various devices in the embodiments of this application, and the chip can implement the corresponding processes implemented by each device in the various methods of the embodiments of this application. For simplicity, further details are omitted here. It should be understood that the chip mentioned in the embodiments of this application can also be called a system-on-a-chip (SoC), system-on-a-chip (SoC), chip system, or system-on-a-chip, etc.

[0500] The processors mentioned above can be general-purpose processors, digital signal processors, off-the-shelf programmable gate arrays, application-specific integrated circuits (ASICs), or other programmable logic devices, transistor logic devices, discrete hardware components, etc. The general-purpose processors mentioned above can be microprocessors or any conventional processor. The memory mentioned above can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory, programmable read-only memory, erasable programmable read-only memory, electrically erasable programmable read-only memory, or flash memory. Volatile memory can be random access memory.

[0501] It should be understood that the above-described memory is exemplary and not a limiting description. For example, the memory in the embodiments of this application may also be static random access memory, dynamic random access memory, etc. That is to say, the memory in the embodiments of this application is intended to include, but is not limited to, these and any other suitable types of memory.

[0502] Figure 13This is a schematic block diagram of a communication system 1300 according to an embodiment of this application. The communication system 1300 includes a first device 1310 and a second device 1320. In the above embodiments, it can be implemented entirely or partially by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially 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 flow or function according to the embodiments of this application is 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. 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 wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates 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).

[0503] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply 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 this application.

[0504] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0505] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. An authentication method performed by a first device, comprising: Obtain the identity information of multiple target devices; A first message is sent to a second device, wherein the first message carries the identity information used to authenticate the plurality of target devices.

2. The method according to claim 1, wherein, The first message also carries group parameters, which are calculated based on the identifiers of the multiple target devices.

3. The method according to claim 1, wherein, The identity information includes the identifier of each of the multiple target devices and one or more parameter values ​​corresponding to each target device.

4. The method according to any one of claims 1-3, wherein, The second device is one of the following types: terminal, Internet of Things device, zero-power device.

5. The method according to any one of claims 1-4, wherein, The first device may be of one of the following types: terminal, access network device.

6. The method according to any one of claims 1-5, wherein, Each of the multiple target devices is of one of the following types: zero-power device, Internet of Things device.

7. An authentication method performed by a second device, comprising: Receive a first message from a first device, wherein the first message carries identity information for authenticating multiple target devices.

8. The method according to claim 7, wherein, The first message also carries group parameters, which are calculated based on the identifiers of the multiple target devices.

9. The method according to claim 8, wherein, The identity information includes the identifier of each of the multiple target devices and one or more parameter values ​​corresponding to each target device.

10. A first device, comprising: The first processing unit is used to obtain the identity information of multiple target devices; A first communication unit is configured to send a first message to a second device, wherein the first message carries the identity information used to authenticate the plurality of target devices.

11. The first device according to claim 10, wherein, The first message also carries group parameters, which are calculated based on the identifiers of the multiple target devices.

12. The first device according to claim 10, wherein, The identity information includes the identifier of each of the multiple target devices and one or more parameter values ​​corresponding to each target device.

13. The first device according to any one of claims 10-12, wherein, The second device is one of the following types: terminal, Internet of Things device, zero-power device.

14. The first device according to any one of claims 10-13, wherein, The first device may be of one of the following types: terminal, access network device.

15. The first device according to any one of claims 10-14, wherein, Each of the multiple target devices is of one of the following types: zero-power device, Internet of Things device.

16. A second device, comprising: The second communication unit is used to receive a first message from the first device, wherein the first message carries identity information for authenticating multiple target devices.

17. The second device according to claim 16, wherein, The first message also carries group parameters, which are calculated based on the identifiers of the multiple target devices.

18. The second device according to claim 17, wherein, The identity information includes the identifier of each of the multiple target devices and one or more parameter values ​​corresponding to each target device.

19. A first device, comprising: A transceiver, a processor, and a memory for storing a computer program, the processor for calling and running the computer program stored in the memory to cause the first device to perform the method as described in any one of claims 1 to 6.

20. A second device, comprising: A transceiver, a processor, and a memory for storing a computer program, the processor for calling and running the computer program stored in the memory to cause the second device to perform the method as described in any one of claims 7 to 9.

Images