Communication method and communication apparatus

Abstract

Provided in the present application are a communication method and a communication apparatus. A signature of a first verifiable credential of a first apparatus in a first distributed ledger can be updated on the basis of a private key of a second distributed ledger (or a private key of an endorsement node in the second distributed ledger), so as to generate a second verifiable credential of the first apparatus in the second distributed ledger, such that an apparatus in a network of the second distributed ledger can verify the second verifiable credential on the basis of a public key of the second distributed ledger (or a public key of the endorsement node in the second distributed ledger). In this way, the first apparatus can execute a corresponding service or acquire a corresponding service in the network of the second distributed ledger.

Description

Communication methods and communication devices

[0001] This application claims priority to Chinese Patent Application No. 202510123805.3, filed on January 24, 2025, entitled "Communication Method and Communication Device", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of communications, and more specifically, to a communication method and a communication device. Background Technology

[0003] A distributed ledger (DL) is a database that is shared, replicated, and synchronized among network members. Distributed ledgers can record transactions between network members, such as the exchange of assets or data. Essentially, a distributed ledger is a shared database where the data or information stored is characterized by being unforgeable, fully traceable, auditable, transparent, and collectively maintained. Therefore, distributed ledger technology has a high probability of being introduced into communication networks in the future to improve communication network security.

[0004] If distributed ledger technology is introduced into communication networks, multiple operators can establish distributed ledgers based on equipment within the network, such as access network equipment or core network equipment. A distributed ledger can store the credentials of a single node, but these credentials cannot be used in another distributed ledger network, thus impacting user experience. Summary of the Invention

[0005] This application provides a communication method and a communication device that enable voucher information on one distributed ledger to be used in another distributed ledger, thereby improving the user experience.

[0006] In a first aspect, a communication method is provided, which can be executed by a first device. Unless otherwise specified, the first device in this application can be a first device, or a component in the first device (e.g., a processor in the first device, or a communication module, or a circuit or chip responsible for communication functions, or a chip (such as a modem chip, also known as a baseband chip, or a system-on-chip (SoC) chip containing a modem core, or a system-in-package (SIP) chip, etc.), or it can be a logic module or software that can implement all or part of the functions of the first device, or it can refer to a device that can support the first device in implementing corresponding functions.

[0007] The method includes: sending a first request message, the first request message being used to request the publication of a second key credential of a first device in a second distributed ledger; receiving a first request response message, the first request response message including the second key credential, the second key credential including the public key and signature of the first device, wherein the public key of the first device is the public key in the first key credential published by the first device in the first distributed ledger, the signature is generated based on the private key of the second distributed ledger, and the signature is verified by the public key of the second distributed ledger.

[0008] In the above technical solution, the second distributed ledger has a public key and a private key. The second key certificate can be seen as a certificate generated by endorsing and replacing the first key certificate with the private key of the second distributed ledger (i.e., re-signing it using the private key of the second distributed ledger). Therefore, devices in the network of the second distributed ledger can verify the signature of the second key certificate using the public key of the second distributed ledger, thus enabling the use of the public key of the first device from the first key certificate within the second distributed ledger.

[0009] In some implementations of the first aspect, the first request message request includes first encrypted information, which is obtained by encrypting a first value corresponding to a first parameter based on the private key of the first device. The first parameter is a parameter associated with the first distributed ledger.

[0010] In the above technical solution, the first encrypted information is used to prove that the first device holds the first device's private key, that is, to prove that the first device's identity has not been impersonated. It can be understood that if the first request message is sent by the first device, the first encrypted information in the first request message is encrypted using the first device's private key. Therefore, if other devices can successfully decrypt the first encrypted information using the first device's public key, it can be determined that the first device's identity has not been impersonated. If the first request message is sent by a device impersonating the first device, since the impersonating device cannot obtain the first device's private key, the first encrypted information carried in the first request message is certainly not based on the first device's private key. Therefore, other devices cannot successfully decrypt the first encrypted information using the first device's public key, thus it can be determined that the first device's identity has been impersonated.

[0011] In some implementations of the first aspect, the first parameter is the hash of the latest block or a specified block in the first distributed ledger, or the first parameter is the generation time of the latest block or a specified block in the first distributed ledger.

[0012] In some implementations of the first aspect, sending the first request message includes sending the first request message to a second device, wherein the second device is a common device in the network of the first distributed ledger and the network of the second distributed ledger.

[0013] In some implementations of the first aspect, the method further includes: receiving a second value from a third device in the network of the second distributed ledger; encrypting the second value using the private key of the first device to obtain second encrypted information; sending the second encrypted information to the third device, the second encrypted information being used to authenticate the first device; and receiving the authentication result of the first device from the third device.

[0014] The above technical solution provides a possible application scenario for the second key credential. It can be understood that the third device is a device within the network of the second distributed ledger. Therefore, the third device can obtain the public key of the second distributed ledger to verify the signature of the second key credential. If the verification passes, the third device can use the public key of the first device in the second key credential to decrypt the second encrypted information and send the authentication result to the first device based on the decryption result. It can be understood that if the decryption result matches the second value, the authentication result indicates successful authentication; otherwise, the authentication result indicates unsuccessful authentication.

[0015] In some implementations of the first aspect, the first request response message also includes verification information used to verify whether the second key credential is stored in the second distributed ledger.

[0016] In one possible scenario, if the first device has high security requirements, it can send the verification information.

[0017] In some implementations of the first aspect, the second key credential is determined to be stored in the second distributed ledger based on the verification information; the second key credential is stored locally.

[0018] Secondly, a communication method is provided, which can be executed by a second device. Unless otherwise specified, the second device in this application can be a second device, or a component in the second device (e.g., a processor, or a communication module, or a circuit or chip responsible for communication functions in the second device), or a logic module or software that can implement all or part of the functions of the second device, or a device that can support the second device in implementing corresponding functions.

[0019] The method includes: receiving a first request message, the first request message being used to request the publication of a second attribute certificate of the first device in a second distributed ledger based on a first attribute certificate of the first device published in a first distributed ledger, the first attribute certificate including first attribute information, and the first request message including relevant information of the first attribute certificate; sending first information to an endorsement device in the network of the second distributed ledger, the first information including the first attribute certificate; receiving a second attribute certificate from the endorsement device, the second attribute certificate including second attribute information and a signature, the second attribute information being determined based on the first attribute information, and the signature being obtained based on the private key of the endorsement device; and sending a first request response message, the first request response message including the second attribute certificate.

[0020] For the beneficial effects of the second aspect, please refer to the description of the first aspect, which will not be repeated here.

[0021] In some implementations of the second aspect, the second device is a common device in the network of the first distributed ledger and the network of the second distributed ledger.

[0022] In some implementations of the second aspect, the first request message includes first encrypted information, which is obtained by encrypting the first encrypted information using the private key of the first device. Before obtaining the second key credential, the method further includes: obtaining the public key of the first device in the first key credential; and successfully decrypting the first encrypted information based on the public key of the first device.

[0023] In the above technical solution, the first encrypted information is used to prove that the first device holds the first device's private key, that is, to prove that the first device's identity has not been impersonated. It can be understood that if the first request message is sent by the first device, the first encrypted information in the first request message is encrypted using the first device's private key. Therefore, if the second device can successfully decrypt the first encrypted information using the first device's public key, it can be determined that the first device's identity has not been impersonated. If the first request message is sent by a device impersonating the first device, since the impersonating device cannot obtain the first device's private key, the first encrypted information carried in the first request message is certainly not based on the first device's private key. Therefore, the second device cannot successfully decrypt the first encrypted information using the first device's public key, thus it can be determined that the first device's identity has been impersonated.

[0024] In some implementations of the second aspect, the first encrypted information is obtained by encrypting a first value corresponding to a first parameter based on the private key of the first device. The first parameter is a parameter associated with the first distributed ledger. The method further includes: obtaining the first value corresponding to the first parameter from the first distributed ledger; successfully decrypting the first encrypted information based on the public key of the first device, including: decrypting the first encrypted information based on the public key of the first device to obtain a decryption result, wherein the decryption result is consistent with the first value.

[0025] In one implementation, to determine whether the identity of the first device has been impersonated, the second device needs to first send a value #1 to the first device. The first device then encrypts this value #1 using its private key to obtain first encrypted information, which it then sends to the second device. However, in this method, the first parameter is associated with the first distributed ledger. Both the first and second devices can obtain the value corresponding to the first parameter from the first distributed ledger themselves. Therefore, the second device does not need to send the value #1 to the first device in advance, thereby reducing the interaction process on the first device's side and simplifying the authentication process.

[0026] In some implementations of the second aspect, the first parameter is the hash of the latest block or a specified block in the first distributed ledger, or the first parameter is the generation time of the latest block or a specified block in the first distributed ledger.

[0027] In some implementations of the second aspect, the first request message originates from the network of the first distributed ledger (e.g., a device within the network of the first distributed ledger), and includes the public key of the first device. The first request message indicates that the first device has been authenticated by the network of the first distributed ledger. That is, when the second device receives the first request message, it is assumed that the first device has been authenticated by the network of the first distributed ledger. Specifically, the device within the network of the first distributed ledger may be a device within the network of the first distributed ledger trusted by the network of the second distributed ledger.

[0028] In the above technical solution, if the second device is not a public device in the network of the first distributed ledger and the second distributed ledger, the first device can be authenticated by a trusted device in the network of the first distributed ledger. If the authentication is successful, the trusted device in the network of the first distributed ledger can send the public key of the first device to the second device.

[0029] In some implementations of the second aspect, the second key credential is obtained by generating the second key credential based on the private key of the second distributed ledger.

[0030] In some implementations of the second aspect, obtaining the second key credential includes: receiving a second key credential from another device in the network of the second distributed ledger.

[0031] In some implementations of the second aspect, generating a second key credential includes generating a signature based on the private key of the second distributed ledger.

[0032] In some implementations of the second aspect, before sending the first request-response message, the method further includes: triggering a consensus mechanism in the network of the second distributed ledger to reach a consensus on the second key credential; sending the first request-response message includes: sending the first request-response message if the consensus is successful.

[0033] In the above technical solution, consensus is reached on the second key credential through a consensus device, which can simplify network deployment from an architectural perspective and avoid single point of attack.

[0034] In some implementations of the second aspect, the first request response message also includes verification information used to verify whether the second key credential is stored in the second distributed ledger.

[0035] Thirdly, a communication method is provided, which can be executed by a third device. Unless otherwise specified, the third device in this application can be a third equipment, a component in the third equipment (e.g., a processor, communication module, circuit or chip responsible for communication functions in the third equipment), or a logic module or software that can implement all or part of the functions of the third equipment, or a device that can support the third equipment to implement corresponding functions.

[0036] The method includes: sending a second value to a first device; receiving second encrypted information from the first device, the second encrypted information being obtained by encrypting the second value using the private key of the first device, the second encrypted information being used to authenticate the first device; obtaining a second key credential of the first device in a second distributed ledger, wherein the second key credential includes the public key of the first device; decrypting the second encrypted information based on the public key of the first device in the second key credential to obtain a decryption result; and sending an authentication result of the first device to the first device based on the decryption result.

[0037] The above technical solution provides a possible application scenario for the second key credential. Specifically, the third device can verify the signature of the second key credential based on the private key of the second distributed ledger. If the verification is successful, the third device uses the public key of the first device in the second key credential to decrypt the second encrypted information and sends the authentication result to the first device based on the decryption result.

[0038] Fourthly, a communication method is provided, which can be executed by a first device. Unless otherwise specified, the first device in this application can be a first device, or a component in the first device (e.g., a processor in the first device, or a communication module, or a circuit or chip responsible for communication functions), or a logic module or software that can implement all or part of the functions of the first device, or a device that can support the first device in implementing corresponding functions.

[0039] The method includes: sending a first request message, the first request message being used to request the publication of a second attribute certificate of the first device in a second distributed ledger based on a first attribute certificate of the first device published in a first distributed ledger, the first attribute certificate including first attribute information, and the first request message including relevant information of the first attribute certificate; receiving a first request response message, the first request response message including a second attribute certificate, the second attribute certificate including second attribute information and a signature, the second attribute information being determined based on the first attribute information in the first attribute certificate, and the signature being obtained based on the private key of an endorsement device in the network of the second distributed ledger.

[0040] In the above technical solution, the second attribute certificate can be seen as a certificate obtained by endorsing and replacing the first attribute certificate with the private key of the endorsing device (i.e., re-signing it using the private key of the endorsing device). Therefore, devices in the second distributed ledger network can verify the second attribute certificate based on the public key of the endorsing device, thus enabling the use of attribute information from the first attribute certificate in the second distributed ledger.

[0041] In some implementations of the fourth aspect, sending the first request message includes sending the first request message to a second device, wherein the second device is a common device in the first distributed ledger and the second distributed ledger.

[0042] In some implementations of the fourth aspect, the method further includes: sending a fourth attribute credential to a third device, the fourth attribute credential including fourth attribute information and a signature of a second attribute credential, the fourth attribute information being determined based on the second attribute information, the fourth attribute credential being used by the third device to authenticate the first device; and receiving the authentication result from the third device for the first device.

[0043] The above technical solution provides an application scenario for the second attribute credential. It can be understood that the third device is a device within the network of the second distributed ledger. Therefore, the third device can obtain the public key of the endorsing device from the second distributed ledger to verify the signature in the fourth attribute credential. If the verification passes, the authentication result for the first device can be determined based on the fourth attribute information. It can be understood that if the signature verification is successful and the fourth attribute credential includes the attribute information required to authenticate the first device, the authentication result indicates successful authentication; otherwise, the authentication result indicates unsuccessful authentication.

[0044] In some implementations of the fourth aspect, before receiving the first request response message, the method further includes: receiving second information, the second information indicating whether a third attribute credential satisfies the requirements of the first device, the third attribute credential being an unsigned second attribute credential; determining that the third attribute credential satisfies the requirements of the first device; and sending third information, the third information indicating that the third attribute credential satisfies the requirements of the first device.

[0045] In some implementations of the fourth aspect, the endorsement device is a device capable of endorsing at least a first type of attribute certificate, which is a certificate of the first type.

[0046] In some implementations of the fourth aspect, the first request response message also includes verification information used to verify whether the second attribute credential is stored in the second distributed ledger.

[0047] In the above technical solution, if the first device has high security requirements, it can send the verification information.

[0048] In some implementations of the fourth aspect, the method further includes: determining, based on the verification information, that the second attribute credential is stored in the second distributed ledger; and storing the second attribute credential locally.

[0049] Fifthly, a communication method is provided, which can be executed by a second device. Unless otherwise specified, the second device in this application can be a second device, a component in the second device (e.g., a processor, communication module, circuit or chip responsible for communication functions in the second device), or a logic module or software that can implement all or part of the functions of the second device, or a device that can support the second device in implementing corresponding functions.

[0050] The method includes: receiving a first request message, the first request message being used to request the publication of a second attribute certificate of the first device in a second distributed ledger based on a first attribute certificate of the first device published in a first distributed ledger, the first attribute certificate including first attribute information, and the first request message including relevant information of the first attribute certificate; sending first information to an endorsement device in the network of the second distributed ledger, the first information including the first attribute certificate; receiving a second attribute certificate from the endorsement device, the second attribute certificate including second attribute information and a signature, the second attribute information being determined based on the first attribute information, and the signature being obtained based on the private key of the endorsement device; and sending a first request response message, the first request response message including the second attribute certificate.

[0051] For the beneficial effects of the fifth aspect, please refer to the description of the fourth aspect, which will not be repeated here.

[0052] In some implementations of the fifth aspect, the method is applied to the second device side, the second device being a common device in the network of the first distributed ledger and the network of the second distributed ledger.

[0053] In some implementations of the fifth aspect, the first attribute credential includes information about the issuer of the first attribute credential and the issuer's signature on the first attribute credential. The method further includes: obtaining the issuer's public key in the first distributed ledger; and verifying the signature of the first attribute credential based on the issuer's public key.

[0054] In some implementations of the fifth aspect, the first request message originates from the network of the first distributed ledger (e.g., a device within the network of the first distributed ledger), and the first attribute credential indicated by the first request message has been verified by the network of the first distributed ledger. That is, when the second device receives the first request message, it assumes that the first attribute credential has been verified by the network of the first distributed ledger. Specifically, the device within the network of the first distributed ledger may be a device within the network of the first distributed ledger trusted by the network of the second distributed ledger.

[0055] In the above technical solution, if the second device is not a public device in the network of the first distributed ledger and the second distributed ledger, the first attribute credential can be verified by a trusted device in the network of the first distributed ledger. If the verification is successful, the trusted device in the network of the first distributed ledger can send the first attribute credential to the second device.

[0056] In some implementations of the fifth aspect, the first information also includes information about the voucher template, and the second attribute voucher is determined based on the first attribute information and the voucher template information. Before sending the first information, the method further includes: determining the voucher template based on the first attribute voucher.

[0057] In one possible scenario, if the endorsement device needs to obtain the corresponding voucher template before it can update the endorsement, the second device also needs to determine and inform the endorsement device of the voucher template based on the first attribute voucher.

[0058] In some implementations of the fifth aspect, before receiving the second attribute credential from the endorsement device, the method further includes: receiving second information from the endorsement device, the second information including a third attribute credential, the third attribute credential being an unsigned second attribute credential, the second information indicating whether the third attribute credential meets the requirements of the first device; sending the second information to the first device; receiving third information from the first device, the third information indicating that the third attribute credential meets the requirements; and sending the third information to the endorsement device.

[0059] In some implementations of the fifth aspect, before sending the first information, the method further includes: determining an endorsement device based on the type of the first attribute credential, wherein the endorsement device is at least capable of endorsing an attribute credential of the first type, and the first attribute credential is a credential of the first type.

[0060] In some implementations of the fifth aspect, the first request response message also includes verification information used to verify whether the second attribute credential is stored in the second distributed ledger.

[0061] In a sixth aspect, a communication method is provided, which can be executed by an endorsement device. Unless otherwise specified, the endorsement device in this application can be an endorsement equipment, a component in the endorsement equipment (e.g., a processor in the endorsement equipment, or a communication module, or a circuit or chip responsible for communication functions), or a logic module or software that can implement all or part of the functions of the endorsement equipment, or a device that can support the endorsement equipment to implement corresponding functions.

[0062] The method includes: receiving first information from a second device in a network of a second distributed ledger, the first information including a first attribute credential of the first device in the network of a first distributed ledger, the first attribute credential including first attribute information, the first information being used to request the issuance of a second attribute credential of the first device in the second distributed ledger based on the first attribute credential; if it is determined that the first attribute credential is a credential issued by a trusted issuer, generating a second attribute credential based on the first attribute credential, wherein the second attribute credential includes second attribute information and a signature, the second attribute information being determined based on the first attribute information, and the signature being obtained based on the private key of an endorsing device; and sending the second attribute credential to the second device.

[0063] For the beneficial effects of the sixth aspect, please refer to the description of the fourth aspect, which will not be repeated here.

[0064] In some implementations of the sixth aspect, the first information also includes information about the voucher template. Generating a second attribute voucher based on the first attribute voucher includes: generating a second attribute voucher based on the first attribute voucher and the voucher template.

[0065] In some implementations of the sixth aspect, before sending the second attribute credential to the second device, the method further includes: sending second information to the second device, the second information including a third attribute credential, the third attribute credential being an unsigned second attribute credential, the second information indicating whether the third attribute credential meets the requirements of the first device; and receiving third information from the second device, the third information indicating that the third attribute credential meets the requirements.

[0066] In some implementations of the sixth aspect, the endorsement device is at least capable of endorsing a first type of attribute certificate, which is a first type of certificate.

[0067] In some implementations of the sixth aspect, before sending the second attribute credential to the second device, the method further includes: triggering a consensus device in the network of the second distributed ledger to reach a consensus on the second attribute credential; sending the second attribute credential to the second device includes: sending the second attribute credential to the second device if the consensus is successful.

[0068] In the above technical solution, consensus is reached on the second key credential through a consensus device, which can simplify network deployment from an architectural perspective and avoid single point of attack.

[0069] In a seventh aspect, a communication method is provided, which can be executed by a third device. Unless otherwise specified, the third device in this application can be a third equipment, a component in the third equipment (e.g., a processor, communication module, circuit or chip responsible for communication functions in the third equipment), or a logic module or software that can implement all or part of the functions of the third equipment, or a device that can support the third equipment to implement the corresponding functions.

[0070] The method includes: receiving a fourth attribute credential from a first device, the fourth attribute credential including fourth attribute information and a signature of a second attribute credential published in a second distributed ledger, the fourth attribute information being determined based on attribute information in the second attribute credential, and the signature being obtained based on the private key of an endorser in the network of the second distributed ledger, the fourth attribute credential being used to authenticate the first device; obtaining the public key of the endorser on the second distributed ledger; verifying the signature of the second attribute credential based on the public key of the endorser; and sending an authentication result for the first device to the first device based on the verification result.

[0071] The above technical solution provides a possible application scenario for the second attribute credential. It can be understood that the third device is a device within the network of the second distributed ledger. Therefore, the third device can obtain the public key of the endorsing device from the second distributed ledger to verify the signature in the fourth attribute credential. If the verification passes, the authentication result for the first device can be determined based on the fourth attribute information.

[0072] Eighthly, a communication apparatus is provided for performing the method provided in any of the above aspects or implementations thereof. Specifically, the apparatus may include units and / or modules for performing the method provided in any of the above aspects or implementations thereof, such as processing units and / or transceiver units.

[0073] In one implementation, the device is an apparatus (e.g., a first apparatus, a second apparatus, a third apparatus, an endorsement apparatus). When the apparatus is a device / network element, the transceiver unit can be a transceiver, or an input / output interface, or a communication interface; the processing unit can be at least one processor. Optionally, the transceiver is a transceiver circuit. Optionally, the input / output interface is an input / output circuit.

[0074] In another implementation, the device is a chip, chip system, or circuit used in a device (e.g., a first device, a second device, a third device, an endorsement device). When the device is a chip, chip system, or circuit used in a device / network element, the transceiver unit can be an input / output interface, interface circuit, output circuit, input circuit, pin, or related circuit on the chip, chip system, or circuit; the processing unit can be at least one processor, processing circuit, or logic circuit.

[0075] A ninth aspect provides a communication device comprising: a memory for storing a program; and at least one processor for executing the computer program or instructions stored in the memory to perform the method provided in any of the foregoing aspects or their implementations.

[0076] In one implementation, the device is a means (e.g., a first means, a second means, a third means, an endorsement means).

[0077] In another implementation, the device is a chip, chip system, or circuit used in a device (e.g., a first device, a second device, a third device, an endorsement device).

[0078] In a tenth aspect, a communication apparatus is provided, comprising: at least one processor and a communication interface, the at least one processor being configured to obtain a computer program or instructions stored in a memory via the communication interface to execute the method provided in any of the foregoing aspects or their implementations. The communication interface may be implemented in hardware or software.

[0079] In one implementation, the device further includes the memory.

[0080] In the eleventh aspect, a processor is provided for executing the methods provided in the foregoing aspects.

[0081] Unless otherwise specified, or if it does not contradict its actual function or internal logic in the relevant description, the transmission and acquisition / reception operations involved in the processor can be understood as processor output and reception, input and other operations, or as transmission and reception operations performed by radio frequency circuits and antennas. This application does not limit them in this regard.

[0082] In a twelfth aspect, a computer-readable storage medium is provided that stores program code for execution by a device, the program code including methods for performing any of the foregoing aspects or implementations thereof.

[0083] In a thirteenth aspect, a computer program product containing instructions is provided, which, when run on a computer, causes the computer to perform the method provided in any of the foregoing aspects or their implementations.

[0084] In a fourteenth aspect, a computer program is provided that, when run on a computer, causes the methods provided by any of the foregoing aspects or their implementations to be executed.

[0085] In a fifteenth aspect, a chip is provided, comprising a processor and a communication interface. The processor reads instructions stored in a memory through the communication interface and executes the methods provided in any of the above aspects or their implementations. The communication interface can be implemented in hardware or software.

[0086] Optionally, as one implementation, the chip also includes a memory that stores computer programs or instructions. The processor is used to execute the computer programs or instructions stored in the memory. When the computer programs or instructions are executed, the processor is used to perform the methods provided by any of the above aspects or their implementations.

[0087] When the method provided in this application is executed by a chip, this application does not limit the specific number of chips implementing the method. For example, it can be executed by one chip, or by two or more chips. Furthermore, when the number of chips implementing the method is two or more, the chip manufacturers are not limited; they can be from the same manufacturer or different manufacturers.

[0088] In a sixteenth aspect, a communication system is provided, comprising at least one of the means described above (e.g., a first means, a second means, a third means, an endorsement means). Attached Figure Description

[0089] Figure 1 is a schematic diagram of a network architecture applicable to the communication method provided in the embodiments of this application.

[0090] Figure 2 is a schematic diagram of a network architecture applicable to another communication method provided in the embodiments of this application.

[0091] Figure 3 is a schematic diagram of a communication system applicable to an embodiment of this application.

[0092] Figure 4 is a schematic diagram of another communication system applicable to the embodiments of this application.

[0093] Figures 5 to 12 are schematic flowcharts of the communication method provided in this application.

[0094] Figure 13 is a schematic block diagram of a communication device 1000 provided in an embodiment of this application.

[0095] Figure 14 is a schematic block diagram of the communication device 1100 provided in an embodiment of this application.

[0096] Figure 15 is a schematic diagram of a chip system 1200 provided in an embodiment of this application. Detailed Implementation

[0097] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0098] The method provided in this application can be used in various communication systems. For example, the communication system can be a long-term evolution (LTE) system, a 5th generation (5G) communication system, a wireless fidelity (WiFi) system, a 3rd generation partnership project (3GPP) related communication system, a future communication network, or a system integrating multiple systems, etc., without limitation. Among them, 5G can also be referred to as new radio (NR).

