Certificate verification method and apparatus

Abstract

The present application relates to the technical field of communications, and particularly relates to a certificate verification method and apparatus, so as to support cross-industry and cross-field verification of a certificate. The method comprises: receiving first distributed ledger record information from a first entity, wherein the first distributed ledger record information indicates a distributed ledger address and / or a verification path of a first certificate of the first entity; on the basis of the first distributed ledger record information, verifying whether the first certificate is published on a distributed ledger; and sending a verification result to the first entity, wherein the verification result is determined on the basis of whether the first certificate is published on the distributed ledger.

Description

A method and apparatus for verifying credentials

[0001] Cross-reference to related applications

[0002] This application claims priority to Chinese Patent Application No. 202410794469.0, filed on June 18, 2024, entitled "A Method for Verifying Credentials", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of communication technology, and in particular to a credential verification method and apparatus. Background Technology

[0004] Public Key Infrastructure (PKI) is an infrastructure that provides information security services using public key theory and technology. It is a crucial component of information security infrastructure and a universally applicable network security infrastructure. Its core purpose is to solve the trust problem in cyberspace, ensuring the uniqueness, authenticity, and legitimacy of the identities of actors (including organizations and individuals) and protecting the security interests of various actors in cyberspace. However, existing PKI systems also have security risks. First, their core implementing bodies, Certificate Authorities (CAs), are centralized nodes, and attacks on CAs causing single points of failure are frequent. Second, because different entities build their own trust systems, different CAs form many isolated trust domains, leading to inefficient credential authentication. A single user often needs to hold credentials issued by multiple CAs simultaneously to meet authentication requirements in different scenarios. Furthermore, cross-CA credential verification requires additional means, such as third-party bridging and the issuance of mutually trusted credentials.

[0005] Therefore, how to support the verifiability of credentials across industries and fields is a problem that needs to be solved. Summary of the Invention

[0006] This application provides a credential verification method and apparatus to support the cross-industry and cross-domain verifiability of credentials.

[0007] In a first aspect, embodiments of this application provide a credential verification method, which can be executed by a second entity. The method includes: receiving first distributed ledger record information from a first entity, the first distributed ledger record information indicating the distributed ledger address and / or verification path of a first credential of the first entity; verifying whether the first credential is published on the distributed ledger based on the first distributed ledger record information; and sending a verification result to the first entity, the verification result being determined based on whether the first credential is published on the distributed ledger.

[0008] In the aforementioned credential verification method, the first entity and the second entity can be two different devices (or apparatuses) in the communication network. Possible implementations of the first entity (or second entity) include: terminal equipment, network equipment, network function (NF) entity, or server; components (e.g., processors, chips, or chip systems) within the terminal equipment, network equipment, NF entity, or server; logical modules or software implementing some or all of the functions of the terminal equipment, network equipment, NF entity, or server; or apparatus used in conjunction with the terminal equipment, network equipment, NF entity, or server. For example: the first entity can be an NF entity in the core network, and the second entity can be another NF entity in the core network; or the first entity can be an access network device, and the second entity can be an NF entity in the core network; or the first entity can be an access network device, and the second entity can be another access network device; or the first entity can be a terminal equipment, and the second entity can be an access network device, etc.

[0009] Using the methods described above, distributed ledger technology (such as blockchain technology) can be used to build a multi-party trust mechanism across industries and fields (for example, a distributed ledger can be built using issuing institutions from different fields such as social authorities and operators as infrastructure). The issuer can publish the certificate to the distributed ledger and provide the certificate's distributed ledger record information to the certificate holder (such as the first entity). The certificate verifier (such as the second entity) can verify the certificate through the multi-party trust distributed ledger based on the certificate's distributed ledger record information, thereby supporting the cross-industry and cross-field verifiability of the certificate.

[0010] In addition, the issuer publishes the certificate to the distributed ledger, and the certificate and the certificate publication time can be found on the distributed ledger, which can realize the tracing and management of maliciously issued certificates.

[0011] In one possible design, the method further includes: receiving credential status service information from a first entity, the credential status service information indicating a smart contract for credential query; invoking the smart contract to query the status information of the first credential, the status information including whether the first credential has been revoked; wherein the verification result is further determined based on whether the first credential has been revoked.

[0012] By publishing credentials to the distributed ledger, smart contracts can be invoked to query credential status information. This avoids the need for the second entity (verifier) ​​to download and store the certificate revocation list (CRL) before querying credential status information, thus reducing the storage overhead for the second entity.

[0013] In one possible design, the method further includes: receiving the identifier of the issuing entity of the first credential from the first entity; invoking a smart contract to query the second credential of the issuing entity based on the identifier of the issuing entity; verifying the first credential through the second credential; wherein the verification result is further determined based on whether the first credential is verified successfully through the second credential.

[0014] By publishing credentials to the distributed ledger, a second entity (verifier) ​​can call a smart contract to query the second credential of the issuing entity based on the identifier of the issuing entity of the first credential from the first entity. This avoids the problem that the second entity needs to pre-configure a list of trusted root credentials to complete authentication, and reduces the storage overhead of the second entity.

[0015] In one possible design, the method further includes: receiving the identifier of the issuing entity of the first document from the first entity or the second distributed ledger record information of the second document of the issuing entity; obtaining the second document from the distributed ledger based on the identifier of the issuing entity or the second distributed ledger record information; verifying the first document through the second document; wherein the verification result is further determined based on whether the first document passes the verification through the second document.

[0016] The above design allows a second entity (verifier) ​​to obtain the second credential of the issuing entity from the distributed ledger based on the identifier of the issuing entity or the second distributed ledger record information of the second credential of the issuing entity. This avoids the problem that the second entity needs to pre-configure a list of trusted root credentials to complete authentication and reduces the storage overhead of the second entity.

[0017] In one possible design, the information recorded in the first distributed ledger includes at least one of the following: the distributed ledger identifier, block identifier, transaction identifier, or verification path.

[0018] The above design enables the first credential to be verifiable on the distributed ledger.

[0019] In one possible design, the information recorded in the first distributed ledger is carried in the first voucher.

[0020] The above design allows for the modification of voucher formats or content, enabling vouchers to carry their corresponding distributed ledger record information, which is beneficial for supporting the cross-industry and cross-domain verifiability of vouchers.

[0021] In one possible design, the first credential may also include one or more of the following: credential status service information, the identifier of the issuing entity of the first credential, or the second distributed ledger record information of the second credential of the issuing entity.

[0022] The above design allows for modifications to the voucher format or content, enabling the verifier to access the voucher of the issuing entity (i.e., the root voucher) and the voucher's status information.

[0023] In one possible design, the method further includes: receiving an identifier of a first credential from a first entity; retrieving the first credential from a distributed ledger based on the identifier of the first credential; or retrieving the first credential from a distributed ledger based on first distributed ledger record information.

[0024] The above design enables a second entity (verifier) ​​to directly obtain a trusted first credential from the distributed ledger based on the identifier of the first credential of the first entity or the first distributed ledger record information of the first credential, which helps to improve the reliability of the first credential; and it eliminates the need for credential transmission between the first entity and the second entity, thus saving signaling overhead between the first entity and the second entity.

[0025] In one possible design, the method further includes: receiving an identifier of a distributed ledger from a first entity; and retrieving a first credential from the distributed ledger based on the identifier of the first credential, including: retrieving the first credential from the distributed ledger based on the identifier of the first credential and the identifier of the distributed ledger.

[0026] In one possible design, the method further includes: receiving credential status service information from a first entity, wherein the credential status service information indicates a smart contract for credential query; querying a first credential through the smart contract based on first distributed ledger record information; or, receiving credential status service information and an identifier of the first credential from the first entity; querying the first credential through the smart contract based on the identifier of the first credential.

[0027] The above design enables a second entity (verifier) ​​to obtain a first credential from a distributed ledger based on a smart contract, using the identifier of the first credential of the first entity or the first distributed ledger record information of the first credential. This improves the reliability of the first credential. Furthermore, it eliminates the need for credential transmission between the first and second entities, saving signaling overhead between them.

[0028] Secondly, embodiments of this application provide a credential verification method, which can be executed by a first entity. The method includes: sending first distributed ledger record information to a second entity, the first distributed ledger record information indicating the distributed ledger address and / or verification path of the first credential; and receiving a verification result from the second entity, the verification result being determined based on whether the first credential is published on the distributed ledger.

[0029] In the aforementioned credential verification method, the first entity and the second entity can be two different devices (or apparatuses) in the communication network. Possible implementations of the first entity (or second entity) include: terminal equipment, network equipment, NF entity, or server; components (e.g., processors, chips, or chip systems) within the terminal equipment, network equipment, NF entity, or server; logical modules or software implementing some or all of the functions of the terminal equipment, network equipment, NF entity, or server; or apparatus used in conjunction with the terminal equipment, network equipment, NF entity, or server. For example: the first entity can be an NF entity in the core network, and the second entity can be another NF entity in the core network; or the first entity can be an access network device, and the second entity can be an NF entity in the core network; or the first entity can be an access network device, and the second entity can be another access network device; or the first entity can be a terminal equipment, and the second entity can be an access network device, etc.

