Trust evaluation method and apparatus

Abstract

The present application relates to the field of Internet of Things. Disclosed are a trust evaluation method and apparatus. The method comprises: when a device trust evaluation attribute changes, determining an affected device; updating an attribute evaluation result of the affected device; and on the basis of the updated attribute evaluation result, re-performing trust evaluation on the affected device to obtain a target trust evaluation result of the affected device, wherein the target trust evaluation result of the affected device is used for adjusting access permissions of the affected device. The present application is used for implementing dynamic evaluation of device trust, thereby effectively ensuring network security.

Description

A trust assessment method and apparatus

[0001] This application claims priority to Chinese Patent Application No. 202410923941.6, filed on July 10, 2024, entitled “A Trust Assessment Method and Apparatus”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of the Internet of Things, and more particularly to a trust assessment method and apparatus. Background Technology

[0003] With the diversification of network functions and services, the Internet of Things (IoT) is widely used in fields such as healthcare and smart homes. Taking the smart home field as an example, multiple devices that make up a smart home system are often directly or indirectly connected through a network. Different devices can collaborate to complete a task, such as indoor and outdoor lighting management.

[0004] It is worth noting that smart home devices and systems are crucial to home security. To ensure the security of device access and network data transmission, it is necessary to have a clear and reliable understanding of the trustworthiness of each device in the smart home system. Otherwise, if one device is compromised, it may cause a chain reaction, leading to the breach of the entire network and a decrease in the overall stability and reliability of the smart home system, thereby seriously affecting the security of the entire smart home system. Summary of the Invention

[0005] This application provides a trust assessment method and apparatus, which can realize dynamic assessment of device trust, thereby effectively ensuring network security.

[0006] To achieve the above objectives, this application adopts the following technical solution.

[0007] In a first aspect, embodiments of this application provide a trust assessment method, which includes: identifying an affected device when a device trust assessment attribute changes; updating the attribute assessment result of the affected device; and re-evaluating the trust of the affected device based on the updated attribute assessment result to obtain a target trust assessment result for the affected device, wherein the target trust assessment result is used to adjust the access permissions of the affected device.

[0008] In the above method, the trust assessment node can perform a trust assessment on any device connected to the current network to obtain its corresponding trust assessment result. A device's trust assessment result is related to its attribute assessment result (reflecting device attributes such as reputation, risk, or threat). The device trust assessment attribute (e.g., device attributes of a specific manufacturer, device attributes of a specific device type, or assessment strategies associated with device attributes) refers to attributes that can affect the attribute assessment result. Therefore, when a device's trust assessment attribute changes, the trust assessment node needs to identify the affected device from the current network and re-evaluate the affected device's trust by updating its attribute assessment result to obtain a new trust assessment result for the affected device (i.e., the target trust assessment result). Since the target trust assessment result of the affected device can be used to adjust the access permissions of the affected device, this means that the trust assessment method provided in this application embodiment can adjust the network connection and data transmission of devices in a timely manner based on the trust assessment result of dynamic trust assessment of network devices, thereby effectively ensuring network security.

[0009] In one implementation, the device trust assessment attribute is N device attributes of the target object, the target attribute belongs to P objects, and the object refers to the device manufacturer or device type, where P and N are both positive integers.

[0010] For example, in this embodiment, the P objects can be represented by four equipment manufacturers, specifically manufacturer 1, manufacturer 2, manufacturer 3, and manufacturer 4. If the N equipment attributes corresponding to the target object include manufacturer 1's reputation and manufacturer 1's risk, then the equipment trust assessment attributes change, meaning that both manufacturer 1's reputation and manufacturer 1's risk have changed. At this time, the trust assessment node Q needs to re-evaluate the trust of the affected equipment in its current network (e.g., equipment from manufacturer 1, or equipment from other equipment manufacturers associated with manufacturer 1). Other equipment manufacturers associated with manufacturer 1 can refer to: manufacturer 1's headquarters or branch offices, manufacturers belonging to the same management user as manufacturer 1, or manufacturers with cooperative relationships with manufacturer 1. Of course, the associated relationships can also be other relationships, which will not be listed here.

[0011] For example, in this embodiment, the P objects can be two device types, specifically including camera type and lighting device type. If the N device attributes corresponding to the target object include the reputation of camera type, then the device trust assessment attribute changes, which means that the reputation of camera type has changed. At this time, the trust assessment node Q needs to re-evaluate the trust of the affected devices (e.g., all cameras) in the current network.

[0012] In the above implementation, the device trust assessment attributes are N device attributes of the target object. When the device trust assessment attributes change, that is, at least one of the M device attributes of a certain device manufacturer (or device type) changes, this means that the embodiments of this application can realize dynamic assessment of device trust according to changes in the external environment, effectively ensuring network security.

[0013] In one implementation, the attribute evaluation result of the affected device includes first evaluation sub-results corresponding to M device attributes, where M is a positive integer greater than or equal to N. The first evaluation sub-results are obtained after evaluating the first remote proof evidence in the first trust evaluation data, which was obtained during the previous evaluation of the device attributes of the affected device. Updating the attribute evaluation result of the affected device includes: determining second evaluation sub-results corresponding to the N device attributes of the target object; and updating the first evaluation sub-results corresponding to the N device attributes of the affected device based on the N second evaluation sub-results.

[0014] When N device attributes of the target object change, that is, at least one of the M device attributes of a certain device manufacturer (or device type) changes, the trust assessment node does not need to evaluate each of the first evaluation sub-results in the attribute assessment results (M first evaluation sub-results) of the affected device. Instead, it directly updates the first evaluation sub-results corresponding to the N device attributes of the target object in turn using the second evaluation sub-results corresponding to the N device attributes of the affected device. This not only saves the computational resources of trust assessment but also improves the efficiency of trust assessment.

[0015] In one implementation, the device trust assessment attribute is an assessment strategy associated with device attributes.

[0016] In the above implementation, if the device trust assessment attribute changes, it means that at least one of the M assessment strategies changes. In other words, the embodiments of this application can realize dynamic assessment of device trust based on such changes in assessment strategies, effectively ensuring network security.

[0017] In one implementation, updating the attribute evaluation results of the affected device includes: re-acquiring second trust evaluation data of the affected device based on the device information of the affected device, the second trust evaluation data including second remote proof evidence; and determining updated evaluation sub-results corresponding to M device attributes of the affected device based on the second remote proof evidence.

[0018] In the above implementation, when the device trust assessment attribute is the assessment strategy, its change means that the module used to assess device attributes (i.e., the attribute assessment module) can no longer update the attribute assessment results corresponding to the affected device based on its own stored data. Therefore, it is necessary to re-acquire the second trust assessment data of the affected device to conduct trust assessment on the affected device. This process combines remote proof protocol technology to ensure the validity and reliability of the second remote proof evidence, thereby enabling a more accurate assessment of the device attributes of the affected device and realizing dynamic assessment of device trust.

[0019] In one implementation, the step of re-acquiring the second trust assessment data of the affected device based on the device information of the affected device includes: determining a parameter to be assessed based on the device information of the affected device, the parameter to be assessed being used to instruct the affected device to provide the second remote proof evidence; determining a target control node for controlling access permissions to the affected device; sending the parameter to be assessed and the device information of the affected device to the target control node; and receiving the second trust assessment data sent by the target control node.

[0020] In the above implementation, since different devices require different information during trust assessment, the trust assessment node does not indiscriminately obtain the same information for each affected device. Instead, it can selectively issue the parameters to be assessed during trust assessment based on device information such as the device type of the affected device. For example, the trust assessment node can send the parameters to be assessed to the target control node to directly indicate the parameter requirements for the affected device, so that the affected device can more accurately extract the trust assessment data (i.e., the second trust assessment data) required for trust assessment. This can effectively avoid the affected device from feeding back redundant information that does not need to be assessed to the target control node, thereby reducing network transmission overhead.

[0021] In one implementation, the M device attributes include a first target device attribute; determining the updated evaluation sub-results corresponding to the M device attributes of the affected device based on the second remote proof data includes: extracting first attribute evaluation information corresponding to the first target device attribute from the second remote proof data; sending the first attribute evaluation information to the target attribute evaluation node corresponding to the first target device attribute; and receiving the updated evaluation sub-results returned by the target attribute evaluation node.

[0022] In the above implementation, the first target device attribute (e.g., reputation) can be any one of the M device attributes. The updated evaluation sub-result is the evaluation sub-result obtained after re-evaluating the first target device attribute of the affected device. Since the updated evaluation sub-result is received by the trust evaluation node from the target attribute evaluation node, rather than evaluated by the trust evaluation node itself, this means that the processing operation of evaluating the device attribute is actually performed by the target attribute evaluation node, which can greatly reduce the computational pressure on the trust evaluation node.

[0023] In one implementation, the M device attributes include a second target device attribute; determining the updated evaluation sub-results corresponding to the M device attributes of the affected device based on the second remote proof data includes: extracting second attribute evaluation information corresponding to the second target device attribute from the second remote proof data; and re-evaluating the second target device attribute of the affected device based on the second attribute evaluation information and the evaluation strategy associated with the second target device attribute to obtain the updated evaluation sub-results corresponding to the second target device attribute.

[0024] In the above implementation, the second target device attribute (e.g., reputation) can be any one of the M device attributes. The updated evaluation sub-result is evaluated by the trust evaluation node itself, without requesting other nodes to evaluate the second target device attribute of the affected device. In other words, the trust evaluation node can include not only a module for trust evaluation, but also a module for device attribute evaluation. This deployment method can not only reduce deployment costs, but also reduce interactions between nodes, thereby reducing network transmission overhead.

[0025] In one implementation, the second target device attribute is reputation; the step of re-evaluating the second target device attribute of the affected device based on the second attribute evaluation information and the evaluation strategy associated with the second target device attribute to obtain an updated evaluation sub-result corresponding to the second target device attribute includes: re-evaluating the second target device attribute of the affected device based on the second attribute evaluation information and the evaluation strategy associated with the second target device attribute to obtain a current evaluation sub-result; obtaining a historical evaluation sub-result corresponding to the second target device attribute based on the device information of the affected device; and determining an updated evaluation sub-result corresponding to the second target device attribute based on the current evaluation sub-result and the historical evaluation sub-result.

[0026] In the above implementation, when the second target device attribute is reputation, the updated evaluation sub-result corresponding to the second target device attribute is jointly determined by the current evaluation sub-result and the historical evaluation sub-result. For example, it can be obtained by averaging the current evaluation sub-result and the historical evaluation sub-result, or by weighted averaging the current evaluation sub-result and the historical evaluation sub-result, or other methods, which will not be limited here. This method of incorporating historical evaluation sub-results into the trust assessment makes the final updated evaluation sub-result more accurate, thereby improving the accuracy of the trust assessment.

[0027] In one implementation, the step of re-evaluating the trust of the affected device based on the updated attribute evaluation results to obtain a target trust evaluation result for the affected device includes: determining the context importance index of the affected device; re-evaluating the trust of the affected device based on the updated attribute evaluation results and the importance index to obtain a current trust evaluation result for the affected device; and determining the target trust evaluation result for the affected device based on the current trust evaluation result for the affected device.

[0028] In the above implementation, since the current trust assessment result of the affected device is determined by the updated attribute assessment result and the importance index, this means that the trust assessment not only involves the assessment sub-results corresponding to device attributes such as reputation, risk, and threat, but also the importance index of the device context, which can effectively improve the accuracy of the trust assessment.

[0029] In one implementation, the importance indicator is sent by a target control node, which controls the access permissions of the affected device.

[0030] In the above implementation, the importance index is sent by the target control node, rather than evaluated by the trust evaluation node itself, which can effectively save the computing resources of the trust evaluation node.

