Remote attestation method, device and system

Abstract

The embodiment of the invention provides a remote attestation method, device and system, and relates to the technical field of remote attestation. The method comprises the following steps that: a relying party sends information of seed anchor verifiers and the number of required verifiers, and a trust manager determines a plurality of recommended verifiers; and after receiving the information of the plurality of recommended verifiers from the trust manager, the relying party obtains a certification result of each recommended verifier to the verified person from each recommended verifier according to the information of the plurality of recommended verifiers. And finally, the relying party performs credibility evaluation on the verified person according to the certification result of each recommended verifier on the verified person. The trust standard of the relying party can be explained by configuring the seed anchor verifier, and the verifier corresponding to the relying party can be flexibly determined in combination with the recommended verifier, so that a flexible personalized trust scoring system is provided.

Description

Technical Field

[0001] This application relates to the technical field, and in particular to a remote verification method, apparatus and system. Background Technology

[0002] With the continuous development of information technology, information security has become a major concern, giving rise to remote attestation. The remote attestation architecture consists of entities such as the attester, verifier, relying party, endorser, reference value provider, verifier owner, and relying party owner. The typical remote attestation process involves the endorser, reference value provider, and verifier owner sending evidence and a reference value (also known as the golden ratio) to the verifier. The verifier evaluates the attester's credibility based on the golden ratio. After evaluation, the verifier sends the attestation result to the relying party as proof of the attester's credibility.

[0003] However, in remote proof processes, when multiple verifiers send their respective proofs to the relying party, there may be untrusted verifiers, or inconsistent proofs from multiple different verifiers verifying the same entity. Currently, in cases of inconsistent proofs, only a single, unique proof result is typically obtained, failing to provide a flexible and personalized trust verification system. Therefore, how to handle inconsistent proofs from different verifiers in remote proofs is a pressing issue that needs to be addressed. Summary of the Invention

[0004] This application provides a remote proof method, apparatus, and system to address the technical problem of how the relying party should process proof results from different verifiers in order to enable the remote proof system to have a flexible and personalized trust scoring system.

[0005] The technical solution is as follows:

[0006] In a first aspect, embodiments of this application provide a remote proof method, the method comprising: a dependent party sending information about a seed anchor validator and the required number of validators, wherein the seed anchor validator and the required number of validators are used to determine multiple recommended validators; the dependent party receiving information about multiple recommended validators from a trust manager; the dependent party obtaining the proof results of each recommended validator for the verified entity from the multiple recommended validators based on the information of the multiple recommended validators; and the dependent party performing a trustworthiness assessment of the verified entity based on the proof results of each recommended validator for the verified entity.

[0007] In this application, a trust manager is introduced. Based on the seed anchor validator information sent by the dependent party and the required number of validators, the trust manager determines multiple recommended validators. After receiving information from the multiple recommended validators from the trust manager, the dependent party obtains the proof results of each recommended validator for the verified party based on this information. Finally, the dependent party performs a trustworthiness assessment of the verified party based on the proof results of each recommended validator. The dependent party's trust criteria can be specified by configuring the seed anchor validator, and combined with the recommended validators, the appropriate validators for the dependent party can be flexibly determined, thus providing a flexible and personalized trust scoring system.

[0008] In one possible implementation, the dependent party obtains the proof results for the verified object from multiple recommended validators, including: the dependent party obtaining evidence from the verified object; the dependent party sending evidence to multiple recommended validators, the evidence being used to determine the proof results; and the dependent party receiving the proof results from each recommended validator. Because the dependent party obtains the proof results from the recommended validators, it can resist the obfuscation of the proof results by malicious validators.

[0009] In one possible implementation, the dependent party's trustworthiness assessment of the verified entity based on the proofs provided by each recommended validator includes: the dependent party determining a summary result based on the proofs provided by each recommended validator; and the dependent party performing a trustworthiness assessment of the verified entity based on the summary result. Since the summary result comes from multiple recommended validators, the dependent party can handle inconsistent proof results from different validators.

[0010] In one possible implementation, the dependent party determines the aggregate result based on the proof results of each recommending verifier for the verifier, including: the dependent party determines the proof result with the highest frequency as the aggregate result, which can satisfy the majority vote principle.

[0011] In one possible implementation, the dependent party determines the aggregated result based on the proofs provided by each recommended validator for the verified entity. This involves: mapping each proof result to a trust value; determining an average trust value for the multiple proof results based on their respective trust values; and finally, determining the aggregated result based on the average trust value, where the aggregated result's trust value is similar to the average trust value. This can make the proof results more accurate.

[0012] Secondly, embodiments of this application provide a remote proof method, the method comprising: a trust manager receiving information about a seed anchor validator and the required number of validators from a dependent party, wherein the seed anchor validator and the required number of validators are used to determine multiple recommended validators; the trust manager determining multiple recommended validators from one or more validator groups based on the seed anchor validator information and the required number of validators, wherein the multiple recommended validators belong to the same validator group, and the multiple validators in the same validator group provide similar proof results for the same verifiable entity; and the trust manager sending information about the multiple recommended validators.

[0013] In one possible implementation, if the number of validators in a validator group is less than the required number of validators, the recommended number of validators is equal to the number of validators in the validator group.

[0014] In one possible implementation, the method provided in this application embodiment further includes: a trust manager sending first request information to a validator group database, the first request information being used to request one or more validator groups. The trust manager receives one or more validator groups from the validator group database.

[0015] The verifier group database can be located within or outside the trust manager; this is not limited in this embodiment.

[0016] In one possible implementation, the trust manager sends a second request to the trust graph database. This second request requests trust graph information, which includes each validator's proof result for the verified entity and a first norm. The first norm is a scalar or vector representing the trustworthiness of the verified entity in the proof result. The trust manager calculates the similarity between each validator's proof result for the verified entity based on the trust graph information. Based on the similarity between each validator's proof result for the verified entity, the trust manager groups validators with similar proof results into one or more validator groups.

[0017] The trust graph database can be located within or outside the trust manager; this is not limited in the embodiments of this application.

[0018] Optionally, the trust manager can also determine the similarity of each pair of validators directly based on the validators themselves, without relying on trust graph information for calculation. For example, the trust manager can determine the similarity of each pair of validators based on the validators' own attributes, including but not limited to the validator's binary code hash value, the validator's affiliated organization, the validator's identifier address, and the validator's domain name range.

[0019] In one possible implementation, before the trust manager sends the second request information to the trust graph database, the method provided in this application embodiment further includes: the trust manager obtaining the proof result of each validator for the verified entity. The trust manager converts the scalar or vector representing the trustworthiness of the verified entity in each validator's proof result into a first norm. The trust manager sends trust graph information to the trust graph database, the trust graph information including the proof result of each validator for the verified entity and the first norm.

[0020] In one possible implementation, the first norm is in the range of 0 to 1. The first norm is set to [0, 1] to standardize the result, but other ranges can also be used for the first norm, which are not limited in this embodiment.

[0021] In one possible implementation, the method provided in this application further includes: a trust manager sending the proof results of each verifier to the proof result database. The proof result database is used to store the proof results of all verifiers to the proof result database.

[0022] The proof result database can be located either within or outside the trust manager; this is not limited in this embodiment.

[0023] Thirdly, embodiments of this application provide a remote verification device that can implement the methods in the first aspect or any possible implementation of the first aspect, and thus also achieve the beneficial effects of the first aspect or any possible implementation of the first aspect. This device can be a dependent party, or an apparatus that supports the dependent party in implementing the methods in the first aspect or any possible implementation of the first aspect, such as a chip applied in the dependent party. This device can implement the above methods through software, hardware, or by hardware executing corresponding software.

[0024] In one example, the remote verification device is a dependent party or a chip or chip system applied in the dependent party. The device includes: a communication module and a processing module, wherein the communication module is used to receive or send information / data, and the processing module is used to process the information / data.

[0025] In one possible implementation, a communication module is used to send information about the seed anchor validator and the required number of validators. The seed anchor validator and the required number of validators are used to determine multiple recommended validators. The communication module is also used to receive information about the multiple recommended validators from the trust manager. A processing module is used to obtain the proof results of each recommended validator for the verified entity from the multiple recommended validators based on the information from the multiple recommended validators. The processing module is also used to perform a trustworthiness assessment of the verified entity based on the proof results of each recommended validator for the verified entity.

[0026] In one possible implementation, the communication module is further configured to obtain evidence from the verifier. The communication module is also configured to send evidence to multiple recommending verifiers, the evidence being used to determine the proof result. The communication module is further configured to receive the proof result from each recommending verifier.

[0027] In one possible implementation, the processing module is further configured to determine a summary result based on the proof results of each recommending verifier for the verifier. The processing module is also configured to perform a credibility assessment of the verifier based on the summary result.

