Security implementation method, device and system, communication equipment, chip and storage medium

Abstract

The embodiment of the invention provides a security implementation method, device and system, communication equipment, a chip and a storage medium. The method comprises the steps that an issuing node receives first request information sent by a first user node; the first request information is used for requesting a first certificate; the first credential is used for verifying the identity of the first user node; under the condition that the signing and issuing node has the first permission, the signing and issuing node responds to the first request information and generates a first voucher; the first authority refers to the authority capable of generating the voucher; the first authority is granted to the signing and issuing node by the plurality of committee nodes in a combined manner.

Description

Security implementation method and device, system, communication equipment, chip, storage medium Technical Field

[0001] The embodiments of the present application relate to the field of mobile communication technology, and specifically to a security implementation method and apparatus, system, communication equipment, chip, and storage medium. Background Art

[0002] In current communication networks, device identities are typically managed using centralized identity management. Centralized identity management specifically means that a single authority manages the identity data of user devices and performs authentication and authorization based on that data.

[0003] However, as technology advances, a large number of devices will be introduced into communication networks, such as zero-power devices and integrated synaesthesia devices. If communication networks still use centralized identity management to manage device identities, it will incur significant computing and communication overhead, and authorities may not be able to promptly process each device's request, causing network service delays.

[0004] Summary of the Invention

[0005] The embodiments of the present application provide a security implementation method and apparatus, system, communication equipment, chip, and storage medium.

[0006] This embodiment of the present application provides a security implementation method, which includes:

[0007] The issuing node receives a first request message sent by the first user node; the first request message is used to request a first credential; the first credential is used to verify the identity of the first user node;

[0008] In the case where the issuing node has the first authority, the issuing node generates the first certificate in response to the first request information; the first authority refers to the authority to generate the certificate; the first authority is jointly granted to the issuing node by multiple committee nodes.

[0009] Another embodiment of the present application provides a security implementation method, the method comprising:

[0010] The blockchain node receives a second request message, the second request message being used to request storage of a first credential; the first credential being used to verify the identity of the first user node; wherein the first credential is generated by the issuing node while possessing a first authority, the first authority being the authority to generate the credential; and the first authority being granted to the issuing node by the committee node.

[0011] When the identity authentication of the first user node based on the first credential is successful, the blockchain node stores the first credential in a block.

[0012] Another embodiment of the present application provides a security implementation method, the method comprising:

[0013] The first user node sends a first request message to the issuing node, where the first request message is used to request a first credential; the first credential is used to verify the identity of the first user node.

[0014] An embodiment of the present application provides a security implementation method, the method comprising:

[0015] The third user node receives the fourth digital signature sent by the first user node;

[0016] The third user node obtains a first credential of the first user node; the first credential is generated by an issuing node with a first authority, where the first authority is the authority to generate a credential; the first authority is jointly granted to the issuing node by multiple committee nodes;

[0017] The third user node authenticates the first user node based on the first credential and the fourth digital signature.

[0018] The present embodiment provides a security implementation device, which is applied to an issuing node and includes:

[0019] A first receiving unit is configured to receive a first request message sent by a first user node, wherein the first request message is used to request a first credential, and the first credential is used to verify the identity of the first user node;

[0020] The credential generation unit is configured to generate the first credential in response to the first request information when the issuing node has a first authority; the first authority refers to the authority to generate a credential; the first authority is jointly granted to the issuing node by multiple committee nodes.

[0021] The present application provides a security implementation device, which is applied to a blockchain node and includes:

[0022] a second receiving unit configured to receive a second request message sent by the issuing node, the second request message being used to request storage of a first credential; the first credential being used to verify the identity of the first user node; wherein the first credential is generated by the issuing node when it has a first authority, the first authority being the authority to issue a credential; and the first authority being granted to the issuing node by the committee node;

[0023] A storage control unit is configured to store the first credential in a block if the identity authentication of the first user node based on the first credential is successful.

[0024] An embodiment of the present application provides a security implementation device, applied to a first user node, including:

[0025] The third sending unit is configured to send a first request message to the issuing node, where the first request message is used to request a first credential; the first credential is used to verify the identity of the first user node.

[0026] An embodiment of the present application provides a security implementation device, applied to a third user node, including:

[0027] a third receiving unit, configured to receive a fourth digital signature sent by the first user node;

[0028] The first verification unit is configured to authenticate the first user node by the third user node based on the first credential and the fourth digital signature.

[0029] The present invention provides a security implementation system, including:

[0030] The committee node is used to jointly authorize the issuing node so that the issuing node has a first authority, where the first authority is the authority to generate a credential for the user node;

[0031] The issuing node is used to manage the user node and, if the issuing node has the first authority, respond to the first request information sent by the user node to generate a credential for the user node.

[0032] An embodiment of the present application provides a communication device including a processor and a memory, wherein the memory is used to store a computer program, and the processor is used to call and run the computer program stored in the memory to execute the above-mentioned security implementation method.

[0033] The chip provided in the embodiment of the present application is used to implement the above-mentioned security implementation method.

[0034] Specifically, the chip includes: a processor for calling and running a computer program from a memory, so that a device equipped with the chip executes the above-mentioned security implementation method.

[0035] The computer-readable storage medium provided in an embodiment of the present application is used to store a computer program, which enables a computer to execute the above-mentioned security implementation method.

[0036] The computer program product provided in the embodiments of the present application includes computer program instructions, which enable a computer to execute the above-mentioned security implementation method.

[0037] The computer program provided in the embodiment of the present application, when run on a computer, enables the computer to execute the above-mentioned security implementation method.

[0038] The security implementation method provided by the embodiment of the present application can be applied to the second-layer identity management architecture of the two-layer identity management architecture. After the committee node authorizes the issuing node with the first authority, it can respond to the credential request of the user node and generate a credential for the user node. In this way, the committee node can transfer the identity management function of the user node to the issuing node, avoiding the problem of high computing and communication overhead caused by centralized identity management. In addition, when the number of user nodes increases significantly, the committee node can authorize more issuing nodes to manage the identities of more user nodes, further reducing the delay of network services. In addition, when there are a large number of user nodes, when two user nodes verify each other, the user node can obtain the credential from the blockchain node for distributed authentication, thereby improving the authentication efficiency. At the same time, the user node does not need to pre-store the credentials of multiple users, further reducing the complexity. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0040] FIG1 is a schematic diagram of an application scenario provided by an embodiment of the present application;

[0041] FIG2 is a flowchart of a security implementation method provided in an embodiment of the present application;

[0042] FIG3 is a second flow chart of a security implementation method provided in an embodiment of the present application;

[0043] FIG4 is a third flow chart of a security implementation method provided in an embodiment of the present application;

[0044] FIG5 is a fourth flow chart of a security implementation method provided in an embodiment of the present application;

[0045] FIG6 is a fifth flow chart of a security implementation method provided in an embodiment of the present application;

[0046] FIG7 is a sixth flow chart of a security implementation method provided in an embodiment of the present application;

[0047] FIG8 is a schematic diagram of the structure of an exemplary Merkle tree provided in an embodiment of the present application;

[0048] FIG9 is a schematic diagram of the structure of a security implementation device 900 provided in an embodiment of the present application;

[0049] FIG10 is a schematic diagram of the structure of a security implementation device 1000 provided in an embodiment of the present application;

[0050] FIG11 is a schematic diagram of the structure of a security implementation device 1100 provided in an embodiment of the present application;

[0051] FIG12 is a schematic diagram of the structure of a security implementation device 1200 provided in an embodiment of the present application;

[0052] FIG13 is a schematic structural diagram of a communication device provided in an embodiment of the present application;

[0053] FIG14 is a schematic structural diagram of a chip according to an embodiment of the present application. DETAILED DESCRIPTION

[0054] The following will describe the technical solutions in the embodiments of this application in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0055] It should be understood that the terms "system" and "network" are often used interchangeably in this document. The term "and / or" in this document is merely a description of the association relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this document generally indicates that the objects associated before and after are in an "or" relationship. It should also be understood that the "indication" mentioned in the embodiments of this application can be a direct indication, an indirect indication, or an indication of an association relationship. For example, A indicates B, which can mean that A directly indicates B, for example, B can be obtained through A; it can also mean that A indirectly indicates B, for example, A indicates C, and B can be obtained through C; it can also mean that there is an association relationship between A and B. It should also be understood that the "correspondence" mentioned in the embodiments of this application can mean that there is a direct or indirect correspondence between the two, or it can mean that there is an association relationship between the two, or it can mean a relationship between indication and indication, configuration and configuration, etc. It should also be understood that the “predefined” or “predefined rules” mentioned in the embodiments of the present application can be implemented by pre-saving corresponding codes, tables or other methods that can be used to indicate relevant information in devices (for example, including terminal devices and network devices), and the present application does not limit its specific implementation method. For example, predefined can refer to what is defined in the protocol. It should also be understood that in the embodiments of the present application, the “protocol” may refer to a standard protocol in the field of communications, such as LTE protocols, NR protocols, and related protocols used in future communication systems, and the present application does not limit this.

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

[0057] Current communication networks typically adopt a centralized identity management architecture. In a centralized identity management architecture, a centralized authority controls the identity data of each device in the system and performs authentication and authorization based on the device's identity data. The identity management architecture of the 3rd Generation Partnership Project (3GPP) is an example of a centralized identity management architecture, in which the operator's network element can act as an authority to manage and control the device's identity data. Specifically, the operator's Unified Data Management (UDM) network element can centrally manage the device's identity data and issue credentials to the terminal device via a Universal Subscriber Identity Module (USIM) card. The operator's network authenticates the terminal device's identity and authorizes the terminal device to access the network.

[0058] The future will feature a wide range of scenarios for integrated communication and perception, as well as zero-power communication. These scenarios will involve industries such as logistics, intelligent manufacturing, and smart home. Device identity management in these scenarios involves multiple parties, including operators, equipment manufacturers, and service providers. This necessitates the establishment of a multi-party trusted identity management model.

[0059] However, the existing centralized identity management architecture cannot meet the needs of synergy integration and zero-power scenarios. Specifically, the identity data of each device in the centralized identity management architecture, as well as the issuance and revocation of credentials, are managed and implemented by a Certificate Authority (CA) or a limited number of CAs. Due to the huge number of devices in synergy integration scenarios and zero-power scenarios, the issuance and revocation of device credentials will cause a lot of computing and communication overhead, resulting in the CA being unable to process all credential applications in a timely manner, causing network service delays. In addition, the current single-layer distributed identity management architecture adopts a consistent identity management strategy for all node management, which cannot meet the needs of personalized identity management for multiple businesses in synergy integration and zero-power scenarios. For the authentication management of massive terminals, centralized credential management is less efficient, and distributed credential management can improve authentication efficiency.

[0060] Based on this, embodiments of the present application provide a security implementation system, also known as a two-tier identity management system. As shown in Figure 1 , this two-tier identity management system includes committee nodes, issuing nodes, and user nodes. Multiple committee nodes and issuing nodes constitute the first-tier identity management system, while multiple issuing nodes and user nodes constitute the second-tier identity management system.

[0061] The members of the two-tier identity management system provided in this embodiment are defined as follows:

[0062] Committee Node: It can manage multiple issuing nodes and implement the issuance, management, and revocation of certificates for issuing nodes. The multiple committee nodes in the embodiment of the present application can be composed of CAs of authoritative institutions or representative members of the industry, such as the CA of operators or the CA of equipment manufacturers.

[0063] Issuing nodes: These nodes can manage multiple user nodes and issue, manage, and revoke credentials for these user nodes. The multiple issuing nodes in the embodiments of this application can be composed of an operator's management server, the operator's core network equipment, access network equipment, a CA server, a device manufacturer's management server, a device manufacturer's CA server, a service provider's management server, a service provider's CA server, and the like.