[0031] In one implementation, determining the target trust assessment result of the affected device based on the current trust assessment result of the affected device includes: obtaining the historical trust assessment result of the affected device based on the device information of the affected device; and determining the target trust assessment result of the affected device based on the historical trust assessment result and the current trust assessment result.

[0032] In the above implementation method, the target trust assessment result of the affected device is derived by combining the historical trust assessment results and the current information assessment results, which can effectively improve the accuracy of trust assessment.

[0033] In one implementation, the method further includes: receiving a change identifier sent by a target attribute evaluation node, the target attribute evaluation node being used to evaluate a first target device attribute, the change identifier being a first identifier or a second identifier, the first identifier being used to indicate that a first target device attribute of a target object has changed, and the second identifier being used to indicate that an evaluation strategy associated with the first target device attribute has changed.

[0034] In the above implementation, different device trust assessment attributes mean that the specific implementation methods for subsequent trust assessment of affected devices are different. The trust assessment node can quickly identify the reason for the change in device trust assessment attributes by receiving change identifiers sent by any attribute assessment node, thereby realizing dynamic assessment of device trust under different changing factors.

[0035] Secondly, embodiments of this application provide a trust assessment apparatus, comprising: a determination module, configured to determine an affected device when a device trust assessment attribute changes; an update module, configured to update the attribute assessment result of the affected device; and an assessment module, configured to reassess the trust of the affected device based on the updated attribute assessment result to obtain a target trust assessment result for the affected device, wherein the target trust assessment result is used to adjust the access permissions of the affected device.

[0036] In one implementation, the device trust assessment attribute is N device attributes of the target object, the target attribute belongs to P objects, and the object refers to the device manufacturer or device type, where P and N are both positive integers.

[0037] In one implementation, the attribute evaluation result of the affected device includes first evaluation sub-results corresponding to M device attributes, where M is a positive integer greater than or equal to N. The first evaluation sub-results are obtained after evaluating the first remote proof evidence in the first trust evaluation data, which was obtained during the previous evaluation of the device attributes of the affected device. The update module is used to update the attribute evaluation result of the affected device, including: a first determining unit, used to determine second evaluation sub-results corresponding to the N device attributes of the target object; and an update unit, used to update the first evaluation sub-results corresponding to the N device attributes of the affected device based on the N second evaluation sub-results.

[0038] In one implementation, the device trust assessment attribute is an assessment strategy associated with device attributes.

[0039] In one implementation, the updating module is used to update the attribute evaluation results of the affected device, including: an acquisition unit, used to reacquire the second trust evaluation data of the affected device based on the device information of the affected device, the second trust evaluation data including the second remote proof evidence; and a second determination unit, used to determine the updated evaluation sub-results corresponding to the M device attributes of the affected device based on the second remote proof evidence.

[0040] In one implementation, the acquisition unit is configured to reacquire the second trust assessment data of the affected device based on the device information of the affected device, comprising: a first determining subunit, configured to determine a parameter to be assessed based on the device information of the affected device, the parameter to be assessed being used to instruct the affected device to provide the second remote proof evidence; the first determining subunit is further configured to determine a target control node for controlling access permissions to the affected device; a first transceiver subunit, configured to send the parameter to be assessed and the device information of the affected device to the target control node; and the first transceiver subunit is further configured to receive the second trust assessment data sent by the target control node.

[0041] In one implementation, the M device attributes include a first target device attribute; the second determining unit is configured to determine, based on the second remote proof data, update evaluation sub-results corresponding to the M device attributes of the affected device, including: a first extraction sub-unit, configured to extract first attribute evaluation information corresponding to the first target device attribute from the second remote proof data; a second transceiver sub-unit, configured to send the first attribute evaluation information to the target attribute evaluation node corresponding to the first target device attribute; the second transceiver sub-unit is further configured to receive the update evaluation sub-results returned by the target attribute evaluation node.

[0042] In one implementation, the M device attributes include a second target device attribute; the second determining unit is configured to determine, based on the second remote proof data, update evaluation sub-results corresponding to the M device attributes of the affected device, including: a second extraction sub-unit, configured to extract second attribute evaluation information corresponding to the second target device attribute from the second remote proof data; and an evaluation sub-unit, configured to re-evaluate the second target device attribute of the affected device based on the second attribute evaluation information and an evaluation strategy associated with the second target device attribute, to obtain the update evaluation sub-results corresponding to the second target device attribute.

[0043] In one implementation, the second target device attribute is reputation; the evaluation subunit is configured to re-evaluate the second target device attribute of the affected device based on the second attribute evaluation information and the evaluation strategy associated with the second target device attribute, to obtain an updated evaluation sub-result corresponding to the second target device attribute, including: an evaluation subunit specifically configured to re-evaluate the second target device attribute of the affected device based on the second attribute evaluation information and the evaluation strategy associated with the second target device attribute, to obtain a current evaluation sub-result; an evaluation subunit specifically configured to obtain a historical evaluation sub-result corresponding to the second target device attribute based on the device information of the affected device; and an evaluation subunit specifically configured to determine an updated evaluation sub-result corresponding to the second target device attribute based on the current evaluation sub-result and the historical evaluation sub-result.

[0044] In one implementation, the evaluation module is configured to re-evaluate the trust of the affected device based on the updated attribute evaluation results to obtain a target trust evaluation result for the affected device, comprising: a third determining unit configured to determine a contextual importance index for the affected device; an evaluation unit configured to re-evaluate the trust of the affected device based on the updated attribute evaluation results and the importance index to obtain a current trust evaluation result for the affected device; and the third determining unit is further configured to determine a target trust evaluation result for the affected device based on the current trust evaluation result for the affected device.

[0045] In one implementation, the importance indicator is sent by a target control node, which controls the access permissions of the affected device.

[0046] In one implementation, the third determining unit is further configured to determine the target trust assessment result of the affected device based on the current trust assessment result of the affected device, including: the third determining unit is specifically configured to obtain the historical trust assessment result of the affected device based on the device information of the affected device; the third determining unit is specifically configured to determine the target trust assessment result of the affected device based on the historical trust assessment result and the current trust assessment result.

[0047] In one implementation, the trust assessment device further includes a transceiver module for receiving a change identifier sent by a target attribute assessment node, wherein the target attribute assessment node is used to assess a first target device attribute, and the change identifier is a first identifier or a second identifier, wherein the first identifier is used to indicate that the first target device attribute of the target object has changed, and the second identifier is used to indicate that the assessment strategy associated with the first target device attribute has changed.

[0048] Thirdly, embodiments of this application provide a trust assessment apparatus, including a memory and a processor. The memory is used to store computer instructions, and the processor is used to call and execute the computer instructions from the memory to implement a method as described in the first aspect or any of the implementations of the first aspect, or to implement a method as described in the second aspect or any of the implementations of the second aspect.

[0049] Fourthly, embodiments of this application provide a computer-readable storage medium storing instructions that, when executed on a processor, implement a method as described in the first aspect or any of the implementations of the first aspect, or implement a method as described in the second aspect or any of the implementations of the second aspect.

[0050] Fifthly, embodiments of this application provide a computer program product, the computer program product including instructions that, when executed on a processor, implement a method as described in the first aspect or any of the implementations of the first aspect, or implement a method as described in the second aspect or any of the implementations of the second aspect.

[0051] The technical effects produced by any of the second to fifth aspects and any of the above-mentioned implementation methods can be referred to the first aspect and the corresponding implementation methods in the first aspect. The repetitions will not be repeated here. Attached Figure Description

[0052] Figure 1A is a schematic diagram of the system framework corresponding to a trust assessment system provided in an embodiment of this application;

[0053] Figure 1B is a schematic diagram of an architecture provided in an embodiment of this application;

[0054] Figure 2 is an interaction diagram of a method for accessing based on trust assessment results provided in an embodiment of this application;

[0055] Figure 3 is an interactive diagram of a method for trust assessment provided in an embodiment of this application;

[0056] Figure 4 is an interaction diagram of a method for dynamic trust management provided in an embodiment of this application;

[0057] Figure 5 is an interactive diagram of a method for dynamic trust management provided in an embodiment of this application;

[0058] Figure 6 is a schematic diagram of a process for performing dynamic trust assessment provided in an embodiment of this application;

[0059] Figure 7 is a schematic diagram of a trust assessment device provided in an embodiment of this application;

[0060] Figure 8 is a schematic diagram of the structure of a trust assessment device provided in an embodiment of this application;

[0061] Figure 9 is a schematic diagram of the structure of a trust assessment device provided in an embodiment of this application. Detailed Implementation

[0062] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. To facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first" and "second" are used to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that "first" and "second" are not necessarily different. Furthermore, in the embodiments of this application, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of this application should not be construed as being better or more advantageous than other embodiments or design schemes. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner for ease of understanding.

[0063] To facilitate understanding of the technical solutions provided in the embodiments of this application, the relevant technologies of the embodiments of this application will be briefly introduced first.