[0028] In one possible implementation, the processing module is further configured to identify the most frequent proof as the summary result. Alternatively, the processing module is further configured to map each proof result to a trust value. The processing module is further configured to determine the average trust value of multiple proof results based on the trust values ​​of each proof result. The processing module is further configured to determine the summary result based on the average trust value, wherein the trust value of the summary result is similar to the average trust value.

[0029] Fourthly, embodiments of this application provide a remote verification device that can implement the methods in the second aspect or any possible implementation of the second aspect, and therefore can also achieve the beneficial effects of the second aspect or any possible implementation of the second aspect. This device can be a trust manager, or an apparatus that supports the trust manager in implementing the methods in the second aspect or any possible implementation of the second aspect, such as a chip applied in the trust manager. This device can implement the above methods through software, hardware, or by hardware executing corresponding software.

[0030] In one example, the remote authentication device is a trust manager or a chip or chip system applied in a trust manager. The device includes a communication module and a processing module, wherein the communication module is used to receive or send information / data, and the processing module is used to process the information / data.

[0031] In one possible implementation, a communication module is used to receive information about the seed anchor validator and the required number of validators from the dependent party. The seed anchor validator and the required number of validators are used to determine multiple recommended validators. A processing module is further used to determine multiple recommended validators from one or more validator groups based on the seed anchor validator information and the required number of validators. The multiple recommended validators belong to the same validator group, and the multiple validators in the same validator group provide similar proof results for the same validated entity. The communication module is also used to send information about the multiple recommended validators.

[0032] In one possible implementation, if the number of validators in a validator group is less than the required number of validators, the recommended number of validators is equal to the number of validators in the validator group.

[0033] In one possible implementation, the communication module is configured to send a first request message to the validator group database, the first request message being used to request one or more validator groups. The communication module is also configured to receive one or more validator groups from the validator group database.

[0034] In one possible implementation, a communication module is used to send a second request message to a trust graph database. This second request message requests trust graph information, which includes the proof results of each validator for the verified entity and a first norm, where the first norm is a scalar or vector representing the credibility level of the verified entity in the proof results. The processing module is further used to calculate the similarity between the proof results of each validator for the verified entity based on the trust graph information. The processing module is also used to group validators with similar proof results into one or more validator groups based on the similarity between their proof results for the verified entity.

[0035] In one possible implementation, the communication module is further configured to acquire the proof result of each verifier for the verifiable entity. The processing module is further configured to convert the scalar or vector representing the credibility of the verifiable entity in each verifier's proof result into a first norm. The communication module is further configured to send trust graph information to a trust graph database, the trust graph information including the proof result of each verifier for the verifiable entity and the first norm.

[0036] In one possible implementation, the first norm ranges from 0 to 1.

[0037] In one possible implementation, the communication module is also used to send the proof results of each verifier to the proof result database.

[0038] Fifthly, embodiments of this application provide a computer-readable storage medium storing a computer program or instructions that, when executed on a computer, cause the computer to perform a remote proof method as described in any of the possible implementations of the first aspect.

[0039] Sixthly, embodiments of this application provide a computer-readable storage medium storing a computer program or instructions that, when executed on a computer, cause the computer to perform a remote proof method as described in any of the possible implementations of the second aspect.

[0040] In a seventh aspect, embodiments of this application provide a computer program product including instructions that, when executed on a computer, cause the computer to perform a remote proof method described in the first aspect or various possible implementations of the first aspect.

[0041] Eighthly, embodiments of this application provide a computer program product including instructions that, when executed on a computer, cause the computer to perform a remote proof method described in the second aspect or various possible implementations of the second aspect.

[0042] In a ninth aspect, embodiments of this application provide a communication device for implementing various methods in various possible designs of either the first or second aspect described above. The communication device may be the aforementioned terminal device, or a device including the aforementioned dependent party, or a component applied to the dependent party (e.g., a chip). Alternatively, the communication device may be the aforementioned trust manager, or a device including the aforementioned trust manager, or the communication device may be a component applied to the trust manager (e.g., a chip). The communication device includes modules and units corresponding to the aforementioned methods; these modules and units may be implemented in hardware, software, or by hardware executing corresponding software implementations. The hardware or software includes one or more modules or units corresponding to the aforementioned functions. It should be understood that the communication device described in the ninth aspect may further include: a bus and a memory, the memory being used to store code and data. Optionally, at least one processor communication interface and the memory are coupled to each other.

[0043] In a tenth aspect, embodiments of this application provide a communication device comprising: at least one processor. The at least one processor is coupled to a memory, and when the communication device is in operation, the processor executes computer execution instructions or programs stored in the memory to cause the communication device to perform any of the various possible designs of the first aspect or any other aspect thereof. For example, the communication device may be a dependent party or a chip applied in the dependent party.

[0044] Eleventhly, embodiments of this application provide a communication device comprising: at least one processor. The at least one processor is coupled to a memory, and when the communication device is in operation, the processor executes computer execution instructions or programs stored in the memory to cause the communication device to perform any of the methods described in the second aspect or any of the various possible designs of the second aspect. For example, the communication device may be a trust manager, or a chip applied in a trust manager.

[0045] It should be understood that the memory described in any of the tenth to eleventh aspects can also be replaced by a storage medium, and the embodiments of this application do not limit this.

[0046] In one possible implementation, the memory described in any one of aspects ten to eleven can be a memory inside the communication device. Of course, the memory can also be located outside the communication device, but at least one processor can still execute computer execution instructions or programs stored in the memory.

[0047] In a twelfth aspect, embodiments of this application provide a communication device comprising one or more modules for implementing the method of any one of the first and second aspects described above. The one or more modules may correspond to the various steps in the method of any one of the first and second aspects described above.

[0048] In a thirteenth aspect, embodiments of this application provide a chip system including a processor. The processor reads and executes a computer program stored in a memory to perform the methods in the first aspect and any possible implementation thereof. Optionally, the chip system may be a single chip or a chip module composed of multiple chips. Optionally, the chip system further includes a memory, which is connected to the processor via circuitry or wires. Further optionally, the chip system includes a communication interface. The communication interface is used to communicate with other modules outside the chip.

[0049] In a fourteenth aspect, embodiments of this application provide a chip system including a processor. The processor reads and executes a computer program stored in a memory to perform the methods of the second aspect and any possible implementation thereof. Optionally, the chip system may be a single chip or a chip module composed of multiple chips. Optionally, the chip system further includes a memory, which is connected to the processor via circuitry or wiring. Further optionally, the chip system includes a communication interface. The communication interface is used to communicate with other modules outside the chip.

[0050] In a fifteenth aspect, embodiments of this application provide a remote proof system. This communication system includes a trust manager, a dependent party, a verifier, and a verified party. The dependent party executes methods from the first aspect and any possible implementation thereof, while the trust manager executes methods from the second aspect and any possible implementation thereof. The verifier provides proof results to the verified party based on the evidence provided.

[0051] Any of the devices, computer storage media, computer program products, chips, or communication systems provided above are used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects of the corresponding solutions in the corresponding methods provided above, and will not be repeated here. Attached Figure Description

[0052] Figure 1 This is a schematic diagram of a remote verification system architecture provided in an embodiment of this application;

[0053] Figure 2 This is a schematic diagram of a P2P remote verification based on the Internet Engineering Task Force draft of remote verification of network devices based on a trusted platform module, provided in an embodiment of this application.

[0054] Figure 3 This is a schematic diagram illustrating remote authentication via a publish / subscribe agent based on a draft reference interaction model for remote authentication and trust services, provided in an embodiment of this application.

[0055] Figure 4 This is a schematic diagram of a gold measurement distribution stored in multiple overlay diagrams, provided in an embodiment of this application;

[0056] Figure 5 Figure (a) in this application illustrates a method for handling inconsistent proof results from different verifiers, provided in an embodiment of this application.

[0057] Figure 5 Figure (b) in this application illustrates another method for handling inconsistent proof results from different verifiers, provided in an embodiment of this application.

[0058] Figure 6 This is a schematic diagram of a jury-based verification method provided in an embodiment of this application;

[0059] Figure 7 This is a schematic diagram of a remote verification system provided in an embodiment of this application;

[0060] Figure 8 This is a flowchart illustrating a remote verification processing method provided in an embodiment of this application;

[0061] Figure 9This is a schematic diagram of a validator group maintenance process provided in an embodiment of this application;

[0062] Figure 10 This is a schematic diagram of a verification process provided in an embodiment of this application;

[0063] Figure 11 This is a network slicing diagram illustrating a router's trusted path selection method provided in an embodiment of this application;

[0064] Figure 12 This is a schematic diagram of a network slice based on BGP route advertisement security filtering provided in an embodiment of this application;