[0099] To better understand the methods provided in this application, the following is a brief explanation of the terms used in this application.

[0100] 1. Distributed Ledger (DL) Technology: A database technology characterized by a record system distributed across different locations and maintained collaboratively by multiple participants. The core characteristic of distributed ledger technology is decentralization. Data and transaction management no longer relies on a single central authority, but rather multiple devices within the DL network jointly verify, store, and update data. This structure makes the system more transparent, robust, and reduces the risk of single points of failure. To ensure consensus on data consistency among devices, distributed ledgers employ a consensus mechanism. This means that all transactions or events must be verified and agreed upon by devices in the network before being added to the ledger. Once data is added to the DL, it is difficult to modify or delete. Each data block is linked to the previous data block, forming a continuously expanding chain structure (such as a blockchain). This structure ensures that modifying any data block requires modifying the entire ledger, greatly enhancing data security and trustworthiness. A distributed ledger can be understood as a distributed database, typically possessing high transparency, allowing participants to view and verify the data on the ledger. However, for the processing of sensitive information, some distributed ledger technologies provide privacy protection mechanisms, such as using encryption algorithms to protect the privacy of data.

[0101] It is understandable that distributed ledgers are usually represented by blockchains, so "distributed ledger" in this application can also be replaced with "blockchain".

[0102] 2. DL Network: Devices participating in the maintenance and querying of the DL form the DL network. Devices participating in the DL network may directly maintain and query the DL (i.e., have consensus, query, and write permissions to the DL), or they may participate in the maintenance and querying of the DL through other devices (i.e., do not have direct consensus, query, and write permissions to the DL).

[0103] In this application, the device participating in the DL network can also be referred to as a node in the DL network, such as including but not limited to radio access network (RAN) nodes, core network elements, network functions (NF), and operator-owned servers.

[0104] In one possible design, the terminal is a node in the DL network. Optionally, the nodes in the DL network also include the terminal. For example, the devices that may directly maintain and query the DL could be NF, base stations, or standalone servers; the devices that may participate in maintaining and querying the DL through other devices could be terminals.

[0105] In another possible design, the terminal is not a node in the DL network, but can obtain services from the DL network.

[0106] 3. User-centric Digital Identity (UCDID): Distributed ledger technology, as a novel technology, is highly likely to be introduced into future networks. Users can join a distributed ledger using their digital identities. This allows different operators to share the same distributed ledger, which is very convenient. UCDID can be seen as a possible form of digital identity. UCDID can be considered an extension of the decentralized identity (DID) defined by the World Wide Web Consortium (W3C).

[0107] The definition of UCDID can be as follows: UCDID corresponds to a subject, which may be a natural person, social institution / organization, digital avatar, Internet of Things (IoT) device, terminal device, or physical or virtual network entity.

[0108] In telecommunications networks, a UCDID can be used to identify a subscriber; a UCDID can represent a virtual or physical entity, such as a base station, a virtual machine belonging to an NF, or a digital virtual avatar of an end user; a UCDID can represent a telecommunications network operator; a UCDID can represent a university / bank / third-party service provider.

[0109] The parameters included in a UCDID are described below. A UCDID includes an identity document (ID) and a profile. Furthermore, the profile contains a document and a verifiable credential (VC).

[0110] (1) ID in UCDID: Used to identify an entity. For example, the entity can be a natural person, social institution / organization, digital avatar, virtual machine, or network entity. For example, a network entity can be a RAN node, core network element, NF entity, server, etc.

[0111] For example, UCDIDs can be stored in the DL as key-value pairs. In this case, the ID can be used as an index for the UCDID to look up the profile corresponding to that ID in the DL.

[0112] (2) The parameters included in the document and VC in the UCDID profile are described in Table 1 and Table 2.

[0113] 1) The document includes descriptive information related to the UCDID subject. The meanings of the parameters included in the document are shown in Table 1.

[0114] Table 1

[0115] 2) A VC is a collection of claims that can be verified using the issuer's public key. A VC can include two types: key credentials (KC) and attribute credentials (AC). For example, the meaning of one or more fields in the VC's data structure is shown in Table 2.

[0116] Table 2

[0117] In this context, the declaration fields of a VC can be understood as including the specific content of that VC. The following examples illustrate the declarations using AC and KC.