[0030] In one possible design, the method further includes: sending credential status service information to a second entity, the credential status service information indicating a smart contract for credential query, the smart contract being used to query the status information of a first credential, the status information including whether the first credential has been revoked; wherein, the verification result is further determined based on whether the first credential has been revoked.

[0031] In one possible design, the method further includes: sending the identifier of the issuing entity of the first credential to the second entity; wherein the verification result is also determined based on whether the first credential is verified successfully using the second credential issued by the issuing entity.

[0032] In one possible design, the method further includes: sending the identifier of the issuing entity of the first document to the second entity or sending the second document of the issuing entity as second distributed ledger record information; wherein the verification result is further determined based on whether the first document passes verification through the second document of the issuing entity.

[0033] In one possible design, the information recorded in the first distributed ledger includes at least one of the following: the distributed ledger identifier, block identifier, transaction identifier, or verification path.

[0034] In one possible design, the distributed ledger records information carried in the first voucher.

[0035] In one possible design, the first credential may also include at least one of the following: credential status service information, the identifier of the issuing entity of the first credential, or the second distributed ledger record information of the second credential of the issuing entity.

[0036] In one possible design, the method further includes sending the identifier of the first credential to the second entity.

[0037] In one possible design, the method also includes sending the identifier of the distributed ledger to the second entity.

[0038] In one possible design, the method further includes: sending the credential status service information of the first entity to the second entity, wherein the credential status service information indicates the smart contract for credential query; or, sending the credential status service information and the identifier of the first credential to the second entity.

[0039] Thirdly, embodiments of this application provide a communication device that has the function of implementing the methods described in the first or second aspect above. This function can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions, such as an interface unit and a processing unit.

[0040] In one possible design, the device can be a chip or an integrated circuit.

[0041] In one possible design, the device includes a memory and a processor, the memory for storing instructions executed by the processor, and when the instructions are executed by the processor, the device can perform the method of the first aspect or the second aspect.

[0042] Fourthly, embodiments of this application provide a communication device, which includes an interface circuit and a processor, with the processor and the interface circuit coupled to each other. The interface circuit is used for inputting and / or outputting signals, and the processor uses logic circuits or executing instructions to implement the methods of the first or second aspect described above. It is understood that the interface circuit can be a transceiver, a transceiver device, or an input / output interface.

[0043] Optionally, the communication device may also include a memory for storing instructions executed by the processor, or storing input data required by the processor to execute instructions, or storing data generated after the processor executes instructions. The memory may be a physically independent unit, or it may be coupled to the processor, or the processor may include the memory (i.e., the processor and the memory are integrated together).

[0044] In one possible implementation, the communication device is a chip.

[0045] Fifthly, embodiments of this application provide a communication system comprising a second entity and a first entity, wherein the second entity is used to implement the method described in the first aspect, and the first entity is used to implement the method described in the second aspect.

[0046] In a sixth aspect, embodiments of this application provide a computer-readable storage medium storing a computer program or instructions, which, when executed by a processor, can implement the methods described in the first or second aspect.

[0047] In a seventh aspect, embodiments of this application also provide a computer program product, including a computer program or instructions, which, when executed by a processor, can implement the methods described in the first or second aspect.

[0048] Eighthly, embodiments of this application also provide a chip system including a processor, the processor being coupled to a memory, the memory being used to store programs or instructions, and when the program or instructions are executed by the processor, the methods of the first or second aspect described above can be implemented.

[0049] The technical effects achievable by aspects two through eight above are similar to those achievable by aspect one above, and will not be repeated here. Attached Figure Description

[0050] Figure 1A is a schematic diagram of the architecture of the communication network provided in an embodiment of this application;

[0051] Figure 1B is a schematic diagram of infrastructure-based trust flow provided in an embodiment of this application;

[0052] Figures 2, 4, 5, and 6 are schematic diagrams of the credential verification method provided in the embodiments of this application;

[0053] Figure 3 is a schematic diagram based on Merkle tree provided in an embodiment of this application;

[0054] Figures 7A, 7B, 7C, and 7D are schematic diagrams of the credential verification process provided in the embodiments of this application;

[0055] Figures 8 and 9 are schematic diagrams of the structure of the communication device provided in the embodiments of this application. Detailed Implementation

[0056] This application provides a credential verification method and apparatus. The method and apparatus are based on the same inventive concept. Since the principles by which the method and apparatus solve the problem are similar, their implementations can be mutually referenced, and repeated details will not be elaborated further.

[0057] Figure 1A illustrates a possible, non-limiting, communication network diagram. As shown in Figure 1A, the communication network 10 includes a radio access network (RAN) 100 and a core network (CN) 200. RAN 100 includes at least one RAN node (110a and 110b in Figure 1A, collectively referred to as RAN node 110) and at least one terminal device (120a-120j in Figure 1A, collectively referred to as terminal device 120). RAN 100 may also include other RAN nodes, such as wireless relay devices and / or wireless backhaul devices (not shown in Figure 1A). Terminal device 120 is wirelessly connected to RAN node 110. RAN node 110 is wirelessly or wired connected to core network 200. The core network devices in core network 200 and RAN node 110 in RAN 100 can be different physical devices, or they can be the same physical device integrating core network logical functions and radio access network logical functions.

[0058] RAN 100 can be a cellular network related to the 3rd Generation Partnership Project (3GPP), such as 4G, 5G mobile communication networks, or future communication networks. RAN 100 can also be an open access network (O-RAN or ORAN), a cloud radio access network (CRAN), or a wireless fidelity (WiFi) network. RAN 100 can also be a communication network that integrates two or more of the above systems.

[0059] It is understood that Figure 1A only shows one possible communication network that can be applied to the embodiments of this application, and other devices may be included in the communication network in other possible scenarios.

[0060] RAN node 110, sometimes also referred to as access network equipment, RAN entity, access node, network equipment, etc., constitutes part of the communication network and is used to help terminal devices achieve wireless access. Multiple RAN nodes 110 in the communication network 10 can be of the same type or different types. In some scenarios, the roles of RAN node 110 and terminal device 120 are relative. For example, in Figure 1A, network element 120i can be a helicopter or drone, which can be configured as a mobile base station. For terminal devices 120j accessing RAN 100 through network element 120i, network element 120i is a base station; but for base station 110a, network element 120i is a terminal device. RAN node 110 and terminal device 120 are sometimes both referred to as communication devices. For example, in Figure 1A, network elements 110a and 110b can be understood as communication devices with base station functions, and network elements 120a-120j can be understood as communication devices with terminal device functions.

[0061] In one possible scenario, a RAN node can be a base station, an evolved NodeB (eNodeB), an access point (AP), a transmission reception point (TRP), a next-generation NodeB (gNB), a base station in a future communication network, or an access node in a WiFi network. A RAN node can be a macro base station (as shown in Figure 1A, 110a), a micro base station or indoor station (as shown in Figure 1A, 110b), a relay node or donor node, or a radio controller in a CRAN scenario. Optionally, a RAN node can also be a server, wearable device, vehicle, or in-vehicle equipment. For example, the access network equipment in vehicle-to-everything (V2X) technology can be a roadside unit (RSU). All or part of the functions of the RAN node in this application can also be implemented through software functions running on hardware, or through virtualization functions instantiated on a platform (e.g., a cloud platform). The RAN node in this application can also be a logical node, logical module, or software capable of implementing all or part of the RAN node functions.

[0062] In another possible scenario, multiple RAN nodes collaborate to assist terminal devices in achieving wireless access, with different RAN nodes each implementing a portion of the base station's functions. For example, RAN nodes can be central units (CUs), distributed units (DUs), CU-control plane (CPs), CU-user plane (UPs), or radio units (RUs), etc. CUs and DUs can be set up separately or included in the same network element, such as a baseband unit (BBU). RUs can be included in radio frequency equipment or radio frequency units, such as remote radio units (RRUs), active antenna units (AAUs), or remote radio heads (RRHs).

[0063] In different systems, CU (or CU-CP and CU-UP), DU, or RU may have different names, but those skilled in the art will understand their meaning. For example, in an ORAN system, CU can also be called O-CU (open CU), DU can also be called O-DU, CU-CP can also be called O-CU-CP, CU-UP can also be called O-CU-UP, and RU can also be called O-RU. For ease of description, this application uses CU, CU-CP, CU-UP, DU, and RU as examples. Any of the units among CU (or CU-CP, CU-UP), DU, and RU in this application can be implemented through software modules, hardware modules, or a combination of software and hardware modules.