[0065] Figure 13 This is a schematic diagram of a communication device provided in an embodiment of this application;

[0066] Figure 14 This is a schematic diagram of the hardware structure of a communication device provided in an embodiment of this application;

[0067] Figure 15 This is a schematic diagram of a chip structure provided in an embodiment of this application. Detailed Implementation

[0068] To facilitate a clear description of the technical solutions in the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish identical or similar items with essentially the same function and role. For example, "first verifier" and "second verifier" are only used to distinguish different verifiers and do not limit their order. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and the terms "first" and "second" do not necessarily imply that they are different.

[0069] It should be noted that, in this application, the terms "exemplary" or "for example" are used to indicate that something is being described as an example, illustration, or illustration. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0070] In this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0071] like Figure 1 As shown, the system architecture of remote attestation typically includes: attester (or attestee), verifier, relying party, endorser, reference value provider, verifier owner, and relying party owner.

[0072] The presenter is responsible for collecting evidence and sending it to the verifier. The presenter generates a report containing information about its security status and sends it to the verifier to prove its credibility.

[0073] Verifier: The verifier is the executor used to verify the evidence of the network element. It can complete the verification and return the proof result, or sign and send a credential. There are no restrictions on the specific verification method. It can be verified locally based on the pre-configured reference value, or it can be verified on a remote server.

[0074] Dependent party: A network element that relies on the proof result to make decisions for the verified entity. For example, a dependent party could be a service program that integrates remote proof verification functionality.

[0075] Endorsers: These are entities used to create endorsements that can be used to help assess the credibility of a certifier.

[0076] Reference value provider: This is a role performed by an entity (such as a manufacturer) that provides reference values ​​that can help the verifier evaluate evidence to determine whether the presenter has documented an acceptable known claim.

[0077] Validator Owner: A role performed by an entity (e.g., an administrator) authorized to configure the evaluation strategy for evidence in the validator.

[0078] Dependant Owner: A role performed by an entity (e.g., an administrator) authorized to configure the evaluation strategy for the proof results in the dependent party.

[0079] As an example, in remote attestation, the credibility of the presenter needs to be assessed by the verifier, who is typically considered trustworthy. The verifier's assessment of the presenter's credibility is based on comparing evidence collected at the verifier with a reference value. This reference value, also known as the golden ratio, is a state of hardware, firmware, software, etc., input by the endorser, the reference value provider, and the verifier owner. After comparing the evidence with the reference value, an attestation result is obtained. The verifier then sends this result to the dependent party as proof of the presenter's credibility.

[0080] In remote proofs, verifiers typically use a single centralized method for verification, but this can lead to single points of failure and poor scalability. To address this, a peer-to-peer (P2P) approach was introduced, such as... Figure 2 The diagram shows a P2P remote attestation diagram based on the Internet Engineering Task Force (IETF) draft (drat-ietf-rats-tpm-based-network-device-attest) for remote attestation of network devices based on a Trusted Platform Module. This allows a pair of devices to take turns acting as the presenter and verifier, enabling devices to verify each other's trustworthiness. However, both devices must have the functions required by the verifier.

[0081] Another publish / subscribe pattern allows presenters, verifiers, and dependents to be decoupled through interaction via a broker or publish / sub server, such as... Figure 3The diagram illustrates remote proof via a publish / subscribe broker based on the IETF draft (ietf-rats-reference-interaction-models) for remote proof and trust services. In this model, the verifier subscribes to the intermediary for verifiable evidence. When the presenter publishes evidence on the intermediary, the verifier receives the push notification, verifies the evidence, and publishes the proof result back to the intermediary. Prior to this, the dependent party registers the required proof result on the intermediary, which then pushes the received proof result to the dependent party. However, when untrusted verifiers exist, or when proof results from different verifiers are inconsistent, the publish / subscribe model cannot guarantee that the dependent party receives consistently reliable proof results.

[0082] In related technologies, such as Figure 4 As shown, the verifier uses the golden ratio metric stored in multiple overlays as the verification standard to provide redundancy. When the golden ratio metrics in several overlays are inconsistent, a majority vote is used to elect the measurement; that is, the golden ratio metric with the most votes is recognized as the system's unique standard. Thus, when a device is verified to be inconsistent with this standard, it is considered infected and isolated from the system. Besides requiring the maintenance of multiple overlays, this method also relies on a system-wide unique standard for verification trustworthiness, failing to provide personalized trustworthiness criteria.

[0083] In other related technologies, two methods are used to obtain globally consistent proof results when the proof results from different verifiers are inconsistent. One method is as follows: Figure 5 As shown in Figure (a), the method includes:

[0084] Step 501a: All verifier nodes in the remote verification system verify all network nodes.

[0085] Step 502a: All validator nodes in the remote proof system exchange proof results, so that each validator node has a comprehensive result after the exchange.

[0086] Step 503a: Based on the comprehensive results, all verifier nodes in the remote proof system generate the final remote proof result.

[0087] Step 504a: Distribute the final remote proof result to all nodes in the remote proof system.

[0088] Another method is as follows Figure 5 As shown in Figure (b), the method includes:

[0089] Step 501b: All verifier nodes in the remote verification system verify all network nodes.

[0090] Step 502b: A witness node in the remote proof system collects the proof results of all verifier nodes, enabling the witness node to determine a comprehensive result.

[0091] Step 503b: Based on the comprehensive results, the witness node generates the final remote proof result.

[0092] Step 504b: The witness node distributes the final remote proof result to all verifier nodes in the remote proof system.

[0093] The drawbacks of both methods are that all validators and all network nodes need to participate, resulting in high system overhead. Furthermore, the final proof result is also unique within the system and cannot provide proof results tailored to the needs of dependent parties.

[0094] In other related technologies, such as Figure 6 The diagram illustrates a jury-based verification method. When a device (e.g., device D1) cannot verify another device (e.g., device D...),... m+3 When device D1 announces device D to the network... m+3 The device is considered suspicious. Several other devices (such as device D2, device D6, device D) are also considered suspicious. m+1 They were randomly elected as jurors and independently reviewed device D. m+3 The process involves verification and consensus-building, after which the jury publicly releases the consensus result online. However, this method also ensures that the consensus result is globally unique, without providing personalized jury recommendations for the initiating device D1.

[0095] As can be seen from the above description of related technologies, the current approach to handling inconsistent proof results from different verifiers (also known as heterogeneous verifiers) in remote proof is mostly to unify the proof results of each verifier, making the final proof result unique to the system. However, this method cannot meet the different needs of the dependent parties for the proof result. Therefore, how to handle inconsistent proof results from different verifiers is an urgent problem to be solved.

[0096] To address the aforementioned issues, this application proposes a remote proof method, apparatus, and system. It introduces a trust manager, which aggregates verifiers with similar proof results into a group, ensuring that verifiers within the same group produce similar results. A recommended verifier list is generated based on a seed anchor verifier list sent by the dependent party. The dependent party then verifies the proofs obtained from the verifiers in the recommended list, using the resulting proofs as the device's trust assessment. By configuring seed anchor verifiers, the dependent party implicitly specifies its trust criteria for verifiers, and the recommended verifiers are determined based on these seed anchor verifiers. This provides a flexible, personalized trust assessment system for inconsistent proof results from different verifiers, while also reducing the impact of malicious verifiers on the proof results.

[0097] like Figure 7 As shown, Figure 7 This is a schematic diagram of a remote authentication system provided in an embodiment of this application. The system includes: a dependent party 100, a verifier 200, multiple verifiers (e.g., verifier 301, verifier 302, ..., verifier 30K, ..., verifier 30N), and a trust manager 400. N is an integer greater than or equal to 2. For example, N can be equal to 3, 4, 5, 6, 7, etc.

[0098] The dependent party 100 is used to receive the proof results from the verifier, which typically includes the integrity and security status of the verifier 200.

[0099] The verifier 200 is the party whose integrity and security need to be verified. The verifier 200 may refer to different entities, such as an end platform, a software component, or a service.

[0100] Verifiers initiate verification requests and generate verification reports upon receiving evidence to measure the trustworthiness of devices. For example, a verifier can be a node device in a trusted path verification process on a 5G / 6G network. Each node device must have the capability to measure the trustworthiness of other node devices.

[0101] Trust Manager 400 is used to select a validator that meets the requirements of Dependent Party 100 from multiple validators, and to provide the validator that meets the requirements of Dependent Party 100 as a recommended validator.

[0102] The message names between nodes or the names of parameters in the messages in the embodiments of this application are just examples. In specific implementations, other names may also be used. This application does not specifically limit this.

[0103] The various embodiments of this application can be referenced or learned from each other. For example, the same or similar steps, method embodiments, communication system embodiments and device embodiments can be referenced from each other without limitation.