[0118] For AC, the claim includes one or more attribute information. The claim may represent a long-term claim of the subject (such as date of birth, nationality, company address, ownership), for example, a long-term claim is "the user was born in 2000"; or the claim may be a temporary claim (such as the subject's current location or subscribed services), for example, a temporary claim is "this user has subscribed to the Avata service".

[0119] For KC, this statement is typically a public key certificate endorsed by a network operator or other trusted authority. The subject of a UCDID can use KC to access the operator's network.

[0120] Figure 1 is a schematic diagram of the VC data model proposed by the W3C. This model illustrates issuers, holders, verifiers, and a verifiable data registry platform. Issuers are the publishers (or signatories) of VCs, holders are the holders of VCs, and verifiers are the verifiers of VCs. Issuers issue VCs to the subject of a VC, where a VC can include one or more claims. Issuers send VCs to holders, who may be the same as or different from the subject. Verifiers issue verification requests when they need to verify certain claims within a VC. VC holders or subjects can process VCs to generate verifiable presentations (VPs) and submit them to verifiers, who then verify the VPs.

[0121] This application aims to apply distributed ledger technology and digital identity technology to telecommunications networks to achieve cross-ledger authentication for VCs.

[0122] Figure 2 is a schematic diagram of a network architecture applicable to the communication method provided in the embodiments of this application. Figure 2 illustrates a network architecture within an operator network. This network architecture shows a distributed ledger anchor function (DLAF) entity, a distributed ledger enabler (DLE) entity, an identifier (ID) management (IDM) entity, a user plane function (UPF) entity, and a data network (DN) entity.

[0123] The DLAF entity serves as the anchor point for the overall management and association of DLs within the network. It can be used to perform DL management functions, DLE entity registration management, chain creation, DLE entity activation, and access control of DLs. DLAFs are typically deployed in the core network as network functions, but a hierarchical structure may also exist, with sub-DLAFs deployed in the access network. The IDM entity can be seen as an enhancement to the unified data management (UDM) in the current 5G core network (5Gcorenet, 5GC). It is used to store user digital identities and credentials and can also issue digital identities to terminal devices and network functions (NFs). For example, DLAFs and IDMs can be independent entities, deployed in the core network as NFs.

[0124] A DLE entity is a distributed ledger enablement module in a DL network, which can be configured and managed by a DLAF. A DLE entity can have one or more of the following functions: transaction proposal, transaction endorsement / execution, deployment and execution of smart contracts, consensus, transaction / block synchronization, or ledger storage or retrieval. A DLE entity can be deployed on various nodes in the DL network; for example, a DLE can be deployed on terminals, RAN nodes, core network elements, or NFs. A DLE entity can also function as an independent NF (Distributed Ledger Enable Function, DLEF), providing distributed ledger proxy capabilities to other NFs.

[0125] For example, DLE entities can be categorized into peers or clients based on their roles. For instance, an endpoint can be considered a client. RAN nodes, servers, and core network elements can be considered either clients or peers. Peer nodes can perform one or more of the following operations on the database corresponding to the DL: participate in consensus, propose transactions, and save or query DL data. Clients can perform one or more of the following operations on the database corresponding to the DL: generate transactions or query DL data.

[0126] Optionally, the IDM can be deployed in conjunction with a DLE entity to participate in DL data querying, transaction generation, consensus algorithm participation, etc.

[0127] In this application, RAN nodes can provide wireless access services to terminals. Specifically, each RAN node corresponds to a service coverage area. Terminals entering this area can communicate with the RAN node through an air interface to receive the wireless access services provided by the RAN node. RAN nodes can be, for example, nodes within a RAN or nodes in an open access network (open RAN, O-RAN, or ORAN). RAN nodes can also be referred to as access network equipment, RAN entities, access nodes, or network devices, etc. RAN nodes include, but are not limited to: evolved Node Bs (NodeBs, eNBs, or e-NodeBs) in LTE, next-generation eNBs (ng-eNBs) in next-generation LTE, gNodeBs or gNBs in NR, transmitting points (TPs) or transmission receiving points / transmission reception points (TRPs), 3GPP subsequent evolution base stations, base stations in future mobile communication systems, satellites, access points (APs) in WiFi systems, wireless relay nodes, wireless backhaul nodes, integrated access and backhaul (IAB) nodes, and network equipment in mobile switching center non-terrestrial network (NTN) communication systems. These can be deployed on low-altitude platforms, high-altitude platforms, or satellites. Base stations can be: macro base stations, micro base stations, pico base stations, small cells, relay stations, or balloon stations, etc. Multiple base stations can support networks using the same technology mentioned above, or they can support networks using different technologies mentioned above. A base station can contain one or more co-located or non-co-located TRPs. RAN nodes can also function as base stations in device-to-device (D2D) communication, vehicle-to-everything (V2X) communication, drone communication, and machine-to-machine (M2M) communication. RAN nodes can also be radio controllers in cloud radio access network (CRAN) scenarios. RAN nodes can also be centralized units (CUs), distributed units (DUs), CU-control plane (CP), CU-user plane (UP), radio units (RUs), roadside units (RSUs) with base station functionality, wired access gateways, or core network elements, etc.RAN nodes can also be servers, wearable devices, machine-to-machine communication devices, or vehicle-mounted devices. For example, the access network equipment in V2X technology can be an RSU. The following explanation uses a RAN node as a base station as an example. The multiple RAN nodes can be base stations of the same type or different types. A base station can communicate with a terminal directly or through a relay station. A terminal can communicate with multiple base stations using different technologies; for example, a terminal can communicate with a base station supporting LTE networks, or with a base station supporting 5G networks, and can also support dual connectivity with both LTE and 5G base stations.

[0128] In this application, the CU can implement the functions of the radio resource control (RRC) layer and the packet data convergence protocol (PDCP) layer in the 3GPP standard. The CU can also implement the functions of the service data adaptation protocol (SDAP) layer. The DU can implement the functions of the radio link control (RLC) layer and the medium access control (MAC) layer in the 3GPP standard. The DU can also implement some or all physical layer functions, such as forward error correction (FEC) encoding / decoding, scrambling / descrambling, or modulation / demodulation. The RU can be used to implement radio frequency signal transmission and reception functions. The CU and DU can be set up separately, or they can be included in the same network element, such as in the baseband unit (BBU). It is understood that the CU can be classified as a network device in the access network or a network device in the core network; no limitation is made here. Furthermore, the CU can be further divided into CU-CP and CU-UP. CU-CP can implement the functions of the RRC layer and the control plane functions of the PDCP layer. CU-UP can implement the functions of the SDAP layer and the user plane functions of the PDCP layer.

[0129] In this application, the RU can be included in a radio frequency (RF) device or RF unit, such as in a remote radio unit (RRU), an active antenna unit (AAU), or a remote radio head (RRH). The RU can implement some physical layer functions and RF functions in the 3GPP standard. The physical layer functions implemented by the RU include one or more of the following: Fast Fourier Transform (FFT), Inverse Fast Fourier Transform (IFFT), digital beamforming, or extraction and filtering of the physical random access channel (PRACH), etc.

[0130] 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.

[0131] Terminals can be deployed on land, including indoors, outdoors, handheld, or vehicle-mounted; they can also be deployed on water (such as ships); and they can be deployed in the air (such as airplanes, balloons, and satellites). Terminals can also be called terminal equipment, which can be user equipment (UE), mobile station (MS), mobile terminal (MT), or any device used to provide voice or data connectivity to users. UEs include handheld devices with wireless communication capabilities, vehicle-mounted devices (e.g., cars, bicycles, electric vehicles, airplanes, ships, trains, high-speed trains), wearable devices (e.g., smartwatches, smart bracelets, pedometers), or computing devices. For example, a UE can be a mobile phone, tablet computer, laptop computer, PDA, mobile internet device (MID), satellite terminal, or computer with wireless transceiver capabilities. UE can also be a virtual reality (VR) terminal device, an augmented reality (AR) terminal device, a wireless modem, a point-of-sale (POS) machine, customer-premises equipment (CPE), a smart robot, a robotic arm, workshop equipment, smart home devices (e.g., refrigerators, televisions, air conditioners, electricity meters, etc.), a wireless terminal in industrial control, a wireless terminal in autonomous driving, a wireless terminal in telemedicine, a wireless terminal in a smart grid, a wireless terminal in transportation safety, a wireless terminal in intelligent transportation, a wireless terminal in a smart city, a wireless terminal in a smart home, an in-vehicle terminal, an RSU with terminal functionality, or flying equipment (e.g., a smart robot, a hot air balloon, a drone, an airplane), etc. A terminal can also be other devices with terminal functionality; for example, a terminal can also be a device that performs terminal functionality in D2D communication.

[0132] The terminal can be an on-board module, on-board component, on-board chip, on-board unit (OBU), or telematics box (T-BOX) built into the vehicle as one or more components or units. The vehicle can implement the methods of this application through the built-in on-board module, on-board component, on-board chip, on-board unit, or T-BOX. The terminal can also be a complete vehicle device.

[0133] Understandably, in some scenarios, the roles of RAN nodes and terminals are relative. For example, a helicopter or drone, which is usually configured as a terminal, can also be configured as a mobile base station, and a device that accesses the RAN via a helicopter or drone is configured as a terminal.

[0134] Core network elements refer to network elements in the core network, such as network slice selection function (NSSF) network elements, network exposure function (NEF) network elements, network repository function (NRF) network elements, policy control function (PCF) network elements, UDM network elements, application function (AF) network elements, authentication server function (AUSF) network elements, access and mobility management function (AMF) network elements, session management function (SMF) network elements, or user plane function (UPF) network elements, etc.

[0135] It is understood that the two operators in this application may correspond to the same DL or two DLs. For example, operator A and operator B can transmit messages through security edge protection proxies (SEPPs). For instance, the two operators are operator A and operator B, and there exist SEPP-a and SEPP-b, where SEPP-a belongs to operator A and SEPP-b belongs to operator B. Both operators pre-configure each other's SEPP public keys, and SEPP-a and SEPP-b can trust each other. Therefore, operator A and operator B can transmit messages through SEPPs.

[0136] Figure 3 is a schematic diagram of a communication system applicable to an embodiment of this application. As shown in Figure 3, this scenario includes networks DL1 and DL2. In this application, networks DL1 and DL2 may belong to different operators or different network domains of the same operator. For example, DL1 belongs to operator A, and DL2 belongs to operator B. Another example is that network DL1 belongs to operator A's network deployed in location B, and network DL2 belongs to operator A's network deployed in location C.

[0137] The DL1 network comprises multiple nodes, such as DLE0, DLE1, and DLE2-a, which establish trust through DL1. For example, DLE0 might be a terminal device, while DLE1 and DLE2 are telecommunications network nodes, which could be access network equipment, NFs, or dedicated servers deployed by the operator specifically for running DL, etc., without limitation. The DL2 network also comprises multiple nodes, such as DLE2-b, DLE3, and DLE4, which establish trust through DL2. Again, these could be access network equipment, NFs, or dedicated servers deployed by the operator specifically for running DL, etc., without limitation.

[0138] In one possible implementation, DLE2-a and DLE2-b are the same DLE node (hereinafter referred to as DLE2). In this case, DLE2 is a cross-distributed ledger node, meaning that DLE2 is a common node belonging to both the DL1 and DL2 networks. For example, in this implementation, DL1 and DL2 can establish trust through DLE2.

[0139] In another possible implementation, DLE2-a and DLE2-b are different DLE nodes. For example, in this implementation, DL1 and DL2 can establish trust by reusing the SEPP in the multi-carrier architecture described above between DLE2-a and DLE2-b. As shown in Figure 4, DLE2-a and SEPP-a belong to the same carrier and therefore can trust each other; DLE2-b and SEPP-b belong to the same carrier and therefore trust each other; the two carriers have a cooperative relationship and pre-configure each other's SEPP public keys, therefore, SEPP-a and SEPP-b can also trust each other; through SEPP-a and SEPP-b, DLE2-a and DLE2-b can establish trust. For example, SEPP can also be co-located with the corresponding DLE2 or set up independently.

[0140] Based on current development trends, if deep learning (DL) and digital identity technologies are introduced into telecommunications networks, it is highly likely that multiple blockchains will be established geographically, such as one blockchain within the EU and another within Asia. For example, in scenarios such as international business trips, tourism, education, and immigration, users' cross-border activities may lead to their movement between different telecommunications network blockchains. If a user is originally in Europe, the European telecommunications network blockchain stores a large amount of the user's credentials, which are issued by organizations on the European telecommunications network blockchain. When the user moves to China, they will join the Chinese telecommunications network blockchain. At this point, because the user's credentials are stored on the European telecommunications network blockchain, and the issuers of the user's credentials are not involved in the Chinese telecommunications network blockchain, the nodes on the Chinese telecommunications network blockchain will be unable to verify the user's credentials. This will cause the user's credentials to become invalid, resulting in wasted resources and a negative impact on user experience. Therefore, there is a need for cross-distributed ledger-based user credential mobility (digital identity).

[0141] In view of this, this application proposes several communication methods that can achieve the above requirements. These communication methods are described in detail below.

[0142] Figure 5 is a schematic flowchart of the communication method 500 provided in this application. The method includes the following steps.

[0143] It is understood that the methods provided below in this application use a device (such as a first device, a second device, a third device, a fourth device, etc.) as an example to illustrate the method, but this application does not limit the execution subject of the interaction. For example, any device in the method provided in the following embodiments of this application can also be a chip, chip system, or processor that supports the device in implementing the method, or it can be a logic device, logic module, or software that can implement all or part of the functions of the device.

[0144] For example, the method provided in this application can be applied to the communication system shown in FIG3 above. For instance, in the following embodiments of this application, the first distributed ledger can be DL1 in FIG3, the second distributed ledger can be DL2 in FIG3, the first device can be DLE0 in the network of DL1 in FIG3, the second device can be DLE2-b in the network of DL2 in FIG3, the third device can be DLE3 or DLE4 in the network of DL2 in FIG3, and the fourth device can be DLE2-a in the network of DL1 in FIG3.

[0145] S510, the first device sends a first request message. The first request message requests the publication of the first device's second key credential in the second distributed ledger. Correspondingly, the second device in the network of the second distributed ledger receives the first request message from the first device.

[0146] For example, the first request message includes the identifier of the first device and the identifier of the second distributed ledger.

[0147] In one implementation, the message name of the first request message can be used to indicate the function of the message. For example, if the message name of the first request message is "Key Credentials Cross-Distributed Ledger Request Message," then the second device can determine, based on the message name of the first request message and the identifiers of the first device and the second distributed ledger in the first request message, that the first request message is used to request the publication of the first device's second key credential in the second distributed ledger.

[0148] In another implementation, the first request message includes an indication that can be used to indicate the function of the message. Then, the second device can determine, based on the first indication in the first request message, the identifier of the first device, and the identifier of the second distributed ledger, that the first request message is used to request the publication of the first device's second key credential in the second distributed ledger.

[0149] In another implementation, the first request message includes a message attribute identifier that indicates the function of the message.

[0150] It is understood that in this application, the first device has already published a first key credential in the first distributed ledger. That is, the first distributed ledger stores the first key credential of the first device, which includes the public key and signature of the first device. The signature in the first key credential can be verified by devices in the network of the first distributed ledger. In this application, the first request message requests the publication of the second key credential of the first device in the second distributed ledger, i.e., requests the generation of a key credential that can be verified by devices in the network of the second distributed ledger. For example, the first request message can be sent directly from the first device to the second device, or it can be forwarded to the second device through an intermediate device; there is no limitation on this.

[0151] It is understandable that the triggering condition for the first request message is the fulfillment of a condition for the first device to cross the distributed ledger. For example, this condition could be that the user moves with the first device, or that the user wants to change carriers; there are no specific limitations.

[0152] S520, the second device obtains the second key credential. The second key credential includes the first device's public key (PK) and signature. The first device's PK is the PK in the first key credential published by the first device in the first distributed ledger. The signature is generated based on the second distributed ledger's private key (SK) and verified using the second distributed ledger's public key.

[0153] In this application, a distributed ledger has a PK and an SK. If a device (hereinafter referred to as device A) in the network of a second distributed ledger can obtain the SK of the second distributed ledger, it can use the SK of the second distributed ledger to endorse the PK of the first device published in the first distributed ledger to generate a second key certificate for the first device. This second key certificate includes the PK of the first device published in the first distributed ledger and a signature. It can be understood that the signature in the second key certificate is generated based on the SK of the second distributed ledger; that is, device A endorses the PK of the first device through the signature. Subsequently, a device (hereinafter referred to as device B) in the second distributed ledger that can obtain the PK of the second distributed ledger can use the PK of the second distributed ledger to verify the signature of the second key certificate. If the verification is successful, device B can use the PK of the first device in the second distributed ledger.

[0154] For example, when creating a distributed ledger, the operator can generate a public-private key pair for the distributed ledger, which will serve as the PK and SK of the distributed ledger, respectively.

[0155] For example, the PK of a distributed ledger can be stored on that distributed ledger. For instance, the first piece of data stored in each distributed ledger is the ID of that distributed ledger and the PK of that distributed ledger.

[0156] For example, the SK of a distributed ledger can be pre-installed on devices within the distributed ledger network. Because the SK of a distributed ledger is relatively important, it should generally not be pre-installed on all devices in the distributed ledger network, but rather on a subset of devices.

[0157] In one possible implementation, if the second device has a pre-configured SK of the second distributed ledger, then the second device obtains the second key credential by: the second device generating the second key credential based on the SK of the second distributed ledger.

[0158] In another possible implementation, the second device obtains the second key credential by requesting device C in the network of the second distributed ledger to generate the second key credential. Device C is a device with a pre-configured SK of the second distributed ledger. Therefore, after receiving the above request message, device C can generate the second key credential based on the SK of the second distributed ledger and send the second key credential to the second device.

[0159] Optionally, the device generating the second key credential (e.g., the second device or device C) may perform the following steps before generating the second key credential: query the second distributed ledger, check whether the first device is a device in the network of the second distributed ledger, if not, check whether there is a key credential corresponding to the first device in the second distributed ledger, and if not, generate the second key credential.

[0160] For example, this application proposes an endorsement replacement smart contract that can be used to generate a second key credential. It is understood that a smart contract is a piece of automatically executing code; for any device with the smart contract installed, as long as the input parameters of the smart contract are the same, the output parameters obtained after running the smart contract will be the same. This smart contract will be described in detail later with reference to Table 4, and will not be elaborated upon here.

[0161] For example, in this method, the input parameters of the smart contract include the identifier of the first device and the public key of the first device in the first key credential, and the output parameter is the second key credential.

[0162] Optionally, before the second device obtains the second key credential, the second device or another device needs to first determine that the identity of the first device has not been impersonated, that is, to determine that the first request message was sent by the first device, and not sent by another device impersonating the first device.

[0163] For example, the first device may carry first encrypted information in the first request message. The first encrypted information is obtained by encrypting using the SK of the first device. The second device or other devices mentioned above can use the PK of the first device to decrypt the first encrypted information, and determine whether the identity of the first device has been impersonated based on the decryption result. The specific reasons are explained below.

[0164] It is understandable that if the first request message is sent by the first device, the first encrypted information in the first request message is obtained by encrypting it using the SK of the first device. Therefore, the second device or other devices can successfully decrypt the first encrypted information using the PK of the first device, thus confirming that the identity of the first device has not been impersonated. If the first request message is sent by a device impersonating the first device, since the device impersonating the first device cannot obtain the SK of the first device, the first encrypted information carried in the first request message must not be obtained based on the SK of the first device. Therefore, the second device or other devices cannot successfully decrypt the first encrypted information using the PK of the first device, thus confirming that the identity of the first device has been impersonated.

[0165] In one possible scenario, the second device is a public device in both the network of the first distributed ledger and the network of the second distributed ledger. In this case, the second device can determine whether the identity of the first device has been impersonated based on the first encrypted information carried in the first request message. Optionally, in this scenario, as shown in Figure 5, before S520, the method 500 further includes S5201 and S5202.

[0166] S5201, the second device obtains the PK of the first device in the first key credential.

[0167] It can be understood that the second device is a common device in the network of the first distributed ledger and the network of the second distributed ledger. Therefore, the second device can obtain the first key certificate in the first distributed ledger, and then verify the signature of the first key certificate. If the verification is successful, the PK of the first device in the first key certificate can be used.

[0168] For example, if the first request message includes the identifier of the first device, the second device can obtain the first key credential from the first distributed ledger based on the identifier of the first device.

[0169] For example, the first request message may also carry a first key credential. Optionally, in this example, the second device may verify whether the first key credential carried in the first request message is the same key credential of the first device stored in the first distributed ledger.

[0170] S5202, the second device successfully decrypted the first encrypted information based on the PK of the first device.

[0171] It is understandable that successful decryption indicates that the identity of the first device has not been impersonated; otherwise, it indicates that the identity of the first device has been impersonated. After confirming that the identity of the first device has not been impersonated, the second device responds to the first request message and uses the first device's PK to obtain the second key credential. As mentioned above, for example, the second device can generate the second key credential based on the first device's PK; or, for example, the second device can inform device C of the first device's PK and request device C to generate the second key credential.

[0172] Example 1: The first encrypted information is obtained by encrypting the first value corresponding to the first parameter using the private key of the first device. The first parameter is a parameter associated with the first distributed ledger. Based on this example, the second device can also obtain the first value corresponding to the first parameter from the first distributed ledger. If, in S5202, the second device decrypts the first encrypted information based on the PK of the first device to obtain the decryption result and determines whether the decryption was successful, and if the decryption result is equal to the first value, then the decryption is considered successful.

[0173] For example, the first parameter is the hash of the latest block or a specified block in the first distributed ledger. For example, the first parameter is the generation time of the latest block or a specified block in the first distributed ledger. It should be noted that if the first parameter is a parameter for a specified block, the first request message also includes the block number of that specified block.

[0174] Example 2: The second device can first send a value #1 to the first device (in this example, the value #1 is a random number or nonce). The first device encrypts the value #1 based on the SK of the first device to obtain the first encrypted information, and then sends the first encrypted information to the second device.

[0175] As can be seen, in the method for determining the first encrypted information based on Example 1, the first parameter is a parameter associated with the first distributed ledger. Both the first device and the second device can obtain the value corresponding to the first parameter from the first distributed ledger. Therefore, compared with the method for determining the first encrypted information in Example 2, the second device does not need to send the value #1 to the first device in advance, which can reduce the interaction process on the first device side and simplify the authentication process.

[0176] In another possible scenario, the second device is neither a public device in the network of the first distributed ledger nor in the network of the second distributed ledger. It is understood that since the second device is not a device in the network of the first distributed ledger, it cannot obtain the first key credential, i.e., it cannot obtain the PK of the first device, and therefore cannot confirm whether the identity of the first device has been impersonated. In this scenario, another device in the network of the first distributed ledger trusted by the second device (hereinafter referred to as the fourth device) can determine whether the identity of the first device has been impersonated based on the first encrypted information. If it has not been impersonated, the fourth device can then directly send or indirectly forward the PK of the first device contained in the first key credential to the second device so that the second device can obtain the second key credential. For example, if the second device described above is DLE2-b (a non-public device) as shown in Figure 3, then the fourth device can be DLE2-a as shown in Figure 3.

[0177] Optionally, in this scenario, the sending of the first request message by the first device in S510 includes: the first device sending the first request message to the fourth device. Correspondingly, the fourth device receives the first request message from the first device. For example, the first device sending the first request message to the fourth device can be done directly or through an intermediate device, without limitation. Subsequently, before S520, the method 500 may further include the following steps.

[0178] S5201', the fourth device obtains the PK of the first device in the first key certificate.

[0179] S5202′, The fourth device successfully decrypted the first encrypted information based on the PK of the first device.

[0180] It is understandable that if decryption is successful, it means that the identity of the first device has not been impersonated. Then, the fourth device will inform the second device of the first device's PK in S5203' so that the second device can obtain the second key credential.

[0181] S5203', the fourth device sends a request message #A to the second device, wherein the request message #A includes the PK of the first device, and the request message #A is used to request the publication of the second key credential of the first device in the second distributed ledger. Correspondingly, the second device receives the request message #A from the fourth device.

[0182] Subsequently, in response to request message #A, the second device obtains the second key credential using the first device's PK. As described above, for example, the second device can generate the second key credential based on the first device's PK, or, for example, the second device can inform device C of the first device's PK and request device C to generate the second key credential.

[0183] Optionally, after the second device obtains the second key credential, i.e., after S520, the method further includes:

[0184] S5204', the second device sends a request response message #A to the fourth device, the request response message #A including the second key credential.

[0185] The process of generating a second key certificate based on a first key certificate has been described in detail above. For example, in addition to the first device PK and signature, the first and second key certificates may also include information corresponding to the fields in Table 2 other than the declaration and signature fields.

[0186] The following example uses the first distributed ledger as DL1 and the second distributed ledger as DL2, providing a simple example of a first key credential and a second key credential. It can be seen that the Domain ID, issuer ID, Validity fields, and signature in the second key credential are different from the corresponding fields and signature in the first key credential.

[0187] Table 3

[0188] It is understood that using the Domain ID in the second key credential as the DL2 ID in Table 3 is merely an example. For instance, the Domain ID in the second key credential can also be the PLMN identifier of the operator corresponding to DL2, or the identifier of the subnet (or network domain) of the operator corresponding to DL2, or the network identifier of a certain area covered by the operator corresponding to DL2; there are no limitations.

[0189] For example, the private key could be the private key of DL1, or it could be the private key of another device within the DL1 network. For example, the signature in the first key credential is generated based on the private key of a device within the DL1 network. For instance, the private key could be the private key of an IDM within DL1.

[0190] S530, the second device sends a first request-response message, which includes a second key credential. Correspondingly, the first device receives the first request-response message.

[0191] For example, the first request response message may also include the identifier of the first device and / or the identifier of the second distributed ledger.

[0192] For example, the first request-response message may also include verification information, which is used to verify whether the second key credential is stored in the second distributed ledger. Correspondingly, the first device verifies whether the second key credential is indeed stored in the second distributed ledger based on the verification information. If the verification is successful, the first device stores the second key credential and its identifier locally. It can be understood that if the first request-response message includes the identifier of the second distributed ledger, then the identifier of the second distributed ledger, the second key credential, and the identifier of the first device are stored locally.

[0193] For example, after the first device stores the second key credential locally, it issues other credentials using its own public and private key pairs. These credentials can also be verified by devices in the network of the second distributed ledger. For instance, the first device can issue credential #1, which includes a signature obtained using the first device's private key. When a device in the network of the second distributed ledger receives credential #1, it can obtain the first device's PK based on the second key credential stored in the second distributed ledger and verify the signature of credential #1 based on that PK.

[0194] For example, the first request-response message may also carry the identifiers of other devices in the network of the second distributed ledger. For instance, the first device can use the identifier of the other device to communicate with it or request to join the second distributed ledger.

[0195] It is understood that the first request-response message can be sent directly from the second device to the first device, or it can be forwarded to the first device through an intermediate device, without limitation. Generally, the first request-response message and the first request message have the same transmission path, but are transmitted in opposite directions.

[0196] Optionally, if the second device is a device for generating the second key credential, then before sending the first request-response message, the method further includes: the second device triggering a consensus device in the network of the second distributed ledger to reach a consensus on the second key credential; further, sending the first request-response message includes: sending the first request-response message if the consensus is successful.

[0197] For example, the second device triggering consensus on the second key credential can be implemented in two ways: Method 1, the second device directly initiates consensus on the second key credential to other consensus devices; Method 2, the second device instructs a consensus device, and the instructed consensus device initiates consensus on the second key credential.

[0198] For example, the consensus algorithm is roughly as follows: Generally, the second device sends the first device's PK and second key credential to other consensus devices or a designated consensus device. Devices participating in the consensus within the second distributed ledger can generate a key credential based on the first device's PK and the private key of the second distributed ledger. They compare the generated key credential with the second key credential and vote based on the comparison result. The success of the consensus is determined by the voting results of the consensus nodes. If the consensus is successful, the second key credential is stored in the second distributed ledger. It should be noted that the success of the consensus is related to pre-defined voting rules. For example, a pre-defined rule might be that consensus is successful if all consensus devices vote in favor, or it might be that consensus is successful if more than 2 / 3 of the consensus devices vote in favor.

[0199] In the above method, the second distributed ledger has a public key and a private key. A device in the network of the second distributed ledger that can obtain the SK of the second distributed ledger can generate a second key certificate based on the SK of the second distributed ledger and the PK of the first device, thereby realizing the endorsement and replacement of the first key certificate.

[0200] The following description, in conjunction with Figure 6, illustrates possible application scenarios for the second key credential. The method 600 shown in Figure 6 may include the following steps.

[0201] S610, the third device in the second distributed ledger sends a second value to the first device. Correspondingly, the first device receives the second value from the third device.

[0202] It is understandable that the third device sends the second value to authenticate the first device, which will be described in detail later. For example, the second value can be a random number or a nonce.

[0203] Optionally, prior to S610, the third device can actively trigger authentication of the first device.

[0204] Optionally, prior to S610, the first device may send a third request message to the third device, the third request message being used to request authentication of the first device. Correspondingly, the third device receives the third request message from the first device. For example, the third request message includes the identifier of the first device.

[0205] Optionally, before sending the second value to the first device, the third device may first query whether the second key credential of the first device exists in the second distributed ledger. If it exists, the third device may send the second value to the first device.

[0206] S620, the first device sends second encrypted information to the third device. The second encrypted information is obtained by encrypting a second value using the SK of the first device. The second encrypted information is used to authenticate the first device. Correspondingly, the third device receives the second encrypted information from the first device.

[0207] S630, the third device obtains the second key credential of the first device in the second distributed ledger.

[0208] Since the second key credential is obtained from the second distributed ledger, the third device can directly use the first device's PK in the second key credential in subsequent steps without verifying the signature of the second key credential.

[0209] S630 only needs to be executed before S640; this application does not specify the exact time for executing S630.

[0210] S640, based on the PK of the first device in the second key certificate, the second encrypted information is decrypted to obtain the decryption result.

[0211] S650, the third device sends the authentication result of the first device to the first device. Correspondingly, the first device receives the authentication result of the first device from the third device.

[0212] It is understandable that if the decryption result and the second value are consistent, the authentication result indicates that the authentication has passed; otherwise, the authentication result indicates that the authentication has failed.

[0213] For example, the statement that the decryption result matches the second value can be understood as either the decryption result and the second value being identical or equal.

[0214] For example, if the third device receives a third request message from the first device, then in S660, the third device sends an authentication result of the first device to the first device, including: the third device sending a third request response message to the first device, the third request response message including the authentication result of the first device. Correspondingly, the first device receives the third request response message from the third device.

[0215] For example, the third request message is used to request authentication of the first device. Specifically, the third request message can be used to request joining or accessing the second distributed ledger, or to request services from the network of the second distributed ledger, or to request establishing a connection with the third device. Then, if the decryption result matches the second value, the third request response message indicates agreement to join or access the second distributed ledger, or indicates agreement to provide services from the network of the second distributed ledger, or indicates agreement to establish a connection with the third device.

[0216] For example, after receiving the third request message, in some possible scenarios, the third device may request the fifth device in the second distributed ledger to authenticate the first device (in this scenario, the fifth device performs the authentication of the first device and returns the authentication result to the third device). Possible scenarios include, but are not limited to: the third device lacks permission to query the second distributed ledger and therefore cannot obtain the second distributed ledger's key (PK) to authenticate the first device; or, the network of the second distributed ledger has the fifth device specifically configured for authentication.

[0217] The process of generating a second key credential by endorsing and replacing the first key credential has been described in detail above. The complete implementation process of method 500 is illustrated below with reference to Figures 7 and 8.

[0218] It is understood that method 700 shown in Figure 7 and method 800 shown in Figure 8 are possible specific implementation processes given based on method 500. Therefore, the descriptions in method 700 and method 800 that are the same as those in method 500 will not be repeated. For descriptions that are not detailed, please refer to the description in method 500.

[0219] Figure 7 is a flowchart of the communication method 700 proposed in this application. The method 700 includes the following steps.

[0220] In method 700, DL1 can be an example of the first distributed ledger in method 500, DL2 can be an example of the second distributed ledger in method 500, DLE0 can be an example of the first device in method 500, and DLE2 can be an example of the second device in method 500. Furthermore, KC1 in method 700 can be considered an example of the first key credential in method 500, and KC2 can be considered an example of the second key credential in method 500.

[0221] Taking the application of method 700 to Figure 3 as an example, the above-mentioned DL1, DL2, and DLE0 can be DL1, DL2, and DLE0 in Figure 3, the above-mentioned DLE2 can be DLE2-a in Figure 3, and DLE2-a and DLE2-b in Figure 3 are the same DLE node.

[0222] S710, DLE0 determines that the conditions for cross-distributed ledger are met, and the target distributed ledger is DL2.

[0223] S720, DLE0 uses its own private key to encrypt h1 (i.e., an example of the value of the first parameter) to obtain enc(h1) (i.e., an example of the first encrypted information).

[0224] It is understandable that DLE0 generates enc(h1) to prove that it holds its own public and private keys, that is, that its identity has not been impersonated. This has been described in detail above and will not be repeated here.

[0225] S730, DLE0 sends request message #1 (an example of the first request message) to DLE2. Request message #1 carries the DLE0 ID, DL2 ID, and enc(h1). Correspondingly, DLE2 receives request message #1 from DLE0.

[0226] For example, DLE0 can send request message #1 to DLE2 directly, or it can be forwarded through an intermediate DLE. The following examples illustrate these two sending methods.

[0227] Method 1: DLE0 forwards request message #1 to DLE2 through an intermediate DLE.

[0228] For example, DLE0 is connected to DLE1 (e.g., DLE0 is a UE, DLE1 is a base station), and DLE1 is connected to DLE2. Then, DLE0 can send request message #1 to DLE2 through DLE1. For example, DLE1 stores a list of DLEs in DL1's network and determines that DLE2 belongs to DL2's network. Alternatively, DLE1 can find DLE2 by querying the UCDID of DLEs in DL1's network and discovering that the Domain ID of DLE2's UCDID is the DL2 ID. See S730a to S730c in Figure 7 for the above description.

[0229] Method 2: DLE0 sends request message #1 directly to DLE2.

[0230] For example, DLE0 stores the list of DLEs in the DL1 network and determines that DLE2 belongs to the DL2 network. Alternatively, DLE0 can find DLE2 by querying the UCDID of the DLEs in the DL1 network and discovering that the Domain ID of DLE2's UCDID is the DL2 ID, and then directly send request message #1 to DLE2.

[0231] S740, DLE2 obtains KC1 in DL1 based on DLE0 ID, and KC1 includes DLE0 ID and PK.

[0232] S750, DLE2 is based on DLE0's PK decryption enc(h1).

[0233] If decryption is successful, proceed to step S760. For the detailed verification process, please refer to the description in S5202; it will not be repeated here.

[0234] S760, DLE2 generates KC2 based on the PK, ID and SK of DLE0 and DL2.

[0235] S770, DLE2 triggers consensus nodes (e.g., DLE3) to reach consensus on KC2. If consensus is successful, S780 is executed.

[0236] In one possible implementation, this application proposes an endorsement replacement smart contract, which can be installed on DLE2 and the consensus node. This contract can be used to generate KC2. For example, the content of this smart contract is shown in Table 4.

[0237] As can be understood, a smart contract is a piece of automatically executing code. For a DLE with this smart contract installed, as long as the input parameters of the smart contract are the same, the output parameters (i.e., the output KC) obtained after running the smart contract will be the same. Therefore, this smart contract can be installed on DLE2 and consensus nodes to achieve consensus on KC2.

[0238] Table 4

[0239] S780, DLE2 sends a request-response message #1 (i.e., an example of the first request-response message) to DLE0. The request-response message #1 includes KC2.

[0240] For example, request response message #1 also includes a DL2 ID and / or a DLE0 ID.

[0241] For example, if DLE0 has high security requirements, DLE2 can also obtain verification information #1 from DL2. Verification information #1 is used to verify whether KC2 is stored in DL2, and verification information #1 can be carried in request-response message #1. After that, S790 is executed.

[0242] S790, DLE2 verifies that KC2 is indeed stored in DL2 based on the verification information, and DLE2 saves KC2 and DLE0 ID accordingly.

[0243] Figure 8 is a flowchart of the communication method 800 proposed in this application. The method includes the following steps:

[0244] In method 800, DL1 can be an example of the first distributed ledger in method 500, DL2 can be an example of the second distributed ledger in method 500, DLE0 can be an example of the first device in method 500, DLE2-b can be an example of the second device in method 500, and DLE2-a can be an example of the fourth device in method 500. Furthermore, KC1 in method 800 can be considered an example of the first key credential in method 500, and KC2 can be considered an example of the second key credential in method 500.

[0245] Taking the application of method 800 to Figure 3 as an example, the above DL1, DL2, DLE0, DLE2-a and DLE2-b can be DL1, DL2, DLE0, DLE2-a and DLE2-b in Figure 3, and DLE2-a and DLE2-b are different DLE nodes.

[0246] S801, DLE0 determines that the conditions for cross-distributed ledger are met, and the target distributed ledger is DL2.

[0247] S802, DLE0 uses its own private key to encrypt h1 (i.e., an example of the value of the first parameter) to obtain enc(h1) (i.e., an example of the first encrypted information).

[0248] S803, DLE0 sends request message #1 (an example of the first request message) to DLE2-a. Request message #1 carries the DLE0 ID, DL2 ID, and enc(h1). Correspondingly, DLE2-a receives request message #1 from DLE0.

[0249] For example, DLE0 can send request message #1 to DLE2-a directly or through an intermediate DLE.

[0250] Method 1: DLE0 forwards request message #1 to DLE2 through an intermediate DLE.

[0251] For example, if DLE0 is connected to DLE1 (e.g., DLE0 is the UE and DLE1 is the base station), and DLE1 is connected to DLE2-a, then DLE0 can send request message #1 to DLE2-a through DLE1.

[0252] For example, based on the architecture shown in Figure 4, DLE1 maintains a list of DLEs in DL1's network and determines that DLE2-a is the DLE connected to SEPP-a. Then, DLE1 forwards request message #1 to DLE2-a.

[0253] Method 2: DLE0 directly sends request message #1 to DLE2-a.

[0254] For example, DLE0 stores the list of DLEs in the DL1 network and determines that DLE2-a is the DLE connected to SEPP-a. Then, it sends request message #1 directly to DLE2-a.

[0255] S804, DLE2-a obtains KC1 in DL1 based on DLE0 ID, and KC1 includes the ID and PK of DLE0.

[0256] S805, DLE2-a PK decryption enc(h1) based on DLE0.

[0257] If decryption is successful, continue with S806. For the specific verification process, please refer to the description in S5202′, which will not be repeated here.

[0258] S806, DLE2-a sends request message #2 (an example of request message #A) to DLE2-b. Request message #2 includes the DLE0 ID and the PK of DLE0. Request message #2 is used to request the publication of the KC2 of DLE0 in DL2. Correspondingly, DLE2-b receives request message #2 from DLE2-a.

[0259] For example, request message #2 may also include the DL2 ID. For instance, if DLE2-b is contained in a network of multiple DLs, and those DLs contain DL2, then request message #2 includes the DL2 ID; if DLE2-b is contained only in a network of DL2s, then request message #2 may not include the DL2 ID.

[0260] It is understandable that DLE2-a forwards request message #2 to DLE2-b through SEPP-a and SEPP-b.

[0261] S807, DLE2-b generates KC2 based on the PK, ID and SK of DLE0 and DL2.

[0262] S808, DLE2-b triggers consensus nodes (e.g., DLE3 in Figure 3) to reach consensus on KC2. If consensus is successful, execute S809.

[0263] For example, the endorsement replacement smart contracts shown in Table 4 above can be installed on DLE2-b and consensus nodes to achieve consensus on KC2.

[0264] S809, DLE2-b sends request-response message #2 (an example of request-response message #A) to DLE2-a. Request-response message #2 includes KC2. Correspondingly, DLE2-a receives request-response message #2 from DLE2-b.

[0265] S810, DLE2-a sends request response message #1 (i.e., a column of the first request response message) to DLE0, and request response message #1 carries KC2.

[0266] For example, request message response #1 and request response message #2 also include DL2 ID and / or DLE0 ID.

[0267] For example, if DLE0 has high security requirements, DLE2-b can also retrieve verification information #1 from DL2. Verification information #1 is used to verify whether KC2 is stored in DL2. Then, verification information #1 is carried in request-response message #2. It can be understood that if request-response message #2 carries verification information #1, then request-response message #1 will also carry verification information #1. Therefore, S811 can still be executed.

[0268] S811, DLE0 verifies that KC2 is indeed stored in DL2 based on the verification information, and DLE2 saves KC2 and DLE0 IDs accordingly.

[0269] The above describes in detail the process of generating the second key certificate by endorsing and replacing the first key certificate. The following section, with reference to Figure 9, describes in detail the process of endorsing and replacing attribute certificates.

[0270] Figure 9 is a schematic flowchart of the communication method 900 provided in this application. The method includes the following steps.

[0271] It is understood that the methods provided below in this application use a device (such as a first device, a second device, a third device, an endorsement device, etc.) as an example to illustrate the method, but this application does not limit the execution subject of the interaction. For example, any device in the methods provided in the following embodiments of this application can also be a chip, chip system, or processor that supports the device in implementing the method, or it can be a logic device, logic module, or software that can implement all or part of the functions of the device.

[0272] For example, the method provided in this application can be applied to the communication system shown in FIG3 above. For instance, in the following embodiments of this application, the first distributed ledger can be DL1 in FIG3, the second distributed ledger can be DL2 in FIG3, the first device can be DLE0 in the network of DL1 in FIG3, the second device can be DLE2-b in the network of DL2 in FIG3, the endorsement device can be DLE3 in the network of DL2 in FIG3, and the third device can be DLE4 in the network of DL2 in FIG3.

[0273] S910, a first device in the network of the first distributed ledger sends a first request message. The first request message requests that a second attribute certificate of the first device be published in a second distributed ledger based on a first attribute certificate published in the first distributed ledger. The first attribute certificate includes first attribute information, and the first request message includes relevant information about the first attribute certificate. Correspondingly, a second device in the network of the second distributed ledger receives the first request message.

[0274] The relevant information of the first attribute credential is used to indicate the first attribute credential, and the second device can obtain the first attribute credential based on this information. The relevant information of the first attribute credential is illustrated below.

[0275] It is understandable that the first distributed ledger can store the plaintext or hash of the first attribute credential. For example, the plaintext of the first attribute credential can be the specific content of the first attribute credential or the SN of the first attribute credential. For example, the second device obtains the first attribute credential based on the relevant information of the first attribute credential carried in the first request message, which can include the following implementation methods.

[0276] Method 1: The plaintext of the first attribute certificate is stored on the first distributed ledger. The relevant information of the first attribute certificate includes the SN (an example of plaintext) corresponding to the first attribute certificate. The second device can obtain the plaintext of the first attribute certificate from the first distributed ledger based on the SN.

[0277] Method 2: The first distributed ledger stores the plaintext of the first attribute certificate. The relevant information of the first attribute certificate includes the specific content of the first attribute certificate (denoted as plaintext #1). Then, the second device can obtain the specific content of the attribute certificate corresponding to the SN (denoted as plaintext #2) from the first distributed ledger based on the SN in plaintext #1. Compare whether plaintext #1 and plaintext #2 are the same. If they are the same, then the first attribute certificate is plaintext #1.

[0278] Method 3: The first distributed ledger stores the SN and hash of the first attribute certificate. The relevant information of the first attribute certificate includes the specific content of the first attribute certificate (denoted as plaintext #1). Then, the second device can obtain the hash of the corresponding attribute certificate (denoted as hash #2) from the first distributed ledger based on the SN in plaintext #1, calculate hash #1 based on plaintext #1, and compare whether hash #1 and hash #2 are the same. If they are the same, then the first attribute certificate is plaintext #1.

[0279] Method 4: The hash of the first attribute certificate is stored on the first distributed ledger. The relevant information of the first attribute certificate includes the specific content of the first attribute certificate (denoted as plaintext #1). Then, the second device can calculate hash #1 based on plaintext #1. Based on hash #1, it queries the first distributed ledger to see if there is a hash of the attribute certificate (denoted as hash #2) that is equal to hash #2. If the query is successful, the first attribute certificate is plaintext #1.

[0280] In one implementation, the message name of the first request message can be used to indicate the function of the message. For example, if the message name of the first request message is "Cross-Distributed Ledger Request Message for Key Credentials," then the second device can determine, based on the message name of the first request message, the relevant information of the first attribute credential in the first request message, the identifier of the first device, and the identifier of the second distributed ledger, that the first request message is used to request the publication of the second attribute credential of the first device in the second distributed ledger based on the first attribute credential published in the first distributed ledger.

[0281] In another implementation, the first request message includes an indication message that can be used to indicate the function of the message. Then, the second device can determine, based on the information related to the first attribute credential in the first request message, the first indication message, the identifier of the first device, and the identifier of the second distributed ledger, that the first request message is for requesting the publication of the second attribute credential of the first device in the second distributed ledger based on the first attribute credential published in the first distributed ledger.

[0282] In another implementation, the first request message includes a message attribute identifier that indicates the function of the message.

[0283] It is understandable that the triggering condition for the first request message is the fulfillment of a condition for the first device to cross the distributed ledger. For example, this condition could be that the user moves with the first device, or that the user wants to change carriers; there are no specific limitations.

[0284] For example, the first request message can be sent directly from the first device to the second device, or it can be forwarded to the second device through an intermediate device, without limitation.

[0285] It is understandable that, in addition to the first attribute information, the first attribute credential also includes the issuer's information and the issuer's signature. Generally, this signature is generated based on the issuer's private key, and the issuer's public key is stored in the first distributed ledger. Therefore, devices on the first distributed ledger network can obtain the issuer's public key from the first distributed ledger to verify the first attribute credential. However, devices on other distributed ledger networks cannot obtain the issuer's public key and thus cannot verify the first attribute credential, i.e., cannot use it.

[0286] For example, the first attribute credential can be a credential that needs to be endorsed and updated, selected by the user of the first device from locally stored attribute credentials. For instance, the user can also select a credential that needs to be endorsed and updated through the human-computer interaction interface with the first device. For example, the first attribute credential can be proof of basic attributes related to the user, such as educational certificates, asset certificates, criminal record certificates, etc.; or, the first attribute credential can be proof of services provided to the user by the operator corresponding to the first distributed ledger, such as data and call packages, without limitation.

[0287] For example, the first attribute credential can also be an attribute credential generated based on a locally stored attribute credential. For instance, locally stored attribute credential #1 declares "the user was born in 2000." For privacy reasons, the user generates a first attribute credential stating "the user is 18 years of age or older," and this first attribute credential maintains the signature of attribute credential #1, which can be verified by devices in the network of the first distributed ledger. This application does not limit the method of obtaining the first attribute credential.

[0288] S920, the second device sends first information to the endorsement device in the network of the second distributed ledger. The first information includes a first attribute certificate and is used to instruct the generation of a second attribute certificate based on the first attribute certificate. Correspondingly, the endorsement device receives the first information from the second device.

[0289] Optionally, prior to S920, the method further includes: a second device determining an endorsement device based on the type of the first attribute certificate, the endorsement device being capable of endorsing at least an attribute certificate of the first type, wherein the first attribute certificate is a certificate of the first type. It can be understood that since the second attribute certificate is generated based on the first attribute certificate, the second attribute certificate is also an attribute certificate of the first type.

[0290] For example, an endorsement device is a device capable of endorsing all attribute credentials (or a device specifically designed for endorsement). For instance, the type of endorsement device can be indicated by the service field of the UCDID (e.g., UCDID service="endorsement update").

[0291] For example, an endorsement device is a device capable of endorsing attribute credentials of a first type. For instance, an endorsement device is a device capable of endorsing attribute credentials related to education, and the type of the endorsement device can be indicated by the service field of the UCDID (e.g., UCDID service="education", which can endorse and update attribute credentials with AC usage="education" or "degree").

[0292] Optionally, prior to S920, the method further includes: the second device determining a credential template (CT) based on the first attribute credential, whereby the first information includes the identifier of the CT. Then, the endorsement device can subsequently generate a second attribute credential based on the CT, meaning the second attribute credential conforms to the requirements of the CT. For example, the second device can query CTs that support the same function based on the information corresponding to the usage field of the first attribute credential.

[0293] Optionally, prior to S920, the second device or other device may further verify whether the first attribute credential is a credential issued by a legitimate device in the network of the first distributed ledger, i.e., determine whether the first attribute credential has been tampered with. An example is given below. In one possible scenario, if the second device is a common device in the network of the first distributed ledger and the network of the second distributed ledger. Optionally, in this scenario, as shown in Figure 9, prior to S920, the method 900 further includes:

[0294] S9201, the second device obtains the PK of the issuer of the first attribute certificate.

[0295] It is understood that the second device is a common device in both the first and second distributed ledger networks, and therefore, it can obtain the PK (Primary Key) of the issuer of the first attribute credential from the first distributed ledger. If the PK of the issuer of the first attribute credential cannot be obtained from the first distributed ledger, it indicates that the issuer of the first attribute credential is not a legitimate device in the first distributed ledger network.

[0296] S9202, the second device verifies the signature of the first attribute credential based on the PK of the issuer of the first attribute credential.

[0297] It is understandable that a successful signature verification means that the first attribute credential has not been tampered with, while a failed signature verification means that the first attribute credential has been tampered with.

[0298] It is understood that the issuer of the first attribute credential has verified the attribute information of the first attribute credential and / or the attribute information of the first attribute credential is provided by the issuer. Therefore, if the second device successfully verifies the signature of the first attribute credential based on the issuer's PK, it means that the first attribute credential is a trustworthy credential information.

[0299] In another possible scenario, if the second device is neither a public device in the network of the first distributed ledger nor the network of the second distributed ledger, it is understandable that since the second device is not a device in the network of the first distributed ledger, it cannot obtain the PK of the issuer of the first attribute credential, and therefore cannot verify the first attribute credential. In this scenario, other devices in the network of the first distributed ledger trusted by the second device (hereinafter referred to as the fourth device) can determine whether the first attribute credential was issued by a legitimate device in the network of the first distributed ledger, that is, whether the first attribute credential has been tampered with. If it has not been tampered with, the fourth device can then directly send or forward the first attribute credential to the second device so that the second device can obtain the second key credential. For example, if the second device in the above description is DLE2-b (non-public device) as shown in Figure 3, then the fourth device can be DLE2-a as shown in Figure 3.

[0300] Optionally, in this scenario, the sending of the first request message by the first device in S510 includes: the first device sending the first request message to the fourth device. Correspondingly, the fourth device receives the first request message from the first device. For example, the first device sending the first request message to the fourth device can be done directly or through an intermediate device, without limitation. Subsequently, before S520, the method 500 may further include the following steps.

[0301] S9201′, the fourth device obtains the PK of the issuer of the first attribute certificate in the first distributed ledger.

[0302] S9202′, the fourth device verifies the signature of the first attribute credential based on the PK of the issuer of the first attribute credential.

[0303] S9203', the fourth device sends a request message #A to the second device, wherein the request message #A includes a first attribute credential and instructs the first device to publish a second attribute credential in the second distributed ledger based on the first attribute credential. Correspondingly, the second device receives the request message #A from the fourth device.

[0304] Subsequently, in the first information of S920, the second device informs the endorsing device of the successfully verified first attribute credential, instructing the endorsing device to generate the second attribute credential of the first device. In this scenario, after receiving the second attribute credential generated by the endorsing device in S930, the second device, in response to the request message #A, can also execute S9204'.

[0305] S9204', the second device sends a request-response message #A to the fourth device, the request-response message #A including the second attribute credential. Correspondingly, the fourth device receives the request-response message #A from the second device.

[0306] S930, if it is determined that the first attribute credential is a credential issued by an issuer trusted by the endorsement device, the endorsement device generates a second attribute credential and sends the second attribute credential to the second device. The second attribute credential includes second attribute information and a signature. The second attribute information is determined based on the first attribute information in the first attribute credential, and the signature is obtained based on the endorsement device's SK. Correspondingly, the second device receives the second attribute credential from the endorsement device.

[0307] In this application, the second key credential is generated by the endorsement device, and thus, for example, the endorsement device also acts as the issuer of the second attribute credential.

[0308] For example, the endorsement device has a pre-set list of trustworthy issuers, including their identifiers and public key certificates. Trust can be established offline. The endorsement device can then determine if the issuer of the first attribute credential is included in the pre-set list. If so, the endorsement device generates a second key credential based on trust in the issuer of the first attribute credential. Alternatively, the endorsement device can obtain the public key certificate of the issuer of the first attribute credential and verify the signature of the first attribute credential based on the PK in the public key certificate. If the verification is successful, the second attribute credential is generated. The following explains whether the endorsement device verifies the first attribute credential in different scenarios.

[0309] For example, if the second device is a common device of the first distributed ledger network and the second distributed ledger network, and the endorsement device confirms that the issuer of the first attribute certificate is included in a preset list and the second device has verified the first attribute certificate through the above S9201 and S9202, then since both the second device and the endorsement device are devices in the second distributed ledger network, the third device does not need to verify the first attribute certificate.

[0310] For example, if the second device is not a common device in the network of the first distributed ledger and the network of the second distributed ledger, the endorsing device confirms that the issuer of the first attribute certificate is included in a preset list. Although the fourth device trusted by the second device in the first distributed ledger has verified the first attribute certificate through the above S9201' and S9202', since the fourth device and the endorsing device are devices in different distributed ledger networks, the endorsing device can choose to verify the first attribute certificate again.

[0311] For example, this application proposes another endorsement replacement smart contract that can be used to generate second-attribute credentials. This smart contract will be described with examples in Table 6 later, and will not be elaborated upon here.

[0312] For example, in this method, the input parameters of the smart contract include a first attribute credential of the first device, and the output parameter is a second key credential. For example, the input parameters of the smart contract may also include the identifier of the CT (i.e., the identifier of the CT indicated by the first information above).

[0313] For example, the attributes indicated by the first attribute information and the second attribute information are the same, or the second attribute information can be derived from the first attribute information. Taking derivation as an example, if the first attribute information is "the user was born in 2000", for privacy protection reasons, the derived second attribute information is "the user is 18 years of age or older".

[0314] For example, the first and second attribute credentials may also include other information, such as the information corresponding to each field in Table 2, which will not be elaborated here. For example, the Domain ID in the second attribute credential may be the identifier of the second distributed ledger, or the PLMN identifier of the operator corresponding to DL2, or the identifier of the subnet (or network domain) of the operator corresponding to DL2, or the network identifier of a certain area covered by the operator corresponding to DL2, without limitation.

[0315] The following example uses the first distributed ledger as DL1, the second distributed ledger as DL2, and the first device as DLE0, to provide a simple example of a first-attribute credential and a second-attribute credential. It can be seen that the Domain ID, issuer ID, Validity fields, and signature in the second-attribute credential are different from the corresponding fields and signatures in the first-attribute credential.

[0316] Table 5

[0317] Optionally, depending on the configuration of the second distributed ledger, if the second attribute credential needs to be confirmed by the first device before signing, the method further includes the following steps before S930.

[0318] S9301, the endorsement device sends second information to the first device via the second device. The second information includes a third attribute certificate, which is an unsigned second attribute certificate. The second information instructs the first device to determine whether the third attribute certificate meets the requirements of the first device. Correspondingly, the first device receives the second information.

[0319] For example, the endorsement device sends message #1 to the second device, message #1 containing second information, and the second device sends message #2 to the first device, message #2 containing second information. It can be understood that messages #1 and #2 are different, but convey the same second information.

[0320] S9302, the first device sends third information to the endorsement device through the second device, the third information indicating whether the third attribute certificate meets or does not meet the requirements of the first device.

[0321] For example, the first device sends message #3 to the second device, message #3 containing second information, and the second device sends message #4 to the endorsement device, message #4 containing second information. It can be understood that messages #3 and #4 are different, but convey the same third information.

[0322] In this embodiment, if the conditions are met, the endorsement device signs the third attribute certificate and generates the second attribute certificate.

[0323] Optionally, before the endorsing device sends the second attribute certificate to the second device, the endorsing device may trigger the consensus device in the network of the second distributed ledger to reach a consensus on the second attribute certificate; further, the endorsing device sending the second attribute certificate to the second device includes: under the condition of successful consensus, the endorsing device saves the second attribute certificate and sends the second attribute certificate to the second device. For the implementation method and consensus algorithm, please refer to the relevant description of consensus in S530, which will not be repeated here.

[0324] S940, the second device sends a first request-response message, which includes a second attribute credential. Correspondingly, the first device receives the first request-response message.

[0325] It is understood that the first request-response message can be sent directly from the second device to the first device, or it can be forwarded to the first device through an intermediate device, without limitation. Generally, the first request-response message and the first request message have the same transmission path, but are transmitted in opposite directions.

[0326] For example, the first request response message also includes the identifier of the first device and the identifier of the second distributed ledger.

[0327] For example, the first request response message also includes verification information, which is used to verify whether the second attribute credential is stored in the second distributed ledger. Correspondingly, the first device verifies whether the second attribute credential is indeed stored in the second distributed ledger based on the verification information. After successful verification, the first device stores the second attribute credential and the identifier of the first device locally.

[0328] In the above method, the endorsing device generates a second attribute certificate based on its own SK signature, thereby achieving the endorsement replacement of the first attribute certificate without needing to reapply to the issuer of the first attribute certificate. Devices in the second distributed ledger network capable of obtaining the endorsing device's PK can verify the second attribute certificate based on the PK to determine whether to allow the first device access, or whether to provide services to the first device, etc.

[0329] The following description, in conjunction with Figure 10, illustrates possible application scenarios for the second attribute credential. The method 1000 shown in Figure 10 includes the following steps.

[0330] S1010, the first device sends a fourth attribute credential to the third device in the second distributed ledger. The fourth attribute credential includes fourth attribute information and a signature of the second attribute credential. The fourth attribute information is determined based on the attribute information contained in the second attribute credential, and the fourth attribute credential is used to authenticate the first device. Correspondingly, the third device receives the fourth attribute credential from the first device.

[0331] Optionally, the third device may actively trigger authentication of the first device, and the first device may send a fourth attribute credential to the third device based on the authentication triggered by the third device.

[0332] Optionally, prior to S1010, the first device may send a third request message to the third device, the third request message being used to request authentication of the first device. Correspondingly, the third device receives the third request message from the first device. For example, the third request message includes a fourth attribute credential.

[0333] For example, the fourth attribute credential can be the second attribute credential.

[0334] For example, the fourth attribute credential can be an attribute credential derived from the second attribute credential. That is, the fourth attribute credential can be understood as the VP mentioned above.

[0335] S1020, the third device obtains the public key of the endorsing device on the second distributed ledger.

[0336] S1030, the third device verifies the signature contained in the fourth attribute credential (i.e. the signature of the second attribute credential) based on the public key of the endorsement device.

[0337] This application does not limit the time when the third device obtains the public key of the endorsement device and verifies the signature; it can be performed at any time before S1040.

[0338] S1040, the third device sends the authentication result of the first device to the first device.

[0339] It is understood that if the signature verification is successful and the fourth attribute credential includes the attribute information required for authenticating the first device, the authentication result indicates that authentication has passed; otherwise, the authentication result indicates that authentication has failed. Correspondingly, the first device receives the authentication result from the third device. For example, if the third device received a third request message from the first device before S1010, then in S1040, the third device sends the authentication result of the first device to the first device, including: the third device sending a third request response message to the first device, the third request response message including the authentication result of the first device. Correspondingly, the first device receives the third request response message from the third device.

[0340] For example, the third request message is used to request authentication of the first device. Specifically, the third request message can be used to request joining or accessing the second distributed ledger, or to request services from the network of the second distributed ledger, or to request establishing a connection with the third device. Then, if the signature verification is successful and the fourth attribute credential includes the attribute information required for authentication, the third request response message indicates agreement to join or access the second distributed ledger, or indicates agreement to provide services from the network of the second distributed ledger, or indicates agreement to establish a connection with the third device.

[0341] For example, after receiving the third request message, in some possible scenarios, the third device may request the fifth device in the second distributed ledger to authenticate the first device (in this scenario, the fifth device performs the authentication of the first device and returns the authentication result to the third device). For example, possible scenarios include, but are not limited to: the third device does not have permission to query the second distributed ledger and therefore cannot obtain the PK of the endorsing device to authenticate the first device; or, the network of the second distributed ledger has the fifth device configured as a dedicated authentication device.

[0342] The following example illustrates how a third request message can be used to request services from the network of a second distributed ledger. If the requested service is the Avata service, the third device, upon successful signature verification, checks whether the claim of the fourth attribute credential in the third request message includes "This device has subscribed to the Avata service". If it does, the Avata service can be provided; otherwise, the Avata service will not be provided.

[0343] For example, when a first device requests services from a third device to the network of the second distributed ledger, it may request services from the third device, data from the second distributed ledger, or services from other devices in the second distributed ledger network.

[0344] The process of generating a second attribute certificate by endorsement replacement of a first attribute certificate has been described in detail above. The following section, with reference to Figures 11 and 12, provides an example of a possible complete implementation process for method 900.

[0345] It is understood that method 1100 shown in Figure 11 and method 1200 shown in Figure 12 are possible specific implementation processes based on method 900. Therefore, the descriptions in method 1100 and method 1200 that are the same as those in method 900 will not be repeated. For descriptions that are not detailed, please refer to the description in method 900.

[0346] Figure 11 is a flowchart of the communication method 1100 proposed in this application. The method 1100 includes the following steps.

[0347] In method 1100, DL1 can be an example of the first distributed ledger in method 900, DL2 can be an example of the second distributed ledger in method 900, DLE0 can be an example of the first device in method 900, DLE2 can be an example of the second device in method 900, and DLE3 can be an example of the endorsement device in method 900. Additionally, AC1 in method 1100 can be considered an example of the first attribute credential in method 900, and AC2 can be considered an example of the second attribute credential in method 900.

[0348] Taking the application of method 1100 to Figure 3 as an example, the above DL1, DL2, DLE0, and DLE3 can be DL1, DL2, DLE0, and DLE3 in Figure 3, and the above DLE2 can be DLE2-a in Figure 3, and DLE2-a and DLE2-b in Figure 3 are the same DLE node.

[0349] S1101, DLE0 determines that the conditions for cross-distributed ledger are met, and the target distributed ledger is DL2.

[0350] S1102, DLE0 determines the AC1 that needs to be used in the DL2 network.

[0351] S1103, DLE0 sends request message #1 (an example of the first request message) to DLE2. Request message #1 carries information about DLE0 ID, DL2 ID, and AC1. Correspondingly, DLE2 receives request message #1 from DLE0.

[0352] The relevant information for AC1 is described in S910 and will not be repeated here. For ease of description, this method will use the SN corresponding to AC1 as an example.

[0353] For example, DLE0 can send request message #1 to DLE2 directly or through an intermediate DLE. See S1103a to S1103c in Figure 11 for example. See S730 for a detailed description.

[0354] S1104, DLE2 obtains and verifies AC1 from DL1 based on the SN corresponding to AC1. If AC1 is verified successfully, subsequent steps are executed.

[0355] Optionally, the method also includes S1105.

[0356] S1105, if DLE3 needs to obtain the corresponding CT before it can perform endorsement update when performing endorsement replacement, then DLE2 also needs to obtain the usage field of AC1 and query DL2 to obtain the CT that supports the same function.

[0357] S1106, DLE2 sends information #1 to DLE3, information #1 includes AC1. Correspondingly, DLE3 receives information #1 from DLE2.

[0358] Optionally, if S1105 is executed, information #1 may also include the corresponding CT ID.

[0359] Optionally, S1105 can also be performed by the endorsement device itself before AC2 is generated, in which case the CT ID does not need to be carried in the information #1 of S1106.

[0360] S1107, DLE3 generates an unsigned AC2 based on AC1 and DLE3's SK.

[0361] In one possible implementation, this application proposes an endorsement replacement smart contract that can be installed on DLE2 and consensus nodes. This contract can be used to generate unsigned AC2. For example, the content of this smart contract is shown in Table 6.

[0362] As can be understood, a smart contract is a piece of automatically executing code. For a DLE with this smart contract installed, as long as the input parameters of the smart contract are the same, the output parameters (i.e., the output AC) obtained after running the smart contract will be the same. Therefore, this smart contract can be installed on DLE2 and consensus nodes to achieve consensus on unsigned AC2.

[0363] Table 6

[0364] For example, the endorsement update contract pre-defines some rules for updating endorsements. For instance, in order to generate a Chinese degree certificate for international students based on their graduation certificate and degree certificate, the credentials containing "civil", "environment", and "transportation" in AC1 need to be replaced with "construction engineering".

[0365] For example, the endorsement update contract pre-constructs a list containing the IDs and public key certificates of trusted issuers (e.g., a public key certificate of a foreign university trusted by an education bureau). This trust may be established offline between two organizations. Based on this endorsement update contract, it can further check whether the issuer of the input AC1 is included in the pre-constructed issuer list. If so, optionally, the issuer's public key certificate can be obtained, and the signature of AC1 can be verified based on that public key certificate.

[0366] The input parameters of this endorsement update contract include the AC that needs to be endorsed. Optionally, it may also carry a CT ID, which indicates the CT required to update AC1 (or generate AC2). For example, if the input parameters of the endorsement update contract include a CT ID, the CT is retrieved from the global constant CT list based on the CT ID, and the updated endorsed AC is generated based on the CT. If the contract is specifically deployed for a particular type of certificate (e.g., generating a degree certificate for a Chinese student studying abroad), meaning the format of the generated AC is fixed in the function of the endorsement update contract, then it is not necessary to obtain the CT.

[0367] Optionally, if AC2 needs DLE0's confirmation before signing, this also includes S1108 to S1110. If AC2 does not need DLE0's confirmation, then S1111 is executed directly.

[0368] S1108, DLE3 sends message #2 to DLE0 via DLE2. Message #2 includes the generated unsigned AC2. Correspondingly, DLE0 receives message #2.

[0369] S1109, DLE0 confirms whether the unsigned AC2 meets its own requirements.

[0370] S1110, DLE0 sends message #3 to DLE3 through DLE2, message #3 indicating whether DLE0's requirements are met (or not met).

[0371] If the requirements are met, continue executing S1111.

[0372] S1111, DLE3 uses DLE3's SK to sign the unsigned AC2, thus obtaining the complete AC2.

[0373] S1112, DLE3 triggers consensus nodes (e.g., DLEn in the DL2 network) to reach consensus on AC2. If consensus is successful, S1113 is executed.

[0374] S1113, DLE3 sends message #4 to DLE2, message #4 includes AC2. Correspondingly, DLE2 receives message #4 from DLE3.

[0375] For example, information #4 also includes the DLE0 ID and / or DL2 ID. S1114, DLE2 sends request-response message #1 (an example of the first request-response message) to DLE0, request-response message #1 including AC2. Correspondingly, DLE0 receives request-response message #1 from DLE2.

[0376] For example, request response message #1 also includes a DLE0 ID and / or a DL2 ID.

[0377] For example, if DLE0 has high security requirements, DLE2 can also obtain verification information #1 from DL2. Verification information #1 is used to verify whether AC2 is stored in DL2, and verification information #1 can be carried in request-response message #1. After that, execute S1114.

[0378] S1114, DLE0 verifies that AC2 is indeed stored in DL2 based on the verification information, and DLE0 saves AC2 and DLE0 ID accordingly.

[0379] Figure 12 is a flowchart of the communication method 1200 proposed in this application. The method 1200 includes the following steps.

[0380] In method 1200, DL1 can be an example of the first distributed ledger in method 900, DL2 can be an example of the second distributed ledger in method 900, DLE0 can be an example of the first device in method 900, DLE2-b can be an example of the second device in method 900, DLE3 can be an example of the endorsement device in method 900, and DLE2-a can be an example of the fourth device in method 900. Furthermore, AC1 in method 1200 can be considered an example of the first attribute credential in method 900, and AC2 can be considered an example of the second attribute credential in method 900.

[0381] Taking the application of method 1200 to Figure 3 as an example, the above DL1, DL2, DLE0, DLE2-a and DLE2-b can be DL1, DL2, DLE0, DLE2-a and DLE2-b in Figure 3, and DLE2-a and DLE2-b are different DLE nodes.

[0382] S1201, DLE0 determines that the conditions for cross-distributed ledger are met, and the target distributed ledger is DL2.

[0383] S1202, DLE0 determines the AC1 that needs to be used in the DL2 network.

[0384] S1203, DLE0 sends request message #1 to DLE2-a. Request message #1 instructs that AC2 be published in DL2 based on AC1. Request message #1 carries the DLE0 ID, DL2 ID, and relevant information about AC1. Correspondingly, DLE2-a receives request message #1 from DLE0.

[0385] For ease of description, this method will be illustrated using the SN corresponding to AC1 as an example.

[0386] For example, DLE0 can send request message #1 to DLE2-a directly or via an intermediate DLE. See the description in S803 for details on the sending methods.

[0387] S1204, DLE2-a obtains and verifies AC1 in DL1 based on the SN corresponding to AC1. If AC1 is verified successfully, subsequent steps are executed.

[0388] S1205, DLE2-a sends request message #2 to DLE2-b. Request message #2 includes AC1 and indicates that AC2 should be published in DL2 based on AC1. Correspondingly, DLE2-b receives request message #2 from DLE2-a.

[0389] For example, request message #2 may also include the DL2 ID.

[0390] Optionally, the method also includes S1206.

[0391] S1206, if DLE3 needs to obtain the corresponding CT before it can update the endorsement when performing endorsement replacement, then DLE2-b also needs to obtain the usage field of AC1 and query DL2 to obtain the CT that supports the same function.

[0392] S1207, DLE2-b sends information #1 to DLE3, information #1 including AC1. Correspondingly, DLE3 receives information #1 from DLE2.

[0393] Optionally, if S1206 is executed, information #1 may also include the CT ID.

[0394] For example, S1206 can also be performed by the endorsement device itself before AC2 is generated, in which case the CT ID does not need to be carried in the information #1 of S1207.

[0395] S1208, DLE3 generates an unsigned AC2 based on AC1 and DLE3's SK.

[0396] For example, the endorsement replacement smart contract shown in Table 6 above can be installed on DLE3, and DLE2-b generates an unsigned AC2 based on this smart contract.

[0397] Optionally, if AC2 needs DLE0's confirmation before signing, this also includes S1209 to S1211. If AC2 does not need DLE0's confirmation, then S1212 is executed directly.

[0398] S1209, DLE3 sends message #2 to DLE0 via DLE2-b and DLE2-a. Message #2 includes the generated unsigned AC2. Correspondingly, DLE0 receives message #2.

[0399] S1210, DLE0 confirms whether the unsigned AC2 meets its own requirements.

[0400] In S1211, DLE0 sends message #3 to DLE3 via DLE2-a and DLE2-b. Message #3 indicates whether DLE0's requirements are met (or not met). If the requirements are met, proceed to S1212.

[0401] S1212, DLE3 uses DLE3's SK to sign the unsigned AC2, obtaining the complete AC2.

[0402] S1213, DLE3 triggers consensus nodes (e.g., DLEn in the DL2 network) to reach consensus on AC2. If consensus is successful, execute S1214.

[0403] S1214, DLE3 sends information #4 to DLE2-b, information #4 including AC2. Correspondingly, DLE2-b receives information #4 from DLE3.

[0404] For example, information #4 also includes the DLE0 ID and / or DL2 ID.

[0405] S1215, DLE2-b sends request-response message #2 to DLE2-a, which includes AC2. Correspondingly, DLE2-a receives request-response message #2 from DLE2-b.

[0406] For example, request response message #2 also includes a DLE0 ID and / or a DL2 ID.

[0407] S1216, DLE2-a sends request-response message #1 to DLE0, which includes AC2. Correspondingly, DLE0 receives request-response message #1 from DLE2-a.

[0408] For example, request response message #2 also includes a DLE0 ID and / or a DL2 ID.

[0409] For example, if DLE0 has high security requirements, verification information #1 can also be included in message #4, request / response message #2, and request / response message #1. Verification information #1 is used to verify whether AC2 is stored in DL2. After that, execute S1217.

[0410] S1217, DLE0 verifies that AC2 is indeed stored in DL2 based on the verification information, and DLE0 saves AC2 and DLE0 ID accordingly.

[0411] It is understood that the steps in the above figures are merely illustrative and are not intended to be strictly limited. Furthermore, the sequence numbers of the processes described above do not imply a specific order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0412] It is also understood that some optional features in the various embodiments of this application may not depend on other features in some scenarios, or may be combined with other features in some scenarios, without limitation.

[0413] The method embodiments provided in this application have been described in detail above with reference to Figures 1 to 12. The apparatus embodiments of this application will be described below with reference to Figures 13 and 14. It is understood that, in order to implement the functions in the above embodiments, the apparatuses in Figures 13 and 14 include hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and method steps of the various examples described in conjunction with the embodiments disclosed in this application, this application can be implemented in hardware or a combination of hardware and computer software. It is understood that the technical features described in the above method embodiments are also applicable to the following apparatus embodiments.

[0414] Figures 13 and 14 are schematic diagrams of possible apparatus structures provided in embodiments of this application. These apparatuses can be used to implement the functions of the apparatuses (e.g., the first apparatus, the second apparatus, the endorsement apparatus) in the above method embodiments, and thus can also achieve the beneficial effects of the above method embodiments.

[0415] Figure 13 is a schematic block diagram of a communication device 1000 provided in an embodiment of this application. As shown in Figure 13, the device 1000 may include a communication unit 1010 and a processing unit 1020. The communication unit 1010 can communicate with the outside world, and the processing unit 1020 is used for data processing. The communication unit 1010 may also be referred to as a communication interface or a transceiver unit.

[0416] Optionally, the device 1000 may further include a storage unit, which can be used to store instructions and / or data, and the processing unit 1020 can read the instructions and / or data in the storage unit to enable the device to implement the aforementioned method embodiments.

[0417] In one possible design, the device 1000 can implement the steps or processes corresponding to those performed by the first device in the above method embodiments, wherein the processing unit 1020 is used to perform processing-related operations of the first device in the above method embodiments, and the communication unit 1010 is used to perform transmission-related operations of the first device in the above method embodiments.

[0418] In another possible design, the device 1000 can implement the steps or processes corresponding to those performed by the second device in the above method embodiments, wherein the communication unit 1010 is used to perform the receiving-related operations of the second device in the above method embodiments, and the processing unit 1020 is used to perform the processing-related operations of the second device in the above method embodiments.

[0419] In another possible design, the device 1000 can implement the steps or processes corresponding to those performed by the endorsement device in the above method embodiments, wherein the communication unit 1010 is used to perform the receiving-related operations of the endorsement device in the above method embodiments, and the processing unit 1020 is used to perform the processing-related operations of the endorsement device in the above method embodiments.

[0420] It is understood that the device 1000 here is embodied in the form of a functional unit. The term "unit" here can refer to an application-specific integrated circuit (ASIC), electronic circuitry, a processor (e.g., a shared processor, a proprietary processor, or a group processor, etc.) and memory for executing one or more software or firmware programs, integrated logic circuitry, and / or other suitable components supporting the described functions. In an alternative example, those skilled in the art will understand that the device 1000 can be specifically the device in the above embodiments (e.g., the first device, the second device, the endorsement device), and can be used to execute the various processes and / or steps corresponding to that device (e.g., the first device, the second device, the endorsement device) in the above method embodiments. To avoid repetition, further details are omitted here.

[0421] The apparatus 1000 of each of the above-described schemes has the function of implementing the corresponding steps performed by the apparatus (e.g., the first apparatus, the second apparatus, the endorsement apparatus) in the above-described methods. The 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; for example, a communication unit can be replaced by a transceiver (e.g., the sending unit in the communication unit can be replaced by a transmitter, and the receiving unit in the communication unit can be replaced by a receiver), and other units, such as processing units, can be replaced by a processor, respectively executing the transmission and reception operations and related processing operations in each method embodiment.

[0422] Furthermore, the aforementioned communication unit can also be a transceiver circuit (e.g., it may include a receiving circuit and a transmitting circuit), and the processing unit can be a processing circuit. In the embodiments of this application, the device in FIG13 can be the first device or the second device or the endorsement device in the foregoing embodiments, or it can be a chip or a chip system, such as a system on chip (SoC). The communication unit can be an input / output circuit or a communication interface; the processing unit is a processor, microprocessor, or integrated circuit integrated on the chip. No limitations are imposed here.

[0423] Figure 14 is a schematic block diagram of a communication device 1100 provided in an embodiment of this application. The device 1100 includes a processor 1110 and a transceiver 1120. The processor 1110 and the transceiver 1120 communicate with each other through an internal connection path. The processor 1110 is used to execute instructions to control the transceiver 1120 to send and / or receive signals.

[0424] Optionally, the device 1100 may further include a memory 1130, which communicates with the processor 1110 and the transceiver 1120 via internal connection paths. The memory 1130 stores instructions, and the processor 1110 can execute the instructions stored in the memory 1130. In one possible implementation, the device 1100 is used to implement the various processes and steps corresponding to the first device in the above method embodiments. In another possible implementation, the device 1100 is used to implement the various processes and steps corresponding to the second device in the above method embodiments. In yet another possible implementation, the device 1100 is used to implement the various processes and steps corresponding to the endorsement device in the above method embodiments.

[0425] Optionally, the memory 1130 may be integrated into the processor 1110.

[0426] In one possible scenario, device 1100 includes at least one processor with integrated memory, and other memory besides the memory integrated on the processor.

[0427] It is understood that device 1100 may be specifically the device in the above embodiments (e.g., the first device, the second device, the endorsement device), or it may be a chip or a chip system. Correspondingly, transceiver 1120 may be the transceiver circuit of the chip, which is not limited here. Specifically, device 1100 may be used to execute the various steps and / or processes corresponding to the device (e.g., the first device, the second device, the endorsement device) in the above method embodiments.

[0428] Optionally, the memory 1130 may include read-only memory and random access memory, and provide instructions and data to the processor. The memory may include non-volatile random access memory. For example, the memory may also store device type information. The processor 1110 may be used to execute instructions stored in the memory, and when the processor 1110 executes instructions stored in the memory, the processor 1110 is used to perform the various steps and / or processes of the method embodiments corresponding to the apparatus (e.g., the first apparatus, the second apparatus, the endorsement apparatus) described above.

[0429] In implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software. The steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware processor, or by a combination of hardware and software modules in the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are omitted here.

[0430] It should be noted that the processor in the embodiments of this application can be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method embodiments can be completed by the integrated logic circuitry in the processor's hardware or by instructions in software form. The processor described above can be a combination of one or more of the following: a general-purpose processor, a digital signal processing (DSP), an ASIC, a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, a microprocessor unit (MPU), a microcontroller unit (MCU), a graphics processing unit (GPU), an artificial intelligence processor (AI processor), or a neural processing unit (NPU). The processor in the embodiments of this application can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

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

[0432] Optionally, the memory (e.g., 1130) in this embodiment may be integrated into the processor (e.g., 1110).

[0433] Figure 15 is a schematic diagram of a chip system 1200 provided in an embodiment of this application. The chip system 1200 (or may also be called a processing system) includes logic circuitry 1210 and an input / output interface 1220.

[0434] The logic circuit 1210 can be a processing circuit in the chip system 1200. The logic circuit 1210 can be coupled to a memory unit, calling instructions from the memory unit, enabling the chip system 1200 to implement the methods and functions of the embodiments of this application. The input / output interface 1220 can be an input / output circuit in the chip system 1200, outputting processed information from the chip system 1200, or inputting data or signaling information to be processed into the chip system 1200 for processing.

[0435] As one approach, the chip system 1200 is used to implement the operations performed by the means (e.g., the first means, the second means, the endorsement means) in the various method embodiments described above.

[0436] For example, logic circuit 1210 is used to implement processing-related operations performed by the means (e.g., the first means, the second means, the endorsement means) in the above method embodiments; input / output interface 1220 is used to implement sending and / or receiving-related operations performed by the means (e.g., the first means, the second means, the endorsement means) in the above method embodiments.

[0437] In addition, this application also provides a computer-readable storage medium storing computer instructions that, when executed on a computer, cause operations and / or processes performed by a first device, a second device, or an endorsement device in the various method embodiments of this application to be executed.

[0438] This application also provides a computer program product, which includes computer program code or instructions. When the computer program code or instructions are run on a computer, the operations and / or processes performed by the first device or the second device or the endorsement device in the various method embodiments of this application are executed.

[0439] Furthermore, this application also provides a chip including a processor. A memory for storing a computer program is provided independently of the chip, and the processor is used to execute the computer program stored in the memory such that operations and / or processes performed by a first device, a second device, or an endorsement device in any method embodiment are performed.

[0440] Furthermore, the chip may also include a communication interface. The communication interface may be an input / output interface or an interface circuit, etc. Furthermore, the chip may also include a memory.

[0441] In addition, this application also provides a communication system, including at least one of the first device, the second device, and the endorsement device in the embodiments of this application.

[0442] It should also be noted that the memory described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0443] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for example, the division of units is merely a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling or direct coupling or communication connection may be through some interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, the functional units in the various embodiments of this application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0444] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0445] It is understood that the term "embodiment" used throughout the specification means that a specific feature, structure, or characteristic related to an embodiment is included in at least one embodiment of this application. Therefore, various embodiments throughout the specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments.