[0064] Terminal devices, also known as terminals, user equipment (UE), mobile stations, mobile terminals, etc., are devices used to provide voice or data connectivity to users, and can also be Internet of Things (IoT) devices. Terminal devices can be widely used in various scenarios, such as device-to-device (D2D), vehicle-to-everything (V2X) communication, machine-type communication (MTC), Internet of Things (IoT), virtual reality, augmented reality, industrial control, autonomous driving, telemedicine, smart grids, smart furniture, smart offices, smart wearables, smart transportation, and smart cities. Terminal devices can be: mobile phones, tablets, laptops, PDAs, mobile internet devices (MIDs), wearable devices (such as smartwatches, smart bracelets, pedometers, smart glasses, etc.), in-vehicle equipment (such as cars, bicycles, electric vehicles, airplanes, ships, trains, high-speed trains, etc.), satellite terminals, virtual reality (VR) devices, augmented reality (AR) devices, smart point of sale (POS) machines, customer-premises equipment (CPE), light user equipment (UE), reduced capability user equipment (REDCAP UE), wireless terminals in industrial control, smart home devices (such as refrigerators, televisions, air conditioners, electricity meters, etc.), smart robots, robotic arms, workshop equipment, wireless terminals in autonomous driving, wireless terminals in telemedicine, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, or wireless terminals in smart homes, and flying equipment (such as smart robots, hot air balloons, drones, airplanes), etc. The terminal device can also be a vehicle device, such as a complete vehicle device, an in-vehicle module, an in-vehicle chip, an on-board unit (OBU), or a telematics box (T-BOX). The terminal device can also be other devices with terminal functions; for example, it can be a device that performs terminal functions in D2D communication. The embodiments of this application do not limit the device form of the terminal device.

[0065] A Network Function (CN) can include multiple network function (NF) entities, such as Unified Data Management (UDM), Unified Data Repository (UDR), Network Exposure Function (NEF), Application Function (AF), Policy Control Function (PCF), Access and Mobility Management Function (AMF), Session Management Function (SMF), User Plane Function (UPF), Network Data Analytics Function (NWDAF), Network Slice Selection Function (NSSF), Authentication Server Function (AUSF), Network Slice Specific Authentication and Authorization Function (NSSAAF), and Network Repository Function (NRF), etc.

[0066] In addition, the aforementioned communication network may also include entities with credential issuance capabilities, such as trusted institutions like Certificate Authorities (CAs) and Attribute Authorities (AAs), or even third parties or users. The CA or AA can be located within the core network (i.e., a core network function) or outside the core network.

[0067] To facilitate understanding by those skilled in the art, some terms used in this application are explained below.

[0068] 1) PKI.

[0069] Public Key Infrastructure (PKI) is an infrastructure that provides information security services using public key theory and technology. It is a crucial component of information security infrastructure and a universally applicable network security infrastructure. Its core purpose is to solve the trust problem in cyberspace, ensuring the uniqueness, authenticity, and legitimacy of the identities of actors (including organizations and individuals) and protecting the security interests of various actors in cyberspace. However, existing PKI systems also have security risks. First, their core execution mechanisms, Certificate Authorities (CAs), are centralized nodes, and attacks on CAs causing single points of failure are frequent. Second, because different entities build their own trust systems, different CAs form many isolated trust domains, leading to inefficient credential authentication. A single user often needs to hold multiple CA credentials to meet authentication requirements in different scenarios. Furthermore, cross-CA credential verification requires additional means, such as third-party bridging and the issuance of mutually trusted credentials. Therefore, building a heterogeneous network cross-domain identity authentication and trust service system and constructing a cross-domain digital identity authentication and trust service platform is crucial in the internet context.

[0070] To address the aforementioned issues, this application proposes introducing distributed ledger technology into the PKI system. Distributed ledger technology is capable of building multi-party trust, completing data writing to the distributed ledger through multi-party consensus, and constructing cross-domain trust domain security. Typical methods include using distributed ledgers to build trust alliances among multiple CAs, publishing the CA's root trust credentials and CA operations on user credentials to the distributed ledger. During credential verification, the verifier can obtain the verified party's CA credential information and credential issuance status through the distributed ledger. Thus, in cross-domain processes, cross-domain authentication and credential status queries can be achieved through the distributed ledger. The distributed ledger can be implemented using blockchain (BC), directed acyclic graphs, holographic chains, or other similar methods.

[0071] Taking distributed ledger implemented in the form of blockchain as an example, as shown in Figure 1B, the components include a social authority (SA), card vendors (such as embedded universal integrated circuit card (eUICC) manufacturers (EUM)), operators (OP), over-the-air card writing servers (such as subscription manager data preparation (SM-DP+)), and third parties (3... rdOrganizations such as parties and terminal equipment manufacturers (such as device manufacturers, DEMs) can serve as the infrastructure for digital identity blockchains. In the next generation of digital identity, blockchain can enable the trust flow of digital identity between various infrastructures, and the verifier can verify the credentials of users under different trust systems (such as credentials issued by different infrastructures).

[0072] 2) X.509 credential (also known as X.509 certificate).

[0073] In current public key-based authentication systems, credentials typically follow the X.509 credential format, which is defined as follows, including a base field and an extension field:

[0074] The basic fields may include: version, serial number, signature, issuer, validity period, subject, subject public key, unique identifiers, signature algorithm, and signature value.

[0075] Extended fields may include: authority key identifier, subject key identifier, key usage, certificate policies, certificate mappings, subject alternative name (also known as subject alt name), issuer alternative name (also known as issuer alt name), subject directory attributes, basic constraints, name constraints, policy constraints, extended key usage, certificate revocation list (CRL) distribution points, inhibit any policy, and freshest CRL, etc.

[0076] 3) Use of vouchers.

[0077] Currently, the use of credentials in network security is mainly reflected in several mainstream security protocols, including Transport Layer Security (TLS) 1.3, Internet Protocol Security (IPSec), and Quick UDP Internet Connections (QUIC). Among these, the QUIC protocol reuses TLS 1.3 at the security negotiation level.

[0078] For example, in the TLS 1.3 protocol, the server sends a certificate to the client via a server hello message. The client's browser has a pre-installed list of trusted root certificates. The client verifies the certificate chain against the received certificate and its local list of trusted root certificates, verifying certificate information (validity period, signature, etc.), and uses the root certificate's CRL or the Online Certificate Status Protocol (OCSP) to verify the certificate's validity. Similarly, in IPSec's Internet Key Exchange (IKE) protocol, both parties exchange certificate information to complete authentication.

[0079] In a specific example from a communication network, taking a base station as an example, base station authentication across vendors and equipment manufacturers is as follows: 1. The equipment manufacturer's CA, acting as the trusted CA for the equipment, pre-loads its CA root credential into the equipment's list of trusted CA root certificates. This is then sent to the peer during communication processes such as IKE and Secure Socket Layer (SSL). The peer can use this CA root credential to determine whether the equipment credentials pre-installed on the equipment manufacturer's equipment are trustworthy. 2. Before deployment, the operator's equipment needs to be configured with the equipment manufacturer's CA root credential or issue cross-authentication credentials. 3. This enables two-way authentication between the equipment manufacturer's equipment and the operator's equipment.

[0080] As can be seen, in security protocols, the two parties typically need to exchange credentials, then use a pre-installed trusted root credential to verify the received credentials, and then use the CRL address in the credentials to download the CRL from the specified link, and use the CRL to verify the validity of the credentials.

[0081] 4) Sending / receiving information. In this application, "sending information" can be understood as one device sending information to another device, or it can also be understood as one logic module within a device sending information to another logic module. For example, "device A sending information" can be understood as device A sending information to another device (device B), or it can be understood as logic module 1 in device A sending information to logic module 2 in device A.

[0082] In this application, "receiving information" can be understood as one device receiving information from another device, or it can also be understood as a logical module within a device receiving information from another logical module. For example, "device A receives information" can be understood as device A receiving information from another device (such as device B), or it can be understood as logical module 1 in device A receiving information from logical module 2 in device A.

[0083] In this application, the phrase "sending information to... (e.g., device B)" or the related illustrations in the accompanying drawings can be understood as the destination of the information being device B. This can include sending information directly or indirectly to device B. Similarly, the phrase "receiving information from... (e.g., device A)," "receiving information from... (e.g., device A)," or "receiving information sent by (e.g., device A)," or the related illustrations in the accompanying drawings, can be understood as the source of the information being device A. This can include receiving information directly or indirectly from device A. Information may undergo necessary processing between the source and destination, such as format changes, but the destination can understand the valid information from the source. Similar expressions in this application can be interpreted similarly, and will not be elaborated further here.

[0084] As can be seen from the above, existing credential verification requires the pre-configuration of a list of trusted root credentials on the verification end in order to complete authentication. Cross-domain authentication is based on manual configuration, and credential information maliciously issued by CAs cannot be traced and managed.

[0085] Based on this, embodiments of this application provide a credential verification method and apparatus to support cross-industry and cross-domain verifiability of credentials, and to support the tracing and management of maliciously issued credentials by CAs. The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0086] Additionally, it should be understood that the ordinal numbers such as "first" and "second" mentioned in the embodiments of this application are used to distinguish multiple objects, and are not used to limit the size, content, order, timing, priority, or importance of the multiple objects. For example, "first certificate" and "second certificate" do not indicate a difference in priority or importance between the two certificates.

[0087] In this application embodiment, the number of nouns, unless otherwise specified, refers to "singular nouns or plural nouns," that is, "one or more." "At least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, or B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the related objects before and after are in an "or" relationship. For example, A / B means: A or B. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c means: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, and c can be single or multiple.