[0064] User node: a communication device for data interaction, which can be composed of operator core network equipment, access network equipment, various terminal devices, such as user equipment (UE), zero-power devices, sensing devices, etc.

[0065] Blockchain nodes: These nodes can store user node credentials, facilitate distributed management of user credentials, and efficiently support user authentication. They can be composed of operator core network equipment, access network equipment, edge server equipment, service provider server equipment, equipment manufacturer management server equipment, and various terminal devices, such as user equipment (UE).

[0066] The committee node can be responsible for the initialization and subsequent maintenance of the entire two-tier identity management architecture. Furthermore, multiple committee nodes can be simulated as a CA, jointly authorizing the issuing node, enabling the issuing node to issue credentials to user nodes. Given the large number of user devices and the limited number of issuing nodes, using multiple CAs to authorize issuing nodes facilitates authorization and management.

[0067] In addition, after the issuing node has been authorized by the committee node to issue certificates, it can issue corresponding certificates for its own user nodes and introduce blockchain technology to publish the generated certificates on the blockchain. As communication devices in the two-tier identity management architecture, user nodes need to continuously perform authentication, authorization and other operations when communicating with each other. For example, when two user nodes authenticate each other, one sends its own certificate to the other, and the other party verifies based on the certificate. Due to the large number of user nodes, the issuing node can manage the user node's credentials in a distributed manner, avoiding the identity data being controlled by a single centralized authority. Each user node can manage its identity data independently, avoiding the high computational and communication overhead caused by centralized identity management. At the same time, relying on blockchain technology can efficiently perform distributed identity management while also ensuring the security of identity data.

[0068] It is understandable that in the first-tier identity management architecture, the committee node can grant the issuing node the authority to issue certificates, and in the second-tier identity management architecture, the authorized issuing node can handle a large number of certificate requests from user nodes. In this way, the committee node can transfer the identity management function of the user node to the issuing node. When the number of user nodes increases significantly, the committee node can authorize more issuing nodes to manage the identities of more user nodes. In this way, the computing and communication overhead within the system can be reduced through the two-tier identity management architecture, and the authorized issuing node can issue certificates for a large number of user nodes, which can further reduce the delay of network services. The embodiment of the present application can combine the CA authorization mode and the distributed authorization mode, which can make identity management more efficient and flexible. For the authentication management of massive terminals, centralized credential management is less efficient, and distributed credential management can improve authentication efficiency.

[0069] The following details the security implementation method in the second-tier identity management architecture.

[0070] Referring to FIG2 , an embodiment of the present application provides a security implementation method, which includes but is not limited to the following steps:

[0071] Step 210: The issuing node receives a first request message sent by the first user node. The first request message is used to request a first credential, and the first credential is used to verify the identity of the first user node.

[0072] It should be understood that the issuing node can manage multiple user nodes to implement the issuance, management and revocation of certificates for multiple user nodes. In the embodiment of the present application, the first user node can be any one of the multiple user nodes managed by the issuing node.

[0073] Optionally, the first user node may send the first request information to the issuing node through a secure channel.

[0074] Optionally, the first request information may include at least one of the following information:

[0075] identification information of the first user node;

[0076] the public key of the first user node;

[0077] First service identification information; the first service identification information is used to indicate the service type supported by the first user node;

[0078] First data identification information; the first data identification information is used to indicate the data type supported by the first user node;

[0079] The first digital signature is obtained by signing other information in the first request information according to the private key of the first user node.

[0080] In the embodiment of the present application, the first user node may provide one or more services, such as positioning service, speed measurement service, health call service, environmental monitoring service, etc. In the embodiment of the present application, the first service identification information may be used to indicate the service type provided by the first user node.

[0081] Optionally, the first service identification information may be an ID of a service type, or an ID of an application server provided by the manufacturer of the first user node, or an ID of an application server provided by a service provider, which is not limited in this embodiment of the present application.

[0082] In an embodiment of the present application, the first data identification information may indicate the data type supported by the first user node, and the data type may include one or more types. Typically, the data type supported by the user node is generally related to the service supported by the user node. For example, if the service supported by the first user node is a health call service, then the data type supported by the first user node may include heart rate data, body temperature data, respiratory rate data, exercise data, blood pressure data, etc. If the service type supported by the first user node is an environmental monitoring service, then the data type supported by the first user node may include location data, wind speed data, temperature data, sunlight data, altitude data, etc. The embodiment of the present application does not limit the data type.

[0083] Step 220: When the issuing node has the first authority, the issuing node generates a first certificate in response to the first request information, wherein the first authority refers to the authority to generate a certificate, and the first authority is jointly granted to the issuing node by multiple committee nodes.

[0084] It should be understood that in the embodiment of the present application, the issuing node with the first authority can respond to the first request information and generate a first credential for the first user node. Here, the first authority refers to the authority to generate (or issue) credentials for multiple user nodes managed by the issuing node, and the first authority can be jointly granted by the committee node. In other words, after the issuing node is authorized by the committee node to have the authority to generate credentials, it can respond to the first request information sent by the user node belonging to it and generate a credential for the user node.

[0085] It can be seen from this that the security implementation method provided by the embodiment of the present application can be applied to the second-tier identity management architecture of the two-tier identity management architecture. After the committee node authorizes the issuing node with the first authority, it can respond to the credential request of the user node and generate a credential for the user node. In this way, the committee node can transfer the identity management function of the user node to the issuing node, avoiding the problem of high computing and communication overhead caused by centralized identity management. In addition, when the number of user nodes increases significantly, the committee node can authorize more issuing nodes to manage the identities of more user nodes, further reducing the delay of network services.

[0086] Optionally, after receiving the first request information, the issuing node may first verify the identity of the sender of the first request information (i.e., the first user node) to determine whether the first user node is a legitimate user. Only after determining that the first user node is a legitimate user does the issuing node generate a first credential for the first user node.

[0087] Optionally, the issuing node may use a shared key between the issuing node and the first user node to verify the identity of the first user node, or the issuing node may use the public key of the first user node to verify the identity of the first user node. This embodiment of the present application does not impose any restrictions on this.

[0088] Optionally, when the first request information includes a first digital signature, the issuing node may use the public key of the first user node to verify the first digital signature to obtain first verification information. If the first verification information is consistent with other information in the first request information except the first digital signature, the issuing node may determine that the first user device is a legitimate user. If the first verification information is inconsistent with other information in the first request information except the first digital signature, the issuing node may deem that the first user node is an illegal user and / or that the first request information has been tampered with by a third party. In this case, the issuing node may ignore the first request information and not perform further processing.

[0089] Optionally, the issuing node may maintain a public key list that stores the identification information of multiple user nodes affiliated with the issuing node, as well as the public key corresponding to each of the multiple user nodes. After receiving the first request message sent by the first user node, the issuing node may search the public key list for the public key corresponding to the identification information of the first user node. The issuing node may then verify the first digital signature in the first request message based on this public key to obtain verification information.

[0090] Optionally, if the first request information includes the public key of the first user node, the issuing node may also directly use the public key carried in the first request information to verify the first digital signature to obtain verification information. This embodiment of the application does not limit the manner in which the issuing node obtains the public key of the first user node.

[0091] It should be understood that when the verification information is consistent with other information in the first request information except the first digital signature, the issuing node can determine that the first user node is a legitimate user and the first request information has not been tampered with. At this time, the issuing node can respond to the first request information and generate a first credential for the first user node.

[0092] Optionally, if the first request information includes first service identification information and / or first data identification information, before verifying the identity of the sender of the first request information (i.e., the first user node), the issuing node can also determine whether it supports the service type indicated by the first service identification information and / or the data type indicated by the first data identification information.

[0093] The first service identification information carried in the first request message can be used to identify the service type of the data that the first user node needs to obtain. The first data identification information carried in the first request message can be used to identify the data type of the data sent by the first user node. Therefore, after receiving the first request message, the issuing node can first determine whether it supports the service type and / or data type required by the first user node.

[0094] Optionally, after receiving the first request information, the issuing node may compare the service type corresponding to the first service identification information in the first request information with the service type provided by itself. If the service type provided by the issuing node includes the service type corresponding to the first service identification information, the issuing node determines that it supports the service type indicated by the first service identification information.

[0095] Optionally, after receiving the first request information, the issuing node may compare the data type indicated by the first data identification information in the first request information with the data type provided by itself. If the data type provided by the issuing node includes the data type indicated by the first data identification information, it is determined that the issuing node supports the data type indicated by the first data identification information.

[0096] It is understandable that only after confirming that the service type and / or data type of the first user node is supported, the issuing node will initiate the identity authentication process for the sender of the first request information (i.e., the first user node), thereby generating a first credential for the first user node. If the issuing node does not support the service type indicated by the first service identification information and does not support the data type indicated by the first data identification information, the issuing node may ignore the first request information and not respond to the first request information.

[0097] It can be seen that in the security implementation method provided in the embodiment of the present application, the issuing node can also verify the identity of the first user node before responding to the first request information of the first user node, and generate a first certificate for the first user node if the identity authentication of the first user node is passed, thereby ensuring the legitimacy of the first certificate.

[0098] The following describes in detail the process of the issuing node generating the first certificate for the first user node.

[0099] In an embodiment of the present application, after the issuing node verifies the identity and other information of the first user node, it can bind its own identification, public key and other information with the relevant information of the first user node to complete the generation of the first credential.

[0100] Optionally, as shown in FIG3 , in an embodiment of the present application, generating the first credential in step 220 may also be achieved by the following steps:

[0101] Step 2201: The issuing node generates a revocation factor;

[0102] Step 2202: The issuing node generates a first certificate based on the revocation factor; the revocation factor is used to prove whether the first certificate is revoked.

[0103] It should be understood that in order to improve the issuing node's efficiency in managing user node credentials and prevent revoked credentials from being illegally used by criminals, the issuing node can generate a revocation factor for each user node when generating credentials for each user node. This allows the verifier to quickly verify whether each user node's credentials have been revoked using the revocation factor.

[0104] Optionally, the issuing node can utilize RSA accumulator technology to generate a revocation factor. In practical applications, an RSA accumulator in cryptography is a one-way membership function. An RSA accumulator can be used to identify whether an object is a member of a set without revealing the membership of the set in the process. The revocation factor corresponding to each user node's credential can be an RSA accumulator parameter.

[0105] In this way, the issuing node can bind the revocation factor, the issuing node's identification information, the public key and other information with the relevant information of the first user node to complete the generation of the first credential.

[0106] Optionally, the first credential includes at least one of the following information:

[0107] identification information of the first user node;

[0108] the public key of the first user node;

[0109] First data identification information; the first service identification information is used to indicate the service type supported by the first user node;

[0110] First service identification information; the first data identification information is used to indicate the data type supported by the first user node;

[0111] Revocation factor; the revocation factor is used to prove whether the first credential is revoked;

[0112] Identification information of the issuing node;

[0113] The public key of the issuing node;

[0114] Second digital signature: The second digital signature is obtained by signing other information in the first certificate based on the private key of the issuing node.

[0115] In one embodiment of the present application, the issuing node can implement the issuance, management, and revocation of user node credentials through a distributed identity management method. The issuing node can use blockchain technology to implement the distributed identity management of user nodes.

[0116] Optionally, after the issuing node generates the first credential for the first user node, the first credential can be stored in the blockchain using blockchain technology to achieve distributed management of the credential.

[0117] In the embodiment of the present application, the issuing node can be a node in the blockchain system. Among them, multiple issuing nodes in the two-tier identity management system provided by the embodiment of the present application can jointly build a blockchain system to achieve distributed management of user node credentials.