[0064] Current technical solutions propose a trust assessment model for devices in smart home scenarios. This model calculates the trust value of device a (e.g., device a) based on its role, contextual importance, and reputation. When device a requests access to another device (e.g., device b's function, such as a query function), device b needs to obtain device a's trust value and determine whether device a has the necessary access rights based on that value. However, current trust assessment schemes do not support dynamic trust assessment. This means that when device a's data changes (e.g., device hardware and software face uncertainties due to upgrades and maintenance), the trust assessment model cannot keep up with device a's trust value in a timely manner. This could result in device a, with a low trust value, remaining on the smart home network. If a malicious user accesses the smart home network through device a, they could steal the user's personal information or even control other devices in the home, significantly increasing the security risks of the smart home network.

[0065] To address the aforementioned issues, this application provides a novel trust assessment method. In this method, when a device's trust assessment attributes change, a node with trust assessment functionality (i.e., a trust assessment node) needs to identify the affected device and update its attribute assessment results. Then, based on the updated attribute assessment results, the trust assessment node can re-evaluate the affected device's trust to obtain a target trust assessment result for the affected device. This target trust assessment result can be used to adjust the access permissions of the affected device.

[0066] In this embodiment, the trust assessment node can perform a trust assessment on any device connected to the current network to obtain its corresponding trust assessment result. A device's trust assessment result is related to its attribute assessment result (reflecting device attributes such as reputation, risk, or threat). The device trust assessment attribute (e.g., a device attribute from a specific manufacturer, a device attribute of a specific device type, or an assessment strategy associated with a device attribute) refers to an attribute that can affect the attribute assessment result. Therefore, when a device's trust assessment attribute changes, the trust assessment node needs to identify the affected device from the current network and re-evaluate the affected device's trust by updating its attribute assessment result to obtain a new trust assessment result for the affected device (i.e., the target trust assessment result). Since the target trust assessment result of the affected device can be used to adjust the access permissions of the affected device, this means that the trust assessment method provided in this embodiment can adjust the network connection and data transmission of devices in a timely manner based on the trust assessment result of dynamic trust assessment of network devices, thereby effectively ensuring network security.

[0067] The trust assessment method provided in this application may be applicable to smart home scenarios, cellular network scenarios, or other scenarios, which will not be limited here. Smart homes connect various devices in the home through IoT technology, providing multiple functions and means such as appliance control, lighting control, remote telephone control, indoor and outdoor remote control, burglar alarms, environmental monitoring, HVAC control, infrared forwarding, and programmable timer control. In a smart home scenario, devices connected to the current network may include: audio-visual equipment, lighting equipment, curtain controllers, air conditioning controllers, security systems, digital cinema systems, audio-visual servers, media storage systems, and networked appliances.

[0068] In cellular network scenarios, devices currently connected to the network can include smart terminals with data processing capabilities such as smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, in-vehicle terminals, and smart TVs. When these devices are connected together, they can provide a variety of functions such as instant messaging, multimedia data display (e.g., live streaming), telemedicine, AR virtual reality, smart manufacturing, and smart transportation (e.g., autonomous driving).

[0069] In this application, the embodiments mainly take a smart home scenario as an example to illustrate how to update the trust assessment results of devices in a timely manner according to changes in the external environment, and determine the access permissions of devices based on the updated trust assessment results. For example, it may determine whether to exit the current network or whether to continue to access all or part of the network resources.

[0070] The system framework for applying the trust assessment method provided in the embodiments of this application is described below:

[0071] Please refer to Figure 1A, which is a schematic diagram of the system framework corresponding to a trust assessment system provided in an embodiment of this application. As shown in Figure 1A, the trust assessment system 1 can be a trust assessment system corresponding to a smart home scenario. The trust assessment system 1 can include a device cluster 10, a control node P (e.g., a smart home controller), and a trust assessment node Q. In addition, this embodiment of the application can also deploy a database in the smart home scenario. When the relevant data in the database changes, the trust assessment node Q is promptly notified to update the trust assessment results. Specifically, the database deployed in the smart home scenario can include database D1 and database D2 as shown in Figure 1A.

[0072] Database D1 (e.g., trust database): Used to store historical trust assessment results of devices and reputation information of devices, etc.

[0073] Database D2 (e.g., business database): Used to store threat and risk information related to device hardware and software configuration information.

[0074] As shown in Figure 1A, the device cluster 10 may include n devices, where n is a positive integer. Specifically, the device cluster 10 may include device a, device b, ..., device n. Each device in the cluster can connect to the control node P via a network, allowing the control node P to adjust the access permissions of each device through this network connection. The network connection method is not limited; it can be a direct or indirect connection via wired communication, wireless communication, or other methods. This application does not impose any restrictions on this method.

[0075] Any device in the device cluster (e.g., device a) can include a remote authentication module 110 and a trust management module 120. When device a accesses the current network, it can provide remote authentication evidence (also known as remote verification evidence or remote verification information) according to the requirements of the control node P. This remote authentication evidence may include device information of device a (e.g., device identifier, device type, device manufacturer, etc.) and hardware and software configuration information of device a (e.g., CPU / BIOS model information, operating system name, version number, etc.). This remote authentication evidence is mainly used for trust assessment. After the assessment is completed, device a can receive the trust assessment result forwarded by the control node P. Here, the trust assessment result can be a trust value that falls within the trust range (e.g., [0, 1]) or a trust level, which will not be limited here.

[0076] Control node P is the core node in trust assessment system 1, mainly comprising a context assessment module 130 and a trust management module 140. Control node P is primarily responsible for managing device access, collecting device hardware and software information, determining the importance indicators of the device context, and requesting trust assessment node Q to perform trust assessment and classification of the device. Upon receiving the trust assessment result from trust assessment node Q, it can determine the resources that the device can access based on the trust assessment result and forward the trust assessment result to the device. The device context mainly includes information such as the device's functionality and reputation.

[0077] The trust assessment node Q may contain a trust assessment module 150. This trust assessment node is mainly responsible for assessing the trust of the device based on the device's contextual importance indicators and the assessment sub-results corresponding to M device attributes such as role, reputation, risk, and threat, and obtaining the device's trust assessment result, where M is a positive integer.

[0078] For ease of explanation, the device attributes in this application embodiment can be categorized into three, specifically including a first device attribute (e.g., reputation), a second device attribute (e.g., risk), and a third device attribute (e.g., threat).

[0079] Further, please refer to Figure 1B, which is a schematic diagram of an architecture provided in an embodiment of this application. As shown in Figure 1B, the architecture includes a remote verification module 110, a trust management module 120, a context evaluation module 130, a trust management module 140, a trust evaluation module 150, and three attribute evaluation modules. Taking three as an example, these may specifically include an attribute evaluation module 160 (e.g., a reputation evaluation module), an attribute evaluation module 170 (e.g., a risk evaluation module), and an attribute evaluation module 180 (e.g., a threat evaluation module). In addition, the architecture may also include databases D1 and D2.

[0080] In this context, the remote verification module 110 and the trust management module 120 can both be two modules deployed on device a shown in Figure 1A; the context evaluation module 130 and the trust management module 140 can both be two modules deployed on the control node P shown in Figure 1A; and the trust evaluation module 150 can be one module deployed on the trust evaluation node Q shown in Figure 1A. It is understood that any attribute evaluation module can be deployed on the trust evaluation node Q along with the trust evaluation module 150, or it can be deployed on a different node than the trust evaluation node Q. The deployment method of the attribute evaluation module will not be limited here.

[0081] It is understood that the reputation assessment module, risk assessment module, and threat assessment module can be deployed on the same node (referred to as the attribute assessment result) or on different nodes. When these three modules are deployed on different nodes, for ease of explanation, the node where the reputation assessment module is located can be referred to as the reputation assessment node, the node where the risk assessment module is located can be referred to as the risk assessment node, and the node where the threat assessment module is located can be referred to as the threat assessment node.

[0082] The functions of each module shown in Figure 1B are described below:

[0083] Remote verification module 110: mainly responsible for providing remote verification evidence to trust management module 140.

[0084] Trust management module 120: mainly responsible for communicating with trust management module 140 in control node P to obtain the trust assessment results of device a.

[0085] Context evaluation module 130: mainly responsible for evaluating the importance of the context of device a and giving a result.

[0086] Trust management module 140: mainly responsible for receiving remote authentication evidence of device a sent by remote authentication module 110; obtaining the context importance index of device a from context evaluation module 130; sending a trust evaluation request to trust evaluation module 150, which may carry remote authentication evidence and the context importance index of the device; receiving the trust evaluation result sent by trust evaluation module 150, and determining the resources that device a can access based on the trust evaluation result; and sending the trust evaluation result to trust management module 120.

[0087] Trust assessment module 150: mainly responsible for receiving trust assessment requests and trust assessment data (including remote proof evidence and context importance indicators) sent by trust management module 140; determining the assessment sub-results corresponding to the three device attributes respectively; and performing trust assessment on device a based on the context importance indicators of device a, the three assessment sub-results and the historical trust assessment results stored in database D1, to obtain the trust assessment result of device a.

[0088] Attribute evaluation module 160: It is mainly responsible for evaluating the reputation of the device based on the information extracted from the remote proof evidence of device a (e.g., device information) and the reputation information stored in database D1, and obtaining evaluation sub-result 1 (e.g., reputation evaluation result).

[0089] Attribute assessment module 170: mainly based on the information extracted from the remote proof evidence of device a (e.g., device information, hardware and software configuration information) and the risk information stored in database D2, the assessment sub-result 2 (e.g., risk assessment result) is obtained after assessing the risk of device a.

[0090] Attribute assessment module 180: It is mainly responsible for assessing the threat of the device based on the information extracted from the remote evidence of the device (e.g., device information, hardware and software configuration information) and the threat information stored in database D2, and obtaining the assessment sub-result 3 (e.g., threat assessment result).

[0091] It should be understood that when device a in Figure 1A is accepted by the trust assessment system 1, it means that device a has successfully connected to the smart home network and obtained the trust assessment result sent by the control node P. Subsequently, when device a accesses other devices (e.g., device b in device cluster 10), it can directly send an access request carrying the trust assessment result to device b. Device b can use the trust assessment result in the access request as a reference value to decide whether to allow device a to access device b.

[0092] Optionally, when device a needs to access device b, it can also send an access request carrying the trust assessment result to the control node P. The control node P then decides whether to allow device a to access device b based on the trust assessment result in the access request. To facilitate understanding of the trust assessment process of device a and the access process of device a, please refer to Figure 2. Figure 2 is an interaction diagram of a method for access based on the trust assessment result provided in an embodiment of this application. As shown in Figure 2, this method can be jointly executed by device a, control node P, trust assessment node Q, and device b. Here, the trust assessment node Q not only deploys a trust assessment module but can also deploy a reputation assessment module, a risk assessment module, and a threat assessment module. This method can at least include steps S201-S212:

[0093] Step S201: Control node P sends a remote verification request to device a.

[0094] Here, the remote verification request is a business request used to instruct device a to provide remote proof evidence. Since different types of devices require different parameters for trust assessment, to avoid device a feeding back redundant information that doesn't need assessment, the control node P in this embodiment can determine the parameters to be assessed for device a (i.e., the parameters required by device a for trust assessment). These parameters can be received from the trust assessment node Q or obtained by the control node P from a database (which stores parameter requirements corresponding to various device types); this is not limited here. Furthermore, the control node P can send a remote verification request to device a, which carries a list of evidence. This list of evidence can be determined by the control node P based on the parameters to be assessed for device a.

[0095] Step S202: Device a sends remote proof evidence to control node P.

[0096] Specifically, when device A receives a remote verification request, it can determine the remote proof evidence based on the list of evidence carried in the remote verification request. This remote proof evidence can include device A's device information (e.g., device ID, device type, or device manufacturer) and device A's hardware and software configuration information (e.g., model, production date, CPU / BIOS parameters, operating system type, version number, etc.).

[0097] Understandably, to ensure the credibility of the data provided by device a, when sending remote proof evidence to control node P, device a can also send the signature data corresponding to the remote proof evidence. This signature data can be obtained by device a signing the remote proof evidence based on a certificate, or it can be obtained by device a signing the remote proof evidence based on its private key. The private key of device a is determined by a node in the current network with public / private key configuration capabilities (e.g., trust evaluation node Q) in this embodiment of the application.

[0098] In the specific implementation of this application, data related to remote proof evidence is involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data shall comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0099] Step S203: Control node P obtains the context importance index of device a.

[0100] Specifically, after receiving remote proof of device a, control node P can extract the device type of device a from the remote proof. Then, based on the extracted device type, it evaluates the context of device a to obtain an importance index for the context of device a. This importance index can be either an importance level or an importance value; neither is limited here. The importance index of device a's context is obtained by control node P after evaluating the context of device a based on a context evaluation strategy.

[0101] For example, please refer to Table 1, which is a schematic table illustrating a method for evaluating device context according to an embodiment of this application. The schematic table may include multiple judgment criteria for the context evaluation strategy, with each judgment criterion corresponding to an importance index. As shown in Table 1:

[0102] Table 1

[0103] Step S204: Control node P sends a trust assessment request to trust assessment node Q.

[0104] The trust assessment request may include remote proof of device a and contextual importance metrics of device a.

[0105] It is worth noting that if the trust assessment request also includes the signature data corresponding to the remote proof evidence, the trust assessment node Q needs to verify the signature data. After successful verification, step S205 can be executed.

[0106] In step S205, the trust evaluation node Q determines the attribute evaluation result of device a based on the remote proof evidence of device a.

[0107] The attribute assessment results here can include assessment sub-results corresponding to the three device attributes, specifically reputation assessment results, risk assessment results, and threat assessment results.

[0108] The reputation assessment result can be the current assessment sub-result obtained by the reputation assessment module after assessing the reputation of device a based on the reputation assessment strategy (an assessment strategy associated with the device attribute of reputation). Optionally, this embodiment can also deploy a device reputation history database to include the historical assessment sub-results of reputation assessment in the device trust assessment. That is, the reputation assessment result can also be the result jointly determined based on the current assessment sub-result and the historical assessment sub-results stored in the database. This will not be limited here.

[0109] The reputation assessment result can be either a reputation level or a reputation value; neither will be limited here. For example, please refer to Table 2, which is a schematic table illustrating a method for reputation assessment provided in this application embodiment. This method schematic table may include multiple judgment criteria for reputation assessment strategies, as specifically shown in Table 2:

[0110] Table 2

[0111] The risk assessment result can be a sub-result obtained by the risk assessment module after assessing the risk of device a based on a risk assessment strategy (an assessment strategy associated with the device attribute of risk). For example, the risk assessment module determines the risk value of the device based on attributes such as the severity, probability, and detectability of the risk faced by the device. After determining the risk value of the device, the risk assessment result of device a is determined based on the risk range in which that risk value falls. This risk assessment result can be either a risk level or a risk value; neither will be limited here.

[0112] For example, the risk value can be determined by the following formula (1): Risk value = Severity * Probability of risk occurrence * Detectability (1)

[0113] Among them, the severity can range from [1, 3], with different values ​​representing different levels. For example, a value of 1 indicates low, a value of 2 indicates medium, and a value of 3 indicates high. The probability of risk occurrence can also range from [1, 3]. For example, a value of 1 indicates low, a value of 2 indicates medium, and a value of 3 indicates high. The detectability can also range from [1, 3]. For example, a value of 1 indicates easy to detect, a value of 2 indicates medium difficulty, and a value of 3 indicates difficult to detect.

[0114] For example, please refer to Table 3, which is a schematic table illustrating a method for risk assessment provided in an embodiment of this application. This method schematic table may include multiple risk intervals, which are obtained by dividing the range of risk values ​​(e.g., [1, 27]). It is understood that these risk intervals can be dynamically adjusted according to actual business conditions, and will not be limited here. The method schematic table may include multiple judgment criteria for risk assessment strategies, as shown in Table 3:

[0115] Table 3

[0116] The threat assessment result can be a sub-result obtained by the threat assessment module after assessing the threat of device a based on the threat assessment strategy (an assessment strategy associated with the device attribute of threat). This threat assessment result can be a threat level or a threat value; neither is limited here. For example, please refer to Table 4, which is a schematic table illustrating a method for threat assessment provided in this application embodiment. This method schematic table can include multiple judgment criteria for the threat assessment strategy, as shown in Table 4:

[0117] Table 4

[0118] To reduce deployment costs, the reputation assessment module, risk assessment module, and threat assessment module in this embodiment can all be deployed on the trust assessment node Q.

[0119] In step S206, the trust assessment node Q performs a trust assessment on device a based on the attribute assessment results of device a and the context importance index of device a, and obtains the trust assessment result of device a.

[0120] Specifically, the method for determining the trust assessment result can be found in the following formula (2):

[0121] Among them, symbols The specific operational logic of the operation needs to be determined based on the trust assessment strategy.

[0122] For ease of understanding, embodiments of this application may provide two different trust assessment strategies, specifically trust assessment strategy 1 and trust assessment strategy 2.

[0123] The trust assessment result determined by trust assessment strategy 1 can be the trust level of the device. For example, please refer to Table 5, which is a schematic table illustrating a method for trust assessment of a device provided in this application embodiment. This method schematic table may include multiple judgment criteria of trust assessment strategy 1. Specifically, as shown in Table 5:

[0124] Table 5

[0125] The trust assessment result determined by trust assessment strategy 2 can be the trust value of the device. For example, the specific determination method of trust assessment strategy 2 can be found in the following formula (3): Trust value = Reputation value * Importance value * Threat value * Risk value (3)

[0126] Step S207: Trust assessment node Q sends the trust assessment result of device a to control node P.

[0127] Here, the trust assessment result is taken as an example, specifically the trust level.

[0128] Step S208: Control node P sends the trust assessment result of device a to device a.

[0129] Step S209: Device a sends a first access request to control node P.

[0130] Here, the first access request is a service request generated by device a to access device b. This first access request may carry access information, including the device to be accessed (e.g., the device identifier of device b), the trust assessment result of device a, and the request content.

[0131] In step S210, the control node P determines whether to allow access based on the access information.

[0132] Since the devices to be accessed have different levels of security impact in the smart home network, different preset levels can be set for different devices in this application embodiment. For example, the preset level for lamps can be level 2, and the preset level for computers can be level 4.

[0133] When control node P receives access information, it can first determine the preset level corresponding to the device to be accessed (i.e., device b), and then compare the trust level in the trust assessment result with the preset level. If the trust level does not reach the preset level (e.g., level 3), it is determined that device a cannot access device b. In this case, a notification indicating access failure can be generated and sent back to device a. Optionally, if the trust assessment result indicates that the trust level of device a reaches the preset level, it is determined that device a can access device b. In this case, control node P can continue to execute the following step S211.

[0134] Step S211: Control node P sends a second access request to device b.

[0135] The second access request is a service request for accessing device b determined by the control node P. The second access request may carry the device identifier of device b and the request content.

[0136] In step S212, device b performs the corresponding operation based on the request content carried in the second access request.

[0137] Therefore, this application provides a method for trust assessment of devices in a smart home scenario. This method not only utilizes traditional centralized trust assessment methods but also incorporates remote authentication protocol technology to extract trust assessment data from the devices, effectively ensuring the reliability of the trust assessment data and making the final trust assessment results more reliable and accurate. Furthermore, this application incorporates the characteristics of smart homes, performing trust assessments of devices based on contextual importance indicators and various assessment sub-results (reputation, threat, risk, etc.), thereby making the trust assessment results more practical and effective.

[0138] It is understandable that before executing step S201, control node P often needs a triggering condition. This triggering condition may be that control node P detects that device a is accessing the network for the first time, or it may be other triggering conditions, which will not be limited here.

[0139] The trust assessment process under the above triggering conditions will be described below:

[0140] Please refer to Figure 3, which is an interactive diagram of a method for trust assessment provided in an embodiment of this application. As shown in Figure 3, this method can be jointly executed by device a, control node P, trust assessment node Q, and three attribute assessment modules. The trust assessment node Q can be equipped with trust assessment module 150, and the three attribute assessment modules can specifically include attribute assessment module 160, attribute assessment module 170, and attribute assessment module 180. This method can include at least steps S301-S318:

[0141] Step S301: Device a sends a registration request to control node P.

[0142] The registration request may include device information for device a, which may include device identifier, device type, and device manufacturer.

[0143] Understandably, the control node P can be used to receive various device types and corresponding parameters to be evaluated sent by the trust evaluation node. In order to improve the efficiency of subsequent trust evaluation, the control node P can associate and store the device type and its corresponding parameters to be evaluated, or associate and store the device type and its corresponding evidence list, which is determined based on the parameters to be evaluated.

[0144] This eliminates the need to repeatedly request trust evaluation nodes, thus greatly reducing network transmission overhead.

[0145] Therefore, after receiving the registration request from device a, control node P can locally search for whether there are any parameters (or evidence lists) to be evaluated that match the device type of device a. If a match is found, control node P does not need to repeatedly request the parameters from trust evaluation node Q, but can directly proceed to step S305, which can greatly reduce network transmission overhead. If no match is found, it means that control node P requests the parameters to be evaluated from trust evaluation node Q.

[0146] The determination of the trust evaluation node Q is related to the number of trust evaluation nodes connected in the current network. If there is a trust evaluation node in the current network, the control node P can directly use it as the trust evaluation node Q.

[0147] In a network with multiple trust evaluation nodes, control node P needs to select one as trust evaluation node Q. For example, control node P can select a trust evaluation node (e.g., the one with the strongest computing power) from among the multiple nodes based on the resource computing power of each node to perform trust evaluation on device a. Alternatively, when each trust evaluation node is responsible for the trust evaluation of devices in different regions, control node P determines the region to which device a's address information belongs, and can then select the trust evaluation node corresponding to that region as trust evaluation node Q.

[0148] Step S302: Control node P sends device information of device a to trust evaluation node Q.

[0149] Specifically, the control node P can send a parameter distribution request (i.e. a service request to determine the parameters to be evaluated) to the trust evaluation node Q. The parameter distribution request can carry the device information of device a.

[0150] In step S303, the trust evaluation node Q determines the parameters to be evaluated based on the device information of device a.

[0151] The parameters to be evaluated can be displayed in list form, set form, or other forms; no specific restrictions will be imposed here. When the parameters to be evaluated are displayed in list form, it can be called a trust evaluation parameter list.

[0152] For example, if device a is a lighting device in a smart home network, the parameters to be evaluated may include device identification, device type, manufacturer, model, and production date; if device a is an audio / video device in a smart home network, the parameters to be evaluated may include device identification, device type, device manufacturer, operating system type, and CPU / BIOS parameters.

[0153] Step S304: Trust evaluation node Q sends the parameters to be evaluated for device a to control node P.

[0154] In step S305, control node P determines the list of evidence that device a needs to provide through remote verification based on the parameters to be evaluated.

[0155] For example, when the parameters to be evaluated are presented in set form, the control node P can adaptively adjust the parameters (e.g., adjust the presentation format) and determine the adjusted parameters as the evidence list. Alternatively, when the parameters to be evaluated are presented in list form, the control node P can directly determine the parameters to be evaluated as the evidence list.

[0156] Step S306: Control node P sends a first remote authentication request to device a.

[0157] The first remote verification request includes a list of evidence so that device a can quickly extract the first remote proof evidence.

[0158] Step S307: Device a sends the first remote proof evidence to control node P.

[0159] Step S308: Control node P obtains the context importance index of device a.

[0160] Step S309: Control node P sends a first trust assessment request to trust assessment node Q.

[0161] The first trust assessment request may carry first trust assessment data for device a, which may include first remote proof of device a and contextual importance indicators of device a.

[0162] In step S310, the trust evaluation node Q sends a first evaluation request to the attribute evaluation module 160.

[0163] The first evaluation request (e.g., a reputation evaluation request) may carry reputation evaluation information (i.e., attribute evaluation information corresponding to the device attribute of reputation), which may specifically include device information such as device identity, device type, and manufacturer. This reputation evaluation information is extracted by the trust evaluation node Q from the remote proof evidence of device a.

[0164] Step S311, attribute evaluation module 160 sends evaluation sub-result 1 to trust evaluation node Q.

[0165] For example, after receiving the first evaluation request, the attribute evaluation module 160 can obtain the reputation information of device a from a database used to store reputation information (e.g., database D1 shown in Figure 1A above) based on the device information of device a. Then, the attribute evaluation module 160 can evaluate the reputation of device a according to the reputation evaluation strategy (e.g., the reputation evaluation strategy shown in Table 2 above) and the reputation information of device a, and obtain evaluation sub-result 1. Herein, evaluation sub-result 1 can be a reputation value.

[0166] In step S312, the trust evaluation node Q sends a second evaluation request to the attribute evaluation module 170.

[0167] The second assessment request (e.g., a risk assessment request) may carry risk assessment information (i.e., attribute assessment information corresponding to the device attribute of risk), which may specifically include device information (e.g., device identity, device type, and manufacturer) and hardware and software configuration information. This risk assessment information is extracted by the trust assessment node Q from the remote proof evidence of device a.

[0168] In step S313, the attribute evaluation module 170 sends the evaluation sub-result 2 to the trust evaluation node Q.

[0169] For example, after receiving the second assessment request, the attribute assessment module 170 can obtain the risk information of device a from a database used to store risk information (e.g., database D2 shown in Figure 1A above) based on the device information of device a. This risk information can indicate the severity, the probability of the risk occurring, and its detectability. Then, the attribute assessment module 170 can assess the risk of device a according to the risk assessment strategy (e.g., the risk assessment strategy shown in Table 3 above) and the risk information of device a, and obtain assessment sub-result 2. The assessment sub-result 2 can be a risk value.

[0170] In step S314, the trust evaluation node Q sends a third evaluation request to the attribute evaluation module 180.