[0446] It can also be understood that in this application, "when," "if," and "if" all refer to the network element making corresponding processing under certain objective circumstances, and are not time-limited, nor do they require the network element to make a judgment when it is implemented, nor do they mean that there are other limitations.

[0447] It can also be understood that in the various embodiments of this application, "B corresponding to A" means that B is associated with A, and B can be determined based on A. However, it can also be understood that determining B based on A does not mean that B is determined solely based on A; B can also be determined based on A and / or other information.

Claims

1. A communication method characterized by comprising: include: Receive a first request message, the first request message being used to request the publication of the second key credential of the first device in the second distributed ledger; Obtain the second key credential, which includes the public key of the first device and a signature, wherein the public key of the first device is the public key in the first key credential issued by the first device in the first distributed ledger, and the signature is generated based on the private key of the second distributed ledger and verified by the public key of the second distributed ledger; Send a first request-response message, the first request-response message including the second key credential.

2. The method of claim 1, wherein, The method is applied to a second device, which is a common device in the network of the first distributed ledger and the network of the second distributed ledger.

3. The method of claim 2, wherein, The first request message includes first encrypted information, which is obtained by encrypting the first device using its private key. Before obtaining the second key credential, the method further includes: Obtain the public key of the first device from the first key credential; The first encrypted information was successfully decrypted using the public key of the first device.