[0118] Referring to FIG4 , the security implementation method provided in the embodiment of the present application may further include the following steps:

[0119] Step 230: The blockchain node receives a second request message, where the second request message is used to request that the first credential be stored in a block of the blockchain system.

[0120] The second request information includes the first credential.

[0121] Optionally, after the issuing node generates the first credential for the first user node, it can access the blockchain system to request that the generated first credential be stored in the blockchain.

[0122] In which, the issuing node can send a second request message to other blockchain nodes in the blockchain system, carrying the first certificate in the second request message, to request the blockchain nodes in the blockchain system to allow the first certificate to be stored in the block of the blockchain system.

[0123] Optionally, the blockchain node receiving the second request information may include the blockchain node receiving the second request information sent by the issuing node; or the blockchain node receiving the second request information sent by the first user node. In other words, the second request information may be sent by the issuing node to the blockchain node, or by the first user node to the blockchain node. Accordingly, the blockchain node may respond to the on-chain request sent by the issuing node or to the on-chain request sent by the first user node, and this embodiment of the application is not limited to this.

[0124] It should be noted that the issuing node can also serve as a blockchain node in the blockchain system, receiving a credential upload request from a user node. Specifically, the issuing node can authenticate the user node requesting the credential upload, and after the user node's authentication is successful, store the user node's credential in the current issuing node's block.

[0125] Among them, the certificate chain request may include the certificate of the user node, and the issuing node can verify the identity of the user node based on the certificate of the user node carried in the certificate chain request.

[0126] It should be noted that when the issuing node acts as a blockchain node in the blockchain system and receives a certificate on-chain request sent by other user nodes, the certificate of the user node may be generated by the issuing node or not. This embodiment of the present application does not impose any restrictions on this.