[0104] In this application embodiment, the specific structure of the executing entity of the remote proof method is not particularly limited, as long as it can communicate according to the remote proof method of this application embodiment by running a program that records the code of the remote proof method of this application embodiment. For example, the remote proof method provided in this application embodiment may be a functional module in the dependent party or trust manager that can call and execute the program, or it may be a communication device applied in the dependent party or trust manager, such as a chip, chip system, integrated circuit, etc. These chips, chip systems, and integrated circuits may be located inside the dependent party or trust manager, or they may be independent of the dependent party or trust manager, and this application embodiment does not impose any restrictions.

[0105] like Figure 8 As shown, Figure 8 This is a flowchart illustrating a remote proof method provided in an embodiment of this application. The method includes:

[0106] Step 801: The dependent party sends the seed anchor validator information and the required number of validators. Correspondingly, the trust manager receives the seed anchor validator information and the required number of validators from the dependent party. The seed anchor validator and the required number of validators are used to determine multiple recommended validators.

[0107] In this context, the seed anchor validator represents the validator trusted by the dependent party. Furthermore, the criteria for judging the validator trusted by the dependent party can also be determined based on this trusted validator. It can be understood that the seed anchor validator can be an entity that validates the validated entity, providing a basis for selecting subsequent validators.

[0108] It is understood that the number of seed anchor validators can be one or more, and this application embodiment does not limit the number.

[0109] For example, if verifier V1 acts as the seed anchor verifier, and verifier V1's proof result for the verified entity is A, then proof result A is the criterion for judging verifiers trusted by the dependent party. For instance, if a verifier's proof result falls within a preset range based on A, then that verifier meets the condition trusted by the dependent party.

[0110] As an example, the seed anchor validator information is used to indicate the identifier and number of seed anchor validators. For example, the seed anchor validator information can be a list of seed anchor validators or other forms, which are not limited in this embodiment.

[0111] For example, the dependency direction trust manager sends a seed anchor validator list {V1}, indicating that the seed anchor validator is the validator identified as V1, and the quantity is 1.

[0112] The recommended validator is selected by the trust manager from multiple validators based on the information of the seed anchor validator and the required number of validators. The similarity between the validators must meet certain requirements; for example, each validator's proof results for the validated entity should be similar.

[0113] For example, multiple validators include validator V1, validator V2, and validator V3. Validators V1, V2, and V3 have the same degree of similarity in their proofs of the same validated entity. The seed anchor validator information is the seed anchor validator list {V1}. If the required number of validators is 2, then the recommended validators are {V1, V2}, or {V1, V3}.

[0114] Step 802: The trust manager determines multiple recommended validators from one or more validator groups based on the seed anchor validator information and the required number of validators. These multiple recommended validators belong to the same validator group within the one or more validator groups.

[0115] Multiple validators belonging to the same validator group may produce the same or similar verification results for evidence provided by the same verifier.

[0116] As an example, the trust manager determines the recommended list of validators based on the seed anchor validator list, the required number of validators, and the validator group list.

[0117] For example, recommending validators can be determined based on the similarity between the seed anchor validators in the seed anchor validator list and the validator group.

[0118] For example, the seed anchor validator list is {V5}, the required number of validators is 2, and the validator group list is {G1, G2, G3}. Seed anchor validator V5 in the seed anchor validator list provides a proof A1 for the validated object. Validator group G1 includes validators V1, V2, and V3, and the proof result for validator group G1 is A0; validator group G2 includes validators V4, V5, and V6, and the proof result for validator group G2 is A1; validator group G3 includes validators V7, V8, and V9, and the proof result for validator group G3 is A2. Since the proof result for validator group G2 is the same as that for seed anchor validator V1, it is recommended to select validators from validator group G2. Because the required number of validators is 2, it is recommended that the validators be two from validator group G2, for example, validators V5 and validator V6.

[0119] For example, recommended validators can be determined based on the number of seed anchor validators in the seed anchor validator list and the number of validators in the validator group.

[0120] For example, the seed anchor validator list is {V1, V2}, including two seed anchor validators: seed anchor validator V1 and seed anchor validator V2. Validator group G1 includes validator V1, validator V2, and validator V3, and validator group G2 includes validator V1, validator V4, and validator V5. Since validator group G1 has two seed anchor validators and validator group G2 has one seed anchor validator, the validators included in validator group G1 can be used as recommended validators.

[0121] For example, the seed anchor validator list is {V1, V2}, including two seed anchor validators: seed anchor validator V1 and seed anchor validator V2. Validator group G1 includes validator V1, validator V2, and validator V3, and validator group G2 includes validator V1 and validator V2. Since two-thirds of the validators in validator group G1 are the same as the seed anchor validators, and 100% of the validators in validator group G2 are the same as the seed anchor validators, the validators included in validator group G2 can be used as recommended validators.

[0122] In one possible embodiment of this application, if the number of validators in the validator group is less than the required number of validators, the recommended number of validators is the same as the number of validators in the validator group.

[0123] For example, if the required number of validators is 3, and the validator group GN matches the seed anchor validator list, and the validator group GN includes 2 validators: validator V1 and validator V2, then the recommended validators are validator V1 and validator V2, that is, 2 recommended validators.

[0124] Step 803: The trust manager sends information about multiple recommended validators to the dependent party. Correspondingly, the dependent party receives information about multiple recommended validators from the trust manager.

[0125] For example, the trust manager can send information about multiple recommended validators to the dependent party in the form of a list. That is, the trust manager sends a list of recommended validators, which includes information about multiple validators. The dependent party receives the list of recommended validators from the trust manager.

[0126] Step 804: The dependent party obtains the proof results of each recommended verifier for the verified entity from the multiple recommended verifiers based on the information of the multiple recommended verifiers.

[0127] In one possible embodiment of this application, the dependent party obtains evidence from the verified party and then sends the obtained evidence to multiple recommended verifiers. Each recommended verifier determines the proof result based on the evidence and sends the proof result to the dependent party.

[0128] Step 805: The dependent party performs a credibility assessment of the verified entity based on the proof results of each recommended verifier.

[0129] In this embodiment, a trust manager is introduced. Based on the seed anchor validator information sent by the dependent party and the required number of validators, the trust manager determines multiple recommended validators. After receiving information from the multiple recommended validators from the trust manager, the dependent party obtains the proof results of each recommended validator for the verified party based on this information. Finally, the dependent party performs a trustworthiness assessment of the verified party based on the proof results of each recommended validator. By configuring the seed anchor validator to specify the dependent party's trust criteria, and combining this with the recommended validators, the corresponding validators for the dependent party can be flexibly determined, thus providing a flexible and personalized trust scoring system.

[0130] In one possible embodiment of this application, step 806 can be implemented in the following way:

[0131] The relying party determines the aggregated result based on the proof results of each recommended verifier for the verifier, and then conducts a credibility assessment of the verifier based on the aggregated result.

[0132] For example, if the proof result of the verifier V1 for the verifier is A0, the proof result of the verifier V2 for the verifier is A1, and the proof result of the verifier V3 for the verifier is A2, the dependent party determines the summary result based on the proof results A0, A1, and A2.

[0133] As an example, the method for determining the summary result can be based on the majority vote principle, specifically including the dependent party using the proof result with the highest frequency as the summary result.

[0134] For example, the proof result of the recommended verifier V1 for the verified object is A0, the proof result of the recommended verifier V2 for the verified object is A1, and the proof result of the recommended verifier V3 for the verified object is A0. Among them, the recommended verifiers with the proof result A0 are in the majority. Therefore, the proof result A0 is taken as the summary result.

[0135] As another example, the summary result can also be determined by mapping trust values. Specifically, the dependent party maps each proof result to a trust value, determines the average trust value of multiple proof results, and then determines the summary result based on the proof result corresponding to the average trust value.

[0136] For example, the proof result of the recommended verifier V1 for the verified object is A0, with a mapped trust value of 1; the proof result of the recommended verifier V2 for the verified object is A1, with a mapped trust value of 2; the proof result of the recommended verifier V3 for the verified object is A1, with a mapped trust value of 2; and the proof result of the recommended verifier V4 for the verified object is A2, with a mapped trust value of 4. It can be determined that the average trust value corresponding to the proof results of recommended verifiers V1, V2, V3, and V4 is 2.25. Since the average trust value is closest to the trust value of 2 mapped to proof result A1, proof result A1 is used as the summary result.