[0088] Figure 2 is a schematic diagram of one of the credential verification methods provided in this application embodiment. Figure 2 illustrates the method using a first entity and a second entity as the execution subjects of the interaction, where the first entity and the second entity can be two different devices (or apparatuses) in a communication network. Possible implementations of the first entity (or second entity) include: a terminal device, a network device, an NF entity, or a server; components (e.g., processors, chips, or chip systems) in the terminal device, network device, NF entity, or server; logical modules or software that implement some or all of the functions of the terminal device, network device, NF entity, or server; or apparatuses used in conjunction with the terminal device, network device, NF entity, or server. For example: the first entity can be an NF entity in the core network, and the second entity can be another NF entity in the core network; or the first entity can be an access network device, and the second entity can be an NF entity in the core network; or the first entity can be an access network device, and the second entity can be another access network device; or the first entity can be a terminal device, and the second entity can be an access network device, etc. The method includes:

[0089] S201: The first entity sends first distributed ledger record information to the second entity, and the second entity receives the first distributed ledger record information accordingly. The first distributed ledger record information indicates the distributed ledger address and / or verification path of the first entity's first credential.

[0090] It should be noted that credentials can also be called certificates, digital certificates, digital credentials, etc. For example, the first credential can also be called the first certificate, the first digital certificate, or the first digital credential. Credentials can be key credentials (such as public key credentials or symmetric key credentials), attribute credentials, etc. Key credentials can also be called identity credentials. Key credentials include a key (such as a public key or symmetric key). Attribute credentials can include at least one attribute information. Attributes can include objective attributes (such as whether real-name authentication has been completed, whether the holder is over 18 years old, or the current location), social attributes (such as industry, professional title, education, or qualifications), and lifestyle attributes (such as tickets, public transport cards, access control, etc.).

[0091] In this embodiment, the distributed ledger can be implemented using blockchain, directed acyclic graph, holographic chain, or other similar methods. The distributed ledger address of the first credential can refer to the address where the first credential is located on the distributed ledger, specifically the block identifier of the block where the first credential is located, or the transaction identifier corresponding to the publication of the first credential on the distributed ledger. If multiple distributed ledgers exist, the distributed ledger address of the first credential can also include the distributed ledger identifier of the distributed ledger where the first credential is located. The verification path of the first credential can refer to the path for verifying the first credential on the distributed ledger. Taking the distributed ledger implemented as a blockchain as an example, the verification path of the first credential can refer to the Merkle tree verification path corresponding to the first credential in the blockchain.