4. The method of claim 3, wherein, The first encrypted information is obtained by encrypting the first value corresponding to the first parameter using the private key of the first device. The first parameter is a parameter associated with the first distributed ledger. The method further includes: Obtain the first value corresponding to the first parameter from the first distributed ledger; The successful decryption of the first encrypted information based on the public key of the first device includes: The first encrypted information is decrypted based on the public key of the first device to obtain a decryption result, and the decryption result is consistent with the first value.

5. The method according to claim 4, characterized in that, The first parameter is the hash of the latest block or a specified block in the first distributed ledger. or, The first parameter is the generation time of the latest block or a specified block in the first distributed ledger.

6. The method according to claim 1, characterized in that, The first request message originates from the network of the first distributed ledger, and the first request message includes the public key of the first device.

7. The method according to any one of claims 1 to 6, characterized in that, Obtaining the second key credential includes: The second key credential is generated based on the private key of the second distributed ledger.

8. The method according to any one of claims 1 to 6, characterized in that, Obtaining the second key credential includes: Receive the second key credential from other devices in the network of the second distributed ledger.

9. The method according to any one of claims 1 to 8, characterized in that, Before sending the first request-response message, the method further includes: The consensus mechanism in the network of the second distributed ledger is triggered to reach a consensus on the second key credential. Sending the first request-response message includes: If the consensus is successful, the first request response message is sent.