[0171] The third assessment request (e.g., a threat assessment request) may carry threat assessment information (i.e., attribute assessment information corresponding to the device attribute of risk), which may specifically include device information (e.g., device identity, device type, and manufacturer) and hardware and software configuration information. This threat assessment information is extracted by the trust assessment node Q from the remote proof evidence of device a.

[0172] In step S315, the attribute evaluation module 180 sends the evaluation sub-result 3 to the trust evaluation node Q.

[0173] For example, after receiving the third assessment request, the attribute assessment module 180 can retrieve the threat information of device a from a database used to store threat information (e.g., database D2 shown in Figure 1A above) based on the device information of device a. This threat information can indicate whether device a has any known threats. Then, the attribute assessment module 180 can assess the threat of device a according to the threat assessment strategy (e.g., the threat assessment strategy shown in Table 4 above) and the threat information of device a, and obtain the assessment sub-result 3. This assessment sub-result can be a threat value.

[0174] Step S316: Trust assessment node Q performs trust assessment on device a based on the acquired data to obtain the initial trust assessment result of device a.

[0175] The acquired data may include the context importance index of device a, evaluation sub-result 1, evaluation sub-result 2, and evaluation sub-result 3. For example, the trust evaluation node Q can evaluate device a according to the trust evaluation strategy (e.g., trust evaluation strategy 2 shown in formula (3) above or trust evaluation strategy 1 shown in Table 5 above) and the acquired data to obtain the initial trust evaluation result of device a.

[0176] Step S317: Trust assessment node Q sends the initial trust assessment result of device a to control node P.

[0177] Step S318: Control node P sends the initial trust assessment result of device a to device a.

[0178] The specific implementation of steps S306-S318 can be found in the description of steps S201-S208 in the embodiment corresponding to Figure 2 above, and will not be repeated here.

[0179] It is understandable that, due to the dynamic nature of network security and system hardware and software configuration, trust management between network devices also has dynamic characteristics. Therefore, this application embodiment embeds a dynamic trust management method into smart home network security and trust management to adjust the network connection and data transmission of devices in a timely manner according to changes in the trust assessment results of devices.

[0180] In other words, when the trust assessment node Q determines that the trust assessment attribute of a device has changed, it will trigger the trust assessment node Q to re-evaluate the trust of the affected device to obtain a new trust assessment result (i.e., the target trust assessment result). In addition, the trust assessment node Q will also send the target trust assessment result to the control node P, so that the control node P can decide whether the affected device needs to leave the network or continue to remain in the current network based on the target trust assessment result. For details, please refer to the implementation methods corresponding to Figures 4-6 below.

[0181] Further, please refer to Figure 4, which is an interaction diagram of a method for dynamic trust management provided in an embodiment of this application. As shown in Figure 4, this method can be jointly executed by the affected device (e.g., device a), control node P, trust evaluation node Q, and M (e.g., 3) attribute evaluation modules. Here, trust evaluation node Q can be deployed with trust evaluation module 150, and the three attribute evaluation modules can specifically include attribute evaluation module 160, attribute evaluation module 170, and attribute evaluation module 180. This method can at least include steps S401-S408:

[0182] Step S401: Trust assessment node Q receives the first result update notification.

[0183] The first result update notification is used to indicate that N device attributes of the target object have changed, where N is a positive integer less than or equal to 3. In other words, this first result update notification can be used to indicate that at least one of the device attributes of the target object—reputation, risk, or threat—has changed. It is understood that if the number of objects (e.g., device manufacturers or device types) in the current network is represented by P, where P is a positive integer, then the target object can be any one of these P objects.

[0184] Furthermore, the first result update notification may also include second evaluation sub-results (i.e., evaluation sub-results determined after changes) corresponding to N device attributes of the target object. These N evaluation sub-results may include at least one of reputation evaluation results, risk evaluation results, or threat evaluation results. The reputation evaluation result is generated by the attribute evaluation module 160 when it detects a change in the target object's reputation; the risk evaluation result is generated by the attribute evaluation module 170 when it detects a change in the target object's risk; and the threat evaluation result is generated by the attribute evaluation module 180 when it detects a change in the target object's threat.

[0185] In step S402, the trust assessment node Q determines the affected target device cluster based on the target object.

[0186] Specifically, the trust assessment node Q can locate the affected devices based on the target object, and then add the affected devices to the target device cluster.

[0187] For example, if the current network includes 5 devices, they may specifically include device a (e.g., camera from manufacturer 1), device b (e.g., audio equipment from manufacturer 1), device c (e.g., camera from manufacturer 2), device d (e.g., lighting equipment from manufacturer 1), and device e (e.g., camera from manufacturer 3).

[0188] If the target object is a device type (e.g., a camera type), then the affected devices can be all cameras connected to the current network. In other words, the target device cluster determined by the trust assessment node Q can include device a, device c, and device e.

[0189] If the target is a device manufacturer (e.g., manufacturer 1), then the affected devices can include all devices of manufacturer 1 connected to the current network, as well as devices from other device manufacturers (also known as associated manufacturers) that are related to manufacturer 1. These associated manufacturers can be manufacturer 1's headquarters or branch offices, manufacturers belonging to the same management user group as manufacturer 1, or manufacturers with cooperative relationships with manufacturer 1; these will not be listed individually here. In other words, the target device cluster determined by the trust assessment node Q can include device a, device b, device d, and device e.

[0190] In one possible implementation, the trust evaluation node Q can also determine the device identifier of each affected device and generate a list of affected device IDs so that trust evaluation can be performed on each affected device in turn. For ease of explanation, the affected device in this application embodiment can be device a.

[0191] In step S403, the trust assessment node Q updates the attribute assessment result of device a, and based on the updated attribute assessment result, re-assesses the trust of device a to obtain the target trust assessment result of device a.

[0192] The attribute evaluation result of device a can include first evaluation sub-results corresponding to M device attributes. Specifically, since the first result update notification indicates that N device attributes of the target object have changed, this means that the current data of device a is still valid. That is, the trust evaluation node Q can directly update the first evaluation sub-results corresponding to the N device attributes of device a according to the N second evaluation sub-results in the first result update notification, obtaining N updated evaluation sub-results. Then, based on the N updated evaluation sub-results, the updated attribute evaluation result can be determined. Then, the trust evaluation node Q can re-evaluate the trust of device a based on the updated attribute evaluation result to obtain the target trust evaluation result of device a. Here, the first evaluation sub-result refers to the evaluation sub-result obtained after the previous evaluation of the device attributes of device a.

[0193] If N equals M, then the N updated evaluator results are directly used as the updated attribute evaluation results. If N is less than M, then the N updated evaluator results and (MN) first evaluator results are determined as the updated attribute evaluation results.

[0194] For example, if device a has M first evaluation sub-results including reputation evaluation result (e.g., reputation value 0.75), risk evaluation result (e.g., risk value 1), and threat evaluation result (e.g., threat value 1), and the first result update notification has N evaluation sub-results including reputation evaluation result (e.g., reputation value 0.5) and risk evaluation result (e.g., risk value 0.5), then the trust evaluation node Q can directly use the reputation evaluation result in the first result update notification as the new reputation evaluation result of device a, and use the risk evaluation result in the first result update notification as the new risk evaluation result of device a. Therefore, the new reputation evaluation result (e.g., reputation value 0.5), the new risk evaluation result (e.g., risk value 0.5), and the original threat evaluation result (e.g., threat value 1) can be determined as the updated attribute evaluation result of device a.

[0195] Then, the trust assessment node Q can reassess the trust of device a based on the updated attribute assessment results and the context importance index of device a, referring to the trust assessment method 1 or trust assessment method 2 mentioned above, to obtain the current trust assessment result of device a, and then obtain the target trust assessment result of device a based on the current trust assessment result.

[0196] For example, trust assessment node Q can directly determine the current trust assessment result as the target trust assessment result for device a. Of course, in order to improve the accuracy of trust assessment, trust assessment node Q can also obtain the historical trust assessment results of device a from the database (e.g., the database D1 shown in Figure 1A above) based on the device information of device a, and then determine the target trust assessment result of device a based on the historical trust assessment results and the current trust assessment result.

[0197] Furthermore, the trust assessment node Q can compare the target trust assessment result of device a with the initial trust assessment result of device a. If the target trust assessment result of device a is the same as the initial trust assessment result, it means that the trust assessment result of device a has not changed. If the target trust assessment result of device a is different from the initial trust assessment result, it means that the trust assessment result of device a has changed. In this case, step S404 continues to be executed.

[0198] Step S404: If the target trust assessment result of device a is different from the initial trust assessment result of device a, then the trust assessment node Q determines the control node P corresponding to device a.

[0199] Specifically, the trust evaluation node Q can identify the control node that controls access permissions to device a in the current network as control node P, and then obtain the node address of control node P, such as a first address (e.g., Internet Protocol Address, IP address) or a second address (e.g., Uniform Resource Locator, URL).

[0200] In step S405, the trust evaluation node Q sends an evaluation result update notification to the control node P.

[0201] The updated notification of the assessment results may include the device identifier of device a and the target trust assessment result of device a.

[0202] Step S406: Control node P determines whether device a should remain in the network based on the target trust assessment result of device a.

[0203] For example, in this application embodiment, different trust thresholds can be set for each device. When the trust assessment result of a device indicates that it has reached the corresponding trust threshold, the device is considered a trusted device and can continue to remain in the network. When the trust assessment result of a device indicates that it has not reached the corresponding trust threshold, the device is considered an untrusted device and needs to leave the current network.

[0204] Step S407: If it is determined that device a will remain in the network, then send the target trust assessment result of device a to device a.

[0205] In step S408, if it is determined that device a cannot remain in the network, a device de-network message is sent to device a.

[0206] The device disconnection message may include an instruction to instruct device a to disconnect from the current network.

[0207] In this embodiment, the first result update notification indicates that N device attributes of the target object have changed. This means that one or more device attributes of the target object (a device manufacturer or device type) in terms of reputation, risk, or threat may change. This triggers the trust assessment node to re-evaluate the affected device. It is understood that when the first result update notification indicates that N device attributes of the target object have changed, the trust assessment node Q does not need to evaluate each of the M first assessment sub-results in the attribute assessment results (M first assessment sub-results) of device a. Instead, it directly updates the first assessment sub-results corresponding to the N device attributes of device a sequentially based on the N first assessment sub-results in the first result update notification. This not only saves computational resources for trust assessment but also improves the efficiency of trust assessment.

[0208] Further, please refer to Figure 5, which is an interactive diagram of a method for dynamic trust management provided in an embodiment of this application. As shown in Figure 5, this method can be jointly executed by the affected device (e.g., device a), control node P, trust evaluation node Q, and M (e.g., 3) attribute evaluation modules. Here, trust evaluation node Q can be deployed with trust evaluation module 150, and the three attribute evaluation modules can specifically include attribute evaluation module 160, attribute evaluation module 170, and attribute evaluation module 180. This method can at least include steps S501-S508:

[0209] Step S501: Trust assessment node Q receives the second result update notification.

[0210] The second result update notification is used to indicate a change in the assessment strategy associated with the device attributes. This assessment strategy can be at least one of M assessment strategies, which may specifically include reputation assessment strategies, risk assessment strategies, and threat assessment strategies. The second result update notification may include the affected device manufacturer or the affected device type.

[0211] Step S502, the trust assessment node Q determines the affected target device cluster.

[0212] Specifically, the trust assessment node Q locates the affected device manufacturers or types based on the updated notification of the second result, and then adds the affected devices to the target device cluster. The method for determining the affected devices can be found in the specific implementation described in step S402 above, and will not be limited thereto.