[0092] In one possible implementation, after the issuer issues a first credential to a user (e.g., the first entity) (e.g., by signing the first credential using the issuer's private key), it can publish the first credential or its digest (e.g., the hash value of the first credential, or the digest value obtained after processing the first credential using a message digest algorithm, etc.) to the distributed ledger, and obtain the first distributed ledger record information corresponding to the first credential from the distributed ledger. The distributed ledger record information may include at least one of the following: a distributed ledger identifier, a block identifier (e.g., the block identifier of the block where the first credential is located), a transaction identifier (e.g., the transaction identifier corresponding to the first credential), or a verification path (e.g., the Merkle tree verification path or the directed acyclic graph verification path corresponding to the first credential).

[0093] In one possible implementation, the issuer sends a first credential and first distributed ledger record information to a first entity, which then receives the first credential and the first distributed ledger record information. After obtaining the first distributed ledger record information, the issuer can send the first credential and the first distributed ledger record information to a user (e.g., the first entity).

[0094] In another possible implementation, the issuer sends a first credential to a first entity, which receives the first credential, wherein the first credential includes first distributed ledger record information. Optionally, the first credential is signed using the issuer's private key. For example, after obtaining the first distributed ledger record information of the first credential, the issuer can add the first distributed ledger record information to the first credential to obtain a new first credential, and then sign the new first credential using the issuer's private key, sending the first credential including the first distributed ledger record information to the user (e.g., the first entity).

[0095] In this context, the issuing party signing the credential using its private key can mean that the issuing party uses a hash algorithm to calculate the hash value of the credential, encrypts the calculated hash value using its private key, and the resulting string can serve as the credential's signature. This signature can be added to the credential to prove (or verify) the authenticity of its content (i.e., the content excluding the signature). For example, after a second entity obtains the first entity's first credential, it can decrypt the signature of the first credential using the issuing party's public key to obtain the decrypted signature (i.e., the hash value). Then, it can use a hash algorithm to calculate the hash value of the content of the first credential (i.e., the content excluding the signature). If this hash value matches the decrypted signature, then the content of the first credential is authentic.

[0096] It is understandable that the aforementioned method of the issuing party using a hash algorithm to calculate the hash value of the credential and encrypting the calculated hash value using the issuing party's private key to obtain the signature is only one possible example of a signature. The issuing party can also use other algorithms besides hash algorithms when signing, and this application does not limit this comparison. For example, the issuing party can also use a message digest algorithm to calculate the digest value of the credential and encrypt the calculated digest value using the issuing party's private key to obtain the signature of the credential.

[0097] Additionally, it should be noted that in the embodiments of this application, the distributed ledger record information can also be referred to as distributed ledger record (DLR) information or DLR verification information, etc.

[0098] Taking a public key certificate as an example, Table 1 shows a format example of a public key certificate provided in this application embodiment. A public key certificate may include fields (or information) such as version, serial number, signature, issuer, validity period, subject, and subject public key. It may also include certificate extension fields (or information) such as DLR. Examples or explanations of the information carried by each of the above fields (or information) are shown in Table 1. In the public key certificate shown in Table 1, the distributed ledger record information of the public key certificate can be carried through the DLR field.

[0099] Table 1

[0100] It should be noted that Table 1 is merely an example of a public key certificate format. In practical applications, public key certificates may include more or fewer fields (or information) than those shown in Table 1, or may include different fields (or information) than those shown in Table 1. The values ​​for the different fields in Table 1 are also just examples. The use of the DLR field to carry distributed ledger record information in Table 1 is only one example; distributed ledger record information can also be carried through other fields of the public key certificate, such as the subject field. Furthermore, the aforementioned digital identity can also be referred to as identity (ID) or self-controlled ID (scID).

[0101] Taking an attribute credential as an example, Table 2 shows a format example of an attribute credential provided in this application embodiment. An attribute credential may include: version, serial number, signature, issuer, validity period, subject, attribute number, subject attribute field, attribute value field, attribute algorithm, attribute hash, and other fields (or information). The attribute number field can indicate the sequence number or quantity of attribute information; n subject attribute fields and attribute value fields can indicate the attribute values ​​corresponding to the n attribute information; the attribute algorithm field can indicate the hash algorithm used to construct the Merkle tree; and the attribute hash field can indicate the signature for the Merkle tree (such as the hash value corresponding to the Merkle tree).

[0102] Attribute certificates may also include certificate extension fields (or information) such as DLR. Examples or explanations of the information carried by these fields (or information) are shown in Table 2. In the attribute certificates shown in Table 2, the distributed ledger record information of the attribute certificate can be carried through the DLR field.

[0103] Table 2

[0104] It should be noted that Table 2 is merely an example of the format of attribute credentials. In practical applications, attribute credentials may include more or fewer fields (or information) than the example in Table 2, or may include different fields (or information) than the example in Table 2. The use of DLR fields to carry distributed ledger record information in Table 2 is only one example; distributed ledger record information can also be carried using other fields of attribute credentials, such as the subject field, etc.

[0105] In scenarios where credential verification is required, such as establishing business connections, the first entity can send the first distributed ledger record information to the second entity.

[0106] S202: The second entity verifies whether the first voucher has been published on the distributed ledger based on the information recorded in the first distributed ledger.

[0107] In one possible implementation, the second entity can download the first credential from the distributed ledger based on the distributed ledger address and / or verification path indicated by the first distributed ledger record information, compare the content of the first credential downloaded from the distributed ledger with the content of the first credential from the first entity, and if the content of the credentials matches, it can be determined that the first credential from the first entity was published on the distributed ledger.

[0108] In another possible implementation, the second entity can also obtain verification information from the distributed ledger based on the information recorded in the first distributed ledger, and verify the first credential from the first entity based on the verification information. If the verification is successful, it can be determined that the first credential has been published on the distributed ledger.

[0109] For example: If the issuer publishes the first credential to the distributed ledger, the verification information may include one or more of the following: a digest of the first credential (e.g., the hash value of the first credential, or the digest value obtained after processing the first credential using a message digest algorithm, etc.) and / or information about each node on the verification path where the first credential resides (e.g., information about each node on the Merkle tree where the first credential resides). If the issuer publishes the digest of the first credential to the distributed ledger, the verification information may include the digest of the first credential published on the distributed ledger.

[0110] Taking the example of the issuer publishing the first credential to the distributed ledger and the verification information including the hash value of the first credential, the second entity can obtain the hash value of the first credential from the distributed ledger based on the information recorded in the first distributed ledger (this hash value can be calculated by the distributed ledger using a hash algorithm based on the content of the first credential), and calculate the hash value of the first credential from the first entity. If this hash value is the same as the hash value of the first credential recorded in the distributed ledger, it can be determined that the first credential has been published on the distributed ledger; otherwise, it can be determined that the first credential has not been published on the distributed ledger.

[0111] Taking the example of the issuer publishing the first credential to the distributed ledger, and the verification information including the information of each node in the Merkle tree where the first credential resides, referring to the Merkle tree shown in Figure 3, where A, B, C, and D represent credentials A, B, C, and D respectively, H1 represents the sum of the hash values ​​of credentials A and B, H2 represents the sum of the hash values ​​of credentials C and D, and Hr represents the root hash value of the Merkle tree, where Hr equals H1 + H2. The first credential is credential A, and the first distributed ledger... The verification path indicated by the record information includes the nodes corresponding to credentials B, H2, and Hr in the Merkle tree. The second entity can obtain credentials B, H2, and Hr based on the first distributed ledger record information, calculate the hash value A' of the first credential from the first entity, and sum this hash value with the hash value B of credential B to obtain the hash value H1'. Summing H1' with H2 gives the hash value Hr'. If Hr' = Hr, it means that the first credential has been published on the distributed ledger; otherwise, it can be determined that the first credential has not been published on the distributed ledger.

[0112] S203: The second entity sends the verification result to the first entity, and the first entity receives the verification result accordingly. The verification result can be determined based on whether the first voucher is published on the distributed ledger.

[0113] For example: If the first credential is not published on the distributed ledger, the verification result sent by the second entity to the first entity indicates that the verification failed (or authentication failed). If the first credential is published on the distributed ledger, the verification result sent by the second entity to the first entity allows the verification to pass (or allows the authentication to pass), or in other words, if the first credential is published on the distributed ledger, the second entity verifies whether the first credential is published on the distributed ledger.

[0114] In some embodiments, the second entity may also verify at least one of the following: the status information of the first credential (e.g., whether it has been revoked) or the accuracy of the information of the first credential.

[0115] As an example: the first entity can also send credential status service information to the second entity. This credential status service information may include information such as the address and / or identifier of the smart contract used for credential query, indicating the smart contract for credential query. The second entity can invoke this smart contract to query the status information of the first credential (e.g., whether it has been revoked). If the first credential has been revoked, the verification result sent by the second entity to the first entity indicates that the verification failed; if the first credential has not been revoked, the verification result sent by the second entity to the first entity indicates that the verification passed. In other words, if the first credential has not been revoked, the second entity verifies whether the first credential has been revoked.

[0116] By calling a smart contract to query the status information of the first credential (such as whether it has been revoked), the second entity can avoid having to download and store the CRL of the root credential of the first credential in order to query the status information of the first credential based on the CRL, thus reducing the storage overhead of the second entity.

[0117] Of course, the second entity can also download and store the CRL of the root credential of the first credential, and query the status information of the first credential (such as whether it has been revoked) through the CRL. This application does not limit the way the second entity queries the status information of the first credential.

[0118] It should be noted that, in the embodiments of this application, the certificate status service information can be called certificate status service (CSS) information, or certificate status query information, or certificate query information, etc.

[0119] In addition, the first entity can also send credential status service information and the identifier of the issuing entity of the first credential to the second entity. The second entity can also receive the credential status service information and the identifier of the issuing entity. Based on the identifier of the issuing entity, it calls the smart contract indicated by the credential status service information to query the second credential of the issuing entity (i.e., the root credential of the first credential). The second entity verifies the first credential through the second credential. If the verification of the first credential through the second credential fails, the second entity sends a verification result to the first entity indicating that the verification failed. If the verification of the first credential through the second credential passes, the second entity sends a verification result to the first entity indicating that the verification passed.

[0120] For example, verifying the first credential with the second credential can refer to decrypting the signature of the first credential with the second credential and verifying whether the decrypted signature (such as the hash value obtained after decryption) is the same as the hash value obtained by hashing the first credential. If they are the same, it means that the content of the first credential is authentic and has not been tampered with, and the verification of the first credential by the second credential passes; if they are not the same, it means that the content of the first credential has been tampered with, and the verification of the first credential by the second credential fails.

[0121] As another example: If the second document of the issuing entity of the first document is published on the distributed ledger, the first entity can send the identifier of the issuing entity of the first document or the second distributed ledger record information of the second document of the issuing entity to the second entity. The second entity can then retrieve the second document from the distributed ledger based on the identifier of the issuing entity or the second distributed ledger record information, and verify the first document with the second document. If the verification of the first document with the second document fails, the verification result sent by the second entity to the first entity indicates that the verification failed; if the verification of the first document with the second document passes, the verification result sent by the second entity to the first entity indicates that the verification passed.

[0122] Understandably, the second entity can verify at least one of the following: whether the first credential is published on the distributed ledger, status information (such as whether it has been revoked), or the authenticity of the first credential (such as verifying whether the first credential is valid through the second credential). If any verification fails, the verification result can indicate that the verification failed (or the authentication failed). If all verification items pass, the verification result can indicate that the verification passed (or the authentication passed).

[0123] For example: The second entity can verify whether the first credential is published on the distributed ledger and its status information (such as whether it has been revoked). If the first credential is published on the distributed ledger and the status information is that the first credential has not been revoked, the verification result can indicate that the verification is successful; if the first credential is published on the distributed ledger and / or the status information is that the first credential has been revoked, the verification result can indicate that the verification is unsuccessful.

[0124] In one possible implementation, at least one of the following information may be carried in the first document: first distributed ledger record information, document status service information, identifier of the issuing entity of the first document, or second distributed ledger record information of the second document of the issuing entity. The second entity may obtain the first distributed ledger record information, document status service information, identifier of the issuing entity of the first document, or second distributed ledger record information of the second document of the issuing entity carried in the first document from the first entity.

[0125] For example: taking the first credential as a public key credential, referring to the format example of the public key credential shown in Table 1, the identifier of the issuing entity of the first credential, and / or the second distributed ledger record information of the second credential of the issuing entity (such as the address on the distributed ledger) can be carried (or carried) through the issuer field of the public key credential, the first distributed ledger record information can be carried (or carried) through the DLR field, and the credential status service information can be carried (or carried) through the CSS field.

[0126] It is understood that at least one of the following information may not be carried in the first document: first distributed ledger record information, document status service information, identifier of the issuing entity of the first document, or second distributed ledger record information of the second document of the issuing entity. Instead, the first entity may send the information to the second entity through other means. This application does not limit the method by which the first entity sends the first distributed ledger record information, document status service information, identifier of the issuing entity of the first document, or second distributed ledger record information of the second document of the issuing entity.

[0127] In some implementations, the first credential can also be obtained by a second entity through a distributed ledger or smart contract.

[0128] As an example: A first entity can send an identifier of a first credential to a second entity. After receiving the identifier of the first credential, the second entity can obtain (e.g., download) the first credential from the distributed ledger based on the identifier of the first credential.

[0129] Alternatively, the first entity can send the first distributed ledger record information to the second entity. After receiving the first distributed ledger record information, the second entity can obtain (e.g., download) the first credential from the distributed ledger based on the first distributed ledger record information.

[0130] In one possible implementation, if multiple distributed ledgers exist, or if the second entity is associated with multiple distributed ledgers, the first entity may also send the identifier of the distributed ledger that issued the first credential to the second entity, so that the second entity can determine the distributed ledger from which the first credential is obtained.

[0131] As another example: the first entity can also send the identifier of the first credential or the first distributed ledger record information, as well as the credential status service information of the smart contract used to indicate the credential query, to the second entity. The second entity can also call the smart contract to query the first credential published on the distributed ledger based on the identifier of the first credential or the first distributed ledger record information.

[0132] The following description uses a distributed ledger as an example, with public key certificates as the basis, and illustrates the embodiments in Figure 2 above in conjunction with the specific implementations in Figures 4, 5, and 6.

[0133] Figure 4 is a second schematic diagram of the credential verification method provided in the embodiments of this application. The method includes:

[0134] S401: The first entity sends a first credential to the second entity, and the second entity receives the first credential accordingly.

[0135] The first credential includes first distributed ledger record information, credential status service information, and second distributed ledger record information of the second credential of the issuing entity of the first credential.

[0136] In one possible implementation, the first entity may send a first credential to the second entity after sending a service connection request to the second entity, or after receiving a service connection request from the second entity. The service request can be a service connection request, a service request, or an access request, etc., such as a TLS connection request, a primary authentication request, an over-the-top (OTT) access request, etc. Alternatively, the first entity may send the first credential to the second entity after receiving a credential request from the second entity.

[0137] In another possible implementation, the first entity may also carry the first credential in the business connection request sent to the second entity.

[0138] The first entity and the second entity can also negotiate a credential transmission mechanism. The first entity can also send a first credential to the second entity according to the negotiated credential transmission mechanism (such as the transmission credential, the identifier of the transmission credential, or the distributed ledger record information of the transmission credential, etc.). In the embodiment of Figure 4, the transmission credential is taken as an example.

[0139] In one possible implementation, if the first credential is a public key credential, the first entity can also use its own private key to sign the message that sent the first credential and send the received message signature to the second entity.

[0140] In one possible implementation, if the first credential is an attribute credential, the first entity can also send its own public key credential to the second entity, or sign the message sending the first credential using its own private key and send the received message signature to the second entity. Optionally, the first entity's public key credential is carried in the message sending the first credential.

[0141] S402: The second entity obtains the second voucher, distributed ledger verification information, and the status information of the first voucher.

[0142] For example: the second entity can obtain the second credential of the issuing entity of the first credential from the distributed ledger based on the second distributed ledger record information; according to the credential status service information, the second entity can call the smart contract for credential query to query the status information of the first credential; according to the first distributed ledger record information, the second entity can obtain the distributed ledger verification information of the first credential from the distributed ledger, which may include the hash value determined based on the first credential in the distributed ledger record, the hash values ​​of each node on the verification path of the Merkle tree where the first credential is located, the block hash value of the block where the first credential is located, and information in the block other than the first credential, etc.

[0143] S403: The second entity verifies whether the first document has been published on the distributed ledger, verifies whether the first document has been revoked, and verifies the first document based on the second document.

[0144] For example: the second entity can verify whether the first credential has been published on the distributed ledger based on the distributed ledger verification information. For instance, the distributed ledger verification information is a hash value determined based on the first credential recorded in the distributed ledger. The second entity can verify whether the first credential has been published on the distributed ledger based on whether the hash value is consistent with the hash value corresponding to the received first credential. It can also obtain information on whether the first credential has been revoked based on the acquired status information (such as whether it has been revoked). Furthermore, it can verify whether the first credential matches the signature of the issuing entity on the first credential based on the second credential (for example, verify whether the hash value corresponding to the first credential is consistent with the hash value obtained after decrypting the signature of the first credential through the second credential).

[0145] S404: The second entity sends the verification result to the first entity, and the first entity receives the verification result accordingly.

[0146] For example: If the second entity verifies all the verifications of the first credential, the second entity may send a verification result indicating that the verification has passed to the first entity; if at least one verification fails, the second entity may send a verification result indicating that the verification has failed (or failed) to the first entity.

[0147] In addition, the second entity can also verify other information such as the validity period of the first credential. If the validity period of the first credential has expired, the verification result can also indicate that the verification failed (or failed).

[0148] The second entity can also decrypt the message signature using the first entity's public key credentials to verify whether the message signature matches the message that sent the first credential (e.g., verifying whether the hash value corresponding to the message signature is equal to the hash value of the message that sent the first credential). If the verification fails, the verification result can also indicate that the verification failed (or failed). Verifying messages through message signatures can ensure the authenticity of the messages, prevent messages from being tampered with during transmission, and improve the security of communication between the first and second entities.

[0149] Figure 5 is a third schematic diagram of the credential verification method provided in this application embodiment, the method including:

[0150] S501: The first entity sends a first credential to the second entity, and the second entity receives the first credential accordingly.

[0151] The first credential includes the identifier of the first credential, credential status service information, and the identifier of the second credential of the entity that issued the first credential.

[0152] In one possible implementation, the first entity may send a first credential to the second entity after sending a service connection request to the second entity, or after receiving a service connection request from the second entity. The service request can be a service connection request, a service request, or an access request, etc., such as a TLS connection request, a primary authentication request, an OTT access request, etc. Alternatively, the first entity may send the first credential to the second entity after receiving a credential request from the second entity.

[0153] In another possible implementation, the first entity may also carry the first credential in the business connection request sent to the second entity.

[0154] The first entity and the second entity can also negotiate a credential transmission mechanism. The first entity can also send a first credential to the second entity according to the negotiated credential transmission mechanism (such as the transmission credential, the identifier of the transmission credential, or the distributed ledger record information of the transmission credential, etc.). In the embodiment of Figure 5, the transmission credential is taken as an example.

[0155] In one possible implementation, if the first credential is a public key credential, the first entity can also use its own private key to sign the message that sent the first credential and send the received message signature to the second entity.

[0156] In one possible implementation, if the first credential is an attribute credential, the first entity can also send its own public key credential to the second entity, or sign the message sending the first credential using its own private key and send the received message signature to the second entity. Optionally, the first entity's public key credential is carried in the message sending the first credential.

[0157] S502: The second entity obtains the status information of the second credential and the first credential.

[0158] For example: The second entity can invoke the smart contract indicated by the credential status service information for credential query, query the status information of the first credential by the identifier of the first credential, and query the second credential by the identifier of the second credential.

[0159] S503: The second entity verifies whether the first document has been revoked and verifies the first document based on the second document.

[0160] For example: the second entity can obtain information on whether the first credential has been revoked based on the acquired status information (such as whether it has been revoked); and verify whether the signature of the first credential by the issuing entity matches the signature of the first credential based on the second credential (for example, verify whether the hash value corresponding to the first credential is consistent with the hash value obtained after decrypting the signature of the first credential through the second credential).

[0161] S504: The second entity sends the verification result to the first entity, and the first entity receives the verification result accordingly.

[0162] For example: If the second entity verifies all the verifications of the first credential, the second entity may send a verification result indicating that the verification has passed to the first entity; if at least one verification fails, the second entity may send a verification result indicating that the verification has failed (or failed) to the first entity.

[0163] In addition, the second entity can also verify other information such as the validity period of the first credential. If the validity period of the first credential has expired, the verification result can also indicate that the verification failed (or failed).

[0164] The second entity can also decrypt the message signature using the first entity's public key credentials to verify whether the message signature matches the message that sent the first credential (e.g., verifying whether the hash value corresponding to the message signature is equal to the hash value of the message that sent the first credential). If the verification fails, the verification result can also indicate that the verification failed (or failed). Verifying messages through message signatures can ensure the authenticity of the messages, prevent messages from being tampered with during transmission, and improve the security of communication between the first and second entities.

[0165] Figure 6 is a schematic diagram of the fourth embodiment of the credential verification method provided in this application, which includes:

[0166] S601: The first entity sends credential status service information and one of the following to the second entity: first distributed ledger record information or the identifier of the first credential; accordingly, the second entity receives credential status service information and one of the following: first distributed ledger record information or the identifier of the first credential.

[0167] In one possible implementation, the first entity may, upon sending a business connection request to the second entity or upon receiving a business connection request from the second entity, send credential status service information and one of the following: first distributed ledger record information or the identifier of the first credential. The business request may be a business connection request, a business service request, or a business access request, etc., such as a TLS connection request, a primary authentication request, an OTT access request, etc. Alternatively, upon receiving a credential request from the second entity, the first entity may send credential status service information and one of the following: first distributed ledger record information or the identifier of the first credential.

[0168] In another possible implementation, the first entity may also carry credential status service information and one of the following in the business connection request sent to the second entity: first distributed ledger record information or the identifier of the first credential.

[0169] The first entity and the second entity can also negotiate a credential transmission mechanism. The first entity can also send a first credential to the second entity according to the credential transmission mechanism determined by negotiation (such as the credential transmission, the identifier of the credential transmission, or the distributed ledger record information of the credential transmission). In the embodiment of Figure 6, the identifier of the credential transmission or the distributed ledger record information is taken as an example.

[0170] In one possible implementation, if the first credential is a public key credential, the first entity can also use its own private key to sign the message that sent the first credential and send the received message signature to the second entity.

[0171] In one possible implementation, if the first credential is an attribute credential, the first entity can also send its own public key credential to the second entity, or sign the message sending the first credential using its own private key and send the received message signature to the second entity. Optionally, the first entity's public key credential is carried in the message sending the first credential.

[0172] S602: The second entity obtains the first credential, the status information of the first credential, and the second credential.

[0173] For example: The second entity can invoke the smart contract indicated by the credential status service information to query the first credential and its status information based on the first distributed ledger record information of the first credential or the identifier of the first credential, and query the second credential based on the identifier of the issuing entity of the first credential or the second distributed ledger record information of the second credential of the issuing entity.

[0174] S603: The second entity verifies whether the first document has been revoked and verifies the first document based on the second document.

[0175] For example: the second entity can obtain information on whether the first credential has been revoked based on the acquired status information (such as whether it has been revoked); and verify whether the signature of the first credential by the issuing entity matches the signature of the first credential based on the second credential (for example, verify whether the hash value corresponding to the first credential is consistent with the hash value obtained after decrypting the signature of the first credential through the second credential).

[0176] S604: The second entity sends the verification result to the first entity, and the first entity receives the verification result accordingly.

[0177] For example: If the second entity verifies all the verifications of the first credential, the second entity may send a verification result indicating that the verification has passed to the first entity; if at least one verification fails, the second entity may send a verification result indicating that the verification has failed (or failed) to the first entity.

[0178] In addition, the second entity can also verify other information such as the validity period of the first credential. If the validity period of the first credential has expired, the verification result can also indicate that the verification failed (or failed).

[0179] The second entity can also decrypt the message signature using the first entity's public key credentials, and verify whether the message signature matches the message that sent the first credential (e.g., verify whether the hash value corresponding to the message signature is equal to the hash value of the message that sent the first credential). If the verification fails, the verification result can also indicate that the verification failed (or failed).

[0180] Referring to the credential verification process shown in Figure 7A, for X.509 format credentials, the first entity (the verified party) can send credentials (such as the first credential) / credential chain, signature, etc. to the second entity (the verifying party). The second entity can obtain the root credential (such as the second credential) of the credential locally or from the database, verify the credential chain (such as verifying the credential through the root credential, verifying the credential validity period, signature, etc.), and perform credential CRL verification (i.e., verifying whether the credential is in the CRL of the root credential; if it is in the CRL, it means that the credential has been revoked).

[0181] Referring to the credential verification process shown in Figure 7B, the X.509 format credential can be improved by adding a DLR field and a CSS field to the credential extension field. The first entity (the party being verified) can send credentials (such as the first credential) / credential chain, signature, etc., to the second entity (the verifier). The second entity can verify whether the credential has been published on the distributed ledger based on the distributed ledger record information carried by the DLR field, realizing transparent verification of credentials based on the distributed ledger. It can also obtain the root credential (such as the second credential) from the distributed ledger, verify the credential chain (such as verifying the credential through the root credential, verifying the credential validity period, signature, etc.), and, based on the credential status service information carried by the CSS field, call the smart contract indicated by the credential status service information to obtain the credential status information (such as whether it has been revoked). The credential verification process shown in Figure 7B can be implemented with reference to the credential verification method shown in Figure 4. The credential verification process shown in 7B can avoid configuring root credentials for multiple parties on the verifier side. At the same time, the credentials are published on the distributed ledger, and the credentials are visible to multiple parties, which can prevent the malicious issuance of credentials. In addition, the credential status information obtained through smart contracts also eliminates the need for the verifier side to store and verify the CRL.

[0182] Referring to the credential verification process shown in Figure 7C, the X.509 format credential can be improved. The credential can include a CSS field (also called a CSS+ field). The first entity (the party being verified) can send credentials (such as the first credential) / credential chain, signature, etc., to the second entity (the verifier). The verifier can use the credential status service information carried in the CSS field to call the smart contract indicated by the credential status service information to obtain the credential status information and root credential information, and verify the credential chain (such as verifying the credential through the root credential, verifying the credential validity period, signature, etc.). The credential verification process shown in Figure 7C can be implemented with reference to the credential verification method shown in Figure 5.

[0183] Referring to the credential verification process shown in Figure 7D, the security protocol can be modified. The first entity and the second entity can additionally carry credential status service information during the interaction process specified in the security protocol (e.g., the first entity sends credential status service information to the second entity during the interaction process specified in the security protocol). The first entity (the party being verified) can also send the credential identifier / transaction identifier of the distributed ledger corresponding to the credential to the second entity (the verifier). The second entity can call the smart contract indicated by the credential status service information to obtain information such as the credential, the credential status information, and the root credential, and verify the credential chain (e.g., verifying the credential through the root credential, verifying the credential validity period, signature, etc.). The credential verification process shown in Figure 7D can be implemented using the credential verification method shown in Figure 6.

[0184] The communication device provided in the embodiments of this application is described below. Please refer to FIG8, which is a structural schematic diagram of the communication device in the embodiments of this application. The communication device may include units or modules corresponding to all or part of the steps in the above method embodiments, and may be used to execute the steps executed by the first entity or the second entity in the above embodiments. For details, please refer to the relevant descriptions in the above method embodiments.

[0185] As shown in Figure 8, the communication device 800 includes a processing unit 810 and an interface unit 820. The processing unit 810 can be a processor or a processing circuit, and the interface unit 820 can be a transceiver unit or an input / output interface. The communication device 800 can be used to implement the steps executed by the first entity or the second entity in the above embodiments.

[0186] When the communication device 800 is used to implement the steps performed by the first entity in the above embodiments:

[0187] Interface unit 820 is used to receive first distributed ledger record information from a first entity, wherein the first distributed ledger record information indicates the distributed ledger address and / or verification path of the first credential of the first entity;

[0188] Processing unit 810 is used to verify whether the first voucher has been published on the distributed ledger based on the first distributed ledger record information;

[0189] Interface unit 820 is also used to send the verification result to the first entity, the verification result being determined based on whether the first credential is published on the distributed ledger.

[0190] In one possible design, the interface unit 820 is further configured to receive credential status service information from the first entity, the credential status service information indicating the smart contract for credential query; the processing unit 810 is further configured to call the smart contract to query the status information of the first credential, the status information including whether the first credential has been revoked; wherein, the verification result is also determined based on whether the first credential has been revoked.

[0191] In one possible design, the interface unit 820 is further configured to receive the identifier of the issuing entity of the first credential from the first entity; the processing unit 810 is further configured to call the smart contract to query the second credential of the issuing entity based on the identifier of the issuing entity; and verify the first credential through the second credential; wherein the verification result is further determined based on whether the first credential is verified successfully through the second credential.

[0192] In one possible design, the interface unit 820 is further configured to receive the identifier of the issuing entity of the first document from the first entity or the second distributed ledger record information of the second document of the issuing entity; the processing unit 810 is further configured to obtain the second document from the distributed ledger according to the identifier of the issuing entity or the second distributed ledger record information; and verify the first document through the second document; wherein the verification result is further determined according to whether the first document passes the verification through the second document.

[0193] In one possible design, the information recorded in the first distributed ledger includes at least one of the following: the distributed ledger identifier, block identifier, transaction identifier, or verification path.

[0194] In one possible design, the information recorded in the first distributed ledger is carried in the first voucher.

[0195] In one possible design, the first credential may further include at least one of the following: credential status service information, the identifier of the issuing entity of the first credential, or the second distributed ledger record information of the issuing entity's second credential.

[0196] In one possible design, the interface unit 820 is further configured to receive an identifier of a first credential from a first entity; the processing unit 810 is further configured to obtain the first credential from the distributed ledger based on the identifier of the first credential; or, to obtain the first credential from the distributed ledger based on the first distributed ledger record information.

[0197] In one possible design, the interface unit 820 is further configured to receive an identifier of the distributed ledger from the first entity; when the processing unit 810 obtains the first voucher from the distributed ledger based on the identifier of the first voucher, it is specifically configured to obtain the first voucher from the distributed ledger based on the identifier of the first voucher and the identifier of the distributed ledger.

[0198] In one possible design, interface unit 820 is further configured to receive credential status service information from the first entity, the credential status service information indicating a smart contract for credential query; processing unit 810 is further configured to query the first credential through a smart contract based on the first distributed ledger record information; or, interface unit 820 is further configured to receive credential status service information and the identifier of the first credential from the first entity; processing unit 810 is further configured to query the first credential through a smart contract based on the identifier of the first credential.

[0199] When the communication device 800 is used to implement the steps performed by the second entity in the above embodiments:

[0200] Processing unit 810 is used to obtain first distributed ledger record information, the first distributed ledger record information indicating the distributed ledger address and / or verification path of the first voucher;

[0201] Interface unit 820 is used to send first distributed ledger record information to the second entity; and to receive verification results from the second entity, the verification results being determined based on whether the first credential is published on the distributed ledger.

[0202] In one possible design, the interface unit 820 is also used to send credential status service information to the second entity, the credential status service information indicating the smart contract for credential query; wherein, the verification result is also determined based on whether the first credential has been revoked.

[0203] In one possible design, the interface unit 820 is also used to send the identifier of the issuing entity of the first credential to the second entity; wherein the verification result is also determined based on whether the first credential has been verified by the second credential of the issuing entity.

[0204] In one possible design, interface unit 820 is further configured to send the identifier of the issuing entity of the first credential to the second entity or send the second distributed ledger record information of the second credential of the issuing entity; wherein the verification result is further determined based on whether the first credential is verified through the second credential of the issuing entity.

[0205] In one possible design, the information recorded in the first distributed ledger includes at least one of the following: the identifier of the distributed ledger, the block identifier, the transaction identifier, or the verification path.

[0206] In one possible design, the distributed ledger records information carried in the first voucher.

[0207] In one possible design, the first credential may further include at least one of the following: credential status service information, the identifier of the issuing entity of the first credential, or the second distributed ledger record information of the issuing entity's second credential.

[0208] In one possible design, interface unit 820 is also used to send the identifier of the first credential to the second entity.

[0209] In one possible design, interface unit 820 is also used to send the identifier of the distributed ledger to the second entity.

[0210] In one possible design, the interface unit 820 is also used to send the credential status service information of the first entity to the second entity, the credential status service information indicating the smart contract for credential query; or, to send the credential status service information and the identifier of the first credential to the second entity.

[0211] As shown in Figure 9, this application also provides a communication device 900, including a processor 910 and potentially a communication interface 920. The processor 910 and the communication interface 920 are coupled to each other. It is understood that the communication interface 920 can be a transceiver, input / output interface, input interface, output interface, interface circuit, etc. Optionally, the communication device 900 may further include a memory 930 for storing instructions executed by the processor 910, or storing input data required by the processor 910 to execute instructions, or storing data generated after the processor 910 executes instructions. The memory 930 can be a physically independent unit, or it can be coupled to the processor 910, or the processor 910 may include the memory 930.

[0212] When the communication device 900 is used to implement the steps performed by the first entity or the second entity in the above embodiments, the processor 910 can be used to implement the function of the processing unit 810, and the communication interface 920 can be used to implement the function of the interface unit 820.

[0213] In this application embodiment, the processor (e.g., processor 910) can be one or more central processing units (CPUs). If the processor is a CPU, it can be a single-core CPU or a multi-core CPU. The processor can also be one or a combination of several of the following: CPU, general-purpose processor, application-specific integrated circuit (ASIC), digital signal processor (DSP), microprocessor unit (MPU), microcontroller unit (MCU), graphics processing unit (GPU), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, artificial intelligence processor (AI processor), or neural processing unit (NPU). The processor can implement or execute the methods, steps, and logic block diagrams disclosed in this application embodiment. The steps of the methods disclosed in this application embodiment can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0214] In this embodiment, the memory (e.g., memory 930) may include, but is not limited to, cache, read-only memory (ROM), random access memory (RAM), synchronous dynamic random access memory (SDRAM), hard disk drive (HDD) or solid-state drive (SSD), erasable programmable read-only memory (EPROM), or compact disc read-only memory (CD-ROM), etc. Memory is any other medium capable of carrying or storing desired program code having an instruction or data structure form and accessible by a computer, but is not limited thereto. The memory in this embodiment may also be a circuit or any other device capable of implementing storage functions for storing computer programs or instructions, and / or data.