[0127] It should be understood that the issuing node can have both the issuing function and the certificate chain function. Among them, the issuing function of the issuing node specifically means that the issuing node can respond to the certificate generation request sent by the user node, and generate a certificate for the user node after verifying at least one of the user node's business type, data type, and user identity. The certificate chain function of the issuing node specifically means that the issuing node can directly chain after generating the certificate, or it can receive the certificate chain request sent by the user node, and after the user node's identity authentication is passed (in this case, the user node's business type and / or data type may not be verified), the user node's certificate is chained.

[0128] Step 240: When the identity authentication of the first user node based on the first credential is successful, the blockchain node stores the first credential in the block.

[0129] In an embodiment of the present application, after receiving the second request information, the blockchain node can verify the identity of the first user node based on the first credential carried in the second request information.

[0130] Optionally, if the first credential is encrypted and / or integrity protected by a shared key, the shared key may be a shared key between the blockchain node and the issuing node, then the blockchain node may verify the first credential based on the shared key to determine whether the first credential has been verified.

[0131] Alternatively, if the first credential includes a second digital signature, the blockchain node may obtain the issuing node's public key and use the issuing node's public key to verify the second digital signature, obtaining second verification information. If the second verification information is consistent with the information in the first credential other than the second digital signature, the blockchain node may determine that the first credential has been verified. If the second verification information is different from the information in the first credential other than the second digital signature, the blockchain node may determine that the first credential has failed verification.

[0132] Optionally, the blockchain node can maintain a public key list that stores the identification information of each issuing node in the blockchain system (that is, each blockchain node in the blockchain) and the public key corresponding to each issuing node. After receiving the first request information, the blockchain node can search the public key list for the public key corresponding to the identification information of the issuing node that sent the first request information. The blockchain node can then verify the second digital signature in the first credential based on this public key to obtain second verification information.

[0133] Optionally, if the first credential includes the public key of the issuing node, the blockchain node may also directly use the public key carried in the first credential to verify the first digital signature to obtain the second verification information. This embodiment of the application does not limit the manner in which the blockchain node obtains the public key of the issuing node.

[0134] Optionally, when the number of blockchain nodes in the blockchain system that have successfully verified the first credential exceeds a first number, the multiple blockchain nodes that have successfully verified the first credential may, through a consensus algorithm, add the first credential to a block in the blockchain system, thereby implementing distributed storage of the first credential of the first user node. The first number may be network-configured or protocol-specified, and this embodiment of the present application does not impose any limitation thereto.

[0135] That is to say, the first credential will only be stored in the block of the blockchain system when more than a certain number of blockchain nodes in the blockchain system have successfully verified the first credential, ensuring that the blockchain nodes in the blockchain system reach a consensus on the storage of the first credential.

[0136] Optionally, as shown in FIG4 , the security implementation method provided in an embodiment of the present application may further include the following steps:

[0137] Step 250: The blockchain node sends storage location information, where the storage location information is used to indicate the storage location of the first credential in the block.

[0138] It is understandable that after the blockchain node stores the first credential in the block, the storage location of the first credential can be fed back to the issuing node through storage location information.

[0139] Optionally, if the issuing node requests that the first credential be put on the chain (that is, the second request information is sent by the issuing node), the blockchain node may send the above storage location information to the issuing node. If the first user node requests that the first credential be put on the chain (that is, the second request information is sent by the first user node), the blockchain node may send the above storage location information to the first user node.

[0140] Optionally, when the issuing node requests to put the first certificate on the chain, the above step 250 may also include the following step 260.

[0141] Step 260: The issuing node sends the first credential and / or storage location information to the first user node.

[0142] In an embodiment of the present application, after the issuing node obtains the storage location information of the first credential, it can send the first credential and / or the storage location information to the first user node. In this way, when the first user node communicates with other user nodes, it can send the first credential and / or the storage location information of the first credential to the other user nodes, allowing the other user nodes to verify the identity of the first user node based on the first credential and / or the storage location information of the first credential. This ensures data security during communication interactions between user nodes.

[0143] Optionally, in one embodiment of the present application, when the issuing node sends a second request message to the blockchain node, the first request message may also include a second credential; the second credential is used to verify whether the issuing node has the first authority, that is, the authority to generate the credential.

[0144] In an embodiment of the present application, in order to prevent a third-party attacker from impersonating the issuing node and requesting to store illegal credentials in the blockchain, the issuing node may also carry the second credential of the issuing node in the second request information to prove that it has the authority to generate (or issue) credentials for the user node.

[0145] Optionally, the second credential may include at least one of the following information:

[0146] Identification information of the issuing node;

[0147] The public key of the issuing node;

[0148] Second data identification information; the second service identification information is used to indicate the service type supported by the issuing node;

[0149] Second service identification information; the second data identification information is used to indicate the data type supported by the issuing node;

[0150] A joint public key; the joint public key is generated by the plurality of committee nodes jointly based on the private key shards of the plurality of committee nodes;

[0151] identification information of each committee node among the plurality of committee nodes;

[0152] The third digital signature is obtained by jointly signing the multiple committee nodes.

[0153] Optionally, based on the embodiment shown in FIG4 , when the second request information includes a second credential, referring to FIG5 , the following steps may be further included before step 240:

[0154] Step 270: The blockchain node verifies whether the issuing node has the first authority based on the second credential.

[0155] Step 280: When it is determined that the issuing node has the first authority, the blockchain node verifies the identity of the first user node based on the first credential.

[0156] It is understandable that the blockchain node can perform double verification. On the one hand, the blockchain node can verify whether the issuing node that sends the second request information has the authority to generate (or issue) the certificate based on the second certificate carried in the second request information. On the other hand, after determining that the issuing node has the authority to generate the certificate, the blockchain node can verify the identity of the first user node based on the first certificate in the second request information to determine whether the first user node is a trusted node. Only when the issuing node has the first authority and the identity verification of the first user node is passed, the blockchain node will respond to the second request information and store the first certificate to be stored on the chain. In this way, it is guaranteed that all the certificates stored in the block are legal, thereby improving data security.

[0157] The following details the verification process of blockchain nodes.

[0158] First, the blockchain node can verify whether the issuing node has the first authority based on the second credential in the second request information.

[0159] Optionally, if the second credential includes a third digital signature, the blockchain node can use the joint public key to verify the third digital signature and obtain third verification information. If the third verification information is consistent with the other information included in the second credential, it can be assumed that the issuing node has the first authority, that is, the authority to generate (or issue) the credential. If the third verification information is different from the other information included in the second credential, it can be assumed that the issuing node does not have the first authority. In this case, the blockchain node can refuse to respond to the first request information sent by the issuing node and not store the first credential of the first user node on the chain.

[0160] Alternatively, the third digital signature can be obtained by jointly signing multiple committee nodes using their own private key shards. In some embodiments, a blockchain node can pre-store the joint public key of multiple committee nodes in a two-tier identity management architecture. When the blockchain node receives the first request from the issuing node, it can verify the third digital signature using the pre-stored joint public key to obtain third verification information. In other embodiments, if the issuing node's second credential includes the joint public key, the issuing node can first obtain the joint public key from the second credential and use it to verify the third digital signature to obtain the third verification information.

[0161] In one example, if the third digital signature is obtained by multiple committee nodes based on the SM2 joint threshold issuance algorithm, the blockchain node can use the joint public key and the basic public parameters of the elliptic curve parameters to verify the second credential. Here, the third digital signature includes (r, s), where r and s are both integers, and the basic public parameters of the elliptic curve can include the elliptic curve base point G. The specific verification process may include the following steps:

[0162] Step 1: Calculate t = r + s. If t is 0, it means that the third digital signature has not passed the verification. If t is not 0, proceed to step 2.

[0163] Step 2: Calculate the coordinates (x, y) of the reference point in the elliptic curve, where (x, y) = s*G+t*P, where P is the joint public key.

[0164] Step 3: Calculate R = e + x. Here, e is the message digest, obtained by hashing all information in the second credential, excluding the third digital signature. R can also be understood as the third verification information.

[0165] Step 4: Verify that R and r are equal. If R=r, the second credential verification is successful and the issuing node has the first authority to generate the credential. Otherwise, the second credential verification fails and the issuing node does not have the first authority.

[0166] In another example, if the third digital signature is obtained by multiple committee nodes based on the SM2 joint threshold issuance algorithm, the blockchain node can use the joint public key and the basic public parameters of the elliptic curve to verify the second credential. Here, the third digital signature includes (r, s), where r and s are both integers, and the basic public parameters of the elliptic curve may include q and g, where q is the prime order and g is the generator corresponding to the cyclic group of the prime order q. The specific verification process may include the following steps:

[0167] Step 1: Check whether r and s are parameters in Zq.

[0168] Step 2: Calculation Where y is the joint public key and m is the message digest, which is obtained by hashing all information in the second credential except the third digital signature. R can also be understood as the third verification information.

[0169] Step 3: Verify that the hash result of R is equal to r. If they are equal, the second credential verification is confirmed to have passed, and the issuing node has the first permission to generate the credential. Otherwise, the second credential verification is determined to have failed, and the issuing node does not have the first permission.

[0170] In an embodiment of the present application, after verifying that the issuing node has the first authority based on the second credential, the blockchain node can continue to verify the identity of the first user node based on the first credential.

[0171] It should be noted that the blockchain node verifies the first credential in the same manner as described in step 240 , and for the sake of brevity, it will not be repeated here.

[0172] As can be seen from the above description, the blockchain node can obtain the public key of the issuing node from its maintained public key list and verify the second digital signature in the first credential to determine whether the first user node's identity has been authenticated. Alternatively, the blockchain node can obtain the public key of the issuing node from the first credential and verify the second digital signature to determine whether the first user node's identity has been authenticated.

[0173] In addition, the second credential may also include the public key of the issuing node. In one embodiment of the present application, if the second credential includes the public key of the issuing node, then after the blockchain node successfully verifies the second credential in step 290, it can also obtain the public key of the issuing node from the second credential and use the public key of the issuing node to verify the second digital signature in the first credential to determine whether the identity authentication of the first user node is successful.

[0174] That is, in step 290, when it is determined that the issuing node has the first authority, the identity of the first user node is verified based on the first credential, which can also be achieved in the following manner:

[0175] When determining that the issuing node has the first authority, the blockchain node obtains the public key of the issuing node from the second credential;

[0176] The first credential is verified based on the public key of the issuing node to determine whether the identity of the first user node is verified.

[0177] In other words, after successfully verifying the second credential, the blockchain node can determine that the data in the second credential is authentic and untampered. Furthermore, the blockchain node can obtain the public key of the issuing node in the second credential, which is authentic and untampered, to verify the stored first credential. This improves data security.

[0178] Optionally, in an embodiment of the present application, in step 270, the blockchain node verifies whether the issuing node has the first authority based on the second credential, which can also be achieved in the following manner:

[0179] The blockchain node determines whether the second credential is revoked;

[0180] If the second credential is not revoked, verify whether the issuing node has the first authority based on the second credential.

[0181] In an embodiment of the present application, before verifying the second certificate of the issuing node, the blockchain node also needs to verify whether the second certificate has been revoked.

[0182] In the two-tier identity management architecture provided in the embodiment of the present application, the number of issuing nodes is limited and the issuing nodes are relatively stable nodes. Therefore, the revocation status of the credentials of the issuing nodes can be managed by constructing a revocation list.

[0183] Optionally, multiple committee nodes can jointly maintain a revocation list to record the revoked credentials of issuing nodes, preventing revoked credentials from being illegally used by criminals. When a issuing node's credential is revoked, the committee node can add the issuing node's credential to the revocation list. Since all revoked issuing node credentials are added to the revocation list, when verifying a second credential, the blockchain node can first search the revocation list to check whether the second credential is on the revocation list. If the second credential is on the revocation list, it indicates that the second credential has been revoked. If the second credential is not on the revocation list, it indicates that the second credential has not been revoked.

[0184] It is understood that only when the second credential has not been revoked can the blockchain node verify whether the issuing node has the first permission based on the second credential. This can prevent the revoked credential from being illegally used by criminals, thereby improving the security of credential use.

[0185] In one embodiment of the present application, in addition to being able to generate credentials for multiple user nodes that it manages, the issuing node with the first authority can also manage the revocation of credentials of user nodes.

[0186] Due to the large number of user nodes, using traditional revocation lists to manage the revocation of issuing node credentials would incur significant computational and communication overhead. Therefore, in an embodiment of the present application, the issuing node can generate a revocation factor when generating credentials for a user node. The issuing node can use the revocation factor in each user node's credential to manage the revocation of credentials for multiple user nodes.

[0187] Optionally, each issuing node may maintain a parameter X, which may be the product of the revocation factors corresponding to all revoked user node credentials managed by the issuing node. The issuing node may use this parameter X to record the revocation factors of revoked user node credentials.

[0188] In the embodiment of the present application, each issuing node will periodically update the parameter X to ensure that the credentials of the revoked user node cannot be used any more.

[0189] Optionally, the issuing node may update the parameter X according to a time period, or the issuing node may update the parameter X when it detects that the credentials of any user node among the multiple user nodes it manages have changed. This embodiment of the present application does not impose any restrictions on this.

[0190] Optionally, in an embodiment of the present application, referring to FIG6 , the security implementation method provided in the embodiment of the present application may further include the following steps:

[0191] Step 610: The issuing node calculates auxiliary information for each second user node among the at least one second user node. The auxiliary information of each second user node is used to prove that the credential corresponding to each second user node has not been revoked. The at least one second user node is a user node whose credential has not been revoked among the multiple user nodes managed by the issuing node.

[0192] Step 620: The issuing node sends the corresponding auxiliary information to each second user node.

[0193] It should be understood that data on the blockchain will be permanently stored on the chain and will not be deleted, so a proof is required to tell the verifier that the certificate is still valid. Based on this, the issuing node can calculate auxiliary information for each user node whose certificate has not been revoked (i.e., the second user node) and send the calculated auxiliary information to the corresponding user node. In this way, the user node can use this auxiliary information to prove that its own certificate has not been revoked.

[0194] In the embodiment of the present application, the at least one second user node may include the first user node, or may not include the first user node, and the embodiment of the present application does not impose any limitation on this.

[0195] Optionally, the issuing node may calculate auxiliary information of each second user node based on parameter X, the revocation factor of each second user node, attribute parameters of the RSA accumulator, and other information, wherein the auxiliary information corresponding to different second user nodes is different.

[0196] Optionally, the issuing node may calculate auxiliary information for each second user node each time data is updated or a certificate is issued for a user node for the first time.

[0197] Exemplarily, the issuing node may calculate auxiliary information (a, d) for each second user node based on the time period of the update parameter X. When a user node applies for a credential from the issuing node, the issuing node generates the credential and then uses the information of the current, revoked credential to generate auxiliary information (a, d) for it. The issuing node may also calculate auxiliary information for each second user node when it detects a change in the credential of any of the multiple user nodes it manages, although this is not a limitation in the present embodiment.

[0198] It should be understood that when communicating with other user nodes, each second user node can send auxiliary information corresponding to the second user node to the other nodes, so that the other nodes can use this auxiliary information to quickly verify whether the current second user node's credentials have not been revoked. In this way, when there are a large number of user nodes, using auxiliary information to verify whether credentials have been revoked can effectively improve the efficiency of credential verification.

[0199] The verification process between user nodes is described in detail below.

[0200] Referring to FIG7 , an embodiment of the present application further provides a security implementation method, which includes but is not limited to the following steps:

[0201] Step 710: The third user node receives a fourth digital signature sent by the first user node; the fourth digital signature is calculated based on the private key of the first user node;

[0202] Step 720: The third user node obtains the first credential of the first user node; wherein the first credential is generated by an issuing node with a first authority, and the first authority refers to the authority to generate a credential; the first authority is jointly granted to the issuing node by multiple committee nodes.

[0203] Step 730: The third user node authenticates the first user node based on the first credential and the fourth digital signature.

[0204] It should be understood that steps 710 to 730 can be applied to scenarios in which a first user node and a third user node communicate with each other. For example, before data is transmitted between the first user node and the third user node, the third user node can use the fourth digital signature sent by the first user node to verify the identity of the first user node to prevent data from being tampered with or stolen by unauthorized parties.

[0205] In this embodiment of the present application, a third user node can serve as a credential verifier. During communication between the first and third user nodes, the first user node can provide the third user node with a fourth digital signature. This allows the third user node to verify the identity of the first user node using the fourth digital signature. Only after the first user node's identity verification is verified can the third user node communicate with the first user node, thereby ensuring the security of data transmission during communication.

[0206] The fourth digital signature is obtained by performing a signature operation on the relevant information of the first user node according to the private key of the first user node.

[0207] Optionally, the fourth digital signature is obtained by the first user node performing a signature operation on at least one of the following based on the private key of the first user node:

[0208] identification information of the first user node;

[0209] The public key of the first user node;

[0210] First service identification information; the first service identification information is used to indicate the service type supported by the first user node;

[0211] First data identification information; the first data identification information is used to indicate the data type supported by the first user node;

[0212] First certificate.

[0213] It should be understood that the first user node can use its own private key to encrypt the above information to obtain the fourth digital signature. The first user node can also first calculate the message digest of the above information and then encrypt the message digest using its own private key to obtain the fourth digital signature. This embodiment of the application does not limit the method for calculating the fourth digital signature.

[0214] In this embodiment of the present application, after receiving the fourth digital signature, the third user node may also obtain the first credential of the first user node. This first credential may be sent by the first user node to the third user node, may be pre-stored by the third user node, or may be obtained by the third user node from a storage block in the blockchain system, and this embodiment of the present application does not limit this.

[0215] Optionally, in some embodiments, the third user node obtaining the first credential of the first user node in step 720 may be implemented in the following manner:

[0216] The third user node receives the storage location information sent by the first user node; the storage location information is used to indicate the storage location of the first credential of the first user node in the block of the blockchain system.

[0217] The third user node obtains the first credential from the block based on the storage location information.

[0218] It should be understood that after the issuing node generates the first credential, it can upload the first credential to a block in the blockchain system for storage, and the issuing node can obtain the storage location information of the first credential in the block. The process of the issuing node storing the first credential on the blockchain is described in detail in the above embodiment and will not be repeated here for the sake of brevity.

[0219] In addition, when the issuing node issues the first credential to the first user node, the issuing node may send the first credential and the storage location information of the first credential to the first user node.

[0220] Based on this, before the first and third user nodes transmit data, the first user node can provide the third user node with the fourth digital signature and the storage location information of the first credential. In this way, the third user node obtains the first credential of the first user node from the block of the blockchain node based on the storage location information, and then verifies the fourth digital signature based on the first credential to determine the legitimacy of the third user node's identity.

[0221] In other words, when two user nodes authenticate each other, they can obtain each other's credentials from the blockchain node's blocks for identity authentication. This achieves distributed authentication and improves authentication efficiency. Furthermore, user nodes do not need to pre-store the credentials of other user nodes, thereby reducing computational complexity.

[0222] Optionally, the first credential includes at least one of the following:

[0223] identification information of the first user node;

[0224] The public key of the first user node;

[0225] First data identification information; the first service identification information is used to indicate the service type supported by the first user node;

[0226] First service identification information; the first data identification information is used to indicate the data type supported by the first user node;

[0227] Revocation factor; the revocation factor is used to prove whether the first credential is revoked;

[0228] Identification information of the issuing node;

[0229] The public key of the issuing node;

[0230] Second digital signature: The second digital signature is obtained by signing other information in the first certificate based on the private key of the issuing node.

[0231] It should be understood that the fourth digital signature is obtained by the first user node signing the relevant information of the first user node based on its private key. Therefore, after receiving the fourth digital signature, the third user node can use the public key of the first user node to verify the fourth digital signature.

[0232] Optionally, in some embodiments, in step 730, the third user node authenticates the first user node based on the first credential and the fourth digital signature, which can be implemented in the following manner:

[0233] The third user node obtains the public key of the first user node in the first certificate;

[0234] The third user node verifies the fourth digital signature based on the public key of the first user node to obtain fourth verification information;

[0235] The third user node authenticates the first user node based on the fourth verification information.

[0236] It is understood that the third user node can use the first user node's public key carried in the first credential to verify the fourth digital signature to obtain fourth verification information. Furthermore, the third user node can use the fourth verification information to authenticate the first user node to determine whether the first user node is a legitimate user node.

[0237] In a possible implementation, the third user node performs identity authentication on the first user node based on the fourth verification information, which can be implemented in the following manner:

[0238] When the fourth verification information is consistent with the information in the first credential, the third user node determines that the identity authentication of the first user node is successful.

[0239] It is understandable that the third user node, as the verifier, can use the storage location information sent by the first user node to obtain the first credential from the block of the blockchain node, and then use the public key in the first credential to decrypt the fourth digital signature to obtain fourth verification information. In this way, after obtaining the fourth verification information, the third user node can compare the fourth verification information with the information in the first credential. If the fourth verification information is consistent with the information in the first credential, it means that the fourth digital signature was generated by the first user node and the fourth digital signature is authentic. At this time, the third user node can determine that the first user node's identity verification has passed. Otherwise, the third user node determines that the first user node's identity verification has failed.

[0240] In another possible implementation, step 730 in which the third user node authenticates the first user node based on the first credential and the fourth digital signature may also be implemented in the following manner:

[0241] The third user node receives the reference information sent by the first user node.

[0242] The reference information includes a first value and a second value, the first value is the value of a leaf node adjacent to the leaf node corresponding to the first user node in the Merkle tree, and the second value is the value of other non-leaf nodes in the Merkle tree except the non-leaf nodes to which the leaf node corresponding to the first user node belongs; the Merkle tree is constructed by the issuing node based on the credentials of at least one second user node, and the at least one second user node is a user node whose credentials have not been revoked among the multiple user nodes managed by the issuing node; the at least one second user node includes the first user node.

[0243] Accordingly, the third user node performs identity authentication on the first user node based on the fourth verification information, which can be achieved in the following manner:

[0244] The third user node obtains the value of the root node in the Merkle tree;

[0245] The third user node generates a verification value based on the first value, the second value and the fourth verification information;

[0246] If the verification value is consistent with the value of the root node, the third user node determines that the identity authentication of the first user node is passed.

[0247] It should be understood that after the issuing node generates the first certificate, it can construct a Merkle tree based on the first certificate and the certificates of other user nodes that have not been revoked, and then determine the above-mentioned reference information based on the values ​​of the leaf nodes and non-leaf nodes in the constructed Merkle tree, and send the obtained reference information to the first user node.

[0248] The issuing node constructs the Merkle tree and determines the calculation method of the reference information as follows:

[0249] The issuing node constructs a Merkle tree based on the credentials of each second user node in the at least one second user node; wherein the value of each leaf node in the Merkle tree is determined based on the credentials of each second user node; the at least one second user node is a user node whose credentials have not been revoked among the plurality of user nodes managed by the issuing node; the at least one second user node may include the first user node;

[0250] The issuing node sends reference information to the first user node; the reference information includes a first value and a second value; wherein the first value is the value of a leaf node adjacent to the leaf node corresponding to the first user node in the Merkle tree, and the second value is the value of other non-leaf nodes in the Merkle tree except the non-leaf nodes to which the leaf node corresponding to the first user node belongs.

[0251] Optionally, the issuing node can hash the credentials of each second user node and use the hashed credentials as the value of a leaf node in the Merkle tree. The issuing node can merge the values ​​of two adjacent leaf nodes in the Merkle tree and hash the merged result to obtain a non-leaf node in the Merkle tree. The values ​​of two adjacent non-leaf nodes are further merged and hashed until the root node of the Merkle tree is obtained.

[0252] That is to say, among the multiple user nodes managed by the issuing node, each user node with an unrevoked certificate corresponds to a leaf node in the Merkle tree, and the value of the leaf node is the hash value of the certificate of the corresponding user node.

[0253] In an embodiment of the present application, the first user node is a user node whose credentials have not been revoked. The issuing node can use the values ​​of the leaf nodes adjacent to the leaf node corresponding to the first user node, as well as the values ​​of other non-leaf nodes in the Merkle tree except the non-leaf nodes to which the leaf node corresponding to the first user node belongs, as reference information.

[0254] Exemplarily, there are four user nodes with unrevoked credentials, namely user node 0, user node 1, user node 2, and user node 3. The credential generated by the issuing node for user node 0 is D0, the credential generated for user node 1 is D1, the credential generated for user node 2 is D2, and the credential generated for user node 3 is D3. The Merkle tree constructed by the issuing node based on D0-D3 is shown in FIG8 . This Merkle tree includes four leaf nodes N0-N3. The value of leaf node N0 is the hash value of D0, i.e., Hash(D0). The value of leaf node N1 is the hash value of D1, i.e., Hash(D1). Similarly, the value of leaf node N2 is Hash(D2), and the value of leaf node N3 is Hash(D3). Furthermore, the Merkle tree shown in FIG8 also includes two non-leaf nodes, N4 and N5. The value of non-leaf node N4 is the result of hashing the values ​​of leaf nodes N0 and N1 together, i.e., Hash(N0+N1). The value of non-leaf node N5 is the result of a hash operation after merging the values ​​of leaf nodes N2 and N3, i.e., Hash(N2+N3). The Merkle tree shown in FIG8 also includes a root node N6, where the value of N6 is the result of a hash operation after merging the values ​​of non-leaf nodes N4 and N5, i.e., Hash(N4+N5). The reference information of user node 0 may include the value of N1 and the value of N5, the reference information of user node 1 may include the value of N0 and the value of N5, the reference information of user node 2 may include the value of N3 and the value of N4, and the reference information of user node N3 may include the value of N2 and the value of N4.

[0255] Optionally, when updating parameter X or calculating auxiliary information (a, d) for each user node with an unrevoked certificate, the issuing node may construct a Merkle tree with the certificates of all unrevoked user nodes as leaf nodes, and determine the reference information of each unrevoked user node based on the Merkle tree.

[0256] Optionally, the issuing node may send reference information to each non-revoked user node when updating the parameter X or calculating the auxiliary information (a, d) for each user node with a non-revoked certificate.

[0257] It should be understood that in an embodiment of the present application, when the third user node needs to authenticate the first user node, the first user node can send reference information of the first user node to the third user node, so that the third user node can verify the authenticity of the fourth digital signature based on the reference information, thereby determining whether the identity of the first user node is verified.

[0258] Optionally, the issuing node may disclose the value of the root node of the Merkle tree after constructing the Merkle tree each time.

[0259] In an embodiment of the present application, the third user node can obtain the value of the root node of the Merkle tree disclosed by the issuing node. In addition, the third user node can calculate the verification value based on the first value and the second value included in the reference information, and the fourth verification information. The third user node can use the hash operation result of the fourth verification information as the value of the leaf node corresponding to the first user node, and then calculate the verification value based on the structure of the Merkle tree in combination with the first value and the second value. Among them, the process of calculating the verification value by the issuing node is similar to the process of calculating the root node of the Merkle tree, and the values ​​of two adjacent leaf nodes in the Merkle tree can be merged, and the result of the merger can be further hashed to obtain a non-leaf node in the Merkle tree. The values ​​of the two adjacent non-leaf nodes are continued to be merged, and the result of the merger can be further hashed until the verification value is obtained.

[0260] After obtaining the verification value, the third user node can compare it with the value of the root node of the Merkle tree published by the issuing node. If the two match, it indicates that the fourth digital signature was generated by the first user node and is authentic. At this point, the third user node can determine that the first user node's identity has been authenticated. Otherwise, the third user node determines that the first user node's identity has failed.

[0261] Optionally, if the fourth digital signature includes the first business identification information and / or the first data identification information, before the third user node verifies the identity of the first user node based on the first certificate and the fourth digital signature, the third user node also needs to determine whether it supports the business type indicated by the first business identification information and / or the data type indicated by the first data identification information.

[0262] Optionally, after receiving the fourth digital signature, the third user node may compare the service type corresponding to the first service identification information in the fourth digital signature with the service type provided by itself. If the service type provided by the third user node includes the service type corresponding to the first service identification information, the third user node determines that it supports the service type indicated by the first service identification information.

[0263] Optionally, after receiving the fourth digital signature, the third user node may compare the data type indicated by the first data identification information in the fourth digital signature with the data type provided by the third user node. If the data type provided by the third user node includes the data type indicated by the first data identification information, it is determined that the third user node supports the data type indicated by the first data identification information.

[0264] It is understood that only after confirming support for the service type and / or data type of the first user node will the third user node authenticate the first user node based on the first credential and the fourth digital signature. If the issuing node does not support the service type indicated by the first service identification information and does not support the data type indicated by the first data identification information, the third user node may ignore the fourth digital signature and refuse to interact with the first user node.

[0265] In one embodiment of the present application, after the third user node passes the identity authentication of the first user node based on the first certificate and the fourth digital signature, it can also verify whether the first certificate of the first user node has been revoked, that is, verify whether the first certificate is valid, to prevent the revoked certificate from being illegally used by criminals.

[0266] In this embodiment of the present application, the issuing node can generate auxiliary information (a, d) for each user node of an unrevoked credential. The auxiliary information (a, d) is calculated and generated for each unrevoked credential each time the issuing node updates data (or issues a credential for the first time), and then sent to the corresponding credential owner.

[0267] It should be noted that the specific generation process of the auxiliary information (a, d) is described in detail in the above embodiment and will not be repeated here for the sake of brevity. In addition, after generating the auxiliary information, the issuing node can send the corresponding auxiliary information to each user node whose certificate has not been revoked.

[0268] In this way, when the third user node performs identity authentication on the first user node, the first user node can send the auxiliary information of the first user node to the third user node.

[0269] Optionally, the third user node may verify whether the first credential is revoked based on the auxiliary information of the first user node. Specifically, the third user node may verify whether the first credential is revoked based on the auxiliary information, the parameter X maintained by the issuing node, and the RSA accumulator parameter.

[0270] In summary, in the second-tier identity management architecture, the issuing node can implement the issuance, revocation, and verification of user node credentials. The issuing nodes jointly maintain a blockchain for storing light node credentials. The revocation and verification of user node credentials are achieved using the RSA accumulator principle. It can be seen that when there are a large number of user nodes, when two user nodes authenticate each other, obtaining user node credentials from the blockchain node can achieve distributed authentication and improve authentication efficiency. At the same time, user nodes do not need to pre-store the credentials of multiple users, which can reduce complexity.

[0271] The preferred embodiments of the present application are described in detail above in conjunction with the accompanying drawings. However, the present application is not limited to the specific details in the above embodiments. Within the technical concept of the present application, the technical solution of the present application can be subjected to a variety of simple modifications, and these simple modifications all fall within the scope of protection of the present application. For example, the various specific technical features described in the above specific embodiments can be combined in any suitable manner without contradiction. In order to avoid unnecessary repetition, the present application will no longer describe the various possible combinations separately. For another example, the various different embodiments of the present application can also be arbitrarily combined, as long as they do not violate the idea of ​​the present application, they should also be regarded as the contents disclosed in the present application. For another example, under the premise of no conflict, the various embodiments and / or the technical features in each embodiment described in the present application can be arbitrarily combined with the prior art, and the technical solution obtained after the combination should also fall within the scope of protection of the present application.

[0272] It should also be understood that in the various method embodiments of the present application, the sequence numbers of the above-mentioned processes do not imply a precedence in the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application. In addition, in the embodiments of the present application, the terms "downlink," "uplink," and "sidelink" are used to indicate the transmission direction of signals or data, where "downlink" is used to indicate the first direction of transmission of signals or data from a site to a user equipment in a cell, "uplink" is used to indicate the second direction of transmission of signals or data from a user equipment in a cell to a site, and "sidelink" is used to indicate the third direction of transmission of signals or data from user equipment 1 to user equipment 2. For example, "downlink signal" indicates that the transmission direction of the signal is the first direction. In addition, in the embodiments of the present application, the term "and / or" is merely a description of the association relationship between associated objects, indicating that three relationships can exist. Specifically, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone. In addition, the character " / " in this document generally indicates that the associated objects are in an "or" relationship.

[0273] FIG9 is a schematic diagram of the structure of a security implementation device provided in an embodiment of the present application, which is applied to an issuing node. As shown in FIG9 , the security implementation device 900 includes:

[0274] The first receiving unit 901 is configured to receive a first request message sent by a first user node, wherein the first request message is used to request a first credential, and the first credential is used to verify the identity of the first user node;

[0275] The credential generation unit 902 is configured to generate the first credential in response to the first request information when the issuing node has the first authority; the first authority refers to the authority to generate the credential; the first authority is jointly granted to the issuing node by multiple committee nodes.

[0276] Optionally, the first request information includes at least one of the following:

[0277] identification information of the first user node;

[0278] the public key of the first user node;

[0279] First service identification information; the first service identification information is used to indicate the service type supported by the first user node;

[0280] First data identification information; the first data identification information is used to indicate the data type supported by the first user node;

[0281] The first digital signature is obtained by signing other information in the first request information according to the private key of the first user node.

[0282] Optionally, the credential generation unit 902 is further configured to generate a revocation factor; and generate the first credential based on the revocation factor, wherein the revocation factor is used to prove whether the first credential is revoked.

[0283] Optionally, the first credential includes at least one of the following information:

[0284] identification information of the first user node;

[0285] the public key of the first user node;

[0286] First data identification information; the first service identification information is used to indicate the service type supported by the first user node;

[0287] First service identification information; the first data identification information is used to indicate the data type supported by the first user node;

[0288] Revocation factor; the revocation factor is used to prove whether the first credential is revoked;

[0289] Identification information of the issuing node;

[0290] The public key of the issuing node;

[0291] Second digital signature: The second digital signature is obtained by signing other information in the first certificate based on the private key of the issuing node.

[0292] Optionally, the issuing node is a node in the blockchain system, and the security implementation device 900 also includes a first sending unit, which is configured to send a second request message to other blockchain nodes in the blockchain system; the second request message includes the first credential, and the second request message is used to request that the first credential be stored in a block of the blockchain system.

[0293] Optionally, the second request information also includes a second credential, and the second credential is used to verify whether the issuing node has the first authority.

[0294] Optionally, the second credential includes at least one of the following information:

[0295] Identification information of the issuing node;

[0296] The public key of the issuing node;

[0297] Second data identification information; the second service identification information is used to indicate the service type supported by the issuing node;

[0298] Second service identification information; the second data identification information is used to indicate the data type supported by the issuing node;

[0299] A joint public key; the joint public key is generated by the plurality of committee nodes jointly based on the private key shards of the plurality of committee nodes;

[0300] identification information of each committee node among the plurality of committee nodes;

[0301] The third digital signature is obtained by jointly signing the multiple committee nodes.

[0302] Optionally, the first receiving unit 901 is further configured to obtain storage location information; the storage location information is used to indicate a storage location of the first credential in the block;

[0303] The first sending unit is further configured to send the first credential and / or the storage location information to the first user node.

[0304] Optionally, the security implementation device 900 further includes a calculation unit configured to calculate auxiliary information of each second user node in at least one second user node; wherein the auxiliary information of each second user node is used to prove that the certificate corresponding to each second user node has not been revoked, and the at least one second user node is a user node whose certificate has not been revoked among the multiple user nodes managed by the issuing node;

[0305] The first sending unit is further configured to send the auxiliary information to each second user node.

[0306] Optionally, the security implementation device 900 further includes a Merkle tree construction unit configured to construct a Merkle tree based on the credentials corresponding to at least one second user node; the value of each leaf node in the Merkle tree is determined based on the credentials corresponding to each second user node in the at least one second user node; the at least one second user node is a user node whose credentials have not been revoked among the multiple user nodes; the at least one second user node includes the first user node;

[0307] The first sending unit is further configured to send reference information to the first user node; the reference information includes a first value and a second value; the first value is the value of a leaf node adjacent to the leaf node corresponding to the first user node in the Merkle tree, and the second value is the value of other non-leaf nodes in the Merkle tree except the non-leaf nodes to which the leaf node corresponding to the first user node belongs.

[0308] FIG10 is a second schematic diagram of the structure of a security implementation device provided in an embodiment of the present application, which is applied to a blockchain node. As shown in FIG10 , the security implementation device 1000 includes:

[0309] The second receiving unit 1001 is configured to receive a second request message, wherein the second request message is used to request storage of a first credential; the first credential is used to verify the identity of the first user node; wherein the first credential is generated by the issuing node when it has a first authority; the first authority is the authority to issue the credential; and the first authority is granted to the issuing node by the committee node;

[0310] The storage control unit 1002 is configured to store the first credential in a block if the identity authentication of the first user node based on the first credential is successful.

[0311] Optionally, the second receiving unit 1001 is further configured to receive the second request information sent by the issuing node; or receive the second request information sent by the first user node.

[0312] Optionally, the security implementation device further includes a second sending unit configured to send storage location information; the storage location information is used to indicate the storage location of the first credential in the block.

[0313] Optionally, in the case where the second request information is sent by the issuing node, the first request information further includes a second credential, and the second credential is used to verify whether the issuing node has the first authority.

[0314] Optionally, the second credential includes at least one of the following information:

[0315] Identification information of the issuing node;

[0316] The public key of the issuing node;

[0317] Second data identification information; the second service identification information is used to indicate the service type supported by the issuing node;

[0318] Second service identification information; the second data identification information is used to indicate the data type supported by the issuing node;

[0319] A joint public key; the joint public key is generated by the plurality of committee nodes jointly based on the private key shards of the plurality of committee nodes;

[0320] identification information of each committee node among the plurality of committee nodes;

[0321] The third digital signature is obtained by jointly signing the multiple committee nodes.

[0322] Optionally, the security implementation device 1000 also includes a second verification unit, which is configured to verify whether the issuing node has the first authority based on the second credential; if it is determined that the issuing node has the first authority, the identity of the first user node is verified based on the first credential.

[0323] Optionally, the second credential includes the public key of the issuing node, and the second verification unit is further configured to obtain the public key of the issuing node from the second credential when it is determined that the issuing node has the first authority; verify the first credential based on the public key of the issuing node to determine whether the identity of the first user node is verified.

[0324] Optionally, the second verification unit is further configured to determine whether the second credential is revoked; if the second credential is not revoked, verify whether the issuing node has the first authority based on the second credential.

[0325] FIG11 is a third structural diagram of a security implementation device provided in an embodiment of the present application, which is applied to a third user node. As shown in FIG11 , the security implementation device 1100 includes:

[0326] The third sending unit 1101 is configured to send a first request message to the issuing node, where the first request message is used to request a first credential; the first credential is used to verify the identity of the first user node.

[0327] Optionally, the first request information includes at least one of the following:

[0328] identification information of the first user node;

[0329] the public key of the first user node;

[0330] First service identification information; the first service identification information is used to indicate the service type supported by the first user node;

[0331] First data identification information; the first data identification information is used to indicate the data type supported by the first user node;

[0332] The first digital signature is obtained by signing other information in the first request information according to the private key of the first user node.

[0333] Optionally, the security implementation device 1100 also includes a third receiving unit, which is configured to receive the first credential and / or storage location information sent by the issuing node; the storage location information is used to indicate the storage location of the first credential in the block of the blockchain system.

[0334] Optionally, the third sending unit 1101 is further configured to send a second request message to the blockchain node, where the second request message is used to request storage of the first credential.

[0335] Optionally, the first credential includes at least one of the following information:

[0336] identification information of the first user node;

[0337] the public key of the first user node;

[0338] First data identification information; the first service identification information is used to indicate the service type supported by the first user node;

[0339] First service identification information; the first data identification information is used to indicate the data type supported by the first user node;

[0340] Revocation factor; the revocation factor is used to prove whether the first credential is revoked;

[0341] Identification information of the issuing node;

[0342] The public key of the issuing node;

[0343] Second digital signature: The second digital signature is obtained by signing other information in the first certificate based on the private key of the issuing node.

[0344] Optionally, the third receiving unit is further configured to receive auxiliary information; the auxiliary information is used to prove that the first credential corresponding to the first user node has not been revoked.

[0345] Optionally, the third receiving unit is further configured to receive reference information sent by the issuing node; the reference information includes a first value and a second value; the first value is a value of a leaf node adjacent to the leaf node corresponding to the first user node in the Merkle tree, and the second value is a value of other non-leaf nodes in the Merkle tree except for the non-leaf nodes to which the leaf node corresponding to the first user node belongs;

[0346] The Merkle tree is constructed by the issuing node based on the credentials of at least one second user node, and the at least one second user node is an unrevoked user node among the multiple user nodes managed by the issuing node; the at least one second user node includes the first user node.

[0347] Optionally, the third sending unit 1101 is further configured to send a fourth digital signature to a third user node, where the fourth digital signature is used by the third user node to verify the identity of the first user node.

[0348] Optionally, the third sending unit 1101 is further configured to send storage location information to the third user node; the storage location information is used to indicate the storage location of the first credential of the first user node in the block of the blockchain system.

[0349] Optionally, the third sending unit 1101 is further configured to send reference information to the third user node; the reference information includes a first value and a second value; the first value is a value of a leaf node adjacent to the leaf node corresponding to the first user node in the Merkle tree, and the second value is a value of other non-leaf nodes in the Merkle tree except for the non-leaf nodes to which the leaf node corresponding to the first user node belongs;

[0350] The Merkle tree is constructed by the issuing node based on the credentials of at least one second user node, and the at least one second user node is an unrevoked user node among the multiple user nodes managed by the issuing node; the at least one second user node includes the first user node.

[0351] Optionally, the third sending unit 1101 is further configured to send auxiliary information to a third user node; the auxiliary information is used to prove that the first credential corresponding to the first user node has not been revoked.

[0352] FIG12 is a third structural diagram of a security implementation device provided in an embodiment of the present application, which is applied to a third user node. As shown in FIG12 , the security implementation device 1200 includes:

[0353] The fourth receiving unit 1201 is configured to receive a fourth digital signature sent by the first user node;

[0354] The obtaining unit 1202 is configured to obtain a first credential of the first user node; the first credential is generated by an issuing node with a first authority, where the first authority is the authority to generate a credential; the first authority is jointly granted to the issuing node by multiple committee nodes;

[0355] The first verification unit 1202 is configured to authenticate the first user node based on the first credential and the fourth digital signature.

[0356] Optionally, the acquisition unit 1202 is further configured to receive storage location information sent by the first user node; the storage location information is used to indicate the storage location of the first credential of the first user node in the block of the blockchain system; based on the storage location information, obtain the first credential from the block.

[0357] Optionally, the fourth digital signature is obtained by performing a signature operation on at least one of the following based on the private key of the first user node:

[0358] identification information of the first user node;

[0359] the public key of the first user node;

[0360] First service identification information; the first service identification information is used to indicate the service type supported by the first user node;

[0361] First data identification information; the first data identification information is used to indicate the data type supported by the first user node;

[0362] the first credential.

[0363] Optionally, the first credential includes at least one of the following:

[0364] identification information of the first user node;

[0365] the public key of the first user node;

[0366] First data identification information; the first service identification information is used to indicate the service type supported by the first user node;

[0367] First service identification information; the first data identification information is used to indicate the data type supported by the first user node;

[0368] Revocation factor; the revocation factor is used to prove whether the first credential is revoked;

[0369] Identification information of the issuing node;

[0370] The public key of the issuing node;

[0371] Second digital signature: The second digital signature is obtained by signing other information in the first certificate based on the private key of the issuing node.

[0372] Optionally, the first verification unit 1203 is further configured to obtain the public key of the first user node in the first credential; verify the fourth digital signature based on the public key of the first user node to obtain fourth verification information; and authenticate the first user node based on the fourth verification information.

[0373] Optionally, the first verification unit 1203 is further configured to, when the fourth verification information is consistent with information in the first credential, determine by the third user node that the identity authentication of the first user node is successful.

[0374] Optionally, the fourth receiving unit 1201 is further configured to receive the reference information sent by the first user node; the reference information includes a first value and a second value, the first value being a value of a leaf node adjacent to the leaf node corresponding to the first user node in the Merkle tree, and the second value being a value of other non-leaf nodes in the Merkle tree except for the non-leaf nodes to which the leaf node corresponding to the first user node belongs;

[0375] The Merkle tree is constructed by the issuing node based on the credentials of at least one second user node, and the at least one second user node is an unrevoked user node among the multiple user nodes managed by the issuing node; the at least one second user node includes the first user node.

[0376] Optionally, the first verification unit 1203 is configured to obtain the value of the root node in the Merkle tree; generate a verification value based on the first value, the second value and the fourth verification information; if the verification value is consistent with the value of the root node, it is determined that the first user node identity authentication is passed.

[0377] Optionally, the fourth receiving unit 1201 is further configured to receive auxiliary information sent by the first user node;

[0378] The first verification unit 1203 is further configured to verify whether the first credential is revoked based on the auxiliary information.

[0379] Those skilled in the art should understand that the relevant description of the above-mentioned security implementation device in the embodiment of the present application can be understood with reference to the relevant description of the security implementation method in the embodiment of the present application.

[0380] Figure 13 is a schematic diagram of a communication device 1300 provided in an embodiment of the present application. The communication device can be a terminal device or a network device. The communication device 1300 shown in Figure 13 includes a processor 1310, which can call and execute a computer program from a memory to implement the method in the embodiment of the present application.

[0381] Optionally, as shown in FIG13 , the communication device 1300 may further include a memory 1320. The processor 1310 may call and execute a computer program from the memory 1320 to implement the method in the embodiment of the present application.

[0382] The memory 1320 may be a separate device independent of the processor 1310 , or may be integrated into the processor 1310 .

[0383] Optionally, as shown in FIG13 , the communication device 1300 may further include a transceiver 1330 , and the processor 1310 may control the transceiver 1330 to communicate with other devices, specifically, to send information or data to other devices, or to receive information or data sent by other devices.

[0384] The transceiver 1330 may include a transmitter and a receiver. The transceiver 1330 may further include an antenna, and the number of antennas may be one or more.

[0385] Optionally, the communication device 1300 may specifically be the issuing node of the embodiment of the present application, and the communication device 1300 may implement the corresponding processes implemented by the issuing node in each method of the embodiment of the present application. For the sake of brevity, they will not be repeated here.

[0386] Optionally, the communication device 1300 may specifically be a blockchain node in an embodiment of the present application, and the communication device 1300 may implement the corresponding processes implemented by the blockchain node in each method of the embodiment of the present application. For the sake of brevity, they will not be repeated here.

[0387] Optionally, the communication device 1300 may specifically be the third user node of the embodiment of the present application, and the communication device 1300 may implement the corresponding processes implemented by the third user node in each method of the embodiment of the present application. For the sake of brevity, they will not be repeated here.

[0388] Figure 14 is a schematic structural diagram of a chip according to an embodiment of the present application. The chip 1400 shown in Figure 14 includes a processor 1410, which can call and run a computer program from a memory to implement the method according to the embodiment of the present application.

[0389] Optionally, as shown in FIG14 , the chip 1400 may further include a memory 1420 , wherein the processor 1410 may call and execute a computer program from the memory 1420 to implement the method in the embodiment of the present application.

[0390] The memory 1420 may be a separate device independent of the processor 1410 , or may be integrated into the processor 1410 .

[0391] Optionally, the chip 1400 may further include an input interface 1430. The processor 1410 may control the input interface 1430 to communicate with other devices or chips, and specifically, may obtain information or data sent by other devices or chips.

[0392] Optionally, the chip 1400 may further include an output interface 1440. The processor 1410 may control the output interface 1440 to communicate with other devices or chips, and specifically, may output information or data to other devices or chips.

[0393] Optionally, the chip can be applied to the issuing node in the embodiments of the present application, and the chip can implement the corresponding processes implemented by the issuing node in each method of the embodiments of the present application. For the sake of brevity, they will not be repeated here.

[0394] Optionally, the chip can be applied to the blockchain node in the embodiments of the present application, and the chip can implement the corresponding processes implemented by the blockchain node in the various methods of the embodiments of the present application. For the sake of brevity, they will not be described here.

[0395] Optionally, the chip can be applied to the third user node in the embodiment of the present application, and the chip can implement the corresponding processes implemented by the third user node in each method of the embodiment of the present application. For the sake of brevity, it will not be repeated here.

[0396] It should be understood that the chip mentioned in the embodiments of the present application can also be called a system-level chip, a system chip, a chip system or a system-on-chip chip, etc.

[0397] It should be understood that the processor of the embodiments of the present application may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method embodiment can be completed by hardware integrated logic circuits in the processor or software instructions. The above processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The various methods, steps, and logic block diagrams disclosed in the embodiments of the present application can be implemented or executed. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of the present application can be directly embodied as being executed by a hardware decoding processor, or can be executed by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium mature in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.

[0398] It is understood that the memory in the embodiments of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct RAM bus random access memory (DR RAM). It should be noted that the memory of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0399] It should be understood that the above-mentioned memories are exemplary but not restrictive. For example, the memories in the embodiments of the present application may also be static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct RAM RAM (DR RAM), etc. In other words, the memories in the embodiments of the present application are intended to include, but are not limited to, these and any other suitable types of memories.