10. The method according to any one of claims 1 to 9, characterized in that, The first request response message also includes verification information, which is used to verify whether the second key credential is stored in the second distributed ledger.

11. A communication method, comprising: include: Send a first request message, the first request message being used to request the publication of the second key credential of the first device in the second distributed ledger; A first request response message is received, the first request response message including a second key credential, the second key credential including the public key of the first device and a signature, wherein the public key of the first device is the public key in the first key credential issued by the first device in the first distributed ledger, the signature is generated based on the private key of the second distributed ledger, and the signature is verified by the public key of the second distributed ledger.

12. The method of claim 11, wherein, The first request message includes first encrypted information, which is obtained by encrypting a first value corresponding to a first parameter based on the private key of the first device. The first parameter is a parameter associated with the first distributed ledger.

13. The method according to claim 11 or 12, characterized in that, Sending the first request message includes: The first request message is sent to a second device, wherein the second device is a common device in the network of the first distributed ledger and the network of the second distributed ledger.

14. The method according to any one of claims 11 to 13, characterized in that, The method further includes: Receive a second value from a third device in the network of the second distributed ledger; The second value is encrypted using the private key of the first device to obtain the second encrypted information; The second encrypted information is sent to the third device, and the second encrypted information is used to authenticate the first device; Receive the authentication result of the first device from the third device.