[0215] It is understood that the method steps in the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory, flash memory, read-only memory, programmable read-only memory, erasable programmable read-only memory, electrically erasable programmable read-only memory, registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium well known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Additionally, the ASIC can reside in a network device or a terminal device. Alternatively, the processor and storage medium can exist as discrete components in the network device or terminal device.

[0216] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the processes or functions described in the embodiments of this application are performed entirely or partially. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, or other programmable device. The computer program or instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, the computer program or instructions can be transferred from one network device, terminal, computer, server, or data center to another network device, terminal, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; it can also be an optical medium, such as a digital video optical disc; or it can be a semiconductor medium, such as a solid-state drive. The computer-readable storage medium may be a volatile or non-volatile storage medium, or may include both types of storage media.

[0217] In the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions of different embodiments are consistent and can be referenced by each other. The technical features of different embodiments can be combined to form new embodiments according to their inherent logical relationship.

[0218] Additionally, it should be understood that in the embodiments of this application, the term "exemplary" is used to indicate that it is an example, illustration, or description. Any embodiment or design scheme described as "exemplary" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the term "exemplary" is intended to present the concept in a concrete manner.

[0219] It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application. The order of the process numbers described above does not imply the order of execution; the execution order of each process should be determined by its function and internal logic.