[0137] In this embodiment, a trust manager is introduced. Based on the seed anchor validator information sent by the dependent party and the required number of validators, the trust manager determines multiple recommended validators. After receiving information from the multiple recommended validators from the trust manager, the dependent party obtains the proof results of each recommended validator for the verified party based on this information. Finally, the dependent party performs a trustworthiness assessment of the verified party based on the proof results of each recommended validator. By configuring the seed anchor validator to specify the dependent party's trust criteria, and combining this with the recommended validators, the corresponding validators for the dependent party can be flexibly determined, thus providing a flexible and personalized trust scoring system.

[0138] In one possible embodiment of this application, the method provided in this application embodiment may further include: a trust manager determining one or more groups of validators.

[0139] For example, one or more validator groups can be represented as a list of validator groups or in other forms, which are not limited in this embodiment.

[0140] For example, the trust manager determines a list of validator groups {G1, G2, G3, ..., GN}, which includes N validator groups.

[0141] As an example, the trust manager directly receives one or more validator groups. For instance, one or more validator groups may be sent to the trust manager by other devices.

[0142] As another example, the trust manager retrieves one or more validator groups from the validator group database. These validator groups can be obtained through direct configuration, such as by other devices sending one or more validator groups to the database. Alternatively, the validator groups in the database can be updated based on the trust graph database and the proof result database.

[0143] In this case, multiple validators in the same validator group provide similar proofs for the same validated entity.

[0144] For example, verifier group G1 includes verifiers V1, V2, and V3, and the three verifiers' proofs of the verified entity are similar. Here, similarity means that the error between the proofs does not exceed a set threshold.

[0145] It is understandable that each validator group corresponds to one proof result, and different validator groups correspond to different proof results. For example, the proof result of each validator in validator group G1 for the verified object is A, and the proof result of each validator in validator group G2 for the verified object is B. Of course, the proof results corresponding to different validator groups can also be the same, which is not limited in this embodiment.

[0146] As an example, the trust manager can identify one or more validator groups in the following way:

[0147] Step 1a: The trust manager sends a first request message to the validator group database. Correspondingly, the validator database receives the first request message from the trust manager. This first request message is used to request one or more validator groups.

[0148] Step 2a: The trust manager receives one or more validator groups from the validator group database. Accordingly, the validator group database, in response to the first request information, sends one or more validator groups to the trust manager.

[0149] The verifier group database can be within the trust manager or independent of the trust manager; this application embodiment does not impose any limitations on it.

[0150] As another example, the trust manager can determine one or more validator groups in the following way:

[0151] Step 1b: The trust manager receives the proof results of each validator for the verified entity.

[0152] In one specific implementation, the trust manager acts as a dependent party, sending a proof request to the verifier. The verifier responds to the proof request by sending evidence to the trust manager. The trust manager then sends evidence to the verifier, requesting a proof result. The verifier generates a proof result based on the evidence.

[0153] Step 2b: The trust manager transforms the scalar or vector representing the trustworthiness of the verified entity in each verifier's proof result into the first norm.

[0154] The level of trustworthiness can be represented by trust level or trust vector.

[0155] For example, verifier Vx verifies verifier A. i The proof result is AR, including the validator identifier V. X The identifier A of the verified entity i Credibility, etc., are denoted as AR(V) X A i (trustlevel / trustvector, ...). A scalar or vector representing the level of trust is transformed into the first norm, trustscore. xi Then the trust graph information corresponding to verifier Vx is (V X A i trustscore xi ).

[0156] In one possible embodiment, the first norm ranges from 0 to 1.

[0157] It is worth noting that the first norm is set to [0, 1] to standardize the result, and it does not necessarily have to be [0, 1]. It can also be other values, which are not limited in this embodiment.

[0158] Step 3b: The trust manager sends trust graph information to the trust graph database. Correspondingly, the trust graph database receives the trust graph information from the trust manager.

[0159] Each trust graph information includes the proof result of the corresponding verifier to the verifier and the first norm, where the first norm is a scalar or vector representing the credibility of the verifier in the proof result.

[0160] The trust graph database can be stored in the trust manager or on other devices. The trust manager can be obtained from other devices, which is not limited in this embodiment.

[0161] Step 4b: The dependent party sends a second request message to the trust graph database. Correspondingly, the trust graph database receives the second request message from the dependent party. This second request message is used to request multiple trust graph information.

[0162] After the dependent party obtains the trust graph information of all validators to the validated party (e.g., all validated parties in the sampled database), the dependent party performs the following steps:

[0163] Step 5b: The dependent party calculates the similarity between each validator's proof results and the validated's proof results based on the trust graph information.

[0164] As an example, the trust manager calculates the similarity between pairs of verifiers based on information from multiple trust graphs.

[0165] Step 6b: The dependent party groups verifiers with similar proof results into one or more verifier groups based on the similarity of each verifier's proof results for the verifier.

[0166] Optionally, after step 1b above, the method provided in this application embodiment further includes: the trust manager sending the proof results of each verifier to the proof result database.

[0167] The proof result database can be stored within the trust manager or outside the trust manager; this is not limited in this embodiment.

[0168] In one possible implementation of this application, the remote proof system includes two data flows: a validator group maintenance process and a verification process. The validator group maintenance process groups all validators and stores them in a validator group database; the verification process allows the relying party to perform a trustworthiness assessment of the verified entity based on the proof results from multiple recommended validators. The validator group maintenance process and the verification process are described in detail below:

[0169] like Figure 9 As shown, Figure 9 A schematic diagram of a validator group maintenance process provided in this application embodiment includes:

[0170] Step 901: The trust manager sends a message to the verified party A.i Send a verification request. Accordingly, the verifier A... i Receive a verification request from the trust manager.

[0171] Step 902, Verified Subject A i The collected claims are signed and converted into evidence, which is then sent to the trust manager. Correspondingly, the trust manager receives evidence from the verified party A. i Evidence.

[0172] Step 903: The trust manager will forward the received evidence to the verifier V. x Request proof of the result. Accordingly, verifier V... x Receive evidence from the trust manager.

[0173] For example, the trust manager sends evidence to validator V1, sends evidence to validator V2, and so on.

[0174] Step 904, Verifier V x Based on the received evidence, a proof result is generated and sent to the trust manager. Correspondingly, the trust manager receives proof results from the verifier V. x The proof results.

[0175] For example, validator V1 generates proof result AR 1i (V1, A) i (trustlevel / trustvector, ...), verifier V2 generates proof result AR 2i (V2, A) i , trustlevel / trustvector, ...), and so on.

[0176] Step 905: The trust manager sends the proof result data from verifier V to the proof result database. x The proof results. Correspondingly, the proof result database receives the verifier V from the trust manager. x The proof results.

[0177] Step 906: The trust manager will come from validator V. x The proof result indicates that the verified party A i The scalar or vector of trustworthiness is transformed into a norm between [0 and 1] trustscore xi .

[0178] Step 907: The trust manager adds / updates edges (V) to the trust graph database. x A i trustscore xi ).

[0179] It is worth noting that steps 901 through 907 are repeated cyclically. All validators compare the validator A in the sampling list. i After generating the proof results and trusting the graph database, and after the proof result database is updated, the following actions are performed:

[0180] Step 908: The Trust Manager sends a request for trust graph information to the Trust Graph Database. Correspondingly, the Trust Graph Database receives the request for trust graph information from the Trust Manager.

[0181] Step 909: The trust graph database sends the full trust graph information to the trust manager. Correspondingly, the trust manager receives the full trust graph information from the trust graph database.

[0182] Step 910: The trust manager calculates V for each pair of validators based on the trust graph information. i V j The degree of similarity between them S ij The matrix S = {S} is formed. ij For each pair of validators V i V j}

[0183] Optionally, the trust manager can also determine the similarity of each pair of verifiers directly based on the verifiers, without relying on trust graph information for calculation.

[0184] For example, the trust manager determines the similarity of each pair of validators based on the validator's own attributes, including but not limited to the validator's binary code hash value, the validator's affiliated organization, the validator's identification address, and the validator's domain range.

[0185] Step 911: The trust manager aggregates all verifiers into several groups G1, G2, G3, ... based on their similarity.

[0186] Optionally, the trust manager can also be configured to directly aggregate all validators into several groups G1, G2, G3, ..., without relying on similarity.

[0187] Step 912: The Trust Manager sends validator group information {G1, G2, G3, ...} to the validator group database. Correspondingly, the validator group database receives the validator group information {G1, G2, G3, ...} from the Trust Manager.

[0188] The verification process is carried out according to the updated verifier group database of the above embodiments, such as... Figure 10 As shown, Figure 10 A verification process diagram provided for an embodiment of this application includes:

[0189] Step 1001: The dependency direction trust manager sends the seed anchor validator list L. in = (V1, V2, ...), and the required number of validators n. Accordingly, the trust manager receives a list L of seed anchor validators from the dependent parties. in = (V1, V2, ...), and the required number of validators n.