[0400] An embodiment of the present application also provides a computer-readable storage medium for storing a computer program.

[0401] Optionally, the computer-readable storage medium can be applied to the network device in the embodiments of the present application, and the computer program enables the computer to execute the corresponding processes implemented by the network device in the various methods of the embodiments of the present application. For the sake of brevity, they are not repeated here.

[0402] Optionally, the computer-readable storage medium can be applied to the mobile terminal / terminal device in the embodiments of the present application, and the computer program enables the computer to execute the corresponding processes implemented by the mobile terminal / terminal device in the various methods of the embodiments of the present application. For the sake of brevity, they will not be repeated here.

[0403] An embodiment of the present application also provides a computer program product, including computer program instructions.

[0404] Optionally, the computer program product can be applied to the network device in the embodiments of the present application, and the computer program instructions enable the computer to execute the corresponding processes implemented by the network device in the various methods of the embodiments of the present application. For the sake of brevity, they are not repeated here.

[0405] Optionally, the computer program product can be applied to the mobile terminal / terminal device in the embodiments of the present application, and the computer program instructions enable the computer to execute the corresponding processes implemented by the mobile terminal / terminal device in the various methods of the embodiments of the present application. For the sake of brevity, they will not be repeated here.

[0406] The embodiment of the present application also provides a computer program.