Claims

1. A method for verifying credentials, characterized in that, include: Receive first distributed ledger record information from a first entity, wherein the first distributed ledger record information indicates the distributed ledger address and / or verification path of the first credential of the first entity; Based on the first distributed ledger record information, verify whether the first voucher has been published on the distributed ledger; A verification result is sent to the first entity, the verification result being determined based on whether the first credential is published on the distributed ledger.

2. The method as described in claim 1, characterized in that, The method further includes: Receive credential status service information from the first entity, wherein the credential status service information indicates the smart contract for credential query; The smart contract is invoked to query the status information of the first credential, including whether the first credential has been revoked; wherein, the verification result is further determined based on whether the first credential has been revoked.

3. The method as described in claim 2, characterized in that, The method further includes: Receive the identifier of the issuing entity of the first credential from the first entity; Based on the identifier of the issuing entity, the smart contract is invoked to query the second credential of the issuing entity; The first credential is verified by the second credential; wherein, the verification result is further determined based on whether the first credential is successfully verified by the second credential.

4. The method as described in claim 1 or 2, characterized in that, The method further includes: Receive the identifier of the issuing entity of the first document from the first entity or the second distributed ledger record information of the second document of the issuing entity; The second credential is obtained from the distributed ledger based on the identifier of the issuing entity or the second distributed ledger record information; The first credential is verified by the second credential; wherein, the verification result is further determined based on whether the first credential is successfully verified by the second credential.