[0190] Step 1002: The Trust Manager sends a request message to the Validator Group Database. Correspondingly, the Validator Group Database receives the request message from the Trust Manager. The request message requests the latest list of validator groups.

[0191] Step 1003: The validator group database sends the updated validator group list {G1, G2, ..., GK} to the trust manager. Correspondingly, the trust manager receives the validator group list {G1, G2, ..., GK} from the validator group database.

[0192] Step 1004: The trust manager uses the seed anchor validator list L in Given the required number of validators n and the validator group list {G1, G2, ..., GK}, determine the recommended validator list L. out .

[0193] Step 1005: The trust manager sends a list of recommended verifiers L to the dependent party. out Accordingly, the dependent party receives a list L of recommended validators from the trust manager. out .

[0194] Step 1006, Dependency direction verified by A i Send an authentication request. Correspondingly, the entity being authenticated receives the authentication request from the dependent party.

[0195] Step 1007, Verified Subject A i The collected claims are signed and converted into evidence, which is then sent to the relying party. Accordingly, the relying party receives evidence from the party whose claim is being verified. i Evidence.

[0196] Step 1008, Dependency Direction Verifier V x Send evidence. Accordingly, verifier V x Receive evidence from the dependent party.

[0197] For example, the dependency sends evidence to validator V1, the dependency sends evidence to validator V2, and so on.

[0198] Step 1009, Verifier V x Generate authentication results (AR) corresponding to the evidence. xiAnd send the authentication result AR to the dependent party. xi Correspondingly, the dependent party receives data from the validator V. x AR certification results xi .

[0199] For example, verifier V1 sends the authentication result AR to the dependent party. 1i The verifier V2 sends the authentication result AR to the dependent party. 2i And so on.

[0200] Step 1010: The dependent party, based on data from verifier V... x The authentication results are summarized, and the verified party A is verified. i Conduct a credibility assessment.

[0201] The specific implementation method for the summary is described in the above embodiments and will not be repeated here.

[0202] The above embodiments describe the verifier group maintenance process and verification process based on the trust manager. In one possible implementation of this application, it is specifically applied to the trusted path selection of routers in the network, such as the trusted path selection based on source routing in the 5G / 6G network bearer network.

[0203] like Figure 11 As shown, Figure 11 A schematic diagram of network slicing for trusted path selection by routers is shown, including multiple routers (Router A to Router I), a trust manager, and multiple validators.

[0204] In a trusted path from one router to another, each router needs to be verified as trusted. The following describes the process of selecting a trusted path, using the example of routers A and H needing to choose a trusted path to router G:

[0205] Step 1: Verifier Group Maintenance Process.

[0206] In this embodiment, multiple verifiers, including verifiers V1 to V7, provide different proof results for the routers. The proof results for the routers are categorized into three levels: highly trustworthy, trustworthy, and untrustworthy, as shown in Table 1. Table 1 shows the trust levels of verifiers V1 to V7 for each router. Taking routers B, C, and D as examples of the verified entities, and considering the verifiers' trust levels for the routers, the verifiers are divided into two groups: Verifier Group 1 {V1, V2, V3, V4} and Verifier Group 2 {V5, V6, V7}.

[0207] Step 2: Verification process.

[0208] Router A, acting as a dependency, sends a seed anchor validator list {V1} and the required number of validators (3) to the trust manager. Based on validator group 1 and validator group 2, the trust manager sends a recommended validator list {V1, V2, V3} to router A. Router H, acting as a dependency, sends a seed anchor validator list {V5} and the required number of validators (2) to the trust manager. Based on validator group 1 and validator group 2, the trust manager sends a recommended validator list {V5, V6} to router A.

[0209] According to Table 1, the trusted routers observed by router A are: router A, router B, router C, router E, and router G; the trusted routers observed by router H are: router H, router B, router D, router F, and router G.

[0210] Based on trusted routers, the trusted path selected from router A to router G is ABCEG; the reliable path selected from router H to router G is HBDFG.

[0211] In one possible implementation, a centralized path computation approach can be used. In this approach, end-to-end path computation is performed by a centralized network element, such as a path computation element (PCE) or a software-defined network (SDN) controller. In this case, the centralized network element acts as a dependent party, and its implementation is similar to that of a router acting as a dependent party, which will not be elaborated upon here.

[0212] In another possible implementation of this application, it can also be applied to the Border Gateway Protocol (BGP). For example, in a 5G / 6G network bearer network, each node can use BGP to publish route advertisements, thereby achieving automatic configuration of network routes. BGP-based route advertisement security filtering can avoid route advertisements from malicious nodes and prevent data from flowing to untrusted nodes. The difference from the trusted path selection of routers in the above embodiments is that in the trusted path selection of routers, one router acts as the dependent party, and other routers act as the verified parties (e.g., router A and router H act as dependent parties); while in BGP-based route advertisement security filtering, any router acts as the dependent party, and its neighboring routers act as the verified parties.

[0213] like Figure 12 As shown, Figure 12 A schematic diagram of a network slicing method based on BGP route advertisement security filtering is shown, which includes multiple routers (Router A to Router I), a trust manager, and multiple authenticators.

[0214] In this system, each router acts as a dependent, while its neighboring routers act as verifiers. Each router determines whether to accept BGP routing advertisements from its neighbors based on their verification results.

[0215] Step 1: Verifier Group Maintenance Process.

[0216] The specific implementation method is the same as the above embodiments, and will not be repeated here.

[0217] Step 2: Verification process.

[0218] Each router, acting as a dependency, sends a seed anchor validator list and the required number of validators to the trust manager. The trust manager then sends a recommended validator list to the routers based on validator group 1 and validator group 2.

[0219] For example, router E sends the seed anchor validator list {V3} and the required number of validators, 3, to the trust manager. Based on validator group 1 and validator group 2, the trust manager sends a recommended validator list {V2, V3, V4} to the router. Referring to Table 1, routers C and G are highly trusted routers, while router I is either a trusted router or an untrusted router, not a highly trusted router. Therefore, router E filters the announcements from router I.

[0220] For example, router G sends a seed anchor validator list {V2} and the required number of validators, 3, to the trust manager. Based on validator group 1 and validator group 2, the trust manager sends a recommended validator list to router G as {V1, V2, V3}. Referring to Table 1, router E is a highly trusted router, while router F is either a trusted router or an untrusted router, not a highly trusted router. Therefore, router G filters the announcements from router F.

[0221] In specific implementation methods, such as Figure 12As shown, router A is configured with a seed anchor validator list {V1} and a required number of validators of 3, with a recommended validator list of {V1, V2, V3}; router B is configured with a seed anchor validator list {V5} and a required number of validators of 3, with a recommended validator list of {V5, V6, V7}; router C is configured with a seed anchor validator list {V2} and a required number of validators of 3, with a recommended validator list of {V1, V2, V4}; router D is configured with a seed anchor validator list {V5, V6} and a recommended validator list of {V5, V6}. The required number of validators is 3, and the matched recommended validator list is {V5, V6, V7}; the seed anchor validator list configured for router F is {V7}, and the required number of validators is 3, resulting in a matched recommended validator list of {V5, V6, V7}; the seed anchor validator list configured for router H is {V5, V6}, and the required number of validators is 3, resulting in a matched recommended validator list of {V5, V6, V7}; the seed anchor validator list configured for router I is {V1, V2, V5}, and the required number of validators is 3, resulting in a matched recommended validator list of {V2, V3, V4}. Specific announcement security filtering for each router is not detailed here.

[0222] The above primarily describes the solutions of this application's embodiments from the perspective of interaction between various nodes. It is understood that each node, such as the dependent party or trust manager, includes corresponding structures and / or software modules to execute the aforementioned functions in order to achieve them. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0223] This application embodiment can divide functional units according to the aforementioned method example dependencies and trust manager. For example, each function can be divided into its own functional unit, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software functional unit. It should be noted that the unit division in this application embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0224] The above combination Figures 8 to 10The methods described in the embodiments of this application have been explained. The communication apparatus provided in the embodiments of this application for executing the above methods is described below. Those skilled in the art will understand that the methods and apparatus can be combined with and referenced in each other, and the communication apparatus provided in the embodiments of this application can execute the steps performed by the terminal device and network device in the above analysis method.

[0225] When using integrated units Figure 13 The communication device involved in the above embodiments is shown. The communication device 130 may include a communication module 1301 and a processing module 1302.

[0226] In an alternative implementation, the communication device 130 may further include a storage module 1303 for storing the program code and data of the communication device.

[0227] On one hand, the communication device 130 is a dependent party, or a chip applied in the dependent party. In this case, the communication module 1301 is used to support communication between the communication device and external network elements (e.g., a trust manager). For example, the communication module 1301 is used to perform the signal transmission and reception operations of the dependent party in the above method embodiments. The processing module 1302 is used to perform the signal processing operations of the dependent party in the above method embodiments.