[0407] Optionally, the computer program can be applied to the network device in the embodiments of the present application. When the computer program runs on a computer, the computer executes the corresponding processes implemented by the network device in the various methods of the embodiments of the present application. For the sake of brevity, they are not described here.

[0408] Optionally, the computer program can be applied to the mobile terminal / terminal device in the embodiments of the present application. When the computer program runs on the computer, the computer executes the corresponding processes implemented by the mobile terminal / terminal device in the various methods of the embodiments of the present application. For the sake of brevity, they will not be repeated here.

[0409] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

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

[0411] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0412] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0413] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0414] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

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

Claims

1. A security implementation method, comprising: The issuing node receives the first request information sent by the first user node; The first request information is used to request a first credential; The first credential is used to verify the identity of the first user node; In a case where the issuing node has the first authority, the issuing node generates the first credential in response to the first request information; The first permission refers to the permission to generate credentials; The first authority is jointly granted to the issuing node by multiple committee nodes.

2. The method according to claim 1, wherein The first request information includes at least one of the following: identification information of the first user node; the public key of the first user node; First service identification information; the first service identification information is used to indicate the service type supported by the first user node; first data identification information; The first data identification information is used to indicate the data type supported by the first user node; The first digital signature is obtained by signing other information in the first request information according to the private key of the first user node.