[0213] In one possible implementation, the trust assessment node Q can also determine the device identifier of each affected device and generate a list of affected device IDs so that trust assessment can be performed again on each affected device in turn.

[0214] Step S503: Trust assessment node Q determines the affected control node.

[0215] Specifically, if there is one control node in the current network, the trust evaluation node Q can directly identify that control node as the affected control node. Optionally, if there are multiple control nodes in the current network, the trust evaluation node Q needs to identify the affected control node based on the affected device. The affected control node may include control node P.

[0216] For example, when multiple control nodes exist in the current network, to facilitate the trust evaluation node Q in quickly finding the affected control node, the trust evaluation node Q in this embodiment can store a schematic table representing the control relationship between devices and control nodes. Further, please refer to Table 6, which is a schematic table representing control relationships provided in this embodiment. For ease of explanation, this embodiment uses three control nodes as an example, specifically including control node P1, control node P2, and control node P3. Five devices can be used as an example, specifically including device a, device b, device c, device d, and device e.

[0217] Table 6

[0218] Among them, control node P1 can be used to control the access permissions of device a and device b, control node P2 can be used to control the access permissions of device c, and control node P3 can be used to control the access permissions of device d and device e.

[0219] It should be noted that, as shown in Table 6, the table may include the device names and control node names in the current network. The items shown in Table 6 are only a reference format. In actual business scenarios, other items (such as device identifiers or control node identifiers) can be created according to requirements. This application embodiment does not limit the specific form of Table 6.

[0220] For example, when the target device cluster includes devices a, b, and d, the trust assessment node Q can search in Table 6 above to identify both control nodes P1 and P3 as affected control nodes. In this case, the trust assessment node Q needs to generate a reassessment notification for control node P1, which may include the device identifiers of devices a and b, and also a reassessment notification for control node P3, which may include the device identifier of device d.

[0221] In step S504, the trust evaluation node Q sends a re-evaluation notification to the control node P.

[0222] The reassessment notification may include the device identifier of the affected device corresponding to control node P. Here, the affected device can be device a, for example.

[0223] Step S505: Repeat steps S306-S317 in the embodiment corresponding to Figure 3 above to initiate the re-evaluation process of device a.

[0224] For example, control node P needs to send a second remote verification request to device a, which includes a list of evidence. Upon receiving the second remote verification request, device a extracts second remote proof evidence based on the evidence list in the request and sends this evidence to control node P. Control node P obtains the context importance index of device a, and can then determine the second remote proof evidence and the context importance index of device a as the second trust assessment data for device a. At this time, control node P sends a second trust assessment request to trust assessment node Q, carrying the second trust assessment data for device a.

[0225] Furthermore, the trust evaluation node Q can send a new first evaluation request to the attribute evaluation module 160 to receive a new evaluation sub-result 1 (i.e., updated evaluation sub-result 1) returned by the attribute evaluation module 160. Similarly, the trust evaluation node Q can also send a new second evaluation request to the attribute evaluation module 170 to receive a new evaluation sub-result 2 (i.e., updated evaluation sub-result 2) returned by the attribute evaluation module 170. The trust evaluation node Q can also send a new third evaluation request to the attribute evaluation module 180 to receive a new evaluation sub-result 3 (i.e., updated evaluation sub-result 3) returned by the attribute evaluation module 180 to the trust evaluation node Q. In this embodiment, updated evaluation sub-result 1, updated evaluation sub-result 2, and updated evaluation sub-result 3 can be collectively referred to as the updated attribute evaluation result.

[0226] Then, the trust assessment node Q can reassess the trust of device a based on the context importance index in the second trust assessment data and the updated attribute assessment results, and obtain the target trust assessment result of device a.

[0227] Step S506: Control node P determines whether device a should remain in the network based on the target trust assessment result of device a.

[0228] Step S507: If it is determined that device a will remain in the network, then the control node P sends the target trust assessment result of device a to device a.

[0229] Step S508: If it is determined that device a cannot remain in the network, then the control node P sends a device de-network message to device a.

[0230] The specific implementation of steps S506-S508 can be found in the description of steps S406-S408 in the embodiment corresponding to Figure 4 above, and will not be repeated here.

[0231] In this embodiment of the application, the second result update notification indicates a change in the evaluation strategy. This means that the attribute evaluation module that sent the second result update notification is no longer able to update the corresponding attribute evaluation result based on its own stored data. Therefore, it is necessary to require the device to restart the trust evaluation. This process combines remote proof protocol technology, that is, by re-extracting the second trust evaluation data from device a, the device attributes of device a are evaluated more accurately.

[0232] The method provided in the embodiments of this application will now be described from the perspective of a single network device, with reference to the accompanying drawings.

[0233] Further, please refer to Figure 6, which is a flowchart illustrating a dynamic trust assessment provided in an embodiment of this application. As shown in Figure 6, this method can be executed by a trust assessment node, which can be the trust assessment node Q shown in Figure 1A or Figure 2 above. The method may include at least steps S601-S603:

[0234] Step S601: When the device trust assessment attribute changes, identify the affected device that matches the device information of the first device.

[0235] Here, the device trust assessment attributes can be N device attributes corresponding to the target object, and the target object belongs to P objects. The objects can refer to the device manufacturer or device type, N is a positive integer less than or equal to M, and P is a positive integer.

[0236] When the target is an equipment manufacturer, the affected equipment here refers to equipment manufactured by the target in the current network, or equipment manufactured by other entities that are related to the target. These other entities can refer to: the target's headquarters or branch offices, manufacturers under the same management user as the target, or manufacturers with a cooperative relationship with the target. Of course, other relationships are also possible, but they will not be listed here.

[0237] For example, in this embodiment of the application, the P objects can be 4 equipment manufacturers, specifically including manufacturer 1, manufacturer 2, manufacturer 3 and manufacturer 4. If the N equipment attributes corresponding to the target object include the reputation of manufacturer 1 and the risk of manufacturer 1, then the equipment trust assessment attributes change, which means that the reputation of manufacturer 1 and the risk of manufacturer 1 have both changed. At this time, the affected equipment determined by the trust assessment node Q is: the equipment of manufacturer 1, or the equipment of other equipment manufacturers that are related to manufacturer 1, etc.

[0238] When the target object is a device type, the affected device here refers to the device corresponding to the target object in the current network.

[0239] For example, the P objects in this application embodiment can be categorized into two device types, specifically camera type and lighting device type. If the N device attributes corresponding to the target object include the reputation of the camera type, then the device trust assessment attribute changes, meaning that the reputation of the camera type has changed. At this time, the trust assessment node Q needs to determine that the affected device is all cameras in the current network.

[0240] In one possible implementation, the device trust assessment attribute here can also be an assessment strategy associated with the device attribute. This assessment strategy can be at least one of M assessment strategies, which may specifically include reputation assessment strategies, risk assessment strategies, and threat assessment strategies. The affected device here is determined based on the type of affected device or the manufacturer of the affected device.

[0241] It is understandable that if the trust assessment node does not deploy the attribute assessment module, it means that the node with the attribute assessment module (i.e., the attribute assessment node) periodically detects the device attributes of the device trust assessment attributes. When it detects that the device trust assessment attributes have changed, it will send a result update notification to the trust assessment node to inform the trust assessment node to reassess the affected devices in the current network. The result update notification is either the first result update notification in the embodiment corresponding to Figure 4 above or the second result update notification in the embodiment corresponding to Figure 5 above.

[0242] To facilitate the trust assessment node's rapid identification of the cause of the result change, the trust assessment node can also receive a change identifier sent by the target attribute assessment node. Here, the target attribute assessment node refers to the node used to assess a first target device attribute, which is any one of M device attributes. The change identifier is either a first identifier or a second identifier. The first identifier indicates a change in the first target device attribute of the target object, while the second identifier indicates a change in the assessment strategy associated with the first target device attribute.

[0243] For example, if the device trust assessment attributes are changes in the reputation and risk of the target object, and the reputation of the target object is assessed by the reputation assessment node and the risk of the target object is assessed by the risk assessment node, then the trust assessment node can receive change flags from the reputation assessment node and the threat assessment node, respectively.

[0244] Optionally, if the trust assessment node is equipped with an attribute assessment module, it means that the trust assessment node needs to periodically check the device trust assessment attributes. When it detects that the device trust assessment attributes have changed, it will reassess the affected devices in the current network.

[0245] Step S602: Update the attribute evaluation results of the affected devices.

[0246] The trust assessment result of the affected device is determined by the first assessment sub-results corresponding to M device attributes, where M is a positive integer. These first assessment sub-results are evaluated based on the first remote proof evidence in the first trust assessment data, which was obtained during the previous assessment of the affected device's attributes. Therefore, before updating the attribute assessment results of the affected device, it is necessary to determine whether the first trust assessment data of the affected device is valid.

[0247] For example, if the change in device trust assessment attributes means that N device attributes of the target object have changed, then the trust assessment node does not need to re-acquire the trust assessment data of the affected device. Instead, it can determine the second assessment sub-results corresponding to the N device attributes of the target object, and then update the first assessment sub-results corresponding to the N device attributes of the affected device based on the N second assessment sub-results. For specific implementation, please refer to the description of step S403 in the embodiment corresponding to Figure 4 above, which will not be repeated here.

[0248] If the device trust assessment attribute changes, it means that the assessment strategy associated with the device attribute changes. This means that the trust assessment node cannot re-evaluate the affected device based on the data stored in the current database. Instead, it needs to re-obtain the second trust assessment data of the affected device based on the device information of the affected device. Based on the second remote proof evidence in the second trust assessment data, it can determine the updated assessment sub-results corresponding to the M device attributes of the affected device.

[0249] For example, the trust assessment node can determine the parameters to be assessed for the affected device based on the device information of the affected device. These parameters can be used to instruct the affected device to provide second remote proof evidence. Further, the trust assessment node can determine a target control node (e.g., control node P in the embodiment corresponding to Figure 5 above) for controlling access to the affected device, and send the parameters to be assessed and the device information of the affected device to the target control node. Upon receiving the parameters to be assessed, the target control node can determine the list of evidence that the affected device needs to provide through remote proof, and send the list of evidence to the affected device.

[0250] In one possible implementation, upon receiving the evidence list, the affected device can quickly extract the second remote proof evidence and send it to the target control node. Upon receiving the second remote proof evidence, the target control node can determine the affected device's second trust assessment data, which may include the second remote proof evidence and contextual importance indicators of the affected device. Upon receiving the second trust assessment data, the trust assessment node can directly determine the updated assessment sub-results corresponding to the affected device's M device attributes based on the second remote proof evidence.

[0251] In another possible implementation, upon receiving the evidence list, the affected device can quickly extract the second remote proof evidence and determine the signature data corresponding to it. For example, the affected device needs to determine the first digest information corresponding to the second remote proof evidence. This first digest information can be obtained by hashing the second remote proof evidence using a certain digest algorithm. Further, the affected device signs the first digest information using its private key to obtain the signature data corresponding to the second remote proof evidence, and then sends the second remote proof evidence and its corresponding signature data to the target control node.

[0252] Then, the target control node can determine the second trust assessment data for the affected device and send it to the trust assessment node. This second trust assessment data may include the context importance index of the affected device, the second remote proof evidence, and the signature data corresponding to the second remote proof evidence. Upon receiving the second trust assessment data, the trust assessment node can verify the signature data corresponding to the second remote proof evidence. After successful verification, based on the second remote proof evidence, it determines the update assessment sub-results corresponding to the M device attributes of the affected device.