[0228] In one example, the communication module 1301 is used to perform the above embodiments. Figure 8 The sending action performed by the dependent party in step 801. Communication module 1301 is used to perform the above embodiments. Figure 8 The receiving action performed by the dependent party in step 804.

[0229] In one possible embodiment, the processing module 1302 is used to execute the embodiments described above. Figure 8 The processing action performed by the dependent party in step 806.

[0230] On the other hand, the communication device 130 is a trust manager, or a chip applied in a trust manager. In this case, the communication module 1301 is used to support communication between the communication device and external network elements (e.g., dependent parties). For example, the communication module 1301 is used to perform the signal transmission and reception operations of the trust manager in the above method embodiment. The processing module 1302 is used to perform the signal processing operations of the trust manager in the above method embodiment.

[0231] In one example, the communication module 1301 is used to perform the above embodiments. Figure 8 The receiving action in step 801 is performed by the trust manager. Communication module 1301 is used to perform the above-described embodiments. Figure 8 The sending action is performed by the trust manager in step 804.

[0232] In one possible embodiment, the processing module 1302 is used to execute the embodiments described above. Figure 8 The processing actions performed by the trust manager in steps 802 and 803.

[0233] The processing module 1302 can be a processor or controller, such as a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field-programmable gate array, or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a digital signal processor and a microprocessor, etc. The communication module can be a transceiver, transceiver circuitry, or communication interface, etc. The storage module can be a memory.

[0234] When the processing module 1302 is a processor 1401 or a processor 1405, the communication module 1301 is a transceiver 1403, and the storage module 1303 is a memory 1402, the communication device involved in this application can be... Figure 14 The communication device shown.

[0235] Figure 14 This illustration shows a schematic diagram of the hardware structure of a communication device according to an embodiment of this application. The hardware structures of the terminal device and network device in this embodiment can be referenced as follows: Figure 14 The structure shown is described. The communication device includes a processor 1401, a communication line 1404, and at least one transceiver. Figure 14 (The illustration is merely exemplary, using transceiver 1403 as an example only).

[0236] Processor 1401 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of programs according to the present application.

[0237] Communication line 1404 may include a path for transmitting information between the aforementioned components.

[0238] Transceiver 1403 is a device that uses any transceiver-like device to communicate with other devices or communication networks, such as Ethernet, radio access network (RAN), wireless local area networks (WLAN), etc.

[0239] Optionally, the communication device may also include a memory 1402.

[0240] Memory 1402 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. Memory 1402 may exist independently and be connected to processor 1401 via communication line 1404. Memory 1402 may also be integrated with processor 1401.

[0241] The memory 1402 stores computer execution instructions for implementing the scheme of this application, and its execution is controlled by the processor 1401. The processor 1401 executes the computer execution instructions stored in the memory 1402, thereby implementing the communication method provided in the following embodiments of this application.

[0242] Optionally, the computer execution instructions in the embodiments of this application may also be referred to as application code, and the embodiments of this application do not specifically limit this.

[0243] CPU1.

[0244] In a specific implementation, as one example, the communication device may include multiple processors, for example... Figure 14 Processors 1401 and 1402 are mentioned. Each of these processors can be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. A processor here can refer to one or more devices, circuits, and / or processing cores used to process data (e.g., computer program instructions).

[0245] This application also provides a communication device, which can be a terminal device or a chip. This communication device can be used to execute the above-described method embodiments.

[0246] Figure 15This is a schematic diagram of the structure of chip 150 provided in an embodiment of this application. Chip 150 includes one or more (including two) processors 1510 and communication interfaces 1530.

[0247] Optionally, the chip 150 also includes a memory 1540, which may include read-only memory and random access memory, and provides operation instructions and data to the processor 1510. A portion of the memory 1540 may also include non-volatile random access memory (NVRAM).

[0248] In some implementations, memory 1540 stores elements such as execution modules or data structures, or subsets thereof, or extended sets thereof.

[0249] In this embodiment of the application, the corresponding operation is executed by calling the operation instructions stored in the memory 1540 (the operation instructions can be stored in the operating system).

[0250] One possible implementation is that the terminal and network devices have similar structures, and different devices can use different chips to achieve their respective functions.

[0251] The processor 1510 controls the processing operations of any terminal or network device. The processor 1510 can also be referred to as a central processing unit (CPU).

[0252] Memory 1540 may include read-only memory and random access memory, and provides instructions and data to processor 1510. A portion of memory 1540 may also include NVRAM. For example, in an application, memory 1540, communication interface 1530, and memory 1540 are coupled together via bus system 1520, which, in addition to a data bus, may also include a power bus, control bus, and status signal bus, etc. However, for clarity, in... Figure 15 The general labeled all buses as Bus System 1520.

[0253] The methods disclosed in the embodiments of this application can be applied to or implemented by the processor 1510. The processor 1510 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in the processor 1510 or by instructions in the form of software. The processor 1510 may be a general-purpose processor, a digital signal processor (DSP), an ASIC, a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or can be executed by a combination of hardware and software modules in the decoding processor. The software modules may be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 1540. Processor 1510 reads the information in memory 1540 and, in conjunction with its hardware, completes the steps of the above method.

[0254] In one possible implementation, the communication interface 1530 is used to perform... Figure 8 The steps for receiving and sending data by the dependent party in the illustrated embodiment are shown. Processor 1510 is used to execute... Figure 9 The steps of the trust manager's processing in the illustrated embodiment.

[0255] In one possible implementation, the communication interface 1530 is used to perform... Figure 9 The steps for receiving and sending data by the dependent party in the illustrated embodiment are shown. Processor 1510 is used to execute... Figure 10 The steps of the trust manager's processing in the illustrated embodiment.

[0256] In one possible implementation, the communication interface 1530 is used to perform... Figure 10 The steps for receiving and sending data by the dependent party in the illustrated embodiment are shown. Processor 1510 is used to execute... Figure 11 The steps of the trust manager's processing in the illustrated embodiment.

[0257] The communication module described above can be a communication interface of the device, used to receive signals from other devices. For example, when the device is implemented as a chip, the communication module is the communication interface used by the chip to receive or send signals from other chips or devices.

[0258] On the one hand, a computer-readable storage medium is provided, in which instructions are stored, which, when executed, implement as follows: Figures 8-10 Functions performed by the dependent party.

[0259] On the one hand, a computer program product including instructions is provided, wherein the computer program product includes instructions that, when executed, implement such... Figures 8-10 The functions performed by the trust manager.

[0260] On one hand, a chip is provided for use in a dependent party. The chip includes at least one processor and a communication interface, the communication interface and the at least one processor being coupled together. The processor is used to execute instructions to achieve, for example... Figures 8-10 Functions performed by the dependent party.

[0261] On one hand, a chip is provided for use in a dependent party. The chip includes at least one processor and a communication interface, the communication interface and the at least one processor being coupled together. The processor is used to execute instructions to achieve, for example... Figures 8-10 The functions performed by the trust manager.

[0262] This application provides a remote authentication processing system, which includes: a dependent party, a trust manager, a verifiable party, and multiple verifiers. The dependent party is used to perform actions such as... Figure 8 ~ and Figure 10 The functions performed by the dependent party are executed by the trust manager. Figures 8-10 The functions performed by the trust manager.

[0263] The explanations and beneficial effects of the relevant content in any of the communication devices provided above can be found in the corresponding method embodiments provided above, and will not be repeated here.

[0264] In this embodiment, the terminal device or network device includes a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on top of the operating system layer. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and memory (also called main memory). The operating system can be any one or more computer operating systems that implement business processing through processes, such as Linux, Unix, Android, iOS, or Windows. The application layer includes applications such as browsers, address books, word processing software, and instant messaging software. Furthermore, this embodiment does not specifically limit the specific structure of the execution entity of the method provided in this embodiment, as long as it can communicate according to the method provided in this embodiment by running a program that records the code of the method provided in this embodiment. For example, the execution entity of the method provided in this embodiment can be a terminal device or a network device, or a functional module in the terminal device or network device that can call and execute a program.

[0265] Furthermore, various aspects or features of this application can be implemented as methods, apparatus, or articles of manufacture using standard programming and / or engineering techniques. The term "article of manufacture" as used herein encompasses a computer program accessible from any computer-readable device, carrier, or medium. For example, computer-readable media may include, but are not limited to: magnetic storage devices (e.g., hard disks, floppy disks, or magnetic tapes), optical discs (e.g., compact discs (CDs), digital versatile discs (DVDs), etc.), smart cards, and flash memory devices (e.g., erasable programmable read-only memory (EPROMs), cards, sticks, or key drives, etc.). Additionally, the various storage media described herein may represent one or more devices and / or other machine-readable media for storing information. The term "machine-readable medium" may include, but is not limited to, wireless channels and various other media capable of storing, containing, and / or carrying instructions and / or data.