3. The method according to claim 1 or 2, wherein: The generating of the first credential includes: The issuing node generates a revocation factor; The issuing node generates the first certificate based on the revocation factor, where the revocation factor is used to prove whether the first certificate is revoked.

4. The method according to any one of claims 1 to 3, wherein: The first credential includes at least one of the following information: identification information of the first user node; the public key of the first user node; First data identification information; the first service identification information is used to indicate the service type supported by the first user node; First service identification information; the first data identification information is used to indicate the data type supported by the first user node; Undo factor; The revocation factor is used to prove whether the first credential is revoked; Identification information of the issuing node; The public key of the issuing node; Second digital signature: The second digital signature is obtained by signing other information in the first certificate based on the private key of the issuing node.

5. The method according to any one of claims 1 to 4, wherein: The issuing node is a node in the blockchain system, and the method further includes: The issuing node sends a second request message to other blockchain nodes in the blockchain system; the second request message includes the first credential, and the second request message is used to request that the first credential be stored in a block of the blockchain system.

6. The method according to claim 5, wherein: The second request information also includes a second credential, and the second credential is used to verify whether the issuing node has the first authority.

7. The method according to claim 6, wherein: The second credential includes at least one of the following information: Identification information of the issuing node; The public key of the issuing node; Second data identification information; the second service identification information is used to indicate the service type supported by the issuing node; Second service identification information; the second data identification information is used to indicate the data type supported by the issuing node; Joint public key; The joint public key is jointly generated by the multiple committee nodes based on the private key shards of the multiple committee nodes; identification information of each committee node among the plurality of committee nodes; The third digital signature is obtained by jointly signing the multiple committee nodes.

8. The method according to any one of claims 5 to 7, wherein: Also includes: The issuing node obtains storage location information; The storage location information is used to indicate the storage location of the first credential in the block; The issuing node sends the first credential and / or the storage location information to the first user node.

9. The method according to any one of claims 1 to 8, wherein: Also includes: The issuing node calculates auxiliary information for each second user node among the at least one second user node; wherein the auxiliary information of each second user node is used to prove that the credential corresponding to each second user node has not been revoked, and the at least one second user node is a user node whose credential has not been revoked among the multiple user nodes managed by the issuing node; The issuing node sends the auxiliary information to each second user node.

10. The method according to any one of claims 1 to 9, wherein: Also includes: The issuing node constructs a Merkle tree based on the credentials corresponding to at least one second user node; the value of each leaf node in the Merkle tree is determined based on the credentials corresponding to each second user node in the at least one second user node; the at least one second user node is a user node whose credentials have not been revoked among the multiple user nodes; the at least one second user node includes the first user node; The issuing node sends reference information to the first user node; The reference information includes a first value and a second value; The first value is a value of a leaf node adjacent to the leaf node corresponding to the first user node in the Merkle tree, and the second value is a value of other non-leaf nodes in the Merkle tree except the non-leaf nodes to which the leaf node corresponding to the first user node belongs.

11. A security implementation method, comprising: The blockchain node receives second request information, where the second request information is used to request storage of the first credential; The first credential is used to verify the identity of the first user node; wherein the first credential is generated by the issuing node when it has the first authority, and the first authority refers to the authority to generate the credential; the first authority is granted to the issuing node by the committee node; When the identity authentication of the first user node based on the first credential is successful, the blockchain node stores the first credential in a block.

12. The method according to claim 11, wherein The blockchain node receives the second request information, including: The blockchain node receives the second request information sent by the issuing node; Alternatively, the blockchain node receives the second request information sent by the first user node.

13. The method according to claim 11 or 12, wherein: Also includes: The blockchain node sends storage location information; The storage location information is used to indicate a storage location of the first credential in the block.

14. The method according to any one of claims 11 to 13, wherein: In the case where the second request information is sent by the issuing node, the second request information further includes a second credential, and the second credential is used to verify whether the issuing node has the first authority.

15. The method according to claim 14, wherein The second credential includes at least one of the following information: Identification information of the issuing node; The public key of the issuing node; Second data identification information; the second service identification information is used to indicate the service type supported by the issuing node; Second service identification information; the second data identification information is used to indicate the data type supported by the issuing node; Joint public key; The joint public key is jointly generated by the multiple committee nodes based on the private key shards of the multiple committee nodes; identification information of each committee node among the plurality of committee nodes; The third digital signature is obtained by jointly signing the multiple committee nodes.