15. The method of claim 11, wherein, Sending the first request message includes: Send the first request message to the network of the second distributed ledger.

16. The method of claim 15, wherein, The first request message includes the public key of the first device. Before sending the first request message, the method further includes: A second request message is received from the first device, the second request message being used to request the publication of the second key credential of the first device in the second distributed ledger, the second request message including first encrypted information, the first encrypted information being obtained by encrypting using the private key of the first device; Obtain the public key of the first device from the first key credential; The first encrypted information was successfully decrypted using the public key of the first device; After receiving the first request response message, the method further includes: A third request-response message is sent to the first device, the third request-response message including the second key credential.

17. The method of claim 16, wherein, The first encrypted information is obtained by encrypting the first value corresponding to the first parameter using the private key of the first device. The first parameter is a parameter associated with the first distributed ledger. The method further includes: Obtain the first value corresponding to the first parameter from the first distributed ledger; The successful decryption of the first encrypted information based on the public key of the first device includes: The first encrypted information is decrypted based on the public key of the first device to obtain a decryption result, which is consistent with the first value.

18. The method according to any one of claims 12 or 15 to 17, characterized in that, The first parameter is the hash of the latest block or a specified block in the first distributed ledger. or, The first parameter is the generation time of the latest block or a specified block in the first distributed ledger.

