WO2023116349A1 - 一种可信证明方法及通信装置 - Google Patents

一种可信证明方法及通信装置 Download PDF

Info

Publication number
WO2023116349A1
WO2023116349A1 PCT/CN2022/134661 CN2022134661W WO2023116349A1 WO 2023116349 A1 WO2023116349 A1 WO 2023116349A1 CN 2022134661 W CN2022134661 W CN 2022134661W WO 2023116349 A1 WO2023116349 A1 WO 2023116349A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
node
block
smart contract
blockchain
Prior art date
Application number
PCT/CN2022/134661
Other languages
English (en)
French (fr)
Inventor
帕蒂潘·洛格纳森
陈利群
牛顿·克里斯托弗·J.P.
刘斐
王东晖
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2023116349A1 publication Critical patent/WO2023116349A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H04L9/0897—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/12—Details relating to cryptographic hardware or logic circuitry
    • H04L2209/127—Trusted platform modules [TPM]

Definitions

  • the embodiments of the present application relate to the technical field of computer security, and in particular, to a trusted certification method and a communication device.
  • trusted proof Platform trusted proof in the field of trusted computing is the research focus of information security.
  • Trusted platform module trusted platform module, TPM
  • TPM trusted platform module
  • a storage root of the key tree supporting the security system is preset inside the TPM.
  • Remote (remote) attestation is a process in which the party issuing the attestation request confirms the identity of the remote platform and the configuration information of the platform status, that is, the process of confirming whether the remote platform is credible.
  • Remote attestation enables the attestation requester to detect changes in the attested nodes and avoid sending private information or important commands to insecure or compromised nodes.
  • Remote attestation is also an important method to establish a trust relationship between nodes, and it is an important means for nodes to extend trust outward. Especially in a complex network environment, it is particularly important to use remote attestation to establish a trust relationship.
  • the nodes involved in the remote proof of trusted computing include an attester and a verifier.
  • the attester reports the integrity status of the target node to the verifier through local metrics, so that the verifier can verify the hardware and software of the target node Whether the component is functioning as expected.
  • Embodiments of the present application provide a trusted certification method and a communication device, in order to improve the operating efficiency of remote certification of trusted computing.
  • a credible proof method is provided, and the method may be executed by the first node, or may be executed by components of the first node.
  • the method can be implemented through the following steps: the first node obtains the information of the first blockchain, and the first node determines the certification information according to the information of the first blockchain, wherein the certification Information for whether the first node is remotely attested to be authentic. Since the information of the first blockchain can be used as a public random number generated by the first blockchain based on consensus and can be used by multiple nodes, the information of the first blockchain can be used as a challenge value for multiple nodes to perform security measurements .
  • the first node generates proof information by referencing a trusted third party to generate a publicly recognized random number as a challenge value.
  • the proof information can be verified by any verifier to achieve multiple verifications for one measurement, so that the first node does not need to communicate with each Validators establish a separate "challenge-response" process. This can help improve the scalability of trusted metrics, improve the operational efficiency of remote attestation, and meet the verification requirements of massive devices in high-concurrency and low-latency application scenarios.
  • the information of the first block chain includes any one or more of the following information: the timestamp of the first block, the hash value of the first block, the last block of the first block The hash value of the block, the hash string of multiple blocks including the first block, the merkle root of the multiple blocks including the first block, or the A random number, a timestamp of the first transaction, a hash value of the first transaction, or a hash string of multiple transactions including the first transaction; wherein, the first block is the first A block on a block chain, the first transaction is a transaction on the first block chain.
  • the first node can upload proof information to the first blockchain multiple times, and each proof information or summary information of the proof information is stored on the first blockchain, which can guarantee The correctness and inalterability of the content of the information. Since the certification information is determined according to the information of the first blockchain, the information of the first blockchain is traceable, so each certification information is historical and traceable. For example, if the first node is based on the first The timestamp of the block determines the certification information, and the certification information has a corresponding relationship with the timestamp, and the certification information indicates whether the first node is credible at the time corresponding to the timestamp. As a verifier, the second node can verify the historical credibility of the first node. The second node can obtain the historical proof information of the first node based on the first blockchain, verify whether the first node is historically credible, and obtain a proof result of whether the first node is historically credible.
  • the first node can also send the proof information to the first blockchain.
  • the first node may be any node that needs to upload its own certification information.
  • the first node can be used by any second node that needs to verify whether the first node is trustworthy. In this way, the first node only needs to generate one certification information, which can be used by The remaining arbitrary second node verification reduces the computational complexity of trusted computing, improves operational efficiency, saves resources, and is more suitable for high-concurrency and low-latency application scenarios.
  • the first node can also send the certification information to the first blockchain through the smart contract, wherein the first node can send the certification information to the smart contract, and the smart contract sends the certification information to the first blockchain
  • the proof information, the smart contract is deployed on the blockchain node on the first blockchain. Based on smart contracts, the proof information of remote proof is uploaded to the first blockchain, which can be applied to a variety of trusted computing technologies and improve the scalability of blockchain when applied to remote proof.
  • the first node sends certification information to the first blockchain, or the first node sends certification information to the first blockchain through a smart contract.
  • the certification information can be stored in the following manner.
  • the first block chain includes a second block, and the second block stores attestation information.
  • the second block stores summary information of the certification information, wherein the summary information is used to verify the integrity of the certification information, and the certification information is stored in off-chain storage nodes, which can improve the consensus efficiency and storage efficiency of the blockchain .
  • the first node may also register identity information with the smart contract, and the identity information includes an identity for recording the proof information.
  • Identity information can also be called role type. By registering the identity information, the first node can call the smart contract to send the first node's certification information to the first blockchain, so as to realize the automatic uploading of the certification information.
  • the trigger timing for the first node to send proof information to the smart contract includes the following. Triggered by the smart contract: the smart contract triggers the proof information collection event, the first node perceives the event, and when the first node determines that the smart contract triggers the proof information collection event, it sends the proof information to the smart contract, so that the smart contract sends the proof information to the first block
  • the proof information is sent on the chain, and the collection event of the proof information is triggered by the smart contract, which can save the overhead of the first node; or, when the first node determines that the smart contract triggers the proof information collection event, the first node sends the proof to the off-chain relay node information, the off-chain relay node sends proof information to the smart contract, so that the smart contract sends proof information to the first blockchain when the first node cannot directly communicate with the blockchain, or the communication between the first node and the blockchain When there are no communication conditions, the first node and the blockchain can communicate through off-chain relays.
  • the first node sends proof information to the blockchain through the smart contract, which can be achieved in the following way: the first node receives the request information from the off-chain relay node; the first node sends the smart contract information according to the request information Send proof information so that the smart contract sends proof information to the first blockchain; or, the first node sends proof information to the off-chain relay node according to the request information, and the off-chain relay node sends proof information to the smart contract to Make the smart contract send proof information to the first blockchain.
  • the first node periodically sends proof information to the smart contract, so that the smart contract sends proof information to the blockchain.
  • the period can be set in advance according to the demand, so as to realize the regular measurement of the reliability of the equipment.
  • the first node periodically sends proof information to the off-chain relay node, and the off-chain relay node sends proof information to the smart contract, so that the smart contract sends proof information to the blockchain.
  • the period can be set in advance according to the demand, so as to realize the regular measurement of the reliability of the equipment.
  • a credible proof method is provided, and the method may be executed by the second node, or may be executed by components of the second node.
  • the method can be implemented through the following steps: the second node obtains the certification information of the first node based on the first blockchain, the certification information includes the information of the first blockchain, the second node The certification information is verified according to the information of the first block chain, and the certification result of whether the first node is credible is obtained. Since the information of the first blockchain can be used as a public random number generated by the first blockchain based on consensus and can be used by multiple nodes, the information of the first blockchain can be used as a challenge value for multiple nodes to perform security measurements .
  • the second node can obtain the proof information of the demonstrator based on the first blockchain, and the second node does not need to establish a separate "challenge-response" process with each demonstrator. This can help improve the scalability of trusted metrics, improve the operating efficiency of trusted proofs, and meet the verification requirements of massive devices in high-concurrency and low-latency application scenarios.
  • the information of the first block chain includes any one or more of the following information: the timestamp of the first block, the hash value of the first block, the first block The hash value of the previous block of the block, the hash string of multiple blocks including the first block, the Merkel merkle tree root of multiple blocks including the first block, Or the random number in the first block, the timestamp of the first transaction, the hash value of the first transaction, or the hash string of multiple transactions including the first transaction; wherein, the The first block is a block on the first block chain, and the first transaction is a transaction on the first block chain.
  • the first node can upload proof information to the first blockchain multiple times, and each proof information or summary information of the proof information is stored on the first blockchain, which can guarantee The correctness and inalterability of the content of the information. Since the certification information is determined according to the information of the first blockchain, the information of the first blockchain is traceable, so each certification information is historical and traceable. For example, if the first node is based on the first The timestamp of the block determines the certification information, and the certification information has a corresponding relationship with the timestamp, and the certification information indicates whether the first node is credible at the time corresponding to the timestamp. As a verifier, the second node can verify the historical credibility of the first node. The second node can obtain the historical proof information of the first node based on the first blockchain, verify whether the first node is historically credible, and obtain a proof result of whether the first node is historically credible.
  • the second node obtains the certification information of the first node from the first block chain, which can be realized in the following way: the second node sends the information of the first node to the smart contract, and the smart contract is deployed on the first node.
  • Obtaining the certification information of the first node through smart contracts can be applied to a variety of trusted computing technologies and improve the scalability of blockchain applications to remote certification.
  • the second node obtains the proof information of the first node from the first block chain, which can be realized in the following way: the second node determines that the smart contract triggers the proof information verification event; the second node receives the first node from the smart contract Proof information for a node.
  • the second node can also register identity information with the smart contract, and the identity information includes the identity used to read the certification information.
  • Identity information can also be called role type. By registering the identity information, the second node can call the smart contract to read the proof information of the first node from the first blockchain.
  • the first blockchain includes a second block; the second block stores proof information, or the second block stores summary information of the proof information, wherein the summary information is used to verify the proof information
  • the integrity of , optional, proof information is stored in off-chain storage nodes. Store proof information through off-chain storage nodes, without storing a large amount of data on the chain, which can improve storage efficiency.
  • a credible proof method is provided, and the method may be executed by the first blockchain node, or may be executed by components of the first blockchain node.
  • the method can be realized through the following steps: the first block chain node receives the first transaction from the first node, the first transaction includes proof information, and the proof information is the first Generated by a node based on the information of the first block chain; the first block chain node verifies the proof information, and the first block chain node sends the first transaction to one of the first block chain after the proof information is verified. or multiple nodes to broadcast.
  • the verification information on the chain is verified by the first block chain node, so as to ensure the credibility of the chain information.
  • the first block chain node verifies the proof information, which can be achieved in the following ways: verifying the reference and LOG proof, proving that the information has not been tampered with, and verifying the generation time of the proof information by verifying the timestamp, And finally through the reference value (reference value) verification to prove the credibility of the information.
  • a communication device may implement the method described in the first aspect above.
  • the communication device has the function of the above-mentioned first node.
  • the communication device is, for example, the first node, or a functional module in the first node, and the like.
  • the first node is, for example, a demonstrator.
  • the communication device may implement the method described in the second aspect above.
  • the communication device has the function of the above-mentioned second node.
  • the communication device is, for example, the second node, or a functional module in the second node.
  • the second node is, for example, a verifier or the like.
  • the communication device may implement the method described in the third aspect above.
  • the communication device has the function of the above-mentioned first block chain node.
  • the communication device is, for example, the first block chain node, or a functional module in the first block chain node.
  • the communication device may include a one-to-one corresponding module for performing the method/operation/step/action described in the first aspect, the second aspect or the third aspect, and the module may be a hardware circuit , also can be software, also can be that hardware circuit combines software to realize.
  • the communication device includes a processing unit (sometimes also called a processing module) and a transceiver unit (sometimes also called a transceiver module). The transceiver unit can realize the sending function and the receiving function.
  • the transceiver unit When the transceiver unit realizes the sending function, it can be called the sending unit (sometimes also called the sending module). When the transceiver unit realizes the receiving function, it can be called the receiving unit (sometimes also called receiving module).
  • the sending unit and the receiving unit can be the same functional module, which is called the transceiver unit, and this functional module can realize the sending function and the receiving function; or, the sending unit and the receiving unit can be different functional modules, and the transceiver unit is for these A general term for functional modules.
  • the processing unit may include an acquisition unit and a determination unit, wherein the acquisition unit is used to acquire the information of the first blockchain; The information of the block chain determines the proof information, and the proof information is used to remotely prove whether the first node is credible.
  • a sending unit configured to send proof information to the first blockchain.
  • the sending unit can also be used to send proof information to the smart contract, and the smart contract is deployed on the blockchain node on the first blockchain.
  • the processing unit may further include a registration unit, configured to register identity information with the smart contract, where the identity information includes an identity used to record certification information.
  • the determining unit is used to determine that the smart contract triggers a proof information collection event; the sending unit is used to send the proof information to the smart contract, so that the smart contract sends the proof information to the first block chain ; or, the first node sends proof information to the off-chain relay node, and the off-chain relay node sends proof information to the smart contract, so that the smart contract sends proof information to the first blockchain.
  • the receiving unit is used to receive the request information from the off-chain relay node; the sending unit is used to send the proof information to the smart contract according to the request information, so that the smart contract Send proof information to the first block chain; or, the first node sends proof information to the off-chain relay node according to the request information, and the off-chain relay node sends proof information to the smart contract, so that the smart contract sends the proof information to the first block chain
  • the sending unit is used to send the proof information to the smart contract according to the request information, so that the smart contract Send proof information to the first
  • the sending unit is used to periodically send proof information to the smart contract, so that the smart contract sends proof information to the blockchain; or, it is used to periodically send proof information to the off-chain relay node, and the off-chain The relay node sends proof information to the smart contract, so that the smart contract sends proof information to the blockchain.
  • the processing unit may include an acquisition unit and a verification unit, wherein the acquisition unit is configured to acquire the certification information of the first node based on the first block chain, and the certification information includes the first The information of a block chain; the verification unit is used to verify the proof information according to the information of the first block chain, and obtain the proof result of whether the first node is credible.
  • the acquiring unit when acquiring the certification information of the first node from the first blockchain, is specifically configured to: send the information of the first node to the smart contract, and the smart contract is deployed on the blockchain on the first blockchain Node; receives the proof information of the first node from the smart contract.
  • the obtaining unit when obtaining the certification information of the first node from the first block chain, is specifically configured to: determine that the smart contract triggers a certification information verification event; receive the certification information of the first node from the smart contract.
  • the processing unit may further include a registration unit, configured to register identity information with the smart contract, where the identity information includes an identity for reading the certification information.
  • the first block chain includes a second block; the second block stores certification information, or the second block stores summary information of the certification information, wherein the summary information is used to verify the integrity of the certification information , proving that the information is stored in off-chain storage nodes.
  • the processing unit may be referred to as a verification unit, wherein the receiving unit is used to receive the first transaction from the first node, the first transaction includes proof information, and the proof information is Generated by the first node according to the information of the first blockchain; the verification unit is used to verify the certification information; the sending unit is used to send the first transaction to one or more of the first blockchain after the certification information is verified. Nodes broadcast.
  • the communication device includes: a processor, coupled to the memory, configured to execute instructions in the memory, so as to implement the method of the first aspect, the second aspect, or the third aspect above.
  • the communication device further includes other components, for example, an antenna, an input and output module, an interface, and the like. These components can be hardware, software, or a combination of software and hardware.
  • a computer-readable storage medium is provided, the computer-readable storage medium is used to store computer programs or instructions, and when executed, the method in any one of the first to third aspects is implemented .
  • a computer program product comprising instructions, which, when run on a computer, enables the method described in any one of the first to third aspects to be implemented.
  • a chip system includes a logic circuit (or it can be understood that the chip system includes a processor, and the processor may include a logic circuit, etc.), and may also include an input/output interface.
  • the input and output interface can be used to receive messages, and can also be used to send messages.
  • the input-output interface can be used to acquire information of the first blockchain.
  • the input and output interfaces can be the same interface, that is, the same interface can realize both the sending function and the receiving function; or, the input and output interface includes an input interface and an output interface, and the input interface is used to realize the receiving function, that is, for receiving Message; the output interface is used to implement the send function, that is, to send a message.
  • the logic circuit can be used to perform the operations in the first aspect to the third aspect above except the sending and receiving function; the logic circuit can also be used to transmit messages to the input and output interfaces, or receive messages from other communication devices through the input and output interfaces.
  • the system-on-a-chip can be used to implement the method in any one of the above-mentioned first aspect to the third aspect.
  • the system-on-a-chip may consist of chips, or may include chips and other discrete devices.
  • system-on-a-chip may further include a memory
  • the memory may be used to store instructions
  • the logic circuit may call the instructions stored in the memory to implement corresponding functions.
  • a communication system may include a first node and a second node, the first node may be used to perform the method described in the first aspect above, and the second node may be used to perform the method described in the above-mentioned The method described in the second aspect;
  • the communication system may further include a first block chain node, and the first block chain node is configured to execute the method as described in the third aspect above.
  • FIG. 1 is a schematic diagram of a remote certification system architecture in an embodiment of the present application
  • FIG. 2 is a schematic diagram of the architecture of a block chain network in the embodiment of the present application.
  • Fig. 3 is a schematic flow chart of the credible proof method in the embodiment of the present application.
  • Fig. 4 is a schematic flowchart of another credible proof method in the embodiment of the present application.
  • Fig. 5 is a schematic diagram of the process of writing certification information into the block chain in the embodiment of the present application.
  • FIG. 6 is a schematic structural diagram of a remote proof smart contract in the embodiment of the present application.
  • Figure 7 is a schematic diagram of role registration or cancellation in the embodiment of this application.
  • Figure 8 is a schematic diagram of the process of registration or cancellation of role provided by the smart contract in the embodiment of this application.
  • Fig. 9 is a schematic diagram of the interface for registering equipment or canceling equipment provided by the smart contract in the embodiment of the present application.
  • Figure 10 is a schematic flow diagram of adding or deleting devices from the smart contract in the embodiment of the present application.
  • Fig. 11 is a schematic diagram of an interface for providing record certification information by a smart contract in the embodiment of this application;
  • Figure 12 is a schematic flow diagram of the caller recording certification information through the interface of the smart contract in the embodiment of the present application.
  • Fig. 13 is a schematic diagram of an interface for reading certification information provided by the smart contract in the embodiment of the present application.
  • FIG. 14 is a schematic flow diagram of the caller reading proof information through the interface of the smart contract in the embodiment of the present application.
  • Fig. 15 is one of the schematic diagrams of the implementation process of the first node sending certification information to the first blockchain in the embodiment of the present application;
  • Figure 16 is the second schematic diagram of the realization process of the first node sending certification information to the first blockchain in the embodiment of the present application;
  • Figure 17 is the third schematic diagram of the realization process of the first node sending certification information to the first blockchain in the embodiment of the present application;
  • Figure 18 is a schematic structural diagram of the smart contract in the embodiment of the present application.
  • Figure 19 is a schematic diagram of the role registration interface or role cancellation interface provided by the smart contract in the embodiment of the application.
  • Figure 20 is a schematic diagram of the implementation process of the first node sending certification information to the first blockchain and the second node obtaining certification information based on the first blockchain in the embodiment of the present application;
  • FIG. 21 is a schematic diagram of a communication device in an embodiment of the present application.
  • the credible proof method provided by the embodiment of the present application can be applied to the fourth generation (4th generation, 4G) communication system, such as long term evolution (long term evolution, LTE), and can also be applied to the fifth generation (5th generation, 5G) communication Systems, such as the 5G new radio (new radio, NR) system, can also be applied to various communication systems that evolve in the future, such as the sixth generation (6th generation, 6G) communication system, or the air-space-sea-ground integrated communication system, or the interface Integrated access and backhaul (IAB) scenarios.
  • the system architecture and application scenarios described in the embodiments of the present application are for more clearly illustrating the technical solutions of the embodiments of the present application, and do not constitute limitations on the technical solutions provided by the embodiments of the present application.
  • Embodiments of the present application provide a trusted attestation method, device, and system to improve the operation efficiency of remote attestation for trusted computing.
  • the method and the device are based on the same technical concept. Since the principles of the method and the device to solve problems are similar, the implementation of the device and the method can be referred to each other, and the repetition will not be repeated.
  • Fig. 1 shows a schematic diagram of a remote attestation system architecture applicable to the embodiment of the present application.
  • the remote attestation system architecture may include a prover 101 , a verifier 102 and a trusted third party (trusted third party, TTP) 103 .
  • the remote attestation system architecture may also include an endorser (endor), and may also include a reference value provider (reference value provider).
  • the number of both the prover 101 and the verifier 102 can be one or more. Multiple means two or more. In FIG. 1 , the number of provers 101 is three, and the number of verifiers 102 is two. Demonstrators 101 are platforms that are verified, measured, and attested to configurations. Validators 102 are entities that validate platform configurations. The names of the prover and the verifier can be other names, for example, the prover can also be called the prover, and the verifier can also be called the verifier. Trusted third party 103 may be a blockchain.
  • Fig. 2 shows a schematic diagram of the architecture of a block chain network applicable to the embodiment of the present application.
  • the blockchain network may include multiple blockchain nodes. Among them, after at least one blockchain node generates a block, it broadcasts the block, and other blockchain nodes verify the block after receiving the block, and update the local blockchain after the verification is passed. "At least one" means one or more. It should be noted that the number of blockchain nodes in the blockchain network shown in Figure 2 is only an example, and it should be understood that more or fewer blockchain nodes may be included in the blockchain network. This is not limited.
  • the structure of the block chain network schematic diagram shown in FIG. 2 is only an example, and there may be other layout structures between block chain nodes, which is not limited in this application.
  • blocks can be used to store data, and multiple blocks are connected in sequence to form a chain, which is called a blockchain.
  • the main features of the blockchain are as follows: (1) Distributed: A blockchain is replicated into multiple copies and maintained on different member servers. (2) Immutable: Each block in the blockchain calculates the hash (Hash) value based on the data stored in the block, and each block in the blockchain records the Hash value of the previous block And the Hash value of the block itself. If the content stored in a block changes, the Hash value of the block changes, and the next block of the block stores the Hash value before the block change, and the next block is based on the Hash value before the change. When verifying the changed Hash of the block, the verification will fail. (3) Traceability: Blocks are connected into a blockchain, and the change history of the entire blockchain can be traced forward according to the connection sequence of each block in the blockchain.
  • the remote attestation process of trusted computing can be divided into three stages: integrity measurement, integrity report and integrity attestation.
  • remote attestation is a "challenge-response" process.
  • the verifier sends a challenge message to the verifier.
  • the challenge message is usually a random number.
  • the verifier performs credibility measurement and returns the measurement result to the verifier.
  • the proof information signed by the identity key or signature key is sent to the verifier.
  • the verifier conducts verification and reasoning on the proof information to determine whether the prover has a trusted computing environment. For example, a device equipped with a TPM can act as a witness.
  • the TPM takes measurements on the system and its software and securely stores these measurements in its platform configuration registers (PCR).
  • PCR platform configuration registers
  • the verifier sends a request, the TPM will report these values, generating a signed digest (i.e. proof) that can be compared with the reference value.
  • the above-mentioned remote proof completed through the "challenge-response" process is a point-to-point proof, which limits the scalability of trusted computing. For example, if 10 nodes need to verify each other, using a point-to-point proof method, a total of a pair of proofs. Each target node needs to generate 9 pieces of proof information. Even if these pieces of proof are almost the same, resources are needed to generate them, resulting in waste of resources and low operating efficiency. For application scenarios with high concurrency and low latency similar to those in 6G networks, the calculation complexity of this method is relatively high.
  • an embodiment of the present application provides a trusted proof method, which uses a blockchain as a trusted third party.
  • the method is implemented by nodes, and the nodes may include a first node and a second node, and may also include a block chain node.
  • the operations performed by the "node” can be performed by the device, or by components of the device (such as processors, chips, or chip systems, etc.), or by software modules or units that integrate logic functions.
  • a node can be a server, a personal computer (PC), a network device or a terminal device in a communication network, or any device with computing and storage capabilities.
  • a node may also be a processor, a chip, or a functional module in the devices listed above.
  • a node is a network device or a terminal device in a communication network
  • the concepts and forms of the network device or the terminal device are as follows.
  • Terminal equipment can also be called user equipment (user equipment, UE), mobile station (mobile station, MS), mobile terminal (mobile terminal, MT), etc., which is a device that provides voice or data connectivity to users.
  • UE user equipment
  • MS mobile station
  • MT mobile terminal
  • the terminal device includes a handheld device with a wireless connection function, a vehicle-mounted device, and the like.
  • Terminal equipment can be: mobile phone (mobile phone), tablet computer, notebook computer, handheld computer, mobile Internet device (mobile internet device, MID), wearable device (such as smart watch, smart bracelet, pedometer, etc.), vehicle-mounted Equipment (such as automobiles, bicycles, electric vehicles, airplanes, ships, trains, high-speed rail, etc.), virtual reality (virtual reality, VR) equipment, augmented reality (augmented reality, AR) equipment, wireless in industrial control (industrial control) Terminals, smart home devices (such as refrigerators, TVs, air conditioners, electricity meters, etc.), intelligent robots, workshop equipment, wireless terminals in self driving, wireless terminals in remote medical surgery, smart grid Wireless terminals in (smart grid), wireless terminals in transportation safety (transportation safety), wireless terminals in smart city (smart city), or wireless terminals in smart home (smart home), flying devices (for example, intelligent robots , hot air balloons, drones, airplanes), etc.
  • vehicle-mounted Equipment such as automobiles, bicycles, electric vehicles, airplanes, ships, trains
  • the terminal device in the embodiment of the present application may also refer to a chip in the terminal device, and may also refer to a communication device, unit or module with a user equipment to user equipment (UE to UE, U2U) communication function, such as a vehicle-mounted communication device , a vehicle-mounted communication module or a vehicle-mounted communication chip, etc.; in the embodiment of the present application, the terminal device may also be a roadside unit (roadside unit) in a vehicle networking communication system, or a communication device or a communication chip in a roadside unit.
  • UE to UE, U2U user equipment to user equipment
  • the network device may be a device in a radio access network, the radio access network may include one or more radio access network devices, and the network device may be a radio access network device.
  • the terminal device can be connected to the wireless access network device in a wireless manner.
  • the communication system may further include a core network (core network, CN), and radio access network devices are connected to the core network in a wireless or wired manner.
  • the core network equipment and the wireless access network equipment can be independent and different physical equipment, or the functions of the core network equipment and the logical functions of the wireless access network equipment can be integrated on the same physical equipment, or it can be a physical equipment It integrates some functions of core network equipment and some functions of wireless access network equipment.
  • Wireless access network equipment can be various types of base stations, such as evolved base stations (evolved NodeB, eNodeB), transmission reception point (transmission reception point, TRP), and next-generation base stations in the fifth generation (5th generation, 5G) mobile communication system (next generation NodeB, gNB), the next generation base station in the sixth generation (6th generation, 6G) mobile communication system, or the base station in the future mobile communication system, etc., can also be an access node and other equipment in the WiFi system; It may be a module or unit that completes some functions of the base station, for example, it may be a centralized unit (central unit, CU) or a distributed unit (distributed unit, DU).
  • eNodeB evolved NodeB
  • TRP transmission reception point
  • next generation NodeB, gNB next generation base station in the sixth generation (6th generation, 6G) mobile communication system
  • the base station in the future mobile communication system
  • the CU here completes the functions of the radio resource control protocol and the packet data convergence protocol (PDCP) of the base station, and also completes the function of the service data adaptation protocol (SDAP); the DU completes the functions of the base station
  • the functions of the radio link control layer and the medium access control (medium access control, MAC) layer can also complete the functions of part of the physical layer or all of the physical layer.
  • 3rd generation partnership project, 3GPP third generation partnership project
  • the embodiment of the present application does not limit the specific technology and specific equipment form adopted by the radio access network equipment.
  • the functions of the base station may also be performed by modules (such as chips) in the base station, or may be performed by a control subsystem including the functions of the base station.
  • the control subsystem including base station functions here may be the control center in the above application scenarios such as smart grid, industrial control, intelligent transportation, and smart city.
  • the functions of the terminal equipment may also be performed by a module (such as a chip or a modem) in the terminal equipment, or may be performed by a device including the functions of the terminal equipment.
  • the first node may serve as a demonstrator, or in other words, the first node is a target node that the demonstrator is responsible for.
  • the second node can act as a validator.
  • the first node and the second node may or may not be blockchain nodes.
  • the specific flow of a credible verification method provided by the embodiment of the present application is as follows, and the method is described from the side of the first node.
  • the first node acquires information of the first blockchain.
  • the first node determines certification information according to the information of the first blockchain.
  • the certification information is used to remotely prove whether the first node is credible.
  • the second node acquires certification information of the first node based on the first blockchain.
  • the proof information includes the information of the first blockchain
  • the second node verifies the certification information according to the information of the first blockchain, and obtains a certification result of whether the first node is credible.
  • the embodiment in FIG. 4 may alone form the solution that requires protection in this application, or may be combined with the embodiment in FIG. 3 to form a solution that requires protection in this application.
  • S401 is performed after S302.
  • the first node can be a witness 101
  • the second node can be a verifier 102
  • the first blockchain can be a trusted third party 103.
  • the information of the first block chain can be a public random number generated by the first block chain based on consensus, so the information of the first block chain can be used as a security measure for multiple nodes challenge value.
  • the first node generates proof information by referencing a trusted third party to generate a publicly recognized random number as a challenge value.
  • the proof information can be verified by any verifier to achieve multiple verifications for one measurement, so that the first node does not need to communicate with each Validators establish a separate "challenge-response" process.
  • the second node can obtain the proof information of the demonstrator based on the first blockchain, and the second node does not need to establish a separate "challenge-response" process with each demonstrator. This can help improve the scalability of trusted metrics, improve the operational efficiency of remote attestation, and meet the verification requirements of massive devices in high-concurrency and low-latency application scenarios.
  • the first block chain includes the first block.
  • the first block is the latest block on the first block chain, or the first block is the first The block with the highest height on the blockchain.
  • the information of the first block chain can be any of the following, or any combination of the following: the timestamp of the first block, the hash value of the first block, the previous block of the first block the hash value of , the hash string of multiple blocks including the first block, the merkle root of multiple blocks including the first block, or the random number in the first block number.
  • the certification information of the first node may be used to prove whether at least one item of software information, hardware information or system information of the first node is credible.
  • the process for the first node to determine the certification information based on the information of the first blockchain can be considered as a measurement process. Perform integrity measurement on at least one item to obtain the certification information, which may include one or more of the following: information of the first blockchain, PCR value, measurement log, or measurement log template.
  • S303 may also be included.
  • the first node sends the proof information to the first blockchain.
  • the first node sends the certification information to the first blockchain, which can be understood as the first node sends the certification information to the blockchain nodes of the first blockchain.
  • the first blockchain sends the certification information to the blockchain nodes of the first blockchain.
  • it when it comes to the interaction between the blockchain and other nodes, it can be understood as the interaction between the nodes of the blockchain and other nodes.
  • the first node can generate a transaction according to the information of the first blockchain.
  • the transaction includes the certification information, and the first node sends the transaction to the blockchain node of the first blockchain.
  • the blockchain nodes of the first blockchain can be recorded as the first blockchain nodes.
  • the first blockchain node can verify the transaction, and the verification process can be as follows: verify the reference and LOG proof, prove that the information has not been tampered with, and verify the timestamp Prove the generation time of the proof information, and finally verify the credibility of the proof information through the reference value. Broadcast the transaction after the verification is passed.
  • the second blockchain node will generate a second block based on the transaction.
  • the second block chain node may generate a second block based on the transaction and other transactions.
  • the second block chain node broadcasts the second block, and other block chain nodes on the first block chain except the second block chain node update the local block chain after receiving the second block.
  • the other blockchain nodes on the first blockchain except the second blockchain node receive the second block, they can first verify the second block, and then pass the verification on the second block Then, verify the transaction.
  • the verification process can refer to the verification process of the transaction by the first block chain node, and update the local block chain after the transaction verification is passed. In this way, the process of proving information on the chain is completed.
  • This implementation method 1 can be applied to the situation where blockchain nodes can add data to blocks without smart contracts.
  • the first node sends the proof information to the smart contract, that is, the first node sends the proof information to the first blockchain through the smart contract.
  • the smart contract is deployed on the blockchain nodes on the first blockchain, for example, the smart contract may be deployed on all the blockchain nodes on the first blockchain.
  • the first node invokes the smart contract, and writes parameters into the smart contract during the calling process, and the parameters include the proof information.
  • Smart contracts generate transactions based on written parameters.
  • the proof information is included in the transaction.
  • the smart contract sends the transaction to the blockchain node of the first blockchain, and the blockchain node of the first blockchain can be recorded as the first blockchain node.
  • the embodiment of this application involves the interaction between the smart contract and other nodes, which can be understood as the interaction between the blockchain node where the virtual machine running the smart contract resides and other nodes.
  • the operations performed by the smart contract can be understood as the operations performed by the blockchain node where the virtual machine running the smart contract is located.
  • the above gives a possible implementation method for the first node to send the certification information to the first blockchain
  • the storage methods of the certification information in the first blockchain may have the following forms.
  • the certification information can be stored in the second block, that is, a complete record of the certification information is stored in the second block.
  • the summary information of the certification information is recorded in the second block, and the summary information is used to verify the integrity of the certification information, and the certification information is stored in an off-chain storage node.
  • the off-chain storage node is located on a node outside the first blockchain.
  • the summary information may be, for example, a hash value of the certification information.
  • Fig. 5 shows each block in the first block chain, and the ellipsis in Fig. 5 indicates that there may be one or more blocks between two blocks.
  • the first blockchain may include more or fewer blocks, the number of blocks in Figure 5 is only an example.
  • the structure of each block includes multiple fields, and different fields are used to store different data.
  • the structure of the block and the names of the fields shown in FIG. 5 are only examples, and more or fewer fields may be included in the block, which is not limited in the present application.
  • FIG. 5 shows each block in the first block chain, and the ellipsis in Fig. 5 indicates that there may be one or more blocks between two blocks.
  • the first blockchain may include more or fewer blocks, the number of blocks in Figure 5 is only an example.
  • the structure of each block includes multiple fields, and different fields are used to store different data.
  • the structure of the block and the names of the fields shown in FIG. 5 are only examples, and more or fewer fields may be included in the block, which is not limited in the
  • a block may include a root field, a hash field, and a timestamp field.
  • the tree root field is also called m_root field, for example, or may have another name.
  • the hash field may also be called the p_hash field, or by another name.
  • the timestamp field is also called timestamp field, for example, or may have other names.
  • the timestamp field of the first block is used for the timestamp of the first block.
  • the process of generating certification information by the first node is as follows, using the PCR value and time stamp to sign (sign) and generate a quote (quote).
  • the proof information includes the reference and the original log (log).
  • the first node sends the generated transaction to the first blockchain node of the first blockchain.
  • the second block chain node will generate the second block based on the transaction.
  • the second block chain node generates the second block based on the packaging of multiple transactions.
  • the multiple transactions are illustrated with four transactions as an example. , represented by TX1, TX2, TX3, TX4 respectively.
  • first blockchain node and the second blockchain node may be the same node or different nodes.
  • the first block and the second block may be the same block or different blocks.
  • the proof information of the first node may be uploaded to the first block.
  • the second node obtains the proof information from the second block.
  • the second node performs verification according to the certification information, and obtains a certification result of whether the first node is credible.
  • the second node obtains the summary information from the second block, and verifies the integrity of the certification information according to the summary information, Obtain the proof result of whether the first node is credible.
  • the second node can obtain the certification information or the summary information from the second block, which can be considered as obtaining the certification information or the summary information from the transaction.
  • the second node first needs to obtain a transaction identifier (ID), and obtains the transaction corresponding to the transaction ID from the blockchain node of the first blockchain according to the transaction ID.
  • ID transaction identifier
  • the second node may send a request to the first node when it needs to verify the credibility of the first node, and the first node sends the certificate information corresponding to the certification information to the second node based on the request. Transaction ID, so that the second node obtains the transaction ID.
  • the first node will trigger an event according to the timer. After the timer expires, the event is triggered, and the first node will send the proof information or the transaction in which the summary information is located to the second node. ID. The second node receives the transaction ID from the first node.
  • the second node when the second node needs to verify the credibility of the first node, it can send the information of the first node to the smart contract.
  • the information of the first node can be, for example, the Identification number (ID).
  • Smart contracts are deployed on blockchain nodes on the first blockchain, for example, smart contracts may be deployed on all blockchain nodes on the first blockchain.
  • the second node invokes the smart contract, and inputs parameters to the smart contract during the calling process, and the parameters may include the information of the first node.
  • the smart contract feeds back the proof information of the first node to the second node according to the input parameters.
  • the second node obtains the certification result of whether the first node is credible according to the certification information.
  • the smart contract can also feed back the proof result of whether the first node is credible to the second node according to the input parameters. In this case, the smart contract verifies whether the first node is credible according to the proof information.
  • the second node can send the proof result to the first block chain.
  • the implementation method of the second node sending the proof result to the first block chain can refer to the realization method of the first node sending the proof information to the first block chain, that is, the process of uploading the proof result to the chain can refer to the process of uploading the proof information to the chain process.
  • the block chain is a platform that cannot be tampered with, and the first node can upload multiple proof information to the first block chain, and each proof information or the proof The summary information of the information is stored on the first block chain, which can guarantee the correctness and non-tamperable modification of the content of the proof information.
  • the certification information is determined according to the information of the first blockchain, the information of the first blockchain is traceable, so each certification information is historical and traceable. For example, if the first node is based on the first The timestamp of the block determines the certification information, and the certification information has a corresponding relationship with the timestamp, and the certification information indicates whether the first node is credible at the time corresponding to the timestamp.
  • the second node can verify the historical credibility of the first node.
  • the second node can obtain the historical proof information of the first node based on the first blockchain, verify whether the first node is historically credible, and obtain a proof result of whether the first node is historically credible.
  • a third party that needs to be tested, a node that is newly connected to the network and other equipment that needs to measure the historical credibility of the network, it only needs to obtain the historical proof information of the network from the blockchain to complete Remote proofs in history.
  • the first node sends the first node's certification information to the first blockchain, and the second node obtains the first node's certification information based on the first blockchain, both of which can be completed through smart contracts.
  • the following describes the optional implementation through smart contracts.
  • Smart contracts include some code and data, which together constitute an executable file unit, which can run on the virtual machine defined by the blockchain and is stored in the leaf nodes of the state tree. So a smart contract is an account with a balance, code and storage. The smart contract is triggered when a parameter transaction containing sufficient funds and any inputs related to the smart contract is sent to this account. The data under the code tree, the storage tree, and the input parameters of the transactions are sent to the virtual machines running on the nodes.
  • New blocks on the blockchain include the output of the virtual machine as an update to the storage root and the storage root hash. Along with other changes, the blockchain's state root hash also changes. This new state root hash will be part of the new block. Old data can be linked to the new tree, which avoids duplication of data.
  • Smart contracts are permanent, but they require maintenance. Errors and design flaws in the code need to be corrected through code upgrades and database migrations. At the end of the lifetime, the contract needs to be destroyed.
  • the maintenance of a smart contract depends on the particular blockchain on which it is deployed. Typically, creating a new contract and migrating the data from the old contract is required to put it into use. Since the updated contract will be a brand new contract, it will have a new address and will need to be published.
  • a transaction needs to be initiated from another account. This transaction also needs to include enough to cover the cost of running the smart contract operation. Sometimes a smart contract needs to get some value from the outside world, or trigger some action on the outside world.
  • the first node sends the certification information of the first node to the first block chain through the smart contract (which can be recorded as the first smart contract), and the second node sends the certification information of the first node through the smart contract (which can be recorded as the second smart contract) Proof information of the first node is acquired based on the first block chain.
  • the first smart contract and the second smart contract can be one or two different smart contracts.
  • the remote proof smart contract is referred to as a smart contract for short, and may include the above-mentioned first smart contract and second smart contract.
  • the remote attestation solution owner designates a deployer, and the deployer deploys the remote attestation smart contract.
  • Figure 6 shows the structure of the remote proof smart contract.
  • the structure of the smart contract can include multiple data, such as data of the following items: owner, evidence writers, evidence readers, equipment Controllers (device controllers), devices (devices), and storage units.
  • each item of data may include the corresponding public key information and account information of the device, and the evidence of each node is stored in the storage unit, which is indexed by the public key of the device.
  • Evidence is proof of information.
  • the deployment process will be done as a single transaction, and the input parameters will contain the smart contract code, owner group and enough fees to pay for creating the smart contract account on the blockchain. Transactions will be signed by the private key of the remote attestation solution deployer.
  • the database is created and the owner table is initialized with the owner group passed in the smart contract creation transaction.
  • the owner group can be used to register writers, readers, and devices.
  • the smart contract exposes a registration/deregistration interface for members of the owner group to add the user to a role that can proceed further.
  • These roles can be Device Controller, Evidence Recorder, and Evidence Reader.
  • the user may be the first node or the second node.
  • the registration/deregistration process can be shown in FIG. 8 . Specifically include the following steps:
  • the caller invokes the role registration/logout interface, and inputs the identity of the caller and the requested role type.
  • the caller may be the first node, and the first node registers identity information with the smart contract, and the identity information includes an identity for recording proof information.
  • the first node invokes the role registration/logout interface, and inputs the identity of the caller and the requested role type as evidence recorder.
  • the caller may be the second node, and the second node registers identity information with the smart contract, and the identity information includes an identity for reading the certification information.
  • the second node invokes the role registration/logout interface, and inputs the identity of the caller and the requested role type as evidence reader.
  • the third-party component checks the validity of the user request.
  • the role type is a device controller
  • a device controller is added/deleted in the device controller list.
  • the role type is evidence recorder
  • the role type is evidence reader
  • the remote attestation smart contract provides a registration/deregistration device interface, and the registration device interface and deregistration device interface can be the same interface, or implemented through two different interfaces.
  • Device controllers can use this register/deregister device interface to add/remove devices from the smart contract.
  • the device may be the first node or the second node.
  • the caller invokes the register/deregister device interface, and inputs the caller's identity and device information.
  • the third-party component checks the validity of the caller.
  • step S1003 If the caller is in the list of device controllers, continue to execute step S1003, otherwise reject the request for device registration/deregistration.
  • the smart contract provides an interface for recording certification information, and the first node can call this interface to record the certification information of the first node.
  • the first node can be a demonstrator, a verifier, or an observer.
  • the caller invokes the interface for recording proof information of the smart contract, and the parameters input to the smart contract may include: caller identity, device information, and proof information.
  • the caller can be the first node.
  • the third-party component checks the validity of the caller.
  • step S1203 If the caller is in the certification information recorder list, continue to step S1203, otherwise, declare that the caller is not allowed to record the certification information.
  • the device may be a first node.
  • the smart contract sends the proof information to the blockchain.
  • the certification information can be sent to each blockchain node of the blockchain.
  • the smart contract provides an interface for reading proof information, and the second node can call this interface to read the proof information of the first node.
  • the second node can be a prover, a verifier, or an observer.
  • the caller invokes the interface for reading proof information of the smart contract, and the parameters input to the smart contract may include: caller identity and device information.
  • the caller can be the second node.
  • the third-party component checks the validity of the caller.
  • step S1403 If the caller is in the certificate information reader list, continue to execute step S1403, otherwise, declare that the caller is not allowed to read the certificate information.
  • the device may be a second node.
  • the smart contract returns the proof information to the caller from the proof information database.
  • the first node sends proof information to the first block chain, and the first node may be any node that needs to upload its own proof information.
  • the second node obtains certification information based on the first block chain, and the second node can also be any node that needs to verify whether the first node is credible. It can be understood that there may be M first nodes sending certification information to the first blockchain, and N second nodes may obtain any one or more first nodes among the M first nodes based on the first blockchain. proof information. Both M and N are positive integers. For example, if 10 nodes need to verify each other, using a point-to-point proof method, a total of a pair of proofs.
  • each node only needs to generate one piece of proof information, and send the proof information to the blockchain, which can then be verified by the remaining nine nodes.
  • the calculation complexity of this method is reduced, the operating efficiency is high, and resources are saved, and it is suitable for application scenarios with high concurrency and low latency.
  • the first node sends proof information to the first blockchain, and the first node can send proof information to the first blockchain through an off-chain relay node.
  • the interaction between the first node and other nodes can be done through off-chain relay nodes.
  • the interaction between the second node and other nodes can also be done through off-chain relay nodes.
  • the triggering manners for the first node to send proof information to the first blockchain may include the following.
  • Trigger method 1 Triggered by the first smart contract.
  • the first smart contract triggers a proof information collection event, the first node perceives the event, and when determining that the smart contract triggers the proof information collection event, the first node sends proof information to the smart contract.
  • the device controller configures the device, for example, the first node, on the first blockchain-based attestation system. Assuming that the first blockchain provides an alarm service, the alarm service itself is another smart contract and is set to call the first smart contract to refresh the certification information of the device. Once the first smart contract receives the alert notification, it will trigger the attestation information collection event and perform remote attestation.
  • the device controller invokes the first smart contract to register the device, and sends a registration alert to the alert service on the first blockchain.
  • the alarm service sends an update proof information message to the first smart contract.
  • the first smart contract triggers a remote certification information collection event.
  • S1503, S1504 or S1505 may be executed.
  • the first node can rotate or register to the first blockchain, the first node can trigger an event of reading proof information from the first smart contract. After S1504, S1506 or S1507 may be executed.
  • the off-chain relay node triggers an event of reading proof information from the first smart contract, and sends a proof request to the first node after the event is triggered.
  • S1506 or S1507 may be executed.
  • the first node If the first node can directly write into the blockchain, the first node writes the certification information into the first smart contract.
  • Step S1508 may also be executed after S1506.
  • the first node If the first node cannot directly write into the blockchain, the first node will send the proof information to the off-chain relay node, and the off-chain relay node will upload the proof information to the smart contract.
  • Step S1508 is also executed after S1507.
  • the smart contract sends proof information to the first blockchain.
  • the smart contract can first verify the consistency of the first node, and then send proof information to the first blockchain. Smart contracts can update each blockchain node after consensus.
  • Trigger method 2 Triggered by off-chain relay nodes.
  • the off-chain relay node triggers the proof information collection event, the off-chain relay node sends request information to the first node, the first node receives the request information from the off-chain relay node, and the first node sends proof information to the smart contract according to the request information .
  • the device controller invokes the first smart contract to register the device, for example, to register the first node.
  • the off-chain relay node triggers a timer for updating the certification information.
  • the off-chain relay node sends request information to the first node.
  • the request information is used to request to upload the certification information of the first node.
  • the first node If the first node can directly write into the blockchain, the first node writes the certification information into the first smart contract.
  • the first node can directly write to the blockchain or it can be considered that the first node can interact with the blockchain.
  • the first node writes the proof information into the first smart contract
  • the first node creates a transaction to write the proof information.
  • Step S1606 may be executed after S1604.
  • the first node If the first node cannot directly write into the blockchain, the first node sends the proof information to the off-chain relay node, and the off-chain relay node uploads the proof information to the smart contract.
  • Step S1606 may be executed after S1605.
  • the smart contract sends proof information to the first blockchain.
  • Trigger method three triggered by the first node.
  • the first node may be triggered based on an event, or periodically based on a timer.
  • the first node sends proof information to the first smart contract based on events or periodically.
  • the device controller invokes the first smart contract to register the device, for example, to register the first node.
  • the first node triggers a timer for updating certification information.
  • the first node If the first node can directly write into the blockchain, the first node writes the certification information into the first smart contract.
  • the first node can directly write to the blockchain or it can be considered that the first node can interact with the blockchain.
  • the first node writes the proof information into the first smart contract
  • the first node creates a transaction to write the proof information.
  • Step S1705 may also be executed after S1703.
  • the first node If the first node cannot directly write into the blockchain, the first node sends the proof information to the off-chain relay node, and the off-chain relay node uploads the proof information to the smart contract.
  • Step S1705 may also be executed after S1704.
  • the smart contract sends proof information to the first blockchain.
  • the structure of the smart contract can include several items of data: the owner of the smart contract (or the publisher of the smart contract), the endorser, the reference value provider , and measurement logs (verification logs).
  • the measurement log is the log information of verification.
  • the structure of the smart contract shown in FIG. 18 can be combined with the structure shown in FIG. 6 to form a smart contract, which can be invoked by the first node and/or the second node.
  • the structure of the smart contract shown in FIG. 18 may be the structure of the second smart contract.
  • the smart contract exposes a registration/deregistration interface for the owner group members.
  • the owner group members can use this interface to add users to roles that can continue to perform further operations. These roles can be endorsers, references value provider.
  • the first node sends proof information to the first block chain through the smart contract, and the second node obtains the proof information based on the first block chain through the smart contract.
  • the second node sends the information of the first node to the smart contract, and the smart contract returns the certification information or the certification result of whether the first node is credible to the second node.
  • the first node and the second node use different smart contracts
  • the first node uses the first smart contract to send proof information to the first block chain
  • the second node obtains the proof information based on the first block chain through the second smart contract. proof information.
  • the second node sends the information of the first node to the second smart contract
  • the second smart contract obtains the certification information of the first node from the first smart contract
  • the second smart contract returns the certification information of the first node to the second node .
  • the second node may actively trigger the acquisition event of the certification information of the first node.
  • the second node may trigger the acquisition of the certification information of the first node based on an event or periodically.
  • the acquisition of proof information by the second node can also be triggered by a smart contract, for example, a smart contract triggers a proof information verification event, and the second node determines that the smart contract triggers a proof information verification event, then obtains the proof information of the first node from the smart contract.
  • the off-chain relay node can also trigger the second node to obtain the certification information, the off-chain relay node triggers the certification information collection event, the off-chain relay node sends the request information to the second node, and the second node obtains from the smart contract according to the request information Proof information of the first node.
  • the second node when the second node obtains the certification information of the first node from the smart contract, the second node can send the information of the first node to the smart contract, and the smart contract returns the certification information of the first node to the second node or whether the first node can Letter of proof results.
  • an implementation process is provided in which the first node sends certification information to the first blockchain in an application scenario, and the second node obtains certification information based on the first blockchain.
  • the device controller configures the device on the proof system based on the first blockchain, for example, configures the first node and/or the second node.
  • This step may include: the device controller registers the first node with the first smart contract; the endorser registers with the second smart contract and initializes relevant endorsements; the reference value provider registers with the second smart contract and initializes relevant reference values.
  • the second node requests the second smart contract to evaluate whether the target device (ie, the first node) is credible, or the second node requests the second smart contract for certification information of the target device.
  • the second smart contract sends a request to the first smart contract for requesting certification information of the first node.
  • the first smart contract verifies whether there is fresh proof information available on the blockchain, and if so, executes S2005, otherwise, the first smart contract triggers a proof information collection event, and executes S2005 after receiving the proof information.
  • the process after the first smart contract triggers the proof information collection event can refer to the description in the first triggering method above, and will not be repeated here.
  • the first smart contract receives the certification information, it can first verify the certification information and store it in the first blockchain.
  • the first smart contract sends the proof information to the second smart contract.
  • the second smart contract verifies the proof information.
  • the second smart contract verifies the signature, proving that it comes from a legitimate trusted hardware platform (TPM).
  • TPM trusted hardware platform
  • the second smart contract can also verify the reference and LOG proof to prove that the information has not been tampered with, and can also verify the timestamp to prove the generation time of the proof information. And finally through the reference value (reference value) verification to prove the credibility of the information.
  • the second smart contract returns to the second node the certification information of the first node or the certification result of whether the first node is credible.
  • the communication device provided by the embodiments of the present application is introduced.
  • An embodiment of the present application provides a communication device.
  • the communication device includes, for example, a processing unit and a transceiver unit (or called a communication unit).
  • the processing unit can be used to implement the first node described in any one of the above method embodiments.
  • processing function the transceiver unit may be used to implement all or part of the transceiver function of the first node described in any one of the above method embodiments.
  • the processing unit may be used to implement the processing function implemented by the second node described in any one of the above method embodiments, and the transceiver unit may be used to implement the second node described in any one of the above method embodiments All or part of the transceiver function.
  • the processing unit can be used to implement the processing function implemented by the first blockchain node described in any one of the above method embodiments, and the transceiver unit can be used to realize the processing functions described in any one of the above method embodiments. All or part of the sending and receiving functions of the first block chain node.
  • the processing unit may include an acquisition unit and a determination unit, and optionally, the processing unit may further include a registration unit.
  • the processing unit may include an acquisition unit and a verification unit, and optionally, the processing unit may also include a registration unit.
  • the processing unit may be a verification unit.
  • the processing unit and/or the transceiver unit may be realized by a virtual module, for example, the processing unit may be realized by a software function unit or a virtual device, and the transceiver unit may be realized by a software function unit or a virtual device.
  • the processing unit and/or the transceiver unit may also be implemented by a physical device (such as a circuit system and/or a processor, etc.). The following describes the case where the processing unit and the transceiver unit are implemented by a physical device.
  • FIG. 21 shows a schematic structural diagram of a communication device provided by an embodiment of the present application.
  • the communication device 2100 may be the first node described in any one of the above method embodiments, the circuit system of the first node, or the circuit system applicable to the first node, etc., and is used to implement the Corresponds to the method of the first node.
  • the communication device 2100 may be the second node described in any one of the above method embodiments, the circuit system of the second node, or the circuit system applicable to the second node, etc., for implementing the above method The example corresponds to the method of the second node.
  • the communication device 2100 may be the first blockchain node described in any one of the above method embodiments, the circuit system of the first blockchain node, or a circuit that can be applied to the first blockchain node
  • the system and the like are used to implement the method corresponding to the first blockchain node in the above method embodiment.
  • a circuit system is a chip system.
  • the communication device 2100 includes one or more processors 2101 .
  • the processor 2101 may implement certain control functions.
  • the processor 2101 may be a general-purpose processor or a special-purpose processor. For example, including: baseband processor, central processing unit, etc.
  • the baseband processor can be used to process communication protocols and communication data.
  • the central processing unit can be used to control the communication device 2100, execute software programs and/or process data.
  • Different processors may be independent devices, or may be arranged in one or more processing circuits, for example, integrated on one or more application-specific integrated circuits.
  • the communication device 2100 includes one or more memories 2102 for storing instructions 2104, and the instructions 2104 can be executed on the processor, so that the communication device 2100 executes the methods described in the above method embodiments.
  • data may also be stored in the memory 2102 .
  • the processor and memory can be set separately or integrated together.
  • the communication device 2100 may store instructions 2103 (also referred to as codes or programs sometimes), and the instructions 2103 may be executed on the processor, so that the communication device 2100 executes the methods described in the above-mentioned embodiments .
  • Data may be stored in the processor 2101.
  • the processing unit is realized by one or more processors 2101, or, the processing unit is realized by one or more processors 2101 and one or more memories 2102, or, the processing unit is realized by one or more Processor 2101, one or more memories 2102, and instructions 2103 implement.
  • the communication device 2100 may further include a transceiver 2105 and an antenna 2106 .
  • the transceiver 2105 may be called a transceiver unit, a transceiver, a transceiver circuit, a transceiver, an input/output interface, etc., and is used to realize the transceiver function of the communication device 2100 through the antenna 2106 .
  • the transceiver unit is implemented by a transceiver 2105
  • the transceiver unit is implemented by a transceiver 2105 and an antenna 2106 .
  • the communication device 2100 may further include one or more of the following components: a wireless communication module, an audio module, an external memory interface, an internal memory, a universal serial bus (universal serial bus, USB) interface, a power management module, an antenna, Speakers, microphones, I/O modules, sensor modules, motors, cameras, or displays, etc. It can be understood that, in some embodiments, the communication device 2100 may include more or fewer components, or some components may be integrated, or some components may be separated. These components may be realized by hardware, software, or a combination of software and hardware.
  • the processor 2101 and transceiver 2105 described in the embodiment of the present application can be implemented in an integrated circuit (integrated circuit, IC), analog IC, radio frequency integrated circuit (radio frequency identification, RFID), mixed signal IC, application specific integrated circuit (application specific integrated circuit, ASIC), printed circuit board (printed circuit board, PCB), or electronic equipment, etc.
  • the communication device described in this article may be an independent device (for example, an independent integrated circuit, a mobile phone, etc.), or it may be a part of a larger device (for example, a module that can be embedded in other devices).
  • a module for example, please refer to the aforementioned Embodiments
  • the explanations about the first node, the second node and the first block chain node will not be repeated here.
  • the embodiments of the present application may be provided as methods, systems, or computer program products. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.
  • computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
  • These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture comprising instruction means, the instructions
  • the device realizes the function specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Power Engineering (AREA)
  • Software Systems (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

一种可信证明方法及通信装置，以期提高可信计算的远程证明的运行效率。该方法为：第一节点获取第一区块链的信息，第一节点根据该第一区块链的信息确定证明信息，其中，该证明信息用于该第一节点被远程证明是否可信。由于第一区块链的信息可以作为第一区块链基于共识生成的可供多个节点使用的公共的随机数，因此第一区块链的信息可以作为多个节点进行安全度量的挑战值。该证明信息可以被任何验证者验证，实现一次度量多次验证，从而第一节点无需与每一个验证者建立单独的"挑战-应答"流程。这样可以有助于提高可信度量的可扩展性，能够有助于提高远程证明的运行效率，满足高并发低时延的应用场景中海量设备的验证需求。

Description

一种可信证明方法及通信装置
相关申请的交叉引用
本申请要求在2021年12月23日提交中华人民共和国知识产权局、申请号为202111593395.7、申请名称为“一种可信证明方法及通信装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请实施例涉及计算机安全技术领域，尤其涉及一种可信证明方法及通信装置。
背景技术
随着计算机技术的迅速发展，在分布式计算环境中对于节点的安全性要求越来越高，针对这种情况，如何证明相互通信的节点安全可信，已经成为计算机安全领域中的重要课题。可信计算领域中的平台可信证明(简称可信证明)是信息安全的研究重点。可信平台模块(trusted platform module，TPM)是可信计算技术中的基础，TPM是嵌入在硬件平台上的安全芯片，TPM内部预置了一个支撑安全体系的密钥树的存储根。通过合理利用各种可信计算技术，能够实现以TPM可信根为起点，逐步扩展到整个硬件平台，构建基于硬件的信任链，最终完成从底层硬件到上层系统的可信传递，从而在本地主机上搭建一套可信的计算环境。虽然在节点上能够建立可信的计算环境，但是，对于外部节点而言并不能确定这个节点具备可信的计算环境，也不能确定与该节点进行通信是否安全。远程(remote)证明是发出证明请求的一方确认远程平台的身份和平台状态配置信息的过程，也就是确认远程平台是否可信的过程。远程证明使得证明请求者可以检测到被证明的节点的变化，可以避免向不安全或安全受损的节点发送私有信息或重要命令。远程证明也是在节点之间建立信任关系的重要方法，是节点将信任向外扩展的重要手段，尤其在复杂的网络环境中，利用远程证明建立信任关系尤为重要。
可信计算的远程证明涉及的节点包括示证者(attester)和验证者(verifier)，示证者通过本地度量向验证者报告目标节点的完整性状态，使得验证者能够验证目标节点的软硬件组件是否按照预期方式运行。
目前，可信计算的远程证明的运行效率较低，如何提高远程证明的运行效率，是需要考虑的问题。
发明内容
本申请实施例提供一种可信证明方法及通信装置，以期提高可信计算的远程证明的运行效率。
第一方面，提供一种可信证明方法，该方法可以由第一节点执行，也可以由第一节点的部件执行。以执行主体为第一节点为例，该方法可以通过以下步骤实现：第一节点获取第一区块链的信息，第一节点根据该第一区块链的信息确定证明信息，其中，该证明信息用于该第一节点被远程证明是否可信。由于第一区块链的信息可以作为第一区块链基于共 识生成的可供多个节点使用的公共的随机数，因此第一区块链的信息可以作为多个节点进行安全度量的挑战值。第一节点通过引用可信的第三方生成公共可认的随机数作为挑战值，生成证明信息，该证明信息可以被任何验证者验证，实现一次度量多次验证，从而第一节点无需与每一个验证者建立单独的“挑战-应答”流程。这样可以有助于提高可信度量的可扩展性，能够有助于提高远程证明的运行效率，满足高并发低时延的应用场景中海量设备的验证需求。
在一个可能的设计中，该第一区块链的信息包括以下任意一种或多种信息：第一区块的时间戳、第一区块的哈希值、第一区块的上一个区块的哈希值、包含有第一区块的多个区块的哈希串、包含有第一区块的多个区块的默克尔(merkle)树根、或第一区块中的随机数、第一交易的时间戳、所述第一交易的哈希值、或包含有所述第一交易的多个交易的哈希串；其中，所述第一区块为所述第一区块链上的区块，所述第一交易为所述第一区块链上的交易。区块链作为不可篡改的平台，第一节点可以向第一区块链上传多次证明信息，每一次的证明信息或该证明信息的摘要信息被存储在第一区块链上，能够保证证明信息的内容的正确性和不可篡改性。由于证明信息是根据第一区块链的信息确定的，第一区块链的信息具有可追溯性，因此每一次的证明信息具有历史性和可追溯性，例如，若第一节点根据第一区块的时间戳确定证明信息，则该证明信息与时间戳具有对应关系，该证明信息表示第一节点在该时间戳对应的时间是否可信的结果。第二节点作为验证者，可以验证第一节点的历史可信度。第二节点可以基于第一区块链获取第一节点的历史证明信息，验证第一节点的历史上是否可信，获得第一节点历史上是否可信的证明结果。
在一个可能的设计中，第一节点还可以向第一区块链发送该证明信息。第一节点可以是任意需要上传自身的证明信息的节点。第一节点通过向第一区块链发送该证明信息，该证明信息可以供需要验证第一节点是否可信的任意第二节点使用，这样，第一节点只需要生成一个证明信息，就可以供其余任意第二节点验证，从而使得可信计算的计算复杂度降低，运行效率较高，节省资源，更加适用于高并发低时延的应用场景。
在一个可能的设计中，第一节点还可以通过智能合约向第一区块链发送该证明信息，其中，第一节点可以向智能合约发送该证明信息，由智能合约向第一区块链发送该证明信息，该智能合约部署于第一区块链上的区块链节点。基于智能合约实现远程证明的证明信息上传第一区块链，可以适用于多种可信计算技术，提高区块链应用到远程证明时的可扩展性。
第一节点向第一区块链发送证明信息，或者第一节点通过智能合约向第一区块链发送证明信息，在此基础上，可选的，证明信息可以有以下存储方式。第一区块链包括第二区块，第二区块存储有证明信息。或者，第二区块存储有证明信息的摘要信息，其中，摘要信息用于验证所述证明信息的完整性，证明信息存储于链外存储节点，这样能够提升区块链的共识效率和存储效率。
在第一节点通过智能合约向第一区块链发送证明信息的情况下，第一节点还可以向智能合约注册身份信息，该身份信息包括用于记录证明信息的身份。身份信息也可以称为角色类型。通过注册身份信息，第一节点可以调用智能合约以向第一区块链发送第一节点的证明信息，从而实现证明信息的自动化上链。
在一个可能的设计中，第一节点向智能合约发送证明信息的触发时机包括以下几种。由智能合约触发：智能合约触发证明信息收集事件，第一节点感知该事件，第一节点在确 定智能合约触发证明信息收集事件时，向智能合约发送证明信息，以使得智能合约向第一区块链发送证明信息，通过智能合约触发证明信息的收集事件，可以节省第一节点的开销；或者，第一节点在确定智能合约触发证明信息收集事件时，第一节点向链下中继节点发送证明信息，由链下中继节点向智能合约发送证明信息，以使得智能合约向第一区块链发送证明信息当第一节点不能直接与区块链通信，或者第一节点与区块链之间不具有通信条件的时候，第一节点和区块链可以通过链下中继进行通信。
在一个可能的设计中，第一节点通过智能合约向区块链发送证明信息，可以通过以下方式实现：第一节点接收来自链下中继节点的请求信息；第一节点根据请求信息向智能合约发送证明信息，以使得智能合约向第一区块链发送证明信息；或者，第一节点根据请求信息向链下中继节点发送证明信息，由链下中继节点向智能合约发送证明信息，以使得智能合约向第一区块链发送证明信息。
在一个可能的设计中，第一节点周期性地向智能合约发送证明信息，以使得智能合约向区块链发送证明信息。可以预先根据需求设定周期，实现对设备可信度的定期度量。
在一个可能的设计中，第一节点周期性地向链下中继节点发送证明信息，由链下中继节点向智能合约发送证明信息，以使得智能合约向区块链发送证明信息。可以预先根据需求设定周期，实现对设备可信度的定期度量。
第二方面，提供一种可信证明方法，该方法可以由第二节点执行，也可以由第二节点的部件执行。以执行主体为第二节点为例，该方法可以通过以下步骤实现：第二节点基于第一区块链获取第一节点的证明信息，该证明信息包括第一区块链的信息，第二节点根据第一区块链的信息对该证明信息进行验证，获得第一节点是否可信的证明结果。由于第一区块链的信息可以作为第一区块链基于共识生成的可供多个节点使用的公共的随机数，因此第一区块链的信息可以作为多个节点进行安全度量的挑战值。第二节点作为验证者，可以基于第一区块链获取示证者的证明信息，第二节点无需与每一个示证者建立单独的“挑战-应答”流程。这样可以有助于提高可信度量的可扩展性，能够有助于提高可信证明的运行效率，满足高并发低时延的应用场景中海量设备的验证需求。
在一个可能的设计中，所述第一区块链的信息包括以下任意一种或多种信息：第一区块的时间戳、所述第一区块的哈希值、所述第一区块的上一个区块的哈希值、包含有所述第一区块的多个区块的哈希串、包含有所述第一区块的多个区块的默克尔merkle树根、或所述第一区块中的随机数、第一交易的时间戳、所述第一交易的哈希值、或包含有所述第一交易的多个交易的哈希串；其中，所述第一区块为所述第一区块链上的区块，所述第一交易为所述第一区块链上的交易。区块链作为不可篡改的平台，第一节点可以向第一区块链上传多次证明信息，每一次的证明信息或该证明信息的摘要信息被存储在第一区块链上，能够保证证明信息的内容的正确性和不可篡改性。由于证明信息是根据第一区块链的信息确定的，第一区块链的信息具有可追溯性，因此每一次的证明信息具有历史性和可追溯性，例如，若第一节点根据第一区块的时间戳确定证明信息，则该证明信息与时间戳具有对应关系，该证明信息表示第一节点在该时间戳对应的时间是否可信的结果。第二节点作为验证者，可以验证第一节点的历史可信度。第二节点可以基于第一区块链获取第一节点的历史证明信息，验证第一节点的历史上是否可信，获得第一节点历史上是否可信的证明结果。
在一个可能的设计中，所述第二节点从第一区块链获取第一节点的证明信息，可以通过以下方式实现：第二节点向智能合约发送第一节点的信息，智能合约部署于第一区块链 上的区块链节点；第二节点从智能合约接收第一节点的证明信息。通过智能合约获取第一节点的证明信息，可以适用于多种可信计算技术，提高区块链应用到远程证明时的可扩展性。
在一个可能的设计中，第二节点从第一区块链获取第一节点的证明信息，可以通过以下方式实现：第二节点确定智能合约触发证明信息验证事件；第二节点从智能合约接收第一节点的证明信息。
在一个可能的设计中，第二节点还可以向智能合约注册身份信息，该身份信息包括用于读取证明信息的身份。身份信息也可以称为角色类型。通过注册身份信息，第二节点可以调用智能合约以从第一区块链读取第一节点的证明信息。
在一个可能的设计中，第一区块链包括第二区块；第二区块存储有证明信息，或者，第二区块存储有证明信息的摘要信息，其中，摘要信息用于验证证明信息的完整性，可选的，证明信息存储于链外存储节点。通过链外存储节点存储证明信息，无需在链上存储大量的数据，可以提升存储效率。
第三方面，提供一种可信证明方法，该方法可以由第一区块链节点执行，也可以由第一区块链节点的部件执行。以执行主体为第一区块链节点为例，该方法可以通过以下步骤实现：第一区块链节点接收来自第一节点的第一交易，该第一交易包括证明信息，该证明信息是第一节点根据第一区块链的信息生成的；第一区块链节点验证所述证明信息，第一区块链节点在证明信息验证通过后，将第一交易向第一区块链的一个或多个节点进行广播。通过第一区块链节点对上链的证明信息进行审核，从而保证上链信息的可信性。
在一个可能的设计中，第一区块链节点验证所述证明信息，可以通过以下方式实现：验证引证和LOG证明，证明信息没有被篡改，还可以验证时间戳证明其证明信息的生成时间，并最终通过参考值(reference value)验证证明信息的可信性。
第四方面，提供一种通信装置。所述通信装置可以实现上述第一方面所述的方法。所述通信装置具备上述第一节点的功能。所述通信装置例如为第一节点，或为第一节点中的功能模块等。第一节点例如为示证者。或者，所述通信装置可以实现上述第二方面所述的方法。所述通信装置具备上述第二节点的功能。所述通信装置例如为第二节点，或为第二节点中的功能模块等。第二节点例如为验证者等。或者，所述通信装置可以实现上述第三方面所述的方法。所述通信装置具备上述第一区块链节点的功能。所述通信装置例如为第一区块链节点，或为第一区块链节点中的功能模块等。一种可选的实现方式中，该通信装置可以包括执行第一方面、第二方面或第三方面中所描述的方法/操作/步骤/动作所一一对应的模块，该模块可以是硬件电路，也可是软件，也可以是硬件电路结合软件实现。一种可选的实现方式中，所述通信装置包括处理单元(有时也称为处理模块)和收发单元(有时也称为收发模块)。收发单元能够实现发送功能和接收功能，在收发单元实现发送功能时，可称为发送单元(有时也称为发送模块)，在收发单元实现接收功能时，可称为接收单元(有时也称为接收模块)。发送单元和接收单元可以是同一个功能模块，该功能模块称为收发单元，该功能模块能实现发送功能和接收功能；或者，发送单元和接收单元可以是不同的功能模块，收发单元是对这些功能模块的统称。
在通信装置用于执行第一方面所描述的方法时，处理单元可以包括获取单元和确定单元，其中，获取单元，用于获取第一区块链的信息；确定单元，用于根据第一区块链的信息确定证明信息，证明信息用于第一节点被远程证明是否可信。
可选的，发送单元，用于向第一区块链发送证明信息。可选的，发送单元还可以用于向智能合约发送证明信息，智能合约部署于第一区块链上的区块链节点。
处理单元还可以包括注册单元，注册单元，用于向智能合约注册身份信息，身份信息包括用于记录证明信息的身份。
可选的，在向智能合约发送证明信息时，确定单元用于确定智能合约触发证明信息收集事件；发送单元用于向智能合约发送证明信息，以使得智能合约向第一区块链发送证明信息；或者，第一节点向链下中继节点发送证明信息，由链下中继节点向智能合约发送证明信息，以使得智能合约向第一区块链发送证明信息。
可选的，在通过智能合约向区块链发送证明信息时，接收单元用于接收来自链下中继节点的请求信息；发送单元用于根据请求信息向智能合约发送证明信息，以使得智能合约向第一区块链发送证明信息；或者，第一节点根据请求信息向链下中继节点发送证明信息，由链下中继节点向智能合约发送证明信息，以使得智能合约向第一区块链发送证明信息。
可选的，发送单元用于周期性地向智能合约发送证明信息，以使得智能合约向区块链发送证明信息；或者，用于周期性地向链下中继节点发送证明信息，由链下中继节点向智能合约发送证明信息，以使得智能合约向区块链发送证明信息。
在通信装置用于执行第二方面所描述的方法时，处理单元可以包括获取单元和验证单元，其中，获取单元，用于基于第一区块链获取第一节点的证明信息，证明信息包括第一区块链的信息；验证单元，用于根据第一区块链的信息对证明信息进行验证，获得第一节点是否可信的证明结果。
可选的，在从第一区块链获取第一节点的证明信息时，获取单元具体用于：向智能合约发送第一节点的信息，智能合约部署于第一区块链上的区块链节点；从智能合约接收第一节点的证明信息。
可选的，在从第一区块链获取第一节点的证明信息时，获取单元具体用于：确定智能合约触发证明信息验证事件；从智能合约接收第一节点的证明信息。
处理单元还可以包括注册单元，注册单元，用于向智能合约注册身份信息，身份信息包括用于读取证明信息的身份。
可选的，第一区块链包括第二区块；第二区块存储有证明信息，或者，第二区块存储有证明信息的摘要信息，其中，摘要信息用于验证证明信息的完整性，证明信息存储于链外存储节点。
在通信装置用于执行第三方面所描述的方法时，处理单元可以称为验证单元，其中，接收单元，用于接收来自第一节点的第一交易，第一交易包括证明信息，证明信息是第一节点根据第一区块链的信息生成的；验证单元，用于验证证明信息；发送单元，用于在证明信息验证通过后，将第一交易向第一区块链的一个或多个节点进行广播。
再例如，所述通信装置包括：处理器，与存储器耦合，用于执行存储器中的指令，以实现上述第一方面、第二方面或第三方面的方法。可选的，该通信装置还包括其他部件，例如，天线，输入输出模块，接口等等。这些部件可以是硬件，软件，或者软件和硬件的结合。
第五方面，提供一种计算机可读存储介质，所述计算机可读存储介质用于存储计算机程序或指令，当其被运行时，使得第一方面至第三方面中任一方面的方法被实现。
第六方面，提供一种包含指令的计算机程序产品，当其在计算机上运行时，使得第一 方面至第三方面中任一方面所述的方法被实现。
第七方面，提供一种芯片系统，该芯片系统包括逻辑电路(或理解为，该芯片系统包括处理器，处理器可包括逻辑电路等)，还可以包括输入输出接口。该输入输出接口可以用于接收消息，也可以用于发送消息。例如该芯片系统用于实现第一节点的功能时，该输入输出接口可用于获取第一区块链的信息。输入输出接口可以是相同的接口，即，同一个接口既能够实现发送功能也能够实现接收功能；或者，输入输出接口包括输入接口以及输出接口，输入接口用于实现接收功能，即，用于接收消息；输出接口用于实现发送功能，即，用于发送消息。逻辑电路可用于执行上述第一方面至第三方面中除收发功能之外的操作；逻辑电路还可用于向输入输出接口传输消息，或者从输入输出接口接收来自其他通信装置的消息。该芯片系统可用于实现上述第一方面至第三方面中任一方面的方法。该芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。
可选的，该芯片系统还可以包括存储器，存储器可用于存储指令，逻辑电路可调用存储器所存储的指令来实现相应功能。
第八方面，提供一种通信系统，该通信系统可以包括第一节点和第二节点，该第一节点可以用于执行如上述第一方面所述的方法，第二节点可以用于执行如上述第二方面所述的方法；
可选的，该通信系统还可以包括第一区块链节点，该第一区块链节点用于执行如上述第三方面所述的方法。
附图说明
图1为本申请实施例中一种远程证明系统架构示意图；
图2为本申请实施例中一种区块链网络的架构示意图；
图3为本申请实施例中可信证明方法的流程示意图；
图4为本申请实施例中另一种可信证明方法的流程示意图；
图5为本申请实施例中将证明信息写入区块链的过程示意图；
图6为本申请实施例中远程证明智能合约的结构示意图；
图7为本申请实施例中角色注册或注销示意图；
图8为本申请实施例中智能合约提供角色注册或注销流程示意图；
图9为本申请实施例中智能合约提供注册设备接口或注销设备接口示意图；
图10为本申请实施例中从智能合约中添加或删除设备流程示意图；
图11为本申请实施例中智能合约提供记录证明信息的接口示意图；
图12为本申请实施例中调用者通过智能合约的接口记录证明信息的流程示意图；
图13为本申请实施例中智能合约提供读取证明信息的接口示意图；
图14为本申请实施例中调用者通过智能合约的接口读取证明信息的流程示意图；
图15为本申请实施例中第一节点向第一区块链发送证明信息的实现过程示意图之一；
图16为本申请实施例中第一节点向第一区块链发送证明信息的实现过程示意图之二；
图17为本申请实施例中第一节点向第一区块链发送证明信息的实现过程示意图之三；
图18为本申请实施例中智能合约的结构示意图；
图19为本申请实施例中智能合约提供角色注册接口或角色注销接口示意图；
图20为本申请实施例中第一节点向第一区块链发送证明信息、以及第二节点基于第 一区块链获取证明信息的实现过程示意图；
图21为本申请实施例中一种通信装置的示意图。
具体实施方式
本申请实施例提供的可信证明方法可以应用于第四代(4th generation，4G)通信系统，例如长期演进(long term evolution，LTE)，也可以应用于第五代(5th generation，5G)通信系统，例如5G新空口(new radio，NR)系统，也可以应用于未来演进的各种通信系统，例如第六代(6th generation，6G)通信系统、或者空天海地一体化通信系统、或者接入回传一体化(integrated access and backhaul，IAB)场景。可理解的，本申请实施例描述的系统架构和应用场景是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定。
下面将结合附图，对本申请实施例进行详细描述。
本申请实施例提供一种可信证明方法、装置及系统，用以提高可信计算的远程证明的运行效率。其中，方法和装置基于同一技术构思，由于方法及装置解决问题的原理相似，因此装置与方法的实施可以相互参见，重复之处不再赘述。
在本申请的描述中，“第一”、“第二”等词汇，仅用于区分描述的目的，而不能理解为指示或暗示相对重要性，也不能理解为指示或暗示顺序。
为了更加清晰地描述本申请实施例的技术方案，下面结合附图，对本申请实施例提供的可信证明方法、装置及系统进行详细说明。
图1示出了本申请实施例适用的一种远程证明系统架构示意图。如图1所示，该远程证明系统架构可以包括示证者101、验证者102以及可信第三方(trusted third party，TTP)103。可选的，远程证明系统架构还可以包括背书者(endorder)，还可以包括参考值提供者(reference value provider)。
示证者101和验证者102的数量都可以是一个或多个。多个是指两个或两个以上。图1中以示证者101的数量为3个进行举例，以验证者102的数量为两个进行举例。示证者101是被验证、度量以及证明配置的平台。验证者102是验证平台配置的实体。示证者和验证者的名称可以是其它名称，例如示证者也可以称为证明方，验证者也可以称为验证方。可信第三方103可以是区块链。
以下对区块链进行介绍。图2示出了本申请实施例适用的一种区块链网络的架构示意图。如图2所示，该区块链网络可以包括多个区块链节点。其中，至少一个区块链节点生成一个区块后，广播该区块，其他区块链节点收到该区块后对区块进行区块验证，验证通过后更新本地的区块链。“至少一个”是指一个或者多个。需要说明的是，图2示出的区块链网络中区块链节点的数量仅为示例，应理解，区块链网络中还可以包括更多或更少的区块链节点，本申请对此不作限定。图2示出的区块链网络的架构示意图的结构也仅仅是示例，区块链节点之间还可以有其他布局结构，本申请对此不作限定。
其中，区块可用于存储数据，多个区块按照先后顺序连接形成链，被称为区块链。区块链的主要特点如下：(1)分布式：一个区块链被复制成多份，分别维护在不同的成员服务器上。(2)不可篡改：区块链中的每个区块都根据该区块存储的数据计算哈希(Hash)值，该区块链中的每个区块都记录前一个区块的Hash值和该区块本身的Hash值。若一个区块存储的内容发生改变，则该区块的Hash值发生变化，该区块的下一个区块存储的是 该区块改变前的Hash值，则下一个区块根据改变前的Hash值对该区块改变后的Hash进行验证时会验证失败。(3)可追溯：区块连接成区块链，可以按照区块链中各区块的连接顺序向前追溯整个区块链的变动历史。
可信计算的远程证明过程可分为三个阶段：完整性度量、完整性报告和完整性证明。一般来说，远程证明是一个“挑战-应答”的过程。验证者向示证者发送一个挑战消息，该挑战消息通常为一个随机数，示证者接收该挑战消息后，示证者进行可信度量，向验证者返回度量结果，例如示证者把经过身份密钥或者签名密钥签名后的证明信息发送给验证者。验证者对证明信息进行检验推理，判定示证者是否具备可信计算环境。例如，配备TPM的设备可以作为示证者，在设备启动时，TPM获取系统及其软件上的测量值，并将这些测量值安全地存储在其平台配置寄存器(platform configuration registers，PCR)中。当验证者发送请求时，TPM将报告这些值，生成可与参考值进行比较的签名摘要(即证据)。
上述通过“挑战-应答”的过程完成的远程证明是单点对单点的证明，使得可信计算的扩展性受到限制。例如，10个节点要相互验证，采用单点对单点的证明方式，共需要
Figure PCTCN2022134661-appb-000001
个成对证明。每个目标节点都需要生成9个证明信息，即使这些证据几乎相同，也需要资源来生成，从而造成资源浪费，以及运行效率低下。对于类似于6G网络中高并发、低时延的应用场景中，该方法的计算复杂度较高。
基于此，本申请实施例提供一种可信证明方法，该方法采用区块链作为可信第三方。该方法通过节点来实现，节点可以包括第一节点和第二节点，还可以包括区块链节点。本申请实施例中，“节点”执行的操作可以由设备来执行，或者由设备的部件(例如处理器、芯片、或芯片系统等)来执行，或者由集成了逻辑功能的软件模块或单元执行。节点可以是服务器、个人电脑(personal computer，PC)、通信网络中的网络设备或终端设备、或任何具有计算和存储能力的设备。节点也可以是上述列举的设备中的处理器、芯片、或一个功能模块。
示例性地，当节点是通信网络中的网络设备或终端设备时，网络设备或终端设备的概念和形态如下所述。
终端设备又可以称之为用户设备(user equipment，UE)、移动台(mobile station，MS)、移动终端(mobile terminal，MT)等，是一种向用户提供语音或数据连通性的设备，也可以是物联网设备。例如，终端设备包括具有无线连接功能的手持式设备、车载设备等。终端设备可以是：手机(mobile phone)、平板电脑、笔记本电脑、掌上电脑、移动互联网设备(mobile internet device，MID)、可穿戴设备(例如智能手表、智能手环、计步器等)，车载设备(例如，汽车、自行车、电动车、飞机、船舶、火车、高铁等)、虚拟现实(virtual reality，VR)设备、增强现实(augmented reality，AR)设备、工业控制(industrial control)中的无线终端、智能家居设备(例如，冰箱、电视、空调、电表等)、智能机器人、车间设备、无人驾驶(self driving)中的无线终端、远程手术(remote medical surgery)中的无线终端、智能电网(smart grid)中的无线终端、运输安全(transportation safety)中的无线终端、智慧城市(smart city)中的无线终端，或智慧家庭(smart home)中的无线终端、飞行设备(例如，智能机器人、热气球、无人机、飞机)等。应理解，本申请实施例中的终端设备还可以指终端设备中的芯片，还可以指具有用户设备到用户设备(UE to UE，U2U)通信功能的通信装置、单元或模块，比如车载通信装置，车载通信模块或者车载通信芯片等；本申请实施例中，终端设备还可以是车联网通信系统中的路侧单元(road side unit)， 或者是路侧单元中的通信装置或通信芯片。
网络设备可以是无线接入网中的设备，无线接入网可以包括一个或多个无线接入网设备，网络设备可以为无线接入网设备。终端设备可以通过无线的方式与无线接入网设备相连。通信系统还可以包括核心网(core network，CN)，无线接入网设备通过无线或有线方式与核心网连接。核心网设备与无线接入网设备可以是独立的不同的物理设备，也可以是将核心网设备的功能与无线接入网设备的逻辑功能集成在同一个物理设备上，还可以是一个物理设备上集成了部分核心网设备的功能和部分的无线接入网设备的功能。无线接入网设备可以是各类基站，例如演进型基站(evolved NodeB，eNodeB)、发送接收点(transmission reception point，TRP)、第五代(5th generation，5G)移动通信系统中的下一代基站(next generation NodeB，gNB)、第六代(6th generation，6G)移动通信系统中的下一代基站、或未来移动通信系统中的基站等，也可以是WiFi系统中的接入节点等设备；也可以是完成基站部分功能的模块或单元，例如，可以是集中式单元(central unit，CU)，也可以是分布式单元(distributed unit，DU)。这里的CU完成基站的无线资源控制协议和分组数据汇聚层协议(packet data convergence protocol，PDCP)的功能，还可以完成业务数据适配协议(service data adaptation protocol，SDAP)的功能；DU完成基站的无线链路控制层和介质访问控制(medium access control，MAC)层的功能，还可以完成部分物理层或全部物理层的功能，有关上述各个协议层的具体描述，可以参考第三代合作伙伴计划(3rd generation partnership project，3GPP)的相关技术规范。无线接入网设备可以是宏基站，也可以是微基站或室内站，还可以是中继节点或施主(donor)节点等。本申请的实施例对无线接入网设备所采用的具体技术和具体设备形态不做限定。在本申请的实施例中，基站的功能也可以由基站中的模块(如芯片)来执行，也可以由包含有基站功能的控制子系统来执行。这里的包含有基站功能的控制子系统可以是智能电网、工业控制、智能交通、智慧城市等上述应用场景中的控制中心。终端设备的功能也可以由终端设备中的模块(如芯片或调制解调器)来执行，也可以由包含有终端设备功能的装置来执行。
第一节点可以作为示证者，或者说第一节点是示证者负责的目标节点。第二节点可以作为验证者。第一节点和第二节点可以是区块链节点，也可以不是区块链节点。
如图3所示，本申请实施例提供的一种可信证明方法的具体流程如下所述，该方法从第一节点侧来描述。
S301.第一节点获取第一区块链的信息。
S302.第一节点根据该第一区块链的信息确定证明信息。
其中，证明信息用于第一节点被远程证明是否可信。
如图4所示，本申请实施例提供的另一种可信证明方法的具体流程如下所述，该方法从第二节点侧来描述。
S401.第二节点基于第一区块链获取第一节点的证明信息。
该证明信息包括第一区块链的信息；
S402.第二节点根据该第一区块链的信息对该证明信息进行验证，获得第一节点是否可信的证明结果。
图4实施例可以单独形成本申请需要保护的方案，也可以与图3实施例结合来形成本申请需要保护的方案，例如，在S302之后执行S401。
结合图1的系统架构，第一节点可以是示证者101，第二节点可以是验证者102，第 一区块链可以是可信第三方103。
图3实施例和图4实施例，第一区块链的信息可以是第一区块链基于共识生成的公共的随机数，因此第一区块链的信息可以作为多个节点进行安全度量的挑战值。第一节点通过引用可信的第三方生成公共可认的随机数作为挑战值，生成证明信息，该证明信息可以被任何验证者验证，实现一次度量多次验证，从而第一节点无需与每一个验证者建立单独的“挑战-应答”流程。第二节点作为验证者，可以基于第一区块链获取示证者的证明信息，第二节点无需与每一个示证者建立单独的“挑战-应答”流程。这样可以有助于提高可信度量的可扩展性，能够有助于提高远程证明的运行效率，满足高并发低时延的应用场景中海量设备的验证需求。
下面结合图3和图4实施例，对本申请实施例提供的一些可选实现方式进行说明。
第一区块链包括第一区块，第一节点在获取第一区块链的信息时，第一区块是第一区块链上最新的区块，或者说第一区块是第一区块链上高度最高的区块。第一区块链的信息可以是以下任意一种，也可以是以下任意多种的结合：第一区块的时间戳、第一区块的哈希值、第一区块的上一个区块的哈希值、包含有第一区块的多个区块的哈希串、包含有第一区块的多个区块的默克尔(merkle)树根、或第一区块中的随机数。
第一节点的该证明信息可以用于证明第一节点的软件信息、硬件信息或系统信息中的至少一项是否可信。
第一节点根据第一区块链的信息确定证明信息的过程可以认为是度量的过程，第一节点根据第一区块链的信息，对第一节点的软件信息、硬件信息或系统信息中的至少一项进行完整性度量，获得该证明信息，该证明信息可以包括以下一项或多项：该第一区块链的信息、PCR值(PCR value)、度量日志、或度量日志模板。
基于图3实施例，在S302之后，还可以包括S303。
S303.第一节点向第一区块链发送该证明信息。
第一节点向第一区块链发送该证明信息，可以理解为，第一节点向第一区块链的区块链节点发送该证明信息。本申请实施例中，当涉及区块链与其他节点的交互时，可以理解为区块链的节点与其他节点的交互。
以下给出第一节点向第一区块链的区块链节点发送该证明信息的两种可能的实现方式。
在一个可能的实现方式1中，第一节点可以根据第一区块链的信息生成交易该交易包括该证明信息，第一节点将该交易向第一区块链的区块链节点发送，该第一区块链的区块链节点可以记为第一区块链节点。第一区块链节点接收该交易后，可选的，第一区块链节点可以验证该交易，验证过程可以如下所述：验证引证和LOG证明，证明信息没有被篡改，还可以验证时间戳证明其证明信息的生成时间，并最终通过参考值(reference value)验证证明信息的可信性。在验证通过后广播该交易。第一区块链上的其他区块链节点中若存在拥有记账权的第二区块链节点，则第二区块链节点将基于该交易生成第二区块。其中，第二区块链节点可能会基于该交易与其他交易一起打包生成第二区块。第二区块链节点广播该第二区块，第一区块链上的除第二区块链节点的其他区块链节点接收该第二区块后，更新本地的区块链。可选的，第一区块链上的除第二区块链节点的其他区块链节点接收该第二区块后，可以先对第二区块进行验证，在对第二区块验证通过后，再对该交易进行验证，验证过程可以参照第一区块链节点对该交易的验证过程，在该交易验证通过后更新本 地的区块链。这样，完成证明信息上链的过程。该实现方式1可以适用于区块链节点在不需要智能合约就可以将数据添加到区块中的情况。
在另一个可能的实现方式2中，第一节点向智能合约发送该证明信息，即第一节点通过智能合约向第一区块链发送证明信息。其中，智能合约部署于第一区块链上的区块链节点，例如，可以智能合约可能会部署在第一区块链上的所有区块链节点上。第一节点调用智能合约，在调用过程中，向智能合约中写入参数，参数包括该证明信息。智能合约根据写入的参数生成交易。该交易中包括该证明信息。智能合约将该交易向第一区块链的区块链节点发送，该第一区块链的区块链节点可以记为第一区块链节点。第一区块链节点接收到交易后执行的操作，可以参考上述实现方式1中的描述，在此不予赘述。需要说明的是，本申请实施例中涉及到智能合约与其他节点的交互，可以理解为是运行智能合约的虚拟机所在的区块链节点与其他节点的交互。智能合约所执行的操作，可以理解为是运行智能合约的虚拟机所在的区块链节点所执行的操作。
以上给出了第一节点向第一区块链发送该证明信息的可能实现方式，证明信息在第一区块链中的存储方式可能有以下几种形式。证明信息可以存储与第二区块中，即第二区块中存储有证明信息的完整记录。或者，第二区块中记录有证明信息的摘要信息，该摘要信息用于验证该证明信息的完整性，该证明信息存储与链外存储节点中。该链外存储节点位于第一区块链之外的节点。该摘要信息例如可以是该证明信息的哈希值。如图5所示，以第一区块链的信息为第一区块的时间戳为例，以及以实现方式1为例，举例介绍一下证明信息上链的过程。图5示出了第一区块链中的各个区块，图5中省略号表示两个区块之间还可能有一个或多个区块。第一区块链可以包括更多或更少的区块，图5中区块的数量仅为示例。每个区块的结构包括多个字段，不同的字段用于存储不同的数据。图5示出的区块的结构以及字段的名称仅仅为举例，区块中还可以包括更多或更少的字段，本申请对此不作限定。如图5所示，例如，区块中可以包括树根字段、哈希字段、和时间戳字段。树根字段例如也称为m_root字段，或者也可以有其他名称。哈希字段也可以称为p_hash字段，或者也可以有其他名称。时间戳字段例如也称为timestamp字段，或者也可以有其他名称。第一区块的时间戳字段用于第一区块的时间戳。第一节点在需要向第一区块链上传证明信息时，获取当前最新区块的时间戳或者当前高度最高的时间戳，例如获取第一区块的时间戳。第一节点基于第一区块的时间戳生成证明信息。图5以TPM为例，第一节点生成证明信息的过程如下，利用PCR值和时间戳进行签名(sign)，生成引证(quote)。证明信息包括该引证和原始的日志(log)。根据证明信息或证明信息的哈希值生成交易，并发布至区块链。具体地，第一节点将生成的交易向第一区块链的第一区块链节点发送。最后由第二区块链节点将基于该交易生成第二区块，图5中，第二区块链节点基于多个交易打包生成第二区块，多个交易以4个交易为例进行示意，分别用TX1、TX2、TX3、TX4表示。
可以理解的是，第一区块链节点和第二区块链节点可能是同一个节点或不同的节点。第一区块和第二区块有可能是相同的区块或不同的区块。例如，在上链比较及时的情况下，第一节点的证明信息可能上传到第一区块中。
基于图4实施例，以下给出第二节点基于第一区块链获取第一节点的证明信息的可选实现方式。
若证明信息存储于第一区块链中的第二区块中，则第二节点从第二区块获取该证明信 息。第二节点根据该证明信息进行验证，得到第一节点是否可信的证明结果。
若第二区块中存储有证明信息的摘要信息，证明信息存储于链外存储节点中，第二节点从第二区块中获取该摘要信息，并根据该摘要信息验证证明信息的完整性，得到第一节点是否可信的证明结果。
第二节点可以从第二区块获取证明信息或该摘要信息，可以认为是从交易中获取证明信息或摘要信息。第二节点首先需要获取交易标识(ID)，根据交易ID向第一区块链的区块链节点获取该交易ID对应的交易。
在一个可能的实现方式3中，第二节点可以在需要对第一节点的可信度进行验证时，向第一节点发送请求，第一节点基于该请求向第二节点发送该证明信息对应的交易ID，从而第二节点获取交易ID。
在一个可能的实现方式4中，第一节点会根据计时器触发一个事件，在计时器超时后，该事件被触发，第一节点会向第二节点发送该证明信息或该摘要信息所在的交易ID。第二节点从第一节点接收该交易ID。
在一个可能的实现方式5中，第二节点可以在需要对第一节点的可信度进行验证时，向智能合约发送第一节点的信息，该第一节点的信息例如可以是第一节点的身份号(ID)。智能合约部署于第一区块链上的区块链节点，例如，可以智能合约可能会部署在第一区块链上的所有区块链节点上。第二节点调用智能合约，在调用过程中，向智能合约输入参数，参数可以包括第一节点的信息。智能合约根据输入的参数向第二节点反馈第一节点的该证明信息。第二节点根据该证明信息获得第一节点是否可信的证明结果。可选的，智能合约也可以根据输入的参数向第二节点反馈第一节点是否可信的证明结果，这种情况下由智能合约来根据证明信息验证第一节点是否可信。
基于图4实施例，第二节点在获得第一节点是否可信的证明结果后，可以向第一区块链发送该证明结果。第二节点向第一区块链发送该证明结果的实现方式，可以参考第一节点向第一区块链发送该证明信息的实现方式，即证明结果上链的过程可以参考证明信息上链的过程。
从上述对图3实施例和图4实施例的描述来看，区块链作为不可篡改的平台，第一节点可以向第一区块链上传多次证明信息，每一次的证明信息或该证明信息的摘要信息被存储在第一区块链上，能够保证证明信息的内容的正确性和不可篡改性。由于证明信息是根据第一区块链的信息确定的，第一区块链的信息具有可追溯性，因此每一次的证明信息具有历史性和可追溯性，例如，若第一节点根据第一区块的时间戳确定证明信息，则该证明信息与时间戳具有对应关系，该证明信息表示第一节点在该时间戳对应的时间是否可信的结果。第二节点作为验证者，可以验证第一节点的历史可信度。第二节点可以基于第一区块链获取第一节点的历史证明信息，验证第一节点的历史上是否可信，获得第一节点历史上是否可信的证明结果。例如，当有监管单位、需要测试的第三方、新接入网络的节点等设备需要对网络的历史可信进行度量时，只需要向区块链上获取该网络的历史证明信息，即可完成历史上的远程证明。
如上述实施例所述，第一节点向第一区块链发送第一节点的证明信息，以及第二节点基于第一区块链获取第一节点的证明信息，都可以通过智能合约来完成。下面对通过智能合约来完成的可选实现方式进行说明。
智能合约包括一些代码和数据，这些代码和数据共同构成了一个可执行文件单元，可 执行文件单元可以在区块链定义的虚拟机上运行，并存储在状态树的叶节点中。因此，智能合约是一个具有余额、代码和存储的账户。当包含足够的资金和与智能合约相关的任何输入的参数交易发送到此账户时，将触发智能合约。代码树下的数据、存储树和事务的输入参数将发送到在节点上运行的虚拟机。区块链上新的区块包括虚拟机的输出，作为对存储根和存储根哈希的更新。随着其他更改，区块链的状态根哈希也会改变。这个新的状态根哈希将是新的区块的一部分。旧数据可以链接到新树，这避免了数据的重复。
智能合约是永久性的，但它们需要维护。代码中的错误和设计缺陷需要通过代码升级和数据库迁移来纠正。在生命周期结束时，合约需要被销毁。智能合约的维护取决于部署它的特定区块链。通常，创建一个新的合约并迁移旧合约中的数据才能投入使用。由于更新后的合约将是一个全新的合约，它将有一个新的地址，并且需要发布。
要触发智能合约，需要从另一个帐户发起交易。此交易还需要包括足以支付运行智能合约操作的成本费用。有时，智能合约需要从外部世界获得一些价值，或者在外部世界上触发一些操作。
本申请实施例中，第一节点通过智能合约(可以记为第一智能合约)向第一区块链发送第一节点的证明信息，第二节点通过智能合约(可以记为第二智能合约)基于第一区块链获取第一节点的证明信息。其中，第一智能合约和第二智能合约可以是一个，也可以是两个不同的智能合约。
首先对远程证明智能合约的管理进行说明。远程证明智能合约简称智能合约，可以包括上述第一智能合约和第二智能合约。
远程证明解决方案拥有者(如企业参与者或监督证明解决方案的组织)指定部署者，由部署者部署远程证明的智能合约。图6展示了远程证明智能合约的结构。智能合约的结构可以包括多项数据(data)，该多项数据例如可以是以下几项的数据：拥有者(owner)、证据记录者(evidence writers)、证据读取者(evidence readers)、设备控制者(device controllers)、设备(devices)、和存储单元。其中，每项数据中可以包括设备对应的公钥信息和账户信息，存储单元中存储每个节点的证据，通过设备的公钥进行索引。证据即证明信息。
部署过程将作为一次交易完成，输入参数将包含智能合约代码、拥有者组和足够的费用，以支付在区块链上创建智能合约账户。交易将由远程证明解决方案部署者的私钥签名。
在构建智能合约时，将创建数据库，并使用智能合约创建交易中传递的拥有者组(owner group)来初始化拥有者表。拥有者组可用于注册编写器、阅读器和设备。
如图7所示，智能合约为拥有者组成员(member of the owner group)公开了一个注册/注销接口，以将用户添加到可以继续执行进一步操作的角色中。这些角色可以是设备控制者、证据记录者和证据读取者。该用户可以是第一节点，也可以是第二节点。
注册/注销的流程可以如图8所示。具体包括以下步骤：
S801.调用者调用角色注册/注销接口，输入调用者身份和请求的角色类型。
调用者可以是第一节点，第一节点向智能合约注册身份信息，该身份信息包括用于记录证明信息的身份。例如，第一节点调用角色注册/注销接口，输入调用者身份和请求的角色类型为证据记录者。调用者可以是第二节点，第二节点向智能合约注册身份信息，该身份信息包括用于读取证明信息的身份。例如，第二节点调用角色注册/注销接口，输入调用者身份和请求的角色类型为证据读取者。
S802.第三方组件检查用户请求的有效性。
如果调用者包含在拥有者组中，则执行S803。否则执行拒绝该调用者的注册/注销请求。
S803.在设备控制者、证据记录者和证据读取者列表中，添加/删除一个设备控制者或证据记录者或证据读取者。
具体地，若角色类型为设备控制者，则在设备控制者列表中添加/删除一个设备控制者。若角色类型为证据记录者，则在证据记录者列表中添加/删除一个证据记录者。若角色类型为证据读取者，则在证据读取者列表中添加/删除一个证据读取者。
如图9所示，远程证明智能合约提供一个注册/注销设备接口，该注册设备接口和注销设备接口可以是相同的接口，或通过两个不同的接口实现。设备控制者可以使用该注册/注销设备接口从智能合约中添加/删除设备。设备可以是第一节点，也可以是第二节点。
从智能合约中添加/删除设备流程如图10所示，具体包括以下几个步骤：
S1001.调用者调用注册/注销设备接口，输入调用者身份和设备信息。
S1002.第三方组件检查调用者有效性。
如果调用者在设备控制者列表中，则继续执行步骤S1003，否则拒绝其注册/注销设备请求。
S1003.检查设备是否在设备列表中，如果请求注册设备且设备在设备列表中，则返回设备已注册，如果请求注册设备且设备在设备列表中，则执行注册操作；如果请求注销设备且设备不在设备列表中，则返回设备不存在，如果请求注销设备且设备在设备列表中，则执行注销设备操作。
如图11所示，智能合约提供记录证明信息的接口，第一节点可以调用该接口记录第一节点的证明信息。第一节点可以是示证者、验证者或观察者(observer)。
如图12所示，调用者通过智能合约的接口记录证明信息的流程如下所述。
S1201.调用者调用智能合约的记录证明信息的接口，向智能合约输入的参数可以包括：调用者身份、设备信息、以及证明信息。
调用者可以是为第一节点。
S1202.第三方组件检查调用者的有效性。
如果调用者在证明信息记录者列表中，则继续执行步骤S1203，否则，声明调用者不被允许记录证明信息。
S1203.如果设备在设备列表中，则继续执行步骤S1204，否则，声明设备未注册。
该设备可以是第一节点。
S1204.智能合约将证明信息发送到区块链。
具体地，可以将证明信息发送到区块链的各个区块链节点。
如图13所示，智能合约提供读取证明信息的接口，第二节点可以调用该接口读取第一节点的证明信息。第二节点可以是示证者、验证者或观察者(observer)。
如图14所示，调用者通过智能合约的接口读取证明信息的流程如下所述。
S1401.调用者调用智能合约的读取证明信息的接口，向智能合约输入的参数可以包括：调用者身份和设备信息。
调用者可以是为第二节点。
S1402.第三方组件检查调用者的有效性。
如果调用者在证明信息读取者列表中，则继续执行步骤S1403，否则，声明调用者不被允许读取证明信息。
S1403.如果设备在设备列表中，则继续执行步骤S1404，否则，声明设备未注册。
该设备可以是第二节点。
S1404.智能合约从证明信息数据库向调用者返回证明信息。
第一节点向第一区块链发送证明信息，第一节点可以是任意需要上传自身的证明信息的节点。第二节点基于第一区块链获取证明信息，第二节点也可以是任意需要验证第一节点是否可信的节点。可以理解的是，可以有M个第一节点向第一区块链发送证明信息，有N个第二节点基于第一区块链获取M个第一节点中的任意一个或多个第一节点的证明信息。M和N均为正整数。例如，10个节点要相互验证，采用单点对单点的证明方式，共需要
Figure PCTCN2022134661-appb-000002
个成对证明。采用本申请提供的可信证明方法，每个节点只需要生成1个证明信息，并将证明信息发给区块链，就可以供其余9个节点验证。该方法的计算复杂度降低，运行效率较高，节省资源，适用于高并发低时延的应用场景。
第一节点向第一区块链发送证明信息，第一节点可以通过链下中继(off-chain relay)节点向第一区块链发送证明信息。第一节点与其他节点的交互，都可以通过链下中继节点完成。类似地，第二节点与其他节点的交互，也可以通过链下中继节点完成。
第一节点向第一区块链发送证明信息的触发方式可以包括以下几种。
触发方式一：由第一智能合约触发。
第一智能合约触发证明信息收集事件，第一节点感知该事件，第一节点在确定智能合约触发证明信息收集事件时，向智能合约发送证明信息。
基于触发方式一，如图15所示，提供一种应用场景下第一节点向第一区块链发送证明信息的实现过程。
设备控制器在基于第一区块链的证明系统上设置设备，例如设置第一节点。假设第一区块链提供了警报服务，警报服务本身是另一个智能合约并被设置为调用第一智能合约，以刷新设备的证明信息。一旦第一智能合约收到警报通知，就会触发证明信息收集事件，并执行远程证明。
S1501.设备控制器调用第一智能合约注册设备，并向第一区块链上的警报服务发送一个注册警报。
S1502.警报服务向第一智能合约发送更新证明信息消息。
S1503.第一智能合约触发远程证明信息收集事件。
S1503之后，可以执行S1504或者执行S1505。
S1504.如果第一节点可以轮训或注册到第一区块链，则第一节点可以触发从第一智能合约读取证明信息的事件。在S1504之后，可以执行S1506或者执行S1507。
S1505.如果第一节点不可以轮训或注册到第一区块链，则链下中继节点触发从第一智能合约读取证明信息的事件，在触发该事件之后向第一节点发送证明请求。在S1505之后，可以执行S1506或者执行S1507。
S1506.如果第一节点可以直接写入区块链，则第一节点将证明信息写入第一智能合约。
S1506之后还可以执行步骤S1508。
S1507.如果第一节点不能直接写入区块链，则第一节点将证明信息发送给链下中继节 点，链下中继节点将该证明信息上传到智能合约。
S1507之后还执行步骤S1508。
S1508.智能合约向第一区块链发送证明信息。
智能合约可以先验证第一节点的一致性，再向第一区块链发送证明信息。智能合约可以在经过共识后更新每个区块链节点。
触发方式二：由链下中继节点触发。
链下中继节点触发证明信息收集事件，链下中继节点向第一节点发送请求信息，第一节点接收来自链下中继节点的请求信息，第一节点根据请求信息向智能合约发送证明信息。
基于触发方式二，如图16所示，提供一种应用场景下第一节点向第一区块链发送证明信息的实现过程。
S1601.设备控制器调用第一智能合约注册设备，例如注册第一节点。
S1602.链下中继节点触发执行证明信息更新的计时器。
S1603.链下中继节点向第一节点发送请求信息。
该请求信息用于请求上传第一节点的证明信息。
S1603之后执行S1604或S1605。
S1604.如果第一节点可以直接写入区块链，则第一节点将证明信息写入第一智能合约。
第一节点可以直接写入区块链也可以认为第一节点可以与区块链交互。第一节点将证明信息写入第一智能合约时，第一节点创建一个事务以写入证明信息。
S1604之后可以执行步骤S1606。
S1605.如果第一节点不能直接写入区块链，则第一节点将证明信息发送给链下中继节点，链下中继节点将该证明信息上传到智能合约。
S1605之后可以执行步骤S1606。
S1606.智能合约向第一区块链发送证明信息。
触发方式三：由第一节点触发。
第一节点可以基于事件触发，也可以基于定时器周期性地触发。
第一节点基于事件或者周期性地向第一智能合约发送证明信息。
基于触发方式三，如图17所示，提供一种应用场景下第一节点向第一区块链发送证明信息的实现过程。
S1701.设备控制器调用第一智能合约注册设备，例如注册第一节点。
S1702.第一节点触发执行证明信息更新的计时器。
S1702之后执行S1703或S1704。
S1703.如果第一节点可以直接写入区块链，则第一节点将证明信息写入第一智能合约。
第一节点可以直接写入区块链也可以认为第一节点可以与区块链交互。第一节点将证明信息写入第一智能合约时，第一节点创建一个事务以写入证明信息。
S1703之后还可以执行步骤S1705。
S1704.如果第一节点不能直接写入区块链，则第一节点将证明信息发送给链下中继节点，链下中继节点将该证明信息上传到智能合约。
S1704之后还可以执行步骤S1705。
S1705.智能合约向第一区块链发送证明信息。
类似于图6所示的智能合约的结构，如图18所示，智能合约的结构可以包括几项的数据：智能合约的拥有者(或智能合约的发布者)、背书者、参考值提供者、和度量日志(verification logs)。其中，度量日志是验证的日志信息。
图18所示的智能合约的结构可以与图6所示的结构合并，共同组成一个智能合约，可以供第一节点和/或第二节点调用。
图18所示的智能合约的结构可以为第二智能合约的结构。
如图19所示，智能合约为拥有者组成员公开了一个注册/注销接口，拥有者组成员可以使用该接口将用户添加到可以继续执行进一步操作的角色中，这些角色可以是背书者、参考值提供者。
当第一节点和第二节点共用相同的智能合约时，第一节点通过智能合约向第一区块链发送证明信息，第二节点通过智能合约基于第一区块链获取该证明信息。例如，第二节点向该智能合约发送第一节点的信息，智能合约向第二节点返回证明信息或者第一节点是否可信的证明结果。
当第一节点和第二节点使用不同的智能合约时，例如第一节点使用第一智能合约向第一区块链发送证明信息，第二节点通过第二智能合约基于第一区块链获取该证明信息。则，第二节点向第二智能合约发送第一节点的信息，第二智能合约从第一智能合约获取第一节点的证明信息，第二智能合约向第二节点返回该第一节点的证明信息。
第二节点可以主动触发第一节点的证明信息的获取事件，例如，第二节点可以基于事件触发或者周期性地触发获取第一节点的证明信息。第二节点获取证明信息也可以由智能合约触发，例如智能合约触发证明信息验证事件，第二节点确定智能合约触发证明信息验证事件，则从智能合约获取第一节点的证明信息。也可以由链下中继节点触发第二节点获取证明信息，链下中继节点触发证明信息收集事件，链下中继节点向第二节点发送请求信息，第二节点根据请求信息从智能合约获取第一节点的证明信息。其中，第二节点从智能合约获取第一节点的证明信息时，第二节点可以向智能合约发送第一节点的信息，智能合约向第二节点返回第一节点的证明信息或第一节点是否可信的证明结果。
如图20所示，提供一种应用场景下第一节点向第一区块链发送证明信息、以及第二节点基于第一区块链获取证明信息的实现过程。
S2001.设备控制器在基于第一区块链的证明系统上设置设备，例如设置第一节点和/或第二节点。
其中该步骤可以包括：设备控制器向第一智能合约注册第一节点；背书者向第二智能合约注册并初始化相关背书，参考值提供者向第二智能合约注册并初始化相关参考值。
S2002.第二节点向第二智能合约请求评估目标设备(即第一节点)是否可信，或者第二节点向第二智能合约请求目标设备的证明信息。
S2003.第二智能合约向第一智能合约发送请求，用于请求第一节点的证明信息。
S2004.第一智能合约验证是否存在新鲜的证明信息在区块链上可用，如果存在，则执行S2005，否则第一智能合约触发证明信息收集事件，并在收到证明信息后执行S2005。第一智能合约触发证明信息收集事件后的流程可以参考上述触发方式一中的描述，在此不予赘述。第一智能合约在接收到证明信息后，可以先验证该证明信息并存储到第一区块链。
S2005.第一智能合约向第二智能合约发送该证明信息。
S2006.第二智能合约验证该证明信息。
例如，第二智能合约验证签名，证明其来自于一个合法的可信硬件平台(TPM)。第二智能合约也可以验证引证和LOG证明，证明信息没有被篡改，还可以验证时间戳证明其证明信息的生成时间。并最终通过参考值(reference value)验证证明信息的可信性。
S2007.第二智能合约向第二节点返回该第一节点的证明信息或者返回该第一节点是否可信的证明结果。
基于前述的方法实施例，介绍本申请实施例提供的通信装置。
本申请实施例提供一种通信装置，该通信装置例如包括处理单元和收发单元(或者，称为通信单元)，处理单元可用于实现上述方法实施例中的任一个实施例所述的第一节点的处理功能，收发单元可用于实现上述方法实施例中的任一个实施例所述的第一节点的全部收发功能或部分收发功能。或者，处理单元可用于实现上述方法实施例中的任一个实施例所述的第二节点所实现的处理功能，收发单元可用于实现上述方法实施例中的任一个实施例所述的第二节点的全部收发功能或部分收发功能。或者，处理单元可用于实现上述方法实施例中的任一个实施例所述的第一区块链节点所实现的处理功能，收发单元可用于实现上述方法实施例中的任一个实施例所述的第一区块链节点的全部收发功能或部分收发功能。
在通信装置用于执行第一节点所执行的方法时，处理单元可以包括获取单元和确定单元，可选的，处理单元还可以包括注册单元。
在通信装置用于执行第二节点所执行的方法时，处理单元可以包括获取单元和验证单元，可选的，处理单元还可以包括注册单元。
在通信装置用于执行第一区块链节点所执行的方法时，处理单元可以为验证单元。
可选的，处理单元和/或收发单元可通过虚拟模块实现，例如处理单元可通过软件功能单元或虚拟装置实现，收发单元可通过软件功能单元或虚拟装置实现。或者，处理单元和/或收发单元也可通过实体装置(例如电路系统和/或处理器等)实现。对于处理单元和收发单元通过实体装置实现的情况，下面进行介绍。
图21给出了本申请实施例提供的一种通信装置的结构示意图。所述通信装置2100可以是上述方法实施例中的任一个实施例所述的第一节点、第一节点的电路系统或能够应用于第一节点的电路系统等，用于实现上述方法实施例中对应于第一节点的方法。或者，所述通信装置2100可以是上述方法实施例中的任一个实施例所述的第二节点、第二节点的电路系统或能够应用于第二节点的电路系统等，用于实现上述方法实施例中对应于第二节点的方法。或者，所述通信装置2100可以是上述方法实施例中的任一个实施例所述的第一区块链节点、第一区块链节点的电路系统或能够应用于第一区块链节点的电路系统等，用于实现上述方法实施例中对应于第一区块链节点的方法。具体的功能可以参见上述方法实施例中的说明。其中，例如一种电路系统为芯片系统。
通信装置2100包括一个或多个处理器2101。处理器2101可以实现一定的控制功能。所述处理器2101可以是通用处理器或者专用处理器等。例如，包括：基带处理器，中央处理器等。所述基带处理器可以用于对通信协议以及通信数据进行处理。所述中央处理器可以用于对通信装置2100进行控制，执行软件程序和/或处理数据。不同的处理器可以是独立的器件，也可以是设置在一个或多个处理电路中，例如，集成在一个或多个专用集成电路上。
可选的，通信装置2100中包括一个或多个存储器2102，用以存储指令2104，所述指 令2104可在所述处理器上被运行，使得通信装置2100执行上述方法实施例中描述的方法。可选的，所述存储器2102中还可以存储有数据。所述处理器和存储器可以单独设置，也可以集成在一起。
可选的，通信装置2100可以存储指令2103(有时也可以称为代码或程序)，所述指令2103可以在所述处理器上被运行，使得所述通信装置2100执行上述实施例中描述的方法。处理器2101中可以存储数据。
例如，所述处理单元通过一个或多个处理器2101实现，或者，所述处理单元通过一个或多个处理器2101以及一个或多个存储器2102实现，或者，所述处理单元通过一个或多个处理器2101、一个或多个存储器2102、以及指令2103实现。
可选的，通信装置2100还可以包括收发器2105以及天线2106。收发器2105可以称为收发单元、收发机、收发电路、收发器，输入输出接口等，用于通过天线2106实现通信装置2100的收发功能。例如，所述收发单元通过收发器2105实现，或者，所述收发单元通过收发器2105以及天线2106实现。
可选的，通信装置2100还可以包括以下一个或多个部件：无线通信模块，音频模块，外部存储器接口，内部存储器，通用串行总线(universal serial bus，USB)接口，电源管理模块，天线，扬声器，麦克风，输入输出模块，传感器模块，马达，摄像头，或显示屏等等。可以理解，在一些实施例中，通信装置2100可以包括更多或更少部件，或者某些部件集成，或者某些部件拆分。这些部件可以是硬件，软件，或者软件和硬件的组合实现。
本申请实施例中描述的处理器2101和收发器2105可实现在集成电路(integrated circuit，IC)、模拟IC、射频集成电路(radio frequency identification，RFID)、混合信号IC、专用集成电路(application specific integrated circuit，ASIC)、印刷电路板(printed circuit board，PCB)、或电子设备等上。实现本文描述的通信装置，可以是独立设备(例如，独立的集成电路，手机等)，或者可以是较大设备中的一部分(例如，可嵌入在其他设备内的模块)，具体可以参照前述各个实施例关于第一节点、第二节点以及第一区块链节点的说明，在此不再赘述。
本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个 方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。
显然，本领域的技术人员可以对本申请实施例进行各种改动和变型而不脱离本申请实施例的精神和范围。这样，倘若本申请实施例的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (38)

  1. 一种可信证明方法，其特征在于，包括：
    第一节点获取第一区块链的信息；
    所述第一节点根据所述第一区块链的信息确定证明信息，所述证明信息用于所述第一节点被远程证明是否可信。
  2. 如权利要求1所述的方法，其特征在于，所述第一区块链的信息包括以下任意一种或多种信息：第一区块的时间戳、所述第一区块的哈希值、所述第一区块的上一个区块的哈希值、包含有所述第一区块的多个区块的哈希串、包含有所述第一区块的多个区块的默克尔merkle树根、所述第一区块中的随机数、第一交易的时间戳、所述第一交易的哈希值、或包含有所述第一交易的多个交易的哈希串；其中，所述第一区块为所述第一区块链上的区块，所述第一交易为所述第一区块链上的交易。
  3. 如权利要求1或2所述的方法，其特征在于，所述第一节点向所述第一区块链发送所述证明信息。
  4. 如权利要求1～3任一项所述的方法，其特征在于，所述第一节点向智能合约发送所述证明信息，所述智能合约部署于所述第一区块链上的区块链节点。
  5. 如权利要求3或4所述的方法，其特征在于，所述第一区块链包括第二区块；
    所述第二区块存储有所述证明信息；
    或者，所述第二区块存储有所述证明信息的摘要信息，其中，所述摘要信息用于验证所述证明信息的完整性，所述证明信息存储于链外存储节点。
  6. 如权利要求4所述的方法，其特征在于，所述方法还包括：
    所述第一节点向所述智能合约注册身份信息，所述身份信息包括用于记录证明信息的身份。
  7. 如权利要求4或6所述的方法，其特征在于，所述第一节点向智能合约发送所述证明信息，包括：
    所述第一节点确定所述智能合约触发证明信息收集事件；
    所述第一节点向所述智能合约发送所述证明信息，以使得所述智能合约向所述第一区块链发送所述证明信息；或者，所述第一节点向链下中继节点发送所述证明信息，由所述链下中继节点向所述智能合约发送所述证明信息，以使得所述智能合约向所述第一区块链发送所述证明信息。
  8. 如权利要求4或6所述的方法，其特征在于，所述第一节点通过智能合约向所述区块链发送所述证明信息，包括：
    所述第一节点接收来自链下中继节点的请求信息；
    所述第一节点根据所述请求信息向所述智能合约发送所述证明信息，以使得所述智能合约向所述第一区块链发送所述证明信息；或者，所述第一节点根据所述请求信息向链下中继节点发送所述证明信息，由所述链下中继节点向所述智能合约发送所述证明信息，以使得所述智能合约向所述第一区块链发送所述证明信息。
  9. 如权利要求4或6所述的方法，其特征在于，
    所述第一节点周期性地向所述智能合约发送所述证明信息，以使得所述智能合约向所述区块链发送所述证明信息；
    或者，所述第一节点周期性地向链下中继节点发送所述证明信息，由所述链下中继节点向所述智能合约发送所述证明信息，以使得所述智能合约向所述区块链发送所述证明信息。
  10. 一种可信证明方法，其特征在于，包括：
    第二节点基于第一区块链获取第一节点的证明信息，所述证明信息包括所述第一区块链的信息；
    所述第二节点根据所述第一区块链的信息对所述证明信息进行验证，获得所述第一节点是否可信的证明结果。
  11. 如权利要求10所述的方法，其特征在于，所述第一区块链的信息包括以下任意一种或多种信息：第一区块的时间戳、所述第一区块的哈希值、所述第一区块的上一个区块的哈希值、包含有所述第一区块的多个区块的哈希串、包含有所述第一区块的多个区块的默克尔merkle树根、所述第一区块中的随机数、第一交易的时间戳、所述第一交易的哈希值、或包含有所述第一交易的多个交易的哈希串；其中，所述第一区块为所述第一区块链上的区块，所述第一交易为所述第一区块链上的交易。
  12. 如权利要求10或11所述的方法，其特征在于，所述第二节点从第一区块链获取第一节点的证明信息，包括：
    所述第二节点向智能合约发送所述第一节点的信息，所述智能合约部署于所述第一区块链上的区块链节点；
    所述第二节点从所述智能合约接收所述第一节点的证明信息。
  13. 如权利要求10或11所述的方法，其特征在于，所述第二节点从第一区块链获取第一节点的证明信息，包括：
    所述第二节点确定所述智能合约触发证明信息验证事件；
    所述第二节点从所述智能合约接收所述第一节点的证明信息。
  14. 如权利要求12或13所述的方法，其特征在于，所述方法还包括：
    所述第二节点向所述智能合约注册身份信息，所述身份信息包括用于读取证明信息的身份。
  15. 如权利要求10～13任一项所述的方法，其特征在于，所述第一区块链包括第二区块；
    所述第二区块存储有所述证明信息；
    或者，所述第二区块存储有所述证明信息的摘要信息，其中，所述摘要信息用于验证所述证明信息的完整性，所述证明信息存储于链外存储节点。
  16. 一种可信证明方法，其特征在于，包括：
    第一区块链节点接收来自第一节点的第一交易，所述第一交易包括证明信息，所述证明信息是所述第一节点根据第一区块链的信息生成的；
    所述第一区块链节点验证所述证明信息；
    所述第一区块链节点在所述证明信息验证通过后，将所述第一交易向所述第一区块链的一个或多个节点进行广播。
  17. 一种通信装置，其特征在于，包括：
    获取单元，用于获取第一区块链的信息；
    确定单元，用于根据所述第一区块链的信息确定证明信息，所述证明信息用于所述第一节点被远程证明是否可信。
  18. 如权利要求17所述的装置，其特征在于，所述第一区块链的信息包括以下任意一种或多种信息：第一区块的时间戳、所述第一区块的哈希值、所述第一区块的上一个区块的哈希值、包含有所述第一区块的多个区块的哈希串、包含有所述第一区块的多个区块的默克尔merkle树根、所述第一区块中的随机数、第一交易的时间戳、所述第一交易的哈希值、或包含有所述第一交易的多个交易的哈希串；其中，所述第一区块为所述第一区块链上的区块，所述第一交易为所述第一区块链上的交易。
  19. 如权利要求17或18所述的装置，其特征在于，还包括：
    发送单元，用于向所述第一区块链发送所述证明信息。
  20. 如权利要求17～19任一项所述的装置，其特征在于，还包括：
    发送单元，用于向智能合约发送所述证明信息，所述智能合约部署于所述第一区块链上的区块链节点。
  21. 如权利要求19或20所述的装置，其特征在于，所述第一区块链包括第二区块；
    所述第二区块存储有所述证明信息；
    或者，所述第二区块存储有所述证明信息的摘要信息，其中，所述摘要信息用于验证所述证明信息的完整性，所述证明信息存储于链外存储节点。
  22. 如权利要求20所述的装置，其特征在于，还包括：
    注册单元，用于向所述智能合约注册身份信息，所述身份信息包括用于记录证明信息的身份。
  23. 如权利要求20或22所述的装置，其特征在于，在向智能合约发送所述证明信息时，所述确定单元用于确定所述智能合约触发证明信息收集事件；
    所述发送单元用于向所述智能合约发送所述证明信息，以使得所述智能合约向所述第一区块链发送所述证明信息；或者，所述第一节点向链下中继节点发送所述证明信息，由所述链下中继节点向所述智能合约发送所述证明信息，以使得所述智能合约向所述第一区块链发送所述证明信息。
  24. 如权利要求20或22所述的装置，其特征在于，所述装置还包括接收单元，在通过智能合约向所述区块链发送所述证明信息时，所述接收单元用于接收来自链下中继节点的请求信息；
    所述发送单元用于根据所述请求信息向所述智能合约发送所述证明信息，以使得所述智能合约向所述第一区块链发送所述证明信息；或者，所述第一节点根据所述请求信息向链下中继节点发送所述证明信息，由所述链下中继节点向所述智能合约发送所述证明信息，以使得所述智能合约向所述第一区块链发送所述证明信息。
  25. 如权利要求20或22所述的装置，其特征在于，
    所述发送单元用于周期性地向所述智能合约发送所述证明信息，以使得所述智能合约向所述区块链发送所述证明信息；
    或者，用于周期性地向链下中继节点发送所述证明信息，由所述链下中继节点向所述智能合约发送所述证明信息，以使得所述智能合约向所述区块链发送所述证明信息。
  26. 一种通信装置，其特征在于，包括：
    获取单元，用于基于第一区块链获取第一节点的证明信息，所述证明信息包括所述第一区块链的信息；
    验证单元，用于根据所述第一区块链的信息对所述证明信息进行验证，获得所述第一 节点是否可信的证明结果。
  27. 如权利要求26所述的装置，其特征在于，所述第一区块链的信息包括以下任意一种或多种信息：第一区块的时间戳、所述第一区块的哈希值、所述第一区块的上一个区块的哈希值、包含有所述第一区块的多个区块的哈希串、包含有所述第一区块的多个区块的默克尔merkle树根、所述第一区块中的随机数、第一交易的时间戳、所述第一交易的哈希值、或包含有所述第一交易的多个交易的哈希串；其中，所述第一区块为所述第一区块链上的区块，所述第一交易为所述第一区块链上的交易。
  28. 如权利要求26或27所述的装置，其特征在于，在从第一区块链获取第一节点的证明信息时，所述获取单元具体用于：
    向智能合约发送所述第一节点的信息，所述智能合约部署于所述第一区块链上的区块链节点；
    从所述智能合约接收所述第一节点的证明信息。
  29. 如权利要求26或27所述的装置，其特征在于，在从第一区块链获取第一节点的证明信息时，所述获取单元具体用于：
    确定所述智能合约触发证明信息验证事件；
    从所述智能合约接收所述第一节点的证明信息。
  30. 如权利要求28或29所述的装置，其特征在于，所述装置还包括：
    注册单元，用于向所述智能合约注册身份信息，所述身份信息包括用于读取证明信息的身份。
  31. 如权利要求26～29任一项所述的装置，其特征在于，所述第一区块链包括第二区块；
    所述第二区块存储有所述证明信息；
    或者，所述第二区块存储有所述证明信息的摘要信息，其中，所述摘要信息用于验证所述证明信息的完整性，所述证明信息存储于链外存储节点。
  32. 一种通信装置，其特征在于，包括：
    接收单元，用于接收来自第一节点的第一交易，所述第一交易包括证明信息，所述证明信息是所述第一节点根据第一区块链的信息生成的；
    验证单元，用于验证所述证明信息；
    发送单元，用于在所述证明信息验证通过后，将所述第一交易向所述第一区块链的一个或多个节点进行广播。
  33. 一种通信装置，其特征在于，包括：处理器和存储器；所述存储器用于存储一个或多个计算机程序，所述一个或多个计算机程序包括计算机执行指令，当所述通信装置运行时，所述处理器执行所述存储器存储的所述一个或多个计算机程序，以使得所述通信装置执行如权利要求1～9中任一项所述的方法，或使得所述通信装置执行如权利要求10～15中任一项所述的方法，或使得所述通信装置执行如权利要求16所述的方法。
  34. 一种芯片系统，其特征在于，所述芯片系统包括逻辑电路和输入输出接口，其中：
    所述输入输出接口用于获取第一区块链的信息，所述逻辑电路用于执行如权利要求1～9中任一项所述的方法；
    或者，所述输入输出接口用于与所述芯片系统之外的其他通信装置进行通信，所述逻辑电路用于执行如权利要求10～15中任一项所述的方法；
    或者，所述输入输出接口用于接收来自第一节点的第一交易，所述第一交易包括证明 信息，所述证明信息是所述第一节点根据第一区块链的信息生成的，所述逻辑电路用于验证所述证明信息，在所述证明信息验证通过后，将所述第一交易向所述第一区块链的一个或多个节点进行广播。
  35. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质用于存储计算机程序，当所述计算机程序在计算机上运行时，使得所述计算机执行如权利要求1～9中任一项所述的方法，或使得所述计算机执行如权利要求10～15中任一项所述的方法，或使得所述计算机执行如权利要求16所述的方法。
  36. 一种计算机程序产品，其特征在于，所述计算机程序产品包括计算机程序，当所述计算机程序在计算机上运行时，使得所述计算机执行如权利要求1～9中任一项所述的方法，或使得所述计算机执行如权利要求10～15中任一项所述的方法，或使得所述计算机执行如权利要求16所述的方法。
  37. 一种通信系统，其特征在于，包括第一节点和第二节点，所述第一节点用于执行如权利要求1～9中任一项所述的方法，所述第二节点用于执行如权利要求10～15中任一项所述的方法。
  38. 如权利要求37所述的通信系统，其特征在于，还包括第一区块链节点，所述第一区块链节点用于执行如权利要求16所述的方法。
PCT/CN2022/134661 2021-12-23 2022-11-28 一种可信证明方法及通信装置 WO2023116349A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202111593395.7 2021-12-23
CN202111593395.7A CN116388965A (zh) 2021-12-23 2021-12-23 一种可信证明方法及通信装置

Publications (1)

Publication Number Publication Date
WO2023116349A1 true WO2023116349A1 (zh) 2023-06-29

Family

ID=86901192

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/134661 WO2023116349A1 (zh) 2021-12-23 2022-11-28 一种可信证明方法及通信装置

Country Status (2)

Country Link
CN (1) CN116388965A (zh)
WO (1) WO2023116349A1 (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160275461A1 (en) * 2015-03-20 2016-09-22 Rivetz Corp. Automated attestation of device integrity using the block chain
US20210117971A1 (en) * 2020-02-03 2021-04-22 Alipay (Hangzhou) Information Technology Co., Ltd. Blockchain-based trustable guarantees
WO2021184975A1 (zh) * 2020-03-18 2021-09-23 支付宝(杭州)信息技术有限公司 链上数据的链下隐私计算方法及装置
CN113708935A (zh) * 2021-08-23 2021-11-26 北京航空航天大学 基于区块链和puf的物联网设备统一认证方法及系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160275461A1 (en) * 2015-03-20 2016-09-22 Rivetz Corp. Automated attestation of device integrity using the block chain
US20210117971A1 (en) * 2020-02-03 2021-04-22 Alipay (Hangzhou) Information Technology Co., Ltd. Blockchain-based trustable guarantees
WO2021184975A1 (zh) * 2020-03-18 2021-09-23 支付宝(杭州)信息技术有限公司 链上数据的链下隐私计算方法及装置
CN113708935A (zh) * 2021-08-23 2021-11-26 北京航空航天大学 基于区块链和puf的物联网设备统一认证方法及系统

Also Published As

Publication number Publication date
CN116388965A (zh) 2023-07-04

Similar Documents

Publication Publication Date Title
US11425111B2 (en) Attestation token sharing in edge computing environments
CN109218079B (zh) 一种区块链网络、部署方法及存储介质
CN110489485B (zh) 联盟区块链网络及在其中存储产品数据的方法和存储介质
US11139991B2 (en) Decentralized edge computing transactions with fine-grained time coordination
CN109191124B (zh) 区块链网络、部署方法及存储介质
EP3522088B1 (en) Securing blockchain access through a gateway
CN102823195B (zh) 利用由虚拟机进行的软件测试远程维护电子网络中的客户端系统的系统和方法
WO2019199405A1 (en) Edge computing service global validation
US20230316273A1 (en) Data processing method and apparatus, computer device, and storage medium
CN111869187A (zh) Iot服务层系统与分布式分类账系统之间的互通
CN112714158B (zh) 事务处理方法、中继网络、跨链网关、系统、介质和设备
US20190370504A1 (en) Digital value tokens created and securely transferred by proof of electrical power generation
EP3598333B1 (en) Electronic device update management
CN113837760B (zh) 数据处理方法、装置、计算机设备以及存储介质
US20230370285A1 (en) Block-chain-based data processing method, computer device, computer-readable storage medium
Gerrits et al. A true decentralized implementation based on iot and blockchain: a vehicle accident use case
Wang Sok: Applying blockchain technology in industrial internet of things
US20230259930A1 (en) Cross-chain transaction processing method and apparatus, electronic device, and storage medium
WO2023116349A1 (zh) 一种可信证明方法及通信装置
CN116761148A (zh) 一种基于区块链的v2x身份管理系统及认证方法
US20220284328A1 (en) Method and apparatus for autonomous decision of network node
CN116760632B (zh) 数据处理方法、装置、设备及可读存储介质
CN114401064B (zh) 信任管理时间同步方法、系统、计算机设备、介质及终端
Killijian et al. Data backup for mobile nodes: a cooperative middleware and an experimentation platform
WO2024001507A1 (zh) 数据处理方法、系统、装置、设备及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22909664

Country of ref document: EP

Kind code of ref document: A1