[0266] It should be understood that the processor mentioned in the embodiments of this application can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0267] It should also be understood that the memory mentioned in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0268] It should be noted that when the processor is a general-purpose processor, DSP, ASIC, FPGA, or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, the memory (storage module) is integrated into the processor.

[0269] It should be noted that the memories described herein are intended to include, but are not limited to, these and any other suitable types of memories.

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

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

[0272] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

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

[0274] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

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

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

Claims

1. A remote proof method, characterized in that, The method includes: Send information about the seed anchor validators and the number of validators required, wherein the seed anchor validators and the number of validators required are used to determine multiple recommended validators; Receive information from multiple recommended verifiers from the trust manager; Based on the information of multiple recommended verifiers, obtain the proof results of each of the multiple recommended verifiers for the verified entity; The credibility of the verified entity is assessed based on the proof results of each of the recommended verifiers.

2. The method according to claim 1, characterized in that, The step of obtaining the proof results of each of the multiple recommended verifiers for the verified entity includes: Obtain evidence from the verified party; The evidence is sent to multiple of the recommended verifiers, and the evidence is used to determine the proof result; Receive proof results from each of the recommended verifiers.

3. The method according to claim 1 or 2, characterized in that, The step of conducting a credibility assessment of the verified entity based on the proof results of each of the recommended verifiers includes: The summary result is determined based on the proof results of the verified persons by each of the recommended verifiers. The credibility of the verified entity is assessed based on the summarized results.

4. The method according to claim 3, characterized in that, The step of determining the summary result based on the proof results of the verified entity by each of the recommended verifiers includes: The proof result with the highest frequency is determined as the summary result; Alternatively, determining the summary result based on the proof results of each of the recommended verifiers for the verified entity includes: Map each of the aforementioned proof results to a trust value; Based on the trust value of each of the proof results, determine the average trust value of the multiple proof results; The summary result is determined based on the average trust value, wherein the trust value of the summary result is similar to the average trust value.

5. A remote proof method, characterized in that, The method includes: Receive information about the seed anchor validator and the number of required validators from the dependent party, the seed anchor validator and the number of required validators being used to determine multiple recommended validators; Based on the information of the seed anchor validator and the number of validators required, multiple recommended validators are determined from one or more validator groups. The multiple recommended validators belong to the same validator group, and the multiple validators in the same validator group have similar proof results for the same verifier. Send information about multiple recommended verifiers.

6. The method according to claim 5, characterized in that, If the number of validators in a validator group is less than the required number of validators, the number of recommended validators is equal to the number of validators in the validator group.

7. The method according to claim 5 or 6, characterized in that, The method further includes: Send a first request message to the validator group database, the first request message being used to request one or more of the validator groups; Receive one or more of the validator groups from the validator group database.

8. The method according to claim 5 or 6, characterized in that, The method further includes: Send a second request message to the trust graph database. The second request message is used to request trust graph information, which includes the proof results of each verifier for the verifier and a first norm. The first norm is a scalar or vector in the proof results that represents the trustworthiness of the verifier. The similarity between the proof results of each verifier and the proof results of the verifier is calculated based on the trust graph information. Based on the similarity of each verifier's proof results for the verifier, verifiers with similar proof results are grouped into one or more verifier groups.

9. The method according to claim 8, characterized in that, Before sending the second request information to the trust graph database, the method further includes: Obtain the proof result of each verifier for the verifier; Transform the scalar or vector representing the credibility of the verified entity in the proof results of each verifier into a first norm; The trust graph information is sent to the trust graph database. The trust graph information includes the proof results of each verifier for the verifier and the first norm.

10. The method according to claim 8 or 9, characterized in that, The first norm ranges from 0 to 1.

11. The method according to claim 9 or 10, characterized in that, The method further includes sending the proof results of each verifier for the verifier to a proof result database.

12. A remote verification device, characterized in that, The device includes: The communication module is used to send information about the seed anchor validators and the number of validators required, wherein the seed anchor validators and the number of validators required are used to determine multiple recommended validators; The communication module is also used to receive information from multiple recommended verifiers from the trust manager; The processing module is used to obtain the proof results of each of the multiple recommended verifiers for the verified entity based on the information of the multiple recommended verifiers; The processing module is further configured to perform a credibility assessment on the verifiable entity based on the proof results of each of the recommended verifiers.

13. The apparatus according to claim 12, characterized in that, The communication module is also used to obtain evidence from the verified party; The communication module is also used to send the evidence to multiple recommended verifiers, the evidence being used to determine the proof result; The communication module is also used to receive proof results from each of the recommended verifiers.

14. The apparatus according to claim 12 or 13, characterized in that, The processing module is further configured to determine a summary result based on the proof results of each of the recommended verifiers for the verified entity; The processing module is also used to perform a credibility assessment on the verified entity based on the summarized results.

15. The apparatus according to claim 14, characterized in that, The processing module is further configured to determine the proof result with the highest frequency as the summary result; Alternatively, the processing module is further configured to map each of the proof results to a trust value; The processing module is further configured to determine the average trust value of multiple proof results based on the trust value of each proof result; The processing module is further configured to determine a summary result based on the average trust value, wherein the trust value of the summary result is similar to the average trust value.

16. A remote verification device, characterized in that, The device includes: A communication module is used to receive information about seed anchor validators and the number of required validators from the dependent party, wherein the seed anchor validators and the number of required validators are used to determine multiple recommended validators; The processing module is also configured to determine multiple recommended validators from one or more validator groups based on the information of the seed anchor validator and the number of validators required, wherein the multiple recommended validators belong to the same validator group and the multiple validators in the same validator group have similar proof results for the same verifier. The communication module is also used to send information about multiple recommended verifiers.

17. The apparatus according to claim 16, characterized in that, If the number of validators in a validator group is less than the required number of validators, the number of recommended validators is equal to the number of validators in the validator group.

18. The apparatus according to claim 16 or 17, characterized in that, The communication module is used to send a first request message to the validator group database, wherein the first request message is used to request one or more of the validator groups; The communication module is also configured to receive one or more of the validator groups from the validator group database.

19. The apparatus according to claim 16 or 17, characterized in that, The communication module is used to send a second request message to the trust graph database. The second request message is used to request trust graph information. The trust graph information includes the proof result of each verifier for the verifier and a first norm. The first norm is a scalar or vector in the proof result that represents the credibility of the verifier. The processing module is further configured to calculate the similarity of each verifier's proof results to the verifier based on the trust graph information; The processing module is further configured to group verifiers with similar proof results into one or more verifier groups based on the similarity of each verifier's proof results for the verifier.

20. The apparatus according to claim 19, characterized in that, The communication module is also used to obtain the proof result of each verifier for the verifier; The processing module is further configured to convert the scalar or vector representing the credibility of the verified party in the proof result of each verifier into the first norm; The communication module is further configured to send the trust graph information to the trust graph database, the trust graph information including the proof result of each verifier for the verifiable entity and the first norm.

21. The apparatus according to claim 19 or 20, characterized in that, The first norm ranges from 0 to 1.

22. The apparatus according to claim 20 or 21, characterized in that, The communication module is also used to send the proof results of each verifier to the proof result database.

23. A remote verification system, characterized in that, The system includes: a trust manager, a dependent party, multiple validators, and one or more verified parties; The dependent party is used to implement the remote proof method as described in any one of claims 1 to 4, and the trust manager is used to implement the remote proof method as described in any one of claims 5 to 11. The verifier is used to generate a proof result based on the evidence presented by the verifier.

24. A communication device, characterized in that, The communication device includes a memory and a processor. The memory is used to store instructions, and the processor is used to execute the instructions stored in the memory. Execution of the instructions stored in the memory causes the processor to perform the remote verification method according to any one of claims 1 to 4, or the remote verification method according to any one of claims 5 to 11.

25. A chip, characterized in that, The chip includes at least one processor and a communication interface, the communication interface being coupled to the at least one processor, the at least one processor being used to run computer programs or instructions to implement the remote proof method as described in any one of claims 1 to 4, or the remote proof method as described in any one of claims 5 to 11, and the communication interface being used to communicate with other modules outside the chip.

26. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed, implement the remote proof method according to any one of claims 1 to 4, or the remote proof method according to any one of claims 5 to 11.

27. A computer program product, characterized in that, The program includes a method for performing remote verification as described in any one of claims 1 to 4, or any one of claims 5 to 11, when the program is run on a processor.

Images