19. The method according to any one of claims 11 to 18, characterized in that, The first request response message also includes verification information, which is used to verify whether the second key credential is stored in the second distributed ledger.

20. The method of claim 19, wherein, The method further includes: Based on the verification information, it is determined that the second key credential is stored in the second distributed ledger; Store the second key credential locally.

21. A method of communication, comprising: include: A first request message is received, which is used to request the publication of a second attribute certificate of the first device in a second distributed ledger based on a first attribute certificate of the first device published in a first distributed ledger. The first attribute certificate includes first attribute information, and the first request message includes relevant information of the first attribute certificate. Send first information to the endorsement device in the network of the second distributed ledger, the first information including the first attribute certificate; Receive the second attribute credential from the endorsement device, the second attribute credential including second attribute information and a signature, the second attribute information being determined based on the first attribute information, and the signature being obtained based on the private key of the endorsement device; Send a first request-response message, the first request-response message including the second attribute credential.

22. The method of claim 21, wherein, The method is applied to a second device, which is a common device in the network of the first distributed ledger and the network of the second distributed ledger.

23. The method of claim 22, wherein, The first attribute credential includes information about the issuer of the first attribute credential and the issuer's signature on the first attribute credential. The method further includes: Obtain the issuer's public key from the first distributed ledger; The signature verification of the first attribute credential based on the issuer's public key was successful.

24. The method according to claim 21, characterized in that, The first request message originates from the network of the first distributed ledger, and the first attribute credential indicated by the first request message has been verified.

25. The method of any one of claims 21-24, wherein, The first information also includes voucher template information, and the second attribute voucher is determined based on the first attribute information and the voucher template information. Before sending the first information, the method further includes: The certificate template is determined based on the first attribute certificate.

26. The method of any one of claims 21-25, wherein, Before receiving the second attribute credential from the endorsement device, the method further includes: The system receives second information from the endorsement device, the second information including a third attribute credential, the third attribute credential being an unsigned second attribute credential, and the second information instructs the system to determine whether the third attribute credential meets the requirements of the first device. Send the second information to the first device; Receive third information from the first device, the third information indicating that the third attribute credential meets the requirements; The third information is sent to the endorsement device.

27. The method of any one of claims 21-26, wherein, Before sending the first information, the method further includes: The endorsement device is determined based on the type of the first attribute certificate, and the endorsement device is at least capable of endorsing attribute certificates of the first type, wherein the first attribute certificate is a certificate of the first type.

28. The method of any one of claims 21-27, wherein, The first request response message also includes verification information, which is used to verify whether the second attribute credential is stored in the second distributed ledger.

29. A method of communication, comprising: include: Receive first information from a second device in a second distributed ledger network, the first information including a first attribute credential of the first device in a first distributed ledger network, the first attribute credential including first attribute information, the first information being used to request the publication of a second attribute credential of the first device in the second distributed ledger based on the first attribute credential; If it is determined that the first attribute credential is a credential issued by a trusted issuer, a second attribute credential is generated based on the first attribute credential, wherein the second attribute credential includes second attribute information and a signature, the second attribute information is determined based on the first attribute information, and the signature is obtained based on the private key of the endorsement device. Send the second attribute certificate to the second device.

30. The method of claim 29, wherein, The first information also includes information about the voucher template, and the step of generating the second attribute voucher based on the first attribute voucher includes: The second attribute certificate is generated based on the first attribute certificate and the certificate template.

31. The method of claim 29 or 30, wherein, Before sending the second attribute credential to the second device, the method further includes: Send a second message to the second device, the second message including a third attribute credential, the third attribute credential being an unsigned second attribute credential, the second message indicating whether the third attribute credential meets the requirements of the first device; Receive third information from the second device, the third information indicating that the third attribute credential meets the requirements.

32. The method of any one of claims 29-31, wherein, The endorsement device is at least capable of endorsing a first type of attribute certificate, where the first attribute certificate is a certificate of the first type.

33. The method of any one of claims 29-32, wherein, Before sending the second attribute credential to the second device, the method further includes: The consensus mechanism in the network of the second distributed ledger is triggered to reach a consensus on the second attribute certificate. Sending the second attribute credential to the second device includes: If the consensus is successful, the second attribute certificate is sent to the second device.

34. A method of communication, comprising: include: Send a first request message, the first request message being used to request the publication of a second attribute certificate of the first device in a second distributed ledger based on a first attribute certificate of the first device published in a first distributed ledger, the first attribute certificate including first attribute information, and the first request message including relevant information of the first attribute certificate; A first request-response message is received, the first request-response message including the second attribute credential, the second attribute credential including second attribute information and a signature, the second attribute information being determined based on the first attribute information in the first attribute credential, and the signature being obtained based on the private key of the endorsement device in the network of the second distributed ledger.

35. The method according to claim 34, characterized in that, Sending the first request message includes: The first request message is sent to a second device, wherein the second device is a common device in the network of the first distributed ledger and the network of the second distributed ledger.

36. The method of claim 34 or 35, wherein, The method further includes: Send a fourth attribute credential to a third device. The fourth attribute credential includes fourth attribute information and the signature of the second attribute credential. The fourth attribute information is determined based on the second attribute information. The fourth attribute credential is used by the third device to authenticate the first device. Receive the authentication result of the first device from the third device.

37. The method of claim 34, wherein, Sending the first request message includes: Send the first request message to the network of the second distributed ledger.

38. The method of claim 37, wherein, Before sending the first request message, the method further includes: Receive a second request message from the first device, the second request message including relevant information about the first attribute certificate, the second request message instructing the publication of a second attribute certificate of the first device in the second distributed ledger based on the first attribute certificate, the first attribute certificate including information of the issuer of the first attribute certificate and the issuer's signature on the first attribute certificate; Obtain the issuer's public key from the first distributed ledger; The signature verification of the first attribute credential based on the issuer's public key was successful; After receiving the first request response message, the method further includes: A third request-response message is sent to the first device, the third request-response message including the second attribute credential.

39. The method of any one of claims 34-38, wherein, Before receiving the first request response message, the method further includes: Receive second information, the second information instructing whether the third attribute credential meets the requirements of the first device, wherein the third attribute credential is the unsigned second attribute credential; It is determined that the third attribute credential satisfies the requirements of the first device; A third message is sent, indicating that the third attribute credential meets the requirements of the first device.

40. The method of any one of claims 34-39, wherein, The endorsement device is a device capable of endorsing at least a first type of attribute certificate, where the first attribute certificate is a certificate of the first type.

41. The method of any one of claims 34-40, wherein, The first request response message also includes verification information, which is used to verify whether the second attribute credential is stored in the second distributed ledger.

42. The method of claim 41, wherein, The method further includes: Based on the verification information, it is determined that the second attribute voucher is stored in the second distributed ledger; Save the second attribute credential locally.

43. A communications device, characterized by It includes modules or units for performing the method of any one of claims 1 to 10 or any one of claims 21 to 28, or modules or units for performing the method of any one of claims 11 to 20 or any one of claims 34 to 42, or modules or units for performing the method of any one of claims 29 to 33.

44. A communications device, characterized by The device includes at least one processor and an interface circuit, the interface circuit being configured to receive signals from other communication devices besides the communication device and transmit them to the processor, or to send signals from the processor to other communication devices besides the communication device. The processor, through logic circuitry or executing code instructions, enables the method as described in any one of claims 1 to 10 or any one of claims 21 to 28 to be implemented, or enables the method as described in any one of claims 11 to 20 or any one of claims 34 to 42 to be implemented, or enables the method as described in any one of claims 29 to 33 to be implemented.

45. The communication apparatus of claim 44, wherein The communication device is a chip or chip system.

46. A computer-readable storage medium, characterized in that, The storage medium stores a computer program or instructions that, when executed, cause the method of any one of claims 1 to 10 or any one of claims 21 to 28 to be implemented, or cause the method of any one of claims 11 to 20 or any one of claims 34 to 42 to be implemented, or cause the method of any one of claims 29 to 33 to be implemented.

47. A computer program product, characterised in that, Includes a computer program that, when run, causes the method of any one of claims 1 to 10 or any one of claims 21 to 28 to be implemented, or causes the method of any one of claims 11 to 20 or any one of claims 34 to 42 to be implemented, or causes the method of any one of claims 29 to 33 to be implemented.

Images