16. The method according to claim 14 or 15, wherein: Also includes: The blockchain node verifies, based on the second credential, whether the issuing node has the first authority; In a case where it is determined that the issuing node has the first authority, the identity of the first user node is verified based on the first credential.

17. The method according to claim 16, wherein The second credential includes the public key of the issuing node, and when it is determined that the issuing node has the first authority, verifying the identity of the first user node based on the first credential includes: When it is determined that the issuing node has the first authority, obtaining the public key of the issuing node from the second credential; The first credential is verified based on the public key of the issuing node to determine whether the identity of the first user node is verified.

18. The method according to claim 16 or 17, wherein The blockchain node verifies, based on the second credential, whether the issuing node has the first authority, further comprising: Determining, by the blockchain node, whether the second credential is revoked; If the second credential has not been revoked, verify whether the issuing node has the first authority based on the second credential.

19. A security implementation method, the method comprising: The first user node sends a first request message to the issuing node, where the first request message is used to request a first credential; The first credential is used to verify the identity of the first user node.

20. The method according to claim 19, wherein The first request information includes at least one of the following: identification information of the first user node; the public key of the first user node; First service identification information; the first service identification information is used to indicate the service type supported by the first user node; first data identification information; The first data identification information is used to indicate the data type supported by the first user node; The first digital signature is obtained by signing other information in the first request information according to the private key of the first user node.

21. The method according to claim 19 or 20, wherein Also includes: The first user node receives the first credential and / or storage location information sent by the issuing node; The storage location information is used to indicate the storage location of the first credential in a block of the blockchain system.

22. The method according to any one of claims 20, wherein: Also includes: The first user sends a second request message to the blockchain node, where the second request message is used to request storage of the first credential.

23. The method according to any one of claims 19 to 22, wherein: The first credential includes at least one of the following information: identification information of the first user node; the public key of the first user node; First data identification information; the first service identification information is used to indicate the service type supported by the first user node; First service identification information; the first data identification information is used to indicate the data type supported by the first user node; Undo factor; The revocation factor is used to prove whether the first credential is revoked; Identification information of the issuing node; The public key of the issuing node; Second digital signature: The second digital signature is obtained by signing other information in the first certificate based on the private key of the issuing node.

24. The method according to any one of claims 19 to 23, wherein: Also includes: The first user node receives auxiliary information; The auxiliary information is used to prove that the first certificate corresponding to the first user node has not been revoked.

25. The method according to any one of claims 19 to 24, wherein: Also includes: The first user node receives the reference information sent by the issuing node; The reference information includes a first value and a second value; The first value is a value of a leaf node adjacent to the leaf node corresponding to the first user node in the Merkle tree, and the second value is a value of other non-leaf nodes in the Merkle tree except for the non-leaf nodes to which the leaf node corresponding to the first user node belongs; The Merkle tree is constructed by the issuing node based on the credentials of at least one second user node, and the at least one second user node is an unrevoked user node among the multiple user nodes managed by the issuing node; The at least one second user node includes the first user node.

26. The method according to any one of claims 19 to 25, wherein: Also includes: The first user node sends a fourth digital signature to a third user node, where the fourth digital signature is used by the third user node to verify the identity of the first user node.

27. The method according to claim 26, wherein Also includes: The first user node sends storage location information to the third user node; The storage location information is used to indicate the storage location of the first credential of the first user node in a block of the blockchain system.

28. The method according to claim 26 or 27, wherein Also includes: The first user node sends reference information to the third user node; The reference information includes a first value and a second value; The first value is a value of a leaf node adjacent to the leaf node corresponding to the first user node in the Merkle tree, and the second value is a value of other non-leaf nodes in the Merkle tree except for the non-leaf nodes to which the leaf node corresponding to the first user node belongs; The Merkle tree is constructed by the issuing node based on the credentials of at least one second user node, and the at least one second user node is an unrevoked user node among the multiple user nodes managed by the issuing node; The at least one second user node includes the first user node.

29. The method according to any one of claims 19 to 28, wherein: Also includes: The first user node sends auxiliary information to the third user node; The auxiliary information is used to prove that the first certificate corresponding to the first user node has not been revoked.

30. A security implementation method, the method comprising: The third user node receives the fourth digital signature sent by the first user node; The third user node obtains the first credential of the first user node; The first credential is generated by an issuing node with a first authority, where the first authority refers to the authority to generate a credential; The first authority is jointly granted to the issuing node by multiple committee nodes; The third user node authenticates the first user node based on the first credential and the fourth digital signature.

31. The method according to claim 30, wherein The third user node obtains the first credential of the first user node, including: The third user node receives the storage location information sent by the first user node; the storage location information is used to indicate the storage location of the first credential of the first user node in the block of the blockchain system; The third user node obtains the first credential from the block based on the storage location information.

32. The method according to claim 30 or 31, wherein The fourth digital signature is obtained by performing a signature operation on at least one of the following based on the private key of the first user node: identification information of the first user node; the public key of the first user node; First service identification information; the first service identification information is used to indicate the service type supported by the first user node; first data identification information; The first data identification information is used to indicate the data type supported by the first user node; the first credential.

33. The method according to any one of claims 30 to 32, wherein: The first credential includes at least one of the following: identification information of the first user node; the public key of the first user node; First data identification information; the first service identification information is used to indicate the service type supported by the first user node; First service identification information; the first data identification information is used to indicate the data type supported by the first user node; Undo factor; The revocation factor is used to prove whether the first credential is revoked; Identification information of the issuing node; The public key of the issuing node; Second digital signature: The second digital signature is obtained by signing other information in the first certificate based on the private key of the issuing node.

34. The method according to any one of claims 30 to 33, wherein: The third user node authenticates the first user node based on the first credential and the fourth digital signature, including: The third user node obtains the public key of the first user node in the first credential; The third user node verifies the fourth digital signature based on the public key of the first user node to obtain fourth verification information; The third user node authenticates the first user node based on the fourth verification information.

35. The method according to claim 34, wherein The third user node performs identity authentication on the first user node based on the fourth verification information, including: When the fourth verification information is consistent with the information in the first credential, the third user node determines that the identity authentication of the first user node is successful.

36. The method of claim 34, wherein: Before the third user node authenticates the first user node based on the first credential and the fourth digital signature, the method further includes: The third user node receives the reference information sent by the first user node, wherein the reference information includes a first value and a second value, wherein the first value is a value of a leaf node adjacent to the leaf node corresponding to the first user node in the Merkle tree, and the second value is a value of a non-leaf node in the Merkle tree except for the non-leaf node to which the leaf node corresponding to the first user node belongs; The Merkle tree is constructed by the issuing node based on the credentials of at least one second user node, and the at least one second user node is an unrevoked user node among the multiple user nodes managed by the issuing node; the at least one second user node includes the first user node.

37. The method according to claim 36, wherein The third user node performs identity authentication on the first user node based on the fourth verification information, including: The third user node obtains the value of the root node in the Merkle tree; The third user node generates a verification value based on the first value, the second value and the fourth verification information; If the verification value is consistent with the value of the root node, the third user node determines that the identity authentication of the first user node is passed.

38. The method according to any one of claims 30 to 37, wherein: After the third user node determines that the identity authentication of the first user node has passed, the method further includes: The third user node receives the auxiliary information sent by the first user node; The third user node verifies whether the first credential is revoked based on the auxiliary information.

39. A security implementation system comprising: Committee nodes, issuing nodes and user nodes; among them, The committee node is used to jointly authorize the issuing node so that the issuing node has a first authority, where the first authority is the authority to generate a credential for the user node; The issuing node is used to manage the user node and, if the issuing node has the first authority, respond to the first request information sent by the user node to generate a credential for the user node.

40. A security implementation device, applied to an issuing node, comprising: A first receiving unit is configured to receive first request information sent by a first user node; The first request information is used to request a first credential; The first credential is used to verify the identity of the first user node; a credential generating unit, configured to generate the first credential in response to the first request information if the issuing node has the first authority; The first permission refers to the permission to generate credentials; The first authority is jointly granted to the issuing node by multiple committee nodes.

41. A security implementation device, applied to a blockchain node, comprising: A second receiving unit is configured to receive second request information sent by the issuing node, where the second request information is used to request storage of the first credential; The first credential is used to verify the identity of the first user node; wherein the first credential is generated by the issuing node when it has the first authority, and the first authority refers to the authority to issue the credential; the first authority is granted to the issuing node by the committee node; A storage control unit is configured to store the first credential in a block if the identity authentication of the first user node based on the first credential is successful.

42. A security implementation device, applied to a first user node, comprising: A third sending unit is configured to send a first request message to the issuing node, where the first request message is used to request a first credential; The first credential is used to verify the identity of the first user node.

43. A security implementation device, applied to a third user node, comprising: a third receiving unit, configured to receive a fourth digital signature sent by the first user node; an acquiring unit, configured to acquire a first credential of the first user node; The first credential is generated by an issuing node with a first authority, where the first authority refers to the authority to generate a credential; The first authority is jointly granted to the issuing node by multiple committee nodes; The first verification unit is configured to authenticate the first user node based on the first credential and the fourth digital signature.

44. A communication device comprising: A processor and a memory, the memory being used to store a computer program, the processor being used to call and run the computer program stored in the memory to execute the method according to any one of claims 1 to 10.

45. A communication device comprising: A processor and a memory, the memory being used to store a computer program, the processor being used to call and run the computer program stored in the memory to execute the method according to any one of claims 11 to 18.

46. ​​A communication device comprising: A processor and a memory, the memory being used to store a computer program, the processor being used to call and run the computer program stored in the memory to execute the method according to any one of claims 19 to 29.

47. A communication device comprising: A processor and a memory, the memory being used to store a computer program, the processor being used to call and run the computer program stored in the memory to execute the method according to any one of claims 30 to 38.

48. A chip comprising: A processor, configured to call and run a computer program from a memory, so that a device equipped with the chip executes the method according to any one of claims 1 to 10.

49. A chip comprising: A processor, configured to call and execute a computer program from a memory, so that a device equipped with the chip executes the method according to any one of claims 11 to 18.

50. A chip, comprising: A processor, configured to call and execute a computer program from a memory, so that a device equipped with the chip executes the method according to any one of claims 19 to 29.

51. A chip, comprising: A processor, configured to call and execute a computer program from a memory, so that a device equipped with the chip executes the method according to any one of claims 30 to 38.

52. A computer-readable storage medium for storing a computer program, wherein the computer program causes a computer to execute the method according to any one of claims 1 to 10.

53. A computer-readable storage medium for storing a computer program, wherein the computer program causes a computer to execute the method according to any one of claims 11 to 18.

54. A computer-readable storage medium for storing a computer program, wherein the computer program causes a computer to execute the method according to any one of claims 19 to 29.

55. A computer-readable storage medium for storing a computer program, wherein the computer program causes a computer to execute the method according to any one of claims 30 to 38.

56. A computer program product comprising computer program instructions for causing a computer to perform the method of any one of claims 1 to 10.

57. A computer program product comprising computer program instructions for causing a computer to perform the method of any one of claims 11 to 18.

58. A computer program product comprising computer program instructions for causing a computer to perform the method of any one of claims 19 to 29.

59. A computer program product comprising computer program instructions for causing a computer to perform the method of any one of claims 30 to 38.

60. A computer program causing a computer to perform the method according to any one of claims 1 to 10.

61. A computer program causing a computer to perform the method of any one of claims 11 to 18.

62. A computer program causing a computer to perform the method of any one of claims 19 to 29.

63. A computer program causing a computer to perform the method of any one of claims 30 to 38.

Images