[0253] For example, a trust evaluation node can obtain the public key of the affected device and then decrypt the signature data based on that public key to obtain the first digest information. Then, the trust evaluation node can use the same digest algorithm as the affected device to hash the second remote proof evidence to obtain the second digest information. At this point, the trust evaluation node can compare the first digest information with the second digest information. If the first digest information matches the second digest information, the trust evaluation node can determine that the verification was successful; if the first digest information does not match the second digest information, the trust evaluation node can determine that the verification failed.

[0254] Understandably, different modules are deployed within the trust assessment node, and therefore, the methods by which it determines and updates the assessment sub-results also differ, as described in detail below:

[0255] If the trust assessment node has not deployed the attribute assessment module, then the trust assessment node needs to request the node with the attribute assessment module to reassess the attributes of the M devices.

[0256] For example, a trust evaluation node can determine a first target device attribute from M device attributes, and then extract the first attribute evaluation information corresponding to the first target device attribute from the second remote proof evidence. Further, the trust evaluation node can send the first attribute evaluation information to the target attribute evaluation node (i.e., the node used to evaluate the first target device attribute), so that the target attribute evaluation node can re-evaluate the first target device attribute of the affected device based on the first attribute evaluation information, obtaining an updated evaluation sub-result corresponding to the first target device attribute. Then, the trust evaluation node can receive the updated evaluation sub-result returned by the target attribute evaluation node.

[0257] As shown in Figure 3, if the first target device attribute is reputation, the trust assessment node can refer to the description of steps S310-S311 above to extract the first attribute assessment information (i.e., the new reputation assessment information) from the second remote proof evidence. Then, the node where the attribute assessment module 160 is located can be determined as the target attribute assessment node, and the new reputation assessment information can be sent to it so that the target attribute assessment node can reassess the reputation of the affected device based on the new reputation assessment information and obtain the updated assessment sub-result (i.e., the new assessment sub-result 1) corresponding to the reputation.

[0258] Similarly, the trust assessment node can sequentially obtain the updated assessment sub-results corresponding to risks (i.e., the new assessment sub-result 2) and threats (i.e., the new assessment sub-result 3).

[0259] If the trust assessment node is equipped with an attribute assessment module, it can directly reassess each of the M device attributes. For example, the trust assessment node can determine the second target device attribute from the M device attributes, and then extract the second attribute assessment information corresponding to the second target device attribute from the second remote proof evidence. Then, the trust assessment node can directly reassess the second target device attribute of the affected device based on the second attribute assessment information and the assessment strategy associated with the second target device attribute, obtaining an updated assessment sub-result corresponding to the second target device attribute.

[0260] For example, if the second target device attribute is reputation, the trust assessment node can extract the second attribute assessment information (i.e., the new reputation assessment information) from the second remote proof evidence. Then, it can directly reassess the second target device attribute of the affected device based on the second attribute assessment information and the assessment strategy associated with the second target device attribute (e.g., the reputation assessment strategy shown in Table 2 above) to obtain the current assessment sub-result. Furthermore, the trust assessment node can determine the updated assessment sub-result corresponding to the second target device attribute based on the current assessment sub-result.

[0261] Understandably, the trust assessment node can determine the current assessment sub-result as the updated assessment sub-result corresponding to the second target device attribute. Optionally, in order to improve the accuracy of reputation assessment, the trust assessment node can also obtain the historical assessment sub-result corresponding to the second target device attribute based on the device information of the affected device in the second attribute assessment information. The historical assessment sub-result can be stored in the device reputation history database, and then the updated assessment sub-result corresponding to the second target device attribute can be determined based on the current assessment sub-result and the historical assessment sub-result.

[0262] The updated evaluation sub-result corresponding to the second target device attribute can be obtained by averaging the current evaluation sub-result and the historical evaluation sub-result, or by weighted averaging the current evaluation sub-result and the historical evaluation sub-result. No limitation will be imposed here.

[0263] Step S603: Based on the updated attribute evaluation results, re-evaluate the trust of the affected devices to obtain the target trust evaluation results of the affected devices.

[0264] Specifically, the trust assessment node can determine the contextual importance index of the affected device. This importance index is sent by the target control node, which controls the access permissions of the affected device. Further, the trust assessment node can re-evaluate the affected device's trust based on the updated attribute assessment results and the importance index, obtaining the current trust assessment result for the affected device. This current trust assessment result can be the trust assessment result obtained using Trust Assessment Strategy 1 or Trust Assessment Strategy 2 described above. Then, based on the current trust assessment result, the trust assessment node can determine the target trust assessment result for the affected device. This target trust assessment result is used to adjust the access permissions of the affected device.

[0265] It should be understood that the trust assessment node can directly determine the current trust assessment result as the target trust assessment result for the affected device. Of course, to improve the accuracy of the trust assessment, the trust assessment node can also obtain the historical trust assessment results of the affected device based on the device information. These historical trust assessment results can be stored in a database (e.g., database D1 shown in Figure 1A above). Furthermore, the trust assessment node can determine the target trust assessment result for the affected device based on both the historical and current trust assessment results.

[0266] The target trust assessment result can be obtained by calculating and processing historical trust assessment results and current trust assessment results. This calculation and processing may be an averaging process, a weighted average process, or other methods; no specific limitations will be imposed here.

[0267] The specific implementation of steps S601-S603 can be found in the description of steps S401-S408 in the embodiment corresponding to Figure 4 above or steps S501-S508 in the embodiment corresponding to Figure 5 above, and will not be repeated here.

[0268] Further, please refer to Figure 7, which is a schematic diagram of the structure of a trust assessment device provided in an embodiment of this application. As shown in Figure 7, the trust assessment device 1 may include at least one of a determination module 701, an update module 702, and an assessment module 703. These units can perform the corresponding functions of the devices in the above method embodiments.

[0269] In one possible implementation, the trust assessment device 1 can be used to implement the function of the trust assessment node Q in FIG1A.

[0270] Specifically, the determination module 701 is used to determine the affected device when the device trust assessment attribute changes; the update module 702 is used to update the attribute assessment result of the affected device; and the assessment module 703 is used to re-evaluate the trust of the affected device based on the updated attribute assessment result to obtain the target trust assessment result of the affected device, which is used to adjust the access permissions of the affected device.

[0271] The specific implementation methods of the determining module 701, the updating module 702, and the evaluation module 703 can be found in the description of steps S601-S603 in the embodiment corresponding to Figure 6 above, and will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated here.

[0272] Further, please refer to Figure 8, which is a second structural schematic diagram of a trust assessment device provided in an embodiment of this application. As shown in Figure 8, the trust assessment device 2 may include at least one of a determination module 801, an update module 802, an assessment module 803, and a transceiver module 804. These units can perform the corresponding functions of the devices in the above method embodiments.

[0273] In one possible implementation, the trust assessment device 2 can be used to implement the function of the trust assessment node Q in FIG1A.

[0274] Specifically, the determination module 801 is used to determine the affected device when the device trust assessment attribute changes; the update module 802 is used to update the attribute assessment result of the affected device; and the assessment module 803 is used to re-evaluate the trust of the affected device based on the updated attribute assessment result to obtain the target trust assessment result of the affected device, which is used to adjust the access permissions of the affected device.

[0275] In one implementation, the device trust assessment attribute is N device attributes of the target object, the target attribute belongs to P objects, and the object refers to the device manufacturer or device type, where P and N are both positive integers.

[0276] In one implementation, the attribute evaluation result of the affected device includes first evaluation sub-results corresponding to M device attributes, where M is a positive integer greater than or equal to N. The first evaluation sub-results are obtained after evaluating the first remote proof evidence in the first trust evaluation data, which was obtained when the device attributes of the affected device were evaluated last time. The update module 802 is used to update the attribute evaluation result of the affected device and includes a first determining unit 8021 and an updating unit 8022.

[0277] The first determining unit 8021 is used to determine the second evaluation sub-results corresponding to the N device attributes of the target object respectively; the updating unit 8022 is used to update the first evaluation sub-results corresponding to the N device attributes of the affected device based on the N second evaluation sub-results respectively.

[0278] In one implementation, the device trust assessment attribute is an assessment strategy associated with device attributes.

[0279] In one implementation, the update module 802 is used to update the attribute evaluation results of the affected device, and includes: an acquisition unit 8023 and a second determination unit 8024.

[0280] The acquisition unit 8023 is used to reacquire the second trust assessment data of the affected device based on the device information of the affected device, the second trust assessment data including the second remote proof evidence; the second determination unit 8024 is used to determine the update assessment sub-results corresponding to the M device attributes of the affected device based on the second remote proof evidence.

[0281] In one implementation, the acquisition unit 8023 is used to reacquire the second trust assessment data of the affected device based on the device information of the affected device, including: a first determination subunit 80231 and a first transceiver subunit 80232.

[0282] The first determining subunit 80231 is configured to determine parameters to be evaluated based on the device information of the affected device, the parameters to be evaluated being used to instruct the affected device to provide the second remote proof evidence; the first determining subunit 80231 is also configured to determine a target control node for controlling access permissions to the affected device; the first transceiver subunit 80232 is configured to send the parameters to be evaluated and the device information of the affected device to the target control node; the first transceiver subunit 80232 is also configured to receive second trust evaluation data sent by the target control node.

[0283] In one implementation, the M device attributes include a first target device attribute; the second determining unit 8024 is used to determine the update evaluation sub-results corresponding to the M device attributes of the affected device based on the second remote proof data, including: a first extraction sub-unit 80241 and a second transceiver sub-unit 80242.

[0284] The first extraction subunit 80241 is used to extract the first attribute evaluation information corresponding to the first target device attribute from the second remote proof data; the second transceiver subunit 80242 is used to send the first attribute evaluation information to the target attribute evaluation node corresponding to the first target device attribute; the second transceiver subunit 80242 is also used to receive the updated evaluation sub-result returned by the target attribute evaluation node.

[0285] In one implementation, the M device attributes include a second target device attribute; the second determining unit 8024 is used to determine the update evaluation sub-results corresponding to the M device attributes of the affected device based on the second remote proof data, including: a second extraction sub-unit 80243 and an evaluation sub-unit 80244.

[0286] The second extraction subunit 80243 is used to extract the second attribute evaluation information corresponding to the second target device attribute from the second remote proof data; the evaluation subunit 80244 is used to re-evaluate the second target device attribute of the affected device based on the second attribute evaluation information and the evaluation strategy associated with the second target device attribute, and obtain the updated evaluation sub-result corresponding to the second target device attribute.

[0287] In one implementation, the second target device attribute is reputation; the evaluation subunit 80244 is used to re-evaluate the second target device attribute of the affected device based on the second attribute evaluation information and the evaluation strategy associated with the second target device attribute, to obtain an updated evaluation sub-result corresponding to the second target device attribute, including: the evaluation subunit 80244 is specifically used to re-evaluate the second target device attribute of the affected device based on the second attribute evaluation information and the evaluation strategy associated with the second target device attribute, to obtain a current evaluation sub-result; the evaluation subunit 80244 is specifically used to obtain a historical evaluation sub-result corresponding to the second target device attribute based on the device information of the affected device; the evaluation subunit 80244 is specifically used to determine an updated evaluation sub-result corresponding to the second target device attribute based on the current evaluation sub-result and the historical evaluation sub-result.

[0288] In one implementation, the evaluation module 803 is used to re-evaluate the trust of the affected device based on the updated attribute evaluation results to obtain the target trust evaluation result of the affected device, including: a third determination unit 8031 ​​and an evaluation unit 8032.

[0289] The third determining unit 8031 ​​is used to determine the context importance index of the affected device; the evaluation unit 8032 is used to re-evaluate the trust of the affected device based on the updated attribute evaluation result and the importance index to obtain the current trust evaluation result of the affected device; the third determining unit 8031 ​​is also used to determine the target trust evaluation result of the affected device based on the current trust evaluation result of the affected device.