5. The method according to any one of claims 1-4, characterized in that, The first distributed ledger record information includes at least one of the following: The identifier, block identifier, transaction identifier, or verification path of the distributed ledger.

6. The method according to any one of claims 1-5, characterized in that, The information recorded in the first distributed ledger is carried in the first voucher.

7. The method as described in claim 6, characterized in that, The first credential also includes at least one of the following: The voucher status service information, the identifier of the issuing entity of the first voucher, or the second distributed ledger record information of the second voucher of the issuing entity.

8. The method according to any one of claims 1-5, characterized in that, The method further includes: Receive the identifier of the first credential from the first entity; Based on the identifier of the first document, retrieve the first document from the distributed ledger; or, The first voucher is obtained from the distributed ledger based on the information recorded in the first distributed ledger.

9. The method as described in claim 8, characterized in that, The method further includes: Receive the identifier of the distributed ledger from the first entity; The step of obtaining the first voucher from the distributed ledger based on the identifier of the first voucher includes: The first credential is obtained from the distributed ledger based on the identifier of the first credential and the identifier of the distributed ledger.

10. The method according to any one of claims 1-5, characterized in that, The method further includes: Receive credential status service information from the first entity, wherein the credential status service information indicates the smart contract for credential query; Based on the information recorded in the first distributed ledger, the first voucher is queried via the smart contract; or... Receive the credential status service information and the identifier of the first credential from the first entity; The first credential is queried through the smart contract based on its identifier.

11. A method for verifying credentials, characterized in that, include: Send a first distributed ledger record to the second entity, wherein the first distributed ledger record indicates the distributed ledger address and / or verification path of the first credential; Receive a verification result from the second entity, the verification result being determined based on whether the first credential is published on the distributed ledger.

12. The method as described in claim 11, characterized in that, The method further includes: Send credential status service information to the second entity. The credential status service information indicates a smart contract for credential query. The smart contract is used to query the status information of the first credential, including whether the first credential has been revoked. The verification result is also determined based on whether the first credential has been revoked.

13. The method as described in claim 11 or 12, characterized in that, The method further includes: The identifier of the issuing entity of the first credential is sent to the second entity; wherein, the verification result is further determined based on whether the first credential is verified successfully using the second credential of the issuing entity.

14. The method as described in claim 11 or 12, characterized in that, The method further includes: Send the identifier of the issuing entity of the first credential to the second entity or send the second distributed ledger record information of the second credential of the issuing entity; wherein, the verification result is further determined based on whether the first credential passes verification through the second credential of the issuing entity.

15. The method according to any one of claims 11-14, characterized in that, The first distributed ledger record information includes at least one of the following: The identifier, block identifier, transaction identifier, or verification path of the distributed ledger.

16. The method according to any one of claims 11-15, characterized in that, The distributed ledger record information is carried in the first voucher.

17. The method as described in claim 16, characterized in that, The first credential also includes at least one of the following: The voucher status service information, the identifier of the issuing entity of the first voucher, or the second distributed ledger record information of the second voucher of the issuing entity.

18. The method according to any one of claims 11-15, characterized in that, The method further includes: Send the identifier of the first credential to the second entity.

19. The method as described in claim 18, characterized in that, The method further includes: Send the identifier of the distributed ledger to the second entity.

20. The method according to any one of claims 11-15, characterized in that, The method further includes: Send the credential status service information of the first entity to the second entity, wherein the credential status service information indicates the smart contract for credential query; or, Send the credential status service information and the identifier of the first credential to the second entity.

21. A communication device, characterized in that, It includes a module or unit for performing the method as described in any one of claims 1-10; or, it includes a module or unit for performing the method as described in any one of claims 11-20.

22. A communication device, characterized in that, It includes a processor and an interface circuit, the interface circuit being used to input and / or output signals, and the processor being used to implement the method as described in any one of claims 1-10 through logic circuits or execution instructions; or, to implement the method as described in any one of claims 11-20.

23. A computer program product, characterized in that, It includes a computer program or instructions that, when executed by a processor, cause the method as described in any one of claims 1-10 to be implemented; or cause the method as described in any one of claims 11-20 to be implemented.

24. A chip system, characterized in that, The chip system includes a processor for coupling with a memory for storing computer programs or instructions that, when executed by the processor, implement the method as described in any one of claims 1-10; or, implement the method as described in any one of claims 11-20.

25. A computer-readable storage medium, characterized in that, The storage medium stores a computer program or instructions that, when executed by a processor, cause the method as described in any one of claims 1-10 to be implemented; or cause the method as described in any one of claims 11-20 to be implemented.

26. A communication system, characterized in that, It includes a first entity and a second entity, wherein the second entity is used to perform the method as described in any one of claims 1-10; and the first entity is used to perform the method as described in any one of claims 11-20.

Images