[0290] In one implementation, the importance indicator is sent by a target control node, which controls the access permissions of the affected device.

[0291] In one implementation, the third determining unit 8031 ​​is further configured to determine the target trust assessment result of the affected device based on the current trust assessment result of the affected device, including: the third determining unit 8031 ​​is specifically configured to obtain the historical trust assessment result of the affected device based on the device information of the affected device; the third determining unit 8031 ​​is specifically configured to determine the target trust assessment result of the affected device based on the historical trust assessment result and the current trust assessment result.

[0292] In one implementation, the trust assessment device further includes a transceiver module 804, configured to receive a change identifier sent by a target attribute assessment node, wherein the target attribute assessment node is configured to assess a first target device attribute, and the change identifier is either a first identifier or a second identifier, wherein the first identifier is configured to indicate that the first target device attribute of the target object has changed, and the second identifier is configured to indicate that the assessment strategy associated with the first target device attribute has changed.

[0293] The specific implementation methods of the determining module 801, updating module 802, evaluation module 803, and transceiver module 804 can be found in the description of steps S601-S603 in the embodiment corresponding to Figure 6 above, and will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated here.

[0294] Further, please refer to Figure 9, which is a schematic diagram of the structure of a trust assessment device provided in an embodiment of this application. As shown in Figure 9, specifically, the trust assessment device 3 can be used to implement the function of the trust assessment node Q in Figure 1A.

[0295] Referring to Figure 9, the trust evaluation device 3 includes all or part of the hardware in a processor 901, a communication interface 902, and a memory 903. The trust evaluation device 3 may have one or more processors 901; Figure 9 shows an example of one processor. In this embodiment, the processor 901, communication interface 902, and memory 903 can be connected via a bus system or other means; Figure 9 shows an example of connection via a bus system 904.

[0296] Processor 901 may be a central processor (CPU), a network processor (NP), or a combination of a CPU and an NP. Processor 901 may also include hardware chips. These hardware chips may be application-specific integrated circuits (ASICs), programmable logic devices (PLDs), or combinations thereof. The PLDs may be complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), generic array logic (GALs), or any combination thereof.

[0297] The communication interface 902 is used to receive and send data. Specifically, the communication interface 902 may include a receiving interface and a sending interface. The receiving interface can be used to receive data, and the sending interface can be used to send data. There can be one or more communication interfaces 902.

[0298] Memory 903 may include volatile memory, such as random-access memory (RAM); memory 3003 may also include non-volatile memory, such as flash memory, hard disk drive (HDD), or solid-state drive (SSD); memory 903 may also include combinations of the above types of memory.

[0299] Optionally, the memory 903 stores an operating system and programs, executable modules, or data structures, or subsets thereof, or extended sets thereof. The programs may include various operation instructions for implementing various operations. The operating system may include various system programs for implementing various basic services and handling hardware-based tasks. The processor 901 can read the programs from the memory 903 to implement the methods provided in the embodiments of this application.

[0300] The memory 903 can be a storage device in the trust evaluation device 3, or it can be a storage device independent of the trust evaluation device 3.

[0301] Bus system 904 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Bus system 3004 can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent them in Figure 9, but this does not mean that there is only one bus or one type of bus.

[0302] In some possible embodiments, the trust assessment device described above can be implemented as a virtualized device. For example, a virtualized device can be a virtual machine (VM) running a program with trust assessment capabilities, deployed on a hardware device (e.g., a physical server). A virtual machine refers to a complete computer system simulated by software, possessing full hardware system functionality and running in a completely isolated environment. A virtual machine can be configured as a trust assessment device. For example, the functionality of the trust assessment device can be implemented based on a general-purpose physical server combined with network functions virtualization (NFV) technology. Those skilled in the art can virtualize a trust assessment device with the above-described functions on a general-purpose physical server using NFV technology by reading this application; further details are omitted here.

[0303] It should be noted that the trust evaluation device mentioned in the embodiments of this application can be a terminal device, a server, or a chip used to implement the method of this application; the embodiments of this application do not impose specific limitations. When the trust evaluation device is a chip, the interface circuit in the chip may be used to perform receiving or sending operations, and the processor in the chip may be used to perform processing operations.

[0304] In one specific implementation, this application also provides a chip, including a processor and an interface circuit. The interface circuit is used to receive instructions and transmit them to the processor. The processor can be used to execute the operations of each trust assessment device in the above-described trust assessment method. The processor is coupled to a memory, which stores programs or instructions. When the program or instructions are executed by the processor, the chip implements the method in any of the above-described method embodiments.

[0305] Optionally, the chip may contain one or more processors. These processors can be implemented in hardware and / or software. When implemented in hardware, the processor may be a logic circuit, an integrated circuit, etc. When implemented in software, the processor may be a general-purpose processor, implemented by reading software code stored in memory.

[0306] Optionally, the chip may contain one or more memories. These memories may be integrated with the processor or separated from it; this application does not limit this. For example, the memory may be a non-transient processor, such as a read-only memory (ROM), which may be integrated with the processor on the same chip or disposed on different chips. This application does not specifically limit the type of memory or the arrangement of the memory and processor.

[0307] For example, the chip can be a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a system on chip (SoC), a central processor unit (CPU), a network processor (NP), a digital signal processor (DSP), a micro controller unit (MCU), a programmable logic device (PLD), or other integrated chips.

[0308] This application also provides a computer-readable storage medium, including instructions or a computer program, which, when run on a processor, causes the processor to execute the trust evaluation method provided in the above embodiments.

[0309] This application also provides a computer program product containing instructions or computer programs, which, when run on a processor, causes a trust evaluation device to execute the trust evaluation method provided in the above embodiments.

[0310] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

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

[0312] In the 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 business 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, indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0313] 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 the embodiments of this application, depending on actual needs.

[0314] Those skilled in the art will recognize that, in one or more of the examples above, the services described in this application can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these services can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transfer of computer programs from one place to another. Storage media can be any available medium accessible to general-purpose or special-purpose computers.

[0315] The above specific embodiments further illustrate the purpose, technical solution and beneficial effects of this application. It should be understood that the above are only specific embodiments of this application.

[0316] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A trust assessment method, characterized in that, The method includes: When device trust assessment attributes change, identify the affected devices; The attribute evaluation results of the affected devices are updated; Based on the updated attribute evaluation results, the affected device is re-evaluated to obtain the target trust evaluation result of the affected device. The target trust evaluation result is used to adjust the access permissions of the affected device.

2. The method according to claim 1, characterized in that, The device trust assessment attributes are N device attributes of the target object, the target attributes belong to P objects, and the objects refer to device manufacturers or device types, where P and N are both positive integers.

3. The method according to claim 2, characterized in that, The attribute evaluation results of the affected device include first evaluation sub-results corresponding to M device attributes, where M is a positive integer greater than or equal to N. The first evaluation sub-results are obtained after evaluating the first remote proof evidence in the first trust evaluation data, which was obtained during the previous evaluation of the device attributes of the affected device. Updating the attribute evaluation results of the affected device includes: Determine the second evaluation sub-results corresponding to the N device attributes of the target object; Based on the N second evaluation sub-results, the first evaluation sub-results corresponding to the N device attributes in the affected devices are updated respectively.

4. The method according to claim 1, characterized in that, The device trust assessment attribute is an assessment strategy associated with device attributes.

5. The method according to claim 4, characterized in that, The updating of the attribute evaluation results of the affected device includes: Based on the device information of the affected device, the second trust assessment data of the affected device is re-acquired, and the second trust assessment data includes second remote proof evidence. Based on the second remote proof evidence, the updated evaluation sub-results corresponding to the M device attributes of the affected device are determined.

6. The method according to claim 5, characterized in that, The step of re-acquiring the second trust assessment data of the affected device based on the device information of the affected device includes: Based on the device information of the affected device, parameters to be evaluated are determined, and the parameters to be evaluated are used to instruct the affected device to provide the second remote proof evidence; Identify the target control node for controlling access permissions to the affected devices; Send the parameters to be evaluated and the device information of the affected device to the target control node; Receive the second trust assessment data sent by the target control node.

7. The method according to claim 5 or 6, characterized in that, The M device attributes include the attributes of the first target device; The step of determining the updated evaluation sub-results corresponding to the M device attributes of the affected device based on the second remote proof data includes: Extract the first attribute evaluation information corresponding to the first target device attribute from the second remote proof data; Send the first attribute evaluation information to the target attribute evaluation node corresponding to the first target device attribute; Receive the updated evaluation sub-result returned by the target attribute evaluation node.

8. The method according to claim 5 or 6, characterized in that, The M device attributes include the second target device attributes; The step of determining the updated evaluation sub-results corresponding to the M device attributes of the affected device based on the second remote proof data includes: Extract the second attribute evaluation information corresponding to the second target device attribute from the second remote proof data; Based on the second attribute evaluation information and the evaluation strategy associated with the second target device attribute, the second target device attribute of the affected device is re-evaluated to obtain the updated evaluation sub-result corresponding to the second target device attribute.

9. The method according to claim 8, characterized in that, The second target device attribute is reputation; The method of re-evaluating the second target device attribute of the affected device based on the second attribute evaluation information and the evaluation strategy associated with the second target device attribute, to obtain an updated evaluation sub-result corresponding to the second target device attribute, includes: Based on the second attribute evaluation information and the evaluation strategy associated with the second target device attribute, the second target device attribute of the affected device is re-evaluated to obtain the current evaluation sub-result; Based on the equipment information of the affected equipment, obtain the historical evaluation sub-results corresponding to the attributes of the second target equipment; Based on the current evaluation sub-result and the historical evaluation sub-result, the updated evaluation sub-result corresponding to the second target device attribute is determined.

10. The method according to any one of claims 1 to 9, characterized in that, The step of re-evaluating the trust of the affected device based on the updated attribute evaluation results to obtain the target trust evaluation result of the affected device includes: Determine the contextual importance metrics of the affected device; Based on the updated attribute evaluation results and the importance index, the affected device is re-evaluated to obtain the current trust evaluation result of the affected device; Based on the current trust assessment results of the affected devices, the target trust assessment results of the affected devices are determined.

11. The method according to claim 10, characterized in that, The importance index is sent by the target control node, which is used to control the access permissions of the affected device.

12. The method according to claim 10 or 11, characterized in that, Determining the target trust assessment result of the affected device based on its current trust assessment result includes: Based on the device information of the affected devices, obtain the historical trust assessment results of the affected devices; Based on the historical trust assessment results and the current trust assessment results, the target trust assessment result for the affected device is determined.

13. The method according to any one of claims 1 to 12, characterized in that, The method further includes: The system receives a change identifier sent by a target attribute evaluation node, which is used to evaluate a first target device attribute. The change identifier is either a first identifier or a second identifier. The first identifier is used to indicate that the first target device attribute of the target object has changed, and the second identifier is used to indicate that the evaluation strategy associated with the first target device attribute has changed.

14. A trust assessment device, characterized in that, include: The determination module is used to identify affected devices when device trust assessment attributes change; The update module is used to update the attribute evaluation results of the affected devices; An evaluation module is used to re-evaluate the trust of the affected device based on the updated attribute evaluation results, and obtain a target trust evaluation result for the affected device. The target trust evaluation result is used to adjust the access permissions of the affected device.

15. A trust assessment device, characterized in that, It includes a memory and a processor, the memory being used to store computer instructions, and the processor being used to retrieve and execute the computer instructions from the memory to implement the method as described in any one of claims 1-13.

16. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed on a processor, implement the method as described in any one of claims 1-13.

17. A computer program product, characterized in that, The computer program product includes instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1-13.

Images